RFC Editorial Guidelines and Procedures

During the RFC editing process, the RFC Editor strives for quality, clarity, and consistency of style and format. In its long history the RFC series evolved a particular editorial style. The RFC Editor is conservative about maintaining this style and the procedures that produce it, but new situations sometimes lead to new editorial guidelines and procedures.

This page summarizes relatively recent changes, which have been adopted after consultation with the IESG and IAB. These changes will be incorporated into the revised Style Guide and associated web site as soon as they are published.

We ask the cooperation of the community in helping us to implement these guidelines, which should result in better quality RFCs for all.

Authors vs. Contributors

Questions are still arising about the editorial policies on RFC authorship, and the contents of the first page, of the Contributors section, and of the Authors' Address section. We will attempt to clarify.

  1. When the RFC Editor refers to "authors", we mean exactly the set of names listed on the first page of an RFC. These people are considered to be equally responsible for the contents of the document, and all will be asked to read and approve the RFC before publication.

  2. When the RFC Editor refers to "contributors", we mean people, other than the authors, who also contributed significantly to the RFC. They should be listed in a Contributors section of the body of the document.

  3. The last section of the document has traditionally been a section listing contact information for authors. The intent of this section is to tell readers how to get in touch with those people responsible for the document, to seek clarification, make comments, etc. This section should include contact information for all authors. This section has been titled "Author's Address" (or "Authors' Addresses").

  4. The issue has arisen: can/should the Contributors section include contact information? The answer is yes, it may include contact information at the authors' discretion.

19 August 2003. Updated 18 October 2006. Updated 14 June 2011.

Go to Top.

Do-Not-Publish-Now Requests

In addition to RFCs generated by the IETF process and approved by the IESG, the RFC Editor publishes independent submissions that are technically competent and relevant to the general subject area of the series. The RFC Editor has primary responsibility to determine publishability of independent submissions, but the IESG does review them to ensure they are not in conflict with any ongoing standardization efforts in the IETF [RFC 2026].

The procedure has been that the IESG could recommend for or against publication of an independent submission. Although the RFC Editor formally has the final decision, in practice the RFC Editor very seldom goes against a Do Not Publish (DNP) request from the IESG, and if they do, they attach a prominent "IESG Note" to the RFC. The RFC Editor is governed by the requirement that independent submission publication must not provide an end-run around the standards process.

Recently, an increasing number of independent submissions have been for publication of technical proposals that have been rejected by some working group. This raises a dilemma. Archival documentation of legitimate alternative ideas is generally a long-term benefit to the community. On the other hand, some users don't read warning labels, so a competing idea published as an independent submission might gain credence outside the IETF before the working group's work has completed.

To balance these competing demands, the IESG and the RFC Editor have developed the following modification to the procedure for reviewing independent submissions. This procedure is provisional; it may be modified if it does not meet its objectives.

When the IESG determines that immediate publication of an independent submission conflicts with an ongoing IETF working group activity, the IESG may recommend to the RFC Editor "do not publish (DNP) at this time" and cite the working group. The RFC Editor will then delay publication for an initial six-month period. The author will be notified that their document will not be published at present but they may re-submit the document six months later. (It is the author's responsibility to retain a copy of the DNP email and include it with subsequent submissions; i.e., the author holds the timer state.)

If the author does resubmit after six months, the same process will be repeated. The IESG can recommend "DNP at this time" a second time, creating a second six-month delay. If the author still wishes to publish the document, it may be submitted a third time. At this time, the IESG may recommend an advisory note be added to the document, but no additional "DNP at this time" delays will be allowed. Thus, working groups are protected from possibly competing publications for up to one year. Note that if the IESG requests it, the RFC Editor will include an IESG Note on the front page of the published RFC, which can give the IESG's opinion about the status of the document in relation to the IETF process.

16 June 2003.

Go to Top.

Copyright statement in MIB and PIB Modules

At the request of the IESG, and immediately effective, the RFC Editor will be placing a copyright statement into all MIB and PIB modules.

Many people/tools extract the MIB or PIB modules out of our RFCs that contain a MIB or PIB module. In most cases they remove the copyright information that is part of the RFC. This is against the IETF copyright claim.

People/tools do this not with bad intentions. The reason they do not extract the copyright info is because it is not in machine readable/parsable form, and they want the MIB or PIB modules to feed them into their agents, network management platforms, or other MIB or PIB tools.

In order to ensure that the copyright statement is properly preserved and included in extracted MIB and PIB modules, and in order to make it easier for people/tools to keep the proper copyright when extracting MIB or PIB modules, the IESG has agreed with the the RFC-Editor that:

The RFC-Editor, during the editing process of an RFC that contains a MIB or a PIB Module, copies a short copyright statement into the DESCRIPTION clause of the MODULE-IDENTITY macro of each MIB or PIB Module in the RFC-to-be.

The copyright statement to be added for a MIB module is as defined in Section 6.d of the Trust License policy.

Go to Top.

Normative References to RFC 2119

Some standards-track documents use certain capitalized words ("MUST", "SHOULD", etc.) to specify precise requirement-levels for technical points. RFC 2119 (BCP 14) [BCP14] defines a default interpretation of these capitalized words in IETF documents. If this interpretation is used, RFC 2119 must be cited (as specified in RFC 2119) and included as a normative reference. Otherwise, the correct interpretation must be specified in the document.
Avoid abuse of requirement-level words. They are intended to provide guidance to implementors about specific technical features, generally governed by considerations of interoperability. RFC 2119 says, "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." To simply specify a necessary logical relationship; the normal lower-case words should be used. On the other hand, if the capitalized words are used in a document, they must be used consistently throughout the document.

Updated: 29 July 2003

Go to Top.


The RFC document series, covering computer communication in general and the Internet in particular, is generally deeply technical. This results in the very extensive use of abbreviations for technical terms. There is a tendency for RFC authors to assume a particular sub-area's terminology and to therefore leave many abbreviations undefined, "because everyone knows what that means". Lack of clarity and sometimes actual confusion of terminology may arise as a result. To preserve the precision and clarity of the RFC documents, the RFC Editor's policy is as follows.

  1. In the body of an RFC, all abbreviations must be expanded when they first appear. The only exceptions are a few abbreviations that are so firmly extablished in modern computer communication and in IETF usage that their use is very unlikely to cause uncertainty or ambiguity. These include: TCP, UDP, IP, IPv4, IPv6, DNS, HTTP, URL, IETF, IRTF, IESG, IAB, OSI, X.25, X.400, X.500.

  2. When abbreviations are thus expanded, the abbreviation in parentheses should follow the expansion; for example:

    "This memo proposes a modification to the Terribly Redundant Internet Protocol Encapsulation (TRIPE) protocol ..."

  3. The same rule applies separately to the Abstract. Thus, an abbreviation that occurs in both the Abstract and the body of an RFC must be expanded in both places.

  4. The same general principle applies to the title of the RFC, although some latitude will be given to keep titles from excessive length or complexity.

Go to Top.

Choosing Titles

Choosing a good title for an RFC can be a challenge. A good title should fairly represent the scope and purpose of the document without being either too general or too specific.

Abbreviations (e.g., acronyms) in a title (as well as the Abstract and the body) must generally be expanded when first encountered. The exception is abbreviations that are so common that every participant in the IETF can be expected to recognize them immediately; examples include (but are not limited to) TCP, IP, SNMP, and FTP.

It may be helpful to follow the expansion with the parenthesized acronym.

        "Encoding Rules for the Common Routing Encapsulation
                      Extension Protocol (CREEP)"

Updated 29 July 2003.

Go to Top.

Author Responsibility

The RFC Editor will hold all the people listed on the front page equally responsible for the final form and content of the published RFC. In particular, the "Author's 48 Hours" final approval period will require signoff from all listed authors. There will be no "honorary" authors.

Go to Top.

Author Overload

The IESG and IETF have ratified a policy of limiting the number of authors listed in the first page header of an RFC. Objections to huge author lists are both practical and ideological. The practical issues have to do with the long-existing RFC formatting conventions that do not comfortably handle large author lists. Ideological objections stem from the Internet community's tradition of individual rather than corporate action and responsibility. Some might see a list of 17 authors on one RFC as motivated by a desire for corporate name-dropping, which would be inappropriate in the IETF/RFC context. If there is a desire to demonstrate how many companies are interested in this spec, a simple acknowledgment section can accomplish the same thing, without Author Overload.

The Internet community's conventions for RFC authors are one of the distinctive features of the IETF culture. Most standards bodies publish anonymous standards, whereas we attach the names of real people, who get both credit and blame, to our specifications. (This is probably a result of the historical beginnings of the IETF in the academic research community.) The person(s) who actually write a document take responsiblity for it, even though there may be a large working group of several hundred people who potentially contributed to it. When there are a number of significant contributors, there is usually a single person tasked with integrating the results into a single document; that person may be listed as "Editor", with acknowledgments for the other contributors. Independent submissions presumably did not originate in an IETF working group, but the same conventions should apply to any informal industry group acting outside the IETF, when the resulting spec is published as an RFC.

The specific policy is as follows:

  1. A small set of author names, with affiliations, may appear on the front page header. These should be the lead author(s) who are most responsible for the actual text. When there are many contributors, the best choice will be to list the person or (few) persons who acted as document editor(s) (e.g.,"Tom Smith, Editor").

    There is no rigid limit on the size of this set, but there is likely to be a discussion if the set exceeds five authors, in which case the right answer is probably to list one editor.

  2. An RFC may include a Contributors section, listing those contributors who deserve significant credit for the document contents. The Contributors section is intended to provide a level of recognition greater than an acknowledgment and nearly equal to listing on the front page. The choice of either, both, or none of Contributor and Acknowledgment sections in a particular RFC depends upon the circumstance.

  3. The body of an RFC may include an Acknowledgements section, in addition to or instead of a Contributors section. An Acknowledgments section may be lengthy, and it may explain scope and nature of contributions. It may also specify affiliations.

  4. The Author's Address section at the end of the RFC must include the authors listed in the front page header. The purpose of this section is to (1) unambiguously define author/contributor identity (e.g., the John Smith who works for FooBar Systems) and to (2) provide contact information for future readers who have questions or comments.

    At the discretion of the author(s), contact addresses may also be included in the Contributors section for those contributors whose knowledge makes them useful future contacts for information about the RFC.

  5. The RFC Editor may grant exceptions to these guidelines upon specific IESG request or in other exceptional circumstances.

Go to Top.

Abstract Section

Every RFC must have an Abstract section following the Title of the document. An Abstract will typically be 5-10 lines. An Abstract of more than 20 lines is generally not acceptable.

The Abstract section should provide a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document. In addition to its function in the RFC itself, the Abstract section text will appear in publication announcements and in the online index of RFCs.

Composing a useful Abstract generally requires thought and care. Usually an Abstract should begin with a phrase like "This memo ..." or "This document ...". A satisfactory abstract can often be constructed in part from material within the Introduction section, but a good abstract will be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is tempting, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract section.

An Abstract should be complete in itself; it should not contain citations unless they are completely defined within the Abstract. Abbreviations appearing in the Abstract should generally be expanded in parentheses. There is a small set of reasonable exceptions to this rule (see guidelines on abbreviations, above.)

Go to Top.

Table of Contents

A Table of Contents (TOC) section is required in RFCs longer than 30 pages and recommended for an RFC longer than 15 pages.

A TOC must be positioned after the Abstract and before the Introduction section (i.e., after the "boiler plate" and before the body of the RFC.)

The TOC itself should not be too long or detailed, or it loses value. For example, if many successive TOC entries point to the same pages of the memo, the TOC probably needs to be coarser. No specific format is required, but the following example illustrates a useful format:

         1.  INTRODUCTION ...............................................    5
            1.1  The Internet Architecture ..............................    6
               1.1.1  Internet Hosts ....................................    6
               1.1.2  Architectural Assumptions .........................    7
               1.1.3  Internet Protocol Suite ...........................    8
               1.1.4  Embedded Gateway Code .............................   10
            1.2  General Considerations .................................   12
               1.2.1  Continuing Internet Evolution .....................   12
               1.2.2  Robustness Principle ..............................   12
               1.2.3  Error Logging .....................................   13

Go to Top.

URLs in RFCs

The use of URLs in RFCs is discouraged, because many URLs are not stable references. Exceptions may be made for normative references in those cases where the URL is demonstrably the most stable reference available. References to long-lived files on ietf.org and rfc-editor.org are also acceptable.

RFCs that include URLs as generic examples must be careful to use the particular example URLs defined in RFC 2606, "Reserved Top-Level DNS Names", to avoid accidental conflicts with real URLs.

Go to Top.

References Section

Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC. There are many styles for references, and the RFCs have one of their own; there is not, however, a standard format for citations.

Please follow the reference style used in recent RFCs. For protocols that have been assigned STD numbers, the STD number must be included in the reference.

Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC.

For more on Normative and Informative references, see "Instructions to RFC Authors".

Go to Top.

Address Munging in Contact Information

The practice of address munging (i.e., altering an email address to make it less readable to bots and web crawlers to avoid spam) is not appropriate in an archival document series. Author contact information is provided so that readers can easily contact the author with questions and/or comments. The practice of address munging makes it more difficult to contact the authors of a document and has not proven advantageous in deterring spam. Therefore, address munging is not allowed in RFCs.

Go to Top.

Go back to RFC Editor home page.

Please send mail about any problems with and/or comments on this page.
Last modified 27 February 2012.