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?). > >> [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. > >> 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?). 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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
