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
