Hi Tony, > On Mar 4, 2023, at 4:42 PM, Tony Li <tony...@tony.li> wrote: > > > Hi all, > > IMHO, this erratum is correct, but the proposed fix is incorrect. > > In this case, the original text seeks to use ‘IS’ as an abbreviation for > ‘Intermediate System’ (i.e., router). Thus, a better fix would be: > > One of the limitations of IS-IS [ISO10589] is that the length of a > TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- > TLV, there are a number of sub-sub-TLVs (defined below) that are > supported. For a given Flex-Algorithm, it is possible that the total > number of octets required to completely define a FAD exceeds the > maximum length supported by a single FAD sub-TLV. In such cases, the > FAD MAY be split into multiple such sub-TLVs, and the content of the > multiple FAD sub-TLVs are combined to provide a complete FAD for the > Flex-Algorithm. In such a case, the fixed portion of the FAD (see > Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- > Algorithm from a given IS (Intermediate System). > > Please note the recurrence of the use of ‘IS’ in the next sentence and again > in the next paragraph.
Strictly speaking, the expansion is not required as IS in the context of IS-IS is “well-known” as per https://www.rfc-editor.org/materials/abbrev.expansion.txt. However, I agree that expansion on first use is an improvement. Thanks, Acee > > Regards, > Tony > > >> On Mar 4, 2023, at 1:28 PM, RFC Errata System <rfc-edi...@rfc-editor.org> >> wrote: >> >> The following errata report has been submitted for RFC9350, >> "IGP Flexible Algorithm". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7376 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Nikolai Malykh <nmal...@protokols.ru> >> >> Section: 6 >> >> Original Text >> ------------- >> One of the limitations of IS-IS [ISO10589] is that the length of a >> TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- >> TLV, there are a number of sub-sub-TLVs (defined below) that are >> supported. For a given Flex-Algorithm, it is possible that the total >> number of octets required to completely define a FAD exceeds the >> maximum length supported by a single FAD sub-TLV. In such cases, the >> FAD MAY be split into multiple such sub-TLVs, and the content of the >> multiple FAD sub-TLVs are combined to provide a complete FAD for the >> Flex-Algorithm. In such a case, the fixed portion of the FAD (see >> Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- >> Algorithm from a given IS. >> >> Corrected Text >> -------------- >> One of the limitations of IS-IS [ISO10589] is that the length of a >> TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- >> TLV, there are a number of sub-sub-TLVs (defined below) that are >> supported. For a given Flex-Algorithm, it is possible that the total >> number of octets required to completely define a FAD exceeds the >> maximum length supported by a single FAD sub-TLV. In such cases, the >> FAD MAY be split into multiple such sub-TLVs, and the content of the >> multiple FAD sub-TLVs are combined to provide a complete FAD for the >> Flex-Algorithm. In such a case, the fixed portion of the FAD (see >> Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- >> Algorithm from a given IS-IS. >> >> Notes >> ----- >> Incorrect name of protocol (IS instead IS-IS). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC9350 (draft-ietf-lsr-flex-algo-26) >> -------------------------------------- >> Title : IGP Flexible Algorithm >> Publication Date : February 2023 >> Author(s) : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, >> A. Gulko >> Category : PROPOSED STANDARD >> Source : Link State Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
