draft-ietf-geopriv-rfc3825bis-10.txt   draft-ietf-geopriv-rfc3825bis-11.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: December 25, 2010 M. Linsner Expires: January 5, 2011 M. Linsner
22 June 2010 Cisco Systems 5 July 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-10.txt draft-ietf-geopriv-rfc3825bis-11.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 December 25, 2010. This Internet-Draft will expire on January 5, 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 8, line 47 skipping to change at page 8, line 47
2.2.1.1. Client Version Support 2.2.1.1. Client Version Support
DHCPv6 clients implementing this specification MUST support receiving DHCPv6 clients implementing this specification MUST support receiving
version 1 responses. DHCPv4 clients implementing this specification version 1 responses. DHCPv4 clients implementing this specification
MUST support receiving responses of versions 0 and 1. It is required MUST support receiving responses of versions 0 and 1. It is required
that DHCPv4 client implementations support version 1 so the that DHCPv4 client implementations support version 1 so the
versioning capability added by this document does not cause errors versioning capability added by this document does not cause errors
interpreting the Latitude, Longitude and Altitude values. Since this interpreting the Latitude, Longitude and Altitude values. Since this
specification utilizes the same DHCPv4 option code as [RFC3825], the specification utilizes the same DHCPv4 option code as [RFC3825], the
option format does not provide a means for the DHCPv4 client to option format does not provide a means for the DHCPv4 client to
indicate the highest version that it supports to the DHCPv6 server. indicate the highest version that it supports to the DHCPv4 server.
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 specifiction MUST support sending DHCPv6 servers implementing this specification MUST support sending
version 1 responses. A DHCPv4 server implementing this specification version 1 responses. A DHCPv4 server implementing this specification
MUST support sending version 1 responses and SHOULD support sending MUST 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
skipping to change at page 29, line 34 skipping to change at page 29, line 34
-02: Added Section 1.2 introducing uncertainty and resolution -02: Added Section 1.2 introducing uncertainty and resolution
concepts. Added Section 2.1 defining DHCPv6 option format. concepts. Added Section 2.1 defining DHCPv6 option format.
-01: Within Section 2.1, split Datum field from RFC 3825 into three -01: Within Section 2.1, split Datum field from RFC 3825 into three
fields: Ver, Res and Datum fields. Explained that the Ver fields: Ver, Res and Datum fields. Explained that the Ver
field is always located at the same offset. Added Section 2.2 field is always located at the same offset. Added Section 2.2
relating to Version Support. relating to Version Support.
-00: None -00: None
Editorial changes: Editorial changes:
-11: Fixed typos.
-10: Consolidated material relating to parameter allocation into -10: Consolidated material relating to parameter allocation into
the IANA Considerations section. the IANA Considerations section.
-07: Updated boilerplate, cleaned up security considerations section. -07: Updated boilerplate, cleaned up security considerations section.
-06: Added corrections to Section 1.2 "Resolution and Uncertainty". -06: Added corrections to Section 1.2 "Resolution and Uncertainty".
Added the DHCPv6 Option Version field to the IANA Added the DHCPv6 Option Version field to the IANA
Considerations section. Considerations section.
-05: Corrected length of DHCPv6 option. Added Key to uncertainty -05: Corrected length of DHCPv6 option. Added Key to uncertainty
figure. figure.
-04: Changed all uses of the LoRes/LaRes/AltRes terminology to -04: Changed all uses of the LoRes/LaRes/AltRes terminology to
LongUnc/LatUnc/AltUnc, and clarified when these parameters LongUnc/LatUnc/AltUnc, and clarified when these parameters
 End of changes. 6 change blocks. 
6 lines changed or deleted 7 lines changed or added

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