I agree with the proposed changes and Xipeng's comments as well. One slight preference noted inline below. ---- nb
On Mon, Nov 10, 2025 at 2:21 AM <[email protected]> wrote: > 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. > I have a slight preference for adding RFC. > > 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]
