TOC 
Network Working GroupS. Dawkins
Internet-DraftHuawei USA
Expires: May 13, 2011D. Crocker
 Brandenburg InternetWorking
 E. Burger
 Georgetown University
 P. Saint-Andre
 Cisco
 November 9, 2010


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




 TOC 

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:

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.



 TOC 

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.).



 TOC 

2.1.  Standards Levels

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

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:

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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:



 TOC 

4.  Differences from HousleyTwoLevel

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



 TOC 

5.  Security Considerations

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



 TOC 

6.  References



 TOC 

6.1. Normative References

[RFC2026] Bradner, S., “The Internet Standards Process -- Revision 3,” RFC 2026, October 1996.


 TOC 

6.2. Informative

[AltTrack] Bradner, S., “An Idea for an Alternate IETF Standards Track,” I-D draft-bradner-ietf-stds-trk-00, July 2003.
[HousleyTwoLevel] Housley, R., “Reducing the Standards Track to Two Maturity Levels,” I-D draft-housley-two-maturity-levels-02.txt, September 2010.
[TwoStage] Dawkins, S., “Two Stage Standardization Approach,” I-D draft-dawkins-pstmt-twostage-00, September 1998.


 TOC 

Authors' Addresses

  Spencer Dawkins
  Huawei Technologies (USA)
Phone:  +1 214 755 3870
Email:  spencer@wonderhamster.org
  
  Dave Crocker
  Brandenburg InternetWorking
Email:  dcrocker@bbiw.net
  
  Eric W. Burger
  Georgetown University
Email:  eburger@standardstrack.com
URI:  http://www.standardstrack.com
  
  Peter Saint-Andre
  Cisco
  1899 Wyknoop Street, Suite 600
  Denver, CO 80202
  USA
Phone:  +1-303-308-3282
Email:  psaintan@cisco.com