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 100 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/2002.txt 106 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/2003.txt 89 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/2004.txt 30 ftp://ftpeng.cisco.com/fred/ietf-ancient-rfc/telnet.txt _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
