Hi Authors, Mach, IJsbrand, and Tony - We have noted your approvals on the AUTH48 status page.
All - We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9793 Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. RFC Editor/ap > On Jun 10, 2025, at 12:31 AM, Antoni Przygienda <p...@juniper.net> wrote: > > All good for me. Thanks. Tony > >> On 10 Jun 2025, at 09:15, IJsbrand Wijnands <i...@braindump.be> wrote: >> >> [External Email. Be cautious of content] >> >> >> 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
