datatracker.ietf.org
Sign in
Version 5.7.4, 2014-11-12
Report a bug

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

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

Summary: Needs a YES.

Adrian Farrel

Comment (2012-04-08 for -13)

Thanks for the update addressing my concerns

Jari Arkko

Comment (2011-06-23 for -)

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.

Stephen Farrell

Comment (2011-06-20 for -)

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/

[Dan Romascanu]

Comment (2011-06-20 for -)

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]

Comment (2011-06-23 for -)

I agree with Adrian's Discuss.

[Peter Saint-Andre]

Comment (2011-06-21 for -)

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

[Russ Housley]

Comment (2011-06-22 for -)

  Please update the title of this document to indicate that this is a Cisco
  protocol.

[Sean Turner]

Comment (2011-06-21 for -)

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