Re: A quick poll about RFC 7221

"Joel M. Halpern" <> Sat, 12 September 2020 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4FFC3A09F0 for <>; Sat, 12 Sep 2020 14:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Status: No, score=-3.046 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.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 1opaO210Gtf5 for <>; Sat, 12 Sep 2020 14:39:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE7903A09E3 for <>; Sat, 12 Sep 2020 14:39:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BpmHg5TfZz4TG0n; Sat, 12 Sep 2020 14:39:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1599946799; bh=sZ6KT99d/7wqH3HDR1ehtBf1x1qTJX9Y3/QSLUUJ6O8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=p9CiONJeGT0gLbYOHIgqWc5H/xSDdTLqCclPh9xdImewDGfjxWTCYHS8z6LSJZEAr fzboCyxCbYgkPyCVk+0YDPwA6mqvo5llsNYyC1eznhXe8WCLthFA9skllTY5+nf8xJ nINqjZR919NXEPEBCOC7/Y9MbSxi7f8S9y+WeuM4=
X-Quarantine-ID: <HtdUt5K8Uf6M>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4BpmHf2Q2Hz4TFSq; Sat, 12 Sep 2020 14:39:58 -0700 (PDT)
Subject: Re: A quick poll about RFC 7221
To: Carsten Bormann <>,
References: <00e001d68940$bc73db70$355b9250$> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sat, 12 Sep 2020 17:39:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Sep 2020 21:40:01 -0000

Actually Carsten, I would phrase your comment differently.

We allow the editors of documents to make changes during the process. 
We expect them to tell the WG what they are doing.
The important part is that if the WG disagrees, the editors are required 
(not merely expected, required) to make the changes to conform with the 
WG rough consensus.

Many years ago I fired a WG document editor for refusing to do so.
I have come close to doing so more than once since.

The document belongs to the WG, not to the editor.
For practical reasons, we allow the editors a lot of room to work on the 

The WG LC should, if things are going right, serve as a final 
confirmation that nothing has gone wrong.  That does not mean it is 


On 9/12/2020 4:50 PM, Carsten Bormann wrote:
> Interesting.  I didn’t actively know about this document.
> (I might have heard about it in 2014, but have since forgotten about it.)
> The title is misleading:
>             Handling of Internet-Drafts by IETF Working Groups
> Instead, it mostly is about adoption of WG documents (and the selection of authors for that segment of its life), except for the introduction where it states in passing that a WG document is (at least substantively) always representing the WG rough consensus.
> This is the second time I need to use the term “process confabulation” today.  While having this statement in an (albeit informational) document is a great stick with which WG chairs can beat up errant authors, it does not reflect reality (even if it does more so in the times of development by github than it used to be), not even an actually always desired process.  (If it actually were true, we wouldn’t need a WGLC.)
> The reality is that in many WGs, authors have pretty wide authority [sic!] to generate new I-Ds that they believe will bring the process forward, and obtain feedback [that could be (but most often is not) judged by the WG chairs to represent WG consensus] only after publishing the new I-D.  Very large WGs may have more elaborate processes that might be closer to mini-WGLCs before accepting changes (in particular with github’s help), but as a universal process requirement, requiring consensus before publishing each update would really impede progress.  The WG needs something concrete to discuss, and I-Ds are that concrete writeup that is input, not output of the current discussion.
> Grüße, Carsten