Top posting, just to say that we can talk about the details, but John's proposal seems very helpful at putting the responsibility for errata handling on an existing working group, that is at least theoretically already chartered to work on a document update, rather than on an AD, who is not.
Where there is no existing working group, we are no worse off than we are, today.
So, I like this enough to encourage people to think about this proposal.
And if (for example) a TSV AD can look at an errata for an RFC that the concluded MPTCP working group produced and say "the existing working group that should handle this is TCPM", we'd be better off, except in cases where a serious (and I presume technical) errata is submitted for an RFC that no existing working group is chartered to work on.
Maybe that's not a huge problem. If it is, we can figure out what The Right Thing To Do is for those cases, and do that.
Best,
Spencer
On Tue, May 11, 2021, 20:18 John C Klensin <john-ietf@xxxxxxx> wrote:
(trying again. Again, my apologies -- explanation on request)
--On Tuesday, May 11, 2021 22:51 +0100 Stewart Bryant
<stewart.bryant@xxxxxxxxx> wrote:
>> On 11 May 2021, at 20:24, John C Klensin <john-ietf@xxxxxxx>
>> 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.
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
