> On Mar 6, 2023, at 7:57 AM, John Scudder <j...@juniper.net> wrote: > > “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.
My point was that the RFC editor guidelines for acronym expansion would not require “IS” first-use expansion. However, this expansion could fall under the following text from https://www.rfc-editor.org/materials/abbrev.expansion.txt: However, since there are so many different abbreviations and there is a range of knowledge among RFC readers, we tend to expand abbreviations in case of doubt. So, HDFU would be fine as well. Thanks, Acee > > —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
