geopriv@ietf.org: Re: [Geopriv] [geopriv] #2: Add DHCPv6 option format

#2: Add DHCPv6 option format
--------------------------------+-------------------------------------------
Reporter: rbarnes@bbn.com | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: Active WG Document | Resolution:
Keywords: |
--------------------------------+-------------------------------------------

Comment(by bernard_aboba@hotmail.com):

The changes for addition of the DHCPv6 option format appear to belong in
Section 2 and 2.1.

Here is an early outline of what the revised sections might look like
(quite a bit of work is still left to fill in blanks and integrate the
DHCPv4 & v6 option descriptions). Comments welcome.

2. DHC Location Configuration Information Elements

DHCP is a binary Protocol; using protocols of LCI are likely to be
text based. Since most coordinate systems translate easily between
binary-based and text-based location output (even emergency services
within the US), translation/conversion is a non-issue with DHCP's
binary format.

This binary format provides a fortunate benefit in a mechanism for
making a true/correct location coordinate imprecise. It further
provides the capability to have this binary representation be
deterministically imprecise.

The DHCPv4 LCI format is as follows:

The DHCPv6 [RFC3315] LCI format is as follows:

2.1. Elements of the Location Configuration Information

Code: The code for the DHCPv4 option (123).

Option Code: The code for the DHCPv6 option (TBD)

Length: The length of the DHCPv4 option, in octets. For
versions 0 and 1, the option length is 16.

OptLen: The length of the DHCPv6 option data, in octets (16).

LaRes: Latitude resolution. 6 bits indicating the number of
valid bits in the fixed-point value of Latitude.

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
not be considered valid and might be purposely false, or zeroed by
the sender.

The examples in Appendix A illustrate that a smaller value in the
resolution field increases the area within which the device is
located.

LaRes does not define Geographic Privacy policy. Values above
decimal 34 are undefined and reserved.

LatUnc:

Latitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Latitude SHOULD be normalized to
within +/- 90 degrees. Positive numbers are north of the
equator and negative numbers are south of the equator.

A value of 2 in the LaRes field indicates a precision of no greater
than 1/6th that of the globe (in the first example of Appendix A). A
value of 34 in the LaRes field indicates a precision of about 3.11 mm
in Latitude at the equator.

LoRes: Longitude resolution. 6 bits indicating the number of
valid bits in the fixed-point value of Longitude.

This value is the number of high-order Longitude bits that should be
considered valid. Any bits entered to the right of this limit should
not be considered valid and might be purposely false, or zeroed by
the sender.

LoRes does not define Geographic Privacy policy. Values above
decimal 34 are undefined and reserved.

LongUnc:

Longitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Longitude SHOULD be normalized
to within +/- 180 degrees. Positive values are East of
the prime meridian and negative (2s complement) numbers
are West of the prime meridian.

A value of 2 in the LoRes field indicates precision of no greater
than 1/6th that of the globe (see the first example of Appendix A).
A value of 34 in the LoRes field indicates a precision of about 2.42
mm in longitude (at the equator). Because lines of longitude
converge at the poles, the distance is smaller (better precision) for
locations away from the equator.

Altitude: A 30 bit value defined by the AT field

AltRes: Altitude resolution. 6 bits indicating the number of
valid bits in the altitude. Values above 30 (decimal) are
undefined and reserved.

AltRes does not define Geographic Privacy policy.

AltUnc:

AT: Altitude Type for altitude. Codes defined are:

1: Meters - in 2s-complement fixed-point 22-bit integer part with 8-
bit fraction

If AT = 1, an AltRes value 0.0 would indicate unknown altitude. The
most precise Altitude would have an AltRes value of 30. Many values
of AltRes would obscure any variation due to vertical datum
differences.

2: Floors - in 2s-complement fixed-point 22-bit integer part with
8-bit fraction

AT = 2 for Floors enables representing altitude in a form more
relevant in buildings which have different floor-to-floor dimensions.
An altitude coded as AT = 2, AltRes = 30, and Altitude = 0.0 is
meaningful even outside a building, and represents ground level at
the given latitude and longitude. Inside a building, 0.0 represents
the floor level associated with ground level at the main entrance.
This document defines a number; one must arrive at the number by
counting floors from the floor defined to be 0.0.

The values represented by this AT will be of local significance.
Since buildings and floors can vary due to lack of common control,
the values chosen to represent the characteristics of an individual
building will be derived and agreed upon by the operator of the
Building and the intended users of the data. Attempting to
standardize this type of function is beyond the scope this document.

Sub-floors can be represented by non-integer values. Example: a
mezzanine between floor 1 and floor 2 could be represented as a value
= 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
represented as values = 4.1 and 4.2 respectively.

Floors located below ground level could be represented by negative
values.

Larger values represent floors that are above (higher in altitude)
floors with lower values.

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
= 0 to denote the floor isn't known.

Any additional LCI Altitude Types(s) to be defined for use via this
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

The datum must include both a horizontal and a vertical reference.
Since the WGS 84 reference datum is three-dimensional, it includes
both. For any additional datum parameters, the datum codepoint must
specify both horizontal datum and vertical datum references.

The Datum field for the DHCPv4 option is 3 bits, providing 8
possibilities. The Datum field for the DHCPv6 option is 8 bits.
Three datum values have been registered with IANA by this document
(all derived from specification in [EPSG]):

1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS
Code 4327, Prime Meridian Name: Greenwich

2: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical datum
is the North American Vertical Datum of 1988 (NAVD88)

This datum pair is to be used when referencing
locations on land, not near tidal water (which would
use Datum = 3 below)

3: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical datum
is Mean Lower Low Water (MLLW)

This datum pair is to be used when referencing
locations on water/sea/ocean

Any additional LCI datum(s) to be defined for use via the DHC Options
defined in this document MUST be done through a Standards Track RFC.

--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/2#comment:3>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

geopriv@ietf.org

Sunday, July 5, 2009

Re: [Geopriv] [geopriv] #2: Add DHCPv6 option format

Followers

Blog Archive

Contributors