idnits 2.17.1 draft-rfc-editor-rfc2223bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 37. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2008. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 39) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 44 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 4.7d IANA Considerations Section' ) ** There are 34 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2223, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: 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 == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 August 2004) is 7201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC' is mentioned on line 646, but not defined == Missing Reference: 'Required' is mentioned on line 972, but not defined -- Looks like a reference, but probably isn't: '14' on line 1598 -- Looks like a reference, but probably isn't: '4' on line 1918 == Unused Reference: 'Word02' is defined on line 1837, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. 'IPC04') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. 'IPT04') (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 1150 (ref. 'FYI90') (Obsoleted by RFC 6360) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA98') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3300 (ref. 'STD1') (Obsoleted by RFC 3600) -- Obsolete informational reference (is this intentional?): RFC 3285 (ref. 'Word02') (Obsoleted by RFC 5385) -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. 'XMLrf99') (Obsoleted by RFC 7749) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Reynolds, Editor 2 draft-rfc-editor-rfc2223bis-08.txt R. Braden, Editor 3 Obsoletes: 2223 RFC Editor 4 Category: Informational 1 August 2004 5 Expires: February 2005 7 Instructions to Request for Comments (RFC) Authors 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 IPR Statement 34 By submitting this Internet-Draft, I certify that any applicable 35 patent or other IPR claims of which I am aware have been disclosed, 36 or will be disclosed, and any of which I become aware will be 37 disclosed, in accordance with RFC 3668. 39 Abstract 41 This memo provides information for authors of Request for Comments 42 (RFC) documents. It summarizes RFC editorial policies and formatting 43 requirements, addresses frequently-asked questions, and serves as a 44 model for constructing a properly formatted RFC. 46 Table of Contents 48 1. Introduction .................................................. 3 49 1.1 Background on the RFC Document Series ..................... 3 50 1.2 Introduction to the RFC Publication Process ............... 4 51 2. General RFC Editorial Policies ............................... 7 52 2.1 Immutability .............................................. 7 53 2.2 Not all RFCs are Standards ................................ 8 54 2.3 Publication Language ...................................... 8 55 2.4 Publication Format(s) ..................................... 9 56 2.5 Consistent Document Style ................................. 10 57 2.6 Assignment of RFC Numbers ................................. 10 58 2.7 References and Citations .................................. 10 59 2.8 URLs in RFCs .............................................. 11 60 2.9 Titles .................................................... 11 61 2.10 IANA Considerations ...................................... 12 62 2.11 Relation to Other RFCs ................................... 12 63 2.12 Authors Listed on RFCs ................................... 13 64 2.13 April 1 RFCs ............................................. 14 65 2.14 Requirement-Level Words .................................. 15 66 2.15 Formal Languages in RFCs ................................. 15 67 3. General Format Rules for RFCs ................................. 16 68 3.1 General Formatting Rules .................................. 16 69 3.2 PostScript Format Rules ................................... 19 70 3.3 Header and Footer Formats ................................. 20 71 3.4 Protocol Data Definitions ................................. 20 72 4. Sections in an RFC ............................................ 21 73 5. Intellectual Property ......................................... 28 74 6. RFC Information and Contacts .................................. 31 75 7. Security Considerations ....................................... 31 76 8. Acknowledgments ............................................... 31 77 Appendix A - IPR Boilerplate ..................................... 32 78 Appendix B - RFC Preparation Tools ............................... 34 79 Appendix C - Checklist ........................................... 36 80 Appendix D - Changes from RFC 2223 ............................... 38 81 Normative References ............................................. 39 82 Informative References ........................................... 40 83 CHANGES (To be removed by RFC Editor before publication) ......... 41 84 Authors' Addresses ............................................... 43 86 1. Introduction 88 This memo provides information for authors of Request for Comments 89 (RFC) documents. It summarizes RFC editorial policies and formatting 90 requirements, addresses frequently-asked questions, and serves as a 91 model for constructing a properly formatted RFC. 93 1.1 Background on the RFC Document Series 95 The Requests for Comments documents, commonly known as RFCs, form 96 an archival series of more than 3800 memos about computer 97 communication and packet switching networks. Included prominently 98 in the RFC series are the official technical specifications of the 99 Internet protocol suite; these are defined by the Internet 100 Engineering Task Force (IETF) under the direction of the Internet 101 Engineering Steering Group (IESG). As a result, RFC publication 102 plays a significant role in the Internet standards process 103 [RFC2026]. 105 The RFC series was begun in 1969 as a set of technical and 106 organizational notes by the ARPAnet research community. Since the 107 early 1980s, the series has focused on the development of the 108 Internet and the TCP/IP protocol suite. Memos in the RFC series 109 discuss many aspects of networking, including protocols, 110 procedures, programs, and concepts as well as meeting notes, 111 opinions, and sometimes humor. For more information on the 112 history of the RFC series, see RFC 2555, "30 Years of RFCs" 113 [Hist99]. 115 RFCs are numbered (roughly) consecutively, and these numbers 116 provide a single unique label space for all RFCs. RFCs are 117 published on-line through a number of repositories (see [RFCed]), 118 and there is an online index of RFCs. 120 Each RFC is labeled with a category: Standards Track, Best Current 121 Practice, Experimental, Informational, or Historic. 123 Note on terminology: The Category attribute of an RFC has 124 sometimes been called its status, but the term "status" has 125 been overloaded. In the early years, it was used to mean the 126 requirement level of a specification, e.g., "Required" or 127 "Elective" (see, for example, RFC2400.) Later this single 128 status attribute proved too simplistic, so it was replaced by 129 more general Applicability Statements [RFC2026]. More 130 recently, we began to refer to the "category" as the 131 "status". However, this attribute is always listed on RFCs 132 as the Category (see Section 4.1.) 134 RFCs in the Standards Track category are published on behalf of 135 the IETF, with IESG approval. The IETF assigns a maturity level 136 -- Proposed Standard, Draft Standard, or Standard -- to each Stan- 137 dards Track RFC. The current maturity levels of all Standards 138 Track RFCs are specified in STD 1, "Official Internet Protocol 139 Standards" [STD1] and in the RFC index; they are not specified on 140 the RFCs themselves. 142 In addition to the master RFC index, there are secondary indexes 143 for useful subsets or "sub-series" of the RFCs. Three sub-series 144 are in use: 146 o STD document -- Category is Standards Track, maturity level 147 is Standard [STD92]. 149 o BCP document -- Category is Best Current Practice [BCP95] 151 o FYI document (For Your Information) -- Category is 152 Informational [FYI90] 154 An RFC in a sub-series is labeled with its sub-series number as 155 well as its RFC number. 157 The RFC series is published by the RFC Editor, under funding 158 provided by the Internet Society (ISOC) and under the supervision 159 of the Internet Architecture Board (IAB). The RFC Editor is 160 responsible for the final editorial review and the on-line 161 publication of RFCs. The RFC Editor also maintains the official 162 RFC archive and the index files and makes these accessible via the 163 Web, FTP, and email [RFCed]. The RFC Editor also maintains a list 164 of errata for previously-published RFCs. Since 1977, the RFC 165 Editor function has been performed by staff at the Information 166 Sciences Institute of the University of Southern California 167 (USC/ISI). 169 In performing its function, the RFC Editor works closely with the 170 IESG and with the Internet Assigned Numbers Authority (IANA). 172 1.2 Introduction to the RFC Publication Process 174 This section contains a brief overview of the submission, review, 175 and publication process for RFCs. More details, especially for 176 standards-track RFCs, will be found in RFC 2026, "The Internet 177 Standards Process -- Revision 3" [RFC2026], as amended by later 178 IETF policy statements. RFC 2026 and amendments, or its 179 successor, takes precedence in the case of any apparent conflict 180 with the following overview. 182 1.2.1 RFC Submission and Review 184 To be considered for publication as an RFC, a document must 185 first be submitted as an Internet-Draft (I-D) [RFC2026]. This 186 ensures an opportunity for feedback from members of the 187 Internet community and from the IESG. The Internet Draft must 188 include boilerplate that allows RFC publication (see 189 "Guidelines to Authors of Internet-Drafts" [IDguide]). 191 The submission and review procedures for RFCs depend upon the 192 document's source. RFC submissions may come from the IETF, 193 from the IAB, from the Internet Research Task Force (IRTF), or 194 from an individual. 196 o Submissions from the IETF 198 RFCs originating in the IETF are submitted to the RFC Editor 199 via the IESG, which reviews them for technical quality and 200 procedural conformance. These IESG submissions are 201 transmitted to the RFC Editor via official "Protocol Action" 202 messages that are recorded at the IETF web site. 203 Submissions through the IESG may be in any of the categories 204 (Standards Track, Best Current Practice, Experimental, 205 Informational, or Historic.) All submissions in the 206 Standards Track or Best Current Practice category must first 207 be submitted to the IESG for approval; the IESG will submit 208 them to the RFC Editor. 210 At IESG request, the RFC Editor will add an "IESG Note" to a 211 published RFC, to provide clarification or guidance to 212 readers. 214 o Submissions from the IAB 216 The IAB may submit documents directly to the RFC Editor for 217 publication as RFCs in the Informational or Experimental 218 category, without IESG approval or review. 220 o Independent Submissions 222 Individuals may submit documents directly to the RFC Editor 223 for publication as RFCs in the Experimental or Informational 224 category. 226 The RFC Editor reviews each such "independent submission" 227 for relevancy and appropriateness as well as general 228 compliance with the rules in Sections 2, 3 and 4 of this 229 document. Updates are requested as necessary, sometimes 230 through several iterations, until an acceptable submission 231 document is achieved. 233 To maintain the integrity of the RFC document series and to 234 avoid wasting scarce publication resources, the RFC Editor 235 may reject an indepedent submission because its content is 236 uninteresting or irrelevant, or because its editorial 237 quality is acceptable. The RFC Editor will attempt to 238 explain as clearly and completely as possible the reasons 239 for rejection. For evaluation of content, the RFC Editor 240 may consult individuals expert in the field. 242 Once the RFC Editor has determined that an independent 243 submission is acceptable, the document is passed to the IESG 244 for review for conflict with work in progress in the IETF 245 [RFC2026]. When its topic is closely related to an existing 246 IETF Working Group, the IESG may request that the author 247 coordinate with that working group. This may result in the 248 production of a revised memo that eventually emerges from 249 the IETF process as an IETF submission. The IESG may also 250 provide input to the RFC Editor on content problems with the 251 document; the RFC Editor will request that the author(s) 252 attempt to address these concerns before publication. 254 If the IESG feels that the submitted document does conflict 255 with the IETF process, they will make a "Do Not Publish" 256 recommendation to the RFC Editor. The RFC Editor may then 257 reject the document, or publish it with an "IESG Position" 258 statement that defines IESG objections to the document or 259 narrows its scope of applicability. The IESG may 260 alternatively ask for deferred publication, via a "Do Not 261 Publish Now" recommendation, for a maximum of two six-month 262 intervals. This should allow completion of any conflicting 263 working group activity. 265 In general, the RFC Editor is charged with the final 266 decision about publication of an independent submission. 268 o Submission from the IRTF 270 RFC submissions from IRTF members are normally treated as 271 independent submissions. 273 1.2.2 RFC Publication 275 A document that is submitted to the RFC Editor enters the 276 RFC Editor's queue, which is viewable at the RFC Editor Web 277 site [RFCed]. The document (Internet Draft) remains in the 278 RFC Editor queue until it is published as an RFC, unless (1) 279 the author withdraws it, (2) the author is very unresponsive 280 in making requested updates, or (3) it is an independent 281 submission that is deemed unacceptable by the RFC Editor. 283 The RFC Editor ensures that the document follows the 284 editorial rules described later in this document. The RFC 285 Editor may make editorial changes to clarify readability and 286 to provide a uniform style and format. If excessive work is 287 required to satisfy the rules and/or to bring the RFC up to 288 publication quality, the memo may be returned to the author 289 or to the IESG for additional work. 291 When editing of the document is complete, the RFC Editor 292 sends the result to the authors for careful proof-reading. 293 This quality control step is critical to maintaining the 294 quality of RFCs. Although this process is traditionally 295 called the "Authors' 48 Hours" period, the RFC Editor is 296 always willing to give authors reasonable additional time to 297 review the document, and a document will not be published 298 until all its listed authors agree. While it is helpful to 299 have one principal author during the editing process, all 300 listed authors will be considered responsible for the 301 correctness of the final document. 303 In practice, the editorial process among the IESG, the RFC 304 Editor, and the author(s) can be lengthy and convoluted, and 305 the time spent in the RFC Editor's queue can vary greatly. 306 Sometimes problems are found that require document revisions 307 by the authors. These revisions may require the publication 308 of another Internet-Draft, and the result must be re- 309 reviewed. Publication may be held up awaiting IANA 310 assignments, or in order to synchronize the publication of 311 related RFCs. 313 2. General RFC Editorial Policies 315 This section summarizes some general editorial and publication 316 policies for RFCs. Individual policies may be modified or new 317 policies added before the present document is revised. RFC authors 318 should obtain the latest RFC editorial policy statements from the RFC 319 Editor web page [RFCed]. 321 2.1 Immutability 323 Since the RFCs form an archival series, an RFC cannot be altered 324 once it is published. To change the contents of an RFC, a new RFC 325 must be written that obsoletes the previous one. (Early in the 326 history of RFCs, the Editor did occasionally make small editorial 327 changes after publication, but this led to confusion regarding 328 which version was correct, and it was a slippery slope. To avoid 329 these pitfalls, the never-change rule is now strictly enforced.) 331 Although RFCs are subjected to careful scrutiny by the RFC Editor 332 and the authors before publication, errors do sometimes creep in. 333 For this reason, the RFC Editor strongly urges the authors to 334 thoroughly review the document during the "Authors' 48 hours" 335 period. 337 The RFC Editor maintains an online list of errata for existing 338 RFCs. If you find what you believe to be an error in an RFC, 339 consult the errata page at the RFC Editor web site [RFCed]. If 340 the bug is not listed, please send email to the authors of the 341 document and to the RFC Editor. 343 2.2 Not all RFCs are Standards 345 Eager salesmen have been known to imply that all RFCs represent 346 official Internet standards. This is false and misleading. While 347 some RFCs are Standards Track documents, many have other 348 categories and do not represent a standard of any kind. 350 2.3 Publication Language 352 Like the Internet itself, the IETF and the Internet Society are 353 international organizations with participation from all areas of 354 the world. However, English is the primary language in which IETF 355 business is conducted, and English is the official publication 356 language for RFCs. 358 RFCs submitted for publication are required to meet a reasonable 359 standard for clear and correct English. 361 RFC 2026 specifically allows RFCs to be translated into languages 362 other than English. Repositories may exist for RFCs that have 363 been translated into particular languages. This is highly 364 desirable and useful. However, it is not possible for the RFC 365 Editor to certify that such translations are accurate. Therefore, 366 the function of the RFC Editor, with respect to non-English RFCs, 367 is limited to providing pointers to non-English language RFC 368 repositories. Upon request, the RFC Editor will list any such 369 repository on its Web page. 371 2.4 Publication Format(s) 373 RFCs are published as plain text files in the [US-]ASCII character 374 set, with the file name extension ".txt". 376 The continued use of ASCII plain text for RFCs, despite the 377 spread of "more modern" formats, is intermittently debated by 378 the Internet community. The consensus continues to be that 379 the great advantages of ASCII plain text -- the ability to 380 readily edit, cut-and-paste, and search documents, the 381 ubiquitous availability of tools for these functions, and the 382 longevity of US-ASCII as a character standard -- make ASCII 383 plain text the clear winner. 385 For the convenience of those whose operating systems have 386 difficulty supporting plain ASCII text, the RFC Editor also 387 maintains PDF files that are exact facsimiles of the plain text 388 versions. 390 The ASCII plain text version (and its .txt.pdf facsimile) is 391 always the official specification, and it must adequately and 392 completely define the technical content. (A very few exceptions 393 have been made over the 30 year history of RFCs, allowing a 394 definitive PostScript (.ps) version with no 395 .txt version.) The primacy of the ASCII version typically 396 requires that the critical diagrams and packet formats be rendered 397 as "ASCII art" in the .txt version. 399 However, secondary or alternative versions in PostScript and/or 400 PDF are provided for some RFCs, to allow the inclusion of fancy 401 diagrams, graphs, or characters that cannot possibly be rendered 402 in ASCII plain text. If there is a PostScript (.ps) or PDF (.pdf) 403 version of the document, the author should inform the RFC Editor 404 at the time of submission of the .txt version. 406 PostScript and PDF versions suffer from a serious flaw: the RFC 407 Editor cannot easily make editorial changes in the source file to 408 produce a new document in either of these formats. This can make 409 the editorial process for .ps and .pdf versions somewhat painful 410 for both the author and editor. The following procedure is 411 followed. When a .ps (or .pdf) version is submitted with a .txt 412 version, the RFC Editor will first edit the .txt version. The 413 final form of the .txt version (or, when feasible, the diffs) will 414 be returned to the author. The author must then update the 415 .ps/.pdf files to match, as closely as possible, the content and 416 format of the ASCII .txt file. When the RFC Editor agrees that 417 the .ps/.pdf versions are acceptable, they are published 418 simultaneously with the .txt version. 420 2.5 Consistent Document Style 422 The RFC Editor attempts to enforce a consistent style of RFCs. To 423 do this, the RFC Editor may choose to reformat a submitted RFC or 424 ask the author to reformat it. Effort is minimized when the 425 submitted document matches the style of the most recent RFCs. 426 Please read the rules and recommendations that are presented in 427 following sections of this memo and look at some recent RFCs, to 428 adopt an appropriate style. 430 To format most ASCII RFCs for publication, the RFC Editor uses the 431 "nroff" program with a simple set of the formatting commands (or 432 "requests") from the "ms" macro package (see Appendix B). If the 433 author has an nroff source file, it will be helpful to make this 434 available to the RFC Editor when the document is submitted. 436 When a .ps version is published, the RFC Editor will also publish 437 a matching .pdf version. When a .txt version is published, the 438 RFC Editor will also publish a matching .txt.pdf version. 440 2.6 Assignment of RFC Numbers 442 RFC numbers are not assigned until very late in the editorial 443 process, to avoid gaps in the RFC number series. Requests for 444 early assignment of an RFC number are generally denied unless they 445 originate from the IAB or the IESG. 447 2.7 References and Citations 449 An RFC will generally contain bibliographic references to other 450 documents, and the body will contain citations to these 451 references. Section 4.7f specifies the format for the references 452 listed at the end of the RFC body, but there is no required format 453 for a citation. 455 Within an RFC, references to other documents fall into two general 456 categories: "normative" and "informative". Normative references 457 specify documents that must be read to understand or implement the 458 technology in the new RFC, or whose technology must be present for 459 the technology in the new RFC to work. An informative reference 460 is not normative; rather, it provides only additional information. 461 For example, an informative reference might provide background or 462 historical information. Material in an informative reference is 463 not required to implement the technology in the RFC. 465 An RFC must include separate lists of normative and informative 466 references (see Section 4.7f below.) The distinction between 467 normative and informative references is often important. The IETF 468 standards process and the RFC Editor publication process need to 469 know whether a reference to a work in progress is normative. A 470 standards-track RFC cannot be published until all of the documents 471 that it lists as normative references have been published. In 472 practice, this often results in the simultaneous publication of a 473 group of interrelated RFCs. 475 We recommend enclosing citations in square brackets ("[ ]"). 476 Simple numeric citations ("[53]") can cause confusing gaps when 477 the list of references is split between normative and informative. 478 A good alternative is to have two separate series, "[n1]", "[n2]", 479 ... "[i1]", "[i2]" for citations to normative and informative 480 references. Other choices include author abbreviations, possibly 481 a year ("[Smith93]"), and some brief encoding of the title and 482 year ("[MPLS99a]"). 484 2.8 URLs and DNS names in RFCs 486 The use of URLs in RFCs is discouraged, because many URLs are not 487 stable references. Exceptions may be made for normative 488 references in those cases where the URL is demonstrably the most 489 stable reference available. References to long-lived files on 490 ietf.org and rfc-editor.org are generally acceptable. 492 DNS names, whether or not in URLs, that as used as generic 493 examples in RFCs should use the particular examples defined in RFC 494 2606, "Reserved Top-Level DNS Names" [TLD99], to avoid accidental 495 conflicts. 497 2.9 Titles 499 Choosing a good title for an RFC can be a challenge. A good title 500 should fairly represent the scope and purpose of the document 501 without being either too general or too specific. 503 Abbreviations (e.g., acronyms) in a title (as well as the Abstract 504 and the body; see Sections 4.5 and 4.7) must generally be expanded 505 when first encountered. The exception is abbreviations that are 506 so common that every participant in the IETF can be expected to 507 recognize them immediately; examples include (but are not limited 508 to) TCP, IP, SNMP, and FTP. Some cases are marginal and the 509 decision on expansion may depend upon the specific title. The RFC 510 Editor will make the final judgment, weighing obscurity against 511 complexity. 513 It is often helpful to follow the expansion with the parenthesized 514 abbreviation, as in the following example: 516 Encoding Rules for the 517 Common Routing Encapsulation Extension Protocol (CREEP) 519 Authors should be aware that the title of an RFC may be subject to 520 policy considerations in addition to the requirement that it 521 provide a concise and technically sound summary of the document 522 contents. For example, at various times in the history of the 523 IETF, the words "Requirements" and "Policies" as well as the 524 phrase "The Directory" have been banned from RFC titles, each for 525 its own reason. 527 RFCs that document a particular company's private protocol must 528 bear a title of the form "XXX's ... Protocol" (where XXX is a 529 company name), to clearly differentiate it from an IETF product. 531 2.10 IANA Considerations 533 Many RFCs define protocol specifications that require the 534 assignment of values to protocol parameters, and some define new 535 parameter fields. Assignment of these parameter values is often 536 (and sometimes must be) deferred until publication of the defining 537 RFC. The IANA and the RFC Editor collaborate closely to ensure 538 that all required parameters are assigned and entered into the 539 final RFC text. 541 Any RFC that defines a new "namespace" of assigned numbers must 542 include an IANA Considerations section specifying how that space 543 should be administered. See "Guidelines for Writing an IANA 544 Considerations Section in RFCs" [IANA98] for a detailed discussion 545 of the issues to be considered and the contents of this section. 547 Current policy (not documented in [IANA98]) is to include an IANA 548 Considerations section always, even if it is "null", i.e., even if 549 there are no IANA considerations. This is helpful to IANA. 550 However, the RFC Editor may remove any null IANA considerations 551 sections before publication. 553 2.11 Relation to other RFCs 555 Sometimes an RFC adds information on a topic discussed in a 556 previous RFC or completely replaces an earlier RFC. Two terms are 557 used for these cases: Updates and Obsoletes, respectively. 559 Updates 561 Specifies an earlier document whose contents are modified or 562 augmented by the new document. The new document cannot be 563 used alone, it can only be used in conjunction with the 564 earlier document. 566 Obsoletes 568 Specifies an earlier document that is replaced by the new 569 document. The new document can be used alone as a 570 replacement for the obsoleted document. The new document 571 may contain revised information or all of the same 572 information plus some new information, however extensive or 573 brief that new information may be. 575 In lists of RFCs and in the RFC-Index (but not on the RFCs 576 themselves) the following are used for older documents that were 577 referred to by Obsoletes or Updates relations in newer documents: 579 Obsoleted-by 581 Used to specify newer document(s) that replace the older 582 document. 584 Updated-by 586 Used to specify newer document(s) that modify or augment the 587 older document. 589 2.12 Authors Listed on RFC 591 The IESG and IETF have ratified a policy of limiting the number of 592 authors listed in the first page header of an RFC. The specific 593 policy is as follows: 595 (1) A small set of author names, with affiliations, may appear on 596 the front page header. These should be the lead author(s) 597 who are most responsible for the actual text. When there are 598 many contributors, the best choice will be to list the person 599 or (few) persons who acted as document editor(s) (e.g.,"Tom 600 Smith, Editor"). 602 There is no rigid limit on the size of this set, but there is 603 likely to be a discussion if the set exceeds five authors, in 604 which case the right answer is probably to list one editor. 606 The RFC Editor will hold all the people listed on the front 607 page equally responsible for the final form and content of 608 the published RFC. In particular, the "Author's 48 Hours" 609 final approval period will require signoff from all listed 610 authors. 612 (2) An RFC may include a Contributors section, listing those 613 contributors who deserve significant credit for the document 614 contents. The Contributors section is intended to provide a 615 level of recognition greater than an acknowledgment and 616 nearly equal to listing on the front page. The choice of 617 either, both, or none of Contributor and Acknowledgment 618 sections in a particular RFC depends upon the circumstance. 620 (3) The body of an RFC may include an Acknowledgements section, 621 in addition to or instead of a Contributors section. An 622 Acknowledgments section may be lengthy, and it may explain 623 scope and nature of contributions. It may also specify 624 affiliations. 626 (4) The Author's Address section at the end of the RFC must 627 include the authors listed in the front page header. The 628 purpose of this section is to (1) unambiguously define 629 author/contributor identity (e.g., the John Smith who works 630 for FooBar Systems) and to (2) provide contact information 631 for future readers who have questions or comments. 633 At the discretion of the author(s), contact addresses may 634 also be included in the Contributors section for those 635 contributors whose knowledge makes them useful future 636 contacts for information about the RFC. 638 (5) The RFC Editor may grant exceptions to these guidelines upon 639 specific IESG request or in other exceptional circumstances. 641 Finally, it is important to note that the copyright rules 642 governing RFC publication [IPC04] require that an RFC must: 644 "[acknowledge] all major Contributors. A major Contributor 645 is any person who has materially or substantially contributed 646 to the [RFC]." 648 The Contributors and Acknowledgment sections fulfill this 649 objective. 651 2.13 April 1 RFCs 653 Many years ago the RFC Editor established the practice of 654 publishing one or more satirical documents on April 1 of each 655 year. Readers should be aware that many of the RFCs bearing the 656 date April 1 are not to be taken seriously. The RFC Editor 657 reviews April 1 RFC submissions for cleverness, humor, and topical 658 association with computer networking, and a few of the best are 659 published. Submissions must be made to the RFC Editor in time for 660 review and publication. 662 Note that in past years the RFC Editor has sometimes published 663 serious documents with April 1 dates. Readers who cannot 664 distinguish satire by reading the text may have a future in 665 marketing. 667 2.14 Requirement-Level Words 669 Some standards-track documents use certain capitalized words 670 ("MUST", "SHOULD", etc.) to specify precise requirement-levels for 671 technical points. RFC 2119 (BCP 14) [BCP14] defines a default 672 interpretation of these capitalized words in IETF documents. If 673 this interpretation is used, RFC 2119 must be cited (as specified 674 in RFC 2119) and included as a normative reference. Otherwise, 675 the correct interpretation must be specified in the document. 677 Avoid abuse of requirement-level words. They are intended to 678 provide guidance to implementors about specific technical 679 features, generally governed by considerations of 680 interoperability. RFC 2119 says, "Imperatives of the type defined 681 in this memo must be used with care and sparingly. In particular, 682 they MUST only be used where it is actually required for 683 interoperation or to limit behavior which has potential for 684 causing harm (e.g., limiting retransmissions). For example, they 685 must not be used to try to impose a particular method on 686 implementors where the method is not required for 687 interoperability." To simply specify a necessary logical 688 relationship; the normal lower-case words should be used. On the 689 other hand, if the capitalized words are used in a document, they 690 must be used consistently throughout the document. 692 2.15 Formal Languages in RFCs 694 See [Lang01] for IESG guidance on the use of formal languages in 695 RFCs. The RFC Editor will run every MIB through a MIB checker 696 before publication, and machine verification of other formal 697 languages included in RFCs may be required. 699 3. General Format Rules for RFCs 701 This section defines the general rules governing the format of a 702 published RFC (as opposed to requirements on submitted documents). 703 Authors are requested to come as close to these rules as reasonable, 704 but in any case the RFC Editor will ensure they are met before 705 publication. For example, the RFC Editor will supply headers and 706 footers, adjust pagination to avoid "widows", and adjust a Table of 707 Contents accordingly. 709 However, author attention to these rules will streamline the 710 publication process and reduce the average publication time. If 711 reaching the final format requires excessive effort by the RFC 712 Editor, the author will be asked to assist in the reformatting. 713 Authors are admonished to proof-read the final publication form 714 carefully, to ensure that no errors accidentally crept in. 716 These formatting rules are intentionally incomplete in some details. 717 They attempt to define only what is strictly necessary for uniformity 718 and simplicity (a virtue). Some latitude is allowed to accommodate a 719 broad range of printers, systems, and evolving requirements. The 720 general objective is to create a series of documents that are 721 reasonably uniform and are easy to read, while accommodating a wide 722 range of content. 724 Note that these rules govern an RFC as published. During the 725 publication process the RFC Editor will verify compliance and will 726 repair minor infractions. 728 3.1 General Formatting Rules 730 (1) Character code 732 The character code is US-ASCII [ASCII69] (also known as ISO 733 646.IRV). Only the printable ASCII characters and the three 734 control characters CR, LF, and FF are allowed. 736 Notes: CR and LF must be used only as provided in rule 737 (2), and FF must be used only as provided in rule (3). 738 Tab (HT) characters and Backspace (BS) characters are 739 never allowed (hence there can be no underlining; see 740 (4) below). 742 (2) Width 744 Each line must be limited to 72 characters followed by the 745 character sequence that denotes an end-of-line (EOL). This 746 limit includes any left-side indentation. 748 Note: A plain-text RFC is expected to be stored on a 749 disk file using the EOL sequence of that system. For 750 example, MS DOS-based systems use the two-character 751 sequence: CR LF (Carriage Return followed by Line Feed), 752 Unix systems use the single character LF for EOL, and 753 EBCDIC systems use the single character NL (New Line). 755 Whenever an RFC is transmitted across the Internet, 756 Internet protocol convention requires that each line of 757 text be followed by the two-character EOL sequence CR LF 758 (Carriage Return followed by Line Feed). A user level 759 protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make 760 the appropriate EOL transformation at each line end. 761 Note that binary transmission of plain-text RFC files 762 can cause the sender's EOL convention to "leak" into the 763 receiver, causing confusion. 765 (3) Height 767 Each page must be limited to 58 lines followed by a Form Feed 768 (FF) character, followed by an EOL sequence. The 58 line 769 limit includes the headers and footers specified below. 771 All pages, except perhaps the first and last, should have the 772 same number of lines when headers and footers are included. 773 That is, footers should not "bounce" from page to page. 775 Note: The maximum line count includes blank lines. 776 However, the first line will normally be the first 777 header line and the last line will be the final footer 778 line; that is, it will not begin or end with a blank 779 line. 781 Note: 58 lines is the maximum; 55 is more commonly used 782 and may actually produce more readable formatting. The 783 recommended page formatting parameters (see Appendix B) 784 produce 55 line pages on many printers, for example. 786 Note: The effect of the Height rule is that the 787 following character sequence will be used: 789 FF 791 ... 793 As transmitted across the Internet as ASCII text, the 794 character sequence is: 796 CR LF FF CR LF 798 CR LF ... 800 Finally, note that the sequence FF CR LF has an 801 ambiguous effect: on some printers, the FF implies an 802 EOL, so this may produce a blank line; on other printers 803 it will produce no blank line. The number 58 and this 804 sequence were designed to render this ambiguity 805 unimportant, assuming the (once predominant) printer 806 standard of 60 lines per page. 808 (4) No Overstriking 810 No overstriking (or underlining) is allowed. 812 (5) No Filling 814 Do not fill the text with extra spaces to provide a straight 815 right margin. Do not right justify the text. 817 (6) No Hyphenation 819 Do not use hyphenation at the right margin to split existing 820 words. However, hyphenated word sequences (e.g., "Internet- 821 Draft") may be split at the hyphen across successive lines. 823 Note: There are good reasons why the right page margin 824 is required to be "ragged", and why hyphenation of words 825 at the right margin is prohibited. Studies have shown 826 that text is harder to read when fixed-size spaces are 827 inserted to adjust the right margins, regardless of 828 which font is used or how smoothly the blank filler is 829 inserted. In addition, when technical text in a fixed- 830 width font is hyphenated at the right margin, the 831 printed result is not only less readable but also ugly. 833 (7) Spaces at the End of a Sentence 835 When a sentence ended by a period is immediately followed by 836 another sentence, there should be two blank spaces after the 837 period. This rule provides clarity when an RFC is displayed 838 or printed with a fixed-width font. 840 (8) Footnotes 842 Do not use footnotes. If such notes are necessary, put them 843 at the end of a section, or at the end of the document. 845 (9) Line Spacing 847 Use single-spaced text within a paragraph, and one blank line 848 between paragraphs. 850 (10) Page Numbering 852 Pages must be numbered consecutively, starting from 1 on the 853 first (cover) page. 855 (11) Headers and Footers 857 RFCs must have running headers and footers, as defined below 858 in Section 3.3. The headers and footers must be separated 859 from the body by at least one and preferably two blank lines. 861 (12) Indentation 863 Successive indentation of sub-subsections (as in this 864 document, for example) is recommended but not required. 865 Experience has shown that indentation by multiples of 3 866 columns works well. In any case, the careful use of 867 indentation can make a very great improvement in the 868 readability of a document. 870 3.2 PostScript Format Rules 872 (1p) Standard page size is 8 1/2 by 11 inches (216 by 279 mm). 874 (2p) Leave a margin of 1 inch (25 mm) on all sides (top, bottom, 875 left, and right). 877 (3p) Main text should have a point size of no less than 10 points 878 with a line spacing of 12 points. 880 (4p) Footnotes and graph notations no smaller than 8 points with a 881 line spacing of 9.6 points. 883 (5p) Three fonts are acceptable: Helvetica, Times Roman, and 884 Courier, plus their bold-face and italic versions. These are 885 the three standard fonts on most PostScript printers. 887 (6p) Prepare diagrams and images based on lowest common 888 denominator PostScript. Consider common PostScript printer 889 functionality and memory requirements. 891 (7p) The following PostScript commands should not be used: 892 initgraphics, erasepage, copypage, grestoreall, initmatrix, 893 initclip, banddevice, framedevice, nulldevice or renderbands. 895 3.3 Header and Footer Formats 897 RFCs must include running headers and footers that obey the 898 following rules. 900 o Running Headers 902 The running header in one line (on page 2 and all subsequent 903 pages) has the RFC number on the left (RFC nnnn), the title 904 (possibly shortened) in the center, and the publication date 905 (Month Year) on the right. 907 o Running Footers 909 All pages contain a one-line running footer, with the author's 910 last name on the left, the category centered, and the page 911 number on the right ("[Page nn]"). 913 If there are two authors, the form "name & name" may be used; 914 for more than two authors, use the form "name, et al." 916 3.4 Protocol Data Definitions 918 Many years ago, the RFC series adopted a pictorial approach to 919 representing data structures such as protocol headers. 920 Furthermore, the research community adopted a "big-endian" 921 convention in which the bits and bytes are shown in network byte 922 order, byte zero is the first byte shown, and bit zero is the most 923 significant bit in a word or a field [IEN137]. 925 For example, RFC 791 contains the following definition of the IP 926 header format. 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 |Version| IHL |Type of Service| Total Length | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Identification |Flags| Fragment Offset | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Time to Live | Protocol | Header Checksum | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Source Address | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Destination Address | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Options | Padding | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Example Internet Datagram Header 946 We strongly recommend that a new RFC follow the same formatting 947 conventions, which have been found to work well. Any alternative 948 style must meet the same level of clarity, readability, and lack of 949 ambiguity. An author wishing to use an alternative style should 950 discuss it with the RFC Editor. 952 4. Sections in an RFC 954 A published RFC may contain the sections in the following list. Some 955 of these sections are required, as noted. The order shown is 956 required, except that the order shown for the sub-items 7a-7f within 957 Body of Memo is generally recommended but not required. 959 1. First-page header [Required] 960 2. Status of this Memo [Required*] 961 3. Copyright Notice [Required*] 962 4. IESG Note [As requested by IESG*] 963 5. Abstract [Required] 964 6. Table of Contents [Required for large documents] 965 7. Body of the Memo [Required] 966 7a. Contributors 967 7b. Acknowledgments 968 7c. Security Considerations [Required] 969 7d. IANA Considerations 970 7e. Appendixes 971 7f. References 972 8. Author's Address [Required] 973 9. IPR Boilerplate [Required*] 975 Those sections marked with * will be supplied by the RFC Editor 976 during the editorial process when necessary. 978 The rules for each of these sections are described below in 979 corresponding subsections. 981 The Body of the Memo will normally contain section numbers (or 982 Appendix labels). Sections listed as 1-6 and 8-9 are to be 983 unnumbered. 985 4.1. First-Page Header 987 Please see the front page of this memo for an example of the front 988 page heading. On the first page there is no running header. The 989 top of the first page has the following items left justified: 991 "Network Working Group" 993 This traditional title must be left-justified on the first line 994 of the heading. It denoted the ARPAnet research group that 995 founded the RFC series. 997 "Request for Comments: nnnn" 999 Identifies this as an RFC and specifies the RFC number, left- 1000 justified on the second line. The actual number is filled in 1001 at the last moment prior to publication by the RFC Editor. 1003 "BCP: nn" or 1004 "FYI: nn" or 1005 "STD: nn" 1007 One of these optional left-justified items indicates the sub- 1008 series number, if the RFC is a member of a sub-series. The 1009 actual number is filled in at the last moment prior to 1010 publication by the RFC Editor. 1012 "Updates: nnnn" or "Updates: nnnn, ..., nnnn" 1014 Optional left-justified field, containing an RFC number or a 1015 comma-separated list of RFC numbers that are updated by this 1016 RFC. See Section 2.11. 1018 "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn" 1020 Optional left-justified field containing an RFC number or a 1021 comma-separated list of RFC numbers that are obsoleted by this 1022 RFC. See Section 2.11. 1024 "Category: xxxxxxxxx" 1026 Required left-justified field specifying the category of this 1027 RFC. Here xxxxxxxx may be one of: Standards Track, Best 1028 Current Practice, Informational, or Experimental. Will be 1029 supplied by RFC Editor, according to request of submittor. 1031 The following information appears right-justified in the header: 1033 Author 1035 The author's name (initial of first given name followed by 1036 family name), right-justified on the first line of the heading. 1038 Organization 1040 The author's organization, indicated on the line following the 1041 Author name. 1043 For multiple authors, each author name appears right-justified 1044 on its own line, followed by that author's organization. When 1045 more than one author has the same organization, the 1046 organization can be "factored out" and appear only once 1047 following the corresponding Author lines. However, such 1048 factoring is not necessary if it results in an unacceptable 1049 reordering of author lines. 1051 The total number of authors is generally limited; see Section 1052 2.12. 1054 Date 1056 The month and year of the RFC Publication, right-justified on 1057 the line after the last Organization line. 1059 The title appears, centered, below the rest of the heading, 1060 preceded and followed by at least one blank line. Periods 1061 ("dots") are not allowed in the title. 1063 The title should be carefully chosen to accurately reflect the 1064 contents of the document. See also Section 2.9. 1066 4.2. Status of this Memo 1068 The RFC Editor will supply a "Status of this Memo" section that 1069 contains two elements: (1) a paragraph describing the category of 1070 the RFC, and (2) the distribution statement. The contents of this 1071 section will be found in Appendix A. 1073 An RFC that is (re-)publishing a specification produced by another 1074 (non-IETF) standards organization or is publishing a proprietary 1075 protocol may include the following paragraph in the Status of the 1076 Memo section [IPC04]: 1078 "This document may not be modified, and derivative works of 1079 it may not be created, except to publish it as an RFC and to 1080 translate it into languages other than English [other than to 1081 extract section XX as-is for separate use]." 1083 Here the optional clause delimited by [ ] is for programmatic 1084 material that is mean to be be extracted, e.g., MIB or PIB 1085 modules. The IETF does not have change control over such 1086 documents, which are published as Informational RFCs. 1088 4.3 Copyright Notice 1090 The Copyright Notice section is required. It contains the 1091 statement, "Copyright (C) The Internet Society (date)." The full 1092 copyright statement described in Section 4.9 must also appear at 1093 the end of the document. 1095 4.4 IESG Note 1097 This optional section will appear when the IESG requires a warning 1098 or clarifying message on an RFC. 1100 4.5 Abstract 1102 Every RFC must have an Abstract section following the Copyright 1103 notice. An Abstract will typically be 5-10 lines. An Abstract of 1104 more than 20 lines is generally not acceptable. 1106 The Abstract section should provide a concise and comprehensive 1107 overview of the purpose and contents of the entire document, to 1108 give a technically knowledgeable reader a general overview of the 1109 function of the document. In addition to its function in the RFC 1110 itself, the Abstract section text will appear in publication 1111 announcements and in the online index of RFCs. 1113 Composing a useful Abstract generally requires thought and care. 1114 Usually an Abstract should begin with a phrase like "This memo 1115 ..." or "This document ...". A satisfactory abstract can often be 1116 constructed in part from material within the Introduction section, 1117 but a good abstract will be shorter, less detailed, and perhaps 1118 broader in scope than the Introduction. Simply copying and 1119 pasting the first few paragraphs of the Introduction is tempting, 1120 but it may result in an Abstract that is both incomplete and 1121 redundant. Note also that an Abstract is not a substitute for an 1122 Introduction; the RFC should be self-contained as if there were no 1123 Abstract section. 1125 An Abstract should be complete in itself; it should not contain 1126 citations unless they are completely defined within the Abstract. 1127 Abbreviations appearing in the Abstract should generally be 1128 expanded in parentheses. There is a small set of reasonable 1129 exceptions to this rule; see the discussion under Titles, Section 1130 2.9. 1132 4.6 Table of Contents 1134 A Table of Contents (TOC) section is required in RFCs longer than 1135 30 pages and recommended for an RFC longer than 15 pages. 1137 A TOC must be positioned after the Abstract and before the 1138 Introduction section (i.e., after the "boilerplate" and before the 1139 body of the RFC.) 1141 The TOC itself should not be too long or detailed, or it loses 1142 value. For example, if many successive TOC entries point to the 1143 same pages of the memo, the TOC probably needs to be coarser. 1145 No specific format is required, but the following example 1146 illustrates a useful format: 1148 1. INTRODUCTION ............................................... 5 1149 1.1 The Internet Architecture .............................. 6 1150 1.1.1 Internet Hosts .................................... 6 1151 1.1.2 Architectural Assumptions ......................... 7 1152 1.1.3 Internet Protocol Suite ........................... 8 1153 1.1.4 Embedded Gateway Code ............................. 10 1154 1.2 General Considerations ................................. 12 1155 1.2.1 Continuing Internet Evolution ..................... 12 1156 1.2.2 Robustness Principle .............................. 12 1157 1.2.3 Error Logging ..................................... 13 1159 4.7 Body of the Memo 1161 Following the Table of Contents, if any, comes the body of the 1162 memo. Depending upon the length of the TOC, a judicious page 1163 break can improve readability. 1165 Each RFC should have an Introduction section that (among other 1166 things) explains the motivation for the RFC and (if appropriate) 1167 describes the applicability of the document, e.g., whether it 1168 specifies a protocol, provides a discussion of some problem, is 1169 simply of interest to the Internet community, or provides a status 1170 report on some activity. 1172 All abbreviations that are used in the body must be expanded the 1173 first time they occur. A few exceptions will be made for very 1174 well-known abbreviations; see the discussion under Titles in 1175 Section 2.9. 1177 Abbreviation overload is an increasingly common problem in RFCs. 1178 We recommend that complex RFCs include a brief glossary at the 1179 end. On the other hand, a glossary is never a substitute for an 1180 explanation. 1182 Cross references within the body of the text should use section 1183 numbers rather than page numbers, as the RFC Editor generally 1184 adjusts pagination during final editing. The only exception is 1185 the Table of Contents, which necessarily shows page numbers. 1187 4.7a Contributors Section 1189 This optional section lists those contributors who deserve 1190 significant credit for the document. When a long author list 1191 is replaced by a single Editor in the front page header, the 1192 displaced authors can be properly and fully acknowledged in the 1193 Contributors section. 1195 The Contributors section may include brief statements about the 1196 nature of particular contributions ("Sam contributed section 1197 3") and it may also include affiliations of listed 1198 contributors. At the discretion of the author(s), contact 1199 addresses (see Author's Address section below) may also be 1200 included in the Contributors section, for those contributors 1201 whose knowledge makes them useful future contacts for 1202 information about the RFC. 1204 4.7b Acknowledgment Section 1206 This optional section may be used instead of, or in addition 1207 to, a Contributors section, when appropriate. 1209 4.7c Security Considerations Section 1211 All RFCs must contain a section that discusses the security 1212 considerations relevant to the specification in the RFC; see 1213 [Secur03] for more information. 1215 4.7d IANA Considerations Section 1216 See Section 2.10 above and [IANA98]. 1218 4.7e Appendixes 1220 Many RFC documents have appendices, some of which may be very 1221 extensive. Common practice is to position Appendixes at the 1222 very end of a document, after the references. However, a 1223 significant set of RFCs have large and dense Appendix sections 1224 for technical details, which are actually an integral part of 1225 the document. In this case, it can be difficult to locate the 1226 references. We therefore recommend that, in general, 1227 references follow the Appendixes in an RFC. 1229 4.7f References Section 1231 There are many styles for references, and the RFCs have one of 1232 their own. Please follow the reference style used in recent 1233 RFCs; in particular, see the Reference section of this RFC for 1234 an example. (Note: the ordering of multiple authors is 1235 intended to be as shown.) On the other hand, there is no 1236 required format for a citation; see the discussion in Section 1237 2.7. 1239 A reference to an RFC that has been assigned an STD, BCP, or 1240 FYI subseries number must include the subseries number of the 1241 document. 1243 Reference lists must indicate whether each reference is 1244 normative or informative. For example, the reference section 1245 might be split into two sections, e.g.: 1247 s. Normative References 1249 xxx 1250 ... 1251 xxx 1253 s+1. Informative References 1255 xxx 1256 ... 1257 xxx 1259 Non-normative references to Internet-Drafts are allowed, but 1260 they must take the following restricted form: the author(s), 1261 the title, the phrase "Work in Progress", and the date; for 1262 example: 1264 [doe13] Doe, J., "The Deployment of IPv6", 1265 Work in Progress, May 2013. 1267 Normative references to Internet Drafts will cause publication 1268 of the RFC to be suspended until the referenced draft is also 1269 ready for publication; the RFC Editor will then replace the 1270 reference by an RFC reference and publish both simultaneously. 1272 The use of URLs in references in RFCs is discouraged, because 1273 URLs are often not stable references. Exceptions will be made 1274 in certain cases where the World Wide Web is demonstrably the 1275 most stable reference available. 1277 4.8 Author's Address Section 1279 This required section gives the name(s) and contact information 1280 for the author(s) listed in the first-page header. Contact 1281 information must include at least one, and ideally would include 1282 all, of a postal address, a telephone number and/or FAX number, 1283 and a long-lived email address. The purpose of this section is to 1284 (1) unambiguously define author/contributor identity (e.g., the 1285 John Smith who works for FooBar Systems) and to (2) provide 1286 contact information for future readers who have questions or 1287 comments. Note that some professional societies offer long-lived 1288 email addresses for their members. 1290 4.9 IPR Boilerplate 1292 The IPR boilerplate is dictated by BCP 78 (RFC 3667) [IPC04] and 1293 BCP 79 (RFC 3668) [IPT04]. It includes a full notice of copyright 1294 by the Internet Society, and an IETF disclaimer on intellectual 1295 property rights over the contents. The actual text is reproduced 1296 in Appendix A. 1298 A specific request from the IAB is required before the RFC Editor 1299 can include a dual copyright, or for any other variation of the 1300 standard ISOC copyright notice. 1302 An RFC should not contain a notice of the existence of relevant 1303 intellectual property (patents, etc.). That is, the Intellectual 1304 Property notice at the end of the document should be *all* that is 1305 said about IPR in the document. 1307 5. Intellectual Property 1309 RFC publication is intertwined with issues of intellectual property 1310 (IP). The following two distinct kinds of IP issues for RFCs are 1311 sometimes confused. 1313 o Rights in Contributions. 1315 This set of issues concerns copyright protection on the RFC text 1316 as a document. The present rules for rights in contributions 1317 are contained in BCP 78 (RFC 3667) [IPC04]. These rules call 1318 for a Copyright Statement in every RFC (see Section 4.9 and 1319 Appendix A). 1321 BCP 78 specifies the copyright rules applicable to RFCs, 1322 aligning these rules with modern copyright law. The resulting 1323 rules are generally intended to continue the historical RFC 1324 Editor policy of maximal freedom for distribution of RFCs. It 1325 adds safeguards for the integrity, future availability, and 1326 usefulness of published RFCs but otherwise preserves author 1327 rights. For example, a published RFC must be open to reading by 1328 anybody, and it must be protected against alteration after it is 1329 published. 1331 o Rights to Technology 1333 An RFC may describe technology -- e.g., a protocol or other 1334 technical specification -- that is subject to intellectual 1335 property right (IPR) claims (e.g., through patents). The 1336 present rules for this case are contained in BCP 79 (RFC 3668) 1337 [IPT04]. 1339 The RFC Editor's responsibility is limited to including a 1340 "Disclaimer of validity" (Section 5 of BCP 79, Appendix A of 1341 this document) in all IETF submissions and in most independent 1342 submissions. The RFC Editor may omit this Disclaimer statement 1343 from independent submissions when it is clear that there are no 1344 claimed intellectual property rights on the RFC contents, and 1345 when including the Disclaimer would make little sense. 1347 Note also that an RFC should *not* contain a notice of the 1348 existence of specific relevant intellectual property. For 1349 example, an RFC may not contain a patent number. 1351 The IETF rules for intellectual property [IPC04, IPT04] have the 1352 following specific implications for RFC republication. 1354 5.1 Copying and distributing an entire RFC (including all IPR-related 1355 boilerplate) without changes: 1357 1a. Copying for free redistribution is allowed and 1358 encouraged. This validates the widespread mirroring of 1359 RFCs on many web sites. 1361 1b. Inclusion of RFC copies within other documents or 1362 collections that are distributed for a fee is allowed. 1363 Anyone can take some RFCs, put them in a book, copyright 1364 the book, and sell it. This in no way inhibits anyone 1365 else from doing the same thing, or inhibits any other 1366 distribution of the RFCs. 1368 In this case, it is a courtesy to ask the RFC author(s) 1369 and to provide a copy of the final document or 1370 collection. 1372 5.2 Translating RFCs into other languages 1374 Translation and publication of an entire RFC into another 1375 language is allowed. However, it is courtesy to inform the 1376 RFC author(s) of such translation. 1378 5.3 Copying and distributing an entire RFC with changes in format, 1379 font, etc.: 1381 Changing format, font, etc. is allowed only with permission 1382 of the author(s). With this permission, (1) applies. 1384 5.4 Copying and distributing portions of an RFC: 1386 This is what the lawyers call "preparation of derivative 1387 works". It is allowed under conditions that differ depending 1388 upon the source of the RFC (see BCP 78 for details and 1389 definitions.) 1391 4a. Preparation of derivative works from an RFC that was an 1392 IETF or IAB submission is permited, but only for use 1393 within the IETF standards process. Proper credit and 1394 citations must be provided (BCP 78 Section 3.3(a)). 1396 4b. Preparation of derivative works from an RFC that was an 1397 independent submission is permitted. Proper credit and 1398 citations must be provided (BCP 78 Section 4.2(a)). 1400 6. RFC Information and Contacts 1402 ************************************************************ 1403 * * 1404 * RFC Editor Email: rfc-editor@rfc-editor.org * 1405 * * 1406 * * 1407 * RFC Editor URL: http://www.rfc-editor.org * 1408 * * 1409 * * 1410 ************************************************************ 1412 In particular, authors should look for the latest version of this 1413 document at the URL listed above. 1415 RFC publication announcements are distributed via two mailing lists: 1416 the "IETF-Announce" list and the "RFC-DIST" list. The IETF-Announce 1417 list announces publication of both Internet Drafts and RFCs; 1418 instructions for subscription and unsubscription to this list are 1419 available on the IETF web site www.ietf.org. The RFC-DIST list 1420 announces only RFC publication; subscription information is available 1421 at the RFC Editor URL listed above. 1423 RFC readers should be aware that the many mirrors of RFCs and RFC 1424 indexes that appear on other sites vary a great deal in reliability. 1425 Consulting the official RFC-Editor site listed above is recommended. 1427 7. Security Considerations 1429 This RFC describes the Security Considerations sections of an RFC. 1430 It raises no new security issues itself. 1432 8. Acknowledgments 1434 This memo includes wording taken from a draft written by Robert W. 1435 Shirey of GTE/BBN Technologies, 29 December 1999, with permission. 1436 Shirey's deconstruction of the formatting rules was very helpful in 1437 writing Sections 3 and 4 of the present memo. 1439 We are grateful for the many thoughtful and helpful suggestions made 1440 by IETF participants during the Last Call on a previous version of 1441 this document. We especially acknowledge the thorough analysis by 1442 John Klensin. 1444 APPENDIX A: RFC Boilerplate 1446 A.1 Status of Memo 1448 The RFC Editor supplies the appropriate one of the following 1449 boilerplate paragraphs in the Status of the Memo section (see 1450 Section 4.2). 1452 Standards Track 1454 "This document specifies an Internet standards track protocol 1455 for the Internet community, and requests discussion and 1456 suggestions for improvements. Please refer to the current 1457 edition of the "Internet Official Protocol Standards" (STD 1) 1458 for the standardization state and status of this protocol. 1459 Distribution of this memo is unlimited." 1461 Best Current Practice 1463 "This document specifies an Internet Best Current Practices for 1464 the Internet Community, and requests discussion and suggestions 1465 for improvements. Distribution of this memo is unlimited." 1467 Experimental 1469 "This memo defines an Experimental Protocol for the Internet 1470 community. This memo does not specify an Internet standard of 1471 any kind. Discussion and suggestions for improvement are 1472 requested. Distribution of this memo is unlimited." 1474 Informational 1476 "This memo provides information for the Internet community. 1477 This memo does not specify an Internet standard of any kind. 1478 Distribution of this memo is unlimited." 1480 A.2 IPR Boilerplate 1482 At the end of each RFC there must be IPR boilerplate including a 1483 full copyright statement and an IETF disclaimer about rights over 1484 technology. There are two forms, depending upon the source of the 1485 document. 1487 For a document originating in the IETF, these statements will read 1488 as follows [IPC04, IPT04]: 1490 Full Copyright Statement 1491 Copyright (C) The Internet Society (2004). 1493 This document is subject to the rights, licenses and restrictions 1494 contained in BCP 78, and except as set forth therein, the authors 1495 retain all their rights. 1497 This document and the information contained herein are provided on an 1498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1499 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1500 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1501 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1502 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1505 Intellectual Property 1507 The IETF takes no position regarding the validity or scope of any 1508 Intellectual Property Rights or other rights that might be claimed 1509 to pertain to the implementation or use of the technology 1510 described in this document or the extent to which any license 1511 under such rights might or might not be available; nor does it 1512 represent that it has made any independent effort to identify any 1513 such rights. Information on the IETF's procedures with respect to 1514 rights in IETF Documents can be found in BCP 78 and BCP 79. 1516 Copies of IPR disclosures made to the IETF Secretariat and any 1517 assurances of licenses to be made available, or the result of an 1518 attempt made to obtain a general license or permission for the use 1519 of such proprietary rights by implementers or users of this 1520 specification can be obtained from the IETF on-line IPR repository 1521 at http://www.ietf.org/ipr. 1523 The IETF invites any interested party to bring to its attention 1524 any copyrights, patents or patent applications, or other 1525 proprietary rights that may cover technology that may be required 1526 to implement this standard. Please address the information to the 1527 IETF at ietf-ipr@ietf.org. 1529 For an independent submission to the RFC Editor, these statements 1530 take the following form: 1532 Full Copyright Statement 1534 Copyright (C) The Internet Society (2004). 1536 This document is subject to the rights, licenses and restrictions 1537 contained in BCP 78 and at www.rfc-editor.org, and except as set 1538 forth therein, the authors retain all their rights. 1540 This document and the information contained herein are provided on an 1541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1542 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1543 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1544 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1545 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1548 Intellectual Property 1550 The IETF takes no position regarding the validity or scope of any 1551 Intellectual Property Rights or other rights that might be claimed 1552 to pertain to the implementation or use of the technology 1553 described in this document or the extent to which any license 1554 under such rights might or might not be available; nor does it 1555 represent that it has made any independent effort to identify any 1556 such rights. Information on the ISOC's procedures with respect to 1557 rights in ISOC Documents can be found in BCP 78 and BCP 79. 1559 Copies of IPR disclosures made to the IETF Secretariat and any 1560 assurances of licenses to be made available, or the result of an 1561 attempt made to obtain a general license or permission for the use 1562 of such proprietary rights by implementers or users of this 1563 specification can be obtained from the IETF on-line IPR repository 1564 at http://www.ietf.org/ipr. 1566 The IETF invites any interested party to bring to its attention 1567 any copyrights, patents or patent applications, or other 1568 proprietary rights that may cover technology that may be required 1569 to implement this standard. Please address the information to the 1570 IETF at ietf-ipr@ietf.org. 1572 APPENDIX B: RFC Preparation Tools 1574 As indicated earlier, the primary submission format for RFCs is 1575 ASCII text. Authors have found various tools to be useful for 1576 preparing this text in the format required by RFCs and Internet- 1577 Drafts. For more complete and uptodate information, see the RFC 1578 Editor Web page. 1580 This Appendix surveys some of the possibilities. 1582 nroff, groff 1583 The nroff program is widely available for Unix systems, while 1584 its freeware equivalent groff is available for an even wider 1585 range of platforms, including Windows. These programs use 1586 directives in the text to control the formatting. The RFC 1587 Editor, in particular, uses nroff for final RFC formatting. 1588 A template is available as 2-nroff.template. 1590 XML 1591 An XML DTD for RFCs has been developed [XMLrf99] and a tool 1592 to format RFCs from XML source. There is also an XML-to- 1593 nroff translator suitable for creating RFC text. Authors 1594 have had a generally good experience with these tools. 1596 Microsoft Word 1597 Microsoft Word is an important example of a WYSIWYG editor. 1598 RFC 3285 [14] describes in detail how to configure Word to 1599 produce an ASCII text file in RFC format. A version of this 1600 document as a Word file (2-Word.template.rtf) can be used as 1601 a template file to initialize this configuration for entering 1602 and displaying RFCs. There is also a DOS executable 1603 (crlf.exe) for a post-processor to establish RFC end-of-line 1604 conventions in the Word output file. 1606 Note that these template files are suitable only for fairly 1607 simple text formatting; they may be incompatible with the 1608 more advanced features of Word. 1610 LaTeX 1611 LaTeX is widely used for text preparation in many academic 1612 environments. A convenient LaTeX template is available as 1613 2-latex.template. Latex in general does not produce plain 1614 ASCII text in the RFC format, but there are tools that 1615 translate LaTeX to nroff; see the RFC Editor web page. 1617 APPENDIX C: Checklist 1619 Topic | Section of 1620 | this doc. 1621 ___________________________________________________________|___________ 1622 A. Editorial/Content Issues | 1623 | 1624 o Reasonably clear and correct English | 2.3 1625 > Also, run spell checker | 1626 | 1627 o All abbreviations (with a few exceptions) are | 4.7 1628 expanded when they first appear. | 1629 | 1630 o References: | 2.7, 4.7f 1631 > Complete and current | 1632 > Normative and Informative listed separately | 2.7 1633 > Internet Drafts correctly referenced | 4.8 1634 | 1635 o All URLs are suspect: they must be stable. | 2.8 1636 | 1637 o Title: | 2.9 1638 > Descriptive and not misleading. | 1639 > No suspect words, e.g., Proposed, Standard, | 1640 Requirements, Policy. | 1641 > Abbreviations expanded | 1642 | 1643 o Author list not too long | 2.12 1644 | 1645 o Category field correct | 4.1 1646 | 1647 B. Basic Formatting | 3.1 1648 | 1649 o Only printable ASCII characters | 3.1(1), 1650 | 3.1(4) 1651 o No lines exceeding 72 characters | 3.1(2) 1652 [This is especially important for "as is" tables | 1653 and figures, which cannot be easily reformatted by| 1654 the RFC Editor.] | 1655 | 1656 o Maximum page size is 58 lines. [RFC Editor may | 3.1(3) 1657 re-paginate, but this limit may be an issue for | 1658 large "as is" tables and figures. | 1659 | 1660 o Must be ragged-right | 3.1(5) 1661 | 1662 o No word-breaking hyphenation at end of line | 3.1(6) 1663 | 1664 o Two blanks after periods ending sentences | 3.1(7) 1665 | 1666 o No footnotes (end notes OK) | 3.1(8) 1667 | 1668 o Line spacing OK | 3.1(9) 1669 | 1670 o Pages numbered | 3.1(10) 1671 | 1672 o Running headers and footers OK | 3.3 1673 | 1674 o Formatted for easy reading; consistent spacing and | 1675 indentation | 3.1(12) 1676 | 1677 o "Big-Endian" data definitions | 3.4 1678 | 1679 C. Required Sections supplied by author | 4 1680 | 1681 o Abstract | 4.5 1682 > Clarity and content OK | 1683 > Reasonable length | 1684 > All abbreviations expanded | 1685 > No references | 1686 > Unnumbered section | 1687 | 1688 o Body of the Memo | 4.7 1689 > Security Considerations | 4.7c 1690 | 1691 o Author's Address | 4.8 1692 | 1693 D. Other Sections | 1694 | 1695 o Table of Contents | 4.6 1696 > Must be present in large document | 1697 | 1698 o Body of the Memo | 4.7 1699 > Contributors and/or Acknowledgments | 4.7a, b 1700 > IANA Considerations, if needed | 4.7d 1701 > Appendixes | 4.7e 1702 > References | 4.7f 1703 | 1705 APPENDIX D: Changes from RFC 2223 1707 In general, this document contains the following major changes 1708 from RFC 2223. 1710 o Section 1: Introduction 1712 The Introduction section was completely rewritten, using material 1713 from several sections of RFC 2223, bringing the discussion into 1714 conformance with RFC 2026 and adding additional clarification. 1716 o Section 2: General RFC Editorial Policies 1718 This section combines material from several sections of RFC 2223. 1719 New material is included about the RFC Editor errata page, 1720 normative references, URLs, titles, RFC number pre-assignment, 1721 author lists, and IANA Considerations. 1723 Major procedural changes include: (1) publication of an RFC in 1724 both ASCII and PostScript versions now requires that both be 1725 published simultaneously, (2) all listed authors must give 1726 approval during the "Authors' 48 Hour" process, (3) long author 1727 lists are generally prohibited, and (4) a Contributors section is 1728 defined as an alternative to long author lists. 1730 o Section 3: General Format Rules 1732 This section is expanded with much additional explanatory 1733 material. For example: 1735 (1) The requirement for printable ASCII characters is 1736 stated, and the use of CR, LF, and FF is clarified. 1738 (2) The requirement for page numbers in specified. 1740 (3) The requirement for running headers and footers is 1741 specified. 1743 o Section 4: Required Sections in an RFC 1745 This section is reorganized to cover all the required sections of 1746 an RFC in order. It adds the current conventions for formatting 1747 multiple author names and organizations, and it defines section 1748 ordering more precisely. 1750 This section describes five major changes in RFC formatting. 1752 (1) The style and contents of the Abstract section are more 1753 completely specified, in order to make RFC abstracts 1754 useful for searching and indexing. 1756 (2) A Table of Contents section is required or recommended 1757 in all but very short RFCs. 1759 (3) Separate lists are now required for normative references 1760 and informative references. 1762 (4) A new optional section, Contributors, is defined. 1764 (5) The intellectual property boilerplate was updated. 1766 o Appendixes 1768 Former Appendix A, which contained the source for the fix.pl 1769 post-processor Perl script and an nroff RFC template, has been 1770 removed. These files are available at the RFC Editor web site. 1772 Appendix B, RFC Preparation Tools, and Appendix C, Checklist, are 1773 new. 1775 Normative References 1777 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1778 Requirement Levels", BCP 14, RFC 2119, March 1997. 1780 [IPC04] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1781 3667, February 2004. 1783 [IPT04] Bradner, S., "Intellectual Property Rights in IETF 1784 Technology", BCP 79, RFC 3668, February 2004. 1786 [RFCed] RFC Editor web page, "http://www.rfc-editor.org". 1788 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1789 3", BCP 9, RFC 2026, October 1996. 1791 Informative References 1793 [ASCII69] Cerf, V., "ASCII Format for Network Interchange", RFC 20, 1794 October 1969. 1796 [BCP95] Postel, J., Li, T. and Y. Rekhter, "Best Current 1797 Practices", BCP 1, RFC 1818, August 1995. 1799 [FYI90] Malkin, G. and J. Reynolds, "F.Y.I. on F.Y.I. -- 1800 Introduction to the F.Y.I. Notes", FYI 1, RFC 1150, March 1801 1990. 1803 [Hist99] RFC Editor et al., "30 Years of RFCs", RFC 2555, April 1804 1999. 1806 [IANA98] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1807 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1808 October 1998. 1810 [IDguide] IETF, "Guidelines to Authors of Internet Drafts". 1811 Available as 1id-guidelines.txt at http://www.ietf.org. 1813 [IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", Internet 1814 Experimental Note (IEN) 137, 1 April 1980. A longer 1815 version is published in IEEE Computer Magazine, pp 48-54, 1816 October 1981. 1818 [Lang01] IESG, "Guidance for the use of formal languages in IETF 1819 specifications", http://www.ietf.org/IESG/STATEMENTS, 1820 October 2001. 1822 [Secur03] Rescorla, E., Korver, B., and Internet Architecture Board, 1823 "Guidelines for Writing RFC Text on Security 1824 Considerations", Work in Progress, January 2003. 1826 [STD1] Internet Engineering Task Force, Reynolds, J., Braden, R., 1827 Ginoza, S., and A. De La Cruz, Ed., "Official Internet 1828 Protocol Standards", STD 1. Latest version RFC 3300, 1829 November 2002. 1831 [STD92] Postel, J., Editor, "Introduction to the STD Notes", RFC 1832 1311, March 1992. 1834 [TLD99] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names", 1835 RFC 2606, June 1999. 1837 [Word02] Gahrns, M. and T. Hain, "Using Microsoft Word to create 1838 Internet Drafts and RFCs", RFC 3285, May 2002. 1840 [XMLrf99] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1841 1999. 1843 CHANGES (To be removed by RFC Editor before publication) 1845 Changes from -07 version 1847 1. The intellectual property discussion and boilerplate was updated 1848 to incorporate the current rules in BCP 78, BCP 79. 1850 2 The term "individual submission" was changed to "independent 1851 submission", to avoid confusion with documents that are 1852 submitted to the IESG by individuals (rather than working 1853 groups) and are then published by the RFC Editor as official 1854 IETF documents. 1856 Changes from -06 version 1858 1. Changed document status from BCP to Informational. All RFC 1859 Editor policy documents have been Informational RFCs. 1861 2. Eliminated duplicate wording (numbers numbers) [1.1]. 1863 Changes from -05 version 1865 1. Add Section 2.16 on Intellectual Property [2.16]. 1867 2. Note that all major contributors must be acknowledged [2.12]. 1869 3. Note that the RFC Editor fills in the sub-series number and the 1870 Categories field of the header, as well as the Status of this 1871 Memo field [4.1, 4.2]. 1873 4. Specify that internal cross references within the body of the 1874 memo should use section numbers, not page numbers [4.7]. 1876 5. Separate the list of changes that have been made in successive 1877 Internet Draft versions of this document from Appendix D, which 1878 summarizes changes from RFC 2223. The former material is to be 1879 removed before publication. 1881 6. Reduce the set of normative references. 1883 7. Correct several minor nits. 1885 Changes from -04 version 1887 1. Replace overloaded "Status" attribute name with "Category" 1888 [1.1]. 1890 2. Clarify the relation of this document to RFC 2026 [1.2]. 1892 3. Clarify the submission rules, including rules for IAB and IRTF 1893 documents and for BCPs [1.2] 1895 4. Specify that RFC Editor reviews independent submissions for 1896 content as well as format [1.2.1]. 1898 5. Document "Do Not Publish Now" recommendation from the IESG 1899 [1.2.1]. 1901 6. Distinguish between the plain text format and the US-ASCII 1902 character set [2.4, 3.1]. 1904 7. Clarify the distinction between citation format and reference 1905 format, and use a more appropriate format for citations in this 1906 document [2.7]. 1908 8. State that RFC 2119 is not required, but some meaning must be 1909 defined for capitalized applicability words [2.14]. 1911 9. Checking of MIBs and other formal languages [2.15] 1913 10. Clarify that Section 3 defines published format, not submission 1914 format [3.]. 1916 11. Reorganize the sections in section 4 to clarify and simplify the 1917 section ordering rules, and move appendixes to match our 1918 recommendation [4]. 1920 12. Suggest Glossary [4.7]. 1922 13. Fix many typos reported by ever-vigilant IETF members. 1924 Changes from -03 version 1926 1. Combine sections 1.3.1 and 1.3.2 into one section 1.3.1. 1928 2 Clarify the section ordering rules in section 4. 1930 Changes from -02 version 1932 1. Removed old Appendix C (definition of ASCII) and replace it with 1933 a reference to RFC 20. 1935 2 Added new Appendix C, a Checklist. 1937 3 Made a few editorial changes and typo fixes. 1939 4 Clarified that .txt.pdf versions are equally authoritative with 1940 .txt versions of RFCs. 1942 5 Stated policy that (nearly) all abbreviations in body of the 1943 document must be expanded when first encountered. 1945 Changes from -01 version 1947 1. Incorporated new author list guidelines. 1949 2. Clarified rules for hyphenation (Section 3.1 (6)). 1951 3. Added guideline on example URLs (Section 2.8). 1953 4. Clarified that dangling normative references are strictly 1954 prohibited only for standards-track documents (Section 2.7). 1956 Authors' Addresses 1958 Joyce K. Reynolds 1959 RFC Editor 1960 4676 Admiralty Way 1961 Marina del Rey, CA 90292 1963 EMail: rfc-editor@rfc-editor.org 1965 Robert Braden 1966 RFC Editor 1967 4676 Admiralty Way 1968 Marina del Rey, CA 90292 1970 EMail: rfc-editor@rfc-editor.org 1972 Full Copyright Statement 1974 Copyright (C) The Internet Society (year). This document is subject 1975 to the rights, licenses and restrictions contained in BCP 78, and 1976 except as set forth therein, the authors retain all their rights. 1978 This document and the information contained herein are provided on an 1979 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1980 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1981 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1982 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1983 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1984 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 1986 Intellectual Property 1988 The IETF takes no position regarding the validity or scope of any 1989 Intellectual Property Rights or other rights that might be claimed to 1990 pertain to the implementation or use of the technology described in 1991 this document or the extent to which any license under such rights 1992 might or might not be available; nor does it represent that it has 1993 made any independent effort to identify any such rights. Information 1994 on the ISOC's procedures with respect to rights in ISOC Documents can 1995 be found in BCP 78 and BCP 79. 1997 Copies of IPR disclosures made to the IETF Secretariat and any 1998 assurances of licenses to be made available, or the result of an 1999 attempt made to obtain a general license or permission for the use of 2000 such proprietary rights by implementers or users of this 2001 specification can be obtained from the IETF on-line IPR repository at 2002 http://www.ietf.org/ipr. 2004 The IETF invites any interested party to bring to its attention any 2005 copyrights, patents or patent applications, or other proprietary 2006 rights that may cover technology that may be required to implement 2007 this standard. Please address the information to the IETF at ietf- 2008 ipr@ietf.org.