Re: [Rfced-future] Why the RFC series is important

Carsten Bormann <cabo@tzi.org> Mon, 25 May 2020 21:12 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8D23A0945 for <rfced-future@ietfa.amsl.com>; Mon, 25 May 2020 14:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 15GtY5DGqzO3 for <rfced-future@ietfa.amsl.com>; Mon, 25 May 2020 14:12:48 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102203A0936 for <Rfced-future@iab.org>; Mon, 25 May 2020 14:12:47 -0700 (PDT)
Received: from [172.16.42.112] (p548dc699.dip0.t-ipconnect.de [84.141.198.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49W8tz2Pzgzyg6; Mon, 25 May 2020 23:12:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <alpine.OSX.2.22.407.2005251504530.26397@ary.qy>
Date: Mon, 25 May 2020 23:12:42 +0200
Cc: Rfced-future@iab.org
X-Mao-Original-Outgoing-Id: 612133962.550801-4517bffa984a506bbf3bd3b26a48076e
Content-Transfer-Encoding: quoted-printable
Message-Id: <821BC38D-97E3-4976-8571-1427CF747627@tzi.org>
References: <alpine.OSX.2.22.407.2005251504530.26397@ary.qy>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/hhqJu-TG2l7sw1O4b2rq1Vwe2a8>
Subject: Re: [Rfced-future] Why the RFC series is important
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2020 21:12:53 -0000

On 2020-05-25, at 22:42, John R Levine <johnl@taugh.com> wrote:
> 
> I am not proposing specific changes other than to say that the model of RFCs solely as independent immutable documents no longer makes sense. While I do not suggest we go to WHATWG style living documents, I do think that for our specifications we need to find a more modern way to collect the material into a small number of places with stable names (perhaps using version numbers like everyone else does), and to make discrete low cost updates as we find errors or make partial updates.

The diagnosis appears to presume a therapy here.

However, most of the problems are with the high-energy approval process of the IETF stream, which makes it impractical to do actual revisions of documents without exposing previous consensus to new attacks and subjecting it to current political and technical fashions.

So we publish updates to updates to updates, and almost never do consolidated versions like they are being done in lawmaking.

We also don’t have a lot of roadmap documents (*).  Nobody gets points for writing them.  The IESG loathes having to review them as consensus documents, so informational documents of this kind are discouraged instead of encouraged.  (Really, no WG should be chartered without securing the energy to write up how its output works together with existing specifications!)

Not much of that is a consequence of the RFC process, it is really a stream issue.

(We could try to repair the stream by exerting pressure from the output end, but I’m not sure that would work very well.  **We need to be able to actually do the work**, first!)

Grüße, Carsten

(*) On 2020-04-17, I wrote:
Yes, we have had a few roadmap documents (RFC 4614/7414 comes to mind, or RFC 6071).
The TCP roadmap is the only example I can find where such a roadmap was actually published again as revised RFC.
Because of the immense effort needed to generate a consensus RFC with this information, some roadmaps never were pushed to RFC (e.g., draft-bormann-6lo-6lowpan-roadmap-00.txt, draft-bormann-core-roadmap-05.txt); others were just published as articles (the ultimate fate of the latter roadmap was https://DOI.org/10.1109/MIC.2012.29).

We never developed roadmapping into an element of our culture, but we could.