Ted,
Given that this proposal is mostly "location-by-reference", you might have missed a little something, because I don't think your concerns apply in that case.
If I understand you correctly, your concerns are levelled at Richard's speculations on attaching policy URIs to non-LbyR cases. In that aspect you are right. That's why a LO contains policy.
I had other issues with both the speculation and the proposal.
As I have to point out on occasion - if the end device understands these LCP protocols, we shouldn't be using third-party requests for these protocols. We don't need to. Thus, we don't need the function that is speculated about.
Richard's speculations aside, the content of the proposal draft is largely sound, if somewhat ugly. I have my objections (*cough* ball gown on a pig *cough*), I still don't like the authorization model for gaining access to the policy document, and overall it doesn't really improve on alternative proposals, but there is a useful kernel in this design and there are elements that I think are superior to what we've seen.
--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Ted Hardie
> Sent: Thursday, 8 October 2009 12:24 PM
> To: Richard Barnes
> Cc: GEOPRIV
> Subject: Re: [Geopriv] [Fwd: New Version Notification fordraft-barnes-
> geopriv-policy-uri-00]
>
> So, color me jet-lagged and stupid, but this seems like this goes down
> a road we rejected once before. If I am reading this correctly, the
> Policy URI has all the rules which apply to the location info. What
> that creates is a sort of split LO, with the location at one spot and
> policy at another.
>
> In the long-ago-time, we agreed that doing that basically didn't work
> because anything that blocked access to the URI blocked access to the
> policy. One response to that was to make sure that the defaults in an
> LO granted no rights and so this block could not result in leakage
> (the "only grants"theory). This seems to substitute that theory with
> the *whole* policy being separated from the location. Is that right,
> or did I miss some basic thing here?
>
> I also, frankly, think specifying how the resource gets provisioned is
> pretty much a secondary issue. Sure, PUT and DELETE would work, but
> so would a lot of WEBDAV style commands and so would XCAP style POST
> etc. The real problem is actually in determining who has the rights
> to change them, and HTTP's mechaisms for that are, as you know, not
> all that useful in cases like these.
>
> You can get around this mentally by saying all LI is really LO with a
> default set of permissions (read: none), but that is deeply
> impractical for getting the actual work of the group done, because
> there is no way of ensuring that others know that is what you meant.
> And blocking access to an all-encompassing policy URI seems to get us
> back to that square one.
>
> Am I missing something basic here, in my fogged state?
>
> regards,
>
> Ted
>
> On Wed, Oct 7, 2009 at 10:08 AM, Richard Barnes <rbarnes@bbn.com>
> wrote:
> > Hey GEOPRIV,
> >
> > I put together a short draft proposing a simple mechanism for
> allowing end
> > users to control policy for location URIs. Basically, wherever an
> LCP has a
> > slot for a location URI, we add a link for a "policy URI", and define
> a very
> > basic usage of HTTP for handling policy.
> >
> > The one major thing that's missing from this draft is an extension of
> this
> > mechanism to non-LbyR policy -- to allow the Target to provision
> policy
> > related to third-party dereferences. At least in HELD, I think this
> can be
> > done by adding a similar policy URI link to the <locationResponse>
> element
> > (i.e., a reference to the *overall* policy for theclinet). But I
> didn't
> > feel like mhy XSD mojo was quite up to defining this.
> >
> > Comments welcome!
> >
> > --Richard
> >
> >
> >
> >
> >
> > -------- Original Message --------
> > Subject: New Version Notification for draft-barnes-geopriv-policy-
> uri-00
> > Date: Wed, 7 Oct 2009 10:00:55 -0700 (PDT)
> > From: IETF I-D Submission Tool <idsubmission@ietf.org>
> > To: rbarnes@bbn.com
> >
> >
> > A new version of I-D, draft-barnes-geopriv-policy-uri-00.txt has been
> > successfuly submitted by Richard Barnes and posted to the IETF
> repository.
> >
> > Filename: draft-barnes-geopriv-policy-uri
> > Revision: 00
> > Title: Location Configuration Extensions for Policy
> Management
> > Creation_date: 2009-10-07
> > WG ID: Independent Submission
> > Number_of_pages: 13
> >
> > Abstract:
> > Current location configuration protocols are capable of provisioning
> > an Internet host with a location URI that refers to the host's
> > location. However, these protocols lack a mechnism for the htarget
> > 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
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
