HI Karen, Changes look good. I approve for publication.
Thanks Rajesh Juniper Business Use Only -----Original Message----- From: Peter Psenak <ppse...@cisco.com> Sent: Monday, September 8, 2025 1:35 PM To: Karen Moore <kmo...@staff.rfc-editor.org>; Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; William Britto A J <bwill...@juniper.net>; tony...@tony.li; Shraddha Hegde <shrad...@juniper.net>; Rajesh M <mraj...@juniper.net>; bruno.decra...@orange.com; a...@cisco.com Cc: lsr-...@ietf.org; lsr-cha...@ietf.org; rfc-edi...@rfc-editor.org; auth48archive@rfc-editor.org 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 <tony...@tony.li> wrote: >> >> Hi Karen, >> >> I concur. Ship it! >> >> T > >> On Sep 5, 2025, at 8:29 AM, Shraddha Hegde <shrad...@juniper.net> 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) >> <gunter.van_de_ve...@nokia.com> wrote: >> >> Hi Karen, >> >> I read through the text and the changes are approved. >> >> Be well, >> G/ >> >> -----Original Message----- >> From: Karen Moore <kmo...@staff.rfc-editor.org> >> Sent: Thursday, September 4, 2025 9:25 PM >> To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; >> bruno.decra...@orange.com; William Britto A J <bwill...@juniper.net>; >> tony...@tony.li; Shraddha Hegde <shrad...@juniper.net>; Rajesh M >> <mraj...@juniper.net>; ppse...@cisco.com >> Cc: lsr-...@ietf.org; lsr-cha...@ietf.org; a...@cisco.com; >> rfc-edi...@rfc-editor.org; auth48archive@rfc-editor.org >> 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, bruno.decra...@orange.com wrote: >>> >>> Hi Karen, >>> >>> Thanks. >>> Changes looks good. >>> >>> I approve publication. >>> >>> >>> --Bruno >>> -----Original Message----- >>> From: Karen Moore <kmo...@staff.rfc-editor.org> >>> Sent: Wednesday, September 3, 2025 3:54 AM >>> To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Rajesh M >>> <mraj...@juniper.net>; tony...@tony.li; William Britto A J >>> <bwill...@juniper.net>; Shraddha Hegde <shrad...@juniper.net>; >>> ppse...@cisco.com >>> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr-cha...@ietf.org; >>> a...@cisco.com; gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >>> 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, bruno.decra...@orange.com 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 <kmo...@staff.rfc-editor.org> >>>> Sent: Saturday, August 30, 2025 12:19 AM >>>> To: Shraddha Hegde <shrad...@juniper.net>; tony...@tony.li; Rajesh M >>>> <mraj...@juniper.net>; DECRAENE Bruno INNOV/NET >>>> <bruno.decra...@orange.com>; ppse...@cisco.com; William Britto A J >>>> <bwill...@juniper.net> >>>> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr-cha...@ietf.org; >>>> a...@cisco.com; gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >>>> 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 <shrad...@juniper.net> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Pls see inline.. >>>>> >>>>> >>>>> Juniper Business Use Only >>>>> -----Original Message----- >>>>> From: Karen Moore <kmo...@staff.rfc-editor.org> >>>>> Sent: 27 August 2025 05:42 >>>>> To: Shraddha Hegde <shrad...@juniper.net>; William Britto A J >>>>> <bwill...@juniper.net>; Rajesh M <mraj...@juniper.net>; >>>>> tony...@tony.li; ppse...@cisco.com; bruno.decra...@orange.com >>>>> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr-cha...@ietf.org; >>>>> a...@cisco.com; gunter.van_de_ve...@nokia.com; >>>>> auth48archive@rfc-editor.org >>>>> 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 >>>>>> <shraddha=40juniper....@dmarc.ietf.org> wrote: >>>>>> >>>>>> Hi, >>>>>> Thank you for the work on editing the draft. >>>>>> Pls see inline for responses >>>>>> >>>>>> >>>>>> Juniper Business Use Only >>>>>> -----Original Message----- >>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>> Sent: 19 August 2025 02:55 >>>>>> To: Shraddha Hegde <shrad...@juniper.net>; William Britto A J >>>>>> <bwill...@juniper.net>; Rajesh M <mraj...@juniper.net>; >>>>>> bruno.decra...@orange.com; ppse...@cisco.com; tony...@tony.li >>>>>> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr-cha...@ietf.org; >>>>>> a...@cisco.com; gunter.van_de_ve...@nokia.com; >>>>>> auth48archive@rfc-editor.org >>>>>> 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, rfc-edi...@rfc-editor.org 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 >>>>>> >>>>>> * rfc-edi...@rfc-editor.org (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). >>>>>> >>>>>> * auth48archive@rfc-editor.org, 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, >>>>>> auth48archive@rfc-editor.org 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
