Re: A quick poll about RFC 7221

David Noveck <> Sun, 13 September 2020 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 133CC3A0544 for <>; Sun, 13 Sep 2020 05:50:27 -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 1uMQriFvhqBo for <>; Sun, 13 Sep 2020 05:50:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E5EE3A053E for <>; Sun, 13 Sep 2020 05:50:25 -0700 (PDT)
Received: by with SMTP id nw23so19459539ejb.4 for <>; Sun, 13 Sep 2020 05:50:25 -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=i/Q9ir/c+akGMGZwFj2rtxeL/MWs3I0pezLdVTQV6uE=; b=O4MExySXojWhnL9WmrD+N5aSJltKaCANYeKiUdJmTtRea2BAnkPzUV1oe69OKr5gjN /kHjA2kiUPfW3cRyL5mQxTRpnovPljBNhfF7DHizkpoJA3/53EH7tKZJRdWGoukf9Vgd Z2gsm4Wrq6g48+bQr7PJzpm54tSBR2tgvRF3zbeWDmw//QUJLr8tRNNuOjbeAQlxWXrQ x/HP/twDyCQP1C9dhvYpKrYS0o8UK06CMYiBmq2ZgjqGGLjNMoHOtgqmaU4lGbbon0SR nv/uy8hbgvjtCUI73NrjccGLRrkPhhdH3AiOTwVRUuqB4ipgNDbPvllwbSL+w795cuan 26ww==
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=i/Q9ir/c+akGMGZwFj2rtxeL/MWs3I0pezLdVTQV6uE=; b=K8z//qpILmtrObnNOEW74g6dHPO/MPZWaBQDg630KZRDxAGnlGv5YktF3vQZN7fqWD 5VzD9x0P2KHKlkBfqDZ+iCghD67Wtw/Id+FabsEFl3Hh5y7bEVlFt4OUfiWILHLOt909 /IECqioAammJzxmqm5BHinw6b44zqNK0/c9qy2kg98NOVxrlAuxVpRiv8dDZA1YNAn2w 52OSjSUPzamixl9VtnmlCoplTnAbOB2Mo/ONxtG1c42cIY3BIw2+hIa3BdSMmucC5hZr LWORd3qJNx2/xj6fqOKy8X3lT4880n0ojDW3elGF1hBPkc8MIjBsa+Xxl8DYbuzwQ03l htVA==
X-Gm-Message-State: AOAM533Kcqcnz+ZdVKWr3BvFv2QdCkbl7qlv1YAC3Dmz3600ws4XliEp rJMQoSJXs5QN7/3S3pg602cEH2tr54PdoCLVRew=
X-Google-Smtp-Source: ABdhPJyAKn+YGsn7rvHnqAWQtJzcANFu1X57tUPe3osbi2JlaxTDMhZ/bGJtgZNmzSgzeBY81YPKrunv0ehmNgHaw2M=
X-Received: by 2002:a17:906:2b97:: with SMTP id m23mr10185165ejg.61.1600001423521; Sun, 13 Sep 2020 05:50:23 -0700 (PDT)
MIME-Version: 1.0
References: <00e001d68940$bc73db70$355b9250$> <> <> <>
In-Reply-To: <>
From: David Noveck <>
Date: Sun, 13 Sep 2020 08:50:10 -0400
Message-ID: <>
Subject: Re: A quick poll about RFC 7221
To: Erik Kline <>
Cc: "Joel M. Halpern" <>,, WG Chairs <>
Content-Type: multipart/alternative; boundary="0000000000007d3e5305af315c51"
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:50:27 -0000

I haven't seen this be a major problem in recent years, although it is an
illustration of the fact that, once WGLC has happened, its ownership of the
document has effectively lapsed and only the authors have a role in dealing
with potential changes that would interfere with the wg consensus.

Way back in 2003, the internationalization section of rfc3530 was
essentially rewritten at IESG direction.  The fact that the wg was not
aware of the change meant that nobody implemented it.  As a result, all
nfsv4 implementations followed the WGLC document rather than the iesg's
revision. The wg had the last word since they were the implementers as
well.  This was all corrected for nfsv4.0 by rfc7530

I'm not sure what would have happened if the wg had been made aware of this
change but the process would probably have been quite contentious. It
almost certainly would have prevented rfc5661 internationalization from
following the unimplemented rfc3530 one. We now have to deal with this as
part of rfc5661bis.  Sigh!

On Sat, Sep 12, 2020, 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
>> >