There was general agreement that the most critical aspect of the process was getting agreement among the participants. It became clear that there were two agreements to be reached, one at the technical level, and one at the adoption level. The caused Oksala to suggest that one of our problems is to determine what ``approval'' really means. As he sees it, ``approval'' of a standard might mean one or more of four different things:
The first two meanings are closely related to the formal definitions of approval that are set up by the various standards developing organizations. The latter two meanings reflect on the end result that is sought -- adoption of the standard. While one would hope that the organizations involved in approving a standard are those who would in turn develop products, such is not always the case. If a standard is approved with little consensus, developers and consumers may choose to ignore it in the adoption phase. Similarly, it is sometimes, we hope rarely, the case that a standard may be approved in a show of apathy -- not caring one way or another about it. It may well be that developer organizations approved OSI standards based on government interest in them, but failed to push the development of product forward when government purchases failed to match the expressed government interest.
- A majority of the participants in the developing group voted for it.
- Public comment was solicited and responded to in a fair way, and there was no significant opposition.
- The three largest companies in the industry agreed on it.
- More people buy products that conform to the standard than buy products that don't conform.
There was also agreement that approval was the result of achieving consensus. Within all of the standards development communities there is a high priority placed on achieving consensus. Oksala defines consensus as ``the absence of significant sustained opposition AND a sufficient level of support.'' Given a definition of a good standard as one that everyone uses, consensus seems like the logical step in the process. This suggests that the development of a standard may be further subdivided into those parts of the process that work toward consensus and those parts that look toward approval at the technical and political levels.
One of the issues that did not surface during the discussion of adoption was the difference between adopting a proprietary solution or a public specification and the adoption of a standard developed in committee. While a publicly developed standard can be changed, and while market pressures and momentum may keep a public specification stable, the commitment to stability and the public nature of the change are very different. One can assume that the specification of 802.3 will not be changed arbitrarily by one organization and that any plans to change the standard will be made known in a public forum. No such assumption can be made about a proprietary approach or a public specification which are controlled exclusively by their owners and may be changed in secret and without notice.