summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3825.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3825.txt')
-rw-r--r--doc/rfc/rfc3825.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc3825.txt b/doc/rfc/rfc3825.txt
new file mode 100644
index 0000000..1f3fbc5
--- /dev/null
+++ b/doc/rfc/rfc3825.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group J. Polk
+Request for Comments: 3825 J. Schnizlein
+Category: Standards Track M. Linsner
+ Cisco Systems
+ July 2004
+
+
+ Dynamic Host Configuration Protocol Option for
+ Coordinate-based Location Configuration Information
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+ This document specifies a Dynamic Host Configuration Protocol Option
+ for the coordinate-based geographic location of the client. The
+ Location Configuration Information (LCI) includes latitude,
+ longitude, and altitude, with resolution indicators for each. The
+ reference datum for these values is also included.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 1]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Location Configuration Information (LCI) Elements. . . . . . . 4
+ 2.1. Elements of the Location Configuration Information . . . 5
+ 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
+ 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ Appendix Calculations of Imprecision possible with the DHC LCI . . 10
+ A.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 10
+ A.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 12
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 13
+ 6.2. Informational References . . . . . . . . . . . . . . . . 14
+ 7. Author Information . . . . . . . . . . . . . . . . . . . . . . 14
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
+
+1. Introduction
+
+ This document specifies a Dynamic Host Configuration Protocol [1]
+ Option for the coordinate-based geographic location of the client, to
+ be provided by the server.
+
+ The DHCP server is assumed to have determined the location from the
+ Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt
+ 1) in [2]. In order to translate the circuit (switch port
+ identifier) into a location, the DHCP server is assumed to have
+ access to a service that maps from circuit-ID to the location at
+ which the circuit connected to that port terminates in the building,
+ for example, the location of the wall jack.
+
+ An important feature of this specification is that after the relevant
+ DHC exchanges have taken place, the location information is stored on
+ the end device rather than somewhere else, where retrieving it might
+ be difficult in practice.
+
+ Another important feature of this LCI is its inclusion of a
+ resolution parameter for each of the dimensions of location. Because
+ this resolution parameter need not apply to all dimensions equally, a
+ resolution value is included for each of the 3 location elements.
+
+ Resolution does not define Geographic Privacy policy.
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 2]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ The resulting location information using this resolution method is a
+ small fixed length Configuration Information that can be easily
+ carried in protocols, such as DHCP, which have limited packet size
+ because this LCI is only 18 bytes long.
+
+ Finally, the appendix of this document provides some arithmetic
+ examples of the implication of different resolution values on the
+ La/Lo/Alt.
+
+1.1. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [3].
+
+1.2. Motivation
+
+ As applications such as IP Telephony are replacing conventional
+ telephony, users are expecting the same (or greater) level of
+ services with the new technology. One service offered by
+ conventional telephony that is missing in any standardized fashion
+ within IP Telephony is for a user to be automatically located by
+ emergency responders, in a timely fashion, when the user summons help
+ (by dialing 911 in North America, for example). Unless strict
+ administrative rules are followed, the mobility of a wired Ethernet
+ device within a campus negates any opportunity for an emergency
+ responder to locate the device with any degree of expediency. Users
+ do not want to give up the mobility IP Telephony offers. Informing
+ the host device of its geo-location at host configuration time will
+ allow the device to utilize this geo-location information to inform
+ others of its current geo-location, if the user and/or application so
+ desires.
+
+ The goal of this option is to enable a wired Ethernet host to 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
+ location of the radio access point used during host configuration,
+ but would need some more exotic mechanisms, maybe GPS, or maybe a
+ future DHCP option, which includes a list of geo-locations like that
+ defined here, containing the locations of the radio access points
+ that are close to the client.
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 3]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+1.3. Rationale
+
+ Within the LCI described here, Latitude and Longitude are represented
+ in fixed-point 2s-complement binary degrees, for the economy of a
+ smaller option size compared to a string encoding of digits in [7].
+ The integer parts of these fields are 9 bits long to accommodate +/-
+ 180 degrees. The fractional part is 25 bits long, better than the
+ precision of 7 decimal digits. The length of each field is 40 bits,
+ 34 of which is the sum of the integer (9) and fractional (25) bits,
+ plus 6 bits of resolution.
+
+ Altitude is determined by the Altitude Type (AT) indicated by the 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-complement
+ fixed-point with 22 bits of integer part and 8 bits of fractional
+ part. Additional Altitude Types MAY be assigned by IANA. The
+ "floors" Altitude Type is provided because altitude in meters may not
+ be known within a building, and a floor indication may be more
+ useful.
+
+ GPS systems today can use WGS84 for horizontal and vertical datums;
+ [6] defines WGS84 as a three-dimensional datum. For other datum
+ values that do not include a vertical component, both the horizontal
+ and vertical datum of reference will be specified in the IANA record.
+
+ Each of these 3 elements begins with an accuracy sub-field of 6 bits,
+ indicating the number of bits of resolution. This resolution sub-
+ field accommodates the desire to easily adjust the precision of a
+ reported location. Contents beyond the claimed resolution MAY be
+ randomized to obscure greater precision that might be available.
+
+2. DHC Location Configuration Information Elements
+
+ DHCP is a binary Protocol; using protocols of LCI are likely to be
+ text based. Since most coordinate systems translate easily between
+ binary-based and text-based location output (even emergency 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
+ making a true/correct location coordinate imprecise. It further
+ provides the capability to have this binary representation be
+ deterministically imprecise.
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 4]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ The LCI format is as follows:
+
+ 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 123 | 16 | LaRes | Latitude +
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Latitude (cont'd) | LoRes | +
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Longitude |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AT | AltRes | Altitude |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Alt (cont'd) | Datum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1. Elements of the Location Configuration Information
+
+ Code 123: The code for this DHCP option.
+
+ 16: The length of this option is 16 bytes.
+
+ LaRes: Latitude resolution. 6 bits indicating the number of
+ valid bits in the fixed-point value of Latitude.
+
+ This value is the number of high-order Latitude bits that should be
+ considered valid. Any bits entered to the right of this limit should
+ not be considered valid and might be purposely false, or zeroed by
+ the sender.
+
+ The examples in the appendix illustrate that a smaller value in the
+ resolution field increases the area within which the device is
+ located.
+
+ LaRes does not define Geographic Privacy policy.
+
+ Values above decimal 34 are undefined and reserved.
+
+ Latitude: a 34 bit fixed point value consisting of 9 bits of integer
+ and 25 bits of fraction. Latitude SHOULD be normalized to
+ within +/- 90 degrees. Positive numbers are north of the
+ equator and negative numbers are south of the equator.
+
+ A value of 2 in the LaRes field indicates a precision of no greater
+ than 1/6th that of the globe (in the first example of the appendix).
+ A value of 34 in the LaRes field indicates a precision of about 3.11
+ mm in Latitude at the equator.
+
+
+
+
+Polk, et al. Standards Track [Page 5]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ LoRes: Longitude resolution. 6 bits indicating the number of
+ valid bits in the fixed-point value of Longitude.
+
+ This value is the number of high-order Longitude bits that should be
+ considered valid. Any bits entered to the right of this limit should
+ not be considered valid and might be purposely false, or zeroed by
+ the sender.
+
+ LoRes does not define Geographic Privacy policy.
+
+ Values above decimal 34 are undefined and reserved.
+
+ Longitude: a 34 bit fixed point value consisting of 9 bits of integer
+ and 25 bits of fraction. Longitude SHOULD be normalized
+ to within +/- 180 degrees. Positive values are East of
+ the prime meridian and negative (2s complement) numbers
+ are West of the prime meridian.
+
+ A value of 2 in the LoRes field indicates precision of no greater
+ than 1/6th that of the globe (see first example of the appendix). A
+ value of 34 in the LoRes field indicates a precision of about 2.42 mm
+ in longitude (at the equator). Because lines of longitude converge
+ at the poles, the distance is smaller (better precision) for
+ locations away from the equator.
+
+ Altitude: A 30 bit value defined by the AT field
+
+ AltRes: Altitude resolution. 6 bits indicating the number of
+ valid bits in the altitude. Values above 30 (decimal) are
+ undefined and reserved.
+
+ AltRes does not define Geographic Privacy policy.
+
+ AT: Altitude Type for altitude. Codes defined are:
+
+ 1: Meters - in 2s-complement fixed-point 22-bit integer part with 8-
+ bit fraction
+
+ If AT = 1, an AltRes value 0.0 would indicate unknown altitude. The
+ most precise Altitude would have an AltRes value of 30. Many values
+ of AltRes would obscure any variation due to vertical datum
+ differences.
+
+ 2: Floors - in 2s-complement fixed-point 22-bit integer part with
+ 8-bit fraction
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 6]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ AT = 2 for Floors enables representing altitude in a form more
+ relevant in buildings which have different floor-to-floor dimensions.
+ An altitude coded as AT = 2, AltRes = 30, and Altitude = 0.0 is
+ meaningful even outside a building, and represents ground level at
+ the given latitude and longitude. Inside a building, 0.0 represents
+ the floor level associated with ground level at the main entrance.
+ This document defines a number; one must arrive at the number by
+ counting floors from the floor defined to be 0.0.
+
+ The values represented by this AT will be of local significance.
+ Since buildings and floors can vary due to lack of common control,
+ the values chosen to represent the characteristics of an individual
+ building will be derived and agreed upon by the operator of the
+ building and the intended users of the data. Attempting to
+ standardize this type of function is beyond the scope this document.
+
+ Sub-floors can be represented by non-integer values. Example: a
+ mezzanine between floor 1 and floor 2 could be represented as a value
+ = 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
+ represented as values = 4.1 and 4.2 respectively.
+
+ Floors located below ground level could be represented by negative
+ values.
+
+ Larger values represent floors that are above (higher in altitude)
+ floors with lower values.
+
+ The AltRes field SHOULD be set to maximum precision when AT = 2
+ (floors) when a floor value is included in the DHCP Reply, or the
+ AT = 0 to denote the floor isn't known.
+
+ Any additional LCI Altitude Types(s) to be defined for use via this
+ DHC Option MUST be done through a Standards Track RFC.
+
+ Datum: The Map Datum used for the coordinates given in this Option
+
+ The datum must include both a horizontal and a vertical reference.
+ Since the WGS 84 reference datum is three-dimensional, it includes
+ both. For any additional datum parameters, the datum codepoint must
+ specify both horizontal datum and vertical datum references.
+
+ The Datum byte has 256 possibilities, of which 3 have been registered
+ with IANA by this document (all derived from specification in [5]):
+
+ 1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS
+ Code 4327, Prime Meridian Name: Greenwich
+
+
+
+
+
+Polk, et al. Standards Track [Page 7]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ 2: NAD83 - North American Datum 1983, CRS Code 4269, Prime
+ Meridian Name: Greenwich; The associated vertical datum
+ is the North American Vertical Datum of 1988 (NAVD88)
+
+ This datum pair is to be used when referencing
+ locations on land, not near tidal water (which would
+ use Datum = 3 below)
+
+ 3: NAD83 - North American Datum 1983, CRS Code 4269, Prime
+ Meridian Name: Greenwich; The associated vertical datum
+ is Mean Lower Low Water (MLLW)
+
+ This datum pair is to be used when referencing
+ locations on water/sea/ocean
+
+ Any additional LCI datum(s) to be defined for use via this DHC Option
+ MUST be done through a Standards Track RFC.
+
+3. Security Considerations
+
+ Where critical decisions might be based on the value of this GeoConf
+ option, DHCP authentication in [4] SHOULD be used to protect the
+ integrity of the DHCP options.
+
+ Since there is no privacy protection for DHCP messages, an
+ eavesdropper who can monitor the link between the DHCP server and
+ requesting client can discover this LCI.
+
+ 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]).
+
+ When implementing a DHC server that will serve clients across an
+ uncontrolled network, one should consider the potential security
+ risks.
+
+4. IANA Considerations
+
+ IANA has assigned a DHCP option code of 123 for the GeoConf option
+ defined in this document.
+
+ The GeoConf Option defines two fields for which IANA maintains 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:
+
+
+
+Polk, et al. Standards Track [Page 8]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ 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 WGS 84 as
+ the vertical datum
+
+ Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as
+ their CRS Code 4269; North American Vertical Datum of 1988
+ (NAVD88) is the associated vertical datum for NAD83
+
+ Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
+ their CRS Code 4269; Mean Lower Low Water (MLLW) is the
+ associated vertical datum for NAD83
+
+ Any additional LCI datum(s) to be defined for use via this DHC Option
+ MUST be done through a Standards Track RFC.
+
+5. Acknowledgements
+
+ The authors would like to thank Patrik Falstrom, Ralph Droms, Ted
+ Hardie, Jon Peterson, and Nadine Abbott for their inputs and
+ constructive comments regarding this document. Additionally, the
+ authors would like to thank Greg Troxel for the education on vertical
+ datums, and to Carl Reed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 9]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+Appendix: Calculations of Imprecision Possible with the DHC LCI
+
+ The following examples for two different locations demonstrate how
+ the Resolution values for Latitude, Longitude, and Altitude can be
+ used. In both examples the geo-location values were derived from
+ maps using the WGS84 map datum, therefore in these examples, the
+ datum field would have a value = 1 (00000001, or 0x01).
+
+A.1. Location Configuration Information of "White House" (Example 1)
+
+ The address was NOT picked for any political reason and can easily be
+ found on the Internet or mapping software, but was picked as an
+ easily identifiable location on our planet.
+
+ Postal Address:
+ White House
+ 1600 Pennsylvania Ave. NW
+ Washington, DC 20006
+
+ Standing on the sidewalk, north side of White House, between
+ driveways.
+
+ Latitude 38.89868 degrees North (or +38.89868 degrees)
+ Using 2s complement, 34 bit fixed point, 25 bit fraction
+ Latitude = 0x04dcc1fc8,
+ Latitude = 0001001101110011000001111111001000
+
+ Longitude 77.03723 degrees West (or -77.03723 degrees)
+ Using 2s complement, 34 bit fixed point, 25 bit fraction
+ Longitude = 0xf65ecf031,
+ Longitude = 1101100101111011001111000000110001
+
+ Altitude 15
+
+ In this example, we are not inside a structure, therefore we will
+ assume an altitude value of 15 meters, interpolated from the US
+ Geological survey map, Washington West quadrangle.
+
+ AltRes = 30, 0x1e, 011110
+ AT = 1, 0x01, 000001
+ Altitude = 15, 0x0F00, 00000000000000000000000001111100000000
+
+ If: LaRes is expressed as value 2 (0x02 or 000010) and LoRes is
+ expressed as value 2 (0x02 or 000010), then it would describe a
+ geo-location region that is north of the equator and extends from
+ -1 degree (west of the meridian) to -128 degrees. This would
+ include the area from approximately 600km south of Saltpond,
+ Ghana, due north to the North Pole and approximately 4400km
+
+
+
+Polk, et al. Standards Track [Page 10]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ south-southwest of Los Angeles, CA due north to the North Pole.
+ This would cover an area of about one-sixth of the globe,
+ approximately 20 million square nautical miles (nm).
+
+ If: LaRes is expressed as value 3 (0x03 or 000011) and LoRes is
+ expressed as value 3 (0x03 or 000011), then it would describe a
+ geo-location area that is north from the equator to 63 degrees
+ north, and -65 degrees to -128 degrees longitude. This area
+ includes south of a line from Anchorage, AL to eastern Nunavut,
+ CN, and from the Amazons of northern Brazil to approximately
+ 4400km south-southwest of Los Angeles, CA. This area would
+ include North America, Central America, and parts of Venezuela
+ and Columbia, except portions of Alaska and northern and eastern
+ Canada, approximately 10 million square nm.
+
+ If: LaRes is expressed as value 5 (0x05 or 000101) and LoRes is
+ expressed as value 5 (0x05 or 000101), then it would describe a
+ geo-location area that is latitude 32 north of the equator to
+ latitude 48 and extends from -64 degrees to -80 degrees
+ longitude. This is approximately an east-west boundary of a time
+ zone, an area of approximately 700,000 square nm.
+
+ If: LaRes is expressed as value 9 (0x09 or 001001) and LoRes is
+ expressed as value 9 (0x09 or 001001), which includes all the
+ integer bits, then it would describe a geo-location area that is
+ latitude 38 north of the equator to latitude 39 and extends from
+ -77 degrees to -78 degrees longitude. This is an area of
+ approximately 9600 square km (111.3km x 86.5km).
+
+ If: LaRes is expressed as value 18 (0x12 or 010010) and LoRes is
+ expressed as value 18 (0x12 or 010010), then it would describe a
+ geo-location area that is latitude 38.8984375 north to latitude
+ 38.9003906 and extends from -77.0390625 degrees to -77.0371094
+ degrees longitude. This is an area of approximately 36,600
+ square meters (169m x 217m).
+
+ If: LaRes is expressed as value 22 (0x16 or 010110) and LoRes is
+ expressed as value 22 (0x16 or 010110), then it would describe a
+ geo-location area that is latitude 38.896816 north to latitude
+ 38.8985596 and extends from -77.0372314 degrees to -77.0371094
+ degrees longitude. This is an area of approximately 143 square
+ meters (10.5m x 13.6m).
+
+ If: LaRes is expressed as value 28 (0x1c or 011100) and LoRes is
+ expressed as value 28 (0x1c or 011100), then it would describe a
+ geo-location area that is latitude 38.8986797 north to latitude
+
+
+
+
+
+Polk, et al. Standards Track [Page 11]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ 38.8986816 and extends from -77.0372314 degrees to -77.0372296
+ degrees longitude. This is an area of approximately 339 square
+ centimeters (20.9cm x 16.23cm).
+
+ If: LaRes is expressed as value 30 (0x1e or 011110) and LoRes is
+ expressed as value 30 (0x1e or 011110), then it would describe a
+ geo-location area that is latitude 38.8986797 north to latitude
+ 38.8986802 and extends from -77.0372300 degrees to -77.0372296
+ degrees longitude. This is an area of approximately 19.5 square
+ centimeters (50mm x 39mm).
+
+ 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
+ geo-location area that is latitude 38.8986800 north to latitude
+ 38.8986802 and extends from -77.0372300 degrees to -77.0372296
+ degrees longitude. This is an area of approximately 7.5 square
+ millimeters (3.11mm x 2.42mm).
+
+ In the (White House) example, the requirement of emergency 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. This would yield a
+ geo-location that is latitude 38.8984375 north to latitude 38.8988616
+ north and longitude -77.0371094 to 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 square feet requested by NENA. In this
+ example, a service provider could enforce that a device send a
+ Location Configuration Information with this minimum amount of
+ resolution for this particular location when calling emergency
+ services.
+
+A.2. Location Configuration Information of "Sears Tower" (Example 2)
+
+ Postal Address:
+ Sears Tower
+ 103rd Floor
+ 233 S. Wacker Dr.
+ Chicago, IL 60606
+
+ Viewing the Chicago area from the Observation Deck of the Sears
+ Tower.
+
+ Latitude 41.87884 degrees North (or +41.87884 degrees)
+ Using 2s complement, 34 bit fixed point, 25 bit fraction
+ Latitude = 0x053c1f751,
+ Latitude = 0001010011110000011111011101010001
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 12]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+ Longitude 87.63602 degrees West (or -87.63602 degrees)
+ Using 2s complement, 34 bit fixed point, 25 bit fraction
+ Longitude = 0xf50ba5b97,
+ Longitude = 1101010000101110100101101110010111
+
+ Altitude 103
+
+ In this example, we are inside a structure, therefore we will assume
+ an altitude value of 103 to indicate the floor we are on. The
+ Altitude Type value is 2, indicating floors. The AltRes field would
+ indicate that all bits in the Altitude field are true, as we want to
+ accurately represent the floor of the structure where we are located.
+
+ AltRes = 30, 0x1e, 011110
+ AT = 2, 0x02, 000010
+ Altitude = 103, 0x00006700, 000000000000000110011100000000
+
+ For the accuracy of the latitude and longitude, the best information
+ available to us was supplied by a generic mapping 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) and LoRes as value 18
+ (0x12 or 010010). This would be describing a geo-location area that
+ is latitude 41.8769531 to latitude 41.8789062 and extends from
+ -87.6367188 degrees to -87.6347657 degrees longitude. This is an
+ area of approximately 373412 square feet (713.3 ft. x 523.5 ft.).
+
+6. References
+
+6.1. Normative References
+
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
+ 1997.
+
+ [2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
+ January 2001.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC
+ 3118, June 2001.
+
+ [5] European Petroleum Survey Group, http://www.epsg.org/ and
+ http://www.ihsenergy.com/epsg/geodetic2.html
+
+ [6] World Geodetic System 1984 (WGS 84), MIL-STD-2401,
+ http://www.wgs84.com/
+
+
+
+
+Polk, et al. Standards Track [Page 13]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+6.2. Informational References
+
+ [7] Farrell, C., Schulze, M., Pleitner, S. and D. Baldoni, "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.
+
+7. Author Information
+
+ James M. Polk
+ Cisco Systems
+ 2200 East President George Bush Turnpike
+ Richardson, Texas 75082 USA
+
+ EMail: jmpolk@cisco.com
+
+
+ John Schnizlein
+ Cisco Systems
+ 9123 Loughran Road
+ Fort Washington, MD 20744 USA
+
+ EMail: john.schnizlein@cisco.com
+
+
+ Marc Linsner
+ Cisco Systems
+ Marco Island, FL 34145 USA
+
+ EMail: marc.linsner@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 14]
+
+RFC 3825 DHCP Option for Coordinate LCI July 2004
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights 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; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Polk, et al. Standards Track [Page 15]
+