IETF Logo Mail Archive

Re: Post-Last-Call versions of documents and change logs: suggestion to the IESG

Benjamin Kaduk <kaduk@mit.edu> Sat, 25 June 2022 23:32 UTC

Return-Path: <kaduk@mit.edu>
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 4467EC15CF5C; Sat, 25 Jun 2022 16:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
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 v63wbdpu3Uyg; Sat, 25 Jun 2022 16:32:21 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA88C15AACB; Sat, 25 Jun 2022 16:32:20 -0700 (PDT)
Received: from kduck.mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 25PNW9rH029036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 25 Jun 2022 19:32:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1656199937; bh=o6qegayWzZAlWi2rEYwr+jMkeEtZ5evm109+CZO1g94=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=caFTg9wSX/87e7mvu4GQliv3ZfilXzoq+8sJc7KtSowBEX8bZ3/SWOMsdzBw2HhIQ 1TCoh/WjbAZRhxg5NM5BaXSGb/a0LDCMf7gYdxdGRmACbA2ATV2KDeNCSUAY1y6m/w dYaT/3ghhcbJPhkR+QTlB8rVZWNw6eM5Le7sJv+uFZFFvXVPYkV802+X3eviMNpXE5 bh3WGXrABuA34Hsiwm8lZ/OvW50huaN/7GZo6C+gJRqv0FmUoNOXo7hC9lUVTaHuqm hGBmNQuCNKOCuoy1FNPgVdCVQxroJInsLXsYQIi3pV7IwLokza7LsbWR4lsgkHS47m Q2DYH0rjcDBcA==
Date: Sat, 25 Jun 2022 16:32:08 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: John C Klensin <john-ietf@jck.com>, iesg@ietf.org, ietf@ietf.org
Subject: Re: Post-Last-Call versions of documents and change logs: suggestion to the IESG
Message-ID: <20220625233208.GK26442@kduck.mit.edu>
References: <ED90C87AEF388AB3BF7CABCF@PSB> <d92b60a6-22a0-1790-2c1d-adf27e95a19d@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d92b60a6-22a0-1790-2c1d-adf27e95a19d@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Ey4wTsILX9mrqJxXs20wdVe8bZY>
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: Sat, 25 Jun 2022 23:32:23 -0000

On Sun, Jun 26, 2022 at 09:06:15AM +1200, Brian E Carpenter wrote:
> (Front posting to avoid a TL;DR.)
> 
> 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 think that the trend in the last couple years of my time on the IESG was
towards doing it more often.  In the face of data on the time documents
spend in various states over their lifecycle, the extra few weeks delay is
usually worth it for the added confidence in the new text.
I'm happy to leave it as a judgment call alongside giving some guidance to
the IESG to err on the side of doing another Last Call.

A strict rule has an unfortunate failure mode of making it fairly easy to
get stuck in a loop of repeated Last Calls for increasingly minor
changes...

-Ben

v2.23.0 | Report a Bug | By Email