Hi Karen,
Thank you for the update. Changes look good. I have one comment on IANA registry OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV The sub-TLVs are numbered as bit number. This should have been called type because Its not really bit number that is being assigned here. Looks like The RFC 9350 introduced this registry And named it bit number. This looks incorrect to me. @Acee, let me know if you agree that the sub-TLVs types and not really bit number. Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Karen Moore <kmo...@staff.rfc-editor.org> Sent: 30 August 2025 03:49 To: Shraddha Hegde <shrad...@juniper.net>; tony...@tony.li; Rajesh M <mraj...@juniper.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 [External Email. Be cautious of content] 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!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GX8rO-z1$ Updated output files: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GZS82neH$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GdwVH-mj$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GYVUTcBW$ Diff files showing all changes made during AUTH48: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GZF4ZX0V$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gad0iXLO$ (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!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GYWmHq62$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gbq3NRaB$ (side by side) Diff files showing all changes: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GW9Rg2Zm$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gbwjfk7S$ (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!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gen6bexO$ 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://www.rfc-editor.org/authors/rfc9843 > .xml__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_tZ_J > o5K32-9qg_w2_qNPqCHQubEPKU_brpjrIkVcW71$ > > Updated output files: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > .txt__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_tZ_J > o5K32-9qg_w2_qNPqCHQubEPKU_brpjrKfEAk5V$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > .pdf__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_tZ_J > o5K32-9qg_w2_qNPqCHQubEPKU_brpjrJaUMdh7$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > .html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_tZ_ > Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrAjb47PY$ > > Diff files showing all changes made during AUTH48: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > -auth48diff.html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G > 8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrF7Nghws$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > -auth48rfcdiff.html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD > 36G8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrHKNknae$ (side by > side) > > Diff files showing all changes: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > -diff.html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQ > I_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrC9UzeGQ$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843 > -rfcdiff.html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8 > WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrDXbt4qc$ (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!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8WqQI_tZ_Jo5K32 > -9qg_w2_qNPqCHQubEPKU_brpjrM5qqAYY$ > > 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://mailarchive.ietf.org/arch/msg/iet >> f >> -announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!GAYtbcKco2W_gMb >> a >> Vd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUCMDQ >> w >> Lp$ >> >> * The archive itself: >> >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ >> a >> 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://www.rfc-editor.org/authors/rfc984 >> 3.xml__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QM >> qQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUNyZupXt$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc984 >> 3.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86Q >> MqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUBv7V6LA$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc984 >> 3.pdf__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QM >> qQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUCHPopHH$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc984 >> 3 >> .txt__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMq >> Q buOG1lYMzLeFLFB7o1ofaRPdVELob8aUBZrKBWa$ >> >> Diff file of the text: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc984 >> 3-diff.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY >> 0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUArKKa_y$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc984 >> 3 >> -rfcdiff.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtD >> G Y0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUEuqnIYn$ (side by side) >> >> Diff of the XML: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc984 >> 3 >> -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://www.rfc-editor.org/auth48/rfc9843 >> _ >> _;!!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> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
