geopriv@ietf.org: 2011

Wednesday, December 14, 2011

Re: [Geopriv] Continued discussion of draft-ietf-geopriv-dhcp-lbyr-uri-option on the dhcwg list

Just so I'm clear:
>
> And, if the valid time is used by the client app (presumably the app that manages handing out the LURI to other hosts) as an indication of when to request an Information-request for the LURI, the mechanism would be compatible with DHCP clients.
>
The "Information-request for the LURI" is a DHCP client request to the DHCP server, right? You are just concerned that this request doesn't (necessarily) request an IP address lease renewal.

If that's it, I see no problem. We need an explicit lifetime for the L-URI in the return from the request which is totally independent of the IP address lease time.

Brian

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Continued discussion of draft-ietf-geopriv-dhcp-lbyr-uri-option on the dhcwg list

On Dec 12, 2011, at 3:49 PM 12/12/11, Robert Sparks wrote:

> On 12/12/11 2:37 PM, James M. Polk wrote:
>> At 08:47 PM 12/9/2011, Martin Thomson wrote:
>>> A good, clear summary.
>>>
>>> You didn't mention access control policy, but that's probably OK for
>>> the purposes of the discussion at hand.
>>>
>>> On the last paragraph, I think that Richard suggested that there be a
>>> recommendation (though not a 2119 SHOULD) that the expiration be
>>> longer than the lease time.
>>
>> err...
>>
>> I'm thoroughly confused.
>>
>> the current WG chair and the AD in the Int area (aka the previous WG chair from the WG's inception) both have a fundamental problem with the whole idea of more than one lifetime timer (i.e., lease). How can anyone here be advocating what they have said needs to go at this late stage?
> They (rightfully) have a problem with the lifetime timer affecting the _lease_ time (either directly or as a side-effect through making the application renew at a time other than it would have under normal DHCP
> requirements).
>
> Please read the note I sent to the dhcwg list - the expiry on the location url is important information
> to the application that will hand out that url. It needs to continue to be defined, and there's no reason
> to force it to be exactly the dhcp lease time.
>
> I've been talking with Ralph (copied) and I believe we're closer to a common understanding that doesn't
> involve completely removing the url expiry.

As I understand the requirements through my conversation with Robert, the option could be defined to be compatible with DHCP server design if the LURI in the option can be provided by the server without a real-time reference to some external information source, and if the "valid time" for the LURI does not *directly* affect the lease time expiration.

So, for example, if the LURIs for hosts can be made available to the DHCP server before the requests arrive from those hosts, the DHCP server should be able to handle returning the speific LURI for a host through the DHCP message exchange. And, if the valid time is used by the client app (presumably the app that manages handing out the LURI to other hosts) as an indication of when to request an Information-request for the LURI, the mechanism would be compatible with DHCP clients.

- Ralph

>>
>> James
>>
>>> The only reason being that it's probably
>>> sensible to ensure that a host always has a valid location URI.
>>>
>>> --Martin
>>>
>>> On 9 December 2011 07:18, Robert Sparks <rjsparks@nostrum.com> wrote:
>>> > Please take a look at
>>> > http://www.ietf.org/mail-archive/web/dhcwg/current/msg12238.html
>>> >
>>> > If you have anything to add, or more importantly, if you see something I got
>>> > wrong that you need
>>> > to correct, please do so on the dhcwg list.
>>> >
>>> > RjS
>>> > _______________________________________________
>>> > Geopriv mailing list
>>> > Geopriv@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/geopriv
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, December 13, 2011

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

At 08:17 AM 12/13/2011, Brian Rosen wrote:
>Option A. We have to make DHCP LbyR work one way or another. I
>don't mind waiting, and I want less work overall.

Option A - for the reasons stated above

James

>Brian
>
>On Dec 12, 2011, at 4:30 PM, Richard L. Barnes wrote:
>
> > Dear GEOPRIV,
> >
> > tl;dr: If you care about whether -policy-uri supports DHCP LbyR,
> please say so now.
> >
> > As you may be aware, we currently have three documents in IESG processing:
> > 1. -deref-protocol
> > 2. -policy-uri
> > 3. -dhcp-lbyr-uri-option
> >
> > The first of these are pretty non-controversial, while the last
> has some outstanding issues with the DHC working group. Right now,
> however, -policy-uri has a normative dependence on
> -dhcp-lbyr-uri-option, because it says how to carry policy URIs
> inside a DHCP LbyR option. This raises the question of whether we
> should remove the DHCP parts of -policy-uri in order to remove the dependency.
> >
> > So I wanted to get the feeling of the WG on which of three
> courses of action people would prefer:
> >
> > A: Do nothing for now.
> > If approved by the IESG, -policy-uri will sit in the RFC editor's
> queue waiting for -dhcp-lbyr-uri-option. If the objections in DHC
> cannot be overcome and that document dies, then we will work with
> the RFC editor to remove the text that depends on it.
> >
> > B: Remove the DHCP text now
> > This would remove the normative dependency, and leave open the
> possibility of adding the same mechanism as part of
> -dhcp-lbyr-uri-option later.
> >
> > C: Remove the DHCP text now and add it to -dhcp-lbyr-uri-option
> > This would just move the functionality from one document to
> another, removing the dependency while ensuring the functionality
> is maintained.
> >
> > For reference, I have attached a diff that describes the changes
> that would need to be made to -policy-uri in order to remove the dependency.
> >
> > If you have an opinion on this issue, it would be helpful if you
> could reply in this thread in the next week or so.
> >
> > Thanks,
> > --Richard
> >
> >
> > <rfcdiff-04-05prop.html>_______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

Option A. We have to make DHCP LbyR work one way or another. I don't mind waiting, and I want less work overall.

Brian

On Dec 12, 2011, at 4:30 PM, Richard L. Barnes wrote:

> Dear GEOPRIV,
>
> tl;dr: If you care about whether -policy-uri supports DHCP LbyR, please say so now.
>
> As you may be aware, we currently have three documents in IESG processing:
> 1. -deref-protocol
> 2. -policy-uri
> 3. -dhcp-lbyr-uri-option
>
> The first of these are pretty non-controversial, while the last has some outstanding issues with the DHC working group. Right now, however, -policy-uri has a normative dependence on -dhcp-lbyr-uri-option, because it says how to carry policy URIs inside a DHCP LbyR option. This raises the question of whether we should remove the DHCP parts of -policy-uri in order to remove the dependency.
>
> So I wanted to get the feeling of the WG on which of three courses of action people would prefer:
>
> A: Do nothing for now.
> If approved by the IESG, -policy-uri will sit in the RFC editor's queue waiting for -dhcp-lbyr-uri-option. If the objections in DHC cannot be overcome and that document dies, then we will work with the RFC editor to remove the text that depends on it.
>
> B: Remove the DHCP text now
> This would remove the normative dependency, and leave open the possibility of adding the same mechanism as part of -dhcp-lbyr-uri-option later.
>
> C: Remove the DHCP text now and add it to -dhcp-lbyr-uri-option
> This would just move the functionality from one document to another, removing the dependency while ensuring the functionality is maintained.
>
> For reference, I have attached a diff that describes the changes that would need to be made to -policy-uri in order to remove the dependency.
>
> If you have an opinion on this issue, it would be helpful if you could reply in this thread in the next week or so.
>
> Thanks,
> --Richard
>
>
> <rfcdiff-04-05prop.html>_______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Monday, December 12, 2011

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

FWIW, my preference would be B or C, if only to remove the uncertainty.
--Richard

On Dec 12, 2011, at 4:30 PM, Richard L. Barnes wrote:

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

Option B.

If it turns out to be a problem for the DHCP LbyR then we can write another specification to address that later.

James Winterbottom

Global Product Manager

Commscope GeoLENs

IP Location Product Portfolio

Andrew Building (39), University of Wollongong

Northfields Ave, Wollongong, NSW, 2522 Australia

Email: james.winterbottom@commscope.com

Phone: +61-2-42-212938

Mobile: +61-447-773-560

www.commscope.com | www.commscopeblogs.com

From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Richard L. Barnes
Sent: Tuesday, 13 December 2011 8:31 AM
To: geopriv@ietf.org WG
Subject: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

Dear GEOPRIV,

tl;dr: If you care about whether -policy-uri supports DHCP LbyR, please say so now.

As you may be aware, we currently have three documents in IESG processing:
1. -deref-protocol
2. -policy-uri
3. -dhcp-lbyr-uri-option

The first of these are pretty non-controversial, while the last has some outstanding issues with the DHC working group. Right now, however, -policy-uri has a normative dependence on -dhcp-lbyr-uri-option, because it says how to carry policy URIs inside a DHCP LbyR option. This raises the question of whether we should remove the DHCP parts of -policy-uri in order to remove the dependency.

So I wanted to get the feeling of the WG on which of three courses of action people would prefer:

A: Do nothing for now.
If approved by the IESG, -policy-uri will sit in the RFC editor's queue waiting for -dhcp-lbyr-uri-option. If the objections in DHC cannot be overcome and that document dies, then we will work with the RFC editor to remove the text that depends on it.

B: Remove the DHCP text now
This would remove the normative dependency, and leave open the possibility of adding the same mechanism as part of -dhcp-lbyr-uri-option later.

C: Remove the DHCP text now and add it to -dhcp-lbyr-uri-option
This would just move the functionality from one document to another, removing the dependency while ensuring the functionality is maintained.

For reference, I have attached a diff that describes the changes that would need to be made to -policy-uri in order to remove the dependency.

If you have an opinion on this issue, it would be helpful if you could reply in this thread in the next week or so.

Thanks,
--Richard

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Removing dhcp-lbyr dependency from policy-uri

	< draft-ietf-geopriv-policy-uri-04.txt	draft-ietf-geopriv-policy-uri-05-proposed.txt >

	GEOPRIV R. Barnes	GEOPRIV R. Barnes
	Internet-Draft BBN Technologies	Internet-Draft BBN Technologies
	Intended status: Standards Track M. Thomson	Intended status: Standards Track M. Thomson

	Expires: May 31, 2012 J. Winterbottom	Expires: June 14, 2012 J. Winterbottom
	Andrew Corporation	Andrew Corporation
	H. Tschofenig	H. Tschofenig
	Nokia Siemens Networks	Nokia Siemens Networks

	November 28, 2011	December 12, 2011

	Location Configuration Extensions for Policy Management	Location Configuration Extensions for Policy Management

	draft-ietf-geopriv-policy-uri-04.txt	draft-ietf-geopriv-policy-uri-05.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 May 31, 2012.	This Internet-Draft will expire on June 14, 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 19	skipping to change at page 2, line 19
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4	3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
	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.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Basic Access Control Policy . . . . . . . . . . . . . . . 9
	5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.1. URN Sub-Namespace Registration for	6.1. URN Sub-Namespace Registration for

	urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12	urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 11
	6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12	6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
	6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7.1. Integrity and Confidentiality for Authorization Policy	7.1. Integrity and Confidentiality for Authorization Policy

	Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13	Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Access Control for Authorization Policy . . . . . . . . . 14	7.2. Access Control for Authorization Policy . . . . . . . . . 12
	7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14	7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 15	9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16	9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

	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
	(LCP) [RFC5687], which allows a location provider (e.g., a local	(LCP) [RFC5687], which allows a location provider (e.g., a local
	access network) to inform a host about its location.	access network) to inform a host about its location.

	There are two basic patterns for location configuration, namely	There are two basic patterns for location configuration, namely

	skipping to change at page 4, line 26	skipping to change at page 4, line 26
	\| \| \|	\| \| \|
	+------+----+----+----+ \|	+------+----+----+----+ \|
	\| Rule \| Target/ \| \|	\| Rule \| Target/ \| \|
	\| Maker \| Host +---------------------+	\| Maker \| Host +---------------------+
	\| \| \|	\| \| \|
	+-----------+---------+	+-----------+---------+

	The remainder of this document is structured as follows: After	The remainder of this document is structured as follows: After
	introducing a few relevant terms, we define policy URIs as a channel	introducing a few relevant terms, we define policy URIs as a channel
	for referencing, inspecting, and updating policy documents. We then	for referencing, inspecting, and updating policy documents. We then

	define extensions to the HELD protocol and the DHCP option for	define an extension to the HELD protocol to carry policy URIs.
	location by reference to allow these protocols to carry policy URIs.
	Examples are given that demonstrate how policy URIs are carried in	Examples are given that demonstrate how policy URIs are carried in
	these protocols and how they can be used by clients.	these protocols and how they can be used by clients.

	2. Definitions	2. Definitions

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].	document are to be interpreted as described in RFC 2119 [RFC2119].

	3. Policy URIs	3. Policy URIs

	skipping to change at page 5, line 46	skipping to change at page 5, line 46
	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.
	This expiry time is specified by the 'expires' attribute in the HELD	This expiry time is specified by the 'expires' attribute in the HELD

	locationResponse or the 'Valid-For' LuriType in DHCP.	locationResponse.

	A location URI can thus become invalid in three ways: By the	A location URI can thus become invalid in three ways: By the
	expiration of a validity interval in policy, by the removal of a	expiration of a validity interval in policy, by the removal of a
	policy document with a DELETE request, or by the expiry of the	policy document with a DELETE request, or by the expiry of the
	LCP-specified validity interval. The former two are temporary,	LCP-specified validity interval. The former two are temporary,
	since the policy URI can be used to update the policy. The latter	since the policy URI can be used to update the policy. The latter
	one is permanent, since the expiry causes the policy URI to be	one is permanent, since the expiry causes the policy URI to be
	invalidated as well.	invalidated as well.

	The Location Server MUST support policy documents in the common-	The Location Server MUST support policy documents in the common-

	skipping to change at page 6, line 40	skipping to change at page 6, line 40
	configuration, for example, 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 HELD, the client assumes that the default policy grants any
	grants any requester access to location information, as long as	requester access to location information, as long as the request
	the request possesses the location URI. To ensure that the	possesses the location URI. To ensure that the authorization
	authorization policy is less permissive, a client updates the	policy is less permissive, a client updates the policy prior to
	policy prior to distributing the location URI.	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 7). 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 the HELD LCP to carry policy URIs
	target can use to control access to location resources.	that the target can use to control access to location resources.

	4.1. HELD

	The HELD protocol [RFC5985] defines a "locationUriSet" element, which	The HELD protocol [RFC5985] defines a "locationUriSet" element, which
	contain a set of one or more location URIs that reference the same	contain a set of one or more location URIs that reference the same
	resource and share a common access control policy. The schema in	resource and share a common access control policy. The schema in
	Figure 1 defines two extension elements for HELD: an empty	Figure 1 defines two extension elements for HELD: an empty
	"requestPolicyUri" element that is added to a location request to	"requestPolicyUri" element that is added to a location request to
	indicate that a Device desires that a policy URI be allocated; and a	indicate that a Device desires that a policy URI be allocated; and a
	"policyUri" element that is included in the location response.	"policyUri" element that is included in the location response.

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	skipping to change at page 8, line 9	skipping to change at page 8, line 7
	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 "https:" 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

	The DHCP location by reference option
	[I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in
	sub-options called LuriElements. This document defines a new
	LuriElement type for policy URIs.

	LuriType=TBD Policy-URI - This is a policy URI that refers to the
	access control policy for the location URIs.

	[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
	LuriType value and remove this note]

	A Policy-URI LuriElement uses a UTF-8 character encoding.

	A Policy-URI LuriElement identifies the policy resource for all
	location URIs included in the location URI option. The URI MUST be a
	policy URI as described in Section 3: It MUST use either the "http:"
	or "https:" scheme, and the Location Server MUST support the
	specified operations on the URI.

	4.3. Client Processing

	It is possible that this document will be updated to allow the use of	It is possible that this document will be updated to allow the use of

	policy URIs that use protocols other than the HTTP-based protocol	policy URIs that use policy-management protocols other than the HTTP-
	described above. To ensure that they fail safely when presented with	based protocol described above. To ensure that they fail safely when
	such a URI, clients implementing this specification MUST verify that	presented with such a URI, clients implementing this specification
	a policy URI received from either HELD or DHCP uses either the	MUST verify that a policy URI received from an LCP uses either the
	"http:" or "https:" scheme. If the URI does not match those schemes,	"http:" or "https:" scheme. If the URI does not match those schemes,
	then the client MUST discard the URI and behave as if no policy URI	then the client MUST discard the URI and behave as if no policy URI
	was provided.	was provided.

	5. Examples	5. Examples

	In this section, we provide some brief illustrations of how policy	In this section, we provide some brief illustrations of how policy
	URIs are delivered to target hosts and used by those hosts to manage	URIs are delivered to target hosts and used by those hosts to manage
	policy.	policy.


	skipping to change at page 9, line 28	skipping to change at page 9, line 5
	</locationURI>	</locationURI>
	<locationURI>	<locationURI>
	sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:	sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
	</locationURI>	</locationURI>
	</locationUriSet>	</locationUriSet>
	<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">	<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
	https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b	https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
	</policyUri>	</policyUri>
	</locationResponse>	</locationResponse>


	5.2. DHCP	5.2. Basic Access Control Policy

	A DHCP option providing one of the location URIs and the
	corresponding policy URI from the previous example would have the
	following form:

	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| option-code \| 110 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 1 \| 0 \| 1 \| 49 \| 'h' \|
	+---------------+---------------+---------------+---------------\|
	\| 't' \| 't' \| 'p' \| 's' \|
	+---------------+---------------+---------------+---------------\|
	\| ':' \| '/' \| '/' \| 'l' \|
	+---------------+---------------+---------------+---------------\|
	\| 's' \| '.' \| ... \|
	+---------------+---------------+---------------+---------------\|
	\| TBD \| 56 \| 'h' 't' \|
	+---------------+---------------+---------------+---------------\|
	\| 't' \| 'p' \| 's' \| ':' \|
	+---------------+---------------+---------------+---------------\|
	\| '/' \| '/' \| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
	LuriType value and remove this note]

	5.3. Basic Access Control Policy

	Consider a client that gets the policy URI	Consider a client that gets the policy URI
	<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the	<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
	above LCP example. The first thing this allows the client to do is	above LCP example. The first thing this allows the client to do is
	inspect the default policy that the LS has assigned to this URI:	inspect the default policy that the LS has assigned to this URI:

	GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1	GET /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

	skipping to change at page 12, line 47	skipping to change at page 11, line 47
	6.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.

	6.3. DHCP LuriType Registration

	IANA is requested to add a value to the LuriTypes registry, as
	follows:

	+------------+----------------------------------------+-----------+
	\| LuriType \| Name \| Reference \|
	+------------+----------------------------------------+-----------+
	\| TBD* \| Policy-URI \| RFC XXXX**\|
	+------------+----------------------------------------+-----------+

	* TBD is to be replaced with the assigned value
	** RFC XXXX is to be replaced with this document's RFC number.

	7. 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 grants or denial of	policy management: The risk of unauthorized grants or denial of
	access to the protected resource via manipulation of the policy	access to the protected resource via manipulation of the policy
	management process, and the risk of disclosure of policy information	management process, and the risk of disclosure of policy information
	itself.	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.

	7.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, for example, [RFC5985]). These measures ensure that a
	These measures ensure that a policy URI is conveyed to the client	policy URI is conveyed to the client without modification or
	without modification or interception.	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, but location servers SHOULD	available, an "http:" URI MAY be used, but location servers SHOULD
	reject PUT and DELETE requests for policy URIs that use the "http:"	reject PUT and DELETE requests for policy URIs that use the "http:"
	URI scheme.	URI scheme.


	skipping to change at page 15, line 30	skipping to change at page 14, line 12

	Thanks to Mary Barnes and Alissa Cooper for providing critical	Thanks to Mary Barnes and Alissa Cooper for providing critical
	commentary and input on the ideas described in this document, and to	commentary and input on the ideas described in this document, and to
	Ted Hardie and Adam Roach for helping clarify the relationships	Ted Hardie and Adam Roach for helping clarify the relationships
	between policy URIs, policy documents, and location resources.	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]
	Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
	and IPv6 Option for a Location Uniform Resource Identifier
	(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work
	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.

	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,

End of changes. 18 change blocks.
	115 lines changed or deleted	35 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/

Dear GEOPRIV,

tl;dr: If you care about whether -policy-uri supports DHCP LbyR, please say so now.

As you may be aware, we currently have three documents in IESG processing:
1. -deref-protocol
2. -policy-uri
3. -dhcp-lbyr-uri-option

The first of these are pretty non-controversial, while the last has some outstanding issues with the DHC working group. Right now, however, -policy-uri has a normative dependence on -dhcp-lbyr-uri-option, because it says how to carry policy URIs inside a DHCP LbyR option. This raises the question of whether we should remove the DHCP parts of -policy-uri in order to remove the dependency.

So I wanted to get the feeling of the WG on which of three courses of action people would prefer:

A: Do nothing for now.
If approved by the IESG, -policy-uri will sit in the RFC editor's queue waiting for -dhcp-lbyr-uri-option. If the objections in DHC cannot be overcome and that document dies, then we will work with the RFC editor to remove the text that depends on it.

B: Remove the DHCP text now
This would remove the normative dependency, and leave open the possibility of adding the same mechanism as part of -dhcp-lbyr-uri-option later.

C: Remove the DHCP text now and add it to -dhcp-lbyr-uri-option
This would just move the functionality from one document to another, removing the dependency while ensuring the functionality is maintained.

For reference, I have attached a diff that describes the changes that would need to be made to -policy-uri in order to remove the dependency.

If you have an opinion on this issue, it would be helpful if you could reply in this thread in the next week or so.

Thanks,
--Richard

geopriv@ietf.org

Wednesday, December 14, 2011

Re: [Geopriv] Continued discussion of draft-ietf-geopriv-dhcp-lbyr-uri-option on the dhcwg list

Re: [Geopriv] Continued discussion of draft-ietf-geopriv-dhcp-lbyr-uri-option on the dhcwg list

Tuesday, December 13, 2011

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

Monday, December 12, 2011

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

Re: [Geopriv] Removing dhcp-lbyr dependency from policy-uri

[Geopriv] Removing dhcp-lbyr dependency from policy-uri

Followers

Blog Archive

Contributors