Two-Stage IETF Standardization
draft-crocker-ietf-twostage-00

Abstract

RFC 2026 specifies a three-stage Standards Track. As currently practiced, IETF standards track documents typically attain only the first stage. This proposal discusses the problems caused by the disparity between documented procedures and actual practice, and proposes a simplified, two-step standard track, which will streamline the IETF standardization process, with distinct benefits for each stage. Clarification of the criteria for handling documents re-submitted as Proposed Standard is also provided.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on May 13, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Proposed Changes
    2.1.  Standards Levels
    2.2.  Status Review
    2.3.  Downward References Permitted
3.  Two IETF Standards Levels
    3.1.  Proposed Standard (PS)
    3.2.  Resubmission of a PS Document for PS
    3.3.  [Full] Internet Standard (IS)
4.  Differences from HousleyTwoLevel
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative
§  Authors' Addresses

1.  Introduction

Officially, the IETF uses a three-stage standards track, roughly defined in terms of completed specification, initial implementation, and successful deployment and use.[RFC2026] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) In practice the Internet has been running primarily on entry level (Proposed Standard) specifications for many years. Furthermore, the periodic IESG review of "immature" standards that is called for in section 6.2 of [TwoStage] (Dawkins, S., “Two Stage Standardization Approach,” September 1998.) seldom happens. This can cause confusion for implementers who fear that a Proposed Standard is unstable and subject to change. This also fails to distinguish established protocols from those that are newer. More generally, a standards organization ought to have meaningful labels and it ought to use them. The proposed change recommended here will streamline the formal IETF standardization process, remove confusion, improve transparency and clarify the benefits for each stage.

Current IETF standards labeling has a number of harmful properties:

• Our documented process isn't what we use in practice. This disparity creates opportunities for miscommunication, which in turn can produce mistrust. At the least, a new implementor or product planner has poor guidance from the IETF, concerning what is and is not viable.
• Consumers of IETF specifications have learned to disregard our formal process. For example RFC 2026 recommends in clear language that Draft Standard, not Proposed Standard, is the proper maturity level for justifying widespread deployment. Any vendor that waits for this status is left far behind in the marketplace - in most cases, "infinitely far behind".
• We are almost assured that the IETF inventory of standards contains specifications which do not reflect the corresponding protocols in use on the Internet today, because the protocols require modifications based on implementation or deployment experience, or simply because "standard" protocols may not be used at all.

This proposal is derived from [TwoStage] (Dawkins, S., “Two Stage Standardization Approach,” September 1998.). The current proposal's core recommendation has basic differences from [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.), but incorporates a number of useful recommendations from it.

If adopted, this proposal will require specific changes to [RFC2026] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.). These are TBD.

2.  Proposed Changes

This proposal specifies a discrete set of changes, and each is separately motivated. Some are drawn from [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.).

2.1.  Standards Levels

The core changes that are proposed in labeling are quite simple:

• Retain the Proposed Standard
• Clarify the handling of documents that are already at Proposed Standard, undergo revision, and are then re-submitted for Proposed Standard.
• Drop Draft Standard
• Retain (full) Internet Standard

This proposal differs significantly from [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.), which retains Proposed and Draft, while dropping the existing (full) Internet Standard. Although that proposal seeks to reduce barriers for achieving these levels, there is nothing in the proposal to effect such changes.

In contrast, the current proposal eliminates a technically-oriented status level (Draft) that has proved problematic to achieve and is deemed a specific example of a more general requirement: the ability to make revisions to a document already at Proposed Standard.

There are different theories about the reasons it is problematic to achieve Draft Status, but objectively it requires specific technical work and significant effort, including Implementation Reports, to document it. Although it is generally deemed advisable to find ways for achieving Proposed Standard more quickly and more easily, the current proposal defers that task. Instead it seeks to create a clear distinction, with fundamentally different criteria:

Proposed Standard:

The IETF community achieves rough consensus -- on the technical adequacy of a specification.

(Full) Internet Standard:

The Internet community achieves rough consensus -- on using the running code of a specification.

A surprising aspect of the current proposal is its elimination of a milestone reflecting basic interoperability demonstration, including interoperability reports. Interoperability testing is fundamental to the success of Internet standardization:

• It verifies the clarity of the specification, because independent, compatible implementations are made to work
• It demonstrates that the associated Intellectual Property Rights rules can be applied acceptably.

In fact the underlying interoperability requirement has not been eliminated by the current proposal. Arguably it has been made more stringent!

Achieving widespread use -- not just implementation or deployment, but actual use -- is the ultimate test of interoperability. If the Internet community finds a specification useful, it will already have done the necessary testing.

Note that "useful" is a more stringent requirement than "implementation" or "deployment". Writing code and distributing it are necessary, but not sufficient, activities. The core requirement is that the mechanism gain extensive use; use means that it demonstrates value to users.

What is being changed, then, is not the underlying requirement but rather the timing and manner by which it is reported: It is no longer an independent step. It is folded into a formal step that relies solely on the far more essential reports of community adoption.

Another concern with elimination of Draft Standard is the handling of improvements to specifications that are not yet ready for full Internet Standard. The presence of Draft Standard has afforded authors a mechanism for resolving this need. Note, however, that it can resolve only one turn of the revision crank and that it only permits changes that entail clarification or removal; it does not cover semantic or syntactic additions or replacements to the specification; these require re-issuance at Proposed Standard. There is a long-standing concern that such re-submission will invite a fresh set of review and approval negotiations for the entire work, often with a new set of IETF management bringing their a new set of criteria to the negotiation.

To provide a more general means of handling a document that modifies, adds or removes syntactic or semantic detail, this proposal clarifies rules for the handling of documents that are already at Proposed Standard and are submitted for re-publication at that level. The critical requirement for this is that the review and approval process must be limited to consideration of the changes, only. It cannot be taken as an opportunity to reconsider the portions that were previously approved by the IETF.

2.2.  Status Review

This change is taken from [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.).

Section 6.2 of [RFC2026] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) calls for an IESG review of standards track documents that have not yet attained full Internet Standards status. That requirement is hereby dropped.

For specifications that have not achieved significant levels of actual use, there remains the option to have them declared Historic.

2.3.  Downward References Permitted

This change is taken from [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.).

Internet Standards are allowed to make normative references to Proposed Standards. The rules that make references to documents at lower maturity levels are a major cause of stagnation in the advancement of documents. This change allows an Internet Standard to freely reference features in any standards track RFC. The intent of this change is to enable expeditious promotion of Proposed Standards to Internet Standards.

Downward references to Internet-Draft documents continue to be prohibited.

3.  Two IETF Standards Levels

The premise of IETF standardization is a pragmatic sequence of diligent specification, serious review, and then publication for community testing and adoption. Long cycles of specification or review limit the ability of the community to benefit from the work and to gain experience that permits iterating improvements based on observed need.

3.1.  Proposed Standard (PS)

Proposed Standard is an established construct and practice in the IETF. Any attempt to change its criteria or handling should be a separate effort. The current proposal is to retain Proposed Standard in its current form. Implementations are sometimes offered or even required, prior to gaining PS status. No changes are required by this proposal.

3.2.  Resubmission of a PS Document for PS

Experience with a specification often leads to revision efforts that clarify, modify, enhance or remove features. A document that is already assigned PS status can be revised and submitted for republication at that level. Review and approval of such documents is limited to the changes. Reconsideration of the portions that were previously approved for PS status is prohibited.

3.3.  [Full] Internet Standard (IS)

This is the existing final standards status, based on attainment of significant community acceptance, as demonstrated by use, as well as product implementation and deployment. In other words, it must have demonstrated that it is useful in the real world. Advancement should merely require documenting this basic fact. Acceptable changes to the specification are for clarity and improved readability, and may include dropping unused features. No other changes or enhancements to specification syntax or semantics are permitted.

There are two incentives for seeking Internet Standard:

• It provides the IETF community with an explicit mark of success for a specific piece of its work.
• It can facilitate wider adoption. Over the full course of a standard's adoption, there often is a point at which the success of a standard is real, and even definitive, but this success might not yet be adequately perceived by the entire community. Having an IS label will remove any question of stability and utility of a specification. This signal can help to overcome organizational hesitance about using the specification.

4.  Differences from HousleyTwoLevel

The core differences between the current proposal and draft-housley-two-maturity-levels are that the current proposal:

• Drops Draft Standard, while [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.) drops (full) IS. The core requirements for these two different levels are quite different. Draft is a second technical evaluation. Internet Standard is a mark of extensive, production-level use.
• Drops Implementation Reports, while [HousleyTwoLevel] (Housley, R., “Reducing the Standards Track to Two Maturity Levels,” September 2010.) retains them.
• Clarifies the handling of revised documents that are re-submitted for Proposed Standard.

5.  Security Considerations

This document contains to text with security issues, except perhaps the security of the IETF standards process.

6.  References

6.1. Normative References

6.2. Informative

Authors' Addresses