I disagree with Valdis' description. I actually worked for a standards organization that used a codebase as part of the definition of the standards it produced. The concept of "Running code" is good, but where are the IETF reference implementations? If "running code" is the actual standard, then you have to have some code to run. This is not the way the IETF has ever done things. The IETF references to "Running code" simply mean that there have been (or must be) demonstrations that the standard works, and is not a hypothetical document awaiting implementation. But "running code" is not the actual IETF standard, as Valdis seems to be claiming. The actual standard is the text of the RFC in the "standard" state. The status of each RFC is given in the current "Internet Offical Protocol Standards" which is updated every hundred RFC's, and is currently RFC 3600. Reviewing the RFC's with this title (or rather the changes between each) will give you an idea of the process the IETF goes through. Compare this to RFC 2026 and other documents. Also, it was my understanding that 2119 and 2026 were "BCP" status because they didn't refer to computer protocols but rather the rules of the organization, and can't be properly classifed as "standards". They reflect the current practice of the organization. However, it is not the case that they were meant ONLY to be vaguely 'generally useful' ideas that could be ignored by the IETF. Although under the current leadership, the rules haven't been followed very closely. This is a failure of the current leadership, not a failure of the organization to adopt rules. An organization can't run without rules. Otherwise, it isn't an organization, its a Cluster-bleep. Rules that aren't really rules, aren't rules at all. A standards organization that has no rules can't be open, transparent and fair. If it is not open, transparent, and fair, then it is closed, opaque, and proprietary. And if its not open, transparent, and fair, then it isn't really a standards organization, but a good-old-boy/chums network operating to the advantage of that group, attempting to create defacto standards just like other proprietary groups such as Microsoft. While this might have been OK many years ago, now far too many people have a stake in the Internet and in Internet Protocols to let the Internet be specified by a closed, opaque, proprietary good-old-boy operation. Your goal of having government RFP's refer to STDxxx's is good. It has been pointed out that relatively few documents ever reach this stage, but the most important ones do. If the IETF were to attend more to the administrative procedures it has adopted, then more RFC's would either reach the "mature" STD or BCP or INFORMATIONAL level or be dropped after development stops and interest fades. I suspect that some old RFCs' are kept around as a way for the leadership to promote bad ideas that never caught on, but that the leadership still favors and hopes someday will catch on, even though interest in further development was lost long ago. --Dean On Thu, 3 Jun 2004 Valdis.Kletnieks@xxxxxx wrote: > On Thu, 03 Jun 2004 11:04:06 PDT, Joe Touch said: > > > STD-5 is a nice choice - it actually refers to 6 different RFCs. > > > > So which one redirects to STD005.txt, and what is in it? > > > > (To see this noted in the RFCs themselves, see STD-62, which refers to a > > set of 8 different RFCs.) > > > > And what happens when a STD is updated/revised? > > This is the IETF, we believe in rough consensus and running code. Note > carefully that RFC2119 and RFC2026 are both BCP rather than Standard, > indicating that even the meta-standard of how we produce standards is "running > code" rather than an actual standard itself... ;) > > But anyhow, if we ever update STD005, we'll just do the obvious - create > STD079 or whatever we're up to, stick an "Obsoletes: STD005" on it, and stick > an "Obsoleted By: STD079" on STD005, and the RFC Editor will turn the crank and > make sure all the appropriate indexes and webpages are updated to match. > Again, this is all "running code" - we know how to issue an RFC that updates or > obsoletes one (modulo the occasional corner case that crops up), and there's no > obvious reason that the scheme that works for I-D, Draft, Proposed shouldn't > work for a full Standard... > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf