Re: A quick poll about RFC 7221

"Andrew G. Malis" <> Sun, 13 September 2020 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30DFA3A03EE for <>; Sun, 13 Sep 2020 05:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v4ShOYoZk1sR for <>; Sun, 13 Sep 2020 05:44:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FD263A03FB for <>; Sun, 13 Sep 2020 05:44:37 -0700 (PDT)
Received: by with SMTP id v54so11443585qtj.7 for <>; Sun, 13 Sep 2020 05:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dgWwA94JMnwwgBNE5zg1tbYINksqfvcmB41+bXDJdOA=; b=G1zxKGJ8FNH7LslxsXwyUET0b031LOLyEs1PXIruWA7CemJzX1t9HbFs5li2dttQPi 7/dZqrglSZCCpn26Lj9/eVo6wuh1od2Mst02RloRHGNJByttgy4hN7koi4GPDMbQGRK4 4kzW4U5NokISFxXOj5cBz4/GeBvWP5zgErbV2/tcA4GKsP7+7laqaCVY2+xCy7cBQssC zkN5jAOt+VurAfSwUyt3bRQ+oAjE9i5Pu11WUKRhBzvUXZgow0x9nH9fY8FkRgsYQCWx xz5qYm7z0s65TwDcQXaVVqLP4MO7ogyP0U+5e6gVOlnua+3Loe5OCHRcB+zci1mXGyGX MNjw==
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:from:date :message-id:subject:to:cc; bh=dgWwA94JMnwwgBNE5zg1tbYINksqfvcmB41+bXDJdOA=; b=MiatrDQjAdC193pMjDWqZZGY3hCt3Hvk00CX+smGiqJDEvCWmYndAwuX6TimQ6amu5 JMcQ+EQasHZKkBRez7Dt3HqBqtaFmZno360F7YEDSFwZ9uW9wM/8+zPm0toRtZJAG3wd sQrVwIWaERCOLQ2T43s1pEPpCR9JlWkeKftqySr9YFPIuRJrYJEYXT3Wta+p3Gm+K+0m ybA9svfrRhtlmvP24DgKyWfjXz9Ntj43UI9pu1TgN/wFC7r96O/byv0RYamd0BbdhJUi lrBpBdvGM2KFHii6JeBAYR5JM4tlFBRZOkPa9wNHksFHxP6gwbSfSRFk7T94J16Cpfu7 JFkA==
X-Gm-Message-State: AOAM532gu6UT8FiZJdUv4GWD6oZrbYTvaVtj3UKTyvBrJp820uDwpXpc Rj49FnnEwC/EkoOlPSWM02QhguqOIvAwlgxc/Uc=
X-Google-Smtp-Source: ABdhPJxHeEFA7d3fM1Ed+uwg8zt3aJBfW9c594FstukksstWdExLIzw+Oqw79WtoXTRFJzkErsty0748yWyqDqOC88A=
X-Received: by 2002:ac8:435e:: with SMTP id a30mr5222449qtn.201.1600001076568; Sun, 13 Sep 2020 05:44:36 -0700 (PDT)
MIME-Version: 1.0
References: <00e001d68940$bc73db70$355b9250$> <> <> <>
In-Reply-To: <>
From: "Andrew G. Malis" <>
Date: Sun, 13 Sep 2020 08:44:25 -0400
Message-ID: <>
Subject: Re: A quick poll about RFC 7221
To: Erik Kline <>
Cc: "Joel M. Halpern" <>, Adrian Farrel <>, Working Group Chairs <>
Content-Type: multipart/alternative; boundary="000000000000cf262805af314702"
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: Sun, 13 Sep 2020 12:44:39 -0000


During IETF LC and IESG eval, all new revisions are uploaded to the
datatracker and are announced by email, so anyone interested can see the
changes. And the WG is copied on most, if not all, of the discussion of the
changes. And finally, during this process the WG chairs and especially the
ADs are watching very closely.

During AUTH48, all changes should only (at least in theory) be editorial in
nature. In addition to the authors, the document shepherd, WG chairs and
ADs are all copied on all of the emails and see the changes, so again,
there are plenty of eyes on the process.


On Sat, Sep 12, 2020 at 5:49 PM Erik Kline <> wrote:

> 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).  :-/
> Yours,
>> 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
>> >