Geopriv WG James Polk Internet-Draft Cisco Systems Intended status: Standards Track (PS) July 13, 2009 Expires: January 13, 2010 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) draft-ietf-geopriv-dhcp-lbyr-uri-option-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Polk Expires January 13, 2010 [Page 1] Internet-Draft Geopriv DHCP Location URI Option July 2009 Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document creates a Dynamic Host Configuration Protocol (DHCP) Option for the downloading of a Location Uniform Resource Identifier (URI) of a client, to be dereferenced in a separate transaction. Once the location URI is received by an endpoint, it can be dereferenced by the client to learn its geographic location, or sent to another entity to learn this client's location. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 5 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 5 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 6 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Polk Expires January 13, 2010 [Page 2] Internet-Draft Geopriv DHCP Location URI Option July 2009 1. Introduction This document creates a Dynamic Host Configuration Protocol (DHCP) Option for the downloading of a Location Uniform Resource Identifier (URI) of a client, to be dereferenced in a separate transaction. A client, for example, can be a Session Initiation Protocol (SIP) User Agent (UA) [RFC3261] (i.e., a Phone). This location URI points a Location Server [ID-LBYR-REQ] which has the geolocation of the client (through means not defined in this document). The Location Server stores the Target's location a presence document, called a Presence Information Date Format - Location Object (PIDF-LO). Once a client attains this location URI, an application on the target can either dereference the URI to receive its PIDF-LO, or it can convey this location URI instead of conveying the location value in a message. Having a location URI has advantages over having a PIDF-LO, especially when a target's location changes. With a location URI, when a target moves, the location URI does not. It can still be given out as the Target's location. The opposite is true if the location is conveyed by value in a message. Once the Target moves, the previously given location is no longer valid, and it the Target wants to inform another entity about its location, it has to send the PIDF-LO to the location recipient (again). The act of dereferencing location from a location URI is explained in [ID-SIP-LOC], which shows how a Location Recipient of a location URI subscribes to a Location Server to attain the location of the Target. If the dereferencer has permission, defined in [ID-GEO-POL], the location of the target will be received. The Location Server (LS) will grant permission to location inquires based on the rules established by a Rule Holder [RFC3693]. The Location Server has the ability to challenge any request of a target's location, thereby providing additive security properties before location revelation. There are use-cases, such as calling the appropriate Pizza Hut without having to look up in a directory which store is closest, where a UA knowing its location can call a main/national/international Pizza Hut number or address and let the UA's location tell Pizza Hut enough information to have them route/retarget the SIP request to the appropriate store within the Pizza Hut organization to deliver the pizza to the caller's location. A problem exists within existing RFCs that provide location to the UA ([RFC3825] and [RFC4776]), these DHCP Options for geolocation require an update of the entire location information (LI) every time a client moves. Not all clients will move frequently, but some will. Refreshing location every time a client moves does not scale in certain networks/environments, such as IP based cellular networks, enterprise networks or service provider networks with mobile endpoints. An 802.11 based access network is one example of Polk Expires January 13, 2010 [Page 3] Internet-Draft Geopriv DHCP Location URI Option July 2009 this. Constantly updating LCI to endpoints might not scale in mobile (residential or enterprise or municipal) networks in which the client is moving through more than one network attachment point, perhaps as a person walks or drives with their endpoint down a neighborhood street or apartment complex or a shopping center. If the client were provided a location URI reference to retain and hand out when it wants or needs to convey its location (in a protocol other than DHCP), a location URI that would not change as the client's location changes (within a domain), scaling issues would be significantly reduced to needing an update of the location URI only when a client changes administrative domains - which is much less often. This delivery of an indirect location has the added benefit of not using up valuable or limited bandwidth to the client with the constant updates. It also relieves the client from having to determine when it has moved far enough to consider asking for a refresh of its location. In enterprise networks, if a known location is assigned to each individual Ethernet port in the network, a device that attaches to the network a wall-jack (directly associated with a specific Ethernet Switch port) will be associated with a known location via a unique circuit-ID that's used by the RAIO Option defined in RFC 3046 [RFC3046]. This assumes wall-jacks have an updated wiremap database. RFC 3825 and RFC 4776 would return an LCI value of location. This document specifies how a location URI is returned using DHCP. Behind the DHCP server, in the backend of the network, via the (logical entity of an) LS has a PIDF-LO to be dereferenced with a location URI. If local configuration has the requirement of only assigning unique location URIs to each client, then unique LbyRs will be given out, though they will all have the same location at the record, relieving the backend Sighter from individually maintaining each location independently. This Option can be useful in WiMAX connected endpoints or IP cellular endpoints. The location URI Option can be configured as a client if there is a router, such as a residential home gateway, with the ability to communicate to downstream endpoints as a server. How an LS challenges a dereference can vary, and a policy established by a rulemaker [RFC3693] for a Location Target as to what type of challenge(s) is to be used, how strong a challenge is used or how precise the location information is given to a requestor. All of this is outside the scope of this document (since this will not be accomplished using DHCP). This document IANA registers the new IPv4 and IPv6 DHC Options for a location URI. Polk Expires January 13, 2010 [Page 4] Internet-Draft Geopriv DHCP Location URI Option July 2009 2. Format of the DHCP LuriElement Option 2.1 Overall Format of LuriElement Option in IPv4 The LuriElement Option format for IPv4 is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code XXX | Length=XX | Ver | Resv | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . LuriElements... ... . (see section 2.3 for details) ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. IPv4 Fields for this LuriElement Option Code XXX: The code for this DHCPv4 option (IANA assigned). Length=XX: The length of this option, counted in bytes - not counting the Code and Length bytes. This is a variable length Option, therefore the length value will change based on the length of the LbyR within the Option. Ver: (4 bits) The version of this Option. This document defines version 1 of this Option. Resv: (4 bits) reserved for future use. LuriElement: see section 2.3 for details 2.2 Overall Format of LuriElement Option in IPv6 The LuriElement Option format for IPv6 is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Resv | . +---------------+ . . LuriElements... . . (see section 2.3 for details) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. IPv6 fields of this LuriElement Option option-code: The code for this DHCPv6 option (IANA assigned). option-len: The length of this option, counted in bytes - not Polk Expires January 13, 2010 [Page 5] Internet-Draft Geopriv DHCP Location URI Option July 2009 counting the Code and Length bytes. This is a variable length Option, therefore the length value will change based on the shape within the Option. Ver: See above (Section 2.1). This will specify version 1. Resv: See above (Section 2.1). LuriElement: see below (Section 2.3 for details). 2.3 LuriElement Format for both IPv4 and IPv6 The LuriElement, in both DHCPv4 and DHCPv6, have the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LuriType | LuriLength | LuriValue ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. LuriElement Format for both IPv4 and IPv6 LuriType: A one-byte identifier of the data location value. LuriLength: The length, in bytes, of the LuriValue, not including the LuriLength field itself, up to a maximum of 255 bytes. LuriValue: The LuriElement value, as described in detail below. The LuriValue is always in UTP-8. The LuriTypes this document defines (and IANA registers) for a point are: LuriType=1 Location URI - This is the URI pointing at the location record where the PIDF-LO resides which indicates the location of the Location Target. LuriType=2 Valid-For - The time, in seconds, this URI is to be considered Valid for dereferencing. The timer associated with this LuriType starts upon receipt of this Option. The LuriType=2 (Valid-For) indicates how long, in seconds, the client is to consider this LuriType=1 (location URI) valid before performing a refresh of this Option, with a refreshed LuriType=2 (Valid-For) value. A refresh MAY be done merely at the normal DHCP refresh rate, or necessitated by this timer, perhaps with the client only requesting this Option be refreshed. Polk Expires January 13, 2010 [Page 6] Internet-Draft Geopriv DHCP Location URI Option July 2009 It is RECOMMENDED when the counter associated with this LuriType=2 (Valid-For) value has passed, the client perform a refresh of this Option. For example, if 16000 was the initial value of the LuriType=2 (Valid-For) value, when 8000 seconds have passed, the Option SHOULD be refreshed. The LuriType=2 (Valid-For) is not mandated for use by this document. However, its presence MUST NOT cause any error in handling the location URI (i.e., if not understood, it MUST be ignored). This Option format is highly extensible. Additional LuriType types created MUST be done so through IANA registration with peer review and an RFC. 3. DHC Option Operation The [RFC3046] RAIO MUST be utilized to provide the appropriate indication to the DHCP Server where this DISCOVER or REQUEST message came from, in order to supply the correct response. That said, this Option SHOULD NOT be in a DISCOVER message, because there is zero knowledge by the client of which Server will answer. Caution SHOULD always be used involving the creation of large Options, meaning that this Option MAY need to be in its own INFORM, OPTION or ACK message. It is RECOMMENDED to avoid building URIs, with any parameters, larger than what a single DHCP response can be. However, if a message is larger than 255 bytes, concatenation is allowed, per RFC 3396 [RFC3396]. Per [RFC2131], subsequent LuriElement Options, which are non-concatenated, overwrite the previous value. location URIs MUST NOT reveal identity information of the user of the device, since DHCP is a cleartext delivery protocol. For example, location URIs such as sips:34LKJH534663J54@example.com SHOULD be done, providing no identity information, rather than a location URI such as this sips:aliceisinatlanta@example.com In the element of the PIDF-LO there is an entity= attribute that identities the target of *this* location. It is up to the PIDF-LO generator, either Location Server or an application in the endpoint, to insert the identity in the entity= attribute. This can be seen in [RFC4119]. The entity= discussion is orthogonal Polk Expires January 13, 2010 [Page 7] Internet-Draft Geopriv DHCP Location URI Option July 2009 to the identification information contained within the location URI. This Option is only for communications between a DHCP client and a DHCP server. It can be solicited (requested) by the client, or it can be pushed by the server without a request for it. DHCP Options not understood are ignored. A DHCP server might or might not have the location of a client, therefore direct knowledge of a location URI within the server. If a server does not have a client's location, a communication path (or request) to an LS would be necessary. Further, any location revelation rules and policies a user has regarding the treatment of their actual location, and who can access (what precision of) their location will be done with a protocol other than DHCP, and likely will be done before anything other than default authentication and authorization permissions are used when a Location Recipient requests for a Target's location. Differentiating clients is done via client identifiers. Therefore, in many implementations, each client can be assigned unique location URIs, though this is not mandatory. Any dereferencing of a client's location URI would not involve DHCP as well, but more likely by an application layer protocol such as SIP, through a subscription to the location URI on the LS. The LS would also handle all authentication and authorization of location requests, which is also not performed with DHCP, therefore not defined here. In the case of residential gateways being DHCP servers, they usually perform as DHCP clients in a hierarchical fashion up into a service provider's network DHCP server(s), or learn what information to provide via DHCP to residential clients through a protocol such as PPP. In these cases, the location URI would likely indicate the residence's civic address to all wired or wireless clients within that residence. This is not inconsistent with what's stated above. 3.1 Architectural Assumptions The following assumptions have been made for use of this LuriElement Option for a client to learn its location URI (in no particular order): o Any user control (what [RFC3693] calls a 'ruleholder') for the parameters and profile options a Location Object will have is out of scope of this document, but assumed to take place via an external web interface between the user and the Location Server (direct or indirect). Some of this is described in [ID-GEO-POL]. o The authorization vs. possession security model can be found in [ID-LBYR-REQ], describing what is expected in each model of Polk Expires January 13, 2010 [Page 8] Internet-Draft Geopriv DHCP Location URI Option July 2009 operation. It should be assumed that a location URI attained using DHCP will operate under an authorization model. This means possessing the location URI does not give that entity the right to view the PIDF-LO of the target whose location is indicated in a presence document. The dereference transaction will be, in many environments, challenged by the Location Server. The nature of this challenge is out of scope of this document. o This document does not prevent some environments from operating in a possession model, for example - tightly controlled enterprise networks, but this operation SHOULD NOT be assumed to exist as a matter of local policy. The costs associated with authorization vs. possession models are discussed in section 3.3.2 of [ID-GEO-RA]. 3.2 Harmful URIs and URLs There are, in fact, some types of URIs that are not good to receive, due to security concerns. For example, any URLs that can have scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web pages that have scripts. Therefore, o URIs received via this Option SHOULD NOT be sent to a general-browser to connect to a web page, because they could have harmful scripts. o This Option SHOULD NOT contain "data:" URLs, because they could contain harmful scripts. Instead of listing all the types of URIs and URLs that can be misused or potentially have harmful affects, Section 3.3 IANA registers acceptable location URI schemes (or types). 3.3 Valid Location URI Schemes or Types This section specifies which URI types are acceptable as a location URI scheme (or type) for this DHCP Option: 1. sip: 2. sips: 3. pres: These location URI types are IANA registered in section 4.2 of this document. Polk Expires January 13, 2010 [Page 9] Internet-Draft Geopriv DHCP Location URI Option July 2009 4. IANA Considerations 4.1 The IPv4 Option number for this Option This document IANA registers this IPv4 Option number XXX (to be assigned by IANA once this document becomes an RFC). 4.2 The IPv6 Option-Code for this Option This document IANA registers this IPv6 Option-Code XXX (to be assigned by IANA once this document becomes an RFC). 4.3 The Version number for this Option This document IANA registers the version number 1 of this Option. 4.4 IANA Considerations for Acceptable Location URI Types IANA is requested to create a new registry for acceptable location URI types. The following 3 URI types are registered by this document: 1. sip: 2. sips: 3. pres: Any additional location URI types to be defined for use via this DHC Option need to be created and IANA registered with peer review and an RFC. 4.5 IANA Considerations for LuriTypes IANA is requested to create a new registry for acceptable location types defined in section 3.2 of this document, arranged similar to this: +------------+----------------------------------------+-----------+ | LuriType | Name | Reference | +------------+----------------------------------------+-----------+ | 1 | Location URI | RFC XXXX* | | 2 | Valid-For | RFC XXXX* | +------------+----------------------------------------+-----------+ * RFC XXXX is to be replaced with this document's RFC-Editor RFC number. Additions to this list require a standards track RFC. Polk Expires January 13, 2010 [Page 10] Internet-Draft Geopriv DHCP Location URI Option July 2009 5. Security Considerations Where critical decisions might be based on the value of this location URI option, DHCP authentication in [RFC3118] SHOULD be used to protect the integrity of the DHCP options. A real concern with RFC 3118 it is that not widely deployed because it requires pre-shared keys to successfully work (i.e., in the client and in the server). Most implementations do not accommodate this. DHCP is a broadcast initially (a client looking for a server), unicast response (answer from a server) type of protocol. It is not secure in a practical sense. In today's infrastructures, DHCP will be primarily used over a wired, switched Ethernet network, requiring physical access to within a wire to gain access. Further, within an 802.11 wireless network, the 802.11 specs have layer 2 security mechanisms in place to help prevent a location URI from being learned by an unauthorized entity. That said, having the location URI does not mean an unauthorized entity has the location of a client. The location URI still needs to be dereferenced to learn the location of the client. This dereferencing function, which is not done using DHCP, is done by requesting the location record at a Location Server, which is a defined entity built to challenge each request it receives based on a joint policy of what is called a rulemaker. The ruleholder, as defined in RFC 3693, configures the authentication and authorization policies for the location revelation of a Target. This includes giving out more or less precise location information in a response, therefore it can answer a bad-hat, but not allow it from learning exactly where a client is. The rulemaker, which is a combination of the default rules set up by the location provider and those decided on by the user of the Target device. Likely, the rules the user wants will not be allowed to go past some limits established by the location provider, i.e., the administrator of the LS, for various capability or security reasons. Penetrating an LS is supposed to be hard, and hopefully vendors that implement an LS accomplish this goal. It is envisioned, as stated in the text above, as described both in [ID-LBYR-REQ] and [ID-GEO-RA], this Option MUST be assumed to operate under an authorization model, vs. a much more open possession model. This model choice is not strictly enforced, but implementations (in the text above) have been advised to build with this in mind. As to the concerns about the location URI itself, as stated in the document here (in Section 3.), it MUST NOT have any user identifying information in the URI user-part/string itself. The location URI Polk Expires January 13, 2010 [Page 11] Internet-Draft Geopriv DHCP Location URI Option July 2009 also needs to be hard to guess that it belongs to a specific user. There is some debate as to whether this location URI need be a random alphanumeric string or just unique. If the latter, there is some debate as to the how we define unique. Is that through space and time, as RFC 3261 defines a SIP Call-ID needs to be (meaning: never a duplicate, ever, by any device, ever)? Or is it unique to within a specific domain for as long as it is actively assigned to a client (plus some interval). When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks therein. 6. Acknowledgements Thanks to James Winterbottom, Marc Linsner, Roger Marshall and Robert Sparks for their useful comments. And to Lisa Dusseault for her concerns about the types of URIs that can cause harm. To Richard Barnes for inspiring a more robust Security Considerations section. To Hannes Tschofenig and Ted Hardie for riding me to comply with their concerns. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002 Polk Expires January 13, 2010 [Page 12] Internet-Draft Geopriv DHCP Location URI Option July 2009 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 7.2. Informative References [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in progress", July 2009 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, November 2006 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference Mechanism", "work in progress", Feb 2009 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", "work in progress", Feb 2009 [ID-GEO-RA] J. Peterson, T. Hardie, J. Morris, " Implications of 'retransmission-allowed' for SIP Location Conveyance", "work in progress", March 2009 Authors' Address James Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Email: jmpolk@cisco.com Polk Expires January 13, 2010 [Page 13]