< draft-ietf-geopriv-lbyr-requirements-08.txt   draft-ietf-geopriv-lbyr-requirements-09.txt >
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational September 2, 2009 Intended status: Informational November 9, 2009
Expires: March 6, 2010 Expires: May 13, 2010
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-08 draft-ietf-geopriv-lbyr-requirements-09
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.
Abstract
This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location Uniform Resource
Identifier (URI) to handle location information within signaling and
other Internet messaging.
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 to IETF 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), 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.
skipping to change at page 1, line 32 skipping to change at page 3, line 33
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 March 6, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
This document may contain material from IETF Documents or IETF include Simplified BSD License text as described in Section 4.e of
Contributions published or made publicly available before November the Trust Legal Provisions and are provided without warranty as
10, 2008. The person(s) controlling the copyright in some of this described in the BSD License.
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.
Abstract
This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location Uniform Resource
Identifier (URI) to handle location information within signaling and
other Internet messaging.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 9
3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9 3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 10
3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9 3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 10
3.3. Location URI Authorization . . . . . . . . . . . . . . . . 10 3.3. Location URI Authorization . . . . . . . . . . . . . . . . 11
3.4. Location URI Construction . . . . . . . . . . . . . . . . 10 3.4. Location URI Construction . . . . . . . . . . . . . . . . 11
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 13
4.1. Requirements for a Location Configuration Protocol . . . . 12 4.1. Requirements for a Location Configuration Protocol . . . . 13
4.2. Requirements for a Location Dereference Protocol . . . . . 14 4.2. Requirements for a Location Dereference Protocol . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
All location-based services rely on ready access to location All location-based services rely on ready access to location
information. Using location information can be done one of two ways, information. Using location information can be done one of two ways,
either in a direct, Location-by-Value (LbyV) approach, or using an either in a direct, Location-by-Value (LbyV) approach, or using an
indirect, Location-by-Reference (LbyR) model. indirect, Location-by-Reference (LbyR) model.
For LbyV, location information is conveyed directly in the form of a For LbyV, location information is conveyed directly in the form of a
Presence Information Data Format-Location Object (PIDF-LO) Presence Information Data Format-Location Object (PIDF-LO)
([RFC4119]). Using LbyV might either be infeasible or undesirable in ([RFC4119]). Using LbyV might either be infeasible or undesirable in
some circumstances. There are cases where LbyR is better able to some circumstances. There are cases where LbyR is better able to
address location requirements for a specific architecture or address location requirements for a specific architecture or
application. This document provides a list of requirements for use application. This document provides a list of requirements for use
with the LbyR approach, and leaves the LbyV model explicitly out of with the LbyR approach, and leaves the LbyV model explicitly out of
scope. scope.
As justification for a LbyR model, consider the circumstance that in As justification for a LbyR model, consider the circumstance that in
some mobile networks it is not efficient for the end host to some mobile networks it is not efficient for the end host to
periodically query the Location Information Server (LIS) for up-to- periodically query the Location Information Server (LIS) for up-to-
date location information. This is especially the case when ower date location information. This is especially the case when power
availability is a constraint or when a location update is not availability is a constraint or when a location update is not
immediately needed. Furthermore, the end host might want to delegate immediately needed. Furthermore, the end host might want to delegate
the task of retrieving and publishing location information to a third the task of retrieving and publishing location information to a third
party, such as to a presence server. Additionally, in some party, such as to a presence server. Additionally, in some
deployments, the network operator may not want to make location deployments, the network operator may not want to make location
information widely available. These kinds of location scenarios form information widely available. These kinds of location scenarios form
the basis of motivation for the LbyR model. the basis of motivation for the LbyR model.
The concept of an LbyR mechanism is simple. An LbyR is made up of a The concept of an LbyR mechanism is simple. An LbyR is made up of a
URI scheme, a domain and a randomized component. This combination of URI scheme, a domain and a randomized component. This combination of
skipping to change at page 5, line 31 skipping to change at page 6, line 31
4. Dereference of a location URI, a request/response between a 4. Dereference of a location URI, a request/response between a
client having a location URI and a location server holding the client having a location URI and a location server holding the
location information that the location URI references. location information that the location URI references.
5. Termination of a location URI, either due to expiration or 5. Termination of a location URI, either due to expiration or
cancellation within a location server, and which is based on a Target cancellation within a location server, and which is based on a Target
cancellation request or some other action, such as timer cancellation request or some other action, such as timer
expiration. expiration.
Note that this document makes no differentiation between a Location Note that this document makes no functional differentiation between a
Server (LS), per [RFC3693], and a Location Information Server (LIS), Location Server (LS), per [RFC3693], and a Location Information
as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may refer to either of Server (LIS), as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may
them as a location server interchangeably. refer to either of them as a location server interchangeably.
Location determination, different than location configuration or Location determination, as distinct from location configuration or
dereferencing, often includes topics related to manual provisioning dereferencing, often includes topics related to manual provisioning
processes, automated location calculations based on a variety of processes, automated location calculations based on a variety of
measurement techniques, and/or location transformations, (e.g., geo- measurement techniques, and/or location transformations, (e.g., geo-
coding), and is beyond the scope of this document. coding), and is beyond the scope of this document.
Location Conveyance for either LbyR or LbyV, as defined within SIP Location Conveyance for either LbyR or LbyV, as defined within SIP
signaling is considered out of scope for this document (see signaling is considered out of scope for this document (see
[I-D.ietf-sip-location-conveyance] for an explanation of location [I-D.ietf-sip-location-conveyance] for an explanation of location
conveyance for either LbyR or LbyV scenarios.) conveyance for either LbyR or LbyV scenarios.)
skipping to change at page 7, line 27 skipping to change at page 8, line 27
Location Object (LO). Furthermore, the following terms are defined Location Object (LO). Furthermore, the following terms are defined
in this document: in this document:
Location-by-Value (LbyV): Using location information in the form of Location-by-Value (LbyV): Using location information in the form of
a location object (LO), such as a PIDF-LO. a location object (LO), such as a PIDF-LO.
Location-by-Reference (LbyR): Representing location information Location-by-Reference (LbyR): Representing location information
indirectly using a location URI. indirectly using a location URI.
Location Configuration Protocol: A protocol that is used by a Target Location Configuration Protocol: A protocol that is used by a Target
to acquire either location or a location URI from a location to acquire either location object or a location URI from a
configuration server, based on information unique to the Target. location configuration server, based on information unique to the
Target.
Location Dereference Protocol: A protocol that is used by a client Location Dereference Protocol: A protocol that is used by a client
to query a location server, based on the location URI input and to query a location server, based on the location URI input and
which returns location information. which returns location information.
Location URI: As defined within this document, an identifier that Location URI: As defined within this document, an identifier that
serves as a reference to location information. A location URI is serves as a reference to location information. A location URI is
provided by a location server, and is later used as input by a provided by a location server, and is later used as input by a
dereference protocol to retrieve location information. dereference protocol to retrieve location information.
3. Overview of Location-by-Reference 3. Overview of Location-by-Reference
This section describes the entities and interactions involved in the This section describes the entities and interactions involved in the
LbyR model. LbyR model.
+---------+---------+ Location +-----------+ +---------+---------+ Location +-----------+
| | | Dereference | Location | | | | Dereference | Location |
| LIS - LS +---------------+ Recipient | | LIS/LS +---------------+ Recipient |
| | | Protocol | | | | | Protocol | |
+----+----+----+----+ (3) +-----+-----+ +----+----+----+----+ (3) +-----+-----+
| * | | * |
| Policy * | | Policy * |
Location | Exchange * | Location | Exchange * |
Configuration | (*) * | Location Configuration | (*) * | Location
Protocol | +----+----+ | Conveyance Protocol | +----+----+ | Conveyance
(1) | | Rule | | Protocol (1) | | Rule | | Protocol
| | Maker | | (2) | | Maker | | (2)
+----+----+ +---------+ | +----+----+ +---------+ |
skipping to change at page 10, line 19 skipping to change at page 11, line 19
requested via a location configuration protocol. The process of requested via a location configuration protocol. The process of
dereferencing location URIs will be influenced by the specific dereferencing location URIs will be influenced by the specific
authorization model applied by the Location Information Server and authorization model applied by the Location Information Server and
the URI scheme that indicates the protocol to be used to resolve the the URI scheme that indicates the protocol to be used to resolve the
reference to a location object. reference to a location object.
Location URIs manifest themselves in a few different forms. The Location URIs manifest themselves in a few different forms. The
different ways that a location URI can be represented is based on different ways that a location URI can be represented is based on
local policy, and are depicted in the following four scenarios. local policy, and are depicted in the following four scenarios.
1. No specific information at all: As is typical, a location URI is 1. No location information included in the URI: As is typical, a
used to get location information. However, in this case, the URI location URI is used to get location information. However, in
representation itself does not need to reveal any specific this case, the URI representation itself does not need to reveal
information at all. Location information is acquired by the any specific information at all. Location information is acquired
dereferencing operation a location URI. by the dereferencing operation using a location URI.
2. No Target specific information: By default, a location URI MUST 2. URI does not identify a Target: By default, a location URI MUST
NOT reveal any information about the Target other than location NOT reveal any information about the Target other than location
information. This is true for the URI itself, (or in the document information. This is true for the URI itself, (or in the document
acquired by dereferencing), unless policy explicitly permits acquired by dereferencing), unless policy explicitly permits
otherwise. otherwise.
3. Access control authorization model: If the "access control 3. Access control authorization model: If the "access control
authorization model" is used, the location URI MUST NOT include authorization model" is used, the location URI MUST NOT include
any location information in its representation. Location URIs any location information in its representation. Location URIs
operating under this model could be widely published to recipients operating under this model could be widely published to recipients
that are not authorized to receive this information. that are not authorized to receive this information.
skipping to change at page 10, line 49 skipping to change at page 11, line 49
confidential information shared between the LIS/LS, the Target and confidential information shared between the LIS/LS, the Target and
all authorized Location Recipients. In this case, possession all authorized Location Recipients. In this case, possession
implies authorization. Because knowledge of the location URI is implies authorization. Because knowledge of the location URI is
used to authenticate and authorize access to location information, used to authenticate and authorize access to location information,
the URI needs to include sufficient randomness to make guessing the URI needs to include sufficient randomness to make guessing
its value difficult. A possession model URI can include location its value difficult. A possession model URI can include location
information in its representation. information in its representation.
3.4. Location URI Construction 3.4. Location URI Construction
Depending on local policy, a location URI may be constructed in such Given scenarios 2 and 4, above, and depending on local policy, a
a way as to make it difficult to guess. Accordingly, the form of the location URI may be constructed in such a way as to make it difficult
URI is then constrained by the degree of randomness and uniqueness to guess. Accordingly, the form of the URI is then constrained by
applied to it. In this case, it may be important to protect the the degree of randomness and uniqueness applied to it. In this case,
actual location information from inspection by an intermediate node. it may be important to protect the actual location information from
Construction of a location URI in such a way as to not reveal any inspection by an intermediate node. Construction of a location URI
Target specific, (e.g., user or device), information, with the goal in such a way as to not reveal any Target specific, (e.g., user or
of making the location URI appear bland, uninteresting, and generic, device), information, with the goal of making the location URI appear
may be helpful to some degree in order to keep location information bland, uninteresting, and generic, may be helpful to some degree in
more difficult to detect. Thus, obfuscating the location URI in this order to keep location information more difficult to detect. Thus,
way may provide some level of safeguard against the undetected obfuscating the location URI in this way may provide some level of
stripping off of what would otherwise be evident location safeguard against the undetected stripping off of what would
information, since it forces a dereference operation at the location otherwise be evident location information, since it forces a
dereference server, an important step for the purpose of providing dereference operation at the location dereference server, an
statistics, audit trails, and general logging for many different important step for the purpose of providing statistics, audit trails,
kinds of location based services. and general logging for many different kinds of location based
services.
4. High-Level Requirements 4. High-Level Requirements
This document outlines the requirements for an Location by Reference This document outlines the requirements for an Location by Reference
mechanism which can be used by a number of underlying protocols. mechanism which can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location general location configuration protocol, and a general location
dereferencing protocol. dereferencing protocol.
The requirements are broken into two sections. The requirements are broken into two sections.
skipping to change at page 12, line 40 skipping to change at page 13, line 40
Motivation: A location URI may not intend to represent a location Motivation: A location URI may not intend to represent a location
forever, and the identifier eventually may need to be recycled, or forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is location reference fails to yield a location, or the location is
determined to be kept confidential. determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol C3. Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific MUST support the ability to request a cancellation of a specific
location URI. location URI.
Motivation: If the Target determines that in its best interest to Motivation: If the Target determines that a location URI should no
destroy the ability for a location URI to effectively be used to longer be used to dereference a location, then there should be a
dereference a location, then there should be a way to nullify the way to request that the location URI be nullified."
location URI.
C4. Location Information Masking: The location URI MUST, through C4. Location Information Masking: The location URI MUST ensure, by
randomization and uniqueness, ensure that the location URI does default, through randomization and uniqueness, that the location
not contain location information specific components. URI does not contain location information specific components.
Motivation: It is important to keep any location information Motivation: It is important to keep any location information
masked from a casual observing node. masked from a casual observing node.
C5. Target Identity Protection: The location URI MUST NOT contain C5. Target Identity Protection: The location URI MUST NOT contain
information that identifies the Target (e.g., user or device). information that identifies the Target (e.g., user or device).
Examples include phone extensions, badge numbers, first or last Examples include phone extensions, badge numbers, first or last
names. names.
Motivation: It is important to protect caller identity or contact Motivation: It is important to protect caller identity or contact
skipping to change at page 13, line 22 skipping to change at page 14, line 22
when it is generated. when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a Target to C6. Reuse indicator: There SHOULD be a way to allow a Target to
control whether a location URI can be resolved once only, or control whether a location URI can be resolved once only, or
multiple times. multiple times.
Motivation: The Target requesting a location URI may request a Motivation: The Target requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability. This opposed to a location URI having multiple reuse capability. This
would allow the server to return an error with or without location would allow the server to return an error with or without location
during the subsequent dereference operation. information during the subsequent dereference operation.
C7. Selective disclosure: The location configuration protocol MUST C7. Selective disclosure: The location configuration protocol MUST
provide a mechanism to control what information is being disclosed provide a mechanism that allows the Rule Maker to control what
about the Target. information is being disclosed about the Target.
Motivation: The Rule Maker has to be in control of how much Motivation: The Rule Maker has to be in control of how much
information is revealed during the dereferencing step as part of information is revealed during the dereferencing step as part of
the privacy features. the privacy features.
C8. Location URI Not guessable: As a default, the location C8. Location URI Not guessable: As a default, the location
configuration protocol MUST return location URIs that are random configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI with and unique throughout the indicated lifetime. A location URI with
128-bits of randomness is RECOMMENDED. 128-bits of randomness is RECOMMENDED.
Motivation: Location URIs should be constructed in such a way that Motivation: Location URIs should be constructed in such a way that
an adversary cannot guess them and dereference them without having an adversary cannot guess them and dereference them without having
ever obtained them from the Target. previously obtained them from the Target.
C9. Location URI Options: In the case of user-provided authorization C9. Location URI Options: In the case of user-provided authorization
policies, where anonymous or non-guessable location URIs are not policies, where anonymous or non-guessable location URIs are not
warranted, the location configuration protocol MAY support a warranted, the location configuration protocol MAY support a
variety of optional location URI conventions, as requested by a variety of optional location URI conventions, as requested by a
Target to a location configuration server, (e.g., embedded Target to a location configuration server, (e.g., embedded
location information within the location URI). location information within the location URI).
Motivation: Users don't always have such strict privacy Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or requirements, but may opt to specify their own location URI, or
skipping to change at page 14, line 15 skipping to change at page 15, line 15
4.2. Requirements for a Location Dereference Protocol 4.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location location-by-reference mechanism as used within the location
dereference protocol. dereference protocol.
D1. Location URI support: The location dereference protocol MUST D1. Location URI support: The location dereference protocol MUST
support a location reference in URI form. support a location reference in URI form.
Motivation: It is required that there be consistency of use Motivation: It is required that there be consistency of use
between location URI formats used in an configuration protocol and between location URI formats used in a configuration protocol and
those used by a dereference protocol. those used by a dereference protocol.
D2. Authentication: The location dereference protocol MUST include D2. Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server. mechanisms to authenticate both the client and the server.
Motivation: Although the implementations must support Motivation: Although the implementations must support
authentication of both parties, any given transaction has the authentication of both parties, any given transaction has the
option not to authenticate one or both parties. option not to authenticate one or both parties.
D3. Dereferenced Location Form: The value returned by the D3. Dereferenced Location Form: The value returned by the
skipping to change at page 15, line 13 skipping to change at page 16, line 13
HTTPS URI scheme. HTTPS URI scheme.
5. Security Considerations 5. Security Considerations
The method of constructing the location URI to include randomized The method of constructing the location URI to include randomized
components helps to prevent adversaries from obtaining location components helps to prevent adversaries from obtaining location
information without ever retrieving a location URI. In the information without ever retrieving a location URI. In the
possession model, a location URI, regardless of its construction, if possession model, a location URI, regardless of its construction, if
made publically available, implies no safeguard against anyone being made publically available, implies no safeguard against anyone being
able to dereference and get the location. Care has to be paid when able to dereference and get the location. Care has to be paid when
distribution such a location URI to the trusted location recipients. distributing such a location URI to the trusted location recipients.
When this aspect is of concern then the authorization model has to be When this aspect is of concern then the authorization model has to be
chosen. Even in this model care has to be taken on how to construct chosen. Even in this model care has to be taken on how to construct
the authorization policies to ensure that only those parties have the authorization policies to ensure that only those parties have
access to location information that are considered trustworthy enough access to location information that are considered trustworthy enough
to enforce the basic rule set that is attached to location to enforce the basic rule set that is attached to location
information in a PIDF-LO document. information in a PIDF-LO document.
Any location URI, by necessity, indicates the server (name) that Any location URI, by necessity, indicates the server (name) that
hosts the location information. Knowledge of the server in some hosts the location information. Knowledge of the server in some
specific domain could therefore reveal something about the location specific domain could therefore reveal something about the location
skipping to change at page 18, line 16 skipping to change at page 19, line 16
8.1. Normative References 8.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.
8.2. Informative References 8.2. Informative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource and IPv6 Option for a Location Uniform Resource Identifier
Identifier (URI)", (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-06 (work
draft-ietf-geopriv-dhcp-lbyr-uri-option-05 (work in in progress), September 2009.
progress), July 2009.
[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] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009. progress), July 2009.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R., Rosen, B., and H. Tschofenig, "A Document Format Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
for Filtering and Reporting Location Notications in the Location Notifications in the Session Initiation Protocol
Presence Information Document Format Location Object (SIP)", draft-ietf-geopriv-loc-filters-08 (work in
(PIDF-LO)", draft-ietf-geopriv-loc-filters-05 (work in progress), November 2009.
progress), July 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
Appendix A. Change log Appendix A. Change log
Changes to this draft in comparison to the previous version (-09 vs.
-08), as part of the IESG review process:
1. clarification of missing text, Introduction, (from Alexey
Melnikov), change from: "ower", to "power" (as appropriate) text now
reads, "This is especially the case when power availability is a
constraint"
2. clarify text, Introduction, (from Spencer Dawkins, 06/03/2009),
change from: "Location determination, different than location
configuration" change to: "Location determination, as distinct from
location configuration"
3. insert text, Terminology section, (from Spencer Dawkins, 06/03/
2009), change from: "to acquire either location or a location URI"
change to: "to acquire either location object or a location URI"
4. reword, section 3.3. Location URI Authorization, (from Spencer
Dawkins, 06/03/2009), change from: "1. No specific information at
all:" change to: "1. No location information included in the URI:"
5. rephrase, (overlay new term), section 3.3. Location URI
Authorization, (from Spencer Dawkins, 06/03/2009), Change from: "2.
No Target specific information:" Change to: "2. URI does not
identify a Target:"
6. Add text ahead of paragraph, section titled, "Location URI
Construction", (from Spencer Dawkins, 06/03/2009), change from:
"Depending on local policy," change to: "Given scenarios 2 and 4,
above, and depending on local policy"
7. reword Motivation text, req. C3, (from Spencer Dawkins, 06/03/
2009), change from: "Motivation: If the Target determines that in its
best interest to destroy the ability for a location URI to
effectively be used to dereference a location, then there should be a
way to nullify the location URI." change to: "Motivation: If the
Target determines that a location URI should no longer be used to
dereference a location, then there should be a way to request that
the location URI be nullified."
8. reword requirement C7, (from Spencer Dawkins, 06/03/2009), "C7.
Selective disclosure: The location configuration protocol MUST
provide a mechanism to control what information is being disclosed
about the Target." Change to: "C7. Selective disclosure: The
location configuration protocol MUST provide a mechanism that allows
the Rule Maker to control what information is being disclosed about
the Target."
9. replace text s/ever/previously, (from Spencer Dawkins, 06/03/
2009), change from: "Motivation: Location URIs should be constructed
in such a way that an adversary cannot guess them and dereference
them without having ever obtained them from the Target." change to:
"Motivation: Location URIs should be constructed in such a way that
an adversary cannot guess them and dereference them without having
previously obtained them from the Target."
10. minor fix, section 4.2, D1., s/in an/in a/1 (from Spencer
Dawkins, 06/03/2009),
11. minor fix, section 5. Security Considerations, (from Spencer
Dawkins, 06/03/2009), change from: "when distribution such" change
to: "when distributing such"
12. qualifying text inserted, req. C4 (from Tin Tsou, Ops Review 10/
21/2009) change from: "The location URI MUST, through randomization
and uniqueness, ensure that the location URI does not contain
location information specific components. change to: "The location
URI MUST ensure, by default, through randomization and uniqueness,
that the location URI does not contain location information specific
components.
13. resolve comments from Tina Tsou relating to C4 vs. C9
compatibility,
14. resolve comments from Lisa Dusseault relating to LIS/LS
references and note
Changes to this draft in comparison to the previous version (-08 vs. Changes to this draft in comparison to the previous version (-08 vs.
-07), as part of the IESG review process: -07), as part of the IESG review process:
1. changes sent 09/02/2009 based on IESG Security comments from 1. changes sent 09/02/2009 based on IESG Security comments from
Hilarie Orman, 06/08/2009. Hilarie Orman, 06/08/2009.
2. changes sent 09/02/2009 based on Operational Directorate comments 2. changes sent 09/02/2009 based on Operational Directorate comments
from Hannes Tschofenig, 06/11/2009. from Hannes Tschofenig, 06/11/2009.
Changes to this draft in comparison to the previous version (-07 vs. Changes to this draft in comparison to the previous version (-07 vs.
 End of changes. 24 change blocks. 
97 lines changed or deleted 177 lines changed or added

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