Hi, These updates are complete:
https://www.iana.org/assignments/bmp-parameters thanks, Amanda On Fri May 08 15:48:19 2026, [email protected] wrote: > IANA, > > We have some updates to communicate regarding the descriptions in the > registry at: > https://www.iana.org/assignments/bmp-parameters/bmp- > parameters.xhtml#statistics-types > > Please see the table in Section 8 of the following diff for the > changes: > https://www.rfc-editor.org/authors/rfc9972-diff.html > > For your convenience, the text file is viewable here: > https://www.rfc-editor.org/authors/rfc9972.txt > > Note: every description has at a least a small change (perhaps article > addition). > > We will await confirmation that the updates have been made prior to > moving this document forward in the publication process. > > Thank you. > > Megan Ferguson > RFC Production Center > > > On May 8, 2026, at 9:26 AM, linchangwang <[email protected]> > > wrote: > > > > Hi Megan, all, > > > > I approve the change. > > Thank you for your valuable work. > > > > Thanks, > > Changwang > > > > 发件人: Megan Ferguson <[email protected]> > > 发送时间: 2026年5月8日 23:07 > > 收件人: linchangwang (RD) <[email protected]>; Srivastava, > > Mukul <[email protected]>; > > [email protected]; [email protected] > > 抄送: [email protected]; [email protected]; rfc-editor@rfc- > > editor.org; [email protected]; [email protected]; > > [email protected] > > 主题: Re: AUTH48: RFC-to-be 9972 <draft-ietf-grow-bmp-bgp-rib-stats-17> > > for your review > > > > > > > > All, > > > > Thank you for your replies thus far. > > > > Changwang - Thank you for your careful review and sending along the > > updates. We have incorporated these changes into the files for you > > to verify. > > > > Jinming, Yisong, and Mukul - We believe your intent was to approve > > the current version of the document (but wanted to confirm as your > > messages addressed a single “change”). We have marked your AUTH48 > > status as “Approved”; if you do have further changes to submit or did > > not intend to approve the document, please let us know. Otherwise, > > please know that your approvals will stand even if further changes > > are submitted by a coauthor unless we hear objection at that time. > > > > Assuming the other authors approve, once we have approval from > > Changwang, we will contact IANA with any necessary updates to the > > registry to match the document prior to moving this document forward > > to publication. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9972.txt > > https://www.rfc-editor.org/authors/rfc9972.pdf > > https://www.rfc-editor.org/authors/rfc9972.html > > https://www.rfc-editor.org/authors/rfc9972.xml > > > > The diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9972-diff.html (Comprehensive) > > https://www.rfc-editor.org/authors/rfc9972-rfcdiff.html (same as > > above but side by side) https://www.rfc-editor.org/authors/rfc9972- > > auth48diff.html (AUTH48 changes only) https://www.rfc- > > editor.org/authors/rfc9972-auth48rfcdiff.html (side by side) > > > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9972 > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > > > > >> On May 8, 2026, at 5:27 AM, linchangwang > >> <[email protected]> wrote: > >> > >> Hi Megan, all, > >> > >> I approve the change. > >> > >> Few comments on the edited version: > >> > >> 1.The abbreviation ASN should be spelled out in full upon its first > >> occurrence. > >> > >> In "3.2. Adj-RIB-In RIB Monitoring Statistics Definition": > >> > >> OLD： > >> Type = 35: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-In invalidated after verifying the route origin ASN > >> through the Route Origin Authorization (ROA) of the Resource > >> Public Key Infrastructure (RPKI) [RFC6811]. This is the total > >> number of routes invalidated due to a mismatch of origin > >> Autonomous System Numbers (ASNs) and a mismatch of prefix > >> length. > >> NEW: > >> Type = 35: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-In invalidated after verifying the route origin > >> Autonomous System Number (ASN) > >> through the Route Origin Authorization (ROA) of the Resource > >> Public Key Infrastructure (RPKI) [RFC6811]. This is the total > >> number of routes invalidated due to a mismatch of origin > >> ASNs and a mismatch of prefix length. > >> > >> 2. Does the following one seem not to have been revised? > >> > >> 6) <!--[rfced] We see both "invalidated through the ROA of RPKI" for > >>> Types 35, 36, 41, and 42 in Section 3.2 and "invalidated after > >>> verifying route origin AS number through the ROA of RPKI" for the > >>> same types in Section 8. Please let us know if/how these should > >>> be made uniform. > >>> --> > >>> 【Changwang] Change it to be consistent with the definition of > >>> Section 8. > >> > >> OLD: > >> Type = 36: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-In validated by verifying the route origin ASN through > >> the > >> ROA of the RPKI [RFC6811]. > >> > >> NEW: > >> Type = 36: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-In validated after verifying the route origin ASN > >> through > >> the ROA of the RPKI [RFC6811]. > >> > >> OLD: > >> Type = 41: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-Out invalidated through the ROA of the RPKI [RFC6811]. > >> This is the total number of routes invalidated due to a mismatch > >> of origin ASNs and a mismatch of prefix lengths. > >> > >> NEW: > >> Type = 41: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-Out invalidated after verifying the route origin ASN > >> through the ROA of the RPKI [RFC6811]. This is the total number > >> of routes invalidated due to a mismatch of origin ASNs and a > >> mismatch of prefix lengths. > >> > >> OLD: > >> Type = 42: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-Out validated by verifying the route origin ASN through > >> the ROA of the RPKI [RFC6811]. > >> NEW: > >> Type = 42: (64-bit Gauge) > >> Current number of routes in the per-AFI/SAFI post-policy > >> Adj-RIB-Out validated after verifying the route origin ASN > >> through > >> the ROA of the RPKI [RFC6811]. > >> > >> > >> > >> Thanks, > >> Changwang > >> > >> > >> 发件人: Megan Ferguson <[email protected]> > >> 发送时间: 2026年5月8日 0:45 > >> 收件人: linchangwang (RD) <[email protected]>; > >> [email protected]; [email protected] > >> 抄送: [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected]; > >> [email protected]; Srivastava, Mukul > >> <[email protected]> > >> 主题: Re: [AD] AUTH48: RFC-to-be 9972 > >> <draft-ietf-grow-bmp-bgp-rib-stats-17> for your review > >> > >> > >> > >> All, > >> > >> *AD - please review and approve the removal of a BCP 14 keyword as > >> follows: > >> > >>>> > >>>> 7) <!--[rfced] Is there any issue with using both RECOMMENDED and > >>>> SHOULD > >>>> in the same sentence? > >>>> > >>>> Original: > >>>> ...it is RECOMMENDED that BMP producers capable of generating both > >>>> (Types 7 and 18) or (Types 9 and 19) BMP statistics SHOULD > >>>> transmit both corresponding types simultaneously. > >>>> > >>>> Perhaps: > >>>> ...it is RECOMMENDED that BMP producers capable of generating both > >>>> (Types 7 and 18) and (Types 9 and 19) BMP statistics transmit both > >>>> corresponding types simultaneously. > >>>> --> > >>>> > >>>> 【Changwang] I agree with the above modifications. > >> > >> > >> Changwang - Thank you for your reply and guidance. > >> > >> We have updated the files as requested and reposted them. We > >> believe all of our initial queries have been resolved and have > >> marked them as such on the this document’s AUTH48 status page (see > >> link below). > >> > >> Please review the files carefully as we do not make changes once > >> published as an RFC. > >> > >> We will await approvals of the document in its current form from > >> each of the parties listed at the AUTH48 status page prior to moving > >> the document forward in the publication process. > >> > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9972.txt > >> https://www.rfc-editor.org/authors/rfc9972.pdf > >> https://www.rfc-editor.org/authors/rfc9972.html > >> https://www.rfc-editor.org/authors/rfc9972.xml > >> > >> The diff files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9972-diff.html > >> (Comprehensive) > >> https://www.rfc-editor.org/authors/rfc9972-rfcdiff.html (same as > >> above but side by side) > >> https://www.rfc-editor.org/authors/rfc9972-auth48diff.html (AUTH48 > >> changes only) > >> https://www.rfc-editor.org/authors/rfc9972-auth48rfcdiff.html > >> (side > >> by side) > >> > >> The AUTH48 status page for this document is available here: > >> https://www.rfc-editor.org/auth48/rfc9972 > >> > >> Thank you. > >> > >> Megan Ferguson > >> RFC Production Center > >> > >> > >>> On May 7, 2026, at 9:48 AM, Srivastava, Mukul > >>> <[email protected]> wrote: > >>> > >>> I just want to support the feedback provided by Changing. > >>> I am in sync with the changes suggest. > >>> > >>> Thanks > >>> Mukul > >>> > >>> From: linchangwang (RD) <[email protected]> > >>> Date: Thursday, May 7, 2026 at 11:32 AM > >>> To: [email protected] <[email protected]>; > >>> Srivastava, Mukul <[email protected]>; > >>> [email protected] <[email protected]>; > >>> [email protected] <[email protected]> > >>> Cc: [email protected] <[email protected]>; [email protected] > >>> <[email protected]>; [email protected] <[email protected]>; > >>> [email protected] <[email protected]>; > >>> [email protected] <[email protected]> > >>> Subject: Re: AUTH48: RFC-to-be 9972 > >>> <draft-ietf-grow-bmp-bgp-rib-stats-17> for your review > >>> > >>> Hi, > >>> > >>> Thank you for your valuable feedback. > >>> For a detailed response, please see the reply below. > >>> > >>> Thanks, > >>> Changwang > >>> > >>> -----邮件原件----- > >>> 发件人: [email protected] <[email protected]> > >>> 发送时间: 2026年5月6日 20:15 > >>> 收件人: [email protected]; [email protected]; > >>> linchangwang > >>> (RD) <[email protected]>; [email protected] > >>> 抄送: [email protected]; [email protected]; > >>> [email protected]; [email protected]; > >>> [email protected]; [email protected] > >>> 主题: Re: AUTH48: RFC-to-be 9972 <draft-ietf-grow-bmp-bgp-rib-stats- > >>> 17> > >>> for your review > >>> > >>> > >>> > >>> Authors, > >>> > >>> While reviewing this document during AUTH48, please resolve (as > >>> necessary) the following questions, which are also in the source > >>> file. > >>> > >>> 1) <!--[rfced] We had the following questions about the Terminology > >>> section: > >>> > >>> a) We notice that some entries in the Terminology section include > >>> quotes from their defining documents while others do not. Should > >>> this be made uniform? > >>> > >>> [Changwang] Maintain consistency. Revise as follows: > >>> OLD: > >>> Post-policy Adj-RIB-In: As defined in Section 2 of [RFC7854]. > >>> > >>> NEW: > >>> Post-policy Adj-RIB-In: As defined in Section 2 of [RFC7854]: > >>> > >>> | The result of applying inbound policy to an Adj-RIB-In, but > >>> | prior to the application of route selection to form the Loc- > >>> | RIB. > >>> > >>> OLD: > >>> Pre-policy Adj-RIB-Out: As defined in Section 3 of [RFC8671]. > >>> > >>> Post-policy Adj-RIB-Out: As defined in Section 3 of [RFC8671]. > >>> > >>> NEW: > >>> Pre-policy Adj-RIB-Out: As defined in Section 3 of [RFC8671]: > >>> > >>> | The result before applying the outbound policy to an Adj-RIB- > >>> | Out. This normally would match what is in the local RIB. > >>> > >>> Post-policy Adj-RIB-Out: As defined in Section 3 of [RFC8671]: > >>> > >>> | The result of applying outbound policy to an Adj-RIB-Out. This > >>> | MUST convey to the BMP receiver what is actually transmitted to > >>> | the peer. > >>> > >>> OLD: > >>> Loc-RIB: As defined in Section 1.1 of [RFC4271]: > >>> > >>> | The Loc-RIB contains the routes that have been selected by the > >>> | local BGP speaker's Decision Process." Note that the Loc-RIB > >>> | state as monitored through BMP might also contain routes > >>> | imported from other routing protocols such as an IGP or local > >>> | static routes. > >>> NEW: > >>> Loc-RIB: As defined in Section 1.1 of [RFC4271]: > >>> > >>> | The Loc-RIB contains the routes that have been selected by the > >>> | local BGP speaker's Decision Process. > >>> > >>> Note that the Loc-RIB state as monitored through BMP might also > >>> contain routes imported from other routing protocols such as an > >>> IGP or local static routes. > >>> > >>> OLD: > >>> Route: As defined in Section 1.1 of [RFC4271]. > >>> NEW: > >>> Route: As defined in Section 1.1 of [RFC4271]: > >>> > >>> | A unit of information that pairs a set of destinations with the > >>> | attributes of a path to those destinations. > >>> > >>> > >>> b) We do not see any uses of Monitoring Station in this document. > >>> Please review if updates to the following text should be made. > >>> > >>> Original: > >>> The terms "Producer" and "Collector" are equivalent to "Monitored > >>> Router" and "Monitoring Station", respectively. > >>> > >>> --> > >>> [Changwang] Here it simply means that Collector is equivalent to > >>> Monitoring Station, without the need for a Monitoring Station to > >>> appear. No modifications are required. > >>> > >>> > >>> 2) <!--[rfced] Do uses of "per-" apply to both AFI and SAFI? Note > >>> that > >>> more instances occur throughout the document. > >>> 【Changwang] Yes, as described in RFC7854/RFC9069, it should be Per- > >>> AFI/SAFI. > >>> > >>> > >>> Note also that, for this instance, as AFI and SAFI are marked as > >>> well-known abbreviations, it may actually be easier for the reader > >>> if the expansions were removed: > >>> > >>> Original: > >>> ...Global Statistics and Per-Address Family Identifier > >>> (AFI)/Subsequent Address Family Identifier (SAFI) [RFC4760] > >>> Statistics. > >>> > >>> Perhaps: > >>> ...Global Statistics and Statistics per-AFI or per-SAFI (see > >>> [RFC4760]). > >>> > >>> --> > >>> 【Changwang] If directly abbreviated, it is recommended to change it > >>> to the following: > >>> NEW: > >>> ...Global Statistics and Per-AFI/SAFI [see RFC4760] Statistics. > >>> > >>> > >>> 3) <!--[rfced] Is the switch between singular and plural in these > >>> sentences intentional? > >>> > >>> a) a statistic vs. statistics > >>> > >>> Original: > >>> Both a Global Statistic and its corresponding Per-AFI/ SAFI > >>> Statistics can be reported simultaneously. > >>> > >>> Perhaps: > >>> Both Global Statistics and and their corresponding Per-AFI/ SAFI > >>> Statistics can be reported simultaneously. > >>> > >>> 【Changwang] I agree with the above modifications. > >>> > >>> b) AFI/SAFIs > >>> > >>> Original: > >>> The Per-AFI/SAFI Statistics apply only to the AFI/SAFIs that a BGP > >>> speaker supports and negotiates with its peer. > >>> > >>> Perhaps: > >>> The Per-AFI/SAFI Statistics apply only to the AFIs/SAFIs that a BGP > >>> speaker supports and negotiates with its peer. > >>> > >>> Note: even when not preceded by "Per", it may be beneficial to > >>> clarify the use of the slash character. Are these either/or > >>> relationships or and relationships? If it has a special meaning, > >>> it may be good to define AFI/SAFI in the Terminology section. > >>> --> > >>> > >>> 【Changwang] Please modify as follows: > >>> OLD: > >>> The Per-AFI/SAFI Statistics apply only to the AFI/SAFIs that a BGP > >>> speaker supports and negotiates with its peer. > >>> > >>> NEW: > >>> The Per-AFI/SAFI Statistics apply only to the AFI/SAFI that a BGP > >>> speaker supports and negotiates with its peer. > >>> > >>> > >>> 4) <!--[rfced] We plan to reformat the following text but have > >>> waited as > >>> there were so many uses, we felt it would clutter the diff file. > >>> > >>> Original: > >>> ...formatted as: 2-byte AFI, 1-byte SAFI, and a 64-bit Gauge. > >>> > >>> Perhaps: > >>> ...formatted as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge. > >>> > >>> Note that we will update the following similar use (many instances > >>> exist) to appear as above unless we hear objection. > >>> > >>> Original: > >>> The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a > >>> 64-bit Gauge. > >>> > >>> Perhaps: > >>> The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64- > >>> bit Gauge. > >>> --> > >>> > >>> 【Changwang] I agree with the above modifications. > >>> > >>> > >>> 5) <!--[rfced] Should the following update be made? > >>> > >>> Original: > >>> The stats type 0 is a 32-counter which is a monotonically > >>> increasing number... > >>> > >>> Perhaps: > >>> Stats type 0 is a 32-bit counter that is a monotonically increasing > >>> number... > >>> > >>> --> > >>> 【Changwang] I agree with the above modifications. > >>> > >>> 6) <!--[rfced] We see both "invalidated through the ROA of RPKI" > >>> for > >>> Types 35, 36, 41, and 42 in Section 3.2 and "invalidated after > >>> verifying route origin AS number through the ROA of RPKI" for > >>> the > >>> same types in Section 8. Please let us know if/how these should > >>> be made uniform. > >>> --> > >>> 【Changwang] Change it to be consistent with the definition of > >>> Section 8. > >>> > >>> > >>> 7) <!--[rfced] Is there any issue with using both RECOMMENDED and > >>> SHOULD > >>> in the same sentence? > >>> > >>> Original: > >>> ...it is RECOMMENDED that BMP producers capable of generating both > >>> (Types 7 and 18) or (Types 9 and 19) BMP statistics SHOULD transmit > >>> both corresponding types simultaneously. > >>> > >>> Perhaps: > >>> ...it is RECOMMENDED that BMP producers capable of generating both > >>> (Types 7 and 18) and (Types 9 and 19) BMP statistics transmit both > >>> corresponding types simultaneously. > >>> --> > >>> > >>> 【Changwang] I agree with the above modifications. > >>> > >>> 8) <!--[rfced] Please rephrase "absent policy otherwise" in the > >>> following: > >>> > >>> Original: > >>> For backward compatibility, and absent policy otherwise... > >>> > >>> Perhaps: > >>> For backward compatibility, and absent any other policy... > >>> --> > >>> 【Changwang] I agree with the above modifications. > >>> > >>> 9) <!--[rfced] This list is not of a parallel structure. How may > >>> we > >>> update? > >>> > >>> Original: > >>> To avoid adversely impacting the restart process, a BMP statistics > >>> producer MAY choose to sample this value at a lower frequency, > >>> buffer updates, or temporarily suspend reporting for this type > >>> during the most critical phases of a switchover. > >>> > >>> Perhaps: > >>> To avoid adversely impacting the restart process, a BMP statistics > >>> producer MAY choose to sample this value at a lower frequency, > >>> sample it at buffer updates, or temporarily suspend reporting for > >>> this type during the most critical phases of a switchover. > >>> > >>> --> > >>> [Changwang] "sample..., buffer..., or temporarily suspend..." > >>> NEW: > >>> To avoid adversely impacting the restart process, a BMP statistics > >>> producer MAY choose to sample this value at a lower frequency, > >>> buffer the updates, or temporarily suspend reporting for this type > >>> during the most critical phases of a switchover. > >>> > >>> > >>> 10) <!--[rfced] We had the following questions/comments related to > >>> the > >>> IANA Considerations section: > >>> > >>> a) We will communicate any updates to the descriptions of the Stat > >>> types to IANA upon the completion of AUTH48. > >>> [Changwang] Agreed. > >>> > >>> b) We will update the format of the list to instead appear as a > >>> table. > >>> We have kept as is for now in order to facilitate diff review. > >>> Please let us know any objections. > >>> > >>> --> > >>> [Changwang] Agreed. > >>> > >>> > >>> 11) <!-- [rfced] Would you like the references to be alphabetized > >>> or left > >>> in their current order? > >>> --> > >>> [Changwang] alphabetized. > >>> > >>> > >>> 12) <!--[rfced] We note that the following terms may be used > >>> inconsistently throughout the document. Please review these terms > >>> and let us know if/how they may be made consistent. > >>> > >>> Stat Type vs. stat type vs. stats type (note RFC 7854 does not use > >>> stats type) [Changwang] Stat Type. > >>> > >>> BMP Statistics Report Message vs. BMP statistics message > >>> [Changwang] > >>> BMP Statistics Report message. > >>> > >>> Statistic vs. statistic (when used by itself) [Changwang] > >>> statistic. > >>> > >>> Gauge vs. gauge > >>> [Changwang] Gauge. > >>> > >>> Type vs. type (e.g., Type 27 vs. type 27) [Changwang] Type 27. > >>> > >>> statistic type vs. statistics types (various casing) - singular or > >>> plural? > >>> --> > >>> [Changwang] statistics types. > >>> > >>> > >>> 13) <!--[rfced] We had the following questions related to > >>> abbreviation use throughout the document: > >>> > >>> a) We see several instances of AS number. May we make these ASN > >>> instead (for Autonomous System Number)? > >>> > >>> --> > >>> [Changwang] Agreed, please make the changes uniformly. > >>> > >>> 14) <!-- [rfced] Please review the "Inclusive Language" portion of > >>> the > >>> online Style Guide > >>> <https://www.rfc- > >>> editor.org/styleguide/part2/#inclusive_language> > >>> 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. > >>> --> > >>> [Changwang] Reviewed, no modifications needed. > >>> > >>> > >>> Thank you. > >>> > >>> Megan Ferguson > >>> RFC Production Center > >>> > >>> *****IMPORTANT***** > >>> > >>> Updated 2026/05/06 > >>> > >>> 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://www.rfc-editor.org/faq/). > >>> > >>> 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 – https://trustee.ietf.org/license-info). > >>> > >>> * 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://authors.ietf.org/rfcxml-vocabulary>. > >>> > >>> * 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 ‘REPLY ALL’ as > >>> all the parties CCed on this message need to see your changes. The > >>> parties > >>> include: > >>> > >>> * your coauthors > >>> > >>> * [email protected] (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). > >>> > >>> * [email protected], which is a new archival mailing > >>> list > >>> to preserve AUTH48 conversations; it is not an active discussion > >>> list: > >>> > >>> * More info: > >>> > >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- > >>> 4Q9l2USx > >>> I > >>> Ae6P8O4Zc > >>> > >>> * The archive itself: > >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>> > >>> * 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, > >>> [email protected] 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 > >>> — OR — > >>> 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 > >>> ‘REPLY ALL’, as all the parties CCed on this message need to see > >>> your approval. > >>> > >>> > >>> Files > >>> ----- > >>> > >>> The files are available here: > >>> https://www.rfc-editor.org/authors/rfc9972.xml > >>> https://www.rfc-editor.org/authors/rfc9972.html > >>> https://www.rfc-editor.org/authors/rfc9972.pdf > >>> https://www.rfc-editor.org/authors/rfc9972.txt > >>> > >>> Diff file of the text: > >>> https://www.rfc-editor.org/authors/rfc9972-diff.html > >>> https://www.rfc-editor.org/authors/rfc9972-rfcdiff.html (side by > >>> side) > >>> > >>> Diff of the XML: > >>> https://www.rfc-editor.org/authors/rfc9972-xmldiff1.html > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> https://www.rfc-editor.org/auth48/rfc9972 > >>> > >>> Please let us know if you have any questions. > >>> > >>> Thank you for your cooperation, > >>> > >>> RFC Editor > >>> > >>> -------------------------------------- > >>> RFC9972 (draft-ietf-grow-bmp-bgp-rib-stats-17) > >>> > >>> Title : Advanced BGP Monitoring Protocol (BMP) > >>> Statistics Types > >>> Author(s) : M. Srivastava, Ed., Y. Liu, C. Lin, Ed., J. Li > >>> WG Chair(s) : Paolo Lucente, Job Snijders > >>> > >>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani > >>> > >>> > >>> --------------------------------------------------------------------- > >>> - > >>> --------------------------------------------------------------- > >>> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 > >>> 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 > >>> 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > >>> This e-mail and its attachments contain confidential information > >>> from New H3C, which is intended only for the person or entity whose > >>> address is listed above. > >>> Any use of the information contained herein in any way (including, > >>> but not limited to, total or partial disclosure, reproduction, or > >>> dissemination) by persons other than the intended recipient(s) is > >>> prohibited. > >>> If you receive this e-mail in error, please notify the sender by > >>> phone or email immediately and delete it! > >> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
