Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information
draft-ietf-geopriv-rfc3825bis-17

IANA has a question about the IANA Actions in this document.

Upon approval of this document, IANA understands that there are five
IANA Actions that must be completed.

First, IANA understands that a new DHCPv4 Option Code is to be assigned.
Section 1.2 of the document refers to the DHCPv4 Option TBD. IANA
understands that this Option Code will be assigned from the BOOTP Vendor
Extensions and DHCP Options located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

IANA QUESTION: what are the name, data length and meaning that IANA
should use for this registration?

Second, in the DHCP Option Codes subregistry of the Dynamic Host
Configuration
Protocol for IPv6 (DHCPv6) registry located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

a new option code should be registered as follows:

Value: TBD
Description: GeoPriv
Reference: RFC-to-be

Third, IANA maintains a GeoConf Option fields (Value 123) - The Altitude
(AT)
field in the DHCPv4 registry.

This registry is located at:
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

This registry will be updated to refer to the new [ RFC-to-be ] and will
now be
populated as follows:

Value: 0
Altitude Field Description: No known altitude.
Reference: [ RFC-to-be ]

Value: 1
Altitude Field Description: meters of altitude defined by the vertical
datum specified.
Reference: [ RFC-to-be ]

Value: 2
Altitude Field Description: building floors of altitude
Reference: [ RFC-to-be ]

Future registrations in this registry require standards action.

Fourth, IANA maintains a GeoConf Option fields (Value 123) - The Datum
field registry. This registry is located at:
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

This registry will be updated to refer to the new [ RFC-to-be ] and will
now be populated as follows:

Value: 1
Datum field description: 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
Reference: [ RFC-to-be ]

Value: 2
Datum field description: 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
Reference: [ RFC-to-be ]

Value: 3
Datum field description: 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
Reference: [ RFC-to-be ]

Future registrations in this registry require standards action.

Fifth, in both the DHCPv4 and the DHCPv6 registries a new registry
named "GeoConf Option FIelds (Value 123) - The Version field" will be
created for the "Ver" field:

New values for the Ver field are assigned through "Standards Action."

The registry will use { RFC-to-be ] as the reference.

Initial values of both registries are as follows:

0: DHCPv4 Implementations conforming to [RFC3825]
1: Implementations of this specification (for both DHCPv4 and DHCPv6)

The registries affected are:

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

and

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

IANA understands that these five actions are the only ones required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information) to Proposed Standard


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Dynamic Host Configuration Protocol Options for Coordinate-based
  Location Configuration Information'
  as a Proposed Standard

This is the 2nd IETF LC for this document focusing on changes resulting from IESG review.
The first last call was on version -12 of the document.
IESG review resulted in these substantial changes:
  - The document will obsolete RFC3825
  - Option code 123 is defined in this document
  - The document defines a new option code instead of extending the behavior of code 123

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document specifies Dynamic Host Configuration Protocol Options
  (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
  of the client.  The Location Configuration Information (LCI) includes
  Latitude, Longitude, and Altitude, with resolution or uncertainty
  indicators for each.  Separate parameters indicate the reference
  datum for each of these values.  This document obsoletes RFC 3825.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/

[Ballot comment]
I've cleared my DISCUSS.  I have a remaining minor
comment - In the descriptions of the options, sentences like:

              When the Ver field = 1, this field represents
              latitude uncertainty.  The contents of this field is
              undefined for other values of the Ver field.

seem unnecessarily detailed.  Why not simply:

              This field represents
              latitude uncertainty.

The descriptions of many fields say nothing about the version number.

[Ballot comment]
I've cleared my DISCUSS.  I have a remaining minor
comment - In the descriptions of the options, sentences like:

              When the Ver field = 1, this field represents
              latitude uncertainty.  The contents of this field is
              undefined for other values of the Ver field.

seem uneceesarily details.  Why not simply:

              This field represents
              latitude uncertainty.

The descriptions of many fields say nothing about the version number.

[Ballot comment]
Ari Keränen reviewed this specification and he had a few comments:

The abstract should state that this document obsoletes RFC 3825 and the
intro should explain why it's done (as described in the I-D checklist).

However, instead of obsoleting 3825, wouldn't it make more sense to have
a new IPv4 DHCP option for this new version given that the new encoding
is not compatible with the old one and re-using the same value seems to
cause a lot of problems (as described in section 2.2.1)? Or otherwise it
would be good idea to mention the reason (preserving DHCP codes?) for
not doing so.


2.3.  Latitude and Longitude Fields

    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 [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due
to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when it
comes to information that could literally be a matter of life and death.

[Ballot discuss]
I think the backwards compatibility design is wrong. If there's really
implementations of the old RFC (are there?) the right thing to do would
be to separate code points at the DHCP level so that peaceful co-existence
of new and old clients can happen.

Also, the normalization process pointed to by Ari's review (below) seems
suspect. Garbage in, garbage out. If the DHCP server cannot be trusted
to follow this specific, a number in the wrong range is equally likely
just bad data. Silently ignoring such options might be the better choice
here. There are obvious downsides to incorrect determination of location.

[Ballot comment]
Ari Keränen reviewed this specification and he had a few comments:

The abstract should state that this document obsoletes RFC 3825 and the
intro should explain why it's done (as described in the I-D checklist).

However, instead of obsoleting 3825, wouldn't it make more sense to have
a new IPv4 DHCP option for this new version given that the new encoding
is not compatible with the old one and re-using the same value seems to
cause a lot of problems (as described in section 2.2.1)? Or otherwise it
would be good idea to mention the reason (preserving DHCP codes?) for
not doing so.


2.3.  Latitude and Longitude Fields

    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 [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due
to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when it
comes to information that could literally be a matter of life and death.

[Ballot 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.

[Ballot 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:

[Ballot discuss]
ike 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.

[Ballot discuss]
Thank you for this document.

I'm afraid that I don't understand the situation after it is published as an RFC. It claims to obsolete RFC 3825, but a lot of the text refers to things like...

  This document defines the Ver field for the DHCPv4 and DHCPv6
  options.  New values for the Ver field are assigned through
  "Standards Action" [RFC5226].  Initial values are as follows:

  0: DHCPv4 Implementations conforming to [RFC3825]
  1: Implementations of this specification (for both DHCPv4 and DHCPv6)

This is not possible because this document obsoletes RFC 3825, so there cannot be conformance to the RFC any more!

I think a little time should be spent re-working the text around references to RFC 3825. Either 3825 is being made historic, or this document is replacing (obsoleting) 3825 and becaomes the full (self-contained) reference for implementations. In fact (as is stated in seciton 2.2)...

              This specification defines the behavior of
              version 0 (originally specified in [RFC3825]) as well as
              version 1.

...so you don't need to reference 3825, and can just get on with the specification of the two versions.

[Ballot comment]
PIFF-LO term used but not defined
GML term used but not defined
Code:      GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
AType:    Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in two places)

[Ballot comment]
This document is well-written, with clear and unambiguous language.

1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID with the geographic location where the
  identified circuit terminates (such as the location of the wall jack)." Would it be the job of the DHCP server to do this correlation? I would assume it was a NM application function to do such correlation.
2) In 2.2.1.2, s/same response. This is not useful since/same response, since/
3) When aType=2, numbering starts at ground level. How does one represent an underground parking garage level?
Should 2.4.3 mention how to represent this? Should Appendix B include such an example?

[Ballot comment]
1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID with the geographic location where the
  identified circuit terminates (such as the location of the wall jack)." Would it be the job of the DHCP server to do this correlation? I would assume it was a NM application function to do such correlation.
2) In 2.2.1.2, s/same response. This is not useful since/same response, since/

[Ballot discuss]
This document is well-written, with clear and unambiguous language.

When aType=2, numbering starts at ground level. How does one represent an underground parking garage level?
Should 2.4.3 mention how to represent this? Should Appendix B include such an example?

Upon approval of this document, IANA understands that there are four
IANA Actions that must be completed.

First, in the DHCP Option Codes subregistry of the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) registry located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

a new option code should be registered as follows:

Value: TBD
Description: GeoPriv
Reference: RFC-to-be

Second, IANA maintains a GeoConf Option fields (Value 123) - The
Altitude (AT) field in the DHCPv4 registry.

This registry will be updated to refer to the new [ RFC-to-be ] and will
now be as follows:

Value: 0
Altitude Field Description: No known altitude.
Reference: [ RFC-to-be ]

Value: 1
Altitude Field Description: meters of altitude defined by the vertical
datum specified.
Reference: [ RFC-to-be ]

Value: 2
Altitude Field Description: building floors of altitude
Reference: [ RFC-to-be ]

Future registrations in this registry require standards action.

Third, IANA maintains a GeoConf Option fields (Value 123) - The Datum
field registry.

This registry will be updated to refer to the new [ RFC-to-be ] and will
now be as follows:

Value: 1
Datum field description: 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
Reference: [ RFC-to-be ]

Value: 2
Datum field description: 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
Reference: [ RFC-to-be ]

Value: 3
Datum field description: 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
Reference: [ RFC-to-be ]

Future registrations in this registry require standards action.

Fourth, in both the DHCPv4 and the DHCPv6 registries a new registry
named "GeoConf Option FIelds (Value 123) - The Version field" will be
created for the "Ver" field:

New values for the Ver field are assigned through "Standards Action."

The registry will use { RFC-to-be ] as the reference.

Initial values of both registries are as follows:

0: DHCPv4 Implementations conforming to [RFC3825]
1: Implementations of this specification (for both DHCPv4 and DHCPv6)

IANA understands that these four actions are the only ones required upon
approval of this document.

The GEOPRIV working group requests publication of draft-ietf-geopriv-
rfc3825bis-09 as Proposed Standard.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Richard Barnes. The
Shepherd has personally reviewed this version of the document, and
believes it is ready for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been the subject of thorough discussion within the
GEOPRIV working group. I have no concerns about the level of review
this document has received.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not believe that this document requires any special review. It
might benefit from a review by the DHC working group, but I do not
view this as necessary, given that the focus of this document is
clarifying the semantics of an existing DHCP option. The changes that
it does make are mainly semantic; they do not change the wire format
of the option. The most significant change is that it extends the
current DHCPv4 option to DHCPv6, with essentially the same format.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no special concerns about this document. There have been no
IPR disclosures related to the document.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is fairly wide consensus in the working group that this document
provides useful clarifications and extensions to the current RFC 3825
format for geolocation in DHCP.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any extreme discontent or potential appeals related
to this document.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have verified that the the document satisfies all ID nits, with the
exception that it needs updated boilerplate text.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative. All references
are to RFCs and documents of comparable stability in other SDOs.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and provides correct
instructions. Mostly, these are copied from the current RFC 3825
(with initial registry values), but the document also requests that a
new DHCPv6 option code be reserved, and specifies a new registry for
tracking versions of this option, to be controlled by Standards Action.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document is an update to the DHCP option format for coordinate-
based geolocation (RFC 3825). It clarifies the geospatial meaning of
the option, and adds an alternative interpretation (signaled by a
version field) that is more suitable for many use cases. While RFC
3825 applies only to DHCPv4, this document adds support for DHCPv6.


Working Group Summary

There is fairly wide consensus in the working group that this document
provides useful clarifications and extensions to the current RFC 3825
format for geolocation in DHCP.


Document Quality

The document has been reviewed by key participants from the GEOPRIV
working group.