idnits 2.17.1 draft-winterbottom-geopriv-held-identity-extensions-09.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: ---------------------------------------------------------------------------- ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 25, 2009) is 5536 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: 'RFC4388' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'LLDP' is defined on line 807, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-12 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-09 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-07 == Outdated reference: A later version (-06) exists of draft-thomson-geopriv-held-measurements-03 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: August 29, 2009 H. Tschofenig 6 Nokia Siemens Networks 7 R. Barnes 8 BBN Technologies 9 February 25, 2009 11 Use of Target Identity in HTTP-Enabled Location Delivery (HELD) 12 draft-winterbottom-geopriv-held-identity-extensions-09 14 Status of This Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 29, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 When a Location Information Server receives a request for location 51 information (using the locationRequest message), described in the 52 base HTTP Enabled Location Delivery (HELD) specification, it uses the 53 source IP address of arriving message as a pointer to the location 54 determination process. This is sufficient in environments where a 55 Target's location can be determined based on its IP address. 57 Two additional use cases are addresses by this document. In the 58 first, location configuration requires additional or alternative 59 identifiers from the source IP address provided in the request. In 60 the second, an entity other than the Target requests the Target's 61 location. 63 This document extends the HELD protocol to allow the location request 64 message to carry Target identifiers. Privacy and security 65 considerations describe the conditions where requests containing 66 identifiers are permitted. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Target Identity . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Identifier Format and Protocol Details . . . . . . . . . . 6 75 3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 7 77 3.2.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 7 78 3.2.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 8 79 3.2.4. Network Access Identifier . . . . . . . . . . . . . . 8 80 3.2.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.2.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.2.7. Directory Number . . . . . . . . . . . . . . . . . . . 9 83 3.2.8. Cellular Telephony Identifiers . . . . . . . . . . . . 9 84 3.2.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 10 85 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 6.1. Location Configuration Protocol Requests . . . . . . . . . 14 89 6.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 14 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 7.1. URN Sub-Namespace Registration for 92 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14 93 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15 94 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 15 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 9.1. Normative references . . . . . . . . . . . . . . . . . . . 16 98 9.2. Informative references . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 Protocols for requesting and providing location information require a 103 way for the requestor to specify the location that should be 104 returned. In a location configuration protocol (LCP), the location 105 being requested is the requestor's location. This fact can make the 106 problem of identifying the Device simpler for LCPs, since IP 107 datagrams that carry the request already carry an identifier for the 108 Device, namely the source IP address of an incoming request. 109 Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery] 110 and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and 111 possibly lower-layer identifiers to identify a Device. 113 Aside from the datagrams that form a request, a location information 114 server (LIS) does not necessarily have access to information that 115 could further identify the Target. In some circumstances, as shown 116 in [I-D.ietf-geopriv-l7-lcp-ps], additional identification 117 information can be included in a request to identify a Target. 119 This document extends the HELD protocol to support the inclusion of 120 additional identifiers for the Target in HELD location requests. An 121 XML schema is defined that provides a structure for including these 122 identifiers in HELD requests. 124 An important characteristic of this addition to the HELD protocol is 125 that is also expands the potential scope of HELD beyond that of an 126 LCP. The scope of an LCP is limited to the interaction between a 127 Device and a LIS. That is, an LCP is limited to the Device 128 retrieving information about their own location. With this addition, 129 third party location recipients (LRs) are able to make requests that 130 include identifiers to retrieve location information about a 131 particular Target. 133 The usage of HELD for purposes beyond the Device-LIS interaction 134 obviously introduces a new set of privacy concerns. In an LCP, the 135 requester is implicitly authorized to access the requested location 136 information, because it is their own location. In contrast, when a 137 third party LR requests a Target's location, the LR MUST be 138 explicitly authorized. Establishing appropriate authorization and 139 other related privacy concerns are discussed in Section 5. 141 1.1. Applications 143 The use of additional identifiers in HELD falls into two categories. 144 A Device can use these parameters to provide additional 145 identification information to a LIS. Identification such as the 146 hardware address of the Device can be used to reduce the time 147 required to determine the location of the Device. In other cases, a 148 LIS might require Device identification before any location 149 information can be generated. 151 A third party LR can be granted authorization to make requests for a 152 given Target. In particular, network services can be permitted to 153 retrieve location for a Device that is unable to acquire location 154 information for itself (see Section 6.3 of 155 [I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent 156 applications--particularly essential services like emergency 157 calling--where Devices do not support a location configuration 158 protocol (LCP) or they are unable to successfully retrieve location 159 information. 161 2. Terminology 163 This document uses the term Location Information Server (LIS) and 164 location configuration protocol (LCP) as described in 165 [I-D.ietf-geopriv-l7-lcp-ps]. 167 This document reuses the term Target to refer to the subject of any 168 request for location information. The term Device is used 169 specifically as the subject of an LCP, consistent with 170 [I-D.ietf-geopriv-http-location-delivery]. Both these terms are 171 defined in [RFC3693]. 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 3. Target Identity 179 Identifiers are used as the starting point in location determination. 180 They should not be confused with measurement information 181 ([I-D.thomson-geopriv-held-measurements]). Measurement information 182 is information about a Device and the time varying details of its 183 network attachment. Identifiers might be associated with a different 184 Target over time, but the their purpose is to identify the Target, 185 not to describe its environment or network attachment. 187 Use of any identifier MUST only be allowed if it uniquely identifies 188 a single Target. In some circumstances, certain of these identifiers 189 are either temporary or could potentially identify multiple devices. 190 Identifiers that are transient or ambiguous could be exploited by an 191 attacker to either gain information about another device or to obtain 192 misleading information. 194 The identifiers described in this section SHOULD only be used where 195 that identifier is used as the basis for location determination. It 196 is tempting for a LIS implementation to allow alternative identifiers 197 for convenience or some other perceived benefit. However, care needs 198 to be taken to ensure that the binding between the indicated 199 identifier and the identifier that is used for location determination 200 is unique and not subject to attacks. 202 3.1. Identifier Format and Protocol Details 204 XML elements are used to express the Target identity. The "target" 205 element is used as a general container for identity information. 206 This document defines a basic set of identifiers. An example HELD 207 request, shown in Figure 1, includes an IP version 4 address. 209 211 geodetic 212 213 192.0.2.5 214 215 217 Figure 1 219 A LIS that supports this specification echoes the "target" element in 220 a successful HELD response, including the identifiers that were used 221 as the basis for location determination. Absence of this indication 222 means that the location information was generated using the source IP 223 address in the request. 225 If an identifier is invalid, not supported by the LIS, or the 226 requester is not authorized to use that identifier, a HELD error 227 response of "badIdentifier". This code is registered in Section 7.3. 229 If the LIS requires an identifier that is not provided in the 230 request, the desired identifiers MAY be identified in the HELD error 231 response, using the "requiredIdentifiers" element. This element 232 contains a list of XML qualified names [W3C.REC-xml-names11-20060816] 233 that identify the identifier elements required by the LIS. Namespace 234 prefix bindings for the qualified names are taken from document 235 context. Figure 2 shows an example error indicating that the 236 requester needs to include a MAC address (Section 3.2.2) if the 237 request is to succeed. 239 242 244 mac 245 246 248 Figure 2 250 3.2. Identifiers 252 A limited selection of identifiers are included in this document. 253 The basic Target identity schema allows for the inclusion of elements 254 from any namespace, therefore additional elements can be defined 255 using different XML namespaces. 257 3.2.1. IP Address 259 The "ip" element can express a Target identity as an IP address. An 260 optional "v" attribute identifies the IP version. The element uses 261 the textual format specific to the indicated IP version. 263 264 2001:DB8::1:ea7:fee1:d1e 265 267 In situations where location configuration does not require 268 additional identifiers, using IP address as an identifier enables 269 third party requests. 271 3.2.2. MAC Address 273 The media access control (MAC) address used by the IEEE 802 family of 274 access technologies is an identifier that is assigned to a particular 275 network device. A MAC address is a unique sequence that is either 276 assigned at the time of manufacture of a device, or assigned by a 277 local administrator. A MAC address rarely changes; therefore, a MAC 278 address is an appropriate identifier for a Device. 280 281 A0-12-34-56-78-90 282 284 3.2.3. TCP or UDP Port Number 286 On its own, a TCP or UDP port number is insufficient to uniquely 287 identify a single host, but in combination with an IP address, it can 288 be used to identify a Target. 290 Use of a particular port number can be transient; often significantly 291 more than use of any given IP address. However, widespread use of 292 network address translation (NAT) means that some Targets cannot be 293 uniquely identified by IP address alone. An individual Target might 294 be identified by a flow of packets that it generates. Providing that 295 a LIS has sufficient knowledge of the mappings used by the NAT, an 296 individual target on the remote side of the NAT might be able to be 297 identified uniquely. 299 300 2001:DB8::1:ea7:fee1:d1e 301 51393 302 304 As with any identifier, use of port numbers is contingent on the 305 value remaining consistent over time. Use of port numbers is not 306 suitable if port numbers cannot be deterministically attributed to a 307 unique Target over a sufficient period of time. 309 3.2.4. Network Access Identifier 311 A Network Access Identifier (NAI) [RFC4282] is an identifier used in 312 network authentication in a range of networks. The identifier 313 establishes a user identity within a particular domain. Often, 314 network services use an NAI in relation to location records, tying 315 network access to user authentication and authorization. 317 318 user@example.net 319 321 Note: The formal grammar for NAI permits invalid Unicode, which 322 cannot be expressed using XML. This is a known problem with that 323 grammar. Any NAI that contains invalid character sequences cannot 324 be used as a Target identifier. 326 3.2.5. URI 328 A Target can be identified by a URI. Any URI can be used providing 329 that the requester and LIS have a common understanding of the 330 semantics implied by use of the URI. 332 333 sip:user@example.net;gr=kjh29x97us97d 334 336 3.2.6. Hostname 338 A domain name can be used as the basis for identification using the 339 "hostname" element. 341 342 host.example.net 343 345 3.2.7. Directory Number 347 Telephony devices are typically identified by the number that is used 348 to reach them. Within enterprises, where globally accessible 349 telephone numbers might not be used, a directory number is the usual 350 form of identification. 352 353 7515 354 356 3.2.8. Cellular Telephony Identifiers 358 A range of different forms of mobile station identifiers are used for 359 different cellular telephony systems. Elements are defined for these 360 identifiers. The following identifiers are defined: 362 msisdn: The Mobile Subscriber Integrated Services Digital Network 363 Number (MSISDN) is an E.164 number between 6 and 15 digits long. 365 imsi: The International Mobile Subscriber Identity (IMSI) an 366 identifier associated with all GSM and UMTS mobile subscribers. 368 imei: The International Mobile Equipment Identifier (IMEI) is a 369 unique device serial number up to 15 digits long. 371 min: The Mobile Identification Number (MIN) is a unique number 372 assigned to CDMA handsets. 374 mdn: The Mobile Directory Number (MDN) is an E.164 number, with 375 usage similar to MSISDN. 377 378 11235550123 380 382 3.2.9. DHCP Unique Identifier 384 The Dynamic Host Configuration Protocol (DHCP) uses a binary 385 identifier for its clients. The DHCP Unique Identifier (DUID) is 386 expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of 387 DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The 388 "duid" element includes the binary value of the DUID expressed in 389 hexadecimal. 391 392 1234567890AaBbCcDdEeFf 393 395 4. XML Schema 397 398 404 405 406 407 408 410 411 413 414 415 416 418 419 420 421 422 423 424 425 426 427 429 430 431 432 434 435 436 437 438 439 441 442 443 444 445 446 447 449 451 453 454 455 456 457 458 460 461 462 463 466 468 469 471 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 494 496 5. Privacy Considerations 498 A location configuration protocol has a very simple privacy model. 499 Because the requester is also the Target, it can be assumed that 500 providing that requester with location information is allowed. This 501 "LCP policy" makes the simple assumption that as the subject of the 502 location information, the Target is also permitted access to that 503 information. In effect, an LCP server (that is, the LIS) follows a 504 single rule policy that states that the Target is the only authorized 505 Location Recipient. 507 Note: HELD explicitly takes the position that the Target is a Device 508 and not a person. For the purpose of discussion related to 509 privacy, this distinction is not important. In this section, 510 Target refers equally to Device and person. 512 When Target identity is used, the "LCP policy" is only applicable if 513 the identity of requester and Target are identical. If the 514 authenticated identity of the requester and the Target are the same, 515 the security and privacy considerations of the base HELD protocol 516 [I-D.ietf-geopriv-http-location-delivery] MAY be applied by a LIS. 517 The LIS MUST NOT use LCP policy unless it can authenticate the 518 requester identity is the same as the requested identity. Requester 519 and target identities MUST be identical, related identities are not 520 sufficient. 522 For example, it is not appropriate to apply LCP policy where a 523 requester is authenticated by NAI and the supplied Target identity 524 is a MAC address, even if that MAC address is currently registered 525 with the network under the given NAI. In this case, the requester 526 might be requesting from a different MAC address registered under 527 the same NAI. The correct way of gaining authorization is to 528 establish a policy that permits this particular request as a third 529 party request. 531 The LCP policy does not allow requests made by third parties. If a 532 LIS permits requests from third parties using identity extensions, it 533 assumes the rule of a Location Server (LS). HELD becomes a more 534 general location request protocol--a "using protocol" by the 535 definitions in [RFC3693]--and the privacy considerations for using 536 protocols apply. As a Location Server, the LIS MUST explicitly 537 authorize requests according to the policies that are provided by 538 Rule Makers, including the Target. This includes authentication of 539 requesters where required by the authorization policies. 541 An organization that provides a LIS that allows third party requests 542 SHOULD provide a means for a Rule Maker to specify authorization 543 policies before allowing third party requests for that Target's 544 location. Until an authorization policy is established, the LIS MUST 545 reject requests by third parties. 547 When the LIS is operated by the Target's access network, the 548 relationship between the Target and the LIS can be transient. 549 However, the process of establishing network access usually results 550 in a form of agreement between the Target and the network provider. 551 This process offers a natural vehicle for establishing location 552 privacy policies. Establishing authorization policy might be a 553 manual process, an explicit part of the terms of service for the 554 network, or an automated system that accepts formal authorization 555 policies (see [RFC4745], [RFC4825]). This document does not mandate 556 any particular mechanism for establishing an authorization policy. 558 6. Security Considerations 560 The security considerations in 561 [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for 562 server authentication, confidentiality and protection from 563 modification. These protections apply to both LCP requests and the 564 requests made by third parties. 566 All HELD requests MUST be authenticated by the LIS. How 567 authentication is accomplished and what assurances are desired is a 568 matter for policy. The base HELD protocol uses return reachability-- 569 the proof of ownership of an IP address implied by the requester 570 being able to successfully complete a TCP handshake. It is 571 RECOMMENDED that any means of authentication provide at least this 572 degree of assurance. [[MT: last sentence too subjective?]] For 573 requests that include Target identity, the LIS MUST support 574 authentication of TLS clients. 576 6.1. Location Configuration Protocol Requests 578 Requests made by a Device in the context of a location configuration 579 protocol are covered by the same set of protections offered by HELD. 580 LCP requests are authorized under an "LCP policy" that permits a 581 Target access to location information about itself. 583 Identity information provided by the Device is private data that 584 might be sensitive. The Device provides this information in the 585 expectation that it assists the LIS in providing the Device a 586 service. The LIS MUST NOT use identity information for any other 587 purpose other than serving the request that includes that 588 information. 590 6.2. Third Party Requests 592 Requests from third parties have the same requirements for server 593 authentication, confidentiality and protection from modification as 594 LCP requests. However, because the third party needs to be 595 authorized, the requester MUST be authenticated by the LIS. In 596 addition, third party requests MUST be explicitly authorized by a 597 policy that is established by a Rule Maker. 599 More detail on the privacy implications of third party requests are 600 covered in Section 5. 602 7. IANA Considerations 604 This document registers an XML namespace and schema with IANA in 605 accordance with guidelines in [RFC3688]. It also creates a new 606 registry for device identity types, and stipulates how new types are 607 to be added. 609 7.1. URN Sub-Namespace Registration for 610 urn:ietf:params:xml:ns:geopriv:held:id 612 This section registers a new XML namespace, 613 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in 614 [RFC3688]. 616 URI: urn:ietf:params:xml:ns:geopriv:held:id 618 Registrant Contact: IETF, GEOPRIV working group, 619 (geopriv@ietf.org), James Winterbottom 620 (james.winterbottom@andrew.com). 622 XML: 624 BEGIN 625 626 628 629 630 HELD Target Identity Parameters 631 632 633

Namespace for HELD Target Identity Parameters

634

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

635 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 636 with the RFC number for this specification.]] 637

See RFCXXXX.

638 639 640 END 642 7.2. XML Schema Registration 644 This section registers an XML schema as per the guidelines in 645 [RFC3688]. 647 URI: urn:ietf:params:xml:schema:geopriv:held:id 649 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 650 James Winterbottom (james.winterbottom@andrew.com). 652 Schema: The XML for this schema can be found as the entirety of 653 Section 4 of this document. 655 7.3. Registration of HELD 'badIdentifier' Error Code 657 This section registers the "badIdentifier" error code in the "Geopriv 658 HELD Registries, Error codes for HELD" IANA registry. 660 badIdentifier This error code indicates that the Target identifiers 661 used in the HELD request were either: not supported by the LIS, 662 badly formatted, or that the requester was not authorized to make 663 a erquest for that identifier. 665 8. Acknowledgements 667 The authors wish to thank the NENA VoIP location working group for 668 their assistance in the definition of the schema used in this 669 document. Special thanks go to Barbara Stark, Guy Caron, Nadine 670 Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input 671 on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for 672 providing further corrections. Bernard Aboba provided extensive 673 feedback on use cases and the security model; Bernard, along with 674 Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis 675 provided motivation for the protocol port parameters. 677 9. References 679 9.1. Normative references 681 [RFC2119] Bradner, S., "Key words 682 for use in RFCs to 683 Indicate Requirement 684 Levels", BCP 14, RFC 2119, 685 March 1997. 687 [RFC3315] Droms, R., Bound, J., 688 Volz, B., Lemon, T., 689 Perkins, C., and M. 690 Carney, "Dynamic Host 691 Configuration Protocol for 692 IPv6 (DHCPv6)", RFC 3315, 693 July 2003. 695 [RFC3688] Mealling, M., "The IETF 696 XML Registry", BCP 81, 697 RFC 3688, January 2004. 699 [RFC4282] Aboba, B., Beadles, M., 700 Arkko, J., and P. Eronen, 701 "The Network Access 702 Identifier", RFC 4282, 703 December 2005. 705 [RFC4361] Lemon, T. and B. 706 Sommerfeld, "Node-specific 707 Client Identifiers for 708 Dynamic Host Configuration 709 Protocol Version Four 710 (DHCPv4)", RFC 4361, 711 February 2006. 713 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 714 J., Thomson, M., and B. 715 Stark, "HTTP Enabled 716 Location Delivery (HELD)", 717 draft-ietf-geopriv-http- 718 location-delivery-12 (work 719 in progress), 720 January 2009. 722 [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. 723 Schulzrinne, "GEOPRIV 724 Layer 7 Location 725 Configuration Protocol; 726 Problem Statement and 727 Requirements", draft-ietf- 728 geopriv-l7-lcp-ps-09 (work 729 in progress), 730 February 2009. 732 [W3C.REC-xml-names11-20060816] Tobin, R., Layman, A., 733 Bray, T., and D. 734 Hollander, "Namespaces in 735 XML 1.1 (Second Edition)", 736 World Wide Web Consortium 737 Recommendation REC-xml- 738 names11-20060816, 739 August 2006, . 743 9.2. Informative references 745 [RFC3693] Cuellar, J., Morris, J., 746 Mulligan, D., Peterson, 747 J., and J. Polk, "Geopriv 748 Requirements", RFC 3693, 749 February 2004. 751 [RFC3825] Polk, J., Schnizlein, J., 752 and M. Linsner, "Dynamic 753 Host Configuration 754 Protocol Option for 755 Coordinate-based Location 756 Configuration 757 Information", RFC 3825, 758 July 2004. 760 [RFC4388] Woundy, R. and K. Kinnear, 761 "Dynamic Host 762 Configuration Protocol 763 (DHCP) Leasequery", 764 RFC 4388, February 2006. 766 [RFC4745] Schulzrinne, H., 767 Tschofenig, H., Morris, 768 J., Cuellar, J., Polk, J., 769 and J. Rosenberg, "Common 770 Policy: A Document Format 771 for Expressing Privacy 772 Preferences", RFC 4745, 773 February 2007. 775 [RFC4776] Schulzrinne, H., "Dynamic 776 Host Configuration 777 Protocol (DHCPv4 and 778 DHCPv6) Option for Civic 779 Addresses Configuration 780 Information", RFC 4776, 781 November 2006. 783 [RFC4825] Rosenberg, J., "The 784 Extensible Markup Language 785 (XML) Configuration Access 786 Protocol (XCAP)", 787 RFC 4825, May 2007. 789 [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, 790 "Best Current Practice for 791 Communications Services in 792 support of Emergency 793 Calling", draft-ietf- 794 ecrit-phonebcp-07 (work in 795 progress), January 2009. 797 [I-D.thomson-geopriv-held-measurements] Thomson, M. and J. 798 Winterbottom, "Using 799 Device-provided Location- 800 Related Measurements in 801 Location Configuration 802 Protocols", draft-thomson- 803 geopriv-held-measurements- 804 03 (work in progress), 805 October 2008. 807 [LLDP] IEEE, "802.1AB, IEEE 808 Standard for Local and 809 Metropolitan area 810 networks, Station and 811 Media Access Control 812 Connectivity Discovery", 813 June 2005. 815 Authors' Addresses 817 James Winterbottom 818 Andrew Corporation 819 PO Box U40 820 University of Wollongong, NSW 2500 821 AU 823 EMail: james.winterbottom@andrew.com 825 Martin Thomson 826 Andrew Corporation 827 PO Box U40 828 University of Wollongong, NSW 2500 829 AU 831 EMail: martin.thomson@andrew.com 833 Hannes Tschofenig 834 Nokia Siemens Networks 835 Linnoitustie 6 836 Espoo 02600 837 Finland 839 Phone: +358 (50) 4871445 840 EMail: Hannes.Tschofenig@gmx.net 841 URI: http://www.tschofenig.priv.at 843 Richard Barnes 844 BBN Technologies 845 9861 Broken Land Pkwy, Suite 400 846 Columbia, MD 21046 847 USA 849 Phone: +1 410 290 6169 850 EMail: rbarnes@bbn.com