In-line responses,
Ted
On Wed, May 4, 2011 at 1:21 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:> Then I suggest that the policy URI "age out" over time. As it stands, the policy URI is created by the location server and effectively never changes during the validity interval set for that location. Whenever it is used to get or set policy through a proxy (like a friendly interception proxy, let's say), it may be revealing itself. If the validity interval is long, this may be a problem (my employer may get or my ex-employer may retain access to the policy URI for my "home" location).We should keep in mind that there are at least three different validity intervals here:
>
> I am assuming that a location may be fairly long lived-e.g. created by my cable company for my "home" location and re-used with its policy URI for long periods. If the validity intervals are short and the LS does not re-use the policy URI when a new location URI for that same location is created, this is less of a problem (this latter problem may require some thought in the inputs to a hash-based mechanism for the creation of a policy URI, especially if an LS re-used the random entropy in a new run. It can neither use the location URI nor the location description, I'd guess).
1. The validity interval of the location value
2. The validity interval of the location URI
3. The validity interval of the policy URI
Would it address your concern to require (2) and (3) to be equal? This seems sensible and implementable to me. Proposed text:
"
A policy URI is only valid while the corresponding location URI set is valid. A location server MUST NOT respond to any requests to a policy URIs once the corresponding location URI set has expired. This expiry time is specified by the 'expires' attribute in the HELD locationResponse or the 'Valid-For' LuriType in DHCP.
"
This works. I would add "Re-use of policy URIs with subsequent location URIs is NOT RECOMMENDED even if the rule maker and location are the same." That may be me being paranoid, so I'm okay if you prefer to leave it out. I can't really see this being done by anyone following the spirit of the other recommendations, but paranoia is paranoia, you know?
Proposed text:
> > It's also not clear whether a location server that allows clients to inspect policy but not update actually meets the goals of this document, since it either then requires some other side-loading mechanism or is incomplete.
>
> Being pragmatic about this, we can't really legislate what policies LS provider will apply. We could have a requirement that servers allow changes to policy, but that just risks that portion of the spec being unused. IMO, even being able to inspect policy is an improvement over the current state of the art.
>
>
> No, but we can say that it is recommended for cases where there is no other way to set policy.
FROM
"TO
A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT).
"
"
A Location Server MUST allow GET requests to allow clients to inspect policy. A Location Server SHOULD support PUT and DELETE requests to allow clients to control policy, especially if clients cannot set policy through other means.
"
Works for me.
> Overloading removing the policy URI with "delete access to the resource" seems like an un-needed optimization to me. As a client writer, I'd update the policy with a validity interval that is gone, set provide-location to false or something similar. That's just my personal take on this obviously, and if other folks feel that this is the optimization to make, I can live with it.Ok, I think I understand you better now. I can agree that overloading DELETE makes sense, especially
Was this "does not make sense"?
in light of the fact that we have two other ways of invalidating location URIs (policy-based validity intervals and the global expiration of the URI). It still seems like an LS shouldn't respond to requests for the location URI while there's no policy document (after a DELETE).
Agreed.
Proposed text:
FROM
"
A DELETE request to a policy URI is a request to delete the referenced policy document and terminate access to the protected resource. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow any further access to the location resources it governs.
TO
A location URI can thus become invalid 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.
"
"
A DELETE request to a policy URI is a request to delete the referenced policy document. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow access to the location URIs it governs until a new policy document has been put in place via a PUT request.
A location URI can thus become invalid 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 LCP-specified validity interval. The former two are temporary, since the policy URI can be used to update the policy. The latter one is permanent, since the expiry causes the policy URI to be invalidated as well.
"
This works for me.
Thanks,
Ted
