Hi Peter, I agree it is not an errata. We really don’t want to set precedence of having published RFC text nominally improved via Errata. I’ve copied John for Errata resolution.
Thanks, Acee > On Mar 6, 2023, at 4:14 AM, Peter Psenak <ppse...@cisco.com> wrote: > > Acee, > > if you ask me, I would not do anything. "IS" is correct in the text and it's > well known. > > my 2c, > Peter > > > On 05/03/2023 14:32, Acee Lindem wrote: >> 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
