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]
