What should IETF “standard track” actually mean?

This post is going to be a little off the beaten path, but it might yet be useful for folks interested in the process of standardization through the IETF.

Last week, at the IETF in Buenos Aires, a proposal was put forward to move the IPv4 specifications to historic status. Geoff Huston, in his ISP column, points out the problem with this sort of thing—

As one commenter in the Working Group session pointed out, declaring IPv4 “Historic” would likely backfire and serve no better purpose other than exposing the IETF to ridicule. And certainly there is some merit in wondering why a standards body would take a protocol specification used by over 3 billion people, and by some estimated 10 billion devices each and every day and declare it to be “Historic”. In any other context such adoption figures for a technology would conventionally be called “outstandingly successful”!

The idea to push IPv4 to historic is, apparently, an attempt to move the market, in a sense. If it’s historic, then the market won’t use it, or will at least move away from it.

Right.

Another, similar, line of thinking came up at the mic during a discussion around whether to move a particular set of specifications to standards track or experimental track. To be precise, the only requirement for standards track is the existence of two interoperable implementations—a hurdle over which the set of specifications under consideration have. The discussion at the mic centered around the commercial viability of the solution, which often also plays into the designation of a document as either a standard or an experimental.

The argument offered was that if these documents were taken to experimental status no-one would be serious about deploying them. The reality, on the other side, is that no matter what status this set of documents obtains, no-one is going to deploy the solution described in any widespread commercial system. No amount of tweaking and messing around is ever going to make this particular solution deployable; there are structural issues that cannot be overcome in any meaningful way forever.

So, what’s the point? There are two, actually.

First, one of the problems the IETF faces is the thought that somehow, in some way, if you build standards, they will come. The IETF, like most standards organizations (and most open source projects), vastly overrates their importance and power in the face of real commercial pressures. Again, this isn’t just a problem the IETF faces, it’s just a reality of all standards bodies and open source projects across all time, and probably in just about every field of endeavor.

Making a standard isn’t the same thing as making a commercial product. Making a commercial product isn’t the same as making a standard. Refer to the entire article by Geoff Huston on this point if you want more information about the reality of historical and active standards.

Second, when you’re reading IETF documents, don’t take the status of the document as a guide to the usefulness or adoption of a protocol or technology. Document status often doesn’t relate to the usefulness of a technology in the real world, but is rather the result of internal political struggles within the IETF itself. Another instance of this same thing is the wild warnings sometimes attached to specific individual informational drafts for no reason other than internal political considerations.

In other words, when you read an IETF document, engage your brain, rather than counting exclusively on the brains of others. Or perhaps: think for yourself.

By the way—before you rant, or say how broken the IETF is, I once worked for an engineering standards body that operates in a completely different area, and I have experience with a number of other standards bodies. Every standards body I’ve worked with, and every open source project I’ve looked at, has this same sort of problem. If you’re honest, your own IT shop has this sort of problem, as well. This is a human level problem, not a problem in the IETF specifically. Standards are politics in a very real sense. Remember that, and you’ll find the documents produced by any standards body—and projects developed in any open source environment—a little more useful in your daily work.