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/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
