idnits 2.17.1 draft-winterbottom-geopriv-held-identity-extensions-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-winterbottom-geopriv-held-identity-extensions', is 51 characters long, but may be at most 50 characters Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 149 has weird spacing: '...dDevice xmlns...' -- 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 (October 24, 2007) is 6022 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) == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-02 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-05 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') == Outdated reference: A later version (-06) exists of draft-thomson-geopriv-held-measurements-00 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew Corporation 5 Expires: April 26, 2008 October 24, 2007 7 HELD Device identity Extensions 8 draft-winterbottom-geopriv-held-identity-extensions-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines a set of URIs for Device identities and a XML 42 containment schema. These can be used in conjunction with HELD to 43 provide Device identification beyond source IP Address. Examples and 44 usage in HELD message syntax are provided. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 5 52 3.1.1. Ethernet MAC URI . . . . . . . . . . . . . . . . . . . 5 53 3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 5 54 3.2. Device Identity Schema . . . . . . . . . . . . . . . . . . 6 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 57 5.1. URN Sub-Namespace Registration for 58 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 10 59 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10 60 5.3. Identifier 'type' Attribute values . . . . . . . . . . . . 11 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 7.1. Normative references . . . . . . . . . . . . . . . . . . . 13 64 7.2. Informative references . . . . . . . . . . . . . . . . . . 13 65 Appendix A. Alternatives . . . . . . . . . . . . . . . . . . . . 15 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 67 Intellectual Property and Copyright Statements . . . . . . . . . . 17 69 1. Introduction 71 Protocols such as HELD [I-D.ietf-geopriv-http-location-delivery] need 72 to identify a device in order to perform some task. Basic HELD only 73 provides device identity through the IP address of the requesting 74 Target, while [I-D.ietf-geopriv-l7-lcp-ps] provides examples of where 75 this may be insufficent. This memo defines a set of URIs an a 76 containment schema that allow the specification of device identity 77 beyond source IP address and may be used with HELD and general 78 presence documents as described in [RFC4479]. 80 2. Terminology 82 The key conventions and terminology used in this document are defined 83 as follows: 85 This document reuses the terms Device and Target, as defined in 86 [RFC3693]. 88 This document uses the term Location Information Server, LIS as 89 described in [I-D.ietf-geopriv-l7-lcp-ps]. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. Details 97 The details of this memo consist of a simple schema extension for 98 HELD to support the inclusion of a device identity in the form of a 99 URI or typed-token, and a set of URI definitions that can be used for 100 device identities. 102 3.1. URI Definitions 104 The URIs defined in this section are designed to identify a device. 105 The URIs identify the Device, they do not identify measurements or 106 sighting data associated with a Device, such as the switch and port 107 information to which the Device is attached (which can be acquired 108 using DHCP relay information [RFC3046] or LLDP [LLDP]. Device 109 measurements and sighting data are described in 110 [I-D.thomson-geopriv-held-measurements]. The identity provided may 111 be transitory, such as an IP address that is leased from a DHCP 112 server pool, but it MUST uniquely identify a device within a network 113 at the time it is used. 115 The URIs in this section are defined using ABNF (augmented Backus- 116 Naur form) described in [RFC2234]. 118 3.1.1. Ethernet MAC URI 120 This is the Ethernet hardware address of the device. The form of 121 this URI is used as example in [RFC4479] and this section provides 122 the ABNF for this URI type. An example of its use is provided in 123 Figure 5. 125 mac-uri = "mac:" 12*12HEXDIG 127 3.1.2. IP Address URIs 129 This section provides the ABNF for IP version 4 and IP version 6 130 URIs. One application of this URI scheme is described in 131 [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to 132 make location requests to a LIS on-behalf-of a Device because, for 133 some reason, the necessary information was not provided by the 134 Device. 136 ip-uri = "ip:" ipv4 / ipv6 137 ipv4 = "IPv4+" IPv4-Address 138 IPv4-Address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 139 ipv6 = "IPv6+" hexpart [ ":" IPv4-Address ] 140 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 141 hexseq = hex4 *( ":" hex4) 142 hex4 = 1*4HEXDIG 143 An example of a location request including a URI in this form to 144 identify the Target device is shown in Figure 3. 146 148 geodetic 149 150 ip:IPv4+192.0.2.5 151 152 154 Figure 3: HELD Location Request Using an IP Address 156 Note that the URI types are not case sensative and the iP:ipv4+ 157 192.0.2.5 is still a valid URI. 159 3.2. Device Identity Schema 161 This section defines a schema that can be used to provide device 162 identities in a HELD location request. 164 165 172 174 175 176 177 179 180 181 183 185 186 187 188 190 191 192 194 196 197 198 200 202 203 205 207 209 Figure 4: Device identity schema 211 The schema provided in Figure 4 allows a URI and/or token to be 212 provided so a Device can identify itself by more than just its IP 213 address. The URI can also include an optional "type" attribute so 214 that URIs that might otherwise look the same can be distinguished 215 based on their usage. 217 For example sip:callee@example.com or sip:callee@example.com 220 When the element is used the "type" attribute is 221 mandatory as this tells the LIS or receiving entity how to interpret 222 the identifier. An IANA registry is established for the central 223 repository for recognized identifier types. The set of initial types 224 is provided in Section 5.3. 226 A HELD location request sent by a device using the schema shown in 227 Figure 4 to provide its identity as a mac URI would look similar to 228 Figure 5. 230 232 geodetic 233 234 mac:01ab34ef690c 235 236 238 Figure 5: HELD Location Request URI example 240 Similarly a device identifying itself using its DHCP client 241 identifier (DHCP option 61 in [RFC2132]) in a location request to a 242 LIS would send something similar to Figure 6. 244 246 geodetic 247 248 035552764 249 250 252 Figure 6: HELD Location Request Identifier example 254 4. Security Considerations 256 An Operator of a LIS that supports this schema extension needs to 257 ensure that location provided to nodes requesting location in this 258 manner are entitled to the location information being requested. In 259 some circumstances support of this schema extension will be 260 inappropriate and alternative measures will need to be employed. 262 5. IANA Considerations 264 This document registers an XML namespace and schema with IANA in 265 accordance with guidelines in [RFC3688]. It also creates a new 266 registry for device identity types, and stipulates how new types are 267 to be added. 269 5.1. URN Sub-Namespace Registration for 270 urn:ietf:params:xml:ns:geopriv:held:id 272 This section registers a new XML namespace, 273 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in 274 [RFC3688]. 276 URI: urn:ietf:params:xml:ns:geopriv:held:id 278 Registrant Contact: IETF, GEOPRIV working group, 279 (geopriv@ietf.org), James Winterbottom 280 (james.winterbottom@andrew.com). 282 XML: 284 BEGIN 285 286 288 289 290 HELD Device Identity Extensions 291 292 293

Namespace for HELD Device Identity Extensions

294

urn:ietf:params:xml:ns:geopriv:held:id

295 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 296 with the RFC number for this specification.]] 297

See RFCXXXX.

298 299 300 END 302 5.2. XML Schema Registration 304 This section registers an XML schema as per the guidelines in 305 [RFC3688]. 307 URI: urn:ietf:params:xml:schema:geopriv:held:id 309 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 310 James Winterbottom (james.winterbottom@andrew.com). 312 Schema: The XML for this schema can be found as the entirety of 313 Figure 4 of this document. 315 5.3. Identifier 'type' Attribute values 317 This document requests that the IANA create a new registry for 318 identifier 'type' attribute values. These are text strings that 319 clarify how the value identifies the Device. Referring to [RFC2434] 320 this registry operates under the "Expert Review" rule. 322 The following identifier types are registered as part of this memo: 324 o 'dhcpClientId' The DHCP client identifier as defined by DHCP 325 option 61 in [RFC2132] 327 o 'msisdn' The Mobile Station International Subscriber Dial Number. 328 This is an E.164 number made up of 6 to 15 digits 330 o 'imsi' The International Mobile Subscriber identifier. A unique 331 identifier for GSM or UMTS mobile terminal made up of 6 to 15 332 digits that identify the country code, the network code and 333 device. 335 o 'imei' The International Mobile Equipment identifier. This is an 336 electronic serial number for a mobile device and is consists of up 337 to 15 digits 339 o 'min' Mobile Identification Number. A unique equipment identifier 340 assigned to CDMA handsets. 342 o 'mdn' Mobile Dial Number. An E.164 number made up of 6 to 15 343 digits. 345 o 'hostname' The hostname or FQDN of the device. 347 6. Acknowledgements 349 The authors wish to thank the NENA VoIP location working group for 350 their assistance in the definition of the schema used in this 351 document. Special thanks go to Barbara Stark, Guy Caron, Nadine 352 Abbott, Jerome Grenier and Martin Dawson. Thanks also to Bob Sherry 353 for requesting that URI-types be supported which led to the typedURI 354 form. 356 7. References 358 7.1. Normative references 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 364 January 2004. 366 [I-D.ietf-geopriv-http-location-delivery] 367 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 368 "HTTP Enabled Location Delivery (HELD)", 369 draft-ietf-geopriv-http-location-delivery-02 (work in 370 progress), September 2007. 372 [I-D.ietf-geopriv-l7-lcp-ps] 373 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 374 Location Configuration Protocol; Problem Statement and 375 Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in 376 progress), September 2007. 378 [I-D.thomson-geopriv-held-measurements] 379 Thomson, M. and J. Winterbottom, "Using Device-provided 380 Location Measurements in HELD", 381 draft-thomson-geopriv-held-measurements-00 (work in 382 progress), October 2007. 384 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 385 Specifications: ABNF", RFC 2234, November 1997. 387 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 388 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 389 October 1998. 391 7.2. Informative references 393 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 394 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 396 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 397 Extensions", RFC 2132, March 1997. 399 [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan 400 area networks, Station and Media Access Control 401 Connectivity Discovery", June 2005. 403 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 404 RFC 3046, January 2001. 406 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 407 RFC 3966, December 2004. 409 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 410 July 2006. 412 Appendix A. Alternatives 414 An alternative to providing the mobile identifiers as an 415 'type' they could be defined as URI types as shown below. This would 416 fit seeming well as other telephony device identifiers are already 417 specified using telephone URIs [RFC3966]. 419 mobile-uri = "mob:" mobile-identifier 420 mobile-identifier = imsi / msisdn / imei / min / mdn 421 imsi = "imsi:" 6*15DIGIT 422 msisdn = "msisdn:" 6*15DIGIT 423 imei = "imei:" 1*15DIGIT 424 min = "min:" 1*15DIGIT 425 mdn = "mdn:" 6*15DIGIT 427 The URIs defined above allow an easy way for the Device to specify 428 this binding to a LIS by using a HELD location request. When the LIS 429 receives the location request in Figure 9 it is able to bind the 430 source IP address of the location request with the provided MSISDN. 432 434 geodetic 435 436 mob:msisdn:61448266004 437 438 440 Figure 9: HELD Location Request Using MSISDN 442 Authors' Addresses 444 James Winterbottom 445 Andrew Corporation 446 PO Box U40 447 University of Wollongong, NSW 2500 448 AU 450 Email: james.winterbottom@andrew.com 452 Martin Thomson 453 Andrew Corporation 454 PO Box U40 455 University of Wollongong, NSW 2500 456 AU 458 Email: martin.thomson@andrew.com 460 Full Copyright Statement 462 Copyright (C) The IETF Trust (2007). 464 This document is subject to the rights, licenses and restrictions 465 contained in BCP 78, and except as set forth therein, the authors 466 retain all their rights. 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 471 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 472 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 473 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Intellectual Property 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be 485 found in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this 491 specification can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org. 500 Acknowledgment 502 Funding for the RFC Editor function is provided by the IETF 503 Administrative Support Activity (IASA).