Re: Thought experiment [Re: Quality of Directorate reviews]

Brian E Carpenter <> Thu, 07 November 2019 02:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E23131200F3 for <>; Wed, 6 Nov 2019 18:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ozdpB66Ch9_u for <>; Wed, 6 Nov 2019 18:25:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1185812008F for <>; Wed, 6 Nov 2019 18:25:45 -0800 (PST)
Received: by with SMTP id y24so356156plr.12 for <>; Wed, 06 Nov 2019 18:25:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EpBrku2KMVwdcffinPKyrpa+8GMmfAUyhiN6HwL4mwM=; b=NN1dP6JiXLCYAidx8LahQ9cRnM330uHM8peOcqEO3/vngRtn6NkYt+iRh4nOPRfhvA /GTvcx6yow5bFvJ4pGRuQu3J5kCOIIW64eZ/StlpjX+UO5ff624Lq3Dleka01s3oqeiL ezUSg9Lab0M9N3voS1BsVt0UmESb4Jriq+IeZmOCt0bDoUlWyA8Hh0xdGmfbzsUOYob6 gX2cv3ivcuiGi+EZLlZZwz4XgANmMW2y8jfE2vvAfdQv1McpVbce/H1kUpFCUQ3sNHex N8o3ar+4LpB9kW4WoFwUFRydAYui+53oq6hFWpB5ovA8UKFsoRw23YNJelaqCpekIqhG SSkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EpBrku2KMVwdcffinPKyrpa+8GMmfAUyhiN6HwL4mwM=; b=PZpu9kHPyNYUVvszF8RASkzK5xs/5IJ6BJaZfepiYzb3Gm8/V9lXVAMVquLlOpXuFq OdSakRPTnnZ/gdiFJULRcGH2iAK8voihLvXQ2dJ8ZvKrUBOk4/4uxZJuZVwHn61HAk3c r1ZqsVkOVUC6oRE8xKxFCBPQvJ1jmM33LP09GeSNGuh0RNYc5WtLCnJE8V2BhX4I2OxP UZwYrbf8H2SLXk4yS9L2qFtO5QKfaPaOS2Npb7hQyqomgaUxPgK8p7ggL4WMp8uyF7Fw ijCZVycVKMd6DG/mTsjB3TwGYzoP+noBae6f/WyiwPwcbgJsh0xO+uPxJPPJ1BeVwBu0 6dTA==
X-Gm-Message-State: APjAAAW7CkEFyyXUDHtY7hVI4p9aymS37mOUSXD3f/5gMGQjcNqRTDUi 3KlJqbFab+TtJCOQpa/+0N8=
X-Google-Smtp-Source: APXvYqxnNVjH8i/vokyOxQ14idqIpHMuUSnkGIohnORcjnC9Fojz8Sd76QOfKI7oQmduDW7ca0tAyg==
X-Received: by 2002:a17:902:6b4c:: with SMTP id g12mr1077301plt.78.1573093544136; Wed, 06 Nov 2019 18:25:44 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id m65sm5463416pje.3.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 18:25:43 -0800 (PST)
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
To: Nico Williams <>
Cc: Bob Hinden <>, Ralph Droms <>, Alexey Melnikov <>, IETF <>, Michael Richardson <>
References: <> <> <> <> <> <26819.1572990657@localhost> <> <> <> <> <20191107014849.GC12148@localhost>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 7 Nov 2019 15:25:40 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191107014849.GC12148@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2019 02:25:47 -0000

On 07-Nov-19 14:48, Nico Williams wrote:
> On Thu, Nov 07, 2019 at 11:54:59AM +1300, Brian E Carpenter wrote:
>> Here's a thought experiment.
>> Update the standards process such that the approval of Proposed Standard
>> RFCs, after an IETF last call including some specified cross-area review
>> requirements, is done by the WG consensus process with the consent of the AD .
>> Why would that work? Because it now incents the WG chairs by making them,
>> in effect, where the buck stops. So the WG chairs and AD (typically
>> a committee of three) will feel the obligation to get everything
>> right. And it scales.
> So, no more IESG review?  What would we need the IESG for anymore?  It
> would be gone, I guess?

Not at all. Firstly, I said *Proposed* Standard. The experiment would leave
the IESG in charge for Internet Standard. (Also for documents submitted
outside the WG process, which is rare of course.) And the criterion is
still IETF rough consensus following an IETF last call. Just trying
to eliminate a manifest bottleneck.

Secondly, they'd still be the authority for chartering, appointing
WG chairs, appointing directorates, and other aspects of overseeing
the process. Most of the duties described in RFC 2026 in fact.

> Sure, it will scale better.  But quality will suffer.

And maybe some documents will spend fewer than, say, 2 years in MISSREF.
Speed vs quality is indeed a trade-off. In the era of rapid prototyping
our timescale really looks pretty stupid.

>> [...]. So the WG chairs and AD (typically a committee of three) [...]
> Typically one of the ADs is uninvolved with a WG for which the other is
> responsible, so that would be a committee of two, not three.

Two WG chairs is almost the norm these days. But yes, the essence of
the experiment is to reduce the number of people in the decision
process - and intentionally lower the bar for Proposed Standard closer
to how it's defined in RFC2026:
   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.
When I look at some the DISCUSSes I've seen in recent months, I really
don't think that definition is being applied.

I would also add to my thought experiment a mandatory Implementation
Status section. That's stronger than RFC2026.