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).
Regards -éric From: Bernie Volz <[email protected]> Date: Friday, 12 December 2025 at 13:47 To: Eric Vyncke (evyncke) <[email protected]> Cc: Megan Ferguson <[email protected]>, [email protected] <[email protected]>, Editor RFC <[email protected]>, [email protected] <[email protected]>, Michael Richardson <[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 I’m ok either way. Only reason I slightly prefer SHOULD NOT is that it doesn’t render a server implementation incompatible with 9915 if it does still send that option. And, given how little usage the unicast option has seen (to my knowledge) and likely this can be controlled by configuration of the server, it seems unnecessary to require the MUST. - Bernie On Dec 12, 2025, at 7:10 AM, Eric Vyncke (evyncke) <[email protected]> wrote: Hello Megan, First of all, thanks for allocating RFC _15 for a _15 bis 😉 About the AD-specific question about 2), I second the authors modification as the first sentence must be removed (this option was never intended to be sent by the client) and the 2nd paragraph has also no place in the I-D. Nevertheless, I would even go stronger (using MUST NOT): > NEW (authors): > > The server *SHOULD NOT* send this option. When any entity receives the > Server Unicast option, the option SHOULD be ignored and the message > processing should continue as usual. > NEW (AD): The server *MUST NOT* send this option. When any entity receives the Server Unicast option, the option SHOULD be ignored and the message processing should continue as usual. I do not object the authors' proposal though, up to them to decide SHOULD vs. MUST. Regards -éric From: Megan Ferguson <[email protected]> Date: Thursday, 11 December 2025 at 18:48 To: Bernie Volz <[email protected]>, [email protected] <[email protected]> Cc: RFC Editor <[email protected]>, [email protected] <[email protected]>, Michael Richardson <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>, Eric Vyncke (evyncke) <[email protected]>, Shawn Zandi via auth48archive <[email protected]> Subject: Re: [AD] AUTH48: RFC-to-be 9915 <draft-ietf-dhc-rfc8415bis-12> for your review Authors and *AD, [*AD - please review question 2 below.] Thank you for your replies to our queries and sending along the further edits. We have updated accordingly, but had the following questions/issues to resolve: 1) Looking at this note: > - IMPORTANT: The "encapsulated option" definition (section 4.2) references > section 21.5 (IA_TA) which should be 21.4 (IA_NA). We see in the reply to our queries, you had suggested a related update: > 4) <!-- [rfced] The following citation may require clarification: > > Current: > A DHCP option that is usually only contained in another option. For > example, the IA Address option is contained in IA_NA options (see > Section 21.5). See Section 9 of [RFC7227] for a more complete > definition. > > Section 21.5 is about the "IA_TA" option, rather than the "IA_NA" > option. Note: Section 21.6 is about the "IA Address Option". > --> > > AUTHORS: The text should reference section 21.4. Hence: > > Perhaps: > A DHCP option that is usually only contained in another option. For > example, the IA Address option is contained in IA_NA options (see > Sections 21.6 and 21.4, respectively). See Section 9 of [RFC7227] for a > more complete > definition. Please review and let us know which section(s) should be cited (i.e., 21.6 and 21.4 or 21.4 only). 2) *AD, please review and approve the following change to Section 21.12: > - IMPORTANT: In section 21.12 Server Unicast Option we likely added "The > client SHOULD NOT request this option in the Option Request option." But I > wonder whether we should remove this as a client was NEVER supposed to > request it anyway (3315/8415). Perhaps we should say: > > OLD: > > The client SHOULD NOT request this option in the Option Request > option. The server SHOULD NOT send this option, even when requested > by clients. When any entity receives the Server Unicast option, the > option SHOULD be ignored and the message processing should continue > as usual. > > As this option was not very popular, and it typically required > special configuration by those server implementations that did support > it, clients still requesting this option in the Option Request option > are increasingly unlikely to receive it. > > NEW: > > The server SHOULD NOT send this option. When any entity receives the > Server Unicast option, the option SHOULD be ignored and the message > processing should continue as usual. > > Note: This deletes the second paragraph as it is wrong (clients don't request > in ORO) and it really doesn't add to what is already in the document. 3) Regarding: > - MAJOR: Appendix B, Table 4 ... several asterisks are in the wrong place: Apologies for these getting garbled! We have updated as requested and reviewed the other tables in the appendices to make sure they appear as in the original. 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) 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. RFC Editor/mf > On Dec 9, 2025, at 3:55 AM, Bernie Volz <[email protected]> wrote: > > The Authors also have the following additional comments and concerns > regarding the RFC9915 “draft” review: > > - IMPORTANT: The "encapsulated option" definition (section 4.2) references > section 21.5 (IA_TA) which should be 21.4 (IA_NA). > > - IMPORTANT: Section 21.1 references 21.5 when it no longer needs to as IA_TA > has been deprecated. So, I think we should remove it. Note: checked all other > references to 21.5 and they are appropriate. > > - MINOR: In section 4.2, we wonder if "IA option(s)" definition needs > "options"? "In this document, one or more IA_NA, IA_TA (obsoleted), and/or > IA_PD [options]. ..."? > > - IMPORTANT: In section 21.12 Server Unicast Option we likely added "The > client SHOULD NOT request this option in the Option Request option." But I > wonder whether we should remove this as a client was NEVER supposed to > request it anyway (3315/8415). Perhaps we should say: > > OLD: > > The client SHOULD NOT request this option in the Option Request > option. The server SHOULD NOT send this option, even when requested > by clients. When any entity receives the Server Unicast option, the > option SHOULD be ignored and the message processing should continue > as usual. > > As this option was not very popular, and it typically required > special configuration by those server implementations that did support > it, clients still requesting this option in the Option Request option > are increasingly unlikely to receive it. > > NEW: > > The server SHOULD NOT send this option. When any entity receives the > Server Unicast option, the option SHOULD be ignored and the message > processing should continue as usual. > > Note: This deletes the second paragraph as it is wrong (clients don't request > in ORO) and it really doesn't add to what is already in the document. > > - MINOR: At the end of Section 22(.0), the text has "and limiting the number > of messages a single client can transmit of a period of time.", which seems a > bit odd. Wonder whether we should say "in a period of time"? (Auto suggested > is "for a period of time", but we think "in" is better?) > > - MAJOR: Appendix B, Table 4 ... several asterisks are in the wrong place: > > OLD: > > > Client ID > Server ID > IA_NA > IA_PD > ORO > Pref > Elap. Time > Relay Msg. > Auth. > Solicit > * > > * > * > * > > * > > > Advert. > * > * > * > * > > * > > > > Request > * > * > * > * > * > > * > > > Confirm > * > > * > > > > * > > > Renew > * > * > * > * > * > * > * > > > Rebind > * > > * > * > * > > * > > > Decline > * > * > * > * > > > * > > > Release > * > * > * > * > > > * > > > Reply > * > * > * > * > > > > > * > Reconf > * > * > > > > > > > * > Inform. > * > (see note) > > > * > > * > > > R-forw. > > > > > > > > > * > R-repl. > > > > > > > > > * > > New: > > > Client ID > Server ID > IA_NA > IA_PD > ORO > Pref > Elap. Time > Relay Msg. > Auth. > Solicit > * > > * > * > * > > * > > > Advert. > * > * > * > * > > * > > > > Request > * > * > * > * > * > > * > > > Confirm > * > > * > > > > * > > > Renew > * > * > * > * > * > > * > > > Rebind > * > > * > * > * > > * > > > Decline > * > * > * > * > > > * > > > Release > * > * > * > * > > > * > > > Reply > * > * > * > * > > > > > * > Reconf > * > * > > > > > > > * > Inform. > * > (see note) > > > * > > * > > > R-forw. > > > > > > > > * > > R-repl. > > > > > > > > * > > > Basically, for Renew (remove Perf option), R-forw. (add Relay Msg. and remove > Auth), and R-Repl. (add Relay Msg. and remove Auth). > > Thanks much! > >> On Nov 24, 2025, at 7:55 PM, [email protected] wrote: >> >> *****IMPORTANT***** >> >> Updated 2025/11/24 >> >> RFC Author(s): >> -------------- >> >> Instructions for Completing AUTH48 >> >> Your document has now entered AUTH48. Once it has been reviewed and >> approved by you and all coauthors, it will be published as an RFC. >> If an author is no longer available, there are several remedies >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> >> You and you coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> >> Planning your review >> --------------------- >> >> Please review the following aspects of your document: >> >> * RFC Editor questions >> >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> >> <!-- [rfced] ... --> >> >> These questions will also be sent in a subsequent email. >> >> * Changes submitted by coauthors >> >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> >> * Content >> >> Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> >> * Copyright notices and legends >> >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> >> * Semantic markup >> >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> >> * Formatted output >> >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> >> >> Submitting changes >> ------------------ >> >> To submit changes, please reply to this email using ‘REPLY ALL’ as all >> the parties CCed on this message need to see your changes. The parties >> include: >> >> * your coauthors >> >> * [email protected] (the RPC team) >> >> * other document participants, depending on the stream (e.g., >> IETF Stream participants are your working group chairs, the >> responsible ADs, and the document shepherd). >> >> * [email protected], which is a new archival mailing list >> to preserve AUTH48 conversations; it is not an active discussion >> list: >> >> * More info: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> [email protected] will be re-added to the CC list and >> its addition will be noted at the top of the message. >> >> You may submit your changes in one of two ways: >> >> An update to the provided XML file >> — OR — >> An explicit list of changes in this format >> >> Section # (or indicate Global) >> >> OLD: >> old text >> >> NEW: >> new text >> >> You do not need to reply with both an updated XML file and an explicit >> list of changes, as either form is sufficient. >> >> We will ask a stream manager to review and approve any changes that seem >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> and technical changes. Information about stream managers can be found in >> the FAQ. Editorial changes do not require approval from a stream manager. >> >> >> Approving for publication >> -------------------------- >> >> To approve your RFC for publication, please reply to this email stating >> that you approve this RFC for publication. Please use ‘REPLY ALL’, >> as all the parties CCed on this message need to see your approval. >> >> >> Files >> ----- >> >> The files are available here: >> https://www.rfc-editor.org/authors/rfc9915.xml >> https://www.rfc-editor.org/authors/rfc9915.html >> https://www.rfc-editor.org/authors/rfc9915.pdf >> https://www.rfc-editor.org/authors/rfc9915.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9915-diff.html >> https://www.rfc-editor.org/authors/rfc9915-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9915-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9915 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9915 (draft-ietf-dhc-rfc8415bis-12) >> >> Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) >> Author(s) : T. Mrugalski, B. Volz, M. Richardson, S. Jiang, T. Winters >> WG Chair(s) : Timothy Winters, Bernie Volz >> Area Director(s) : Erik Kline, Éric Vyncke
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
