[auth48] Re: Final review: RFC-to-be 10005 (draft-ietf-idr-link-bandwidth-24) in XML

["Das, Reshma" <[e-mail]>]

Hi Alice,

The latest diff and the edits look good to me.

Thanks & Regards,
Reshma Das


Get Outlook for Mac <https://aka.ms/GetOutlookForMac>
From: Alice Russo <[e-mail]>
Date: Wednesday, June 17, 2026 at 12:05 PM
To: Serge Krier (sekrier) <[e-mail]>, Das, Reshma <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, RFC Editor <[e-mail]>
Subject: Re: Final review: RFC-to-be 10005 (draft-ietf-idr-link-bandwidth-24) in XML

Serge, Reshma, Rafal,

This is a reminder that we await your approval of this document's readiness for publication as an RFC. Please let us know if any further changes are needed.The files are here:

  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzUU9bGbA$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.pdf__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukwgl980Sw$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.txt__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhuky9qJll6w$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.xml__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzIL6Xs7w$  (source)

Diff files of all changes from the approved Internet-Draft:
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-diff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukxpIHdW_g$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-rfcdiff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzJXtwXMQ$  (side by side)

Diff file of Final Review changes only:
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-auth48rfcdiff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzD09SpBQ$

This page shows the Final Review status of your document:
  https://urldefense.com/v3/__https://queue.rfc-editor.org/final-review/rfc10005__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukyZgqw5Iw$

Thank you.

Alice Russo
RFC Production Center


> On Jun 8, 2026, at 3:12 PM, Serge Krier (sekrier) <[e-mail]> wrote:
>
>
> Thanks Alice, I will comment/ack by tomorrow.
>
> Regards
>
>
> From: Alice Russo <[e-mail]>
> Date: Monday, 8 June 2026 at 20:03
> To: Das, Reshma <reshma.das=[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Serge Krier (sekrier) <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; RFC Editor <[e-mail]>
> Subject: Re: Final review: RFC-to-be 10005 (draft-ietf-idr-link-bandwidth-24) in XML
>
> Reshma,
>
> Thank you for your reply. The revised files are here (please refresh):
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzUU9bGbA$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.txt__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhuky9qJll6w$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.pdf__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukwgl980Sw$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005.xml__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzIL6Xs7w$
>
> This diff file shows all changes from the approved I-D:
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-diff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukxpIHdW_g$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-rfcdiff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzJXtwXMQ$  (side by side)
>
> This diff file shows the changes made during AUTH48 thus far:
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-auth48diff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzMgHY2nw$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc10005-auth48rfcdiff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukzD09SpBQ$  (side by side)
>
> Re: #1
> We await word from Pradosh on this.
>
>
> Re: #6
> > RD> It would be good to retained  this section to provide useful context on
> > the evolution of the LBWC and its impact on interoperability.
>
>
> Ack; Appendix A remains as is.
>
>
> Re: #7b
> > RD> Adj-RIB-In" and "Adj-RIB-Out" are defined in [RFC 4271],
> > may be we can add a definition referring to the same.
>
> Added a sentence in Section 3.1 and a normative reference to RFC 4271; please let us know if you prefer otherwise.
>
>
> Re: #8
> > RD> [...] In particular, the use of "tradition" is intended to convey established practice, and its meaning is clear in context.
>
> Ack.
>
> FYI, we updated the sentence to remove the word 'routing' as the original phrase 'Traditional equal load-balancing routing' reads oddly. The phrase 'equal load-balancing' is used in RFC 8431 for example.
>
> Original:
>    Traditional equal load-balancing routing does not
>    account for the varying capacities of different paths.
>
> Current:
>    Traditional equal load-balancing does not
>    account for the varying capacities of different paths.
>
> Perhaps (if "routing" is significant here):
>    In routing, conventional equal load-balancing does not
>    account for the varying capacities of different paths.
>
>
> We will wait to hear from you again and from your coauthors
> before continuing the publication process. This page shows
> the Final Review status of your document:
>   https://urldefense.com/v3/__https://queue.rfc-editor.org/final-review/rfc10005/__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukwd2UtxcA$
>
> Thank you.
>
> Alice Russo
> RFC Production Center
>
> > On Jun 4, 2026, at 5:24 PM, Das, Reshma <reshma.das=[e-mail]> wrote:
> >
> > Hi RFC Editors,
> >
> > Thank you for reviewing and editing the document. I have gone through the diff (https://urldefense.com/v3/__https://auth48-transition.rfc-editor.org/authors/rfc10005-diff.html__;!!NpxR!nHEGa-dSpXh6zrWoKoan73ledF4vaA0j70LhQg2dhKQnl29phuymGKaABVu9YiTb2vk08fzHZrJhukwDMjXSQQ$ ), and the changes look good.
> >
> > Please find my other comments inline (RD>).
> >
> > Thanks & Regards,
> > Reshma Das
> >
> >
> > Get Outlook for Mac
> > From: [e-mail] <[e-mail]>
> > Date: Monday, June 1, 2026 at 3:54 PM
> > To: [...]
> > Subject: Re: Final review: RFC-to-be 10005 (draft-ietf-idr-link-bandwidth-24) in XML
> >
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
> >
> > 1) <!--[rfced] Pradosh, we note that your email address in this document
> > does not match your email address in the Datatracker. Please let us know
> > which one you prefer within the RFC, and please consider updating
> > your Datatracker account if it's not that one.
> >
> >   This Document: [e-mail]
> > —>
> >
> > RD>I had updated this as per Pradosh’s request. I will let him also confirm this.
> >
> > 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__;!!NpxR!kADhD5efgy5ovW-4_71togTd7OHPLdHdLb6Zry9FdywhHmTJmKaohaJsRquRVNABhfx6Tc135z27EC1QBrz4og$ . -->
> >
> >
> > 3) <!-- [rfced] In the text below, what does "connecting to a remote network"
> > refer to? How may we clarify?
> >
> > Original:
> >    The Link Bandwidth Extended Community is defined as a BGP extended
> >    community that carries the bandwidth information of a router,
> >    represented by BGP Next Hop, connecting to a remote network.
> >
> > Perhaps:
> >    The Link Bandwidth Extended Community is defined as a BGP extended
> >    community that carries the bandwidth information of a router
> >    (represented by BGP next hop) and connects to a remote network.
> >
> > Or:
> >    The Link Bandwidth Extended Community is defined as a BGP extended
> >    community that carries the bandwidth information of a router
> >    (represented by BGP Next Hop) that is connecting to a remote network.
> > —>
> >
> > RD> The second option looks good:
> > "   The Link Bandwidth Extended Community is defined as a BGP extended
> >    community that carries the bandwidth information of a router
> >    (represented by BGP Next Hop) that is connecting to a remote network.”
> >
> >
> > 4) <!-- [rfced] May we adjust this text for readability? Specifically,
> > may we move "inconsistent behavior could ..." to the beginning of
> > the first sentence, and add "so then" to the second sentence?
> >
> > Original:
> >    In circumstances where networks have deployed a mixture of
> >    implementations supporting this document's procedures for both
> >    transitivity types, and older implementations that only understand
> >    one transitivity type, inconsistent behavior could result.  A prime
> >    example is when a route received by a BGP speaker contains both a
> >    transitive and a non-transitive Link Bandwidth Extended Community and
> >    that BGP speaker performs an operation that updates only one of the
> >    Link Bandwidth Extended Communities, the other community may have an
> >    inconsistent value.  As a result, downstream BGP speakers that may
> >    receive such routes may perform inappropriate weighted load
> >    balancing.
> >
> > Perhaps:
> >    Inconsistent behavior could occur when networks have deployed a mixture
> >    of implementations supporting this document's procedures for both
> >    transitivity types, or have deployed older implementations that only
> >    understand one transitivity type.  A prime example is when a route
> >    received by a BGP speaker contains both a transitive and a
> >    non-transitive Link Bandwidth Extended Community, and that BGP speaker
> >    performs an operation that updates only one of the Link Bandwidth
> >    Extended Communities, so then the other community may have an inconsistent
> >    value.  As a result, downstream BGP speakers that may
> >    receive such routes may perform inappropriate weighted load
> >    balancing.
> > —>
> >
> > RD> Ack, This change is good.
> >
> > 5) <!-- [rfced] What is meant to be "filtered" in the text below? May we adjust
> > as follows to clarify?
> >
> > Original:
> >    One option would be to filter either at advertisement time on the older BGP
> >    speaker the unsupported transitivity type of Link Bandwidth Extended
> >    Community - if the implementation is capable of such filtering.
> >
> > Perhaps:
> >    One option would be to filter the unsupported transitivity type of the
> >    Link Bandwidth Extended Community at advertisement time on the older BGP
> >    speaker, if the implementation is capable of such filtering.
> > —>
> > RD> Ack, This change is good.
> >
> >
> > 6) <!--[rfced] Is Appendix A (Document History), which describes an
> > intentional change between draft versions, needed in the RFC? Seems
> > this was relevant as the draft was undergoing revision; is it relevant
> > in the RFC?
> >
> > Current:
> > Appendix A.  Document History
> >
> >    The BGP Link Bandwidth Extended Community has evolved over several
> >    versions of the IETF draft.  In the earlier versions up to draft-
> >    ietf-idr-link-bandwidth-08, only the non-transitive version of the
> >    Link Bandwidth Extended Community was supported.  However, starting
> >    from draft-ietf-idr-link-bandwidth-09, both transitive and non-
> >    transitive versions of the Link Bandwidth Extended Community are
> >    supported.
> >
> >    A BGP speaker (sender or receiver) needs to be upgraded to support
> >    the procedures defined in this document to provide full
> >    interoperability for both transitive and non-transitive versions of
> >    the Link Bandwidth Extended Community.  In order to simplify
> >    implementations, it is not a goal to provide interoperability by
> >    upgrading only the Route Reflector (RR).
> > —>
> >
> > RD> It would be good to retained  this section to provide useful context on
> > the evolution of the LBWC and its impact on interoperability.
> >
> >
> > 7) <!-- [rfced] Please review the following questions and changes regarding the
> > abbreviations used in this document:
> >
> > a) We note the following different uses of the term below. We have updated the
> > first instance in this document to "Autonomous System Number (ASN)", and we
> > have updated all instances after to use the abbreviation "ASN".
> > Please review these changes for accuracy.
> >
> > Autonomous System (AS) number
> > Autonomous System number
> > ASNs
> > AS number
> >
> > RD> ACK.
> >
> > b) We note that "Local-RIB" is expanded as "Local Routing Information Base
> > (Local-RIB)". Should the abbreviations below also be expanded or should a
> > definition be referenced?
> >
> > Adj-RIB-In
> > Adj-RIB-Out
> >
> > RD> Adj-RIB-In" and "Adj-RIB-Out" are defined in [RFC 4271],
> > may be we can add a definition referring to the same.
> >
> >
> >
> > c) We have added expansions for abbreviations upon first use
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> >
> > Route Reflector (RR)
> > —>
> >
> > RD> ACK
> >
> > 8) <!-- [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!!NpxR!kADhD5efgy5ovW-4_71togTd7OHPLdHdLb6Zry9FdywhHmTJmKaohaJsRquRVNABhfx6Tc135z27EC3mHc6evQ$ >
> > and let us know if any changes are needed.  Updates of this nature typically
> > result in more precise language, which is helpful for readers.
> >
> > For example, please consider whether "tradition" should be updated for clarity.
> > While the NIST website
> > <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/*www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1__;LyM!!NpxR!kADhD5efgy5ovW-4_71togTd7OHPLdHdLb6Zry9FdywhHmTJmKaohaJsRquRVNABhfx6Tc135z27EC3hobiVjQ$ >
> > indicates that this term is potentially biased, it is also ambiguous.
> > "Tradition" is a subjective term, as it is not the same for everyone.
> >
> > Original:
> >   Traditional equal load-balancing routing does not account for...
> > —>
> >
> > RD> I have reviewed the Inclusive Language guidance and do not believe any changes are needed.
> > In particular, the use of "tradition" is intended to convey established practice, and its meaning is clear in context.
> >
> >
> > Thank you.
> >
> > Kaelin Foody and Alice Russo
> > RFC Production Center
>