Re: Stray thoughts on ' Update of IESG statement "Last Call Guidance to the Community"'

Adam Roach <> Thu, 22 April 2021 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0A5C3A13FC for <>; Thu, 22 Apr 2021 15:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Status: No, score=-2.08 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, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u_J51LOvkzeK for <>; Thu, 22 Apr 2021 15:42:22 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC2103A13F7 for <>; Thu, 22 Apr 2021 15:42:22 -0700 (PDT)
Received: from Zephyrus.local ( []) (authenticated bits=0) by (8.16.1/8.16.1) with ESMTPSA id 13MMgJoh031519 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 22 Apr 2021 17:42:20 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1619131340; bh=9wsDcGoFKwsggT+M2cW7nFfgoakf/4v/6FBXxTWIC3U=; h=Subject:To:References:From:Date:In-Reply-To; b=m2N01gAgdMq0uqZ4rXJYf049G+PyJG4UyUDOZA5pBUWesoNPZyiKtqcnNHa1T4JhE gq55JE733AJCqgQgtcmVBmrxVf4tGXbPuWH0HFIfUVPu61D9etC9t9vhmemne5Rux9 9cTxmhuBy6SoEdeQV17lbRImaApD8dkBHJnXnn0w=
X-Authentication-Warning: Host [] claimed to be Zephyrus.local
Subject: Re: Stray thoughts on ' Update of IESG statement "Last Call Guidance to the Community"'
To: Keith Moore <>,
References: <> <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Thu, 22 Apr 2021 17:42:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Apr 2021 22:42:27 -0000

On 4/22/21 17:27, Keith Moore wrote:
> On 4/22/21 4:59 PM, Adam Roach wrote:
>> On 4/22/21 15:40, Brian E Carpenter wrote:
>>> Tom,
>>>> Last, comments from organised review teams should be sent to the last
>>>> call list as opposed to being made available to the community.
>>> The last call list *is* available to the community, so this is just
>>> being more specific about what "available to the community" means.
>>> Is that a problem?
>> More pointedly -- it lets folks see discussions of IETF work product 
>> without them getting lost among (checks notes) 150 messages about a 
>> New York Times article, 132 posts about QUIC and DNSSEC, and 234 
>> messages about inclusiveness.
>> I'm not necessarily saying these topics aren't worth discussing; but 
>> it's important to get broad consensus on the documents we publish as 
>> RFCs, and we can't afford to lose those conversations under the crush 
>> of high-volume topics. The risk of documents in last call getting 
>> lost in the noise is far more of a barrier to being "available to the 
>> community" than the use of a dedicated mailing list.
> One can credibly make the opposite argument also: that it's hard to 
> find the time/patience to scan all of the Last Call discussions that 
> happen, just so you can be "in the loop" for the relatively rare Last 
> Call discussions that seem important to you. 

That's the same argument on a smaller scale: I asserted that we needed 
(and then benefited from) a smaller haystack for the needles of 
interest, and you're saying that the new, much smaller haystack may 
still be too large for effective needle finding.

And it's a reasonable argument. I agree with the implication that 
last-call@ was merely an improvement and not perfection, and something 
like what you imply -- even finer grained breakdown than ietf@ and 
last-call@ -- *might* be even *more* of an improvement.