I approve the document in its current state as well. Thank you
Gyan <http://www.verizon.com/> *Gyan Mishra* *IT Technologist & Innovations Specialist* *Associate Fellow-Network Design* *Network Solutions A**rchitect, * *R&S, SP SME & Protocol Design Expert* *Global Technology Services* *O 240 970-6287M 301 502-1347* On Tue, Nov 18, 2025 at 4:50 AM Vasilenko Eduard < [email protected]> wrote: > Hi all, > No problem for me. It is so small matter. > Eduard > > -----Original Message----- > > From: Xipengxiao <[email protected]> > > Sent: Tuesday, November 18, 2025 12:30 > > To: Kaelin Foody <[email protected]>; Vasilenko Eduard > > <[email protected]>; [email protected]; Nick > > Buraglio <[email protected]> > > Cc: [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 > > > > Hi Kaelin, Eduard, and all, > > > > Because "Partial L2 Isolation" is a special noun, all capital case is > correct. > > Therefore, I approve the document in its current state. Thank you for > your > > hard work. @Vasilenko Eduard can you also approve it? > > > > My apology for missing Kaelin's email, and thus the delay. Thanks to > > @[email protected] for the reminder. > > > > XiPeng > > > > > > > > -----Original Message----- > > From: Kaelin Foody <[email protected]> > > Sent: Wednesday, 12 November 2025 16:24 > > To: Nick Buraglio <[email protected]> > > Cc: [email protected]; Xipengxiao <[email protected]>; rfc- > > [email protected]; Vasilenko Eduard <[email protected]>; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; auth48archive@rfc- > > editor.org > > Subject: Re: AUTH48: RFC-to-be 9898 > <draft-ietf-v6ops-nd-considerations-14> > > for your review > > > > Hi XiPeng, all, > > > > Thank you all for your responses! We have updated the document > accordingly > > and have marked Gyan, Nick, and Eduard Metz’s approvals on the AUTH48 > > status page for this document. > > > > We have a few follow-up questions and notes: > > > > a) While updating some list items to sentence case (see the question > below as > > an example), we note that “Isolation” appears consistently capitalized > > throughout this document. Therefore, we have not made “Isolation” > lowercase > > when updating to sentence case. Please review and let us know if you > would > > like for this item to remain capitalized, or if it should be made > lowercase (as > > seen in the Perhaps text below). > > > > > 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: > > > > > > . Router Support for Partial L2 Isolation: > > > > > > Perhaps: > > > > > > * Router support for partial L2 isolation: > > > --> > > > > > > XX: yes, let’s use the sentence case. > > > > > > b) Per Eduard's request below, we have retained “Proxy” in the title of > Section > > 3.7. > > > > > I have a little concern about: > > > Perhaps: > > > 3.7. ND in Ethernet Virtual Private Networks (ND EVPN) > > > IMHO: "Proxy" at the beginning was a valuable clarification. Because ND > > could be "normal" if it is between local users. > > > > > > c) Per Nick’s request below, we have added “RFC” to these entries in > Table 1 > > and to their corresponding section titles (see Sections 3.8, 3.11, and > 3.12). > > > > > 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? > > > > > > Original entries in table 1: > > > > > > 7772 > > > 6583 > > > 9686 > > > ... > > > > > > I have a slight preference for adding RFC. > > > > > > Upon careful review, please contact us with any further updates or with > your > > approval of the document in its current form. We will await approvals > from > > each party listed on the AUTH48 status page for this document prior to > moving > > forward in the publication process. > > > > — FILES (please refresh): — > > > > The updated files have been posted here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=XN9ygCV_gHYwFxZO1RAypk1IoXitafXmO8zlCB2AU_o&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898.pdf&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=IZ9A-GBJO2Rh8pkKTy-UfSaF68jJ9o3ufXWqrtr8WoQ&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898.html&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=W70KnnnrnOOEScwFhDKV-oIDxHEaqxXzKNeEP-O0-no&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898.xml&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=_R8jZG7bcIODTNbvldKd6NZTrwExpAvTyfq1vAQr4Iw&e= > > > > The relevant diff files have been posted here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898-2Dauth48diff.html&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=8nCZshH_tk6RuD90gJ5aLz3b0b9YYJT_Fhva2f9S-_s&e= > (AUTH48 changes > > only) > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898-2Dauth48rfcdiff.html&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=xnqO8Gt5imNLpi1AXOnt3V2aKGkfbh_Z078BFKHxZUk&e= > (AUTH 48 > > changes side by side) > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898-2Ddiff.html&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=gpL-6zua8HrPq7VPVopAbgyVDXUjEKaVpSht6jpfzuc&e= > (all > > changes) > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9898-2Drfcdiff.html&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=4drjngDUmS6FV5166SqiMxG0LHVqU9WnqchTAZcpnA4&e= > (all changes > > side by side) > > > > The AUTH48 status page for this document is available here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9898&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=veeOCoWog2Whl3B_BXvikVb1YD_CSoEtXxw2_8hsEBo&e= > > > > > > Thank you all for your time, > > > > Kaelin Foody > > RFC Production Center > > > > > On Nov 10, 2025, at 8:04 PM, Nick Buraglio <[email protected]> wrote: > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc- > > editor.org%2Fsearch&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dc > > c > > > > > 08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C > > 0%7C0%7 > > > > > C638982297425490085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > > nRydWUsIl > > > > > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > > 7C0 > > > > > %7C%7C%7C&sdata=GWzHsN%2BxNJRuArJI2jsrBnoZXwB2F0%2FEsP6k5%2F2o > > cXE%3D&r > > > eserved=0. --> > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > > > .rfc- > > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 > > > > > C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7% > > 7Cd7790 > > > > > 5498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425513511%7CUnk > > nown%7CT > > > > > WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > > W4zMiI > > > > > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Bt%2FNcJ0 > > EeYEzd > > > EfIB3BCW79RwaZyxik4xf7k9O3rKBQ%3D&reserved=0> > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > > > .rfc- > > editor.org%2Ffaq%2F&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5d > > c > > > > > c08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C > > 0%7C0% > > > > > 7C638982297425524642%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > > OnRydWUsI > > > > > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > > 7C > > > > > 0%7C%7C%7C&sdata=92ttZNJvxRJJwehtQ6Xa3L7Iq9vAchh2mQBbw7dJspc%3D > > &reserv > > > ed=0) > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftrus&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=zQ4wDEP2tkvT-sgx8IqlM0ZPiwt__3ZkzUqgz-aYDrU&e= > > > tee.ietf.org%2Flicense- > > info&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de > > > > > 5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8 > > %7C0%7 > > > > > C0%7C638982297425535054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > > GkiOnRydW > > > > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > > D > > > > > %7C0%7C%7C%7C&sdata=pbo%2BxvIZGKBM5A1L3hQ6hyIbmmiB2nz6Rq7iqk > > MF7qI%3D&r > > > eserved=0) > > > > > > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fauthor&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=Dm5ceoQhqcjZXgxHlEsLNfLSO5pn_ug1TYIB1sbS1bk&e= > > s.ietf.org%2Frfcxml- > > vocabulary&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46 > > e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0% > > 7C638982297425545318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > > Q%3D%3D%7C0%7C%7C%7C&sdata=jo09peKeHPV6BqzclG5G%2FzWubC7cuZZ > > jaDLDb3dqXRA%3D&reserved=0>. > > > > > > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmail&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=_FxPHUMnArpLUPIBNB4IoGYJL4fIzI2uOl4vsX7QusQ&e= > > > archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > > 4Q9l2USxIAe6P > > > > > 8O4Zc&data=05%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e094 > > 0708de1 > > > > > f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297 > > 42555651 > > > > > 1%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > > MDAwMCIs > > > > > IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat > > a=th > > > %2F8n514wFag7DIxZKP%2FT7adhzgkjOBJx6hrxy53RxE%3D&reserved=0 > > > > > > * The archive itself: > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmail&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=_FxPHUMnArpLUPIBNB4IoGYJL4fIzI2uOl4vsX7QusQ&e= > > > > > archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C > > edu > > > > > ard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd7790549 > > 8c3540 > > > > > eaad75954ac3e86be8%7C0%7C0%7C638982297425567331%7CUnknown%7CT > > WFpbGZsb3 > > > > > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > > joi > > > > > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f2ta7gOs9OnMFJS9rJx > > ZUhaZVQ > > > cr%2FLzhhNnkqpDULIU%3D&reserved=0 > > > > > > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.rf&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=Qd8h4I6jCvPlPe64zmi9iV8kllgYOtXmrd0EVzxaGJc&e= > > c- > > editor.org%2Fauthors%2Frfc9898.xml&data=05%7C02%7Ceduard.metz%40kp > > n.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75 > > 954ac3e86be8%7C0%7C0%7C638982297425577586%7CUnknown%7CTWFpb > > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xWg8%2Bxfw > > pGxxdGwhMb2RTahs6CECOS4QM%2Funnduu2CY%3D&reserved=0 > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.rf&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=Qd8h4I6jCvPlPe64zmi9iV8kllgYOtXmrd0EVzxaGJc&e= > > c- > > editor.org%2Fauthors%2Frfc9898.html&data=05%7C02%7Ceduard.metz%40kp > > n.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75 > > 954ac3e86be8%7C0%7C0%7C638982297425587684%7CUnknown%7CTWFpb > > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6WEdep6z%2 > > BXmtN7d5yBgPcLK6T0RnYD7CTOpUh9zW7F8%3D&reserved=0 > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc- > > editor.org%2Fauthors%2Frfc9898.pdf&data=05%7C02%7Ceduard.metz%40kp > > > > > n.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75 > > 954ac3e > > > > > 86be8%7C0%7C0%7C638982297425598540%7CUnknown%7CTWFpbGZsb3d8 > > eyJFbXB0eU1 > > > > > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > > UI > > > > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=mZ8IAf13AkyX6n65clJBIL188ZWZ%2F > > MK6mlHLJ > > > h0QQgo%3D&reserved=0 > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc- > > editor.org%2Fauthors%2Frfc9898.txt&data=05%7C02%7Ceduard.metz%40kp > > > > > n.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75 > > 954ac3e > > > > > 86be8%7C0%7C0%7C638982297425609151%7CUnknown%7CTWFpbGZsb3d8 > > eyJFbXB0eU1 > > > > > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > > UI > > > > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=648TZD3FZ8memoXdw9sfbayvQE6w > > 92Kc7mowcvK > > > %2Bzcg%3D&reserved=0 > > > > > > Diff file of the text: > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc-editor.org%2Fauthors%2Frfc9898- > > diff.html&data=05%7C02%7Ceduard.met > > > > > z%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540 > > eaad759 > > > > > 54ac3e86be8%7C0%7C0%7C638982297425619450%7CUnknown%7CTWFpbGZ > > sb3d8eyJFb > > > > > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > > pbCI > > > > > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fwpdNsvbtLfFFzAUMo0nm3%2 > > B%2FBJaE% > > > 2BMo1eJ5vaF8u82o%3D&reserved=0 > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc-editor.org%2Fauthors%2Frfc9898- > > rfcdiff.html&data=05%7C02%7Ceduard. > > > > > metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3 > > 540eaad > > > > > 75954ac3e86be8%7C0%7C0%7C638982297425629632%7CUnknown%7CTWFp > > bGZsb3d8ey > > > > > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > > WFp > > > > > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vlQhbRPHAZ9kgT04HzBndv4 > > p8FDQFR > > > p7w6fCQzVIoLk%3D&reserved=0 (side by side) > > > > > > Diff of the XML: > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc-editor.org%2Fauthors%2Frfc9898- > > xmldiff1.html&data=05%7C02%7Ceduard > > > > > .metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c > > 3540eaa > > > > > d75954ac3e86be8%7C0%7C0%7C638982297425639774%7CUnknown%7CTWF > > pbGZsb3d8e > > > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > > WF > > > > > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=n40ftKTKN8iot0DqWfi58rF > > CFboWS > > > aSLuayj4hRqZxE%3D&reserved=0 > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=zR4I1-4M8crDDddso1-5GdXtEK3a-kQswZHaG1sCUtyXMH94894wStgAlBpuMbiS&s=TRNwMXHYf7Lil_QqOtNUFQkMeWs9rYgiM7dawQXWjGA&e= > . > > > rfc- > > editor.org%2Fauth48%2Frfc9898&data=05%7C02%7Ceduard.metz%40kpn.co > > m > > > > > %7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3 > > e86be8 > > > > > %7C0%7C0%7C638982297425812836%7CUnknown%7CTWFpbGZsb3d8eyJFbX > > B0eU1hcGki > > > > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > > Q > > > > > %3D%3D%7C0%7C%7C%7C&sdata=HQpg%2FHwtDDMEgtio4SEdK5Xqh5czemB > > xTFF2kcqNkq > > > Q%3D&reserved=0 > > > > > > 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]
