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 02:32 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 6EE7EC15A73E; Sat, 25 Jun 2022 19:32:42 -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 jSlfaXXySEwp; Sat, 25 Jun 2022 19:32:40 -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 D1036C15A72A; Sat, 25 Jun 2022 19:32:39 -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 1o5I4j-000E0h-TO; Sat, 25 Jun 2022 22:32:37 -0400
Date: Sat, 25 Jun 2022 22:32:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, iesg@ietf.org
cc: ietf@ietf.org
Subject: Re: Post-Last-Call versions of documents and change logs: suggestion to the IESG
Message-ID: <2B75E00161A10F5B6A2A3B7D@JcK-HP5>
In-Reply-To: <d92b60a6-22a0-1790-2c1d-adf27e95a19d@gmail.com>
References: <ED90C87AEF388AB3BF7CABCF@PSB> <d92b60a6-22a0-1790-2c1d-adf27e95a19d@gmail.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/n1JLEN8mUllIdCLJawgTBegLHC0>
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 02:32:42 -0000
--On Sunday, 26 June, 2022 09:06 +1200 Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > It's already the case that if the AD considers that the > changes after Last Call and IESG review are substantive, a > second Last Call can (and should) be issued. Isn't that > sufficient? It does rely on the AD's judgment, of course, and > should probably be done more often. > > I agree about the change log, although I tend to rely on > rfcdiff or iddiff. Brian, I think that is exactly the point. Some of us prefer to rely on diffs. Others may believe that a quick review of the change log may help them decide whether a more careful review (whether by diff, by carefully reading particular sections, or both) is in order. If we want more substantive reviews from more perspectives, we should make that process as easy and accommodating to different styles as possible. I think both Ben and Keith are correct too. The best solution will almost always be the responsible AD making a judgment call as to whether an additional Last Call is needed and erring on the side of doing one when there is doubt. Change logs (as well as diffs) can help inform that decision and, if the AD's choice is to ask for a review of the changes only, help write the announcement. And, if an AD concludes the changes are not substantive enough to justify an additional Last Call but people in the community disagree, there should be a good point at which to raise those objections, ideally without the heavy weight and time-consuming nature of an appeal. 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