One document matched: draft-crocker-ietf-twostage-00.txt
Network Working Group S. Dawkins
Internet-Draft Huawei USA
Expires: May 13, 2011 D. 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
Dawkins, et al. Expires May 13, 2011 [Page 1]
Internet-Draft Two Stage November 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposed Changes . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Standards Levels . . . . . . . . . . . . . . . . . . . . . 4
2.2. Status Review . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Downward References Permitted . . . . . . . . . . . . . . . 6
3. Two IETF Standards Levels . . . . . . . . . . . . . . . . . . . 6
3.1. Proposed Standard (PS) . . . . . . . . . . . . . . . . . . 6
3.2. Resubmission of a PS Document for PS . . . . . . . . . . . 6
3.3. [Full] Internet Standard (IS) . . . . . . . . . . . . . . . 6
4. Differences from HousleyTwoLevel . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Dawkins, et al. Expires May 13, 2011 [Page 2]
Internet-Draft Two Stage November 2010
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] 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] 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:
o 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.
o 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".
o 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]. The current proposal's
core recommendation has basic differences from [HousleyTwoLevel], but
incorporates a number of useful recommendations from it.
If adopted, this proposal will require specific changes to [RFC2026].
These are TBD.
2. Proposed Changes
This proposal specifies a discrete set of changes, and each is
separately motivated. Some are drawn from [HousleyTwoLevel].
Dawkins, et al. Expires May 13, 2011 [Page 3]
Internet-Draft Two Stage November 2010
2.1. Standards Levels
The core changes that are proposed in labeling are quite simple:
o Retain the Proposed Standard
o Clarify the handling of documents that are already at Proposed
Standard, undergo revision, and are then re-submitted for Proposed
Standard.
o Drop Draft Standard
o Retain (full) Internet Standard
This proposal differs significantly from [HousleyTwoLevel], 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:
o It verifies the clarity of the specification, because independent,
compatible implementations are made to work
o 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!
Dawkins, et al. Expires May 13, 2011 [Page 4]
Internet-Draft Two Stage November 2010
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].
Section 6.2 of [RFC2026] 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.
Dawkins, et al. Expires May 13, 2011 [Page 5]
Internet-Draft Two Stage November 2010
2.3. Downward References Permitted
This change is taken from [HousleyTwoLevel].
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
Dawkins, et al. Expires May 13, 2011 [Page 6]
Internet-Draft Two Stage November 2010
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:
o It provides the IETF community with an explicit mark of success
for a specific piece of its work.
o 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:
o Drops Draft Standard, while [HousleyTwoLevel] 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.
o Drops Implementation Reports, while [HousleyTwoLevel] retains
them.
o 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
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
Dawkins, et al. Expires May 13, 2011 [Page 7]
Internet-Draft Two Stage November 2010
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.
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
Dawkins, et al. Expires May 13, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 06:25:03 |