< draft-ietf-geopriv-dhcp-lci-option-02.txt   draft-ietf-geopriv-dhcp-lci-option-03.txt >
Internet Engineering Task Force J. Polk Internet Engineering Task Force J. Polk
Internet Draft J. Schnizlein Internet Draft J. Schnizlein
Expiration: Feb 21st, 2004 M. Linsner Expiration: June 8th, 2004 M. Linsner
File: draft-ietf-geopriv-dhcp-lci-option-02.txt Cisco Systems File: draft-ietf-geopriv-dhcp-lci-option-03.txt Cisco Systems
Dynamic Host Configuration Protocol Option for Dynamic Host Configuration Protocol Option for
Location Configuration Information for GEOPRIV Coordinate-based Location Configuration Information
Aug 21st, 2003 December 8th, 2003
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html. at http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies a Dynamic Host Configuration Protocol Option This document specifies a Dynamic Host Configuration Protocol Option
for the geographic location of the client. The Location for the coordinate-based geographic location of the client. The
Configuration Information (LCI) includes latitude, longitude, and Location Configuration Information (LCI) includes latitude,
altitude, with resolution indicators for each. The reference datum longitude, and altitude, with resolution indicators for each. The
for these values is also included. reference datum for these values is also included.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Rationale . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Rationale . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Changes from version -00 . . . . . . . . . . . . . . . . 4 2. Location Configuration Information (LCI) Elements . . . . . . 4
2. Location Configuration Information (LCI) Elements . . . . . . 5 2.1 Elements of the Location Configuration Information . . . 5
2.1 Elements of the Location Configuration Information . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . 8
3. Purpose of Resolution Value per La/Lo/Alt Elements . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Appendix Calculations of Imprecision possible with the DHC LCI . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 A.1 LCI of "White House" (Example 1) . . . . . . . . . . . . 9
Appendix Calculations of Imprecision possible with the DHC LCI . 10 A.2 LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 12
A.1 LCI of "White House" (Example 1) . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . 12
A.2 LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 13 7. Informational References . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Author Information . . . . . . . . . . . . . . . . . . . . . 13
8. Author Information . . . . . . . . . . . . . . . . . . . . . 14
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies a Dynamic Host Configuration Protocol [1] This document specifies a Dynamic Host Configuration Protocol [1]
Option for the geographic location of the client, to be provided by Option for coordinate-based geographic location of the client, to be
the server. provided by the server.
The DHCP server is assumed to have determined the location from the The DHCP server is assumed to have determined the location from the
Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt
1) in [2]. In order to translate the circuit (switch port 1) in [2]. In order to translate the circuit (switch port
identifier) into a location, the DHCP server is assumed to have identifier) into a location, the DHCP server is assumed to have
access to a service that maps from circuit-ID to the location at access to a service that maps from circuit-ID to the location at
which the circuit connected to that port terminates in the building; which the circuit connected to that port terminates in the building;
for example, the location of the wall jack. for example, the location of the wall jack.
An important feature of this specification is that location An important feature of this specification is that after the
information is completely under control of the end device rather relevant DHC exchanges have taken place, the location information
than stored in an outside service for retrieval by the end device. is stored on the end device rather than somewhere else, where
Storage outside the end device during times of emergency can cause retrieving it might be difficult in practice.
unnecessary delay, or failure during communication.
Another important feature of this LCI is its inclusion of a Another important feature of this LCI is its inclusion of a
resolution parameter for each of the dimensions of location. The resolution parameter for each of the dimensions of location.
GEOPRIV working group has a stated requirement [3] to enable Because this resolution parameter need not apply to all dimensions
decreasing the precision of a location element. Because this equally, a resolution value is included for each of the 3 location
resolution parameter need not apply to all dimensions equally, a elements.
resolution value is included for each of the 3 location elements.
This resolution method provides a natural ability for the device to This resolution method provides a natural ability for the device to
hide from the center point of the bounding area as this resolution hide from the center point of the bounding area as this resolution
method is determined via the inherent effects of binary method is determined via the inherent effects of binary
representation. representation; or, this resolution mechanism could be used to
define a geographic area. This would be useful when a group of
clients would want to be known as the same geo-location, possibly
all users in a room of a building would use the same LCI value.
Resolution does not define how Geographic Privacy policy should relate to precision. Then the using application could use that value as a key for lookup
in another data source. This is similar to one of the mechanisms
utilized in the North American E911 systems today.
Resolution does not define how Geographic Privacy policy should
relate to precision.
The resulting location information using this resolution method is a The resulting location information using this resolution method is a
small fixed length Configuration Information that can be easily small fixed length Configuration Information that can be easily
carried in protocols, such as DHCP, which have limited packet size carried in protocols, such as DHCP, which have limited packet size
because this LCI is only 18 bytes long. because this LCI is only 18 bytes long.
Finally, in the appendix this document provides some arithmetic Finally, the appendix this document provides some arithmetic
examples of just how the imprecision can be introduced in any or all examples of the implication of different resolution values on the
of the La/Lo/Alt values without the IP device needing to be La/Lo/Alt.
preprogrammed with bogus location information, and just how
imprecise the La/Lo/Alt values can be.
This document does not cover any policy regarding the use of this
other than a few as potential suggestions to convey the meaning
intended by the document.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [4]. document are to be interpreted as described in [3].
1.2 Motivation 1.2 Motivation
As applications such as IP Telephony are replacing conventional As applications such as IP Telephony are replacing conventional
telephony, users are expecting the same (or greater) level of telephony, users are expecting the same (or greater) level of
services with the new technology. One service offered by services with the new technology. One service offered by
conventional telephony that is missing, in any standardized fashion, conventional telephony that is missing, in any standardized fashion,
within IP Telephony is for a user to be automatically located by within IP Telephony is for a user to be automatically located by
emergency responders, in a timely fashion, when the user summons emergency responders, in a timely fashion, when the user summons
help (by dialing 911 in North America, for example). Unless strict help (by dialing 911 in North America, for example). Unless strict
administrative rules are followed, the mobility of a wired Ethernet administrative rules are followed, the mobility of a wired Ethernet
device within a campus negates any opportunity for an emergency device within a campus negates any opportunity for an emergency
responder to locate the device with any degree of expediency. Users responder to locate the device with any degree of expediency. Users
do not want to give up the mobility IP Telephony offers. Informing do not want to give up the mobility IP Telephony offers. Informing
the host device of its geo-location at host configuration time will the host device of its geo-location at host configuration time will
allow the device to utilize this geo-location information to inform allow the device to utilize this geo-location information to inform
others of it's current geo-location, if the user and/or application others of it's current geo-location, if the user and/or application
so desires. so desires.
The goal of this option is to enable a wired Ethernet host to The goal of this option is to enable a wired Ethernet host to
provide its location to an emergency responder, as one example. obtain its location, which it could provide to an emergency
responder, as one example.
Wireless hosts can utilize this option to gain knowledge of the Wireless hosts can utilize this option to gain knowledge of the
location of the radio access point used during host configuration, location of the radio access point used during host configuration,
but will need some more exotic mechanisms, maybe GPS, or maybe a but would need some more exotic mechanisms, maybe GPS, or maybe a
future DHCP option, which includes a list of geo-locations like that future DHCP option, which includes a list of geo-locations like that
defined here, which has the locations of the radio access points defined here, containing the locations of the radio access points
that are close to the client. that are close to the client.
1.3 Rationale 1.3 Rationale
Within the LCI described here, Latitude and Longitude are Within the LCI described here, Latitude and Longitude are
represented in fixed-point 2s-complement binary degrees, for the represented in fixed-point 2s-complement binary degrees, for the
economy of a smaller option size compared to a string encoding of economy of a smaller option size compared to a string encoding of
digits in [5]. The integer parts of these fields are 9 bits long to digits in [7]. The integer parts of these fields are 9 bits long to
accommodate +/- 180 degrees. The fractional part is 25 bits long, accommodate +/- 180 degrees. The fractional part is 25 bits long,
better than the precision of 7 decimal digits. Each parameter is 40 better than the precision of 7 decimal digits. Each parameter is 40
bits total, in length. bits total, in length.
Altitude is determined by the Altitude Type (AT) indicated by the Altitude is determined by the Altitude Type (AT) indicated by the
AT field, which is 4 bits long. Two Altitude Types are defined AT field, which is 4 bits long. Two Altitude Types are defined
here, meters (code=1) and floors (code=2), both of which are 2s- here, meters (code=1) and floors (code=2), both of which are 2s-
complement fixed-point with 8 bits of fraction. Additional complement fixed-point with 8 bits of fraction. Additional
Altitude Types MAY be assigned by IANA. The "floors" Altitude Type Altitude Types MAY be assigned by IANA. The "floors" Altitude Type
is provided because altitude in meters may not be known within a is provided because altitude in meters may not be known within a
building, and a floor indication may be more useful. building, and a floor indication may be more useful.
GPS systems today can use WGS84 for horizontal and vertical datums, GPS systems today can use WGS84 for horizontal and vertical datums,
[9] defines WGS84 as a three-dimensional datum. For other datum [6] defines WGS84 as a three-dimensional datum. For other datum
values that do not include a vertical component, both the horizontal values that do not include a vertical component, both the horizontal
and vertical datum of reference will be specified in the IANA and vertical datum of reference will be specified in the IANA
record. record.
Each of these 3 elements is preceded by an accuracy sub-field of 6 Each of these 3 elements is preceded by an accuracy sub-field of 6
bits, indicating the number of bits of resolution. This resolution bits, indicating the number of bits of resolution. This resolution
sub-field accommodates the GEOPRIV requirement [3] to easily adjust sub-field accommodates the desire by some to easily adjust
the precision of a reported location. Contents beyond the claimed the precision of a reported location. Contents beyond the claimed
resolution MAY be randomized to obscure greater precision that might resolution MAY be randomized to obscure greater precision that might
be available. be available.
1.4 Changes from version -00
Here is a list of changes to version -01 from -00:
- inadvertently left out the Acknowledgements section; corrected
that error
- added the NAD83 Datum to the list in section 2.1, and to the list
put forth for IANA registration
Here is a list of changes to version -02 from -01:
- changed Measurement Unit to Altitude Type to relieve some
confusion regarding the use of Floors in this field
- added some text explaining GPS uses of WGS 84
- Clarified the text to eliminate ôpairingö of datum, but requiring
both horizontal and vertical where the reference datum is not 3-D,
as it is in WGS 84.
- added a line to each *Res description section that it isn't to be
used to provide or enforce policy by the domain (which is
contradictory to Geopriv requirements of a single point of policy
injection)
- Split the Datum NAD83 into two different datum registries: One
adding a vertical datum (NVAD88) for land (not near Tidal water),
and added a new NAD83 datum pair (currently #5) to include NAD83
when used on the water/sea/ocean - with a vertical datum of MLLW
- Deleted all text regarding policy (through the use of the *Res
field values) not being injected at two places (Geopriv
requirements state this should only occur at one location)
- augmented the IANA section to include the Horizontal and Vertical
Datum pairings for #s 1, 2 & 3
- Deleted the all references to datums ED50 and ED87 because Carl
Reed established that neither has a "well known" vertical datum to
pair either with
2. DHC Location Configuration Information Elements 2. DHC Location Configuration Information Elements
DHCP is a binary Protocol; GEOPRIV is text-based. Since most DHCP is a binary Protocol; using protocols of LCI are likely to be
coordinate systems translate fairly easily between binary-based and text based. Since most coordinate systems translate fairly easily
text-based location output (even emergency services within the US), between binary-based and text-based location output (even emergency
translation/conversion is a non-issue with DHCP's binary format. services within the US), translation/conversion is a non-issue with
DHCP's binary format.
This binary format provides a fortunate benefit in a mechanism for This binary format provides a fortunate benefit in a mechanism for
making a true/correct location coordinate imprecise. It further making a true/correct location coordinate imprecise. It further
provides the capability to have this binary representation be provides the capability to have this binary representation be
deterministically imprecise. deterministically imprecise.
The proposed LCI format is: The LCI format is as follows:
0 1 2 3 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 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 | 16 | LaRes | Latitude + | Code TBD | 16 | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | + | Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | | Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT | AltRes | Altitude | | AT | AltRes | Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt (cont'd) | Datum | | Alt (cont'd) | Datum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1 Elements of the Location Configuration Information 2.1 Elements of the Location Configuration Information
Code TBD: The code for this DHCP option is TBD by IANA. Code TBD: The code for this DHCP option.
16: The length of this option is 16 bytes. 16: The length of this option is 16 bytes.
LaRes: Latitude resolution. 6 bits indicating the number LaRes: Latitude resolution. 6 bits indicating the number
of valid bits in the fixed-point value of Latitude. of valid bits in the fixed-point value of Latitude.
This value is the number of high-order Latitude bits that should be This value is the number of high-order Latitude bits that should be
considered valid. Any bits entered to the right of this limit considered valid. Any bits entered to the right of this limit
should not be considered valid and might be purposely false, or should not be considered valid and might be purposely false, or
zeroed by the sending. zeroed by the sending.
The examples below in section 4.0, are to illustrate that a smaller The examples below in section 4.0, are to illustrate that a smaller
value in the resolution field increases the area within which the value in the resolution field increases the area within which the
device is located (without deception). device is located).
LaRes does not define how Geographic Privacy policy should relate to LaRes does not define how Geographic Privacy policy should relate to
precision. precision.
Values of resolution above decimal 34 are Undefined and reserved Values of resolution above decimal 34 are Undefined and reserved
because that is the largest number of bits in the Latitude field. because that is the largest number of bits in the Latitude field.
Latitude: a 34 bit fixed point value consisting of 9 bits of integer Latitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Latitude SHOULD be normalized to and 25 bits of fraction. Latitude SHOULD be normalized to
within +/- 90 degrees. Geo-location formats provide for within +/- 90 degrees. Positive numbers are north of the
positive numbers to be north of the equator and negative equator and negative numbers are south of the equator.
numbers to be south of the equator.
A value of 2 in the LaRes field indicates a precision of no greater A value of 2 in the LaRes field indicates a precision of no greater
than 1/6th that of the globe (detailed in the first example in than 1/6th that of the globe (detailed in the first example in
section 4.0). A value of 34 in the LaRes field indicates a section 4.0). A value of 34 in the LaRes field indicates a
precision of about 3.11 mm in Latitude. precision of about 3.11 mm in Latitude at the equator.
LoRes: Longitude resolution. 6 bits indicating the number of LoRes: Longitude resolution. 6 bits indicating the number of
valid bits in the fixed-point value of Longitude. valid bits in the fixed-point value of Longitude.
This value is the number of high-order Longitude bits that should be This value is the number of high-order Longitude bits that should be
considered valid. Any bits entered to the right of this limit considered valid. Any bits entered to the right of this limit
should not be considered valid and might be purposely false, or should not be considered valid and might be purposely false, or
zeroed by the sending. zeroed by the sending.
LoRes does not define how Geographic Privacy policy should relate to LoRes does not define how Geographic Privacy policy should relate to
precision. precision.
Values above decimal 34 are undefined and reserved. Values above decimal 34 are undefined and reserved.
Longitude: a 34 bit fixed point value consisting of 9 bits of Longitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction. Longitude SHOULD be integer and 25 bits of fraction. Longitude SHOULD be
normalized to within +/- 180 degrees. Geo-location normalized to within +/- 180 degrees. Positive values are
formats provide for positive numbers to be east of the East of the prime meridian and negative (2s complement)
prime meridian and negative (2s complement) numbers to be numbers are West of the prime meridian.
west of the prime meridian.
Entering a value of 2 in the LoRes field will result in the A value of 2 in the LoRes field indicates precision of no greater
precision of no greater than 1/6th that of the globe (see first than 1/6th that of the globe (see first example in section 4.0). A
example in section 4.0 for more here). A value of 34 in the LoRes value of 34 in the LoRes field indicates a precision of about
field indicates a precision of about 2.42 mm in longitude (at the 2.42 mm in longitude (at the equator). Because lines of longitude
equator). Because lines of longitude converge at the poles, the converge at the poles, the distance is smaller (better precision)
distance is smaller (resolution greater) for locations away from the for locations away from the equator.
equator.
Altitude: A 30 bit value defined by the AT field Altitude: A 30 bit value defined by the AT field
AltRes: Altitude resolution. 6 bits indicating the number of valid AltRes: Altitude resolution. 6 bits indicating the number of valid
bits in the altitude. Values above 30 (decimal) are bits in the altitude. Values above 30 (decimal) are
undefined and reserved. undefined and reserved.
AltRes does not define how Geographic Privacy policy should relate AltRes does not define how Geographic Privacy policy should relate
to precision. to precision.
skipping to change at page 8, line 34 skipping to change at page 7, line 33
Floors located below ground level could be represented by negative Floors located below ground level could be represented by negative
values. values.
Larger values represent floors that are above (higher in altitude) Larger values represent floors that are above (higher in altitude)
floors with lower values. floors with lower values.
The AltRes field SHOULD be set to maximum precision when AT = 2 The AltRes field SHOULD be set to maximum precision when AT = 2
(floors) when a floor value is included in the DHCP Reply, or (floors) when a floor value is included in the DHCP Reply, or
the AT = 0 to denote the floor isn't known. the AT = 0 to denote the floor isn't known.
Any additional Geopriv Altitude Types(s) to be defined for use via Any additional LCI Altitude Types(s) to be defined for use via
this DHC Option MUST be done through a Standards Track RFC. this DHC Option MUST be done through a Standards Track RFC.
Datum: The Map Datum used for the coordinates given in this Option Datum: The Map Datum used for the coordinates given in this Option
The datum must include both a horizontal and a vertical reference. The datum must include both a horizontal and a vertical reference.
Since the WGS 84 reference datum is three-dimensional, it includes Since the WGS 84 reference datum is three-dimensional, it includes
both. For any additional datum parameters, the datum codepoint must both. For any additional datum parameters, the datum codepoint must
specify both horizontal datum and vertical datum references. specify both horizontal datum and vertical datum references.
The Datum byte has 255 possibilities, of which 3 are to be The Datum byte has 256 possibilities, of which 3 are to be
registered with IANA by this document (all derived from registered with IANA by this document (all derived from
specification in [8]): specification in [5]):
1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS 1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS
Code 4327, Prime Meridian Name: Greenwich Code 4327, Prime Meridian Name: Greenwich
2: NAD83 - North American Datum 1983, CRS Code 4269, Prime 2: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical Meridian Name: Greenwich; The associated vertical
datum is the North American Vertical Datum of 1988 datum is the North American Vertical Datum of 1988
(NAVD88) (NAVD88)
This datum pair to be used when referencing
This datum pair would be used when referencing
locations on land, not near tidal water (which would locations on land, not near tidal water (which would
use Datum = 3 below) use Datum = 3 below)
3: NAD83 - North American Datum 1983, CRS Code 4269, Prime 3: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical Meridian Name: Greenwich; The associated vertical
datum is Mean Lower Low Water (MLLW) datum is Mean Lower Low Water (MLLW)
This datum pair would be used when referencing This datum pair to be used when referencing
locations on water/sea/ocean locations on water/sea/ocean
Any additional Geopriv datum(s) to be defined for use via this DHC Any additional LCI datum(s) to be defined for use via this DHC
Option MUST be done through a Standards Track RFC. Option MUST be done through a Standards Track RFC.
3. Purpose of Resolution Value per La/Lo/Alt Element 3. Security Considerations
GEOPRIV specified the requirement [3] that any location expressed
from or proxied on behalf of a device through the GEOPRIV Protocol
can have the accuracy or precision of that device's location
limited. The owner of the device, or the domain of the device
determines the policy for divulging how precise the location is for
any/all given requesters of that device's location.
As stated in section 2.1, these resolution fields are not intended
to specify policy towards the endpoint. However, the *Res fields
can provide a quite useful feature by providing to the endpoint the
maximum precision of location in the DHCP Reply.
4. Security Considerations
Where critical decisions might be based on the value of this Where critical decisions might be based on the value of this
GeoLoc option, DHCP authentication in [7] SHOULD be used to GeoLoc option, DHCP authentication in [4] SHOULD be used to
protect the integrity of the DHCP options. protect the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and eavesdropper who can monitor the link between the DHCP server and
requesting client can discover this LCI. requesting client can discover this LCI.
5. IANA Considerations To minimize the unintended exposure of location information, the LCI
option SHOULD be returned by DHCP servers only when the DHCP client
has included this option in its 'parameter request list' (section
3.5 [1]).
The DHCP option code for the GeoLoc option is TBD. When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
This document calls for the IANA registration of the following: 4. IANA Considerations
AT = 1 is meters of Altitude defined by the vertical datum IANA has assigned a DHCP option code of TBD for the GeoLoc option
specified. Semantics are included in this document (section defined in this document.
2.1)
AT = 2 is building Floors of Altitude. Semantics are included in The GeoLoc Option defines two fields for which IANA is to maintain
this document (section 2.1) a registry: The Altitude (AT) field (see Section 2) and the Datum
field (see Section 2). The datum indicator MUST include
specification of both horizontal and vertical datum. New values
for the Altitude (AT) field are assigned through "Standards Action"
[RFC 2434]. The initial values of the Altitude registry are as
follows:
Datum = 1 is denoting the vertical datum WGS 84 as defined by the AT = 1 meters of Altitude defined by the vertical datum
specified.
AT = 2 building Floors of Altitude.
Datum = 1 denotes the vertical datum WGS 84 as defined by the
EPSG as their CRS Code 4327; CRS Code 4327 also specifies EPSG as their CRS Code 4327; CRS Code 4327 also specifies
WGS 84 as the vertical datum WGS 84 as the vertical datum
Datum = 2 is denoting the vertical datum NAD83 as defined by the Datum = 2 denotes the vertical datum NAD83 as defined by the
EPSG as their CRS Code 4269; North American Vertical Datum EPSG as their CRS Code 4269; North American Vertical Datum
of 1988 (NAVD88) is the associated vertical datum for NAD83 of 1988 (NAVD88) is the associated vertical datum for NAD83
The semantics of this datum pair (#2) is presented in Datum = 3 denotes the vertical datum NAD83 as defined by the
section 2.1 above
Datum = 3 is denoting the vertical datum NAD83 as defined by the
EPSG as their CRS Code 4269; Mean Lower Low Water (MLLW) is EPSG as their CRS Code 4269; Mean Lower Low Water (MLLW) is
the associated vertical datum for NAD83 the associated vertical datum for NAD83
The semantics of this datum pair (#3) is presented in Any additional LCI datum(s) to be defined for use via this DHC
section 2.1 above Option MUST be done through a Standards Track RFC.
6. Acknowledgements 5. Acknowledgements
The authors would like to thank Patrik Falstrom, Ralph Droms, Ted The authors would like to thank Patrik Falstrom, Ralph Droms, Ted
Hardie, Jon Peterson and Nadine Abbott for their inputs and Hardie, Jon Peterson and Nadine Abbott for their inputs and
constructive comments regarding this document. Additionally, the constructive comments regarding this document. Additionally, the
authors would like to thank Greg Troxel for the education on authors would like to thank Greg Troxel for the education on
vertical datums, and to Carl Reed. vertical datums, and to Carl Reed.
Appendix: Calculations of Imprecision possible with the DHC LCI Appendix: Calculations of Imprecision possible with the DHC LCI
The following examples for two different locations demonstrate The following examples for two different locations demonstrate
skipping to change at page 12, line 48 skipping to change at page 11, line 45
centimeters (50mm x 39mm). centimeters (50mm x 39mm).
If: LaRes is expressed as value 34 (0x22 or 100010) and LoRes is If: LaRes is expressed as value 34 (0x22 or 100010) and LoRes is
expressed as value 34 (0x22 or 100010), then it would describe a expressed as value 34 (0x22 or 100010), then it would describe a
geo-location area that is latitude 38.8986800 north to latitude geo-location area that is latitude 38.8986800 north to latitude
38.8986802 and extends from -77.0372300 degrees to -77.0372296 38.8986802 and extends from -77.0372300 degrees to -77.0372296
degrees longitude. This is an area of approximately 7.5 square degrees longitude. This is an area of approximately 7.5 square
millimeters (3.11mm x 2.42mm). millimeters (3.11mm x 2.42mm).
In the (White House) example, the requirement of emergency In the (White House) example, the requirement of emergency
responders in North America via their NENA Model Legislation [6], responders in North America via their NENA Model Legislation [8],
could be met by a LaRes value of 21 and a LoRes value of 20. could be met by a LaRes value of 21 and a LoRes value of 20.
This would yield a geo-location that is latitude 38.8984375 north This would yield a geo-location that is latitude 38.8984375 north
to latitude 38.8988616 north and longitude -77.0371094 to to latitude 38.8988616 north and longitude -77.0371094 to
longitude -77.0375977. This is an area of approximately 89 feet longitude -77.0375977. This is an area of approximately 89 feet
by 75 feet or 6669 square feet, which is very close to the 7000 by 75 feet or 6669 square feet, which is very close to the 7000
square feet asked for by NENA. In this example a service square feet asked for by NENA. In this example a service
provider could enforce that a device send a Location provider could enforce that a device send a Location
Configuration Information with this minimum amount of resolution Configuration Information with this minimum amount of resolution
for this particular location when calling emergency services. for this particular location when calling emergency services.
skipping to change at page 14, line 5 skipping to change at page 12, line 49
For the accuracy of the latitude and longitude, the best For the accuracy of the latitude and longitude, the best
information available to us was supplied by a generic mapping information available to us was supplied by a generic mapping
service that shows a single geo-loc for all of the Sears Tower. service that shows a single geo-loc for all of the Sears Tower.
Therefore we are going to show LaRes as value 18 (0x12 or 010010) Therefore we are going to show LaRes as value 18 (0x12 or 010010)
and LoRes as value 18 (0x12 or 010010). This would be describing and LoRes as value 18 (0x12 or 010010). This would be describing
a geo-location area that is latitude 41.8769531 to latitude a geo-location area that is latitude 41.8769531 to latitude
41.8789062 and extends from -87.6367188 degrees to -87.6347657 41.8789062 and extends from -87.6367188 degrees to -87.6347657
degrees longitude. This is an area of approximately 373412 degrees longitude. This is an area of approximately 373412
square feet (713.3 ft. x 523.5 ft.). square feet (713.3 ft. x 523.5 ft.).
7. References 6. Normative References
[1] Droms R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997 March 1997
[2] Patrick M., "DHCP Relay Agent Information Option", RFC 3046, [2] Patrick M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001 January 2001
[3] Cuellar J., Morris J., Mulligan D., "GEOPRIV Requirements", [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
[4] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997 Levels", RFC 2119, March 1997
[5] Farrell C., Schulze M., Pleitner S. and Baldoni D., "DNS [4] Droms R., "Authentication for DHCP Messages", RFC 3118, June
Encoding of Geographical Location", RFC 1712, November 1994.
[6] National Emergency Number Association (NENA) www.nena.org
NENA Technical Information Document on Model Legislation
Enhanced 911 for Multi-Line Telephone Systems
(http://www.nena.org/9%2D1%2D1techstandards/TechInfoDocs/
MLTS_ModLeg_Nov200.PDF)
[7] Droms R., "Authentication for DHCP Messages", RFC 3118, June
2001 2001
[8] European Petroleum Survey Group, http://www.epsg.org/ and [5] European Petroleum Survey Group, http://www.epsg.org/ and
http://www.ihsenergy.com/epsg/geodetic2.html http://www.ihsenergy.com/epsg/geodetic2.html
[9] World Geodetic System 1984 (WGS 84), MIL-STD-2401, [6] World Geodetic System 1984 (WGS 84), MIL-STD-2401,
http://164.214.2.59/publications/specs/printed/WGS84/wgs84.html http://164.214.2.59/publications/specs/printed/WGS84/wgs84.html
and http://www.wgs84.com/ and http://www.wgs84.com/
7. Informational References
[7] Farrell C., Schulze M., Pleitner S. and Baldoni D., "DNS
Encoding of Geographical Location", RFC 1712, November 1994.
[8] National Emergency Number Association (NENA) www.nena.org
NENA Technical Information Document on Model Legislation
Enhanced 911 for Multi-Line Telephone Systems
(http://www.nena.org/9%2D1%2D1techstandards/TechInfoDocs/
MLTS_ModLeg_Nov200.PDF)
8. Author Information 8. Author Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 USA Richardson, Texas 75082 USA jmpolk@cisco.com
jmpolk@cisco.com
John Schnizlein John Schnizlein
Cisco Systems Cisco Systems
9123 Loughran Road 9123 Loughran Road
Fort Washington, MD 20744 USA Fort Washington, MD 20744 USA john.schnizlein@cisco.com
john.schnizlein@cisco.com
Marc Linsner Marc Linsner
Cisco Systems Cisco Systems
Marco Island, FL 34145 USA Marco Island, FL 34145 USA marc.linsner@cisco.com
marc.linsner@cisco.com Intellectual Property Statement
9. Full Copyright Statement The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
"Copyright (C) The Internet Society (February 23rd, 2001). "Copyright (C) The Internet Society (February 23rd, 2001).
All Rights Reserved. All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
skipping to change at page 15, line 42 skipping to change at page 14, line 53
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE." PURPOSE."
The Expiration date for this Internet Draft is: The Expiration date for this Internet Draft is:
Feb. 8, 2004 June 8th, 2004
 End of changes. 60 change blocks. 
182 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/