Re: discuss on draft-ietf-geopriv-dhcp-lci-option

[hardie@qualcomm.com]

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.
			regards,	
				Ted


At 8:30 PM -0500 10/29/2003, Steve Bellovin wrote:
>Nit:  the title is wrong.  This isn't a DHCP option "for" geopriv;
>rather, it's a geopriv-compatible DHCP option.
>
>Not as much of a nit:  a pass by a copy editor is needed; the writing
>is bad enough, in places, to obscure the meaning.
>
>major objection:  I wonder if the philosophy of this option is, in
>fact, geopriv-compatible.  The location information is indeed
>obfuscatable, but the amount of the obfuscation is controlled by the
>DHCP server, not the end system.  I would think that the DHCP client
>should supply the maximum precision in the DHCP request, rather than
>relying on the server.
>
>
>		--Steve Bellovin, http://www.research.att.com/~smb