Tomek: These are great finds!! And, perhaps an errata is needed for several of them against RFC8415 as these appear there?
Comments below (bv>). - Bernie > On Dec 19, 2025, at 3:58 PM, Tomek Mrugalski <[email protected]> > wrote: > > 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) > bv> yes, this is an error and needs to be corrected. > 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) > bv> either way is fine by me, as RFC8415 used old. > 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. > bv> I’m not sure this is worth it as confirm is generic terminology and not a message name? > 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. > bv> agreed that correlate is probably better. > 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... > bv> ok > 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). > bv> yes, there are no error codes that could be used. I think this was a conceptual idea at one point that was never used and should be removed. It was in 3315 as well. > 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? > bv> you are correct that a client cannot send a status code, at least in the messages covered by this document. Again 3315 and 8415 have this text. Though I am a bit unsure as to whether we should actually change this text. > 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. > bv> yes, this would be an improvement. > 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]
