(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
