Solutions Mailing List Spencer Dawkins
INTERNET DRAFT MCSR Labs
8 October 2003 Charles E. Perkins
Nokia Research Center
Dave Crocker
Brandenburg InternetWorking
Two Stage Standardization
draft-dawkins-pstmt-twostage-01.txt
STATUS OF THIS MEMO
This document is a submission to the Solutions Mailing List,
which is not an official mailing list of the Internet
Engineering Task Force, but is the best place weÆve found to
discuss process change proposals. Comments should be
submitted to the solutions@alvestrand.no mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
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.
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.
This proposal also defines an optional, pre-standards label
for use within working groups. The proposal is intended to
streamline the IETF standardization process, and to provide
clear benefits for each stage.
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:
* 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.
* 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.
1.1. The Problems
Current IETF standards management has a number of harmful
properties:
* Our documented process isn't what we use in
practice. This disparity creates many opportunities
for miscommunication, which in turn can produce
mistrust.
* 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.
* 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ö
* 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.
* 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 used at all.
Because of the delays, implementers often cannot wait for
even the first formal standards track specification approval
of Proposed Standard before they begin to implement. This
leads to a variety of problems.
* The version of the specification that is used may be
immature, and may change markedly between revisions.
* Different implementers may choose different
revisions of the specification as a basis for
development.
* When a Proposed Standard needs to be revised, it can
take years for the revision to be published even for
very minor repairs. Then it is quite difficult for
vendors and other standards organizations (i.e., the
IETFÆs ôcustomersö) to know what the real protocol
specification is, and they may be forced to specify
known bugs as part of systems to be built, even when
the bugs are well known to the ôcustomerö.
* The "running code" component of the IETF culture
clearly means that it is good to base a standard on
implementation history. The implementation results
need to be discussed and documented in order for
this history to have its greatest value.
1.2. A Hybrid Solution
This current proposal merges the previous one 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.
Bradner essentially proposes a new label that primarily
serves to move the IETF process one to the 'left' of the
current labels. A concern with this proposal is that it will
only buy us some time, without actually fixing any
underlying problems or changing anyone's motivations to do
better. It permits quicker issuance of early-stage
specifications, but with significantly less review.
The synthesized variant, proposed here, also adds a new
label, but it also makes some changes to Proposed and it
removes Draft. Mostly, it seeks to capture existing
practise, with some features intended to encourage revision
and progress along the track.
2. PROPOSAL -- TWO-STAGES AND A LABEL
A two-stage standards process is suggested, and a new
working group action is defined. The working group action
is not needed in all cases before a specification is
standardized, but it can be quite useful to facilitate the
progress of working group documents.
Draft Standard status is dropped.
2.1. Working Group Snapshot (WGS)
The Working Group Snapshot (WGS) label can be affixed to an
Internet-Draft, for working group synchronization. It is
pointedly not an IETF standards label. Rather it is an
optional part of the working group development process,
permitting the working group to synchronize on a particular
version of a draft.
A WGS is an Internet-Draft that
a) Achieves ôrough consensusö based on a Working
Group Last Call
b) May receive IESG comment
A working group can issue a WGS at any time, and does so by
notifying the IESG of their intention to issue a WGS as the
*next* revision of an Internet-Draft.
The IESG has up to 1 month to supply additional text that is
added to an "IESG Comments" section of the document. It may
not delay or veto issuance of a WGS. Therefore, IESG
involvement is not for "approval" but rather to permit
formal, outside comments to be affixed to the draft.
The document is subject to all normal I-D rules.
When a WGS specification needs more time, active effort on
it will usually result in changes to the specification being
needed, with a resulting new version of the document, and
(possibly) another working group decision to assign it WGS
status.
COMMENT: This label augments the current situation with I-
Ds. It imposes minimal delay, permits vendors to
be better coordinated, and permits IESG review and
comment. The label makes clear that the
specification is a WG product, not an IETF
product, and it does not imply long-term stability
to the specification. The use of a non-archival
version (I-D) and the resulting 9-month time limit
on that version should encourage folks to revise
and progress the specification.
COMMENT: It is worth considering extending the I-D time-
limit to 9 months. This will be more convenient
for WGS documents and will have no substantive
effect on other I-Ds.
2.2. Proposed Standard (PS)
The IETF process would retain current Proposed Standard
rules, with the following modifications:
a) All specifications must have least one implementation
that has been tested under the circumstances that
represent its intended use.
b) 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.
c) PS specifications receive an STD number, or are added
to an existing STD
2.3. 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.
3. FORMAL EDITING CHANGES
This proposal would be put into effect by making the
following formal changes to official IETF process and
procedures specifications. Specifically:
* Add text to the end of section 7.2 of [GUIDE],
according to text provided later in this section
* Delete section 4.1.3 of [STD]
* Rewrite sections 4.1.1 and 4.1.2 of [STD], according
to text provided later this section
* Rewrite the last paragraph of section 6.2 of [STD].
* Remove references to Draft Standard from [STD]
* Perform other edits required for consistency
3.1. [RFC2418- 7.2] Internet-Drafts (I-D)
A working group may wish to synchronize its activities
according to particular versions of its Internet-Drafts.
The label "Working Group Snapshot" (WGS) may be affixed to
an Internet-Draft, for this purpose. The label does not
indicate that the Internet Draft is ready for widespread
deployment.
A WGS is an Internet-Draft that
a) Achieves ôrough consensusö based on a Working
Group Last Call
b) May receive IESG comment
A working group can issue a WGS at any time, and does so by
notifying the IESG of their intention to issue a WGS as the
*next* revision of an Internet-Draft.
The IESG has up to 1 month to supply additional text that is
added to an "IESG Comments" section of the document. It may
not delay or veto issuance of a WGS. Therefore, the IESG
review is not an "approval" step but rather it is a step
permitting formal, outside comments to be affixed to the
draft.
The document is subject to all normal I-D rules, except that
the time before deletion is extended to be 9 months.
3.2. [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.
3.3. [RFC2026-4.1.2] Internet Standard
A specification may be elevated to the Internet Standard
level, when the specification has been significantly
deployed and used over the Internet.
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.
3.4. [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.
4. DISCUSSION
This proposal seeks to capture, specify and refine current
practise in the IETF, by making its formal labeling actions
more streamlined. It defines a new label for use within
working groups, 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.
Because candidate specifications for Proposed Standard
already frequently reflect implementation experience, making
that experience be required for all specifications is deemed
a minimal change. The reason for making this minimal change
is to ensure that all IETF standards track documents reflect
running code.
One reason that specifications do not advance to Draft
Standard is the considerable effort required to provide
technical documentation of sufficient interoperability
testing. Because the community has demonstrated such a
reluctance to seek this status, it is removed. It is
expected that elimination of this step, as well as the
proposed adjustments to the criteria for Internet Standard,
will make this label appealing to seek and to require only
modest effort.
The suggested scheme has labels that represent:
WGS: Working group project management milestone
PS: IETF-wide technical approval
IS: Internet community production deployment and
use
Simplistically this means that WGS is the goal for working
group internal coordination, PS is the goal for community
technical evaluation, and IS is the goal for operations
community adoption.
4.1. WGS
This proposal extends the de facto status of "working group
document" and the de facto occurrence of implementations
based on Internet-Draft specifications, by permitting
working groups to declare that a specification has achieved
a developmental milestone. In particular, this will permit
working group participants, and the rest of industry, to
coordinate their development and testing efforts.
However working group documents need to be kept formally
fluid (unstable) in case major changes are needed. This is
accomplished by giving the specification no formal IETF-wide
status and by not publishing it as an RFC. If folks want to
record the specification for posterity, even if itÆs not
acceptable as a Proposed Standard, then they can issue it as
an Informational RFC.
Working groups are provided a formal and public means of
circulating their work for technical evaluation, before it
is complete. The process to achieve this is streamlined,
which is balanced by imparting no IETF-wide status to the
document and issuing it only through the non-archival
Internet-Drafts process.
4.2. PS
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.
4.3. IS
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.
5. SECURITY CONSIDERATIONS
This document contains to text with security issues, except
perhaps the security of the IETF standards process.
6. 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
Normative
[GUIDE] Bradner, S., "Working Group Guidelines", RFC 2418,
September 1998
[STD] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996.
7. AUTHOR CONTACT INFORMATION
Spencer Dawkins
Mobile Communications and Security Research Labs
1547 Rivercrest Blvd.
Allen, TX 75002
Email: spencer@mcsr-labs.org
Phone: +1.214.755.3870
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
Email: charles.perkins@nokia.com
Phone: +1.650.625.2986
Fax: +1.650.625.2502
Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
Email: dcrocker@brandenburg.com
Tel: +1.408.246.8253