Bringing Standards to Life

The promise of a technology standard, unlike a closed or proprietary vendor solution, is that when all the players in a given ecosystem agree to do certain things the same way, implementations from different vendors will work with each other “out of the box.” This reduces time to market, gives customers more flexibility, and allows the vendor community to invest in and collaborate on innovative capabilities, rather than “reinventing the wheel” for common functions. One of the most successful examples of a technology standard is the Internet itself. Imagine if each web designer had to invent HTML or HTTP every time he or she set out to create a web site. Not only would there be innumerable private networks required to carry the traffic of all these different efforts, there would probably be no time left over to develop an Amazon, a Google, or even a personal web page.

The release of a standard is often celebrated as an industry milestone, and for good reason. Getting a group of opinionated, strong-willed technologists (who generally work for competing companies) to agree on the same approach is no easy task. Any published standard represents hours of tedious technical work and compromises, building on the combined and sometimes conflicting expertise of several individuals. Good standards represent the best a group of companies has to offer an industry in which they all play a part.

On the other hand, a standard is hardly the end of the road. Instead, it is perhaps best understood as a grammar textbook: it tells a speaker how to construct sentences that can be understood by any listener. These fundamental rules are essential. If I tell you that a dog bit me, it’s important that you have the same understanding of what a dog is and what it means for it to bite. On the other hand, understanding the theory of verb conjugation doesn’t get you very far when, for example, you need directions in a foreign country. This is the experience many engineers have when they attempt to implement a standard for the first time. The amount of heavy lifting in front of them to turn a document into a product can be daunting.

Engineers building an actual product who read a standard for the first time might have questions about the specification, especially since they are often unlikely to have been involved in the standards process themselves and probably lack the context behind many of the compromises reached. This problem is compounded by the fact that the standard itself isn’t owned by any one person within their company, it’s owned by the standards consortium, so obtaining answers to questions can be challenging. In addition, the standard may have ambiguous portions that are interpreted differently by different organizations. What might have appeared clear during a document editing process could turn out to be far more confusing in practice, especially as subtle distinctions, corner cases and error conditions are considered. The specification may even contain a few errors, since even with a number of eyes reviewing the document; it’s rare to get something entirely right the first time. That also explains why initial implementations can contain bugs and errors that keep them from properly working with other implementations.

Given this potential for ambiguity, customers should be wary of vendor claims about standards conformance. These claims should be backed with real proof, whether it be demonstrated ability to work with other vendors or official certification, especially as some vendors may exploit the confusion. To reduce the potential for confusion, there are a number of activities that individual companies and industry consortia can take to ensure that members all understand and interpret the standard correctly. These include plugfests, certification programs and partner programs.

Plugfests are among the most important events for standards organizations. They provide a neutral venue where vendors can clarify and resolve issues related to the specification and their own implementations. These events can be thought of as group conversation classes in the standard language; a group of people get together and ensure that, as they attempt to speak it, they can actually understand each other and improve their use of the language. Usually protected by extremely strong nondisclosure agreements that prohibit public discussion of testing results, plugfests often bring out a surprising level of open collaboration among members of an otherwise competitive vendor community. Shielded from customer scrutiny, companies bring implementations at all levels of completion, from shipping product to prototype models that have yet to even go through a full in-house test process.

What is most surprising about these events is the strong collaborative attitude. Engineers working for market rivals often help troubleshoot their competitors’ implementations, assist each other in researching the finer technical details of various protocols, and work together to solve problems. They do this because it improves the viability of their own products, exposes them to a wide range of industry players that they may need to work with later, and provides access to broader feedback on their own questions about the standard. It also provides the opportunity to create a positive feedback loop with the organization that created the specification, in the form of joint questions and clarifications from those who use the standard on a daily basis.

Some standards consortia require that a certain level of interoperability be demonstrated by vendors before a particular protocol can be ratified and published to the industry at large. Other industries take the concept of testing one step further, creating certification logo programs. These programs create test plans that validate conformance to (and potential interoperability within) a particular standard. Vendors who pass the test are allowed to put a sticker or some other certification mark on their product to promote their adherence to the standard. These are especially prominent in the consumer electronics industry. Pick up a home networking device at any given retailer and you’re likely to see marks for WiFi certification, DLNA (Digital Living Network Alliance) and UPnP (Universal Plug and Play) certification, as well as Underwriters Laboratory (UL) certification (indicating that the device adheres to the specifications for power usage and safety in the US). Other certification marks are geared more towards service providers to let them know that equipment conforms to specifications that align with their interests. For example, CableLabs has a long history of certifying cable modems for DOCSIS (Data Over Cable Service Interface Specification) compliance, and Independent Test Labs (ITLs) certifies compliance with certain DSL Forum specifications for DSL providers in Europe.

To complement these activities at the industry level, some companies further invest in partner interoperability programs to ensure that their products work with others. These programs may pre-date industry-level interoperability events, or they may augment the level of testing performed. They may also simply give companies additional testing opportunities outside of periodic industry events. In the highest value cases, they provide “real life” style use-case testing to ensure that implementations don’t just work together in a generic way, but that they can actually function together as they would in a true deployment. Sometimes mutual customers will strongly “suggest” that two companies work together behind the scenes to validate interoperability and specification conformance to reduce the potential for issues during deployment. Customers may also do their own in-house testing to validate or augment a vendor’s test.

The time that follows the ratification of a standard is often an intense period marked by competing claims of compliance, questions about specification requirements, and vendors trying to beat each other to market, while at the same time collaborating at plugfests and within standards groups. Customers and the industry at large should prepare for this activity -- sometimes there is disappointment at the lack of immediate interoperability after ratification, or concern about the amount of work still required to make early implementations actually work. However, this phase of activity is normal and as much a part of the process as the disagreements and compromises required to get to the final specification. Achieving interoperability is a thankless job. Those engineers and testers who show up at a plugfest, and spend hours in a lab debugging their own and their competitors’ and partners’ products (as well as the specifications themselves), are unsung heroes. They help ensure that the work coming out of the standards consortium is not just a piece of documentation, but a tool that delivers value to their companies and their customers. Without these dedicated experts and the work they do, the promise of standardization would remain only that: a promise.

Heather Kirksey is a member of the DSL Forum’s Board of Directors and co-chair of the DSL Home-Technical Working Group. At Motive, Inc., she directs the strategy and execution of the company’s device management and digital home standards initiatives.