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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 May 2017 14:52:50 +0000

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

---

From: kkinnear <[email-masked]>
Date: Thu, 18 May 2017 15:15:22 -0400

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) <[email-masked]> 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.
>  
> 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.
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Tue, 23 May 2017 13:18:00 -0700

On Tue, May 9, 2017 at 7:52 AM, Bernie Volz (volz) <[email-masked]> wrote:

> 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!

I'd still abstain about whether to advance the document as I stated
for the previous WGLC:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html
but I've checked if the 08 version has addressed my LC comments.

I found some of them still open (perhaps they are intentionally left
open or unchanged, but it's not clear to me).  I'm listing them below,
with followup comments for some of them.

>> - I'm okay with deprecating the delayed authentication protocol,
>> but I'm not sure if it's okay to ship the spec with no built-in
>> authentication (the reconfigure key protocol is very limited and
>> too weak).

>> - I wonder whether we should still keep IA_TA.

>>   link-local address        An IPv6 address having a link-only scope,
>>                             indicated by having the prefix (FE80::/10),
>>  You might want to lower-case the prefix (i.e., to "fe80::/10").

This is not fully addressed as the case is still mixed (Sections 7.1
and 24 use upper case hex).

>> - Section 5.2
>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>  s/RFC2462/RFC4862/.

and there are still more references to RFC2462.

>> - Section 5.4
>> [...] the requesting router MUST set the valid lifetime in those
>> advertisements to be no later than the valid lifetime specified in
>> the IA_PD Prefix option.
>>  "no later than" sounds awkward as the lifetime is a duration, not
>>  a particular point in time.

This is simply open as before.

>> - Section 8.1
[...]

>> site-scope unicast address has been deprecated.  Also, the phrase
>> "global or ULA" is awkward as ULA is a global (scoped) address.

The 08 version states:

                           This is typically a globally unique
                           address or unique local address (ULA)
                           [RFC4193],

This is still awkward to me, since in a sense ULAs are also "globally
unique" (even if the uniqueness is not 100% guaranteed).  Personally
I'd simply avoid mentioning ULAs unless there is a specific to reason
to refer to it in the context (and I don't see such a reason here),
but if we want to refer to ULAs here, I'd say, e.g., "a global address
(including unique local addresses)".

>> - Section 10

>> [...] The DUID is designed to be unique across all DHCP clients and
>> servers, and stable for any specific client or server - that is,
>> the DUID used by a client or server SHOULD NOT change over time if
>> at all possible;

>> I guess this property is now changing because of the privacy
>> concerns.

The main change that may be related to this comment is probably the
following new sentence:

   [...]  The client may change its DUID as specific in [RFC7844].

I personally don't think this fully addresses the point of the
comment, although I can live with it.  btw, I believe  there's a typo:
s/specific/specified/.

>> - Section 15.11

>>   -  the message was not unicast to the client.

>> I'm not sure why we bother to say this, and only for Reconfigure.
>> Is there any case where a DHCPv6 message to a client isn't
>> unicasted at all?

There doesn't seem to be any change regarding this comment.  I was not
sure if it was intentional or oversight.

>> - Section 17.1.10.1
>> "no later than" sounds awkward for these lifetimes (see also Sec
>> 5.4).

>> - Section 17.1.10.1
[...]
>> Specifically, the bullet description seems to lead to multiple
>> separate state machines for different bindings.

These two don't seem to be addressed.

>> - Section 18.1.1
>>  s/global, ULA [RFC4193] or site-scoped/global/ (see comment on Sec 8.1)

The revised text still has an issue:

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or unique local [RFC4193] address

"global or unique local" is redundant since ULAs are global addresses
(scope wise).

>> - Section 18.1.2
>> s/global or site-scoped/global/ (see above)

Same here.

>> - Section 19.4
[...]
>> This statement now sounds awkward since this is now the only
>> defined authentication protocol. (see also comment on Section
>> 17.2.2)

There doesn't seem to be any change to address this point.

>> - Section 20.7
>>   encapsulated in the container MUST NOT by in the Option Request, see
>>  s/Option Request/Option Request option/

'option' (after 'Request') is still missing.

>> - Section 20.22
[...]
>> This choice of valid/preferred lifetime in an IA prefix and the
>> (possible) relationship between them and those lifetimes advertised
>> in the delegated site do not make perfect sense to me. [...]

I don't think the revised version addresses the main point.  The new
text simply avoids saying specifics about these lifetimes, but then
it's even more unclear about what these lifetimes are (especially the
preferred lifetime).

>> - Section 20.23
[...]
>> The expected usage is not very clear to me here.  Is it intended to
>> be used for Advertise and apply the value to the ongoing
>> Solicit-Advertise exchange?  Or is it mainly intended to be used
>> for a possible subsequent restart of a DHCPv6 session?

I guess it was supposed to be addressed by the newly added paragraph
at the end of the section:

   The requirement for the client to request SOL_MAX_RT serves two
   purposes.  First, it distinguishes between legacy and modern clients.
   Second, it allows modern clients to take advantage of the
   configurable SOL_MAX_RT values, even if the server is a legacy one.

of which I don't understand the second purpose: if the server is
legacy, how the client can benefit from the option?

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 26 May 2017 17:56:18 +0000

Hi Jinmei:

Thanks for reviewing. Comments from me inline below (BV>).

You can view the changes to the XML made from these comments at:

https://github.com/dhcwg/rfc3315bis/commit/357e98d84f728e5909598a82672562b0889f1f13

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Tuesday, May 23, 2017 4:18 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

On Tue, May 9, 2017 at 7:52 AM, Bernie Volz (volz) <[email-masked]> wrote:

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

I'd still abstain about whether to advance the document as I stated for the previous WGLC:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html
but I've checked if the 08 version has addressed my LC comments.

I found some of them still open (perhaps they are intentionally left open or unchanged, but it's not clear to me).  I'm listing them below, with followup comments for some of them.

>> - I'm okay with deprecating the delayed authentication protocol, but 
>> I'm not sure if it's okay to ship the spec with no built-in 
>> authentication (the reconfigure key protocol is very limited and too 
>> weak).

BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:

   Many of these rogue server attacks can be mitigated by making use of
   the mechanism described in [RFC7610].

>> - I wonder whether we should still keep IA_TA.

BV> We decided as a WG not to remove IA_TA. See https://trac.tools.ietf.org/group/dhcpv6bis/ticket/124.

>>                             indicated by having the prefix 
>> (FE80::/10),  You might want to lower-case the prefix (i.e., to "fe80::/10").

This is not fully addressed as the case is still mixed (Sections 7.1 and 24 use upper case hex).

BV> OK. The FF0x: cases were just missed. This is now fixed.

BV> This is by design. RFC4862 does not mention the M & O bits so we can't reference that RFC. We documented the reason for this in Appendix A:

   26.  ...
                                        Note that in a few
        places, older obsoleted RFCs (such as RFC2462 related to M and O
        bit handling) are still referenced as the material cited was not
        added in the replacement RFC.

BV> The other place we uses is when mentioning "stateful address autoconfiguration protocol" as RFC 4862 does not use this terminology except in Appendix C:

   o  Avoided the wording of "stateful configuration", which is known to
      be quite confusing, and simply used "DHCPv6" wherever appropriate.

BV> I hope this explains to you why we leave this reference in the 4 places (excepting Appendix A) where it is still used.

>>  "no later than" sounds awkward as the lifetime is a duration, not  a 
>> particular point in time.

BV> Unless you suggest some text, we will leave this be. I think the point of the text is rather clear.

[...]

The 08 version states:

This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".

BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.

>> servers, and stable for any specific client or server - that is, the 
>> DUID used by a client or server SHOULD NOT change over time if at all 
>> possible;

>> I guess this property is now changing because of the privacy 

The main change that may be related to this comment is probably the following new sentence:

I personally don't think this fully addresses the point of the comment, although I can live with it.  btw, I believe  there's a typo:
s/specific/specified/.

BV> Thanks for catching typo, will be fixed. As you can live with it, we will leave alone otherwise.

>> Is there any case where a DHCPv6 message to a client isn't unicasted 
>> at all?

There doesn't seem to be any change regarding this comment.  I was not sure if it was intentional or oversight.

BV> This is intentional as the specification clearly does NOT allow for multicast Reconfigure to be valid. Perhaps a future draft will support this, but for now this prohibition is appropriate.

>> "no later than" sounds awkward for these lifetimes (see also Sec 

BV> See above.

[...]
>> separate state machines for different bindings.

BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:

   The server controls the time at which the client should contact the
   server to extend the lifetimes on assigned leases through the T1 and
   T2 parameters assigned to an IA.  However, as the client Renews/
   Rebinds all IAs from the server at the same time, the client MUST
   select a T1 and T2 time from all IA options, which will guarantee
   that the client will send Renew/Rebind messages not later than at the
   T1/T2 times associated with any of the client's bindings (earliest
   T1/T2).

"global or unique local" is redundant since ULAs are global addresses (scope wise).

BV> See comment earlier as I think mention both does no harm and helps to clarify that it would be either.

Same here.

BV> See comment earlier as I think mention both does no harm and helps to clarify that it would be either.

[...]
>> This statement now sounds awkward since this is now the only defined 
>> authentication protocol. (see also comment on Section
>> 17.2.2)

BV> While it does sound a bit awkward, we left this in given seDHCPv6 work as there would be little point in using RKAP if that was used. We can remove "the client and server are not using any other authentication protocol" and assume the seDHCPv6 will make this clear.

>> - Section 20.7
>>   encapsulated in the container MUST NOT by in the Option Request, 
>> see  s/Option Request/Option Request option/

BV> OK, this must have just been missed.

[...]
>> in the delegated site do not make perfect sense to me. [...]

I don't think the revised version addresses the main point.  The new text simply avoids saying specifics about these lifetimes, but then it's even more unclear about what these lifetimes are (especially the preferred lifetime).

BV> Unless you provide text, I think we'll leave this alone as mentioned earlier we feel that this document is not the one that should describe how these lifetimes are to be used.

[...]
>> Solicit-Advertise exchange?  Or is it mainly intended to be used for 
>> a possible subsequent restart of a DHCPv6 session?

I guess it was supposed to be addressed by the newly added paragraph at the end of the section:

of which I don't understand the second purpose: if the server is legacy, how the client can benefit from the option?

BV> I'm not sure why we would want this paragraph at all. So I think best to just remove it.
BV> You original question was I think about why SOL_MAX_RT MUST be in ORO. It MUST be as per RFC 7083 so that clients can get updated SOL_MAX_RT values. And, yes, the idea is that the Advertise with the SOL_MAX_RT value is used (even if it offers no leases) so that the client applies this value for any future requests. I don't see the need for this to be spelled out?

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 29 May 2017 22:19:55 +0000

Hi:

I have reviewed the document and while there are some minor issues, I did not find anything major. Therefore, I do support this document moving forward (once the minor issues are corrected).

Most of my issues are minor typos or wording improvements and I suspect Kim and/or Jinmei's review got most of them, so I will not waste the time to document them (I will apply the changes to the XML in the GitHub repository soon). Here are other comments which might require some discussion (at least among the co-authors):

[Page numbers are based on https://tools.ietf.org/pdf/draft-ietf-dhc-rfc3315bis-08.pdf.]

Page 25, section 8: We don't define the "size" of the msg-type and transaction-id fields; might be worth clarifying these (1-octet and 3-octets, respectively).

Page 27, section 9.1: Same as above, msg-type (1-octet), hop-count (1-octet), link-address/peer-address (16-octets).

Page 44, section 16.11: "the message does not include DHCP authentication ...", should we explicitly say RKAP or leave general? We might also want to just say uses RKAP or some other (yet to be developed, such as <ref to sedhcpv6>) authentication?

Page 44, section 17: What does this 1 paragarph section intend to say/mean? ("Client's behavior is different depending on the purpose of the configuration.") Can we drop it? Should we say something else/more?

Page 45, section 8 (Kim mentioned this): There's a bunch of text duplicated in this section (more than just the list). I do think "The client has many" and the list following should be removed. I also wonder if the later paragraph (The client is responsible for creating IAs ...) should be moved up as part of the Solicit exchange (but it would need to be edited/merged in to that earlier material). The duplicated instance of "A server may initiate a message exchange" should be dropped.

Page 50, section 18.2 (last paragraph): The "and duplicate responses by servers" doesn't make any sense in this regard. Unicast can only be used for instances where a single server is being addressed so it makes no sense to say this.

Page 51,section 18.2.1: The "after a power outage" is technically wrong as it should be "after recovery from a power outage"? We should double check if used elsewhere and correct.

Page 57, section 18.2.4 (last paragraph): So this says "If the terminated Renew exchange was not initiated as a result of receiving a Reconfigure message, the client begins Rebind message exchange...". But isn't this true even it was initiate by receiving a Reconfigure? The Renew is terminated at (earlist) T2 and a Rebind would start then anyway? This doesn't make sense to me. I think we should just drop the "was not initiated as a result of receiving a Reconfigure message"? Or what does happen in that case that is different?

Page 63, section 18.2.10: (Top of page paragraph) - "The client resends the original message using multicast". So should we qualify this to only happen if the client was using unicast (otherwise a storm could occur if "server" sends use Multicast and client retransmits using multicast)? Other option might be to say that retransmission doesn't happen until normal timer expires? Perhaps we can let client implementers chose either one depending on what's easier to implement for them?

Page 63, section 18.2.10: (2nd to last paragraph of section) - "This behavior does not apply to other IA containers, and their processing is described in detail on other parts of this document.". I'm not exactly sure where that is described. Could we add references? Or was this intended to reference other documents that might describe containers?

Page 67, section 18.2.11: (top of page) "Subsequent Reconfigure messages cause the client to initiate a new exchange." Subsequent here is a bit confusing since the text preceding just said "the client MUST ignore any additional Reconfigure messages until the exchange is complete". Perhaps we should change subsequent to "After the exchange is complete, ..."?

Page 68, section 18.3: (2nd to last paragraph on page) I think we can say "These Advertise and Reply messages MUST" (instead of just "This reply")?

Page 68, section 18.3 (top of page paragraph) I think "reply message" should be "response message" (that was used on previous page).

Page 68, section 18.3 (1st full paragraph, end) I think the printing and new software examples probably aren't that hot? DHCPv6 has no printing options so why would printing impact client configuration. And, while software might be OK given the BOOTFILE options, but it seems unlikely. Perhaps we just say when "other configuration options are updated, perhaps because servers are moved, added, or removed" or something more general?

Page 78 & 80, sections 18.3.9, 18.3.11: I suggest cleaning this up a bit as follows:

-          Change 18.3.9 title to remove transmission (so just "Creation of Advertise Messages")

-          Change 18.3.9 to remove the last two paragarphs (perhaps replace with text to say "Transmission of the Advertise message is described in the next section.")

-          Change 18.3.10 title to "Transmission of Advertise and Reply Messages"

-          Change text in 18.3.10 from using "Reply" to "Advertise or Reply".

-          Add a reference to section 19.3 as that talks about how the server should response. This is probably better reference than just to 21.10 (which could be moved to 19.3).

Pages 85 & 86, sections 20.2 and 20.3 - Merge these as we could just remove the section break and the first paragraph of 20.3.

Page 95, section 21.6 - Drop the last sentence of first paragraph; seems broken.

Page 117, section 21.24 (also 118 and 21.25): Replace "in the main body of the message to client" with "top-level option"? We have "top-level option" in terminology section.

Page 121, section 24: Remove "IANA is requested to add a column to the DHCPv6 Option table" as next paragraph asks them to add two columns and this should be been deleted.

Page 136, Appendix B: The "Auth." Option was incorrectly marked as being used in an Information-Request, but it should have been in the Reconfigure (1 line earlier). So, this needs to be moved "up".

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, May 09, 2017 10:53 AM
To: [email-masked]
Cc: Ralph Droms <[email-masked]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Hello:

-          Tomek & Bernie