Hi Ali, Thank you for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9746>. 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-...@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://www.rfc-editor.org/authors/rfc9746.xml > https://www.rfc-editor.org/authors/rfc9746.txt > https://www.rfc-editor.org/authors/rfc9746.pdf > https://www.rfc-editor.org/authors/rfc9746.html > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9746-auth48diff.html > https://www.rfc-editor.org/authors/rfc9746-auth48rfcdiff.html (side by side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9746-diff.html > https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (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://www.rfc-editor.org/auth48/rfc9746>. > > > > 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 at https://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. > >> > >> > >> > >> Hi Jorge, > >> > >> Thank you for your review. We have noted your approval on the AUTH48 page > >> <https://www.rfc-editor.org/auth48/rfc9746>. 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://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. > >>> > >>> > >>> > >>> 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://www.rfc-editor.org/authors/rfc9746.xml > >>> https://www.rfc-editor.org/authors/rfc9746.txt > >>> https://www.rfc-editor.org/authors/rfc9746.pdf > >>> https://www.rfc-editor.org/authors/rfc9746.html > >>> > >>> AUTH48 diffs: > >>> https://www.rfc-editor.org/authors/rfc9746-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9746-auth48rfcdiff.html (side > >>> by side) > >>> > >>> Comprehensive diffs: > >>> https://www.rfc-editor.org/authors/rfc9746-diff.html > >>> https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (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://www.rfc-editor.org/search. --> > >>>> > >>>> [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://www.rfc-editor.org/rfc/rfc8126.html#section-6> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > >>>> 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://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >>>> 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://www.rfc-editor.org/faq/). > >>>> > >>>> 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://trustee.ietf.org/license-info). > >>>> > >>>> * 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://authors.ietf.org/rfcxml-vocabulary>. > >>>> > >>>> * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US > >>>> xIAe6P8O4Zc > >>>> > >>>> * The archive itself: > >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>> > >>>> * 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://www.rfc-editor.org/authors/rfc9746.xml > >>>> https://www.rfc-editor.org/authors/rfc9746.html > >>>> https://www.rfc-editor.org/authors/rfc9746.pdf > >>>> https://www.rfc-editor.org/authors/rfc9746.txt > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9746-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (side by > >>>> side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9746-xmldiff1.html > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> https://www.rfc-editor.org/auth48/rfc9746 > >>>> > >>>> 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
