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.

If your document is in the RFC Editor Queue, please go ahead and send the changes to the RFC Editor at any time.

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 state. See Publication Process.

We recommend one of the following paths forward:

1. The author can be removed as an author and moved to the Acknowledgements section.
2. The author can be removed as an author and moved to a Contributors section.
3. A stream manager can approve the document in place of the unavailable author. (See the IESG Statement on AUTH48 State.)

Option 3 is typically used in instances where the missing author made significant contributions to the document, so the other authors are not comfortable removing the individual from the author list.

The WG chairs and Area Directors are CC'ed on every message sent from the RFC Editor to the authors during the course of the publication process, so they have the option of giving input at any time. Specifically, Area Director approval is requested when any changes that are beyond editorial are introduced into the document. A reply from WG chairs may be sought for issues that affect more than one document from their WG or for decisions about whether the WG needs to review changes. The Document Shepherd (when not one of the WG chairs) is also CC'ed on each message from the RFC Editor during the publication process. After the RFC is published, the authors as well as the WG chairs and Area Directors receive the notification message if errata are reported for that RFC.

After an RFC has been published, there is an option of posting a PDF with images; it contains the exact text of the RFC with diagrams added. This file is an option for authors and is produced by the authors.

Examples of RFCs that have used this option are RFC 4128, RFC 4137, RFC 4601, RFC 5059, RFC 5317, and RFC 5598. Note that each RFC has a PDF file available, which is a PDF file of the straight text. The optional PDF is listed as "PDF with images".

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.