INTERNET-DRAFT J. Reynolds, Editor draft-rfc-editor-rfc2223bis-04.txt R. Braden, Editor Obsoletes: 2223 RFC Editor Category: Best Current Practice 25 February 2003 Expires: August 2003 Instructions to Request for Comments (RFC) Authors Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo provides instructions for authors of Request for Comments (RFC) documents. It specifies RFC editorial policies and formatting requirements, addresses frequently-asked questions, and serves as a model for constructing a properly formatted RFC. RFC Editor Informational [Page 1] Internet-Draft Instructions to RFC Authors 10 Feb 2003 Table of Contents 1. Introduction .................................................. 4 1.1 The RFC Document Series ................................... 4 1.2 The RFC Editor ............................................ 4 1.3 The RFC Publication Process ............................... 5 2. RFC Editorial and Publication Policies ....................... 8 2.1 Immutability .............................................. 8 2.2 Not all RFCs are Standards ................................ 8 2.3 Publication Language ...................................... 8 2.4 Publication Format(s) ..................................... 9 2.5 Consistent Document Style ................................. 10 2.6 Assignment of RFC Numbers ................................. 10 2.7 Normative References ...................................... 10 2.8 URLs in RFCs .............................................. 11 2.9 Titles .................................................... 11 2.10 IANA Considerations ...................................... 12 2.11 Relation to Other RFCs ................................... 12 2.12 Author Listed on RFCs .................................... 13 2.13 April 1 RFCs ............................................. 14 3. General Format Rules for RFCs ................................. 15 3.1 General ASCII Format Rules ................................ 15 3.2 Postscript Format Rules ................................... 18 3.3 Header and Footer Formats ................................. 19 3.4 Protocol Data Definitions ................................. 19 4. Required Sections in an RFC .................................. 20 5. RFC Information and Contacts .................................. 27 Appendix A - RFC Boilerplate ..................................... 28 Appendix B - RFC Preparation Tools ............................... 29 Appendix C - Checklist ........................................... 30 Appendix D - Changes from RFC 2223 ............................... 32 Acknowledgments .................................................. 33 Security Considerations .......................................... 33 Normative References ............................................. 33 Informative References ........................................... 33 Authors' Addresses ............................................... 34 Full Copyright Statement ......................................... 35 RFC Editor Informational [Page 2] Internet-Draft Instructions to RFC Authors 10 Feb 2003 Changes from -03 version 1. Combine sections 1.3.1 and 1.3.2 into one section 1.3.1. 2 Clarify the section ordering rules in section 4. Changes from -02 version 1. Removed old Appendix C (definition of ASCII) and replace it with a reference to RFC 20 [11]. 2 Added new Appendix C, a Checklist. 3 Made a few editorial changes and typo fixes. 4 Clarified that .txt.pdf versions are equally authoritative with .txt versions of RFCs. 5 Stated policy that (nearly) all abbreviations in body of the document must be expanded when first encountered. Changes from -01 version 1. Incorporated new author list guidelines. 2. Clarified rules for hyphenation (Section 3.1 (6)). 3. Added guideline on example URLs (Section 2.8). 4. Clarified that dangling normative references are strictly prohi- bited only for standards-track documents (Section 2.7). RFC Editor Informational [Page 3] Internet-Draft Instructions to RFC Authors 10 Feb 2003 1. Introduction This Request for Comments (RFC) document provides instructions for authors regarding the preparation of RFCs and describes RFC publication policies. For the latest version of this document, see the URL listed in Section 5. 1.1 The RFC Document Series The Requests for Comments documents, commonly known as RFCs, form an archival series of more than 3000 memos about computer communication and packet switching networks. Included prominently in the RFC series are the official technical specifications of the Internet protocol suite, which are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). As a result, RFC publication plays a significant role in the Internet standards process. The RFC series was begun in 1969 as a set of technical and organizational notes of the ARPAnet research community [1]. Since the early 1980s, the series has focused on the development of the Internet and the TCP/IP protocol suite. Memos in the RFC series discuss many aspects of networking, including protocols, procedures, programs, and concepts as well as meeting notes, opinions, and sometimes humor. For more information on the history of the RFC series, see RFC 2555, "30 Years of RFCs" [1]. The RFC numbers provide a single unique address space for locating a particular RFC in the primary RFC index. In addition, secondary indexes have been defined for useful subsets or "sub-series" of the RFCs. There are three sub-series in use: -- FYI (For Your Information) [4], BCP (Best Current Practice) [5], and STD (Standard) [6]. 1.2 The RFC Editor The RFC series is published by the RFC Editor under funding provided by the Internet Society (ISOC). Since 1977, the RFC Editor function has been performed by staff at the Information Sciences Institute of the University of Southern California (USC/ISI). The RFC Editor is responsible for the final editorial review and the publication of RFCs. The RFC Editor also maintains the official RFC archive and the master index files, and makes these accessible via the Web, FTP, and email (see URL in Section 5.) RFC Editor Informational [Page 4] Internet-Draft Instructions to RFC Authors 10 Feb 2003 1.3 The RFC Publication Process A more complete explanation of the RFC publication procedures will be found in RFC 2026 [2]. 1.3.1 RFC Submission and Review Before the RFC Editor considers publication of a document, it must first be submitted as an Internet-Draft (I-D) [1]. This allows feedback from members of the Internet community and the IESG. All RFCs have been I-Ds, but many I-Ds do not become RFCs. Since Internet-Drafts are precursors to RFCs, the rules for formatting Internet-Drafts have been made consistent with the RFC formatting rules presented here. Specific Internet-Draft guidelines are available from the IETF web page. The Internet Draft must include boilerplate that allows RFC publication (see "Guidelines to Authors of Internet-Drafts" [10]). The submission and review procedures for RFCs depend upon the document's source. Submissions come from the IETF or from an individual. o Submission from the IETF RFCs originating in the IETF are submitted to the RFC Editor via the Internet Engineering Steering Group (IESG) after review for technical quality and conformance with IETF procedures. These IESG submissions are transmitted to the RFC Editor via official "Protocol Action" messages that are recorded at the IETF web site. IESG submissions normally originate in working groups; however, the IESG may occasionally accept non-working-group documents into the IETF process. A document submitted by the IESG must have one of the following categories (also called status values): Proposed Standard, Draft Standard, Standard (sometimes referred to as "Full Standard"), BCP (Best Common Practice), Experimental, or Informational. A document with Proposed Standard, Draft Standard, or Standard status is said to be a standards-track document [2]. The IESG may also specify that a document is to become part of the STD or TYI sub-series (Best Common Practice category documents necessarily join the BCP sub- series.) The RFC Editor publishes all documents submitted from the RFC Editor Informational [Page 5] Internet-Draft Instructions to RFC Authors 10 Feb 2003 IESG but reserves the right to discuss any issues it may find in particular documents. o Individual Submissions Individuals can also submit Internet-Drafts directly to the RFC Editor for publication as RFCs. Such individual submissions may be in the Experimental or Informational category. Note: The RFC Editor does not accept independent submissions of standards track documents; all standards track documents must be submitted to the appropriate area directors of the IETF. The RFC Editor reviews each individual submission for editorial issues, including proper English, clarity, completeness, and formatting. Updates will be requested as necessary, perhaps through several iterations, until a document appropriate for publication as an RFC is achieved. To maintain the standards of the RFC document series and to avoid wasting scarce publication resources, the RFC Editor occasionally determines that a submission is not publishable because of its content or its form. Whenever possible, such a decision is made in consultation with appropriate Area Directors of the IESG and/or with independent experts in the field being covered. In any case, the RFC Editor will attempt to explain as clearly and completely as possible the reasons for rejection. The RFC Editor is always hopeful of a miracle -- that a bad document will reemerge as a good document -- and occasionally it even happens! Once the the document is in publishable form, the RFC Editor passes the document to the IESG for review. The IESG reviews each individual submission to ensure it does not conflict with work in progress in the IETF and to ensure its technical quality. When the topic of an individual submission is closely related to an existing IETF Working Group, the IESG may request that the author coordinate with that working group. This may result in the production of a revised memo that eventually emerges from the IETF process as an IETF submission. The IESG may also suggest improvements to the author of the document prior to publication. If the IESG feels that the submitted document is not appropriate material for publication as an RFC, they will so RFC Editor Informational [Page 6] Internet-Draft Instructions to RFC Authors 10 Feb 2003 recommend to the RFC Editor. The RFC Editor may then reject the document, or publish it with an "IESG Position" statement that defines their objections to the document or narrows its scope of applicability. The RFC Editor makes the final decision about publication of individual submissions. 1.3.2 RFC Publication A document that is submitted to the RFC Editor enters the RFC Editor's queue. The queue is publicly accessible at the RFC Editor Web site (Section 5). The RFC remains in the queue until it is published, or until the IESG or the author requests that it be removed. The RFC Editor ensures that the document follows the rules described in this document. The RFC Editor may make editorial changes to clarify readability and to provide a uniform style and format. If significant changes are required to satisfy the rules and/or to bring the RFC up to publication quality, the memo will often be returned to the author for the additional work. When editing of the document is complete, the RFC Editor sends the result to the authors for careful proof-reading. This quality control step is critical to maintaining the quality of RFCs. Although this process is traditionally called the "Authors' 48 Hours" period, the RFC Editor is always willing to give authors reasonable additional time to review the document, and a document will not be published until all its listed authors agree. While it is helpful to have one principal author during the editing process, all listed authors will be considered responsible for the correctness of the final document. 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 Internet Assigned Numbers Authority (IANA) assignments, or in order to synchronize publication with that of related RFCs. RFC Editor Informational [Page 7] Internet-Draft Instructions to RFC Authors 10 Feb 2003 2. RFC Editorial and Publication Policies This section summarizes some general policies governing the publication of RFCs. Individual policies may be modified or new policies added by the RFC Editor and the IESG, before the present document is revised. RFC authors should obtain the latest policy statements (see "News") from the RFC Editor web page. 2.1 Immutability Since the RFCs form an archival series, an RFC cannot be altered once it is published. To change the contents of an RFC, a new RFC must be written that obsoletes the previous one. (Early in the history of RFCs, the Editor did occasionally make small editorial changes after publication, but this led to confusion regarding which version was correct, and it was a slippery slope. To avoid these pitfalls, the never-change rule is now strictly enforced.) Although RFCs are subjected to careful scrutiny by the RFC Editor and the authors before publication, errors do sometimes creep in. For this reason, the RFC Editor strongly recommends that the authors thoroughly review the document during the "authors' 48 hours" period. The RFC Editor maintains an online list of errata for existing RFCs. If you find what you believe to be an error in an RFC, consult the errata page at the RFC Editor web site. If the bug is not listed, please send e-mail to the authors of the document, and CC: the RFC Editor (Section 5.) 2.2 Not all RFCs are Standards Eager salesmen have been known to imply that all RFCs represent official Internet standards. This is false and misleading. While some RFCs are standards track documents, many have the status of Informational or Experimental and do not represent a standard of any kind. Even those documents on the standards track come in three grades -- Proposed Standard, Draft Standard, and Standard -- and only the last is a full standard. 2.3 Publication Language Like the Internet itself, the IETF and the Internet Society are international organizations with representation from all areas of the world. However, English is the primary language in which IETF business is conducted, and English is the official publication language for RFCs. RFC Editor Informational [Page 8] Internet-Draft Instructions to RFC Authors 10 Feb 2003 RFCs submitted for publication are required to meet a reasonable standard for clear and correct English. RFC 2026 specifically allows RFCs to be translated into languages other than English. Repositories may exist for RFCs that have been translated into particular languages. This is highly desirable and useful. However, it is not possible for the RFC Editor to certify that such translations are accurate. Therefore, the function of the RFC Editor, with respect to non-English RFCs, is limited to providing pointers to non-English language RFC repositories. Upon request, the RFC Editor will list any such repository on its Web page. 2.4 Publication Format(s) RFCs are published as ASCII text (.txt) files. However, secondary or alternative versions of an RFC may be provided in PostScript and/or PDF, to allow the inclusion of fancy diagrams and graphs that cannot possibly be rendered in ASCII. The continued use of ASCII text for RFCs, despite the spread of "more modern" printing formats, is intermittently debated by the Internet community. The consensus continues to be that the great advantages of plain ASCII text -- the ability to readily edit, cut-and-paste, and search documents, as well as the ubiquitous availability of tools for these functions -- have made the ASCII choice a clear winner. The ASCII text version is always the official specification, and it must adequately and completely define the technical content. (A very few exceptions have been made over the 30 year history of RFCs, allowing a definitive .ps version with no .txt version.) The primacy of the ASCII version typically requires that the critical diagrams and packet formats be rendered as "ASCII art" in the .txt version. If there is a Postscript and/or PDF version of the document (see Section 2.4), the author should inform the RFC Editor at the time of submission of the ASCII version. For the convenience of those whose operating systems have difficulty supporting simple ASCII text, the RFC Editor also maintains PDF files that are exact facsimiles of the ASCII (.txt) versions. These PDF files, with suffix .txt.pdf, are equally authoritative with the .txt versions. Postscript and PDF versions suffer from a serious flaw: the RFC Editor cannot easily make editorial changes in the source file to RFC Editor Informational [Page 9] Internet-Draft Instructions to RFC Authors 10 Feb 2003 produce a new document in either of these formats. This makes the editorial process somewhat painful for both the author and editor. When a .ps (or .pdf) version is submitted with a .txt version, the RFC Editor will first edit the .txt version. The final form of the .txt version (or, when feasible, the diffs) will be returned to the author. The author must then update the .ps/.pdf files to match, as closely as possible, the content and format of the ASCII .txt file. When the RFC Editor agrees that the .ps/.pdf versions are acceptable, they will be published simultaneously. 2.5 Consistent Document Style The RFC Editor attempts to enforce a consistent style of RFCs. To do this, the RFC Editor may choose to reformat a submitted RFC or ask the author to reformat it. Effort is minimized when the submitted document matches the style of the most recent RFCs. Please read the rules and recommendations that are presented in following sections of this memo and look at some recent RFCs, to adopt an appropriate style. To format most ASCII RFCs for publication, the RFC Editor uses the unix "nroff" program with a very simple set of the formatting commands (or "requests") from the "ms" macro package (see Appendix B). If a memo submitted to be an RFC has been prepared by the author using nroff, it is helpful to make the nroff source available when the document is submitted. When a .ps version is published, the RFC Editor will also publish a corresponding .pdf version by using the 'distill' utility. 2.6 Assignment of RFC Numbers RFC numbers are not assigned until very late in the editorial process to avoid gaps in the RFC number series. Requests for early assignment of an RFC number for use in another forum are generally denied unless they originate from the IAB (Internet Architecture Board) or the IESG. 2.7 Normative 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 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. Material in an informative reference is RFC Editor Informational [Page 10] Internet-Draft Instructions to RFC Authors 10 Feb 2003 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 inter-related RFCs. An RFC must include separate lists of normative and informative references (see Section 4.8 below.) Some standards track document use certain capitalized words ("MUST", "SHOULD", etc.) to specify precise requirement-levels for technical points. BCP 14 (RFC 2119) [3] defines the proper interpretation of these capitalized words in IETF documents. If these words are used and capitalized, RFC 2119 should be cited (as specified in RFC 2119) and included as a normative reference. (It is noted that this is a formal violation of the rules of RFC 2026, since RFC 2119 has BCP category.) 2.8 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" [10], to avoid accidental conflicts with real URLs. 2.9 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 should generally be expanded; the exception is abbreviations that are so common (like TCP, IP, SNMP, FTP, etc.) that every member of the IETF can be expected to recognize them immediately. It is often helpful to follow the expansion with the parenthesized abbreviation, as in RFC Editor Informational [Page 11] Internet-Draft Instructions to RFC Authors 10 Feb 2003 the following example: "Encoding Rules for the Common Routing Encapsulation Extension Protocol (CREEP)" Authors should be aware that the title of an RFC may be subject to policy considerations in addition to the requirement that it provide a concise and technically sound summary of the document contents. For example, at various times in the history of the IETF, the words "Requirements" and "Policies" as well as the phrase "The Directory" have been banned from RFC titles, each for its own reason. RFCs that document a particular company's private protocol must bear a title of the form "XXX's ... Protocol" (where XXX is a company name), to clearly differentiate it from an IETF product. 2.10 IANA Considerations 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. Any RFC that defines a new "namespace" [9] of assigned numbers should include an IANA Considerations section specifying how that space should be administered. See "Guidelines for Writing an IANA Considerations Section in RFCs" [9] for a detailed discussion of the issues to be considered and the contents of this section. 2.11 Relation to other 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. RFC Editor Informational [Page 12] Internet-Draft Instructions to RFC Authors 10 Feb 2003 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. In lists of RFCs and in the RFC-Index (but not on the RFCs themselves) the following are used for older documents that were referred to by Obsoletes or Updates relations in newer documents: Obsoleted-by Used to specify newer document(s) that replace the older document. Updated-by Used to specify newer document(s) that modify or augment the older document. 2.12 Authors Listed on RFC The IESG and IETF have ratified a policy of limiting the number of authors listed in the first page header of 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. 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. (2) An RFC may include a Contributors section, listing those RFC Editor Informational [Page 13] Internet-Draft Instructions to RFC Authors 10 Feb 2003 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 Authors' 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. 2.13 April 1 RFCs Many years ago the RFC Editor established the practice of publishing one or more satire documents on April 1 of each year. Readers should be aware that many of the RFCs bearing the date April 1 are not to be taken seriously. The RFC Editor reviews April 1 RFC submissions for cleverness, humor, and topical association with computer networking, and a few of the best are published. Submissions must be made to the RFC Editor in time for review and publication. Note that in past years the RFC Editor has sometimes published serious documents with April 1 dates. Readers who cannot distinguish satire by reading the text may have a future in marketing. RFC Editor Informational [Page 14] Internet-Draft Instructions to RFC Authors 10 Feb 2003 3. General Format Rules for RFCs The following formatting rules are intentionally incomplete in some details. They attempt to define only what is strictly necessary for uniformity and simplicity (a virtue). Some latitude is allowed to accommodate a broad range of printers, systems, and evolving requirements. The general objective is to create a series of documents that are reasonably uniform and are easy to read, while accommodating a wide range of content. 3.1 General ASCII Format Rules (1) Character code The character code is US-ASCII [11] (also known as ISO 464.IRV). Only the printable ASCII characters and the three control characters CR, LF, and FF are allowed. Notes: CR and LF must be used only as provided in rule (2), and LF must be used only as provided in rule (3). Tab (HT) characters and Backspace (BS) characters are never allowed (hence there can be no underlining; see (4) below). (2) Width Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). This limit includes any left-side indentation. Note: An ASCII RFC is expected to be stored on a file disk using the EOL sequence of that system. For example, MS DOS-based systems use the two-character sequence CR LF (Carriage Return followed by Line Feed), Unix systems use the single character LF for EOL, and EBCDIC systems use the single character NL (New Line). Whenever an RFC is transmitted across the Internet, Internet protocol convention requires that each line of text be followed by the two-character EOL sequence CR LF (Carriage Return followed by Line Feed). A user level protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make the appropriate EOL transformation at each line end. Note that binary transmission of ASCII RFC files can cause the sender's EOL convention to "leak" into the receiver, causing confusion. RFC Editor Informational [Page 15] Internet-Draft Instructions to RFC Authors 10 Feb 2003 (3) Height Each page must be limited to 58 lines followed by a Form Feed (FF) character, followed by an EOL sequence. The 58 line limit includes the headers and footers specified below. All pages, except perhaps the first and last, should have the same number of lines when headers and footers are included. That is, footers should not "bounce" from page to page. Note: The maximum line count includes blank lines. However, the first line will normally be the first header line and the last line will be the final footer line; that is, it will not begin or end with a blank line. Note: 58 lines is the maximum; 55 is more commonly used and may actually produce more readable formatting. The recommended page formatting parameters (see Appendix B) produce 55 line pages on many printers, for example. Note: The effect of the Height rule is that the following character sequence will be used: FF ... As transmitted across the Internet as ASCII text, the character sequence is: CR LF FF CR LF CR LF ... Finally, note that the sequence FF CR LF has an ambiguous effect: on some printers, the FF implies an EOL, so this may produce a blank line; on other printers it will produce no blank line. The number 58 and this sequence were designed to render this ambiguity unimportant, assuming the (once predominant) printer standard of 60 lines per page. (4) No Overstriking No overstriking (or underlining) is allowed. RFC Editor Informational [Page 16] Internet-Draft Instructions to RFC Authors 10 Feb 2003 (5) No Filling Do not fill the text with extra spaces to provide a straight right margin. Do not right justify the text. (6) No Hyphenation Do not use hyphenation at the right margin to split existing words. However, hyphenated word sequences (e.g., "Internet- Draft") may be split at the hyphen across successive lines. Note: There are good reasons why the right page margin is required to be "ragged", and why hyphenation of words at the right margin is prohibited. Studies have shown that text is harder to read when fixed-size spaces are inserted to adjust the right margins, regardless of which font is used or how smoothly the blank filler is inserted. In addition, when technical text in a fixed- width font is hyphenated at the right margin, the printed result is not only less readable but also ugly. (7) Spaces at the End of a Sentence When a sentence ended by a period is immediately followed by another sentence, there should be two blank spaces after the period. This rule provides clarity when an RFC is displayed or printed with a fixed-width font. (8) Footnotes Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document. (9) Line Spacing Use single-spaced text within a paragraph, and one blank line between paragraphs. (10) Page Numbering Pages must be numbered consecutively, starting from 1 on the first (cover) page. (11) Headers and Footers RFCs must have running headers and footers, as defined below in Section 3.3. The headers and footers must be separated from the body by at least one and preferably two blank lines. RFC Editor Informational [Page 17] Internet-Draft Instructions to RFC Authors 10 Feb 2003 (12) Indentation Successive indentation of sub-subsections (as in this document, for example) is recommended but not required. Experience has shown that indentation by multiples of 3 columns works well. In any case, the careful use of indentation can make a very great improvement in the readability of a document. 3.2 PostScript Format Rules (1p) Standard page size is 8 1/2 by 11 inches. (2p) Leave a margin of 1 inch on all sides (top, bottom, left, and right). (3p) Main text should have a point size of no less than 10 points with a line spacing of 12 points. (4p) Footnotes and graph notations no smaller than 8 points with a line spacing of 9.6 points. (5p) Three fonts are acceptable: Helvetica, Times Roman, and Courier, plus their bold-face and italic versions. These are the three standard fonts on most PostScript printers. (6p) Prepare diagrams and images based on lowest common denominator PostScript. Consider common PostScript printer functionality and memory requirements. (7p) The following PostScript commands should not be used: initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice or renderbands. Note that the number of pages in a document and the page numbers on which various sections fall will likely differ between the ASCII and the PostScript versions of an RFC. Thus, cross references in the text by section number usually are easier to keep consistent than cross references by page number. RFC Editor Informational [Page 18] Internet-Draft Instructions to RFC Authors 10 Feb 2003 3.3 Header and Footer Formats RFCs must include running headers and footers that obey the following rules. o Running Headers The running header in one line (on page 2 and all subsequent pages) has the RFC number on the left (RFC nnnn), the title (possibly shortened) in the center, and the publication date (Month Year) on the right. o Running Footers All pages contain a one-line running footer, with the author's last name on the left, the category centered, and the page number on the right ([Page nn]). If there are two authors, the form "name & name" may be used; for more than two authors, use the form "name, et al." 3.4 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 [8]. For example, RFC 791 contains the following definition of the IP header format. We strongly recommend that a new RFC follow the same formatting conventions, which have been found to work well. Any alternative style must meet the same level of clarity, readability, and lack of ambiguity. An author wishing to use an alternative style should discuss it with the RFC Editor. RFC Editor Informational [Page 19] Internet-Draft Instructions to RFC Authors 10 Feb 2003 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header 4. Sections in an RFC An RFC may contain the following sections. Some of these are optional, as noted. When they are present, the generally recommended order is shown in the following list. However, the order of items marked "floating" may vary according to the desire of the authors and the particular circumstances. 1. First-page header 2. Status of this Memo 3. Copyright Notice 4. IESG Note [optional -- when required] 5. Abstract 6. Table of Contents [optional for small documents] 7. Body of memo 8. Contributors [optional, floating] 9. Acknowledgments [optional, floating] 10. Security Considerations [floating] 11. IANA Considerations [floating] 12. References [optional, floating] 13. Authors' Address 14. Full Copyright Statement The rules for each of these sections are described below in corresponding subsections. The Body of the memo will normally contain section numbers. Sections preceding the Body must not have section numbers; section numbers are optional for sections following the Body. RFC Editor Informational [Page 20] Internet-Draft Instructions to RFC Authors 10 Feb 2003 4.1. First-Page Header Please see the front page of this memo for an example of the front page heading. On the first page there is no running header. The top of the first page has the following items left justified: "Network Working Group" This traditional title must be left-justified on the first line of the heading. It denoted the ARPANET research group that founded the RFC series. "Request for Comments: nnnn" Identifies this as an RFC and specifies the number, left- justified on the second line. The actual number is filled in at the last moment prior to publication by the RFC Editor. "BCP: nn" or "FYI: nn" or "STD: nn" One of these optional left-justified items indicates the sub- series number, if the RFC is a member of a sub-series. "Updates: nnnn" or "Updates: nnnn, ..., nnnn" Optional left-justified field, containing an RFC number or a comma-separated list of RFC numbers that are updated by this RFC. See Section 5. "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn" Optional left-justified field, containing an RFC number or a comma-separated list of RFC numbers that are obsoleted by this RFC. See Section 5. "Category: xxxxxxxxx" Required left-justified field specifying the category (i.e., status) of this RFC. Here xxxxxxxx, the document status (see RFC 2026 [2]), may be one of: Standards Track, Best Current Practice, Informational, or Experimental. The "Standards Track" category indicates that the status is one of: Proposed Standard, Draft Standard, or Standard. The actual status may be found in STD 1, "Official Internet Standards", or from the RFC Editor web site. RFC Editor Informational [Page 21] Internet-Draft Instructions to RFC Authors 10 Feb 2003 The following information appears right-justified in the header: Author The author's name (first initial and last name only), right- justified on the first line of the heading. Organization The author's organization, indicated on the line following the Author name. For multiple authors, each author name appears right-justified on its own line, followed by that author's organization. When more than one author has the same organization, the organization can be "factored out" and appear only once following the corresponding Author lines. However, such factoring is not necessary if it results in an unacceptable reordering of author lines. The total number of authors is generally limited; see Section 2.12. Date The month and year of the RFC Publication, right-justified on the line after the last Organization line. The title appears, centered, below the rest of the heading, preceded and followed by at least one blank line. Periods ("dots") are not allowed in the title. The title should be carefully chosen to accurately reflect the contents of the document. See also Section 2.9. 4.2. Status of this Memo Each RFC must include on its first page the "Status of this Memo" section that contains two elements: (1) a paragraph describing the type of the RFC, and (2) the distribution statement. The required contents of this section will be found in Appendix A. 4.3 Copyright Notice RFC Editor Informational [Page 22] Internet-Draft Instructions to RFC Authors 10 Feb 2003 The Copyright Notice section consists of the statement, "Copyright (C) The Internet Society (date). All Rights Reserved." and is required. The Full Copyright Statement described in Section 4.12 must also appear at the end of the document. 4.4 IESG Note This optional section will appear when the IESG requires a warning or clarifying message on an RFC. 4.5 Abstract Every RFC must have an Abstract section following the Copyright notice. An Abstract will typically be 5-10 lines, but 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. Mnemonics appearing in the Abstract should generally be expanded in parentheses. There is a small set of reasonable exceptions to this rule; for example, readers do not need to be reminded of the meaning of the mnemonics "IP" or "TCP" or "MIB". In the end this is a judgment call, but please err on the side of explicitness. 4.6 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. RFC Editor Informational [Page 23] Internet-Draft Instructions to RFC Authors 10 Feb 2003 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 4.7 Body of Memo Following the Table of Contents, if any, comes the body of the memo. Depending upon the length of the TOC, a judicious page break can improve readability. Each RFC should have an Introduction section that (among other things) explains the motivation for the RFC and (if appropriate) describes the applicability of the document, e.g., 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. Many RFC documents have appendices, some of which may be very extensive. It is often customary in academic publications to place appendices at the very end, after references. This is permissible in an RFC, but we recommend that an author place any appendices at the end of the body of the text and before the references. This is appropriate because the references of an RFC may be normative and should therefore be clearly accessible at the very end of the document. All abbreviations that are used in the body must be expanded the first time they occur. A few exceptions will be made for abbreviations that are so well known that expansion is unnecessary, e.g., TCP or IP. RFC Editor Informational [Page 24] Internet-Draft Instructions to RFC Authors 10 Feb 2003 See [15} for IESG guidance on the use of formal languages in RFCs. 4.8 Contributors Section This 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. At the discretion of the author(s), contact addresses (see Authors' Address section below) may also be included in the Contributors section, for those contributors whose knowledge makes them useful future contacts for information about the RFC. The Contributors and Acknowledgment sections are floating and optional. If they appear, they must appear later than the Abstract section and earlier than the Authors' Address section. 4.9 Acknowledgment Section This optional section may be used instead of, or in addition to, a Contributors section, when appropriate. 4.10 Security Considerations Section All RFCs must contain a section near the end of the document that discusses the security considerations of the specification that are the main topic of the RFC. The Security and IANA Considerations sections are floating; they may occur in the body or after, but before the Authors' Address sections. 4.11 IANA Considerations Section Any RFC that defines a new "namespace" [9] of assigned numbers should include an IANA Considerations section specifying how that space should be administered; see Section 2.10 above and [9]. 4.12 References Section Nearly all RFCs contain citations to other documents, listed near the end of the RFC. There are many styles for references, and the RFCs have one of their own. Please follow the reference style RFC Editor Informational [Page 25] Internet-Draft Instructions to RFC Authors 10 Feb 2003 used in recent RFCs; in particular, see the Reference section of this RFC for an example. For a reference to an RFC that has been assigned an STD, BCP, or FYI subseries number, that subseries number must be included in the reference. Reference lists must indicate whether each reference is normative or informative. For example, if both normative and informative references are included, then the reference section should be split into two sections, e.g.: s. Normative References xxx ... xxx s+1. Informative References xxx ... xxx Non-normative references to Internet-Drafts are allowed, but they must take the following restricted form: the author(s), the title, and the phrase "Work in Progress", for example: [6] Doe, J., "The Deployment of IPv6", Work in Progress. The use of URLs in references in RFCs is discouraged, because URLs are often not stable references. Exceptions will be made in certain cases where the World Wide Web is demonstrably the most stable reference available. The References sections are floating. 4.13 Authors' Address Section This required section gives the name(s) and contact information for the author(s) listed in the first-page header. Contact information must include at least one, and ideally would include all, of a postal address, a telephone number and/or FAX number, and a long-lived email address. 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. Note that some professional societies offer long-lived RFC Editor Informational [Page 26] Internet-Draft Instructions to RFC Authors 10 Feb 2003 email addresses for their members. 4.14 Full Copyright Statement Per Section 10.4(C) of BCP 9, RFC 2026 [2], "The following copyright notice and disclaimer shall be included in all ISOC standards-related documentation." This is the "Full Copyright Statement", whose text will be found at the end of this RFC as well as in RFC 2026. A specific request from the IAB is required before the RFC Editor can include a dual copyright, or for any other variation of the standard ISOC copyright notice. 5. RFC Information and Contacts ************************************************************ * * * RFC Editor Email: rfc-editor@rfc-editor.org * * * * * * RFC Editor URL: http://www.rfc-editor.org * * * * * ************************************************************ In particular, authors should look for the latest version of this document at the URL listed above. RFC publication announcements are distributed via two mailing lists: the "IETF-Announce" list and the "RFC-DIST" list. The IETF-Announce list announces publication of both Internet Drafts and RFCs; instructions for subscription and unsubscription to this list are available on the IETF web site www.ietf.org. The RFC-DIST list announces only RFC publication; subscription information is available at the RFC Editor URL listed above. RFC readers should be aware that the many mirrors of RFCs and RFC indexes that appear on other sites vary a great deal in reliability. Consulting the official RFC-Editor site listed above is recommended. RFC Editor Informational [Page 27] Internet-Draft Instructions to RFC Authors 10 Feb 2003 APPENDIX A: RFC Boilerplate This Appendix defines standard wording required in every RFC. Standards Track "This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited." Best Current Practice "This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited." Experimental "This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited." Informational "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited." RFC Editor Informational [Page 28] Internet-Draft Instructions to RFC Authors 10 Feb 2003 APPENDIX B: RFC Preparation Tools As indicated earlier, the primary submission format for RFCs is ASCII text. Authors have found various tools to be useful for preparing this text in the format required by RFCs and Internet-Drafts. For more complete and uptodate information, see the RFC Editor Web page. This Appendix surveys some of the possibilities. nroff, groff The nroff program is widely available for Unix systems, while its freeware equivalent groff is available for an even wider range of platforms, including Windows. These programs use directives in the text to control the formatting. The RFC Editor, in particular, uses nroff for final RFC formatting. A template is available as 2-nroff.template. XML An XML DTD for RFCs has been developed [7]. There is also an XML-to-nroff translator suitable for creating RFC text. RFC Editor experience with this procedure is limited, but it has worked very well. Microsoft Word Microsoft Word is an important example of a WYSIWYG editor. RFC 3285 [14] describes in detail how to configure Word to produce an ASCII text file in RFC format. A version of this document as a Word file (2-Word.template.rtf) can be used as a template file to initialize this configuration for entering and displaying RFCs. There is also a DOS executable (crlf.exe) for a post- processor to establish RFC end-of-line conventions in the Word output file. LaTeX LaTeX is widely used for text preparation in many academic environments. A convenient LaTex template is available as 2- latex.template. Latex in general does not produce plain ASCII text in the RFC format, but there are tools that translate LaTex to nroff; see the RFC Editor web page. RFC Editor Informational [Page 29] Internet-Draft Instructions to RFC Authors 10 Feb 2003 APPENDIX C: Checklist Topic | Section of | this doc. ___________________________________________________________|___________ A. Editorial/Content Issues | | 1. Reasonably clear and correct English | 2.3 > Also, run spell checker | | 2. All abbreviations (with a few exceptions) are | 4.7 expanded when they first appear. | | 3. References: | 2.7, 4.8 > Complete and current | > Normative and Informative listed separately | 2.7 > Internet Drafts correctly referenced | 4.8 | 4. All URLs are suspect: they must be stable. | 2.8 | 5. Title: | 2.9 > Descriptive and not misleading. | > No suspect words, e.g., Proposed, Standard, | Requirements, Policy. | > Abbreviations expanded | | 6. Author list not too long | 2.12 | 7. Category field correct | 4.1 | B. Basic Formatting | 3.1 | 1. Only printable ASCII characters | 3.1(1), | 3.1(4) 2. No lines exceeding 72 characters | 3.1(2) [This is especially important for "as is" tables | and figures, which cannot be easily reformatted by| the RFC Editor.] | | 3. Maximum page size is 58 lines. [RFC Editor may | 3.1(3) re-paginate, but this limit may be an issue for | large "as is" tables and figures. | | 4. Must be ragged-right | 3.1(5) | 5. No hyphenation at end of line | 3.1(6) | 6. Two blanks after periods ending sentences | 3.1(7) RFC Editor Informational [Page 30] Internet-Draft Instructions to RFC Authors 10 Feb 2003 | 7. No footnotes (end notes OK) | 3.1(8) | 8. Line spacing OK | 3.1(9) | 9. Pages numbered | 3.1(10) | 10. Running headers and footers OK | 3.3 | 11. Formatted for easy reading; consistent spacing and | indentation | 3.1(12) | 12. "Big-Endian" data definitions | 3.4 | C. Required Sections | 4 | 1. Status of Memo | 4.2 > Choose text appropriate to Category | App. B | 2. Copyright Notice | 4.3 | 3. Abstract | 4.5 > Clarity and content OK | > Reasonable length | > All abbreviations expanded | > No references | > Unnumbered section | | 4. Security Considerations | 4.9 | 5. Authors' Addresses | 4.13 | B. Optional Sections | 4 | 1. IESG Note, if requested. | 4.4 | 2. Table of Contents | 4.6 > Must be present in large document | | 3. IANA Considerations, if needed | 4.10 4. Contributors and/or Acknowledgments | 4.11, 4.12 RFC Editor Informational [Page 31] Internet-Draft Instructions to RFC Authors 10 Feb 2003 APPENDIX D: Changes from RFC 2223 o Section 1: Introduction This section was completely rewritten, using material from several sections of RFC 2223 and bringing the discussion into conformance with RFC 2026. o Section 2: RFC Editorial and Publication Policies This section combines material from several sections of RFC 2223. New material is included about the RFC Editor errata page, normative references, URLs, titles, RFC number pre-assignment, author lists, and IANA Considerations. There are four changes of procedure: (1) publication of an RFC in both ASCII and Postscript versions now requires that both be published simultaneously, (2) all listed authors must give approval during the "Authors' 48 Hour" process, (3) long author lists are generally prohibited, and (4) a Contributors section is defined as an alternative to long author lists. o Section 3: General Format Rules This section is expanded with much additional explanatory material. For example: (1) The requirement for printable ASCII characters is stated, and the use of CR, LF, and FF is clarified. (2) The requirement for page numbers in specified. (3) The requirement for running headers and footers is specified. o Section 4: Required Sections in an RFC This section is reorganized to cover all the required sections of an RFC in order. It adds the current conventions for formatting multiple author names and organizations, and it defines section ordering more precisely. This section describes four major changes in RFC formatting. (1) The style and contents of the Abstract section are more completely specified, in order to make RFC abstracts useful for searching and indexing. RFC Editor Informational [Page 32] Internet-Draft Instructions to RFC Authors 10 Feb 2003 (2) A Table of Contents section is required or recommended in all but very short RFCs. (3) Separate lists are now required for normative references and informative references. (4) A new optional section, Contributors, is defined. o Appendixes Former Appendix A, which contained the source for the fix.pl post-processor Perl script and an nroff RFC template, has been removed. These files are available at the RFC Editor web site. Appendix B, RFC Preparation Tools, and Appendix C, Checklist, are new. Acknowledgments This memo includes wording taken from a draft written by Robert W. Shirey of GTE/BBN Technologies, 29 December 1999, with permission. Shirey's deconstruction of the formatting rules was very helpful in writing Sections 3 and 4 of the present memo. Normative References [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [10] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999. [11] Cerf, V., "ASCII Format for Network Interchange", RFC 20, October 1969. Informative References [1] RFC Editor et al., "30 Years of RFCs", RFC 2555, 7 April 1999. [4] Malkin, G. and J. Reynolds, "F.Y.I. on F.Y.I. Introduction to the F.Y.I. Notes", FYI 1, RFC 1150, March 1990. [5] Postel, J., Li, T. and Y. Rekhter, "Best Current Practices", BCP 1, RFC 1818, August 1995. RFC Editor Informational [Page 33] Internet-Draft Instructions to RFC Authors 10 Feb 2003 [6] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, March 1992. [7] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [8] Cohen, D., "On Holy Wars and a Plea for Peace", Internet Experimental Note (IEN) 137, 1 April 1980. A longer version is published in IEEE Computer Magazine, pp 48-54, October 1981. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [12] IETF, "Guidelines to Authors of Internet Drafts". Available as 1id-guidelines.txt at http://www.ietf.org. [13] Rescorla, E., Korver, B., and Internet Architecture Board, "Guidelines for Writing RFC Text on Security Considerations", Work in Progress, January 2003. [14] Garhns, M. and T. Hain, "Using Microsoft Word to create Internet Drafts and RFCs", RFC 3285, May 2002. [15] IESG, "Guidance for the use of formal languages in IETF specifications", http://www.ietf.org/IESG/STATEMENTS, October 2001. Security Considerations This RFC describes the Security Considerations sections of an RFC. Authors' Addresses Joyce K. Reynolds RFC Editor 4676 Admiralty Way Marina del Rey, CA 90292 EMail: rfc-editor@rfc-editor.org Robert Braden RFC Editor 4676 Admiralty Way Marina del Rey, CA 90292 EMail: rfc-editor@rfc-editor.org RFC Editor Informational [Page 34] Internet-Draft Instructions to RFC Authors 10 Feb 2003 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement: Funding for the RFC Editor function is currently provided by the Internet Society. RFC Editor Informational [Page 35]