Subject: [Geopriv] [geopriv] rfc3825bis #43 (new): Ralph Droms DISCUSS

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 02 Dec 2010 16:17:14 -0000

#43: Ralph Droms DISCUSS

 Ralph Droms has entered the following ballot position for
 draft-ietf-geopriv-rfc3825bis-14.

 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)

 Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT positions.

 ----------------------------------------------------------------------
 DISCUSS:
 ----------------------------------------------------------------------

 (Including the dhc WG chairs in the discussion thread for their input on
 the reuse of option code 123 or use of a new option code.)

 Like Adrian, I am concerned about the details of how this document
 refers to RFC 3825 and the disposition of RFC 3825.  For example,
 because of the changes to the interpretation of the Datum field, it is
 important that 3825bis, when published, is a self-contained
 description of the syntax and semantics of both versions of the
 options.

 As another example, the text in section 2.2.1.1 that begins "Moving
 forward
 ..."
 would be better written to simply reference "3825bis-compliant clients"

 Did the working group consider defining a new option for the new
 format?  Were the alternatives of an RFC3825bis versus a new option
 discussed with the dhc WG?  Although there is some need to conserve
 DHCP option codes, the use of a new option code for this new format of
 the option would avoid the problems with backward compatibility:

 * an RFC 3825 compliant client misinterprets the
  contents of a 3825bis DHCP option 123 because of the
  unexpected version value 1
 * an RFC 3825 compliant client rejects the contents of
  a 3825bis option 123 because the version value 1 causes
  the client to interpret the option as containing an
  invalid datum value; the client has no way to indicate
  to the server that it has rejected the option contents
 * a DHCP client can't indicate which version of the option
  it understands

 In the IANA considerations section, I would like to see a
 clarification that the registries replace the existing registries.
 The second paragraph states that new Altitude Types and Datums must
 define the way in which the related uncertainty values are
 interpreted.  However, the registry values in the table do not include
 those definitions; presumably, the uncertainty values are interpreted
 as in 3825bis, but this interpretation should be indicated in the
 registry.

 ----------------------------------------------------------------------
 COMMENT:
 ----------------------------------------------------------------------

 I found the wording of the IANA Considerations section confusing and
 inconsistent.  I suggest:

   IANA maintains registries for the Altitude Type (AType), Datum and
   Version fields.  New values for each of these registries are
   assigned through "Standards Actions" [RFC5226].

   Each AType registry entry MUST define the way that the 30 bit
   altitude values and the associated 6 bit uncertainty are
   interpreted.

   Each Datum registry entry MUST include specification of both
   horizontal and vertical datum, and MUST define the way that the 34
   bit values and the respective 6 bit uncertainties are interpreted.

   The initial AType registry is:

   The initial Datum registry is:

   The initial Version registry is:

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  bernard_aboba@…           
     Type:  defect                     |      Status:  new                       
 Priority:  blocker                    |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:  1.0                       
 Severity:  Submitted WG Document      |    Keywords:                            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/43>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 04 Dec 2010 22:56:09 -0000

#43: Ralph Droms DISCUSS

Comment(by bernard_aboba@…):

 Addressed the COMMENT relating to the IANA Considerations Section.  The
 new text reads as follows:

 4.  IANA Considerations

    IANA has assigned a DHCPv4 option code of 123 for the GeoConf option
    defined in this document.  Assignment of a DHCPv6 option code is
    requested.

    IANA maintains registries for the Altitude Type (AType), Datum and
    Version fields.  New values for each of these registries are assigned
    through "Standards Actions" [RFC5226].

    Each AType registry entry MUST define the way that the 30 bit
    altitude values and the associated 6 bit uncertainty are interpreted.

    AType = 0  No known altitude.

    AType = 1  meters of altitude defined by the vertical datum
            specified.

    AType = 2  building floors of altitude.

    Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG
            as their CRS Code 4327; CRS Code 4327 also specifies WGS 84
            as the vertical datum.

    Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as
            their CRS Code 4269; North American Vertical Datum of 1988
            (NAVD88) is the associated vertical datum for NAD83.

    Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
            their CRS Code 4269; Mean Lower Low Water (MLLW) is the
            associated vertical datum for NAD83.

    0: DHCPv4 implementations utilizing resolution parameters.

    1: Implementations utilizing uncertainty parameters
       (for both DHCPv4 and DHCPv6).

Ticket URL: <https://wiki.tools.ietf.org/wg/geopriv/trac/ticket/43#comment:1>
geopriv <http://tools.ietf.org/geopriv/>