Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"

[John C Klensin <[e-mail]>]

--On Saturday, May 8, 2021 15:53 -0700 Bob Hinden
<[e-mail]> wrote:

> IESG,
> 
> I think this is good and appreciate the IESG publishing it.
> 
> There is an issue that this does not cover, that something
> needs to be done about.  It is when an Errata if filed, it
> identify the problem the Errata is addressing, and new
> includes text to fix the problem.
> 
> However, we have run into errata where the problem identified
> is correct, but the the fix to the problem is wrong.   It may
> be completely wrong, or there may be a better way to fix the
> problem.  In the worst case, it could make the problem worse.
> 
> The three states for processing an errata are:
> 
> * Verified
> * Rejected
> * Hold for Document Update
> 
> These don't address this issue.   For example, marking the
> errata as "Verified" is fine for the problem, but not good
> for the fix in the errata.    We wouldn't want implementors
> to assume the fix is correct.
> 
> I think something is needed where the reported problem can be
> accepted, but the fix can be rejected.    Perhaps some new
> states, or a change to how the Errata system works.

Bob,

While I agree with your statement of the problem, I'm not sure
about the fix :-).  And I'm afraid you just opened a can of
worms.

Let's take the two cases I think are difficult and putting aside
documents that are not on the standards track or that did not
come from a WG for the moment:

Example 1:  Text says "...Mickey is a duck".  Errata report says
'"not" is missing; Mickey is not a duck' and claims it is an
editorial matter.

Now, I would hope the RFC Editor would say "the suggestion
changes the meaning of the sentence and is consequently not
editorial" but I would hope there would be an additional set of
eyes on that decision, or any decision that something more
serious than, e.g., an obvious misspelling, is editorial.  To
reduce AD  workload, I think those eyes can safely be those of
the author(s).

Example 2: There is a real technical issue.  The assertion about
Mickey's species might turn out to be an example but I'm more
concerned about proposed errata that involve more complex
issues.  If the consensus among ADs, Authors, and present or
former WG Chairs is "whoops, the WG didn't think about that and
thinking about that now gives us a headache", then the erratum
clearly gets "save for document revision" and we move on.  But
suppose it is "Verified".  What does that mean and, coming back
to your point in particular, can an implementer rely on it?  It
does not represent IETF Consensus: there is been no IETF Last
Call and it is really the position of a handful of people.

My guess is that, at least for technical issues, "hold for
document update"  means "we are not going to think about that
now" and that "verified" means "we agree that there is probably
a problem, the proposed fix may or may not be correct, and you
will need to wait for a new RFC with IETF Consensus to get a
conclusion implementers can rely on".  The IESG should be able
to make statements about the level of their confidence in the
fix as long as it was clear that their comments must not be
confused with IETF consensus either.  That would, of course,
solve the problem you identify but has much broader
implications.  If there is agreement about "verified" not
representing IETF consensus -- even for the problem statement,
much less the fix-- I'd hope the relevant RFC Editor pages could
be updated to clearly show definitions like those and that IESG
statements could point to them.

These distinctions are particularly important if the IETF is
going to publish versions of RFCs with errata incorporated.

The only other option I can see involves putting every single
erratum with potentially substantive technical implications
through IETF Last Call before it is marked "verified".  Even if
that was not required for "rejected" or "save for document
update", to say that would not reduce AD (or community) workload
significantly would be an understatement.  

best,
   john