Hi Les, Thanks for the input. I’ve verified the erratum as editorial/HFDU already under the doctrine of “doesn’t hurt, might help”. Apart from other considerations, the existence of the erratum serves as further documentation that the text in question does *not* mean the protocol (IS-IS).
—John > On Mar 6, 2023, at 11:01 AM, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > > [External Email. Be cautious of content] > > > (At the risks of giving this issue more attention than it merits…) > > My interpretation of the filed Errata is that the submitter incorrectly > thought that the text should be referring to the protocol (IS-IS) and that > the text had been inadvertently truncated. Consider that the “Note” says: > > “Incorrect name of protocol (IS instead IS-IS).” > > We all agree that the text is in fact referring to a router (an IS) that > supports the IS-IS protocol. The text is therefore correct as it stands. > > Acee has pointed out further that we are not required to expand this > particular acronym on first use – therefore there really is no reason to > accept this Errata (IMHO). > > John – whatever you want to do here is fine – but I think your statement “the > lack of expansion confused at least one person” is being overly generous in > this case. > > Les > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of John Scudder > Sent: Monday, March 6, 2023 4:57 AM > To: Acee Lindem <acee.i...@gmail.com> > Cc: Peter Psenak (ppsenak) <ppse...@cisco.com>; Tony Li <tony...@tony.li>; > RFC Errata System <rfc-edi...@rfc-editor.org>; nmal...@protokols.ru; Shraddha > Hegde <shrad...@juniper.net>; Clarence Filsfils (cfilsfil) > <cfils...@cisco.com>; Ketan Talaulikar <ketant.i...@gmail.com>; > arkadiy.gu...@edwardjones.com; lsr <lsr@ietf.org> > Subject: Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376) > > “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 > perhttps://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
