Go to Top.
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.
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.
19 August 2003. Updated 18 October 2006. Updated 14 June 2011.
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.
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.
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
Abbreviations
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.
"This memo proposes a modification to the Terribly Redundant Internet Protocol Encapsulation (TRIPE) protocol ..."
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.
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.
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:
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.
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.
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.)
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:
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.
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".
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.
Please send mail about any
problems with and/or comments on this page.
Abstract Section
Table of Contents
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
Address Munging in Contact Information
Last modified 27 February 2012.