Hi: Also, Table 6 is still formatted slightly differently than Table 4 & 5 - the message names (first column) in Table 6 are not shaded in the PDF version as they are in the other tables (in TXT version, dashes are used versus equal signs).
- Bernie > On Dec 11, 2025, at 3:53 PM, Bernie Volz <[email protected]> wrote: > > 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]
