Network Working Group J. Klensin
Internet-Draft May 23, 2004
Expires: November 21, 2004
Valuable Antique Documents: A Model for Advancement
draft-klensin-newtrk-antiques-00.txt
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.
This Internet-Draft will expire on November 21, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
RFC 2026 and some of its predecessors require that Proposed and Draft
Standards either advance in grade within a reasonable period of time
or that they expire and be moved to Historic. That procedure has
never been followed on a systematic basis. A new procedure has been
proposed that would make that action easier for protocols that have
not gotten any real acceptance. In the interest of symmetry,
fairness, and an orderly attic, it is worth noting that there are a
number of protocol descriptions which have been at less than Full
Standard level for a long time but which have proven their value by
the traditional criteria of multiple interoperable implementations
Klensin Expires November 21, 2004 [Page 1]
Internet-Draft Advancing Antiques May 2004
and wide deployment and use.
This document provides a procedure for upgrading such documents to
Full Standards without creating an unreasonable burden on authors
purely to meet the needs of procedural rituals or placing an
unreasonable load on groups charged with performing other tasks in
the IETF.
Table of Contents
1. Introduction and History . . . . . . . . . . . . . . . . . . . 3
2. Modified Advancement Model . . . . . . . . . . . . . . . . . . 4
3. Candidates for Advancement . . . . . . . . . . . . . . . . . . 4
4. Advancement of Individual Documents . . . . . . . . . . . . . 5
5. RFC Boilerplate . . . . . . . . . . . . . . . . . . . . . . . 6
6. Selection of the Commission . . . . . . . . . . . . . . . . . 6
7. Temporary Note to the Newtrk WG . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Klensin Expires November 21, 2004 [Page 2]
Internet-Draft Advancing Antiques May 2004
1. Introduction and History
This document is intended to be read in conjunction with the proposal
to use a "Commission for Protocol Obsolescence" to make
recommendations to the IESG for downgrading or progressing documents
on the IETF standards track [1] and is probably meaningless in its
present form unless that proposal is adopted. The difference between
the two is that the cited document focuses on downgrading -- retiring
of a document to Historic -- while this one focuses on getting
documents advanced when they describe protocols that have already
proven their value, i.e., are "mature".
That document notes that documents to retire descriptions of immature
standards "require significant time and effort on the part of
authors, area directors, and the RFC Editor" and that "no document
should be required for an immature standard to be retired to Historic
status". Using much the same reasoning, we suggest that, in many or
most cases, no document (or, at most, only trivial modifications,
should be required to advance a fully-mature standard whose
usefulness has been widely demonstrated.
Over the years, there have been many discussions in the IETF
community about why documents never move beyond "Proposed" status
even when they describe protocols that are obviously widely deployed
and for which multiple interoperable implementations exist. Many
reasons have been suggested, but at least the following seem to be
significant:
o Once a Proposed Standard protocol has been implemented and
deployed, and the specification has proven, in practice, to be
adequate to support multiple conforming implementations, it is
extremely difficult to stimulate authors to produce revisions to
the description to advance it in grade. Even if the authors can
be convinced to do so, that may not be in the best interest of the
IETF community: authors and editors who might do the document
upgrading work might better be doing work with real, rather than
procedural, impact.
o Similarly, over the years, IETF requirements for standards-track
documents and standards-track protocols have steadily increased,
with new sections and levels of detail being required that were
not required when the documents for some of our proven, mature,
standards were written. While most or all of those additional
requirements are justified for new protocols, retroactively
imposing burdensome additional documentation requirements on
proven protocols has been another disincentive to advancement of
those protocols.
o Even worse, from the standpoint of getting these documents
advanced, there has been some history of second-guessing older
Klensin Expires November 21, 2004 [Page 3]
Internet-Draft Advancing Antiques May 2004
protocols in the light of more recent thinking. Specifically, if
an attempt is made to advance a protocol that has been deployed
and established for years, the question may be asked by the IESG
or others as to whether it would be designed the same way today.
If the answer is "no", or even "probably not", the protocol has
often been rejected for advancement.
This combination of circumstances sends a powerful message to
authors, and that message is "do not even bother trying to advance
the protocol".
2. Modified Advancement Model
The IETF community has long claimed to believe, not only in "rough
consensus and running code", but in interoperable implementations and
deployment. The procedure outlined below is based on the assumption
that the basic functional requirements for Draft and Full Standard
outlined in RFC 2026 [2] are, for mature, deployed, and proven
protocols, more important than documentation "nits" or procedural
rituals. The empirical observation that a protocol has been widely
deployed and used for many years without significant harm being done
to the Internet is, in that context, more important than an extensive
theoretical presentation of scaling or security issues.
This model, and the specific suggestions that follow, depend
critically on the community remembering and understanding that
"Internet Standard" designates a protocol that is sufficiently
specified to facilitate independent interoperable implementations,
that is widely deployed, and that has been found significantly
useful. It does not imply that the protocol is either recommended or
required: when we had those categories, they were considered
orthogonal to standards track maturity levels.
It also depends critically on the community making the distinction
between a mature, useful, and widely implemented and deployed
protocol and a document of that protocol that may not be optimal
under contemporary standards. It suggests that, for those cases, it
is better to explicitly advance a protocol with a weak or incomplete
specification than it is to pretend (even by omission) that the
protocol is not, de facto, a Standard.
3. Candidates for Advancement
The advancement procedure for mature standards has the following
steps. These closely parallel the steps of [1] and are intended to
use the same Commission. Having two separate bodies parse the
collection of older standards track documents is almost certainly
inefficient.
Klensin Expires November 21, 2004 [Page 4]
o In the process of its investigations as to whether documents
should be reclassified as Historic according to RFC 2026, the
Commission may identify some documents as likely candidates for
treatment as "mature standards". The definition of those
standards is as described above, i.e., in spite of being
officially at Proposed or Draft levels, they are widely accepted
in the community, widely deployed, and appear to be the
beneficiaries of independent implementations.
o For each such RFC, the Commission sends out a message to the IETF
list and the lists deemed relevant, asking for comments on
implementation experience and active usage.
o Unless those reports cause the Commission to determine that the
standards are, in fact, not mature, it will treat each one as
discussed in the next section.
4. Advancement of Individual Documents
While some other options are possible, and might be attractive, this
document assumes that any advancement in grade will need to be
considered individually and subjected to a formal IETF Last Call.
The goal of the procedure outlined here is to avoid even more
complicated procedures, time-consuming and frustrating document
rewriting, etc., where possible.
To the three alternatives listed under "Individual Decommissioning
Procedure" in [1], this document adds "Advancement of Grade". The
intent is to move all "mature" standards to Full Internet Standard
unless there are significant and substantive reasons to not do so.
Because of the requirements of RFC 2026, Proposed Standard documents
for mature standards must be advanced in two steps, but the IESG is
strongly encouraged to make the second of those steps completely pro
forma, with no change in the published RFC.
If the Commission recommends that a specification be advanced, and
the community (as determined by the IESG) agrees, rewriting of the
relevant RFC should be avoided to the extent possible. As suggested
above, if the specification was good enough to support multiple
independent implementations and wide deployment, then it is
sufficient for an Internet Standard. If additional text is required,
it should take the form of supplemental comments to be published
either separately or as an appendix to an otherwise substantially
identical RFC. If the Commission and community determine that the
protocol is mature, contemporary standards for documentation and
specification shall not be applied retroactively.
The "Procedure" to be used is identical to that discussed in [1].
The "Evaluation Criteria" are those discussed above for determining
whether or not a standard is mature. Put differently, those criteria
are the ones listed for Internet Standard in RFC 2026, independent of
judgments about document editorial quality.
Klensin Expires November 21, 2004 [Page 5]
Internet-Draft Advancing Antiques May 2004
5. RFC Boilerplate
This document explicitly contemplates the advancement to Internet
Standard of documents that would not pass muster for Proposed if
first written today. It also contemplates the publication, as part
of advancement of other documents that, similarly, would not meet
today's criteria. The RFC Editor and IESG are encouraged to work out
a suitable "boilerplate" statement that indicates that the documents
describe mature specifications designated as Internet Standards
because they represent common and established practice rather than
because the documents are of the quality expected today for such
Standards.
6. Selection of the Commission
Since this procedure is expected to use the same Commission as in
[1], whatever selection mechanism is specified in that document and
its successors will apply here as well.
7. Temporary Note to the Newtrk WG
While I didn't intend it when I agreed to write this draft, it became
clear to me in doing so that, if viewed as an ongoing procedure
rather than a one-time cleanup mechanism, it actually provides an
alternate standards track mechanism. Viewed that way, we end up with
the same maturity levels as in 2026, but two ways of getting past
Proposed. One involved being very diligent about writing and
upgrading documents, as 2026 more or less explicitly contemplates.
The other involves producing Proposed Standard documents of
sufficient quality to support interoperable implementations, getting
them implemented and deployed widely enough to meet both the criteria
for full Standard and a perhaps-somewhat-stronger standard of
usefulness and then, after period of time long enough to establish
the specification as common practice, just promoting the documents as
written. While some of the language above contemplates documents of
the quality and content that was considered acceptable a decade or
two ago going to full Standard essentially unchanged, more recent
Proposed Standard documents would presumably be more complete and
meet contemporary criteria, thereby requiring fewer disclaimers.
The document deliberately does not specify how elderly a document
must be for this procedure to be invoked. While some guidelines
might be possible and should be discussed, I am comfortable leaving
that question to the discretion of the Commission, subject to the
bounds set by RFC 2026.
Klensin Expires November 21, 2004 [Page 6]
Internet-Draft Advancing Antiques May 2004
8. Security Considerations
See [1] which doesn't seem to have one of these sections either :-)
9. Acknowledgements
This document arose out of a discussion of [1] that, in turn, led to
this author's volunteering to put together an "advancement"
discussion to match that one's downgrading. The contributors to that
discussion, and especially the co-authors of the partner document
(from whom many ideas and much text has been appropriated) are
gratefully acknowledged.
10 Normative References
[1] Alvestrand, H. and E. Lear, "Moving documents to Historic: A
procedure", draft-alvestrand-newtrk-historical-00 (work in
progress), March 2004.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Klensin Expires November 21, 2004 [Page 7]
Internet-Draft Advancing Antiques May 2004
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 (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.
Klensin Expires November 21, 2004 [Page 8]