Appendix C. The Standardization Process

Open systems are predicated on common standards that define how protocols and interfaces should perform. Ideally, if different vendors engineer products to the same standards, the products should function in an identical manner and should be interoperable. This homogenization of functionality does not preclude proprietary value-added features but simply establishes the common ground for base features across multivendor environments. The IETF standard for SNMP management, for example, defines common Management Information Bases (MIBs) for Ethernet, Token Ring, and so on. Vendors may also include proprietary management functionality through vendor-specific MIB extensions. The vendor that complies with standard MIBs may supply additional proprietary MIBs, which are then made to comply with the SNMP management platform so that the customer can monitor both standard and vendor-specific values of a specific product. This flexibility ensures that customers can go to multiple vendors to source similar products (thus achieving the benefit of open systems) while having the option to choose one vendor over another on the basis of value-added functionality.

How, specifically, the industry settles on which features are desirable for open systems implementation and which features are best assigned to vendors' unique value propositions is worked out through the standardization process. Vendors and technologists must reach a consensus on the essential requirements of a technology without burdening the proposed standard with excessive demands. Including too many requirements slows the standards process and delays introduction of solutions to the market. Failing to accommodate essential requirements, on the other hand, undermines open systems and inhibits interoperability. Therefore, reaching agreement on a balance of base requirements is never a simple task and often requires sustained discussion and debate before resolution is reached.

The standardization process may vary in detail from one standards organization to another but is commonly based on elementary democratic principles. Participation is generally open to anyone, or if membership in a standards organization is required, it is based on a minimal and reasonable fee. This policy encourages participation by vendors that have a vested interest in a technology and by technologists or academics whose interest is more objective. Any participant can introduce proposals for standards or proposed revisions, with simple peer pressure acting to discourage frivolous or poorly formulated submissions. Discussion and debate are typically conducted via readily accessible channels such as Internet reflector e-mail threads, conference calls, and periodic face-to-face meetings. In the IETF, for example, anyone with Internet access can join a working group reflector, assuming that the person has the endurance to follow the discussions and sufficient disk space to save the e-mail threads.

During a proposal or standards discussion, difficult or tangential issues that delay or divert the process may be tabled by majority agreement or by recommendation of a workgroup chair. Typically, multiple facets of a specification are discussed concurrently so that the proposal as a whole gets fleshed out simultaneously instead of sequentially. Interim revision levels of a proposal mark the overall progress to date, until eventually a 1.0 version is released as standard. These thresholds serve as checks and balances, ensuring open discussion and majority agreement before the process passes to the next level. A last call for comment offers an open forum for any additions or critique, after which a specification may undergo a final review by officials of the standards organization before a standards identifier is issued.

As shown in Figure C-1, requirements for a proposed standard may be defined by a work group within the relevant standards body or by technical work groups in other contributing organizations. The requirements definition for SNMP management of Fibre Channel devices, for example, was conducted in the SNIA technical workgroups and the renegade Fibre Alliance before being submitted to the IETF for further standards track work. Much of the requirements work for extended copy (third-party copy) was also done by the SNIA and then handed to ANSI T10 for standardization. The InfiniBand Trade Association (IBTA), by contrast, conducts its own requirements definition and standards development internally.

Figure C-1. During development, standards drafts may be validated via compliance testing

Compliance testing is an important complement to the standards process. This work may be done externally, as in the case of the University of New Hampshire's work on behalf of both Fibre Channel and iSCSI standards development. The aim of compliance testing is to validate vendor implementation of various revision levels of a proposed standard and to identify omissions in the standards draft itself. Compliance testing is done via test suites or scripts that exercise the main features of a proposed standard and verify appropriate response by vendor products. Compliance to fabric login, for example, is tested by sending the requisite login streams to a switch and monitoring the conversation between the switch and the test device. It is thus possible to verify compliance to properly formatted protocol streams as well as to test the response to invalid streams. The FCIA has codified much of the lower-level Fibre Channel protocol compliance testing in its SANmark program, giving vendors an industry-recognized stamp of approval for passing through a hierarchy of compliance testing. The SNIA Interoperability Committee has established the Interoperability Compliance Test Program (ICTP) to create test harnesses for a variety of SNIA-sponsored standards initiatives, including iSCSI adapter management, iSNS discovery, and storage-specific CIM/WBEM specifications.

Achieving the status of a completed and released standard is by no means the conclusion of this extended process. Work on technology standards is an ongoing process, and as indicated in Figure C-1, release of the 1.0 version of a standard may immediately launch new work on the 2.0 version.

Although not all this activity is free from vendor influence and maneuvering, it is still an amazingly objective and democratic process and fosters cooperation and camaraderie within the technical community. Having many cooks in the soup sometimes makes dinner a bit late, but it is far better than the eclectic and proprietary fare that otherwise would be served to customers.