draft-ietf-geopriv-held-identity-extensions-03.txt   draft-ietf-geopriv-held-identity-extensions-04.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation Intended status: Standards Track Andrew Corporation
Expires: August 27, 2010 H. Tschofenig Expires: December 23, 2010 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Barnes R. Barnes
BBN Technologies BBN Technologies
February 23, 2010 June 21, 2010
Use of Device Identity in HTTP-Enabled Location Delivery (HELD) Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-held-identity-extensions-03 draft-ietf-geopriv-held-identity-extensions-04
Abstract Abstract
When a Location Information Server receives a request for location When a Location Information Server receives a request for location
information (using the locationRequest message), described in the information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the base HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the source IP address of the arriving message as a pointer to the
location determination process. This is sufficient in environments location determination process. This is sufficient in environments
where the location of a Device can be determined based on its IP where the location of a Device can be determined based on its IP
address. address.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
the second, an entity other than the Device requests the location of the second, an entity other than the Device requests the location of
the Device. the Device.
This document extends the HELD protocol to allow the location request This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing considerations describe the conditions where requests containing
identifiers are permitted. identifiers are permitted.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 23, 2010.
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 August 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9 2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
skipping to change at page 4, line 22 skipping to change at page 4, line 22
carry the request already carry an identifier for the Device, namely carry the request already carry an identifier for the Device, namely
the source IP address of an incoming request. Existing LCPs, such as the source IP address of an incoming request. Existing LCPs, such as
HTTP-Enabled Location Delivery (HELD) HTTP-Enabled Location Delivery (HELD)
[I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825], [I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825],
[RFC4776]) rely on the source IP address or other information present [RFC4776]) rely on the source IP address or other information present
in protocol datagrams to identify a Device. in protocol datagrams to identify a Device.
Aside from the datagrams that form a request, a location information Aside from the datagrams that form a request, a location information
server (LIS) does not necessarily have access to information that server (LIS) does not necessarily have access to information that
could further identify the Device. In some circumstances, as shown could further identify the Device. In some circumstances, as shown
in [I-D.ietf-geopriv-l7-lcp-ps], additional identification in [RFC5687], additional identification information can be included
information can be included in a request to identify a Device. in a request to identify a Device.
This document extends the HELD protocol to support the inclusion of This document extends the HELD protocol to support the inclusion of
additional identifiers for the Device in HELD location requests. An additional identifiers for the Device in HELD location requests. An
XML schema is defined that provides a structure for including these XML schema is defined that provides a structure for including these
identifiers in HELD requests. identifiers in HELD requests.
An important characteristic of this addition is that the HELD An important characteristic of this addition is that the HELD
protocol with identity extensions implemented is not considered an protocol with identity extensions implemented is not considered an
LCP. The scope of an LCP is limited to the interaction between a LCP. The scope of an LCP is limited to the interaction between a
Device and a LIS, and LCPs can guarantee the identity of Devices Device and a LIS, and LCPs can guarantee the identity of Devices
skipping to change at page 6, line 16 skipping to change at page 6, line 16
include how the request is authenticated and the set of include how the request is authenticated and the set of
identifiers (and types of identifiers) that the third-party is identifiers (and types of identifiers) that the third-party is
authorized to use in requests. authorized to use in requests.
Automated mechanisms to ensure privacy constraints are respected Automated mechanisms to ensure privacy constraints are respected
are possible. are possible.
1.2. Terminology 1.2. Terminology
This document uses the term Location Information Server (LIS) and This document uses the term Location Information Server (LIS) and
location configuration protocol (LCP) as described in location configuration protocol (LCP) as described in [RFC5687] and
[I-D.ietf-geopriv-l7-lcp-ps] and [I-D.ietf-geopriv-arch]. [I-D.ietf-geopriv-arch].
The term Device is used specifically as the subject of an LCP, The term Device is used specifically as the subject of an LCP,
consistent with [I-D.ietf-geopriv-http-location-delivery]. This consistent with [I-D.ietf-geopriv-http-location-delivery]. This
document also uses the term Target to refer to any entity that might document also uses the term Target to refer to any entity that might
be a subject of the same location information. Target is used in a be a subject of the same location information. Target is used in a
more general sense, including the Device, but also any nearby entity, more general sense, including the Device, but also any nearby entity,
such as the user of a Device. A Target has a stake in setting such as the user of a Device. A Target has a stake in setting
authorization policy on the use of location information. Both Device authorization policy on the use of location information. Both Device
and Target are defined in [I-D.ietf-geopriv-arch]. and Target are defined in [I-D.ietf-geopriv-arch].
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Some identifiers can be either temporary or could potentially Some identifiers can be either temporary or could potentially
identify multiple Devices. Identifiers that are transient or identify multiple Devices. Identifiers that are transient or
ambiguous could be exploited by an attacker to either gain ambiguous could be exploited by an attacker to either gain
information about another Device or to coerce the LIS into producing information about another Device or to coerce the LIS into producing
misleading information. misleading information.
The identifiers described in this document MUST only be used where The identifiers described in this document MUST only be used where
that identifier is used as the basis for location determination. that identifier is used as the basis for location determination.
Considerations relating to the use of identifiers for a Device Considerations relating to the use of identifiers for a Device
requesting its own location are discussed in Section 5 of requesting its own location are discussed in Section 5 of [RFC5687];
[I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of this section discusses use of identifiers for authorized third-party
identifiers for authorized third-party requests. requests.
It is tempting for a LIS implementation to allow alternative It is tempting for a LIS implementation to allow alternative
identifiers for convenience or some other perceived benefit. The identifiers for convenience or some other perceived benefit. The
LIS is responsible for ensuring that the identifier used in the LIS is responsible for ensuring that the identifier used in the
request does not refer to a Device other than the one for which it request does not refer to a Device other than the one for which it
determines location. determines location.
Some identifiers are always uniquely attributable to a single Device. Some identifiers are always uniquely attributable to a single Device.
However, other identifiers can have a different meaning to different However, other identifiers can have a different meaning to different
entities on a network. This is especially true for IP addresses entities on a network. This is especially true for IP addresses
skipping to change at page 9, line 6 skipping to change at page 9, line 6
not be valid - it could be identifying an entity within another not be valid - it could be identifying an entity within another
address space. The LIS can be configured to reject such requests, address space. The LIS can be configured to reject such requests,
unless it knows by other means that the request is valid. unless it knows by other means that the request is valid.
In the same example, the requester might include an address from In the same example, the requester might include an address from
the external space in an attempt to identify a host within the the external space in an attempt to identify a host within the
network. The LIS could use knowledge about how the external network. The LIS could use knowledge about how the external
address is mapped to a private address, if that mapping is fixed, address is mapped to a private address, if that mapping is fixed,
to determine an appropriate response. to determine an appropriate response.
The residential gateway scenario in Section 3.1 of The residential gateway scenario in Section 3.1 of [RFC5687] is a
[I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a particular example of where a subjective view is permitted. The LIS
subjective view is permitted. The LIS knowingly provides Devices on knowingly provides Devices on the remote side of the residential
the remote side of the residential gateway with location information. gateway with location information. The LIS provides location
The LIS provides location information with appropriate uncertainty to information with appropriate uncertainty to allow for the fact that
allow for the fact that the residential gateway serves a small the residential gateway serves a small geographical area.
geographical area.
2.1.2. Transient Identifiers 2.1.2. Transient Identifiers
Some identifiers are temporary and can, over the course of time, be Some identifiers are temporary and can, over the course of time, be
assigned to different physical entities. An identifier that is assigned to different physical entities. An identifier that is
reassigned between the time that a request is formulated by a reassigned between the time that a request is formulated by a
requester and when the request is received by the LIS causes the LIS requester and when the request is received by the LIS causes the LIS
to locate a different entity than the requester intended. The to locate a different entity than the requester intended. The
response from the LIS might be accurate, but the request incorrectly response from the LIS might be accurate, but the request incorrectly
associates this information with the wrong subject. associates this information with the wrong subject.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
natural vehicle for establishing location privacy policies. natural vehicle for establishing location privacy policies.
Establishing authorization policy might be a manual process, an Establishing authorization policy might be a manual process, an
explicit part of the terms of service for the network, or an explicit part of the terms of service for the network, or an
automated system that accepts formal authorization policies (see automated system that accepts formal authorization policies (see
[RFC4745], [RFC4825]). This document does not mandate any particular [RFC4745], [RFC4825]). This document does not mandate any particular
mechanism for establishing an authorization policy. mechanism for establishing an authorization policy.
5. Security Considerations 5. Security Considerations
The security considerations in The security considerations in
[I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for [I-D.ietf-geopriv-http-location-delivery] describe the use of
server authentication, confidentiality and protection from Transport Layer Security (TLS) [RFC5246] for server authentication,
modification. These protections apply to both Target requests for confidentiality and protection from modification. These protections
their own locations and requests made by third parties. apply to both Target requests for their own locations and requests
made by third parties.
All HELD requests containing identity MUST be authenticated by the All HELD requests containing identity MUST be authenticated by the
LIS. How authentication is accomplished and what assurances are LIS. How authentication is accomplished and what assurances are
desired is a matter for policy. desired is a matter for policy.
The base HELD protocol uses return reachability of an IP address The base HELD protocol uses return reachability of an IP address
implied by the requester being able to successfully complete a TCP implied by the requester being able to successfully complete a TCP
handshake. It is RECOMMENDED that any means of authentication handshake. It is RECOMMENDED that any means of authentication
provide at least this degree of assurance. For requests that include provide at least this degree of assurance. For requests that include
Device identity, the LIS MUST support HTTP digest authentication. Device identity, the LIS MUST support HTTP digest authentication.
skipping to change at page 20, line 42 skipping to change at page 20, line 42
<xs:element name="requiredIdentifiers" type="id:qnameList"/> <xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList"> <xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/> <xs:list itemType="xs:QName"/>
</xs:simpleType> </xs:simpleType>
<xs:element name="ip" type="id:ipAddress"/> <xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress"> <xs:complexType name="ipAddress">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:token"> <xs:extension base="xs:token">
<xs:attribute name="v" use="optional"> <xs:attribute name="v" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/> <xs:pattern value="[\da-fA-F]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:element name="mac" type="id:macAddress"/> <xs:element name="mac" type="id:macAddress"/>
skipping to change at page 25, line 7 skipping to change at page 25, line 7
This section registers the "badIdentifier" error code in the "Geopriv This section registers the "badIdentifier" error code in the "Geopriv
HELD Registries, Error codes for HELD" IANA registry. HELD Registries, Error codes for HELD" IANA registry.
badIdentifier This error code indicates that a Device identifier badIdentifier This error code indicates that a Device identifier
used in the HELD request was either: not supported by the LIS, used in the HELD request was either: not supported by the LIS,
badly formatted, or not one for which the requester was authorized badly formatted, or not one for which the requester was authorized
to make a request. to make a request.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank the NENA VoIP location working group for The the NENA VoIP location working group provided assistance in the
their assistance in the definition of the schema used in this definition of the schema used in this document. Special thanks go to
document. Special thanks go to Barbara Stark, Guy Caron, Nadine Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin
Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam
on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for Muhlbauer and Eddy Corbett for providing further corrections.
providing further corrections. Bernard Aboba provided excellent Bernard Aboba provided excellent feedback on use cases and the
feedback on use cases and the security model; Bernard, along with security model; Bernard, along with Alan DeKok, also helped resolve
Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis an issue with NAIs. Ray Bellis provided motivation for the protocol
provided motivation for the protocol port parameters. Marc Linsner port parameters. Marc Linsner and Alissa Cooper provided guidance
and Alissa Cooper provided guidance and text (respectively) that and text (respectively) that greatly clarified the discussion
greatly clarified the discussion relating to LCPs. Thanks to Jon relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for
Peterson and Cullen Jennings for forcing us to be practical. forcing this to be practical.
9. References 9. References
9.1. Normative references 9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
skipping to change at page 26, line 33 skipping to change at page 26, line 33
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006. Version Four (DHCPv4)", RFC 4361, February 2006.
[I-D.ietf-idnabis-defs]
Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
draft-ietf-idnabis-defs-13 (work in progress),
January 2010.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009. progress), August 2009.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009.
[W3C.REC-xml-names11-20060816] [W3C.REC-xml-names11-20060816]
Hollander, D., Tobin, R., Bray, T., and A. Layman, Tobin, R., Hollander, D., Bray, T., and A. Layman,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web "Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816, Consortium Recommendation REC-xml-names11-20060816,
August 2006, August 2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>. <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[WiMAX-T33-110-R015v01-B] [WiMAX-T33-110-R015v01-B]
WiMAX Forum, "Protocols and Procedures for Location Based WiMAX Forum, "Protocols and Procedures for Location Based
Services", WiMAX Forum Network Architecture T33-110- Services", WiMAX Forum Network Architecture T33-110-
R015v01-B, May 2009. R015v01-B, May 2009.
9.2. Informative references 9.2. Informative references
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997. Address Behaviour Today", RFC 2101, February 1997.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-idnabis-defs] [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Klensin, J., "Internationalized Domain Names for Location Configuration Protocol: Problem Statement and
Applications (IDNA): Definitions and Document Framework", Requirements", RFC 5687, March 2010.
draft-ietf-idnabis-defs-13 (work in progress),
January 2010.
[I-D.ietf-geopriv-arch] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress), draft-ietf-geopriv-arch-02 (work in progress), May 2010.
October 2009.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-14 (work in progress), draft-ietf-ecrit-phonebcp-14 (work in progress),
January 2010. January 2010.
[I-D.thomson-geopriv-held-measurements] [I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in Location Configuration Location-Related Measurements in Location Configuration
Protocols", draft-thomson-geopriv-held-measurements-05 Protocols", draft-thomson-geopriv-held-measurements-06
(work in progress), October 2009. (work in progress), May 2010.
[TS.3GPP.23.271] [TS.3GPP.23.271]
3GPP, "Functional stage 2 description of Location Services 3GPP, "Functional stage 2 description of Location Services
(LCS)", 3GPP TS 23.271 8.0.0, December 2008. (LCS)", 3GPP TS 23.271 8.0.0, December 2008.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
Andrew Building (39) Andrew Building (39)
 End of changes. 22 change blocks. 
71 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/