The RFC publication process includes the stages described below. See the process flowcharthere.
All RFCs are first published asInternet-Drafts (I-Ds).All RFCs have been I-Ds, but not all I-Ds become RFCs.
A well-formed RFC starts with a well-formed Internet-Draft. Please see theInternet-Drafts page on theIETF site for policy and submission guidelines, as it is authoritative regarding Internet-Drafts. In addition, we recommend the following for authors.
The IAB processes their documents as described inRFC 4845.
All RFCs in a Standards Track or Best Current Practice (BCP) category, as well as some Informational and Experimental RFCs, originate within the IETF process and reach the RFC Editor through the IESG. Members of the IESG include the IETF Area Directors (ADs), who are responsible for sets of related working groups. These working groups develop documents that may be approved for publication as RFCs by the ADs with IESG concurrence.
The IRTF processes their documents as described inRFC 5743.
Anyone can write an Internet-Draft and independently submit it to the Independent Submissions Editor (ISE) for possible publication as an RFC (Informational, Experimental, and Historic categories only). It will be reviewed for technical competence, relevance, and adequate writing. It will also be reviewed by the ISE and by the IESG for possible conflict with the IETF process. If selected for publication, the submission will enter the RFC Editor’spublication queue.
An independent submission must first be published as an Internet-Draft. Please see the instructions on theIndependent Submissions page regarding submission.
The RFC Editor maintains a list of documents in the editorial process. Since documents are processed in roughly FIFO order, this list is called thepublication queue.
Each document in the queue is assigned to astate that tracks its progress. Thestate diagram shows the overall publication process.
Whenever a document enters the editorial queue, changes its state in the queue, or leaves the queue, an automatic email message summarizing the state change is sent to the authors. This message is for information only; it does not replace existing messages to authors, such as AUTH48 messages.
Here are thedetails of how we update your source file, and here are some important notes on the process.
Once an RFC has been edited and is ready for publication, the author(s) are given “48 hours” (in practice, this often stretches over weeks) to look over their document for errors, editorial and otherwise. We DO NOT make changes to RFCs once they have been published, so please look over your document carefully. Upon approval by all authors, the RFC will be published.
The AUTH48 notification message sent to authors asks that they review the entire document, paying particular attention to:
All AUTH48 messages will be CCed to auth48archive@rfc-editor.org, the archival mailing list that preserves the AUTH48 conversation. Theauth48archive list isnot an active discussion list.
Note: If absolutely necessary, authors may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If opting out, authors should add a note to the top of the message that indicates the auth48archive@rfc-editor.org has been dropped. When the discussion is concluded, the archive will be re-added to the CC list and its addition will be noted at the top of the message.
See the general AUTH48 process describedhere.
If an author is no longer available, there are several options (as listed in theFAQ). Indefinite delays are not allowed, but when there is a choice, the RFC Editor would in general prefer to publish it right than to publish it early.
See theAUTH48 FAQ for more information.
When an RFC is published, an announcement is sent toietf-announce andrfc-dist mailing lists. The URL for the info page of an RFC is of the form: https://www.rfc-editor.org/info/rfcXXXX. The most recently published RFCs are listedhere.
TheIETF Trustee License Information page summarizes the current rules governingRFC copyrights and disclaimers on patent (“Intellectual Property”) rights, as of 10 November 2008.