IETF Document Series and How Standing is Denoted

A section of An LDAP Roadmap & FAQ: A tutorial aid to navigating various LDAP and X.500 resources on the Internet, v2.0a

This is v2.0a -- a "beta" release -- it is still way under construction. You will find version 1.5, which may or may not be more up-to-date, HERE. Apologies for any confusion.

This section last updated: 16-Feb-1999

Back to the main LDAP Roadmap page v2.0a

IETF Document Series Explained

Note: there are a couple of RFCs that explain this stuff in gory detail. They are referenced near the bottom of this page.

The IETF produces several document series. They are classified as...

RFC -- Request For Comments
RFCs are the IETF's fundamental series of persistent documents. Being persistent means they have all been permanently assigned an RFC number, are permanently available from the RFC repositories by that number, and are immutable. Except for Internet-Drafts, all of the IETF's other document series noted below are subsets of the RFC series.

STD -- Standards.
These are RFCs whose standardization state (see below) is Standard (aka "Full" Standard). There are 54 Standard RFCs at the time of this writing. A STD will have both an RFC number and a STD number.

BCP -- Best Current Practices
These RFCs document the results of IETF community deliberations about statements of principle, or document conclusions on the currently best way to administer portions of the Internet's space and/or protocols. There are 30 BCPs at the time of this writing. A BCP will have both an RFC number and a BCP number.

FYI -- For Your Information
From the Introduction to FYI1 (FYI one)...

The FYI series of notes is designed to provide Internet users with a central repository of information about any topics which relate to the Internet. FYIs topics may range from historical memos on "Why it was was done this way" to answers to commonly asked operational questions.

An FYI will have both an RFC number and an FYI number. There are 33 FYIs at the time of this writing.

RTR -- RARE Technical Reports
The documents in this series are somewhat historical in that RARE (Reseaux Associes pour la Recherche Europeenne, roughly: Euopean Research Association) merged with EARN (European Academic and Research Network) in 1994 to form TERENA (Trans-European Research and Education Networking Association). Essentially, some of RARE's documents were of interest to the Internet as a whole and so were co-published as RFCs.

I-Ds, IDs -- Internet-Drafts
Internet-Drafts are a mutable document series and are the proper precursors to most RFCs. Being mutable means that the series is unstable over time, i.e. documents are removed from, as well as added to, the series. The series supports document versioning -- the documents have version numbers as well as names. They do not, however, have a persistent document series number as do the documents of the RFC series and its subsets.

How the Standing of RFCs is Denoted

The overall standing of an RFC is defined by a tuple vector (see below and STD1, for details):

Overall standing := {Standardization State, Requirement Level Status}

"Standardization State" is also referred to as the maturity level of the RFC. Often Standardization State is referred to as the status of an RFC because the Requirement Level isn't often noted in casual, or even reasonably formal, references to one. An example is the RFC-Editor's own RFC list. At any point in time an RFC's overall standing is made up of one maturity level value from this list...

Standard (aka "Full" Standard); Draft Standard; Proposed Standard; Experimental; Informational; Historic
: ( The first three maturity levels are also referred to as the standards track.)

..plus one "Requirement Level Status" from this list...

Required

Recommended

Elective

Limited

Not Recommended

Most RFCs are at Elective requirement status level. Substantially less are at Recommended, and very few are Required (see the table in section 4 of STD1). These status levels are in terms of systems that are attached to the Internet, where a system is considered either a router or a host, or both, at a (admittedly) gross level of granularity.

Internet-Drafts, aka Life Before RFCs

Note that there is life before a document becomes an RFC. It is almost always initially published as an Internet-Draft. Internet-Drafts are working documents with no standards state or requirement level status at all -- except of course as a glimmer in the eye of their individual authors and champions. The Internet Engineering Steering Group (IESG) is the body that annoints documents (typically Internet Drafts) as RFCs and causes the RFC Editor to publish them. An Internet-Draft typically goes through some amount of vetting process within the IETF which helps provide the basis for the IESG's annointing it with an RFC number.

Summary

These notions of overall standing, maturity levels, requirement levels, Internet-Drafts, etc. are thoroughly discussed in both...

The current issue of INTERNET OFFICIAL PROTOCOL STANDARDS, which is permanently designated as STD1 ,
: And in RFC 2026, The Internet Standards Process -- Revision 3.

These documents, plus several of the documents that they reference,are must-reads for those needing or wishing to understand the ins-and-outs of RFC-space.

How the Standing of Internet-Drafts is Denoted

In short, the standing of Internet-Drafts (I-Ds) isn't explicitly denoted because they don't have any widely- or officially-recognized standing. However, they do have standing to their authors and champions, which are often constituted as an IETF Working Group or (usually) are participants in one. The Internet Drafts editor ensures that I-Ds each have a unique filename, composed according to some rules, along with a monotonically increasing version number. See section 2.2 of RFC 2026 for details.

Back to the LDAP Roadmap table of contents...
Back to the LDAP FAQ contents...
Back to the main LDAP Roadmap & FAQ page...