Internet DRAFT - draft-black-newtrk-proposals
draft-black-newtrk-proposals
Network Working Group
Internet Draft D. Black
Document: draft-black-newtrk-proposals-00.txt EMC Corporation
Expires: November 2004 B. Carpenter
IBM
May 2004
Proposals for a New IETF Standards Track
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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
Discussions in the IETF's "problem" working group reached consensus
that the current IETF 3-stage standards track, as implemented, is not
working. This draft proposes various alternative multi-step
standards tracks for debate in the "newtrk" working group.
Table of Contents
1. Introduction 2
2. Some Proposals for New Standards Tracks 3
2.1 No More Mr. Nice Guy - make the current system work 3
2.2 Prune 4
2.3 Slash and Burn 4
2.4 Placeholder for another idea... 5
2.5 Snapshot 5
3. Discussion of Pros and Cons 5
4. Security Considerations 5
5. Acknowledgements 5
6. Appendix 1: Summary of Current IETF Standards Track 5
7. Appendix 2: Specific example of "Prune" 8
7.1 Alternate Standards Track Maturity Levels 9
7.2 Stable Snapshot 9
7.3 Proposed Standard 10
7.4 Internet Standard 12
7.5 Minimum time in each stage. 13
8. Informative References 13
9. Authors' Addresses 13
1. Introduction
By way of preamble, note that this is a discussion document and not a
firm or fully worked out proposal. Once the "newtrk" working group
reaches consensus on the general direction to follow, this document
will have served its purpose and a revision or update of [RFC2026]
will be needed.
The consensus in the "problem" working group was that the current
IETF three stage standards track, described in RFC 2026 [RFC2026] and
summarized below in Appendix 1, is not working as originally
intended. The problem statement document [RFC3774] says:
The current hierarchy of Proposed, Draft, and Full Standard
maturity levels for specifications is no longer being used in the
way that was envisioned when the stratification was originally
proposed. In practice, the IETF currently has a one-step
standards process that subverts the IETF's preference for
demonstrating effectiveness through running code in multiple
interoperable implementations. This compresses the process that
previously allowed specifications to mature as experience was
gained with actual implementations:
The document then goes on to list various observations including:
1/ Few documents actually progress after being published as
Proposed Standard (PS).
2/ There is a perception that the IESG raised the quality
requirement for approval as PS beyond the intention of
[RFC2026].
3/ In spite of the raised quality requirement, running code is not
required to achieve PS status.
4/ There seems to be a reinforcing feedback loop involved: vendors
implement and deploy PS specifications, so increasingly the
IESG tries to make the PS documents better.
[RFC3774] concludes that the three-stage process is excessive.
An alternative interpretation of these observations is that a three-
step standards process still operates, but the existing standards
levels have been shifted upwards so that PS is no longer the initial
step. Vendors will often implement, and their customers deploy,
technology based on Internet Drafts as soon as they seem to be
stable. Thus, Internet Drafts have, in effect, replaced PS as the
first stage of the IETF standards process, PS has become the second
stage, and Draft Standard (DS) the hard-to-achieve third stage.
But there are significant problems with using Internet Drafts as
standards documents. Most importantly, Internet Drafts are not
stable, and their actual degree of instability varies widely.
Internet Drafts have short lifetimes with most of them being replaced
by new versions or expiring within a few months. If a vendor decides
to implement from an Internet Draft they have to be sure that they
are implementing the same version of the Internet Draft as other
vendors with whom they want to interoperate. Many examples show that
this is far from being the normal case. Also, of course, Internet
Drafts tend to have bugs and gaps by their very nature.
Objectively, over time, the IESG has raised the bar for the
publication of Proposed Standard documents. The current level of
review, except for not having a requirement for interoperable
implementations, is close to what is described for Draft Standard in
[RFC2026]. Thus PS has, in effect, replaced DS as the second stage in
the IETF standards process, with the first stage being an ill-defined
choice of Internet Draft. So few specifications are now advanced to
final Internet Standard status that this stage has been, in practice,
removed. Few specifications are promoted to the level requiring
interoperability (Draft Standard) and any revision of the IETF
standards process should try to correct that.
2. Some Proposals for New Standards Tracks
This section gives a short summary of a number of possible proposals
to resolve the above issues by tuning or changing the standards track
process. More suggestions are welcome. The following section
discusses pros and cons.
2.1 No More Mr. Nice Guy - make the current system work
This proposal would confirm the intention of [RFC2026] and implement
strict operational procedures to make it work. This would mean:
* reducing the strictness of IESG review for PS to a defined
minimum,
* enforcing the two year "dwell time" at PS by automatically
demoting PS documents to Historic if no interoperability
evidence is offered after two years or unless active work on a
revised specification is under way, and
* introducing a similar "dwell time" for DS to be considered for
Internet Standard status or die (back to PS for another two
years?).
The dwell time could be adjusted from its current value of two years.
2.2 Prune
The number of standards levels is pruned to two (we could call them
Proposed Standard and Internet Standard). The threshold for PS would
be roughly as today (stricter than in [RFC2026] but not requiring
proof of interoperability). The threshold for IS would be a minimum
period at PS, plus evidence of interoperability and reasonable
deployment experience.
This could be combined with some form of Snapshot (Section 2.5) to
provide an initial level with better stability than an arbitrary
Internet-Draft.
Specific proposals can be found in Appendix 2 (with Snapshot) and
[TSS] (without Snapshot, but the [WGS] Snapshot proposal is intended
to be complementary to [TSS]).
2.3 Slash and Burn
The number of levels is reduced to one, called Internet Standard.
The threshold would be roughly the same as for Proposed Standard
today (roughly what is described in [RFC2026] for Draft Standard, but
*without* the interoperability requirement).
In addition, a separate "Interoperability and Deployment Register"
would be maintained by the IETF Secretariat. This would be a public
record of demonstrated interoperability and deployment experience.
Either the IESG, or better perhaps a special IETF Interoperability
Committee, would approve the publication of such a record. An
Internet Standard would get a gold star when it had such a public
record.
This could be combined with some form of Snapshot (Section 2.5) to
provide an initial level with better stability than an arbitrary
Internet-Draft.
2.4 Placeholder for another idea ...
2.5 Snapshot
It seems inevitable that there will be a noticeable time lag from
when a working group believes that a specification is done until it
gets finally published, whatever changes are made to the standards
track. Mechanically, the processes of IETF Last Call, IESG review,
IANA action if needed, and RFC Editor action will take time, even if
no issues are found that need to be referred back to the WG. During
this wait, early implementers need to know which version of the
document to work from. Also, WGs may reach intermediate stages in
developing a complex specification when it is useful for all trial
implementations to be using the same version. For these two reasons,
a snapshot mechanism has been suggested, in at least two variants:
a) Working Group Snapshot. In this model WGs are authorized to
declare (by WG rough consensus) that a particular draft is a WG
Snapshot. No IESG or even Area Director approval would be
required - this would be a simple statement to the world that the
WG has declared a snapshot, along with a statement of the purpose
for which the snapshot was declared. As far as implementers are
concerned, 'caveat emptor' applies. The only procedural issue is
that an Internet Draft that has been declared a WG Snapshot could
get a life extension beyond the normal six months, even if a later
version number is published. A specific proposal is in [WGS].
b) IETF Stable Snapshot. Similar, but AD or IESG approval is
required. A lightweight cross-area technical review (lighter
than [RFC2026] intended even for PS) would be made. A specific
proposal is in Appendix 2.
There are a variety of options in the possible level (depth and cross-
area breadth) of technical review that could be part of declaring a
Snapshot; the required level could vary based on the stated purpose
of the snapshot.
None of the current Snapshot proposals contain new measures for
retiring snapshots. It is unclear whether allowing Snapshots to
expire (as Internet Drafts do) is an effective impetus for
implementers to move on to a subsequent stable version (which may
contain significant technical improvements). Higher levels of
approval (e.g., IESG) for a Snapshot may make this more difficult to
accomplish.
3. Discussion of Pros and Cons
This section will be filled in after initial discussion on the
working group mailing list.
4. Security Considerations
This document relates to IETF process, not any particular technology,
thus it raises no particular security concerns.
5. Acknowledgements
Substantial text was taken directly from an earlier draft by Scott
Bradner. Ideas were lifted from mailing list discussions. Comments
and contributions were made by <your name could be here>.
6. Appendix 1: Summary of Current IETF Standards Track
Section 4.1 [RFC2026] defines the stages on the IETF standards track
as follows:
4.1 Standards Track Maturity Levels
Internet specifications go through stages of development, testing,
and acceptance. Within the Internet Standards Process, these
stages are formally labeled "maturity levels".
This section describes the maturity levels and the expected
characteristics of specifications at each level.
4.1.1 Proposed Standard
The entry-level maturity for the 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 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.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed
Standard designation.
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.
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 to be
useful and necessary (and timely) even with known technical
omissions.
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to
gain experience and to validate, test, and clarify the
specification. However, since the content of Proposed Standards
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 Draft Standard
A specification from which at least two independent and
interoperable implementations from different code bases have been
developed, and for which sufficient successful operational
experience has been obtained, may be elevated to the "Draft
Standard" level. 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. Elevation to Draft Standard is a major advance in
status, indicating a strong belief that the specification is
mature and will be useful.
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.
The Working Group chair is responsible for documenting the
specific implementations which qualify the specification for Draft
or Internet Standard 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.
A Draft Standard must be well-understood and known to be quite
stable, both in its semantics and as a basis for developing an
implementation. A Draft Standard may still require additional or
more widespread field experience, since it is possible for
implementations based on Draft Standard specifications to
demonstrate unforeseen behavior when subjected to large-scale use
in production environments.
A Draft 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 Draft
Standards into a disruption sensitive environment.
4.1.3 Internet Standard
A specification for which significant implementation and
successful operational experience has been obtained may be
elevated to the Internet Standard level. 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.
7. Appendix 2: Specific example of "Prune"
Scott Bradner originally proposed this alternate IETF standards track
with a new stage inserted before Proposed Standard, combining Draft
Standard and Internet Standard and retaining Proposed Standard as it
has evolved over the years.
Part of the problem we have been seeing with getting timely
publication of IETF specifications is that once people start
implementing the technology it often seems counterproductive to
dedicate effort to finishing off the documents. If implementations
of Internet Drafts achieve success in the marketplace, as they did
with MPLS, it may seem that it is not worth spending time tweaking
successive generations of Internet Drafts in order to get something
the IESG is willing to publish as a Proposed Standard then, if that
achieves widespread success in the market, fiddle with the document
again and do the bookkeeping needed to get it published as a Draft
Standard. The prerequisites for getting something published as an
Internet Standard seem to many people to be fuzzy at best. In
addition, the current standards track steps did not do much to
encourage early implementations, which are the best way to check to
see that a specification is clear enough for implementers to use.
This alternate set of stages tries to encourage vendors to implement
specifications and the comments with the descriptions of each stage
attempt to provide guidance for the IESG in implementing reviews for
each stage.
RFC 2026 would have to be revised in order to put any change of this
type into effect. That could be done by replacing RFC 2026 itself
with a whole new document or by writing a short document that updates
the standards track part of RFC 2026.
7.1 Alternate Standards Track Maturity Levels
Internet specifications go through stages of development, testing,
and acceptance. Within the Internet Standards Process, these stages
are formally labeled "maturity levels".
This section describes a set of alternate maturity levels and the
expected characteristics of specifications at each level.
7.2 Stable Snapshot
The entry-level maturity for the standards track is "Stable
Snapshot". A specific action by the IESG is required to move a
specification onto the standards track at the "Stable Snapshot"
level.
A Stable Snapshot 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.
A Stable Snapshot should have no unknown technical omissions with
respect to the requirements placed upon it. Any such omissions must
be noted in the document. No such omission can endanger the security
or stability of the Internet or of networks where the technology
might be used.
Implementers should treat Stable Snapshots as immature, pre-standard,
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Stable Snapshots will be changed if
problems are found or better solutions are identified, and will be
changed as the technology is finalized, deploying implementations of
such technologies into a disruption-sensitive environment is not
recommended.
Commentary:
This stage is designed to institutionalize and encourage the
current practice of vendors implementing from Internet Drafts
while providing a way that a working group can indicate that
they feel that a technology is stable enough to be so implemented
and to provide a long-lived, unlike Internet Drafts, snapshot that
the vendors can implement. Having vendors implement technology is
an important quality check and meets the "running code"
requirement of our motto. We want to encourage implementations
whenever we can but this does need to be balanced with some level
of maturity and stability of the protocol.
This is almost the same definition as RFC 2026 has for Proposed
Standard. The major difference is that some of the technical
requirements might not have yet been met. This is OK as long as
any such holes in the specification are carefully noted in the
document, except that there needs to be a complete enough security
component so as to not endanger the networks where the technology
is to be used, and that the technology not endanger the wellbeing
of the network it will be run on. The exact guidelines for
the level of security required for a Stable Snapshot will evolve
over time.
In reviewing an Internet Draft for publication as a Stable
Snapshot the IESG only needs to be sure that the working group has
a reason to think that the technology is at a mature enough level
that implementers can start to play with it and that the minimum
security and 'health of the net' requirements have been met. The
IESG should not try to ensure that the text is clear and
unambiguous, the vendors will find that out while implementing and
provide feedback to the working group. The IESG should not do a
careful technology review as a precondition for publication as a
Stable Snapshot. This process should be lightweight, not taking
too much time on the part of the IESG or effort on the part of the
working group and authors.
The name, "Stable Snapshot" was chosen to clearly indicate that
this is a pre-standard stage and to ensure that marketing people
cannot easily misrepresent the status but there may be a better
name that accomplishes the same goals.
7.3 Proposed Standard
A Proposed Standard 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.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.
Generally some documented level of implementation and/or operational
experience is required prior to granting Proposed Standard status.
However, the IESG may waive this requirement in order to allow a
specification to advance to the Proposed Standard state when it is
considered to be useful and necessary (and timely) even without any
known implementations.
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it.
Implementers should treat Proposed Standards as stable, but perhaps
not final, specifications. A Proposed Standard must be well-
understood and known to be quite stable, both in its semantics and as
a basis for developing an implementation. A Proposed Standard may
still require additional or more widespread field experience, since
it is possible for implementations based on Proposed Standard
specifications to demonstrate unforeseen behavior when subjected to
large-scale use in production environments.
Commentary:
The requirements for publication as a Proposed Standard are mostly
the same as currently in RFC 2026 for Proposed Standard with the
addition of a requirement for at least some implementation
experience.
The IESG review for Proposed Standard could stay just like it is.
The IESG should do the same careful technical review and a review
to ensure that the language of the document is clear and precise
as it has been doing for quite a while.
Because most specifications for which publication as a Proposed
Standard is requested will have been implemented I would expect
that the IESG review will generally take less effort since the
implementers experience will have uncovered unclear language and
some or all technical issues, at least for the parts of the
specification that had been implemented.
There should be some documentation to show that there has been at
least one implementation of a specification before the IESG
authorizes the publication of the specification as a Proposed
Standard. But the documentation does not need to be so detailed
that it shows which individual options have been implemented. A
list of the names of people or companies who have said they had
implemented the specification should be sufficient.
Before adoption of a new description of Proposed Standard the IPR-
related aspects should be revisited in list of the work in the IPR
working group but I have not done that here.
7.4 Internet Standard
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and
for which sufficient successful operational experience has been
obtained, may be elevated to the "Internet Standard" level. 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.
Elevation to Internet Standard is a major advance in status,
indicating a strong belief that the specification is mature and will
be useful.
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 Draft or Internet
Standard 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.
A Internet Standard (which may simply be referred to as a Standard)
must be well-understood and known to be stable, both in its semantics
and as a basis for developing an implementation. 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.
An Internet Standard is considered to be a final specification, and
changes should only be made to solve specific problems encountered.
Commentary:
The description here is a combination of the descriptions of Draft
Standard and Internet Standard in RFC 2026.
One issue we have had over the years is just what does a working
group chair have to do to show multiple implementations of the
base specification and all of the features. I have always felt
that a simple spread sheet showing each feature, how many vendors
claim to have the feature, and a checkbox to indicate that two or
more vendors claim that they have tested implementations of the
feature, would be just fine. But this turns out to be quite
complex in some cases (see the Implementer's report for http 1.1
as an example). It is not cleare if this turns out to be actually
too much of an effort or just seems like too much of an effort.
It still seems like about the right thing but the barrier to
reach Internet Standard should be just as high as it needs to be
but no higher.
Since, in reality, there was little difference between the
requirements in RFC 2026 for Draft Standard and Internet Standard,
mostly a need to show market acceptance in some way, there seems
to be no technical reason to preserve the different labels.
7.5 Minimum time in each stage.
It seems that there needs to be a minimum time that a document must
sit at a stage before it can move onward (as is the case in RFC 2026)
just to be sure that any problems are uncovered.
It is unclear how to figure out the ideal time so it is suggested
that 6 months would be enough (as long as the rest of the
requirements for the next level have been met).
8. Informative References
[RFC2026] Bradner, S. Ed., "The Internet Standards Process --
Revision 3," October 1996, RFC 2026
[RFC3774] Davies, E. Ed., "IETF Problem Statement," May 2004,
RFC 3774
[TSS] Dawkins, S., et. al., "Two Stage Standardization," work in
progress, draft-dawkins-pstmt-twostage-02.txt
[WGS] Dawkins, S., et al, "Working Group Snapshot (WGS)," work in
progress, draft-dawkins-newtrk-wgs-00.txt
9. Authors' Addresses
David Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
Email: black_david@emc.com
Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4 / Postfach
8803 Rueschlikon
Switzerland
Email: brc@zurich.ibm.com
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 IETF's procedures with respect to rights in IETF 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 (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
