RE: [dhcwg] Geographic position option

[Sam Critchley <[e-mail]>]

Hi Bernie,

Thanks for the help and the comments.

On Fri, 16 Aug 2002, Bernie Volz (EUD) wrote:

> Sam:
>
> If you want to submit this, you need to send it to [e-mail]. (I think they'd prefer an attachment - .txt file - rather than embedded text.)
>
> If you want this to be a DHC WG item, you need to request that (which is perhaps exactly why you send the email). You can submit the draft (as an individual contribution) in any case.

Okay, I guess I'll go with the flow here... although I assume that if I
send it to [e-mail] as an individual contribution then at
least it gets a URL that people can refer to rather than having to include
the text in every message...

>
> My questions regarding this draft are:
> 1. What use is the location of the DHCP server? Isn't there some assumption implied here that the server is "close" to the client and hence the client could use the server's location information as an indication of where it is located (and hence use these location based services)?

Sure, this assumption is definitely there. For example, if someone with a
laptop and a 802.11b card logged on to an 802.11b AP whilst travelling to
a city they weren't familiar with, they could use LBS without having to
manually configure their computer.

>
> However, I don't see that the location of a client and the location of a server are necessarily related. Sure, there are lots of instances where they are physically close (such as an office building). But there are many other indicates where they are not (for example in a cable modem environment). And, how does a client determine this?

I agree that in many cases the DHCP server and client will not be
geographically close (such as in dial-up access or with cable modems as
you say), and it may be preferable to manually input the host's location
at the application level.

The original reason for writing this draft was following some discussion
on an LBS mailing-list, as to whether a similar system would be available
for 802.11 mobile devices as for mobile telephony-style devices, which use
technologies such as E-OTD and A-GPS to derive location. It turned out
that there isn't really a standardised technology to do this, and that
there were two options:

i) Do something in DHCP
ii) Use the NAT setup and a browser environment variable.

The disadvantages of the second are that not everyone has a NAT setup, and
that http isn't the only service which might want to use LBS.

>
> 2. More text on what a client does with this information would be useful. For example, does the client use it as in (1) above or could a client use this to chose a DHCP server (for example, one that it is "closest" to it if it knows its own location)? I'm not sure what value this has, but it would be good to be clear about how clients use this option.

I think probably the first, rather than the second. What I had in mind was
that an application running on the client host would have an interface to
the location information, and would be able to use that when presented
with a "location request" from a LBS server. Unfortunately I'm not really
an expert on the stack required to do that but presumably it would be the
same as many IP-based applications?

>
> 3. Is there any assumption that this positioning information might be extended to other devices? For example, could the DHCP server tell the clients where a DNS server or printer is located? (Why this would be of use I have no idea.) Anyway, can more than one Geographic Position Sentence be specified? If so, how? Please note that DHCP doesn't allow multiple options to be present to represent separate instances of the option (all of the option strings are assumed to be concatenatable).
>
> The reason I ask is that the first parameter is "DHCPPS", so by implication this could mean others might be possible. Though, you do say "which always must have a value of "DHCPPS"".

Well, I only really intended this to be used in a DHCP Server -> Client
relationship in order to satisfy the question (initially) of how a mobile
802.11 host might make use of LBS without manual input of location such as
street address etc. However, it's possible that there would be other uses.
That's also why I put in an option to have a sentence other than "DHCPPS",
just in case someone comes up with another one in the future.

> Personally, I'm not so sure of the importance of this option.

Well, I think there would be demand for this mainly for 802.11a/b/g
roaming at the moment. One of the differences between cellular-based
roaming for mobile devices and 802.11 is that there's no location
mechanism in place for 802.11... the kinds of services this enables are
very popular in, for example, South Korea, where over 1 million
GPS-enabled handsets are in use already on the KDDI CDMA network.

Thanks,


Sam

>
> - Bernie
>
>
> -----Original Message-----
> From: Sam Critchley [mailto:[e-mail]]
> Sent: Friday, August 16, 2002 10:52 AM
> To: [e-mail]
> Subject: [dhcwg] Geographic position option
>
>
>
> Hi,
>
> Included below is a draft proposing an option to allow a DHCP server to
> pass its geographic location to a DHCP client.
>
> >From RFC 2489:
>
> "Preferably, the author will submit the Internet Draft to the DHC Working
> Group,..."
>
> and
>
> "The specification is reviewed by the DHC WG (if it exists) or by the
> IETF."
>
> So, I'd be interested in people's comments on this document. What should I
> do with the document now?
>
> Many thanks,
>
>
> Sam
>
>
> Here is the draft:
>
> ************************************************************************
>
> Network Working Group                                      Sam Critchley
> Internet Draft                                             Worldcom, Inc
>
>                                                             August, 2002
>                                                    Expires January, 2003
>
>
> 	     The Geographic Position Option for DHCP
>            <draft-critchley-dhc-location-option-00.txt>
>
> Status of this Memo
>
>    This document is an Internet-Draft and is subject to all provisions
>    of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six
>    months and may be updated, replaced, or obsoleted by other
>    documents at any time.  It is inappropriate to use Internet-
>    Drafts as reference material or to cite them other than as
>    "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
>
> Abstract
>
>    This document describes a DHCP option in which the geographic
>    position of the DHCP server is passed to the DHCP client in order
>    to allow the client to make use of Location-Based Services.
>
> 1. 	Introduction
>
>    Mobile telephony networks are able to make use of certain
>    technologies which supply the geographic location of a mobile
>    suscriber's handset to a Location-Based Services (LBS) provider. The
>    mobile subscriber is then able to take advantage of such services
>    as point-of-interest (POI) location, mapping, route-determination,
>    traffic services and location-aware mobile instant messaging.
>
>    There is currently no standardised mechanism in place to supply
>    a geographic location to Internet hosts not connected to mobile
>    telephony network, including, but not limited to, hosts connecting
>    using IEEE 802.11x wireless protocols, and those connected to
>    wire-based networks but configured with non-static IP addresses.
>    Consequently, these hosts are more limited in their ability to
>    take advantage of LBS, including having to manually enter a
>    geographic position or street address in many cases.
>
>    This document defines a DHCP option by which a DHCP server can pass
>    its geographical location, in the form of a latitude, longitude and
>    altitude position, to its clients.
>
>    This document does not seek to define a method to allow a host to
>    pass its location to a LBS server, as there are already in place
>    several standards which propose these mechanisms, such as the Mobile
>    Location Protocol (MLP) developed by the Location Interoperability
>    Forum (LIF), although it does make one security recommendation in
>    this area.
>
>    Furthermore, this document does not attempt to propose a mechanism
>    which would perform in the same manner as critical emergency location
>    services such as the Enhanced 911 (E-911) service being implemented
>    in US mobile telephony networks, nor does it propose a mechanism
>    to be used for highly accurate positioning applications, such as that   provided by the Global Positioning System (GPS).
>
>    However, the Geographic Position Option for DHCP does propose a
>    mechanism which, in many cases, will provide a position to the same
>    degree of accuracy as that provided by mobile telephony networks'
>    geographic location mechanisms.
>
> 2. 	The Geographic Position Option for DHCP
>
> 2.1	DHCP Option field definitions.
>
>    This option contains the following fields:
>
>    a) Option Code - TBD
>    b) Option length in bytes
>    c) DHCP Server Geographic Position Sentence
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Code = TBD  |    Length     |  Geographic Position Sentence |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 Geographic Position Sentence                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            . . . .                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            . . . .                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 2.2 	DHCP Server Geographic Position Sentence
>
>    The DHCP Server Geographic Position Sentence takes the form of a
>    comma-separated ASCII string of position terms. This is in some ways
>    similar to the format used in the National Marine Electronics
>    Association's NMEA 0183 and NMEA 2000 standards, commonly used by
>    GPS navigation devices for passing location information to other
>    devices.
>
>    The sentence takes the following form:
>
>    DHCPPS,A,B,C,D,E,F,G,H,I,J,K
>
>    Where the following are field definitions:
>
>    - DHCPPS - DHCP Position Sentence. Indicates to the DHCP client that
>    this is a sentence designed to provide the geographic position of
>    the DHCP server to the DHCP client, as opposed to any other
>    information.
>
>    - A - Latitude. Expressed in decimal degrees, to a maximum of 6
>    decimal places.
>
>    - B - Latitude N/S. Whether the latitude figure expressed is North or
>    South of the equator, expressed simply as the letter "N" or the
>    letter "S" in upper case.
>
>    - C - Longitude. Expressed in decimal degrees, to a maximum of 6
>    decimal places.
>
>    - D - Longitude E/W. Whether the longitude figure expressed is East
>    or West of the Greenwhich Meridian, expressed simply as the letter
>    "E" or the letter "W" in upper case.
>
>    - E - Altitude. The altitude, expressed to a maximum of 2 decimal
>    places, and preceded with a "+" or a "-" symbol to indicate whether
>    the value is above mean sea level (positive) or below mean sea level
>    (negative).
>
>    - F - Altitude unit. The upper-case letter "M" to indicate that the
>    unit is in Metres, or the upper-case letters "FT" to indicate that
>    the unit is in feet.
>
>    - G - Horizontal Accuracy. The horizontal accuracy of the latitude
>    and longitude position obtained by the DHCP client from the DHCP
>    server. Intended to represent the maximum horizontal distance that
>    a DHCP client will be from its DHCP server, and useful, for example,
>    in the case of DHCP scenarios such as IEEE 802.11b setups using
>    bridging, and where the DHCP client can expect to be some distance
>    from the DHCP server. Figure given to a maximum of three decimal
>    places.
>
>    - H - Horizontal Accuracy unit. The upper-case letter "M" to indicate
>    that the unit is in metres, the upper-case letters "KM" to indicate
>    that the unit is in kilometres, the upper-case letters "FT" to
>    indicate that the unit is in feet, or the upper-case letters "ML" to
>    indicate that the unit is in miles.
>
>    - I - Vertical Accuracy. The vertical accuracy of the Altitude
>    position obtained by the DHCP client from the DHCP server. Intended
>    to represent the maximum vertical distance that a DHCP client will be
>    located from its DHCP server, and useful, for example, in the case
>    of network segments located in tall buildings.
>
>    - J - Vertical Accuracy unit. The upper-case letter "M" to indicate
>    that the unit is in metres, the upper-case letters "KM" to indicate
>    that the unit is in kilometres, the upper-case letters "FT" to
>    indicate that the unit is in feet, or the upper-case letters "ML" to
>    indicate that the unit is in miles.
>
>    - K - Geodesic Datum. The standard abbreviated form of the geodesic
>    datum used to calculate position. This term has a default value of
>    "WGS84" should no datum be specified.
>
>    The DHCP Server Geographic Position Sentence would normally have a
>    maximum length of between 49 and 64 bytes, depending on the values
>    used.
>
>    Apart from the first term of the DHCP Server Geographic Position
>    Sentence, which always must have a value of "DHCPPS", and must be
>    present, the presence of a value in all other fields is optional.
>    However, all fields, whether a value is present or not, must be
>    comma-separated. Furthermore, it is understood that a DHCPPS
>    containing few or no values might be of little use in determining
>    the position of the DHCP client.
>
>
> 2.2.1 	Example of a DHCP Server Geographic Position Sentence
>
>    DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84
>
>    This sentence indicates that the DHCP server is located at 52.3742
>    degrees North, 4.8925 degrees East, at 3.12 metres above mean sea
>    level, that the DHCP client is a maximum of 50.9 metres horizontally
>    from the DHCP server, a maximum of 5 metres altitude above or below
>    the DHCP server, and that the datum used to calculate this position
>    was WGS-84.
>
> 2.3	Security Concerns
>
>    Whilst this document does not seek to define a method to allow a
>    host to pass its location to a LBS server, it does note that
>    there are possible security concerns involved in the location of
>    an Internet host being passed to an LBS server. In the case of mobile
>    telephony networks, most subscriber locations are passed to an LBS
>    server from a mobile provider's location server, not directly from
>    the mobile handset, and the list of permitted LBS servers is strictly
>    controlled. However, in the case of a Geographic Position option for
>    DHCP, this security infrastructure may not be in place, and it is
>    therefore recommended that any client application supplying a
>    DHCP-acquired position to an LBS server should implement an adequate
>    security mechanism to protect users from any possible wrongdoing.
>    Such mechanisms might include implementing a list of permitted LBS
>    servers, popup alerts when passing a host's location to an LBS
>    server, or the ability to turn on/off the passing of location
>    information.
>
>
> 3.	Author's Address
>
>    Sam Critchley
>    Worldcom EMEA Network Service
>    Joan Muyskenweg 22
>    1096 CJ Amsterdam
>    The Netherlands
>
>    Phone: [phone]
>    Email: [e-mail]
>
> ***************************************************************************
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>


******************************************************
Sam Critchley           Technology Integration Manager
                        Network Services EMEA
[e-mail]  Worldcom
                       	Joan Muyskenweg 22
Tel: [phone]    1096 CJ Amsterdam
                        The Netherlands
******************************************************










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