Subject: Re: Processing of Expired Internet-Drafts

From: Carl Malamud <[email-masked]>
Date: Wed, 14 Jan 2004 09:39:11 -0800 (PST)

Hi Fred -

> 
> If I can have two separate files (a tombstone and a subsequent new file 
> version) that have the same name, as described in the recent announcement, 
> I am going to have to figure out a trigger that will tell me that I need to 
> re-download the file.

Incrementing the number also screws up a common operation for authors: is
the internet-draft that I'm citing the current one?  With the new algorithm,
a search for a +1 version will yield a hit and I have to go look in that
file.

> the context of the above. If the "tombstone" is literally as described, it 
> would be far more space/search/etc efficient for us to have the tombstone 
> consist of an added text line in a file indicating that the named draft 
> expired on a certain date, and keep separate files for the active internet 
> drafts. It seems to me that this makes it simpler to maintain a mirror and 
> to find temporary documents.
> 

A tombstone jail containing that information would be preferable in my
view to mixing them all together.  

Regards,

Carl

---

From: James M Galvin <[email-masked]>
Date: Wed, 14 Jan 2004 13:58:51 -0500 (EST)

On Wed, 14 Jan 2004, Fred Baker wrote:

    I am very concerned about the accumulation of tombstones forever,
    though.  If we don't want to accumulate draft versions forever, what
    makes tombstones different? I would far rather age them out after
    some interval, such as six months.

I don't feel strong about this issue either way.

I will observe that from the point of view of the Secretariat, if they
don't keep I-Ds around forever they probably should not keep tombstones
around forever either, which really only means I don't see the problem
they are solving by keeping them.

Keeping them around forever is a role filled nicely by the archiving
mirrors (although this presupposes incrementing the version number if a
revision is submitted).

Certainly, a tombstone should be removed if a revision is submitted,
which would be a change to the new rules as documented.

Jim

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 Jan 2004 14:20:54 -0500

One reminder for those who may not know...

For those mirroring IDs and/or RFCs, both the Secretariat and RFC
Editor support rsync. If you are still using ftp for the mirroring,
rsync has a lot to offer.

http://www.ietf.org/rsync-help.html
 
http://www.rfc-editor.org/rsync-help.html

Thomas

---

From: David Morris <[email-masked]>
Date: Wed, 14 Jan 2004 11:25:05 -0800 (PST)

On Wed, 14 Jan 2004, Fred Baker wrote:

> I'd be happier bumping the number any time the file is changed, so that the
> tombstone supercedes the removed file and a subsequent posting supercedes
> the tombstone.

Absolutely. Principals of version control are broken otherwise.

In the preferences space, I'd rather see the file extension change as well
so it would be possible to determine w/o parsing the file content that it
is a tombstone.

> I am very concerned about the accumulation of tombstones forever, though.
> If we don't want to accumulate draft versions forever, what makes
> tombstones different? I would far rather age them out after some interval,
> such as six months.

As was noted, a mechanism must be maintained to track names and such a
mechanism SHOULD be visible to the ietf community. Doesn't have to be the
drafts directory.

If they are aged, it should be based on natural IETF cycles and not the
current arbitrary 6 months ... for example, a draft associated with a
working group should have the tombstone remain until some time after the
WG closes ... 1 year? That should include drafts submitted to but not
owned by a WG. Individual drafts should retain the tombstone for
substantially longer than 6 months. Perhaps 2 years.

Regarding the clarification about expiration occuring the moment the
processing reopens after a meeting... a better approach would be 15 days
AFTER ALL drafts submitted while processing was suspended and processed.

I wonder how many WG drafts are resubmitted these days to reset the clock
rather than because there were substantive changes? Needless churn. It
seems quite reasonable that a WG would have reference materials written
early in the cycle for discussion which don't change but are still
important 2 years later as the WG is perhaps finishing the official RFC
track documents. Perhaps even later as RFCs progress thru the standards
track. WG chairs should have a mechanism which allows them to extend the
expiration of WG drafts w/o churn of version, etc.

Dave Morris

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 14 Jan 2004 14:42:56 -0500

On Wednesday, Jan 14, 2004, at 11:43 US/Eastern, Fred Baker wrote:
> At 07:52 AM 1/14/2004, The IETF Secretariat wrote:
>> When an Internet-Draft expires, a "tombstone" file will be created 
>> that includes the filename and version number of the Internet-Draft 
>> that has expired.  The filename of the tombstone file will be the 
>> same as that of the expired Internet-Draft with the version number 
>> increased by one.  If a revised version of an expired Internet-Draft 
>> is submitted for posting, then the revised version will replace the 
>> tombstone file and will receive the same version number as that 
>> previously assigned to the tombstone file.  Tombstone files will 
>> never expire and will always be available for reference unless they 
>> are replaced by updated versions of the subject Internet-Drafts.

Does this also apply in the "published as RFC" and "replaced by 
draft-foo" cases, not just expiration without publication?

>
> If I can have two separate files (a tombstone and a subsequent new 
> file version) that have the same name, as described in the recent 
> announcement, I am going to have to figure out a trigger that will 
> tell me that I need to re-download the file.
>

Kind of like how 1id-*.txt changes almost daily?  If you can't use the 
timestamp as a trigger, the file size would probably be fairly 
reliable.  For my personal mirror, I use rsync, and I've noticed no 
problems.

 From what I've been told, the handling of numbers described above has 
been the procedure for a while.  I asked about it a year or so ago and 
was told that the number of the tombstone file should be reused for the 
next submission "reviving" the draft.  So, you may have been missing 
updates for a while.

> It seems to me that there is a better approach to the above, at least 
> in the context of the above. If the "tombstone" is literally as 
> described, it would be far more space/search/etc efficient for us to 
> have the tombstone consist of an added text line in a file indicating 
> that the named draft expired on a certain date, and keep separate 
> files for the active internet drafts. It seems to me that this makes 
> it simpler to maintain a mirror and to find temporary documents.

Keeping the tombstone files around forever does sound messy.  I like 
your suggestion of using a file to collect the data, at least for the 
long term.  We'd want the author contact (and disposition, if not just 
for expiration) info around for at least a while, though maybe not 
permanently.  So maybe still keeping tombstone files for six months or 
so would be wise.  And it's the established way of finding out what's 
happening with recent enough drafts.

This file with the "used" names might grow to be pretty large after a 
lot of years, but we're probably not talking about more than a megabyte 
or two a year, are we, even if we keep all the author info around?  By 
the time it's big enough to be a problem, we'll probably have better 
solutions....

Ken

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 14 Jan 2004 12:06:42 -0800

I also concur with this suggestion. 

This modification would also assist us to find expired drafts containing good ideas but that were either introduced before the community became interested in the topic or else were not renewed due to procedural issues (i.e., not due to their lack of technical merit). I am sure that others in our community are interested in many drafts which we are unable to read due to more pressing local work-related pressures and then are disappointed that we can't find the draft once the work pressures permit us time to read the previously deferred drafts. There are many reasons why some drafts fail to receive resonance and this approach would increase the probability of technically viable ideas not timing out and becoming lost.

-----Original Message-----
From: Theodore Ts'o [mailto:[email-masked]]
Sent: Wednesday, January 14, 2004 11:49 AM
To: Fred Baker
Cc: [email-masked]
Subject: Re: Processing of Expired Internet-Drafts

On Wed, Jan 14, 2004 at 08:43:58AM -0800, Fred Baker wrote:
> 
> It seems to me that there is a better approach to the above, at least in 

I would prefer this as well.

						- Ted