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
