GeoPriv M. Linsner Internet Draft Cisco Systems Intended status: Standards Track S. Dhesikan Expires: January12, 20082009 Cisco Systems H. Tschofenig Nokia Siemens Networks July11, 200714, 2008 Administrative Specific Elements for Civic Location Formatdraft-linsner-geopriv-adminspecific-00.txtdraft-linsner-geopriv-adminspecific-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January12, 2008.15, 2009. Copyright Notice Copyright (C) The IETF Trust(2007).(2008). Abstract This document defines additional civic address parameters for use in Location Objects[1][1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These addition parameters allow expression of administrative specific location data elements. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Administrative Specific Location...............................3 2.1. Examples of the Admin specific location parameters........5 3. Example Schema.................................................6 4. Security Considerations........................................7 5. IANA Considerations............................................7 5.1. XML Schema Registration...................................7 5.2. CAType Registry Update....................................7 6. Acknowledgments................................................7 7. References.....................................................8 7.1. Normative References......................................8 7.2. Informative References....................................8 Author's Addresses................................................8 Intellectual PropertyStatement...................................8Statement...................................9 Disclaimer of Validity............................................9 1. Introduction In large enterprise/campus networks, information about a host's network/campus location is often useful for internal application configuration and maintenance of both applications and network infrastructure. Typically, this is information that is not useful outside of the campus or enterprise. Currently, this information is collected via additional data collection mechanisms such as SNMP or link layer protocols. The information included within this locally significant data set includes elements like access point identifier, switch port identifier, administrative domain identifier, etc. Although these attributes are not normally associated with publicly known civic locations advertised outside the enterprise, they are none the less very important to the configuration, administration and maintenance of campus networks/applications. These elements are considered 'location' within the domain of enterprise application and infrastructure administration. Although PIDF-LO civic location currently supports additional elements such as CAtypes 28 (room), 32 (additional code), or 33 (seat), the use of already defined fields for internal purposes is problematic as there may be conflicts in the future. Therefore, there is the need to identify a range of elements that network/application administrators can use for their own local purposes. Since these additional CAtypes are designated for internal administrative usage and have no value outside the administrative domain, the additional CAtypes defined here SHOULD be deleted from any location object (LO) prior to the LO being distributed outside the respective administrative domain. Additions to PIDF-LO PIDF-LO, as updated by [2], includes a full set of parameters used to describe civic locations. The new parameters defined here are additions to the updated set. Such additions provide a means to describe a host's location with additional local administrative significance. 2. Administrative Specific Location Administrative Specific Location elements are defined by first identifying the Administrative domain via a new CAType. The CAtype 200 is recommended for this purpose. It is then suggested that the CAtype 201 to 225 be reserved for the Administrative domain specified information. New Civic CAtype Description Example Field Admin 200 Administrative Identifier Cisco AS-1 201 Administrative specific location Port-6 element 1 AS-2 202 Administrative specific location Region-12 element 2 AS-3 203 Administrative specific location Sector-9 element 3 AS-4 204 Administrative specific location Response element 4 team-6 AS-5 205 Administrative specific location 987654 element 5 AS-6 206 Administrative specific location element 6 AS-7 207 Administrative specific location element 7 AS-8 208 Administrative specific location element 8 AS-9 209 Administrative specific location element 9 AS-10 210 Administrative specific location element 10 AS-11 211 Administrative specific location element 11 AS-12 212 Administrative specific location element 12 AS-13 213 Administrative specific location element 13 AS-14 214 Administrative specific location element 14 AS-15 215 Administrative specific location element 15 AS-16 216 Administrative specific location element 16 AS-17 217 Administrative specific location element 17 AS-18 218 Administrative specific location element 18 AS-19 219 Administrative specific location element 19 AS-20 220 Administrative specific location element 20 AS-21 221 Administrative specific location element 21 AS-22 222 Administrative specific location element 22 AS-23 223 Administrative specific location element 23 AS-24 224 Administrative specific location element 24 AS-25 225 Administrative specific location element 25 Table 1: New CAtypes 2.1. Examples of the Admin specific location parameters A location that includes administrative specific information for switch number 6, port 3. <ADMIN>cisco</ADMIN> <AS-1>sw6port3</AS-1> A location that includes administrative specific information for zone 6. <ADMIN>cisco</ADMIN> <AS-2>zone6</AS-2> 3. Example Schema <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:xml="http://www.w3.org/XML/1998/namespace" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd" /> <xs:element name="civicAddress" type="ca:civicAddress" /> <xs:complexType name="caType"> <xs:simpleContent> <xs:extension base="xs:token"> <xs:attribute ref="xml:lang" use="optional" /> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="civicAddress"> <xs:sequence> <!-- additions to civicAddress --> <xs:element name="admin" type="ca:caType" minOccurs="0" /> <xs:element name="as-1" type="ca:caType" minOccurs="0" /> <xs:element name="as-2" type="ca:caType" minOccurs="0" /> <xs:element name="as-3" type="ca:caType" minOccurs="0" /> <xs:element name="as-4" type="ca:caType" minOccurs="0" /> <xs:element name="as-5" type="ca:caType" minOccurs="0" /> <xs:element name="as-6" type="ca:caType" minOccurs="0" /> <xs:element name="as-7" type="ca:caType" minOccurs="0" /> <xs:element name="as-8" type="ca:caType" minOccurs="0" /> <xs:element name="as-9" type="ca:caType" minOccurs="0" /> <xs:element name="as-10" type="ca:caType" minOccurs="0" /> <xs:element name="as-11" type="ca:caType" minOccurs="0" /> <xs:element name="as-12" type="ca:caType" minOccurs="0" /> <xs:element name="as-13" type="ca:caType" minOccurs="0" /> <xs:element name="as-14" type="ca:caType" minOccurs="0" /> <xs:element name="as-15" type="ca:caType" minOccurs="0" /> <xs:element name="as-16" type="ca:caType" minOccurs="0" /> <xs:element name="as-17" type="ca:caType" minOccurs="0" /> <xs:element name="as-18" type="ca:caType" minOccurs="0" /> <xs:element name="as-19" type="ca:caType" minOccurs="0" /> <xs:element name="as-20" type="ca:caType" minOccurs="0" /> <xs:element name="as-21" type="ca:caType" minOccurs="0" /> <xs:element name="as-22" type="ca:caType" minOccurs="0" /> <xs:element name="as-23" type="ca:caType" minOccurs="0" /> <xs:element name="as-24" type="ca:caType" minOccurs="0" /> <xs:element name="as-25" type="ca:caType" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:schema> 4. Security Considerations The XML parameters defined in the document are additions to the current PIDF-LO specification. Therefore the parameters defined here are subject to the same security considerations of [1]. 5. IANA Considerations 5.1. XML Schema Registration IANA will update the registered XML schema with additions as shown in section 3. of this document. URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 5.2. CAType Registry Update IANA will update the civic address type registry established by RFC4776. The additions to the registry are shown in Table 1 of the document. 6. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 7. References 7.1. Normative References [1] Petersen, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [2] Thomson, M. & Winterbottom, J., "Revised Civic Location Format forPIDF-LO", draft-ietf-geopriv-revised-civic-lo-05.txt,Presence Identifier Format Location Object (PIDF-LO)", RFC 5139, February2007.2008. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC4776, November 2006 7.2. Informative References Author's Addresses Marc Linsner Cisco Systems, Inc. Marco Island, Florida, USA Email: mlinsner@cisco.com Subha Dhesikan Cisco Systems, Inc. San Jose, California, USA Email: sdhesika@cisco.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust(2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.