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%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425490085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GWzHsN%2BxNJRuArJI2jsrBnoZXwB2F0%2FEsP6k5%2F2ocXE%3D&reserved=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%7C02%7Ceduard.metz%40kpn.com%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425513511%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Bt%2FNcJ0EeYEzdEfIB3BCW79RwaZyxik4xf7k9O3rKBQ%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%7C9de5dcc08aac46e0940708de1f038bb7%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638982297425524642%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=92ttZNJvxRJJwehtQ6Xa3L7Iq9vAchh2mQBbw7dJspc%3D&reserved=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%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) > > * 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>. > > * 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 > > * 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 > > * 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://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://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://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 > > 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://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 > (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 > > > 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 > > 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]
