I think that most of your comments are good feedback, I'll pick out a few that I think need response.
On 2011-04-23 at 01:43:42, Hannes Tschofenig wrote:
> TO:
> "
> From a privacy perspective, however, current LCPs are limited in
> their flexibility, in that they do not provide hosts (the clients
[...]
> policy references. Using the mechanisms defined in this document,
> an
> LCP server (acting for the LIS) can inform a host as to
I think that the original "(active for the Location Server)" was correct in this context. Policy is enforced by the Location Server and so policy is created for the benefit of the LS. I consider LIS and LCP server to be synonymous.
The other edits are good.
> which policy document controls a given location resource, and the
[...]
> "
>
>
> In Section 3 I noticed that we only talk about HTTP URIs. We may want
> to use HTTP/HTTPS instead.
I tend to use "HTTP URI" as the general and "http: or https: URI" as the specific. HTTPS isn't a protocol, though the contemporary etymologists might disagree given its widespread use.
On the other hand, that degree of pedantry doesn't help a casual or lazy reader. The goal is to make it clear that a secured resource is important. Without making Section 3 any less succinct.
> The text in Section 3.2 says:
>
> "
> A Location Server creates a policy URI for a specific location
> resource at the time that the location resource is created; that is,
> a policy URI is created at the same time as the location URI that it
> controls. The URI of the policy resource MUST be different to the
> location URI.
> "
>
>
> The current text gives the impression that the policy URI is bound to
> location itself. Location, however, is an always changing element in
> the architecture. Instead, the policy URI follows the lifecycle of it
> the location URI: when all the location URI are destroyed the policy
> URI becomes invalid as well.
> As the text later says each location URI is associated with zero or
> one policy URIs. This is not correct given the example in Section 5.1
> where a single policy URI is associated with two location URIs.
There might need to be a clarification, but there is an important distinction between _resource_ and _URI_. A better way to describe it might be:
There is exactly one policy resource for each location resource. For a given resource, there are zero or more URIs that can be used to identify that resource.
Section 3.2 might need to be updated with text to this effect.
Based on this model, Section 5.1 shows an example where location URIs = 2 and policy URIs = 1.
> So, I suggest to add a picture to illustrate the case. Here is a
> proposal:
That's a good picture - though I'd not use the term "Context Handler" without better context [sic]. I'm inclined not to include the picture. If we did include such a picture, I'd include two things: policy resource/URI separation, and location resource/location snapshot distinction - that is, noting that the location resource is tied to a particular device and that the value/representation of the resource changes as the location of the device changes.
> Now, the only question is how the lifetime of each of these objects
> relate to each other.
> For example, a policy may contain a validity element. For example, do
> you expert the location URI to be invalid when the validity time
> expires?
Policy and location resources are irrevocably tied. Their lifetimes are the same.
Any policy needs to be enforced against the location URI until the location URI expires. If the policy includes validity statements, then those need to be respected.
>
> We have to describe the followingI believe it should instead say:
[[Missed something here?]]
>
> "
> A Location Server creates a policy URI at the same time as the
> location URI
> that it controls. Internally to the Location Server the policy URI
> refers to
> the location URIs. The URI of the policy resource MUST be different
> to the
> location URI since they refer to different information elements.
> "
I'd prefer not to include this. See above discussion on URIs and resources in respect to the first two sentences.
For the last sentence, the reason you give is only the smallest part. There's actually more reason than the fact that they are different resources. The security considerations section explains why you shouldn't be able to go from location URI to policy URI in any way: the policy URI is primarily protected by the fact that it isn't known.
> TO:
>
> "
> [1: From a security point of view a policy URI has to be treated like a
> secret shared between Location Server and each of its
> clients.] Knowledge of a policy URI is all that is required to
> perform any operations allowed on the policy. Thus, a policy URI is
> constructed so that it is hard to predict (see Section 8) [2: and
> confidentiality protected while in transit.]
> "
I'm not sure what the first edit adds. The addition to the end of the paragraph is a good pickup.
> Security considerations: Wouldn't it be more useful to always require
> HTTPS to be used? Are there really cases where it wouldn't be used? Do
> we feel OK with the requirement that every LCP has to confidentiality
> protect the transmission of the policy URI to the host given that DHCP
> does not meet this confidentiality requirement?
DHCP weasels around that by relying on layer 1 or layer 2 measures - they assume that the wire is secured somehow. That gives DHCP the ability to claim confidentiality. It's fairly clear that open WiFi wrecks that, but you could say that RFC 3825^H^H^H^H 3825bis and RFC 4676^H^H^H^H 4776 do have the proper "caveat lector" sections.
> Regarding the policy capabilities: In HELD context we had the
> functionality for limited use URIs and Snapshot URIs. A limited use
> URI can only be accessed a fixed number of times to yield the location
> of the Target. A snapshot URI points to the location of the Target at
> a specific point in time, and no matter how many times the URI is
> accessed it will always yield the same location.
>
> Did we loose this functionality?
If you want to think about it in those terms, yes. Conceptually, those are still possible, though I've been convinced that limited use is hard enough to implement that adding it would be a waste of effort. Snapshot might still be addressed through a HELD extension.
> Ciao
> Hannes
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
