Re: A quick poll about RFC 7221

Carsten Bormann <> Sat, 12 September 2020 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F34323A08BA for <>; Sat, 12 Sep 2020 13:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hYl1XivbsWIX for <>; Sat, 12 Sep 2020 13:50:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F8C23A08AE for <>; Sat, 12 Sep 2020 13:50:44 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4BplBn71vqzyW4; Sat, 12 Sep 2020 22:50:41 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: A quick poll about RFC 7221
From: Carsten Bormann <>
In-Reply-To: <00e001d68940$bc73db70$355b9250$>
Date: Sat, 12 Sep 2020 22:50:41 +0200
X-Mao-Original-Outgoing-Id: 621636641.499627-c07f204c5cdc495613b28b5c590fa177
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <00e001d68940$bc73db70$355b9250$>
X-Mailer: Apple Mail (2.3608.
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 20:50:48 -0000

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