draft-ietf-geopriv-rfc3825bis-13.txt   draft-ietf-geopriv-rfc3825bis-14.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: May 7, 2011 M. Linsner Expires: May 25, 2011 M. Linsner
7 November 2010 Cisco Systems 27 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-13.txt draft-ietf-geopriv-rfc3825bis-14.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 May 7, 2011. This Internet-Draft will expire on May 25, 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 9, line 40 skipping to change at page 9, line 40
Moving forward, DHCPv4 and DHCPv6 clients not understanding a datum Moving forward, DHCPv4 and DHCPv6 clients not understanding a datum
value MUST assume a World Geodesic System 1984 (WGS84) [WGS84] datum value MUST assume a World Geodesic System 1984 (WGS84) [WGS84] datum
(EPSG [EPSG] 4326 or 4979, depending on whether there is an Altitude (EPSG [EPSG] 4326 or 4979, depending on whether there is an Altitude
value present) and proceed accordingly. Assuming that a less value present) and proceed accordingly. Assuming that a less
accurate location value is better than none, this ensures that some accurate location value is better than none, this ensures that some
(perhaps less accurate) location is available to the client. (perhaps less accurate) location is available to the client.
2.2.1.2. Server Version Selection 2.2.1.2. Server Version Selection
DHCPv6 servers implementing this specification MUST support sending DHCPv6 servers implementing this specification MUST send version 1
version 1 responses. A DHCPv4 server implementing this specification responses. A DHCPv4 server implementing this specification MUST
MUST support sending version 1 responses and SHOULD support sending support sending version 1 responses and SHOULD support sending
version 0 responses. A DHCPv4 server that provides location version 0 responses. A DHCPv4 server that provides location
information cannot provide options with both version 0 and version 1 information cannot provide options with both version 0 and version 1
formats in the same response. This is not useful since receiving two 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 copies of the same Option (either in the same response or a separate
response) causes a DHCPv4 client to replace the information in the response) causes a DHCPv4 client to replace the information in the
old Option with the information in the new Option. old Option with the information in the new Option.
A DHCPv4 server uses configuration to determine which version to send A DHCPv4 server uses configuration to determine which version to send
in a response. For example, where a mixture of version 0 and version in a response. For example, where a mixture of version 0 and version
1 clients are expected, the DHCPv4 server could be configured to send 1 clients are expected, the DHCPv4 server could be configured to send
version 0 or version 1 depending on configuration (possibly making version 0 or version 1 depending on configuration (possibly making
the choice based on information such as the client MAC address). the choice based on information such as the client MAC address).
Where few version 0 clients are expected, the DHCPv4 server could be Where few version 0 clients are expected, the DHCPv4 server could be
configured to send only version 1 responses. Version 0 options will configured to send only version 1 responses. Version 0 options will
provide resolution, while version 1 options will provide an area of provide resolution, while version 1 options will provide an area of
uncertainty. uncertainty.
An RFC 3825 DHCPv4 client that receives a version 1 option, as An RFC 3825 DHCPv4 client that receives a version 1 option defined in
defined in this document, will either reject the Option or will not this document will either reject the Option, or will not understand
understand the additions to the Datum field and will misinterpret the the additions to the Datum field and will misinterpret the LongUnc,
LongUnc, LatUnc, and AltUnc values. If the RFC 3825 DHCPv4 client LatUnc, and AltUnc values. If the RFC 3825 DHCPv4 client does not
does not reject the option and utilizes the location data it will reject the option and utilizes the location data it will most likely
most likely assume a datum. Assuming one of the RFC 3825 datums assume a datum. Assuming one of the RFC 3825 datums causes correct
causes correct interpretation of Latitude/Longitude/Altitude values. interpretation of Latitude/Longitude/Altitude values. The values for
The values for LongUnc/LatUnc/AltUnc are mistakenly interpreted as LongUnc/LatUnc/AltUnc are mistakenly interpreted as representing
representing significant digits. The resultant location value will significant digits. The resultant location value will be in error up
be in error up to a full degree of latitude and longitude, and a full to a full degree of latitude and longitude, and a full increment of
increment of altitude. altitude.
This results in a version 0-only DHCPv4 client either not obtaining This results in a version 0-only DHCPv4 client either not obtaining
location information (with no ability to indicate to the server that location information (with no ability to indicate to the server that
version 1 was unsupported), or misinterpreting the option. version 1 was unsupported), or misinterpreting the option.
Therefore, in situations where some DHCPv4 clients are known to Therefore, if it is not known whether all DHCPv4 clients support
support only version 0, by default the DHCPv4 server SHOULD send a version 1, and it is not possible for the DHCPv4 server to
version 0 response. distinguish between version 0 and version 1 DHCPv4 clients by some
means, by default the DHCPv4 server SHOULD send a version 0 response.
2.3. Latitude and Longitude Fields 2.3. Latitude and Longitude Fields
The Latitude and Longitude values in this specification are encoded The Latitude and Longitude values in this specification are encoded
as 34 bit, twos complement, fixed point values with 9 integer bits as 34 bit, twos complement, fixed point values with 9 integer bits
and 25 fractional bits. The exact meaning of these values is and 25 fractional bits. The exact meaning of these values is
determined by the datum; the description in this section applies to determined by the datum; the description in this section applies to
the datums defined in this document. This document uses the same the datums defined in this document. This document uses the same
definition for all datums it specifies. definition for all datums it specifies.
 End of changes. 6 change blocks. 
21 lines changed or deleted 22 lines changed or added

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