From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3825.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc3825.txt (limited to 'doc/rfc/rfc3825.txt') 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] + -- cgit v1.2.3