Re: [dhcwg] [dhc] #14: Response to WG last call on draft-ietf-dhc-subnet-alloc

#14: Response to WG last call on draft-ietf-dhc-subnet-alloc
------------------------------+---------------------------------------------
 Reporter:  rdroms@cisco.com  |        Owner:  Bernie Volz
     Type:  defect            |       Status:  new        
 Priority:  major             |    Milestone:             
Component:  subnet-alloc      |      Version:             
 Severity:  In WG Last Call   |   Resolution:             
 Keywords:                    |  
------------------------------+---------------------------------------------
Description changed by rdroms@cisco.com:

Old description:

> 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

New description:

 {{{
 #!html
 <pre>

 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
 </pre>
 }}}

--

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dhc/trac/ticket/14#comment:1>
dhc <http://tools.ietf.org/wg/dhc/>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg