--On Friday, September 16, 2011 01:08 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>...
> Part of the problem is the expectation that some single label
> should entirely define the status of a specification. There
> are several almost-orthogonal variables that the community
> cares about (or should care about):
>
> - currency - does the document (still) reflect best current
> practice for implementations of this protocol to work well?
> - maintenance status - is the specification still being
actively
> maintained?
> - technical soundness - does the protocol
> described meet current criteria for technical soundness?
> (okay, this is similar to currency)
> - applicability - is this
> protocol (still) recommended for general use in this space, or
> for use only in corner cases, or is its use generally
> discouraged (presumably in favor of something else)?
> - maturity - has this specification been implemented for long
> enough and enough times to have confidence in the quality of
> the protocol described and the specification for it?
> - market
> penetration - is the protocol widely used in practice? is it
> generally necessary for applications in this space to support
> it?
> Trying to collapse all of these into X standard /
> informational / experimental / historic quite naturally leads
> to some tension between different interpretations of those
> terms.
Right. And part of that, again, is why some of us continue to
press for rethinking the use of categories rather than, e.g.,
seeing if we can improve the deck situation on the Titanic by
stacking two of the deck chairs rather than leaving them
separate or by wholesale repainting of all old-colored deck
chairs to a different color.
But, more important for this particular case, it is why "let's
reclassify all of these" efforts usually (always?) turn into
expensive and time-consuming case by case evaluations. An
important lesson from the Newtrk "de-cruft" exercise that
Spencer mentioned is that it was intended to quickly and
efficiently get rid of low-lying fruit. I think it would be a
fair summary to say that, by the time we got finished, it was
clear that "quickly and efficiently" wasn't in the cards and
that there were fewer low-lying fruit than expected. The
experiment, described in RFC 4450, started with 125 candidate
documents and, approximately 244 messages later (I think not
counting discussions of the approach on the newtrk list or
comments during IETF Last Call), ended up moving 44 documents to
Historic.
FWIW, a quick scan through pre-IETF RFCs yielded a wide range of
answers to Keith's questions, from
o full standard, vague specification, not being actively
maintained, widely implemented, working and rarely used
these days (e.g., CHARGEN (RFC 864) or Quote of the Day
(RFC 865))
to
o full standard, decent specification that does not meet
today's standards, not being actively maintained, widely
implemented, working and very significantly used (e.g.,
the IP over Ethernet document cluster).
to informational specifications that are of historical interest,
if that, today (RFC 809, 831, 841, or 851 anyone?). Again, the
point is that this needs to be done on a case by case basis...
and that the level of investment that takes has just not been
justified and almost certainly cannot be.
john
If we are going to embark on this again (note that , was very
narrow in scope and restricted to
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf