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.