idnits 2.17.1 draft-rfc-editor-rfc2223bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines 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' ) == 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: ---------------------------------------------------------------------------- == 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 (26 August 2003) is 7549 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC' is mentioned on line 632, but not defined == Missing Reference: 'Required' is mentioned on line 1001, but not defined -- Looks like a reference, but probably isn't: '14' on line 1420 -- Looks like a reference, but probably isn't: '4' on line 1729 == Unused Reference: 'IPR03' is defined on line 1603, but no explicit reference was found in the text == Unused Reference: 'Word02' is defined on line 1659, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (ref. 'IPR03') (Obsoleted by RFC 7322) -- Duplicate reference: RFC2223, mentioned in 'IPS03', was also mentioned in 'IPR03'. ** Obsolete normative reference: RFC 2223 (ref. 'IPS03') (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3300 (ref. 'STD1') (Obsoleted by RFC 3600) -- 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 3285 (ref. 'Word02') (Obsoleted by RFC 5385) -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. 'XMLrf99') (Obsoleted by RFC 7749) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Reynolds, Editor 3 draft-rfc-editor-rfc2223bis-07.txt R. Braden, Editor 4 Obsoletes: 2223 RFC Editor 5 Category: Informational 26 August 2003 6 Expires: February 2004 8 Instructions to Request for Comments (RFC) Authors 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo provides information for authors of Request for Comments 38 (RFC) documents. It summarizes RFC editorial policies and formatting 39 requirements, addresses frequently-asked questions, and serves as a 40 model for constructing a properly formatted RFC. 42 Table of Contents 44 1. Introduction .................................................. 3 45 1.1 Background on the RFC Document Series ..................... 3 46 1.2 Introduction to the RFC Publication Process ............... 4 47 2. General RFC Editorial Policies ............................... 7 48 2.1 Immutability .............................................. 7 49 2.2 Not all RFCs are Standards ................................ 8 50 2.3 Publication Language ...................................... 8 51 2.4 Publication Format(s) ..................................... 8 52 2.5 Consistent Document Style ................................. 9 53 2.6 Assignment of RFC Numbers ................................. 10 54 2.7 References and Citations .................................. 10 55 2.8 URLs in RFCs .............................................. 11 56 2.9 Titles .................................................... 11 57 2.10 IANA Considerations ...................................... 12 58 2.11 Relation to Other RFCs ................................... 12 59 2.12 Authors Listed on RFCs ................................... 13 60 2.13 April 1 RFCs ............................................. 14 61 2.14 Requirement-Level Words .................................. 15 62 2.15 Formal Languages in RFCs ................................. 15 63 2.16 Intellectual Property .................................... 15 64 3. General Format Rules for RFCs ................................. 16 65 3.1 General Formatting Rules .................................. 17 66 3.2 PostScript Format Rules ................................... 20 67 3.3 Header and Footer Formats ................................. 20 68 3.4 Protocol Data Definitions ................................. 21 69 4. Sections in an RFC ............................................ 22 70 5. RFC Information and Contacts .................................. 29 71 6. Security Considerations ....................................... 29 72 7. Acknowledgments ............................................... 29 73 Appendix A - RFC Boilerplate ..................................... 30 74 Appendix B - RFC Preparation Tools ............................... 31 75 Appendix C - Checklist ........................................... 32 76 Appendix D - Changes from RFC 2223 ............................... 34 77 Normative References ............................................. 35 78 Informative References ........................................... 36 79 CHANGES (To be removed by RFC Editor before publication) ......... 37 80 Authors' Addresses ............................................... 39 82 1. Introduction 84 This memo provides information for authors of Request for Comments 85 (RFC) documents. It summarizes RFC editorial policies and formatting 86 requirements, addresses frequently-asked questions, and serves as a 87 model for constructing a properly formatted RFC. 89 1.1 Background on the RFC Document Series 91 The Requests for Comments documents, commonly known as RFCs, form 92 an archival series of more than 3500 memos about computer 93 communication and packet switching networks. Included prominently 94 in the RFC series are the official technical specifications of the 95 Internet protocol suite; these are defined by the Internet 96 Engineering Task Force (IETF) under the direction of the Internet 97 Engineering Steering Group (IESG). As a result, RFC publication 98 plays a significant role in the Internet standards process 99 [RFC2026]. 101 The RFC series was begun in 1969 as a set of technical and 102 organizational notes by the ARPAnet research community. Since the 103 early 1980s, the series has focused on the development of the 104 Internet and the TCP/IP protocol suite. Memos in the RFC series 105 discuss many aspects of networking, including protocols, 106 procedures, programs, and concepts as well as meeting notes, 107 opinions, and sometimes humor. For more information on the 108 history of the RFC series, see RFC 2555, "30 Years of RFCs" 109 [Hist99]. 111 RFCs are numbered (roughly) consecutively, and these numbers 112 provide a single unique label space for all RFCs. RFCs are 113 published on-line through a number of repositories (see [RFCed]), 114 and there is an online index of RFCs. 116 Each RFC is labeled with a category: Standards Track, Best Current 117 Practice, Experimental, Informational, or Historic. 119 Note on terminology: The Category attribute of an RFC has 120 sometimes been called its status, but the term "status" has 121 been overloaded. In the early years, it was used to mean the 122 "requirement level" of a specification, e.g., "Required" or 123 "Elective" (see, for example, RFC2400.) Later this single 124 status attribute proved too simplistic, so it was replaced by 125 more general Applicability Statements [RFC2026]. Still 126 later, we began to refer to the "category" as the "status" 127 (see e.g., the wording for the Standards Track Status of this 128 Memo, shown in Appendix A). However, this attribute has 129 always appeared on RFCs as the Category (see Section 4.1.) 131 RFCs in the Standards Track category are published on behalf of 132 the IESG. The IESG assigns a maturity level -- Proposed Standard, 133 Draft Standard, or Standard -- to each Standards Track RFC. The 134 current maturity levels of all Standards Track RFCs are specified 135 in STD 1, "Official Internet Protocol Standards" [STD1] and in the 136 RFC index; they are not specified on the RFCs themselves. 138 In addition to the master RFC index, there are secondary indexes 139 for useful subsets or "sub-series" of the RFCs. Three sub-series 140 are in use: 142 o STD document -- Category is Standards Track, maturity level 143 is Standard [STD92]. 145 o BCP document -- Category is Best Current Practice [BCP95] 147 o FYI document (For Your Information) -- Category is 148 Informational [FYI90] 150 An RFC in a sub-series is labeled with its sub-series number as 151 well as its RFC number. 153 The RFC series is published by the RFC Editor, under funding 154 provided by the Internet Society (ISOC) and under the supervision 155 of the Internet Architecture Board (IAB). The RFC Editor is 156 responsible for the final editorial review and the on-line 157 publication of RFCs. The RFC Editor also maintains the official 158 RFC archive and the index files and makes these accessible via the 159 Web, FTP, and email [RFCed]. The RFC Editor also maintains a list 160 of errata for previously-published RFCs. 162 In performing these functions, the RFC Editor works closely with 163 the IESG and with the Internet Assigned Numbers Authority (IANA). 164 Since 1977, the RFC Editor function has been performed by staff at 165 the Information Sciences Institute of the University of Southern 166 California (USC/ISI). 168 1.2 Introduction to the RFC Publication Process 170 This section contains a brief overview of the submission, review, 171 and publication process for RFCs. More details, especially for 172 standards-track RFCs, will be found in RFC 2026, "The Internet 173 Standards Process -- Revision 3" [RFC2026], as amended by later 174 IESG policy statements. RFC 2026 or its successor takes 175 precedence in the case of any apparent conflict with this 176 overview. 178 1.2.1 RFC Submission and Review 180 To be considered for publication as an RFC, a document must 181 first be submitted as an Internet-Draft (I-D) [RFC2026]. This 182 ensures an opportunity for feedback from members of the 183 Internet community and from the IESG. The Internet Draft must 184 include boilerplate that allows RFC publication (see 185 "Guidelines to Authors of Internet-Drafts" [IDguide]). 187 The submission and review procedures for RFCs depend upon the 188 document's source. RFC submissions may come from the IETF, 189 from the IAB, from the Internet Research Task Force (IRTF), or 190 from an individual. 192 o Submission from the IETF 194 RFCs originating in the IETF are submitted to the RFC Editor 195 via the IESG, which reviews them for technical quality and 196 procedural conformance. These IESG submissions are 197 transmitted to the RFC Editor via official "Protocol Action" 198 messages that are recorded at the IETF web site. 199 Submissions through the IESG may be in any of the categories 200 (Standards Track, Best Current Practice, Experimental, 201 Informational, or Historic.) All submissions in the 202 Standards Track or Best Current Practice category must first 203 be submitted to the IESG for approval; the IESG will submit 204 them to the RFC Editor. 206 At IESG request, the RFC Editor will add an "IESG Note" to a 207 published RFC, to provide clarification or guidance to 208 readers. 210 o Submission from the IAB 212 The IAB may submit documents directly to the RFC Editor for 213 publication as RFCs in the Informational or Experimental 214 category, without IESG approval or review. 216 o Individual Submission 218 Individuals may submit documents directly to the RFC Editor 219 for publication as RFCs in the Experimental or Informational 220 category. 222 The RFC Editor reviews each such individual submission for 223 relevancy and appropriateness as well as general compliance 224 with the rules in Sections 2, 3 and 4 of this document. 225 Updates are requested as necessary, sometimes through 226 several iterations, until an acceptable submission document 227 is achieved. 229 To maintain the integrity of the RFC document series and to 230 avoid wasting scarce publication resources, the RFC Editor 231 may occasionally determine that a submission is not 232 publishable because of its content or its form. In such a 233 case, the RFC Editor will attempt to explain as clearly and 234 completely as possible the reasons for rejection. The RFC 235 Editor is always hopeful of a miracle -- that a bad document 236 will re-emerge as a good document -- and occasionally it 237 happens! 239 Once the document is clearly publishable, the RFC Editor 240 passes the document to the IESG for review for conflicts 241 with works in progress in the IETF [RFC2026]. When the 242 topic of an individual submission is closely related to an 243 existing IETF Working Group, the IESG may request that the 244 author coordinate with that working group. This may result 245 in the production of a revised memo that eventually emerges 246 from the IETF process as an IETF submission. The IESG may 247 also suggest improvements to the author of the document 248 prior to publication. 250 If the IESG feels that the submitted document is 251 inappropriate material for publication as an RFC, they will 252 make a "Do Not Publish" recommendation to the RFC Editor. 253 The RFC Editor may then reject the document, or publish it 254 with an "IESG Position" statement that defines their 255 objections to the document or narrows its scope of 256 applicability. The IESG may also ask for deferred 257 publication, in a maximum of two six-month increments. The 258 RFC Editor makes the final decision about publication of 259 individual submissions. 261 o Submission from the IRTF 263 RFC submissions from IRTF members are treated as individual 264 submissions. 266 1.2.2 RFC Publication 268 A document that is submitted to the RFC Editor enters the 269 RFC Editor's queue, which is publicly accessible at the RFC 270 Editor Web site [RFCed]. The RFC remains in the queue until 271 it is published or until the IESG or the author requests 272 that it be removed. 274 The RFC Editor ensures that the document follows the 275 editorial rules described later in this document. The RFC 276 Editor may make editorial changes to clarify readability and 277 to provide a uniform style and format. If excessive work is 278 required to satisfy the rules and/or to bring the RFC up to 279 publication quality, the memo may be returned to the author 280 or to the IESG for additional work. 282 When editing of the document is complete, the RFC Editor 283 sends the result to the authors for careful proof-reading. 284 This quality control step is critical to maintaining the 285 quality of RFCs. Although this process is traditionally 286 called the "Authors' 48 Hours" period, the RFC Editor is 287 always willing to give authors reasonable additional time to 288 review the document, and a document will not be published 289 until all its listed authors agree. While it is helpful to 290 have one principal author during the editing process, all 291 listed authors will be considered responsible for the 292 correctness of the final document. 294 In practice, the editorial process among the IESG, the RFC 295 Editor, and the author(s) can be lengthy and convoluted, and 296 the time spent in the RFC Editor's queue can vary greatly. 297 Sometimes problems are found that require document revisions 298 by the authors. These revisions may require the publication 299 of another Internet-Draft, and the result must be re- 300 reviewed. Publication may be held up awaiting IANA 301 assignments, or in order to synchronize the publication of 302 related RFCs. 304 2. General RFC Editorial Policies 306 This section summarizes some general editorial and publication 307 policies for RFCs. Individual policies may be modified or new 308 policies added by the RFC Editor and the IESG, before the present 309 document is revised. RFC authors should obtain the latest policy 310 statements (see "News") from the RFC Editor web page [RFCed]. 312 2.1 Immutability 314 Since the RFCs form an archival series, an RFC cannot be altered 315 once it is published. To change the contents of an RFC, a new RFC 316 must be written that obsoletes the previous one. (Early in the 317 history of RFCs, the Editor did occasionally make small editorial 318 changes after publication, but this led to confusion regarding 319 which version was correct, and it was a slippery slope. To avoid 320 these pitfalls, the never-change rule is now strictly enforced.) 321 Although RFCs are subjected to careful scrutiny by the RFC Editor 322 and the authors before publication, errors do sometimes creep in. 323 For this reason, the RFC Editor strongly urges the authors to 324 thoroughly review the document during the "Authors' 48 hours" 325 period. 327 The RFC Editor maintains an online list of errata for existing 328 RFCs. If you find what you believe to be an error in an RFC, 329 consult the errata page at the RFC Editor web site [RFCed]. If 330 the bug is not listed, please send email to the authors of the 331 document and to the RFC Editor. 333 2.2 Not all RFCs are Standards 335 Eager salesmen have been known to imply that all RFCs represent 336 official Internet standards. This is false and misleading. While 337 some RFCs are Standards Track documents, many have other 338 categories and do not represent a standard of any kind. 340 2.3 Publication Language 342 Like the Internet itself, the IETF and the Internet Society are 343 international organizations with participation from all areas of 344 the world. However, English is the primary language in which IETF 345 business is conducted, and English is the official publication 346 language for RFCs. 348 RFCs submitted for publication are required to meet a reasonable 349 standard for clear and correct English. 351 RFC 2026 specifically allows RFCs to be translated into languages 352 other than English. Repositories may exist for RFCs that have 353 been translated into particular languages. This is highly 354 desirable and useful. However, it is not possible for the RFC 355 Editor to certify that such translations are accurate. Therefore, 356 the function of the RFC Editor, with respect to non-English RFCs, 357 is limited to providing pointers to non-English language RFC 358 repositories. Upon request, the RFC Editor will list any such 359 repository on its Web page. 361 2.4 Publication Format(s) 363 RFCs are published as plain text files in the [US-]ASCII character 364 set, with the file name extension ".txt". 366 The continued use of ASCII plain text for RFCs, despite the 367 spread of "more modern" formats, is intermittently debated by 368 the Internet community. The consensus continues to be that 369 the great advantages of ASCII plain text -- the ability to 370 readily edit, cut-and-paste, and search documents, the 371 ubiquitous availability of tools for these functions, and the 372 longevity of US-ASCII as a character standard -- make ASCII 373 plain text the clear winner. 375 For the convenience of those whose operating systems have 376 difficulty supporting plain ASCII text, the RFC Editor also 377 maintains PDF files that are exact facsimiles of the plain text 378 versions. These PDF files, with suffix .txt.pdf, are equally 379 authoritative with the .txt versions. 381 The ASCII plain text version (and its .txt.pdf facsimile) is 382 always the official specification, and it must adequately and 383 completely define the technical content. (A very few exceptions 384 have been made over the 30 year history of RFCs, allowing a 385 definitive PostScript (.ps) version with no .txt version.) The 386 primacy of the ASCII version typically requires that the critical 387 diagrams and packet formats be rendered as "ASCII art" in the .txt 388 version. 390 However, secondary or alternative versions in PostScript and/or 391 PDF are provided for some RFCs, to allow the inclusion of fancy 392 diagrams, graphs, or characters that cannot possibly be rendered 393 in ASCII plain text. If there is a PostScript or PDF version of 394 the document, the author should inform the RFC Editor at the time 395 of submission of the .txt version. 397 PostScript and PDF versions suffer from a serious flaw: the RFC 398 Editor cannot easily make editorial changes in the source file to 399 produce a new document in either of these formats. This can make 400 the editorial process for .ps and .pdf versions somewhat painful 401 for both the author and editor. The following procedure is 402 followed. When a .ps (or .pdf) version is submitted with a .txt 403 version, the RFC Editor will first edit the .txt version. The 404 final form of the .txt version (or, when feasible, the diffs) will 405 be returned to the author. The author must then update the 406 .ps/.pdf files to match, as closely as possible, the content and 407 format of the ASCII .txt file. When the RFC Editor agrees that 408 the .ps/.pdf versions are acceptable, they are published 409 simultaneously with the .txt version. 411 2.5 Consistent Document Style 413 The RFC Editor attempts to enforce a consistent style of RFCs. To 414 do this, the RFC Editor may choose to reformat a submitted RFC or 415 ask the author to reformat it. Effort is minimized when the 416 submitted document matches the style of the most recent RFCs. 418 Please read the rules and recommendations that are presented in 419 following sections of this memo and look at some recent RFCs, to 420 adopt an appropriate style. 422 To format most ASCII RFCs for publication, the RFC Editor uses the 423 "nroff" program with a simple set of the formatting commands (or 424 "requests") from the "ms" macro package (see Appendix B). If the 425 author has an nroff source file, it will be helpful to make this 426 available to the RFC Editor when the document is submitted. 428 When a .ps version is published, the RFC Editor will also publish 429 a matching .pdf version. When a .txt version is published, the 430 RFC Editor will also publish a matching .txt.pdf version. 432 2.6 Assignment of RFC Numbers 434 RFC numbers are not assigned until very late in the editorial 435 process, to avoid gaps in the RFC number series. Requests for 436 early assignment of an RFC number are generally denied unless they 437 originate from the IAB or the IESG. 439 2.7 References and Citations 441 An RFC will generally contain bibliographic references to other 442 documents, and the body will contain citations to these 443 references. Section 4.7f specifies the format for the references 444 listed at the end of the RFC body, but there is no required format 445 for a citation. 447 Within an RFC, references to other documents fall into two general 448 categories: "normative" and "informative". Normative references 449 specify documents that must be read to understand or implement the 450 technology in the new RFC, or whose technology must be present for 451 the technology in the new RFC to work. An informative reference 452 is not normative; rather, it provides only additional information. 453 For example, an informative reference might provide background or 454 historical information. Material in an informative reference is 455 not required to implement the technology in the RFC. 457 An RFC must include separate lists of normative and informative 458 references (see Section 4.7f below.) The distinction between 459 normative and informative references is often important. The IETF 460 standards process and the RFC Editor publication process need to 461 know whether a reference to a work in progress is normative. A 462 standards-track RFC cannot be published until all of the documents 463 that it lists as normative references have been published. In 464 practice, this often results in the simultaneous publication of a 465 group of interrelated RFCs. 467 We recommend enclosing citations in square brackets ("[ ]"). 468 Simple numeric citations ("[53]") can cause confusing gaps when 469 the list of references is split between normative and informative. 470 A good alternative is to have two separate series, "[n1]", "[n2]", 471 ... "[i1]", "[i2]" for citations to normative and informative 472 references. Other choices include author abbreviations, possibly 473 a year ("[Smith93]"), and some brief encoding of the title and 474 year ("[MPLS99a]"). 476 2.8 URLs in RFCs 478 The use of URLs in RFCs is discouraged, because many URLs are not 479 stable references. Exceptions may be made for normative 480 references in those cases where the URL is demonstrably the most 481 stable reference available. References to long-lived files on 482 ietf.org and rfc-editor.org are also acceptable. 484 RFCs that include URLs as generic examples must be careful to use 485 the particular example URLs defined in RFC 2606, "Reserved Top- 486 Level DNS Names" [TLD99], to avoid accidental conflicts with real 487 URLs. 489 2.9 Titles 491 Choosing a good title for an RFC can be a challenge. A good title 492 should fairly represent the scope and purpose of the document 493 without being either too general or too specific. 495 Abbreviations (e.g., acronyms) in a title (as well as the Abstract 496 and the body; see Sections 4.5 and 4.7) must generally be expanded 497 when first encountered. The exception is abbreviations that are 498 so common that every participant in the IETF can be expected to 499 recognize them immediately; examples include (but are not limited 500 to) TCP, IP, SNMP, and FTP. Some cases are marginal and the 501 decision on expansion may depend upon the specific title. The RFC 502 Editor will make the final judgment, weighing obscurity against 503 complexity. 505 It is often helpful to follow the expansion with the parenthesized 506 abbreviation, as in the following example: 508 Encoding Rules for the 509 Common Routing Encapsulation Extension Protocol (CREEP) 511 Authors should be aware that the title of an RFC may be subject to 512 policy considerations in addition to the requirement that it 513 provide a concise and technically sound summary of the document 514 contents. For example, at various times in the history of the 515 IETF, the words "Requirements" and "Policies" as well as the 516 phrase "The Directory" have been banned from RFC titles, each for 517 its own reason. 519 RFCs that document a particular company's private protocol must 520 bear a title of the form "XXX's ... Protocol" (where XXX is a 521 company name), to clearly differentiate it from an IETF product. 523 2.10 IANA Considerations 525 Many RFCs define protocol specifications that require the 526 assignment of values to protocol parameters, and some define new 527 parameter fields. Assignment of these parameter values is often 528 (and sometimes must be) deferred until publication of the defining 529 RFC. The IANA and the RFC Editor collaborate closely to ensure 530 that all required parameters are assigned and entered into the 531 final RFC text. 533 Any RFC that defines a new "namespace" of assigned numbers should 534 include an IANA Considerations section specifying how that space 535 should be administered. See "Guidelines for Writing an IANA 536 Considerations Section in RFCs" [IANA98] for a detailed discussion 537 of the issues to be considered and the contents of this section. 539 2.11 Relation to other RFCs 541 Sometimes an RFC adds information on a topic discussed in a 542 previous RFC or completely replaces an earlier RFC. Two terms are 543 used for these cases: Updates and Obsoletes, respectively. 545 Updates 547 Specifies an earlier document whose contents are modified or 548 augmented by the new document. The new document cannot be 549 used alone, it can only be used in conjunction with the 550 earlier document. 552 Obsoletes 554 Specifies an earlier document that is replaced by the new 555 document. The new document can be used alone as a 556 replacement for the obsoleted document. The new document 557 may contain revised information or all of the same 558 information plus some new information, however extensive or 559 brief that new information may be. 561 In lists of RFCs and in the RFC-Index (but not on the RFCs 562 themselves) the following are used for older documents that were 563 referred to by Obsoletes or Updates relations in newer documents: 565 Obsoleted-by 567 Used to specify newer document(s) that replace the older 568 document. 570 Updated-by 572 Used to specify newer document(s) that modify or augment the 573 older document. 575 2.12 Authors Listed on RFC 577 The IESG and IETF have ratified a policy of limiting the number of 578 authors listed in the first page header of an RFC. The specific 579 policy is as follows: 581 (1) A small set of author names, with affiliations, may appear on 582 the front page header. These should be the lead author(s) 583 who are most responsible for the actual text. When there are 584 many contributors, the best choice will be to list the person 585 or (few) persons who acted as document editor(s) (e.g.,"Tom 586 Smith, Editor"). 588 There is no rigid limit on the size of this set, but there is 589 likely to be a discussion if the set exceeds five authors, in 590 which case the right answer is probably to list one editor. 592 The RFC Editor will hold all the people listed on the front 593 page equally responsible for the final form and content of 594 the published RFC. In particular, the "Author's 48 Hours" 595 final approval period will require signoff from all listed 596 authors. 598 (2) An RFC may include a Contributors section, listing those 599 contributors who deserve significant credit for the document 600 contents. The Contributors section is intended to provide a 601 level of recognition greater than an acknowledgment and 602 nearly equal to listing on the front page. The choice of 603 either, both, or none of Contributor and Acknowledgment 604 sections in a particular RFC depends upon the circumstance. 606 (3) The body of an RFC may include an Acknowledgements section, 607 in addition to or instead of a Contributors section. An 608 Acknowledgments section may be lengthy, and it may explain 609 scope and nature of contributions. It may also specify 610 affiliations. 612 (4) The Author's Address section at the end of the RFC must 613 include the authors listed in the front page header. The 614 purpose of this section is to (1) unambiguously define 615 author/contributor identity (e.g., the John Smith who works 616 for FooBar Systems) and to (2) provide contact information 617 for future readers who have questions or comments. 619 At the discretion of the author(s), contact addresses may 620 also be included in the Contributors section for those 621 contributors whose knowledge makes them useful future 622 contacts for information about the RFC. 624 (5) The RFC Editor may grant exceptions to these guidelines upon 625 specific IESG request or in other exceptional circumstances. 627 Finally, it is important to note that the copyright rules 628 governing RFC publication [IPS03] require that an RFC must: 630 "[acknowledge] all major Contributors. A major Contributor 631 is any person who has materially or substantially contributed 632 to the [RFC]." [IPS03] 634 The Contributors and Acknowledgment sections fulfill this 635 objective. 637 2.13 April 1 RFCs 639 Many years ago the RFC Editor established the practice of 640 publishing one or more satirical documents on April 1 of each 641 year. Readers should be aware that many of the RFCs bearing the 642 date April 1 are not to be taken seriously. The RFC Editor 643 reviews April 1 RFC submissions for cleverness, humor, and topical 644 association with computer networking, and a few of the best are 645 published. Submissions must be made to the RFC Editor in time for 646 review and publication. 648 Note that in past years the RFC Editor has sometimes published 649 serious documents with April 1 dates. Readers who cannot 650 distinguish satire by reading the text may have a future in 651 marketing. 653 2.14 Requirement-Level Words 655 Some standards-track documents use certain capitalized words 656 ("MUST", "SHOULD", etc.) to specify precise requirement-levels for 657 technical points. RFC 2119 (BCP 14) [BCP14] defines a default 658 interpretation of these capitalized words in IETF documents. If 659 this interpretation is used, RFC 2119 must be cited (as specified 660 in RFC 2119) and included as a normative reference. Otherwise, 661 the correct interpretation must be specified in the document. 663 Avoid abuse of requirement-level words. They are intended to 664 provide guidance to implementors about specific technical 665 features, generally governed by considerations of 666 interoperability. RFC 2119 says, "Imperatives of the type defined 667 in this memo must be used with care and sparingly. In particular, 668 they MUST only be used where it is actually required for 669 interoperation or to limit behavior which has potential for 670 causing harm (e.g., limiting retransmissions). For example, they 671 must not be used to try to impose a particular method on 672 implementors where the method is not required for 673 interoperability." To simply specify a necessary logical 674 relationship; the normal lower-case words should be used. On the 675 other hand, if the capitalized words are used in a document, they 676 must be used consistently throughout the document. 678 2.15 Formal Languages in RFCs 680 See [Lang01] for IESG guidance on the use of formal languages in 681 RFCs. The RFC Editor will run every MIB through a MIB checker 682 before publication, and machine verification of other formal 683 languages included in RFCs may be required. 685 2.16 Intellectual Property 687 Increasingly, RFC publication is intertwined with issues of 688 intellectual property (IP). The two distinct kinds of IP issues 689 for RFCs are often confused. 691 o Rights in Contributions. 693 This set of issues concerns copyright protection on the RFC 694 text as a document. The governing principle is the desire to 695 make RFCs maximally open, while preserving their integrity. 696 For example, a published RFC must be open to reading by 697 anybody, and it must be protected against alteration after it 698 is published. RFCs can be translated into foreign languages, 699 and with some restrictions they can be republished and 700 abstracted for other documents. 702 The present rules for RFC copyrights are contained in RFC 703 2026 Sections 10.1, 10.2, 10.3 except 10.3.2 and 10.3.3, and 704 10.4(C). These rules call for the Copyright Notice and Full 705 Copyright Statement sections in every RFC (see Sections 4.2 706 and 4.9 below), granting the Internet Society non-exclusive 707 copyright. 709 The statement defining rights in contributions policy is 710 under revision at this time. [IPS03]. 712 o Rights to Technology 714 An RFC may describe technology -- e.g., a protocol or other 715 technical specification -- that is subject to intellectual 716 property right (IPR) claims (normally, through patents.) The 717 present rules for this case are contained in RFC 2026 718 Sections 10.3.2, 10.3.3, and 10.4(A,B,D). These rules are 719 under revision at this time. 721 An RFC should never itself contain an assertion of rights to 722 technology. For example, an RFC may not contain a patent 723 number. 725 RFC 2026 Sections 10.4(A,B) specified standard IPR disclaimer 726 text that the RFC Editor should put in all standards-track 727 RFCs. In practice this has not happened, and it will not 728 happen until the revised rules are adopted. 730 3. General Format Rules for RFCs 732 This section defines the general rules governing the format of a 733 published RFC (as opposed to requirements on submitted documents). 734 Authors are requested to come as close to these rules as reasonable, 735 but in any case the RFC Editor will ensure they are met before 736 publication. For example, the RFC Editor will supply headers and 737 footers, adjust pagination to avoid "widows", and adjust a Table of 738 Contents accordingly. 740 However, author attention to these rules will streamline the 741 publication process and reduce the average publication time. If 742 reaching the final format requires excessive effort by the RFC 743 Editor, the author will be asked to assist in the reformatting. 744 Authors are admonished to proof-read the final publication form 745 carefully, to ensure that no errors accidentally crept in. 747 These formatting rules are intentionally incomplete in some details. 748 They attempt to define only what is strictly necessary for uniformity 749 and simplicity (a virtue). Some latitude is allowed to accommodate a 750 broad range of printers, systems, and evolving requirements. The 751 general objective is to create a series of documents that are 752 reasonably uniform and are easy to read, while accommodating a wide 753 range of content. 755 Note that these rules govern an RFC as published. During the 756 publication process the RFC Editor will verify compliance and will 757 repair minor infractions. 759 3.1 General Formatting Rules 761 (1) Character code 763 The character code is US-ASCII [ASCII69] (also known as ISO 764 646.IRV). Only the printable ASCII characters and the three 765 control characters CR, LF, and FF are allowed. 767 Notes: CR and LF must be used only as provided in rule 768 (2), and FF must be used only as provided in rule (3). 769 Tab (HT) characters and Backspace (BS) characters are 770 never allowed (hence there can be no underlining; see 771 (4) below). 773 (2) Width 775 Each line must be limited to 72 characters followed by the 776 character sequence that denotes an end-of-line (EOL). This 777 limit includes any left-side indentation. 779 Note: A plain-text RFC is expected to be stored on a 780 disk file using the EOL sequence of that system. For 781 example, MS DOS-based systems use the two-character 782 sequence: CR LF (Carriage Return followed by Line Feed), 783 Unix systems use the single character LF for EOL, and 784 EBCDIC systems use the single character NL (New Line). 786 Whenever an RFC is transmitted across the Internet, 787 Internet protocol convention requires that each line of 788 text be followed by the two-character EOL sequence CR LF 789 (Carriage Return followed by Line Feed). A user level 790 protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make 791 the appropriate EOL transformation at each line end. 792 Note that binary transmission of plain-text RFC files 793 can cause the sender's EOL convention to "leak" into the 794 receiver, causing confusion. 796 (3) Height 798 Each page must be limited to 58 lines followed by a Form Feed 799 (FF) character, followed by an EOL sequence. The 58 line 800 limit includes the headers and footers specified below. 802 All pages, except perhaps the first and last, should have the 803 same number of lines when headers and footers are included. 804 That is, footers should not "bounce" from page to page. 806 Note: The maximum line count includes blank lines. 807 However, the first line will normally be the first 808 header line and the last line will be the final footer 809 line; that is, it will not begin or end with a blank 810 line. 812 Note: 58 lines is the maximum; 55 is more commonly used 813 and may actually produce more readable formatting. The 814 recommended page formatting parameters (see Appendix B) 815 produce 55 line pages on many printers, for example. 817 Note: The effect of the Height rule is that the 818 following character sequence will be used: 820 FF 822 ... 824 As transmitted across the Internet as ASCII text, the 825 character sequence is: 827 CR LF FF CR LF 829 CR LF ... 831 Finally, note that the sequence FF CR LF has an 832 ambiguous effect: on some printers, the FF implies an 833 EOL, so this may produce a blank line; on other printers 834 it will produce no blank line. The number 58 and this 835 sequence were designed to render this ambiguity 836 unimportant, assuming the (once predominant) printer 837 standard of 60 lines per page. 839 (4) No Overstriking 841 No overstriking (or underlining) is allowed. 843 (5) No Filling 845 Do not fill the text with extra spaces to provide a straight 846 right margin. Do not right justify the text. 848 (6) No Hyphenation 850 Do not use hyphenation at the right margin to split existing 851 words. However, hyphenated word sequences (e.g., "Internet- 852 Draft") may be split at the hyphen across successive lines. 854 Note: There are good reasons why the right page margin 855 is required to be "ragged", and why hyphenation of words 856 at the right margin is prohibited. Studies have shown 857 that text is harder to read when fixed-size spaces are 858 inserted to adjust the right margins, regardless of 859 which font is used or how smoothly the blank filler is 860 inserted. In addition, when technical text in a fixed- 861 width font is hyphenated at the right margin, the 862 printed result is not only less readable but also ugly. 864 (7) Spaces at the End of a Sentence 866 When a sentence ended by a period is immediately followed by 867 another sentence, there should be two blank spaces after the 868 period. This rule provides clarity when an RFC is displayed 869 or printed with a fixed-width font. 871 (8) Footnotes 873 Do not use footnotes. If such notes are necessary, put them 874 at the end of a section, or at the end of the document. 876 (9) Line Spacing 878 Use single-spaced text within a paragraph, and one blank line 879 between paragraphs. 881 (10) Page Numbering 883 Pages must be numbered consecutively, starting from 1 on the 884 first (cover) page. 886 (11) Headers and Footers 888 RFCs must have running headers and footers, as defined below 889 in Section 3.3. The headers and footers must be separated 890 from the body by at least one and preferably two blank lines. 892 (12) Indentation 894 Successive indentation of sub-subsections (as in this 895 document, for example) is recommended but not required. 896 Experience has shown that indentation by multiples of 3 897 columns works well. In any case, the careful use of 898 indentation can make a very great improvement in the 899 readability of a document. 901 3.2 PostScript Format Rules 903 (1p) Standard page size is 8 1/2 by 11 inches (216 by 279 mm). 905 (2p) Leave a margin of 1 inch (25 mm) on all sides (top, bottom, 906 left, and right). 908 (3p) Main text should have a point size of no less than 10 points 909 with a line spacing of 12 points. 911 (4p) Footnotes and graph notations no smaller than 8 points with a 912 line spacing of 9.6 points. 914 (5p) Three fonts are acceptable: Helvetica, Times Roman, and 915 Courier, plus their bold-face and italic versions. These are 916 the three standard fonts on most PostScript printers. 918 (6p) Prepare diagrams and images based on lowest common 919 denominator PostScript. Consider common PostScript printer 920 functionality and memory requirements. 922 (7p) The following PostScript commands should not be used: 923 initgraphics, erasepage, copypage, grestoreall, initmatrix, 924 initclip, banddevice, framedevice, nulldevice or renderbands. 926 3.3 Header and Footer Formats 928 RFCs must include running headers and footers that obey the 929 following rules. 931 o Running Headers 933 The running header in one line (on page 2 and all subsequent 934 pages) has the RFC number on the left (RFC nnnn), the title 935 (possibly shortened) in the center, and the publication date 936 (Month Year) on the right. 938 o Running Footers 940 All pages contain a one-line running footer, with the author's 941 last name on the left, the category centered, and the page 942 number on the right ("[Page nn]"). 944 If there are two authors, the form "name & name" may be used; 945 for more than two authors, use the form "name, et al." 947 3.4 Protocol Data Definitions 949 Many years ago, the RFC series adopted a pictorial approach to 950 representing data structures such as protocol headers. 951 Furthermore, the research community adopted a "big-endian" 952 convention in which the bits and bytes are shown in network byte 953 order, byte zero is the first byte shown, and bit zero is the most 954 significant bit in a word or a field [IEN137]. 956 For example, RFC 791 contains the following definition of the IP 957 header format. We strongly recommend that a new RFC follow the 958 same formatting conventions, which have been found to work well. 959 Any alternative style must meet the same level of clarity, 960 readability, and lack of ambiguity. An author wishing to use an 961 alternative style should discuss it with the RFC Editor. 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 |Version| IHL |Type of Service| Total Length | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Identification |Flags| Fragment Offset | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Time to Live | Protocol | Header Checksum | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Source Address | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Destination Address | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Options | Padding | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 Example Internet Datagram Header 981 4. Sections in an RFC 983 A published RFC may contain the sections in the following list. Some 984 of these sections are required, as noted. The order shown is 985 required, except that the order shown for the sub-items 7a-7f within 986 Body of Memo is generally recommended but not required. 988 1. First-page header [Required] 989 2. Status of this Memo [Required*] 990 3. Copyright Notice [Required*] 991 4. IESG Note [As requested by IESG*] 992 5. Abstract [Required] 993 6. Table of Contents [Required for large documents] 994 7. Body of the Memo [Required] 995 7a. Contributors 996 7b. Acknowledgments 997 7c. Security Considerations [Required] 998 7d. IANA Considerations 999 7e. Appendixes 1000 7f. References 1001 8. Author's Address [Required] 1002 9. Full Copyright Statement [Required*] 1004 Those sections marked with * will be supplied by the RFC Editor 1005 during the editorial process. 1007 The rules for each of these sections are described below in 1008 corresponding subsections. 1010 The Body of the Memo will normally contain section numbers (or 1011 Appendix labels). Sections listed as 1-6 and 8-9 are to be 1012 unnumbered. 1014 4.1. First-Page Header 1016 Please see the front page of this memo for an example of the front 1017 page heading. On the first page there is no running header. The 1018 top of the first page has the following items left justified: 1020 "Network Working Group" 1022 This traditional title must be left-justified on the first line 1023 of the heading. It denoted the ARPAnet research group that 1024 founded the RFC series. 1026 "Request for Comments: nnnn" 1028 Identifies this as an RFC and specifies the number, left- 1029 justified on the second line. The actual number is filled in 1030 at the last moment prior to publication by the RFC Editor. 1032 "BCP: nn" or 1033 "FYI: nn" or 1034 "STD: nn" 1036 One of these optional left-justified items indicates the sub- 1037 series number, if the RFC is a member of a sub-series. The 1038 actual number is filled in at the last moment prior to 1039 publication by the RFC Editor. 1041 "Updates: nnnn" or "Updates: nnnn, ..., nnnn" 1043 Optional left-justified field, containing an RFC number or a 1044 comma-separated list of RFC numbers that are updated by this 1045 RFC. See Section 2.11. 1047 "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn" 1049 Optional left-justified field, containing an RFC number or a 1050 comma-separated list of RFC numbers that are obsoleted by this 1051 RFC. See Section 2.11. 1053 "Category: xxxxxxxxx" 1055 Required left-justified field specifying the category of this 1056 RFC. Here xxxxxxxx may be one of: Standards Track, Best 1057 Current Practice, Informational, or Experimental. Will be 1058 supplied by RFC Editor, according to request of submittor. 1060 The following information appears right-justified in the header: 1062 Author 1064 The author's name (initial of first given name followed by 1065 family name), right-justified on the first line of the heading. 1067 Organization 1069 The author's organization, indicated on the line following the 1070 Author name. 1072 For multiple authors, each author name appears right-justified 1073 on its own line, followed by that author's organization. When 1074 more than one author has the same organization, the 1075 organization can be "factored out" and appear only once 1076 following the corresponding Author lines. However, such 1077 factoring is not necessary if it results in an unacceptable 1078 reordering of author lines. 1080 The total number of authors is generally limited; see Section 1081 2.12. 1083 Date 1085 The month and year of the RFC Publication, right-justified on 1086 the line after the last Organization line. 1088 The title appears, centered, below the rest of the heading, 1089 preceded and followed by at least one blank line. Periods 1090 ("dots") are not allowed in the title. 1092 The title should be carefully chosen to accurately reflect the 1093 contents of the document. See also Section 2.9. 1095 4.2. Status of this Memo 1097 The RFC Editor will supply a "Status of this Memo" section that 1098 contains two elements: (1) a paragraph describing the category of 1099 the RFC, and (2) the distribution statement. The contents of this 1100 section will be found in Appendix A. 1102 4.3 Copyright Notice 1104 The Copyright Notice section consists of the statement, "Copyright 1105 (C) The Internet Society (date). All Rights Reserved." and is 1106 required. The Full Copyright Statement described in Section 4.12 1107 must also appear at the end of the document. 1109 4.4 IESG Note 1111 This optional section will appear when the IESG requires a warning 1112 or clarifying message on an RFC. 1114 4.5 Abstract 1116 Every RFC must have an Abstract section following the Copyright 1117 notice. An Abstract will typically be 5-10 lines. An Abstract of 1118 more than 20 lines is generally not acceptable. 1120 The Abstract section should provide a concise and comprehensive 1121 overview of the purpose and contents of the entire document, to 1122 give a technically knowledgeable reader a general overview of the 1123 function of the document. In addition to its function in the RFC 1124 itself, the Abstract section text will appear in publication 1125 announcements and in the online index of RFCs. 1127 Composing a useful Abstract generally requires thought and care. 1128 Usually an Abstract should begin with a phrase like "This memo 1129 ..." or "This document ...". A satisfactory abstract can often be 1130 constructed in part from material within the Introduction section, 1131 but a good abstract will be shorter, less detailed, and perhaps 1132 broader in scope than the Introduction. Simply copying and 1133 pasting the first few paragraphs of the Introduction is tempting, 1134 but it may result in an Abstract that is both incomplete and 1135 redundant. Note also that an Abstract is not a substitute for an 1136 Introduction; the RFC should be self-contained as if there were no 1137 Abstract section. 1139 An Abstract should be complete in itself; it should not contain 1140 citations unless they are completely defined within the Abstract. 1141 Abbreviations appearing in the Abstract should generally be 1142 expanded in parentheses. There is a small set of reasonable 1143 exceptions to this rule; see the discussion under Titles, Section 1144 2.9. 1146 4.6 Table of Contents 1148 A Table of Contents (TOC) section is required in RFCs longer than 1149 30 pages and recommended for an RFC longer than 15 pages. 1151 A TOC must be positioned after the Abstract and before the 1152 Introduction section (i.e., after the "boilerplate" and before the 1153 body of the RFC.) 1155 The TOC itself should not be too long or detailed, or it loses 1156 value. For example, if many successive TOC entries point to the 1157 same pages of the memo, the TOC probably needs to be coarser. 1159 No specific format is required, but the following example 1160 illustrates a useful format: 1162 1. INTRODUCTION ............................................... 5 1163 1.1 The Internet Architecture .............................. 6 1164 1.1.1 Internet Hosts .................................... 6 1165 1.1.2 Architectural Assumptions ......................... 7 1166 1.1.3 Internet Protocol Suite ........................... 8 1167 1.1.4 Embedded Gateway Code ............................. 10 1168 1.2 General Considerations ................................. 12 1169 1.2.1 Continuing Internet Evolution ..................... 12 1170 1.2.2 Robustness Principle .............................. 12 1171 1.2.3 Error Logging ..................................... 13 1173 4.7 Body of the Memo 1175 Following the Table of Contents, if any, comes the body of the 1176 memo. Depending upon the length of the TOC, a judicious page 1177 break can improve readability. 1179 Each RFC should have an Introduction section that (among other 1180 things) explains the motivation for the RFC and (if appropriate) 1181 describes the applicability of the document, e.g., whether it 1182 specifies a protocol, provides a discussion of some problem, is 1183 simply of interest to the Internet community, or provides a status 1184 report on some activity. 1186 All abbreviations that are used in the body must be expanded the 1187 first time they occur. A few exceptions will be made for very 1188 well-known abbreviations; see the discussion under Titles in 1189 Section 2.9. 1191 Abbreviation overload is an increasingly common problem in RFCs. 1192 We recommend that complex RFCs include a brief glossary at the 1193 end. On the other hand, a glossary is never a substitute for an 1194 explanation. 1196 Cross references within the body of the text should use section 1197 numbers rather than page numbers, as the RFC Editor generally 1198 adjusts pagination during final editing. The only exception is 1199 the Table of Contents, which necessarily shows page numbers. 1201 4.7a Contributors Section 1203 This optional section lists those contributors who deserve 1204 significant credit for the document. When a long author list 1205 is replaced by a single Editor in the front page header, the 1206 displaced authors can be properly and fully acknowledged in the 1207 Contributors section. 1209 The Contributors section may include brief statements about the 1210 nature of particular contributions ("Sam contributed section 1211 3") and it may also include affiliations of listed 1212 contributors. At the discretion of the author(s), contact 1213 addresses (see Author's Address section below) may also be 1214 included in the Contributors section, for those contributors 1215 whose knowledge makes them useful future contacts for 1216 information about the RFC. 1218 4.7b Acknowledgment Section 1220 This optional section may be used instead of, or in addition 1221 to, a Contributors section, when appropriate. 1223 4.7c Security Considerations Section 1225 All RFCs must contain a section that discusses the security 1226 considerations relevant to the specification in the RFC; see 1227 [Secur03] for more information. 1229 4.7d IANA Considerations Section 1231 See Section 2.10 above and [IANA98]. 1233 4.7e Appendixes 1235 Many RFC documents have appendices, some of which may be very 1236 extensive. Common practice is to position Appendixes at the 1237 very end of a document, after the references. However, a 1238 significant set of RFCs have large and dense Appendix sections 1239 for technical details, which are actually an integral part of 1240 the document. In this case, it can be difficult to locate the 1241 references. We therefore recommend that, in general, 1242 references follow the Appendixes in an RFC. 1244 4.7f References Section 1246 There are many styles for references, and the RFCs have one of 1247 their own. Please follow the reference style used in recent 1248 RFCs; in particular, see the Reference section of this RFC for 1249 an example. (Note: the ordering of multiple authors is 1250 intended to be as shown.) On the other hand, there is no 1251 required format for a citation; see the discussion in Section 1252 2.7. 1254 A reference to an RFC that has been assigned an STD, BCP, or 1255 FYI subseries number must include the subseries number of the 1256 document. 1258 Reference lists must indicate whether each reference is 1259 normative or informative. For example, the reference section 1260 might be split into two sections, e.g.: 1262 s. Normative References 1264 xxx 1265 ... 1266 xxx 1268 s+1. Informative References 1270 xxx 1271 ... 1272 xxx 1274 Non-normative references to Internet-Drafts are allowed, but 1275 they must take the following restricted form: the author(s), 1276 the title, the phrase "Work in Progress", and the date; for 1277 example: 1279 [doe13] Doe, J., "The Deployment of IPv6", 1280 Work in Progress, May 2013. 1282 Normative references to Internet Drafts will cause publication 1283 of the RFC to be suspended until the referenced draft is also 1284 ready for publication; the RFC Editor will then replace the 1285 reference by an RFC reference and publish both simultaneously. 1287 The use of URLs in references in RFCs is discouraged, because 1288 URLs are often not stable references. Exceptions will be made 1289 in certain cases where the World Wide Web is demonstrably the 1290 most stable reference available. 1292 4.8 Author's Address Section 1294 This required section gives the name(s) and contact information 1295 for the author(s) listed in the first-page header. Contact 1296 information must include at least one, and ideally would include 1297 all, of a postal address, a telephone number and/or FAX number, 1298 and a long-lived email address. The purpose of this section is to 1299 (1) unambiguously define author/contributor identity (e.g., the 1300 John Smith who works for FooBar Systems) and to (2) provide 1301 contact information for future readers who have questions or 1302 comments. Note that some professional societies offer long-lived 1303 email addresses for their members. 1305 4.9 Full Copyright Statement 1307 Per Section 10.4(C) of BCP 9, RFC 2026, "The following copyright 1308 notice and disclaimer shall be included in all ISOC standards- 1309 related documentation." This is the "Full Copyright Statement", 1310 whose text will be found at the end of this RFC as well as in RFC 1311 2026. 1313 A specific request from the IAB is required before the RFC Editor 1314 can include a dual copyright, or for any other variation of the 1315 standard ISOC copyright notice. 1317 5. RFC Information and Contacts 1319 ************************************************************ 1320 * * 1321 * RFC Editor Email: rfc-editor@rfc-editor.org * 1322 * * 1323 * * 1324 * RFC Editor URL: http://www.rfc-editor.org * 1325 * * 1326 * * 1327 ************************************************************ 1329 In particular, authors should look for the latest version of this 1330 document at the URL listed above. 1332 RFC publication announcements are distributed via two mailing lists: 1333 the "IETF-Announce" list and the "RFC-DIST" list. The IETF-Announce 1334 list announces publication of both Internet Drafts and RFCs; 1335 instructions for subscription and unsubscription to this list are 1336 available on the IETF web site www.ietf.org. The RFC-DIST list 1337 announces only RFC publication; subscription information is available 1338 at the RFC Editor URL listed above. 1340 RFC readers should be aware that the many mirrors of RFCs and RFC 1341 indexes that appear on other sites vary a great deal in reliability. 1342 Consulting the official RFC-Editor site listed above is recommended. 1344 6. Security Considerations 1346 This RFC describes the Security Considerations sections of an RFC. 1347 It raises no new security issues itself. 1349 7. Acknowledgments 1351 This memo includes wording taken from a draft written by Robert W. 1352 Shirey of GTE/BBN Technologies, 29 December 1999, with permission. 1353 Shirey's deconstruction of the formatting rules was very helpful in 1354 writing Sections 3 and 4 of the present memo. 1356 We are grateful for the many thoughtful and helpful suggestions made 1357 by IETF participants during the Last Call on a previous version of 1358 this document. We especially acknowledge the thorough analysis by 1359 John Klensin. 1361 APPENDIX A: RFC Boilerplate 1363 The RFC Editor supplies the appropriate one of the following 1364 boilerplate paragraphs in the Status of the Memo section (see Section 1365 4.2). 1367 Standards Track 1369 "This document specifies an Internet standards track protocol for 1370 the Internet community, and requests discussion and suggestions 1371 for improvements. Please refer to the current edition of the 1372 "Internet Official Protocol Standards" (STD 1) for the 1373 standardization state and status of this protocol. Distribution 1374 of this memo is unlimited." 1376 Best Current Practice 1378 "This document specifies an Internet Best Current Practices for 1379 the Internet Community, and requests discussion and suggestions 1380 for improvements. Distribution of this memo is unlimited." 1382 Experimental 1384 "This memo defines an Experimental Protocol for the Internet 1385 community. This memo does not specify an Internet standard of any 1386 kind. Discussion and suggestions for improvement are requested. 1387 Distribution of this memo is unlimited." 1389 Informational 1391 "This memo provides information for the Internet community. This 1392 memo does not specify an Internet standard of any kind. 1393 Distribution of this memo is unlimited." 1395 APPENDIX B: RFC Preparation Tools 1397 As indicated earlier, the primary submission format for RFCs is ASCII 1398 text. Authors have found various tools to be useful for preparing 1399 this text in the format required by RFCs and Internet-Drafts. For 1400 more complete and uptodate information, see the RFC Editor Web page. 1402 This Appendix surveys some of the possibilities. 1404 nroff, groff 1405 The nroff program is widely available for Unix systems, while 1406 its freeware equivalent groff is available for an even wider 1407 range of platforms, including Windows. These programs use 1408 directives in the text to control the formatting. The RFC 1409 Editor, in particular, uses nroff for final RFC formatting. A 1410 template is available as 2-nroff.template. 1412 XML 1413 An XML DTD for RFCs has been developed [XMLrf99] and a tool to 1414 format RFCs from XML source. There is also an XML-to-nroff 1415 translator suitable for creating RFC text. Authors have had a 1416 generally good experience with these tools. 1418 Microsoft Word 1419 Microsoft Word is an important example of a WYSIWYG editor. RFC 1420 3285 [14] describes in detail how to configure Word to produce 1421 an ASCII text file in RFC format. A version of this document as 1422 a Word file (2-Word.template.rtf) can be used as a template file 1423 to initialize this configuration for entering and displaying 1424 RFCs. There is also a DOS executable (crlf.exe) for a post- 1425 processor to establish RFC end-of-line conventions in the Word 1426 output file. 1428 Note that these template files are suitable only for fairly 1429 simple text formatting; they may be incompatible with the more 1430 advanced features of Word. 1432 LaTeX 1433 LaTeX is widely used for text preparation in many academic 1434 environments. A convenient LaTeX template is available as 2- 1435 latex.template. Latex in general does not produce plain ASCII 1436 text in the RFC format, but there are tools that translate LaTex 1437 to nroff; see the RFC Editor web page. 1439 APPENDIX C: Checklist 1441 Topic | Section of 1442 | this doc. 1443 ___________________________________________________________|___________ 1444 A. Editorial/Content Issues | 1445 | 1446 o Reasonably clear and correct English | 2.3 1447 > Also, run spell checker | 1448 | 1449 o All abbreviations (with a few exceptions) are | 4.7 1450 expanded when they first appear. | 1451 | 1452 o References: | 2.7, 4.7f 1453 > Complete and current | 1454 > Normative and Informative listed separately | 2.7 1455 > Internet Drafts correctly referenced | 4.8 1456 | 1457 o All URLs are suspect: they must be stable. | 2.8 1458 | 1459 o Title: | 2.9 1460 > Descriptive and not misleading. | 1461 > No suspect words, e.g., Proposed, Standard, | 1462 Requirements, Policy. | 1463 > Abbreviations expanded | 1464 | 1465 o Author list not too long | 2.12 1466 | 1467 o Category field correct | 4.1 1468 | 1469 B. Basic Formatting | 3.1 1470 | 1471 o Only printable ASCII characters | 3.1(1), 1472 | 3.1(4) 1473 o No lines exceeding 72 characters | 3.1(2) 1474 [This is especially important for "as is" tables | 1475 and figures, which cannot be easily reformatted by| 1476 the RFC Editor.] | 1477 | 1478 o Maximum page size is 58 lines. [RFC Editor may | 3.1(3) 1479 re-paginate, but this limit may be an issue for | 1480 large "as is" tables and figures. | 1481 | 1482 o Must be ragged-right | 3.1(5) 1483 | 1484 o No word-breaking hyphenation at end of line | 3.1(6) 1485 | 1486 o Two blanks after periods ending sentences | 3.1(7) 1487 | 1488 o No footnotes (end notes OK) | 3.1(8) 1489 | 1490 o Line spacing OK | 3.1(9) 1491 | 1492 o Pages numbered | 3.1(10) 1493 | 1494 o Running headers and footers OK | 3.3 1495 | 1496 o Formatted for easy reading; consistent spacing and | 1497 indentation | 3.1(12) 1498 | 1499 o "Big-Endian" data definitions | 3.4 1500 | 1501 C. Required Sections supplied by author | 4 1502 | 1503 o Abstract | 4.5 1504 > Clarity and content OK | 1505 > Reasonable length | 1506 > All abbreviations expanded | 1507 > No references | 1508 > Unnumbered section | 1509 | 1510 o Body of the Memo | 4.7 1511 > Security Considerations | 4.7c 1512 | 1513 o Author's Address | 4.8 1514 | 1515 D. Other Sections | 1516 | 1517 o Table of Contents | 4.6 1518 > Must be present in large document | 1519 | 1520 o Body of the Memo | 4.7 1521 > Contributors and/or Acknowledgments | 4.7a, b 1522 > IANA Considerations, if needed | 4.7d 1523 > Appendixes | 4.7e 1524 > References | 4.7f 1525 | 1527 APPENDIX D: Changes from RFC 2223 1529 In general, this document contains the following major changes 1530 from RFC 2223. 1532 o Section 1: Introduction 1534 The Introduction section was completely rewritten, using material 1535 from several sections of RFC 2223, bringing the discussion into 1536 conformance with RFC 2026 and adding additional clarification. 1538 o Section 2: General RFC Editorial Policies 1540 This section combines material from several sections of RFC 2223. 1541 New material is included about the RFC Editor errata page, 1542 normative references, URLs, titles, RFC number pre-assignment, 1543 author lists, and IANA Considerations. 1545 Major procedural changes include: (1) publication of an RFC in 1546 both ASCII and PostScript versions now requires that both be 1547 published simultaneously, (2) all listed authors must give 1548 approval during the "Authors' 48 Hour" process, (3) long author 1549 lists are generally prohibited, and (4) a Contributors section is 1550 defined as an alternative to long author lists. 1552 o Section 3: General Format Rules 1554 This section is expanded with much additional explanatory 1555 material. For example: 1557 (1) The requirement for printable ASCII characters is 1558 stated, and the use of CR, LF, and FF is clarified. 1560 (2) The requirement for page numbers in specified. 1562 (3) The requirement for running headers and footers is 1563 specified. 1565 o Section 4: Required Sections in an RFC 1567 This section is reorganized to cover all the required sections of 1568 an RFC in order. It adds the current conventions for formatting 1569 multiple author names and organizations, and it defines section 1570 ordering more precisely. 1572 This section describes four major changes in RFC formatting. 1574 (1) The style and contents of the Abstract section are more 1575 completely specified, in order to make RFC abstracts 1576 useful for searching and indexing. 1578 (2) A Table of Contents section is required or recommended 1579 in all but very short RFCs. 1581 (3) Separate lists are now required for normative references 1582 and informative references. 1584 (4) A new optional section, Contributors, is defined. 1586 o Appendixes 1588 Former Appendix A, which contained the source for the fix.pl 1589 post-processor Perl script and an nroff RFC template, has been 1590 removed. These files are available at the RFC Editor web site. 1592 Appendix B, RFC Preparation Tools, and Appendix C, Checklist, are 1593 new. 1595 Normative References 1597 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1598 Requirement Levels", BCP 14, RFC 2119, March 1997. 1600 [BCP95] Postel, J., Li, T. and Y. Rekhter, "Best Current 1601 Practices", BCP 1, RFC 1818, August 1995. 1603 [IPR03] Bradner, S., "Intellectual Property Rights in IETF 1604 Technology", Work in Progress, June 2003. [[This will hold 1605 up publication of RFC2223bis]] 1607 [IPS03] Bradner, S., "IETF Rights in Submissions", Work in 1608 Progress, June 2003. [[This will hold up publication of 1609 RFC2223bis]] 1611 [RFCed] RFC Editor web page, "http://www.rfc-editor.org". 1613 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1614 3", BCP 9, RFC 2026, October 1996. 1616 [STD1] Internet Engineering Task Force, Reynolds, J., Braden, R., 1617 Ginoza, S., and A. De La Cruz, Ed., "Official Internet 1618 Protocol Standards", STD 1. Latest version RFC 3300, 1619 November 2002. 1621 Informative References 1623 [ASCII69] Cerf, V., "ASCII Format for Network Interchange", RFC 20, 1624 October 1969. 1626 [FYI90] Malkin, G. and J. Reynolds, "F.Y.I. on F.Y.I. -- 1627 Introduction to the F.Y.I. Notes", FYI 1, RFC 1150, March 1628 1990. 1630 [Hist99] RFC Editor et al., "30 Years of RFCs", RFC 2555, April 1631 1999. 1633 [IANA98] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1634 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1635 October 1998. 1637 [IDguide] IETF, "Guidelines to Authors of Internet Drafts". 1638 Available as 1id-guidelines.txt at http://www.ietf.org. 1640 [IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", Internet 1641 Experimental Note (IEN) 137, 1 April 1980. A longer 1642 version is published in IEEE Computer Magazine, pp 48-54, 1643 October 1981. 1645 [Lang01] IESG, "Guidance for the use of formal languages in IETF 1646 specifications", http://www.ietf.org/IESG/STATEMENTS, 1647 October 2001. 1649 [Secur03] Rescorla, E., Korver, B., and Internet Architecture Board, 1650 "Guidelines for Writing RFC Text on Security 1651 Considerations", Work in Progress, January 2003. 1653 [STD92] Postel, J., Editor, "Introduction to the STD Notes", RFC 1654 1311, March 1992. 1656 [TLD99] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names", 1657 RFC 2606, June 1999. 1659 [Word02] Gahrns, M. and T. Hain, "Using Microsoft Word to create 1660 Internet Drafts and RFCs", RFC 3285, May 2002. 1662 [XMLrf99] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1663 1999. 1665 CHANGES (To be removed by RFC Editor before publication) 1667 Changes from -06 version 1669 1. Changed document status from BCP to Informational. All RFC 1670 Editor policy documents have been Informational RFCs. 1672 2. Eliminated duplicate wording (numbers numbers) [1.1]. 1674 Changes from -05 version 1676 1. Add Section 2.16 on Intellectual Property [2.16]. 1678 2. Note that all major contributors must be acknowledged [2.12]. 1680 3. Note that the RFC Editor fills in the sub-series number and the 1681 Categories field of the header, as well as the Status of this 1682 Memo field [4.1, 4.2]. 1684 4. Specify that internal cross references within the body of the 1685 memo should use section numbers, not page numbers [4.7]. 1687 5. Separate the list of changes that have been made in successive 1688 Internet Draft versions of this document from Appendix D, which 1689 summarizes changes from RFC 2223. The former material is to be 1690 removed before publication. 1692 6. Reduce the set of normative references. 1694 7. Correct several minor nits. 1696 Changes from -04 version 1698 1. Replace overloaded "Status" attribute name with "Category" 1699 [1.1]. 1701 2. Clarify the relation of this document to RFC 2026 [1.2]. 1703 3. Clarify the submission rules, including rules for IAB and IRTF 1704 documents and for BCPs [1.2] 1706 4. Specify that RFC Editor reviews individual submissions for 1707 content as well as format [1.2.1]. 1709 5. Document "Do Not Publish Now" recommendation from the IESG 1710 [1.2.1]. 1712 6. Distinguish between the plain text format and the US-ASCII 1713 character set [2.4, 3.1]. 1715 7. Clarify the distinction between citation format and reference 1716 format, and use a more appropriate format for citations in this 1717 document [2.7]. 1719 8. State that RFC 2119 is not required, but some meaning must be 1720 defined for capitalized applicability words [2.14]. 1722 9. Checking of MIBs and other formal languages [2.15] 1724 10. Clarify that Section 3 defines published format, not submission 1725 format [3.]. 1727 11. Reorganize the sections in section 4 to clarify and simplify the 1728 section ordering rules, and move appendixes to match our 1729 recommendation [4]. 1731 12. Suggest Glossary [4.7]. 1733 13. Fix many typos reported by ever-vigilant IETF members. 1735 Changes from -03 version 1737 1. Combine sections 1.3.1 and 1.3.2 into one section 1.3.1. 1739 2 Clarify the section ordering rules in section 4. 1741 Changes from -02 version 1743 1. Removed old Appendix C (definition of ASCII) and replace it with 1744 a reference to RFC 20. 1746 2 Added new Appendix C, a Checklist. 1748 3 Made a few editorial changes and typo fixes. 1750 4 Clarified that .txt.pdf versions are equally authoritative with 1751 .txt versions of RFCs. 1753 5 Stated policy that (nearly) all abbreviations in body of the 1754 document must be expanded when first encountered. 1756 Changes from -01 version 1758 1. Incorporated new author list guidelines. 1760 2. Clarified rules for hyphenation (Section 3.1 (6)). 1762 3. Added guideline on example URLs (Section 2.8). 1764 4. Clarified that dangling normative references are strictly 1765 prohibited only for standards-track documents (Section 2.7). 1767 Authors' Addresses 1769 Joyce K. Reynolds 1770 RFC Editor 1771 4676 Admiralty Way 1772 Marina del Rey, CA 90292 1774 EMail: rfc-editor@rfc-editor.org 1776 Robert Braden 1777 RFC Editor 1778 4676 Admiralty Way 1779 Marina del Rey, CA 90292 1781 EMail: rfc-editor@rfc-editor.org 1783 Full Copyright Statement 1785 Copyright (C) The Internet Society (2003). All Rights Reserved. 1787 This document and translations of it may be copied and furnished to 1788 others, and derivative works that comment on or otherwise explain it 1789 or assist in its implementation may be prepared, copied, published 1790 and distributed, in whole or in part, without restriction of any 1791 kind, provided that the above copyright notice and this paragraph are 1792 included on all such copies and derivative works. However, this 1793 document itself may not be modified in any way, such as by removing 1794 the copyright notice or references to the Internet Society or other 1795 Internet organizations, except as needed for the purpose of 1796 developing Internet standards in which case the procedures for 1797 copyrights defined in the Internet Standards process must be 1798 followed, or as required to translate it into languages other than 1799 English. 1801 The limited permissions granted above are perpetual and will not be 1802 revoked by the Internet Society or its successors or assigns. 1804 This document and the information contained herein is provided on an 1805 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1806 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1807 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1808 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1809 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1811 Acknowledgement: 1813 Funding for the RFC Editor function is currently provided by the 1814 Internet Society.