Subject: Re: [Geopriv] Fwd: New Version Notification for draft-barnes-geopriv-policy-uri-01

From: Alissa Cooper <[email-masked]>
Date: Fri, 23 Jul 2010 17:24:13 +0100

(individual hat on)

Hi Richard,

I think this is an interesting (and probably necessary) idea, but it  
has some gaps that need filling in. A couple of thoughts to tee up  
before the meeting:

3.1 says:

"Knowledge of the policy URI can be considered adequate evidence of  
authorization. While the Location Server MAY deny any particular  
request according to local policy, it SHOULD allow all requests (with  
any of the three methods). This does not prevent a Location Server  
from applying local policy in determining how to authorize any of  
these requests. For instance, a Location Server might allow clients to  
inspect policy (GET), but not to update it (PUT)."

I find the multiple caveats here to be confusing. I think the outcome  
you're looking for is that an LS SHOULD allow all requests, but it MAY  
deny certain requests based on local authorization policy (e.g.,  
allowing GETs but not PUTs, or only allowing dereferences from certain  
clients). Is that right?

3.2: This section discusses both policies for access to location and  
policies for access to policy URIs. Combining them like this is pretty  
confusing, and I'm not sure that either part is complete. For access  
to location, you say that the default policy has to be what it would  
be if there were no policy, but you don't say what the default policy  
is. The example in 5.3 suggests that the default policy's  
transformations are

        <transformations>
          <gp:provide-location/>
        </transformations>

Didn't the default policy used to also include retransmission-allowed  
= FALSE and retention-expiry = 24 hours? What happened to those?

For access to policy URIs, it says

"A Location Server chooses whether or not to provide a policy URI  
based on local policy."

I'm confused about the LS "providing" a URI in HELD. You describe a  
mechanism in 5.1 for *creating* a URI. But how does an LS provide a  
URI that has previously been created? If a Target issues the HELD  
request in 5.1, and then a third party issues a query containing both  
a "requestPolicyUri" element and a "device" element, does the original  
URI get overwritten? Or is that the point at which the "local policy"  
referenced above gets checked to see whether the third party is  
authorized to overwrite (or receive?) the URI?

As to your question below about LSes providing other policy URIs,  
since the requests aren't coming via HELD or DHCP, what would you  
intend to specify other than making a generic statement that an LS can  
hand out policy URIs via other protocols? It seems like an LS that  
implements other protocols could do that already if it wanted to.

Alissa

On Jun 1, 2010, at 1:34 AM, Richard L. Barnes wrote:

> Hey all,
>
> James, Martin, and I have put together a new version of the policy- 
> uri draft.  As a reminder, this draft defines a way for a location  
> server to associate location URIs with "policy URIs" that allow the  
> target to control the policy associated with the location URI, and a  
> simple usage of HTTP to manipulate policy (which is forward- 
> compatible with WebDAV / XCAP).
>
> The major unresolved point of discussion among the author team that  
> I would like to bring to the list is whether this draft should also  
> allow the LS to provide a policy URI that is *not* associated with a  
> location URI.  This policy URI would govern queries for the target's  
> location that are not based on a location URI provided through HELD  
> or DHCP, e.g., a third-party query.
>
> Comments welcome!
>
> Thanks,
> --Richard
>
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool <[email-masked]>
>> Date: May 30, 2010 7:37:08 PM EDT
>> To: [email-masked]
>> Cc: [email-masked],[email-masked]
>> Subject: New Version Notification for draft-barnes-geopriv-policy- 
>> uri-01
>>
>>
>> A new version of I-D, draft-barnes-geopriv-policy-uri-01.txt has  
>> been successfully submitted by Martin Thomson and posted to the  
>> IETF repository.
>>
>> Filename:	 draft-barnes-geopriv-policy-uri
>> Revision:	 01
>> Title:		 Location Configuration Extensions for Policy Management
>> Creation_date:	 2010-05-31
>> WG ID:		 Independent Submission
>> Number_of_pages: 16
>>
>> Abstract:
>> Current location configuration protocols are capable of provisioning
>> an Internet host with a location URI that refers to the host's
>> location.  These protocols lack a mechanism for the target host to
>> inspect or set the privacy rules that are applied to the URIs they
>> distribute.  This document extends the current location configuration
>> 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.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 13:58:37 +0800

Hi Alissa,

It looks like most of this is an artefact of my inability to generate sane prose :)  I

> 3.1 says:
...
> allowing GETs but not PUTs, or only allowing dereferences from certain

Correct.  I'll take a second go at this.

> = FALSE and retention-expiry = 24 hours? What happened to those?

Thanks.  We should be explicit about what the default policy is.  And I missed those.
 
> URI that has previously been created?

It doesn't have to and it probably should not.  I'll expand on this below.

> If a Target issues the HELD

A policy URI applies to a single location URI - if we haven't then we'd better fix it.

Following on from this, we don't want to provide the same location URI to uncorrelated requests for the same Target, which means different policy URIs.  Some text on this would be a good idea.  I think that there might be something in RFC5808 on uniqueness of URIs, but if there isn't we should make explicit note of it.

The main reason for this is that a single Target from the perspective of the LIS, could actually be several different devices and - by extension - people.  These people can have different preferences and policies and they might want to ensure that their policies (and identity) remain distinct.  Once you start attributing policy to URIs, giving each a unique location URI ensures that they don't trample on each other's policies.  Even the ability to see another person's policy is sufficient reason for separation.

When you add a third party into the equation, it gets even worse.  For instance, you don't want your service provider messing with your policy.  If they have to set policy, then they can (and should) do so transparently by altering the initial policy you get for the location URI and preventing you from destroying their rules.

Of course, uniqueness of URIs matters considerably less for pure authorization by possession.

Obviously, this needs text.  I'll propose something later.

> implements other protocols could do that already if it wanted to.

The idea that a policy URI applies to a specific location URI tends to bias me against what Richard is talking about.  The same underlying reasons apply.