top of page
  • Marta Beckwith

Input on the United States Government National Standards Strategy for CET - Part 1

The Department of Commerce of the United States government in conjunction with the U.S. National Institute of Standard and Technology (“NIST”) has asked stakeholders and the public to provide input into Implementation of the United States Government National Standards Strategy for Critical and Emerging Technology. They have provided a long list of complex questions and a very short time frame for comments. You can find the notice here:

I’m going to start by saying that if they really wanted input from the public and from small and medium size businesses (SMEs), they should have better publicized the request, beaten the bushes to get responses (e.g. been out there talking to members of the public and SMEs and hosting many more forums than they have planned) and given a longer time frame for response.

Putting that issue aside, I find the request hard to respond to because of the way the questions are phrased and because the questions that are asked do not get to the heart of the matter. There are many different ways that government can help, or hinder, standard development and adoption. So here’s my attempt to answer the bigger picture question of when and how government intervention and support is needed. This first post focuses on when and how “private”[1] standardization is likely to be successful. I will have a second post later this week that will focus on when and what government support is necessary or useful to support standard development, standard adoption and/or standard implementation, with a focus on technologies on the Critical and Emerging Technologies List Update.[2]

What Makes for Successful Private Standardization?

While government can play a role in supporting private standardization, such support should not generally be during development of a standard for which private standardization is likely to be successful. So what makes for successful private standard development?

Here are the attributes that are likely to lead to successful private standardization:

  • Aligned and Skillful Implementers: Enough implementers and potential implementers across the value chain, but not so many that the market is highly fragmented. Those implementers and potential implementers should have:

    • the necessary technical expertise to develop the standard; and

    • aligned interests and motivation to develop a standard.

Often, although not always, this happens when the standard relates to interoperability and interoperability is important.

  • Market Opportunity: The standard development is done at the right time for the standardized products to arrive in the marketplace, the market is likely to be robust (there is pent up demand) and implementers and potential implementers across the value chain believe they will sell more products and services if the standard is implemented.

  • Existing Infrastructure: There is existing infrastructure that can be used or adapted to support implementation.

  • Existing Organizational Support. Most successful standardization efforts need the support of a standard development organization with the experience and bandwidth necessary to foster the development efforts. At a minimum, a standard requires a standard setting organization for adoption as a standard.[3]

  • Supportive Regulatory Environment. The regulatory environment supports (or at least does not interfere with) the standard or its implementation.

Let’s take 802.11 (WiFi) as an example. Wireless communications require at least two different types of devices: a user device and an access point. The user device must be enabled to connect wirelessly to the access point and the access point must be connected to a network that can carry whatever type of communications is being transmitted from the user device (or converted in the access point or another device to a communications protocol type that can be carried on the available network).

During the 802.11 a/b development you had:

  • Implementers: A wide range of implementers and potential implementer from startups to large multinationals each of which brought significant technical expertise to the table. Participating entities included companies across the value chain: service providers (the super users of most networking technology), user device manufactures of varying kinds (bar code readers, cellular telephones, computers), entities intending to make access points and chipmakers. Despite many of the participants being competitors in their market space (and several of them being, at the time, involved in bitter patent disputes with each other), their interests were aligned when it came to developing a workable standard. In other words, there was an entire ecosystem of companies with technical expertise and reasonably aligned interests, all of which were motivated to develop a viable wireless standard and believed that interoperability would lead to increased sales of their own products.

  • Market Opportunity. There was already demand in the marketplace for a wireless technology to allow certain user devices (cash registers, laptops, bar code scanners, etc.) to connect to existing networks wirelessly at least in circumstances in which it was impractical or prohibitively expensive to use wireline connections. Several companies (which ended up being part of the standard development efforts) had already tried to develop their own wireless technologies, but it became apparent to these companies that a standardized solution would be more useful than a multitude of different technologies that did not allow for interoperability. In other words, there was existing demand and interoperability was clearly needed so these otherwise competitive companies were motivated to develop a standard.

  • Infrastructure. There were existing chip companies that could retool to make wireless chips, existing user device makers and network equipment makers that had the capacity to use those wireless chips in their products and existing service providers that could integrate those products into their networks. All of these stakeholders participated in the development efforts.

  • Existing Organizational Support. The 802.11 standard was supported by the IEEE during its development and used many of the existing IEEE tools and the framework that had been created or improved during earlier IEEE development efforts.

  • Regulatory Environment. And you had regulatory changes that helped.[4]

When is Private Standardization Unlikely to Be Successful

Private standardization is unlikely to be needed (and thus unlikely to be successful) if the technology is important only to a small group of companies and will only be implemented by a few companies. So, for example, the Critical and Emerging Technologies List Update includes semiconductor manufacturing technologies and manufacturing equipment. This is an area where there are (comparatively) few equipment providers and a (relatively) small number of equipment customers. To the extent interoperability or some type of uniformity is needed, the industry is likely to drive to that solution without any formal standard setting.

In other words, not every type of interoperability needs formal standard setting. In industries with limited and sophisticated stakeholders, the stakeholders can often work it out themselves informally or through industry organizations, often without formal standard setting. But, in these circumstances, government intervention for standard development is not likely to be helpful, and may even be harmful if it distracts those companies from other, more important development efforts or gets in the way of the industry solving its own interoperability needs.

Private standardization also is unlikely to be successful if one or more of the other attributes of successful standardization is not present. For example, private standardization is unlikely to be successful when the technology is one that product makers intend to use to differentiate their products from each other (e.g. they believe they will sell more products by using their own solutions rather than by using a standardized technology) and/or when implementation is likely to lead to increased costs without increased sales or other business advantages. In some of these circumstances, government support for standards development is needed. More to come on this in my next post.

[1] By private, I mean the development of a standard in a non-governmental standard development body such as the IEEE, IETF or 3GPP.

[3] Although most successful standardization efforts have required the auspices of an SDO during development, there have been a few in which the technology has been mostly developed outside an SDO and then “donated” to the standard setting organization (SSO) for finalization and adoption as a standard. For example, the Session Initiation Protocol (“SIP”) which is used for VoIP communications was primarily developed by a few University professors and their graduate students working sometimes under the auspices of a small number of companies for which one or the other of the developers worked at various times during the development. The technology was then provided to the IETF to be adopted as a standard and became RFC 2543.


Commenting has been turned off.
bottom of page