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

Keith Moore <> Thu, 07 November 2019 02:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B502112008F for <>; Wed, 6 Nov 2019 18:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 aFRdoVECHeq9 for <>; Wed, 6 Nov 2019 18:50:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68578120041 for <>; Wed, 6 Nov 2019 18:50:28 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 1582A21236; Wed, 6 Nov 2019 21:50:27 -0500 (EST)
Received: from mailfrontend2 ([]) by compute6.internal (MEProxy); Wed, 06 Nov 2019 21:50:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=E2Doxb MbWY+Ee9iaWHRVcAVwSTub4hgcOuKVzAnDYcQ=; b=uESNU5/TayJui5NLsu99yr 80kDC3kMsEDupg2HMekRCJ+ehR+XM+UlZbiRA9MSr1Ll9/XPZQ/TCeNLgqzWwJKW D8O0aSqcq57hobM8AXISiB7PicfDBMbKJlctchO5oP3aWibjtmKHohhEl9B1kUr6 1kEYBvzAJIv2tjm6unHF8QW4X/oC6cOnyVOLlqA7zJM5SChngCwvCJkP7zcYT27h G9TQoC/pF3gVustxTXgWV8X0dKehdq87Vfe5hCm3lZ7q4sqcddbg8iQZ/yaF6unz r+jGqtFFz6uTShJG/gw/al8XbFYG03QMs+cZ182bAeGDTrNkOF/2zbcdlltCxwHg ==
X-ME-Sender: <xms:cYbDXfaokBswM-uybE5sk2HkMnk42mX2Jg5YRkz8BP4-WLup5k3KBw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecukfhppedutdekrddvvddurddukedtrdduhe enucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgv thhitghsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:cYbDXaHLeWbybAwte66HkqP8LKFzxUo-4Fv9tpi5eiu14TkEk5F2cQ> <xmx:cYbDXY1RrDE0djTXkj_d-lQ_5LT4Ly62sbsRZ00yiocqLC8oQMN6Cw> <xmx:cYbDXacnjLlQs7ro90_1l-GeS4WwZYrvhLl1kmn1YPgC1hKO3gEAxA> <xmx:c4bDXdW66XR-a4l755gKMWPy7P0CEVr12GNp8uTfFEMuCPY2vnKRnw>
Received: from [] ( []) by (Postfix) with ESMTPA id C4DDD306005E; Wed, 6 Nov 2019 21:50:24 -0500 (EST)
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
References: <> <> <> <> <> <26819.1572990657@localhost> <> <> <> <> <20191107014849.GC12148@localhost> <>
From: Keith Moore <>
Message-ID: <>
Date: Wed, 6 Nov 2019 21:50:23 -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: <>
Content-Type: multipart/alternative; boundary="------------CBB39B8190DD94405A18B7E5"
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 02:50:31 -0000

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.

>     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.
RFC2026 also says:

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified,/*deploying implementations of such standards into a 
disruption-sensitive environment is not recommended.*/

(emphasis mine)

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.

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

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.

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