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@xxxxxxxxxxxxxxxxxx 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@xxxxxxxxxxxx On Fri, 12 Mar 2004, John C Klensin wrote: > Date: Fri, 12 Mar 2004 12:49:02 -0500 > From: John C Klensin <john-ietf@xxxxxxx> > >... > > (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. >...