One document matched: draft-dawkins-pstmt-twostage-00.txt
Problem Statement WG Spencer Dawkins
INTERNET DRAFT MCSR Labs
23 June 2003 Charles E. Perkins
Nokia Research Center
Two Stage Standardization Approach
draft-dawkins-pstmt-twostage-00.txt
Status of This Memo
This document is a submission to the problem-statment Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the problem-statment@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
1. Abstract
This specification points out the (obvious) distinction between the
RFC 2026 Standards Track as documented and the IETF standards track
as practiced, and proposes a two-step standard track, with judicious
use of Experimental RFCs, as an alternative.
Dawkins, Perkins Expires 23 December 2003 [Page i]
Internet Draft Two Stage Standardization 23 June 2003
2. Problem Statement
RFC 2026 specifies a three-stage standards process, but relatively
few standards-track specifications advance beyond Proposed Standard.
In practice, the IETF has a one-step standards process that is
vulnerable at both ends of the spectrum:
- Admission to "Proposed Standard" is a heavier burden than
originally envisioned. Protocol developers may be required to
specify a complete system, not an interface, in order for their
specification to be approved as a Proposed Standard.
- In spite of this, "Proposed Standard" still does not require
implementation or deployment experience, so that the IETF's
"rough consensus and running code" guiding principle has only
half a chance to be effective.
3. Why Is This A Problem?
In theory, Proposed Standard is an entry to the standards track.
In practice, relatively few specifications even advance to Draft
Standard, and the periodic IESG review of "immature" standards
described in section 6.2 of RFC 2026 is unknown. The Internet
runs on Proposed Standards, some of which are more than 25 years
old, covering critical aspects of routing, congestion control, and
security.
Our use of a "one-step" standards process has these effects:
- Our documented process isn't what we use in practice. This
disconnect gives us many opportunities for miscommunication and
mistrust, and doesn't decrease the number of times specifications
are returned to working groups for rework.
- Consumers of IETF specifications have learned to disregard our
process. RFC 2026 recommends in clear language that Draft
Standard, not Proposed Standard, is the proper maturity level for
widespread deployment. If vendors believed us, they would be
left far behind in the marketplace.
- Newcomers to the IETF don't understand our process or 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 requirement, but
one not described in RFC 2026.
Dawkins, Perkins Expires 23 December 2003 [Page ii]
Internet Draft Two Stage Standardization 23 June 2003
4. One Way of Solving the Problem
One way of solving the problem is to collapse the "standards track"
to two steps, Proposed Specification and Internet Standard. This
reflects current practice, while making advancing a Proposed
Specification somewhat more attractive (since Internet Standard is
only one leap away).
If it were up to the proposal authors, we would "lower the bar"
for Proposed Standard, to its original intent - a designation for
a specification with stable text, some implementation experience,
and little or no deployment experience. We recognize that we
have trained industry to implement and deploy Proposed Standards,
so instead we propose more active use of Experimental status
specifications as a "step toward IETF standardization" that does not
include the word "Standard" in the document status designation, in
any form.
Our suggestion is to delete section 4.1.3 of RFC 2026, and rewrite
sections 4.1.1, 4.1.2, and 4.2.1 of RFC 2026, as follows (other
edits are required for consistency, but these edits describe what is
actually proposed):
4.1.1 Proposed Specification
The entry-level maturity for the standards track is "Proposed
Specification". A specific action by the IESG is required to
move a specification onto the standards track at the "Proposed
Specification" level.
A Proposed Specification 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
might result in a change or even retraction of the specification
before it advances.
Neither implementation nor operational experience is absolutely
required for the designation of a specification as a Proposed
Specification. However, such experience is highly desirable, and
will usually represent a strong argument in favor of designation as a
Proposed Specification.
The IESG may require implementation and/or operational experience
prior to granting Proposed Specification status to a specification
that materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet. CEP opinion: two implementations, supporting all mandated
features, should ALWAYS be REQUIRED for Proposed Specification.
Dawkins, Perkins Expires 23 December 2003 [Page iii]
Internet Draft Two Stage Standardization 23 June 2003
A Proposed Specification 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 Specification state when it is considered
to be useful and necessary (and timely) even with known technical
omissions.
Implementors should treat a Proposed Specification as an immature
specification. Implementation provides experience and validates,
tests, and clarifies the specification. Since the content of
Proposed Specification may be changed if problems are found or better
solutions are identified, deploying implementations of such standards
into a disruption-sensitive environment is not recommended.
4.1.2 Internet Standard
A specification may be elevated to the Internet Standard level, when
- at least two independent and interoperable implementations of all
protocol features, from different code bases, have been developed
from the specification, and
- significant implementation and successful operational experience
has been obtained.
For the purposes of this section, "interoperable" means to be
functionally equivalent or interchangeable components of the
system or process in which they are used. If patented or otherwise
controlled technology is required for implementation, the separate
implementations must also have resulted from separate exercise of the
licensing process.
An Internet Standard (which may simply be referred to as a 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 Standard is assigned a
number in the STD series while retaining its RFC number.
The requirement for at least two independent and interoperable
implementations applies to all of the options and features of
the specification. In cases in which one or more options or
features have not been demonstrated in at least two interoperable
implementations, the specification may advance to the Internet
Standard level only if those options or features are removed.
The Working Group chair is responsible for documenting the specific
implementations which qualify the specification for Internet Standard
Dawkins, Perkins Expires 23 December 2003 [Page iv]
Internet Draft Two Stage Standardization 23 June 2003
status along with documentation about testing of the interoperation
of these implementations. The documentation must include information
about the support of each of the individual options and features.
This documentation should be submitted to the Area Director with the
protocol action request. (see Section 6)
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 to be 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.2.1 Experimental
The "Experimental" designation typically denotes a specification that
is stable enough to implement, but may not be part of a complete
system (yet), and may not reflect substantial implementation or
deployment experience. Such a specification is published for the
general advancement of the Internet technical community, including
implementors who wish to obtain implementation and deployment
experience with the protocol described by the specification. It
can also serve as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below). An
Experimental specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), an IETF Working
Group, or an individual contribution.
"Adequate coordination with the standards process" may take the
form of publication notes pointing out problematic aspects of the
specification as published, as described in section 4.2.3.
Experimental specifications have NO standards-track status, although
Experimental specifications may move to Proposed Specification status
when they meet the criteria described in section 4.1.1 of this memo.
CEP observation: A working charter could, however, have publication
of an Experimental Standard to be a milestone on the way towards
completion of a Proposed Specification.
Protocol developers who have observed the need for deployment
experience in the past are encouraged to publish Experimental
specifications.
Dawkins, Perkins Expires 23 December 2003 [Page v]
Internet Draft Two Stage Standardization 23 June 2003
5. If This is the Wrong Way to Solve the Problem
There are other ways to design a standards track for the IETF.
Instead of cycling through many proposals, the General Area
Director should assign this problem (if not this draft) to a
Short Term Problem Resolution working group (as proposed by
draft-ietf-problem-process-01.txt).
6. Security Considerations
If security continues to be the last thing protocol developers think
about, Experimental specifications are likely to reflect this.
This is preferable to blocking specifications while protocol
developers who aren't specialists in, for instance, key exchange
protocols try to come up with acceptable security considerations
before a specification can be published.
7. Authors Contact Information
Spencer Dawkins
Mobile Communications and Security Research Labs
1547 Rivercrest Blvd.
Allen, TX 75002
spencer@mcsr-labs.org
Tel: +1 214 755 3870
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Dawkins, Perkins Expires 23 December 2003 [Page vi]
| PAFTECH AB 2003-2026 | 2026-04-23 12:18:11 |