the word "specifying" would more precisely describe what you get out
of common policy and geolocation policy (and is still accurate for
held-context).
Alissa
On Nov 4, 2009, at 1:31 AM, Hannes Tschofenig wrote:
>
> Another response:
>
> ---- Draft Text ---
>
> Each of these documents listed above comes with a security
> consideration section but the security and privacy aspects are best
> covered by the SIP presence event package, see Section 9 of
> [RFC3856], and with the GEOPRIV architectural description found in
> [I-D.ietf-geopriv-arch]. The functionality for uploading
> authorization policies and other information that limit access to
> location information are provided by other protocols, such Common
> Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or
> more recent work around HELD context
> [I-D.winterbottom-geopriv-held-context]. The functionality described
> in this document extends the filter framework with location specific
> filters. Local policies might be associated with the usage of
> certain filter constructs and with the amount of notifications
> specific filter settings might cause.
>
> ------
>
>
> I find it curious
> why these references work for this
> document - knowing there is no defined
> transport for loading such policies - but
> the ID creating a DHCP Option for
> Location URIs requires a policy transport
> defined. why is that?
>
> -------
>
> The security consideration section essentially says two tings:
>
> * these location filters are just an extension in a larger system.
> Hence,
> the security of these other building blocks are applicable.
>
> * this document does not define any new security mechanisms for
> location-specific filters.
>
> Ciao
> Hannes
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
