Internet DRAFT - draft-carpenter-newtrk-questions
draft-carpenter-newtrk-questions
Network Working Group B. Carpenter (ed)
Internet-Draft IBM
Expires: December 11, 2006 June 9, 2006
Questions about the standards track
draft-carpenter-newtrk-questions-00
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.
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 December 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document sets out some thoughts about three possible directions
for further work on the evolution of the IETF standards track. Its
purpose is to stimulate community discussion leading to a choice
between these three directions.
Carpenter (ed) Expires December 11, 2006 [Page 1]
Internet-Draft Questions about the standards track June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Focus on document relationships . . . . . . . . . . . . . . . 4
3. Focus on maturity levels . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Change log [RFC Editor: please remove this section] . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Carpenter (ed) Expires December 11, 2006 [Page 2]
Internet-Draft Questions about the standards track June 2006
1. Introduction
BCP 9 [RFC2026] is the current definition of the IETF standards
track. For some years there has been concern in the IETF that the
three stages of the standards track are no longer well adapted to
current conditions. One version of the statement of this problem is
in [RFC3774] which says:
"2.4. Three Stage Standards Hierarchy not properly Utilized
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:
o Relatively few specifications are now progressed beyond Proposed
Standard (PS) to Draft Standard (DS) level, and even fewer to Full
Standard (FS)."
(etc.)
It is important that the concern is not viewed only as a matter
internal to the IETF. The IETF's output is of no value unless it is
useful to a much wider community: implementors, vendors, service
providers, and directly or indirectly for the whole user community.
Therefore, the comprehensibility and useability of IETF
specifications for all these stakeholders is at issue. This broad
perspective, and not the IETF's internal workings, should be our
first concern. This point seems to have been missed in the drafting
of [RFC3774], which is rather focussed on the mechanics of the IETF,
but is implicit in the IETF Mission Statement [RFC3935].
Some time ago, the New IETF Standards Track Discussion (newtrk) WG
was set up to tackle this problem. Its charter says in part:
"The goal of this working group is to agree on a revised IETF
Standards Track, to replace the standards track described in RFC
2026. The working group will also decide on a process path forward.
"The disparity between the documented IETF standards process and what
is used in practice can cause confusion on the part of those people
or organizations that use IETF technologies...
"The goal of this working group is to agree on a revised IETF
Carpenter (ed) Expires December 11, 2006 [Page 3]
Internet-Draft Questions about the standards track June 2006
Standards Track, taking into consideration the above points, to
replace the standards track described in RFC 2026. The working group
will also decide on a process for making forward progress...
"As part of a revised standards track process, the group will also
explore the creation of a new series of short IESG-approved IETF
documents to describe and define IETF technology standards. These
documents should be able to be used to define the IETF understanding
of what constituted a specific IETF standard at particular points in
time."
This draft will not attempt to recapitulate the history of
discussions in newtrk. However, they have not yet led to a set of
proposals which have both solid WG support and seem likely to rapidly
reach IETF consensus and IESG approval. There are undoubtedly
differences of opinion about how this situation arose and who is to
blame. This draft avoids that discussion. Its goal is to set out
three distinct ways forward and to stimulate constructive discussion
in the community (not just in the WG) about which is the best choice
for the future.
The three possible ways forward are:
1. Agree that, apart from day to day efforts to improve efficiency,
the problems with the existing standards track are not serious
enough to justify the effort needed to make substantial changes.
Conclude that [RFC3774] exagerrated the problem and we only need
to make a relatively minor set of clarifications to BCP 9
[RFC2026].
2. Focus on the issue of document relationships, or as the newtrk
charter currently says "the creation of a new series of short
IESG-approved IETF documents to describe and define IETF
technology standards."
3. Focus on the three-stage standards track, or as the newtrk
charter currently says "agree on a revised IETF Standards
Track... to replace the standards track described in RFC 2026."
The next two sections expand somewhat on the latter two alternatives.
2. Focus on document relationships
Today, users of IETF standards have no way to unambiguously identify
the complete current set of specifications for a given standard. In
particular, there is no effective structured document identification
scheme and no systematic approach to documenting the relationship
between various parts and versions of a standard.
This issue is best illustrated by example. Perhaps the most
Carpenter (ed) Expires December 11, 2006 [Page 4]
Internet-Draft Questions about the standards track June 2006
fundamental example is Internet Protocol version 4. Consider a
hypothetical programmer on a desert island, with a computer and an
electricity supply, but no information except the indexed corpus of
RFCs and their external normative references. How can this
programmer implement IPv4 interoperably? The index will suggest
starting with RFC 791 (a Standard), updated by RFC 1349 (a Proposed
Standard, i.e. of lower status, so how can it have priority?). The
index then tells our programmer that RFC 1349 was obsoleted by RFC
2474 (another Proposed Standard). It then indicates that RFC 2474
was updated by RFC 3168 (Proposed Standard) and by RFC 3260
(Informational). Only by reading RFC 2474 will our programmer know
to consult RFC 2475 (Informational). And nowhere in this process is
she led to a much more important reference: RFC 1122 "Requirements
for Internet Hosts - Communication Layers" (a Standard), which itself
has been updated by RFC 1349 (again) and RFC 4379 (17 years later).
We will stop the trail here, but it should be clear that our isolated
programmer is unlikely to determine which RFCs she needs to follow to
build an interoperable IPv4 stack.
Other examples abound. What is the set of documents needed to fully
specify TCP or SMTP? How does an implementor of FTP know that the
appropriate reference for ASCII is RFC 20? Among more modern
protocols, where does a SIP or MPLS implementor look for the complete
set of relevant specifications?
All is not hopeless. An IPv4 implementor who starts with RFC 1122
and its updates has a better chance than one who starts with RFC 791,
at least until having to tackle DHCP. An IPv6 implementor can start
with RFC 4294 (IPv6 Node Requirements). An IPv4 router implementor
can start with RFC 1812 (Requirements for IP Version 4 Routers). But
these are exceptions produced with great effort. In the general
case, implementors need to be experts in the baroque structure of the
corpus of RFCs as much as in the technology itself. This is a cost
to the community, directly resulting from the IETF's piecemeal
approach.
At least two lines of attack on this problem have been pursued in the
newtrk WG. To avoid this document interfering in newtrk's due
process, only a very brief overview is given here.
The first approach is known as Internet Standards Documents (ISDs).
Conceptually, an ISD defines what a given standard is and which RFCs
(of any maturity level) form part of that standard. In this model,
an ISD equivalent of RFC 4294 would actually be *the* IPv6 standard,
for example.
The other, simpler, approach is an XML model for describing a set of
associated RFCs, without otherwise affecting the concept of what a
Carpenter (ed) Expires December 11, 2006 [Page 5]
Internet-Draft Questions about the standards track June 2006
standard actually is. These documents would be known as Set of RFC
Documents (SRDs). In effect, they are a boost to the existing
indexing mechanisms for RFCs.
Obviously, the introduction of any such mechanism would create a new
document series and, in some cases, extra work. In other cases the
work is already done but in other forms (e.g. Applicability
Statement RFCs, or external white papers). As with any change of
practice in the IETF, we would need all WG chairs, and the IESG, to
sign on and to manage the necessary work. The community needs to
decide whether the benefits outweigh these costs.
3. Focus on maturity levels
The current three stage standards track is perceived to be under-used
and to have specific problems that make some aspects of it
unrealistic. (It should be noted that the number of stages in the
standards track does not affect the time taken to move a draft
through the approval process and to publish it, so the problem under
discussion is distinct from the issues of the time taken to obtain
IESG approval and RFC publication.)
This is the topic that the newtrk WG tackled initially. Proposals
have been made over several years for reducing the standards track
from three to two stages or even one stage, for adding a WG Snapshot
option, and for related clarification of the implementation report
requirement (a.k.a. the "running code" requirement) for advancement
in the standards track. All of these changes are relatively simple
to define, but no consensus has emerged in the WG as to which of them
is preferable.
It seems to be generally agreed that the requirement in BCP 9
[RFC2026] for regular review of Proposed Standards and Draft
Standards to see if they are ready for advancement is unrealistic,
with so many such RFCs on the books. Even the exercise in de-
classifying unused Proposed Standards [RFC4450] proved to be a lot of
work, needing several rounds of community review.
The community needs to decide whether the problems in this area are
in fact grievous enough to be tackled in priority, or whether they
are relatively benign.
4. Discussion
Clearly a case can be made for all three of the approaches mentioned.
We could shrug our shoulders and perform a maintenance update of BCP
Carpenter (ed) Expires December 11, 2006 [Page 6]
Internet-Draft Questions about the standards track June 2006
9 [RFC2026]. We could make a concerted effort to choose between a
two-stage and a one-stage replacement for the three-stage standards
track. We could set that question aside and make a concerted effort
to agree on a standards-description recipe. However, experience
strongly suggests that we *do* need to make a choice as a community
between these three alternatives, and (assuming effort can be found)
charter work on only one of them with clear goals and realistic
milestone dates.
It seems likely that if we choose to charter work on the standards
description effort, formal adjustments to the three-stage standards
track could be made at a later stage if the community wanted. It
also seems likely that a maintenance update of BCP 9 will be needed
anyway, but this should not be confused with the major question: do
we embark first on the standards track update, the standards
description effort, or neither?
Community discussion is invited, in the first instance at
ietf@ietf.org.
5. Security Considerations
This document has no security implications for the Internet.
6. IANA Considerations
This document requires no action by the IANA.
7. Acknowledgements
In drafting this document, previous discussions within the IESG were
reviewed. Discussion with, among others, the current newtrk Chair,
Scott Bradner, and John Klensin are gratefully acknowledged.
This document was produced using the xml2rfc tool[RFC2629].
8. Change log [RFC Editor: please remove this section]
draft-carpenter-newtrk-questions-00: original version, 2006-06-09
9. References
Carpenter (ed) Expires December 11, 2006 [Page 7]
Internet-Draft Questions about the standards track June 2006
9.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
[RFC4450] Lear, E. and H. Alvestrand, "Getting Rid of the Cruft:
Report from an Experiment in Identifying and Reclassifying
Obsolete Standards Documents", RFC 4450, March 2006.
Carpenter (ed) Expires December 11, 2006 [Page 8]
Internet-Draft Questions about the standards track June 2006
Author's Address
Brian Carpenter (ed)
IBM
8 Chemin de Blandonnet
1214 Vernier,
Switzerland
Email: brc@zurich.ibm.com
Carpenter (ed) Expires December 11, 2006 [Page 9]
Internet-Draft Questions about the standards track June 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 authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Carpenter (ed) Expires December 11, 2006 [Page 10]
