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

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

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:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, May 09, 2017 10:53 AM
To: [e-mail]
Cc: Ralph Droms <[e-mail]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

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