Carl
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
Cc: <geopriv@ietf.org>; "geopriv issue tracker" <trac@tools.ietf.org>
Sent: Tuesday, June 22, 2010 6:21 AM
Subject: Re: [Geopriv] [geopriv] #33: Lat/Long and Datum
> Great, thanks.
>
> On Jun 22, 2010, at 2:55 AM, Thomson, Martin wrote:
>
>> Looks good.
>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>> Behalf Of geopriv issue tracker
>>> Sent: Tuesday, 22 June 2010 4:38 PM
>>> To: bernard_aboba@hotmail.com
>>> Cc: geopriv@ietf.org
>>> Subject: Re: [Geopriv] [geopriv] #33: Lat/Long and Datum
>>>
>>> #33: Lat/Long and Datum
>>> ---------------------------------------
>>> +-------------------------------
>>> -----
>>> Reporter: bernard_aboba@… | Owner: bernard_aboba@…
>>> Type: defect | Status: closed
>>> Priority: major | Milestone: draft-ietf-
>>> geopriv-3825bis
>>> Component: rfc3825bis | Version: 1.0
>>> Severity: In WG Last Call | Resolution: fixed
>>> Keywords: |
>>> ---------------------------------------
>>> +-------------------------------
>>> -----
>>> Changes (by bernard_aboba@…):
>>>
>>> * status: new => closed
>>> * resolution: => fixed
>>>
>>>
>>> Comment:
>>>
>>> Recommended changes:
>>>
>>> 2.1. DHCPv6 Option
>>>
>>> The DHCPv6 [RFC3315] option format is as follows:
>>>
>>> 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
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Option Code (TBD) | OptLen (16) |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | LatUnc | Latitude +
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Lat (cont'd) | LongUnc | Longitude +
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Longitude (cont'd) | AT | AltUnc | Altitude +
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Altitude (cont'd) |Ver| Res |Datum|
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>> Code: GEOCONF_GEODETIC (16 bits).
>>>
>>> OptLen: Option Length (16). This option has a fixed length, so
>>> that the value of this octet will always be 16.
>>>
>>> LatUnc: 6 bits. When the Ver field = 1, this field represents
>>> latitude uncertainty. The contents of this field is
>>> undefined for other values of the Ver field.
>>>
>>> Latitude: a 34 bit fixed point value consisting of 9 bits of
>>> integer and 25 bits of fraction, interpreted as
>>> described in Section 2.3.
>>>
>>> LongUnc: 6 bits. When the Ver field = 1, this field represents
>>> longitude uncertainty. The contents of this field is
>>> undefined for other values of the Ver field.
>>>
>>> Longitude: a 34 bit fixed point value consisting of 9 bits of
>>> integer and 25 bits of fraction, interpreted as
>>> described in Section 2.3.
>>>
>>> AType: Altitude Type (4 bits).
>>>
>>> AltUnc: 6 bits. When the Ver field = 1, this field represents
>>> altitude uncertainty. The contents of this field is
>>> undefined for other values of the Ver field.
>>>
>>> Altitude: A 30 bit value defined by the AType field.
>>>
>>> Ver: The Ver field is two bits, providing for four potential
>>> versions. This specification defines the behavior of
>>> version 1. The Ver field is always located at the same
>>> offset from the beginning of the option, regardless of
>>> the version in use.
>>>
>>> Res: 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: 3 bits. The Map Datum used for the coordinates given in
>>> this Option.
>>>
>>> 2.2. DHCPv4 Option
>>>
>>> The DHCPv4 option format is as follows:
>>>
>>> 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
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Code 123 | Length | LatUnc | Latitude +
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Latitude (cont'd) | LongUnc | +
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Longitude |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | AType | AltUnc | Altitude +
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Alt.(cont'd) |Ver| Res |Datum|
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>> Code: 8 bits. The code for the DHCPv4 option (123).
>>>
>>> Length: 8 bits. The length of the DHCPv4 option, in octets.
>>> For versions 0 and 1, the option length is 16.
>>>
>>> LatUnc: 6 bits. When the Ver field = 0, this field represents
>>> latitude resolution. When the Ver field = 1,
>>> this field represents latitude uncertainty.
>>>
>>> Latitude: a 34 bit fixed point value consisting of 9 bits of
>>> signed integer and 25 bits of fraction, interpreted
>>> as described in Section 2.3.
>>>
>>> LongUnc: 6 bits. When the Ver field = 0, this field represents
>>> longitude resolution. When the Ver field = 1,
>>> this field represents longitude uncertainty.
>>>
>>> Longitude: a 34 bit fixed point value consisting of 9 bits of
>>> signed integer and 25 bits of fraction, interpreted
>>> as described in Section 2.3.
>>>
>>> AType: Altitude Type (4 bits).
>>>
>>> AltUnc: 6 bits. When the Ver field = 0, this field represents
>>> altitude resolution. When the Ver field = 1,
>>> this field represents altitude uncertainty.
>>>
>>> Altitude: A 30 bit value defined by the AType field.
>>>
>>> Ver: 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.
>>>
>>> Res: 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: 3 bits. The Map Datum used for the coordinates given in
>>> this Option.
>>>
>>> Section 2.2.1 new text:
>>>
>>> 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
>>> LongUnc, LatUnc, and AltUnc values.
>>>
>>> If the RFC 3825 DHCPv4 client does not reject the option and
>>> utilizes
>>> the location data it will most likely assume a datum. Assuming one
>>> of the RFC 3825 datums causes correct interpretation of
>>> Latitude/Longitude/Altitude values. The values for
>>> LongUnc/LatUnc/AltUnc are mistakenly interpreted as representing
>>> significant digits. 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 version 0-only DHCPv4 client either not obtaining
>>> location information (with no ability to indicate to the server
>>> that
>>> version 1 was unsupported), or misinterpreting the option.
>>> Therefore, in situations where some DHCPv4 clients are known to
>>> support only version 0, by default the DHCPv4 server SHOULD send a
>>> version 0 response.
>>>
>>> 2.3. Latitude and Longitude Fields
>>>
>>> The Latitude and Longitude values in this specification are encoded
>>> as 34 bit, twos complement, fixed point values with 9 integer bits
>>> and 25 fractional bits. The exact meaning of these values is
>>> determined by the datum; the description in this section applies to
>>> the datums defined in this document.
>>>
>>> New datums MUST define the way that the 34 bit values and the
>>> respective 6 bit uncertainties are interpreted. This document uses
>>> the same definition for all datums it specifies.
>>>
>>> Latitude values encoded by the DHCP server MUST be constrained to
>>> the
>>> range from -90 to +90 degrees. Location consumers MUST be prepared
>>> to normalize values outside this range. Values outside the range
>>> are
>>> normalized by clamping (e.g. values less than -90 degrees are set
>>> to
>>> -90; values greater than 90 degrees are set to +90). Positive
>>> latitudes are north of the equator and negative latitudes are south
>>> of the equator.
>>>
>>> Longitude values encoded by the DHCP server MUST be normalized to
>>> the
>>> range from -180 to +180 degrees. Location consumers MUST be
>>> prepared
>>> to normalize values outside this range. Values outside the range
>>> are
>>> normalized by wrapping (e.g. adding or subtracting 360 until they
>>> fall within the range of -180 to 180). Positive longitudes are
>>> east
>>> of the Prime Meridian (Greenwich) and negative (2s complement)
>>> longitudes are west of the Prime Meridian.
>>>
>>> When encoding, Latitude and Longitude values are rounded to the
>>> nearest 34-bit binary representation. This imprecision is
>>> considered
>>> acceptable for the purposes to which this form is intended to be
>>> applied and is ignored when decoding.
>>>
>>> --
>>> Ticket URL:
>>> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/33#comment:1>
>>> geopriv <http://tools.ietf.org/geopriv/>
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
