Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
John C Klensin <john-ietf@jck.com> Wed, 12 May 2021 01:17 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFA73A2DBC; Tue, 11 May 2021 18:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wu2lPLnzp0M; Tue, 11 May 2021 18:17:29 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769003A2DBB; Tue, 11 May 2021 18:17:29 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lgdV9-000D7E-Ru; Tue, 11 May 2021 21:17:27 -0400
Date: Tue, 11 May 2021 21:17:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
cc: Alvaro Retana <aretana.ietf@gmail.com>, Bob Hinden <bob.hinden@gmail.com>, IESG <iesg@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
Message-ID: <15911ECC8C711146AC9B3921@PSB>
In-Reply-To: <4FEB3D6F-E635-43FD-8DE4-FCE2B18F9775@gmail.com>
References: <A3EDA8207BC7C8BE22C9A00C@PSB> <4FEB3D6F-E635-43FD-8DE4-FCE2B18F9775@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/R3LhP50R85muUYEhSZYniR4uVkU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 01:17:34 -0000
(trying again. Again, my apologies -- explanation on request) --On Tuesday, May 11, 2021 22:51 +0100 Stewart Bryant <stewart.bryant@gmail.com> wrote: >> On 11 May 2021, at 20:24, John C Klensin <john-ietf@jck.com> >> 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
- Re: Updated IESG Statement "IESG Processing of RF… Brian E Carpenter
- Re: Updated IESG Statement "IESG Processing of RF… Eric Vyncke (evyncke)
- Re: Updated IESG Statement "IESG Processing of RF… Michael Richardson
- Re: Updated IESG Statement "IESG Processing of RF… Brian E Carpenter
- Re: Updated IESG Statement "IESG Processing of RF… Bob Hinden
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… tom petch
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… otroan
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… Lloyd W
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Michael Richardson
- Re: Updated IESG Statement "IESG Processing of RF… Alvaro Retana
- Re: Updated IESG Statement "IESG Processing of RF… Brian E Carpenter
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… Lloyd W
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… lloyd.wood@yahoo.co.uk
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… Julian Reschke
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant
- Re: Updated IESG Statement "IESG Processing of RF… Bob Hinden
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant
- Re: Updated IESG Statement "IESG Processing of RF… Carsten Bormann
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Ole Jacobsen
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… John C Klensin
- Re: Updated IESG Statement "IESG Processing of RF… Spencer Dawkins at IETF
- Re: Updated IESG Statement "IESG Processing of RF… tom petch
- Re: Updated IESG Statement "IESG Processing of RF… Stewart Bryant