draft-ietf-geopriv-rfc3825bis-00.txt   draft-ietf-geopriv-rfc3825bis-01.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 ISOC Category: Standards Track ISOC
Expires: December 15, 2009 M. Linsner Expires: January 12, 2010 M. Linsner
5 June 2009 Cisco Systems 12 July 2009 Cisco Systems
Bernard Aboba (ed) Bernard Aboba (ed)
Microsoft Corporation Microsoft Corporation
Dynamic Host Configuration Protocol Option for Dynamic Host Configuration Protocol Option for
Coordinate-based Location Configuration Information Coordinate-based Location Configuration Information
draft-ietf-geopriv-rfc3825bis-00.txt draft-ietf-geopriv-rfc3825bis-01.txt
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 December 15, 2009. This Internet-Draft will expire on January 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
reference datum for these values is also included. reference datum for these values is also included.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . 4
2. Location Configuration Information (LCI) Elements. . . . . . . 5 2. Location Configuration Information (LCI) Elements. . . . . . . 5
2.1. Elements of the Location Configuration Information . . . 5 2.1. Elements of the Location Configuration Information . . . 5
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 8 2.2 Version Support . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 9 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Informational References . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Calculations of Imprecision possible with the DHC LCI 11 6.2. Informational References . . . . . . . . . . . . . . . . 11
A.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 11 Appendix A. Calculations of Imprecision possible with the DHC LCI 12
A.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 13 A.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 12
Appendix B. Changes from RFC 3825 . . . . . . . . . . . . . . . . 14 A.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Changes from RFC 3825 . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies a Dynamic Host Configuration Protocol This document specifies a Dynamic Host Configuration Protocol
[RFC2131] Option for the coordinate-based geographic location of the [RFC2131] Option for the coordinate-based geographic location of the
client, to be provided by the server. client, to be provided by the server.
The DHCP server is assumed to have determined the location from the The DHCP server is assumed to have determined the location from the
Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt
1) in [RFC3046]. In order to translate the circuit (switch port 1) in [RFC3046]. In order to translate the circuit (switch port
skipping to change at page 5, line 27 skipping to change at page 5, line 27
This binary format provides a fortunate benefit in a mechanism for This binary format provides a fortunate benefit in a mechanism for
making a true/correct location coordinate imprecise. It further making a true/correct location coordinate imprecise. It further
provides the capability to have this binary representation be provides the capability to have this binary representation be
deterministically imprecise. deterministically imprecise.
The LCI format is as follows: The LCI format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 123 | 16 | LaRes | Latitude + | Code 123 | Length | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | + | Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | | Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT | AltRes | Altitude | | AT | AltRes | Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt (cont'd) | Datum | | Alt (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Elements of the Location Configuration Information 2.1. Elements of the Location Configuration Information
Code 123: The code for this DHCP option. Code 123: The code for this DHCP option.
16: The length of this option is 16 bytes. Length: The length of this option, in octets. For versions 0
and 1, the option length is 16.
LaRes: Latitude resolution. 6 bits indicating the number of LaRes: Latitude resolution. 6 bits indicating the number of
valid bits in the fixed-point value of Latitude. valid bits in the fixed-point value of Latitude.
This value is the number of high-order Latitude bits that should be This value is the number of high-order Latitude bits that should be
considered valid. Any bits entered to the right of this limit should considered valid. Any bits entered to the right of this limit should
not be considered valid and might be purposely false, or zeroed by not be considered valid and might be purposely false, or zeroed by
the sender. the sender.
The examples in Appendix A illustrate that a smaller value in the The examples in Appendix A illustrate that a smaller value in the
skipping to change at page 7, line 52 skipping to change at page 7, line 52
Larger values represent floors that are above (higher in altitude) Larger values represent floors that are above (higher in altitude)
floors with lower values. floors with lower values.
The AltRes field SHOULD be set to maximum precision when AT = 2 The AltRes field SHOULD be set to maximum precision when AT = 2
(floors) when a floor value is included in the DHCP Reply, or the AT (floors) when a floor value is included in the DHCP Reply, or the AT
= 0 to denote the floor isn't known. = 0 to denote the floor isn't known.
Any additional LCI Altitude Types(s) to be defined for use via this Any additional LCI Altitude Types(s) to be defined for use via this
DHC Option MUST be done through a Standards Track RFC. DHC Option MUST be done through a Standards Track RFC.
The Ver field is two bits, providing for four potential versions.
This specification defines the behavior of version 0 (originally
specified in [RFC3825]) as well as version 1. The Ver field is
always located at the same offset from the beginning of the option,
regardless of the version in use.
The Res field which is 3 bits, is reserved. These bits have been
used by [IEEE-802.11y], but are not defined within this
specification.
Datum: The Map Datum used for the coordinates given in this Option Datum: The Map Datum used for the coordinates given in this Option
The datum must include both a horizontal and a vertical reference. The datum must include both a horizontal and a vertical reference.
Since the WGS 84 reference datum is three-dimensional, it includes Since the WGS 84 reference datum is three-dimensional, it includes
both. For any additional datum parameters, the datum codepoint must both. For any additional datum parameters, the datum codepoint must
specify both horizontal datum and vertical datum references. specify both horizontal datum and vertical datum references.
The Datum byte has 256 possibilities, of which 3 have been registered The Datum field is 3 bits, providing 8 possibilities, of which 3 have
with IANA by this document (all derived from specification in been registered with IANA by this document (all derived from
[EPSG]): specification in [EPSG]):
1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS 1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS
Code 4327, Prime Meridian Name: Greenwich Code 4327, Prime Meridian Name: Greenwich
2: NAD83 - North American Datum 1983, CRS Code 4269, Prime 2: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical datum Meridian Name: Greenwich; The associated vertical datum
is the North American Vertical Datum of 1988 (NAVD88) is the North American Vertical Datum of 1988 (NAVD88)
This datum pair is to be used when referencing This datum pair is to be used when referencing
locations on land, not near tidal water (which would locations on land, not near tidal water (which would
skipping to change at page 8, line 34 skipping to change at page 8, line 46
3: NAD83 - North American Datum 1983, CRS Code 4269, Prime 3: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical datum Meridian Name: Greenwich; The associated vertical datum
is Mean Lower Low Water (MLLW) is Mean Lower Low Water (MLLW)
This datum pair is to be used when referencing This datum pair is to be used when referencing
locations on water/sea/ocean locations on water/sea/ocean
Any additional LCI datum(s) to be defined for use via this DHC Option Any additional LCI datum(s) to be defined for use via this DHC Option
MUST be done through a Standards Track RFC. MUST be done through a Standards Track RFC.
2.2. Version Support
2.2.1. Client Version Support
Clients implementing this specification MUST support receiving
responses of versions 0 and 1. Since this specification utilizes the
same DHCP option code as [RFC3825], the option format does not
provide a means for the client to indicate the highest version that
it supports to the server.
2.2.2. Server Version Selection
A DHCP server that provides location information cannot provide
options with both v0 and v1 formats in the same response. This is not
useful since receiving two copies of the same Option (either in the
same response or a separate response) causes a DHCP client to replace
the information in the old Option with the information in the new
Option.
A server uses configuration to determine which version to send in a
response. For example, where a mixture of v0 and v1 clients are
expected, the server could be configured to send v0 or v1 depending
on configuration (possibly making the choice based on information
such as the client MAC address). Where few v0 clients are expected,
the server could be configured to send only v1 responses.
Servers that opt to send location in v1 format are likely to cause
clients that support only v0 to reject the Option. This results in a
v0-only client not obtaining location information, with no ability to
indicate to the server that v1 was unsupported. Therefore, in
situations where some clients are known to support only v0, by
default the server SHOULD send a v0 response.
3. Security Considerations 3. Security Considerations
Where critical decisions might be based on the value of this GeoConf Where critical decisions might be based on the value of this GeoConf
option, DHCP authentication in [RFC3118] SHOULD be used to protect option, DHCP authentication in [RFC3118] SHOULD be used to protect
the integrity of the DHCP options. the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and eavesdropper who can monitor the link between the DHCP server and
requesting client can discover this LCI. requesting client can discover this LCI.
skipping to change at page 9, line 36 skipping to change at page 10, line 36
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
Any additional LCI datum(s) to be defined for use via this DHC Option Any additional LCI datum(s) to be defined for use via this DHC Option
MUST be done through a Standards Track RFC. MUST be done through a Standards Track RFC.
This document defines the Ver field, with values as follows:
0: Implementations conforming to [RFC3825]
1: Implementations of this specification
Any additional Ver field values to be defined for use with this DHC
Option MUST be done through a Standards Track RFC.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Patrik Falstrom, Ralph Droms, Ted The authors would like to thank Patrik Falstrom, Ralph Droms, Ted
Hardie, Jon Peterson, and Nadine Abbott for their inputs and Hardie, Jon Peterson, and Nadine Abbott for their inputs and
constructive comments regarding this document. Additionally, the constructive comments regarding this document. Additionally, the
authors would like to thank Greg Troxel for the education on vertical authors would like to thank Greg Troxel for the education on vertical
datums, as well as Carl Reed. datums, as well as Carl Reed.
6. References 6. References
skipping to change at page 10, line 33 skipping to change at page 11, line 33
[WGS84] US National Imagery and Mapping Agency, "Department of Defense [WGS84] US National Imagery and Mapping Agency, "Department of Defense
(DoD) World Geodetic System 1984 (WGS 84), Third Edition", (DoD) World Geodetic System 1984 (WGS 84), Third Edition",
NIMA TR8350.2, January 2000, 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
[IEEE-802.11y]
Information technology - Telecommunications and information
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.
[NENA] National Emergency Number Association (NENA) www.nena.org NENA [NENA] National Emergency Number Association (NENA) www.nena.org NENA
Technical Information Document on Model Legislation Enhanced Technical Information Document on Model Legislation Enhanced
911 for Multi-Line Telephone Systems. 911 for Multi-Line Telephone Systems.
[RFC1712] Farrell, C., Schulze, M., Pleitner, S. and D. Baldoni, "DNS [RFC1712] Farrell, C., Schulze, M., Pleitner, S. and D. Baldoni, "DNS
Encoding of Geographical Location", RFC 1712, November 1994. Encoding of Geographical Location", RFC 1712, November 1994.
[RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008. Considerations Section in RFCs", RFC 5226, May 2008.
Appendix A. Calculations of Imprecision Possible with the DHC LCI Appendix A. Calculations of Imprecision Possible with the DHC LCI
The following examples for two different locations demonstrate how The following examples for two different locations demonstrate how
the Resolution values for Latitude, Longitude, and Altitude can be the Resolution values for Latitude, Longitude, and Altitude can be
used. In both examples the geo-location values were derived from used. In both examples the geo-location values were derived from
maps using the WGS84 map datum, therefore in these examples, the maps using the WGS84 map datum, therefore in these examples, the
datum field would have a value = 1 (00000001, or 0x01). datum field would have a value = 1 (00000001, or 0x01).
skipping to change at page 14, line 29 skipping to change at page 15, line 33
to show LaRes as value 18 (0x12 or 010010) and LoRes as value 18 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 (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.).
Appendix B. Changes from RFC 3825 Appendix B. Changes from RFC 3825
Technical changes: Technical changes:
-01: Within Section 2.1, split Datum field from RFC 3825 into three
fields: Ver, Res and Datum fields. Explained that the Ver
field is always located at the same offset. Added Section 2.2
relating to Version Support.
-00: None -00: None
Editorial changes: Editorial changes:
-01: Added references to IEEE 802.11y, RFC 3825.
-00: Changed boilerplate. Added B. Aboba as editor. Re-positioned -00: Changed boilerplate. Added B. Aboba as editor. Re-positioned
Appendix A and Acknowledgements sections. Changed reference Appendix A and Acknowledgements sections. Changed reference
numbers to names, added reference to RFC 5226 (since RFC 3825 numbers to names, added reference to RFC 5226 (since RFC 3825
was missing a reference to RFC 2434, now obsolete), updated was missing a reference to RFC 2434, now obsolete), updated
references (and URLs). Updated author affiliations and email references (and URLs). Updated author affiliations and email
addresses. Changed references to "the appendix" to Appendix A. addresses. Changed references to "the appendix" to Appendix A.
Added Appendix B listing changes. Added Appendix B listing changes.
Authors' Addresses Authors' Addresses
 End of changes. 16 change blocks. 
21 lines changed or deleted 95 lines changed or added

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