IT STANDARDS TUTORIAL Part IV – Standardization Processes

1. ITSTANDARDSTUTORIALPart IV – Standardization Processes

2. Goals of Standards Process • Well-Defined Product: • Consistent implementations • Coherent functionality • Commercial Viability: • Allows range of implementations • Commercial products are possible • Promotes wide adoption • No “Standards-for-Standards-Sake” (e.g., some standards consultant dominated projects) • Wide acceptance: • Many conforming implementations • Few bugs: • Low number of defect reports

3. IT Standards Development Processes • International Standards Development • De jure Process • Professional Society Process • Industry Association Process • Consortia Process • Government Process

4. DIFFERENT APPROACHES TOP DOWN - Treaty-type organization such as the ITU BOTTOM-UP - Voluntary-type organization such as ISO/IEC “FLY-BEFORE-YOU-BUY” - Internet Society approach

5. TYPES 1 - OPEN Standards and specifications are considered “open” when sponsored and supported by an organization which uses an open, public consensus process to develop and maintain them 2 - CLOSED Controlled, usually, in a proprietary fashion; often referred to as de facto specifications

6. TYPES TWO KINDS OF OPEN STANDARDS: * Formally recognizedstandards body which produces and distributes formal or de jure, public standards * Informal organizationsthat produce specifications such as industry standards; called de facto specifications (which are sometimes submitted to formal standards bodies for accreditation or adoption to become formally recognized)

7. CATEGORIES 1 - PRODUCT Standards 2 - CONTROL Standards 3 - PROCESS Standards 4 - PERFORMANCE Standards

8. CATEGORIES PRODUCT STANDARDS Product standards embody information. They specify the characteristics of a product and permit product identification, interoperability, and quality control. E.g., VCR standards, machine bolt thread sizes, encryption specifications, etc.

9. CATEGORIES CONTROL STANDARDS Control Standards are designed to address a societal hazard or problem. They generally define a range of acceptability with respect to the design, performance, and/or use of a product. They often appear in the form of regulations e.g., building codes, fuel economy standards, auto safety, etc.

10. CATEGORIES PROCESS STANDARDS Process Standards facilitate and support socioeconomic transactions and interactions. They define roles and relationships, establish the rules of interpreting behavior, and specify the way in which a particular procedure or process is executed. Examples are EDI specifications that not only govern standardized electronic procedures for economic interactions, but also establish common protocols for business interactions and determine roles and relationships between suppliers, manufacturers, and customs. E.g., language, customs, bills of lading, growing of Smithfield ham, certified processes, etc.

11. CATEGORIES PERFORMANCE STANDARDS Performance standards state requirements in terms of required results with criteria for verifying compliance, but without stating the methods [processes] for achieving the required results. They define the ‘functional’ requirements for the item, environment in which it must operate, and interface and interchangeability characteristics. E.g., SGML, CGM, STEP, etc.

12. “12 WaystoPublishYourSpecification”

13. What Do You Want To BeWhen You Grow Up? ISO Standard Consortia Spec Publicly Available Spec de jure Standard Multi- Lateral Agreement National Standard Industry Spec ISO Tech Spec Professional Society Standard

14. How Mature Is Your Base? • Technology Currency? • Global Participation? • Stability? • Ubiquity? • Vendor Support? • Implementation Extent?

15. 12 WAYS... • 3 Kinds of Sponsors: A) Accredited Standards Body B) Government C) Industry Association / Professional Society / Consortium

16. 12 WAYS... • Government • National Standard (each National Body) • Multi-Lateral Agreement • Non-Accredited Organization • Professional Society/Industry Specification • Consortia • De jure Accredited Standards Body • SC4 New Project 6,7,8. SC4 ‘External Harvesting’ Alternatives • ISO/IEC JTC1 SC32 • JTC1 PAS • Other ISO or IEC TC • New Direct Process

17. INTERNATIONAL STANDARDS DEVELOPMENT

18. Generic Steps to Developing an International Standard International Standard Draft for Public Review Committee Draft STAGES OF DEVELOPMENT New Work Item

19. Steps to Becoming an Accredited International Standard (IS) in ISO IS International Standard DIS Draft International Standard CD Committee Draft NWI STAGES OF DEVELOPMENT New Work Item 2 - 3 years

20. Steps to Becoming an Accredited International Standard (IS) ISO Technical Committee Sub Committee Working Group ORGANIZATION HEIRARCHY

21. Steps to Becoming an Accredited International Standard (IS) ISO Technical Committee Sub Committee ORGANIZATION HEIRARCHY Working Group Technical Editor National Body Technical Experts

22. Steps to Becoming an Accredited Standard ORGANIZATION HEIRARCHY Working Group Convenor Technical Editor National Body Technical Experts

23. Steps to Becoming an Accredited International Standard (IS) US Example ORGANIZATION HEIRARCHY U.S. Participation Working Group Convenor Technical Editor National Body Technical Experts U.S. Micro Soft Etc IEEE Compac NCITS IBM DOD HP SUN

24. Steps to Becoming an Accredited International Standard (IS) ISO JTC1 SC 24 Working Group 8 CGM Example Technical Editor National Body Technical Experts

25. Steps to Becoming an Accredited International Standard (IS) ISO JTC1 SC 24 Technical Editors VRML Example Draft Specification VRML CONSORTIUM

26. DEVELOPMENT • An engineering and management process • Consider relevant industry input: Need to include all stakeholders with “material interest”, e.g., vendors, testers, producers, users, government, etc. • Produces a technical document (specification)

27. DEVELOPMENT Engineering Process [1] • Identify scope • Use proven engineering methodology • Preference for existing commercial practice • Don’t standardize implementations - Standardize specifications

28. DEVELOPMENTEngineering Process [2] • Can new technology be incorporated? • Technology horizon: • Which technology incorporated? Feasible/commercial, up to 1-2 years from now • How long should standard be useful? At least 5-10 years from now

29. DEVELOPMENTEngineering Process [3] • Risk management: scope, prior art, schedule • Determining requirements • Asking the right questions (1-3 years?) • Document organization and phasing • Base documents -- starting points • Proposals and papers -- additions

30. DEVELOPMENTEngineering Process [4] • Developing standards wording ... • Step #0: Requirements identification (optional) • Step #1: Functionality: what it does • Step #2: Conceptual model: how it works • Step #3: Semantics: precise description of features • Step #4: Bindings: transform into target, e.g., application programming interfaces (APIs), syntax, commands, protocol definition, file format, codings • Step #5: Encodings: bit/octet formats (optional) • Step #6: Standards words: “legal” wording

31. DEVELOPMENTEngineering Process [5] • Let bake – settle over time • Baking is very important • Shakes out subtle bugs • Greatly improves quality! • Usually, vendors fight “baking” ... want to announce “conforming” products ASAP

32. DEVELOPMENTConsider Relevant Input • Stakeholders/Sources: • Commercial products and services • Industry participants • Government • Developers • Producers • Manufacturers • Testers • Users • Researchers • Etc.

33. DEVELOPMENTTechnical Specification [1] • Assertions: • Sentences using “shall” • Weaker assertions: “should”, “may” • Inquiries/Ranges: • Implementations have varying limitations • Interoperability: tolerances vs. minimums • Allows implementation-defined and unspecified behavior • Negotiations: • Adaptation to conformance levels

34. DEVELOPMENTTechnical Specification [2] • Conformance: • Complies with all assertions • Performs in range allowed within inquiries/ranges and negotiations • Minimize implementation-defined, unspecified, and undefined behavior

35. DEVELOPMENTTechnical Specification [3] • Applications and standards use: • Strictly conforming: uses features that exist in all implementations • Conforming: uses features in some conforming implementations • Conformance levels vs. interoperability

36. DEVELOPMENTTechnical Specification [4] • Rationale: • Explanation of important committee decisions • Features considered/rejected • Allows for change in membership • Helps with Requests for Interpretation

37. Building Consensus • Public review cycles: • Related industries and stakeholders • Liaisons • Responding to comments • Ballot: • Solidifying consensus -- issues resolved, not revisited • Resolving disputes • May require several iterations • Approval: • Document can be published • Can measure conformance

38. Maintenance [1] • Defect reports: • Bug reports • Fix features, as necessary • Many defect reports ==> weak standard • Weak standard ==> little acceptance/use • Little acceptance/use ==> failure • Consistent responses -- highly desirable

39. Maintenance [2] • Other deliverables: • Record of responses (to RFIs) • Technical corrigenda (for defect reports) • Amendments • Next revision: • Reaffirm • Revise • Withdraw

40. STANDARDSTUTORIALPart V – Standards Life Cycle

41. Comparison of Life Cycles Highlight similarities IEEE, W3C, IETF, de jure, ITU, etc.

42. User / Vendor Needs Assessment Committee Draft (CD) International Standard (IS) Draft International Standard (DIS) Working Draft (WD) Development Consensus and Verification Validation, Consensus and Fixes Standards Development

43. Paradigm Comparisons • De jure community (ISO, ANSI, NCITS, etc.) • Consortia (OASIS, W3C, IETF) • Professional Society (IEEE, ACM) • Industry Association (EIA/GEIA, etc.) • Federal Government (DSP, FIPS, FGDC)

44. Paradigm Comparisons

45. Paradigm Comparisons

46. Paradigm Comparisons

47. Paradigm Comparisons Note: ANSI accreditation implies that accredited organizations will comply with ANSI rules and processes for developing standards that will be submitted for ANSI or International Standard approval.

48. Choosing the right “process” is not trivial Accreditation affords consistent process Committees don’t reinvent wheel Accredited process is well-tested and “off the shelf” Consensus is significant Broad participation yields better quality results but make for slower process Development ConsensusBuilding Generic IT Standards Life Cycle Consistency Via Accredited Process Revise, Reaffirm, Withdraw Maintenance

49. Source: “from scratch” or “base documents” Create “standards wording” (normative and informative), rationale for decisions Technical committee: in-person or electronic collaboration Generic IT Standards Life Cycle:DEVELOPMENT DEVELOPMENT

50. Collaboration, harmon-ization, refinement Public reviews as soon as possible Public comments Resolution of comments Approval stages: Working draft Committee draft Draft Standard Approved Standard Generic IT Standards Life Cycle:CONSENSUS BUILDING CONSENSUSBUILDING Development