Reading RFCs

Writing RFCs

The RFC Editor is no longer a single person, it is a small group of people. The Internet Society, on behalf of the IETF, contracts the RFC Editor function to Association Management Solutions, LLC (AMS). Through 2009, the home of the RFC Editor function was the Networking Division of the USC Information Sciences Institute (ISI) in Marina del Rey, CA. ISI played a key role in the development of the Internet, and Jon Postel was the Director of ISI'S Networking Division for many years. For a historical account of the RFC series, see " 30 Years of RFCs" and "40 Years of RFCs".

This label in the heading of RFCs is historical in form and symbolic in content. Historically, "network working group" meant the set of researchers who developed the packet switching protocols for the ARPAnet, beginning in 1969. This label was maintained on RFCs as a reminder of the long and significant technical history that is recorded in the RFC series, and as a reminder that today's technical decisions, wise or not, may be with us for many years. Today, the "Network Working Group" should be interpreted as the set of users, vendors, and researchers who are working to improve and extend the Internet, in particular under the ISOC/IETF umbrella.

Consult the online document "Internet Official Protocol Standards". We periodically publish a snapshot of this information as an RFC whose number is divisible by 100; the latest such RFC is STD 1.

These links are also on the RFC Database page.

You cannot! Once an RFC is published, it cannot be changed. The RFCs form an archival series. If the bug represents a change of content, a revised RFC can be written that obsoletes the one in error.

For both technical and editorial errors, the RFC Editor provides a list of errata for published RFCs. Use the RFC Errata page to look up errata by RFC number or view the complete list. Also, search results from the RFC search engine include hyperlinks to any corresponding errata entries. To report an error in an RFC, please use the form available from the RFC Errata page (see How to Report Errata for details).

All RFCs may be freely reproduced and translated (unmodified). Since the publication of RFC 5377 and RFC 5378 in November 2008, the copyright notice and legends that appear on RFCs have been determined by the IETF Trust Legal Provisions. See the IETF Trust Copyright FAQ for further information.

Yes. An announcement of each new RFC is sent to all members of the rfc-dist mailing list. You can subscribe and unsubscribe from this list at:

      http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

There is a short list of RFC numbers that were issued to documents that were never actually published. This explains the occasional gap between numbers. The current procedures are set up to try very hard to avoid this situation in the future; in particular, RFC numbers are never reserved, rather they are assigned at the last moment in the editorial process.

In addition, some RFCs prior to 800 existed only on paper. The RFC Editor has an "RFC Online" project to make the entire RFC series available online. However, this process has necessarily had lower priority than editing new RFCs. We are grateful for the help of volunteers in the Internet community who entered and nroffed text of the missing online RFCs.

See "The End-of-Line Story" for a historical account of the problem and possible solutions.

See the RFC publication process.

Please look at the RFC Editor Queue

Typical time to publish is 1-2 months, but the actual time varies greatly from one RFC to another. Publication may be held up for a variety of reasons, including IESG approval, inconsistencies or omissions that show up in editing, or normative references to other documents that must be published earlier or simultaneously. (For current information on documents linked by normative references, see the cluster page.) Authors should also be aware that the RFC Queue may be congested right before meetings of the IETF.

Read all the instructions carefully. Make sure your document is formatted properly. See the RFC publication process and the RFC Style Guide.

You have two options: WAIT until the document has been approved for publication and then send the changes to the RFC Editor, or wait until AUTH48 to send the RFC Editor the changes. DO NOT send the RFC Editor changes for a document that does not appear in the RFC Editor Queue.

See the RFC Style Guide. Also, we generally follow two sources for style advice: "The Elements of Style" by Strunk & White (4th Ed., 2000) and "A Pocket Style Manual" by Diana Hacker (4th Ed., 2004).

A handy file of reference text for RFCs is available here: ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt. We prefer representative reference tags (such as [RFC2119]) over numeric reference tags (such as [1]).

Yes, during AUTH48. See Publication Process.

April 1st submissions are the only RFCs-to-be that do not need to be published as Internet-Drafts. These entries should be sent directly to the RFC Editor. We appreciate receiving all entries at least 2 weeks prior to April 1st so that the RFC Editor team has time to review all of the documents and prepare those that we decide to publish.