Happy New Year ! Megan, please look below for AD>
Regards -éric From: Megan Ferguson <[email protected]> Date: Wednesday, 24 December 2025 at 17:40 To: Bernie Volz <[email protected]>, Tomek Mrugalski <[email protected]>, [email protected] <[email protected]>, Eric Vyncke (evyncke) <[email protected]> Cc: Michael Richardson <[email protected]>, Editor RFC <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>, Shawn Zandi via auth48archive <[email protected]> Subject: Re: [AD] AUTH48: RFC-to-be 9915 <draft-ietf-dhc-rfc8415bis-12> for your review Hi Tomek and Bernie (and *AD), [*AD - please see *AD in several places in the message below.] Thanks for sending along these comments. We have updated the files where we felt we were confident in the desired change, but had a few further questions inserted below with [rfced] that could help us in implementing the rest of the desired updates. > >> 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. [rfced] We have updated to “ff02::1:2”. If the possible update to “All_DHCP_Relay_Agents_and_Servers multicast” ends up being preferred, please provide further Old/New text as to how you want that to fit into the sentence. > >> 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. [rfced] We have updated to point to Section 20.4 as there seems to be no objection. > >> 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? [rfced] Seems this is not unanimous. Please provide further guidance on how to proceed (*AD?). AD> good catch, even if this is close to split hair, I have a preference for the new text (i.e., using "leased addresses" rather than "confirmed addresses"). > >> [snip] > >> 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. [rfced] *AD - please review/approve the deletion of text here. AD> deletion is approved (I agree with Tomek & Bernie) > >> 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. [rfced] Please let us know how to proceed (perhaps *AD input could help?). AD> Let's avoid ambiguities and update the text to be clear that status code is sent by the server only and should be ignored by the server upon receiving any status code. Authors, can you propose OLD/NEW text ? AD> In short, I will approve the I-D when the above AD-approved changes are executed. -éric
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
