Subject: Query about procedure: Tombstones?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 10:42:54 -0800

Hi folks,

a query about the I-D directories....

just at this moment, we seem to have a couple of thousand "tombstones" - 
files containing information that an I-D has expired, or that an I-D has 
been published as an RFC.
It looks as if the tombstone of every I-D that has expired since November 
2001 is still in the directory.

To me, it would make sense to expire these at the same schedule as I-Ds - 
that is, they're gone 6 months after the event happened.
But since this is a change in procedures, I'd like to check that there 
aren't any people depending on the current behaviour before I say "this is 
obvious - just do it".

What do you think?

               Harald

---

From: [email-masked] (Scott Bradner)
Date: Tue, 9 Dec 2003 14:13:07 -0500 (EST)

> I'd like to check that there

I do not think its obvious
I think the Tombstones are useful to tell people what happened to an ID 
they might have seen referenced or discussed - disk is cheap - I'd leave them

Scott

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 09 Dec 2003 14:33:35 -0500

In message <[email-masked]>, Scott Bradner writes
>they might have seen referenced or discussed - disk is cheap - I'd leave them

They cause me a different problem:  they confuse rsync (maybe I haven't 
found the right option) when someone sends in a new version of an 
expired draft.  My getietf script now deletes all old tombstones...

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: [email-masked] (Scott Bradner)
Date: Tue, 9 Dec 2003 14:34:29 -0500 (EST)

> they confuse rsync 

that is a problem - one could look for size changes

Scott

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 9 Dec 2003 11:38:36 -0800

At 10:42 AM -0800 12/9/03, Harald Tveit Alvestrand wrote:
>just at this moment, we seem to have a couple of thousand 
>"tombstones" - files containing information that an I-D has expired, 
>or that an I-D has been published as an RFC.
>It looks as if the tombstone of every I-D that has expired since 
>November 2001 is still in the directory.

That's about right. Before that, the secretariat would delete 
different tombstones at different times. It seemed that they often 
did this in big batches just before IETF meetings. Sometimes they 
would remove all tombstones, sometimes just the expired I-Ds (leaving 
the "we have turned this into an RFC" ones around).

>To me, it would make sense to expire these at the same schedule as 
>I-Ds - that is, they're gone 6 months after the event happened.
>But since this is a change in procedures, I'd like to check that 
>there aren't any people depending on the current behaviour before I 
>say "this is obvious - just do it".
>
>What do you think?

It would be good if it was consistent. A consistent "everything dies 
after six months" is just fine. Alternatively, "leave the RFC 
announcement tombstones around forever but the expiration tombstones 
die in six months" is fine too.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 09 Dec 2003 14:49:48 -0500

>What do you think?

I think tombstone for ID published as an RFC are fine, but disagree with
the reason for tombstone for expired drafts. In the worst case the
tombstones overwrite the last (and frequently the best) copy of the draft.

Stop putting in tombstones for expired ID's, the ID contains text that
says it is expired.

         Olafur

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 09 Dec 2003 15:00:53 -0500

On Tuesday, December 09, 2003 14:33:35 -0500 "Steven M. Bellovin" 
<[email-masked]> wrote:

> In message <[email-masked]>, Scott Bradner
> writes :
>>> aren't any people depending on the current behaviour before I say "this
>>> is  obvious - just do it".
>>
>>

I end up using something like

rsync -rWlvt --copy-unsafe-links '--exclude=.[0-9]*' --delete --progress \
  /afs/andrew.cmu.edu/common/internet-drafts/ internet-drafts/

Which definitely works, provided the source directory is being updated.  I 
don't know what the script does that keeps the local mirror up to date.

I'm inclined to agree with Scott -- disk is cheap, and the tombstones 
provide valuable information that "something has changed" since the last 
version.  Now, it might be interesting to name them -XX or something 
instead of using the next number...

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 12:02:48 -0800

We changed the procedure recently so that a tombstone has a version number 
1 higher than the expired draft, which solves the overwriting problem.
If it's resurrected, the new draft then overwrites the tombstone, but that 
isn't a great loss.....

                 Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 12:06:42 -0800

> they might have seen referenced or discussed - disk is cheap - I'd leave

Google gives you the old drafts in 20 seconds anyway.... I do think that we 
could do much better in keeping the history of I-Ds available, even when 
the I-Ds are gone.I

But I object to the clutter - only when I counted the tombstones did I 
realize that the number of active internet-drafts is closer to 3000 than to 
5000.

Note that I still want to keep the tombstones around for 6 months.....

                 Harald

---

From: [email-masked] (Scott Bradner)
Date: Tue, 9 Dec 2003 15:09:00 -0500 (EST)

> could do much better in keeping the history of I-Ds available, even when 
. the I-Ds are gone.I

it does not give you the ID->RFC mapping

the tracker may do that someday at which time its less of an issue for me

(but "clutter" does not seem to be too strong a reason when we have
3K semi-randomly named IDs)

Scott

---

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 12:06:42 -0800

Harald

---

From: Ralph Droms <[email-masked]>
Date: Tue, 09 Dec 2003 15:19:05 -0500

Was this change to the tombstone procedure announced and discussed?  I just
discovered the new procedure the hard way by tripping over conflicts between
a reference to a draft-n that was replaced by tombstone-n+1.

At the risk of asking for a detailed change that might not be worth the
effort, perhaps we could consider putting the specific rev number of the
expired draft in the tombstone file?

- Ralph

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 12:20:27 -0800

> expired draft in the tombstone file?

That seems like a good idea (and should be simple). I'll ask.

               Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 12:54:18 -0800

--On 10. desember 2003 07:31 +1100 Geoff Huston <[email-masked]> wrote:

> I use these files to figure out what happened to each ID
> (http://bgp.potaroo.net/ietf/xids-all.html)
>
> What is annoying is that the final version of the id is _replaced_ by
> this notice, rather than creating a new version.
>
> So if there is going to be a change in management procedures of these
> files a little notice would be appreciated so that various scripts can be
> changed.

I think that point has been well made!
There's a limit to how far down we should go in announcing changes - but 
once we get the expiry procedures written up, I think we should announce 
them. They never HAVE been documented in detail....

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 13:50:01 -0800

Ralph,

> a reference to a draft-n that was replaced by tombstone-n+1.

what was the nature of the "trip-up"?

The change was instituted following complaints that we were losing 
information, and made it hard to keep track of all versions of drafts - 
some subpoena requested access to some recently expired drafts, and the I-D 
directories were only producing tombstones, the drafts having been 
overwritten.

So we did a brief internal discussion and couldn't see any downside, and 
Just Did It. Guess we didn't check with everybody ... but then again, at 
the time, it seemed like an issue not worth spending all that much time 
on....

                   Harald

---

From: Ralph Droms <[email-masked]>
Date: Tue, 09 Dec 2003 17:05:50 -0500

I had two problems...

First, draft-ietf-dhc-agentopt-radius-03.txt (of which I am a co-author) was
expired prematurely and replaced by tombstone
draft-ietf-dhc-agentopt-radius-04.txt.  I read the tombstone to mean that
draft-ietf-dhc-agentopt-radius-04.txt had expired.  I couldn't remember ever
submitting draft-ietf-dhc-agentopt-radius-04.txt, and I couldn't find any
record of submitting draft-ietf-dhc-agentopt-radius-04.txt (after searching
for a while and contacting the co-author).  I sent e-mail to internet-drafts
to check on the problem, and we discovered
draft-ietf-dhc-agentopt-radius-03.txt had been expired prematurely.  Had I
know draft-ietf-dhc-agentopt-radius-04.txt meant that
draft-ietf-dhc-agentopt-radius-03.txt was expired, I wouldn't have spent so
much time checking my records to understand where
draft-ietf-dhc-agentopt-radius-04.txt came from.

Second, draft-ietf-dhc-failover-12.txt expired (without my noticing) and I
referred to draft-ietf-dhc-failover-12.txt in a WG last call.  I got a note
pointing out that draft-ietf-dhc-failover-12.txt didn't exist and
draft-ietf-dhc-failover-13.txt was the tombstone.  Since I hadn't submitted
draft-ietf-dhc-failover-13.txt (I'm a co-author), I had to check with the
current editor to see if he had submitted draft-ietf-dhc-failover-13.txt, so
I could find out what changes he had made.  He looked in his records and
couldn't figure out where draft-ietf-dhc-failover-13.txt came from.  Again,
we wouldn't have looked around for the source of
draft-ietf-dhc-failover-13.txt if we had known it was the tombstone.

Not a big deal in either case (and I apologize for the long-winded
explanation).  But the lack of an announcement caused us
both some amount of pain...

- Ralph

At 01:50 PM 12/9/2003 -0800, Harald Tveit Alvestrand wrote:
>some subpoena requested access to some recently expired drafts, and the 
>I-D directories were only producing tombstones, the drafts having been 
>overwritten.
>
>the time, it seemed like an issue not worth spending all that much time on....
>
>                   Harald
>
>
>

---

From: Aaron Falk <[email-masked]>
Date: Tue, 9 Dec 2003 14:40:07 -0800

Hmmm.  Should the Secretariat notify authors when an ID is expired?  
Seems like a reasonable failsafe and perhaps automatable in the draft 
tracker...

--aaron

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 10 Dec 2003 00:32:11 +0100

> tombstones overwrite the last (and frequently the best) copy of the draft.

?? My understanding is that the tombstones are consistently given a
number one higher than the expired draft, not overwriting it - so that a
possble later new submission of the draft in a new version will
overwrite the tombstone, rather than the other way around ?

	Henrik

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 15:36:14 -0800

> overwrite the tombstone, rather than the other way around ?

As of a few months ago, that's how it works....

---

From: Kurtis Lindqvist <[email-masked]>
Date: Wed, 10 Dec 2003 09:17:21 +0200 (EET)

> them. They never HAVE been documented in detail....

While I sort of like the tombstones, why don't we just move the last
version of the I-D to a "historical" directory?

- kurtis -

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2003 23:31:33 -0800

> version of the I-D to a "historical" directory?

because we promised to only publish them for 6 months?
this has been a recurring theme, with no resolution, ever....

---

From: Kurtis Lindqvist <[email-masked]>
Date: Wed, 10 Dec 2003 10:03:38 +0200 (EET)

> this has been a recurring theme, with no resolution, ever....

well, everyone else seems to publish them, so I sort of fail to see what
difference publishing them as historical in a separate directory would do.

But I guess that is just me...

- kurtis -

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 10 Dec 2003 04:27:47 -0800 (PST)

Just to echo Kurt here...

There may be one I-D author left who doesn't know about Google,
much less the various repositories that seem to have every
version of every I-D that has ever been written, *whether it was
ever submitted or not*.

So, maybe the right thing to do is to announce that we are going
to stop deleting I-Ds, as of IETF 59, so stop submitting I-Ds
that you're going to be embarrassed by.

Instead, we will copy I-Ds to an "inactive" directory after six
months (and, since it's a process change anyway, "nine months"
would allow us to think about an I-D for two IETFs, and if it
doesn't go anywhere after two IETFs, it probably isn't
"active").

But this really is a recurring discussion topic that could go
away, if we recognized that the world has changed in the last
ten years and adjust.

No one really knows what goes on inside the Secretariat, but I'm
told that we really don't delete old I-Ds anymore, instead
keeping them around for IPR prior art searches. If this is true,
we're already doing what we told people we wouldn't do, we're
just making the archive unusable for people who aren't on a
legal fishing trip.

The world has changed. There are probably dumb I-Ds I've written
that did vanish, as advertised - but that day has gone. We could
adjust.

One reason to adjust might be that we really do have I-Ds, not
RFCs, that mattered. We're pulling a lot of ideas out of NSRG
into multi6 - but those ideas were never published as RFCs, so
now we're citing http://users.exis.net/~jnc/tech/endpoints.txt.

FWIW, there's a mildly entertaining discussion on NEWTRK about
whether we're a standards organization or not. If we're not, one
reason why would be that we don't think we produce anything
that's important enough to keep around if it doesn't result in
an RFC, instead relying on web search engines as our
institutional memory.

And then we complain because none of the newbies know why things
are the way they are. But now I'm ranting - have a nice day!

Spencer, who was amazed when old poems started popping up on
DejaNews several years after I'd written them...

---

From: Geoff Huston <[email-masked]>
Date: Wed, 10 Dec 2003 07:31:55 +1100

thanks,

    Geoff

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 9 Dec 2003 19:42:59 -0500

> aren't any people depending on the current behaviour before I say "this is 

How much work would it take to create a perl script that parsed out
the tombstone information, and created a single text file,
expired-ids.txt that contained a table with three columns, the I-D
name of the expired draft, and the expiration time, and the RFC # if
the I-D grew up and to become an RFC?  That's all the useful
information that's in the tombstone files, right?

						- Ted