Hi William, Thanks for your review. We have noted your approval accordingly (see https://www.rfc-editor.org/auth48/rfc9843).
We now await approvals from Peter and Rajesh prior to starting the publication process. Best regards, Karen Moore RFC Production Center > On Sep 5, 2025, at 11:20 AM, William Britto A J <[email protected]> wrote: > > Hi Karen, > > Changes look good to me. I approve for publication. > > Thanks, > William > > Get Outlook for Mac > > Juniper Business Use Only > > From: Tony Li <[email protected]> on behalf of Tony Li <[email protected]> > Date: Friday, 5 September 2025 at 21:07 > To: Shraddha Hegde <[email protected]> > Cc: Karen Moore <[email protected]>, Gunter Van De Velde (Nokia - > BE/Antwerp) <[email protected]>, Bruno Decraene > <[email protected]>, William Britto A J <[email protected]>, > Rajesh M <[email protected]>, Peter Psenak <[email protected]>, > [email protected] <[email protected]>, lsr-chairs <[email protected]>, Acee > Lindem (acee) <[email protected]>, RFC Errata System > <[email protected]>, [email protected] > <[email protected]> > Subject: Re: [AD] AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw-con-22> > for your review > > [External Email. Be cautious of content] > > > Hi Karen, > > I concur. Ship it! > > T > > > > On Sep 5, 2025, at 8:29 AM, Shraddha Hegde <[email protected]> wrote: > > > > Hi Karen, > > > > Changes look good. I approve for publication. > > > > Rgds > > Shraddha > > > > > > Juniper Business Use Only > > -----Original Message----- > > From: Shraddha Hegde <[email protected]> > > Sent: 05 September 2025 00:55 > > To: [email protected]; [email protected]; William > > Britto A J <[email protected]>; [email protected]; Shraddha Hegde > > <[email protected]>; Rajesh M <[email protected]>; [email protected] > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected] > > Subject: [AD] Re: AUTH48: RFC-to-be 9843 > > <draft-ietf-lsr-flex-algo-bw-con-22> for your review > > > > [External Email. Be cautious of content] > > > > > > Dear Bruno, Shraddha, and *Gunter (AD), > > > > As requested, we have updated the first column of the "OSPF Flexible > > Algorithm Definition TLV Sub-TLVs” registry from “Bit Number” to “Type” (in > > Section 10.3) and have asked IANA to update their registry accordingly per > > agreement with Acee. We have also marked Bruno’s approval of the document > > on the AUTH48 status page for this document. Note that we will await each > > author's approval prior to moving forward with publication. > > > > *Gunter, please review the updates in the Abstract and Sections 2, 2.1, > > 2.2, 3, 3.1.2, 3.2.2, 4.1.3.1, 4.1.3.2, 4.1.4.1, and 4.1.4.2 and let us > > know if you approve. A summary of the updates are shown below for ease; > > please review the actual updates at > > "https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofznwurpfE$ > > ”. > > > > a) The Updates tag was added to the header as well as the following text to > > the last sentence of the Abstract: > > > > Current: > > This document updates RFC 9350. > > > > ... > > b) Section 2 > > > > OLD: > > Implementations MUST support sending and receiving generic metric > > sub-TLV in Application Specific Link Attributes (ASLA) encodings as > > well as in the TLV 22/extended link LSA/TE-LSAs. > > > > NEW: > > Implementations MUST support sending and receiving a Generic Metric > > sub-TLV in Application-Specific Link Attributes (ASLA) encodings as > > well as in TLV 22 and extended Link Opaque Link State Advertisements > > (LSAs) [RFC7684] and TE-LSAs. > > > > ... > > c) Section 2.1 > > > > Removed text: > > The Generic Metric sub-TLV, type 17, is 6 octets in length. > > > > Rationale: > > [BD]: I feel that indicating both a length of 6 and a length of 4 may be > > misleading. Also looking in other RFC (e.g., 8570) it seems that the length > > always refers to value of the Length field. > > > > ... > > d) Section 3 > > > > OLD: > > If the capacity of a link is constant, this can already be achieved > > through the use of administrative groups. > > > > NEW: > > If the capacity of a low bandwidth link is constant, constraining the > > topology to avoid those links can already be achieved through the use > > of administrative groups. > > > > ... > > e) Section 3.1.2: > > In Figure 4, the "Max Link Delay" field was updated to 24 bits > > (instead of 23 bits). > > > > ... > > f) Sections 4.1.3.1, 4.1.3.2, 4.1.4.1, and 4.1.4.2 > > > > OLD: > > Unassigned bits MUST be set to zero. > > > > NEW: > > Unassigned bits MUST be set to zero and MUST be ignored by the receiver. > > > > ... > > g) Sections 2.2 and 3.2.2 > > > > OLD: > > Must be set to zero by the sender and must be ignored by the receiver. > > > > NEW: > > MUST be set to zero by the sender and MUST be ignored > > by the receiver. > > > > > > --Files (please refresh)-- > > > > Updated XML file: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.xml__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzpj-EEbz$ > > > > Updated output files: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzvkVvjsv$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzkKHkjtG$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzhz1HgF6$ > > > > Diff files showing all changes made during AUTH48: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofznwurpfE$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzrBd7OBS$ > > (side by side) > > > > Diff files showing only the last round of changes: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzvAUAB5Y$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofztinNqqm$ > > (side by side) > > > > Diff files showing all changes: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzpOdZfZV$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzsj7CGKl$ > > (side by side) > > > > For the AUTH48 status of this document, please see: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9843__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzsL1xajX$ > > > > Best regards, > > > > Karen Moore > > RFC Production Center > > > > > >> On Sep 3, 2025, at 12:14 AM, [email protected] wrote: > >> > >> Hi Karen, > >> > >> Thanks. > >> Changes looks good. > >> > >> I approve publication. > >> > >> > >> --Bruno > >> -----Original Message----- > >> From: Karen Moore <[email protected]> > >> Sent: Wednesday, September 3, 2025 3:54 AM > >> To: DECRAENE Bruno INNOV/NET <[email protected]>; Rajesh M > >> <[email protected]>; [email protected]; William Britto A J > >> <[email protected]>; Shraddha Hegde <[email protected]>; > >> [email protected] > >> Cc: [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected] > >> Subject: Re: AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw-con-22> > >> for your review > >> > >> -------------------------------------------------------------------------------------------------------------- > >> CAUTION : This email originated outside the company. Do not click on any > >> links or open attachments unless you are expecting them from the sender.. > >> > >> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez > >> pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre > >> l'expéditeur. > >> -------------------------------------------------------------------------------------------------------------- > >> > >> Hi Bruno, > >> > >> Thank you for the review and suggested changes. We have updated our files > >> accordingly. Please review and let us know if any further updates are > >> needed or if you approve the document in its current form. Note the > >> following: > >> > >> 1) We made the following updates in Sections 4.1.4.1 and 4.1.4.2 to match > >> the entries in Sections 4.1.3.1 and 4.1.3.2. If these updates are not > >> correct, please let us know. > >> > >> Should the G-flag entry in Section 4.1.3.1 be indented to match the other > >> entries? > >> > >> OLD: > >> Unassigned bits MUST be set to zero. > >> > >> NEW: > >> Unassigned bits MUST be set to zero and MUST be ignored by the receiver. > >> > >> ... > >> 2) For consistency with other instances of "N" and to match Figure 9, we > >> made the following updates in Section 4.1.3.2. If these instances are not > >> correct, please let us know. > >> > >> OLD: > >> Bandwidth Threshold n (4 octets): > >> > >> Threshold Metric n (3 octets): > >> > >> NEW: > >> Bandwidth Threshold N (4 octets): > >> > >> Threshold Metric N (3 octets): > >> > >> 3) In Section 2.2, we updated one instance of "eight octets" to "8 octets" > >> for consistency. > >> > >> NEW: > >> The Generic Metric sub-TLV, types 25/36/34, is 8 octets in length. > >> > >> > >> -Files (please refresh)- > >> > >> Updated XML file: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.xml__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzpj-EEbz$ > >> > >> Updated output files: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzvkVvjsv$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzkKHkjtG$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzhz1HgF6$ > >> > >> Diff files showing all changes made during AUTH48: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofznwurpfE$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzrBd7OBS$ > >> (side by side) > >> > >> Diff files showing only the last round of changes: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzvAUAB5Y$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofztinNqqm$ > >> (side by side) > >> > >> Diff files showing all changes: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzpOdZfZV$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzsj7CGKl$ > >> (side by side) > >> > >> For the AUTH48 status of this document, please see: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9843__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzsL1xajX$ > >> > >> We will await each author's approval prior to moving forward with > >> publication. > >> > >> Best regards, > >> > >> Karen Moore > >> RFC Production Center > >> > >>> On Sep 1, 2025, at 7:30 AM, [email protected] wrote: > >>> > >>> Hi Karen, all > >>> > >>> Thanks for the work. > >>> I've reviewed the latest version. > >>> Please find below some proposed comments/changes > >>> > >>> §1 > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html*name-introduction__;Iw!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoqRq7Oc$ > >>> > >>> May be, to be consistent with previous (section 3) and subsequent > >>> (section 4.1) sentences: > >>> > >>> OLD: In Section 4, this document specifies a new bandwidth-based > >>> metric-type to be used with Flex-Algorithm and other applications. > >>> > >>> NEW: <CR> > >>> Section 4 specifies a new bandwidth-based metric-type to be used with > >>> Flex-Algorithm and other applications. > >>> > >>> ---- > >>> §2 > >>> May be > >>> > >>> OLD: This document further specifies a user-defined metric-type space of > >>> metric-types 128-255. These are user defined and can be assigned by an > >>> operator for local use. > >>> NEW: This document further specifies a user-defined metric-type space of > >>> metric-types 128-255. They can be assigned by an operator for local use. > >>> > >>> (The two "user-defined" seem redundant and read as repetitive) > >>> > >>> --- > >>> §2.1 > >>> > >>> OLD: The Generic Metric sub-TLV, type 17, is 6 octets in length. > >>> [...] > >>> OLD: Length (1 octet): > >>> An 8-bit field indicating the total length, in octets, of the subsequent > >>> fields. For this TLV, the Length is set to 4. > >>> > >>> > >>> I feel that indicating both a length of 6 and a length of 4 may be > >>> misleading. Also looking in other RFC (e.g., 8570) it seems that the > >>> length always refers to value of the Length field. > >>> > >>> I would suggest to remove the first sentence: > >>> > >>> OLD: The Generic Metric sub-TLV, type 17, is 6 octets in length. > >>> NEW: <blank> > >>> > >>> --- > >>> §3.1.2 > >>> In Figure 4, the "Max Link Delay" field has 23 bits. It should have 24 > >>> bits. > >>> > >>> ---- > >>> §4.1.3.2 > >>> > >>> OLD: For this sub-TLV, the Length is calculated as (1+n*7). Here, N is > >>> equal to the number of Threshold Metrics specified. n MUST be greater > >>> than or equal to 1. > >>> NEW: For this sub-TLV, the Length is calculated as (1+N*7). Here, N is > >>> equal to the number of Threshold Metrics specified. N MUST be greater > >>> than or equal to 1. > >>> > >>> > >>> (there is a mixture of "n" and "N" to represent the same variable) > >>> > >>> I'm proposing "N" rather than "n" as the rest of this section uses "N" > >>> and §4.1.4.2 (OSPF counterpart) also uses "N". > >>> > >>> ---- > >>> §4.1.3.1 > >>> AND > >>> §4.1.3.2 > >>> > >>> OLD: Unassigned bits MUST be set to zero. > >>> NEW: Unassigned bits MUST be set to zero and MUST be ignored by the > >>> receiver. > >>> > >>> (*2) > >>> > >>> Note that for those MBZ statements, the document sometimes uses "must" > >>> and sometimes "MUST". I would assume that consistency would be better. My > >>> preference would be MUST as this is an interop consideration. > >>> > >>> --- > >>> §5 > >>> OLD: In ISIS, > >>> NEW: In IS-IS, > >>> > >>> > >>> Best regards > >>> --Bruno > >>> > >>> > >>> -----Original Message----- > >>> From: Karen Moore <[email protected]> > >>> Sent: Saturday, August 30, 2025 12:19 AM > >>> To: Shraddha Hegde <[email protected]>; [email protected]; Rajesh M > >>> <[email protected]>; DECRAENE Bruno INNOV/NET > >>> <[email protected]>; [email protected]; William Britto A J > >>> <[email protected]> > >>> Cc: [email protected]; [email protected]; [email protected]; > >>> [email protected]; [email protected]; > >>> [email protected] > >>> Subject: Re: AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw-con-22> > >>> for your review > >>> > >>> -------------------------------------------------------------------------------------------------------------- > >>> CAUTION : This email originated outside the company. Do not click on any > >>> links or open attachments unless you are expecting them from the sender. > >>> > >>> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne > >>> cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de > >>> connaitre l'expéditeur. > >>> -------------------------------------------------------------------------------------------------------------- > >>> > >>> Hi Shraddha, > >>> > >>> Thank you providing the udpated XML file. We have updated our files per > >>> your feedback; the changes are reflected in the files below along with > >>> your terminology updates. Please review and let us know if any further > >>> changes are needed or if you approve the document in its current form. We > >>> will await approvals from each author prior to moving forward in the > >>> publication process. > >>> > >>> 1) Note that we added the Updates tag as well as the following text (as > >>> the last sentence) in the Abstract: > >>> > >>> Current: > >>> This document updates RFC 9350. > >>> > >>> > >>> -Files (please refresh)- > >>> > >>> Updated XML file: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.xml__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzpj-EEbz$ > >>> > >>> Updated output files: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzvkVvjsv$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzkKHkjtG$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzhz1HgF6$ > >>> > >>> Diff files showing all changes made during AUTH48: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofznwurpfE$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzrBd7OBS$ > >>> (side by side) > >>> > >>> Diff files showing only the last round of changes: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzvAUAB5Y$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofztinNqqm$ > >>> (side by side) > >>> > >>> Diff files showing all changes: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzpOdZfZV$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzsj7CGKl$ > >>> (side by side) > >>> > >>> For the AUTH48 status of this document, please see: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9843__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzsL1xajX$ > >>> > >>> Best regards, > >>> > >>> Karen Moore > >>> RFC Production Center > >>> > >>> > >>>> On Aug 29, 2025, at 7:19 AM, Shraddha Hegde <[email protected]> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Pls see inline.. > >>>> > >>>> > >>>> Juniper Business Use Only > >>>> -----Original Message----- > >>>> From: Karen Moore <[email protected]> > >>>> Sent: 27 August 2025 05:42 > >>>> To: Shraddha Hegde <[email protected]>; William Britto A J > >>>> <[email protected]>; Rajesh M <[email protected]>; > >>>> [email protected]; [email protected]; [email protected] > >>>> Cc: [email protected]; [email protected]; [email protected]; > >>>> [email protected]; [email protected]; > >>>> [email protected] > >>>> Subject: Re: AUTH48: RFC-to-be 9843 > >>>> <draft-ietf-lsr-flex-algo-bw-con-22> for your review > >>>> > >>>> [External Email. Be cautious of content] > >>>> > >>>> > >>>> Hi Shraddha and William, > >>>> > >>>> Thank you for your replies. We have updated our files accordingly. > >>>> Please review and let us know if any futher updates are needed. Note > >>>> that we have some clarifications below as well an action item for the > >>>> authors.. > >>>> > >>>> 1) Please confirm if "proposes" is accurate or if "introduces" should be > >>>> used in the following sentence since this document is being published as > >>>> a Standards Track RFC. > >>>> > >>>> Current: > >>>> This document proposes standard metric-types that have specific > >>>> semantics and require standardization. > >>>> > >>>> Perhaps: > >>>> This document introduces standard metric-types that have specific > >>>> semantics and require standardization. > >>>> > >>>> <SH> "introduces" sounds better > >>>> > >>>> 2) This section sounds like it updates RFC 9350. Please confirm that an > >>>> Updates tag is not needed on this document. > >>>> > >>>> Original: > >>>> 6. Calculation of Flex-Algorithm paths > >>>> > >>>> Two new additional rules are added to the existing rules in the Flex- > >>>> Algorithm calculations specified in Section 13 of [RFC9350]. > >>>> > >>>> 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm > >>>> definition. If such exclude rule exists and the link has Maximum > >>>> Link Bandwidth advertised, check if the link bandwidth satisfies > >>>> the FAEMB rule. If the link does not satisfy the FAEMB rule, the > >>>> link MUST be pruned from the Flex-Algorithm computation. > >>>> > >>>> 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm > >>>> definition. If such exclude rule exists and the link has Min > >>>> Unidirectional link delay advertised, check if the link delay > >>>> satisfies the FAEMD rule. If the link does not satisfy the FAEMD > >>>> rule, the link MUST be pruned from the Flex-Algorithm computation. > >>>> <SH> Updates RFC 9350 tag is required. > >>>> > >>>> 3) Note that we updated the terminology to reflect the form on the > >>>> right. Please review the updated files to ensure the updates are > >>>> correct.. > >>>> > >>>> metric type -> metric-type > >>>> [Note that we left "Bandwidth metric type" as is; should it be > >>>> updated as "Bandwidth metric-type" instead?] <SH> yes > >>>> > >>>> bandwidth metric calculation -> Bandwidth metric calculation simple > >>>> mode -> Simple Mode <SH> ok > >>>> > >>>> - Note that no updates were made to the following terms: > >>>> Bandwidth metric type > >>>> Min Delay > >>>> > >>>> 4) We would appreciate it if the authors could update the XML file > >>>> accordingly for the following terms to ensure correctness: > >>>> > >>>> Minimum Bandwidth value > >>>> Minimum bandwidth advertised > >>>> Maximum Delay constraint > >>>> Maximum delay advertised > >>>> <SH> attached xml with changes > >>>> > >>>> --Files-- > >>>> Note that it may be necessary for you to refresh your browser to view > >>>> the most recent version. Please review the document carefully to ensure > >>>> satisfaction as we do not make changes once it has been published as an > >>>> RFC. > >>>> > >>>> We will await approvals from each author prior to moving forward in the > >>>> publication process. > >>>> > >>>> Updated XML file: > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43.xml__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_ > >>>> tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrIkVcW71%24&data=05%7C02%7Cbruno.de > >>>> craene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20af34b4 > >>>> 0bfbc48b9253b6f5d20%7C0%7C0%7C638921028883146400%7CUnknown%7CTWFpbGZsb > >>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cLxIsScSvldUo60wHYfNxJZZ1 > >>>> IViVhRzC8f8rzWAbRU%3D&reserved=0 > >>>> > >>>> Updated output files: > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43.txt__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_ > >>>> tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrKfEAk5V%24&data=05%7C02%7Cbruno.de > >>>> craene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20af34b4 > >>>> 0bfbc48b9253b6f5d20%7C0%7C0%7C638921028883159801%7CUnknown%7CTWFpbGZsb > >>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EQHlGfxzn9zQMAgTP2tCr%2FZ > >>>> uhN0A0aRSYnMnlSHkKx4%3D&reserved=0 > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43.pdf__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_ > >>>> tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrJaUMdh7%24&data=05%7C02%7Cbruno.de > >>>> craene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20af34b4 > >>>> 0bfbc48b9253b6f5d20%7C0%7C0%7C638921028883175199%7CUnknown%7CTWFpbGZsb > >>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=czSYaQ1IjCx0YLD5uzO1MyAy3 > >>>> yUhEHm3XRJvvfTczxU%3D&reserved=0 > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43.html__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI > >>>> _tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrAjb47PY%24&data=05%7C02%7Cbruno.d > >>>> ecraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20af34b > >>>> 40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883188789%7CUnknown%7CTWFpbGZs > >>>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > >>>> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dLSs0LVGBGMHaiyxk3Zz5dPh > >>>> Ao3PoVPHZLir8vBWwIE%3D&reserved=0 > >>>> > >>>> Diff files showing all changes made during AUTH48: > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43-auth48diff.html__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQK > >>>> D36G8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrF7Nghws%24&data=05%7C0 > >>>> 2%7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C9 > >>>> 0c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883202698%7CUnknown > >>>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 > >>>> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iGpkrwW6A28M5 > >>>> TxhV1f8PHt9pNK5WdDxz8tE2BAfpEA%3D&reserved=0 > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43-auth48rfcdiff.html__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHI > >>>> BQKD36G8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrHKNknae%24&data=05% > >>>> 7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162% > >>>> 7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883216327%7CUnkn > >>>> own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > >>>> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tqke48aEYc > >>>> eJwFZhNHIhjxykAuVhf6yRS9MP4ufpr7s%3D&reserved=0 (side by side) > >>>> > >>>> Diff files showing all changes: > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43-diff.html__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>>> 8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrC9UzeGQ%24&data=05%7C02%7Cbr > >>>> uno.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20 > >>>> af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883229768%7CUnknown%7CTWF > >>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > >>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VvI9Rp%2Ftflj3zQehs > >>>> VF7YZuFHTmvRCJyiX5E6MyLeiI%3D&reserved=0 > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98 > >>>> 43-rfcdiff.html__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36 > >>>> G8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrDXbt4qc%24&data=05%7C02%7 > >>>> Cbruno.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7 > >>>> a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883243335%7CUnknown%7C > >>>> TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > >>>> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bIqIMM5apvkwC7F4 > >>>> zT9jZ0i5uOr3LSp5e4Xl1wODa2E%3D&reserved=0 (side by side) > >>>> > >>>> For the AUTH48 status of this document, please see: > >>>> https://urldefense.com/v3/__https://urld/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofzoEgF-EH$ > >>>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc984 > >>>> 3__%3B!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_tZ_Jo > >>>> 5K32-9qg_w2_qNPqCHQubEPKU_brpjrM5qqAYY%24&data=05%7C02%7Cbruno.decraen > >>>> e%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20af34b40bfbc > >>>> 48b9253b6f5d20%7C0%7C0%7C638921028883257784%7CUnknown%7CTWFpbGZsb3d8ey > >>>> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > >>>> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bHZv6B9JOEAKyn2o5BpBCI30wVbQyX > >>>> W42p%2BTYTVIogM%3D&reserved=0 > >>>> > >>>> Best regards, > >>>> > >>>> Karen Moore > >>>> RFC Production Center > >>>> > >>>> > >>>>> On Aug 24, 2025, at 10:15 PM, Shraddha Hegde > >>>>> <[email protected]> wrote: > >>>>> > >>>>> Hi, > >>>>> Thank you for the work on editing the draft. > >>>>> Pls see inline for responses > >>>>> > >>>>> > >>>>> Juniper Business Use Only > >>>>> -----Original Message----- > >>>>> From: [email protected] <[email protected]> > >>>>> Sent: 19 August 2025 02:55 > >>>>> To: Shraddha Hegde <[email protected]>; William Britto A J > >>>>> <[email protected]>; Rajesh M <[email protected]>; > >>>>> [email protected]; [email protected]; [email protected] > >>>>> Cc: [email protected]; [email protected]; [email protected]; > >>>>> [email protected]; [email protected]; > >>>>> [email protected] > >>>>> Subject: Re: AUTH48: RFC-to-be 9843 > >>>>> <draft-ietf-lsr-flex-algo-bw-con-22> 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] We removed "A J" from William Britto's name to match use > >>>>> in RFC 9502. If that is not desired, please let us know. > >>>>> --> > >>>>> <SH> will let William confirm > >>>>> > >>>>> > >>>>> 2) <!--[rfced] How may we clarify "and require to be standardized"? > >>>>> Please let us know if option A or option B captures in the intended > >>>>> meaning. > >>>>> > >>>>> In addition, as this document is being published as a Standards-Track > >>>>> RFC, please consider whether "proposes" is accurate. Perhaps > >>>>> "introduces" would work? > >>>>> > >>>>> Original: > >>>>> This document proposes standard metric-types which have specific > >>>>> semantics and require to be standardized. > >>>>> > >>>>> Perhaps A: > >>>>> This document proposes standard metric-types that have specific > >>>>> semantics and require standardization. > >>>>> > >>>>> Perhaps B: > >>>>> This document proposes standard metric-types that have specific > >>>>> semantics and requirements for standardization. > >>>>> --> > >>>>> <SH> I prefer A > >>>>> This document proposes standard metric-types that have specific > >>>>> semantics and require standardization > >>>>> > >>>>> 3) <!--[rfced] Should the section references be in order for ease of > >>>>> reading as shown below? > >>>>> > >>>>> Original: > >>>>> In Section 4, this document specifies a new bandwidth based metric > >>>>> type to be used with Flex-Algorithm and other applications. > >>>>> Section 3 defines additional Flexible Algorithm Definition (FAD) > >>>>> [RFC9350] constraints that allow the network administrator to > >>>>> preclude the use of low bandwidth links or high delay links. > >>>>> > >>>>> Section 4.1 defines... > >>>>> > >>>>> Perhaps: > >>>>> Section 3 defines additional FAD [RFC9350] constraints that allow > >>>>> the network administrator to preclude the use of low bandwidth links > >>>>> or high delay links. In Section 4, this document specifies a new > >>>>> bandwidth-based metric type to be used with Flex-Algorithm and other > >>>>> applications. > >>>>> > >>>>> Section 4.1 defines... > >>>>> --> > >>>>> <SH> ok > >>>>> > >>>>> > >>>>> 4) <!--[rfced] Should "Min Unidirectional delay metric" be > >>>>> "Unidirectional Link Delay" or "Min/Max Unidirectional Link Delay" per > >>>>> RFCs 8570 and 7471? > >>>>> > >>>>> Original: > >>>>> The Traffic Engineering Default Metric is defined in [RFC5305] and > >>>>> [RFC3630] and the Min Unidirectional delay metric is defined in > >>>>> [RFC8570] and [RFC7471]. > >>>>> > >>>>> Perhaps: > >>>>> The Traffic Engineering Default Metric is defined in [RFC5305] and > >>>>> [RFC3630], and the Min/Max Unidirectional Link Delay is defined in > >>>>> [RFC8570] and [RFC7471]. > >>>>> --> > >>>>> <SH> It should be Unidirectional Link Delay > >>>>> > >>>>> New: > >>>>> The Traffic Engineering Default Metric is defined in [RFC5305] and > >>>>> [RFC3630], and the Unidirectional Link Delay is defined in > >>>>> [RFC8570] and [RFC7471]. > >>>>> > >>>>> 5) <!--[rfced] We find "TLV 22/extended link LSA/TE-LSAs" hard to read. > >>>>> How may we reword this for clarity and to also include the expansion of > >>>>> "LSA"? > >>>>> > >>>>> Also, should "generic metric sub-TLV" be singular and uppercase for > >>>>> consistency as shown below? > >>>>> <SH> Ok with the uppercase > >>>>> > >>>>> Original: > >>>>> Implementations MUST support sending and receiving generic metric > >>>>> sub-TLV in Application Specific Link Attributes (ASLA)encodings as > >>>>> well as in the TLV 22/extended link LSA/TE-LSAs. > >>>>> > >>>>> Perhaps: > >>>>> Implementations MUST support sending and receiving a Generic Metric > >>>>> sub-TLV in Application-Specific Link Attributes (ASLA) encodings as > >>>>> well as in TLV 22 and extended Link State Advertisements (LSAs) and > >>>>> TE-LSAs. > >>>>> --> > >>>>> <SH> With slight modification as below > >>>>> > >>>>> Implementations MUST support sending and receiving a Generic Metric > >>>>> sub-TLV in Application-Specific Link Attributes (ASLA) encodings as > >>>>> well as in TLV 22 and Extended Link Opaque Link State Advertisements > >>>>> (LSAs) [RFC7684] and TE-LSAs. > >>>>> > >>>>> > >>>>> > >>>>> 6) <!--[rfced] When referring to "TLV 22/222/23/223/141" (or "TLV > >>>>> 22/23/141/222/223" > >>>>> if updated), should "TLV" be plural (e.g., "TLVs 22/222/23/223/141")? > >>>>> We note that the plural form is used in the "Sub-TLVs for TLVs 22, 23, > >>>>> 141, 222, and 223" registry. > >>>>> > >>>>> Original: > >>>>> f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV > >>>>> 22/222/23/223/141 [RFC9479] > >>>>> > >>>>> g. TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as "y(s)" > >>>>> (shareable among bundle members) > >>>>> > >>>>> ... > >>>>> One example in the running text (see the document for more instances). > >>>>> > >>>>> Original: > >>>>> For a particular metric type, the Generic Metric sub-TLV MUST be > >>>>> advertised only once for a link when advertised in TLV 22, 222, 23, > >>>>> 223 and 141. > >>>>> --> > >>>>> <SH> Pluralisation of TLV to TLVs is ok > >>>>> > >>>>> > >>>>> 7) <!--[rfced] Would it be correct to update "2" to "type 2" as shown > >>>>> below for clarity? > >>>>> > >>>>> Original: > >>>>> a. sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. > >>>>> > >>>>> b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA > >>>>> [RFC5392]. > >>>>> > >>>>> c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA [RFC5329]. > >>>>> > >>>>> d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA > >>>>> [RFC5392]. > >>>>> > >>>>> Perhaps: > >>>>> a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630]. > >>>>> > >>>>> b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA > >>>>> [RFC5392]. > >>>>> > >>>>> c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA > >>>>> [RFC5329]. > >>>>> > >>>>> d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA > >>>>> [RFC5392]. > >>>>> --> > >>>>> <SH> ok > >>>>> > >>>>> 8) <!--[rfced] Please clarify what "this" refers to in the following > >>>>> sentence. > >>>>> > >>>>> Original: > >>>>> If the capacity of a link is constant, this can already be achieved > >>>>> through the use of administrative groups. > >>>>> --> > >>>>> <SH> If the capacity of a low bandwidth link is constant, Constraining > >>>>> the topology to avoid those links can already be achieved through the > >>>>> use of administrative groups. > >>>>> > >>>>> > >>>>> 9) <!--[rfced] May we update this sentence for clarity as shown below? > >>>>> > >>>>> Original: > >>>>> Bandwidth metric is a link attribute and for the advertisement and > >>>>> processing of this attribute for Flex-algorithm, MUST follow the > >>>>> section 12 of [RFC9350]. > >>>>> > >>>>> Perhaps: > >>>>> The Bandwidth Metric is a link attribute, and it MUST follow Section > >>>>> 12 of [RFC9350] for its advertisement and processing during > >>>>> Flex-Algorithm calculation. > >>>>> --> > >>>>> <SH> ok > >>>>> > >>>>> 10) <!--[rfced] We updated this text to make it a complete sentence. > >>>>> There are two instances in the document. Please let us know if this is > >>>>> not correct. > >>>>> > >>>>> Original: > >>>>> Staircase bandwidth threshold and associated metric values. > >>>>> > >>>>> Current: > >>>>> Following is the staircase bandwidth threshold and associated metric > >>>>> values. > >>>>> --> > >>>>> <SH> ok > >>>>> > >>>>> 11) <!--[rfced] We note similar text in Sections 4.1.3.1, 4.1.3.2, and > >>>>> 4.1.4.2. Should any of this text be in paragraph form or bulleted form > >>>>> for consistency? > >>>>> > >>>>> Original > >>>>> Section 4.1.3.1: > >>>>> In case of Interface Group Mode, if > >>>>> all the parallel links have been advertised with the Bandwidth > >>>>> Metric, The individual link Bandwidth Metric MUST be used. If only > >>>>> some links among the parallel links have the Bandwidth Metric > >>>>> advertisement, the Bandwidth Metric for such links MUST be ignored > >>>>> and automatic Metric calculation MUST be used to derive link metric. > >>>>> > >>>>> Section 4.1.3.2: > >>>>> In case of Interface Group Mode, if all the parallel links have been > >>>>> advertised with the Bandwidth Metric, The individual link Bandwidth > >>>>> Metric MUST be used. If only some links among the parallel links > >>>>> have the Bandwidth Metric advertisement, the Bandwidth Metric for > >>>>> such links MUST be ignored and automatic Metric calculation MUST be > >>>>> used to derive link metric. > >>>>> > >>>>> Section 4.1.4.2: > >>>>> In the context of Interface Group Mode, the following rules apply to > >>>>> parallel links: > >>>>> > >>>>> * If all parallel links have advertised the Bandwidth Metric: > >>>>> > >>>>> The individual link Bandwidth Metrics MUST be used for each link > >>>>> during path computation. > >>>>> > >>>>> * If only some of the parallel links have advertised the Bandwidth > >>>>> Metric: > >>>>> > >>>>> - The Bandwidth Metric advertisements for those links MUST be > >>>>> ignored. > >>>>> > >>>>> - Automatic metric calculation MUST be used to derive the link > >>>>> metrics for all parallel links. > >>>>> --> > >>>>> <SH> Bulleted form looks more readable. Sec 4.1.3.1 and sec 4.1.3.2 > >>>>> can be modified to bulleted form > >>>>> > >>>>> 12) <!-- [rfced] Please review whether any of the notes in this > >>>>> document should be in the <aside> element. It is defined as "a > >>>>> container for content that is semantically less important or tangential > >>>>> to the content that surrounds it" > >>>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aULFhXTJk$ > >>>>> ). > >>>>> --> > >>>>> <SH> The current form of Notes looks appropriate to me. > >>>>> > >>>>> > >>>>> 13) <!-- [rfced] Terminology > >>>>> > >>>>> a) Throughout the text, the following terminology appears to be used > >>>>> inconsistently. Please review these occurrences and let us know if/how > >>>>> they may be made consistent. > >>>>> > >>>>> Bandwidth metric type vs. bandwidth metric calculation (Should > >>>>> "bandwidth metric calculation" be "Bandwidth metric calculation" > >>>>> to match "Bandwidth metric type"?) > >>>>> > >>>>> <SH> Good to use below consistently > >>>>> Bandwidth metric type , Bandwidth metric calculation > >>>>> > >>>>> > >>>>> metric-type vs. metric type > >>>>> <SH> metric-type > >>>>> > >>>>> Minimum Bandwidth value vs. Minimum bandwidth advertised (Are these > >>>>> terms different or should "bandwidth" be uppercase for consistency?) > >>>>> <SH> When sub-TV is referred First letter should be capitalised , when > >>>>> the actual value contained in the sb-TLV is referred, small case should > >>>>> be used. > >>>>> Exampls: > >>>>> Old: > >>>>> If the Maximum Link Bandwidth is lower than the Minimum Link > >>>>> Bandwidth advertised in the FAEMB sub-TLV, Maximum Delay constraint > >>>>> vs. Maximum delay advertised > >>>>> > >>>>> New: > >>>>> > >>>>> If the maximum link bandwidth is lower than the minimum link > >>>>> bandwidth advertised in the FAEMB sub-TLV, > >>>>> > >>>>> I can take a first cut on fixing this in the document. Let me know. > >>>>> > >>>>> > >>>>> (Are these terms different or should "delay" be uppercase for > >>>>> consistency? > >>>>> > >>>>> Min Delay value (used once in this document) > >>>>> Is this the intended term or should it perhaps be > >>>>> "Minimum Delay value" or "Min Unidirectional Link Delay > >>>>> value"? > >>>>> > >>>>> <SH> the Min Delay is the term used in RFC 7471 > >>>>> > >>>>> b) We updated the document to reflect the forms on the right for > >>>>> consistency. > >>>>> Please let us know of any objections. > >>>>> > >>>>> Bandwidth metric -> Bandwidth Metric > >>>>> bytes-per-second -> bytes per second > >>>>> Flex-algorithm -> Flex-Algorithm (per RFC 9350) Flex-Algorithm > >>>>> definition -> Flex Algorithm Definition (per RFC 9350) > >>>>> > >>>>> Flexible Algorithm Definition Bandwidth Thresholds -> > >>>>> Flexible Algorithm Definition Bandwidth Threshold (singular) > >>>>> > >>>>> Generic metric -> Generic Metric (for consistency and per IANA) IGP > >>>>> metric -> IGP Metric (per RFC 9350 and IANA) ISIS -> IS-IS > >>>>> interface group mode -> Interface Group Mode L-Flag -> L-flag (per > >>>>> RFC 9350) > >>>>> layer-2 -> Layer 2 > >>>>> layer-3 -> Layer 3 > >>>>> Max link delay -> Max Link Delay > >>>>> > >>>>> Min Unidirectional link delay and Minimum Unidirectional Link Delay -> > >>>>> Min Unidirectional Link Delay (per RFC 9350) > >>>>> > >>>>> Minimum link bandwidth -> Minimum Link Bandwidth nexthops -> next > >>>>> hops Reference Bandwidth Field -> Reference Bandwidth field > >>>>> > >>>>> <SH> OK for all > >>>>> > >>>>> c) Should "simple mode" be made uppercase to match "Interface Group > >>>>> Mode" > >>>>> since they are both listed as automatic metric calculation modes? > >>>>> --> > >>>>> <SH> OK > >>>>> > >>>>> > >>>>> 14) <!-- [rfced] Abbreviations > >>>>> > >>>>> a) FYI - We have added expansions for the following abbreviations per > >>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > >>>>> expansion in the document carefully to ensure correctness. > >>>>> > >>>>> Area Border Router (ABR) > >>>>> Link Aggregation Group (LAG) > >>>>> Link State Advertisement (LSA) > >>>>> Link State Protocol Data Unit (LSPDU) <SH> OK > >>>>> > >>>>> b) We made the following change to follow use in RFC 9350. Please let > >>>>> us know of any objections. > >>>>> > >>>>> Flex-Algorithm Definition (FAD) -> Flexible Algorithm Definition > >>>>> (FAD) > >>>>> --> > >>>>> <SH> OK > >>>>> > >>>>> 15) <!-- [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!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUDCHaRVn$ > >>>>> > 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. > >>>>> --> > >>>>> <SH> ok > >>>>> > >>>>> Thank you. > >>>>> > >>>>> Karen Moore and Sandy Ginoza > >>>>> RFC Production Center > >>>>> > >>>>> > >>>>> On Aug 18, 2025, at 2:21 PM, [email protected] wrote: > >>>>> > >>>>> *****IMPORTANT***** > >>>>> > >>>>> Updated 2025/08/18 > >>>>> > >>>>> 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!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUHT0O_G1$ > >>>>> ). > >>>>> > >>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUNtLNH4K$ > >>>>> ). > >>>>> > >>>>> * 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!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUGqmN29i$ > >>>>> >. > >>>>> > >>>>> * 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://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg% > >>>>> 2Fietf&data=05%7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9 > >>>>> bb408dde74a5162%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63892102 > >>>>> 8883553242%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj > >>>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >>>>> 7C&sdata=0luYgk1OB3vN%2BpvcgEt1mmPWOH41bv1mK05tO%2FTdN%2BM%3D&reserve > >>>>> d=0 > >>>>> -announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!GAYtbcKco2W_gMb > >>>>> a > >>>>> Vd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUCMDQ > >>>>> w > >>>>> Lp$ > >>>>> > >>>>> * The archive itself: > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrow > >>>>> se%2Fa&data=05%7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9 > >>>>> bb408dde74a5162%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63892102 > >>>>> 8883574559%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj > >>>>> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >>>>> 7C&sdata=NywdkSYAeSLlyX0UZ4%2BdGzwWSal8%2BdyRNkgL2xIagXw%3D&reserved= > >>>>> 0 > >>>>> uth48archive/__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtD > >>>>> G Y0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUDhfuJRq$ > >>>>> > >>>>> * 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://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843.xml__%3B!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0 > >>>>> T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUNyZupXt%24&data=05%7C02%7Cbrun > >>>>> o.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20a > >>>>> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883590950%7CUnknown%7CTWF > >>>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >>>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FbgQHC39QME5ZP6 > >>>>> pIhZ5NKZxwJL%2Bh%2BcnRHHNYxrBFlY%3D&reserved=0 > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843.html__%3B!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY > >>>>> 0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUBv7V6LA%24&data=05%7C02%7Cbru > >>>>> no.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20 > >>>>> af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883605538%7CUnknown%7CTW > >>>>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >>>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JEbCewYstHhNHtzK > >>>>> UsXorO35mll9McGtFlSPrhfbvrg%3D&reserved=0 > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843.pdf__%3B!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0 > >>>>> T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUCHPopHH%24&data=05%7C02%7Cbrun > >>>>> o.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90c7a20a > >>>>> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883619573%7CUnknown%7CTWF > >>>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >>>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yqWqjL7PBhAOfs67D > >>>>> GjYR%2Ft4LROiMxf0Iy%2BhCWmx1WM%3D&reserved=0 > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843&data=05%7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb > >>>>> 408dde74a5162%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389210288 > >>>>> 83635096%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >>>>> &sdata=kUurH2s9AC1BYOpoVd9u7ErDsakYf4%2BKhpYhV2D4st0%3D&reserved=0 > >>>>> .txt__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMq > >>>>> Q buOG1lYMzLeFLFB7o1ofaRPdVELob8aUBZrKBWa$ > >>>>> > >>>>> Diff file of the text: > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843-diff.html__%3B!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGaf > >>>>> DtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUArKKa_y%24&data=05%7C02% > >>>>> 7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb408dde74a5162%7C90 > >>>>> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638921028883649516%7CUnknown > >>>>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW > >>>>> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ervkYPukgRn > >>>>> Hy3g%2FNZs4%2BhhxHAT2dFDQcnNHRGcQH5w%3D&reserved=0 > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843&data=05%7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb > >>>>> 408dde74a5162%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389210288 > >>>>> 83664653%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >>>>> &sdata=dy%2B4kjjODknzatrbwq5KChKgmaahK%2BJIA7JoPM5UOP4%3D&reserved=0 > >>>>> -rfcdiff.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtD > >>>>> G Y0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUEuqnIYn$ (side by side) > >>>>> > >>>>> Diff of the XML: > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc > >>>>> 9843&data=05%7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb > >>>>> 408dde74a5162%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389210288 > >>>>> 83679154%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >>>>> &sdata=KebxVEGoc18D7AqgYCGx%2Fv96VxmGaEx%2Bhg74Ii%2BOKpo%3D&reserved= > >>>>> 0 > >>>>> -xmldiff1.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDt > >>>>> D GY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUN3Xt-LR$ > >>>>> > >>>>> > >>>>> Tracking progress > >>>>> ----------------- > >>>>> > >>>>> The details of the AUTH48 status of your document are here: > >>>>> > >>>>> https://urldefense.com/v3/__https://url/__;!!NEt6yMaO-gk!BcPglu81bd_Z3jCWTcLnwieS2LECvZcHsgTFhQr2nj3nKq3ltdue7cxC62rLYbWEziTjEO05FD1-tnofziHkfSOq$ > >>>>> defense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9 > >>>>> 843_&data=05%7C02%7Cbruno.decraene%40orange.com%7C37a942e30644480d9bb > >>>>> 408dde74a5162%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389210288 > >>>>> 83692764%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >>>>> &sdata=AkQKm8b5vO694KkW%2BGSdkU0f4PrzsoqqyHowu%2BQXuQI%3D&reserved=0 > >>>>> _;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG > >>>>> 1 > >>>>> lYMzLeFLFB7o1ofaRPdVELob8aUOE3WnXi$ > >>>>> > >>>>> Please let us know if you have any questions. > >>>>> > >>>>> Thank you for your cooperation, > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> -------------------------------------- > >>>>> RFC 9843 (draft-ietf-lsr-flex-algo-bw-con-22) > >>>>> > >>>>> Title : IGP Flexible Algorithms: Bandwidth, Delay, Metrics > >>>>> and Constraints > >>>>> Author(s) : S. Hegde, W. Britto A J, R. Shetty, B. Decraene, P. > >>>>> Psenak, T. Li > >>>>> WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen Qu > >>>>> > >>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > >>>>> Velde > >>>>> > >>>>> > >>>> > >>>> <rfc9843(1).xml> > >>> > >>> ____________________________________________________________________________________________________________ > >>> Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc > >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > >>> recu ce message par erreur, veuillez le signaler > >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > >>> electroniques etant susceptibles d'alteration, > >>> Orange decline toute responsabilite si ce message a ete altere, deforme > >>> ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or privileged > >>> information that may be protected by law; > >>> they should not be distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender and > >>> delete this message and its attachments. > >>> As emails may be altered, Orange is not liable for messages that have > >>> been modified, changed or falsified. > >>> Thank you. > >>> > >> > >> ____________________________________________________________________________________________________________ > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc > >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > >> recu ce message par erreur, veuillez le signaler > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > >> electroniques etant susceptibles d'alteration, > >> Orange decline toute responsabilite si ce message a ete altere, deforme ou > >> falsifie. Merci. > >> > >> This message and its attachments may contain confidential or privileged > >> information that may be protected by law; > >> they should not be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > >> delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have been > >> modified, changed or falsified. > >> Thank you. > >> > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
