Hi Megan, Updated 35 and 41:
https://www.iana.org/assignments/bmp-parameters thanks, Amanda On Wed May 13 00:12:27 2026, [email protected] wrote: > Hi Amanda, > > It looks like Mukul has added two further changes that still need to > be incorporated. Otherwise, all of the updates look good. Please let > us know when these two changes have been made. > > Original: > 35: Number of routes currently in the per-AFI/SAFI post- > policy Adj-RIB-In invalidated after verifying the > route origin ASN through the ROA of the RPKI. > > New (add “and mismatch of prefix length” to the end): > 35: Number of routes currently in the per-AFI/SAFI post- > policy Adj-RIB-In invalidated after verifying the > route origin ASN through the ROA of the RPKI and mismatch of prefix > length. > > Original: > 41: Number of routes currently in the per-AFI/SAFI post- > policy Adj-RIB-Out invalidated after verifying the > route origin ASN through the ROA of the RPKI. > > New (add “and mismatch of prefix length” to the end): > 41: Number of routes currently in the per-AFI/SAFI post- > policy Adj-RIB-Out invalidated after verifying the > route origin ASN through the ROA of the RPKI and mismatch of prefix > length. > > This brings the descriptions more in-line with those that appear in > Section 3.2. > > These updates have been incorporated into the document, viewable > below: > > 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) > > https://www.rfc-editor.org/authors/rfc9972-lastdiff.html (last version > to this) > https://www.rfc-editor.org/authors/rfc9972-lastrfcdiff.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 12, 2026, at 1:24 PM, Amanda Baber via RT <iana- > > [email protected]> wrote: > > > > 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]
