Re: Post-Last-Call versions of documents and change logs: suggestion to the IESG
John C Klensin <john-ietf@jck.com> Sun, 26 June 2022 18:58 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 B0DBBC18BCBC for <ietf@ietfa.amsl.com>; Sun, 26 Jun 2022 11:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywWgkn0ccT8p for <ietf@ietfa.amsl.com>; Sun, 26 Jun 2022 11:58:16 -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 8E71DC18BCBB for <ietf@ietf.org>; Sun, 26 Jun 2022 11:58:15 -0700 (PDT)
Received: from localhost ([::1] helo=JcK-HP5) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1o5XSX-000FyS-Dk; Sun, 26 Jun 2022 14:58:13 -0400
Date: Sun, 26 Jun 2022 14:58:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, ietf@ietf.org
Subject: Re: Post-Last-Call versions of documents and change logs: suggestion to the IESG
Message-ID: <D708FBE616D80785B79BD7BB@JcK-HP5>
In-Reply-To: <240f598a-ec73-2939-6911-829c52a33f1b@network-heretics.com>
References: <ED90C87AEF388AB3BF7CABCF@PSB> <d92b60a6-22a0-1790-2c1d-adf27e95a19d@gmail.com> <71A62AB6-A0C3-4C60-A3E3-A1D9966741CD@cisco.com> <C22B22F186D398F1828952E6@JcK-HP5> <240f598a-ec73-2939-6911-829c52a33f1b@network-heretics.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: ::1
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/9Z-h-cy1MTnoMQrCGUgmZF1w8lg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 26 Jun 2022 18:58:19 -0000
--On Sunday, 26 June, 2022 14:00 -0400 Keith Moore <moore@network-heretics.com> wrote: > On 6/26/22 12:43, John C Klensin wrote: > >> As I think Keith has been trying to point out, the edge cases >> rarely represent bad behavior, only difference in judgment. > > While I agree with that statement, I'm concerned about both > differences in judgment and actual (hopefully very rare) bad > behavior. We may disagree about this, but let me make another small distinction. With the understanding that I think all three are likely to be very rare, I think there are actually three separate cases: (1) Some important information that is clear to the reviewer/ protestor but that slipped through the process cracks. Such information might bear on the _correctness_ of the changes. (2) A decision to move forward despite difference of opinion about the _importance_ of the changes. (3) Bad and/or malicious behavior, including behavior as a consequence of improper influence(s). Now, I think (1) and (2) may reasonably be treated as "bad (or differences in) judgment" in spite of being rather different in substance. They are situations in which, despite good intentions and reasonable efforts, the process has failed to work as we might expect. They are the issues my note was intended to address and with which I think a few small adjustments in how we do things might help (both identify and solve). Looking narrowly at document approval, even if one AD were behaving badly, failure by the rest of the IESG to be aware of that and effectively push back would fall into one of those categories, probably (1), and the best remedy for document processing would be to draw their attention to that problem as efficiently (and with as little uproar) as possible. Dealing with the problem AD(s) would be a separate matter. For the third -- to which my note and suggestions were deliberately not addressed -- I think we would be far better off with the conventional appeal (and, if it were usable, recall) procedure. If a document is being moved forward for bad reasons, reasons the rest of the IESG is either deliberately ignoring or in which they are complicit, then that behavior should be challenged with an appeal, precisely because that process is very public, a response is required, and because, if the IESG remains part of the problem, there are clear mechanisms for taking the issue to the IAB and, if necessary and the perceived problems involve unfairness, to the ISOC BoT. If conclusion were that the AD(s) involved had behaved badly, that would presumably not only force careful reconsideration of the document but would create a record that I assume the next relevant Nomcom would not easily ignore. Because it seems to me extremely unlikely (although not impossible) that behavior that bad would occur for the first time after Last Call was initiated, affecting document review and late changes, I'd also prefer to see such complaints/ appeals filed not much later than when the Last Call is announced rather than waiting until the last possible moment, only because trying to kill the document at the very end of the process could also be viewed as bad behavior. True or not, such a claim would likely bias against an open and fair review of the appeal. However, again, not the subject of my suggestions or the concerns that drove them. best, john
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Post-Last-Call versions of documents and change l… John C Klensin
- Re: Post-Last-Call versions of documents and chan… John C Klensin
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Re: Post-Last-Call versions of documents and chan… Brian E Carpenter
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Re: Post-Last-Call versions of documents and chan… Benjamin Kaduk
- Re: Post-Last-Call versions of documents and chan… John C Klensin
- Re: Post-Last-Call versions of documents and chan… Eric Vyncke (evyncke)
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Re: Post-Last-Call versions of documents and chan… John Levine
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Re: Post-Last-Call versions of documents and chan… John C Klensin
- Re: Post-Last-Call versions of documents and chan… John C Klensin
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Re: Post-Last-Call versions of documents and chan… John C Klensin
- Re: Post-Last-Call versions of documents and chan… Keith Moore
- Re: Post-Last-Call versions of documents and chan… Stephen Farrell
- Re: Post-Last-Call versions of documents and chan… Salz, Rich
- Re: Post-Last-Call versions of documents and chan… Salz, Rich
- Re: Post-Last-Call versions of documents and chan… Larry Masinter
- Re: Post-Last-Call versions of documents and chan… John C Klensin