idnits 2.17.00 (12 Aug 2021) /tmp/idnits27900/draft-ietf-geopriv-dhcp-lbyr-uri-option-09.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 (Oct 13, 2010) is 4238 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) ** Downref: Normative reference to an Informational RFC: RFC 5808 -- 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 (~~), 3 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) Oct 13, 2010 4 Expires: April 13, 2011 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-09 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 April 13, 2011. 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 [RFC5808] 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). This document does not provide mechanisms 176 for the LS to tell the client about policies or for the client to 177 specify a policy for the LS. While an LS should apply an appropriate 178 access-control policy, clients must assume that the LS will provide 179 location in response to any request (following the possession model 180 [RFC5808]). For further discussion of privacy, see the Security 181 Considerations. 183 This document IANA registers the new IPv4 and IPv6 DHC Options for a 184 location URI. 186 2. Format of the DHCP LuriElement Option 188 2.1 Overall Format of LuriElement Option in IPv4 190 The LuriElement Option format for IPv4 is as follows: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Code XXX | Length=XX | . 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 197 . LuriElements... ... 198 . (see Section 2.3 for details) ... | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1. IPv4 Fields for this LuriElement Option 203 Code XXX: The code for this DHCPv4 option (IANA assigned). 205 Length=XX: The length of this option, counted in bytes - not 206 counting the Code and Length bytes. This is a variable 207 length Option, therefore the length value will change 208 based on the length of the URI within the Option. 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 | LuriElements... . 222 . (see Section 2.3 for details) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 2. IPv6 fields of this LuriElement Option 227 option-code: The code for this DHCPv6 option (IANA assigned). 229 option-len: The length of this option, counted in bytes - not 230 counting the Code and Length bytes. This is a variable 231 length Option, therefore the length value will change 232 based on the length of the URI within the Option. 234 LuriElement: see below (Section 2.3 for details). 236 2.3 LuriElement Format for both IPv4 and IPv6 238 The LuriElement, in both DHCPv4 and DHCPv6, have the following 239 format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | LuriType | LuriLength | LuriValue ... 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 3. LuriElement Format for both IPv4 and IPv6 249 LuriType: A one-byte identifier of the data location value. 251 LuriLength: The length, in bytes, of the LuriValue, not including 252 the LuriLength field itself, up to a maximum of 255 253 bytes. 255 LuriValue: The LuriElement value, as described in detail below. 256 The LuriValue is always in UTP-8. 258 The LuriTypes this document defines (and IANA registers) for a point 259 are: 261 LuriType=1 Location URI - This is the URI pointing at the 262 location record where the PIDF-LO resides which 263 indicates the location of the Location Target. 265 LuriType=2 Valid-For - The time, in seconds, this URI is to be 266 considered Valid for dereferencing. The timer 267 associated with this LuriType starts upon receipt of 268 this Option by the client. 270 The LuriType=2 (Valid-For) indicates how long, in seconds, the 271 client is to consider this LuriType=1 (location URI) valid 272 before performing a refresh of this Option, with a refreshed 273 LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done 274 the normal DHCP refresh rate, or necessitated by this timer, perhaps 275 with the client only requesting this Option be refreshed. 277 If the LuriType=2 (Valid-For) timer is received (solicited or 278 unsolicited), it is RECOMMENDED that the client refresh the Location 279 URI when the (Valid-For) counter value has reaches the halfway 280 point. For example, if 16000 was the initial value of the 281 LuriType=2 (Valid-For) value, when 8000 seconds have passed, the 282 Option SHOULD be refreshed. 284 The LuriType=2 (Valid-For) is not mandated for use by this document. 285 However, its presence MUST NOT cause any error in handling the 286 location URI (i.e., if not understood, it MUST be ignored). 288 This Option format is highly extensible. Additional LuriType types 289 created MUST be done so through IANA registration with a standards 290 track RFC. 292 3. DHC Option Operation 294 The [RFC3046] RAIO can be utilized to provide the appropriate 295 indication to the DHCP Server where this DISCOVER or REQUEST message 296 came from, in order to supply the correct response. 298 Caution SHOULD always be used involving the creation of large 299 Options, meaning that this Option MAY need to be in its own INFORM, 300 OPTION or ACK message. 302 It is RECOMMENDED to avoid building URIs, with any parameters, 303 larger than what a single DHCP response can be. However, if a 304 message is larger than 255 bytes, concatenation is allowed, per RFC 305 3396 [RFC3396]. 307 Per [RFC2131], subsequent LuriElement Options, which are 308 non-concatenated, overwrite the previous value. 310 Location URIs MUST NOT reveal identity information of the user of 311 the device, since DHCP is a cleartext delivery protocol. For 312 example, location URIs such as 314 sips:34LKJH534663J54@example.com 316 are to be done, providing no identity information, rather than a 317 location URI such as this 319 sips:aliceisat123mainstalanta@example.com 321 In the element of a PIDF-LO document, there is an 322 'entity' attribute that identities what entity *this* document 323 (including the associated location) refers to. It is up to the 324 PIDF-LO generator, either Location Server or an application in the 325 endpoint, to insert the identity in the 'entity' attribute. This 326 can be seen in [RFC4119]. The entity= discussion is orthogonal to 327 the identification information contained within the location URI. 329 This Option is used only for communications between a DHCP client 330 and a DHCP server. It can be solicited (requested) by the client, 331 or it can be pushed by the server without a request for it. DHCP 332 Options not understood are ignored. A DHCP server supporting this 333 Option might or might not have the location of a client. If a 334 server does not have a client's location, but needs to provide this 335 Location URI Option to a client (for whatever reason), an LS is 336 contacted. This server-to-LS transaction is not DHCP, therefore it 337 is out of scope of this document. 339 The deference of a target's location URI would not involve DHCP, but 340 an application layer protocol, such as SIP or HTTP, therefore 341 dereferencing is out of scope of this document. 343 In the case of residential gateways being DHCP servers, they usually 344 perform as DHCP clients in a hierarchical fashion up into a service 345 provider's network DHCP server(s), or learn what information to 346 provide via DHCP to residential clients through a protocol, such as 347 PPP. In these cases, the location URI would likely indicate the 348 residence's civic address to all wired or wireless clients within 349 that residence. 351 3.1 Architectural Assumptions 353 The following assumptions have been made for use of this LuriElement 354 Option for a client to learn its location URI (in no particular 355 order): 357 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 358 to the dereferencing step is assumed to be out of scope of this 359 document. An example authorization policy is in [ID-GEO-POL]. 361 o The authorization vs. possession security model can be found in 362 [RFC5808], describing what is expected in each model of 363 operation. It should be assumed that a location URI attained 364 using DHCP will operate under an authorization model. This means 365 possessing the location URI does not give that entity the right 366 to view the PIDF-LO of the target whose location is indicated in 367 a presence document. The dereference transaction will be, in 368 many environments, challenged by the Location Server. The nature 369 of this challenge is out of scope of this document. 371 o This document does not prevent some environments from operating 372 in a possession model, for example - tightly controlled 373 enterprise networks, but this operation SHOULD NOT be assumed to 374 exist as a matter of local policy. The costs associated with 375 authorization vs. possession models are discussed in Section 376 3.3.2 of [RFC5606]. 378 3.2 Harmful URIs and URLs 380 There are, in fact, some types of URIs that are not good to receive, 381 due to security concerns. For example, any URLs that can have 382 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 383 pages that have scripts. Therefore, 385 o URIs received via this Option SHOULD NOT be sent to a 386 general-browser to connect to a web page, because they could have 387 harmful scripts. 389 o This Option SHOULD NOT contain "data:" URLs, because they could 390 contain harmful scripts. 392 Instead of listing all the types of URIs and URLs that can be 393 misused or potentially have harmful affects, Section 3.3 IANA 394 registers acceptable location URI schemes (or types). 396 3.3 Valid Location URI Schemes or Types 398 This section specifies which URI types are acceptable as a location 399 URI scheme (or type) for this DHCP Option: 401 1. sip: 402 2. sips: 403 3. pres: 404 4. http: 406 5. https: 408 URIs using the "pres" scheme are dereferenced using the presence 409 event package for SIP [RFC3856], so they will reference a PIDF-LO 410 document when location is available. Responses to requests for URIs 411 with other schemes ("sip", "sips", "http", and "https") MUST have 412 MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS 413 URIs MAY refer to information with MIME type 'application/held+xml', 414 in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can 415 indicate which MIME types they support using the "Accept" header 416 field in SIP [RFC3261] or HTTP [RFC2616]. 418 These location URI types are IANA registered in Section 4.2 of this 419 document. 421 4. IANA Considerations 423 4.1 The IPv4 Option number for this Option 425 This document IANA registers this IPv4 Option number XXX (to be 426 assigned by IANA once this document becomes an RFC). 428 4.2 The IPv6 Option-Code for this Option 430 This document IANA registers this IPv6 Option-Code XXX (to be 431 assigned by IANA once this document becomes an RFC). 433 4.3 IANA Considerations for Acceptable Location URI Types 435 IANA is requested to create a new registry for acceptable location 436 URI types. 438 The following 3 URI types are registered by this document: 440 1. sip: 441 2. sips: 442 3. pres: 443 4. http: 444 5. https: 446 Any additional location URI types to be defined for use via 447 this DHC Option need to be created and IANA registered with peer 448 review and an RFC. 450 4.4 IANA Considerations for LuriTypes 452 IANA is requested to create a new registry for acceptable location 453 types defined in Section 3.2 of this document, arranged similar to 454 this: 456 +------------+----------------------------------------+-----------+ 457 | LuriType | Name | Reference | 458 +------------+----------------------------------------+-----------+ 459 | 1 | Location URI | RFC XXXX* | 460 | 2 | Valid-For | RFC XXXX* | 461 +------------+----------------------------------------+-----------+ 463 * RFC XXXX is to be replaced with this document's RFC-Editor RFC 464 number. 466 Additions to this registry require a standards track RFC. 468 5. Security Considerations 470 Where critical decisions might be based on the value of this 471 location URI option, DHCP authentication in [RFC3118] SHOULD be used 472 to protect the integrity of the DHCP options. 474 A real concern with RFC 3118 it is that not widely deployed because 475 it requires pre-shared keys to successfully work (i.e., in the 476 client and in the server). Most implementations do not 477 accommodate this. 479 DHCP, initially, is a broadcast request (a client looking for a 480 server), and a unicast response (answer from a server) type of 481 protocol. It does not provide security at the network layer. 482 Instead, it relies on lower-layer security mechanisms. In today's 483 infrastructures, DHCP will be primarily used over a wired, switched 484 Ethernet network, requiring physical access to within a wire to gain 485 access. Further, within an 802.11 wireless network, the 802.11 486 specs offer layer 2 security mechanisms to prevent a location URI 487 from being learned by an unauthorized entity. 489 Once a client has a URI, it needs information on how the location 490 server will control access to dereference requests. A client might 491 treat a tightly access-controlled URI differently from one that can 492 be dereferenced by anyone on the Internet (i.e., one following the 493 "possession model"). With the LuriTypes defined in this document, 494 the DHCP option for delivering location URIs can only tell the user 495 how long the URI will be valid. Since the client does not know what 496 policy will be applied during this validity interval, clients MUST 497 handle location URIs as if they could be dereferenced by anybody 498 until they expire. For example, such open location URIs should only 499 be transmitted in encrypted channels. Nonetheless, location servers 500 SHOULD apply appropriate access control policies, for example by 501 limiting the number of queries that any given client can make, or 502 limiting access to users within an enterprise. 504 Extensions to this option, such as [ID-POLICY-URI] can provide 505 mechanisms for accessing and provisioning policy. Giving users 506 access to policy information will allow them to make more informed 507 decisions about how to use their location URIs. Allowing users to 508 provide policy information to the LS will enable them to tailor 509 access control policies to their needs (within the bounds of policy 510 that the LS will accept). 512 Penetrating an LS is supposed to be hard, and hopefully vendors that 513 implement an LS accomplish this goal. 515 As to the concerns about the location URI itself, as stated in the 516 document here (in Section 3), it MUST NOT have any user identifying 517 information in the URI user-part/string itself. The location URI 518 also needs to be hard to guess that it belongs to a specific user. 520 When implementing a DHC server that will serve clients across an 521 uncontrolled network, one should consider the potential security 522 risks therein. 524 6. Acknowledgements 526 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 527 Robert Sparks for their useful comments. And to Lisa Dusseault for 528 her concerns about the types of URIs that can cause harm. To 529 Richard Barnes for inspiring a more robust Security Considerations 530 section, and for offering the text to incorporate HTTP URIs. To 531 Hannes Tschofenig and Ted Hardie for riding me to comply with their 532 concerns, including a good scrubbing of the nearly final doc. To 533 Richard Barnes for his guidance with respect to the model used by 534 this document and fine tuning the security considerations section. 536 7. References 538 7.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 544 3046, January 2001. 546 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 547 March 1997. 549 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 550 Messages", RFC 3118, June 2001. 552 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 553 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 554 Session Initiation Protocol", RFC 3261, May 2002. 556 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 557 Host Configuration Protocol (DHCPv4)", RFC 3396, November 558 2002 560 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 561 Format", RFC 4119, December 2005 563 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 564 Initiation Protocol (SIP)", RFC 3856, August 2004 566 [RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference 567 Mechanism", RFC 5808, May 2010 569 7.2. Informative References 571 [ID-SIP-LOC] J. Polk, B. Rosen, J. Peterson, "SIP Location 572 Conveyance", "work in progress", July 2010 574 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 575 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 576 HELD", "work in progress", January 2010 578 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 579 Configuration Protocol Option for Coordinate-based Location 580 Configuration Information", RFC 3825, July 2004 582 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 583 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 584 Information ", RFC 4776, November 2006 586 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference 587 Mechanism", RFC 5808, May 2010 589 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 590 "Geopriv Requirements", RFC 3693, February 2004 592 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 593 Polk, "Geolocation Policy: A Document Format for Expressing 594 Privacy Preferences for Location Information", "work in 595 progress", July 2010 597 [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of 598 'retransmission-allowed' for SIP Location Conveyance", 599 August 2009 601 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 602 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 603 Protocol - HTTP/1.1", RFC 2616, June 1999 605 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 606 Configuration Extensions for Policy Management", "work in 607 progress", May 2010 609 Authors' Address 611 James Polk 612 3913 Treemont Circle 613 Colleyville, Texas 76034 614 USA 616 Email: jmpolk@cisco.com