Why old-standards (Re: List of Old Standards to be retired)

[Harald Tveit Alvestrand <harald at alvestrand.no>]

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.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.org
> https://www1.ietf.org/mailman/listinfo/ietf





_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf