Re: A quick poll about RFC 7221

Erik Kline <> Sat, 12 September 2020 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F13F3A09EC for <>; Sat, 12 Sep 2020 14:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1hCZ9V1Us3Zp for <>; Sat, 12 Sep 2020 14:49:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB8E53A09E9 for <>; Sat, 12 Sep 2020 14:49:42 -0700 (PDT)
Received: by with SMTP id g16so4238336uan.5 for <>; Sat, 12 Sep 2020 14:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=v5NbmHH9oVtunw8YDu7bPqNVIl4n3fvw2cI3qI6pOKo=; b=f9+rbEGnzK5vIJIr8NIPGaSZ7lnwZ5Edsm0m4G6YM+HgbeSJqNC5ESVtFq6/U/wMXU DBZSxeXcjeSylzP1hKvKuFeeq3eJIXmafQOSb3Fq0JcA1h6bvh+R9IjQArPbVbQFVpcp NJj3cKspKvM0YfAg/NAtp+046s7JH/LcyzkXs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=v5NbmHH9oVtunw8YDu7bPqNVIl4n3fvw2cI3qI6pOKo=; b=OiA/rQjAYoZ0myK9/TEzJ67eQzSqCVt0nY+pCM1GK/QEtk0IFkvJvQpMXQQmsoczYD l/sgKn0q6AMp/TARS6AAdJBlmL16L9rBN+lPpUOmzONfhkgO87vZEPvVbuyvSOW0C1XO /Uf6oSVkSjGSOgKio7eyL0AvdoZ65vzXoKLEWDUjzuC5a+1pwlun1y+WOGCHq+IIdwFJ Lk7GYgH4v/rcK2APgcDe87F6CbmRsVvkmhRBpsIFxhmxvgydJ4kD2c41By6RfDJCyZNB hlhOBpbxkp8Ty5H/4/1x28afCfozUP/qioPLuhDfQwdvOiMTU9K2A3HjDAHcrrG8JZYz jTWg==
X-Gm-Message-State: AOAM532WA32JsHm/bTiGC3ZYBxAKixug0k60pieACnEZ6XF48NjSOMiX oh6mS8wy4o55rz2gQRWUZBmt66fzimLoc0IDMrs4eA06RWqgaw==
X-Google-Smtp-Source: ABdhPJzZxE7WeiEjyRxmHnOE1+w/A1iL/OBts8W8X0NS0bZtkYQT4uJAo1cWnhFlTp30oHGGR6ouTLvarTgZlF2ee+4=
X-Received: by 2002:ab0:5905:: with SMTP id n5mr4003424uad.90.1599947381524; Sat, 12 Sep 2020 14:49:41 -0700 (PDT)
MIME-Version: 1.0
References: <00e001d68940$bc73db70$355b9250$> <> <>
In-Reply-To: <>
From: Erik Kline <>
Date: Sat, 12 Sep 2020 14:49:30 -0700
Message-ID: <>
Subject: Re: A quick poll about RFC 7221
To: "Joel M. Halpern" <>
Cc: Carsten Bormann <>,,
Content-Type: multipart/alternative; boundary="00000000000056258c05af24c7c3"
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:49:45 -0000

On Sat, Sep 12, 2020 at 2:40 PM Joel M. Halpern <> wrote:

> 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
> document.
> 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
> unnecessary.

Sadly changes can also creep in during IETF LC and IESG eval (and during
AUTH48), without much awareness by the working group(s).  :-/

> Joel
> 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
> >