Hi RFC Editors I have reviewed the latest diff and the edits look good to me.
Thanks On Tue, Jun 9, 2026 at 7:33 AM Satya Mohanty <[email protected]> wrote: > Hi RFC Editors, > > Thank you for reviewing the document and the edits. I have gone through > the diff ( > https://auth48-transition.rfc-editor.org/authors/rfc10005-diff.html). The > changes > look good. > > Thanks, > Satya > > On Mon, Jun 8, 2026 at 3:13 PM Serge Krier (sekrier) <[email protected]> > wrote: > >> >> Thanks Alice, I will comment/ack by tomorrow. >> >> Regards >> >> >> *From: *Alice Russo <[email protected]> >> *Date: *Monday, 8 June 2026 at 20:03 >> *To: *Das, Reshma <[email protected]> >> *Cc: *[email protected] <[email protected]>; >> [email protected] <[email protected]>; Serge Krier (sekrier) < >> [email protected]>; [email protected] <[email protected]>; >> [email protected] <[email protected]>; [email protected] < >> [email protected]>; [email protected] <[email protected]>; [email protected] >> <[email protected]>; [email protected] <[email protected]>; >> [email protected] <[email protected]>; RFC Editor < >> [email protected]> >> *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://www.rfc-editor.org/authors/rfc10005.html >> https://www.rfc-editor.org/authors/rfc10005.txt >> https://www.rfc-editor.org/authors/rfc10005.pdf >> https://www.rfc-editor.org/authors/rfc10005.xml >> >> This diff file shows all changes from the approved I-D: >> https://www.rfc-editor.org/authors/rfc10005-diff.html >> https://www.rfc-editor.org/authors/rfc10005-rfcdiff.html (side by side) >> >> This diff file shows the changes made during AUTH48 thus far: >> https://www.rfc-editor.org/authors/rfc10005-auth48diff.html >> https://www.rfc-editor.org/authors/rfc10005-auth48rfcdiff.html (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://queue.rfc-editor.org/final-review/rfc10005/ >> >> Thank you. >> >> Alice Russo >> RFC Production Center >> >> > On Jun 4, 2026, at 5:24 PM, Das, Reshma <reshma.das= >> [email protected]> wrote: >> > >> > Hi RFC Editors, >> > >> > Thank you for reviewing and editing the document. I have gone through >> the diff ( >> https://auth48-transition.rfc-editor.org/authors/rfc10005-diff.html), >> and the changes look good. >> > >> > Please find my other comments inline (RD>). >> > >> > Thanks & Regards, >> > Reshma Das >> > >> > >> > Get Outlook for Mac >> > From: [email protected] <[email protected]> >> > 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: [email protected] >> > —> >> > >> > 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 >> >> > > This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system.
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
