[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET-DRAFT                                     Paul Hoffman, Editor
draft-hoffman-rfc-author-guide-01.txt                   VPN Consortium
Obsoletes: RFC 2223
Category: Informational                              September 13, 2004
Expires in six months

           Instructions to Request for Comments (RFC) Authors

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than a "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

IPR Statement

By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.


This document explains what authors who are writing Internet Drafts
which are intended to become Request for Comments (RFC) documents need
to do, and also gives suggestions for those documents.  It explains the
process of RFC publication and lists the requirements for Internet
Drafts that will eventually become RFCs.

Table of Contents

1.  Introduction
   1.1  Acknowledgments
2.  The Precursor to RFCs: Internet Drafts
   2.1 Internet Draft preparation tools
   2.2 Submissions from the IETF
   2.3 Submissions from the IAB
   2.4 Independent submissions
   2.5 Submission from the IRTF
3.  RFC Publication Process
4.  General RFC Editorial Policies
   4.1 Language and character set
   4.2 Non-text files
   4.3 Authors and editors listed on RFC
   4.4 Relation to other RFCs
   4.5 Abbreviations and acronyms in titles and abstracts
   4.6 IANA considerations section
   4.7 Security considerations section
   4.8 References section
   4.9 Author's address section
   4.10 Titles for non-IETF RFCs
5.  Formatting Requirements for RFCs
   5.1 Line width
   5.2 Page height
6.  Suggestions for Input to the RFC Editor
   6.1 Protocol data definitions
   6.2 Examples
   6.3 Pseudocode and formal languages in RFCs
   6.4 The abstract and the introduction
   6.5 The contributors and acknowledgements sections
   6.6 Appendixes
   6.7 General suggestions
7.  Security Considerations
8.  References
   8.1 Normative references
   8.2 Informative references

1.  Introduction

This document provides information to authors who are writing Internet
Drafts which are intended to become Request for Comments (RFC)
documents.  It includes requirements for and suggestions for the format
and content of the input to the RFC process.

Although this document describes all of the formatting and many of the
content requirements, it cannot be a complete discussion of the RFC
process because it relies on other documents, particularly other RFCs,
which may change or be obsoleted at different times.  The reader must
also read all of the documents listed in the normative references
section.  Note in particular that [CONTR-RIGHTS] and [IPR-TECH] specify
boilerplate text that must appear in all Internet Drafts and RFCs.

The RFC Editor maintains extensive information on the RFC process at its
web site, <http://www.rfc-editor.org>.  The RFC Editor can be reached by
email at rfc-editor@rfc-editor.org.

1.1  Acknowledgments

This document is based on contributions collected over many years.
Major contributors include Jon Postel, Joyce Reynolds, Robert Braden,
Robert Shirley, and John Klensin.

2.  The Precursor to RFCs: Internet Drafts

To be considered for publication as an RFC, a document must first be
submitted as an Internet-Draft (often called an "I-D") as described in
[STANDARDS-PROCESS].  This ensures an opportunity for feedback from
members of the Internet community and from the IESG.  The Internet Draft
must include boilerplate text that allows RFC publication (see
"Guidelines to Authors of Internet-Drafts" [ID-AUTHORS]).

The submission and review procedures for RFCs depend upon the document's
source.  RFC submissions may come from the IETF, from the IAB, from
individuals, or from the Internet Research Task Force (IRTF).

2.1 Internet Draft preparation tools

Authors have found various useful tools for preparing this text in the
format required by RFCs and Internet Drafts.  More complete and
up-to-date information on such tools, including templates for some of
the tools, is available from the RFC Editor's web site.

The most popular tool for creating Internet Drafts is the XML DTD for
RFCs described in [RFC-XML] and a tool to format RFCs from XML source.
You can edit an XML file and either process it using the tool, or submit
the XML to a web site that will produce a text version and an HTML
version for you. There is also an XML-to-nroff translator suitable for
creating RFC text. More information on this tool is referenced from the
RFC Editor's web site.

Other tools include:

nroff, groff -- The nroff and groff programs are available on most
popular computer operating platforms.  These programs use directives in
the text to control the formatting.  The RFC Editor, in particular, uses
nroff for final RFC formatting.

Microsoft Word -- [RFC-WORD] describes in detail how to configure Word to
produce an ASCII text file in Internet Draft format.  Note that the
template files are suitable only for fairly simple text formatting; they
may be incompatible with the more advanced features of Word.

LaTeX -- LaTeX is widely used for text preparation in many academic
environments.  LaTeX in general does not produce plain ASCII text in the
RFC format, but there are tools that translate LaTeX to nroff.

2.2 Submissions from the IETF

RFCs originating in the IETF are submitted to the RFC Editor by the
IESG.  The IESG considers them as described in [IESG-CHARTER].  These
IESG submissions are transmitted to the RFC Editor through official
"Protocol Action" messages, which are also recorded at the IETF web
site. Submissions from the IESG may be in any of the possible categories
for RFCs (Standards Track, Best Current Practice, Experimental,
Informational, or Historic.)

As described in [IESG-CHARTER], an Internet Draft intended for either
the Standards Track or Best Current Practice category must first be
submitted to the IESG for approval.  If the IESG approves of the
document, it will submit the document to the RFC Editor.

If the IESG requests, the RFC Editor will add an "IESG Note" to a
published RFC, to provide clarification or guidance to readers, as
described in [IESG-CHARTER].

Internet Drafts submitted from the IETF have some requirements that
allow RFC publication, described in [ID-AUTHORS]. These requirements are
beyond the minimum needed to get an Internet Draft published.

2.3 Submissions from the IAB

The IAB may submit documents directly to the RFC Editor for publication
as RFCs in the Informational or Experimental category, without IESG
approval or review.  This is described at [IAB-SUBMISSION].

2.4 Independent submissions

Individuals may submit documents directly to the RFC Editor for
publication as RFCs in the Experimental or Informational category.  The
RFC Editor reviews each such "independent submission" for relevancy and
appropriateness.  The RFC Editor may require updates to the Internet
Draft, at its discretion, sometimes through several iterations, until an
acceptable submission document is achieved.

To maintain the integrity of the RFC document series and to avoid
wasting scarce publication resources, the RFC Editor may reject an
independent submission because its content is uninteresting or
irrelevant, or because its editorial quality is unacceptable.  The RFC
Editor will attempt to explain as clearly and completely as possible the
reasons for rejection.  The RFC Editor may consult individuals expert in
the field.

After (and if) the RFC Editor has determined that an independent
submission is acceptable, the document is passed to the IESG for review
for conflict with work in progress in the IETF, as described in

In general, the RFC Editor is charged with the final decision about
publication of an independent submission.

2.5 Submission from the IRTF

RFC submissions from IRTF members are normally treated as independent

3.  RFC Publication Process

The RFC Editor makes many editing and formatting changes to documents
before they become RFCs, based on the RFC Editor's policies.  The goal
of these policies is to make the RFC series the most useful to the
Internet community.  For example, the RFC Editor controls the content of
the header on the first page which describes the publication date,
status, and its relation to other RFCs. Another example is that the RFC
Editor will run every MIB through a MIB checker before publication.

The RFC Editor normally starts with just the Internet Draft. If the
authors of the draft also have the draft in a different format, that is
often useful to the RFC Editor and should be sent to them at the time
that the Internet Draft enters the RFC Editor queue. For example, if one
of the formatting tools described in section 7 is used, the input to
that tool may save the RFC Editor time in doing the final formatting.

An Internet Draft that is submitted to the RFC Editor enters the RFC
Editor's publication queue; the queue is viewable at the RFC Editor Web
site.  The document remains in the publication queue until it is
published as an RFC, unless either the author withdraws it, the author
is very unresponsive in making requested updates, or the document is an
independent submission that is deemed unacceptable by the RFC Editor.

The RFC Editor ensures that the document follows the editorial rules
described later in this document.  The RFC Editor may make editorial
changes to clarify readability and to provide a uniform style and format
consistent with other RFCs.  For example, the RFC Editor will often
generate a table of contents for the document.  If additional work is
required to satisfy to bring the RFC up to publication quality, the
document might be returned to the author or to the IESG for additional

When editing of the document is complete, the RFC Editor sends email to
the authors suggesting that the authors review the revised document
carefully.  This step is the last chance for the author to make sure
that the RFC Editor has not changed the technical meaning of the
document during the RFC Editor's processing.  Each listed author or
editor must reply to the RFC Editor in email that he or she approves of
the formatting and editorial changes made by the RFC Editor.  In some
cases, the RFC Editor needs to make further changes to the document,
such as making additional formatting changes or correcting some of the
content. All requests for changes and corrections are discussed with the
RFC Editor in email.  (This step was historically called the "Authors'
48 Hours" period, although there is now no time limit on the step.)

In practice, the editorial process among the IESG, the RFC Editor, and
the author(s) can be lengthy and convoluted, and the time spent in the
RFC Editor's queue can vary greatly.  Sometimes problems are found that
require document revisions by the authors.  These revisions may require
the publication of another Internet-Draft, and the result must be re-
reviewed.  Publication may be held up awaiting IANA assignments, or in
order to synchronize the publication of related RFCs.

RFC numbers are usually not assigned until very late in the editorial
process.  Requests for early assignment of an RFC number are generally
denied unless they originate from the IAB or the IESG.

4.  General RFC Editorial Policies

4.1 Language and character set

The IETF is an international organization with active participants from
dozens of countries, languages, and cultures, and it is very important
that all participants be able to read the standards that it produces.
Because of this, all RFCs must be written in the English language.

At the current time, all RFCs only use the US-ASCII character set, even
for such things as author's names and addresses.  This also means that
all artwork in RFCs must be done in ASCII art.  This topic gets
revisited in the IETF on a regular basis, usually with no new issues
being presented during the debate.

4.2 Non-text files

In a small number of cases, document authors provide secondary or
alternative versions in PostScript and/or PDF because of a need for
diagrams and graphs that cannot possibly be rendered in ASCII plain
text.  RFCs published this way have often been not as useful as those
only in plain ASCII because many people do not know to retrieve the
alternate versions, and also because not all PostScript or PDF files
display well on all devices.  Thus, most authors try very hard to get
their artwork to work as ASCII art.  If you intend to publish an RFC
using a secondary version, contact the RFC Editor ahead of time about
their PostScript and PDF requirements.

4.3 Authors and editors listed on RFC

The copyright rules governing RFC publication [CONTR-RIGHTS] require
that an RFC must "[acknowledge] all major Contributors.  A major
Contributor is any person who has materially or substantially
contributed to the [RFC]." The Contributors and Acknowledgment sections
of RFCs fulfill this objective.

The RFC Editor proposed, and the IESG ratified, a policy of limiting the
number of authors listed in the first page header of an RFC.  That
policy is:

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

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
sign-off from all listed authors.

(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

(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

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

4.4 Relation to other RFCs

The RFC Editor may add an indication of the relation of a new RFC to
earlier RFCs. Sometimes an RFC adds information on a topic discussed in
a previous RFC or completely replaces an earlier RFC.  Two terms are
used for these cases: "updates" and "obsoletes", respectively.

"Updates" specifies an earlier document whose contents are modified or
augmented by the new document.  The new document cannot be used alone,
it can only be used in conjunction with the earlier document.

"Obsoletes" specifies an earlier document that is replaced by the new
document.  The new document can be used alone as a replacement for the
obsoleted document.  The new document may contain revised information or
all of the same information plus some new information, however extensive
or brief that new information may be.

4.5 Abbreviations and acronyms in titles and abstracts

The RFC Editor will often expand abbreviations and acronyms used in the
title and/or abstract of an RFC that is about to be published.  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.  Some cases are
marginal and the decision on expansion may depend upon the specific

It is often helpful to follow the expansion with the parenthesized
abbreviation, such as "Encoding Rules for the Common Routing
Encapsulation Extension Protocol (CREEP)".

The RFC Editor will make the final judgment on abbreviation and acronym
expansion in titles and abstracts, weighing obscurity against

4.6 IANA considerations section

Many RFCs define protocol specifications that require the assignment of
values to protocol parameters, and some define new parameter fields.
Assignment of these parameter values is often (and sometimes must be)
deferred until publication of the defining RFC.  The IANA and the RFC
Editor collaborate closely to ensure that all required parameters are
assigned and entered into the final RFC text.  The process for this is
described in [IANA-CONS].

Even if the document has no IANA considerations, it is a good idea
to have a section that says so explicitly. The RFC Editor can decide
whether or not to remove this section at the time of publication.

4.7 Security considerations section

Most RFCs require a security considerations section that describes any
issues that affect security on the Internet.  See [SEC-CONS] for more
information on creating a security consideration section. Even if
there are no security considerations for the Internet (such as in
this document), this section must be present.

4.8 References section

An RFC will generally contain bibliographic references to other
documents, and the body will contain citations to these references.  If
there are both normative and informative references, they must be
clearly separated in sub-sections of the references section in the

There are many styles for references, and the RFCs have one of their
own.  Please follow the reference style used in recent RFCs; in
particular, see the Reference section of this RFC for an example.  The
RFC Editor may change the style used in the references during the
editing phase.

There is no required format for a citation to a reference.  It is common
to enclose citations in square brackets, as is exemplified in this
document.  The naming scheme for citations is up to the authors.  Some
authors prefer citations that name the documents (such as "RFC2119" and
"TCP-OPTIONS"), while others prefer citations that are by author and
year (such as "Pos92" and "IEEE97a").  Numbered citations are often
difficult for readers because the reference lists in RFCs are split into
normative and informative references.

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 document, or whose technology must be present for the technology in
the new RFC to work.  An informative reference provides additional,
non-essential information to the reader.  For example, an informative
reference might provide background or historical information.  Material
in an informative reference is not required to implement the technology
in the RFC.

The distinction between normative and informative references is often
important.  The IETF standards process and the RFC Editor publication
process need to know whether a reference to a work in progress is
normative.  A standards-track RFC cannot be published until all of the
documents that it lists as normative references have been published.  In
practice, this often results in the simultaneous publication of a group
of interrelated RFCs.

The use of URLs as references in RFCs is discouraged except in cases
where the URL is widely believed to be stable for many years or decades,
and where there is no other useful reference.  References to long-lived
files on ietf.org and rfc-editor.org are generally acceptable.

Informative references to Internet Drafts are allowed, but should
include the authors names, the title of the draft, the beginning part of
the Internet Draft file name, and the phrase "work in progress".  For
instance, a reference might look like:

   Smith, C., "The TLA Expansion Algorithm", draft-smith-tla-expansion,
   work in progress

4.9 Author's address section

The author's address section, which is required for all RFCs, gives the
name(s) and some contact information for the author(s) who are listed in
the first-page header.  Contact information must include at least a
postal address, a telephone number, and/or a long-lived email address
(only one of these is needed).  The purpose of this section is to
unambiguously define the identity of the author(s) and/or
contributor(s), such as "the John Smith who works for FooBar Systems".
It also provides contact information for future readers who have
questions or comments.

4.10 Titles for non-IETF RFCs

RFCs that document a particular company's private protocol must bear a
title of the form "XYZZY's ... Protocol" (where XYZZY is the company's
name). This will clearly differentiate it from an IETF product.

5.  Formatting Requirements for RFCs

The RFC Editor will use text formatting tools to change the Internet
Draft that is submitted to the RFC Editor into the final text RFC.
Because of this, the formatting of the document may change radically.
Most of these transformations are of no concern to the document author
and, in fact, are out of the author's control.  A few of the changes,
however, are relevant to authors because it may affect the technical
content of the final RFC.  This section covers those requirements.

5.1 Line width

Each line of the final RFC will be no more than 72 characters wide (plus
an end-of-line character).  This means that all examples in the Internet
Draft from which the RFC Editor is working must have all lines
restricted to 72 characters with no exceptions.

5.2 Page height

RFC pages have a usable body size of 50 lines (the remaining lines on
the page are reserved for headers and footers).  This means that
examples that are longer than 50 lines will be split across multiple

6.  Suggestions for Input to the RFC Editor

6.1 Protocol data definitions

Many years ago, the RFC series adopted a pictorial approach to
representing data structures such as protocol headers.  Furthermore, the
research community adopted a "big-endian" convention in which the bits
and bytes are shown in network byte order, byte zero is the first byte
shown, and bit zero is the most significant bit in a word or a field.

For example, RFC 791 contains the following definition of the IP header

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|Version|  IHL  |Type of Service|          Total Length         |
|         Identification        |Flags|      Fragment Offset    |
|  Time to Live |    Protocol   |         Header Checksum       |
|                       Source Address                          |
|                    Destination Address                        |
|                    Options                    |    Padding    |

6.2 Examples

DNS names that as used as generic examples in RFCs should use the
particular examples defined in [RESERVED-DNS].  IPv4 addresses in
generic examples should be from the range, as described in
[IPV4-ADDR]. IPv6 addresses in generic examples should be from the range
2001:DB8::/32, as described in [IPV6-ADDR].

6.3 Pseudocode and formal languages in RFCs

The IESG has issued guidelines ([FORMAL-LANGS]) on using pseudocode and
formal languages such as ASN.1 and ABNF in RFCs. It covers topics such
how normative the pseudocode or formal language can be, and how to word
such references.

6.4 The abstract and the introduction

Every RFC must begin with an abstract.  An abstract of more than 20
lines is generally not acceptable.  The abstract 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.

A satisfactory abstract can often be constructed from a summary of some
of the material within the Introduction section.  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 generally not
contain citations. Abbreviations appearing in the abstract should
generally be expanded in parentheses.

Each RFC should have an Introduction section that (among other things)
explains the motivation for the RFC.  If appropriate, the introduction
should describe the applicability of the document, such as whether it
specifies a protocol, provides a discussion of some problem, is simply
of interest to the Internet community, or provides a status report on
some activity. The introduction must be the first numbered section.

6.5 The contributors and acknowledgements sections

The contributors section is an optional section lists those contributors
who deserve significant credit for the document.  When a long author
list is replaced by a single editor in the front page header, the
displaced authors can be properly and fully acknowledged in the
contributors section. The contributors section may include brief
statements about the nature of particular contributions ("Sam
contributed section 3") and it may also include affiliations of listed

An acknowledgements section may be used instead of, or in addition to, a
contributors section, when appropriate.

6.6 Appendixes

Many RFCs have appendices, some of which may be very extensive.  Common
practice is to position appendixes at the very end of a document, after
the references.  However, some RFCs have large and dense appendix
sections for technical details which are actually an integral part of
the document.  In such documents, it can be difficult to locate the
references, and therefore it may be better to put the references after
the appendixes.

6.7 General suggestions

Use single-spaced text within a paragraph, and one blank line between

When turning in an Internet Draft, do not fill the text with extra
spaces to provide a straight right margin, that is, do not right-justify
the text.

Do not use hyphenation at the right margin to split single words.
However, hyphenated word sequences (e.g., "Internet-Draft") may be split
at the hyphen across successive lines.

When a sentence ended by a period is immediately followed by another
sentence, there should be two blank spaces after the period.

Footnotes are strongly discouraged in RFCs.  If such notes are
necessary, put them at the end of a section, or at the end of the

Cross references within the body of the text must use section numbers
rather than page numbers because the RFC Editor generally adjusts
pagination during formatting.

7.  Security Considerations

This RFC raises no new security issues.

8.  References

8.1 Normative references

[CONTR-RIGHTS] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.

[ID-AUTHORS] IETF, "Guidelines to Authors of Internet Drafts", available
as 1id-guidelines.txt at http://www.ietf.org.

[IESG-CHARTER] Alvestrand, H., "An IESG Charter", RFC 3710, February

[IESG-REVIEW] Alvestrand, H., "The IESG and RFC Editor documents:
Procedures", draft-iesg-rfced-documents, work in progress.

[IPR-TECH] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.

[STANDARDS-PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.

8.2 Informative references

[FORMAL-LANGS] IESG, "Guidance for the use of formal languages in IETF
http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt, October

[IAB-SUBMISSION] IAB, "Process for Publication of IAB RFCs",

[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[IPV4-ADDR] IANA, "Special-Use IPv4 Addresses", RFC 3330, September

[IPV6-ADDR] Huston, G., et. al, "IPv6 Address Prefix Reserved for
Documentation", RFC 3849, July 2004.

[RESERVED-DNS] Eastlake, D. and E. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.

[RFC-WORD] Gahrns, M. and T. Hain, "Using Microsoft Word to create
Internet Drafts and RFCs", RFC 3285, May 2002.

[RFC-XML] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June

[SEC-CONS] Rescorla, E. and B. Korver., "Guidelines for Writing RFC Text
on Security Considerations", BCP 72, RFC 3552, July 2003.

Author's Address

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA  95060

Changes from -00 to -01

- Small editorial changes throughout based on comments from the
rfc-interest mailing list.

- Removed open questions throughout.

- 2.1: Moved the previous section 7 (RFC Tools) to section 2.1, and
expanded on xml2rfc. Renumbered the rest of section 2.

- 2.2: Added paragraph at the end about requirements above those for
turing in Internet Drafts.

- 2.3: Specified where the IAB submission rules are described.

- 4.3: Claified the origin of the number-of-names policy.

- 4.6: Added the second paragraph about empty IANA consideration

- 4.7: Added the last sentence about the security considerations section
being required even if trivial.

- 4.9: Clarified that only one piece of address information is required.

- 4.10: Added this section ("Titles for non-IETF RFCs").

- 6.2: Updated this to point to the correct RFCs for example addresses
for IPv4 and IPv6. Also added those as references.

- 6.4: Shortened the description of citations in abstracts.

- 6.4: Added "The introduction must be the first numbered section.".

- References: Made all reference citations mneumonic.

- Author's address: fixed formatting.

Full Copyright Statement

Copyright (C) The Internet Society (2004).  This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights.  Information on the
ISOC's procedures with respect to rights in ISOC Documents can be found
in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard.  Please address the information to the IETF at

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/