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
