Choosing between Informational and Experimental Status
This document reproduces the rules for classifying documents as Informational and Experimental from RFC 2026, and amplifies those rules with guidelines relevant to ongoing IESG evaluations. It is not intended to change any of the underlying principles.
Table of Contents
In addition to standards-track documents (proposed, draft, standard and BCP), the RFC series contains three other categories: Informational, Experimental and Historic.
People, including the IESG, are often confused about whether a given document should be Informational or Experimental; this document tries to make that determination simpler. While this serves as commentary on the IETF process rules, it is not intended to change any of the underlying principles. The IESG would welcome comments on this document, which is expected to end up as an informational web page (and therefore doesn't contain all the required sections for RFCs).
2. The Rules
The following sections are reproduced from RFC 2026, including the original section numbers.
4.2 Non-Standards Track Maturity Levels
Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor.
Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense.
The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution.
An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3).
Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor.
The rules above are not always precise. In particular, the reasons for declaring something "part of a research and development effort" aren't clear, and the word "typically" allows a lot of wiggle room.
So more guidelines are often needed in order to interpret the rules.
The following set of guidelines will be used by the IESG. The list is read from top to bottom; the first one that seems to apply is probably the one that makes sense to follow.
Note that guideline 4 above is not intended to say that by publishing this, the IETF is promising to do a followup; the IETF may later decide that the experiment failed, and may sometimes believe this outcome to be very probable even when publishing the document.
Guideline 2 may sometimes be hard to evaluate, because it requires evaluating the intent of the proposer; still, often it is very easy, and nothing further needs to be said.
4. Security considerations
The IESG believes that the security of the Internet is not directly affected by the difference between Experimental and Informational RFCs.
This document was originally drafted by Harald Alvestrand. An XML source was created by Bill Fenner. Useful comments were received from Scott Bradner, Fred Baker and others.
This document was produced using the xml2rfc tool (RFC2629).