Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-uri-00

[Richard L. Barnes <[e-mail]>]

Hey Hannes,

Always nice when co-authors submit comments :)

> In the document we do not use Target but instead host. Is this intentional? 

The host in this case is being both a Target and a Rule Maker.  I don't see a need to replace all the terms, but we could insert some text to clarify.


> We also use the term LS rather than LIS. Is this intentional? 

This makes sense, since the location server in question really is acting as a Location Server in the sense of RFC 3693 and geopriv-arch.


> 
> A few minor comments inline:
> 
> FROM:
> TO:
> "
>    their flexibility, in that they do not provide hosts (the clients
>    ...
>    LCP server (acting for the LIS) can inform a host as to
>    which policy document controls a given location resource, and the LCP
>    client (in its Rule Maker role) can inspect this document and modify
>    it as necessary.
> "

Agree to change Device / client to "host".  Think that Location Server is better than LIS here.


> 
> The following figure, which is based on Figure 1 of RFC 5808, illustrates the interactions:

Added the figure to the Introduction, but changed the letters to numbers to correspond to 5808.


> In Section 3 I noticed that we only talk about HTTP URIs. We may want to use HTTP/HTTPS instead. 

Done, in first sentence.


> 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.

You've got the constraint backwards: Each location URI has at most one policy URI, but each policy URI can control multiple location URIs.  As Martin notes, in light of that, the example in Section 5.1 is fine.

I agree with Martin that the diagram is unnecessary.


> 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? 

Yes, by definition.  But not necessarily permanently; the RM can send a new policy that re-opens the validity period.  The validity ends permanently when the HELD validity time is reached or the RM sends a DELETE request.  Added a note:
"
A location URI can thus become valid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the HELD-specified validity interval.  The former is temporary, since the policy URI can be used to update the validity interval in the policy; the latter two are permanent.
" 


> TO:
> "
>    A DELETE request to a policy URI is a request to delete the
>    referenced policy document. The LS MUST also terminate access to 
>    location information referenced by any of the location URIs 
>    previously distributed. 
> "

How is this different from the current text?
"
the Location Server deletes the policy referenced by the URI and disallows any further access to the location resources it governs.
"
I've added a MUST here, if that helps.



> There is a small typo in the following sentence:
> 
> A policy URI MUST NOT be provided to an entity that is not
>    authorized to view or set policy.  This document does not describe
>    how policy might be provided to entities other than for location
>    configuration. in responses to dereferencing requests
>                 ˆˆˆˆ
>    [I-D.ietf-geopriv-deref-protocol] or requests from third parties
>    [I-D.ietf-geopriv-held-identity-extensions].

Fixed.


> TO:
> "
>    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) and
>    confidentiality protected while in transit. 
> "

Agree with Martin.  Made the latter change, but not the former.


> s/5.3.  Basic access control policy/5.3.  Basic Access Control Policy

Fixed.



> Section 5.3 says:
> 
> "
>    Consider a user that gets the policy URI
>    <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
>    above LCP example.  The first thing this allows the user to do is
>    inspect the default policy that the LS has assigned to this URI:
> "
> 
> I would suggest not to talk about the user but instead talk about the LCP client software since otherwise one might get the impression that a human would do any of this. 

Done. s/user/client/g


> From:
> "
>    Finally, after using the URI for a period, the user wishes to
>    permanently invalidate the URI.
> "

Leaving this as "user", since clients don't make authorization decisions.



> Section 7.1: 
> The text says "URI: urn:ietf:params:xml:ns:grip" but it has to be "urn:ietf:params:xml:ns:geopriv:held:policy". 

Fixed.


> 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? 

I agree with Martin's comments here.


> 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? 

I agree with Martin's comments here, with one revision: These should be common-policy extensions rather than HELD extensions.  For example:
<transformations>
  <provide-at-time>2011-04-29T12:34</provide-at-time>
</transformations>

But in any case, not in this document.

--Richard