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.


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.


  1. stephen on 14 April 2016 at 10:43 pm

    Russ, Its not that the IETF is broken, but I believe that the perception of the IETF “standards” could be seen as a little confusing.

    For example, I was recently discussing a new technology and the first question I was asked is.. ” is it a standard?”.
    the organisation is was talking to were looking for confirmation that the technology has some sort of approval.
    that’s its generally good ideal to deploy
    and is not another HD-DVD.

    looking at the rfc-editor web page, my reply to the question above could have been “it depends”.

    lets take RFC 6830 as an example,
    this refers to LISP, it states its an experimental standard, but I have found “LISP” configuration guides from various vendors.

    should that say to me that this is a “proper” standard and ready for production?
    And that its not really experimental but an internet standard/BCP/ “the name for a production-ready standard” ?.

    This leads to the following question.

    Is a standard a standard if…..
    its experimental ?
    its a Draft IETF paper ?
    it is proposed, internet,informational, historic , BCP or unknown RFC?.

    Being very flippant, i believe that most organisations want this from the IETF standards body is the following.

    “hey guys !!!, we’ve got this new thing,
    we’ve gone through some governance
    and we think its good to use and generally a good idea,
    hence we made it a “current” standard”.

    Please check availability with your local Vendor, ! Not all deployments are the same ! Protocols/links can go down as well as up.

    taking that into account,
    I believe that in general, most people would like and could hopefully benefit from a little more clarity about what is defined as a “standard”.

    • Russ on 15 April 2016 at 7:30 am

      Thanks for stopping by! First, I do think the IETF has some cultural issues. In fact, any old/large organization is likely to be “broken” in some respect; it’s just a matter of finding the brokenness. On the other hand, the IETF is working to change its culture, and interact with the more “open” world in which we find ourselves. So I think things are broken, but there is a healthy response brewing, so I believe that things will get better in terms of the way people are treating on list, the avenues people have to participate, etc.

      Second, the problem, I think, may be with the concept of a “standard.” Maybe the term is just the wrong one in the first place–perhaps it should just be “levels of vetting,” or some such, from “individual” through “community vetted,” or 1 through 5, or some such. The point has always been mixed up; standards are things the IETF thinks the community should use, other stuff is things the community may use, but this rarely matches with reality.

      This is something that might want/need to be addressed at some point.