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