Skip to main content

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

Yes

(Ralph Droms)

No Objection

(Gonzalo Camarillo)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 12 and is now closed.

Ralph Droms Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2012-04-08) Unknown
Thanks for the update addressing my concerns
Dan Romascanu Former IESG member
No Objection
No Objection (2011-06-20) Unknown
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/ 
 

 

'
David Harrington Former IESG member
No Objection
No Objection (2011-06-23) Unknown
I agree with Adrian's Discuss.
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2011-06-23) Unknown
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.
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection (2011-06-21) Unknown
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).
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2011-06-22) Unknown
  Please update the title of this document to indicate that this is a Cisco protocol.
Sean Turner Former IESG member
No Objection
No Objection (2011-06-21) Unknown
#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?
Stephen Farrell Former IESG member
No Objection
No Objection (2011-06-20) Unknown
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 <<terms>>" 
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/
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown