[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: discuss on draft-ietf-geopriv-dhcp-lci-option
In message <p06002001bbc6362f3f87@[205.214.163.73]>, hardie@qualcomm.com writes
:
>Hi Steve,
> The theory that the working group came to was
>that the DHCP work actually fell into a bucket that occurred
>in a very early part of the geopriv process--the provisioning
>of geolocation data for the purpose of *constructing* geopriv
>objects. If you look in section 4 of draft-ietf-geoprive-reqs-04.txt,
>you'll see a boxes and arrows diagram of the geopriv entities
>and their relationships which looks more or less like this:
>
> +----------+
> | Rule |
> | Holder |
> | |
> +----+-----+
> |
> rule|interface
> V
> +----------+ +----------+ +----------+
> |Location | publication | Location | notification |Location |
> |Generator +-------------->| Server +-------------->|Recipient |
> | | interface | | interface | |
> +----------+ +----------+ +----------+
>
> The working group believed that dhcp work was within the
>"location generator" box, rather than taking the view that the dhcp
>server should be seen as location server. I agree with that view,
>as all of the work of constructing the rules and the real geopriv
>object are after the receipt of that initial geolocation data. One
>of the consequences is that all the rules are applied after the receipt
>as well (meaning the geopriv object actually delivered by a geopriv
>using protocol could be significantly fuzzed compared to that delivered
>by the dhcp for the purposes of creating that object.
> I hope that clarifies this for you; we can, of course, also
>talk about it on the call.
We need to talk -- especially given the geopriv threats document, I
don't agree with their analysis, because there's no confidentiality
mechanism for dhcp.
--Steve Bellovin, http://www.research.att.com/~smb