Re: Expiring a publication - especially standards track documents which are abandoned

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 4, 2011 at 9:23 AM, todd glassey <tglassey@xxxxxxxxxxxxx> wrote:

> To that end I would like to propose the idea that any IETF RFC which is
> submitted to the Standards Track which has sat unchanged in a NON-STANDARD
> status for more than 3 years is struck down and removed formally from the
> Standards Track because of failure to perform on the continued commitment to
> evolve those standards.

That's not a bad idea. At the very least, it clearly illustrates that
our process is broken. We have rules that we're not really using. In
our quest for "better", we've made things too difficult to comply
with. It's time to make it easier for a change.

Automatic expiry, as you propose, is easy. But given the fact that
long-lived PS have essentially become "standards", I'd like to make a
counter-proposal -- semi-automatic advancement.

We set a 3-year life-cycle for Proposed Standard, Draft Standard, and
Standard. On the 3rd anniversary of any state, the RFC Editor polls
the IESG (which might seek community input). If anybody is actually
developing from the document, the document, it advances to the next
standards-level or remains a "full standard", and the RFC Editor edits
in any posted errata and republishes (whether as a new RFC no. or a
"version" of the original RFC number is open). If nobody is using it,
it goes to "historic". Such a poll should be pretty easy; one post to
the IETF list, and a 2-min discussion on the telechat.

When I say "developing from" the document, I don't mean "using the
protocol specified by the document in a static deployment", but
"referencing the document in new deployments, or actively trying to
revise the protocol therein".

I'm guessing FTP would probably qualify as one of the things that
would  move from "standard" to "historic". And HTTP, although
something we're still working on its bis, would be a full standard
(which might be revised by a proposed standard replacement as we make
more progress on it).

--
Dean Willis
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]