Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
draft-ietf-dhc-reclassify-options-01

[Ballot comment]
A couple more questions besides Scott's about step 2 in the IANA procedure: how shall IANA handle
it if vendors have conflicting uses of a value?  The normal IANA requirement for an assignment
is an RFC, but for the vendor-claimed values, does "wiling to document" mean they will write an
RFC, or just that they'll register?

Follow-Up IANA Last Call Comments with Bernie Volz:

17 May 2004
[MSC] So does this mean that we will get rid of the "private use" range, mark all those that are "Unassigned" and change it to "Unavailable"?
What happens to 224-254?  Do these remain private use? 

BV> Correct. And, yes 224-254 are still considered "site-specific".

*******************************************

1.  Expand the publicly defined DHCPv4 options space
from 1-127 to 1-223. The new options (128-223) are to be listed as "Unavailable" and MUST NOT be assigned to any publicly defined options.

[MSC] Which registry is this referring to?  The only DHCP registry I see is .

BV> Yes, this is the correct registry. It likely would be good for this link to be included in the document.

2.  Receive notices from vendors that have been using one or more of the options in the 128-223 range that they are using the option and are willing to document that usage. IANA will list these options as "Tentatively-Assigned".

[MSC] What happens if folks are using the same option?  Also, the paragraph above sounds strange.  Maybe there is a missing comma?

BV> See the note in Section 4, Reclassifying Options under list number

BV>
2:    NOTE: If multiple vendors of an option number come forward and can demonstrate their usage is in reasonably wide use, none of the vendors will be allowed to keep the current option number and they MUST go through the normal process of getting a publicly assigned option [RFC2939].  And, perhaps rewording the IANA step 2 as follows would help:

  2.  Receive notices from vendors that they are willing to document their usage of one or more options in the 128-223 range and pursue an official IANA assignment through the IETF process. IANA will list these option numbers as "Tentatively-Assigned".

  3.  6 months from this RFC's publication date, change the listing of any options listed as "Unavailable" to "Available".

These options may now be assigned in accordance with [RFC2939].

[MSC] We understand the only way to be assigned an option from this registry is IETF Consensus (Publication of an RFC).

BV> Yes, that is the intent. This step simply makes the options available for assignment by IANA. It does not assign any options.

4.  18 months from this RFC's publication date and periodically thereafter as long as there is an option listed as "Tentatively-Assigned", change the listing of any options listed as "Tentatively-Assigned" to "Unavailable" if no un-expired Internet-Draft exists documenting the usage.

[MSC] Will the folks who submit notices or
"Tenatively-Assigned" options submit I-Ds to become RFCs so that they're option can just be "Assigned"?
We understand the only way for an option to be "Assigned" is through an RFC.  I understand that the IANA will need to periodically check to see if there is an un-expired I-D for those that would move to the "Unavailable" state.  After another 6 months pass, will that option then become available, similar to step 3?

BV> This step 4 should perhaps become step 5 and we should insert a Step 4 for clarify:

  4. When a "Tentatively-Assigned" option is published as an RFC (as per [RFC2939]), IANA will move the option to the "Assigned" state.

IANA Last Call Comments:
The IANA Considerations says the following:

  IANA is requested to:
1.  Expand the publicly defined DHCPv4 options space from 1-127 to
      1-223. The new options (128-223) are to be listed as
      "Unavailable" and MUST NOT be assigned to any publicly defined
      options.

Which registry is this referring to?  The only DHCP registry I see is
.

  2.  Receive notices from vendors that have been using one or more of
      the options in the 128-223 range that they are using the option
      and are willing to document that usage. IANA will list these
      options as "Tentatively-Assigned".

What happens if folks are using the same option?  Also, the paragraph
above sounds strange.  Maybe there is a missing comma?

  3.  6 months from this RFC's publication date, change the listing of
      any options listed as "Unavailable" to "Available". These options
      may now be assigned in accordance with [RFC2939].

We understand the only way to be assigned an option from this registry
is IETF Consensus (Publication of an RFC).

  4.  18 months from this RFC's publication date and periodically
      thereafter as long as there is an option listed as
      "Tentatively-Assigned", change the listing of any options listed
      as "Tentatively-Assigned" to "Unavailable" if no un-expired
      Internet-Draft exists documenting the usage.

Will the folks who submit notices for "Tenatively-Assigned" options
submit I-Ds to become RFCs so that they're option can just be "Assigned"?
We understand the only way for an option to be "Assigned" is through
an RFC.  I understand that the IANA will need to periodically check to
see if there is an un-expired I-D for those that would move to the
"Unavailable" state.  After another 6 months pass, will that option
then become available, similar to step 3?

Document submission form:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.
 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

I'm comfortable with the entire document.
 
5) 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?

Several WG members have expressed strong support.  Several
alternatives to this draft were discussed in the WG and there is
consensus with no objection to this final document

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

The DHCPv4 option codes defined for public use in RFC 2131 and RFC
2132, option codes 1-127, are nearly all assigned to DHCP
options.  Efforts such as the reclamation of unused DHCP option codes
in RFC 3679 help to extend the life of the option code space, but
ultimately the space is expected to be exhausted.

This document reclassifies much of the site-specific option range,
option codes 128-254, which has not been widely used for its original
intended purpose, to be used as option codes for publicly defined DHCP
options.'

There are known to be some devices that use options in the range of
128-254 in undocumented ways.  This document defines a process through
which an option code is provisionally marked as a candidate for
assignment to a DHCP option and subject oto public review and comment
before actuall assignment.  Vendors will be encouragedd to bring
forward specifications for options that currently option codes that
are reclassified by this document.

  - Working Group Summary

The dhc WG reviewed several alternative mechanisms for extending the
option code space before choosing the mechanism specified in this
document.  The other mechanisms were' described in earlier drafts of
the document.  The WG reviewed the alternatives in two WG meetings and
on the WG mailing list.

  - Protocol Quality

The mechanism for review and reclassification of option codes in this
document allows for public review of reclassifed option codes to
avoid conflict with the use of DHCP option codes by existing and
deployed devices.