[dhcwg] draft-polk-dhcp-geo-loc-option-00

John Schnizlein <jschnizl@cisco.com> Fri, 25 October 2002 21:32 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12894 for <dhcwg-archive@odin.ietf.org>; Fri, 25 Oct 2002 17:32:37 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PLYVn01123 for dhcwg-archive@odin.ietf.org; Fri, 25 Oct 2002 17:34:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PLYVv01120 for <dhcwg-web-archive@optimus.ietf.org>; Fri, 25 Oct 2002 17:34:31 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12862 for <dhcwg-web-archive@ietf.org>; Fri, 25 Oct 2002 17:32:06 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PLW9v01052; Fri, 25 Oct 2002 17:32:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PLV2v01006 for <dhcwg@optimus.ietf.org>; Fri, 25 Oct 2002 17:31:02 -0400
Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12756 for <dhcwg@ietf.org>; Fri, 25 Oct 2002 17:28:37 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9PLUtot025919; Fri, 25 Oct 2002 14:30:55 -0700 (PDT)
Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PLUsqx002409; Fri, 25 Oct 2002 14:30:54 -0700 (PDT)
Received: from jschnizl-w2k.cisco.com (rtp-vpn2-820.cisco.com [10.82.243.52]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA05850; Fri, 25 Oct 2002 14:30:47 -0700 (PDT)
Message-Id: <4.3.2.7.2.20021025170935.01eaf5f8@wells.cisco.com>
X-Sender: jschnizl@wells.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 25 Oct 2002 17:30:45 -0400
To: Ted Lemon <Ted.Lemon@nominum.com>
From: John Schnizlein <jschnizl@cisco.com>
Cc: "Marc Linsner" <mlinsner@cisco.com>, "James M. Polk" <jmpolk@cisco.com>, dhcwg@ietf.org
In-Reply-To: <5AE3D9D6-E85C-11D6-B81E-003065D63CF6@nominum.com>
References: <4.3.2.7.2.20021023142936.01d98d88@wells.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [dhcwg] draft-polk-dhcp-geo-loc-option-00
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

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.
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg