Re: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-07.txt

["Bernie Volz (volz)" <[e-mail]>]

I support this document moving forward, but (oh what a surprise?) I have
some nits:

- All of the option drawings need to indent the bits count lines by 1:

   0                   1                   2
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |     Len       |     Flags     | Suboptions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should be:

    0                   1                   2
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |     Len       |     Flags     | Suboptions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- In section 3 (and actually all option format sections), I think the
text about the (sub) option length excluding the code and len fields is
unncessary as that is the norm for DHCP options.

It may also be worth identifying the length of the options (minimum or
fixed). For example, section 3.1's suboption always has a length of 2?

For the section 3 flags field, shouldn't it specify that unused flag
bits must be zero (in this case, the entire field MUST be 0).

- In section 3.1 (other than the len issue mentioned above), the text
uses "P" whereas the suboption diagram and field definitions use
"Prefix". There are multiple references to P or "P" field.

Also, as there can be multiple instances of this suboption, I think
there should be a caution that instances of this suboption MUST NOT be
concentated. I don't think the RFC 3396 applies to suboptions, but it
can't hurt to make this very clear.

For the case where the "i" flag is "1", can this only be used in
DHCPDISCOVER? And, in that case, I think there is only a DHCPOFFER
response (no subsequence DHCPREQUEST/DHCPACK sequence would follow).
Perhaps that should be stated? Or, did I misunderstand this?

- In section 3.2.1, as all flags have descriptions for what the "set"
('1') and "clear" ('0') values, shouldn't that be the case for the 'd'
flag?

- In section 4.2, 1st paragraph:

   including the Subnet-Information suboption in order to specify the
   subnet(s) which it is willing to allocate to the Client in order to
   fill the request(s).

Should "fill" be "fulfill"?

- In section 5.1, 2nd paragraph, it uses "w.r.t."? Why not just say "as
described above in the Subnet-Information suboption format section
(3.2)"?

In the 3rd paragraph, "Ususable" is used ... This should be "Unusable".

- In section 5.4, I think "This message effectively immediately times
out the Client's lease(s) for the allocated subnet(s)." is not really
correct. The DHCPFORCERENEW is supposed to cause the client to renew,
but it can't "time out the lease(s)". That may be the RESULT of the
DHCPREQUEST to renew the leases, but the DHCPFORCERENEW does not cause
that by itself. (And, in fact the 2nd paragraph makes that clear when
describing the DHCPNAK that may be returned for the DHCPREQUEST).


The examples in section 8 are nice - for complex option definitions (as
this is), they are extremely useful.


Again, I support this moving forward and none of the above are "major"
issues - just nits to improve the document.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Ralph Droms (rdroms)
Sent: Monday, September 08, 2008 3:35 PM
To: DHC WG
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-07.txt

This message announces a WG last call on "Subnet Allocation Option"
<draft-ietf-dhc-subnet-alloc-07.txt>.  The last call will conclude at
1700PDT on Monday, 2008-09-29.  This document is intended for
publication as an Informational RFC.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

draft-ietf-dhc-subnet-alloc-07.txt 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..  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-07.txt

- John Brzozowski, Ralph Droms
   dhc WG chairs

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg