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 > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
