Network Working Group S. Dawkins
Internet-Draft Inet Technologies, Inc.
Expires: November 19, 2004 D. Crocker
Brandenburg Internetworking
C. Perkins
Nokia Research Center
May 21, 2004
Two Stage Standardization
draft-dawkins-pstmt-twostage-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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 two-step standard track.
Dawkins, et al. Expires November 19, 2004 [Page 1]
Internet-Draft Two Stage Standardization May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Hybrid Solution . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Proposed Standard (PS) . . . . . . . . . . . . . . . . . . 5
3.2 Internet Standard (IS) . . . . . . . . . . . . . . . . . . 5
4. Formal Editing Changes . . . . . . . . . . . . . . . . . . . . 6
4.1 [RFC2026-4.1.1] Proposed Standard . . . . . . . . . . . . 6
4.2 [RFC2026-4.1.3] Internet Standard . . . . . . . . . . . . 6
4.3 [RFC2026-6.2] Advancing in the Standards Track . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Proposed Standard . . . . . . . . . . . . . . . . . . . . 8
5.2 Internet Standard . . . . . . . . . . . . . . . . . . . . 8
6. Relationship With Other Proposals . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
A. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Dawkins, et al. Expires November 19, 2004 [Page 2]
Internet-Draft Two Stage Standardization May 2004
1. Introduction
RFC 2026 specifies a three-stage standards process. In theory,
Proposed Standard is an entry to the standards track. In practice
relatively few specifications ever advance even to the second stage,
Draft Standard. Furthermore, the periodic IESG review of "immature"
standards that is called for in section 6.2 of RFC 2026 seldom
happens. Consequently the Internet runs on Proposed Standards, some
of which are more than 25 years old, covering critical aspects of
routing, congestion control, and security.
This results in vulnerability at both ends of the spectrum:
1. Admission to "Proposed Standard" carries a heavier burden than
originally envisioned, because responsible reviewers realize this
is probably their last chance to identify problems with the
specification, and try to ôthink of everything that could go
wrongö. This thought exercise causes standards track work to be
less timely. The protracted development cycle often causes
productive engineers to lose interest and/or their opportunity to
remain involved.
2. In spite of this, advancing to "Proposed Standard" still does not
require implementation or deployment experience, so that the
IETF's "rough consensus and running code" guiding principle isn't
given a chance to be effective.
Discussion venue: Online discussion of this draft should take place
on the newtrk@lists.uoregon.edu mailing list.
Dawkins, et al. Expires November 19, 2004 [Page 3]
Internet-Draft Two Stage Standardization May 2004
2. The Problems
Current IETF standards management has a number of harmful properties:
1. Our documented process isn't what we use in practice. This
disparity creates opportunities for miscommunication, which in
turn creates opportunities for mistrust.
2. Basing the review for Proposed Standard on a thought exercise
instead of implementation and deployment experience encourages
"late surprises" in the process. The desire for perfection
drives reviewers to agonize over warnings and clarity. Whether a
specification will be returned to a working group for rework is
unpredictable, and the time required for approval is highly
variable.
3. Consumers of IETF specifications have learned to disregard our
formal process. RFC 2026 recommends in clear language that Draft
Standard, not Proposed Standard, is the proper maturity level for
widespread deployment. Any vendor that waits for this status is
left far behind in the marketplace (in most cases, infinitely far
behind).
4. Newcomers to the IETF have no written document to explain the ad
hoc adjustments we've made to accommodate current practice. For
example, the Transport Area routinely cycles proposed changes to
TCP congestion control through Experimental status before
approval as a Proposed Standard - a reasonable practice, but one
not described in RFC 2026.
5. 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 to the Proposed Standard specification
based on implementation or deployment experience, or simply
because some of these "standard" protocols may not be used at
all.
Dawkins, et al. Expires November 19, 2004 [Page 4]
Internet-Draft Two Stage Standardization May 2004
3. A Hybrid Solution
This current proposal merges a previous proposal by two of the
current authors [DAWK], with one suggested by Scott Bradner [BRAD].
The resulting recipe for labeling IETF standards track documents
includes some additional seasoning.
A two-stage standards process is suggested, and Draft Standard status
is dropped.
3.1 Proposed Standard (PS)
The IETF process would retain current Proposed Standard rules, with
the following modifications:
1. All specifications must have least one implementation that has
been tested under the circumstances that represent its intended
use.
2. A fixed, 36-month time limit exists for all Proposed Standards.
By the end of that time the specification must be re-processed
for PS status, or it must be processed for the next standards
level, or it will be moved to Historic status.
3. PS specifications receive a STD number, or are added to an
existing STD.
3.2 Internet Standard (IS)
This is essentially the same as current full Standard. The
specification must have attained a significant degree of community
acceptance.
In other words, it must have demonstrated that it is deployed and
useful in the real world.
Dawkins, et al. Expires November 19, 2004 [Page 5]
Internet-Draft Two Stage Standardization May 2004
4. Formal Editing Changes
This proposal would be put into effect by making the following formal
changes to official IETF process and procedures specifications.
Specifically:
o Delete section 4.1.2 of [STD]
o Rewrite sections 4.1.1 and 4.1.3 of [STD], according to text
provided later this section
o Rewrite the last paragraph of section 6.2 of [STD]
o Remove references to Draft Standard from [STD]
o Perform other edits required for consistency
4.1 [RFC2026-4.1.1] Proposed Standard
The entry-level maturity for the IETF standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track at the "Proposed Standard"
level.
A Proposed Standard is generally stable, has resolved known design
choices, is believed to be well understood, has received significant
community review, and appears to enjoy enough community interest to
be considered valuable. However, further experience may well result
in a change of the specification before it advances, or even perhaps
a retraction.
Implementation experience is required for the designation of a
specification as a Proposed Standard. The specification must have
least one implementation that has been tested under the circumstances
that represent its intended use. This experience will usually
represent a strong argument in favor of designation as a Proposed
Standard.
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered useful and
necessary (and timely) even with known technical omissions.
A specification that reaches the status of Proposed Standard is
assigned a number in the STD series.
4.2 [RFC2026-4.1.3] Internet Standard
A specification may be elevated to the Internet Standard level, when
the specification has been significantly deployed and used over the
Internet.
Dawkins, et al. Expires November 19, 2004 [Page 6]
Internet-Draft Two Stage Standardization May 2004
An Internet Standard is characterized by a high degree of technical
maturity and by a generally held belief that the specified protocol
or service provides significant benefit to the Internet community.
A specification that reaches the status of Internet Standard retains
its STD number, but is given a new RFC number.
The Working Group chair is responsible for documenting the community
adoption and use of the specification.
An Internet Standard must be well understood and known to be quite
stable, both in its semantics and as a basis for developing an
implementation.
An Internet Standard is normally considered a final specification,
and changes are likely to be made only to solve specific problems
encountered. In most circumstances, it is reasonable for vendors to
deploy implementations of Internet Standards into a disruption
sensitive environment.
4.3 [RFC2026-6.2] Advancing in the Standards Track
From the time it is assigned Proposed Standard status, a
specification has thirty-six (36) months to achieve the status of
Internet Standard. If it fails to achieve IS status, it will
automatically be moved to the status of Historic. This
reclassification to Historic status shall be communicated to the IETF
by electronic mail to the IETF Announce mailing list. Alternatively,
a specification may be renewed as Proposed Standard, if it again
satisfies the usual requirements for that status.
Dawkins, et al. Expires November 19, 2004 [Page 7]
Internet-Draft Two Stage Standardization May 2004
5. Discussion
This proposal seeks to capture, specify and refine current practise
in the IETF, by making its formal labeling actions more streamlined.
It makes implementation history required for all Proposed Standards,
eliminates Draft Standard and calls for Internet Standard status to
be based strictly upon community adoption and use.
The suggested scheme uses these labels:
PS: IETF-wide technical approval
IS: Internet community production deployment and use
Simplistically this means that PS is the goal for community technical
evaluation and IS is the goal for operations community adoption.
5.1 Proposed Standard
The status of Proposed Standard is the entry-level standards label,
resulting from IETF-wide technical review and approval. Many
Proposed Standards documents already reflect implementation and
testing history, because this improves both the technical quality and
the credibility of the work. The new process requires "running code"
for all PS specifications. However only one implementation is
required. Therefore the requirement for PS is not as demanding as
the current Draft Standard.
In order to keep the IETF inventory from having unused and/or buggy
specifications, documents are allowed to reside at PS for only a
limited time.
5.2 Internet Standard
The Internet Standard label is assigned to a specification that has
received the convincing demonstration of community support, namely
community use. Hence the label is not assigned due to technical
evaluation, but rather by virtue of demonstrated utility.
Hence the requirements for achieving IS status are to have been at PS
and then to receive community rough consensus that the specification
has established a track record of significant usefulness to the
community.
Dawkins, et al. Expires November 19, 2004 [Page 8]
Internet-Draft Two Stage Standardization May 2004
6. Relationship With Other Proposals
This proposal touches the topic area for [LOUG], which focuses on
improving our ability to describe what documents make up a standard.
We like many of the ideas in [LOUG], and our proposal will
significantly increase the number of STDs assigned, and will likely
increase the need for [LOUG], or something like it. But [LOUG] is
orthogonal to this proposal.
We continue to hope for adoption of some variant of the "Working
Group Snapshot"/"Stable Snap Shot" mechanism described in [BRAD] and
[DAWK], but that mechanism is also orthogonal to this proposal.
Dawkins, et al. Expires November 19, 2004 [Page 9]
Internet-Draft Two Stage Standardization May 2004
7. Security Considerations
This document contains no text with security issues, except perhaps
the security of the IETF standards process.
Authors' Addresses
Spencer Dawkins
Inet Technologies, Inc.
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Phone: +1.469.330.3616
EMail: spencer@mcsr-labs.org
Dave Crocker
Brandenburg Internetworking
675 Spruce Dr.
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
EMail: dcrocker@brandenburg.com
Charles E. Perkins
Nokia Research Center
Communications Systems Lab
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1.650.625.2986
EMail: charles.perkins@nokia.com
Dawkins, et al. Expires November 19, 2004 [Page 10]
Internet-Draft Two Stage Standardization May 2004
Appendix A. References
Informative
[BRAD]: Bradner, S., "An Idea for an Alternate IETF Standards Track",
draft-bradner-ietf-stds-trk-00.txt, July 2003.
[DAWK]: Dawkins, S., C. E. Perkins, "Two Stage Standardization
Approach", draft-dawkins-pstmt-twostage-00.txt, June 2003.
[LOUG]: Loughney, J., "Standards, What Standards?",
draft-loughney-what-standards-01.txt, February 2004.
Normative
[STD]: Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
Dawkins, et al. Expires November 19, 2004 [Page 11]
Internet-Draft Two Stage Standardization May 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dawkins, et al. Expires November 19, 2004 [Page 12]