< draft-ietf-geopriv-rfc3825bis-12.txt   draft-ietf-geopriv-rfc3825bis-13.txt >
GEOPRIV Working Group J. Polk GEOPRIV Working Group J. Polk
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Obsoletes: 3825 (if approved) J. Schnizlein Obsoletes: 3825 (if approved) J. Schnizlein
Category: Standards Track Individual Contributor Category: Standards Track Individual Contributor
Expires: March 12, 2011 M. Linsner Expires: May 7, 2011 M. Linsner
5 September 2010 Cisco Systems 7 November 2010 Cisco Systems
M. Thomson M. Thomson
Andrew Andrew
B. Aboba (ed) B. Aboba (ed)
Microsoft Corporation Microsoft Corporation
Dynamic Host Configuration Protocol Options for Dynamic Host Configuration Protocol Options for
Coordinate-based Location Configuration Information Coordinate-based Location Configuration Information
draft-ietf-geopriv-rfc3825bis-12.txt draft-ietf-geopriv-rfc3825bis-13.txt
Abstract Abstract
This document specifies Dynamic Host Configuration Protocol Options This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes of the client. The Location Configuration Information (LCI) includes
Latitude, Longitude, and Altitude, with resolution or uncertainty Latitude, Longitude, and Altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference indicators for each. Separate parameters indicate the reference
datum for each of these values. datum for each of these values.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2011. This Internet-Draft will expire on May 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5 1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5
2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 6 2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 6
2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 6 2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 6
2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 7 2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 8
2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 10 2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 10
2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 15 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informational References . . . . . . . . . . . . . . . . 17 6.2. Informational References . . . . . . . . . . . . . . . . 18
Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 20
A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 19 A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 22 Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 23
B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 22 B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 23
B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 25 B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 26
Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 26 Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 27
C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 26 C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 27
Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 30 Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The physical location of a network device has a range of The physical location of a network device has a range of
applications. In particular, emergency telephony applications rely applications. In particular, emergency telephony applications rely
on knowing the location of a caller in order to determine the correct on knowing the location of a caller in order to determine the correct
emergency center. emergency center.
The location of a device can be represented either in terms of The location of a device can be represented either in terms of
geospatial (or geodetic) coordinates, or as a civic address. geospatial (or geodetic) coordinates, or as a civic address.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
apply to all dimensions equally, a resolution value is included for apply to all dimensions equally, a resolution value is included for
each of the three location elements. Since version 0 of the DHCPv6 each of the three location elements. Since version 0 of the DHCPv6
option format is not defined, the DHCPv6 option does not support a option format is not defined, the DHCPv6 option does not support a
resolution parameter. Version 1 of the DHCPv4 and DHCPv6 option resolution parameter. Version 1 of the DHCPv4 and DHCPv6 option
format utilizes an uncertainty parameter. Appendix A describes the format utilizes an uncertainty parameter. Appendix A describes the
mapping of DHCP option values to GML. Appendix B of this document mapping of DHCP option values to GML. Appendix B of this document
provides examples showing the calculation of resolution values. provides examples showing the calculation of resolution values.
Appendix C provides an example demonstrating calculation of Appendix C provides an example demonstrating calculation of
uncertainty values. uncertainty values.
Since the PIDF-LO format [RFC4119][RFC5491] is used to conveying
location and the associated uncertainty within an emergency call
[Convey], a mechanism is needed to convert the information contained
within the DHCPv4 and DHCPv6 options to PIDF-LO. This document
describes the following conversions:
version 0 to PIDF-LO
version 1 to PIDF-LO
PIDF-LO to version 1
Conversion to PIDF-LO does not increase uncertainty; conversion from
PIDF-LO to version 1 increases uncertainty by less than a factor of 2
in each dimension. Since it is not possible to translate an
arbitrary PIDF-LO to version 0 with a bounded increase in
uncertainty, the conversion to version 0 is not specified.
2. DHCP Option Format 2. DHCP Option Format
This section defines the format for the DHCPv4 and DHCPv6 options. This section defines the format for the DHCPv4 and DHCPv6 options.
These options utilize a similar format, differing primarily in the These options utilize a similar format, differing primarily in the
option code. option code.
2.1. DHCPv6 Option 2.1. DHCPv6 Option
The DHCPv6 [RFC3315] option format is as follows: The DHCPv6 [RFC3315] option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code (TBD) | OptLen (16) | | Option Code (TBD) | OptLen (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LatUnc | Latitude + | LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat (cont'd) | LongUnc | Longitude + | Lat (cont'd) | LongUnc | Longitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (cont'd) | AT | AltUnc | Altitude + | Longitude (cont'd) | AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (cont'd) |Ver| Res |Datum| | Altitude (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: GEOCONF_GEODETIC (16 bits). Code: GEOCONF_GEODETIC (16 bits).
OptLen: Option Length (16). This option has a fixed length, so OptLen: Option Length (16). This option has a fixed length, so
that the value of this octet will always be 16. that the value of this octet will always be 16.
LatUnc: 6 bits. When the Ver field = 1, this field represents LatUnc: 6 bits. When the Ver field = 1, this field represents
skipping to change at page 12, line 50 skipping to change at page 13, line 27
x = 8 - ceil( log2( uncertainty ) ) x = 8 - ceil( log2( uncertainty ) )
Note that the result of encoding this value increases the range of Note that the result of encoding this value increases the range of
uncertainty to the next available power of two; subsequent repeated uncertainty to the next available power of two; subsequent repeated
encodings and decodings do not change the value. Only increasing encodings and decodings do not change the value. Only increasing
uncertainty means that the associated confidence does not have to uncertainty means that the associated confidence does not have to
decrease. decrease.
2.4. Altitude 2.4. Altitude
The altitude is expressed as a 30 bit, fixed point, twos complement The Altitude value is expressed as a 30 bit, fixed point, twos
integer with 22 integer bits and 8 fractional bits. How the Altitude complement integer with 22 integer bits and 8 fractional bits. How
value is interpreted depends on the type of altitude and the selected the Altitude value is interpreted depends on the Altitude Type
datum. Three Altitude Types are defined in this document: unknown (AType) value and the selected datum. Three Altitude Type values are
(0), meters (1) and floors (2). defined in this document: unknown (0), meters (1) and floors (2).
2.4.1. No Known Altitude (AT = 0) 2.4.1. No Known Altitude (AType = 0)
In some cases, the altitude of the location might not be provided. An In some cases, the altitude of the location might not be provided.
Altitude Type of 0 indicates that the altitude is not given to the An Altitude Type value of zero indicates that the altitude is not
client. In this case, the Altitude and Altitude Uncertainty fields given to the client. In this case, the Altitude and Altitude
can contain any value and MUST be ignored. Uncertainty fields can contain any value and MUST be ignored.
2.4.2. Altitude in Meters (AT = 1) 2.4.2. Altitude in Meters (AType = 1)
If the Altitude Type has a value of 1, the Altitude is measured in If the Altitude Type has a value of one, Altitude is measured in
meters. The altitude is measured in relation to the zero set by the meters, in relation to the zero set by the vertical datum.
vertical datum.
2.4.3. Altitude in Floors (AT = 2) 2.4.3. Altitude in Floors (AType = 2)
A value of 2 for altitude type indicates that the Altitude value is A value of two for Altitude Type indicates that the Altitude value is
measured in floors. This value is relevant only in relation to a measured in floors. This value is relevant only in relation to a
building; the value is relative to the ground level of the building. building; the value is relative to the ground level of the building.
In this definition, numbering starts at ground level, which is floor In this definition, numbering starts at ground level, which is floor
0 regardless of local convention. 0 regardless of local convention.
Non-integer values can be used to represent intermediate or sub- Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. For instance, a mezzanine between floors, such as mezzanine levels. For instance, a mezzanine between
floors 4 and 5 could be represented as 4.1. floors 4 and 5 could be represented as 4.1.
2.4.4. Altitude Resolution 2.4.4. Altitude Resolution
In the version 0 DHCPv4 Option, the AltUnc value encodes the number In the version 0 DHCPv4 Option, the Altitude Uncertainty (AltUnc)
of high-order altitude bits that should be considered valid. Values value encodes the number of high-order altitude bits that should be
above 30 (decimal) are undefined and reserved. considered valid. Values above 30 (decimal) are undefined and
reserved.
If AT = 1, an AltUnc value 0.0 would indicate unknown Altitude. The If the Altitutde Type value is one (AType = 1), an AltUnc value 0.0
most precise altitude would have an AltUnc value of 30. Many values would indicate unknown Altitude. The most precise altitude would
of AltUnc would obscure any variation due to vertical datum have an AltUnc value of 30. Many values of AltUnc would obscure any
differences. variation due to vertical datum differences.
The AltUnc field SHOULD be set to maximum precision when AT = 2 The AltUnc field SHOULD be set to maximum precision when AType = 2
(floors) when a floor value is included in the DHCP Reply, or when AT (floors) when a floor value is included in the DHCP Reply, or when
= 0, to denote that the floor isn't known. An altitude coded as AT = AType = 0, to denote that the floor isn't known. An altitude coded
2, AltRes = 30, and Altitude = 0.0 is meaningful even outside a as AType = 2, AltRes = 30, and Altitude = 0.0 is meaningful even
building, and represents ground level at the given latitude and outside a building, and represents ground level at the given latitude
longitude. and longitude.
2.4.5. Altitude Uncertainty 2.4.5. Altitude Uncertainty
In the DHCPv6 option or the version 1 DHCPv4 option, the AltUnc value In the DHCPv6 option or the version 1 DHCPv4 option, the AltUnc value
quantifies the amount of uncertainty in the Altitude value. As with quantifies the amount of uncertainty in the Altitude value. As with
LatUnc and LongUnc, a value of 0 for AltUnc is reserved to indicate LatUnc and LongUnc, a value of 0 for AltUnc is reserved to indicate
that Altitude Uncertainty is not known; values above 30 are also that Altitude Uncertainty is not known; values above 30 are also
reserved. Altitude Uncertainty only applies to Altitude Type 1. reserved. Altitude Uncertainty only applies to Altitude Type 1.
The amount of Altitude Uncertainty can be determined by the following The amount of Altitude Uncertainty can be determined by the following
formula, where x is the encoded integer value: formula, where x is the encoded integer value:
Uncertainty = 2 ^ ( 21 - x ) Uncertainty = 2 ^ ( 21 - x )
This value uses the same units as the associated altitude. This value uses the same units as the associated altitude.
Similarly, a value for the encoded integer value can be derived by Similarly, a value for the encoded integer value can be derived by
the following formula: the following formula:
x = 21 - ceil( log2( x ) ) x = 21 - ceil( log2( uncertainty ) )
2.5. Datum 2.5. Datum
The Datum field determines how coordinates are organized and related The Datum field determines how coordinates are organized and related
to the real world. Three datums are defined in this document, based to the real world. Three datums are defined in this document, based
on the definitions in [OGP.Geodesy]: on the definitions in [OGP.Geodesy]:
1: WGS84 (Latitude, Longitude, Altitude): 1: WGS84 (Latitude, Longitude, Altitude):
The World Geodesic System 1984 [WGS84] coordinate reference The World Geodesic System 1984 [WGS84] coordinate reference
system. system.
skipping to change at page 15, line 50 skipping to change at page 16, line 23
Link layer confidentiality and integrity protection may also be Link layer confidentiality and integrity protection may also be
employed to reduce the risk of location disclosure and tampering. employed to reduce the risk of location disclosure and tampering.
4. IANA Considerations 4. IANA Considerations
IANA has assigned a DHCPv4 option code of 123 for the GeoConf option IANA has assigned a DHCPv4 option code of 123 for the GeoConf option
defined in this document. Assignment of a DHCPv6 option code is defined in this document. Assignment of a DHCPv6 option code is
requested. requested.
The GeoConf Option defines two fields for which IANA maintains a The GeoConf Option defines two fields for which IANA maintains a
registry: The Altitude Type (AT) field and the Datum field (see registry: The Altitude Type (AType) field and the Datum field (see
Section 2). The datum indicator MUST include specification of both Section 2). The datum indicator MUST include specification of both
horizontal and vertical datum. New values for the Altitude Type (AT) horizontal and vertical datum. New values for the Altitude Type
and Datum fields are assigned through "Standards Action" [RFC5226]. (AType) and Datum fields are assigned through "Standards Action"
New Altitude Types MUST define the way that the 30 bit altitude [RFC5226]. New Altitude Types MUST define the way that the 30 bit
values and the associated 6 bit uncertainty are interpreted. New altitude values and the associated 6 bit uncertainty are interpreted.
datums MUST define the way that the 34 bit values and the respective New datums MUST define the way that the 34 bit values and the
6 bit uncertainties are interpreted. The initial values of the respective 6 bit uncertainties are interpreted. The initial values
Altitude registry are as follows: of the Altitude registry are as follows:
AT = 0 No known altitude. AType = 0 No known altitude.
AT = 1 meters of altitude defined by the vertical datum specified. AType = 1 meters of altitude defined by the vertical datum
specified.
AT = 2 building floors of altitude. AType = 2 building floors of altitude.
Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG as Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG
their CRS Code 4327; CRS Code 4327 also specifies WGS 84 as as their CRS Code 4327; CRS Code 4327 also specifies WGS 84
the vertical datum as the vertical datum.
Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; North American Vertical Datum of 1988 their CRS Code 4269; North American Vertical Datum of 1988
(NAVD88) is the associated vertical datum for NAD83 (NAVD88) is the associated vertical datum for NAD83.
Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; Mean Lower Low Water (MLLW) is the their CRS Code 4269; Mean Lower Low Water (MLLW) is the
associated vertical datum for NAD83 associated vertical datum for NAD83.
This document defines the Ver field for the DHCPv4 and DHCPv6 This document defines the Ver field for the DHCPv4 and DHCPv6
options. New values for the Ver field are assigned through options. New values for the Ver field are assigned through
"Standards Action" [RFC5226]. Initial values are as follows: "Standards Action" [RFC5226]. Initial values are as follows:
0: DHCPv4 Implementations conforming to [RFC3825] 0: DHCPv4 Implementations conforming to [RFC3825]
1: Implementations of this specification (for both DHCPv4 and DHCPv6) 1: Implementations of this specification (for both DHCPv4 and DHCPv6)
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Randall Gellens, Patrik Falstrom, The authors would like to thank Randall Gellens, Patrik Falstrom,
Ralph Droms, Ted Hardie, Jon Peterson, and Nadine Abbott for their Ralph Droms, Ted Hardie, Jon Peterson, Robert Sparks and Nadine
inputs and constructive comments regarding this document. Abbott for their inputs and constructive comments regarding this
Additionally, the authors would like to thank Greg Troxel for the document. Additionally, the authors would like to thank Greg Troxel
education on vertical datums, as well as Carl Reed. Thanks to for the education on vertical datums, as well as Carl Reed. Thanks
Richard Barnes for his contribution on GML mapping for resolution. to Richard Barnes for his contribution on GML mapping for resolution.
6. References 6. References
6.1. Normative References 6.1. Normative References
[EPSG] European Petroleum Survey Group, http://www.epsg.org/ and [EPSG] European Petroleum Survey Group, http://www.epsg.org/ and
http://www.epsg-registry.org/ http://www.epsg-registry.org/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
2131, March 1997. March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
and M. Carney, "Dynamic Host Configuration Protocol for M. Carney, "Dynamic Host Configuration Protocol for IPv6
IPv6 (DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[WGS84] US National Imagery and Mapping Agency, "Department of [WGS84] US National Imagery and Mapping Agency, "Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition", NIMA TR8350.2, January 2000, Edition", NIMA TR8350.2, January 2000,
https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/ https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/
WORLDGEODETICSYSTEM/Pages/default.aspx and WORLDGEODETICSYSTEM/Pages/default.aspx and
http://www.ngs.noaa.gov/faq.shtml#WGS84 http://www.ngs.noaa.gov/faq.shtml#WGS84
6.2. Informational References 6.2. Informational References
[GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape [Convey] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance
Application Schema for use by the Internet Engineering for the Session Initiation Protocol", Internet draft (work
Task Force (IETF)", Candidate OpenGIS Implementation in progress), draft-ietf-sipcore-location-
Specification 06-142, Version: 0.0.9, December 2006. conveyance-04.txt, October 25, 2010.
[IEEE-802.11y] Information technology - Telecommunications and [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
information exchange between systems - Local and Application Schema for use by the Internet Engineering Task
metropolitan area networks - Specific requirements - Part Force (IETF)", Candidate OpenGIS Implementation
11: Wireless LAN Medium Access Control (MAC) and Physical Specification 06-142, Version: 0.0.9, December 2006.
Layer (PHY) specifications Amendment 3: 3650-3700 MHz
Operation in USA, November 2008.
[NENA] National Emergency Number Association (NENA) www.nena.org [IEEE-802.11y]
NENA Technical Information Document on Model Legislation Information technology - Telecommunications and information
Enhanced 911 for Multi-Line Telephone Systems. exchange between systems - Local and metropolitan area
networks - Specific requirements - Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 3: 3650-3700 MHz Operation in USA,
November 2008.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [NENA] National Emergency Number Association (NENA) www.nena.org
3046, January 2001. NENA Technical Information Document on Model Legislation
Enhanced 911 for Multi-Line Telephone Systems.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 3046, January 2001.
[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
"Threat Analysis of the Geopriv Protocol", RFC 3694, Polk, "Geopriv Requirements", RFC 3693, February 2004.
February 2004.
[RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson,
Configuration Protocol Option for Coordinate-based "Threat Analysis of the Geopriv Protocol", RFC 3694,
Location Configuration Information", RFC 3825, July 2004. February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host
Format", RFC 4119, December 2005. Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
(DHCPv4 and DHCPv6) Option for Civic Addresses Format", RFC 4119, December 2005.
Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
Format for Presence Information Data Format Location (DHCPv4 and DHCPv6) Option for Civic Addresses
Object (PIDF-LO)", RFC 5139, February 2008. Configuration Information", RFC 4776, November 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
IANA Considerations Section in RFCs", RFC 5226, May 2008. Format for Presence Information Data Format Location Object
(PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations, and
Recommendations ", RFC 5491, March 2009
Appendix A. GML Mapping Appendix A. GML Mapping
The GML representation of a decoded DHCP option depends on what The GML representation of a decoded DHCP option depends on what
fields are specified. The DHCP format for location logically fields are specified. The DHCP format for location logically
describes a geodetic prism, rectangle, or point, depending on whether describes a geodetic prism, rectangle, or point, depending on whether
Altitude and uncertainty values are provided. In the absence of Altitude and uncertainty values are provided. In the absence of
uncertainty information, the value decoded from the DHCP form can be uncertainty information, the value decoded from the DHCP form can be
expressed as a single point; this is true regardless of whether the expressed as a single point; this is true regardless of whether the
version 0 or version 1 interpretations of the uncertainty fields are version 0 or version 1 interpretations of the uncertainty fields are
skipping to change at page 24, line 25 skipping to change at page 25, line 25
bits of resolution allow for values in the range from -77.0390625 to bits of resolution allow for values in the range from -77.0390625 to
-77.0351563. Having 17 bits of resolution in the altitude allows for -77.0351563. Having 17 bits of resolution in the altitude allows for
values in the range from 0 to 32 meters. values in the range from 0 to 32 meters.
GML Representation of Decoded Location Configuration Information GML Representation of Decoded Location Configuration Information
The following GML shows the value decoded in the previous example as The following GML shows the value decoded in the previous example as
a point in a three dimensional CRS: a point in a three dimensional CRS:
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979" <gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml";> xmlns:gml="http://www.opengis.net/gml">
<gml:pos>38.897647 -77.0366 15</gml:pos> <gml:pos>38.897647 -77.0366 15</gml:pos>
</gml:Point> </gml:Point>
This representation ignores the values included in the resolution This representation ignores the values included in the resolution
parameters. If resolution values are provided, a rectangular prism parameters. If resolution values are provided, a rectangular prism
can be used to represent the location. can be used to represent the location.
The following example uses all of the decoded information from the The following example uses all of the decoded information from the
previous example: previous example:
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979" <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"; xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml";> xmlns:gml="http://www.opengis.net/gml">
<gs:base> <gs:base>
<gml:Polygon> <gml:Polygon>
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList> <gml:posList>
38.8964844 -77.0390625 0 38.8964844 -77.0390625 0
38.8964844 -77.0351563 0 38.8964844 -77.0351563 0
38.8984375 -77.0351563 0 38.8984375 -77.0351563 0
38.8984375 -77.0390625 0 38.8984375 -77.0390625 0
38.8964844 -77.0390625 0 38.8964844 -77.0390625 0
skipping to change at page 25, line 40 skipping to change at page 26, line 40
Altitude 103 Altitude 103
In this example, we are inside a structure, therefore we will assume 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 an Altitude value of 103 to indicate the floor we are on. The
Altitude Type value is 2, indicating floors. The AltUnc field would Altitude Type value is 2, indicating floors. The AltUnc field would
indicate that all bits in the Altitude field are true, as we want to 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. accurately represent the floor of the structure where we are located.
AltUnc = 30, 0x1e, 011110 AltUnc = 30, 0x1e, 011110
AT = 2, 0x02, 000010 AType = 2, 0x02, 000010
Altitude = 103, 0x00006700, 000000000000000110011100000000 Altitude = 103, 0x00006700, 000000000000000110011100000000
For the accuracy of the Latitude and Longitude, the best information For the accuracy of the Latitude and Longitude, the best information
available to us was supplied by a generic mapping service that shows 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 a single geo-loc for all of the Sears Tower. Therefore we are going
to show LatUnc as value 18 (0x12 or 010010) and LongUnc as value 18 to show LatUnc as value 18 (0x12 or 010010) and LongUnc as value 18
(0x12 or 010010). This would be describing a geo-location area that (0x12 or 010010). This would be describing a geo-location area that
is Latitude 41.8769531 to Latitude 41.8789062 and extends from is Latitude 41.8769531 to Latitude 41.8789062 and extends from
-87.6367188 degrees to -87.6347657 degrees Longitude. This is an -87.6367188 degrees to -87.6347657 degrees Longitude. This is an
area of approximately 373412 square feet (713.3 ft. x 523.5 ft.). area of approximately 373412 square feet (713.3 ft. x 523.5 ft.).
skipping to change at page 26, line 20 skipping to change at page 27, line 20
can be calculated. can be calculated.
C.1. Location Configuration Information of "Sydney Opera House" C.1. Location Configuration Information of "Sydney Opera House"
(Example 3) (Example 3)
This section describes an example of encoding and decoding the This section describes an example of encoding and decoding the
geodetic DHCP Option. The textual results are expressed in GML geodetic DHCP Option. The textual results are expressed in GML
[OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119]. [OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119].
These examples all assume a datum of WGS84 (datum = 1) and an These examples all assume a datum of WGS84 (datum = 1) and an
Altitude type of meters (AT = 1). Altitude type of meters (AType = 1).
C.1.1. Encoding a Location into DHCP Geodetic Form C.1.1. Encoding a Location into DHCP Geodetic Form
This example draws a rough polygon around the Sydney Opera House. This example draws a rough polygon around the Sydney Opera House.
This polygon consists of the following six points: This polygon consists of the following six points:
33.856625 S, 151.215906 E 33.856625 S, 151.215906 E
33.856299 S, 151.215343 E 33.856299 S, 151.215343 E
33.856326 S, 151.214731 E 33.856326 S, 151.214731 E
33.857533 S, 151.214495 E 33.857533 S, 151.214495 E
skipping to change at page 30, line 13 skipping to change at page 31, line 13
encoded value of 9 or greater). encoded value of 9 or greater).
Appendix D. Changes from RFC 3825 Appendix D. Changes from RFC 3825
This section lists the major changes between [RFC3825] and this This section lists the major changes between [RFC3825] and this
document. Minor changes, including style, grammar, spelling and document. Minor changes, including style, grammar, spelling and
editorial changes are not mentioned here. editorial changes are not mentioned here.
o Section 1 now includes clarifications on wired and wireless uses. o Section 1 now includes clarifications on wired and wireless uses.
o The former Sections 1.2 and 1.3 have been removed. Section 1.2 o The former Sections 1.2 and 1.3 have been removed. Section 1.2
now defines the concepts of uncertainty and resolution. now defines the concepts of uncertainty and resolution, as well
as conversion between the DHCP option format and PIDF-LO.
o A DHCPv6 option is now defined (Section 2.1) as well o A DHCPv6 option is now defined (Section 2.1) as well
as a DHCPv4 option (Section 2.2). as a DHCPv4 option (Section 2.2).
o The former Datum field has been split into three fields: o The former Datum field has been split into three fields:
Ver, Res and Datum. These fields are used in both the Ver, Res and Datum. These fields are used in both the
DHCPv4 and DHCPv6 options. DHCPv4 and DHCPv6 options.
o Section 2.2.1 has been added, describing Version support. o Section 2.2.1 has been added, describing Version support.
o Section 2.3 has been added, describing the Latitude and o Section 2.3 has been added, describing the Latitude and
Longitude fields. Longitude fields.
o Section 2.3.1 has been added, covering Latitude and Longitude o Section 2.3.1 has been added, covering Latitude and Longitude
resolution. resolution.
 End of changes. 51 change blocks. 
130 lines changed or deleted 158 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/