Hi all, I also approve the publication of the current version of the draft.
Thanks, Mach > -----Original Message----- > From: Alanna Paloma <apal...@staff.rfc-editor.org> > Sent: Tuesday, June 10, 2025 1:05 AM > To: 徐小虎 <xuxia...@cmss.chinamobile.com> > Cc: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Mach Chen > <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> > foryour review > > Hi Xiaohu, > > We have noted your approval on the AUTH48 status page: > https://www.rfc-editor.org/auth48/rfc9793 > > Thank you, > RFC Editor/ap > > > > On Jun 8, 2025, at 8:13 PM, 徐小虎 <xuxia...@cmss.chinamobile.com> > wrote: > > > > > > Hi all， > > > > I approve the changes as well. > > > > BR > > Xiaohu > > > > Hi Jeffrey, > > > > We have reverted these changes back to "Encapsulation sub-TLV”. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9793.xml > > https://www.rfc-editor.org/authors/rfc9793.txt > > https://www.rfc-editor.org/authors/rfc9793.html > > https://www.rfc-editor.org/authors/rfc9793.pdf > > > > The relevant diff files have been posted here: > > https://www.rfc-editor.org/authors/rfc9793-diff.html (comprehensive > > diff) https://www.rfc-editor.org/authors/rfc9793-auth48diff.html > > (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/rfc979 > >> > 3.xml__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_ > UH7k-L8 > >> 9VDPhD9qzA0k3V8croYABgvEEahFswRw1LTRkP4J_rg$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 > >> > 3.txt__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_ > UH7k-L8 > >> 9VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSvcMTvmQ$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 > >> > 3.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP > _UH7k-L > >> 89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTTO-THXdw$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 > >> > 3.pdf__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_ > UH7k-L8 > >> 9VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSFK2imLw$ > >> > >> 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_3Hi4QoiFsqpigGAB > MP_U > >> > H7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSpqctNWw$ (comprehens > ive > >> diff) > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 > >> > 3-auth48diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsq > pigG > >> > ABMP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTS_c4zfOg$ (AUTH > 48 > >> 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 > -L89VDPh > >> D9qzA0k3V8croYABgvEEahFswRw1LTRKxj6t8A$ > >> > >> 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/rfc97 > >>> 93 > >>> .xml__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABM > P_UH7k-L8 > >>> 9V DPhD9qzA0k3V8croYABgvEEahFswRw1LTRkP4J_rg$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > >>> 93 > >>> .txt__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABM > P_UH7k-L8 > >>> 9V DPhD9qzA0k3V8croYABgvEEahFswRw1LTSvcMTvmQ$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > >>> 93 > >>> .html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGAB > MP_UH7k-L > >>> 89 VDPhD9qzA0k3V8croYABgvEEahFswRw1LTTO-THXdw$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > >>> 93 > >>> .pdf__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABM > P_UH7k-L8 > >>> 9V DPhD9qzA0k3V8croYABgvEEahFswRw1LTSFK2imLw$ > >>> > >>> The relevant diff files have been posted here: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > >>> 93 > >>> > -diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGAB > MP_U > >>> H7 > k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSpqctNWw$ (comprehensive > >>> diff) > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > >>> 93 > >>> > -auth48diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqp > igG > >>> AB > 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/rfc979 > >>> 3_ > >>> > _;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k- > L89VDPh > >>> D9 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__;!!N > >>>> Et > >>>> > 6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mb > mmtftA > >>>> Pg 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!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UW > CbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_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!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIU > fYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_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/__;!!NEt6yMa > O-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtft > APg1aih3Jvh2GZMI2a16x_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__;!!NEt6y > MaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbm > mtftAPg1aih3Jvh2GZMI2a16x_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!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4 > mbmmtftAPg1aih3Jvh2GZMI2a16x_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/i > >>>> et > >>>> > f-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!BJ6v2FOBd8V > G > >>>> kY > >>>> > JHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a1 > 6x_qo > >>>> lL > >>>> qKqFy$ > >>>> > >>>> * The archive itself: > >>>> > >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/brows > >>>> e/ > >>>> > auth48archive/__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr4 > >>>> 6U 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/rfc9 > >>>> 79 > >>>> > 3.xml__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbn > U9e > >>>> 0r wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qokw_3RTt$ > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >>>> 79 > >>>> > 3.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbn > U9 > >>>> e0 rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qonasllh-$ > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >>>> 79 > >>>> > 3.pdf__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU > 9e > >>>> 0r wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qop-041dD$ > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >>>> 79 > >>>> > 3.txt__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU > 9e > >>>> 0r wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qouGvs8K2$ > >>>> > >>>> Diff file of the text: > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >>>> 79 > >>>> > 3-diff.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UW > >>>> Cb nU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qots0QlJN$ > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >>>> 79 > >>>> > 3-rfcdiff.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr4 > >>>> 6U > WCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qorEH-8sl$ (side by > >>>> side) > >>>> > >>>> Diff of the XML: > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >>>> 79 > >>>> > 3-xmldiff1.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr > >>>> 46 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/rfc97 > >>>> 93 > >>>> > __;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0r > wA4 > >>>> mb 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
