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

Carsten Bormann <cabo@tzi.org> Mon, 10 May 2021 06:58 UTC

Return-Path: <cabo@tzi.org>
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 E19B63A0833; Sun, 9 May 2021 23:58:51 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 m1uGIJNY2Mu0; Sun, 9 May 2021 23:58:47 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7E33A0825; Sun, 9 May 2021 23:58:47 -0700 (PDT)
Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FdsN36pHWzyW5; Mon, 10 May 2021 08:58:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <243B59C0-05D7-4F08-AE4D-4022099C6637@employees.org>
Date: Mon, 10 May 2021 08:58:43 +0200
Cc: IESG <iesg@ietf.org>, IETF <ietf@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
X-Mao-Original-Outgoing-Id: 642322723.1361639-6f9fe3a72b52d59321707c698d748af7
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEBFBDA6-626B-4576-8F88-025D799107C4@tzi.org>
References: <162040549861.22240.16336069769197991691@ietfa.amsl.com> <18d87dd8-3363-ef49-36f6-a34ff8c60e59@gmail.com> <63FC3945-4207-4CA9-8B25-38ACD4A51BCF@gmail.com> <243B59C0-05D7-4F08-AE4D-4022099C6637@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7umq0MoDZG6eDz0C-m0Ph4HRlP0>
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: Mon, 10 May 2021 06:58:52 -0000

On 2021-05-10, at 08:31, otroan@employees.org wrote:
> 
> A clearer distinction between a reported document bug and a verified errata could be a start.

Yes.  

(1) We need to stop calling errata reports that are not (yet) verified, “errata”.

The errata are the problems that we *agree* exist.
(Each single such problem is an erratum, BTW.)

Section 4.8.6.5 of RFC 7322 MUST die, die, die.

(My own errata report about the incorrect terminology of that section was almost rejected…  https://www.rfc-editor.org/errata/eid6347 (*))

(2) When an errata report is indeed verified, it should be OPTIONAL whether the suggested solution is also verified.  I’m not unhappy about the idea of last-calling an actual solution instead, after it has been discussed and shaped by authors and the WG (or the WG’s old mailing list, or a dispatch WG if that doesn’t exist).

Grüße, Carsten

(*)  [Err4409] [Err4963] [Err4964] were attempts to change the (admittedly not so bright, after all) WG consensus after the fact.  They are still cited as “errata” in RFC 8949 in Appendix G, where we discuss how we handled the errata reports on its predecessor RFC 7049.  Reason did not prevail over Section 4.8.6.5.