idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 == Unrecognized Status in 'Intended status: Standards Track (PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (March 7, 2010) is 5154 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: 'RFC3265' is defined on line 552, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Geopriv WG James Polk 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track (PS) March 7, 2010 4 Expires: Sept 7, 2010 6 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 7 Option for a Location Uniform Resource Identifier (URI) 8 draft-ietf-geopriv-dhcp-lbyr-uri-option-07 10 Abstract 12 This document creates a Dynamic Host Configuration Protocol (DHCP) 13 Option for transmitting a client's geolocation Uniform Resource 14 Identifier (URI) of a client, which can be dereferenced in a 15 separate transaction by the client or an entity the client sends 16 this URI to. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 7, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4 60 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 4 61 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 62 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 5 63 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 6 64 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 65 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 66 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 7.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 1. Introduction 81 This document creates a Dynamic Host Configuration Protocol (DHCP) 82 Option for transmitting a client's geolocation Uniform Resource 83 Identifier (URI). The DHCP implementation of the client can then 84 make this location information available to upper layer protocols 85 for their usage. This location URI points a Location Server 86 [ID-LBYR-REQ] which has the geolocation of the client (through means 87 not defined in this document). In this scenario, the DHCP client 88 is a Geopriv Target (i.e., the entity whose geolocation is 89 associated by the location URI). 91 Applications using upper layer protocols within the Target can then 92 choose to deference this location URI and/or transmit the URI to 93 another entity as a means of conveying where the Target is located. 94 Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying 95 a location URI is also described in [ID-SIP-LOC]. Session Initiation 96 Protocol (SIP) is not the only protocol that can dereference a 97 location URI; there is also HTTP-Enabled Location Delivery (HELD) 98 [ID-HELD-DEREF]. 100 Having a location URI has advantages over having a PIDF-LO, 101 especially when a target's location changes. With a location URI, 102 when a target moves, the location URI does not change (at least 103 within the same domain). It can still be given out as the reference 104 to the Target's current location. The opposite is true if the 105 location is conveyed by value in a message. Once the Target moves, 106 the previously given location is no longer valid, and it the Target 107 wants to inform another entity about its location, it has to send 108 the PIDF-LO to the location recipient (again). 110 A Location Server (LS) stores the Target's location as a presence 111 document, called a Presence Information Date Format - Location 112 Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server 113 is the entity contacted during the act of dereferencing a Target's 114 location. If the dereferencing entity has permission, defined in 115 [ID-GEO-POL], the location of the target will be received. The LS 116 will grant permission to location inquires based on the rules 117 established by a Rule Holder [RFC3693]. The LS has the ability to 118 challenge any request for a target's location, thereby providing 119 additive security properties before location revelation. 121 A problem exists within existing RFCs that provide location to the 122 UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation 123 values require an update of the entire location information (LI) 124 every time a client moves. Not all clients will move frequently, 125 but some will. Refreshing location values every time a client moves 126 does not scale in certain networks/environments, such as IP-based 127 cellular networks, enterprise networks or service provider networks 128 with mobile endpoints. An 802.11 based access network is one 129 example of this. Constantly updating LCI to endpoints might not 130 scale in mobile (residential or enterprise or municipal) networks in 131 which the client is moving through more than one network attachment 132 point, perhaps as a person walks or drives with their client down a 133 neighborhood street or apartment complex or a shopping center or 134 through a municipality (that has IP connectivity as a service). 136 If the client were provided a location URI reference to retain and 137 hand out when it wants or needs to convey its location (in a 138 protocol other than DHCP), a location URI that would not change as 139 the client's location changes (within a domain), scaling issues 140 would be significantly reduced to needing an update of the location 141 URI only when a client changes administrative domains - which is 142 much less often. This delivery of an indirect location has the 143 added benefit of not using up valuable or limited bandwidth to the 144 client with the constant updates. It also relieves the client from 145 having to determine when it has moved far enough to consider asking 146 for a refresh of its location. 148 In enterprise networks, if a known location is assigned to each 149 individual Ethernet port in the network, a device that attaches to 150 the network a wall-jack (directly associated with a specific 151 Ethernet Switch port) will be associated with a known location via a 152 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 153 [RFC3046]. This assumes wall-jacks have an updated wiremap 154 database. RFC 3825 and RFC 4776 would return an LCI value of 155 location. This document specifies how a location URI is returned 156 using DHCP. Behind the DHCP server, in the backend of the network, 157 via the (logical entity of an) LS has a PIDF-LO to be dereferenced 158 with a location URI. 160 If local configuration has the requirement of only assigning unique 161 location URIs to each client, then unique location URIs will be 162 given out, though they will all have the same location at the 163 record, relieving the backend Sighter or LS from individually 164 maintaining each location independently. 166 This Option can be useful in IEEE 802.16e connected endpoints or IP 167 cellular endpoints. The location URI Option can be configured as a 168 client if there is a router, such as a residential home gateway, 169 with the ability to communicate to downstream endpoints as a server. 171 How an LS responds to a dereference request can vary, and a policy 172 established by a Ruleholder [RFC3693] for a Location Target as to 173 what type of challenge(s) is to be used, how strong a challenge is 174 used or how precise the location information is given to a 175 Location Recipient (LR). All of this is outside the scope of this 176 document (since this will not be accomplished using DHCP). 178 This document IANA registers the new IPv4 and IPv6 DHC Options for a 179 location URI. 181 2. Format of the DHCP LuriElement Option 183 2.1 Overall Format of LuriElement Option in IPv4 185 The LuriElement Option format for IPv4 is as follows: 187 0 1 2 3 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Code XXX | Length=XX | Ver | Resv | . 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 192 . LuriElements... ... 193 . (see Section 2.3 for details) ... . 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1. IPv4 Fields for this LuriElement Option 198 Code XXX: The code for this DHCPv4 option (IANA assigned). 200 Length=XX: The length of this option, counted in bytes - not 201 counting the Code and Length bytes. This is a variable 202 length Option, therefore the length value will change 203 based on the length of the URI within the Option. 205 Ver: (4 bits) The version of this Option. This document 206 defines version 1 of this Option. 208 Resv: (4 bits) reserved for future use. 210 LuriElement: see Section 2.3 for details 212 2.2 Overall Format of LuriElement Option in IPv6 214 The LuriElement Option format for IPv6 is as follows: 216 0 1 2 3 217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | option-code | option-len | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Ver | Resv | . 222 +---------------+ . 223 . LuriElements... . 224 . (see Section 2.3 for details) . 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 2. IPv6 fields of this LuriElement Option 229 option-code: The code for this DHCPv6 option (IANA assigned). 231 option-len: The length of this option, counted in bytes - not 232 counting the Code and Length bytes. This is a variable 233 length Option, therefore the length value will change 234 based on the shape within the Option. 236 Ver: See above (Section 2.1). This will specify version 1. 238 Resv: See above (Section 2.1). 240 LuriElement: see below (Section 2.3 for details). 242 2.3 LuriElement Format for both IPv4 and IPv6 244 The LuriElement, in both DHCPv4 and DHCPv6, have the following 245 format: 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | LuriType | LuriLength | LuriValue ... 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 3. LuriElement Format for both IPv4 and IPv6 254 LuriType: A one-byte identifier of the data location value. 256 LuriLength: The length, in bytes, of the LuriValue, not including 257 the LuriLength field itself, up to a maximum of 255 258 bytes. 260 LuriValue: The LuriElement value, as described in detail below. 261 The LuriValue is always in UTP-8. 263 The LuriTypes this document defines (and IANA registers) for a point 264 are: 266 LuriType=1 Location URI - This is the URI pointing at the 267 location record where the PIDF-LO resides which 268 indicates the location of the Location Target. 270 LuriType=2 Valid-For - The time, in seconds, this URI is to be 271 considered Valid for dereferencing. The timer 272 associated with this LuriType starts upon receipt of 273 this Option. 275 The LuriType=2 (Valid-For) indicates how long, in seconds, the 276 client is to consider this LuriType=1 (location URI) valid 277 before performing a refresh of this Option, with a refreshed 278 LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done 279 the normal DHCP refresh rate, or necessitated by this timer, perhaps 280 with the client only requesting this Option be refreshed. 282 If the LuriType=2 (Valid-For) timer is received (solicited or 283 unsolicited), it is RECOMMENDED that the client refresh the Location 284 URI when the (Valid-For) counter value has reaches the halfway 285 point. For example, if 16000 was the initial value of the 286 LuriType=2 (Valid-For) value, when 8000 seconds have passed, the 287 Option SHOULD be refreshed. 289 The LuriType=2 (Valid-For) is not mandated for use by this document. 290 However, its presence MUST NOT cause any error in handling the 291 location URI (i.e., if not understood, it MUST be ignored). 293 This Option format is highly extensible. Additional LuriType types 294 created MUST be done so through IANA registration with peer review 295 and an RFC. 297 3. DHC Option Operation 299 The [RFC3046] RAIO MUST be utilized to provide the appropriate 300 indication to the DHCP Server where this DISCOVER or REQUEST message 301 came from, in order to supply the correct response. That said, this 302 Option SHOULD NOT be in a DISCOVER message, because there is zero 303 knowledge by the client of which Server will answer. 305 Caution SHOULD always be used involving the creation of large 306 Options, meaning that this Option MAY need to be in its own INFORM, 307 OPTION or ACK message. 309 It is RECOMMENDED to avoid building URIs, with any parameters, 310 larger than what a single DHCP response can be. However, if a 311 message is larger than 255 bytes, concatenation is allowed, per RFC 312 3396 [RFC3396]. 314 Per [RFC2131], subsequent LuriElement Options, which are 315 non-concatenated, overwrite the previous value. 317 Location URIs MUST NOT reveal identity information of the user of 318 the device, since DHCP is a cleartext delivery protocol. For 319 example, location URIs such as 321 sips:34LKJH534663J54@example.com 323 are to be done, providing no identity information, rather than a 324 location URI such as this 326 sips:aliceisat123mainstalanta@example.com 328 In the element of a PIDF-LO document, there is an 329 'entity' attribute that identities what entity *this* document 330 (including the associated location) refers to. It is up to the 331 PIDF-LO generator, either Location Server or an application in the 332 endpoint, to insert the identity in the 'entity' attribute. This 333 can be seen in [RFC4119]. The entity= discussion is orthogonal to 334 the identification information contained within the location URI. 336 This Option is used only for communications between a DHCP client 337 and a DHCP server. It can be solicited (requested) by the client, 338 or it can be pushed by the server without a request for it. DHCP 339 Options not understood are ignored. A DHCP server supporting this 340 Option might or might not have the location of a client. If a 341 server does not have a client's location, but needs to provide this 342 Location URI Option to a client (for whatever reason), an LS is 343 contacted. This server-to-LS transaction is not DHCP, therefore it 344 is out of scope of this document. 346 The deference of a target's location URI would not involve DHCP, but 347 an application layer protocol, such as SIP or HTTP, therefore 348 dereferencing is out of scope of this document. 350 In the case of residential gateways being DHCP servers, they usually 351 perform as DHCP clients in a hierarchical fashion up into a service 352 provider's network DHCP server(s), or learn what information to 353 provide via DHCP to residential clients through a protocol, such as 354 PPP. In these cases, the location URI would likely indicate the 355 residence's civic address to all wired or wireless clients within 356 that residence. 358 3.1 Architectural Assumptions 360 The following assumptions have been made for use of this LuriElement 361 Option for a client to learn its location URI (in no particular 362 order): 364 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 365 to the dereferencing step is assumed to be out of scope of this 366 document. An example authorization policy is in [ID-GEO-POL]. 368 o The authorization vs. possession security model can be found in 369 [ID-LBYR-REQ], describing what is expected in each model of 370 operation. It should be assumed that a location URI attained 371 using DHCP will operate under an authorization model. This means 372 possessing the location URI does not give that entity the right 373 to view the PIDF-LO of the target whose location is indicated in 374 a presence document. The dereference transaction will be, in 375 many environments, challenged by the Location Server. The nature 376 of this challenge is out of scope of this document. 378 o This document does not prevent some environments from operating 379 in a possession model, for example - tightly controlled 380 enterprise networks, but this operation SHOULD NOT be assumed to 381 exist as a matter of local policy. The costs associated with 382 authorization vs. possession models are discussed in Section 383 3.3.2 of [RFC5606]. 385 3.2 Harmful URIs and URLs 387 There are, in fact, some types of URIs that are not good to receive, 388 due to security concerns. For example, any URLs that can have 389 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 390 pages that have scripts. Therefore, 392 o URIs received via this Option SHOULD NOT be sent to a 393 general-browser to connect to a web page, because they could have 394 harmful scripts. 396 o This Option SHOULD NOT contain "data:" URLs, because they could 397 contain harmful scripts. 399 Instead of listing all the types of URIs and URLs that can be 400 misused or potentially have harmful affects, Section 3.3 IANA 401 registers acceptable location URI schemes (or types). 403 3.3 Valid Location URI Schemes or Types 405 This section specifies which URI types are acceptable as a location 406 URI scheme (or type) for this DHCP Option: 408 1. sip: 409 2. sips: 410 3. pres: 411 4. http: 412 5. https: 414 URIs using the "pres" scheme are dereferenced using the presence 415 event package for SIP [RFC3856], so they will reference a PIDF-LO 416 document when location is available. Responses to requests for URIs 417 with other schemes ("sip", "sips", "http", and "https") MUST have 418 MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS 419 URIs MAY refer to information with MIME type 'application/held+xml', 420 in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can 421 indicate which MIME types they support using the "Accept" header 422 field in SIP [RFC3261] or HTTP [RFC2616]. 424 These location URI types are IANA registered in Section 4.2 of this 425 document. 427 4. IANA Considerations 429 4.1 The IPv4 Option number for this Option 431 This document IANA registers this IPv4 Option number XXX (to be 432 assigned by IANA once this document becomes an RFC). 434 4.2 The IPv6 Option-Code for this Option 436 This document IANA registers this IPv6 Option-Code XXX (to be 437 assigned by IANA once this document becomes an RFC). 439 4.3 The Version number for this Option 441 This document IANA registers the version number 1 of this Option. 443 4.4 IANA Considerations for Acceptable Location URI Types 445 IANA is requested to create a new registry for acceptable location 446 URI types. 448 The following 3 URI types are registered by this document: 450 1. sip: 451 2. sips: 452 3. pres: 453 4. http: 454 5. https: 456 Any additional location URI types to be defined for use via 457 this DHC Option need to be created and IANA registered with peer 458 review and an RFC. 460 4.5 IANA Considerations for LuriTypes 462 IANA is requested to create a new registry for acceptable location 463 types defined in Section 3.2 of this document, arranged similar to 464 this: 466 +------------+----------------------------------------+-----------+ 467 | LuriType | Name | Reference | 468 +------------+----------------------------------------+-----------+ 469 | 1 | Location URI | RFC XXXX* | 470 | 2 | Valid-For | RFC XXXX* | 471 +------------+----------------------------------------+-----------+ 473 * RFC XXXX is to be replaced with this document's RFC-Editor RFC 474 number. 476 Additions to this list require a standards track RFC. 478 5. Security Considerations 480 Where critical decisions might be based on the value of this 481 location URI option, DHCP authentication in [RFC3118] SHOULD be used 482 to protect the integrity of the DHCP options. 484 A real concern with RFC 3118 it is that not widely deployed because 485 it requires pre-shared keys to successfully work (i.e., in the 486 client and in the server). Most implementations do not 487 accommodate this. 489 DHCP, initially, is a broadcast request (a client looking for a 490 server), and a unicast response (answer from a server) type of 491 protocol. It is not secure in a practical sense. In today's 492 infrastructures, DHCP will be primarily used over a wired, switched 493 Ethernet network, requiring physical access to within a wire to gain 494 access. Further, within an 802.11 wireless network, the 802.11 495 specs offer layer 2 security mechanisms to prevent a location URI 496 from being learned by an unauthorized entity. 498 That said, having the location URI does not mean an unauthorized 499 entity has the location of a client. The location URI still needs 500 to be dereferenced to learn the location of the client. This 501 dereferencing function, which is not done using DHCP, is done by 502 requesting the location record at a Location Server, which can 503 challenge each request it receives based on the policy provided by 504 the Ruleholder. The Ruleholder, as defined in RFC 3693, configures 505 the authentication and authorization policies for the location 506 revelation of a Target. This includes giving out more or less 507 precise location information in a response, therefore it can answer 508 a bad-hat, but not allow it from learning exactly where a client is. 510 Penetrating an LS is supposed to be hard, and hopefully vendors that 511 implement an LS accomplish this goal. 513 As to the concerns about the location URI itself, as stated in the 514 document here (in Section 3), it MUST NOT have any user identifying 515 information in the URI user-part/string itself. The location URI 516 also needs to be hard to guess that it belongs to a specific user. 518 When implementing a DHC server that will serve clients across an 519 uncontrolled network, one should consider the potential security 520 risks therein. 522 6. Acknowledgements 524 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 525 Robert Sparks for their useful comments. And to Lisa Dusseault for 526 her concerns about the types of URIs that can cause harm. To 527 Richard Barnes for inspiring a more robust Security Considerations 528 section, and for offering the text to incorporate HTTP URIs. To 529 Hannes Tschofenig and Ted Hardie for riding me to comply with their 530 concerns, including a good scrubbing of the nearly final doc. 532 7. References 534 7.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 540 3046, January 2001. 542 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 543 March 1997. 545 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 546 Messages", RFC 3118, June 2001. 548 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 549 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 550 Session Initiation Protocol", RFC 3261, May 2002. 552 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 553 Event Notification", RFC 3265, June 2002. 555 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 556 Host Configuration Protocol (DHCPv4)", RFC 3396, November 557 2002 559 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 560 Format", RFC 4119, December 2005 562 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 563 Initiation Protocol (SIP)", RFC 3856, August 2004 565 7.2. Informative References 567 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in 568 progress", Feb 2010 570 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 571 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 572 HELD", "work in progress", January 2010 574 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 575 Configuration Protocol Option for Coordinate-based Location 576 Configuration Information", RFC 3825, July 2004 578 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 579 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 580 Information ", RFC 4776, November 2006 582 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 583 Mechanism", "work in progress", November 2009 585 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 586 "Geopriv Requirements", RFC 3693, February 2004 588 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 589 Polk, "Geolocation Policy: A Document Format for Expressing 590 Privacy Preferences for Location Information", "work in 591 progress", July 2009 593 [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of 594 'retransmission-allowed' for SIP Location Conveyance", 595 August 2009 597 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 598 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 599 Protocol - HTTP/1.1", RFC 2616, June 1999 601 Authors' Address 603 James Polk 604 3913 Treemont Circle 605 Colleyville, Texas 76034 606 USA 608 Email: jmpolk@cisco.com