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 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. Abstract 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, . 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 [IESG-REVIEW]. 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 submissions. 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 work. 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 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. 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 title. 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 complexity. 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 document. 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 pages. 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 format. 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 192.0.2.0/24, 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 contributors. 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 paragraphs. 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 document. 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 2004. [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 specifications", http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt, October 2001. [IAB-SUBMISSION] IAB, "Process for Publication of IAB RFCs", http://www.iab.org/documents/docs/iab-rfc-publication-process.html. [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 2002. [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 1999. [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 paul.hoffman@vpnc.org 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 sections. - 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org.