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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 November 2019 20:07 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 DBBCF120255 for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2019 12:07:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 x_56tQNE5j8Z for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2019 12:07:45 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F06120044 for <ietf@ietf.org>; Thu, 7 Nov 2019 12:07:44 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 093C63897B for <ietf@ietf.org>; Thu, 7 Nov 2019 15:04:46 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1FE90913 for <ietf@ietf.org>; Thu, 7 Nov 2019 15:07:43 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IETF <ietf@ietf.org>
Subject: Re: Thought experiment [Re: Quality of Directorate reviews]
In-Reply-To: <012b9437-4440-915c-f1f9-b85e1b0be768@gmail.com>
References: <157279399807.13506.13363770981495597049.idtracker@ietfa.amsl.com> <0EF64763-BA25-468A-B387-91445A61D318@gmail.com> <CAJU8_nUovmFmgNiYx0ez_1f+GPdU9xGViDYWfowEEomrn0pyDw@mail.gmail.com> <alpine.LRH.2.21.1911040841160.27600@bofh.nohats.ca> <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>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 07 Nov 2019 15:07:43 -0500
Message-ID: <10457.1573157263@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/voi5NutLTe74gCJvR6gHmPcPbzQ>
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 20:07:47 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > 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.

I was not a fan of the proposal to designate an Internet-Draft as a stable
document, because I felt that it was basically creating a new level of
document status. (Another hurdle)

Your proposal is almost the same, but I like it because I feel that instead
of adding a hurdle, it is removing one.

Would you consider if these new documents are *RFC*s or, would you consider
if we could make a new document series for these documents? I would suggest
that it become the *Proposed Standard* series.  That is, we'd change our
first step to not be an *RFC*.

I believe that this would solve the problems that the stable-document
proponents were trying to create, while not adding a new step to the process.

I would want such RFCPS or WGPS, etc. to go through the RPC.
This fixes all the english, references, etc. issues, and of course causes
IANA assignments.

Upon being finished processing, the exact XML would be returned to the WG to
collect errata, interop experience and clarification, setting things up for
the "bis" document that would then be ready for Internet Standard (RFC).

This also synchronizes our notion of what an RFC is with what the industry
thinks is an RFC.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-