The Basics

  1. The RFC Editor was once Jon Postel; who is it today?
  2. Every RFC was attributed to the "Network Working Group". What working group is that?
  3. Are all RFCs Internet standards documents?
  4. How can one tell where in the Standards Track an RFC is?
  5. Can the status of an RFC change after publication?
  6. How can I correct an error in a published RFC?
  7. May I reproduce or translate an RFC?
  8. Who are the stream managers?

    Reading RFCs

  9. Can I be notified when a new RFC is published?
  10. I cannot retrieve the text of an RFC. Why not?
  11. When I retrieve an RFC, every line ends in "^M". What gives?
  12. Can I get a hard copy of the RFCs?
  13. Can I get a copy of the RFCs on CD-ROM?

    Writing RFCs

  14. How do I get an RFC published?
  15. 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?
  16. How long does it take for a document to become an RFC?
  17. Can I reserve an RFC number?
  18. What can I do to expedite the RFC publication process?
  19. I just realized my document has typos, or my address or affiliation has changed, what do I do?
  20. What style guide does the RFC Editor use?
  21. How should RFCs be listed in the references section?
  22. Will I have a chance to look over my document before it becomes an RFC?
  23. One of the authors is no longer available; how do we proceed?
  24. 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?
  25. What if I want to include diagrams in an RFC that cannot be rendered in ASCII?
  26. How can I submit an April 1st RFC?

    Authors' Final Review (AUTH48 State)

  27. How does AUTH48 work?
  28. 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?
  29. You sent me the URL for my XML file, but I'm getting a 404 Not Found error message. How do I retrieve it?
  30. Which file should I use to make updates myself and to send back to the RFC Editor?
  31. When can I send my changes?
  32. Can you change the placement of the page breaks?
  33. Why isn't there a blank line between two authors' addresses (there seems to be missing whitespace)?
  34. Who needs to approve the document?
  35. What do we do if one of the authors is unavailable?
  36. Why does the stream manager need to approve the changes?
  37. I changed my affiliation after this document was edited. Should I use my new or old affiliation for this document?
  38. 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?
  39. Why did you change "which" to "that"?
  40. I used British English. Why did you change it to American English?

  1. 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. 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".
  2. Every RFC was attributed to the "Network Working Group" (before the publication of RFC 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 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.
  3. 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.

  4. How can one tell where in the Standards Track an RFC is?
    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.

  5. 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 in RFC 6410) or from Informational to Historic. For a list of all RFCs that have changed status, please see the list of status changes.
  6. How can I correct an error in a published RFC?
    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).

  7. May I reproduce or translate an RFC?
    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.
  8. Who are the stream managers?
    As defined in RFC 4844, the RFC Editor publishes documents from 4 streams. These are:
    Stream Stream Manager
    IAB IAB Chair
    IETF IESG
    Independent Submissions ISE
    IRTF IRTF Chair
  9. Can I be notified when a new RFC is published?
    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
    
  10. I cannot retrieve the text of an RFC. Why not?
    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.

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

  12. 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 three thousand RFCs the size of a hard copy would fill several book cases. 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.
  13. Can I get a copy of the RFCs on CD-ROM?
    The RFC Editor does not publish CD-ROM copies of the RFC repository. As expressed above, these would become quickly out of date. For this reason, users are encouraged to consult the RFC Editor website for the most current version of any standard. In the past we have given permission for several commercial ventures to market RFC CDs, but we are not aware that any of these ventures still exist. Users may, of course, create their own CD-ROMs.
  14. How do I get an RFC published?
    See the RFC publication process.
  15. 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 the RFC Editor Queue
  16. 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 the cluster page.) Authors should also be aware that the RFC Queue may be congested right before meetings of the IETF.
  17. 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 see I cannot retrieve the text of an RFC. Why not?
  18. What can I do to expedite the RFC publication process?
    Read all the instructions carefully. Make sure your document is formatted properly. See the RFC publication process and the RFC Style Guide.
  19. I just realized my document has typos, or my address or affiliation has changed, what do I do?
    If your document is in the RFC Editor Queue, please go ahead and send the changes to the RFC Editor at any time.
  20. What style guide does the RFC Editor use?
    See the RFC Style Guide. Also, we generally refer to "The Chicago Manual" (16th edition).
  21. How should references to RFCs be listed?
    A handy file of reference text for RFCs is available here: http://www.rfc-editor.org/in-notes/rfc-ref.txt. We prefer representative reference tags (such as [RFC2119]) over numeric reference tags (such as [1]).
  22. Will I have a chance to look over my document before it becomes an RFC?
    Yes, during AUTH48 state. See Publication Process.
  23. One of the authors is no longer available; how do we proceed?
    We recommend one of the following paths:
    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.
  24. 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 if errata are reported for that RFC.
  25. What if I want to include diagrams in an RFC that cannot be rendered in ASCII?
    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".
  26. 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 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.
  27. How does AUTH48 work?
    See the instructions for completing AUTH48 here.
  28. 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.

    Note: XML files are available only if the authors submitt an XML file as a starting point for editing.

  29. 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 to the RFC Editor, as the file may not have been posted correctly.

    Note: XML files are available only if the authors submitt an XML file as a starting point for editing.

  30. Which file should I use to make updates myself and to send back to the RFC Editor?
    If you submitted an XML file, please use the edited XML file, which is available here (as noted in the AUTH48 notification message):

      http://www.rfc-editor.org/authors/rfcXXXX.xml

    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 the XML file and the email. Replying in either form is sufficient.

    If you submitted an NROFF or TXT file, you should send your changes in email (as described in the AUTH48 notice).

  31. 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.
  32. Can you change the placement of the page breaks?
    If you submitted an XML file, page breaking will be handled at the final stage of production, just before the document is published as an RFC. Once you approve the content of the document, the page breaks will be updated.

    If you haven't submitted an XML file and you want the page breaking to appear differently, please let us know.

  33. Why isn't there a blank line between two authors' addresses (there seems to be missing whitespace)?
    Diff files do not display page breaks and thus do not always accurately represent whitespace. Review the TXT file to view the whitespace.
  34. 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. 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:

      http://www.rfc-editor.org/auth48/rfcXXXX

    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.

  35. What do we do if one of the authors is unavailable?
    This is the same as described above.
  36. 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.

    See information about stream managers above.

    Editorial changes do not require approval from a stream manager.

  37. 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:

  38. 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).
  39. 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.

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

This page was last updated on 16 May 2014.