RE: Location Option for DHCP

As a specific case of another desirable format per Dante's suggestion, take
a look at the E9-1-1 location information contained in NENA 02-010:
http://nena.org/9-1-1TechStandards/nena_recommended_standards.htm

Aside from the LAT/LONG/ALT, there is a need for 'civil' locations of the
form (parsed street address and 20 character location description). Note
that this is U.S.-centric, and other variations can exist for every country
just for the emergency services location descriptions. So the numbering
space for encoding the location format should be fairly large (e.g. 16+ bits).

While the draft indicates it is not for E9-1-1 or other emergency services,
I'd argue that this is worth pursuing, in conjunction with future DHCP
enhancements that allow Ethernet switches to snoop DHCP responses and
insert location information based on the Ethernet switch port associated
with the requesting device. This will be important to provide location
information that is more granular than an IP subnet (because IP subnets can
span large physical areas through the use of VLANs).

Regards,
Scott

At 04:41 PM 8/31/2002 -0300, Dante Castiglione wrote:

>I found the DHCP location option quite clear, but also I was wondering
>if there should be a field indicating that this is one arbitrary format
>of passing the position (let's call it, for example, format x) so in the
>future other formats (y, z) can be added to the specification without
>much trouble.
>
>The sentence would then look like this:
>
> DHCPPS,X,A,B,C,D,E,F,G,H,I,J,K
>
>Where 'X' is the name of the position format being used.
>
>Just my 2c.
>
>Regards,
>
>Dante
>
>
>Dante Castiglione
>Focus Education Partners
>dantec@abastonet.com.ar
>ICQ: 49465083
>
>
>
>
>-----Mensaje original-----
>De: Sam Critchley [mailto:Sam.Critchley@wcom.com]
>Enviado el: Wednesday, August 28, 2002 6:52 PM
>Para: geopriv@mail.apps.ietf.org
>Asunto: Location Option for DHCP
>
>
>
>Hi,
>
>There was some discussion on the DHC-WG mailing-list over the last
>couple of weeks about a DHCP option to allow the DHCP server to pass its
>location to the DHCP client. This might be useful for enabling LBS on,
>for example, an 802.11 AP where the client device's user is in a roaming
>situation.
>
>The draft is written up (by me) as a personal submission:
>
>http://www.ietf.org/internet-drafts/draft-critchley-dhc-location-option-
>00.txt
>
>Initial feedback seemed mainly to be based around why there would be a
>requirement for such a mechanism, and why wouldn't it be satisfied by
>RFC1712. Feelings (mine at least) on this last are several:
>
>- An 802.11 AP's IP address can be dynamically assigned, and NATed to
>the client, so a DNS-based system might not work well here.
>- Overhead for an ISP where the DNS isn't being run on site.
>- Security and lack of granularity and user-choice in choosing who gets
>to have target information with a DNS-based system.
>
>By the time of submission I hadn't come across the Geopriv requirements,
>but have now read them.
>
>The DHCP option draft does make a mention of precision (or "accuracy"),
>and datum, but nothing on velocity/vector. It also makes a brief (and
>possibly less relevant to DHCP) mention of a cookie-style
>application-level permit warning.
>
>I'd be interested in hearing the comments of people in the geopriv WG on
>this, if you have a moment to read it.
>
>Many thanks in advance,
>
>
>Sam

Regards,

Scott Keagy, CCIE# 3985
Product Manager, Enterprise Voice and Video Business Unit
Cisco Systems, Inc.
tel:+1-408-902-3902
mailto:skeagy@cisco.com
Received on Thu Sep 26 23:37:59 2002