Hi Bin, Thank you for your reply. We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9786).
We now await approvals from Luc, Patrice, and Edward. Have a great weekend! Best regards, RFC Editor/kc > On May 30, 2025, at 12:21 PM, Wen, Bin <bin_...@comcast.com> wrote: > > Hi Karen, > > I have reviewed the document, and it looks good to me. > > Very glad to see this going thru. Thank you all! > > Bin > > > On 5/30/25, 3:19 PM, "Karen Moore" <kmo...@staff.rfc-editor.org > <mailto:kmo...@staff.rfc-editor.org>> wrote: > > > Hi Jorge, > > > Thank you for your reply. We have noted your approval on the AUTH48 status > page for this document > (https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$ > > <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$> > ). > > > We now await approvals from Luc, Patrice, Bin, and Edward. > > > Best regards, > RFC Editor/kc > > >> On May 30, 2025, at 5:01 AM, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com >> <mailto:jorge.raba...@nokia.com>> wrote: >> >> Hi Karen, >> >> I checked the changes and they look good to me. >> I approve the document for publication. >> >> Thank you for all the work, and thanks to Luc André for driving this during >> the last stages. >> >> Jorge >> >> From: Karen Moore <kmo...@staff.rfc-editor.org >> <mailto:kmo...@staff.rfc-editor.org>> >> Date: Thursday, May 29, 2025 at 12:04 PM >> To: Luc Andre Burdet (lburdet) <lbur...@cisco.com >> <mailto:lbur...@cisco.com>>, Patrice Brissette (pbrisset) >> <pbris...@cisco.com <mailto:pbris...@cisco.com>>, edward.leyton >> <edward.ley...@verizonwireless.com >> <mailto:edward.ley...@verizonwireless.com>>, Jorge Rabadan (Nokia) >> <jorge.raba...@nokia.com <mailto:jorge.raba...@nokia.com>>, >> bin_...@comcast.com <mailto:bin_...@comcast.com> <bin_...@comcast.com >> <mailto:bin_...@comcast.com>> >> Cc: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>>, >> bess-...@ietf.org <mailto:bess-...@ietf.org> <bess-...@ietf.org >> <mailto:bess-...@ietf.org>>, bess-cha...@ietf.org >> <mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org >> <mailto:bess-cha...@ietf.org>>, slitkows.i...@gmail.com >> <mailto:slitkows.i...@gmail.com> <slitkows.i...@gmail.com >> <mailto:slitkows.i...@gmail.com>>, Gunter van de Velde (Nokia) >> <gunter.van_de_ve...@nokia.com <mailto:gunter.van_de_ve...@nokia.com>>, >> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> >> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> >> Subject: Re: [auth48] AUTH48: RFC-to-be 9786 <draft-ietf-bess-evpn-mh-pa-13> >> for your review >> >> [You don't often get email from kmo...@staff.rfc-editor.org >> <mailto:kmo...@staff.rfc-editor.org>. Learn why this is important >> athttps://aka.ms/LearnAboutSenderIdentification ] >> >> CAUTION: This is an external email. Please be very careful when clicking >> links or opening attachments. See the URL nok.it/ext for additional >> information. >> >> >> >> Authors, >> >> Please let us know if any further updates are needed for this document or if >> you approve this document in its current form. We will await approvals from >> each author prior to publication. >> >> Best regards, >> RFC Editor/kc >> >>> On May 21, 2025, at 6:16 PM, Karen Moore <kmo...@staff.rfc-editor.org >>> <mailto:kmo...@staff.rfc-editor.org>> wrote: >>> >>> Hi Luc, >>> >>> Thank you for your reply and for the updated XML file. We have updated our >>> files accordingly. >>> >>> Note that we updated one instance of "ESI label extended community" to "ESI >>> Label Extended Community" (which will be consistent with "ESI Label" (0x01) >>> per RFC 7432 as well as "DF Election Extended Community"). >>> >>> --FILES-- >>> The updated XML file is here: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$> >>> >>> >>> The updated output files are here: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$> >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$> >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$> >>> >>> >>> These diff files show all changes made during AUTH48: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr88iV-yH0$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr88iV-yH0$> >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8W9ciCLE$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-auth48rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8W9ciCLE$> >>> (side by side) >>> >>> These diff files show all changes made to date: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$> >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$> >>> (side by side) >>> >>> Note that it may be necessary for you to refresh your browser to view the >>> most recent version. Please review the document carefully to ensure >>> satisfaction as we do not make changes once it has been published as an RFC. >>> >>> Please contact us with any further updates or with your approval of the >>> document in its current form. We will await approvals from each author >>> prior to moving forward in the publication process. >>> >>> For the AUTH48 status of this document, please see: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$ >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$> >>> >>> >>> Best regards, >>> RFC Editor/kc >>> >>> >>>> On May 20, 2025, at 9:17 AM, Luc Andre Burdet (lburdet) via auth48archive >>>> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> wrote: >>>> >>>> Hi Alice, >>>> >>>> I have addressed most in XML directly, with only a few comments here: >>>> >>>> DF Election extended community -> DF Election Extended Community (per RFC >>>> 8584) >>>> ESI Label Extended Community -> ESI label extended community (per RFC 7432) >>>> Wouldn’t this just swap from one inconsistent capitalisation to another? I >>>> will leave the final call in your hands. >>>> >>>> >>>> I added the T flag to the bitmap, and a reference at the end: >>>> <!-- [RFC9722] draft-ietf-bess-evpn-fast-df-recovery-12 companion doc >>>> RFC9722; in RFC Editor Queue as of 04/24/25. Updated the title to match >>>> the doc --> >>>> <reference anchor="RFC9722" >>>> target=https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc9722__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Ut6pKA8$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc9722__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Ut6pKA8$> >>>> > >>>> >>>> >>>> All other changes made directly in XML. I have also reviewed the changes >>>> in diff >>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$> >>>> ) which look good, thank you! >>>> >>>> >>>> Regards, >>>> Luc André >>>> >>>> Luc André Burdet | lbur...@cisco.com <mailto:lbur...@cisco.com> | Tel: +1 >>>> 613 254 4814 >>>> >>>> >>>> From: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> >>>> Date: Thursday, May 15, 2025 at 16:30 >>>> To: Patrice Brissette (pbrisset) <pbris...@cisco.com >>>> <mailto:pbris...@cisco.com>>, Luc Andre Burdet (lburdet) >>>> <lbur...@cisco.com <mailto:lbur...@cisco.com>>, bin_...@comcast.com >>>> <mailto:bin_...@comcast.com> <bin_...@comcast.com >>>> <mailto:bin_...@comcast.com>>, edward.leyton >>>> <edward.ley...@verizonwireless.com >>>> <mailto:edward.ley...@verizonwireless.com>>, jorge.raba...@nokia.com >>>> <mailto:jorge.raba...@nokia.com><jorge.raba...@nokia.com >>>> <mailto:jorge.raba...@nokia.com>> >>>> Cc: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>>, >>>> bess-...@ietf.org <mailto:bess-...@ietf.org><bess-...@ietf.org >>>> <mailto:bess-...@ietf.org>>, bess-cha...@ietf.org >>>> <mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org >>>> <mailto:bess-cha...@ietf.org>>, slitkows.i...@gmail.com >>>> <mailto:slitkows.i...@gmail.com> <slitkows.i...@gmail.com >>>> <mailto:slitkows.i...@gmail.com>>, gunter.van_de_ve...@nokia.com >>>> <mailto:gunter.van_de_ve...@nokia.com> <gunter.van_de_ve...@nokia.com >>>> <mailto:gunter.van_de_ve...@nokia.com>>,auth48archive@rfc-editor.org >>>> <mailto:auth48archive@rfc-editor.org><auth48archive@rfc-editor.org >>>> <mailto:auth48archive@rfc-editor.org>> >>>> Subject: Re: AUTH48: RFC-to-be 9786 <draft-ietf-bess-evpn-mh-pa-13> for >>>> your review >>>> >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> 1) <!--[rfced] Luc André, FYI, we updated your name to match >>>> how you updated it in RFC 9722 during AUTH48 recently. >>>> Please let us know if you prefer otherwise. >>>> --> >>>> >>>> >>>> 2) <!-- [rfced] FYI, we note that RFC 5306 does not mention "LDP". >>>> Apparently the digits were transposed, so we updated the reference >>>> from [RFC5306] to [RFC5036], titled "LDP Specification". >>>> Please let us know if this is not accurate. >>>> >>>> Original: >>>> b. Port-Active redundancy eliminates the need for ICCP and LDP >>>> [RFC5306] (e.g., VXLAN [RFC7348] or SRv6 [RFC8402] may be used in >>>> the network). >>>> >>>> Current: >>>> b. It eliminates the need for ICCP and LDP [RFC5036] (e.g., Virtual >>>> eXtensible Local Area Network (VXLAN) [RFC7348] or Segment >>>> Routing over IPv6 (SRv6) [RFC8402] may be used in the network). >>>> --> >>>> >>>> >>>> 3) <!--[rfced] The text states that one or more PEs keep the port in >>>> standby mode. Do one or more PEs keep the port in active mode >>>> as shown below? >>>> >>>> Original: >>>> PEs in the redundancy group leverage the DF election defined in >>>> [RFC8584] to determine which PE keeps the port in active mode and >>>> which one(s) keep it in standby mode. >>>> >>>> Perhaps: >>>> PEs in the redundancy group leverage the DF election defined in >>>> [RFC8584] to determine which PE(s) keeps the port in active mode >>>> and which PE(s) keeps it in standby mode. >>>> --> >>>> >>>> >>>> 4) <!-- [rfced] [RFC7432] does not mention a "Single-Active blocking >>>> scheme", but it does mention "Single-Active redundancy mode". Is >>>> an update perhaps needed to the text below? >>>> >>>> Original: >>>> Non-DF routers SHOULD implement a bidirectional blocking scheme >>>> for all traffic comparable to the Single-Active blocking scheme >>>> described in [RFC7432], albeit across all VLANs. >>>> --> >>>> >>>> >>>> 5) <!--[rfced] Should Figure 2 be updated to show the T bit as >>>> defined in RFC-to-be 9722 (draft-ietf-bess-evpn-fast-df-recovery-12), >>>> which is currently in AUTH48 state? If so, should any text >>>> be added to mention that document? >>>> (This question also appears in RFC-to-be 9785.) >>>> >>>> Original: >>>> 1 1 1 1 1 1 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |D|A| |P| | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Perhaps: >>>> 1 1 1 1 1 1 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |D|A| |T| |P| | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> --> >>>> >>>> >>>> 6) <!--[rfced] How may we rephrase this sentence for clarity? We note >>>> that "DF Elected" is not used elsewhere in the document or in the >>>> normative references; should "Elected" perhaps be removed (option A), >>>> or should "election" perhaps be used instead (option B)? >>>> >>>> Also note that RFC 8584 expands "BDF" as "Backup Designated Forwarder" >>>> (rather than "Back-up DF Elected"); may we update this expansion >>>> accordingly? >>>> >>>> Original: >>>> The algorithm to detemine the DF Elected and Backup-DF >>>> Elected (BDF) at Section 3.2 of [RFC8584] is repeated >>>> and summarized below using only (Es) in the computation: >>>> >>>> Perhaps A: >>>> The algorithm used to determine the DF and Backup Designated >>>> Forwarder (BDF) per Section 3.2 of [RFC8584] is repeated and >>>> summarized below using only (Es) in the computation: >>>> or >>>> >>>> Perhaps B: >>>> The algorithm used to determine the DF and Backup Designated >>>> Forwarder (BDF) elections per Section 3.2 of [RFC8584] is >>>> repeated and summarized below using only (Es) in the computation: >>>> --> >>>> >>>> >>>> 7) <!--[rfced] In the title of Section 4.1, we added "Bits" as the "P and >>>> B bits" are described in this section. Please let us know if this >>>> update is not correct. >>>> >>>> Original: >>>> 4.1. Primary / Backup per Ethernet-Segment >>>> >>>> Current: >>>> 4.1. Primary/Backup Bits per Ethernet Segment >>>> --> >>>> >>>> >>>> 8) <!--[rfced] Does the remote ESI label extended community signal a >>>> Single-Active "procedure" or perhaps "redundancy mode"? Please >>>> clarify. >>>> >>>> Original: >>>> * The remote ESI Label Extended Community ([RFC7432]) signals >>>> Single-Active (Section 3) >>>> >>>> Perhaps: >>>> * The remote ESI label extended community [RFC7432] signals the >>>> Single-Active redundancy mode (Section 3). >>>> --> >>>> >>>> >>>> 9) <!-- [rfced] Terminology >>>> >>>> a) Throughout the text, the following terminology appears to be used >>>> inconsistently. Please review these occurrences and let us know if/how they >>>> may be made consistent. >>>> >>>> Bitmap field vs. bitmap field >>>> [Are these different? For example, "a Bitmap (2 octets) field" vs. >>>> "DF Election Capabilities bitmap field"] >>>> >>>> b) We updated the text to use the form on the right for consistency >>>> within this document and Cluster 492 (C492). Please let us know of any >>>> objections. >>>> >>>> active-standby -> active/standby >>>> All-active -> All-Active >>>> DF Election -> DF election (for general use, per RFC 8584) >>>> DF Election extended community -> DF Election Extended Community (per RFC >>>> 8584) >>>> 'Don't Pre-empt' -> 'Don't Preempt' (per companion doc and IANA registry) >>>> ESI Label Extended Community -> ESI label extended community (per RFC 7432) >>>> Ethernet-AD per-ES -> Ethernet A-D per ES (per RFC 8584) >>>> Port Mode DF Election -> Port Mode Designated Forwarder Election (per IANA) >>>> Single-active -> Single-Active >>>> --> >>>> >>>> >>>> 10) <!-- [rfced] Abbreviations >>>> >>>> a) FYI: We have added expansions for the following abbreviations >>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>> expansion in the document carefully to ensure correctness. >>>> >>>> Customer Equipment (CE) >>>> Cyclic Redundancy Check (CRC) >>>> Media Access Control (MAC) >>>> Neighbor Discovery (ND) >>>> Segment Routing over IPv6 (SRv6) >>>> Virtual Routing and Forwarding (VRF) >>>> Virtual Private Wire Service (VPWS) >>>> Virtual eXtensible Local Area Network (VXLAN) >>>> >>>> b) For consistency within the RFC series and C492, we updated >>>> the document to use the form on the right. Please review. >>>> >>>> AC-Influenced Designated Forwarder Election (AC-DF) -> >>>> AC-Influenced DF (AC-DF) election (per RFC 8584) >>>> >>>> Interchassis Communication Protocol (ICCP) -> >>>> Inter-Chassis Communication Protocol (ICCP) >>>> >>>> Multi-Chassis Link Aggregation Group (MC-LAG) -> >>>> Multi-Chassis Link Aggregation (MC-LAG) group >>>> --> >>>> >>>> >>>> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online >>>> Style Guide >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language__;Iw!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8AxX4rCs$ >>>> > >>>> 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 the following should be updated: >>>> >>>> - black-holing >>>> --> >>>> >>>> >>>> Thank you. >>>> >>>> RFC Editor/kc/ar >>>> >>>> >>>> On May 15, 2025, rfc-edi...@rfc-editor.org >>>> <mailto:rfc-edi...@rfc-editor.org> wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/05/15 >>>> >>>> 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.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Mv-KgyA$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Mv-KgyA$> >>>> ). >>>> >>>> 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.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8CxPiKUk$ >>>> >>>> <https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8CxPiKUk$> >>>> ). >>>> >>>> * 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.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8rlg1KH0$ >>>> >>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8rlg1KH0$> >>>> >. >>>> >>>> * 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 >>>> >>>> * rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> (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). >>>> >>>> * auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>, >>>> which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8hTA4ur0$ >>>> >>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8hTA4ur0$> >>>> >>>> >>>> * The archive itself: >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8oCO2e9Q$ >>>> >>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8oCO2e9Q$> >>>> >>>> >>>> * 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, >>>> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> 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.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.xml__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8xgVz6JE$> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8bk0N2V0$> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.pdf__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8Vk5qkis$> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786.txt__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8JQGE-Eg$> >>>> >>>> >>>> Diff file of the text: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-diff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8104iKxU$> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-rfcdiff.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8zTZGlpU$> >>>> (side by side) >>>> >>>> Diff of the XML: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-xmldiff1.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8MXnFziY$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9786-xmldiff1.html__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8MXnFziY$> >>>> >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$ >>>> >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9786__;!!CQl3mcHX2A!CqnuddmPUNsPJIusav3poiLarWrXSbx6XWqh6R0QubQRAunQG35V3Ba748IpnMn4ISECRa63gUeA4vr8ki27DPY$> >>>> >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9786 (draft-ietf-bess-evpn-mh-pa-13) >>>> >>>> Title : EVPN Port-Active Redundancy Mode >>>> Author(s) : P. Brissette, LA. Burdet, Ed., B. Wen, E. Leyton, J. Rabadan >>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang >>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >>>> <rfc9786-01-from-0.diff.html><rfc9786-01.txt><rfc9786-01.xml>-- >>>> auth48archive mailing list -- auth48archive@rfc-editor.org >>>> <mailto:auth48archive@rfc-editor.org> >>>> To unsubscribe send an email to auth48archive-le...@rfc-editor.org >>>> <mailto:auth48archive-le...@rfc-editor.org> >>> >> > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
