Subject: SUMMARY: Processing of expired Internet-Drafts

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 28 Jan 2004 18:15:48 -0800

Just to make one thing clear....

The published processing of expired Internet-Drafts was intended to be a 
reasonably small change to existing procedures.

That's not to say that the procedures are going to live forever. But we 
don't want to make bigger changes than we have to until we're ready to 
overhaul the whole system (and know why).

Anyway, back to the summary..... I've tried to represent what people said, 
and group them into a few topics. Conclusions (mine) at the end.

* Use of tombstone files.
Current procedure is to create tombstone files whenever an I-D is no longer 
valid (withdrawn, expired, published as RFC).
Arguments raised are that a file of "old names" is better (Fred, Ted, Eric 
F) or a separate directory (Carl) or a search system (Alexey).

* Tombstones and expiry.
Current procedure is to make them live forever.
Arguments raised are that 700 IDs per year produce a lot of tombstones 
(Fred, Ken), and that we could expire them after 6 months (Zefram, Fred) or 
2 years (David Morris).
My argument is that we've lived with the present system since 2001, and 
produced only around 2500 tombstones; it's not worth bothering to change 
that until we change the system more dramatically.

* Tombstones and version numbers:
Current procedure is to expire name-nn, create tombstone name-nn+1, and if 
it is resurrected, to resurrect as name-nn+1.
(Until some time ago, the tombstone was name-nn)
Arguments raised are that 2 files with the same name and different content 
is a Bad Thing, and that we should increment the number once again for a 
new version (Fred, Zefram, Jim Galvin), or use another extension for 
tombstones (David Morris).
One problem seen is searching for name+1 will now give a hit (Carl), and 
that maintaining mirrors is harder (Fred).
The problem of mirroring can be cleanly solved with rsync (Thomas), or 
comparing file sizes (someone else).

* Status of drafts:
Current procedure is to let the version-numbered files, including 
tombstones, serve as status information, as well as 1id-index listing the 
current drafts.
Argument is that a name without the version number would be more easy to 
find (Iljitch); this is easy to make when you need it (Scott Brim), and 
exists at www.watersprings.org (among other places (Tim Chown) and 
www.potaroo.net (Geoff)

Conclusions, all mine:

- Documenting current procedures is good.
- We won't expire tombstones. They're not a big enough problem yet.
- We'll think about naming tombstones something else than the exact draft 
name (for instance draft-whatever-version-nn-expired.txt???)
- We'll note the issue of referencing names without the version number as 
input for thinking about overhauling the whole I-D system. But that won't 
happen very quickly - it "mostly works".

Seems to make sense?

                        Harald

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 29 Jan 2004 14:18:06 -0600

On 1/28/2004 8:15 PM, Harald Tveit Alvestrand wrote:

> Conclusions, all mine:
> 
> - Documenting current procedures is good. - We won't expire tombstones.
> They're not a big enough problem yet. - We'll think about naming
> tombstones something else than the exact draft name (for instance
> draft-whatever-version-nn-expired.txt???) - We'll note the issue of
> referencing names without the version number as input for thinking
> about overhauling the whole I-D system. But that won't happen very
> quickly - it "mostly works".
> 
> Seems to make sense?

How about using the draft name without a version number as placeholder?
That placeholder file can either reference the current version, or it can
contain the tombstone text. For example, draft-whatever.txt can either
contain a pointer to draft-whatever-nn.txt or can contain text that the
last version of that I-D was -nn but has since expired.

That eliminates naming collisions, allows for mirroring based on the
filedate alone, and provides a running reference to the latest version
which can either be fetched directly (if active) or can be retrieved from
an archival system (if expired). Other useful information could also be
provided in the placeholder, such as referencing the I-D's current
progress through the channels, referencing any RFC which may have been
published, and so forth.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/