Hello authors, We have noted approvals for Peter and Rajesh at "https://www.rfc-editor.org/auth48/rfc9843”. We now have all necessary approvals and will move this document forward in the publication process.
Thank you to all for your time! Best regards, Karen Moore RFC Production Center > On Sep 8, 2025, at 1:53 AM, Rajesh M <[email protected]> wrote: > > HI Karen, > > Changes look good. I approve for publication. > > Thanks > Rajesh > > > > Juniper Business Use Only > -----Original Message----- > From: Peter Psenak <[email protected]> > Sent: Monday, September 8, 2025 1:35 PM > To: Karen Moore <[email protected]>; Gunter van de Velde (Nokia) > <[email protected]>; William Britto A J <[email protected]>; > [email protected]; Shraddha Hegde <[email protected]>; Rajesh M > <[email protected]>; [email protected]; [email protected] > Cc: [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 Karen, > > I approve it for publication. > > thanks, > Peter > > On 05/09/2025 20:14, Karen Moore wrote: >> Dear Acee, Gunter, Shraddha, and Tony, >> >> Thank you for your replies. The IANA actions are now complete, and we have >> noted approvals for Gunter, Shraddha, and Tony on the AUTH48 status page >> (https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9843__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGIdBrrE$ >> ). >> >> We now await approval of the document from Rajesh, Peter, and William prior >> to moving forward with publication. >> >> Best regards, >> >> Karen Moore >> RFC Production Center >> >> >>> On Sep 5, 2025, at 8:37 AM, Tony Li <[email protected]> wrote: >>> >>> 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 >> >>> On Sep 4, 2025, at 8:40 PM, Gunter van de Velde (Nokia) >>> <[email protected]> wrote: >>> >>> Hi Karen, >>> >>> I read through the text and the changes are approved. >>> >>> Be well, >>> G/ >>> >>> -----Original Message----- >>> From: Karen Moore <[email protected]> >>> Sent: Thursday, September 4, 2025 9:25 PM >>> To: Gunter van de Velde (Nokia) <[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 >>> >>> >>> CAUTION: This is an external email. Please be very careful when clicking >>> links or opening attachments. See the URL nok.it/ext for additional >>> information. >>> >>> >>> >>> 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**B__;4oCd!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYp3S71rSU$ >>> . >>> >>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpy8hOtv4$ >>> >>> Updated output files: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpbMhnEac$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpKGwawUE$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpe5NmZG4$ >>> >>> Diff files showing all changes made during AUTH48: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGD6Jyl4$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpBm5gMX8$ >>> (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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpkCSxLdk$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYppVlmNKc$ >>> (side by side) >>> >>> Diff files showing all changes: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpNRmk7FA$ >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpk1IBU9w$ >>> (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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGIdBrrE$ >>> >>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpy8hOtv4$ >>>> >>>> Updated output files: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpbMhnEac$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpKGwawUE$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpe5NmZG4$ >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGD6Jyl4$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpBm5gMX8$ >>>> (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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpkCSxLdk$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYppVlmNKc$ >>>> (side by side) >>>> >>>> Diff files showing all changes: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpNRmk7FA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpk1IBU9w$ >>>> (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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGIdBrrE$ >>>> >>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpHc4I6V0$ >>>>> >>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpy8hOtv4$ >>>>> >>>>> Updated output files: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpbMhnEac$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpKGwawUE$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpe5NmZG4$ >>>>> >>>>> Diff files showing all changes made during AUTH48: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGD6Jyl4$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpBm5gMX8$ >>>>> (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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpkCSxLdk$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYppVlmNKc$ >>>>> (side by side) >>>>> >>>>> Diff files showing all changes: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpNRmk7FA$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpk1IBU9w$ >>>>> (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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpGIdBrrE$ >>>>> >>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpknQMU24$ >>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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!E-MLZDZFnk7Tn5YzKYKl6-POyImnrPzdFun8tdm1hP4-yjARXS4dRCCS5P7K-JgMN2GpCaYpMVeg1qQ$ >>>>>>> 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]
