idnits 2.17.1 draft-winterbottom-geopriv-held-identity-extensions-07.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 719. 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 -- 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 (November 3, 2008) is 5653 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: 'RFC3986' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ecrit-phonebcp' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC3966' is defined on line 619, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-10 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-08 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-05 == Outdated reference: A later version (-06) exists of draft-thomson-geopriv-held-measurements-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: May 7, 2009 H. Tschofenig 6 Nokia Siemens Networks 7 R. Barnes 8 BBN Technologies 9 November 3, 2008 11 HELD Identity Extensions 12 draft-winterbottom-geopriv-held-identity-extensions-07 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 7, 2009. 39 Abstract 41 When a Location Information Server receives a request for location 42 information (using the locationRequest message), described in the 43 base HTTP Enabled Location Delivery (HELD) specification, it uses the 44 source IP address of arriving message as a pointer to the location 45 determination process. This is sufficient in environments where an 46 Target's location can be determined based on its IP address. 48 Two additional use cases are addresses by this document. In the 49 first, the source IP address in the request is not the only 50 identifier for the Target. In the second, an entity other than the 51 Target requests the Target's location. 53 This document extends the HELD protocol to allow the location request 54 message to carry additional identifiers assisting the location 55 determination process. It defines a set of URIs for Target 56 identifiers and an XML containment schema. This extension is used in 57 conjunction with HELD to provide Target identification, and set of 58 criteria of when to use this extensions are provided. Examples and 59 usage in HELD message syntax are also shown. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Identity Extension Details . . . . . . . . . . . . . . . . . . 6 66 3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 6 67 3.1.1. MAC Address URI . . . . . . . . . . . . . . . . . . . 6 68 3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 6 69 3.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 5.1. Location Configuration Protocol Requests . . . . . . . . . 12 73 5.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 12 74 5.3. Distinguishing LCP Requests from Third Party Requests . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 6.1. URN Sub-Namespace Registration for 77 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14 78 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14 79 6.3. Identifier 'type' Attribute values . . . . . . . . . . . . 15 80 6.4. URI Type Attribute Values . . . . . . . . . . . . . . . . 15 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 8.1. Normative references . . . . . . . . . . . . . . . . . . . 18 84 8.2. Informative references . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 86 Intellectual Property and Copyright Statements . . . . . . . . . . 21 88 1. Introduction 90 Protocols for requesting and providing location information require a 91 way for the requestor to specify the location that should be 92 returned. In a location configuration protocol (LCP), the location 93 being requested is the requestor's location. This fact can make the 94 problem of identifying the Target simpler for LCPs, since IP 95 datagrams that carry the request already carry an identifier for the 96 Target, namely the source IP address of an incoming request. 97 Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery] 98 and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and 99 possibly lower-layer identifiers to identify a Target. 101 Aside from the datagrams that form a request, a location information 102 server (LIS) does not necessarily have access to information that 103 could further identify the Target of the request. In some 104 circumstances, as shown in [I-D.ietf-geopriv-l7-lcp-ps], additional 105 identification information can be included in a request to identify a 106 Target. 108 This document extends the HELD protocol to support the inclusion of 109 additional identifiers for the Target in HELD location requests. The 110 identifiers are defined as URIs that include a range of different 111 types of identification information. Finally, an XML schema is 112 defined that provides a structure for including these identifiers in 113 HELD requests. 115 An important characteristic of this addition to the HELD protocol is 116 that is also expands the potential scope of HELD beyond that of an 117 LCP. The scope of an LCP is limited to the interaction between a 118 Target and a LIS. That is, an LCP is limited to the Target 119 retrieving information about their own location. With this addition, 120 third party location recipients (LRs) are able to make requests that 121 include identifiers to retrieve location information about a 122 particular Target. 124 The usage of HELD for purposes beyond the Target-LIS interaction 125 obviously introduces a new set of privacy concerns. In an LCP, the 126 requester is implicitly authorized to access the request location 127 information, because it is their own location. In contrast, when a 128 third party LR requests a Target's location, the LR MUST be 129 explicitly authorized. Establishing appropriate authorization and 130 other related privacy concerns are discussed in Section 4. 132 2. Terminology 134 This document reuses the term Target, as defined in [RFC3693]. 136 This document uses the term Location Information Server, LIS as 137 described in [I-D.ietf-geopriv-l7-lcp-ps]. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Identity Extension Details 145 This section defines the details of the schema extension for HELD to 146 support the inclusion of a Target identity in the form of a URI or 147 typed-token. A set of URI definitions that can be used to specify 148 these identities is also provided. 150 3.1. URI Definitions 152 The URIs defined in this section are designed to identify a Target; 153 they do not identify measurements or sighting data associated with a 154 Target, such as the switch and port information to which the Target 155 is attached. This information may, for example, be acquired using 156 DHCP relay information [RFC3046] or LLDP [LLDP]. Device measurements 157 and sighting data are described in 158 [I-D.thomson-geopriv-held-measurements]. The identity provided may 159 be transitory, such as an IP address that is leased from a DHCP 160 server pool. 162 The URIs in the following sub-sections are defined using ABNF 163 (augmented Backus-Naur form) described in [RFC2234]. 165 3.1.1. MAC Address URI 167 A MAC URI represents the media access control address of the Device, 168 as defined in the IEEE 802 series of specifications. The ABNF for 169 this URI type is defined as: 171 mac-uri = "mac:" 2*2HEXDIG 5*5macdig 172 macdig = "-" 2*2HEXDIG 174 MAC URIs can be used in the same manner as is suggested by the 175 undefined "mac:" URIs used in examples in RFC 4479 [RFC4479]. An 176 example of its use is provided in Figure 3. 178 3.1.2. IP Address URIs 180 This section provides the ABNF for IP version 4 and IP version 6 181 URIs. One application of this URI scheme is described in 182 [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to 183 make location requests to a LIS on behalf of a Target because, for 184 some reason, the necessary information was not provided by the 185 Target. 187 ip-uri = "ip:" ipv4 / ipv6 188 ipv4 = "IPv4+" IPv4address ; from RFC 3986 189 ipv6 = "IPv6+" IPv6address ; from RFC 3986 190 The definitions for "IPv4address" and "IPv6address" are taken from 191 [RFC3986]. 193 An example of a location request including a URI in this form to 194 identify the Target device is shown in Figure 1. 196 198 geodetic 199 200 ip:IPv4+192.0.2.5 201 202 204 Figure 1: HELD Location Request Using an IP Address 206 Note that the URI types are not case sensitive and the iP:ipv4+ 207 192.0.2.5 is still a valid URI. 209 3.2. Schema 211 This section defines a schema that is used to provide Target 212 identifiers in a HELD location request. 214 215 222 224 225 226 227 229 230 231 233 235 236 237 238 240 241 242 244 246 247 248 250 252 253 255 257 259 Figure 2: Schema 261 The schema provided in Figure 2 allows a URI and/or token to be 262 provided so that a Target can identify itself by more than just its 263 IP address. The URI can also include an optional "type" attribute so 264 that URIs that might otherwise look the same can be distinguished 265 based on their usage. 267 For example sip:callee@example.com or sip:callee@example.com 270 An IANA registry is established for defining uri token types, and 271 this defined in Section 6.4. 273 When the element is used the "type" attribute is 274 mandatory as it tells the LIS or receiving entity how to interpret 275 the identifier. An IANA registry is established for the central 276 repository for recognized identifier types. The set of initial types 277 is provided in Section 6.3. 279 A HELD location request sent by a device using the schema shown in 280 Figure 2 to provide its identity as a MAC URI would look similar to 281 Figure 3. 283 285 geodetic 286 287 mac:01-ab-34-ef-69-0c 288 289 291 Figure 3: HELD Location Request URI example 293 Similarly a Target identifying itself using its DHCP client 294 identifier (DHCP option 61 in [RFC2132]) in a location request to a 295 LIS would send something similar to Figure 4. 297 299 geodetic 300 301 035552764 302 303 305 Figure 4: HELD Location Request Identifier example 307 4. Privacy Considerations 309 A location configuration protocol has a very simple privacy model. 310 Because the requester is also the Target, it can be assumed that 311 providing that requester with location information is allowed. Such 312 a policy makes the simple assumption that as the subject of the 313 location information, the Target is also permitted access to that 314 information. In effect, an LCP server (that is, the LIS) follows a 315 single rule policy that states that the Target is the only authorized 316 Location Recipient. 318 Note: HELD explicitly takes the position that the Target is a Device 319 and not a person. For the purpose of the discussion in this 320 section, the two are considered one and the same. 322 When the identity extensions defined above are used by the Target to 323 augment an LCP query, this default "LCP policy" remains the relevant 324 policy, and the security and privacy considerations of the base HELD 325 protocol [I-D.ietf-geopriv-http-location-delivery] apply. The only 326 augmentation required is that if the LCP policy is to be applied, the 327 LIS MUST authenticate that the requested identity is in fact that of 328 the requestor, and MUST deny access to location if this 329 authentication fails. 331 The LCP policy does not allow requests made by third parties. If a 332 LIS permits requests from third parties using identity extensions, it 333 assumes the rule of a Location Server (LS). HELD becomes a more 334 general location request protocol--a "using protocol" by the 335 definitions in [RFC3693]--and the privacy considerations for using 336 protocols apply. As a Location Server, the LIS MUST explicitly 337 authorize requests according to the policies that are provided by 338 Rule Makers, including the Target. This includes authentication of 339 requesters where required by the authorization policies. 341 An organization that provides a LIS that allows third party requests 342 SHOULD provide a means for a Rule Maker to specify authorization 343 policies before allowing third party requests for that Target's 344 location. Until an authorization policy is established, the LIS MUST 345 reject requests by third parties. 347 For a network operator, authorization might be a manual process, an 348 explicit part of the terms of service for the network, or an 349 automated system that accepts formal authorization policies (see 350 [RFC4745], [RFC4825]). This document does not mandate any particular 351 mechanism for establishing an authorization policy. 353 When the LIS is operated by the Target's access network, the 354 relationship between the Target and the LIS can be transient. 356 However, the process of establishing network access usually results 357 in a form of agreement between the Target and the network provider. 358 This process offers a natural vehicle for establishing location 359 privacy policies. 361 5. Security Considerations 363 The security considerations in 364 [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for 365 server authentication, confidentiality and protection from 366 modification. These protections apply to both LCP requests and the 367 requests made by third parties. 369 5.1. Location Configuration Protocol Requests 371 Requests made by a Device (or Target) in the context of a location 372 configuration protocol are covered by the same set of protections 373 offered by HELD. All the security considerations for HELD apply. 375 Identity information provided by the Device is private data that 376 might be sensitive. The Device provides this information in the 377 expectation that it assists the LIS in providing the Device a 378 service. The LIS MUST NOT use identity information for any other 379 purpose other than serving the request that includes that 380 information. 382 Falsification of identification information could be used by 383 malicious Devices to gain access to location information for others, 384 or to acquire false location information. For location 385 configuration, the LIS MUST ensure that claimed identity information 386 belongs to the requester before relying upon it. If this 387 verification cannot be performed, the LIS MUST treat the request as 388 if it were a third party request. 390 Note: This might seem to negate much of the advantage provided by 391 the inclusion of identity parameters for the LCP case. However, 392 checking that the identity information is correct is generally 393 more feasible than acquiring the information in the first place. 395 For example, a MAC address provided by a target device can be 396 verified by performing a DHCP lease-query ([RFC4388]). Identity 397 extensions such as tel: URIs and hostnames can be validated using 398 network services such as the DNS, ENUM, LDAP and SIP registrars. 400 5.2. Third Party Requests 402 Requests from third parties have the same requirements for server 403 authentication, confidentiality and protection from modification as 404 LCP requests. However, because the third party needs to be 405 authorized, the requester MUST be authenticated by the LIS. The LIS 406 MUST NOT provide location information to unauthorized requesters. 408 A LIS that allows requests from third parties MUST support TLS client 409 authentication. 411 More detail on the privacy implications of third party requests are 412 covered in Section 4. 414 5.3. Distinguishing LCP Requests from Third Party Requests 416 There is a risk that a LIS that supports both LCP requests as well as 417 requests from third parties could leak information. To successfully 418 exploit this leak, a third party could convince the server that its 419 request is an LCP request and that the identity information it 420 provides indeed belongs to it. This could mean that the third party 421 is exempted from the mandatory authorization process. 423 A LIS that only provides LCP access to Targets is subject to the same 424 attack. If a Target can provide false identification information 425 that is accepted by the LIS, it can effectively act as an authorized 426 third party. 428 This is limited by the ability of the LIS to detect falsified 429 identity information. Implementations need to take care to verify 430 identity information as described in Section 5.1. 432 For all requests, the LIS MUST ensure that the requester is 433 authorized to receive location information for the specified Target 434 before providing that information. 436 6. IANA Considerations 438 This document registers an XML namespace and schema with IANA in 439 accordance with guidelines in [RFC3688]. It also creates a new 440 registry for device identity types, and stipulates how new types are 441 to be added. 443 6.1. URN Sub-Namespace Registration for 444 urn:ietf:params:xml:ns:geopriv:held:id 446 This section registers a new XML namespace, 447 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in 448 [RFC3688]. 450 URI: urn:ietf:params:xml:ns:geopriv:held:id 452 Registrant Contact: IETF, GEOPRIV working group, 453 (geopriv@ietf.org), James Winterbottom 454 (james.winterbottom@andrew.com). 456 XML: 458 BEGIN 459 460 462 463 464 HELD Device Identity Extensions 465 466 467

Namespace for HELD Device Identity Extensions

468

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

469 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 470 with the RFC number for this specification.]] 471

See RFCXXXX.

472 473 474 END 476 6.2. XML Schema Registration 478 This section registers an XML schema as per the guidelines in 479 [RFC3688]. 481 URI: urn:ietf:params:xml:schema:geopriv:held:id 483 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 484 James Winterbottom (james.winterbottom@andrew.com). 486 Schema: The XML for this schema can be found as the entirety of 487 Figure 2 of this document. 489 6.3. Identifier 'type' Attribute values 491 This document requests that the IANA create a new registry for 492 identifier 'type' attribute values. These are text strings that 493 clarify how the value identifies the Device. Referring to [RFC2434] 494 this registry operates under the "Expert Review" rule. 496 The following identifier types are registered as part of this memo: 498 dhcpClientId: The DHCP client identifier as defined by DHCP option 499 61 in [RFC2132] 501 msisdn: The Mobile Station International Subscriber Dial Number. 502 This is an E.164 number made up of 6 to 15 digits 504 imsi: The International Mobile Subscriber identifier. A unique 505 identifier for GSM or UMTS mobile terminal made up of 6 to 15 506 digits that identify the country code, the network code and 507 device. 509 imei: The International Mobile Equipment identifier. This is an 510 electronic serial number for a mobile device and is consists of up 511 to 15 digits 513 min: Mobile Identification Number. A unique equipment identifier 514 assigned to CDMA handsets. 516 mdn: Mobile Dial Number. An E.164 number made up of 6 to 15 digits. 518 hostname: The hostname or FQDN of the device. 520 directoryNumber: The directory number of the device. 522 6.4. URI Type Attribute Values 524 This document requests that the IANA create a new registry for uri 525 'type' attribute values. These are text strings that clarify what a 526 URI actually identifies, and MUSt include the URI scheme to which the 527 type applies. Referring to [RFC2434] this registry operates under 528 the "Expert Review" rule. 530 The following identifier types are registered as part of this memo: 532 aor: The SIP address of record as defined [RFC3261]. Applies to 533 'sip:', 'sips:', 'pres:' 535 gruu: The Globally Routable User Agent URI (GRUU) as defined in 536 [I-D.ietf-sip-gruu]. Applies to 'sip:', 'sips:' 538 7. Acknowledgements 540 The authors wish to thank the NENA VoIP location working group for 541 their assistance in the definition of the schema used in this 542 document. Special thanks go to Barbara Stark, Guy Caron, Nadine 543 Abbott, Jerome Grenier and Martin Dawson. Thanks also to Bob Sherry 544 for requesting that URI-types be supported which led to the typedURI 545 form. Thanks to Adam Muhlbauer and Eddy Corbett for providing 546 further corrections. 548 8. References 550 8.1. Normative references 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 556 January 2004. 558 [I-D.ietf-geopriv-http-location-delivery] 559 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 560 "HTTP Enabled Location Delivery (HELD)", 561 draft-ietf-geopriv-http-location-delivery-10 (work in 562 progress), October 2008. 564 [I-D.ietf-geopriv-l7-lcp-ps] 565 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 566 Location Configuration Protocol; Problem Statement and 567 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 568 progress), June 2008. 570 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 571 Specifications: ABNF", RFC 2234, November 1997. 573 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 574 A., Peterson, J., Sparks, R., Handley, M., and E. 575 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 576 June 2002. 578 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 579 Resource Identifier (URI): Generic Syntax", STD 66, 580 RFC 3986, January 2005. 582 [I-D.ietf-sip-gruu] 583 Rosenberg, J., "Obtaining and Using Globally Routable User 584 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 585 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 586 October 2007. 588 8.2. Informative references 590 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 591 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 593 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 594 Extensions", RFC 2132, March 1997. 596 [I-D.ietf-ecrit-phonebcp] 597 Rosen, B. and J. Polk, "Best Current Practice for 598 Communications Services in support of Emergency Calling", 599 draft-ietf-ecrit-phonebcp-05 (work in progress), 600 July 2008. 602 [I-D.thomson-geopriv-held-measurements] 603 Thomson, M. and J. Winterbottom, "Using Device-provided 604 Location-Related Measurements in Location Configuration 605 Protocols", draft-thomson-geopriv-held-measurements-03 606 (work in progress), October 2008. 608 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 609 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 610 October 1998. 612 [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan 613 area networks, Station and Media Access Control 614 Connectivity Discovery", June 2005. 616 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 617 RFC 3046, January 2001. 619 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 620 RFC 3966, December 2004. 622 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 623 July 2006. 625 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 626 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 628 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 629 Configuration Protocol Option for Coordinate-based 630 Location Configuration Information", RFC 3825, July 2004. 632 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 633 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 635 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 636 Polk, J., and J. Rosenberg, "Common Policy: A Document 637 Format for Expressing Privacy Preferences", RFC 4745, 638 February 2007. 640 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 641 (DHCPv4 and DHCPv6) Option for Civic Addresses 642 Configuration Information", RFC 4776, November 2006. 644 Authors' Addresses 646 James Winterbottom 647 Andrew Corporation 648 PO Box U40 649 University of Wollongong, NSW 2500 650 AU 652 Email: james.winterbottom@andrew.com 654 Martin Thomson 655 Andrew Corporation 656 PO Box U40 657 University of Wollongong, NSW 2500 658 AU 660 Email: martin.thomson@andrew.com 662 Hannes Tschofenig 663 Nokia Siemens Networks 664 Linnoitustie 6 665 Espoo 02600 666 Finland 668 Phone: +358 (50) 4871445 669 Email: Hannes.Tschofenig@gmx.net 670 URI: http://www.tschofenig.priv.at 672 Richard Barnes 673 BBN Technologies 674 9861 Broken Land Pkwy, Suite 400 675 Columbia, MD 21046 676 USA 678 Phone: +1 410 290 6169 679 Email: rbarnes@bbn.com 681 Full Copyright Statement 683 Copyright (C) The IETF Trust (2008). 685 This document is subject to the rights, licenses and restrictions 686 contained in BCP 78, and except as set forth therein, the authors 687 retain all their rights. 689 This document and the information contained herein are provided on an 690 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 691 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 692 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 693 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 694 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 697 Intellectual Property 699 The IETF takes no position regarding the validity or scope of any 700 Intellectual Property Rights or other rights that might be claimed to 701 pertain to the implementation or use of the technology described in 702 this document or the extent to which any license under such rights 703 might or might not be available; nor does it represent that it has 704 made any independent effort to identify any such rights. Information 705 on the procedures with respect to rights in RFC documents can be 706 found in BCP 78 and BCP 79. 708 Copies of IPR disclosures made to the IETF Secretariat and any 709 assurances of licenses to be made available, or the result of an 710 attempt made to obtain a general license or permission for the use of 711 such proprietary rights by implementers or users of this 712 specification can be obtained from the IETF on-line IPR repository at 713 http://www.ietf.org/ipr. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights that may cover technology that may be required to implement 718 this standard. Please address the information to the IETF at 719 ietf-ipr@ietf.org.