Subject: [dhcwg] Re: Fwd: I-D ACTION:draft-polk-dhcp-geo-loc-option-00.txt

From: John Schnizlein <[email-masked]>
Date: Fri, 25 Oct 2002 16:33:20 -0400

Please comment on the geo-loc-option draft announced in the following.

While we are asking for a moment in the DHC WG at the Atlanta meeting, 
the semantics of this option are to be discussed in the GEOPRIV WG.
We hope the format will be useful more widely, but it is designed to
fit the circumstances of DHCP.

The concept of this draft is different from the recently discussed 
draft-critchley-dhc-location-option-00.txt in several ways:
1) the location configured is that of the DHC client, not the server,
2) the encoding is binary for economy,
3) the resolution of each measure is under explicit control, and
4) an immediate purpose is to give wired IP telephones the location 
   they would send when calling to report an emergency.

There is, of course, no reason to wait for Atlanta to comment.

John

>To: IETF-Announce:;
>From: [email-masked]
>Subject: I-D ACTION:draft-polk-dhcp-geo-loc-option-00.txt
>Date: Wed, 23 Oct 2002 07:36:17 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: DHCP Option for Geographic Location
>	Author(s)	: J. Polk et al.
>	Filename	: draft-polk-dhcp-geo-loc-option-00.txt
>	Pages		: 22
>	Date		: 2002-10-22
>	
>This document specifies a Dynamic Host Configuration Protocol option for 
>the geographic location of the client. The location includes latitude, 
>longitude, and altitude, with resolution indicators for each.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-polk-dhcp-geo-loc-option-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt>

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Oct 2002 13:57:21 -0700

It looks fine, superficially, but all those fiddly 4-bit, 34-bit, and 
30-bit values are going to be a real pain for implementation.   I don't 
know if this is going to be implemented on servers that are not 
embedded in devices that can do location calculations, but if it is, it 
would be better to use a less complex numbering scheme.   It's normally 
considered bad form to have a DHCP option that requires special 
modifications to the server in order to implement.

I'm also a bit skeptical that DHCP is even the right way to do this, 
because the DHCP server's physical location, and even the relay agent's 
physical location, is not the same as the device's physical location.   
For wired devices, you can figure out the devices location through a 
database lookup, but for wireless devices you need to triangulate, and 
I have trouble figuring out how you're going to cram that functionality 
into a DHCP server.

---

From: John Schnizlein <[email-masked]>
Date: Fri, 25 Oct 2002 17:30:45 -0400

Wow, Ted! Thanks for the almost instantaneous reply.

The only modification is a little arithmetic to evaluate the option.
We thought dividing the byte containing the MU by 16, would be easy. 
And fixed point arithmetic is often handled by treating the combination,
which we arranged to be 5 bytes long, as an integer multiple of the
(peculiar) smallest increment precision. There would be just a few 
tricky arithmetic expressions for the client to extract the resolution
and apply it to the location measure. The server would, presumably,
just hand out the properly formatted lump of 15 bytes it gets out of
the Circuit-ID-to-location database lookup.

We completely agree that the DHCP server's location is irrelevant.

Although we have not considered the wireless case beyond the obvious
that the location of the access-point, which this method can support,
is within radio distance of the client. The appropriately smaller
resolution would be associated with those entries in the location 
database. 

We suspect that the triangulation to determine more precise locations
might be performed by the receiver in the client, which would be someone
else's problem to standardize. The point that we think GEO-PRIV really
cares about is that the host finds its location in some not-very-public
way, and it decides when and where to send it - for example to an
emergency responder.

John

At 04:57 PM 10/25/2002, Ted Lemon wrote:
>It looks fine, superficially, but all those fiddly 4-bit, 34-bit, and 30-bit values are going to be a real pain for implementation.   I don't know if this is going to be implemented on servers that are not embedded in devices that can do location calculations, but if it is, it would be better to use a less complex numbering scheme.   It's normally considered bad form to have a DHCP option that requires special modifications to the server in order to implement.
>
>I'm also a bit skeptical that DHCP is even the right way to do this, because the DHCP server's physical location, and even the relay agent's physical location, is not the same as the device's physical location.   
>For wired devices, you can figure out the devices location through a database lookup, but for wireless devices you need to triangulate, and I have trouble figuring out how you're going to cram that functionality into a DHCP server.
>