Search RFCs

Frequently Asked Questions

The Basics

Reading RFCs

Writing RFCs

Authors’ Final Review (AUTH48 State)

The RFC Editor was once Jon Postel; who is it today?

The RFC Editor is no longer a single person; it is a small group of people. TheIETF Administration LLC (IETF LLC) contracts the RFC Editor function toAssociation Management Solutions, LLC (AMS). Through 2009, the home of the RFC Editor function was the Networking Division of theUSC 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,”“40 Years of RFCs,”, and“Fifty Years of RFCs.”

Every RFC was attributed to the “Network Working Group” (before the publication ofRFC 5741). What working group is that?

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 in 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.

Are all RFCs Internet standards documents?

In a word,“NO!”. Many RFCs have Informational or Experimental status and do not represent any kind of standard. They contain information that may be useful or important to retain in this archival document series. This is important to understand, because unscrupulous marketeers and a careless trade press sometimes falsely suggest that every RFC represents a standard, or that all standards have equal weight. The relationship among Internet technical specifications is often complex.

How can one tell where in the Standards Track an RFC is?

Consult the online document“Internet Official Protocol Standards”.

Can the status of an RFC change after publication?

Yes, the status of an RFC can change; this information is available in several locations including the RFC info page and RFC search results. For example, an RFC can be moved from Proposed Standard to Internet Standard (as described inRFC 6410) or from Informational to Historic. For a list of all RFCs that have changed status, please see thelist of status changes.

How can I correct an error in a published RFC?

Youcannot! 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 theRFC Errata page to look up errata by RFC number or view the complete list. Also, search results from theRFC search page include hyperlinks to any corresponding errata entries. To report an error in an RFC, please use the form available from the RFC Errata page (seeHow to Report Errata for details).

For RFCs that have verified technical errata, there are files available with the errata shown inline (when possible). They are listed as “HTML with inline errata” in the RFC search results and info pages. For example:
RFC 5234.

May I reproduce or translate an RFC?

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

How are the document streams related to the categories?
While information on which streams can publish in which category is recorded in various RFCs (see RFCs4844,4845, and5742), a summary is captured here to make the information viewable at a glance. As always, the canonical information is in the RFCs.
Document Stream Standards Track* Best Current Practice (BCP) Experimental Informational Historic
IETF X X X X X
IRTF X X X
IAB X X X X
Independent X X X
* including Internet Standard (STD) and Proposed Standard
Who are the stream managers?
As defined inRFC 4844, the RFC Editor publishes documents from 4 streams. These are:
Stream Stream Manager
IAB IAB Chair
IETF IESG
Independent Submissions ISE
IRTF IRSG
Can I be notified when a new RFC is published?

Document Stream	Standards Track*	Best Current Practice (BCP)	Experimental	Informational	Historic
IETF	X	X	X	X	X
IRTF			X	X	X
IAB		X	X	X	X
Independent			X	X	X

Stream	Stream Manager
IAB	IAB Chair
IETF	IESG
Independent Submissions	ISE
IRTF	IRSG

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 athttps://mailman.rfc-editor.org/mailman/listinfo/rfc-dist. There’s also anRSS feed andAtom feed.

I cannot retrieve the text of an RFC. Why not?

There is alist 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.

When I retrieve an RFC, every line ends in “^M”. What gives?

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

Can I get a hard copy of the RFCs?

The RFC Editor does not publish the repository in hard copy. There are several reasons for this. First, with over eight thousand RFCs the size of a hard copy would fill several bookcases. Second, given that most of the community obtains electronic versions of these documents, there is insufficient market to justify the printing costs. Finally, the RFC repository is constantly being extended. Any printed version would be quickly out of date.

How do I get an RFC published?

Seethe RFC publication process.

Once my document has been sent to the IESG for review, or approved by the IESG for publication, how do I know the RFC Editor has it in their queue?

Please look at theRFC Editor Queue.

How long does it take for a document to become an RFC?

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 thecluster page.) Authors should also be aware that the RFC Queue may be congested right before meetings of the IETF.

Can I reserve an RFC number?

No, reserving an RFC number is not an option. The RFC number assigned to a given document is released when the document moves to AUTH48 state. For further information as to why this policy was adopted, please seeI cannot retrieve the text of an RFC. Why not?

What can I do to expedite the RFC publication process?

If expedited publication is needed (including release of an RFC number only) to coordinate publication with other standards development organizations (SDOs), contact your stream manager. They may request that your document be prioritized. A number will be released when AUTH48 is initiated. Please be sure to notify the RPC of the date by which the RFC number is needed.

I just realized my document has typos, or my address or affiliation has changed. What do I do?

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

What style guide does the RFC Editor use?

See theRFC Style Guide. Also, we generally refer to“The Chicago Manual”.

How should RFCs be listed in the references section?

References to RFCs should appear as described in theOnline Portion of the RFC Editor Style Guide; see “Referencing RFCs”.

We recommend using these files for referencing RFCs:
XML: viaBibXML Service (e.g.,https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml)
TXT:https://www.rfc-editor.org/in-notes/rfc-ref.txt

Representative reference tags (such as [RFC2119]) are preferred over numeric reference tags (such as [1]).

How should Internet-Drafts be listed in the references section?

References to I-Ds should appear as described in
Section 4.8.6.3 of the intended update to RFC Style Guide.

We recommend using the XML citation library; the URLs are of the form https://datatracker.ietf.org/doc/bibxml3/reference.I-D.foo.xml. For example:
<xi:include href=”https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mmusic-msrp-usage-data-channel.xml”>

xml2rfc will reference the most current version of the I-D when this format is used. If a reference to a specific version of the I-D is desired, included the version number as part of the URL.

Will I have a chance to look over my document before it becomes an RFC?

Yes, during AUTH48 state. SeePublication Process andAuthors’ Final Review (AUTH48).

One of the authors is no longer available; how do we proceed?

We recommend one of the following paths:

The author can be removed as an author and moved to the Acknowledgements section.
The author can be removed as an author and moved to the Contributors section.
A stream manager can approve the document in place of the unavailable author. (See theIESG 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.

After an Internet-Draft from a working group is approved for publication as an RFC, how are the WG chairs and Area Directors involved in the publication process?

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 iferrata are reported for that RFC.

What if I want to include diagrams in an RFC that cannot be rendered in ASCII?

You can use SVG; please seeHow do I include SVG in my document?.

For background, before the transition to v3 XML, there was an option to post a PDF with enhanced images after the ASCII text was published. It would contain the exact text of the RFC with diagrams added. This file was produced by the authors. Since 16 September 2020, authors may no longer submit enhanced PDF files, as they can use SVG to create their figures in the RFC.

Note that the enhanced PDF files posted before that date are still available. Examples of RFCs that have used this option areRFC 4128,RFC 4137,RFC 4601,RFC 5059,RFC 5317, andRFC 5598. The optional PDF is listed as “PDF with images”.

How do I get the source file to write a “bis” document (a document that will obsolete an existing RFC)?

For a recent source file (RFC 8650 and onwards), please retrieve it fromhttps://www.rfc-editor.org/in-notes/prerelease/. This is the“not prepped” XML source file, best for continued editing.

For numbers below RFC 8650, source files (XML or NROFF) are available by request; please send mail to theRFC Editor.

What is the “not prepped” XML file?

It’s the file before the prep tool defined inRFC 7998 is run. Before we publish the source file of an RFC, we use the xml2rfc tool to do a process called “preparing” the XML. This fills in defaults, adds explicit section numbers, and adds other data (including any external content) to make it easier to render the XML consistently into other formats. While the prepped XML is ideal for rendering, it is far from ideal for editing, since section numbers can change as text is added or reordered, and all of the default values can make it hard to find the useful XML elements and attributes.

How can I submit an April 1st RFC?

April 1st submissions are the only RFCs-to-be that do not need to be posted as Internet-Drafts. These entries should be sent directly to theRFC 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.

How does AUTH48 work?
See the instructions for completing AUTH48here.

You sent me the URL for my XML file, but I can’t view the XML file in my browser. How do I retrieve it?

In the browser, there are several options to save the XML file. Please use “view page source” (or similar) and save the file.

You sent me the URL for my XML file, but I’m getting a 404 Not Found error message. How do I retrieve it?
Please send mail tothe RFC Editor, as the file may not have been posted correctly.
Which file should I use to make updates myself and to send back to the RFC Editor?
Please use the edited XML file, which is available here (as noted in the AUTH48 notification message):
where XXXX is the number of the RFC.
Note: If there are questions included within the XML file, you do not need to reply in both the XML file and the email. Replying in either form is sufficient. Please seethe AUTH48 notice for more information.

When can I send my changes?
If your document is in AUTH48, send your changes as soon as possible. This is your last chance to make changes; once the document is published as an RFC, we will not make changes.

Can you change the placement of the page breaks?
In the v3 format, no, we cannot generally change the placement of the page breaks (which only appear in the PDF output).

Who needs to approve the document?
Each of the authors listed in the first-page header must approve the document before it can be published as an RFC. Note that those listed in the document header are responsible for reviewing and approving the RFC-to-be for publication. As part of that, they are also responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing their approval. In addition, the RFC Editor requires stream manager approval for any changes that seem beyond editorial in nature. See information about stream managers above. You can track the progress of approvals on the AUTH48 page at the following location:
where XXXX is the assigned RFC number.
Note: Before or after your approval of the document as a whole, there may be changes sent by your coauthors. Assuming you have already sent us your approval of the document, it still stands unless you notify us otherwise. Any changes that are beyond editorial will be sent to the relevant body for approval.

What do we do if one of the authors is unavailable?
This is the same as the topicdescribed above.

Why does the stream manager need to approve the changes?
We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Seeinformation about stream managers above. Editorial changes do not require approval from a stream manager.

I changed my affiliation after this document was edited. Should I use my new or old affiliation for this document?
We require a working and long-lived email address, but updating the rest of your contact information is up to you. We prefer up-to-date contact information, but we understand that authors sometimes need to credit the employer that supported their work on the document. A few options (in no particular order) that may work here:
- No change to your contact information (if it includes a long-lived and working email address).
- Completely update your contact information (no mention of your previous employer).
- Completely update your contact information, and include an acknowledgement to thank the organization that supported your work on the document. For example, seeRFC 6113.

How does the IANA get notified of any changes to the descriptions of values being registered by this document, and how do they know when to update the reference to point to the published RFC?
Once we have approvals from each of the authors, we will begin the publication process. The RFC Editor will notify the IANA that the RFC has been published and what the assigned RFC number is. The references will be updated to reflect the new RFC number shortly after the notification has been sent (usually a few business days).

Why did you change “which” to “that”?
“Which” clauses are nonrestrictive (nonessential to the sentence) and add something about an item already identified, while “that” clauses are restrictive (essential to the sentence) and narrow a category or identify a particular item being talked about.For example:
- (non-restrictive “which”: all RST attacks rely on brute-force): It should be noted that RST attacks, which rely on brute-force, are relatively easy to detect at the TCP layer.
- (restrictive “that”: only *some* RST attacks rely on brute-force): It should be noted that RST attacks that rely on brute-force are relatively easy to detect at the TCP layer.

I used British English. Why did you change it to American English?
If there is a mix of British and American English within the Internet-Draft, the document is updated to use American English for consistency, as noted in Section 3.1 ofRFC 7322.

IAB •IANA •IETF •IRTF •ISE •ISOC •IETF Trust
Reports •Privacy Statement •Site Map •Contact Us

Movatterモバイル変換

Search RFCs

The Series

For Authors

Sponsor

Frequently Asked Questions