Thanks for the review and we’ll look to address your nits in a future revision (after IETF last-call ends). - Bernie > On Dec 26, 2024, at 11:45 AM, Dale Worley via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-dhc-rfc8415bis-07 > Reviewer: Dale R. Worley > Review Date: 2024-12-26 > IETF LC End Date: 2024-12-26 > IESG Telechat date: [not known] > > I have not reviewed the technical content of the draft, given that I > am only generally familiar with DHCPv6 and that DHCPv6 has been in > wide use with multiple implementations for 20 years. I have only > reviewed the parts of the exposition that have been changed from RFC > 8415. > > Summary: > > This draft is basically ready for publication, but has nits that > should be fixed before publication. > > Nits/editorial comments: > > 18.2.12. Refreshing Configuration Information > > However, a client > MUST rate-limit such exchange attempts to avoid flooding a server > with requests when there are link issues (for example, only doing one > of these at most every 30 seconds). > > I think you want to say "such initiation attempts" or "such > initiations" since the preceding text speaks of "initiate an > exchange"; the action is "initiate" and so that is what can be > rate-limited. > > 18.4. Reception of Unicast Messages > > The server is not supposed to accept unicast traffic from a client. > The Server Unicast option (see Section 21.12) and UseMulticast status > code (see Section 21.13) have been obsoleted and hence clients should > no longer send messages to a server's unicast address nor receive the > UseMulticast status code. However, a server that previously > supported the Server Unicast option and is upgraded to not support > it, may continue to receive unicast messages if it previously sent > the client the Server Unicast option. > > This seems important enough that it ought to use RFC 8174 words: > > The server SHOULD NOT to accept unicast traffic from a client. > The Server Unicast option (see Section 21.12) and UseMulticast status > code (see Section 21.13) have been obsoleted and hence clients should > no longer send messages to a server's unicast address nor receive the > UseMulticast status code. However, a server that previously > supported the Server Unicast option and is upgraded to not support > it, MAY continue to receive unicast messages if it previously sent > the client the Server Unicast option. > > 21.4. Identity Association for Non-temporary Addresses Option > > Addresses appearing in an IA_NA option are not temporary addresses > (see Section 21.5). > > This sentence may be redundant now that temporary addresses have been > obsoleted. Alternatively, it may be to warn users not to use IA_NA > for addresses that are intended to be temporary. But perhaps this > text should be adjusted, as App. A item 1 mentions that the client can > get the effect of a temporary address by simply allocating and > relatively soon deallocating an address. > > Perhaps this approach: Change this sentence to state clearly whatever > properties IA_NA addresses have that causes them to be "not temporary" > and continue to refer to sec. 21.5. Then enlarge 21.5 to include this > discussion from App. A item 1: > > A client that needs a short-term / > special purpose address can use a new IA_NA binding to request > an address and release it when finished with it. > > Effectively, "if you used to use IA_TA to get a temporary address, now > you need to allocate it using IA_NA and then release it in the > ordinary way when you're done with it". > > Appendix A. Summary of Changes > > 2. The following errata for RFC 8415 were incorporated: Erratum IDs > 6159 and 6183. Note that Erratum ID 6269 was no longer > applicable after the Server Unicast Option was obsoleted. > > Note that erratum 6159 is also no longer applicable now that temporary > addresses have been obsoleted. Indeed, the section (6.5) that erratum > 6159 corrects has been deleted. > > [END] > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
