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

["geopriv issue tracker" <[e-mail]>]

#2: Add DHCPv6 option format
--------------------------------+-------------------------------------------
 Reporter:  [e-mail]     |        Owner:                            
     Type:  enhancement         |       Status:  new                       
 Priority:  major               |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis          |      Version:                            
 Severity:  Active WG Document  |   Resolution:                            
 Keywords:                      |  
--------------------------------+-------------------------------------------

Comment(by [e-mail]):

 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:

     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     |   LaRes   |     Latitude      +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Latitude (cont'd)              |    LoRes  |   +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Longitude                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   AT  |   AltRes  |                Altitude                   +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Alt.(cont'd)  |Ver| Res |Datum|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The DHCPv6 [RFC3315] LCI 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)               |     Datum     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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/>