As I was unable to find this email in my inbox (not even in spam) and in the absence of replies from the authors, I am resending to all recipients as I fear a technical problem with the IETF/RPC mail system.
Let's try to publish this RFC in 2025 😉 Regards -éric On 25/11/2025, 01:56, "[email protected]" <[email protected]> wrote: Authors, While reviewing this document during AUTH48 (https://www.rfc-editor.org/authors/rfc9915.html and other formats), please resolve the following questions, which are also in the source file. 1) <!--[rfced] In the abstract, should "reported errata" be "verified errata reports" for accuracy? In the RFC errata system, "Reported" is the status name for errata that have not yet been reviewed (see https://www.rfc-editor.org/errata-definitions/). In addition, we suggest splitting the sentence as follows. Original: This document obsoletes RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). Perhaps: This document obsoletes RFC 8415. It incorporates reported errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). Similarly, in Section 1.1, should "all applicable errata" be "verified errata reports"? Original: This document obsoletes [RFC8415] by applying all applicable errata and obsoleting two features that have not been widely implemented - the assignment of temporary addresses using the IA_TA option and allowing clients to unicast some messages directly to the server if the server sent the Server Unicast option to a client in an early exchange. Perhaps: This document obsoletes [RFC8415]. It applies verified errata reports and obsoletes two features that have not been widely implemented - the assignment of temporary addresses using the IA_TA option and allowing clients to unicast some messages directly to the server if the server sent the Server Unicast option to a client in an early exchange. --> 2) <!--[rfced] Please clarify this sentence. If the suggestion doesn't correctly capture your intent, please let us know how we can rephrase. Original: Note that these documents use "requesting router" for what this document uses client and "delegating router" for server. Perhaps: Note that those documents use "requesting router" and "delegating router" where this document uses "client" and "server", respectively. --> 3) <!--[rfced] Is this a list of 2 or 3 items (i.e., is it lifetime hints and timer hints?)? Original: It also obsoleted a small number of mechanisms: delayed authentication, lifetime and timer hints sent by a client. Perhaps: It also obsoleted a small number of mechanisms: delayed authentication, lifetime, and timer hints sent by a client. --> 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". --> 5) <!--[rfced] It may be useful to further clarify the reach of this BCP 14 keyword (i.e., are both clauses RECOMMENDED?). Original: It is RECOMMENDED for clients to send messages from UDP source port 546, and servers and relay agents from UDP source port 547. Perhaps: It is RECOMMENDED for clients to send messages from UDP source port 546 and for servers and relay agents from UDP source port 547. --> 6) <!--[rfced] Does the following rephrase correctly capture your intent? Original: When a client received a configuration option in an earlier Reply and then sends a Renew, Rebind, or Information-request and the requested option is not present in the Reply, the client SHOULD stop using the previously received configuration information. Perhaps: If a client received a configuration option in an earlier Reply, when it later sends a Renew, Rebind, or Information-request, the requested option needs to be present in the next Reply; otherwise, the client SHOULD stop using the previously received configuration information. --> 7) <!--[rfced] The phrasing of "not associated with a detection of having moved" is a bit tough to get through. Also, it may be easier on the reader if this sentence did not have two "if" clauses. If our suggested rephrasing does not capture your intent, please rephrase. Original: If not associated with a detection of having moved to a new link, a client SHOULD initiate one of the Renew/Reply, Confirm/Reply or Information-request/Reply exchanges, if the client detects a significant change regarding the prefixes available on the link. Perhaps: A client not detected as having moved to a new link SHOULD initiate one of the Renew/Reply, Confirm/Reply or Information-request/Reply exchanges, if the client detects a significant change regarding the prefixes available on the link. --> 8) <!--[rfced] Please review our updates to the following text for readability. Note that this updated text includes a repeat of a BCP 14 keyword. Original: Whenever a client restarts the DHCP server discovery process or selects an alternate server as described in Section 18.2.9, the client SHOULD stop using any addresses and delegated prefixes for which it has bindings (see Section 18.2.7) and if possible, any previously received other configuration information, and try to obtain new bindings and other configuration information from a "new" server for the same interface. Current: Whenever a client restarts the DHCP server discovery process or selects an alternate server as described in Section 18.2.9, the client SHOULD stop using any addresses and delegated prefixes for which it has bindings (see Section 18.2.7) and, if possible, any other configuration information it previously received. The client SHOULD also try to obtain new bindings and other configuration information from a "new" server for the same interface. --> 9) <!--[rfced] Please review: Should "null-terminated" should be "NUL-terminated" if it is referring to the NUL character (which is mentioned in RFC 3629)? Original: status-message A UTF-8 encoded [RFC3629] text string suitable for display to an end user. MUST NOT be null-terminated. A variable- length field (2 octets less than the value in the option-len field). --> 10) <!--[rfced] Please note that we have updated "sub-option-len" to "suboption-len" in the following to match both Figure 29 and the updates to other instances made in Section 21.17. Please let us know any objections. Original: The data area for the suboption. The length, in octets, is specified by sub-option-len. Current: The data area for the suboption. The length, in octets, is specified by suboption-len. --> 11) <!-- [rfced] This IEEE Std was superseded by a new version in 2020 https://ieeexplore.ieee.org/document/9018454. We will update to point to the newer version unless we hear an objection. Original: [IEEE-802.1x] IEEE, "IEEE Standard for Local and metropolitan area networks-Port-Based Network Access Control", IEEE 802.1X- 2010, DOI 10.1109/IEEESTD.2010.5409813, <https://ieeexplore.ieee.org/servlet/ opac?punumber=5409757>. --> 12) <!--[rfced] We had the following questions/comments about abbreviation use throughout the document: a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. b) Should CPE be expanded as Customer Premises Equipment here? Original: The prefix delegation process begins when the client (CPE) requests configuration information through DHCP. Perhaps: The prefix delegation process begins when the client (or Customer Premises Equipment (CPE)) requests configuration information through DHCP. --> 13) <!-- [rfced] Some tables and figures in this document do not have titles. Please review and provide titles for these, if desired. --> 14) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: man-in-the-middle --> Thank you. Megan Ferguson and Alice Russo RFC Production Center On Nov 24, 2025, [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]
