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

Nico Williams <> Thu, 07 November 2019 05:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D02E0120041 for <>; Wed, 6 Nov 2019 21:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SxtFLfQWRvla for <>; Wed, 6 Nov 2019 21:02:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EB52120033 for <>; Wed, 6 Nov 2019 21:02:34 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 7EDAD1413BE; Thu, 7 Nov 2019 05:02:33 +0000 (UTC)
Received: from (100-96-8-64.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 03FC9141752; Thu, 7 Nov 2019 05:02:32 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ([TEMPUNAVAIL]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.5); Thu, 07 Nov 2019 05:02:33 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Illegal-Macabre: 0400a9f809a027d4_1573102953305_3366770158
X-MC-Loop-Signature: 1573102953304:3025119303
X-MC-Ingress-Time: 1573102953304
Received: from (localhost []) by (Postfix) with ESMTP id A7282A0E06; Wed, 6 Nov 2019 21:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=VXvuD7HhXNesrW eFdr3ToauqFZ8=; b=Vuq94Hk15Nmxak2pM/Gw2+UFRg2+qnHQl6//Bx0smm0aWG dMyTKkKBAyDpyejim9A9ympy0gahIWXiEESPrTqUOrThmeD1Lqjb+iWOc1QXCSNk rVkL/z61u4N1kS0jn1ehDt30xAdiSPE+X5y4uKKVbQRuIqQkarhq3sMLWSGtc=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 75F72A1125; Wed, 6 Nov 2019 21:02:24 -0800 (PST)
Date: Wed, 6 Nov 2019 23:02:22 -0600
X-DH-BACKEND: pdx1-sub0-mail-a82
From: Nico Williams <>
To: Brian E Carpenter <>
Cc: Bob Hinden <>, Ralph Droms <>, Alexey Melnikov <>, IETF <>, Michael Richardson <>
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
Message-ID: <20191107050221.GD12148@localhost>
References: <> <> <> <26819.1572990657@localhost> <> <> <> <> <20191107014849.GC12148@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
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 05:02:36 -0000

On Thu, Nov 07, 2019 at 03:25:40PM +1300, Brian E Carpenter wrote:
> 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.

When most of our documents are PS -when PS is the new Standard!- this
really does mean doing away with IESG review.  Nothing obligates anyone
to do the work to move PS to DS and then S.

> 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, but picking good chairs now becomes essential, but finding chairs
as good as ADs will be difficult.

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

Perhaps so.  But then we'd better find a way to incentivize moving PS
docs to DS and S, or give up the fiction.

> >> [...]. 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.

That's a fair observation.  But, too, we could ask the IESG to take a
lighter approach to publication as PS.

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

Implementation Status for PS?  But that will drag us into the I-D
stability thread all over again -- it's a catch-22: how can we develop a
protocol, implement it, and test it but not deploy it (despite a very
strong market desire for it) without some sort of I-D stability