[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/