“Hold For Document Update” is exactly for the purpose [1] of making nominal but inessential improvements. This one seems roughly on the level of “trivial grammar correction” (item 4 of [1]) which is in-scope for HFDU, and apparently the lack of expansion confused at least one person, so I’m inclined to verify as HFDU with Tony’s text, unless there’s a strong case not to.
—John [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ On Mar 6, 2023, at 7:39 AM, Acee Lindem <acee.i...@gmail.com> wrote: 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://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$ . 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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$ -------------------------------------- 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZAWT6IUg$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZAWT6IUg$
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
