Creating an RFC

Before it can be published as an RFC, a document must first be published as an Internet Draft (I-D). All RFCs have been I-Ds, but not all I-Ds become RFCs.

The following links point to important information for RFC authors.

RFC Submission Process

  • RFCs from the IETF

    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.

  • Independent Submissions

    Anyone can write an RFC and independently submit it to the RFC Editor for possible publication. It will be published after review, and perhaps revision, for technical competence, relevance, and adequate writing. It will also be reviewed by the RFC Editor and by the IESG for possible conflict with the IETF process. Once this has been completed successfully, independent submissions enter the same publication process as IETF submissions.

    An independent submission must first be published as an Internet Draft. The author may then send e-mail to rfc-editor@rfc-editor.org requesting that the document to be considered as an RFC in the Informational or Experimental category (please specify).

RFC Publication Process

The RFC Editor maintains a list of documents in the editorial process. Since documents are processed in roughly FIFO order, this list is called the publication queue.

Each document in the queue is assigned to a state that tracks its progress. The state diagram shows the overall publication process. The top of this diagram, in yellow, shows the independent submission review process. The bottom, in green is the actual 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 some important notes on the process.

  • IANA processing generally takes place in parallel with editing, but occasionally a document can be held up a long time in IANA state (through no fault of IANA).

  • A document A that has a normative reference to a document B that is not yet in the queue will be held at MISSREF state (perhaps a very long time) until B enters the queue.

    Once A and B are both in the queue, they will both be edited. For various reasons this editing may required diferent times. A will be held in REF state, if necessary, until B's editing is complete, so that A and B will enter the final quality control state RFC-EDITOR, together. Collections of 5 or more documents linked by such normative references are not unusual.

  • IETF working groups sometimes submit sets of documents that should be published together although they are not explicitly coupled by normative references. (Ideally, such document sets would be visible in the queue; we are working on that). A document that belongs to such an implicit set may be held (perhaps a long time) in RFC-EDITOR state, untiL the entire set has entered RFC-EDITOR state.

  • The Author Final Review state AUTH48 can sometimes cause a long delay, when authors are unresponsive or when significant technical issues arise at the last minute.

  • Editing sometimes raises issues that lead to technical discucssions involving the working group and an Area Director. If the delay is significant, the document is put into IESG state (not shown) until the issue is resolved.

  • Although the diagram does not show it, a document may occasionally "fall out" of the queue at any time, e.g., because a working group, and author, or an Area Director requests that it be withdrawn.

Authors' Final Review (AUTH48 State)

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.

We STRONGLY suggest that authors use this opportunity to check for spelling and missing words and to ensure that the references and contact information are up to date. Also, if the is a MIB, we encourage one last look at your CODE.

Upon request or because of temporary unavailability of an author, the nominal 48 hours will be extended. In extreme cases, the relevant AD can act in stead of a missing author. 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.

Reference

  • RFC 2026 "The Internet Standards Process -- Revision 3".

This page was last updated on 07Nov08.