draft-ietf-geopriv-policy-uri-01.txt   draft-ietf-geopriv-policy-uri-02.txt 
GEOPRIV R. Barnes GEOPRIV R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational M. Thomson Intended status: Informational M. Thomson
Expires: December 22, 2011 J. Winterbottom Expires: April 6, 2012 J. Winterbottom
Andrew Corporation Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
June 20, 2011 October 4, 2011
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-01.txt draft-ietf-geopriv-policy-uri-02.txt
Abstract Abstract
Current location configuration protocols are capable of provisioning Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's an Internet host with a location URI that refers to the host's
location. These protocols lack a mechanism for the target host to location. These protocols lack a mechanism for the target host to
inspect or set the privacy rules that are applied to the URIs they inspect or set the privacy rules that are applied to the URIs they
distribute. This document extends the current location configuration distribute. This document extends the current location configuration
protocols to provide hosts with a reference to the rules that are protocols to provide hosts with a reference to the rules that are
applied to a URI, so that the host can view or set these rules. applied to a URI, so that the host can view or set these rules.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on December 22, 2011. This Internet-Draft will expire on April 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 5 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 5
3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
4. Location Configuration Extensions . . . . . . . . . . . . . . 7 4. Location Configuration Extensions . . . . . . . . . . . . . . 7
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 8 4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.1. URN Sub-Namespace Registration for
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Integrity and Confidentiality for Authorization Policy 7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Access Control for Authorization Policy . . . . . . . . . 14 7.2. Access Control for Authorization Policy . . . . . . . . . 13
8.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
A critical step in enabling Internet hosts to access location-based A critical step in enabling Internet hosts to access location-based
services is to provision those hosts with information about their own services is to provision those hosts with information about their own
location. This is accomplished via a Location Configuration Protocol location. This is accomplished via a Location Configuration Protocol
skipping to change at page 3, line 31 skipping to change at page 3, line 31
In some cases, location by reference offers a few benefits over In some cases, location by reference offers a few benefits over
location by value. From a privacy perspective, the required location by value. From a privacy perspective, the required
dereference transaction provides a policy enforcement point, so that dereference transaction provides a policy enforcement point, so that
the opaque URI itself can be safely conveyed over untrusted media the opaque URI itself can be safely conveyed over untrusted media
(e.g., SIP through untrusted proxies [RFC5606]). If the target host (e.g., SIP through untrusted proxies [RFC5606]). If the target host
is mobile, an application provider can use a single reference to is mobile, an application provider can use a single reference to
obtain the location of the host multiple times, saving bandwidth to obtain the location of the host multiple times, saving bandwidth to
the host. For some configuration protocols, the location object the host. For some configuration protocols, the location object
referenced by a location URI provides a much more expressive syntax referenced by a location URI provides a much more expressive syntax
for location values than the configuration protocol itself (e.g., for location values than the configuration protocol itself (e.g.,
DHCP geodetic location [I-D.ietf-geopriv-rfc3825bis] versus GML in a DHCP geodetic location [RFC6225] versus GML in a PIDF-LO [RFC4119]).
PIDF-LO [RFC4119]).
From a privacy perspective, however, current LCPs are limited in From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide hosts (the clients in their flexibility, in that they do not provide hosts (the clients in
an LCP) with a way to inform the Location Server with policy for how an LCP) with a way to inform the Location Server with policy for how
his location information should be handled. This document addresses his location information should be handled. This document addresses
this gap by defining a simple mechanism for referring to and this gap by defining a simple mechanism for referring to and
manipulating policy, and by extending current LCPs to carry policy manipulating policy, and by extending current LCPs to carry policy
references. Using the mechanisms defined in this document, an LCP references. Using the mechanisms defined in this document, an LCP
server (acting for the Location Server) can inform a host as to which server (acting for the Location Server) can inform a host as to which
policy document controls a given location resource, and the host (in policy document controls a given location resource, and the host (in
skipping to change at page 5, line 32 skipping to change at page 5, line 32
A GET request to a policy URI is a request for the referenced policy A GET request to a policy URI is a request for the referenced policy
information. If the request is authorized, then the Location Server information. If the request is authorized, then the Location Server
sends an HTTP 200 response containing the complete policy identified sends an HTTP 200 response containing the complete policy identified
by the URI. by the URI.
A PUT request to a policy URI is a request to replace the current A PUT request to a policy URI is a request to replace the current
policy. The entity-body of a PUT request includes a complete policy policy. The entity-body of a PUT request includes a complete policy
document. When a Location Server receives a PUT request, it MUST document. When a Location Server receives a PUT request, it MUST
validate the policy document included in the body of the request. If validate the policy document included in the body of the request. If
the request is valid and authorized, then the Location Server the request is valid and authorized, then the Location Server MUST
replaces the current policy with the policy provided in the request. replace the current policy with the policy provided in the request.
A DELETE request to a policy URI is a request to delete the A DELETE request to a policy URI is a request to delete the
referenced policy document. If the request is authorized, then the referenced policy document. If the request is authorized, then the
Location Server MUST delete the policy referenced by the URI and Location Server MUST delete the policy referenced by the URI and
disallow access to the location URIs it governs until a new policy disallow access to the location URIs it governs until a new policy
document has been put in place via a PUT request. document has been put in place via a PUT request.
A policy URI is only valid while the corresponding location URI set A policy URI is only valid while the corresponding location URI set
is valid. A location server MUST NOT respond to any requests to a is valid. A location server MUST NOT respond to any requests to a
policy URIs once the corresponding location URI set has expired. policy URIs once the corresponding location URI set has expired.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
This usage of HTTP is generally compatible with the use of XCAP This usage of HTTP is generally compatible with the use of XCAP
[RFC4825] or WebDAV [RFC4918] to manage policy documents, but this [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this
document does not define or require the use of these protocols. document does not define or require the use of these protocols.
3.2. Policy URI Allocation 3.2. Policy URI Allocation
A Location Server creates a policy URI for a specific location A Location Server creates a policy URI for a specific location
resource at the time that the location resource is created; that is, resource at the time that the location resource is created; that is,
a policy URI is created at the same time as the location URI that it a policy URI is created at the same time as the location URI that it
controls. The URI of the policy resource MUST be different to the controls. The URI of the policy resource MUST be different from the
location URI. location URI.
A policy URI is provided in response to location configuration A policy URI is provided in response to location configuration
requests. A policy URI MUST NOT be provided to an entity that is not requests. A policy URI MUST NOT be provided to an entity that is not
authorized to view or set policy. This document does not describe authorized to view or set policy. This document does not describe
how policy might be provided to entities other than for location how policy might be provided to entities other than for location
configuration. In responses to dereferencing requests configuration, for example, in responses to dereferencing requests
[I-D.ietf-geopriv-deref-protocol] or requests from third parties [I-D.ietf-geopriv-deref-protocol] or requests from third parties
[RFC6155]. [RFC6155].
Each location URI has either one policy URI or no policy URI. The Each location URI has either one policy URI or no policy URI. The
initial policy that is referenced by a policy URI MUST be identical initial policy that is referenced by a policy URI MUST be identical
to the policy that would be applied in the absence of a policy URI. to the policy that would be applied in the absence of a policy URI.
A client that does not support policy URIs can continue to use the A client that does not support policy URIs can continue to use the
location URI as they would have if no policy URI were provided. location URI as they would have if no policy URI were provided.
For DHCP and HELD, the client assumes that the default policy For DHCP and HELD, the client assumes that the default policy
skipping to change at page 7, line 5 skipping to change at page 7, line 5
policy prior to distributing the location URI. policy prior to distributing the location URI.
A Location Server chooses whether or not to provide a policy URI A Location Server chooses whether or not to provide a policy URI
based on local policy. A HELD-specific extension also allows a based on local policy. A HELD-specific extension also allows a
requester to specifically ask for a policy URI. requester to specifically ask for a policy URI.
A policy URI is effectively a shared secret between Location Server A policy URI is effectively a shared secret between Location Server
and its clients. Knowledge of a policy URI is all that is required and its clients. Knowledge of a policy URI is all that is required
to perform any operations allowed on the policy. Thus, a policy URI to perform any operations allowed on the policy. Thus, a policy URI
should be constructed so that it is hard to predict and should be constructed so that it is hard to predict and
confidentiality-protected when transmitted (see Section 8). To avoid confidentiality-protected when transmitted (see Section 7). To avoid
re-using these shared secrets, the Location Server MUST generate a re-using these shared secrets, the Location Server MUST generate a
new policy URI whenever it generates a new location URI set. new policy URI whenever it generates a new location URI set.
4. Location Configuration Extensions 4. Location Configuration Extensions
Location configuration protocols can provision hosts with location Location configuration protocols can provision hosts with location
URIs that refer to the host's location. If the target host is to URIs that refer to the host's location. If the target host is to
control policy on these URIs, it needs a way to access the policy control policy on these URIs, it needs a way to access the policy
that the Location Server uses to guide how it serves location URIs. that the Location Server uses to guide how it serves location URIs.
This section defines extensions to LCPs to carry policy URIs that the This section defines extensions to LCPs to carry policy URIs that the
skipping to change at page 7, line 48 skipping to change at page 7, line 48
<xs:element name="policyUri" type="xs:anyURI"/> <xs:element name="policyUri" type="xs:anyURI"/>
</xs:schema> </xs:schema>
Figure 1 Figure 1
The URI carried in a "policyUri" element refers to the common access The URI carried in a "policyUri" element refers to the common access
control policy for location URIs in the location response. The URI control policy for location URIs in the location response. The URI
MUST be a policy URI as described in Section 3. A policy URI MUST MUST be a policy URI as described in Section 3. A policy URI MUST
use the "http:" or "http:" scheme, and the Location Server MUST use the "http:" or "https:" scheme, and the Location Server MUST
support the specified operations on the URI. support the specified operations on the URI.
A HELD request MAY contain an explicit request for a policy URI. The A HELD request MAY contain an explicit request for a policy URI. The
presence of the "requestPolicyUri" element in a location request presence of the "requestPolicyUri" element in a location request
indicates that a policy URI is desired. indicates that a policy URI is desired.
4.2. DHCP 4.2. DHCP
The DHCP location by reference option The DHCP location by reference option
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in
skipping to change at page 11, line 41 skipping to change at page 11, line 41
HTTP/1.1 200 OK HTTP/1.1 200 OK
Finally, after using the URI for a period, the user wishes to Finally, after using the URI for a period, the user wishes to
permanently invalidate the URI. permanently invalidate the URI.
DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768 Host: ls.example.com:9768
HTTP/1.1 200 OK HTTP/1.1 200 OK
6. Acknowledgements 6. IANA Considerations
Thanks to Mary Barnes, Alissa Cooper, and Hannes Tschofenig for
providing critical commentary and input on the ideas described in
this document.
7. IANA Considerations
This document requires several IANA registrations, detailed below. This document requires several IANA registrations, detailed below.
7.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy urn:ietf:params:xml:ns:geopriv:held:policy
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:policy URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).
skipping to change at page 12, line 41 skipping to change at page 12, line 37
<body> <body>
<h1>Namespace for HELD Policy URI Extension</h1> <h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
<p>See RFCXXXX</p> <p>See RFCXXXX</p>
</body> </body>
</html> </html>
END END
7.2. XML Schema Registration 6.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:policy URI: urn:ietf:params:xml:schema:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Richard Barnes (rbarnes@bbn.com) Richard Barnes (rbarnes@bbn.com)
Schema: The XML for this schema can be found in Section Section 4.1. Schema: The XML for this schema can be found in Section Section 4.1.
7.3. DHCP LuriType Registration 6.3. DHCP LuriType Registration
IANA is requested to add a value to the LuriTypes registry, as IANA is requested to add a value to the LuriTypes registry, as
follows: follows:
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| LuriType | Name | Reference | | LuriType | Name | Reference |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| TBD* | Policy-URI | RFC XXXX**| | TBD* | Policy-URI | RFC XXXX**|
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
* TBD is to be replaced with the assigned value * TBD is to be replaced with the assigned value
** RFC XXXX is to be replaced with this document's RFC number. ** RFC XXXX is to be replaced with this document's RFC number.
8. Security Considerations 7. Security Considerations
There are two main classes of risks associated with access control There are two main classes of risks associated with access control
policy management: The risk of unauthorized disclosure of the policy management: The risk of unauthorized disclosure of the
protected resource via manipulation of the policy management process, protected resource via manipulation of the policy management process,
and the risk of disclosure of policy information itself. and the risk of disclosure of policy information itself.
Protecting the policy management process from manipulation entails Protecting the policy management process from manipulation entails
two primary requirements: First, the policy URI has to be faithfully two primary requirements: First, the policy URI has to be faithfully
and confidentially transmitted to the client, and second, the policy and confidentially transmitted to the client, and second, the policy
document has to be faithfully and confidentially transmitted to the document has to be faithfully and confidentially transmitted to the
Location Server. The mechanism also needs to ensure that only Location Server. The mechanism also needs to ensure that only
authorized entities are able to acquire or alter policy. authorized entities are able to acquire or alter policy.
8.1. Integrity and Confidentiality for Authorization Policy Data 7.1. Integrity and Confidentiality for Authorization Policy Data
Each LCP ensures integrity and confidentiality through different Each LCP ensures integrity and confidentiality through different
means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]). means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).
These measures ensure that a policy URI is conveyed to the client These measures ensure that a policy URI is conveyed to the client
without modification or interception. without modification or interception.
To protect the integrity and confidentiality of policy data during To protect the integrity and confidentiality of policy data during
management, the Location Server SHOULD provide policy URIs with the management, the Location Server SHOULD provide policy URIs with the
"https:" scheme and require the use of HTTP over TLS [RFC2818]. The "https:" scheme and require the use of HTTP over TLS [RFC2818]. The
cipher suites required by TLS [RFC5246] provide both integrity cipher suites required by TLS [RFC5246] provide both integrity
protection and confidentiality. If other means of protection are protection and confidentiality. If other means of protection are
available, an "http:" URI MAY be used. available, an "http:" URI MAY be used.
8.2. Access Control for Authorization Policy 7.2. Access Control for Authorization Policy
Access control for the policy resource is based on knowledge of its Access control for the policy resource is based on knowledge of its
URI. The URI of a policy resource operates under the same URI. The URI of a policy resource operates under the same
constraints as a possession model location URI [RFC5808] and is constraints as a possession model location URI [RFC5808] and is
subject to the same constraints: subject to the same constraints:
o Knowledge of a policy URI MUST be restricted to authorized Rule o Knowledge of a policy URI MUST be restricted to authorized Rule
Makers. Confidentiality is required for its conveyance in the Makers. Confidentiality is required for its conveyance in the
location configuration protocol, and in the requests that are used location configuration protocol, and in the requests that are used
to inspect, change or delete the policy resource. to inspect, change or delete the policy resource.
o The Location Server MUST ensure that the URI cannot be easily o The Location Server MUST ensure that the URI cannot be easily
predicted. The policy URI MUST NOT be derived solely from predicted. The policy URI MUST NOT be derived solely from
information that might be public, including the Target identity or information that might be public, including the Target identity or
any location URI. The addition of random entropy increases the any location URI. The addition of random entropy increases the
difficulty of guessing a policy URI. difficulty of guessing a policy URI.
8.3. Location URI Allocation 7.3. Location URI Allocation
A policy URI enables the authorization by access control lists model A policy URI enables the authorization by access control lists model
[RFC5808] for associated location URIs. Under this model, it might [RFC5808] for associated location URIs. Under this model, it might
be possible to more widely distribute a location URI, relying on the be possible to more widely distribute a location URI, relying on the
authorization policy to constrain access to location information. authorization policy to constrain access to location information.
To allow for wider distribution, authorization by access control To allow for wider distribution, authorization by access control
lists places additional constraints on the construction of location lists places additional constraints on the construction of location
URIs. URIs.
skipping to change at page 15, line 5 skipping to change at page 14, line 48
the same location URI or the same policy URI. the same location URI or the same policy URI.
In some deployments, it is not always apparent to a LCP server that In some deployments, it is not always apparent to a LCP server that
two clients are different. In particular, where a middlebox two clients are different. In particular, where a middlebox
[RFC3234] exists two or more clients might appear as a single client. [RFC3234] exists two or more clients might appear as a single client.
An example of a deployment scenario of this nature is described in An example of a deployment scenario of this nature is described in
[RFC5687]. An LCP server MUST create a different location URI and [RFC5687]. An LCP server MUST create a different location URI and
policy URI for every request, unless the requests can be reliably policy URI for every request, unless the requests can be reliably
identified as being from the same client. identified as being from the same client.
8. Acknowledgements
Thanks to Mary Barnes and Alissa Cooper for providing critical
commentary and input on the ideas described in this document, and to
Ted Hardie and Adam Roach for helping clarify the relationships
between policy URIs, policy documents, and location resources.
9. References 9. References
9.1. Normative References 9.1. Normative 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 Identifier and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-11 (work (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work
in progress), February 2011. in progress), October 2011.
[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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 15, line 43 skipping to change at page 15, line 46
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
9.2. Informative References 9.2. Informative References
[I-D.ietf-geopriv-deref-protocol] [I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "A Location Dereferencing Thomson, M., and M. Dawson, "A Location Dereferencing
Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-03
(work in progress), December 2010. (work in progress), June 2011.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Morris, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-23 (work in progress), draft-ietf-geopriv-policy-24 (work in progress),
March 2011. September 2011.
[I-D.ietf-geopriv-rfc3825bis]
Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-based
Location Configuration Information",
draft-ietf-geopriv-rfc3825bis-17 (work in progress),
February 2011.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[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.
skipping to change at page 17, line 5 skipping to change at page 16, line 39
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", RFC 6155, March 2011. Delivery (HELD)", RFC 6155, March 2011.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Parkway 9861 Broken Land Parkway
Columbia, MD 21046 Columbia, MD 21046
US US
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com Email: rbarnes@bbn.com
 End of changes. 27 change blocks. 
50 lines changed or deleted 47 lines changed or added

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