On Sep 21, 2006, at 5:08 AM, John C Klensin wrote:
Having seen the consequences of one-step standards processes,
especially in environments in which the standards designers are not
very closely tied to products that are shipping or ready to ship, I
remain strongly committed to a standards model that separates
consensus proposals for implementation and consensus standards
that have been tested -- for both specification quality and
demonstrable experience with interoperability and scalability-- by
implementation and deployment.
No argument. But I don't think that our current model works either.
The fact is that we don't take the final step (Full Standard, or what
I call Obsolete Standard) very frequently, and we don't document
interoperability (which is what Draft Standard does) very frequently.
What we in fact do is take documents to Proposed Standard (we agree
that this is what we will build, and if you're lucky some of us have
partially implemented it when we said that) and leave them there.
And it's not that we don't ask the question; it's that the answer
doesn't come back in the form that RFC 2026 recognizes.
I would really like to see interoperability documented, and lack of
use/interoperability documented.
Collapsing Draft Standard and Standard together into what Mike O used
to call a good 'nuff standard, and making one of the ways to
demonstrate interoperability be demonstrated multi-vendor
interoperation in the field for a period of in excess of two years,
is IMHO a good thing. The number of years could be argued, and if
someone wants to say three years or four years I'm not going to
complain. We have a Proposed Standard dated 1975; that's silly. Pick
one. Is it obsolete or in current use, and if the latter, which
Telnet implementations implement the Extended ASCII option? We should
be able to bless it or not at this point.
We would really like interoperability testing in the sense that PPP
did for many years and the SCTP community does now, with multiple
vendors and open source implementers getting together in a room and
each proving interoperability with every other, and then reporting
back with issues found and successes experienced. That's a good
thing, very good, and some of us do it. Far more commonly, for
example in BGP, interoperability testing is done bilaterally between
vendors (our routing guys and the Juniper guys have been known to get
together and test specific features, for example), or more commonly
yet it is done under real life conditions in operational networks.
Live insertion is not as controlled (understatement), and the reports
back tend to be to the vendor's TAC. But trust me, it happens. Since
the operators and end users don't demand Full Standard status to use
the protocols, the vendors have no incentive to spend the money for
interoperability demos. Hence, I think the IETF needs to find a way
to capitalize on what really happens rather than attempt to impose a
solution that no-one else seems to find useful.
When I sent this note this morning, I attached a file listing 416
candidate RFCs. I guess, at 174K, the file was too large for the
exploder. So I have instead posted the suggestions broken out by
decade or year, and telnet separately; the URLs, with the count of
candidate RFCs they suggest, are at the end of this note. I think
these should each be either moved to Historic (we don't use any
more, or we don't recommend people use it any more), Informational
(in use but not commonly implemented), or Standard (this is
something widely implemented and proven operationally). I'll bet in
each case the relevant AD or working group chair could make that call
without thinking very hard, and in any event it could be sorted out
with a short email thread on each relevant list. If there were a
feature to remove in standardization it could be done by publishing a
profile RFC that says we think RFC 12345 works operationally for
the following reasons, but the opening twelve way handshake is not
widely implemented, substituting a three-way handshake, and we
consider that sufficient that updates the RFC in question and is
taken to standard with the relevant RFC.
For your amusement:
6 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1970s.txt
16 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1980s.txt
25 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/early-1990s.txt
20 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1994.txt
13 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1995.txt
36 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1996.txt
54 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1997.txt
77 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1998.txt
88 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/1999.txt
105 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/2000.txt
69 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/2001.txt
