idnits 2.17.00 (12 Aug 2021)
/tmp/idnits8208/draft-linsner-geopriv-adminspecific-01.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 18.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 375.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 352.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 359.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 365.
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 :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [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 14, 2008) is 5058 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 310, but no explicit reference
was found in the text
Summary: 2 errors (**), 0 flaws (~~), 2 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 2009 Cisco Systems
5 H. Tschofenig
6 Nokia Siemens Networks
7 July 14, 2008
9 Administrative Specific Elements for Civic Location Format
10 draft-linsner-geopriv-adminspecific-01.txt
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that
15 any applicable patent or other IPR claims of which he or she is
16 aware have been or will be disclosed, and any of which he or she
17 becomes aware will be disclosed, in accordance with Section 6 of
18 BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
23 Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html
36 This Internet-Draft will expire on January 15, 2009.
38 Copyright Notice
40 Copyright (C) The IETF Trust (2008).
42 Abstract
44 This document defines additional civic address parameters for use in
45 Location Objects [1], [2], and [4]. The format is based on the civic
46 address definition of PIDF-LO. These addition parameters allow
47 expression of administrative specific location data elements.
49 Conventions used in this document
51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
53 document are to be interpreted as described in RFC-2119 [1].
55 Table of Contents
57 1. Introduction...................................................2
58 2. Administrative Specific Location...............................3
59 2.1. Examples of the Admin specific location parameters........5
60 3. Example Schema.................................................6
61 4. Security Considerations........................................7
62 5. IANA Considerations............................................7
63 5.1. XML Schema Registration...................................7
64 5.2. CAType Registry Update....................................7
65 6. Acknowledgments................................................7
66 7. References.....................................................8
67 7.1. Normative References......................................8
68 7.2. Informative References....................................8
69 Author's Addresses................................................8
70 Intellectual Property Statement...................................9
71 Disclaimer of Validity............................................9
73 1. Introduction
75 In large enterprise/campus networks, information about a host's
76 network/campus location is often useful for internal application
77 configuration and maintenance of both applications and network
78 infrastructure. Typically, this is information that is not useful
79 outside of the campus or enterprise. Currently, this information is
80 collected via additional data collection mechanisms such as SNMP or
81 link layer protocols.
83 The information included within this locally significant data set
84 includes elements like access point identifier, switch port
85 identifier, administrative domain identifier, etc. Although these
86 attributes are not normally associated with publicly known civic
87 locations advertised outside the enterprise, they are none the less
88 very important to the configuration, administration and maintenance
89 of campus networks/applications. These elements are considered
90 'location' within the domain of enterprise application and
91 infrastructure administration.
93 Although PIDF-LO civic location currently supports additional
94 elements such as CAtypes 28 (room), 32 (additional code), or 33
95 (seat), the use of already defined fields for internal purposes is
96 problematic as there may be conflicts in the future. Therefore, there
97 is the need to identify a range of elements that network/application
98 administrators can use for their own local purposes.
100 Since these additional CAtypes are designated for internal
101 administrative usage and have no value outside the administrative
102 domain, the additional CAtypes defined here SHOULD be deleted from
103 any location object (LO) prior to the LO being distributed outside
104 the respective administrative domain.
106 Additions to PIDF-LO
108 PIDF-LO, as updated by [2], includes a full set of parameters used to
109 describe civic locations. The new parameters defined here are
110 additions to the updated set. Such additions provide a means to
111 describe a host's location with additional local administrative
112 significance.
114 2. Administrative Specific Location
116 Administrative Specific Location elements are defined by first
117 identifying the Administrative domain via a new CAType. The CAtype
118 200 is recommended for this purpose. It is then suggested that the
119 CAtype 201 to 225 be reserved for the Administrative domain specified
120 information.
122 New Civic CAtype Description Example
123 Field
125 Admin 200 Administrative Identifier Cisco
127 AS-1 201 Administrative specific location Port-6
128 element 1
130 AS-2 202 Administrative specific location Region-12
131 element 2
133 AS-3 203 Administrative specific location Sector-9
134 element 3
136 AS-4 204 Administrative specific location Response
137 element 4 team-6
139 AS-5 205 Administrative specific location 987654
140 element 5
142 AS-6 206 Administrative specific location
143 element 6
145 AS-7 207 Administrative specific location
146 element 7
148 AS-8 208 Administrative specific location
149 element 8
151 AS-9 209 Administrative specific location
152 element 9
154 AS-10 210 Administrative specific location
155 element 10
157 AS-11 211 Administrative specific location
158 element 11
160 AS-12 212 Administrative specific location
161 element 12
163 AS-13 213 Administrative specific location
164 element 13
166 AS-14 214 Administrative specific location
167 element 14
169 AS-15 215 Administrative specific location
170 element 15
172 AS-16 216 Administrative specific location
173 element 16
175 AS-17 217 Administrative specific location
176 element 17
178 AS-18 218 Administrative specific location
179 element 18
181 AS-19 219 Administrative specific location
182 element 19
184 AS-20 220 Administrative specific location
185 element 20
187 AS-21 221 Administrative specific location
188 element 21
190 AS-22 222 Administrative specific location
191 element 22
193 AS-23 223 Administrative specific location
194 element 23
196 AS-24 224 Administrative specific location
197 element 24
199 AS-25 225 Administrative specific location
200 element 25
202 Table 1: New CAtypes
204 2.1. Examples of the Admin specific location parameters
206 A location that includes administrative specific information for
207 switch number 6, port 3.
209 cisco
211 sw6port3
213 A location that includes administrative specific information for zone
214 6.
216 cisco
218 zone6
220 3. Example Schema
222
228
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
256
257
258
259
261
262
263
264
266
267
268
269
271
272
273
274 4. Security Considerations
276 The XML parameters defined in the document are additions to the
277 current PIDF-LO specification. Therefore the parameters defined here
278 are subject to the same security considerations of [1].
280 5. IANA Considerations
282 5.1. XML Schema Registration
284 IANA will update the registered XML schema with additions as shown in
285 section 3. of this document.
287 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
289 5.2. CAType Registry Update
291 IANA will update the civic address type registry established by
292 RFC4776. The additions to the registry are shown in Table 1 of the
293 document.
295 6. Acknowledgments
297 This document was prepared using 2-Word-v2.0.template.dot.
299 7. References
301 7.1. Normative References
303 [1] Petersen, J., "A Presence-based GEOPRIV Location Object
304 Format", RFC 4119, December 2005.
306 [2] Thomson, M. & Winterbottom, J., "Revised Civic Location Format
307 for Presence Identifier Format Location Object (PIDF-LO)", RFC
308 5139, February 2008.
310 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
311 Levels", BCP 14, RFC 2119, March 1997.
313 [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
314 and DHCPv6) Option for Civic Addresses Configuration
315 Information", RFC4776, November 2006
317 7.2. Informative References
319 Author's Addresses
321 Marc Linsner
322 Cisco Systems, Inc.
323 Marco Island, Florida, USA
325 Email: mlinsner@cisco.com
327 Subha Dhesikan
328 Cisco Systems, Inc.
329 San Jose, California, USA
331 Email: sdhesika@cisco.com
333 Hannes Tschofenig
334 Nokia Siemens Networks
335 Linnoitustie 6
336 Espoo 02600
337 Finland
339 Phone: +358 (50) 4871445
340 Email: Hannes.Tschofenig@gmx.net
341 URI: http://www.tschofenig.priv.at
343 Intellectual Property Statement
345 The IETF takes no position regarding the validity or scope of any
346 Intellectual Property Rights or other rights that might be claimed to
347 pertain to the implementation or use of the technology described in
348 this document or the extent to which any license under such rights
349 might or might not be available; nor does it represent that it has
350 made any independent effort to identify any such rights. Information
351 on the procedures with respect to rights in RFC documents can be
352 found in BCP 78 and BCP 79.
354 Copies of IPR disclosures made to the IETF Secretariat and any
355 assurances of licenses to be made available, or the result of an
356 attempt made to obtain a general license or permission for the use of
357 such proprietary rights by implementers or users of this
358 specification can be obtained from the IETF on-line IPR repository at
359 http://www.ietf.org/ipr.
361 The IETF invites any interested party to bring to its attention any
362 copyrights, patents or patent applications, or other proprietary
363 rights that may cover technology that may be required to implement
364 this standard. Please address the information to the IETF at
365 ietf-ipr@ietf.org.
367 Disclaimer of Validity
369 This document and the information contained herein are provided on an
370 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
371 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
372 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
373 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
374 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
375 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
377 Copyright Statement
379 Copyright (C) The IETF Trust (2008).
381 This document is subject to the rights, licenses and restrictions
382 contained in BCP 78, and except as set forth therein, the authors
383 retain all their rights.
385 Acknowledgment
387 Funding for the RFC Editor function is currently provided by the
388 Internet Society.