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://www.rfc-editor.org/authors/rfc9898.txt > https://www.rfc-editor.org/authors/rfc9898.pdf > https://www.rfc-editor.org/authors/rfc9898.html > https://www.rfc-editor.org/authors/rfc9898.xml > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9898-auth48diff.html (AUTH48 changes > only) https://www.rfc-editor.org/authors/rfc9898-auth48rfcdiff.html (AUTH 48 > changes side by side) https://www.rfc-editor.org/authors/rfc9898-diff.html > (all > changes) https://www.rfc-editor.org/authors/rfc9898-rfcdiff.html (all changes > side by side) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9898 > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrus > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > 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://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%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://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%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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > 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]
