[Tools-discuss] Expiry Doctrine (Re: Expired draft on the w.g. status pages [was Re: disappearing IDs on www.ietf.org])

Carsten Bormann <cabo@tzi.org> Sat, 12 September 2020 08:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AAF3A0F28 for <tools-discuss@ietfa.amsl.com>; Sat, 12 Sep 2020 01:31:27 -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 4Xne-BThpQ6w for <tools-discuss@ietfa.amsl.com>; Sat, 12 Sep 2020 01:31:24 -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 BDE793A0F26 for <tools-discuss@ietf.org>; Sat, 12 Sep 2020 01:31:23 -0700 (PDT)
Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4BpQnk0hvNzyRj; Sat, 12 Sep 2020 10:31:22 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <C44C644D-C24A-4839-BB61-F758AA2D7BF1@vigilsec.com>
Date: Sat, 12 Sep 2020 10:31:21 +0200
Cc: Bob Hinden <bob.hinden@gmail.com>, Tools Team Discussion <tools-discuss@ietf.org>
X-Mao-Original-Outgoing-Id: 621592281.437448-6d06143d5b6994b3e9e793203708daf2
Content-Transfer-Encoding: quoted-printable
Message-Id: <BCB7C223-EFDE-46D3-A4E2-82068C688547@tzi.org>
References: <8657.1599751932@localhost> <84c8d593-c7b6-4327-338f-9b2b0e7a36e0@levkowetz.com> <0C6D4DE2-F9F3-4C7C-8427-264F34C8C2B7@tzi.org> <26d795d2-3761-2950-4346-62f849d86eed@nostrum.com> <7792.1599768579@localhost> <C73D6AB9-694E-458E-AEEE-45DBDEF623C5@vigilsec.com> <3B281EED-CDCE-4025-8C78-7BA689490936@tzi.org> <5B0C691F-EA59-44E9-959F-52445CA58314@gmail.com> <41EEFFCD-DEB9-4950-95B1-F43ACC73CAF1@vigilsec.com> <2F82E43A-39CF-4C99-BE9E-CD84D2BE21B3@gmail.com> <C44C644D-C24A-4839-BB61-F758AA2D7BF1@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/m7JpGhYlI_qYgo_jq0tn4ocERUQ>
Subject: [Tools-discuss] Expiry Doctrine (Re: Expired draft on the w.g. status pages [was Re: disappearing IDs on www.ietf.org])
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Sep 2020 08:31:28 -0000

On 2020-09-11, at 20:59, Russ Housley <housley@vigilsec.com> wrote:
> 
> I disagree.  If the I-D has expired, it should not be shown there.

A little Saturday metacomment:

This is a nice example of “process confabulation”, designing software for what SHOULD happen, not for what actually DOES (and NEEDS TO) happen.

Our discussion of Internet-Drafts is dominated by what I’ll call the “Expiry Doctrine” — Internet-Drafts expire and then no longer exist.  Since this doctrine is obviously unworkable per se, we patch it up by providing a separate archive of expired drafts.

What actually happens is that URLs for Internet-Drafts are generated by various pieces of software (email, web pages) and propagate into other places.  At the time they are first generated, these Internet-Drafts are not expired yet.  The expiry doctrine makes us delete the data behind these URLs at expiry time, making the URLs we use for Internet-Drafts *unstable* URIs.

The archive can be addressed by *stable* URIs, but these are not the ones generated during the pre-expiry usage of Internet-Drafts.  Stable URIs need to be generated manually, which mostly does not happen at the time the URIs propagate into various places.

The tools server has been providing stable URIs throughout for Internet-Drafts (both for a single draft and for an entire series of revisions), which is probably a strong reason most people have been using tools server URIs (and still continue to do so) instead of the unstable “official” URIs to link to Internet-drafts.  Since the tools server has not been updated for the v3 world, there is now more incentive to use the “official” infrastructure, and the problems caused by the process confabulation surface once again.

The only true fix is to stop constraining ourselves by the expiry doctrine, and instead design the systems for what we are actually doing (and want to be doing!) with them.  Bridge pages like the ones I proposed are more patches and may restore some workability while continuing to pay lip service to the expiry doctrine and enduring the problems it creates.

How do we represent the (desirable) aspects of expiry without trying, unsuccessfully, to live the expiry doctrine?
By making expiry (and replacement) a dynamic *property* of a draft.  (Note that there is text in each draft that describes the current value of this property based on the current date — this text is actually more likely untrue than true, and this has caused all kinds of problems with people taking the text at face value.  Instead it should point to a resource where the true current state can be ascertained.)

I cannot finish this note without noticing how all this is not in the domain of the RFC editor — we have kept the domain of authoring and progressing documents out of this domain and are continuously baffled by the process discontinuities that the cliff between authoring and publishing creates.  We need to think about the entire process of RFC creation in a unified way to reduce the obstacles.

Grüße, Carsten