Thanks Amanda! > On Mar 3, 2025, at 4:11 PM, Amanda Baber via RT <iana-mat...@iana.org> wrote: > > Hi, > > These changes are complete: > > https://www.iana.org/assignments/bgp-extended-communities > > thanks, > > Amanda Baber > IANA Operations Manager > > On Mon Mar 03 21:37:42 2025, sgin...@staff.rfc-editor.org wrote: >> Hi IANA, >> >> Please make the following updates in the "Border Gateway Protocol >> (BGP) Extended Communities” registry. Updates are noted below; they >> can also be viewed in <https://www.rfc-editor.org/authors/rfc9746- >> rfcdiff.html>. >> >> A) EVPN ESI Label Extended Community Flags >> https://www.iana.org/assignments/bgp-extended-communities/bgp- >> extended-communities.xhtml#evpn-esi-label-extended-community-flags >> >> Old: >> 6-7 Split Horizon Type >> >> New (hyphen): >> 6-7 Split-Horizon Type >> >> >> B) Multihoming Redundancy Mode >> https://www.iana.org/assignments/bgp-extended-communities/bgp- >> extended-communities.xhtml#multihoming-redundancy-mode >> >> Old: >> 00 All-Active mode >> 01 Single-Active mode >> >> New (remove “mode”): >> 00 All-Active >> 01 Single-Active >> >> >> C) Split Horizon Type >> https://www.iana.org/assignments/bgp-extended-communities/bgp- >> extended-communities.xhtml#split-horizon-type >> >> C.1) Old title: >> Split Horizon Type >> >> New (hyphen): >> Split-Horizon Type >> >> >> C.2) Old column header: >> Split Horizon Type Value >> >> New (hyphen): >> Split-Horizon Type Value >> >> >> C.3) Old value 10: >> 10 ESI Label based filtering >> >> New (hyphen): >> 10 ESI Label-based filtering >> >> >> Please let us know if you have any questions. Otherwise, please let >> us know when the updates are complete. >> >> Thank you, >> RFC Editor/sg >> >> >> >> >>> On Mar 3, 2025, at 12:03 PM, Wen Lin <w...@juniper.net> wrote: >>> >>> Hi Sandy and Jorge, >>> >>> Thank you for advancing the draft to this stage. >>> >>> I reviewed the latest. It looks good. I approve the publication as >>> an RFC. >>> >>> Wen >>> >>> >>> Juniper Business Use Only >>> >>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>> Date: Monday, March 3, 2025 at 10:07 AM >>> To: Ali Sajassi (sajassi) <saja...@cisco.com> >>> Cc: Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com>, Jorge Rabadan >>> (Nokia) <jorge.raba...@nokia.com>, RFC Editor <rfc-editor@rfc- >>> editor.org>, Wen Lin <w...@juniper.net>, bess-...@ietf.org <bess- >>> a...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, Jeffrey >>> (Zhaohui) Zhang <zzh...@juniper.net>, Gunter van de Velde (Nokia) >>> <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org >>> <auth48archive@rfc-editor.org> >>> Subject: Re: AUTH48: RFC-to-be 9746 <draft-ietf-bess-evpn-mh-split- >>> horizon-11> for your review >>> >>> [External Email. Be cautious of content] >>> >>> >>> Hi Ali, >>> >>> Thank you for your review. We have noted your approval on the AUTH48 >>> page <https://urldefense.com/v3/__https://www.rfc- >>> editor.org/auth48/rfc9746__;!!NEt6yMaO- >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>> b8rfBd5vRCx3kJs0$ >. We will wait to hear from Wen before continuing >>> with the process. >>> >>> Thank you, >>> RFC Editor/sg >>> >>> >>>> On Mar 2, 2025, at 1:09 PM, Ali Sajassi (sajassi) >>>> <saja...@cisco.com> wrote: >>>> >>>> Hi Sandy, >>>> >>>> I reviewed it and it looked good . Thanks for your work. I approve >>>> the publication of this RFC. >>>> >>>> Cheers, >>>> Ali >>>> >>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>> Date: Friday, February 28, 2025 at 11:39 AM >>>> To: Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com> >>>> Cc: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, RFC Editor >>>> <rfc-edi...@rfc-editor.org>, w...@juniper.net <w...@juniper.net>, >>>> Ali Sajassi (sajassi) <saja...@cisco.com>, bess-...@ietf.org <bess- >>>> a...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, >>>> zzh...@juniper.net <zzh...@juniper.net>, Gunter van de Velde >>>> (Nokia) <gunter.van_de_ve...@nokia.com>, auth48archive@rfc- >>>> editor.org <auth48archive@rfc-editor.org> >>>> Subject: Re: AUTH48: RFC-to-be 9746 <draft-ietf-bess-evpn-mh-split- >>>> horizon-11> for your review >>>> >>>> Hi Wen and Ali, >>>> >>>> Please note that we await your review of RFC-to-be 9746 before >>>> continuing with the publication process. Please review and let us >>>> know if any updates are needed or if you approve the RFC for >>>> publication. >>>> >>>> The current files are available here: >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746.xml__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vRFwUxWIg$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746.txt__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vRQeRvL-8$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746.pdf__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vR_d3ClH8$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746.html__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vRpeiSVBE$ >>>> >>>> AUTH48 diffs: >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746-auth48diff.html__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vR9rk8n_E$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746-auth48rfcdiff.html__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vROUPpKvo$ (side by side) >>>> >>>> Comprehensive diffs: >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vRNyybZAs$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO- >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>> b8rfBd5vRxzIodOY$ (side by side) >>>> >>>> Thank you, >>>> RFC Editor/sg >>>> >>>> >>>> >>>>> On Feb 24, 2025, at 10:40 AM, Sandy Ginoza <sgin...@staff.rfc- >>>>> editor.org> wrote: >>>>> >>>>> Hi Kiran, >>>>> >>>>> Thank you for your review. We have noted your approval on the >>>>> AUTH48 page <https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/auth48/rfc9746__;!!NEt6yMaO- >>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>> b8rfBd5vRCx3kJs0$ >. >>>>> >>>>> Thank you, >>>>> RFC Editor/sg >>>>> >>>>> >>>>>> On Feb 24, 2025, at 9:10 AM, Kiran Nagaraj (Nokia) >>>>>> <kiran.naga...@nokia.com> wrote: >>>>>> >>>>>> Hi Sandy, >>>>>> Thank you very much for you work on this. The RFC looks good to >>>>>> me and I approve it for publication. >>>>>> >>>>>> Thanks >>>>>> Kiran >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>>>> Sent: Monday, February 24, 2025 8:41 AM >>>>>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> >>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Kiran Nagaraj >>>>>> (Nokia) <kiran.naga...@nokia.com>; w...@juniper.net; >>>>>> saja...@cisco.com; bess-...@ietf.org; bess-cha...@ietf.org; >>>>>> zzh...@juniper.net; Gunter van de Velde (Nokia) >>>>>> <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org >>>>>> Subject: Re: AUTH48: RFC-to-be 9746 <draft-ietf-bess-evpn-mh- >>>>>> split-horizon-11> for your review >>>>>> >>>>>> [You don't often get email from sgin...@staff.rfc-editor.org. >>>>>> Learn why this is important >>>>>> athttps://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO- >>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>> b8rfBd5vRj2C5yYI$ ] >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> Hi Jorge, >>>>>> >>>>>> Thank you for your review. We have noted your approval on the >>>>>> AUTH48 page <https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/auth48/rfc9746__;!!NEt6yMaO- >>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>> b8rfBd5vRCx3kJs0$ >. Please note that we will wait to hear from >>>>>> your coauthors as well before continuing with the publication >>>>>> process. >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/sg >>>>>> >>>>>> >>>>>>> On Feb 24, 2025, at 2:57 AM, Jorge Rabadan (Nokia) >>>>>>> <jorge.raba...@nokia.com> wrote: >>>>>>> >>>>>>> Hi Sandy, >>>>>>> >>>>>>> Looks good. >>>>>>> I approve the RFC for publication. >>>>>>> >>>>>>> Thanks! >>>>>>> Jorge >>>>>>> >>>>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>>>>> Date: Wednesday, February 19, 2025 at 4:31 PM >>>>>>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> >>>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, Kiran Nagaraj >>>>>>> (Nokia) >>>>>>> <kiran.naga...@nokia.com>, w...@juniper.net <w...@juniper.net>, >>>>>>> saja...@cisco.com <saja...@cisco.com>, bess-...@ietf.org >>>>>>> <bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>> <bess-cha...@ietf.org>,zzh...@juniper.net <zzh...@juniper.net>, >>>>>>> Gunter >>>>>>> van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, >>>>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9746 >>>>>>> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review >>>>>>> >>>>>>> [You don't often get email from sgin...@staff.rfc-editor.org. >>>>>>> Learn >>>>>>> why this is important at >>>>>>> https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vRj2C5yYI$ >>>>>>> ] >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Jorge, >>>>>>> >>>>>>> Thank you for your detailed review. We have updated the >>>>>>> document based on the replies below, but please review these >>>>>>> followup notes. >>>>>>> >>>>>>> a) We updated the terms as noted here. However, we left “Local >>>>>>> Bias” and “Split-Horizon Type” in Table 1, and where the values >>>>>>> seemed to refer to the IANA value or the expansion of SHT. >>>>>>> Please review and let us know if any adjustments are needed. >>>>>>> >>>>>>>> [jorge] Since RFC7432 was the first spec that introduced the >>>>>>>> concept, we should probably use “split-horizon”. >>>>>>>> [jorge] if we follow the same reasoning as in (a), we should >>>>>>>> use “local-bias” >>>>>>>> [jorge] “Geneve” based on the same reason. >>>>>>> >>>>>>> >>>>>>> >>>>>>> b) We updated the text to refer to Table 2. Please let us know >>>>>>> if you prefer otherwise. >>>>>>> >>>>>>>> [jorge] it refers to the multihoming redundancy mode field in >>>>>>>> table >>>>>>>> 2 (of section 5, IANA considerations) >>>>>>> >>>>>>> >>>>>>> >>>>>>> The current files are available here: >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746.xml__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vRFwUxWIg$ >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746.txt__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vRQeRvL-8$ >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746.pdf__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vR_d3ClH8$ >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746.html__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vRpeiSVBE$ >>>>>>> >>>>>>> AUTH48 diffs: >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746-auth48diff.html__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vR9rk8n_E$ >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746-auth48rfcdiff.html__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vROUPpKvo$ (side >>>>>>> by side) >>>>>>> >>>>>>> Comprehensive diffs: >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vRNyybZAs$ >>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>> editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO- >>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>> b8rfBd5vRxzIodOY$ (side by >>>>>>> side) >>>>>>> >>>>>>> Please review the updates carefully and let us know if any >>>>>>> corrections are needed or if you approve the RFC for >>>>>>> publication. >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/sg >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Feb 18, 2025, at 10:40 AM, Jorge Rabadan (Nokia) >>>>>>>> <jorge.rabadan=40nokia....@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>> Dear RFC-editor team, >>>>>>>> >>>>>>>> Thank you very much for your work on this. >>>>>>>> Please find our comments to your suggestions below with >>>>>>>> [jorge]. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Jorge >>>>>>>> >>>>>>>> >>>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>>>> Date: Monday, February 10, 2025 at 7:36 PM >>>>>>>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Kiran >>>>>>>> Nagaraj >>>>>>>> (Nokia) <kiran.naga...@nokia.com>, w...@juniper.net >>>>>>>> <w...@juniper.net>, saja...@cisco.com <saja...@cisco.com> >>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>>> <bess-cha...@ietf.org>, zzh...@juniper.net >>>>>>>> <zzh...@juniper.net>, >>>>>>>> Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, >>>>>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9746 >>>>>>>> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review >>>>>>>> >>>>>>>> >>>>>>>> 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, >>>>>>>> >>>>>>>> While reviewing this document during AUTH48, please resolve >>>>>>>> (as necessary) the following questions, which are also in the >>>>>>>> XML file. >>>>>>>> >>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>> appear >>>>>>>> in the title) for use on >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/search__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vR7P8vQMA$ . --> >>>>>>>> >>>>>>>> [jorge] some keywords: >>>>>>>> >>>>>>>> EVPN Multihoming, Split Horizon Filtering, Local Bias, ESI, >>>>>>>> encapsulations, SHT >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2) <!-- [rfced] We see the following terms used in various >>>>>>>> ways in the RFC Series. This document was consistent in their >>>>>>>> use of the capitalziation for the terms below. Is this the >>>>>>>> preferred form for future documents related to this subject? >>>>>>>> >>>>>>>> a) RFC 7432 uses "split-horizon" (lowercase and hyphenated) >>>>>>>> when acting as an adjective appearing before the noun, while >>>>>>>> this document uses the initial-capitalized form without a >>>>>>>> hyphen consistently. >>>>>>>> >>>>>>>> Examples from this document: >>>>>>>> Split Horizon procedure >>>>>>>> Split Horizon filtering >>>>>>>> Split Horizon method >>>>>>>> Split Horizon behavior >>>>>>>> Split Horizon Type (SHT) >>>>>>>> >>>>>>>> [jorge] Since RFC7432 was the first spec that introduced the >>>>>>>> concept, we should probably use “split-horizon”. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> b) "Local Bias" (this document) vs "local-bias" per RFCs 8365 >>>>>>>> and >>>>>>>> 9252 >>>>>>>> >>>>>>>> [jorge] if we follow the same reasoning as in (a), we should >>>>>>>> use “local-bias” >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> c) "GENEVE" (this document) vs "Geneve" per RFC 8926 >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] “Geneve” based on the same reason. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3) <!-- [rfced] Please review the following questions and >>>>>>>> changes >>>>>>>> regarding the terminology list in Section 1.1. >>>>>>>> >>>>>>>> a.) We have made some adjustments for readability and to >>>>>>>> demonstrate >>>>>>>> 1:1 relationships between abbreviations and their expansions. >>>>>>>> Please >>>>>>>> carefully review and let us know any objections. >>>>>>>> >>>>>>>> [jorge] looks good, thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> b.) We were unable to find the "EVPN Ethernet Auto-Discovery >>>>>>>> per ES route" >>>>>>>> explicitly mentioned in RFC 7432. May we update this item as >>>>>>>> follows >>>>>>>> for accuracy and concision? >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> * A-D per ES route: refers to the EVPN Ethernet Auto- >>>>>>>> Discovery per >>>>>>>> ES route defined in [RFC7432]. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> >>>>>>>> A-D per ES route: Auto-Discovery per Ethernet Segment route >>>>>>>> (as defined in >>>>>>>> [RFC7432]). >>>>>>>> >>>>>>>> [jorge] yes, that’s the one. Thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> c.) Arg.FE2 is mentioned in RFC 9252; however, RFC 9252 says >>>>>>>> that >>>>>>>> "the Arg.FE2 notation [is] introduced in [RFC8986]". Would you >>>>>>>> like >>>>>>>> to update the citation below to RFC 8986? >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> * Arg.FE2: refers to the ESI filtering argument used for >>>>>>>> Split >>>>>>>> Horizon as specified in [RFC9252]. >>>>>>>> >>>>>>>> [jorge] I’d prefer to keep RFC9252. Although first introduced >>>>>>>> in RFC8986, it’s use is really specified in RFC9252. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> d.) Several abbreviations appear in this document but are not >>>>>>>> included in this terminology list (see some examples below). >>>>>>>> Please >>>>>>>> review and let us know if you would like to add these or any >>>>>>>> additional terms to this list. >>>>>>>> >>>>>>>> Type-Length-Value (TLV) >>>>>>>> Route Targets (RTs) >>>>>>>> Provider Edge (PE) >>>>>>>> Customer Edge (CE) >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] yes please, add those to the terminology list. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4) <!-- [rfced] The parentheses in the text below seem to >>>>>>>> contain a >>>>>>>> mixture of abbreviations and additional context. For clarity >>>>>>>> and >>>>>>>> readability, may we update as follows? >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> The ingress Network Virtualization Edge (NVE) device appends a >>>>>>>> label >>>>>>>> corresponding to the source Ethernet Segment Identifier (ESI >>>>>>>> label) >>>>>>>> during packet encapsulation. The egress NVE verifies the ESI >>>>>>>> label when >>>>>>>> attempting to forward a multi-destination frame through a >>>>>>>> local >>>>>>>> Ethernet Segment (ES) interface. If the ESI label matches the >>>>>>>> site >>>>>>>> identifier (ESI) associated with that ES interface, the packet >>>>>>>> is not >>>>>>>> forwarded... >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> >>>>>>>> The ingress NVE device appends a label corresponding to the >>>>>>>> source ESI >>>>>>>> (the ESI label) during packet encapsulation. The egress NVE >>>>>>>> verifies >>>>>>>> the ESI label when attempting to forward a multi-destination >>>>>>>> frame >>>>>>>> through a local ES interface. If the ESI label matches the >>>>>>>> site >>>>>>>> identifier (the ESI) associated with that ES interface, then >>>>>>>> the packet >>>>>>>> is not forwarded... >>>>>>>> >>>>>>>> [jorge] your suggestion is good, please go ahead. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 5) <!-- [rfced] For clarity and consistency with other list >>>>>>>> items, >>>>>>>> may we adjust the term "(SR-)MPLS" as seen below? >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> This document classifies the tunnel encapsulations used by >>>>>>>> EVPN into: >>>>>>>> >>>>>>>> 1. IP-based MPLS tunnels >>>>>>>> >>>>>>>> 2. (SR-)MPLS tunnels, that is, MPLS and Segment Routing with >>>>>>>> MPLS >>>>>>>> data plane tunnels >>>>>>>> >>>>>>>> 3. IP tunnels >>>>>>>> >>>>>>>> 4. SRv6 tunnels >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> >>>>>>>> This document classifies the tunnel encapsulations used by >>>>>>>> EVPN into: >>>>>>>> >>>>>>>> 1. IP-based MPLS tunnels >>>>>>>> >>>>>>>> 2. MPLS and SR-MPLS tunnels >>>>>>>> >>>>>>>> 3. IP tunnels >>>>>>>> >>>>>>>> 4. SRv6 tunnels >>>>>>>> >>>>>>>> [jorge] yes, go ahead please. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> b.) "(SR-)MPLS" also appears in the instances below. For ease >>>>>>>> of the >>>>>>>> reader, may we update these instances similarly? >>>>>>>> >>>>>>>> Originals: >>>>>>>> >>>>>>>> * (SR-)MPLS tunnels only support ESI Label-based Split >>>>>>>> Horizon >>>>>>>> filtering >>>>>>>> >>>>>>>> | (SR-)MPLS | ESI Label filtering | No | Yes >>>>>>>> | | >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] sure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6) <!-- [rfced] Please review the artwork in Section 2.1 and >>>>>>>> let us >>>>>>>> know what "Section 5" refers to and if any other updates are >>>>>>>> needed. Perhaps this refers to Table 3? >>>>>>>> >>>>>>>> Original: >>>>>>>> RED = "Multihoming Redundancy Mode" field (section 5) >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] it refers to the multihoming redundancy mode field in >>>>>>>> table >>>>>>>> 2 (of section 5, IANA considerations) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 7) <!-- [rfced] The figure in Section 2.1 indicates that value >>>>>>>> 11 is "reserved for future use". However, table 3 (and the >>>>>>>> IANA registry) indicates the value is unassigned. "Reserved" >>>>>>>> and "Unassigned" have distinct meanings. Please review "Well- >>>>>>>> Known Registration Status Terminology" in RFC 8126 >>>>>>>> <https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/rfc/rfc8126.html*section-6__;Iw!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRz303NOo$ > and let us know which is correct. >>>>>>>> >>>>>>>> Section 2.1 (double hyphen changed to single hyphen so this >>>>>>>> comment appears correctly in the XML file: >>>>>>>> 1 1 -> reserved for future use >>>>>>>> >>>>>>>> Table 3: >>>>>>>> | 11 | Unassigned | | >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] please change the figure to “Unassigned” >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 8) <!-- [rfced] How may we adjust the text below to avoid >>>>>>>> using an >>>>>>>> RFC as an adjective? >>>>>>>> >>>>>>>> Original: >>>>>>>> An egress NVE MUST NOT use an SHT value other than 00 when >>>>>>>> advertising an A-D per ES route with [RFC9012] Tunnel >>>>>>>> encapsulation >>>>>>>> types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or >>>>>>>> no BGP >>>>>>>> tunnel encapsulation extended community at all. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> An egress NVE MUST NOT use an SHT value other than 00 when >>>>>>>> advertising an A-D per ES route with the following tunnel >>>>>>>> encapsulation >>>>>>>> types from [RFC9012]: VXLAN (type 8), NVGRE (type 9), MPLS >>>>>>>> (type 10), or no BGP >>>>>>>> Tunnel Encapsulation Extended Community at all. >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] your suggestion looks good to me >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 9) <!-- [rfced] How may we update the citations in the text >>>>>>>> below? >>>>>>>> We were unable to find either "Tunnel encapsulation type 19" >>>>>>>> or >>>>>>>> "GENEVE" encapsulation in [RFC9012]. We note that the IANA >>>>>>>> entry refers to RFC 8926 (19 Geneve Encapsulation). >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with >>>>>>>> GENEVE >>>>>>>> encapsulation ([RFC9012], Tunnel encapsulation type 19, >>>>>>>> [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> >>>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with >>>>>>>> GENEVE >>>>>>>> encapsulation [RFC9012] (and tunnel encapsulation type 19 >>>>>>>> [EVPN-GENEVE]) MAY >>>>>>>> use an SHT value of 01 or 10. >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] Hmm.. I think this is more accurate: >>>>>>>> >>>>>>>> ORIGINAL: >>>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with >>>>>>>> GENEVE >>>>>>>> encapsulation ([RFC9012], Tunnel encapsulation type 19, >>>>>>>> [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or >>>>>>>> 10. >>>>>>>> >>>>>>>> NEW: >>>>>>>> >>>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with >>>>>>>> GENEVE >>>>>>>> encapsulation (tunnel encapsulation type 19 in the BGP Tunnel >>>>>>>> Encapsulation attribute [RFC9012]) MAY >>>>>>>> use an SHT value of 01 or 10. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 10) <!-- [rfced] How may we rephrase the title of this section >>>>>>>> to >>>>>>>> avoid using an RFC as an adjective? >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> 2.4. Backwards Compatibility With RFC8365 NVEs >>>>>>>> >>>>>>>> Perhaps (no RFC mentioned): >>>>>>>> >>>>>>>> 2.4. Backwards Compatibility with NVEs >>>>>>>> >>>>>>>> Perhaps (RFC mentioned): >>>>>>>> >>>>>>>> 2.4. Backwards Compatibility with NVEs from RFC 8365 >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] use the latter one please – “2.4. Backwards >>>>>>>> Compatibility with NVEs from RFC 8365” >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 11) <!-- [rfced] May we make these registry titles plural? >>>>>>>> >>>>>>>> Multihoming Redundancy Mode -> Multihoming Redundancy Modes >>>>>>>> Split >>>>>>>> Horizon Type -> Split Horizon Types >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] I don’t think so, it reads better the way it is >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 12) <!-- [rfced] Because "mode" is part of the registry and >>>>>>>> column titles, does "mode" need to appear in description? >>>>>>>> >>>>>>>> From Table 3 and the IANA registry [1]: >>>>>>>> +=======+=============================+===========+ >>>>>>>> | Value | Multihoming redundancy mode | Reference | >>>>>>>> +=======+=============================+===========+ >>>>>>>> | 00 | All-Active mode | [RFC7432] | >>>>>>>> | 01 | Single-Active mode | [RFC7432] | >>>>>>>> >>>>>>>> [1] >>>>>>>> https://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fww__;JSUl!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vR2IYPsDg$ >>>>>>>> w.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp- >>>>>>>> extended-c >>>>>>>> ommunities.xhtml%23multihoming-redundancy- >>>>>>>> mode&data=05%7C02%7Ckiran. >>>>>>>> nagaraj%40nokia.com%7C4f6980c5bf9a4351ccd608dd54f24d2a%7C5d471751967 >>>>>>>> 5428d917b70f44f9630b0%7C0%7C0%7C638760122149077373%7CUnknown%7CTWFpb >>>>>>>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >>>>>>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7XZv%2B8E8kYSZvSG >>>>>>>> cFZAMh00gKiO2DkZa5QJEVpFJOjk%3D&reserved=0 >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] no, it does not. You can change those values to “All- >>>>>>>> Active” and “Single-Active” and remove the “mode”. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 13) <!-- [rfced] Please review the following questions and >>>>>>>> changes >>>>>>>> regarding the terminology used in this document: >>>>>>>> >>>>>>>> a.) We note that the term "MPLSoX" does not appear in this >>>>>>>> document >>>>>>>> after it is introduced in Section 1. May we remove this term >>>>>>>> from the terminology list? >>>>>>>> >>>>>>>> Original: >>>>>>>> * MPLSoX: refers to MPLS over any IP encapsulation. >>>>>>>> Examples are >>>>>>>> MPLS-over-UDP or MPLS-over-GRE. >>>>>>>> >>>>>>>> [jorge] But it appears in the introduction and it may still >>>>>>>> help if the reader does not know what MPLSoX means in the >>>>>>>> introduction… I would leave it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> b.) FYI - For consistency with RFCs 8402, 8986, and 9252, we >>>>>>>> have updated the terms below as follows. Please review and let >>>>>>>> us know any objections. >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> Segment Routing with MPLS data plane (SR-MPLS) Segment Routing >>>>>>>> with >>>>>>>> IPv6 data plane (SRv6) >>>>>>>> >>>>>>>> Current: >>>>>>>> >>>>>>>> SR over MPLS (SR-MPLS) >>>>>>>> Segment Routing over IPv6 (SRv6) >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> [jorge] sounds good, thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 14) <!-- [rfced] The references in this document do not appear >>>>>>>> to be sorted. >>>>>>>> Would you like to order them alphanumerically? --> >>>>>>>> >>>>>>>> [jorge] yes, please >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 15) <!-- [rfced] Please review the "Inclusive Language" >>>>>>>> portion of >>>>>>>> the online Style Guide >>>>>>>> <https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRPqqoIkQ$ > >>>>>>>> and let us know if any changes are needed. Updates of this >>>>>>>> nature typically result in more precise language, which is >>>>>>>> helpful for readers. >>>>>>>> >>>>>>>> Note that our script did not flag any words in particular, but >>>>>>>> this >>>>>>>> should still be reviewed as a best practice. --> >>>>>>>> >>>>>>>> [jorge] I checked, but couldn’t identify anything to change. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> RFC Editor >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Feb 10, 2025, at 7:28 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>>> >>>>>>>> *****IMPORTANT***** >>>>>>>> >>>>>>>> Updated 2025/02/10 >>>>>>>> >>>>>>>> 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/__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRXEli_vU$ ). >>>>>>>> >>>>>>>> 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__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRMZaFfHE$ ). >>>>>>>> >>>>>>>> * 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__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vROfzigsg$ >. >>>>>>>> >>>>>>>> * 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 (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, 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-4Q9l2US__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRCXlkn0U$ >>>>>>>> xIAe6P8O4Zc >>>>>>>> >>>>>>>> * The archive itself: >>>>>>>> >>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vR8SD3tkc$ >>>>>>>> >>>>>>>> * 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 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/rfc9746.xml__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRFwUxWIg$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/authors/rfc9746.html__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRpeiSVBE$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/authors/rfc9746.pdf__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vR_d3ClH8$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/authors/rfc9746.txt__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRQeRvL-8$ >>>>>>>> >>>>>>>> Diff file of the text: >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRNyybZAs$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRxzIodOY$ (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Diff of the XML: >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/authors/rfc9746-xmldiff1.html__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vR9ybFjas$ >>>>>>>> >>>>>>>> >>>>>>>> Tracking progress >>>>>>>> ----------------- >>>>>>>> >>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>> editor.org/auth48/rfc9746__;!!NEt6yMaO- >>>>>>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- >>>>>>>> b8rfBd5vRCx3kJs0$ >>>>>>>> >>>>>>>> Please let us know if you have any questions. >>>>>>>> >>>>>>>> Thank you for your cooperation, >>>>>>>> >>>>>>>> RFC Editor >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> RFC 9746 (draft-ietf-bess-evpn-mh-split-horizon-11) >>>>>>>> >>>>>>>> Title : BGP EVPN Multi-Homing Extensions for Split >>>>>>>> Horizon Filtering >>>>>>>> Author(s) : J. Rabadan, K. Nagaraj, W. Lin, A. Sajassi >>>>>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui >>>>>>>> (Jeffrey) Zhang >>>>>>>> >>>>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de >>>>>>>> Velde >>>>> >>>> >>> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
