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

Nico Williams <nico@cryptonector.com> Thu, 07 November 2019 19:44 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 DAC1612099C for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2019 11:44:18 -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 vtDzkwV6884J for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2019 11:44:16 -0800 (PST)
Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (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 A760E1200F5 for <ietf@ietf.org>; Thu, 7 Nov 2019 11:44:16 -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 AFC1460106D; Thu, 7 Nov 2019 19:44:15 +0000 (UTC)
Received: from pdx1-sub0-mail-a34.g.dreamhost.com (100-96-14-250.trex.outbound.svc.cluster.local [100.96.14.250]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1978A601108; Thu, 7 Nov 2019 19:44:15 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a34.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 19:44:15 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Macabre-Language: 4750bf327ae47870_1573155855437_1326638109
X-MC-Loop-Signature: 1573155855437:2059151928
X-MC-Ingress-Time: 1573155855436
Received: from pdx1-sub0-mail-a34.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a34.g.dreamhost.com (Postfix) with ESMTP id B645CA9DFE; Thu, 7 Nov 2019 11:44:12 -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:content-transfer-encoding; s= cryptonector.com; bh=1sHHYZZJtQs+5tRWn+MVqXR7N1c=; b=SvbVoHKooKo 8YJxQdejY776mH7DrV/XuVoTK4bmrDHRXR+fe6OWvx6u7NkhcKfmck5gN/QP+Qfu MS6QXChGXsHeLX6znPr/XDKFg/dudrlTX709tQ1MHosowKsuDy9eCENoljlovTx2 aIFXMfGhxYwqAvh3vCrRFnd/dd110K+o=
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-a34.g.dreamhost.com (Postfix) with ESMTPSA id 5DDA2A9DF6; Thu, 7 Nov 2019 11:44:10 -0800 (PST)
Date: Thu, 7 Nov 2019 13:44:08 -0600
X-DH-BACKEND: pdx1-sub0-mail-a34
From: Nico Williams <nico@cryptonector.com>
To: Keith Moore <moore@network-heretics.com>
Cc: ietf@ietf.org
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
Message-ID: <20191107194408.GF12148@localhost>
References: <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> <3caeb4cf-b92b-99fd-77df-7b1aef3e2979@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <3caeb4cf-b92b-99fd-77df-7b1aef3e2979@network-heretics.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/s8Mt2RX3Z2_wl31fAJ_9N00KrN4>
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 19:44:19 -0000

On Wed, Nov 06, 2019 at 09:50:23PM -0500, Keith Moore wrote:
> On 11/6/19 9:25 PM, Brian E Carpenter wrote:
> > 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:
> 
> But 2026 criteria assumed a three-stage standards track.   Now we're down to
> two stages in theory, and still usually just one stage in practice.   As far
> as I can tell, getting rid of Draft Standard hasn't done anything to make
> Proposed Standard less of a terminal state and more of a stepping-stone.
> 
> [...]
> 
> This is where the biggest disconnect between 2026 and reality is.   If the
> reality is that industry is going to deploy implementations at Proposed
> Standard or sooner (and as far as I can tell, that's been reality for as
> long as there's been an Internet "industry"), it makes sense for IETF to
> recognize that and react accordingly.

+1

> If we want there to be a prototype "just for testing" status, it should
> probably be called something other than Proposed - the name has come to mean
> something else in IETF context.   And we should deliberately change one or

We have it: it's Experimental.  But it's essentially seen as a negative,
thus underused.

> more protocol elements to make the standard incompatible with
> already-deployed implementations.   The trick would be to keep that
> information from leaking out beforehand.    Maybe give the RSE /N/ options
> for things to change that are selected at random, similarly to the way
> nomcoms are selected.

Are you proposing that there be a required backwards-incompatible change
so as to force... what exactly?  That the old thing does not get
deployed?  I assume it will mostly discourage use of the new track.

The risk with deploying prototypes is that a backwards-incompatible
change will be needed, so perhaps early reviews should focus only on
identifying features at risk of such changes and requiring that the
experimental protocol cover upgrades or reduce the risk.

> Also, the WG completion, IESG approval and RFC publication dates of a new
> standard should be determined well in advance so that vendors can tailor
> their product development schedules to those dates.   This would mean
> holding WGs, IESG, and the RSE to a schedule (gasp!) once there was
> confidence that the document would be standardized (another argument for
> broad review well prior to Last Call.)  I'm not saying that there could
> absolutely be no slippage, but reality should be close enough that
> developers can plan by it.

Maybe, yeah, for high-profile protocols (e.g., TLS).

> But my guess is that the only way to get buy-in for Prototype specifications
> would be to convincingly promise faster development.

Yes.  That includes faster RFC-Editor turnarounds.  If we remove the
other bottlenecs, then RFC-Editor queue time will become the next
bottleneck to address.

Nico
--