Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

[John Scudder <[e-mail]>]

Hi Les,

Yes that’s about right, except I think the changes could be processed either as a bis or as a so-called “patch” draft, i.e. one that looks substantially similar to the errata you submitted (a bunch of OLD: and NEW: blocks, for example) that Updates: RFC 8919.

The IESG has in the past discussed whether and how to avoid problems such as you describe, but so far to no effect. Because of such concerns — that even a closely-focused bis may be treated as open season for review comments unrelated to the substance of the actual changes — it’s pretty common practice for authors to use patch RFCs instead. IMO these are ugly to have floating around our document set, but our process creates a strong incentive to use them. As such, if you wanted to follow that approach I wouldn’t be against it, on the other hand if you view the bis as “the right thing” and you want to DTRT, I’d do what I can to encourage the IESG to keep their comments focused and not treat it as open season.

Hope that helps. Do let me know if we agree in principle on this as a way forward; if so I’ll close the errata.

Thanks,

—John

On May 10, 2022, at 1:08 PM, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> wrote:


John –

If I interpret the essence of your comments correctly, you are expressing a preference that the proposed changes be handled via a BIS draft rather than an errata.

I don’t have an objection to that – and in some ways it makes sense to me.
However, I have not been pleased (in general) with the way that the IETF – and in particular the IESG review process– handles BIS drafts.
A BIS is created to address specific issues. But, based on past experience,  IESG review considers a BIS draft as an opportunity to revisit the draft in its entirety – even when that was clearly NOT the stated goal during WG review.
In a case such as this, I think the lack of agreed upon scope may be a major issue.

Any words of wisdom on this? 😊

   Les

From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 10, 2022 9:20 AM
To: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8919 (6630)

-rfc-editor

Hi All,

This kind of erratum requires careful consideration and I’d appreciate it if the WG were to weigh in. In particular, without reviewing the RFC and mailing list carefully (which I’ve not yet done, but will) it’s unclear to me if the proposed erratum meets this criterion:

“Errata are meant to fix "bugs" in the specification and should not be used to change what the community meant when it approved the RFC.” [1]

So to verify this erratum we’d need one of two things:

1. A solid reason why the erratum is a straight-up bug. An example of an erratum where this is unambiguously true is https://www.rfc-editor.org/errata/eid6866<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6866__;!!NEt6yMaO-gk!DGhKp6_DX170iyhoOlLE83y4AOYlegZ0jktQIBmgAMFC0mcnlUyBUYf5awQk13zMkSQa__MPA_KloQ$>, where the RFC refers to a YANG leaf that simply doesn’t exist.
   At first reading, the present erratum isn’t obviously a bug.

2. Clear and unambiguous evidence in the written record (mainly, the mailing list archives) that the WG consensus was for what the erratum says, and not for the text in the RFC. Importantly, the authors’ saying “that is not what was intended” isn’t good enough to establish this. What must be established is what the WG had consensus for.

The bar is intentionally high for introducing changes to RFCs via the errata process. If neither of the above criteria can be fulfilled then I have to mark the erratum as rejected. In that case the recourse would be to write and process a short RFC that updates RFC 8919.

Thanks,

—John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/<https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/__;!!NEt6yMaO-gk!DGhKp6_DX170iyhoOlLE83y4AOYlegZ0jktQIBmgAMFC0mcnlUyBUYf5awQk13zMkSQa__NcYIxF0g$>

On Jul 6, 2021, at 4:27 PM, Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>> wrote:


LSR WG,

This Errata is an outcome of the Flex-Algorithm discussion - is there any further comment?

Thanks,
Acee

On 7/5/21, 5:48 PM, "RFC Errata System" <[e-mail]<mailto:[e-mail]>> wrote:

   The following errata report has been submitted for RFC8919,
   "IS-IS Application-Specific Link Attributes".

   --------------------------------------
   You may review the report below and at:
   https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6630__;!!NEt6yMaO-gk!V8pyJglE5nwp2XEvvZFMfNsgQt2U2UKisYFncXzo7IFZNV_oakn0wjZ0Ak22xg$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6630__;!!NEt6yMaO-gk!V8pyJglE5nwp2XEvvZFMfNsgQt2U2UKisYFncXzo7IFZNV_oakn0wjZ0Ak22xg$>

   --------------------------------------
   Type: Technical
   Reported by: Les Ginsberg <[e-mail]<mailto:[e-mail]>>

   Section: GLOBAL

   Original Text
   -------------
   Section 4.2:
   OLD

   If the SABM or UDABM Length in the Application Identifier Bit Mask
   is greater than 8, the entire sub-TLV MUST be ignored.

   (Later in Section 4.2)
   OLD

   If link attributes are advertised associated with zero-length
   Application Identifier Bit Masks for both standard applications and
   user-defined applications, then any standard application and/or any
   user-defined application is permitted to use that set of link
   attributes so long as there is not another set of attributes
   advertised on that same link that is associated with a non-zero-length
   Application Identifier Bit Mask with a matching Application Identifier
   Bit set.

   Section 6.2
   OLD

   Link attribute advertisements associated with zero-length Application
   Identifier Bit Masks for both standard applications and user-defined
   applications are usable by any application, subject to the
   restrictions specified in Section 4.2. If support for a new
   application is introduced on any node in a network in the presence
   of such advertisements, these advertisements are permitted to
   be used by the new application. If this is not what is intended,
   then existing advertisements MUST be readvertised with an explicit
   set of applications specified before a new application is introduced.


   Corrected Text
   --------------
   Section 4.2
   NEW

   If the SABM or UDABM Length in the Application Identifier Bit Mask
   is greater than 8, the entire sub-TLV MUST be ignored.

   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
   applications specified in the bit mask MUST use the link attribute
   advertisements in the sub-TLV.

   (Later in Section 4.2)
   NEW

   Link attributes MAY be advertised associated with zero-length
   Application Identifier Bit Masks for both standard applications and
   user-defined applications. Such link attribute advertisements MUST be
   used by standard applications and/or user defined applications when
   no link attribute advertisements with a non-zero-length Application
   Identifier Bit Mask and a matching Application Identifier Bit set are
   present for a given link. Otherwise, such link attribute advertisements
   MUST NOT be used.

   Section 6.2
   NEW

   Link attributes MAY be advertised associated with zero-length
   Application Identifier Bit Masks for both standard applications and
   user-defined applications. Such link attribute advertisements MUST be
   used by standard applications and/or user defined applications when
   no link attribute advertisements with a non-zero-length Application
   Identifier Bit Mask and a matching Application Identifier Bit set are
   present for a given link. Otherwise, such link attribute advertisements
   MUST NOT be used.

   Notes
   -----
   RFC 8919 defines advertising link attributes with zero
   length Standard Application Bit Mask (SABM) and zero length User
   Defined ApplicationBit Mask (UDABM) as a means of advertising link
   attributes that can be used by any application. However, the text uses
   the word "permitted", suggesting that the use of such advertisements
   is "optional". Such an interpretation could lead to interoperability
   issues and is not what was intended.

   The replacement text below makes explicit the specific conditions when
   such advertisements MUST be used and the specific conditions under
   which they MUST NOT be used.

   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.

   --------------------------------------
   RFC8919 (draft-ietf-isis-te-app-19)
   --------------------------------------
   Title               : IS-IS Application-Specific Link Attributes
   Publication Date    : October 2020
   Author(s)           : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake
   Category            : PROPOSED STANDARD
   Source              : Link State Routing
   Area                : Routing
   Stream              : IETF
   Verifying Party     : IESG