The RFC publication process includes the stages
All RFCs are first published as Internet-Drafts
(I-Ds). All RFCs have been I-Ds, but not all I-Ds
A well-formed RFC starts with a well-formed
Internet-Draft. Please see the Internet-Drafts
page on the IETF
site for policy and submision guidelines, as it
is authoritative regarding Internet-Drafts. In
addition, we recommend the following for authors.
- 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
Anyone can write an Internet-Draft and
independently submit it to the RFC Editor for
possible publication as an RFC (Informational or
Experimental category only). 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. Please see the instructions
on the Independent
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 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
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 require different 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.
Editing sometimes raises issues that lead to
technical discussions involving the working
group and an Area Director. If the delay is
significant, the document is put into IESG state
until the issue is resolved.
may occasionally "fall out" of the queue at any
time, e.g., because a working group, an author,
or an Area Director requests that it be
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:
If an author is no longer available, there are several options
(as listed in
the FAQ). 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 the AUTH48
FAQ for more information.
When an RFC is published, an announcement is sent to
rfc-dist mailing lists. The canonical URI is of
the form: http://www.rfc-editor.org/rfc/rfcXXXX.txt. The
most recently published RFCs are listed here.
The IETF Trustee
License Information page summarizes the current
copyrights and disclaimers on patent
("Intellectual Property") rights, as of 10 November 2008.
2026 "The Internet Standards Process --
This page was last updated on 18 September 2012.