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

by: Jeff Hodges
Under Construction   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...

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
( The first three maturity levels are also referred to as the standards track.) one "Requirement Level Status" from this list...
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.


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...

© 1996-1999 Jeff Hodges, All Rights Reserved