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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 12 September 2020 20:31 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 B668F3A0DEC for <tools-discuss@ietfa.amsl.com>; Sat, 12 Sep 2020 13:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level:
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6-zfLQR7Wo3o for <tools-discuss@ietfa.amsl.com>; Sat, 12 Sep 2020 13:31:51 -0700 (PDT)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C64D3A0DE7 for <tools-discuss@ietf.org>; Sat, 12 Sep 2020 13:31:51 -0700 (PDT)
Received: by mail-pg1-x544.google.com with SMTP id j34so8664058pgi.7 for <tools-discuss@ietf.org>; Sat, 12 Sep 2020 13:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=18pivJCsknhbsA2fUSYgCLyDryxiJ3Jnf2KZM/0gsKA=; b=B7PsNmAoIqTSDPFRXPPXzGkFcpct/oluwmFgXmvsAsGLsb/Wmy0sbUbIrjwAm91WKN JWlflbiJCdeKoNW7cUoAUDoxN3IZAsf+vnWVV9cJFeXqt2pg3JrahspV6rmsxVZMAt18 hrmUxu6MXY9yoBQe+rtKbVaHTLMexmaRIxpKlhxVIyAaH6lxnBtifzpfPpI5jVPErPe1 Ss7KZgeTNyHxPPkdMSpMqFKIM2RTIq3pZtlhSrfmh5fhijStV2cTreRIpeGK0jSI++qJ aFJk0aZo0Cu9qiO1vQ1kbLnP6n5sAZu3Fg+jCPGtfkPXJrQ/aun7t8NhIfE1B+FG5THj DfOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=18pivJCsknhbsA2fUSYgCLyDryxiJ3Jnf2KZM/0gsKA=; b=J2dlo/djPDxtIGw1igBkXtV7AmzlJU6v5AOIekmzDlseEhggE7fkuB6c5T0ZRUAgOa jfBcw4IPZMIWPB8pN48/oKv7CGWDabyZAnb1U0AyCNn9URettOmssOeX50l3TVYlv5Ed XvDsp/9jyKYxSWVJmq6SzoZ+2aMhTS2ceS/3EBnQa57dnsxhgDIGHRDSpXht9l71hj6k trf9Oj9Alud0n4DeqmdD73sSJn7OxMLx7GpaS70pLQJMxil1/7+F5bzi400MIsiwu7Ni tLZwgiA/PHv9dZ38XWJkbsIdNO9AAwF1OfpJtHmV8OuxuPz0ujgZsuQm52ivraN1XF6Z D1JQ==
X-Gm-Message-State: AOAM530UOv7oIUhjEPuvVLFHXHHshrEcceVvY7Ag6/XOvAU0A3GBS7xm BpOt/rI8EJypwZeGWpHNFfw1Vxfwj00=
X-Google-Smtp-Source: ABdhPJwKKZGpdzNcPDTptpyx8TEA80DhITSL3aKqb9/dnxAyGIgeiObBj06hnaHKEFwvOSlmNeFW5A==
X-Received: by 2002:a63:1b65:: with SMTP id b37mr6040409pgm.453.1599942710447; Sat, 12 Sep 2020 13:31:50 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id e62sm5945996pfh.76.2020.09.12.13.31.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Sep 2020 13:31:49 -0700 (PDT)
To: Carsten Bormann <cabo@tzi.org>, Russ Housley <housley@vigilsec.com>
Cc: Tools Team Discussion <tools-discuss@ietf.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> <BCB7C223-EFDE-46D3-A4E2-82068C688547@tzi.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <95e1bae1-88b1-9df8-8bf5-c4f51b7bc081@gmail.com>
Date: Sun, 13 Sep 2020 08:31:47 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <BCB7C223-EFDE-46D3-A4E2-82068C688547@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/ypz61Xw2CCVRBbUN3B8BrXjYQnc>
Subject: Re: [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 20:31:53 -0000

On 12-Sep-20 20:31, Carsten Bormann wrote:
> 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.

And what SHOULD happen is defined in RFC2026, our most basic process document.
I don't think we can blame the official tools for following the official rules.
There are 14 RFCs that update RFC2026 already, so one more can't do much harm.

   Brian
> 
> 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
> 
> ___________________________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datatracker-project@ietf.org
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster@tools.ietf.org
>