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

Keith Moore <> Thu, 07 November 2019 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BA881209B0 for <>; Thu, 7 Nov 2019 13:15:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=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 a8t6EthKxy4M for <>; Thu, 7 Nov 2019 13:15:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD2A11209C8 for <>; Thu, 7 Nov 2019 13:14:58 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id CB009209B5; Thu, 7 Nov 2019 16:14:57 -0500 (EST)
Received: from mailfrontend2 ([]) by compute6.internal (MEProxy); Thu, 07 Nov 2019 16:14:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=jexkWyoHwvz8/b8z4kP2GWyy+Tuw1zeCoEU31HcBV RY=; b=n1S/xrA53E/Q1Yk80NgmSP4IrgaFoUUPUAipzvBdyPNeja2ncaDTxagRU +0LsgnW6bSz/RyI5PfE89Jrl2/8XWtGcdl5yWSGdsMKPPZsyZAMxHO8j9te/MRfp fuYLFHZQw3FarPSMf04CtP1BTtaTXoULYYytmv4PkjoJ0cN1l5RffWgoRMuoxvW+ u5pF6s+HsLoarhiwt0ujjSyLxLce8uKi3yQk+tQU1crnKTIRAfnAqHQHyWpjgMu8 As+PDL6RZjtjGorq3fuitZi82E3gcBmYVE2O/+rGUyddvDgfUHzks3b32InnrhXq duLZtklGkDhABTu85DEohRCiEBR5Q==
X-ME-Sender: <xms:UInEXX8kRf_4Yxj1P_TcD9qbDBgLEi98T6MPPZWBZYnHHAw0wMB7QQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduledgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghi thhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtoh hmqeenucfkphepuddtkedrvddvuddrudektddrudehnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomhenucevlhhush htvghrufhiiigvpedt
X-ME-Proxy: <xmx:UInEXcjgDqG_v3a7bggGxSf_V3Klo55YsIWLk5esB7mmJ-SOlTp3OA> <xmx:UInEXbWtEi3XIGSLAVYKJx1iX9sv4FECcJRcSY0NRG9l5GE7sAl61A> <xmx:UInEXaEJbQNBUODyq9uDU_M2NHzsEckjOokzLPvbO6_nQcRJvwx2hg> <xmx:UYnEXW_NN2iFLeHAVufcPE4gL7sqEMad_sGXe-iW-nU9DDCtfSPXDQ>
Received: from [] ( []) by (Postfix) with ESMTPA id C9302306005B; Thu, 7 Nov 2019 16:14:55 -0500 (EST)
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
To: Nico Williams <>
References: <> <> <26819.1572990657@localhost> <> <> <> <> <20191107014849.GC12148@localhost> <> <> <20191107194408.GF12148@localhost>
From: Keith Moore <>
Message-ID: <>
Date: Thu, 7 Nov 2019 16:14:54 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191107194408.GF12148@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 21:15:12 -0000

On 11/7/19 2:44 PM, Nico Williams wrote:

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

Experimental doesn't imply that there's an intention to standardize a 
protocol, though this does happen in rare cases.

Though now that I think about it, the right way to denote prototype 
status is probably to designate specific Internet-Drafts rather than to 
publish them as RFCs.   RFC publication isn't designed for temporary 

>> 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 purpose is to remove some of the incentives to deploy protocol 
implementations before they're approved, while still allowing 
implementations and meaningful interoperability tests. When things are 
prematurely deployed it puts pressure on the WG and/or IESG to accept 
specifications that have significant flaws. It can also harm IETF's 
reputation when implementations don't meet the specification or don't 

> 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.
IMO one of the primary reasons for early reviews is to learn as early as 
possible whether an intended direction or protocol design choice would 
create or exacerbate tussles that could be addressed, and/or have 
adverse effects on other interests that might compel a different 
direction or choice.    It goes beyond "identifying features" because 
it's not always individual features that cause the conflicts.
>> 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.

I was thinking earlier today that the biggest waster of time and energy 
might be when IETF invests years of volunteer effort on specifications 
that turn out to be not very useful.   Even worse might be when IETF 
increases complexity (of implementations, operations, etc.) that doesn't 
result in a tremendous benefit to the Internet user community.

(It's easy to pay more attention to things that are easily measured, 
than those that are not, even though the easily measured quantities 
might not be the most relevant ones.)