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 <idsubmission@ietf.org>
>> Date: May 30, 2010 7:37:08 PM EDT
>> To: martin.thomson@andrew.com
>> Cc: rbarnes@bbn.com,james.winterbottom@andrew.com
>> 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
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
