I Approve the changes! Sent from my iPhone
> On 6 Jun 2025, at 21:53, Keyur Patel <ke...@arrcus.com> wrote: > > Approving the changes as well. > >> On Jun 6, 2025, at 12:42 PM, Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >> wrote: >> >> Hi Alanna, >> >> The .txt file looks fine, but the second diff does not look correct (I did >> not check the first diff file - I am not used to the format). >> >> I approve the changes. >> >> Thanks. >> Jeffrey >> >> >> Juniper Business Use Only >> -----Original Message----- >> From: Alanna Paloma <apal...@staff.rfc-editor.org> >> Sent: Friday, June 6, 2025 3:26 PM >> To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >> Cc: xuxia...@cmss.chinamobile.com; mach.c...@huawei.com; ke...@arrcus.com; >> i...@braindump.be; Antoni Przygienda <p...@juniper.net>; >> rfc-edi...@rfc-editor.org; bier-...@ietf.org; bier-cha...@ietf.org; >> chen....@zte.com.cn; gunter.van_de_ve...@nokia.com; >> auth48archive@rfc-editor.org >> Subject: Re: AUTH48: RFC-to-be 9793 <draft-ietf-bier-idr-extensions-19> for >> your review >> >> [External Email. Be cautious of content] >> >> >> Hi Jeffrey, >> >> We have reverted these changes back to "Encapsulation sub-TLV”. >> >> The files have been posted here (please refresh): >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.xml__;!!NEt6yMaO-gk!ExYIOxRQzQoIzEBrbCPJfPz9-EaIrgihxDgrsm3LQ4IfEwhdgSWTWLn72lidmUAqv_eJHYF5XaVrk64mosCB7Fbn5w$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.txt__;!!NEt6yMaO-gk!ExYIOxRQzQoIzEBrbCPJfPz9-EaIrgihxDgrsm3LQ4IfEwhdgSWTWLn72lidmUAqv_eJHYF5XaVrk64mosBWlIHtvQ$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.html__;!!NEt6yMaO-gk!ExYIOxRQzQoIzEBrbCPJfPz9-EaIrgihxDgrsm3LQ4IfEwhdgSWTWLn72lidmUAqv_eJHYF5XaVrk64mosB7-0sXjg$ >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.pdf__;!!NEt6yMaO-gk!ExYIOxRQzQoIzEBrbCPJfPz9-EaIrgihxDgrsm3LQ4IfEwhdgSWTWLn72lidmUAqv_eJHYF5XaVrk64mosAcVt3ouQ$ >> >> The relevant diff files have been posted here: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793-diff.html__;!!NEt6yMaO-gk!ExYIOxRQzQoIzEBrbCPJfPz9-EaIrgihxDgrsm3LQ4IfEwhdgSWTWLn72lidmUAqv_eJHYF5XaVrk64mosAHeveWeg$ >> (comprehensive diff) >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793-auth48diff.html__;!!NEt6yMaO-gk!ExYIOxRQzQoIzEBrbCPJfPz9-EaIrgihxDgrsm3LQ4IfEwhdgSWTWLn72lidmUAqv_eJHYF5XaVrk64mosCT3ui_bg$ >> (AUTH48 changes) >> >> Thank you, >> RFC Editor/ap >> >> >>>> On Jun 6, 2025, at 12:14 PM, Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >>>> wrote: >>> >>> Hi Alanna, >>> >>> I see that in section 4 and 5, "MPLS" was added before "Encapsulation >>> sub-TLV". That should not be done - the existing wording applies to both >>> MPLS and non-MPLS Encapsulation sub-TLV. If necessary, you can say "MPLS or >>> non-MPLS Encapsulation sub-TLV". >>> >>> Thanks. >>> Jeffrey >>> >>> >>> Juniper Business Use Only >>> -----Original Message----- >>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>> Sent: Friday, June 6, 2025 1:25 PM >>> To: xuxia...@cmss.chinamobile.com; mach.c...@huawei.com; >>> ke...@arrcus.com; i...@braindump.be; Antoni Przygienda >>> <p...@juniper.net>; Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >>> Cc: rfc-edi...@rfc-editor.org; bier-...@ietf.org; >>> bier-cha...@ietf.org; chen....@zte.com.cn; >>> gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >>> Subject: Re: AUTH48: RFC-to-be 9793 >>> <draft-ietf-bier-idr-extensions-19> for your review >>> >>> [External Email. Be cautious of content] >>> >>> >>> Authors, >>> >>> This is a friendly reminder that we await your reviews and approvals of the >>> updated files. We will await approvals from each party listed on the AUTH48 >>> status page below prior to moving this document forward in the publication >>> process. >>> >>> The files have been posted here (please refresh): >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793 >>> .xml__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89V >>> DPhD9qzA0k3V8croYABgvEEahFswRw1LTRkP4J_rg$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793 >>> .txt__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89V >>> DPhD9qzA0k3V8croYABgvEEahFswRw1LTSvcMTvmQ$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793 >>> .html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89 >>> VDPhD9qzA0k3V8croYABgvEEahFswRw1LTTO-THXdw$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793 >>> .pdf__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89V >>> DPhD9qzA0k3V8croYABgvEEahFswRw1LTSFK2imLw$ >>> >>> The relevant diff files have been posted here: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793 >>> -diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7 >>> k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSpqctNWw$ (comprehensive diff) >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793 >>> -auth48diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGAB >>> MP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTS_c4zfOg$ (AUTH48 >>> changes) >>> >>> For the AUTH48 status of this document, please see: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9793_ >>> _;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89VDPhD9 >>> qzA0k3V8croYABgvEEahFswRw1LTRKxj6t8A$ >>> >>> Thank you, >>> RFC Editor/ap >>> >>>>> On May 30, 2025, at 11:08 AM, Alanna Paloma >>>>> <apal...@staff.rfc-editor.org> wrote: >>>> >>>> Hi Jeffrey, >>>> >>>> Thank you for your reply. We have updated the files accordingly. >>>> >>>> The files have been posted here (please refresh): >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3 >>>> .xml__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89 >>>> V DPhD9qzA0k3V8croYABgvEEahFswRw1LTRkP4J_rg$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3 >>>> .txt__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89 >>>> V DPhD9qzA0k3V8croYABgvEEahFswRw1LTSvcMTvmQ$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3 >>>> .html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L8 >>>> 9 VDPhD9qzA0k3V8croYABgvEEahFswRw1LTTO-THXdw$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3 >>>> .pdf__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89 >>>> V DPhD9qzA0k3V8croYABgvEEahFswRw1LTSFK2imLw$ >>>> >>>> The relevant diff files have been posted here: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3 >>>> -diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH >>>> 7 k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSpqctNWw$ (comprehensive >>>> diff) >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3 >>>> -auth48diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGA >>>> B MP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTS_c4zfOg$ (AUTH48 >>>> changes) >>>> >>>> Please review the document carefully and contact us with any further >>>> updates you may have. Note that we do not make changes once a document is >>>> published as an RFC. >>>> >>>> We will await approvals from each party listed on the AUTH48 status page >>>> below prior to moving this document forward in the publication process. >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9793 >>>> _ >>>> _;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89VDPhD >>>> 9 qzA0k3V8croYABgvEEahFswRw1LTRKxj6t8A$ >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On May 29, 2025, at 7:26 PM, Jeffrey (Zhaohui) Zhang >>>>> <zzhang=40juniper....@dmarc.ietf.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please see zzh> below. >>>>> >>>>> >>>>> Juniper Business Use Only >>>>> -----Original Message----- >>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>> Sent: Tuesday, May 27, 2025 8:20 PM >>>>> To: xuxia...@cmss.chinamobile.com; mach.c...@huawei.com; >>>>> ke...@arrcus.com; i...@braindump.be; Antoni Przygienda >>>>> <p...@juniper.net>; Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >>>>> Cc: rfc-edi...@rfc-editor.org; bier-...@ietf.org; >>>>> bier-cha...@ietf.org; chen....@zte.com.cn; >>>>> gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >>>>> Subject: Re: AUTH48: RFC-to-be 9793 >>>>> <draft-ietf-bier-idr-extensions-19> for your review >>>>> >>>>> [External Email. Be cautious of content] >>>>> >>>>> >>>>> Authors, >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the XML file. >>>>> >>>>> 1) <!--[rfced] Please note that the title of the document has been >>>>> updated as follows. >>>>> Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style >>>>> Guide"). >>>>> Please review. >>>>> >>>>> Original: >>>>> BGP Extensions for BIER >>>>> >>>>> Current: >>>>> BGP Extensions for Bit Index Explicit Replication (BIER) >>>>> --> >>>>> >>>>> Zzh> Ack. >>>>> >>>>> 2) <!-- [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__;!!NE >>>>> t >>>>> 6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAP >>>>> g >>>>> 1aih3Jvh2GZMI2a16x_qopTsnJnq$ . --> >>>>> >>>>> >>>>> 3) <!--[rfced] We see these two similar sentences in the Abstract and >>>>> Introduction. May we update the sentence from the Introduction to match >>>>> the one from the Abstract? >>>>> >>>>> Zzh> Sure. >>>>> >>>>> Abstract: >>>>> This document describes BGP extensions for advertising the BIER >>>>> information and methods for calculating BIER states based on the >>>>> advertisements. >>>>> >>>>> Introduction: >>>>> This document describes BGP extensions for advertising the >>>>> BIER-specific information and the methods for calculating BIER >>>>> forwarding states with this information. >>>>> --> >>>>> >>>>> >>>>> 4) <!--[rfced] FYI - We moved the Requirements Language paragraph to the >>>>> Terminology section per the RFC Style Guide; see Section 4 of RFC 7322. >>>>> --> >>>>> >>>>> Zzh> Sure. >>>>> >>>>> 5) <!--[rfced] FYI - We note a mix of "one-octet" vs. "1-octet" and "two >>>>> octets" vs. "2 octets". We updated the document to use the numeral form >>>>> for consistency. >>>>> --> >>>>> >>>>> Zzh> Thanks. >>>>> >>>>> 6) <!--[rfced] Should a citation be added for the quoted text below? Or >>>>> may we remove the quotation marks? >>>>> >>>>> Zzh> Please remove the quotation marks. >>>>> >>>>> Original: >>>>> If a BIER attribute is >>>>> received from the peer, it MUST be treated exactly as if it were an >>>>> unrecognized non-transitive attribute. That is, "it MUST be quietly >>>>> ignored and not passed along to other BGP peers". >>>>> --> >>>>> >>>>> >>>>> 7) <!-- [rfced] Some author comments are present in the XML. Please >>>>> confirm that no updates related to these comments are outstanding. Note >>>>> that the comments will be deleted prior to publication. >>>>> --> >>>>> >>>>> Zzh> Confirmed. >>>>> >>>>> >>>>> 8) <!--[rfced] Acronyms >>>>> >>>>> a) Both the expansion and the acronym for the following terms are used >>>>> throughout the document. After the first expansions, would you like to >>>>> use only the acronyms for consistency and per the guidance from the "Web >>>>> Portion of the Style Guide" >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*ref_repo__;Iw!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qoiGXIx1-$ >>>>> >? >>>>> >>>>> BFR Neighbor (BFR-NBR) >>>>> Set Identifier (SI) >>>>> >>>>> Zzh> Yes, please. >>>>> >>>>> b) Per RFC 8279, may we update the following acronym expansions to the >>>>> latter form listed for consistency? >>>>> >>>>> BFER = BIER Forwarding Egress Router > Bit-Forwarding Egress Router >>>>> BFR = BIER Forwarding Router > Bit-Forwarding Router >>>>> BIFT = BIER Forwarding Table > Bit Index Forwarding Table >>>>> BFR-id = BIER Forwarding Router Identifier, BIER Forwarding Router >>>>> identifier > BFR Identifier >>>>> >>>>> zzh> Ah, yes. Thank you. >>>>> >>>>> c) FYI - We have added an expansion for the following abbreviation per >>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion >>>>> in the document carefully to ensure correctness. >>>>> >>>>> External BGP (EBGP) >>>>> --> >>>>> >>>>> Zzh> Yes. >>>>> >>>>> >>>>> 9) <!-- [rfced] Terminology >>>>> >>>>> a) Throughout the text, the following terminology appears to be used >>>>> inconsistently. May we update to the latter form listed for consistency? >>>>> >>>>> BIER Attribute > BIER attribute >>>>> >>>>> BIER Path Attribute > BIER path attribute >>>>> >>>>> MPLS encapsulation sub-TLV, MPLS encapsulation Sub-TLV, MPLS >>>>> Encapsulation Sub-TLV, Encapsulation sub-TLV > MPLS Encapsulation >>>>> sub-TLV (per >>>>> IANA) >>>>> >>>>> non-MPLS encapsulation sub-TLV, non-MPLS encapsulation Sub-TLV > >>>>> non-MPLS Encapsulation sub-TLV (per IANA) >>>>> >>>>> Nexthop sub-TLV > BIER Nexthop sub-TLV (per IANA) >>>>> >>>>> Zzh> Yes. Thanks! >>>>> >>>>> b) The following terminology appears to be used inconsistently throughout >>>>> the text. Please review and let us know if/how they may be made >>>>> consistent. >>>>> >>>>> Nexthop vs. nexthop >>>>> [Note that RFCs 4271, 7606, 8279, and 8296 use "next hop" (for >>>>> general use).] >>>>> >>>>> Zzh> There are many "BIER Nexthop sub-TLV". I'd like to keep the capital >>>>> there. The figure for the encoding also shows "Nexthop" and that matches >>>>> other fields like "Length". The text related to that sub-TLV uses >>>>> capital, and I think that is reasonable. >>>>> Zzh> The "nexthop" (lower case) in the following three places can be >>>>> changed to "next hop": >>>>> >>>>> ... If the BIER Nexthop sub-TLV is >>>>> not included, the BIER prefix will be used by receiving BFRs as the >>>>> BIER nexthop when calculating BIFT. >>>>> >>>>> --------------- >>>>> >>>>> When BFR2 receives the route, it calculates its BIFT entries. >>>>> Because the route from BFER1 does not include a BIER Nexthop, BFR2 >>>>> uses BFRer1's BFR-prefix as the nexthop. >>>>> >>>>> ----------------- >>>>> >>>>> When BFR1 receives the routes, it calculates the BIFT entries, using >>>>> BFR2's address encoded in the BIER Nexthop sub-TLV as the nexthop. >>>>> Because BFR2 is not directly connected, a tunnel must be used. >>>>> >>>>> Zzh> There are a few places where "Nexthop sub-TLV" is used w/o the >>>>> preceding "BIER". Those should be replaced with "BIER Nexthop sub-TLV". >>>>> Zzh> In the "6. Example of BIER Nexthop Usage and Handling", please add >>>>> sub-TLV after Nexthop. >>>>> >>>>> Sub-domain vs. sub-domain >>>>> --> >>>>> >>>>> Zzh> Please use "sub-domain" except in the text related to the figure >>>>> about the encoding. >>>>> Zzh> For example, "sub-domain" should be used in the following paragraph: >>>>> >>>>> When creating a BIER attribute, a BFR MUST include one BIER TLV for >>>>> every Sub-domain that the prefix belongs to. The attribute type >>>>> code for the BIER Attribute is TBD. The value field of the BIER >>>>> Attribute contains one or more BIER TLV shown as follows: >>>>> >>>>> zzh> While "Sub-domain" can be used in the following places: >>>>> >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> >>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- >>>>> | Type = 1 | Length | >>>>> >>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- >>>>> | Sub-domain | BFR-ID | Reserved | >>>>> >>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+- >>>>> +AH4 +AH4 >>>>> | Sub-TLVs | >>>>> >>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-.......................... >>>>> >>>>> Type: 1. >>>>> >>>>> Length: Two octets encoding the length in octets of the Value >>>>> part. >>>>> >>>>> Sub-domain [RFC8279]: ... >>>>> >>>>> Zzh> Thanks! >>>>> Zzh> Jeffrey >>>>> >>>>> >>>>> 10) <!-- [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!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qooA8SONK$ >>>>> > 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. >>>>> --> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/ap/kc >>>>> >>>>> >>>>> On May 27, 2025, at 5:18 PM, rfc-edi...@rfc-editor.org wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2025/05/27 >>>>> >>>>> 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!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qorCbWs3T$ >>>>> ). >>>>> >>>>> 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 +IBM >>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qorkpCTZ3$ >>>>> ). >>>>> >>>>> * 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!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qohwa_t3F$ >>>>> >. >>>>> >>>>> * 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 +IBg-REPLY >>>>> ALL+IBk 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/ie >>>>> t >>>>> f-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!BJ6v2FOBd8VGk >>>>> Y >>>>> JHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qol >>>>> L >>>>> qKqFy$ >>>>> >>>>> * The archive itself: >>>>> >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse >>>>> / >>>>> auth48archive/__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46 >>>>> U WCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qovujzSGw$ >>>>> >>>>> * 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 >>>>> +IBQ OR +IBQ >>>>> 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 +IBg-REPLY >>>>> ALL+IBk, 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/rfc97 >>>>> 9 >>>>> 3.xml__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0 >>>>> r wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qokw_3RTt$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>> 9 >>>>> 3.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e >>>>> 0 rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qonasllh-$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>> 9 >>>>> 3.pdf__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0 >>>>> r wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qop-041dD$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>> 9 >>>>> 3.txt__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0 >>>>> r wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qouGvs8K2$ >>>>> >>>>> Diff file of the text: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>> 9 >>>>> 3-diff.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWC >>>>> b nU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qots0QlJN$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>> 9 >>>>> 3-rfcdiff.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46 >>>>> U WCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qorEH-8sl$ (side by >>>>> side) >>>>> >>>>> Diff of the XML: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>> 9 >>>>> 3-xmldiff1.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr4 >>>>> 6 UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qolwW7YVW$ >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc979 >>>>> 3 >>>>> __;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4m >>>>> b mmtftAPg1aih3Jvh2GZMI2a16x_qovI0B0Uw$ >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9793 (draft-ietf-bier-idr-extensions-19) >>>>> >>>>> Title : BGP Extensions for BIER >>>>> Author(s) : X. Xu, M. Chen, K. Patel, I. Wijnands, T. Przygienda, >>>>> Z. Zhang >>>>> WG Chair(s) : Tony Przygienda, Greg Shepherd >>>>> >>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de >>>>> Velde >>> >>> >> >> [EXTERNAL] -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
