idnits 2.17.00 (12 Aug 2021)
/tmp/idnits9024/draft-linsner-geopriv-adminspecific-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 359.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 336.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 343.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 349.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 18 instances of too long lines in the document, the longest
one being 4 characters in excess of 72.
** The abstract seems to contain references ([4], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 11, 2007) is 5427 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: '3' is defined on line 304, but no explicit reference
was found in the text
== Outdated reference: draft-ietf-geopriv-revised-civic-lo has been
published as RFC 5139
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 GeoPriv M. Linsner
2 Internet Draft Cisco Systems
3 Intended status: Standards Track S. Dhesikan
4 Expires: January 12, 2008 Cisco Systems
5 July 11, 2007
7 Administrative Specific Elements for Civic Location Format
8 draft-linsner-geopriv-adminspecific-00.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that
13 any applicable patent or other IPR claims of which he or she is
14 aware have been or will be disclosed, and any of which he or she
15 becomes aware will be disclosed, in accordance with Section 6 of
16 BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html
34 This Internet-Draft will expire on January 12, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2007).
40 Abstract
42 This document defines additional civic address parameters for use in
43 Location Objects [1] and [4]. The format is based on the civic
44 address definition of PIDF-LO. These addition parameters allow
45 expression of administrative specific location data elements.
47 Conventions used in this document
49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
51 document are to be interpreted as described in RFC-2119 [1].
53 Table of Contents
55 1. Introduction...................................................2
56 2. Administrative Specific Location...............................3
57 2.1. Examples of the Admin specific location parameters........5
58 3. Example Schema.................................................6
59 4. Security Considerations........................................7
60 5. IANA Considerations............................................7
61 5.1. XML Schema Registration...................................7
62 5.2. CAType Registry Update....................................7
63 6. Acknowledgments................................................7
64 7. References.....................................................8
65 7.1. Normative References......................................8
66 7.2. Informative References....................................8
67 Author's Addresses................................................8
68 Intellectual Property Statement...................................8
69 Disclaimer of Validity............................................9
71 1. Introduction
73 In large enterprise/campus networks, information about a host's
74 network/campus location is often useful for internal application
75 configuration and maintenance of both applications and network
76 infrastructure. Typically, this is information that is not useful
77 outside of the campus or enterprise. Currently, this information is
78 collected via additional data collection mechanisms such as SNMP or
79 link layer protocols.
81 The information included within this locally significant data set
82 includes elements like access point identifier, switch port
83 identifier, administrative domain identifier, etc. Although these
84 attributes are not normally associated with publicly known civic
85 locations advertised outside the enterprise, they are none the less
86 very important to the configuration, administration and maintenance
87 of campus networks/applications. These elements are considered
88 'location' within the domain of enterprise application and
89 infrastructure administration.
91 Although PIDF-LO civic location currently supports additional
92 elements such as CAtypes 28 (room), 32 (additional code), or 33
93 (seat), the use of already defined fields for internal purposes is
94 problematic as there may be conflicts in the future. Therefore, there
95 is the need to identify a range of elements that network/application
96 administrators can use for their own local purposes.
98 Since these additional CAtypes are designated for internal
99 administrative usage and have no value outside the administrative
100 domain, the additional CAtypes defined here SHOULD be deleted from
101 any location object (LO) prior to the LO being distributed outside
102 the respective administrative domain.
104 Additions to PIDF-LO
106 PIDF-LO, as updated by [2], includes a full set of parameters used to
107 describe civic locations. The new parameters defined here are
108 additions to the updated set. Such additions provide a means to
109 describe a host's location with additional local administrative
110 significance.
112 2. Administrative Specific Location
114 Administrative Specific Location elements are defined by first
115 identifying the Administrative domain via a new CAType. The CAtype
116 200 is recommended for this purpose. It is then suggested that the
117 CAtype 201 to 225 be reserved for the Administrative domain specified
118 information.
120 New Civic CAtype Description Example
121 Field
123 Admin 200 Administrative Identifier Cisco
125 AS-1 201 Administrative specific location Port-6
126 element 1
128 AS-2 202 Administrative specific location Region-12
129 element 2
131 AS-3 203 Administrative specific location Sector-9
132 element 3
134 AS-4 204 Administrative specific location Response
135 element 4 team-6
137 AS-5 205 Administrative specific location 987654
138 element 5
140 AS-6 206 Administrative specific location
141 element 6
143 AS-7 207 Administrative specific location
144 element 7
146 AS-8 208 Administrative specific location
147 element 8
149 AS-9 209 Administrative specific location
150 element 9
152 AS-10 210 Administrative specific location
153 element 10
155 AS-11 211 Administrative specific location
156 element 11
158 AS-12 212 Administrative specific location
159 element 12
161 AS-13 213 Administrative specific location
162 element 13
164 AS-14 214 Administrative specific location
165 element 14
167 AS-15 215 Administrative specific location
168 element 15
170 AS-16 216 Administrative specific location
171 element 16
173 AS-17 217 Administrative specific location
174 element 17
176 AS-18 218 Administrative specific location
177 element 18
179 AS-19 219 Administrative specific location
180 element 19
182 AS-20 220 Administrative specific location
183 element 20
185 AS-21 221 Administrative specific location
186 element 21
188 AS-22 222 Administrative specific location
189 element 22
191 AS-23 223 Administrative specific location
192 element 23
194 AS-24 224 Administrative specific location
195 element 24
197 AS-25 225 Administrative specific location
198 element 25
200 Table 1: New CAtypes
202 2.1. Examples of the Admin specific location parameters
204 A location that includes administrative specific information for
205 switch number 6, port 3.
207 cisco
209 sw6port3
211 A location that includes administrative specific information for zone
212 6.
214 cisco
216 zone6
218 3. Example Schema
220
225
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
268 4. Security Considerations
270 The XML parameters defined in the document are additions to the
271 current PIDF-LO specification. Therefore the parameters defined here
272 are subject to the same security considerations of [1].
274 5. IANA Considerations
276 5.1. XML Schema Registration
278 IANA will update the registered XML schema with additions as shown in
279 section 3. of this document.
281 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
283 5.2. CAType Registry Update
285 IANA will update the civic address type registry established by
286 RFC4776. The additions to the registry are shown in Table 1 of the
287 document.
289 6. Acknowledgments
291 This document was prepared using 2-Word-v2.0.template.dot.
293 7. References
295 7.1. Normative References
297 [1] Petersen, J., "A Presence-based GEOPRIV Location Object
298 Format", RFC 4119, December 2005.
300 [2] Thomson, M. & Winterbottom, J., "Revised Civic Location Format
301 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05.txt,
302 February 2007.
304 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
305 Levels", BCP 14, RFC 2119, March 1997.
307 [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
308 and DHCPv6) Option for Civic Addresses Configuration
309 Information", RFC4776, November 2006
311 7.2. Informative References
313 Author's Addresses
315 Marc Linsner
316 Cisco Systems, Inc.
317 Marco Island, Florida, USA
319 Email: mlinsner@cisco.com
321 Subha Dhesikan
322 Cisco Systems, Inc.
323 San Jose, California, USA
325 Email: sdhesika@cisco.com
327 Intellectual Property Statement
329 The IETF takes no position regarding the validity or scope of any
330 Intellectual Property Rights or other rights that might be claimed to
331 pertain to the implementation or use of the technology described in
332 this document or the extent to which any license under such rights
333 might or might not be available; nor does it represent that it has
334 made any independent effort to identify any such rights. Information
335 on the procedures with respect to rights in RFC documents can be
336 found in BCP 78 and BCP 79.
338 Copies of IPR disclosures made to the IETF Secretariat and any
339 assurances of licenses to be made available, or the result of an
340 attempt made to obtain a general license or permission for the use of
341 such proprietary rights by implementers or users of this
342 specification can be obtained from the IETF on-line IPR repository at
343 http://www.ietf.org/ipr.
345 The IETF invites any interested party to bring to its attention any
346 copyrights, patents or patent applications, or other proprietary
347 rights that may cover technology that may be required to implement
348 this standard. Please address the information to the IETF at
349 ietf-ipr@ietf.org.
351 Disclaimer of Validity
353 This document and the information contained herein are provided on an
354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
356 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
357 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
358 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
361 Copyright Statement
363 Copyright (C) The IETF Trust (2007).
365 This document is subject to the rights, licenses and restrictions
366 contained in BCP 78, and except as set forth therein, the authors
367 retain all their rights.
369 Acknowledgment
371 Funding for the RFC Editor function is currently provided by the
372 Internet Society.