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
