Maybe I'm confused but, as I understand it, standards track level is
already, in principle, completely decoupled from "write and publish an
RFC" in that the standards level is not incorporated in the RFC
anywhere but listed separately.
In general, I agree with John Klensin as to what are considered the real
barriers to advancement, adding that the usual reason a new RFC is
required is that some small part/option of a Proposed Standards does not
have multiple implementations or if it does they don't interoperabe and
people have decided that part/option is of so little use this is not
worth fixing. Thus, under our current rules, a new RFC is needed to drop
out this more or less failed portion of the Proposed Standard.
Thanks,
Donald
======================================================================
Donald E. Eastlake 3rd
dee3(_at_)torque(_dot_)pothole(_dot_)com
155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w)
Milford, MA 01757 USA
Donald(_dot_)Eastlake(_at_)motorola(_dot_)com
On Fri, 12 Mar 2004, John C Klensin wrote:
Date: Fri, 12 Mar 2004 12:49:02 -0500
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
...
(1) We decouple "change maturity levels" from "write and
publish an RFC" (this means that the listing of maturity
levels must be current and authoritative). This also
meshes nicely with another proposal that was floated a
few years ago, but never really written up (see below)
As far a I know all of the above is true.
...