-----------------------------+----------------------------------------------
Reporter: rbarnes@… | Owner: jmpolk@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: - | Keywords:
-----------------------------+----------------------------------------------
Comment(by bernard_aboba@…):
Here is the proposed new text of Section 2.2.1.2:
2.2.1.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. Version 0
options will provide resolution, while version 1 options will provide
an area of uncertainty.
An RFC 3825 DHCPv4 client that receives a version 1 option, as
defined in this document, will either reject the Option or will not
understand the additions to the datum field and will misinterpret the
LoRes, LaRes, and AltRes values. If the RFC 3825 DHCPv4 client does
not reject the option and utilizes the location data it will most
likely assume a datum and interpret the LoRes/LaRes/AltRes values as
significant digits and apply them to the Latitude, Longitude, and
Altitude values. The resultant location value will be in error up to
a full degree of latitude and longitude, and a full increment of
altitude. This results in a v0-only client either not obtaining
location information (with no ability to indicate to the server that
v1 was unsupported), or misinterpreting the option.
Therefore, in situations where some clients are known to support only
v0, by default the server SHOULD send a v0 response. It is also
RECOMMENDED that DHCPv4 client implementations support version 1, so
the versioning capability added by this document does not cause
errors interpreting the latitude, longitude and altitude values.
Moving forward, clients not understanding a data value MUST assume a
WGS84 datum (EPSG 4326 or 4979, depending on whether there is an
altitude value present) and proceed accordingly. Assuming that a
less accurate location value is better than none, this ensures that
some (perhaps less accurate) location is available to the client.
--
Ticket URL: <http://zinfandel.levkowetz.com/wg/geopriv/trac/ticket/5#comment:4>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
