draft-ietf-geopriv-l7-lcp-ps-08.txt   draft-ietf-geopriv-l7-lcp-ps-09.txt 
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: December 31, 2008 Columbia University Expires: August 25, 2009 Columbia University
June 29, 2008 February 21, 2009
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements Requirements
draft-ietf-geopriv-l7-lcp-ps-08.txt draft-ietf-geopriv-l7-lcp-ps-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2008. This Internet-Draft will expire on August 25, 2009.
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document provides a problem statement, lists requirements and This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). This protocol aims to allow an end host to obtain Protocol L7 (LCP). This protocol aims to allow an end host to obtain
location information, by value or by reference, from a Location location information, by value or by reference, from a Location
Information Server (LIS) that is located in the access network. The Information Server (LIS) that is located in the access network. The
obtained location information can then be used for a variety of obtained location information can then be used for a variety of
different protocols and purposes. For example, it can be used as different protocols and purposes. For example, it can be used as
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5
3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
4. Discovery of the Location Information Server . . . . . . . . . 11 4. Discovery of the Location Information Server . . . . . . . . . 11
5. Identifier for Location Determination . . . . . . . . . . . . 13 5. Identifier for Location Determination . . . . . . . . . . . . 13
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
This document provides a problem statement, lists requirements and This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). The protocol has two purposes: Protocol L7 (LCP). The protocol has two purposes:
o It is used to obtain location information (referred as "Location o It is used to obtain location information (referred as "Location
by Value" or LbyV) from a dedicated node, called the Location by Value" or LbyV) from a dedicated node, called the Location
Information Server (LIS). Information Server (LIS).
skipping to change at page 3, line 25 skipping to change at page 3, line 25
o It enables the Target to obtain a reference to location o It enables the Target to obtain a reference to location
information (referred as "Location by Reference" or LbyR). This information (referred as "Location by Reference" or LbyR). This
reference can take the form of a subscription URI, such as a SIP reference can take the form of a subscription URI, such as a SIP
presence URI, a HTTP/HTTPS URI, or another URI. The requirements presence URI, a HTTP/HTTPS URI, or another URI. The requirements
related to the task of obtaining a LbyR are described in a related to the task of obtaining a LbyR are described in a
separate document, see [4]. separate document, see [4].
The need for these two functions can be derived from the scenarios The need for these two functions can be derived from the scenarios
presented in Section 3. presented in Section 3.
For this document we assume that the GEOPRIV Layer 7 LCP runs between For this document we assume that the Geopriv Layer 7 LCP runs between
the end host (i.e., the Target in [1] terminology) and the LIS. the end host (i.e., the Target in [1] terminology) and the LIS.
This document is structured as follows. Section 4 discusses the This document is structured as follows. Section 4 discusses the
challenge of discovering the LIS in the access network. Section 5 challenge of discovering the LIS in the access network. Section 5
compares different types of identifiers that can be used to retrieve compares different types of identifiers that can be used to retrieve
location information. A list of requirements for the L7 LCP can be location information. A list of requirements for the L7 LCP can be
found in Section 6. found in Section 6.
This document does not describe how the access network provider This document does not describe how the access network provider
determines the location of the end host since this is largely a determines the location of the end host since this is largely a
matter of the capabilities of specific link layer technologies or matter of the capabilities of specific link layer technologies or
certain deployment environments. certain deployment environments.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], and "OPTIONAL" are to be interpreted as described in RFC 2119 [2],
with the qualification that unless otherwise stated these words apply with the qualification that unless otherwise stated these words apply
to the design of the GEOPRIV Layer 7 Location Configuration Protocol. to the design of the Geopriv Layer 7 Location Configuration Protocol.
The term Location Information Server (LIS) refers to an entity The term Location Information Server (LIS) refers to an entity
capable of determining the location of a Target and of providing that capable of determining the location of a Target and of providing that
location information, a reference to it, or both via the Location location information, a reference to it, or both via the Location
Configuration Protocol (LCP) to the requesting party. In most cases Configuration Protocol (LCP) to the requesting party. In most cases
the requesting party is the Target itself but it may also be an the requesting party is the Target itself but it may also be an
authorized entity that acts on behalf of it, such as a SIP proxy or authorized entity that acts on behalf of it, such as a SIP proxy or
another LIS. another LIS.
This document also uses terminology from [1] (such as Target) and [3] This document also uses terminology from [1] (such as Target) and [3]
skipping to change at page 11, line 7 skipping to change at page 11, line 7
| |
+------+ +------+
| End | | End |
| Host | | Host |
+------+ +------+
Figure 3: Wireless Access Scenario Figure 3: Wireless Access Scenario
4. Discovery of the Location Information Server 4. Discovery of the Location Information Server
Note that this section lists mechanisms that were discussed as
part of the work on the Geopriv Layer 7 Location Configuration
Protocol design team. They are included to show challenges in the
problem space and are listed for completeness reasons. They do
not in any way mean that their is consensus that any of these
approaches are good or bad or that the IETF is in any recommended
in this document that any of these be used.
When a Target wants to retrieve location information from the LIS it When a Target wants to retrieve location information from the LIS it
first needs to discover it. Based on the problem statement of first needs to discover it. Based on the problem statement of
determining the location of the Target, which is known best by determining the location of the Target, which is known best by
entities close to the Target itself, we assume that the LIS is entities close to the Target itself, we assume that the LIS is
located in the local subnet or in access network. Several procedures located in the local subnet or in access network. Several procedures
have been investigated that aim to discover the LIS in such an access have been investigated that aim to discover the LIS in such an access
network. network.
DHCP-based Discovery: DHCP-based Discovery:
skipping to change at page 11, line 36 skipping to change at page 11, line 44
Before a DNS lookup can be started it is necessary to learn the Before a DNS lookup can be started it is necessary to learn the
domain name of the access network that runs a LIS. Several ways domain name of the access network that runs a LIS. Several ways
to learn the domain name exist. For example, the end host obtains to learn the domain name exist. For example, the end host obtains
its own public IP address, for example via STUN [6], and performs its own public IP address, for example via STUN [6], and performs
a reverse DNS lookup (assuming the data is provisioned into the a reverse DNS lookup (assuming the data is provisioned into the
DNS). Then, the SRV or NAPTR record for that domain is retrieved. DNS). Then, the SRV or NAPTR record for that domain is retrieved.
A more detailed description of this approach can be found in [7]. A more detailed description of this approach can be found in [7].
Redirect Rule: Redirect Rule:
A redirect rule at a device in the access network, for example at A redirect rule at a device in the access network could be used to
the AAA client, could be used to redirect the L7 LCP signalling redirect the L7 LCP signalling messages (destined to a specific
messages (destined to a specific port) to the LIS. The end host port) to the LIS. The end host could then discover the LIS by
could then discover the LIS by sending a packet with a specific sending a packet with a specific (registered) port number to
(registered) port number to almost any address (as long as the almost any address (as long as the destination IP address does not
destination IP address does not target a device in the local target a device in the local network). The packet would be
network). The packet would be redirected to the respective LIS redirected to the respective LIS being configured. The same
being configured. The same procedure is used by captive portals procedure is used by captive portals whereby any HTTP traffic is
whereby any HTTP traffic is intercepted and redirected. intercepted and redirected.
To some extend this approach is similar to packets that are marked To some extend this approach is similar to packets that are marked
with a Router Alert option [8] and intercepted by entities that with a Router Alert option [8] and intercepted by entities that
understand the specific marking. In the above-mentioned case, understand the specific marking. In the above-mentioned case,
however, the marking is provided via a registered port number however, the marking is provided via a registered port number
instead of relying on a Router Alert option. instead of relying on a Router Alert option.
This solution approach would require a deep packet inspection
capability at an entity in the access providers networks that
scans for the occurrence of particular destination port numbers.
Multicast Query: Multicast Query:
An end node could also discover a LIS by sending a DNS query to a An end node could also discover a LIS by sending a DNS query to a
well-known address. An example of such a mechanism is multicast well-known address. An example of such a mechanism is multicast
DNS (see [9] and [10]). Unfortunately, these mechanisms only work DNS (see [9] and [10]). Unfortunately, these mechanisms only work
on the local link. on the local link.
Anycast: Anycast:
With this solution an anycast address is defined (for IPv4 and With this solution an anycast address is defined (for IPv4 and
skipping to change at page 13, line 7 skipping to change at page 13, line 7
Teredo server discovery approach outlined in Section 4.2 of [12]. Teredo server discovery approach outlined in Section 4.2 of [12].
The LIS discovery procedure raises deployment and security issues. The LIS discovery procedure raises deployment and security issues.
The access network needs to be designed to prevent man-in-the-middle The access network needs to be designed to prevent man-in-the-middle
adversaries from presenting themselves as a LIS to end hosts. When adversaries from presenting themselves as a LIS to end hosts. When
an end host discovers a LIS, it needs to ensure (and be able to an end host discovers a LIS, it needs to ensure (and be able to
ensure) that the discovered entity is indeed an authorized LIS. ensure) that the discovered entity is indeed an authorized LIS.
5. Identifier for Location Determination 5. Identifier for Location Determination
Note that this section lists mechanisms that were discussed as
part of the work in the Geopriv Layer 7 Location Configuration
Protocol design team. They are included to show challenges in the
problem space and are listed for completeness reasons. They do
not in any way mean that their is consensus that any of these
approaches are good or bad or that the IETF is in any recommended
in this document that any of these be used.
The LIS returns location information to the end host when it receives The LIS returns location information to the end host when it receives
a request. Some form of identifier is therefore needed to allow the a request. Some form of identifier is therefore needed to allow the
LIS to retrieve the Target's current location (or a good LIS to retrieve the Target's current location (or a good
approximation of it) from a database. approximation of it) from a database.
The chosen identifier needs to have the following properties: The chosen identifier needs to have the following properties:
Ability for Target to learn or know the identifier: Ability for Target to learn or know the identifier:
The Target MUST know or MUST be able to learn the identifier The Target MUST know or MUST be able to learn the identifier
skipping to change at page 18, line 7 skipping to change at page 19, line 7
Requirement L7-10: PIDF-LO Creation Requirement L7-10: PIDF-LO Creation
When a LIS creates a PIDF-LO [20] then it MUST put the <geopriv> When a LIS creates a PIDF-LO [20] then it MUST put the <geopriv>
element into the <device> element of the presence document (see element into the <device> element of the presence document (see
[21]). This ensures that the resulting PIDF-LO document, which is [21]). This ensures that the resulting PIDF-LO document, which is
subsequently distributed to other entities, conforms to the rules subsequently distributed to other entities, conforms to the rules
outlined in [22]. outlined in [22].
7. Security Considerations 7. Security Considerations
This document contains security related requirements. A discussion By using a Geolocation L7 Location Configuration Protocol, the client
about security aspects of the HELD protocol when used in the GEOPRIV expose themselves to a privacy risk whereby an unauthorized entity
architecture when applied to certain usage environments, such as receives location information. The provision of confidentiality
emergency services, can be found in [23]. protected location to the requestor depends on the success of four
steps:
1. The client must have a means to discover a LIS.
2. The client must authenticate the discovered LIS.
3. The LIS must be able to determine location and return it to the
authorized entity.
4. The LIS must securely exchange messages without intermedaries
eavesdropping or tampering them.
This document contains various security related requirements
throughout the document addressing the above-mentioned steps. For a
broader security discussion of the overall geolocation privacy
architecture the reader is referred to [23].
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Contributors 9. Contributors
This contribution is a joint effort of the GEOPRIV Layer 7 Location This contribution is a joint effort of the Geopriv Layer 7 Location
Configuration Requirements Design Team of the IETF GEOPRIV Working Configuration Requirements Design Team of the IETF GEOPRIV Working
Group. The contributors include Henning Schulzrinne, Barbara Stark, Group. The contributors include Henning Schulzrinne, Barbara Stark,
Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson,
Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig.
We would like to thank the GEOPRIV working group chairs, Andy Newton, We would like to thank the GEOPRIV working group chairs, Andy Newton,
Randy Gellens and Allison Mankin, for creating the design team. Randy Gellens and Allison Mankin, for creating the design team.
Furthermore, we would like thank Andy Newton for his support during
the design team mailing list, for setting up Jabber chat conferences
and for participating in the phone conference discussions.
The design team members can be reached at: The design team members can be reached at:
Marc Linsner: mlinsner@cisco.com Marc Linsner: mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com Rohan Mahy: rohan@ekabal.com
Andrew Newton: andy@hxr.us Andrew Newton: andy@hxr.us
Jon Peterson: jon.peterson@neustar.biz Jon Peterson: jon.peterson@neustar.biz
skipping to change at page 21, line 7 skipping to change at page 22, line 7
Barbara Stark: Barbara.Stark@bellsouth.com Barbara Stark: Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com Martin Thomson: Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@nsn.com Hannes Tschofenig: Hannes.Tschofenig@nsn.com
James Winterbottom: James.Winterbottom@andrew.com James Winterbottom: James.Winterbottom@andrew.com
10. Acknowledgements 10. Acknowledgements
We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating this design
team. Furthermore, we would like thank Andy Newton for his support
during the design team mailing list, for setting up Jabber chat
conferences and for participating in the phone conference
discussions.
We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin
Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl,
Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard,
Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara
Stark, Michael Haberler, and Mary Barnes for their WGLC review Stark, Michael Haberler, and Mary Barnes for their WGLC review
comments. comments.
The authors would like to thank NENA for their work on [24] as it The authors would like to thank NENA for their work on [24] as it
helped to provide some of the initial thinking. helped to provide some of the initial thinking.
The authors would also like to thank Cullen Jennings for his feedback
as part of the IESG processing.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
11.2. Informative References 11.2. Informative References
[4] Marshall, R., "Requirements for a Location-by-Reference [4] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work in Mechanism", draft-ietf-geopriv-lbyr-requirements-05 (work in
progress), February 2008. progress), November 2008.
[5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work
in progress), November 2007. in progress), November 2007.
[6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[7] Thomson, M. and J. Winterbottom, "Discovering the Local [7] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-03 (work in progress), draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007. September 2007.
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast [9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
Name Resolution (LLMNR)", RFC 4795, January 2007. Name Resolution (LLMNR)", RFC 4795, January 2007.
[10] Cheshire, S. and M. Krochmal, "Multicast DNS", [10] Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-06 (work in progress), draft-cheshire-dnsext-multicastdns-07 (work in progress),
August 2006. September 2008.
[11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[12] Ward, N., "Teredo Server Selection", [12] Ward, N., "Teredo Server Selection",
draft-nward-v6ops-teredo-server-selection-00 (work in draft-nward-v6ops-teredo-server-selection-00 (work in
progress), July 2007. progress), July 2007.
[13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", draft-ietf-hip-base-10 (work in "Host Identity Protocol", draft-ietf-hip-base-10 (work in
skipping to change at page 23, line 29 skipping to change at page 24, line 29
[17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 3588, September 2003.
[18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers [18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
for Dynamic Host Configuration Protocol Version Four (DHCPv4)", for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006. RFC 4361, February 2006.
[19] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ [19] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/
Firewall NSIS Signaling Layer Protocol (NSLP)", Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-18 (work in progress), draft-ietf-nsis-nslp-natfw-20 (work in progress),
February 2008. November 2008.
[20] Peterson, J., "A Presence-based GEOPRIV Location Object [20] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[21] Rosenberg, J., "A Data Model for Presence", RFC 4479, [21] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006. July 2006.
[22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work
in progress), February 2008. in progress), November 2008.
[23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, [23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne,
"Security Requirements for the Geopriv Location System", "Additional Location Privacy Considerations",
draft-barnes-geopriv-lo-sec-02 (work in progress), draft-barnes-geopriv-lo-sec-04 (work in progress),
February 2008. January 2009.
[24] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA [24] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA
Recommended Method(s) for Location Determination to Support IP- Recommended Method(s) for Location Determination to Support IP-
Based Emergency Services - Technical Information Document Based Emergency Services - Technical Information Document
(TID)", PDF NENA 08-505, December 2006. (TID)", PDF NENA 08-505, December 2006.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
skipping to change at page 25, line 4 skipping to change at line 844
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 22 change blocks. 
52 lines changed or deleted 96 lines changed or added

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