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

[Carsten Bormann <[e-mail]>]

On 2020-09-11, at 20:59, Russ Housley <[e-mail]> 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