Hi, I reviewed this document carefully and here are my comments. Briefly, I found 1 mistake and have couple editorial suggestions.
1. Incorrect address in Section 22.4, bullet 2. This is clearly an error. The multicast address starts with ff, not fe. OLD: fe02::1:2 NEW: ff02::1:2 (or better yet, say All_DHCP_Relay_Agents_and_Servers multicast instead) 2. Better reference in reconfigure key terminology Section 4.2 has a reference in reconfigure key. It points to list of message types, which is really a minor implementation detail. A better reference would be 20.4, which explains how the reconfigure key is being used. OLD: Reconfigure key A key supplied to a client by a server. Used to provide security for Reconfigure messages (see Section 7.3 for the list of available message types) NEW: Reconfigure key A key supplied to a client by a server. Used to provide security for Reconfigure messages (see Section 20.4 for use cases for the reconfigure key) 3. Unfortunate wording in Section 5.2 The section is about normal assignment using SARR, but it's using "confirmed". Confirm is a specific term in DHCPv6 context and it's not relevant here. Better to say assigned or leased. The "confirmed" is used twice in this paragraph. OLD: The client then chooses one of the servers and sends a Request message to the server asking for confirmed assignment of addresses and/or delegated prefixes and other configuration information. The server responds with a Reply message that contains the confirmed addresses, delegated prefixes, and configuration. NEW: The client then chooses one of the servers and sends a Request message to the server asking for the lease of addresses and/or delegated prefixes and other configuration information. The server responds with a Reply message that contains the leased addresses, delegated prefixes, and configuration. 4. Better wording in Section 16.1 The text explains how client uses transaction-id to match incoming responses to the queries it sent. I would use "match" or "correlate". There is no synchronization mechanism here. OLD: The "transaction-id" field holds a value used by clients and servers to synchronize server responses to client messages. NEW: The "transaction-id" field holds a value used by clients and servers to correlate server responses to client messages. 5. More precise wording in Section 20. The text says "This document introduces two security mechanisms...". Both mechanisms were introduced in 3315. Better would be to say "defines" OLD: This document introduces two security mechanisms... NEW: This document defines two security mechanisms... 6. Can Status code be included in IAAddress option? There's this text in Section 21.6 (last para): The status of any operations involving this IA Address is indicated in a Status Code option in the IAaddr-options field, as specified in Section 21.13. I'm genuinely confused here. Although technically the status code could be put in the IAAddress option, I don't remember ever seeing such encapsulation. Status codes were always put in the IA containers or in some cases in the top level, but never in addresses. We're talking about doubly nested options here (IA_NA/IAaddress/Status code). Am I missing something here? What's the use case for this? Also, the table 7 in appendix C says that status code is not allowed in IAADDR or IAPREFIX. We either need to remove the last sentence from 21.6 (that would be my preference) or update the table 7 (and hopefully add an example scenario where it's useful). 7. Can client send status code? The table in Section 21.13 lists UnspecFail status code with this text: "...this status code is sent by either a client or a server to indicate a failure...". In which cases client would be sending status code? I don't remember ever seeing client sending a status code in the wild. Is this to indicate some weird failure in reconfigure? Do we have a normative text somewhere that would say "client sends status code if ..."? I'm not sure what would be the point. What would the server be supposed to do with such information? 8. Better explanation of preference The notes about the default value being 0 and "higher is better" are technically there, but buried deep in 17th paragraph in 18.2.1. That's not an exaggeration. It's easy to miss, unless you know what you're looking for. OLD: The preference value for the server in this message. NEW: The preference value for the server in this message. Allowed values are from 0 (least) to 255 (most preferred). Absence of option means preference 0. That's it. Apologies it took so long. Thanks, Tomek On 12/15/25 21:20, Megan Ferguson wrote: > Bernie, Michael, and Éric, > > Thank you for your replies, guidance, and clarifications. We have updated > the files as requested, recorded AD approval, and noted that all of our > queries have been resolved (see AUTH48 status page below). > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9915.txt > https://www.rfc-editor.org/authors/rfc9915.pdf > https://www.rfc-editor.org/authors/rfc9915.html > https://www.rfc-editor.org/authors/rfc9915.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9915-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9915-rfcdiff.html (comprehensive side > by side) > https://www.rfc-editor.org/authors/rfc9915-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9915-auth48rfcdiff.html (AUTH48 side > by side) > https://www.rfc-editor.org/authors/rfc9915-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9915-lastrfcdiff.html (last to this > side by side) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9915 > > Thank you. > > Megan Ferguson > RFC Production Center > >> On Dec 15, 2025, at 10:15 AM, Michael Richardson <[email protected]> wrote: >> >> >> Eric Vyncke (evyncke) <[email protected]> wrote: >>> So,, let's use a "MUST NOT" as we all want all DHCPv6 servers moving to >>> RFC 9915, this will be an incentive to implementors to clean up their >>> code by removing this function (if they had it). >> >> I don't think it will push any implementation to change. >> I don't care SHOULD NOT vs MUST NOT :-) >> It might guide new implementations, but I doubt there will be any. >> >> >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
