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/rfc9793.xml__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTRkP4J_rg$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.txt__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSvcMTvmQ$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTTO-THXdw$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793.pdf__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSFK2imLw$ >> >> >> 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_UH7k-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTSpqctNWw$ >> (comprehensive diff) >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9793-auth48diff.html__;!!NEt6yMaO-gk!HcMPo3GfNKhUuDWZ9KLz_3Hi4QoiFsqpigGABMP_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-L89VDPhD9qzA0k3V8croYABgvEEahFswRw1LTRKxj6t8A$ >> >> >> 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/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) >>> >>> 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-L89VDPhD9 >>> 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__;!!NEt >>>> 6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg >>>> 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/iet >>>> f-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkY >>>> JHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qolL >>>> qKqFy$ >>>> >>>> * The archive itself: >>>> >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ >>>> auth48archive/__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46U >>>> 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/rfc979 >>>> 3.xml__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0r >>>> wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qokw_3RTt$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0 >>>> rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qonasllh-$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3.pdf__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0r >>>> wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qop-041dD$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3.txt__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0r >>>> wA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qouGvs8K2$ >>>> >>>> Diff file of the text: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3-diff.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCb >>>> nU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qots0QlJN$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3-rfcdiff.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46U >>>> WCbnU9e0rwA4mbmmtftAPg1aih3Jvh2GZMI2a16x_qorEH-8sl$ (side by side) >>>> >>>> Diff of the XML: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc979 >>>> 3-xmldiff1.html__;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46 >>>> 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/rfc9793 >>>> __;!!NEt6yMaO-gk!BJ6v2FOBd8VGkYJHlaHgnjGegvKzbIUfYyr46UWCbnU9e0rwA4mb >>>> 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
