When is a standard a standard?

Insightful analysis by consultants Steve Taylor and Jim Metzler, plus links to the latest WAN news headlines

With all of our years in the industry, one of the most fascinating topics has been what makes a "standard" a "standard"? We all say we want "standards," and, at least in theory, having a standard leads to interoperability. But what does it take to make something a standard?

Emerging IEEE Ethernet standards could soothe data center

The purists among us would probably argue that the only real "standards" are those that are approved and agreed to by a third-party independent body, such as ANSI. The problem with the third-party standards is at least two-fold, though. First, in order to reach consensus on a standard, there are usually so many compromises and options that two pieces of equipment may both be compliant with the standard but they still fail to interoperate. Secondly, these bodies tend to be sufficiently cumbersome that by the time a standard is agreed to, the technology is obsolete.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

With all of our years in the industry, one of the most fascinating topics has been what makes a "standard" a "standard"? We all say we want "standards," and, at least in theory, having a standard leads to interoperability. But what does it take to make something a standard?

Emerging IEEE Ethernet standards could soothe data center

The purists among us would probably argue that the only real "standards" are those that are approved and agreed to by a third-party independent body, such as ANSI. The problem with the third-party standards is at least two-fold, though. First, in order to reach consensus on a standard, there are usually so many compromises and options that two pieces of equipment may both be compliant with the standard but they still fail to interoperate. Secondly, these bodies tend to be sufficiently cumbersome that by the time a standard is agreed to, the technology is obsolete.

This led to organizations like the Frame Relay Forum and ATM Forum developing "Implementation Agreements." An implementation agreement was intentionally not called a standard. Rather, these pseudo-standards were developed so that they filled in the holes around the options so that there was a high probability that two devices would indeed interoperate.

Another type of standard is the "retro-standard." A perfect example here is the T-1 framing formats that were (and are still) in use at Layer 1 for transport. For the most part, these "standards" were not voted on by a committee – at least in the beginning. Rather, the early developers, such as those at Bell Labs, built a network and the equipment in a monopolistic environment. Later the "standards" were released so that others could build compliant equipment.

Then there are de facto standards. These are the "standards" where a company is so dominant in a given area that there is no need to go to a standards committee. Back in the 1980s, IBM's SNA was the perfect example. IBM had sufficient market share that it didn't really matter whether there was a standard or not.

Of course, there are many additional standards issues that we can (and eventually will) discuss. Politics. Economics. Strategic positioning. Patent issues.

In the meantime, I encourage you to read and comment on the most interesting paper by Cisco and its view of the standards process. You can find this discussion here. 

Read more about lans & wans in Network World's LANs & WANs section.

Steve Taylor is president of Distributed Networking Associates and publisher/editor-in-chief of Webtorials. Jim Metzler is vice president of Ashton, Metzler & Associates.