Description of Cisco Systems' Subnet Allocation Option for DHCPv4
draft-ietf-dhc-subnet-alloc-13

[Ballot discuss]
1. Technical (thanks Alexey): In section 3.2:

  The "Name" in this suboption is simply a number of octets and
  need not be ASCII text.

Please specify as UTF-8 [RFC3629] unless you've got some really impressive reason not to.

2. [Update 6/23/11:] I now understand why this document is being put forward as Informational. I suggest the following changes:

In the abstract:

OLD

  This document defines a new DHCP option which...

NEW

  This memo documents a currently existing and previously privately defined DHCP option which...

In the introduction:

OLD

  There is a need for a DHCP Client to be able to allocate a subnet
  from a DHCP Server.  Alternate methods of allocation, such as AAA are
  not appropriate for various reasons and the most straight-forward way
  to accomplish this allocation is via DHCP.  A DHCP option to support
  this may be utilized by a simple Dialin Aggregation box, or even to
  implement a Hierarchical chain of DHCP Servers, each one in turn
  leasing one or more subnets to the next DHCP Server down the chain.

  This new DHCP option [RFC2132], the Subnet Allocation option is
  specified in such a way as to use one DHCP Option number, while using
  suboption numbers for each function.

NEW

  This memo documents a DHCP option [RFC2132], the Subnet Allocation
  option, that was developed by Cisco and allows a DHCP Client to
  allocate a subnet given information from a DHCP Server. This protocol
  makes use of DHCP option number 220, one of the option numbers
  reclassified by [RFC3942]. That RFC specifies in section 4, procedure
  2, "Vendors that currently use one or more of the reclassified
  options have 6 months following this RFC's publication date to notify
  the DHC WG and IANA that they are using particular options numbers
  and agree to document that usage in an RFC." This memo serves as that
  documentation. The DHC WG has had no input into any of the details of
  the protocol operation and makes no statement about the correctness
  or any other aspect of the protocol. The WG also has seen no interest
  in further implementation or deployment of this protocol other than
  privately, and therefore has decided to publish this document solely
  for informational purposes.

  The Subnet Allocation option provides a straightforward way to
  allocate a subnet from DHCP, useful for a simple Dialin Aggregation
  box, or to implement a Hierarchical chain of DHCP Servers, each one
  in turn leasing one or more subnets to the next DHCP Server down the
  chain. This option is specified in such a way as to use one DHCP
  Option number, while using suboption numbers for each function.
 
And then strike the last paragraph of the Introduction entirely.

3. Procedural: The document writeup says:

  There was nothing controversial about this document.  There was
  consensus in the working group to include the following text in the
  document:

Something is odd about this. If there was nothing controversial, why was the text added between versions -11 and -12? When I went to take a look at the list archive to see if I could figure out why, I did not see *any* comment on the document between version -11 and version -12. That doesn't really justify saying that there was consensus in the WG for the text. Please explain.

[Ballot comment]
I agree about the suggested title change. I think Informational is fine for this type of documents. This is NOT a standard, we are describing a vendor's pre-standard approach to something. Its also not an experiment either.

[Ballot comment]
I agree with Adrian Farrel about the document title. Changing it to something like "Description of Cisco Systems' Subnet
Allocation Option for DHCP" would be consistent with other vendor uses of reclassified options from RFC 3942, as evidenced by RFC 4578 ("Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)") and RFC 5071 ("Dynamic Host Configuration Protocol Options Used by PXELINUX"). If that change is made, I think Informational is fine (since RFC 4578 and RFC 5071 are also informational).

[Ballot discuss]
I'm afraid I agree with Pete's Discuss so strongly that I will raise it as my own Discuss.

Either this document should be recast as "Description of Cisco Systems' Subnet Allocation Option for DHCP" (in which case Informational is acceptable) such that it is obvious what and why people might be implementing. Or it should be put on to the Standards Track.

For the avoidance of doubt, I do not object to documents describing what is in the field and allowing people to decide to interoperate with that. In particular, in the 3942 context, this is good and proper. But I do not like the way this document sits on the fence between defining "a new DHCP option" and being Informaitonal.

[Ballot comment]
#1) I support Dan's discuss wrt whether this is for IPv4 or IPv6.  Just say so early on in the document.

#2) In Section 3.1 and 3.2, please indicate whether unused flags are ignored by a recipient if non-zero.

#3) Section 3.2.1 contains the following:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Network                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Prefix     |     Flags |h|d|   Stat-len    |  Optional stats...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Addr   = IPv4 network number (4 octets)

Did you mean "Network"? There is no "Addr" in the table above.

#4) Section 3.2.1.1 contains the following:

   Fewer fields may be included than what is specified in any current
   RFC, but all fields which are included MUST remain in order specifed
   here.

Can you elaborate on what this mean? Does it mean only including 1 or 2 of the specified fields?

[Ballot discuss]
1. Technical (thanks Alexey): In section 3.2:

  The "Name" in this suboption is simply a number of octets and
  need not be ASCII text.

Please specify as UTF-8 [RFC3629] unless you've got some really impressive reason not to.

2. Procedural: I don't understand why this document is being put forward as Informational. It is clearly protocol. It clearly has the potential to be used by multiple implementors. It's converting an private code point to a public one. It's being put forth by a WG and is not individuals documenting a private protocol. What reason is there for this to not be either Proposed Standard or Experimental. Please explain.

3. Procedural: The document writeup says:

  There was nothing controversial about this document.  There was
  consensus in the working group to include the following text in the
  document:

Something is odd about this. If there was nothing controversial, why was the text added between versions -11 and -12? When I went to take a look at the list archive to see if I could figure out why, I did not see *any* comment on the document between version -11 and version -12. That doesn't really justify saying that there was consensus in the WG for the text. Please explain.

[Ballot comment]
So I don't mind if I don't get an answer for this one or not but I always
wondered, (though never bothered to ask;-) if an IPR declaration
like this one [1] says that "if this standard blah blah then <>"
but then the document ends up informational, as in this case, then
do the stated terms apply or not?

[1] https://datatracker.ietf.org/ipr/811/

[Ballot comment]
I am fine with approving this document. I have a number of comments (in part based on the OPS-DIR review performed by Fred Baker) that could improve IMO the clarity and accuracy of the document, but none is a show-stopper:

1. I suspected this was an IPv4 prefix throughout, the only clues I had of that were that the protocol in question is "DHCP" as opposed to "DHCPv6", a statement in a field description in section 3.2.1 indicated that "Addr" designates an "IPv4 Network Number"  (which seems strange; why not call it a prefix or a network number as opposed to an 'Addr'?), and the distinction from DHCPv6 Prefix Delegation discussed in section 9. If the authors revise the draft, I would suggest replacing "prefix" or "subnet" with "IPv4 prefix" or "IPv4 Subnet" in the title, at least one place in the abstract, and at least one place in the introduction.

2. I think that the statement in the introduction 'Alternate methods of allocation, such as AAA are not appropriate for various reasons and the most straight-forward way to accomplish this allocation is via DHCP. ' needs either to be explained or dropped.

3. In Section 3.2.1.1 - 'Additional statistics may be added to this option in the future. If so, they MUST be appended to the end of the option.' s/to the end of the option/immediately after the already defined statistics fileds/

4. In section 4.2:

The Server need not reserve the subnets which are being offered, but
  SHOULD strive to not offer the same subnets to another DHCP Client
  until a reasonable time period (implementation dependent) has passed.
  (This is similar to normal DHCP address allocation.)


s/SHOULD strive to not offer/SHOULD not offer/

5. The usage of the kewwords is inconsistent and in a number of place it looks like capitalized keywords need to be used. A list that may not be complete:
- section 4.2: s/the DHCP Server should respond with a DHCPOFFER message/the DHCP Server SHOULD respond with a DHCPOFFER message/
- section 5.3: s/The DHCP Client should send a DHCPRELEASE/The DHCP Client SHOULD send a DHCPRELEASE/
- section 5.4: s/The DHCP Server may issue a DHCPFORCERENEW [RFC3203] message/DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message/
- section 6: s/A DHCP Client may request from the DHCP Server a list/A DHCP Client MAY request from the DHCP Server a list/
- section 6.1: s/The DHCP Client DHCPDISCOVER message, when used to discover already allocated subnet information, should contain a Subnet-Request suboption/The DHCP Client DHCPDISCOVER message, when used to discover already allocated subnet information, SHOULD contain a Subnet-Request suboption/
- section 6.2: s/Any DHCP Server which has allocated subnets to the Client should respond/Any DHCP Server which has allocated subnets to the Client SHOULD respond/
- section 6.3: s/The Client, upon receiving any Server DHCPOFFER messages containing Subnet Information suboption information with the 'c' ("Client") bit set, should gather the network number/The Client, upon receiving any Server DHCPOFFER messages containing Subnet Information suboption information with the 'c' ("Client") bit set, SHOULD gather the network number/




'

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:  (Subnet Allocation Option) to Informational RFC


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Subnet Allocation Option'
  as an Informational RFC

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-06-22. 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 defines a new DHCP option which is passed between the
  DHCP Client and the DHCP Server to request dynamic allocation of a
  subnet, give specifications of subnet(s) allocated, and report usage
  statistics.  This memo documents the current usage of the option in
  agreement with [RFC3942], which declares that any pre-existing usages
  of option numbers in the range 128 - 223 should be documented and the
  working group will try to officially assign those numbers to those
  options.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/811/

Submission questions for "Subnet Allocation Option"

(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?

John Jason Brzozowski, dhc WG co-chair
I have reviewed the document and I believe 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?

The document has been sufficiently reviewed by members of the dhc WG.

At this time there are no concerns about the breadth and depth of the review conducted for this document.  This document is ready for publication.

(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?

No, the document has been thoroughly reviewed.  No additional reviews appear to be required at this time.

(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 specific concerns about this document.  This document is ready for publication.

There were some comments pertaining to IPR on the dhcwg mailing list.  These comments did not appear to be gating to the publication of this draft as informational.

(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 was good level of WG involvement in the development leading up to the final version of this document.  There was strong consensus from a number of individuals.  There were no objections in response to the WG last call.  I believe the WG as a whole understands and agrees with the document.

(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.)

No.

(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?

All idits have been satisified.  All review criteria has been met, no additional reviews are required.

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

The references are split into normative and informative.  There are no problematic normative references.

(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 [RFC2434].  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.  It specifies reservations that are appropriate for the clearly identified existing registries.

(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?

Not applicable.

(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
Relevant content can frequently be found in the abstract and/or introduction of the document.  If not, this may be
an indication that there are deficiencies in the abstract or introduction.


  This document defines a new DHCP option which is passed between the
  DHCP Client and the DHCP Server to request dynamic allocation of a
  subnet, give specifications of subnet(s) allocated, and report usage
  statistics.  This memo documents the current usage of the option in
  agreement with [RFC3942], which declares that any pre-existing usages
  of option numbers in the range 128 - 223 should be documented and the
  working group will try to officially assign those numbers to those
  options.

Working Group Summary
Was there anything in WG process that is worth noting?  For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was nothing controversial about this document.

Document Quality
Are there existing implementations of the protocol?  Have a significant number of vendors indicated their plan to implement the specification?  Are there any reviewers that merit special mention as having done a thorough review,  e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?  If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?  In the case of a Media Type review, on what date was the request posted?

There is at least one existing implementation of this specification.  It is not known if additional DHCP server implementations have or will implement this draft.  Existing implementations are believed to be available today.

Beyond what was performed with key members of the dhc WG no special reviews were performed or required.

Personnel
Who is the Document Shepherd for this document?
Who is the Responsible Area Director?
Is an IANA expert needed?

Shepherd: John Jason Brzozowski
AD:      Ralph Droms
IANA:    N/A