idnits 2.17.00 (12 Aug 2021)
/tmp/idnits61694/draft-linsner-geopriv-adminspecific-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
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 and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 5, 2009) is 4818 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 322, but no explicit reference
was found in the text
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: September 2009 Cisco Systems
5 H. Tschofenig
6 Nokia Siemens Networks
7 March 5, 2009
9 Administrative Specific Elements for Civic Location Format
10 draft-linsner-geopriv-adminspecific-02.txt
12 Status of this Memo
14 This Internet-Draft is submitted to IETF in full conformance with the
15 provisions of BCP 78 and BCP 79.
17 This document may contain material from IETF Documents or IETF
18 Contributions published or made publicly available before November
19 10, 2008. The person(s) controlling the copyright in some of this
20 material may not have granted the IETF Trust the right to allow
21 modifications of such material outside the IETF Standards Process.
22 Without obtaining an adequate license from the person(s) controlling
23 the copyright in such materials, this document may not be modified
24 outside the IETF Standards Process, and derivative works of it may
25 not be created outside the IETF Standards Process, except to format
26 it for publication as an RFC or to translate it into languages other
27 than English.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF), its areas, and its working groups. Note that
31 other groups may also distribute working documents as Internet-
32 Drafts.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 The list of current Internet-Drafts can be accessed at
40 http://www.ietf.org/ietf/1id-abstracts.txt
42 The list of Internet-Draft Shadow Directories can be accessed at
43 http://www.ietf.org/shadow.html
45 This Internet-Draft will expire on September 7, 2009.
47 Copyright Notice
49 Copyright (c) 2009 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents in effect on the date of
54 publication of this document (http://trustee.ietf.org/license-info).
55 Please review these documents carefully, as they describe your rights
56 and restrictions with respect to this document.
58 Abstract
60 This document defines additional civic address parameters for use in
61 Location Objects [1], [2], and [4]. The format is based on the civic
62 address definition of PIDF-LO. These addition parameters allow
63 expression of administrative specific location data elements.
65 Table of Contents
67 1. Introduction...................................................2
68 2. Conventions used in this document..............................3
69 3. Administrative Specific Location...............................3
70 3.1. Examples of the Admin specific location parameters........5
71 4. Example Schema.................................................6
72 5. Security Considerations........................................7
73 6. IANA Considerations............................................7
74 6.1. XML Schema Registration...................................7
75 6.2. CAType Registry Update....................................8
76 7. References.....................................................8
77 7.1. Normative References......................................8
78 7.2. Informative References....................................8
79 8. Acknowledgments................................................8
80 Author's Addresses................................................9
82 1. Introduction
84 In large enterprise/campus networks, information about a host's
85 network/campus location is often useful for internal application
86 configuration and maintenance of both applications and network
87 infrastructure. Typically, this is information that is not useful
88 outside of the campus or enterprise. Currently, this information is
89 collected via additional data collection mechanisms such as SNMP or
90 link layer protocols.
92 The information included within this locally significant data set
93 includes elements like access point identifier, switch port
94 identifier, administrative domain identifier, etc. Although these
95 attributes are not normally associated with publicly known civic
96 locations advertised outside the enterprise, they are none the less
97 very important to the configuration, administration and maintenance
98 of campus networks/applications. These elements are considered
99 'location' within the domain of enterprise application and
100 infrastructure administration.
102 Although PIDF-LO civic location currently supports additional
103 elements such as CAtypes 28 (room), 32 (additional code), or 33
104 (seat), the use of already defined fields for internal purposes is
105 problematic as there may be conflicts in the future. Therefore, there
106 is the need to identify a range of elements that network/application
107 administrators can use for their own local purposes.
109 Since these additional CAtypes are designated for internal
110 administrative usage and have no value outside the administrative
111 domain, the additional CAtypes defined here SHOULD be deleted from
112 any location object (LO) prior to the LO being distributed outside
113 the respective administrative domain.
115 Additions to PIDF-LO
117 PIDF-LO, as updated by [2], includes a full set of parameters used to
118 describe civic locations. The new parameters defined here are
119 additions to the updated set. Such additions provide a means to
120 describe a host's location with additional local administrative
121 significance.
123 2. Conventions used in this document
125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
127 document are to be interpreted as described in RFC-2119 [1].
129 3. Administrative Specific Location
131 Administrative Specific Location elements are defined by first
132 identifying the Administrative domain via a new CAType. The CAtype
133 200 is recommended for this purpose. It is then suggested that the
134 CAtype 201 to 225 be reserved for the Administrative domain specified
135 information.
137 New Civic CAtype Description Example
138 Field
140 Admin 200 Administrative Identifier Cisco
142 AS-1 201 Administrative specific location Port-6
143 element 1
145 AS-2 202 Administrative specific location Region-12
146 element 2
148 AS-3 203 Administrative specific location Sector-9
149 element 3
151 AS-4 204 Administrative specific location Response
152 element 4 team-6
154 AS-5 205 Administrative specific location 987654
155 element 5
157 AS-6 206 Administrative specific location
158 element 6
160 AS-7 207 Administrative specific location
161 element 7
163 AS-8 208 Administrative specific location
164 element 8
166 AS-9 209 Administrative specific location
167 element 9
169 AS-10 210 Administrative specific location
170 element 10
172 AS-11 211 Administrative specific location
173 element 11
175 AS-12 212 Administrative specific location
176 element 12
178 AS-13 213 Administrative specific location
179 element 13
181 AS-14 214 Administrative specific location
182 element 14
184 AS-15 215 Administrative specific location
185 element 15
187 AS-16 216 Administrative specific location
188 element 16
190 AS-17 217 Administrative specific location
191 element 17
193 AS-18 218 Administrative specific location
194 element 18
196 AS-19 219 Administrative specific location
197 element 19
199 AS-20 220 Administrative specific location
200 element 20
202 AS-21 221 Administrative specific location
203 element 21
205 AS-22 222 Administrative specific location
206 element 22
208 AS-23 223 Administrative specific location
209 element 23
211 AS-24 224 Administrative specific location
212 element 24
214 AS-25 225 Administrative specific location
215 element 25
217 Table 1: New CAtypes
219 3.1. Examples of the Admin specific location parameters
221 A location that includes administrative specific information for
222 switch number 6, port 3.
224 cisco
226 sw6port3
228 A location that includes administrative specific information for zone
229 6.
231 cisco
233 zone6
235 4. Example Schema
237
243
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
271
272
273
274
276
277
278
279
281
282
283
284
286
287
288
290 5. Security Considerations
292 The XML parameters defined in the document are additions to the
293 current PIDF-LO specification. Therefore the parameters defined here
294 are subject to the same security considerations of [1].
296 6. IANA Considerations
298 6.1. XML Schema Registration
300 IANA will update the registered XML schema with additions as shown in
301 section 4 of this document.
303 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
305 6.2. CAType Registry Update
307 IANA will update the civic address type registry established by
308 RFC4776. The additions to the registry are shown in Table 1 of the
309 document.
311 7. References
313 7.1. Normative References
315 [1] Petersen, J., "A Presence-based GEOPRIV Location Object
316 Format", RFC 4119, December 2005.
318 [2] Thomson, M. & Winterbottom, J., "Revised Civic Location Format
319 for Presence Identifier Format Location Object (PIDF-LO)", RFC
320 5139, February 2008.
322 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
323 Levels", BCP 14, RFC 2119, March 1997.
325 [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
326 and DHCPv6) Option for Civic Addresses Configuration
327 Information", RFC4776, November 2006
329 7.2. Informative References
331 There are no informative references at this time.
333 8. Acknowledgments
335 This document was prepared using 2-Word-v2.0.template.dot.
337 Author's Addresses
339 Marc Linsner
340 Cisco Systems, Inc.
341 Marco Island, Florida, USA
343 Email: mlinsner@cisco.com
345 Subha Dhesikan
346 Cisco Systems, Inc.
347 San Jose, California, USA
349 Email: sdhesika@cisco.com
351 Hannes Tschofenig
352 Nokia Siemens Networks
353 Linnoitustie 6
354 Espoo 02600
355 Finland
357 Phone: +358 (50) 4871445
358 Email: Hannes.Tschofenig@gmx.net
359 URI: http://www.tschofenig.priv.at