Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

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

Kim:

Thanks for the thorough review. I think I did (almost) all of these. You will see them in the -09 when published.

One that I skipped is #19 as we use this convention in other places (total of 7) in the document when the reference is just for informational purposes (following the reference isn't key to the point being made and is just "For Your Information" if you case). I have raised it for the co-authors to discuss to see if we want to remove the parenthesis everywhere, switch to commas, or leave as is. We may also just punt this to see what the RFC-Editor may do.

For Appendix B and C, there were a bunch of issues with these and I think they have been corrected (there a few other issues). I also wonder whether we should just drop these as I'm not they add much value -- and likely if something if "off" in them, may cause more confusion. So, another point to be raised to the co-authors.

The co-authors are expecting to discuss the issues on Wed June 14th @ 0800 EDT. Those interested in participating in that discussion can contact me for meeting details (https://jitsi.tools.ietf.org/dhcpv6 or webex in case jitsi has issues - it sometimes does).

- Bernie

-----Original Message-----
From: Kim Kinnear (kkinnear) 
Sent: Thursday, May 18, 2017 3:15 PM
To: [e-mail]; Ralph Droms <[e-mail]>
Cc: Kim Kinnear (kkinnear) <[e-mail]>; Bernie Volz (volz) <[e-mail]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Folks,

I did a pretty complete review of the document, and while most of the
first issues I found were editorial, I found a number of technical
issues as I went along.  Of the 33 issues I found (all of which I felt
important enough to write down), the following stand out as
particularly important:

Editorial: #8, #23

Technical: #10, #14, #15, #16, #17, #20.5, #21, #22, #26
           #27, #28, #30, #31, #32

I have read this document, and I approve its moving forward.

I would very much like to see the issues I've highlighted above
addressed, either by taking my suggested corrections, or by explaining
why the document is correct as it stands.  

As it happens, a few of the issues I found were from RFC 3315
and not added by the -bis process.  But, as I commented below,
that doesn't make them correct.  

Here are the issues:

1. Section 11, para 2, "such are those" -> "such as those"

2. Section 11, para 3, last sentence, "as specfic in" -> "as specified in"

3. Section 13.2, para 4, "... with additional condition that the new
   address is not duplicated with any assigned addresses" -> 
   "... with the additional condition that any new address is not 
   the same as any assigned address."

4. Section 13.2, para 7, "of temporary address is unlinkability of different
   actions over time." -> "of a temporary address is to make it 
   difficult to link the address to different actions over time."

5. Same as above, "though DHCP provides such possibility" -> 
   "though DHCP provides for such a possibility"

6. Section 14.2, list with 3 elements.  I think we want to remove
   the ", and" at the end of item 2, the comma at the end of item
   1, and the period at the end of item 3.  In particular, the 
   ", and" kind of implies that item 2 and item 3 are linked, but I
   don't think they are.

7. [retracted correction: diff had a problem not present in the actual draft]

8. Section 18, para 5.  Paragraph beginning with "The client has many..."
   and containing a list with 4 elements.  This list appears to have been
   moved to the first part of the section and slightly improved there, 
   and it looks like this older version of the list should have been 
   deleted.

9. Section 20.4.1.  para 3 (or 2, depending on how you count).  
   "The format of the Authentication information..."
   -> "The format of the authentication information ...".  In the option
   description (21.11), "authentication information" is not capitalized.

10. Section 20.4.3, para 1, "... in the initial Reply ..." -> "... in an 
    Authentication option in the initial Reply ..."

11. Section 21.4, para 2 after table after Figure 15. "Each IA_NA ... attached
    to." -> "Each IA_NA carries one "set" of non-temporary addresses; it is up
    to the server policy to determine how many addresses are assgined,
    but typically at most one address is assigned from each prefix assigned to
    the link to which the client is attached."  Note removal of double quote
    before 'it' as well as improved wording.

12. Section 21.5, para 6 after table after Figure 16. "... MAY request that
    valid lifetime ..." -> "... MAY request that the valid lifetimes ...".
    Two changes, added "the", and made lifetime plural.  I'm not positive
    about making lifetime plural here, please validate that.

13. Same para as #12, "Extending only valid but not preferred ..." ->
    "Extending only the valid but not the preferred ..."

14. Section 21.6, para 1.  The last sentence "The Options fields
    of the IA_NA or IA_TA option encapsulates those options that are 
    specific to this address." hasn't changed since the -05 draft, but
    it *is* different from RFC 3315, which said: "The Options field
    encapsulates those options that are specific to this address."
    I find the current language confusing.  Why would the Options
    field of the IA_NA or IA_TA encapsulate options that are specific
    to this address, when there can be multiple IA Address options in
    an IA_NA or IA_TA?  I would have expected this sentence to read
    "The IAaddr-options field encapsulates those options that are
    specific to this address.", since there seems to be no other 
    point to having an IAaddr-options field.  But in any case, this needs
    to be figured out and fixed, as it is plenty confusing as it now
    stands.

15. Section 21.7, para 1 after table after Figure 18.  

    Sections 21.24 and 21.25 state that the SOL_MAX_RT and
    INF_MAX_RT options MUST always be in every Option Request option.
    But this is contradicted by Table 1, which says that they MUST
    only appear for certain message types.  I believe that Table 1
    is in fact more correct than the statements in Section 21.24 and 21.25.
    In which case, I would suggest that a new sentence be added here:
    "For certain message types, some Option codes MUST be included
    in the Option Request option, see Table 1 for details."

    And, Sections 21.24 and Section 21.25 should be corrected to
    mention the message type qualification:

    Section 21.24, para 1 after table after Figure 38:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    a SOLICIT message."

    Section 21.25, para 1 after table after Figure 39:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    an Information-request message."

16. Section 21.7, para 2 after table after Figure 18. "Only container
    options MUST appear in the Option Request," --- I think that this 
    is simply incorrect.  The better way to say this would be "Only container
    options MAY appear in the Option Request option,", but that is also
    incorrect.  I believe that the statement is "Only top-level options
    MAY appear in the Option Request option."  The next sentence
    should then be: "Options encapsulated in a container option MUST
    NOT appear in an Option Request option, see [RFC7598] as an
    example of container options."  

17. same as #16.  I think the last sentence should be replaced with 
    "Options MAY be defined which specify exceptions to the restriction
    on including encapsulated options in an Option Request option.  For
    example, the Option Request option MAY be used to signal support for
    a feature even when that option is encapsulated, as in the case of the
    Prefix Exclude option [RFC6603].  See Table 1."

18. Section 21.11, Authentication Option.  In Figure 22, there is
   "auth-info" at the start of the "authentication information" section.
   I would remove the "auth-info", since this field is actually known
   as "authentication information" in the table below Figure 22.  I
   don't think the "auth-info" label adds any value, and is rather
   inconsistent and might be confusing. 

19. Section 21.14, DISCUSSION, para 1.  Last sentence, RFC references
    have extraneous () around references.

20. Same as #19, para 2.  Replace with "The problem of unused leases can be
    minimized by designing the DHCP service so that only one server responds
    to the Solicit, by using relatively short lifetimes for newly assigned
    leases, or by having DHCP clients release unused leases using the 
    Release message."  Whether or not this paragraph is used, the 
    word "initiatively" isn't commonly used, and some references
    label it "nonstandard" and others show it from the late 1700's.
    I don't think it belongs in an RFC.

20.5 Section 21.16, last sentence.  "Each instance of
     OPTION_VENDOR_CLASS can carry multiple sub-options."  I see
     no sub-options at all here, using the definition of sub-option
     from RFC 7227 (see item #21 for a link to the relevant section
     of this RFC).  I see two possible things that this sentence
     could be trying to say:

     a) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        enterprise-number and vendor-class-data pairs."

     b) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        instances of vendor-class-data, all relating to the same
        enterprise-number."

    I don't know which was intended, if either. Or, possibly, both.
    I know that (b) is true, and I'm pretty sure that (a) is true
    but I could be wrong about that.  If it is true, then it would
    be really good to confirm it here.  This sentence is new since
    RFC 3315.

21. Section 21.17.  This section uses the term "encapsulated options"
    throughout, which I believe is technically incorrect.  See:
    https://tools.ietf.org/html/rfc7227#section-9 
    which explains the distinction between "encapsulated options"
    and "sub-options" really well.  I believe that this section
    should be discussing "sub-options", not "encapsulated options",
    per RFC 7227.   My suggestion would be to rename the "option-data"
    field in Figure 30 as "sub-option-data", to distinguish it from
    the "option-data" field in Figure 31.  And replace the "option-data"
    line in the table after Figure 30 with:

    "sub-option-data    Sub-options, interpreted by vendor-specific
                        code on the clients and servers."
    
    I would replace the paragraph before Figure 31 with:
    "The sub-option-data field MUST be encoded as a sequence of 
    code/length/value fields identical in format to the DHCP 
    options field (see Section 21.1).  The sub-option codes are defined 
    by the vendor identified in the enterprise-number field, and are 
    not managed by IANA.  See Section 9 of [RFC7227].
    Each of the sub-options is formatted as follows:"

    In the table below Figure 31:

    "opt-code           The code for the sub-option.

    option-len          An unsigned integer giving the length of the
                        option-data field in this sub-option in
                        octets.

    option-data         The data area for the sub-option."

    Replace the last line of the para 1 after the table after Figure 31:
    "... MAY contain multiple encapsulated options." -> "... MAY contain
    multiple sub-options."

22. Section 21.21, para 6 after table after Figure 35.  This paragraph
    makes no sense.  In RFC 3633 (the PD RFC), this paragraph talked
    about which numbers to put in T1 and T2.  Now, it talks about
    T1 and T2 "fields" and T1 and T2 "parameters".  The way it comes
    out now, it seems like it is talking about what the *client*
    should be doing with the T1 and T2 fields, not the server.  In
    which case, the sentence should start out "In a message sent
    by a server to a client, the client MUST use..." This is exactly
    what the text in the IA_NA option says, for what that is worth.

    But as it is, it can't be correct.

23. Section 21.22, para 3 after table after Figure 36.  This sentence
    also appears (slightly differently) in Section 21.6, the IA
    Address option.  "A client discards any prefixes for which the
    preferred lifetine is greater than the valid lifetime."  Shouldn't
    this be "A client MUST discard any prefixes..." in both
    sections?  

24. Section 23, para 1, sentence 2.  Replace "of said document" with 
    "of that document".

25. Section 27.1, Normative References.  I think that RFC 7227
    should be normative because if its discussion of the distinction
    between encapsulated options and sub-options in Section 9
    of RFC 7227.

26. Appendix B., Info Refresh Time column.  I don't understand why
    this option is shown for the Inform. message.  I believe that
    the option code for it MUST be in an Option Request option for
    an Inform. message.  But not that the option itself must be in
    the Inform. message, which is what this table is all about.
    Section 21.23 says directly that this option "MUST only appear
    in the top level option area of Reply messages.", so something
    is wrong in one of these places.  I think the table in Appendix
    B is the one that is wrong, and that the * for Info Refresh
    Time should be removed from the row titled Inform.

27. Appendix B., SOL_MAX_RT column.  I believe that the option code
    for the SOL_MAX_RT option MUST appear in an Option Request option
    in a Solicit message, but this table isn't about the Option Request
    option, it is about messages.  So I believe that this is wrong,
    and that the * for SOL_MAX_RT should be removed from the Solicit
    message row.

28. Appendix B., INF_MAX_RT column.  I can see no reason why this is
    listed as an option to appear in the Advertise message.  I think
    this is simply an error and should be removed. 

29. Appendix B. Interesting that the document mentions User Class,
    Vendor Class, and Vendor Specific Options as all valid for
    Relay-Forward and Relay-Reply messages.  I'm not saying that
    isn't OK, but I didn't see anything in this document that would
    suggest anything other than an Interface Id option would go in
    a Relay-Forward or Relay-Reply message.  Maybe I missed it.

30. Appendix C.  This table is only relative to this
    document.  Some of these options can appear in other DHCPv6
    options defined in other RFC's.  That exist today, not just
    future ones.  Perhaps replacing the existing sentence "The
    following ... other options:" with "The following table indicates
    with a "*" where options defined in this document can appear
    in the options field of other options defined in this document.
    Other RFC's define additional situations where options defined
    in this document are encapsulated in other options." would make
    it more clear that this isn't the final word on what options
    can appear inside of what other options.

31. Appendix C.  The sentence describing this table is moderately
    misleading.  "where options can appear in the options field of
    other options." would seem to indicate that the column headings
    along the top of the table are all options.  However, the first
    column isn't the name of an option, it is (presumably) the
    options field of any message.  I think that we should remove
    this column, since any information that it contains is already
    covered (and in more correct detail) by the information in
    Appendix B, which discusses precisely which options can appear
    in the options field of individual messages.  If I'm wrong about
    what the "Option Field" column represents, then it would be
    good to explain it more clearly.

32. Appendix C.  Columns Relay-Forw, Relay-Reply, and Note.
    The note is just wrong, near as I can tell.  There are no
    Relay-Forw or Relay-Reply options.  There are Relay-Forward and
    Relay-Reply messages.  I think having a Relay-Forw and Relay-Reply
    column in this table is very misleading, since as I said above,
    this table seems to be for options.  These aren't options, they
    are messages.   We already have the Relay Message option allowed
    in the Relay-Forward message and Relay-Reply message in Appendix
    B.  In addition, the data there conflicts with the data here
    for the Relay-Forward and Relay-Reply messages.  I don't know
    what someone was trying to communicate here, but I think that we 
    need to remove the Relay-Forw and Relay-Reply columns, and
    the Note.

    I recognize that this is left over from RFC 3315 and wasn't
    something added as part of the current process, but that doesn't
    make it right.

33. Appendix C.  If we remove the first and last two columns, as
    I think makes sense, since this information is already covered
    in Appendix B, we are left with 3 options in the left column
    that have any * in any of the right 4 columns.  Not the end of
    the world, but we could probably explain this with a sentence
    or two.  For instance: "Several options may themselves appear
    in the options field of other options defined in this document.
    The IA Address options may appear in the options field of either
    the Identity Association for Non-temporay Addresses option or
    the Identity Association for Temporary Addresses option.  The
    IA Prefix option may appear in the options field of the Identity
    Association for Prefix Delegation option.  The Status Code
    option may appear in the options field of any of the three
    Identity Association options just discussed."  I have no
    particular preference toward either approach (i.e., keep the
    table or replace it with the above paragraph), but offer the
    paragraph to show one possibility.


Thanks -- Kim

> On May 9, 2017, at 10:52 AM, Bernie Volz (volz) <[e-mail]> wrote:
> 
> Hello:
>  
> The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.
>  
> Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!
>  
> Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.
>  
> If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:
>  
> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt
>  
> The list of issues we recorded and action/assignee details are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98(some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report)
>  
> One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.
>  
> The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.
>  
> -          Tomek & Bernie
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg