Date: Fri, 17 Dec 2004 13:16:25 +0100
From: Harald Tveit Alvestrand <harald(_at_)alvestrand(_dot_)no>
Subject: Why old-standards (Re: List of Old Standards to be retired)
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.
By the end of 1994, RFCs through 1735 had been published (plus or
minus a few stragglers). Currently, we have more than double that
number, and it is likely that the acceleration will continue.
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".
What the IETF community may have thought to be feasible in 1994
evidently turned out not to be practical. I suspect that there
are several contributing issues:
1. annual review of hundreds or thousands of standards in an
organization comprised primarily of volunteers is not
practical. IEEE had, in the mid-90s, a 5-year review
policy (as I understand it, tied to an ANSI cycle tied
to an ISO cycle), and was rather far behind in its efforts
to review (and reaffirm, supersede, or obsolete) old
standards (some which were still deemed useful had
vacuum-tube circuit diagrams as examples of implementation).
The effort required by the review period needs to be
consistent with the availability of qualified and motivated
worker bees that will perform the review.
2. RFC 2026 specifies some specific requirements for advancement
along the Standards Track. In a few cases (e.g. where a
Proposed Standard includes an unencumbered reference
implementation) the combination of various forces (market
size, legal issues, etc.) may result in multiple interoperable
implementations based in part on a single code base derived
from a single (implicit or explicit) license. As I understand
RFC 2026 section 4.1.2, it precludes such a case from
advancing to Draft Standard (i.e. there is no provision for
IESG or IAB waiver for the two independent implementations
3. In many cases, once a Proposed Standard has been developed
by a WG, the WG's official work is finished and the WG is
disbanded. That leaves no responsible group to field
questions, take on the tasks of documenting independent
interoperable implementations (as required for advancement
to Draft Standard) etc.
And that's still true.
Beware the implicit positive feedback path (no, that's NOT a
good thing!); as the backlog of RFCs needing review grows, and
the rate at which that backlog grows accelerates, a "we have
more important things to do" attitude quickly results in the
enormity of the task growing beyond the ability to cope with
Ietf mailing list