More below.
> >If you want suggested text, here's some:
> >
> > This location URI operates under the "authorization by
> > possession" model, described in [lbyr-requirements].
>
> lbyr-reqjuirements is rooted from a HELD ID, I believe. HELD has the
> concept of identity and of TLS to protect that HTTP based protocol in
> transit. DHCP has no such protection, therefore possession of a
> location URI shouldn't grant access to a DHCP client's location
> without a challenge from the requested resource/entity. I don't
> believe a possession model works when there is no change of secure
> communication to a Target.
Possession model works well enough. If DHCP is secure enough for location by value, it is good enough for possession model. ...by virtue of possession model sharing security properties with location by value.
> Right now, there is no consensus this WG document
> needs to change, and it shouldn't until such consensus is reached.
I don't want to get entangled in minutiae, but I could equally argue that there is no consensus for the current form of the document.
> Here's an issue with HELD too, it's only valid if the Target doesn't
> move since it last requested location; else, the location is
> invalid/stale. There is no difference with DHCP (by value or with a
> locaition URI).
That's true for provision of location by value, but not for location by reference. The location URI can be dereferenced at any time after the initial HELD or DHCP request, at which time the location server can (and should) acquire fresh location information. RAIO doesn't help the LS in this task. Thus, I conclude that while it might provide marginal assistance where the URI is dereferenced shortly after the URI is minted, it doesn't provide any tangible aid in the time after that.
> > 'A URI included in this option is constrained to 255 octets in
> length.'
>
> without the exception - which I quoted - it is constrained to
> 255. Perhaps I can either say something like:
>
> Location URIs are normally or RECOMMENDED to be less than
> 255, to comply with existing DHCP practices. Exceptions can be met by
> following RFC 3396."
As it stands, a location URI cannot be 256 octets long. The length field for the sub-option is one octet and sub-options aren't concatenated. Get a bigger sub-option code, or allow concatenation and this might apply; otherwise, you're stuck with a hard limit.
I'd also point out that 2119 language wont change this, so I'd argue that capitalization is pointless.
Also, to get to 255 octets, you need RFC 3396 because of the overhead in the option (ver, resv, sub-option code and length), so 3396 is worth a mention, but not for this.
> >I think that it would be more helpful to use Rule Maker than Rule
> >Holder. I personally don't find Rule Holding to be especially
> >relevant to the discussion. It's a necessary function, with real
> >security and privacy considerations, but it's a passive rather than
> >active role.
>
> The Rule Holder is who is asked for the location, or for the
> policy(ies) for location distribution by Location Servers (per RFC
> 3693 - which the -arch- isn't obsoleting BTW. Therefore I'm going to
> have to think a little more about how to use the terms in a consistent
> way.
Actually, the Location Server is the one that is asked for location.
In other architectures, the Location Server and Rule Holder are distinct entities. There is a protocol interface between the LS and the Rule Holder for the Rule Holder to communicate authorization decisions about specific requests. (e.g., LS asks can person X get person Y's location? Rule Holder says yes/no/maybe...)
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
