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

[tom petch <[e-mail]>]

On 12/05/2021 02:17, John C Klensin wrote:
> (trying again.  Again, my apologies -- explanation on request)
>
> --On Tuesday, May 11, 2021 22:51 +0100 Stewart Bryant
> <[e-mail]> wrote:
>
>>> On 11 May 2021, at 20:24, John C Klensin <[e-mail]>
>>> wrote:
>
>>>> ...
>>>> The AD can edit the text and provide a solution that works.
>>>
>>> And which has IETF consensus?
>>
>> In  the majority of cases the resolution of an erratum  is a
>> simple obvious fix.
>
> Indeed.  And in even a larger majority of cases, it is obvious
> that a reported erratum either correctly identified the problem
> or resulted from significant confusion on the part of the
> reporter (which might be a separate problem).
>
> I'm concerned about the other cases, but your comment suggests
> a way to streamline processing even more than the current IESG
> Statement suggests. Consider the following steps after
> submission:
>
> (1) If the reported error is in a document produced by a WG
> that is still active, the report goes to them. If they decide
> they want to deal with it, they can either verify or reject or
> just identify it as "Held for Document Update" (and,
> potentially, decide to go to work on it). If they cannot reach
> consensus (either on reviewing or on what action to take, the
> status should clearly be "Held for Document Update". Other than
> some quick administrative actions, neither the RFC Editor nor
> any IESG member need to be involved. In any event, modulo the
> usual appeal provisions, their decision is final.
>
> (2) The RFC Editor, in consultation with the author(s), make a
> determination of whether the matter is a simple editorial issue
> and, if so, whether the proposed fix is correct. If the answer
> to both questions is "yes", then the report is verified.
> Otherwise, go to the next step.
>
> (3) Some relevant AD (obviously the one who worked on the
> document earlier if there is such a person) consults with
> authors, present or former WG chairs, and, at their discretion,
> other ADs and anyone else who seems relevant. They make a
> determination as to whether the problem is correctly identified
> and the proposed fix is correct, simple, and obvious. If those
> who are consulted can reach consensus, the report is either
> verified, rejected, or classified as "held for...". If they
> cannot agree, the matter is sufficiently controversial that
> "Held for Document Update" is the correct status
> classification. It would be a good idea to announce that
> decision to the community in case someone sees issues the
> review team missed or otherwise objects but I'd see that as a
> monthly or per-IETF-meeting summary, not noise on the IETF list
> (or even a relevant ex-WG list) per reported error.

John,

Mostly, I agree but would suggest two wrinkles.

One is that when the WG who produced the RFC is not longer active, there 
may be a successor WG which is competent to reach consensus on the 
erratum, e.g. ipsecme, lamps, and I think that whether or not such a 
group exists is a judgement call for an AD from the area, so I would 
insert such a step - pass to Area AD to see if another WG can step in - 
before going to the RFC Editor (whom I would not see as necessariy 
having skills in that field).

Second, you say that 'Hold for Document Update' makes it painfully clear 
that there is no IETF consensus on the problem.  I disagree.  The Editor 
page says that this status says that it is not a necessaary update, may 
be considered for a future update which to me has always implied that 
this may not be an error at all, rather out of scope at present, a 
request for a functional change, such as to make a product compliant to 
the RFC:-).  SO there may be a clear consensus, not right at this time.

Tom Petch

> So, if things are simple and obvious, they get dealt with very
> quickly and efficiently. Or, if they are not, they get
> classified as "Held for Document Update", which makes it
> painfully clear to the reader that there is no IETF consensus
> on the problem and solution. It also puts the decision as to
> what to do about the report when there is no conensus back into
> our normal process rather than using errata reports for
> non-obvious problems or solutions as a means of changing
> documents with little or no community input.
>
> There is obvious potential for DoS attacks in both the above
> and in the IETF Statement as it now stands, but our current
> procedures for dealing with people who are disruptive ought to
> be perfectly adequate to handle them.
>
> best,
>     john
>
>
> .
>