>
> On May 5, 2011, at 7:12 PM, Winterbottom, James wrote:
>
> >> 3. The draft talks quite a bit about the lifetime and validity of
> >> policy URLs. But (unless I missed it) it doesn't say as much about
> >> the scope and lifetime of the policy documents referenced by such
> >> URLs. I think, in order to get the security properties I think you
> >> contemplate for the policy URIs, you must have a distinct policy
> >> object for each URI. That is, two policy URIs for the same device
> are
> >> not aliases for the same policy document. If the policy docs are
> >> the same, it's just a coincidence, and changing one does not affect
> >> the other. Furthermore, each policy doc is only meaningful for the
> >> Location URI associated with the policy URI. If the LS mints a new
> >> Location URI and associated Policy URI, the referenced policy
> >> document is always a _new_ one set to the "default policy". Is this
> the idea?
> >
> >
> > [AJW] Yes this is the idea. Take a residential broadband situation
> for example, all device behind a residential gateway performing NAT
> will appear the same the LS, but clearly there maybe several different
> devices. In this case each time a new location URI is requested, a new
> policy URI is minted. Certainly I don't want my daughter changing my
> policy.
> >
> >
>
> I think we are on the same page here, but I want to emphasize I'm
> talking about the referenced policy document, not the policy URL. So
> as long as, for every new location URI you get a new policy URI and a
> new policy _document_ that only applies to that particular URI pair,
> then I think it's fine.
I find that it's helpful to distinguish between the resource and the thing that identifies it. In all these cases, it is actually a new _resource_, not just a new identifier. Naturally, that means a different identifier.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
