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

Robert Sparks <> Sat, 12 September 2020 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3708F3A0C20 for <>; Sat, 12 Sep 2020 09:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.027
X-Spam-Status: No, score=-3.027 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, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hrg27jUCQ3AE for <>; Sat, 12 Sep 2020 09:57:23 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50CC83A0C1F for <>; Sat, 12 Sep 2020 09:57:23 -0700 (PDT)
Received: from unescapeable.local ([]) (authenticated bits=0) by (8.16.1/8.15.2) with ESMTPSA id 08CGvKOh002696 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <>; Sat, 12 Sep 2020 11:57:22 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1599929842; bh=BdrhhVFm4qtA9i3AObcoTPcSp6ji6wUBm5tGlTRRFGI=; h=Subject:To:References:From:Date:In-Reply-To; b=VJGpAH6CtPCC0RJEaKh9j3AFEW7u7xenBa8NdIqlsdsGvVR7YmK8f9Iaf3s4hO4gQ I4DPAJ6qnmV3A147tvuRLsOcIyZhYkVjkg+A9cPazRIk8HXv2nQuk6+bbpSJLx+NK1 QJecFBFhRUdD3+NNGBqPYQxt3L/KPejBGKRb1bxk=
X-Authentication-Warning: Host [] claimed to be unescapeable.local
References: <8657.1599751932@localhost> <> <> <> <7792.1599768579@localhost> <> <> <> <> <> <> <>
From: Robert Sparks <>
Message-ID: <>
Date: Sat, 12 Sep 2020 11:57:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Tools-discuss] Expiry Doctrine (Re: Expired draft on the w.g. status pages [was Re: disappearing IDs on])
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Sep 2020 16:57:27 -0000

One minor, but I think important, tweak to your commentary.

On 9/12/20 3:31 AM, Carsten Bormann wrote:
> On 2020-09-11, at 20:59, Russ Housley <> 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.
The archive is _all_ drafts, not just expired ones - the active ones are 
there too. It is the stable thing you are asking for already. The 
question I'm hearing is do we point more things at that by default.
> 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
> Please report and
> bugs at
> or send email to
> Please report bugs at
> or send email to