One document matched: draft-crocker-ietf-twostage-00.xml
<?xml version='1.0' encoding='US-ASCII'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict='no'?>
<?rfc toc='yes'?>
<?rfc tocdepth='2'?>
<?rfc tocindent='yes'?>
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<rfc
docName="draft-crocker-ietf-twostage-00"
ipr="trust200902">
<front>
<title
abbrev="Two Stage">Two-Stage IETF Standardization</title>
<author
fullname="Spencer Dawkins"
initials="S."
surname="Dawkins">
<organization
abbrev="Huawei USA">Huawei Technologies (USA)</organization>
<address>
<phone>+1 214 755 3870</phone>
<email>spencer@wonderhamster.org</email>
</address>
</author>
<author
fullname="Dave Crocker"
initials="D."
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author
fullname="Eric W. Burger"
initials="E.W."
surname="Burger">
<organization>Georgetown University</organization>
<address>
<email>eburger@standardstrack.com</email>
<uri>http://www.standardstrack.com</uri>
</address>
</author>
<author
fullname="Peter Saint-Andre"
initials="P."
surname="Saint-Andre">
<organization>Cisco</organization>
<address>
<postal>
<street>1899 Wyknoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<date
year="2010" />
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>Officially, the IETF uses a three-stage standards track, roughly
defined in terms of completed specification, initial implementation,
and successful deployment and use.<xref
target="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 <xref
target="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. </t>
<t>Current IETF standards labeling has a number of harmful properties: <list
style="symbols">
<t>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. </t>
<t>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". </t>
<t>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. </t>
</list>
</t>
<t>This proposal is derived from <xref
target="TwoStage" />. The current proposal's core recommendation
has basic differences from <xref
target="HousleyTwoLevel" />, but incorporates a number of useful
recommendations from it.</t>
<t>If adopted, this proposal will require specific changes to <xref
target="RFC2026" />. These are TBD.</t>
</section>
<section
title="Proposed Changes">
<t>This proposal specifies a discrete set of changes, and each is
separately motivated. Some are drawn from <xref
target="HousleyTwoLevel" />.</t>
<section
title="Standards Levels">
<t>The core changes that are proposed in labeling are quite simple: <list
style="symbols">
<t>Retain the Proposed Standard</t>
<t>Clarify the handling of documents that are already at
Proposed Standard, undergo revision, and are then
re-submitted for Proposed Standard.</t>
<t>Drop Draft Standard</t>
<t>Retain (full) Internet Standard</t>
</list>
</t>
<t>This proposal differs significantly from <xref
target="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.</t>
<t>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.</t>
<t> 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: <list>
<t><list
style="hanging">
<t
hangText="Proposed Standard: ">The IETF community
achieves rough consensus -- on the technical adequacy
of a specification.</t>
<t
hangText="(Full) Internet Standard: ">The Internet
community achieves rough consensus -- on using the
running code of a specification.</t>
</list></t>
</list>
</t>
<t>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: <list
style="symbols">
<t>It verifies the clarity of the specification, because
independent, compatible implementations are made to
work</t>
<t>It demonstrates that the associated Intellectual Property
Rights rules can be applied acceptably.</t>
</list>
</t>
<t>In fact the underlying interoperability requirement has not been
eliminated by the current proposal. Arguably it has been made
more stringent! <list>
<t>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. </t>
<t>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.</t>
</list> 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. </t>
<t>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.</t>
<t>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. </t>
</section>
<section
title="Status Review">
<t>This change is taken from <xref
target="HousleyTwoLevel" />.</t>
<t>Section 6.2 of <xref
target="RFC2026" /> calls for an IESG review of standards
track documents that have not yet attained full Internet
Standards status. That requirement is hereby dropped.</t>
<t>For specifications that have not achieved significant levels of
actual use, there remains the option to have them declared
Historic. </t>
</section>
<section
title="Downward References Permitted">
<t>This change is taken from <xref
target="HousleyTwoLevel" />.</t>
<t> 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.</t>
<t>Downward references to Internet-Draft documents continue to be
prohibited. </t>
</section>
</section>
<section
title="Two IETF Standards Levels">
<t>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.</t>
<section
title="Proposed Standard (PS)">
<t>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. </t>
</section>
<section
title="Resubmission of a PS Document for PS">
<t>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. </t>
</section>
<section
title="[Full] Internet Standard (IS)">
<t>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.</t>
<t>There are two incentives for seeking Internet Standard: <list
style="symbols">
<t>It provides the IETF community with an explicit mark of
success for a specific piece of its work.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section
title="Differences from HousleyTwoLevel">
<t>The core differences between the current proposal and
draft-housley-two-maturity-levels are that the current proposal: <list
style="symbols">
<t>Drops Draft Standard, while <xref
target="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.</t>
<t>Drops Implementation Reports, while <xref
target="HousleyTwoLevel" /> retains them.</t>
<t>Clarifies the handling of revised documents that are
re-submitted for Proposed Standard.</t>
</list>
</t>
</section>
<section
title="Security Considerations">
<t>This document contains to text with security issues, except perhaps
the security of the IETF standards process.</t>
</section>
</middle>
<back>
<references
title="Normative References">
<!--
<t>>[GUIDE]Bradner, S., "Working Group Guidelines", RFC 2418, September
1998</t>
-->
<reference
anchor="RFC2026">
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author
fullname="S. Bradner"
initials="S."
surname="Bradner"> </author>
<date
month="October"
year="1996" />
</front>
<seriesInfo
name="RFC"
value="2026" />
</reference>
</references>
<!--
<reference anchor="">
<front>
<title></title>
<author fullname="" initials="" role="" surname="">
</author>
<date month="" year=""/>
</front>
<seriesInfo name="" value=""/>
</reference>
-->
<references
title="Informative">
<reference
anchor="TwoStage">
<front>
<title>Two Stage Standardization Approach</title>
<author
fullname="S. Dawkins"
initials="S."
surname="Dawkins"> </author>
<date
month="September"
year="1998" />
</front>
<seriesInfo
name="I-D"
value="draft-dawkins-pstmt-twostage-00" />
</reference>
<reference
anchor="AltTrack">
<front>
<title>An Idea for an Alternate IETF Standards Track</title>
<author
fullname="S. Bradner"
initials="S."
surname="Bradner"> </author>
<date
month="July"
year="2003" />
</front>
<seriesInfo
name="I-D"
value="draft-bradner-ietf-stds-trk-00" />
</reference>
<reference
anchor="HousleyTwoLevel">
<front>
<title>Reducing the Standards Track to Two Maturity
Levels</title>
<author
fullname="R. Housley"
initials="R."
surname="Housley"> </author>
<date
month="September"
year="2010" />
</front>
<seriesInfo
name="I-D"
value="draft-housley-two-maturity-levels-02.txt" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:15:28 |