The Benefits of Openness

Making publicly available standards documents that stipulate every nuance of a technology is known as open standards. Open standards offer tremendous benefits that have been proven time and again since the introduction of this concept. In the days before the Internet, the previous paradigm was tightly integrated proprietary platforms. In other words, every aspect of a networked computing architecture (including endpoint devices, cable interfaces, computing platforms, operating systems, applications, and printers) was tightly linked by the manufacturers. You couldn't mix and match components from different manufacturers; you had to select one vendor for all your needs.

The benefits have proven very compelling. Competition has leveled the playing field, prices have dropped, and manufacturers have continued to innovate in order to develop meaningful (albeit temporary) advantages over their competitors. The Internet standards-setting process is one of the ways in which technologies can be either developed out in the open or, if developed privately, granted openness.

Competitive Advantages of Openness

Although the Internet's standards-setting process might seem very altruistic, especially because virtually all the IETF's members are volunteers, you need to remember that things are not always as they first appear. Joining the IETF, or any of its functional components, as a volunteer can represent a substantial commitment of time and effort. Because the IETF doesn't pay network engineers for these efforts, and most network engineers aren't independently wealthy, it stands to reason that someone must fund or subsidize their involvement. Usually, that is the engineer's employer.

So the obvious question to ask is "What's in it for the employer?". Why would any company fund or subsidize anyone's involvement in the IETF? The answer is remarkably simple: They have a vested interest in the outcome of the proceedings. It is quite common for a company to develop a proprietary technology and then seek to legitimize its standing in the Internet community by presenting the technology to the IETF in the form of an RFC. A working group might or might not then be required to examine the proposal or RFC in more detail and determine what, if any, changes are required to make the proposal more acceptable. Other companies also benefit from participating in that they get the "inside track" on emerging technologies that might or might not become approved for use on the Internet.

At this point, you might be wondering why any company that has developed a great new technology would want to give it away to potential competitors by publishing its technical specifications as an open standard. Wouldn't the company be better off just keeping the technology for itself instead of creating competition? The answer is a resounding no. Consumers of information technologies all but demand open technologies. Thus, a technology manufacturer would find a much larger potential customer base awaiting an open-standards product than it would for a proprietary product. Another benefit is that the company has a distinct advantage over other companies. Simply stated, it has already developed its product, and it can start selling it long before other companies, which have to start from scratch.

Creating Propriety Through Openness

The final nail in the coffin of altruism is found in how some companies manipulate the process of open-standards development. RFC 2119, also known as BCP #14, spells out acceptable language to use in an RFC or similar document used to define new open standard technologies. Acceptable wording describing a function's criticality includes the following:

• MUST

• MUST NOT

• REQUIRED

• SHALL

• SHALL NOT

• SHOULD

• SHOULD NOT

• RECOMMENDED

• MAY

• OPTIONAL

These words are intentionally capitalized, as they are in the various IETF publications, to indicate compliance with their definitions in RFC 2119/BCP #14. This isn't a very long or difficult-to-read document. It should be one of the first things you read as you start to familiarize yourself with the works of the IETF, including the IP address space. It can be found at www.ietf.org/rfc/rfc2119.txt

Despite this careful attempt at creating consistency in products based on open standards, inconsistency continues to abound. Each technology manufacturer is given latitude in defining how closely its product conforms to the recommended specification. The words SHOULD, SHOULD NOT, MAY, RECOMMENDED, and OPTIONAL are almost an invitation for variation. Thus, depending on how well two or more manufacturers adhere to the recommendation of an open-standards document, their products might interoperate with varying degrees of success. The only way to achieve perfect operability is to maintain a single-vendor infrastructure, thereby defeating the very purpose of openness.

Another interesting way that actual products might vary from the open standard is to include additional functions or features that are absent from the standards document. Such technologies or products might still legitimately claim to be "open-standard" and are founded on the belief that they embrace the open standard and then extend it. This belief also leads to the creation of a proprietary architecture within an otherwise open-standards technology.