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

From: Dean Willis <[email-masked]>
Date: Tue, 4 Oct 2011 11:03:33 -0500

On Sun, Sep 4, 2011 at 9:23 AM, todd glassey <[email-masked]> 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

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Oct 2011 13:29:23 -0400

--On Tuesday, October 04, 2011 11:03 -0500 Dean Willis
<[email-masked]> wrote:

>...
> 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.

While this is an interesting variation, the general idea of
semi-automatic promotion is not exactly new.  See, e.g.,
http://tools.ietf.org/id/draft-ietf-newtrk-promotion from 2006.
It may not surprise you to know that the idea is more
controversial than might first appear.  One reason appears
below...

> 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". 

That would come as an interesting surprise to the ftpext2 WG and
several of the developers who are active there.  That WG, while
not as active as some of us would like, is definitely alive and
kicking under a fairly recent charter.

I suggest that the fact that you (and presumably lots of the
community) didn't know that such a WG existed and was doing
work, and hence that FTP is being "developed from" is
symptomatic of part of the problem with your proposal (and even
the earlier one).  Accidentally deprecating which was being
actively deployed and developed  because not enough of the right
had the patience to read announcements on the IETF (or
IETF-Announce) lists would be a really unfortunate development.

   john

---

From: "Gellens, Randall" <[email-masked]>
Date: Tue, 4 Oct 2011 18:58:55 +0000

>revise the protocol therein".

I don't understand this aspect.  If an RFC is deployed, even widely
deployed, but no new extensions are being done, and no developers are
clamoring for changes, you want to move it to Historic?  Wouldn't that be
misleading to anyone wanting to implement it in any situation where they
want to interoperate with existing deployments?  Perhaps that's what you
meant by "referencing the document in new deployments," but how would
people on the IESG or even in the IETF as a whole know about everyone
everywhere who might be trying to use a protocol?

---

From: Douglas Otis <[email-masked]>
Date: Tue, 04 Oct 2011 17:47:26 -0700

On 9/4/11 7:23 AM, todd glassey wrote:
> There are any number of IETF RFC's which were published and then 
> accepted in the community under the proviso 'that they would become 
> IETF standards' which in many instances they do not. Further many of 
> them are abandoned in an uncompleted mode as standards efforts.
>
> 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.
>
> Why this is necessary is that the IETF has become a tool of companies 
> which are trying to get specific IETF approval for their wares and 
> protocols - whether they are open in form or not. The IETF entered 
> into a contract with these people to establish their standard and 
> published those documents on the standards track so that they would be 
> completed.  Since they have not been completed as IETF Standards the 
> Project Managers for those submissions have formally breached their 
> contract to complete that process with both their WG members who 
> vetted those works as well as the rest of the IETF's relying parties.
>
> As such it is reasonable to put a BURN DATE on any Standards Track 
> effort which has stalled or stopped dead in its tracks for years.
>
> Todd Glassey
Todd,

I do not hold that view.  It should not require careers be dedicated in 
the advancement of specifications.  As in programming, many of these 
specifications should become components supporting more complex 
protocols.  While the current publications tools help tremendously in 
allowing interested parties determine the current state of a 
specification, I have not found standard's track informative.

It seems there should be an effort to better objectify specifications, 
in other words, allow them to be deconstructed into separate elements.  
Above the deconstruction, allow higher level organizations to offer a 
breakdown of options, relative use, current and best practices.  This 
high level organization should not include any normative language, other 
than in arranging existing specifications.  It would be with this higher 
level arrangement where status ranking makes more sense.

-Doug

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Oct 2011 12:26:22 +0900

On Oct 5, 2011, at 3:58 AM, Gellens, Randall wrote:

> clamoring for changes, you want to move it to Historic? 

Yes. He misses the point of what we do. We do what we do not to achieve some particular status, but to meet a technical and market need. If the objective is to achieve standard status, we can spend our energies getting it there. If the issue is meeting technological needs, the statuses are mile markers, not destinations.