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

Nico Williams <nico@cryptonector.com> Thu, 07 November 2019 05:02 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02E0120041 for <ietf@ietfa.amsl.com>; Wed, 6 Nov 2019 21:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxtFLfQWRvla for <ietf@ietfa.amsl.com>; Wed, 6 Nov 2019 21:02:34 -0800 (PST)
Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB52120033 for <ietf@ietf.org>; Wed, 6 Nov 2019 21:02:34 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7EDAD1413BE; Thu, 7 Nov 2019 05:02:33 +0000 (UTC)
Received: from pdx1-sub0-mail-a82.g.dreamhost.com (100-96-8-64.trex.outbound.svc.cluster.local [100.96.8.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 03FC9141752; Thu, 7 Nov 2019 05:02:32 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a82.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 07 Nov 2019 05:02:33 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Illegal-Macabre: 0400a9f809a027d4_1573102953305_3366770158
X-MC-Loop-Signature: 1573102953304:3025119303
X-MC-Ingress-Time: 1573102953304
Received: from pdx1-sub0-mail-a82.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTP id A7282A0E06; Wed, 6 Nov 2019 21:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=VXvuD7HhXNesrW eFdr3ToauqFZ8=; b=Vuq94Hk15Nmxak2pM/Gw2+UFRg2+qnHQl6//Bx0smm0aWG dMyTKkKBAyDpyejim9A9ympy0gahIWXiEESPrTqUOrThmeD1Lqjb+iWOc1QXCSNk rVkL/z61u4N1kS0jn1ehDt30xAdiSPE+X5y4uKKVbQRuIqQkarhq3sMLWSGtc=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a82.g.dreamhost.com (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 <nico@cryptonector.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ralph Droms <rdroms.ietf@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>, IETF <ietf@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
Message-ID: <20191107050221.GD12148@localhost>
References: <CE06CC6D-E37F-4C90-B782-D14B1D715D4B@cable.comcast.com> <38E47448-63B4-4A5D-8A9D-3AB890EBDDDD@akamai.com> <09886edb-4302-b309-9eaa-f016c4487128@gmail.com> <26819.1572990657@localhost> <2668fa45-7667-51a6-7cb6-4b704c7fba5a@isode.com> <2C97D18E-3DA0-4A2D-8179-6D86EB835783@gmail.com> <91686B28-9583-4A8E-AF8A-E66977B1FE13@gmail.com> <012b9437-4440-915c-f1f9-b85e1b0be768@gmail.com> <20191107014849.GC12148@localhost> <57465486-71b1-a87a-fa8c-bad7157f9025@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57465486-71b1-a87a-fa8c-bad7157f9025@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/w3DzmD90cLeQOu_IjEsw9t9Ooqw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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
mechanism?

Nico
--