> Date: Fri, 17 Dec 2004 13:16:25 +0100 > From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> > Subject: Why old-standards (Re: List of Old Standards to be retired) > Message-ID: <[EMAIL PROTECTED]>
> 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 requirement). 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 it. _______________________________________________ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
