Since the IETF list is obviously in rehash-of-WG-discussion mode today, I
thought I'd contribute to the flamage, and rehash the logic behind the list
of old standards that arrived in your inboxes a few days ago.....
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(_at_)cisco(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf