Thanks for the thorough review. Agree with proposed changes and suggestions of Xipeng
cheers, Eduard ________________________________ From: Xipengxiao <[email protected]> Sent: Saturday, November 08, 2025 21:14 To: [email protected] <[email protected]>; Vasilenko Eduard <[email protected]>; Metz, Eduard <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: AUTH48: RFC-to-be 9898 <draft-ietf-v6ops-nd-considerations-14> for your review Dear editors, Please see my feedback (starting with XX:). In short, I accept all your proposed changes, except that in 4 cases (TRILL, MADINAS, ND optimization, SEND) I proposed slightly different text. I also proposed 2 new editorial changes at the end. Thank you very much for your meticulous review and editorial improvements. I appreciate your support. Dear co-authors, Please review and accept the proposed changes from the editors and me. Thank you. XiPeng -----Original Message----- From: [email protected] <[email protected]> Sent: Thursday, 6 November 2025 16:30 To: Xipengxiao <[email protected]>; Vasilenko Eduard <[email protected]>; [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: AUTH48: RFC-to-be 9898 <draft-ietf-v6ops-nd-considerations-14> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file. 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425490085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GWzHsN%2BxNJRuArJI2jsrBnoZXwB2F0%2FEsP6k5%2F2ocXE%3D&reserved=0<https://www.rfc-editor.org/search>. --> XX: ND, NDP, SLACC, DHCPv6-PD, host isolation Or where do I insert the keywords? 2) <!--[rfced] Authors' Addresses: Regarding the postal addresses for XiPeng and Eduard, the markdown file you provided does not match the approved Internet-Draft in that the postal addresses were removed. Would you like your postal address information to be included in the RFC? If so, we will restore it. --> XX: it's OK to remove the postal addresses. 3) <!-- [rfced] Regarding section titles: a) May we update these section titles as follows? This would make them consistent in the table of contents (all terms would appear with their abbreviations) and more closely align with the items in the "ND solution" column in Table 1. (Part b is about the sections not included in this list.) Original: 3. Review of DN Mitigation Solutions..............................9 3.1. ND Solution in Mobile Broadband IPv6.....................10 3.2. ND Solution in Fixed Broadband IPv6......................11 3.3. Unique IPv6 Prefix per Host (UPPH).......................12 3.5. Scalable Address Resolution Protocol.....................14 3.9. Gratuitous Neighbor Discovery (GRAND)....................15 Perhaps: 3. Review of ND Mitigation Solutions 3.1. Mobile Broadband IPv6 (MBBv6) 3.2. Fixed Broadband IPv6 (FBBv6) 3.3. Unique IPv6 Prefix per Host (UPPH) 3.5. Scalable Address Resolution Protocol (SARP) 3.9. Gratuitous Neighbor Discovery (GRAND) XX: yes it's OK to update the section titles. In addition, it is OK to remove "IPv6" in Section 3.3, as you suggested below. b) We note the following inconsistencies between the section titles below and their respective entries in Table 1. May we make the following updates for consistency? i) We were unable to find "Subnet ND" explicitly mentioned in this section. May we update as follows to match "WiND" in Table 1? Original: 3.4. Wireless ND and Subnet ND Perhaps: 3.4. Wireless ND (WiND) XX: OK. ii) The item for this section appears as "ND TRILL" in Table 1. May we drop "ARP" from this section title and update as follows? Original: 3.6. ARP and ND Optimization for TRILL Perhaps: 3.6. ND Optimization for TRILL XX: Yes - ARP is not relevant to our document, but it's in the title of RFC8302. All things considered, I think it’s clearer to remove “ARP” from the title and the text below. Thank you. iii) May we update as follows to match Table 1? Original: 3.7. Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN) Perhaps: 3.7. ND in Ethernet Virtual Private Networks (ND EVPN) XX: yes iv) Section 3.10: The item for this section appears as "SAVI/RA G/G+" in Table 1. In addition, we were unable to find "G+" defined in this section. May we update both this section title and its respective entry in Table 1 as follows? Original (section title): 3.10. Source Address Validation Improvement (SAVI) and Router Advertisement Guard Original (table entry): SAVI/ RA G/G+ Perhaps (new section title): 3.10. Source Address Validation Improvement (SAVI) and Router Advertisement Guard (RA-Guard) Perhaps (new table entry): SAVI/ RA-G --> XX: yes 4) <!-- [rfced] Introduction: To make this list parallel in structure, may we adjust the punctuation as follows? Original: ND uses multicast in many messages, trusts messages from all nodes, and routers may install NCEs for hosts on demand when they are to forward packets to these hosts. Perhaps: ND uses multicast in many messages and trusts messages from all nodes; in addition, routers may install NCEs for hosts on demand when they are to forward packets to these hosts. --> XX: yes 5) <!-- [rfced] Introduction: a) The items in the list below appear to be a mixture of both RFC titles and "ND issues and mitigation solutions". In addition, some of these terms (e.g., Wireless ND (WiND)) do not explicitly appear in the RFCs that follow. May we update these items to their full RFC titles for consistency and clarity? For the list items that contain multiple RFCs, we would separate each RFC or reference into a separate bullet point. Original: Concretely, various ND issues and mitigation solutions have been published in more than 20 RFCs, including: . ND Trust Models and Threats [RFC3756], . Secure ND [RFC3971], . Cryptographically Generated Addresses [RFC3972], . ND Proxy [RFC4389], . Optimistic ND [RFC4429], . ND for mobile broadband [RFC6459][RFC7066], [etc.] Perhaps: Concretely, various ND issues and mitigation solutions have been published in more than 20 RFCs, including: * "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756] * "SEcure Neighbor Discovery (SEND)" [RFC3971] * "Cryptographically Generated Addresses (CGA)" [RFC3972] * "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] * "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] * "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" [RFC6459] * "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC7066] [etc.] XX: yes b) We note that the title of RFC 4429 is "Optimistic Duplicate Address Detection (DAD) for IPv6" (rather than "Optimistic ND"); may this be updated to the full title of RFC 4429? Original: . Optimistic ND [RFC4429], Perhaps: * "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] --> XX: yes. Thank you for the catch. 6) <!-- [rfced] Please review the following questions regarding the "Issues" defined in this document. a) May we update the "Issues" to appear in sentence case rather than title case? We would make these changes in Sections 2.1, 2.2, 2.3, and 2.4 and wherever else they appear in this document. For example: Original: . Issue 1: LLA DAD Degrading Performance Perhaps: * Issue 1: LLA DAD degrading performance XX: yes. Thank you. b) Should the issue names in Section 2.4 match those in Sections 2.1, 2.2, and 2.3? For example, the following issue is slightly different in Sections 2.1 and 2.4: In Section 2.1: . Issue 2: Router's Periodic Unsolicited RAs Draining Hosts' Battery In Section 2.4: o Issue 2: Unsolicited RA Draining Host Battery Life. XX: yes. Please use the one in Section 2.1. c) We note that several Issues contain verbs that end in "-ing" (e.g., "degrading" and "draining"). Would updating these verbs to their forms "degrades" and "drains" retain their meaning? This update would clarify the subject and object of these "-ing" verbs. Original: . Issue 1: LLA DAD Degrading Performance . Issue 2: Router's Periodic Unsolicited RAs Draining Hosts' Battery . Issue 3: GUA DAD Degrading Performance - same as in Issue 1. . Issue 4: Router's Address Resolution for Hosts Degrading Performance . Issue 5: Host's Address Resolution for Hosts Degrading Performance Perhaps: * Issue 1: LLA DAD Degrades Performance * Issue 2: Router's Periodic Unsolicited RAs Drain Host's Battery * Issue 3: GUA DAD Degrades Performance * Issue 4: Router's Address Resolution for Hosts Degrades Performance * Issue 5: Host's Address Resolution for Hosts Degrades Performance XX: yes. In addition, as we have agreed, please use the “sentence case”. d) How may we adjust the verbs in the item below for clarity? (Note that we have also adjusted this list item so that it is formatted consistently with the other items.) Original: . (For Further Study) Hosts' MAC Address Change NAs Degrading Performance - with randomized and changing MAC addresses [MADINAS], there may be many such multicast messages. Perhaps: * Issue for further study: Host's MAC Address Changes to NAs Degrades Performance With randomized and changing MAC addresses [MADINAS], there may be many such multicast messages. --> XX: NEW change should be: * Issue for further study: Multicast NAs for host's MAC address changes may degrade performance With randomized and changing MAC addresses [MADINAS], there may be many such multicast messages. 7) <!--[rfced] Trusting-All-Hosts vs. Trusting-all-nodes These terms are both used within this document. If they have the same meaning, how would you like to make this consistent? For example: Section 2.2: 2.2. Trusting-All-Hosts May Cause On-Link Security Issues Section 2.4: These issues stem from three primary causes: multicast, Trusting-all-nodes, and Router-NCE-on-Demand. --> XX: agree. please change “Trusting-All-Hosts” to “Trusting-All-Nodes” in the title of Section 2.2, and in the “Table of Content”. Thank you. 8) <!-- [rfced] Regarding Table 1 a) We note that a few RFC numbers appear in the "ND solution" column. For consistency with the other items in this column, what terminology would you like to replace these RFC numbers with? (Note that we will also update the section titles that correspond with these table entries to match.) Original entries in table 1: 7772 6583 9686 Corresponding section titles: 3.8. Reducing Router Advertisements 3.11. RFC 6583 Dealing with NCE Exhaustion Attacks 3.12. Registering Self-generated IPv6 Addresses using DHCPv6 XX: there is no terminology/name for these RFCs. Therefore, we have 2 options: 1. In the table, we can replace 7772 with “Reducing RAs”, 6583 with “Dealing with NCE Exh. Attacks” (taking advantages of the abbreviation you proposed below), 9686 with “Registering IPv6 Addr.”, or 2. Add “RFC” in front of each number, e.g., 7772 -> RFC7772 Please pick one option that you think is better. b) Some abbreviations in this table do not clearly correspond to the list of issues in Section 2.4 (e.g., "No A. Acct."). Would you like to add a legend above or below Table 1, or add the abbreviations in Section 2.4? Also, FYI, we updated the abbreviations as shown below. Current abbreviations: On-link securi. NCE Exhau. Fwd. Delay No A. Acct. Perhaps: The abbreviations in Table 1 correspond to Section 2.4 as follows. On-link Sec. = Trusting-all-nodes related issues NCE Exh. = NCE Exhaustion Fwd. Delay = Router Forwarding Delay No Addr. Acc. = Lack of Address Accountability XX: yes. Thank you. c) FYI - We renamed the "RFC type" column to "RFC cat." (RFC category) to align with the text that precedes the table. XX: ok. d) FYI - We updated "U" to "N/A" to make it clear that the corresponding items are not specified in RFCs. Original: I - Informational B - Best Current Practice U - Unknown (not formally defined by the IETF) Current: I: Informational B: Best Current Practice N/A: Not Applicable (not an RFC) --> XX: ok. Thank you. 9) <!--[rfced] We suggest removing "Draft Standard" from this list because that Standards Track maturity level is no longer in use, per RFC 6410. (Also, it appears that zero of the ND solutions listed in Table 1 are specified in a Draft Standard; please review. We note that RFCs 4861 and 4862 are Draft Standards, but they are not listed in Table 1.) Original: S - Standards Track (Proposed Standard, Draft Standard, or Internet Standard) Suggested: S: Standards Track (Proposed Standard or Internet Standard) --> XX: OK. Thank you. 10) <!-- [rfced] Section 3.4: As the phrase "WiND" does not explicitly appear in the RFCs mentioned below, may we adjust the text below to indicate this a new term? Original: Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929] (Standards Track) defines a fundamentally different ND solution for Low-Power and Lossy Networks (LLNs) [RFC7102]. Perhaps: The term "Wireless ND (WiND)" is used in this document to describe the fundamentally different ND solution for Low-Power and Lossy Networks (LLNs) [RFC7102] that is defined in [RFC6775], [RFC8505], [RFC8928], and [RFC8929] (Standards Track). --> XX: OK. 11) <!-- [rfced] Should the comma after "ARP" be removed in the text below so that "ARP and ND optimization" appear as one item? Original: Like SARP, ARP, and ND Optimization for TRILL focuses on reducing multicast address resolution. Perhaps: Like SARP, ARP and ND optimization for TRILL focuses on reducing multicast address resolution. --> XX: you are right, but as we discussed previously, we will remove ARP from the section title, so the new sentence should be: Like SARP, ND optimization for TRILL focuses on reducing multicast address resolution. 12) <!-- [rfced] Please clarify; after the 3 options are listed, how does the second part of this sentence relate to the first part? Original: SeND defined three new ND options, i.e., Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in the ND protocol. Perhaps: SEND defined three new ND options: Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce. These are an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in the ND protocol, respectively. --> XX: the new text should be: SEND defined three new ND options: Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce. In addition, SEND also defined an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in the ND protocol. 13) <!-- [rfced] We note a mixture of sentence and title case for several of the list items that appear in Sections 4.2.1, 4.2.2, and 4.2.3. For consistency, may we update these list items to sentence case? Some examples below: Original: 3. Privacy Issue from Unique Prefix Identifiability: 1. Unique Prefix Allocation 2. Router Support for L3 Isolation . Reduced Multicast Traffic: . Router Support for Partial L2 Isolation: Perhaps: 3. Privacy issue from unique prefix identifiability: 1. Unique prefix allocation 2. Router support for L3 isolation * Reduced multicast traffic: * Router support for partial L2 isolation: --> XX: yes, let’s use the sentence case. 14) <!-- [rfced] Terminology and abbreviations: a) FYI, we updated each instance of "SeND" to "SEND" to match usage in RFC 3971 as well as most usage in recent RFCs. XX: OK. b) Should "IPv6" be removed from this abbreviation for a more 1:1 relationship between abbreviation and expansion (and to match other uses of "Unique Prefix Per Host [RFC8273]" in this document)? Original: 3.3. Unique IPv6 Prefix per Host (UPPH) Perhaps: 3.3. Unique Prefix per Host (UPPH) XX: yes. c) FYI - For consistency with RFC 9663, we have expanded "DHCP-PD" to "DHCPv6 Prefix Delegation (DHCPv6-PD)" and updated another instance of "DHCP-PD" to "DHCPv6-PD". Please review. XX: OK. d) 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. Media Access Control (MAC) DHCPv6 Prefix Delegation (DHCPv6-PD) --> XX: yes. Thank you. 15) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425513511%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Bt%2FNcJ0EeYEzdEfIB3BCW79RwaZyxik4xf7k9O3rKBQ%3D&reserved=0<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 "native" should be updated in the text below: The switches are interconnected by a native or overlay L2 network. --> XX: please change “native” to “pure” if you think it’s clearer. Otherwise, we will keep the “native” word. XX: While reviewing the document, I also notice that 2 more editorial changes are needed: OLD: Host isolation: Separating hosts into different subnets or links. NEW: (capitalize “isolation” to be consistent with other bullets”) Host Isolation: Separating hosts into different subnets or links. OLD Node Advertisements (NAs) NEW Neighbor Advertisements (NAs) Thank you very much! XiPeng – end of my message. ========== Thank you. Kaelin Foody and Alice Russo RFC Production Center On 6 November 2025, [email protected] wrote: *****IMPORTANT***** Updated 2025/11/06 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425524642%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=92ttZNJvxRJJwehtQ6Xa3L7Iq9vAchh2mQBbw7dJspc%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425535054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pbo%2BxvIZGKBM5A1L3hQ6hyIbmmiB2nz6Rq7iqkMF7qI%3D&reserved=0)<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425545318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jo09peKeHPV6BqzclG5G%2FzWubC7cuZZjaDLDb3dqXRA%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425556511%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=th%2F8n514wFag7DIxZKP%2FT7adhzgkjOBJx6hrxy53RxE%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> * The archive itself: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425567331%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f2ta7gOs9OnMFJS9rJxZUhaZVQcr%2FLzhhNnkqpDULIU%3D&reserved=0<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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898.xml&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425577586%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xWg8%2BxfwpGxxdGwhMb2RTahs6CECOS4QM%2Funnduu2CY%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898.xml> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898.html&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425587684%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6WEdep6z%2BXmtN7d5yBgPcLK6T0RnYD7CTOpUh9zW7F8%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898.html> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898.pdf&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425598540%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mZ8IAf13AkyX6n65clJBIL188ZWZ%2FMK6mlHLJh0QQgo%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898.pdf> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898.txt&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425609151%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=648TZD3FZ8memoXdw9sfbayvQE6w92Kc7mowcvK%2Bzcg%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898.txt> Diff file of the text: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898-diff.html&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425619450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fwpdNsvbtLfFFzAUMo0nm3%2B%2FBJaE%2BMo1eJ5vaF8u82o%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898-diff.html> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898-rfcdiff.html&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425629632%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vlQhbRPHAZ9kgT04HzBndv4p8FDQFRp7w6fCQzVIoLk%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898-rfcdiff.html> (side by side) Diff of the XML: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9898-xmldiff1.html&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425639774%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=n40ftKTKN8iot0DqWfi58rFCFboWSaSLuayj4hRqZxE%3D&reserved=0<https://www.rfc-editor.org/authors/rfc9898-xmldiff1.html> Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9898&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425812836%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HQpg%2FHwtDDMEgtio4SEdK5Xqh5czemBxTFF2kcqNkqQ%3D&reserved=0<https://www.rfc-editor.org/auth48/rfc9898> Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9898 (draft-ietf-v6ops-nd-considerations-14) Title : Neighbor Discovery Considerations in IPv6 Deployments Author(s) : X. Xiao, E. Vasilenko, E. Metz, G. Mishra, N. Buraglio WG Chair(s) : XiPeng Xiao, Nick Buraglio Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
