Internet DRAFT - draft-klensin-historical-definition
draft-klensin-historical-definition
IETF J.C. Klensin
Internet-Draft S. Bradner
Updates: 2026 (if approved) Harvard University
Intended status: Best Current Practice February 14, 2014
Expires: August 16, 2014
RFCs and the "Historical" Category
draft-klensin-historical-definition-01.txt
Abstract
The "Historical" category has been used to identify some documents in
the RFC Series for many years, but has never been precisely defined
except in various oral traditions. More important, with one
exception that is now obsolete, the conditions under which documents
should be reclassified as Historic and the procedures for doing so
have never been defined, leading to a number of ad hoc and
inconsistent actions. This document clarifies both the category and
procedures for putting documents into it.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 16, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Klensin & Bradner Expires August 16, 2014 [Page 1]
Internet-Draft Historical RFCs February 2014
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction and History . . . . . . . . . . . . . . . . . . . 2
2. A Typology of Documents that Have Been Placed in the Historic
Category . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Obsoleted by another document . . . . . . . . . . . . . . 3
2.2. Published but ignored . . . . . . . . . . . . . . . . . . 3
2.3. Documents that are no longer relevant to the Internet . . 4
2.4. Specifications published purely for historical value . . . 4
2.5. Specifications that are believed to be undesirable or
dangerous in some way . . . . . . . . . . . . . . . . . . 4
3. Procedures for Classification as Historic . . . . . . . . . . 5
4. Documentation Requirements . . . . . . . . . . . . . . . . . . 5
4.1. Case 1: Clearly Obsolete and Irrelevant for Future
Development . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Case 2: Obsolescent documents requiring formal action . . 6
4.3. Case 3: Deprecation and other situations requiring consensus
decisions . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Interaction with Applicability Statements . . . . . . . . . . 7
6. Documenting Status Changes . . . . . . . . . . . . . . . . . . 7
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A.1. Changes from version -00 to -01 . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and History
The "Historical" category for RFCs was mentioned in the RFC Series as
early as December 1988. The description at that time said
"[t]hese are protocols that are unlikely to ever become standards
in the Internet either because they have been superseded by later
developments or due to lack of interest. These are protocols that
are at an evolutionary dead end." [RFC1083]
Klensin & Bradner Expires August 16, 2014 [Page 2]
Internet-Draft Historical RFCs February 2014
The category was most recently specified in Section 4.2.4 of the
Internet Standards Process definition [RFC2026]. However, the
specification there says only "has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level". With one exception, it does not
specify what entity makes that assignment, how it is done, and when
it is actually appropriate. The exception is the provision for
automatic reclassification of standards track documents that have not
advanced in Section 6.2 of the Standards Process definition, a
provision that was eliminated in 2013 [RFC6410]. It is worth noting,
for example, that neither the RFC Editor nor the IESG routinely moved
earlier documents to Historic when later ones where published that
superseded ("obsoleted") except in the case where the replacement
documents explicitly specified that action.
This memo elaborates on the Historic category (or "level") and
defines conditions and mechanisms for placing documents in it.
While this is not a protocol specification in the usual sense, the
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted for the actions and options it
specifies as described in RFC 2119 [RFC2119].
2. A Typology of Documents that Have Been Placed in the Historic
Category
Part of the long-term difficulty with the Historic category is that,
in the past, it was applied to documents for a number of different
reasons. This section lists those situations and gives examples of
each to provide a proper background.
There may be controversy about whether this is the only typology
possible. We assert only that it is one reasonable typology.
2.1. Obsoleted by another document
This is the one category that is explicitly called out by the IETF
Standards Process [RFC2026]. Documents in this category are
associated with a subsequent RFC that contains similar or replacement
content and which explicitly identifies the earlier, now obsolete,
"Historic" candidate in an "Obsoletes" header and the author wants to
make it clear that the older RFC is no longer to be relied upon.
RFC 1145 [RFC1145] is an example of a document in this category.
2.2. Published but ignored
Klensin & Bradner Expires August 16, 2014 [Page 3]
Internet-Draft Historical RFCs February 2014
Documents fall into this category if they were published but were
never implemented or deployed and there is no evidence that anyone
expects them to be implemented or deployed in the future. Someone
was motivated to reclassify the RFC, most often to minimize the
chance that a casual reader would assume that the technology
described in the RFC was relevant.
RFC 1421 [RFC1421] is an example of documents in this category.
Documents in this category and the next one have occasionally been
classified as Historic and documented as a group. RFC 4450 [RFC4450]
is an example of that approach.
2.3. Documents that are no longer relevant to the Internet
These are specifications that may have been important at one time but
that are believed to no longer be in use and to have no future
utility. Protocol specifications that became irrelevant after the
transition from the ARPANET to the Internet would fall into this
category. The reason to reclassify RFCs in this case is the same as
with the last category.
RFC 1240 [RFC1240] is an example of a document in this category and
RFC 2556 [RFC2556] is an example of a document reclassifying a RFC to
Historic for this reason.
2.4. Specifications published purely for historical value
Occasionally a document will be published in the RFC series simply to
record something for historical value. These documents may be
identified by their authors as Historic at the time of first
publication in order to make it clear that the documents are not
meant to be implemented.
RFC 4156 [RFC4156] is an example of documents in this category.
2.5. Specifications that are believed to be undesirable or dangerous in
some way
Occasionally, a specification may be published that is later found to
be undesirable, less attractive than some alternative, or dangerous
or harmful in some way. In this case, the aim of reclassification is
to ensure that the technology described in the RFC is not seen as one
Klensin & Bradner Expires August 16, 2014 [Page 4]
Internet-Draft Historical RFCs February 2014
that should be implemented or used.
RFC 1058 [RFC1058] is an example of a document in this category and
RFC 1923 [RFC1923] is an example of a document reclassifying a RFC to
Historic for this reason.
3. Procedures for Classification as Historic
In 2011, the IETF removed [RFC6410] the never-used procedure for
automatic reclassification to Historic was removed from the Internet
Standards Process [RFC2026]. That action eliminated the only case in
which a change to Historic status did not require some formal action.
With the exception of that automatic reclassification procedure,
there has never been an organized procedure for identifying non-
standards-track IETF documents, much less documents from other
Streams [RFC4844] as Historic unless they were published that way
(see Section 2.4).
Moving a document to Historic is treated as a significant action, not
merely a side-effect of, e.g., its being superseded by another one.
In the context of Section 2.1 above, a document being obsoleted by
another is one possible justification for classifying the earlier
document as Historic, but it is not a sufficient one.
An actual reclassification to Historic requires justification and a
level of community review equivalent to that required to approve
publication of the document (or subsequent documents of that type)
initially. For the IETF Stream, that implies a formal Last Call
process documents and community consensus for standards track ones.
Other streams are required to establish appropriate procedures
consistent with the principle above before reclassifying any future
documents to Historic.
4. Documentation Requirements
There are three main cases for identification of a document as
Historic, with applicability based on the categories above.
Klensin & Bradner Expires August 16, 2014 [Page 5]
Internet-Draft Historical RFCs February 2014
4.1. Case 1: Clearly Obsolete and Irrelevant for Future Development
This group contains documents that were published as Historic
(Section 2.4 above), have been explicitly obsoleted by one or more
other documents (Section 2.1), or that describe protocols or other
topics that are obviously of no further use to, or on, the Internet
(Section 2.2). ARPANET-specific documents that, as of the time of
this writing, have had a status of "UNKNOWN" for many years MAY be
recommended for reclassification to Historic by the RFC Editor if a
determination is made that they are not referenced by active
documents in other categories. For documents not on the standards
track that precede the distinctions of the streams model of RFC 4844,
there may be ambiguity about the applicable stream. In those cases,
the RFC Editor should work out an appropriate procedure for review
and approval with the IAB. Subject to the more general requirements
above, the RFC Editor and/or the relevant stream authority are
encouraged to consult relevant communities before classifying a
document as Historic using this method, but are not required to do
so. For this case, documentation other than tracking records
associated with the Last Call is not required but may be useful,
especially to future historians of the IETF and associated Internet
documents.
4.2. Case 2: Obsolescent documents requiring formal action
Where the conditions above do not apply but a document appears to
cover a specification or description that is no longer in use, a
stream MAY verify the absence of implementations or deployment by its
usual procedures for obtaining consensus from its community to
reclassify the document. If there is doubt about that consensus or
there appears to be a strong possibility that the specification has
been implemented and deployed, the third procedure MUST be used. The
stream MUST document the decision in some stable and permanent way
according to procedures of its choice. As with the case above,
ambiguity about the applicable stream and review process should be
resolved between the RFC Editor and the IAB. The RFC Editor is
responsible for assuring that documentation is readily identified and
available to anyone looking for information about the relevant
RFC(s).
4.3. Case 3: Deprecation and other situations requiring consensus
decisions
Klensin & Bradner Expires August 16, 2014 [Page 6]
Internet-Draft Historical RFCs February 2014
This procedure applies when neither of the above procedures is
applicable and, in particular, when there is reason to believe that
the specification or information in the RFC has been implemented and
deployed, and that it may still be in use on the Internet or some
network that might leak into it. It is also appropriate if the move
to Historic is intended to formally deprecate a specification rather
than simply record the fact that it is obsolete. For these cases,
the stream is expected to prepare a document that describes the
reasons for the status change and approve it for RFC publication
using the stream's normal procedures. That RFC should explicitly
note that it obsoletes the earlier document; the request to move that
earlier document to Historic may be part of the RFC or communicated
separately. The RFC may be an Applicability Statement (most
appropriate if the previous document was Standards Track) or an
Informational one that describes the outcome of an earlier experiment
or that documents operational experience or a new understanding of
the implications of the prior specification or information.
5. Interaction with Applicability Statements
Specifications that the community has concluded are undesirable or
dangerous SHOULD normally be formally assigned a status of "Not
Recommended" (see Section 3.3(e) of RFC 2026) and MAY be identified
as Historic when that is appropriate for other reasons.
Because of the existence of other categories and the potential for
confusion with them, reclassification to Historic is, by itself, not
an appropriate way to deprecate a document or what it specifies.
6. Documenting Status Changes
Any change in the status of a RFC to Historic SHOULD be documented in
a way that informs readers as to the reason for the change. The
documentation SHOULD be made easily findable and remain accessible
for as long as likely that someone might want to refer to the RFC.
In the case of the approval and publication of a new RFC that
explicitly recategorizes one or more RFCs the new RFC serves as the
documentation. In other cases, the existence and location of the
documentation should be easy to find from the normal way that people
determine the status of RFCs, for example, in the RFC index.
7. Summary
Klensin & Bradner Expires August 16, 2014 [Page 7]
Internet-Draft Historical RFCs February 2014
A document may be moved to Historic for multiple reasons, ranging
from recognition that it is no longer in use, useful, or applicable
to a desire to formally deprecate a specification and warn the
community against its use. In general, the former cases should be
handled as an administrative procedure: documented as appropriate but
not requiring an explanation in the RFC Series. By contrast, when a
protocol that is in active use (even if only a few places) is to be
deprecated, that action and the reasons for it should be documented
in the RFC Series and should receive the same levels of review and
consensus as the document it proposes to deprecate and make Historic.
The principle is that, unless something was never implemented or
taken seriously or has become completely unused over time, undoing
its approval and any implicit recommendation (even a recommendation
for experimentation) should require the same process of approval and
publication as was needed to approve it initially. Anything else
risks both confusing readers of the RFC Series and questions about
the fairness of the actions taken.
8. Acknowledgements
This document was developed as an alternative to an appeal of an IESG
action that classified a specification that had been implemented and
deployed as Historic without documentation in the RFC series of the
reasons for that action. The issues are discussed in more detail in
Section 7.
Comments from Jari Arkko and Pete Resnick about the initial version
were particularly helpful in shaping the second one.
9. IANA Considerations
This memo includes no requests to or actions for IANA. It is,
however, important to check that any document being proposed for
Historic status neither contains the definitions of, nor is
referenced from, any IANA registry without clarification of the
status of the registry or registry entry. That clarification might
require publication of an RFC even if the category of the document
itself does not.
10. Security Considerations
While this specification should have no direct effect on Internet
Security, some of its provisions will have the effect of getting
specifications that are found to pose security risks appropriate
documented so as to warn the community, rather than creating doubt
about why the specification was made Historic.
11. References
11.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
Klensin & Bradner Expires August 16, 2014 [Page 8]
Internet-Draft Historical RFCs February 2014
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1083] Postel, J., "IAB official protocol standards", RFC 1083,
December 1988.
[RFC1145] Zweig, J. and C. Partridge, "TCP alternate checksum
options", RFC 1145, February 1990.
[RFC1240] Shue, C., Haggerty, W. and K. Dobbins, "OSI connectionless
transport services on top of UDP: Version 1", RFC 1240,
June 1991.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993.
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement
for Historic Status", RFC 1923, March 1996.
[RFC2556] Bradner, S., "OSI connectionless transport services on top
of UDP Applicability Statement for Historic Status", RFC
2556, March 1999.
[RFC4156] Hoffman, P., "The wais URI Scheme", RFC 4156, August 2005.
[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.
[RFC4844] Daigle, L.Internet Architecture Board, "The RFC Series and
RFC Editor", RFC 4844, July 2007.
[RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
October 2011.
Appendix A. Change Log
RFC Editor: Please remove this appendix before publication.
Appendix A.1. Changes from version -00 to -01
o Separated the discussions of approval requirements from
documentation requirements
o Several small editorioal changes to improve readability and
correct errors.
Klensin & Bradner Expires August 16, 2014 [Page 9]
Internet-Draft Historical RFCs February 2014
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Scott Bradner
Harvard University
Email: sob@harvard.edu
Klensin & Bradner Expires August 16, 2014 [Page 10]
