Network Working Group R. Atkinson, Editor
Internet-Draft Extreme Networks
Expires: 22 July 2006 22 February 2006
A two stage standards process
draft-atkinson-newtrk-twostep-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
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.
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 22 July 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes several changes to the Internet standards
process, especially a reduction from three to two stages in the
IETF standards track.
Atkinson (Editor) Expires 22 July 2006 [Page 1]
Internet-Draft Two stage 22 February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Stage 1: Proposed Standard . . . . . . . . . . . . . . . . . . 3
3. Stage 2: Interoperable Standard . . . . . . . . . . . . . . . . 3
4. Stage 3: No stage three . . . . . . . . . . . . . . . . . . . . 4
5. Timing rules . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IS can reference PS . . . . . . . . . . . . . . . . . . . . . . 5
7. The STD designation, and updates . . . . . . . . . . . . . . . 5
8. Transitional arrangements . . . . . . . . . . . . . . . . . . . 5
9. Not excluded . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . 6
11. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
14. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Atkinson (Editor) Expires 22 July 2006 [Page 2]
Internet-Draft Two stage 22 February 2006
1. Introduction
This document proposes several changes to the Internet standards
process defined in RFC-2026. [1] These changes are designed to
simplify the process. They seek to reduce the set of impediments to
standards progression without any major changes to Internet
engineering philosophy.
The background for this proposal is the published analysis of
problems in the IETF [2], various discussions in the IETF's "New IETF
Standards Track Discussion" (newtrk) working group, various largely
expired drafts, the original author's personal experience, and the
editor's personal experience. It has little claim to originality
(see Acknowledgements).
The problems tackled by this proposal are those of clumsiness in the
three-stage standards process, and related clumsiness in the clarity
and useability of IETF standards. This draft is deliberately short
on rationale and explanation - the interested reader should study the
above references and discussions carefully.
2. Stage 1: Proposed Standard
This is exactly as described in RFC-2026. [1]
3. Stage 2: Interoperable Standard
This is very similar to Draft Standard as described in [1]. The name
is changed partly to mark the change, partly because people outside
the IETF often confuse "Draft Standard" with "Internet-Draft", and
partly to emphasise the IETF's value statement of "rough consensus
and running code."
The criteria for advancing from Proposed Standard to Interoperable
Standard are roughly the same as the current criteria for moving to
Draft Standard.
However, two inconveniences in the present advancement process and
interoperability requirements have been encountered:
1. The objective is to validate that a specification contains only
features that have been demonstrated to be interoperable. The
current text does not make it crystal clear that this, and not
the availability of conformant implementations, is being
demonstrated: the essential difference being that all features
must be interoperable, not that all implementations must be shown
to support all features.
Atkinson (Editor) Expires 22 July 2006 [Page 3]
Internet-Draft Two stage 22 February 2006
2. The current text requires features that have not been demonstrated
as interoperable to be removed from the specification. This may
cause an RFC to be updated, at a cost of many months delay, even
if only one or two features have not been demonstrated to
interoperate. The proposed new text would also allow an RFC to
be upgraded without change, even if some features had not been
proved interoperable, as long as this fact was duly documented.
Thus, this paragraph:
"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 Draft Standard
level only if those options or features are removed."
is replaced by:
"The requirement for at least two independent and interoperable
implementations applies to each of the options and features of the
specification considered individually. 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
Interoperable Standard level only if those options or features are
removed, or marked as untested for interoperability in a revised
specification or in an external document available at the IETF web
site and at the IETF ftp site."
4. Stage 3: No stage three
The final, rare, "Standard" stage is simply abolished. The
difference between the second and third stages isn't enough to
justify the extra bureaucracy, and there is nothing negative about
"Interoperable Standard" as the final state.
5. Timing rules
The minimum time at "Proposed Standard" remains six months.
The highly theoretical rule about annual review of PS documents after
two years is dropped to a recommendation; no review cycle is mandated
for IS documents.
The six month (and two year) timer starts when the IESG approval
announcement for a document is sent, not when the RFC is published.
As an adjunct to this, approved drafts should be parked in a special
public directory while they are in the RFC queue, so that they are
Atkinson (Editor) Expires 22 July 2006 [Page 4]
Internet-Draft Two stage 22 February 2006
readily available to implementers.
6. IS can reference PS
Interoperable Standards are allowed to make normative references to
Proposed Standards. The current rule prohibiting "down references"
is a major cause of stickiness in the publication process. This
change, in theory, allows an Interoperable Standard to reference
features that have not been formally agreed to be demonstrably
interoperable. But it is a matter of common sense - if we want to be
able to promote Proposed Standard documents expeditiously, we have to
allow this form of down reference. (Down references from an RFC to
an Internet-Draft continue to be prohibited.)
7. The STD designation, and updates
Presently, an STD designation and number is only given to a document
(or document set) at the full Standard level. This can cause extreme
confusion when a full Standard is technically obsoleted by a Proposed
Standard. What is an implementer to do?
One option is to simply abolish the STD designation, which is little
used anyway. (The editor prefers to abolish STD on grounds that it
eliminates needless process and is currently not often used; however,
his view is not strongly held.)
The alternative is to assign the STD designation (and number) to a
document (or document set) at PS level; if a PS is promoted to IS,
its STD number goes with it; if an IS is obsoleted by a PS, the STD
number reverts to the PS. In any case, this function (assigning
documents to specific STD designations) would be an IETF (WG or IESG)
matter and not an RFC Editor action as today.
8. Transitional arrangements
On the day these changes enter service, all existing Draft Standard
and (Full) Standard RFCs would be automatically reclassified as
Interoperable Standard RFCs. Corresponding changes would be made to
the RFC Index and various features of the RFC Editor site and any
other RFC repositories displaying the status of RFCs.
If and only if the STD designation is retained, all existing STD
designations will be applied as follows:
1. If the old Standard has not been obsoleted, it is now an IS with
the same STD designation.
Atkinson (Editor) Expires 22 July 2006 [Page 5]
Internet-Draft Two stage 22 February 2006
2. If the old Standard has been obsoleted, the STD designation
goes to the document(s) that obsoleted it, which may be PS, IS or
a mixture.
3. If the old Standard has been updated, the STD designation is
added to the document(s) that updated it, which may be PS, IS or
a mixture.
4. The IESG would designate a team or teams to rapidly classify
all PS and IS documents not assigned an STD designation by the
above process into new STD designations.
(If the STD designation is abolished, these steps would be
unnecessary, but various cleanings up of the RFC Index and the RFC
Editor web site would be needed to remove all references to STD.)
9. Not excluded
The above changes have been constructed in such a way that they do
not exclude the notions of WG Snapshots (drafts declared to be in a
stable state by the WG), Stable Snapshots (drafts declared to be in a
stable state with IESG agreement) or Internet Standards Documentation
(ISDs, external descriptors of a set of RFCs as a single
standard)[3].
This document has been written such that it neither requires nor
prohibits other unrelated process changes to be made.
10. Initial Publication as Historic RFC
An unrelated process clarification is that, occasionally, the IESG
may decide to approve a document for immediate publication as
Historic (rather than Informational), when it is desired to publish
it for the record but the document's content is already overtaken by
events.
10. Housekeeping
Obviously, [1] will need considerable editing in addition to the
above changes, for example to remove the intellectual property
material which is already obsolete. Also, [4], which defined the STD
designation, should be obsoleted. (Even if the STD designation is
retained, it should be fully described in the replacement for [1].)
11. Security Considerations
This document does not directly affect the security of the Internet.
Atkinson (Editor) Expires 22 July 2006 [Page 6]
Internet-Draft Two stage 22 February 2006
12. IANA Considerations
Atkinson (Editor) Expires 22 July 2006 [Page 7]
Internet-Draft Two stage 22 February 2006
This document requests no action by the IANA.
13. Acknowledgements
The current editor proposed a two-stage standards track process to
the IAB and IESG whilst he was serving on the IAB. At that time, the
idea did not garner much support. Separately, a two-stage standards
track proposal was made Spencer Dawkins, Charlie Perkins and Dave
Crocker in 2003, which also contained a version of the WG Snapshot
proposal. Another variant including Stable Snapshots was made by
Scott Bradner in 2004. This draft was written by Brian Carpenter in
June 2005. The current editor took over the draft in February 2006
with permission from Brian Carpenter. Comments on the Brian
Carpenter's original draft by Spencer Dawkins are gratefully
acknowledged.
This document was originally produced using the xml2rfc tool[5], but
the current editor is using nroff.
14. Informative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP-9, RFC-2026, October 1996.
[2] Davies, E., "IETF Problem Statement", RFC-3774, May 2004.
[3] Klensin, J. and J. Loughney, "Internet Standards Documentation
(ISDs)", draft-ietf-newtrk-repurposing-isd-03 (work in
progress), April 2005.
[4] Postel, J., "Introduction to the STD Notes", RFC-1311, March
1992.
[5] Rose, M., "Writing I-Ds and RFCs using XML", RFC-2629, June
1999.
Atkinson (Editor) Expires 22 July 2006 [Page 8]
Internet-Draft Two stage 22 February 2006
Author's Address
Randall Atkinson
Extreme Networks
PO Box 14129
3306 East NC Highway 54, Suite 100
Research Triangle Park, NC
27709 USA
Email: rja@extremenetworks.com
Atkinson (Editor) Expires 22 July 2006 [Page 9]
Internet-Draft Two stage 22 February 2006
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 2006. This document is subject to
the rights, licenses and restrictions contained in BCP-78, and except
as set forth therein, the author and editor retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Atkinson (Editor) Expires 22 July 2006 [Page 10]
Internet-Draft Two stage 22 February 2006
Atkinson (Editor) Expires 22 July 2006 [Page 11]