Hi IANA, The Document Shepherd of RFC 9350 and the authors of RFC-to-be 9843 have agreed on changing the name of the first column in the "OSPF Flexible Algorithm Definition TLV Sub-TLVs” registry at "https://www.iana.org/assignments/ospf-parameters/";. Please make the following change:
OLD: Bit Number NEW: Type Best regards, Karen Moore RPC Production Center > From: Acee Lindem <acee.i...@gmail.com> > Subject: Re: AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw-con-22> for > your review > Date: September 4, 2025 at 8:19:50 AM PDT > To: shraddha <shrad...@juniper.net>, David Dong via RT <iana-iss...@iana.org> > Cc: Karen Moore <kmo...@staff.rfc-editor.org>, "a...@cisco.com" > <a...@cisco.com>, "tony...@tony.li" <tony...@tony.li>, Rajesh Shetty > <mraj...@juniper.net>, Bruno Decraene <bruno.decra...@orange.com>, Peter > Psenak <ppse...@cisco.com>, William Britto A J <bwill...@juniper.net>, > "rfc-edi...@rfc-editor.org" <rfc-edi...@rfc-editor.org>, "lsr-...@ietf.org" > <lsr-...@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, > "gunter.van_de_ve...@nokia.com" <gunter.van_de_ve...@nokia.com>, > "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org> > > Hi Shraddha, > >> On Sep 3, 2025, at 2:43 AM, Shraddha Hegde <shrad...@juniper.net> wrote: >> >> 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. > > No - that should be "Type" rather than "Bit Number". > > https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml#flexible-algorithm-definition-tlv-sub-tlvs > > Copied IANA issues (iana-iss...@iana.org <mailto:iana-iss...@iana.org>) to > fix. > > Thanks, > Acee > P.S. I guess it is your Juniper mailer that is obfuscating the URLs in > forwarded mails? You might want to switch to a different Email address for > IETF work as this is very annoying. > > >> >> >> 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 > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
