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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 12 May 2021 12:10 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 1F5983A0C5D; Wed, 12 May 2021 05:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EGEaDW_P1QWX; Wed, 12 May 2021 05:10:50 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AE23A0C5C; Wed, 12 May 2021 05:10:50 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id e190so30383977ybb.10; Wed, 12 May 2021 05:10:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1YNgGx71vTUaUWbxlSkxB8q0/TWFX1rgi3YYNAwP+ew=; b=qBT7B9/MGWnteDQY4grhs0kaTEcOcQAZtxHoOgdCd21cu+3jv6TBATvGjBTfYk7lEk zsQrbNDy6OGJ8zecY5X4Mm31PVX3cqWYVeuDOLI3HsLAl31iEUwOHAW8OmpwOlqwyh5z mUe3ZM5hIWHBpAFQVbmEGhKguClPk2RFT4qqKEt4StHy+7FWSyTpOzrnM79vhGeQX8cc ZeQfuWAFtwaFU4KkIu1Nia6BzyKnOJdGY+Ca6jT2mtIDBqRxtV014WKbXXbc3Kcr7B5K qDgPaTOXF/u8CWWRXLiG2cezd+S4h3BwoVoOTFJw2N8VyNUEOP6kXfFhm9WHWC3anpmd kyvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1YNgGx71vTUaUWbxlSkxB8q0/TWFX1rgi3YYNAwP+ew=; b=Zfl0J2WQ131TYw1c0eZy/PeaktZ3q/+Sag719dIAl1hk6qZQcUMzGtNVXtfauS1+i6 VtE6zmNUv/3jjlyyRE4XaLU2afrxZjGJ6ZDho13faYkmdiD3TrUZ03S2zbsd5UHQq9PS x2HuQCO1LDHoTL/X6agea/ckBemwSgpza2VlBRjNUK2AhsfAQYPLbmNDVPAMqi60ZzdO BLtQlonQ0i/GyI9cZKMPqPXDNLmd9guYlZBEcI/NAzFObyTP2omHDmMt/MabRc6Ptfcw NvHF9nPvKGrJAkaHcd+OCrWAXzUn+RQml0LoLkxDZjF6gkCqPC9DR4gESMieh7TOKynD aq3Q==
X-Gm-Message-State: AOAM531GFD1sGPcwWqZYxGqRlNy+eyZqsUERwv2ygVB8p7IQ0yGOmslG 9dcMuf3e1x2fzhZ9Wpo0JcPEMTMlUBQFegSjlqM=
X-Google-Smtp-Source: ABdhPJz1SWwb/FkcVRZyWcpgh+N+JTsehp2qNttXLIpBS16ldYNnLKhdY0gzbbTPrLz/tWPJQdfJaik5fzTiAzemckM=
X-Received: by 2002:a25:1883:: with SMTP id 125mr46041808yby.465.1620821448804; Wed, 12 May 2021 05:10:48 -0700 (PDT)
MIME-Version: 1.0
References: <A3EDA8207BC7C8BE22C9A00C@PSB> <4FEB3D6F-E635-43FD-8DE4-FCE2B18F9775@gmail.com> <15911ECC8C711146AC9B3921@PSB>
In-Reply-To: <15911ECC8C711146AC9B3921@PSB>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 12 May 2021 07:10:37 -0500
Message-ID: <CAKKJt-db1CawHufgwPF_peh7ZQSWBw78R=e8XN=Pftzw-ghXtw@mail.gmail.com>
Subject: Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"
To: John C Klensin <john-ietf@jck.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, IETF <ietf@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b34cac05c220e60b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RHJ46HQP9bRVvt0PnBnwDBSgcRw>
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 12:10:55 -0000

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@jck.com> wrote:

> (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
>
>
>