Hi: Sorry for the confusion regarding the encapsulated option definition in section 4.2, but we believe it would be best to reference both sections:
Use: 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. Thanks. - Bernie > On Dec 11, 2025, at 12:47 PM, Megan Ferguson <[email protected]> > wrote: > > 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]
