Hi Les, I apologize for having missed your reply earlier. I think the outcome would have been the same in terms of rejecting the errata, but I wish I’d replied first. I’ll reply now since I think some of your points still deserve attention.
> On May 11, 2022, at 2:46 PM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > John – > > Don’t know if you have completed your review of the mailing list archives on > this subject. > > Given it is almost a year since the discussion, I had to review it myself. 😊 > Here are some pointers: > > The discussion started with an email from Bruno asking for some clarification: > https://mailarchive.ietf.org/arch/msg/lsr/DrehmMy9Ru7CNPTfAMmyCofXjTY/ > > > This led to proposed Errata for RFC 8919/8920 – the discussion of which can > be found here: > > https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1&q=%22Proposed%20Errata%20for%20RFCs%208919%2F8920%22 > > Given the protracted discussions on the drafts which became RFC 8919/8920, I > am not eager to do a BIS draft simply to insert a clarification. > > I do think the discussion of the Errata on the list could be considered as > achieving consensus. To be clear, the standard to process an erratum isn’t that there be consensus to do so. The standard is that the erratum has to reflect the consensus that existed *at the time the RFC was created*. To quote from the IESG statement, "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.” So, it has to be possible to unambiguously document that the consensus existed at that time; this can be challenging, and the AD has to start from the presumption that the plain language of the RFC is what there was consensus for. > There are then two options: > > 1)Use the errata to document the clarifications I hope the above helps explain why I didn’t feel able to verify the proposed errata. > 2)Use a “patch RFC” > > I have never done a “patch RFC” – wasn’t even aware this option existed. And > I am not clear on how it is done procedurally – is this simply a new draft > but everyone agrees to limit discussion given the “patch format”? Basically yes. An example of a good “patch” document is draft-ietf-lamps-8410-ku-clarifications-01 — it’s tightly scoped to revising the language of a single section. An example of a “patch” document that is proving problematic is draft-ietf-lamps-cmp-updates-20, because of the volume and scope of the changes. If you go looking, you can find lots of examples of these kinds of documents, some groups use them more than others. I’m not saying this is a *good* thing, but it’s a thing. > Frankly, I don’t see the difference between the Errata and the “patch RFC”- > other than the latter is more work. An RFC goes through the IETF consensus process. An erratum doesn’t. (I mean, we could change our procedures to require consensus for Errata, but that’s not how they stand.) > Certainly content-wise they are the same. > So your comment that Errata are only meant to address “bugs” doesn’t make it > clear why a “patch RFC” is OK but an Errata that has the same textual changes > is not. I hope the above, plus the IESG statement I shared earlier (again, https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/) has made it clearer. Feel free to keep asking if it’s still unclear. > I would prefer to use the Errata if possible. > > Your thoughts? I’ll follow up to your/Bruno's later email with further thoughts. —John > > Les > > From: Lsr <[email protected]> On Behalf Of John Scudder > Sent: Tuesday, May 10, 2022 11:16 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Acee Lindem (acee) <[email protected]>; Peter Psenak (ppsenak) > <[email protected]>; [email protected]; [email protected]; John E > Drake <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Re: [Lsr] [Technical Errata Reported] RFC8919 (6630) > > 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) <[email protected]> > 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 <[email protected]> > Sent: Tuesday, May 10, 2022 9:20 AM > To: Acee Lindem (acee) <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]> > Cc: Peter Psenak (ppsenak) <[email protected]>; [email protected]; > [email protected]; John E Drake <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected] > 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, 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/ > > On Jul 6, 2021, at 4:27 PM, Acee Lindem (acee) <[email protected]> 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" <[email protected]> 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$ > > -------------------------------------- > Type: Technical > Reported by: Les Ginsberg <[email protected]> > > 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 > > > _______________________________________________ > Lsr mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EBV-D0cwvUZ1lrN7YuWEU8G2XxeQvbjZhMTnOUutn7m8UVtzu-Py4sLsXB-sDISJm784xV64fim6dQQWFy9SrLddrFmg$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
