(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 <[email protected]> On Behalf Of John Scudder
Sent: Monday, March 6, 2023 4:57 AM
To: Acee Lindem <[email protected]>
Cc: Peter Psenak (ppsenak) <[email protected]>; Tony Li <[email protected]>; RFC
Errata System <[email protected]>; [email protected]; Shraddha Hegde
<[email protected]>; Clarence Filsfils (cfilsfil) <[email protected]>;
Ketan Talaulikar <[email protected]>; [email protected]; lsr
<[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
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$<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
<[email protected]<mailto:[email protected]>> 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$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$>
--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZAWT6IUg$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZAWT6IUg$>
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZAWT6IUg$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZAWT6IUg$>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
