Gary S. Robinson

Standards Give You Control

Most of the columns that I have written so far have been based on the standards process. I felt it was the most important information that I could help others with. Now, before I continue with more discussions of the process in the wonderful world of standards, let’s take a short break and discuss the reasons you would want to develop a specification into a standard. Why should you work for an open standard, that is, contribute a specification to a Standards Development Organization or consortia? Why become involved in the processes of an SDO or consortium? I can give you at least two key reasons. Primarily, a standard opens a new market, one in addition to those that already exist. Even more important sometimes, a standard gives you more control over your specification than you thought you had.

ANSI's role in standards development

ANSI is the American National Standards Institute, the US national coordinating institute for voluntary standards. Typically, you will see ANSI in a standards name followed by some letters and numbers such as X3.181-1980. These characters represent the full name of the standard and the year it was published. Does this mean that ANSI wrote the standard and published it? No. ANSI itself does not write standards. ANSI develops the procedures that standards developing organizations, SDOs, use to develop standards. It also reviews the procedures and processes that the SDOs use, and in the end approves the standards that SDOs develop to become ANSI standards. For many industries, it is very important to have the name of the standard include ANSI because ANSI is respected, is known throughout the world, and has an excellent track record of openness and fairness. All IEEE standards developed by the Computer Society and many other groups automatically seek ANSI approval after they become approved IEEE standards.

Why standards are here to stay

I’ve been reviewing some interesting articles for the 2001 Conference on Standardization and Innovation in Information Technology (SIIT), which will take place from 3-5 October 2001 at the University of Colorado, Boulder (http://www. siit2001.org). The first SIIT was held in September 1999 in Aachen, Germany. After reading these articles, I am reassured that standards are alive and well. The process could be better, but it’s working. The papers at SIIT are international and academic, and they all focus on standards in some way. By “academic,” I don’t mean all the papers and participants are from universities. I mean that rather than focusing on specific technical standards, these papers approach standards at the metalevel. They discuss such topics as the life of standards, the need for standards, the standards process, and how to use standards in unique situations.

International standards: why do them?

A friend recently asked me to help him write a justification for turning a proposed American National Standards Institute (ANSI) standard into an international one, and I think it’s worth elaborating on here. I’ll skip over the bit about why you should standardize a specification in the first place—a very large subject that has been, and will continue to be, discussed in many publications. Instead, I’d like to begin by explaining what an international standard is. The best way to do this is to explain what constitutes a noninternational standard. As in previous columns, I will limit my discussion to information technology standards. In the US, most IT standards—those from the IEEE, Telecommunications Industry Association (TIA), Electronics Industries Association (EIA), T10-SCSI, T11FibreChannel, and so on—carry the ANSI identifier. These are all national US standards. Informal standards groups and consortia can also develop standards, but these standards do not carry the ANSI title.

Starting an international standard

Recently I received e-mail from a standards developer asking me how to make an IEEE standard into an international standard. I explained that the procedure used to develop international standards was very difficult and secret. The reason I gave for this secrecy was that I wanted to guarantee that when we standards experts retire, we could enjoy gainful employment as consultants on international standards development. Of course, I was joking. The process is actually very simple and, except in unusual cases, fast. However, this e-mail exposed a big problem: not many people from the US are involved in international standards, and few written instructions on the process of starting them exist. The current method of training involves mentoring. If you’re interested in the international process, you bounce around for a while, find the right committee, and then attend meetings, all the while learning on the job. So I thought it might be useful to take some time in this column, which has a fairly wide distribution among potential standards developers, to describe the actual process. The first step, which my e-mail sender has already passed, is to recognize the need for an international standard. National standards are a great first step. They document an agreement among many parties and produce a carefully written specification for use by many people. But international standards go one step further. Internationally, standards give us worldwide consistency of design, manufacturing, training, and expanding markets. International standards also enable government procurement, which is much more invasive internationally than in the US. In the next step, you need to determine where to go in the international standard-developing organization (SDO) arena. There are three major international SDOs: the International Organization for Standardization (ISO), the International Electrotechnical Committee (IEC), and the International Telecommunication Union (ITU). Without going into the scope of each of these, most of the average Micro reader’s potential standards development work would occur in ISO/IEC Joint Technical Committee 1 (JTC1) subcommittees like SC6, SC25, or SC26. Therefore I limit my explanation to the process used in these committees. The IEEE Standards Board published a document called ISO/IEC JTC1 Synchronization. This document details the synchronization of the IEEE and JTC1 standards processes. To delve deeper, you can get a copy of the synchronization guide, you can attend international meetings, or if you don’t feel ready for that yet, you can read this primer. Work on an international standard begins at any of the following three stages of IEEE standardization:

Active Standards Projects [Micro Standards]

asked if I would be interested in writing about standards for IEEE Micro. As you can readily see, I agreed and joined the Editorial Board. Though I am new to Micro and to this column, I am not new to standards. I have been involved in information technology standards for over 30 years and have worked full time in this field for the last 20 years. My standards work has given me the privilege of meeting and getting to know many people in our industry, and of seeing how many, but not all, standards developing organizations (SDOs) develop standards. I have worked in ISO (International Organization for Standardization), ECMA, ANSI (American National Standards Institute), X3 (an Accredited Standards Committee newly named the National Committee for Information Technology Standardization, or NCITS), IEEE, BSI (British Standards Institute), JIS (Japanese Industrial Standards), DIN (Deutsches Institute für Normung, German standards body), and many other SDOs. For one reason or another, I’ve sat in on many of their working groups, technical committees, and administrative committees. In the IEEE, I introduced Ethernet and was part of the group that produced P802 (P indicates a proposed standard) and then carried the approved standard to ISO. I am still the project editor for IS 8802.3. I have chaired the RevCom (Revision Committee) for IEEE Standards as well as served on the Board. I’ve also chaired the Computer Society Standards Activity Board and many other committees. For my first column, I thought it would be useful to list the active, not yet approved, projects in the IEEE CS (see Tables 1-3). For more details on any of the items below as well as approved standards, see the IEEE Standards Web page at http://stdsbbs.ieee.org/products/index.html. In future columns, I’ll list the active projects in other technical committees and in the former X3’s 3T10 committee. If you have questions or suggestions for other standards information you’d like to learn about, e-mail me at gary.robinson@east.sun.com.

Micro standards: truth and specious urban myths

Lets start with two simple and very important facts. First, standards development has changed dramatically over the years. Its initial thrust was to allow manufacturers the ability to produce hardware faster and less expensively through standardized steps (economies of scale and all that). Next came the intent to standardize to increase market penetration (creation of a larger market and increased sales into the larger market). Now we use standards to reduce time to market by introducing new ideas and concepts into standardization first (witness the Web). Is this bad? I think not; its merely another way of making a technology usable and known to a larger and larger audience. In my opinion, standards are a discipline, and people tend to use a discipline for a myriad divergent reasons. The market (the users and the providers) will decide a standards fate-not a committee sitting in judgment.