[Old-standards] Brief Procedural Proposal

[Eliot Lear]

Pekka,

> Did I understand this correctly, that unless nobody calls some RFC down 
> from the list, it gets crufted without no description why it's crufty, 
> except "nobody seems to care anymore, because otherwise they would have 
> jumped up".

Yes, and so it's important that each of us look at the whole list and 
remove things we know to be in use.  Also, if you know of mailing lists 
that might have more information or interest, it would be worth querying 
them as well.

> 
> I'd say that for the remaining documents, which would get moved to 
> historic, someone(s) should generate some reason why we think they 
> should be moved to historic -- this doesn't need to be complicated, just 
> one sentence or the like. ("why we believe nobody is caring about this 
> RFC anymore..")

How about "obsolete" or "not in use"?  Seriously.  There are some cases 
where that really will be the reason.

>> Finally, if someone wants to remove an RFC from the list and others 
>> object, the others should write a small draft indicating why the RFC 
>> should be downgraded.  In other words, follow the alternative 
>> procedure and gain consensus within the IETF.
> 
> 
> This is an OK approach, though I'd prefer that before we begin the 
> "name-calling", we should try to formulate a description of what it 
> means to move the document to historic, similar to an introduction for a 
> draft which might include the list of RFCs.

Ok, but let's defer that discussion until we have a disagreement.

> 
> For reasons to this, just look at the dialogue I had with Harald. All of 
> these RFCs are still in use in some obscure part of the universe, but 
> that doesn't mean they should not be moved to Historic. There should be 
> a very short statement (maybe only a paragraph) which would describe the 
> goals here -- i.e., that it's OK to move stuff to historic that's still 
> in use somewhere.

I think the reasons for keeping a standard are the following:

1.  It's in general use; or
2.  There is no better way to accomplish what that standard does,
     and what it does would still need doing in a new implementation; or
3.  It's currently being revised.

This leaves the cases where [1] and [2] conflict.  Those cases require 
more thought.  I'd suggest we defer those until the second round.  They 
will likely require more detailed explanation as to why they should be 
demoted (if at all).