Re: Post-Last-Call versions of documents and change logs: suggestion to the IESG
John C Klensin <john-ietf@jck.com> Tue, 28 June 2022 20:51 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 B002DC147920; Tue, 28 Jun 2022 13:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 JkRcBVDUtFG9; Tue, 28 Jun 2022 13:51:43 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 9E0EDC14F720; Tue, 28 Jun 2022 13:51:41 -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 1o6IBP-000Mop-6p; Tue, 28 Jun 2022 16:51:39 -0400
Date: Tue, 28 Jun 2022 16:51:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: Larry Masinter <LMM@acm.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
cc: 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: <49AEE408E06F0409A9BB3063@PSB>
In-Reply-To: <CAKq15verKs0PnJD3L-_wypbdWNTApXUWdj3QA+SGkhyihqyWJQ@mail.gmail.com>
References: <ED90C87AEF388AB3BF7CABCF@PSB> <d92b60a6-22a0-1790-2c1d-adf27e95a19d@gmail.com> <5e7888ed-5acc-36d3-e148-1c253366cebc@network-heretics.com> <7609D78E-39C0-47DD-9A1B-7D2126FC8E60@akamai.com> <CAKq15verKs0PnJD3L-_wypbdWNTApXUWdj3QA+SGkhyihqyWJQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/0Z0117iHaE4iEpW8vRz2mYdpEv0>
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: Tue, 28 Jun 2022 20:51:43 -0000
--On Monday, June 27, 2022 10:56 -0700 Larry Masinter <LMM@acm.org> wrote: > Post last-call changes are reviewed by authors, wg chairs, ad > and now AUTH48-list reviewers. > If an objectionable change is made despite those reviews, > there is the recourse of errata or an "updates" RFC. > > I think the situation is covered. Larry, I should probably just let this lie but, given a possible problematic example that has come up in the last few hours... In recent years, we have made increasingly strong assertions that any document published in the IETF Stream represents IETF consensus. For a document produced by a WG, there is at least a general understanding that it represents WG consensus as well and that, if the IETF (presumably during IESG review or later) overrules the consensus of the WG and the WG does not review the changes and agree, that would be clearly documented [1]. Those two assertions of consensus are actually rather strong and they are about the document as published, not about some earlier draft. Without knowing how closely people will watch the AUTH48 logs, especially for documents about which they not are specifically concerned, I think we are asking the first three categories of people above to make two rather separate decisions. The first is the one that I think has been assumed all along, which is whether the document reflects Last Call comments as appropriate and is correct, internally consistent, and consistent with other work. Your "situation is covered" comment suggests that we also expect them to make a decision about IETF and WG consensus about the final product, presumably by reading the community's collective mind. I think Ben and Éric (at least) have suggested a solution that goes beyond your "situation is covered" and that is already in effect: reopening the Last Call if there is any doubt about either the correctness of the changes or community consensus about them... and, if in doubt, erring on the side of reopening that Last Call. In posting my initial note in this thread, I was concerned about two things: (i) While they are (or, in Ben's case, were), IMO, doing exactly the right thing, that has not always been the policy in the past and there are no guarantees about the future. (ii) No one, not even the IESG, is infallible in judgments about community consensus, especially when the community has not been asked some of the questions. I thought a really lightweight mechanism for saying "looks like this is ok to go ahead without another Last Call; if anyone has a substantive reason for disagreeing (without revisiting old arguments), speak up now" would do the job. Other suggestions, such as forcing an additional or extended Last Call if any changes occur after the original Last Call (or after IESG approval) occur, have been made. My personal view (and others have said much the same thing) is that forcing those additional formal community reviews would introduce significant delays in an already too-slow process to protect us against a very small number of cases. That would make it a bad tradeoff even though that position has some theoretical attraction. Let's try to find a balance about this, one that takes advantage of the reviews you cite and the good judgment of ADs but that does not completely substitute their judgment for that of the community. If the rest of the IESG agrees and will behave in similar ways, I think Éric's and Ben's comments get us about 75% of the way there. I'd say about 90% if there were an IESG policy statement along the same lines that takes group responsibility for not voting on documents (or handing them off to the RFC Editor) that have undergone significant changes since the Last Call started. That would move things a bit further along than the preferences or judgments of individual ADs and the other 10% would probably be rare enough that appeals would be an appropriate remedy. But I don't see the present state of affairs, especially without an extra Last Call on documents that have clearly undergone significant changes, as "covered". best, john [1] At the very least, a participant in the WG who supported the original document but questioned or disagreed with some of the changes would have, IMO, excellent grounds for appeal and, if needed, carrying that appeal all the way on the grounds that the procedure followed was unfair.
- 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