Let's look back on what the IETF has decided previously.
In 1994, the IETF community resolved to make the following procedure into "IETF law" through RFC 1602:
When a standards-track specification has not reached the Internet
Standard level but has remained at the same status level for
twenty-four (24) months, and every twelve (12) months thereafter
until the status is changed, the IESG shall review the viability
of the standardization effort responsible for that specification.
Following each such review, the IESG shall approve termination or
continuation of the development. This decision shall be
communicated to the IETF via electronic mail to the IETF mailing
list, to allow the Internet community an opportunity to comment.
This provision is not intended to threaten a legitimate and active
Working Group effort, but rather to provide an administrative
mechanism for terminating a moribund effort.In 1996, through RFC 2026, it reconfirmed that decision.
In 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 and 2004, various people cricticized the IESG for not following the process as written; the standard answer was "this is not the most important thing for the IESG to be doing".
And that's still true.
In March 2004, having gone through yet another of those "debates", I decided to see if I could write down some words on how this COULD be done without being an undue burden on the IESG.
I recruited Eliot Lear to lead the effort, and together we created what's currently draft-ietf-newtrk-cruft-00.
At the NEWTRK WG meeting in San Diego in August, I explained my motivation for pursuing this:
This is the lightest-way process for doing what RFC 2026 mandates that I have been able to imagine. Now, we should either execute on that process, OR STOP TALKING ABOUT MOVING TO HISTORIC.
The argument that Bob Braden is making, and you seem to be making - that we should not move "crufty" things to Historic at all - is a rational argument.
But in that case, WE SHOULD UPDATE RFC 2026 TO SAY EXACTLY THAT.
<flame>
HAVING THE IETF CONTINUE TO SAY ONE THING AND DO ANOTHER IS NOT A GOOD THING FOR THE INTERNET.
</flame>
OK, finished shouting. Eric and Bob: the NEWTRK list is waiting for your contribution on the principle involved, and your internet-draft suggesting the change to RFC 2026 to get rules aligned with reality.
It's possible that that contribution will overturn the consensus of the WG to run this experiment.
But in the meantime - please get out of the way and let us who want to try run the experiment and evaluate the result.
Harald
--On torsdag, desember 16, 2004 14:00:13 -0500 Eric Rosen <erosen@xxxxxxxxx> wrote:
I see this exercise has already reached the point of absurdity.
How can it possibly be worth anyone's time to look at each telnet option and determine whether it is deployed? What possible purpose could be achieved by changing the standards status of some telnet option? Is there some chance that someone is going to implement one of these by mistake somehow?
A similar comment applies to the FDDI MIB. Are we trying to make sure that no one implements that MIB by mistake? Or that no one implements FDDI by mistake, just because he thinks there's an IETF standard about it?
Let me echo Bob Braden's "if it's not broken, why break it?" query.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf