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://www.rfc-editor.org/auth48/rfc9843). We now await approval of the document from Rajesh, Peter, and William prior to moving forward with publication. Best regards, Karen Moore RFC Production CenterOn Sep 5, 2025, at 8:37 AM, Tony Li <tony...@tony.li> wrote: Hi Karen, I concur. Ship it! TOn Sep 5, 2025, at 8:29 AM, Shraddha Hegde <shrad...@juniper.net> wrote: Hi Karen, Changes look good. I approve for publication. Rgds ShraddhaOn 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://www.rfc-editor.org/authors/rfc9843-auth48diff.html%E2%80%9D. 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://www.rfc-editor.org/authors/rfc9843.xml Updated output files: https://www.rfc-editor.org/authors/rfc9843.txt https://www.rfc-editor.org/authors/rfc9843.pdf https://www.rfc-editor.org/authors/rfc9843.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9843-auth48diff.html https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html (side by side) Diff files showing only the last round of changes: https://www.rfc-editor.org/authors/rfc9843-lastdiff.html https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9843-diff.html https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9843 Best regards, Karen Moore RFC Production CenterOn 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://www.rfc-editor.org/authors/rfc9843.xml Updated output files: https://www.rfc-editor.org/authors/rfc9843.txt https://www.rfc-editor.org/authors/rfc9843.pdf https://www.rfc-editor.org/authors/rfc9843.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9843-auth48diff.html https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html (side by side) Diff files showing only the last round of changes: https://www.rfc-editor.org/authors/rfc9843-lastdiff.html https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9843-diff.html https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9843 We will await each author's approval prior to moving forward with publication. Best regards, Karen Moore RFC Production CenterOn 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://www.rfc-editor.org/authors/rfc9843.html#name-introduction 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://www.rfc-editor.org/authors/rfc9843.xml Updated output files: https://www.rfc-editor.org/authors/rfc9843.txt https://www.rfc-editor.org/authors/rfc9843.pdf https://www.rfc-editor.org/authors/rfc9843.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9843-auth48diff.html https://www.rfc-editor.org/authors/rfc9843-auth48rfcdiff.html (side by side) Diff files showing only the last round of changes: https://www.rfc-editor.org/authors/rfc9843-lastdiff.html https://www.rfc-editor.org/authors/rfc9843-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9843-diff.html https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9843 Best regards, Karen Moore RFC Production CenterOn 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://urld/ 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://urld/ 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://urld/ 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://urld/ 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://urld/ 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://urld/ 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://urld/ 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://urld/ 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://urld/ 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 CenterOn 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://url/ 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://url/ 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://url/ 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://url/ 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://url/ 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://url/ 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://url/ 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://url/ 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://url/ 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://url/ 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
