idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-11.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 -- 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 (Feb 11, 2011) is 4822 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 (~~), 2 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: Proposed Standard Feb 11, 2011 4 Expires: August 11, 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-11 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 August 11, 2011. 41 Copyright Notice 43 Copyright (c) 2011 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 LocationURI Option . . . . . . . . . . . . 4 60 2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4 61 2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5 62 2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5 63 3. DHCP 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] and HTTP [RFC2616]. 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 if 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 Data 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 was 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. The location URI points to a PIDF-LO contained on an 157 LS. Performing a dereferencing transaction, that Target's PIDF-LO 158 will be returned. If local configuration has the requirement of 159 only assigning unique location URIs to each client at the same 160 attachment point to the network (i.e., same RJ-45 jack or same 161 802.11 Access Point - except when triangulation is used), then 162 unique location URIs will be given out, though they will all have 163 the same location at the record, relieving the backend Sighter or LS 164 from individually 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 on a 168 router, such as a residential home gateway, such that the router 169 receives this Location URI Option as a client with the ability to 170 communicate to downstream endpoints as a server. 172 How an LS responds to a dereference request can vary, and a policy 173 established by a Ruleholder [RFC3693] for a Location Target as to 174 what type of challenge(s) is to be used, how strong a challenge is 175 used or how precise the location information is given to a 176 Location Recipient (LR). This document does not provide mechanisms 177 for the LS to tell the client about policies or for the client to 178 specify a policy for the LS. While an LS should apply an appropriate 179 access-control policy, clients must assume that the LS will provide 180 location in response to any request (following the possession model 181 [RFC5808]). For further discussion of privacy, see the Security 182 Considerations. 184 This document IANA-registers the new IPv4 and IPv6 DHCP Options for 185 a location URI. 187 2. Format of the DHCP LocationURI Option 189 2.1 Overall Format of LocationURI Option in IPv4 191 The LocationURI Option format for IPv4 is as follows: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Code XXX | Length=XX | . 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 198 . LocationURI... ... 199 . (see Section 2.3 for details) ... | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 1. IPv4 Fields for this LocationURI Option 204 Code XXX: The code for this DHCPv4 option (IANA assigned). 206 Length=XX: The length of this option, counted in bytes - not 207 counting the Code and Length bytes. This is a variable 208 length Option, therefore the length value will change 209 based on the length of the URI within the Option. 211 LocationURI: see Section 2.3 for details 213 2.2 Overall Format of LocationURI Option in IPv6 215 The LocationURI Option format for IPv6 is as follows: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | option-code | option-len | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | LocationURI... . 223 . (see Section 2.3 for details) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 2. IPv6 fields of this LocationURI Option 228 option-code: The code for this DHCPv6 option (IANA assigned). 230 option-len: The length of this option, counted in bytes - not 231 counting the Code and Length bytes. This is a variable 232 length Option, therefore the length value will change 233 based on the length of the URI within the Option. 235 LocationURI: see below (Section 2.3 for details). 237 2.3 LocationURI Format for both IPv4 and IPv6 239 The LocationURI, in both DHCPv4 and DHCPv6, have the following 240 format: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | LuriType | LuriLength | LuriValue ... 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 3. LocationURI TLV Format for both IPv4 and IPv6 250 LuriType: A one-byte identifier of the data location value. 252 LuriLength: The length of the LuriValue, not including the 253 LuriLength field itself, up to a maximum of 255 254 units. The unit of measurement is defined by the 255 LuriType field definition. The LuriLength itself is 256 always a one-byte unsigned integer. 258 LuriValue: The LocationURI value, as described in detail below. 260 The LuriTypes this document defines (and IANA registers) for a point 261 are: 263 LuriType=1 Location URI - This is the URI pointing at the 264 location record where the PIDF-LO resides, which 265 indicates the location of the Location Target. The 266 LuriValue of LuriType=1 is always represented in 267 UTF-8. 269 LuriType=2 Valid-For - The time, in seconds, this URI is to be 270 considered Valid for dereferencing. The timer 271 associated with this LuriType starts upon receipt of 272 this Option by the client. The LuriValue of LuriType=2 273 is always represented as a four-byte unsigned integer. 275 The Valid-For (LuriType=2) indicates how long, in seconds, the 276 client is to consider this location URI (LuriType=1) to be 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 during the normal DHCP refresh rate, or necessitated by this timer, 280 perhaps with the client only requesting this Option be refreshed. 282 If the Valid-For timer (LuriType=2) is received (solicited or 283 unsolicited), it is RECOMMENDED that the client refresh the Location 284 URI when the (Valid-For) counter value reaches the halfway point. 285 For example, if 16000 was the initial value of the Valid-For 286 (LuriType=2) value, when 8000 seconds have passed, the 287 Option SHOULD be refreshed. 289 The Valid-For (LuriType=2) 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 a standards 295 track RFC. 297 3. DHCP Option Operation 299 The [RFC3046] RAIO can 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. 303 Caution SHOULD always be used involving the creation of large 304 Options, meaning that this Option MAY need to be in its own INFORM, 305 OPTION or ACK message. 307 It is RECOMMENDED to avoid building URIs, with any parameters, 308 larger than what a single DHCP response can be. However, if a 309 message is larger than 255 bytes, concatenation is allowed, per RFC 310 3396 [RFC3396]. 312 Per [RFC2131], subsequent LocationURI Options, which are 313 non-concatenated, overwrite the previous value. 315 Location URIs MUST NOT reveal identity information of the user of 316 the device, since DHCP is a cleartext delivery protocol. For 317 example, location URIs such as 319 sips:34LKJH534663J54@example.com 321 are to be done (in which 34LKJH534663J54 is considered to be random 322 in this example), providing no identity information, rather than a 323 location URI such as this 325 sips:aliceisat123mainstalantageorgiaus@example.com 327 In the element of a PIDF-LO document, there is an 328 'entity' attribute that identities what entity *this* document 329 (including the associated location) refers to. It is up to the 330 PIDF-LO generator, either Location Server or an application in the 331 endpoint, to insert the identity in the 'entity' attribute. This 332 can be seen in [RFC4119]. The entity= discussion is orthogonal to 333 the identification information contained within the location URI. 335 This Option is used only for communications between a DHCP client 336 and a DHCP server. It can be solicited (requested) by the client, 337 or it can be pushed by the server without a request for it. DHCP 338 Options not understood MUST be ignored [RFC2131]. A DHCP server 339 supporting this Option might or might not have the location of a 340 client. If a server does not have a client's location, but needs to 341 provide this Location URI Option to a client (for whatever reason), 342 an LS is contacted. This server-to-LS transaction is not DHCP, 343 therefore it is out of scope of this document. Note that this 344 server-to-LS transaction could delay the DHCP messaging to the 345 client. If the server fails to have location before it transmits its 346 message to the client, location will not be part of that DHCP 347 message. Any timers involved here are a matter of local 348 configuration. 350 The deference of a target's location URI would not involve DHCP, but 351 an application layer protocol, such as SIP or HTTP, therefore 352 dereferencing is out of scope of this document. 354 In the case of residential gateways being DHCP servers, they usually 355 perform as DHCP clients in a hierarchical fashion up into a service 356 provider's network DHCP server(s), or learn what information to 357 provide via DHCP to residential clients through a protocol, such as 358 PPP. In these cases, the location URI would likely indicate the 359 residence's civic address to all wired or wireless clients within 360 that residence. 362 3.1 Architectural Assumptions 364 The following assumptions have been made for use of this LocationURI 365 Option for a client to learn its location URI (in no particular 366 order): 368 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 369 to the dereferencing step is assumed to be out of scope of this 370 document. An example authorization policy is in [ID-GEO-POL]. 372 o The authorization vs. possession security model can be found in 373 [RFC5808], describing what is expected in each model of 374 operation. It should be assumed that a location URI attained 375 using DHCP will operate under an possession model by default. 376 An authorization model can be instituted as a matter of local 377 policy. An authorization model means possessing the location URI 378 does not give that entity the right to view the PIDF-LO of the 379 target whose location is indicated in a presence document. The 380 dereference transaction will be challenged by the Location Server 381 only in an authorization model. The nature of this challenge is 382 out of scope of this document. 384 o This document does not prevent some environments from operating 385 in an authorization model, for example - in less tightly 386 controlled networks. The costs associated with authorization vs. 387 possession models are discussed in Section 3.3.2 of [RFC5606]. 389 3.2 Harmful URIs and URLs 391 There are, in fact, some types of URIs that are not good to receive, 392 due to security concerns. For example, any URLs that can have 393 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 394 pages that have scripts. Therefore, 396 o URIs received via this Option SHOULD NOT be sent to a 397 general-browser to connect to a web page, because they could have 398 harmful scripts. 400 o This Option SHOULD NOT contain "data:" URLs, because they could 401 contain harmful scripts. 403 Instead of listing all the types of URIs and URLs that can be 404 misused or potentially have harmful affects, Section 3.3 IANA 405 registers acceptable location URI schemes (or types). 407 3.3 Valid Location URI Schemes or Types 409 This section specifies which URI types are acceptable as a location 410 URI scheme (or type) for this DHCP Option: 412 1. sip: 413 2. sips: 414 3. pres: 415 4. http: 416 5. https: 418 URIs using the "pres" scheme are dereferenced using the presence 419 event package for SIP [RFC3856], so they will reference a PIDF-LO 420 document when location is available. Responses to requests for URIs 421 with other schemes ("sip", "sips", "http", and "https") MUST have 422 MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS 423 URIs MAY refer to information with MIME type 'application/held+xml', 424 in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can 425 indicate which MIME types they support using the "Accept" header 426 field in SIP [RFC3261] or HTTP [RFC2616]. 428 These location URI types are IANA registered in Section 4.2 of this 429 document. 431 4. IANA Considerations 433 4.1 The IPv4 Option number for this Option 435 This document IANA registers this IPv4 Option number XXX (to be 436 assigned by IANA once this document becomes an RFC). 438 4.2 The IPv6 Option-Code for this Option 440 This document IANA registers this IPv6 Option-Code XXX (to be 441 assigned by IANA once this document becomes an RFC). 443 4.3 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 5 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 DHCP Option need to be created and IANA registered with peer 458 review and an RFC. 460 4.4 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 registry 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 does not provide security at the network layer. 492 Instead, it relies on lower-layer security mechanisms. 494 Once a client has a URI, it needs information on how the location 495 server will control access to dereference requests. A client might 496 treat a tightly access-controlled URI differently from one that can 497 be dereferenced by anyone on the Internet (i.e., one following the 498 "possession model"). With the LuriTypes defined in this document, 499 the DHCP option for delivering location URIs can only tell the user 500 how long the URI will be valid. Since the client does not know what 501 policy will be applied during this validity interval, clients MUST 502 handle location URIs as if they could be dereferenced by anybody 503 until they expire. For example, such open location URIs should only 504 be transmitted in encrypted channels. Nonetheless, location servers 505 SHOULD apply appropriate access control policies, for example by 506 limiting the number of queries that any given client can make, or 507 limiting access to users within an enterprise. 509 Extensions to this option, such as [ID-POLICY-URI] can provide 510 mechanisms for accessing and provisioning policy. Giving users 511 access to policy information will allow them to make more informed 512 decisions about how to use their location URIs. Allowing users to 513 provide policy information to the LS will enable them to tailor 514 access control policies to their needs (within the bounds of policy 515 that the LS will accept). 517 Penetrating an LS is supposed to be hard, and hopefully vendors that 518 implement an LS accomplish this goal. 520 As to the concerns about the location URI itself, as stated in the 521 document (see Section 3), it MUST NOT have any user identifying 522 information in the URI user-part/string itself. The location URI 523 also needs to be hard to guess that it belongs to a specific user. 525 When implementing a DHCP server that will serve clients across an 526 uncontrolled network, one should consider the potential security 527 risks therein. 529 6. Acknowledgements 531 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 532 Robert Sparks for their useful comments. And to Lisa Dusseault for 533 her concerns about the types of URIs that can cause harm. To 534 Richard Barnes for inspiring a more robust Security Considerations 535 section, and for offering the text to incorporate HTTP URIs. To 536 Hannes Tschofenig and Ted Hardie for riding me to comply with their 537 concerns, including a good scrubbing of the nearly final doc. 539 7. References 541 7.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 547 3046, January 2001. 549 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 550 March 1997. 552 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 553 Messages", RFC 3118, June 2001. 555 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 557 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 558 Session Initiation Protocol", RFC 3261, May 2002. 560 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 561 Host Configuration Protocol (DHCPv4)", RFC 3396, November 562 2002 564 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 565 Format", RFC 4119, December 2005 567 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 568 Initiation Protocol (SIP)", RFC 3856, August 2004 570 [RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference 571 Mechanism", RFC 5808, May 2010 573 7.2. Informative References 575 [ID-SIP-LOC] J. Polk, B. Rosen, J. Peterson, "SIP Location 576 Conveyance", "work in progress", Feb 2011 578 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 579 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 580 HELD", "work in progress", December 2010 582 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 583 Configuration Protocol Option for Coordinate-based Location 584 Configuration Information", RFC 3825, July 2004 586 [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol 587 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 588 Information ", RFC 4776, November 2006 590 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference 591 Mechanism", RFC 5808, May 2010 593 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 594 "Geopriv Requirements", RFC 3693, February 2004 596 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 597 Polk, "Geolocation Policy: A Document Format for Expressing 598 Privacy Preferences for Location Information", "work in 599 progress", Oct 2010 601 [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of 602 'retransmission-allowed' for SIP Location Conveyance", 603 August 2009 605 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 606 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 607 Protocol - HTTP/1.1", RFC 2616, June 1999 609 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 610 Configuration Extensions for Policy Management", "work in 611 progress", January 2011 613 Authors' Address 615 James Polk 616 3913 Treemont Circle 617 Colleyville, Texas 76034 618 USA 620 Email: jmpolk@cisco.com