idnits 2.17.1 draft-flanagan-style-03.txt: ** The Status of Memo section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 137 has weird spacing: '...44] and appli...' == Line 408 has weird spacing: '...her too gener...' -- The document date (January 16, 2014) is 3746 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Required' is mentioned on line 323, but not defined == Missing Reference: 'RFC1311' is mentioned on line 583, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 665, but not defined == Missing Reference: 'RFC3080' is mentioned on line 648, but not defined == Missing Reference: 'RFC6323' is mentioned on line 659, but not defined == Missing Reference: 'RFC6429' is mentioned on line 672, but not defined ** Obsolete undefined reference: RFC 6429 (Obsoleted by RFC 9293) == Missing Reference: 'SYMBOLIC-TAG' is mentioned on line 725, but not defined == Missing Reference: 'RFC-STYLE' is mentioned on line 692, but not defined == Missing Reference: 'ErrNNNN' is mentioned on line 701, but not defined == Missing Reference: 'Err1912' is mentioned on line 704, but not defined == Missing Reference: 'IEEE802.1Q' is mentioned on line 730, but not defined == Unused Reference: 'WEBSTERS' is defined on line 884, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1150 (ref. 'FYI90') (Obsoleted by RFC 6360) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Duplicate reference: RFC4844, mentioned in 'RFC5741', was also mentioned in 'RFC4844'. -- Obsolete informational reference (is this intentional?): RFC 4844 (ref. 'RFC5741') (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Flanagan 3 RFC Editor 4 Intended Status: Informational S. Ginoza 5 Expires: July 20, 2014 RFC Editor 6 January 16, 2014 8 RFC Style Guide 9 draft-flanagan-style-03 11 Abstract 13 This document is a summary of the style conventions and editorial 14 policies that apply to the the RFC Series. It captures the RFC 15 Editor's fundamental requirements and offers guidance regarding the 16 style and structure of an RFC. Guidance provided by this document 17 will not be applied until published as an RFC. Please send your 18 comments about the contents of this document to . 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. RFC Editorial Philosophy . . . . . . . . . . . . . . . . . . . 4 61 3. RFC Style Conventions . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Language . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Punctuation . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Capitalization . . . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Citations . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.5. Abbreviation Rules . . . . . . . . . . . . . . . . . . . . 7 67 4. Structure of an RFC . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. First-Page Header . . . . . . . . . . . . . . . . . . . . 8 69 4.1.1. Author/Editor . . . . . . . . . . . . . . . . . . . . 8 70 4.1.2. Organization . . . . . . . . . . . . . . . . . . . . . 9 71 4.1.3. "ISSN: 2070-1721" . . . . . . . . . . . . . . . . . . 9 72 4.1.4. Updates and Obsoletes . . . . . . . . . . . . . . . . 9 73 4.2. Full Title . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.4. RFC Editor or Stream Manager Notes . . . . . . . . . . . . 11 76 4.5. Status of This Memo . . . . . . . . . . . . . . . . . . . 11 77 4.6. Copyright, Licenses, and IPR Boilerplate . . . . . . . . . 11 78 4.7. Table of Contents . . . . . . . . . . . . . . . . . . . . 11 79 4.8. Body of the Memo . . . . . . . . . . . . . . . . . . . . . 11 80 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11 81 4.8.2. Requirement Words (RFC 2119) . . . . . . . . . . . . . 12 82 4.8.3. IANA Considerations Section . . . . . . . . . . . . . 12 83 4.8.4. Security Considerations Section . . . . . . . . . . . 13 84 4.8.5. References . . . . . . . . . . . . . . . . . . . . . . 13 85 4.8.5.1. URLs and DNS Names in RFCs . . . . . . . . . . . . 14 86 4.8.5.2. Referencing RFCs . . . . . . . . . . . . . . . . . 15 87 4.8.5.3. Referencing Internet-Drafts . . . . . . . . . . . 15 88 4.8.5.4. Referencing Errata . . . . . . . . . . . . . . . . 16 89 4.8.5.5. Referencing Other Standards Development 90 Organizations (SDOs) . . . . . . . . . . . . . . . 16 91 4.9. Appendices . . . . . . . . . . . . . . . . . . . . . . . . 17 92 4.10. Acknowledgments Section . . . . . . . . . . . . . . . . . 17 93 4.11. Contributors Section . . . . . . . . . . . . . . . . . . 17 94 4.12. "Author's Address" Section . . . . . . . . . . . . . . . 17 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 100 Appendix A. Related Procedures . . . . . . . . . . . . . . . . . 21 101 A.1. Dispute Resolution . . . . . . . . . . . . . . . . . . . . 21 102 A.2. Returning an I-D to the Stream Manager . . . . . . . . . . 21 103 A.3. Revising This Document and Associated Web Pages . . . . . 21 104 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 The ultimate goal of the RFC publication process is to produce 111 documents that are readable, clear, consistent, and reasonably 112 uniform. The basic format conventions for RFCs were established in 113 the 1970s by the original RFC Editor, Jon Postel. This document 114 describes the fundamental and unique style conventions and editorial 115 policies currently in use for the RFC Series [RFC4844]. It is 116 intended as a stable, infrequently updated reference for authors, 117 editors, and reviewers. 119 The RFC Editor also maintains a web portion of the Style Guide (see 120 Appendix A) that describes issues as they are raised and indicates 121 how the RFC Editor intends to address them. As new style issues 122 arise, the RFC Editor will first address them on the web portion of 123 the Style Guide [StyleWeb]. These may become part of the greater 124 Style Guide when it is revised. 126 The world of technical publishing has generally accepted rules for 127 grammar, punctuation, capitalization, sentence length and complexity, 128 parallelism, etc. The RFC Editor generally follows these accepted 129 rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a 130 few important exceptions to avoid ambiguity in complex technical 131 prose and to handle mixtures of text and computer languages. This 132 document presents these exceptions where they are required. 134 All RFCs begin as an Internet-Draft, and a well-written and properly 135 constructed Internet-Draft [IDGuide] provides a strong basis for a 136 good RFC. The RFC Editor accepts Internet-Drafts from specified 137 streams for publication [RFC4844] and applies the rules and 138 guidelines for the RFC Series during the editorial process. 140 2. RFC Editorial Philosophy 142 Authors may find it helpful to understand the RFC Editor's goals 143 during the publication process, namely: 145 - Prepare the document to RFC style and format. 147 - Make the document as clear, consistent, and readable as possible. 149 - Look for larger content/clarity issues; flag any unclear passages 150 for author review. 152 - Point out inconsistencies (e.g., terms that appear in various 153 forms, text that appears multiple times, or inconsistent 154 capitalization). 156 We strive for consistency within: 158 a. the document, 160 b. a set of documents, and 162 c. the series of RFCs on the subject matter. 164 The editorial process of the RFC Editor is not an additional 165 technical review of the document. Where the RFC Editor may suggest 166 changes in wording for clarity and readability, it is up to the 167 author, working group, or stream manager (e.g., the ISE, IESG, IRSG, 168 or IAB Chair) to determine if the changes have an impact on the 169 technical meaning in the document. If the original wording is a more 170 accurate representation of the technical content being described in 171 the document, it takes precedence over editorial conventions. 173 The activity of editing often creates a tension between author and 174 editor. The RFC Editor attempts to minimize this conflict for RFC 175 publication, while continually striving to produce a uniformly 176 excellent document series. The RFC Editor refers to this fundamental 177 tension as "editorial balance", and maintaining this balance is a 178 continuing concern for the RFC Editor. There is a prime directive 179 that must rule over grammatical conventions: do not change the 180 intended meaning of the text. 182 If a document is submitted to the RFC Editor that proves to be 183 uneditable due to consistently unclear and poorly written text, the 184 document may be returned to the stream for revision. See more 185 details in Appendix A.2. 187 3. RFC Style Conventions 189 All RFCs begin as an Internet-Draft, and a well-written and properly 190 constructed Internet-Draft [IDGuide] provides a strong basis for a 191 good RFC. The RFC Editor generally follows accepted rules as defined 192 by the Chicago Manual of Style (CMOS) [CMOS], with a few important 193 exceptions to avoid ambiguity in complex technical prose and to 194 handle mixtures of text and computer languages. This document 195 presents these exceptions where they are required. 197 3.1. Language 199 The RFC publication language is English. This may be either American 200 or British as long as an individual document is internally 201 consistent. Where both American and British English are used within 202 a document or cluster of documents, the text will be modified to be 203 consistent with American English. 205 3.2. Punctuation 207 * No overstriking (or underlining) is allowed. 209 * When a sentence ended by a period is immediately followed by 210 another sentence, there should be two blank spaces after the 211 period. 213 * A comma is used before the last item of a series, e.g., 215 "TCP service is reliable, ordered, and full-duplex" 217 * When quoting literal text, punctuation is placed outside quotation 218 marks, e.g., 220 'Search for the string "Error Found"'. 222 When quoting general text, such as general text from another RFC, 223 punctuation may be included within the quotation marks, e.g., 225 RFC 4844 indicates that "RFCs are available free of charge to 226 anyone via the Internet." 228 Quotes are not necessary when block quotes are used. 230 * Angle brackets are strongly recommended around URIs [STD66], e.g., 232 234 Note that URIs may not be the sole information provided for a 235 reference entry. 237 3.3. Capitalization 239 * Capitalization must be consistent within the document and should 240 be consistent with related RFCs. Refer to the online "Table of 241 decisions on consistent usage of terms in RFCs" [PubProcess]. 243 * Per CMOS guidelines, the major words in RFC titles and section 244 titles should be capitalized (this is sometimes called "title 245 case"). Typically, all words in a title will be capitalized, 246 except for internal articles, prepositions, and conjunctions. 248 * Section titles that are in sentence form will follow typical 249 sentence capitalization. 251 * Titles of figures may be in sentence form or use title case. 253 3.4. Citations 255 * References and citations must match. That is, there must be a 256 reference for each citation used, and vice versa. 258 * Citations must be enclosed in square brackets, e.g., "[CITE1]". 260 * A citation/reference tag must not contain spaces or hyphens. 262 Example: "[RFC2119]", not "[RFC 2119]". 264 However, the proper textual naming of an RFC contains a space. 266 Example: "See RFC 2119 [BCP14] for more information." 268 * Cross references within the body of the text and to other RFCs 269 should use section numbers rather than page numbers, as pagination 270 may change per format and device. 272 3.5. Abbreviation Rules 274 Abbreviations must be expanded in document titles and upon first use 275 in the body of the document, which includes the Abstract. The full 276 expansion of the text should be followed by the abbreviation itself 277 in parentheses. The exception is abbreviations that are so common 278 that the readership of RFCs can be expected to recognize them 279 immediately; examples include (but are not limited to) TCP, IP, SNMP, 280 and FTP. The online list of abbreviations [ABBR] provides guidance. 281 Some cases are marginal, and the RFC Editor will make the final 282 judgment, weighing obscurity against complexity. 284 Note: The online list of abbreviations is not exhaustive or 285 definitive. It is a list of abbreviations appearing in RFCs and 286 sometimes reflects discussions with authors, WG chairs, and/or 287 ADs. Note that some abbreviations have multiple expansions. 288 Additionally, this list includes some terms that look like 289 abbreviations but are actually fixed names for things, and hence 290 cannot and should not be expanded. These are noted as "No 291 expansion". 293 4. Structure of an RFC 295 A published RFC will contain the elements in the following list. 296 Some of these sections are required, as noted. Those sections marked 297 with "*" will be supplied by the RFC Editor during the editorial 298 process when necessary. The rules for each of these elements are 299 described in more detail below. 301 First-page header * [Required] 302 Title [Required] 303 Abstract [Required] 304 RFC Editor or Stream Manager Note * [Upon request] 305 Status of this Memo * [Required] 306 Copyright and License Notice * [Required] 307 Table of Contents [Required] 308 Body of the Memo [Required] 309 1. Introduction [Required] 310 2. Requirement Words (RFC 2119) 311 3. ... 312 MAIN BODY OF THE TEXT 313 6. ... 314 7. IANA Considerations [Required in I-D] 315 8. Security Considerations [Required] 316 9. References 317 9.1. Normative References 318 9.2. Informative References 319 Appendix A. 320 Appendix B. 321 Acknowledgments 322 Contributors 323 Author's Address [Required] 325 Within the body of the memo, the order shown above is strongly 326 recommended. Exceptions will be questioned. Outside the body of the 327 memo, the order above is required. The section numbers above are for 328 illustrative purposes; they are not intended to correspond to 329 required numbering in an RFC. 331 The elements preceding the body of the memo should not be numbered. 332 Typically, the body of the memo will have numbered sections and the 333 appendices will be labeled with letters. Any sections that appear 334 after the appendices should not be numbered or labeled (e.g., see 335 "Contributors" above). 337 4.1. First-Page Header 339 Headers will follow the format as described in "RFC Streams, Headers, 340 and Boilerplates" [RFC5741] and its successors. In addition, the 341 following conventions will apply. 343 4.1.1. Author/Editor 345 The determination of who should be listed as an author or editor on 346 an RFC is dependent on Stream policy. The RFC Editor provides 347 guidelines for number and format of the author-related components of 348 an RFC. 350 The author's name (initials followed by family name) appears on the 351 first line of the heading. Some variation, such as additional 352 initials or capitalization of family name, is acceptable but the 353 author should be consistent once they've selected a name format. 355 The total number of authors or editors on the first page is generally 356 limited to five individuals and their affiliations. If there is a 357 request for more than five authors, the stream manager needs to 358 consider if one or two editors should have primary responsibility for 359 this document, with the other individuals listed in the Contributors 360 or Acknowledgements section. There must be a direct correlation of 361 authors and editors in the header and Authors' Address section. 362 These are the individuals that must sign off on the document during 363 the AUTH48 process and respond to inquiries, such as errata. 365 4.1.2. Organization 367 The author's organization is indicated on the line following the 368 author's name. 370 For multiple authors, each author name appears on its own line, 371 followed by that author's organization. When more than one author is 372 affiliated with the same organization, the organization can be 373 "factored out", appearing only once following the corresponding 374 Author lines. However, such factoring is inappropriate when it would 375 force an unacceptable reordering of author names. 377 If an author cannot or will not provide an affiliation for any 378 reason, "Independent", "Retired", or some other term that 379 appropriately describes the author's affiliation may be used. 380 Alternatively, a blank line may be included in the document header 381 when no affiliation is provided. 383 4.1.3. "ISSN: 2070-1721" 385 The RFC Series has been assigned an International Standard Serial 386 Number of 2070-1721 [ISO3297]. It will be included by the RFC 387 Editor. 389 4.1.4. Updates and Obsoletes 391 When an RFC obsoletes or updates a previously published RFC or RFCs, 392 this information is in the header. For example: 394 "Updates: nnnn" or "Updates: nnnn, ..., nnnn" 396 "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn" 398 If the document updates or obsoletes more than one document, numbers 399 will be listed in ascending order. 401 4.2. Full Title 403 The title must be centered below the rest of the heading, preceded by 404 two blank lines and followed by one blank line. 406 Choosing a good title for an RFC can be a challenge. A good title 407 should fairly represent the scope and purpose of the document without 408 being either too general or too specific and lengthy. 410 Abbreviations or acronyms in a title must generally be expanded when 411 first encountered (see Section 3.5 for additional guidance on 412 acronyms). 414 It is often helpful to follow the expansion with the parenthesized 415 abbreviation, as in the following example: 417 Encoding Rules for the 418 Common Routing Encapsulation Extension Protocol (CREEP) 420 An RFC that documents a particular company's private protocol should 421 bear a title of the form "Foo's ... Protocol" (where Foo is a company 422 name), to clearly differentiate it from a protocol of more general 423 applicability. 425 4.3. Abstract 427 Every RFC must have an Abstract of a maximum of 20 lines. 429 The Abstract should provide a concise and comprehensive overview of 430 the purpose and contents of the entire document, to give a 431 technically knowledgeable reader a general overview of the function 432 of the document. 434 Composing a useful Abstract generally requires thought and care. 435 Usually an Abstract should begin with a phrase like "This memo ..." 436 or "This document ...". A satisfactory Abstract can often be 437 constructed in part from material within the Introduction section, 438 but an effective Abstract may be shorter, less detailed, and perhaps 439 broader in scope than the Introduction. Simply copying and pasting 440 the first few paragraphs of the Introduction is allowed, but it may 441 result in an Abstract that is both incomplete and redundant. Note 442 also that an Abstract is not a substitute for an Introduction; the 443 RFC should be self-contained as if there were no Abstract. 445 Similarly, the Abstract should be complete in itself. It will 446 appear 447 in isolation in publication announcements and in the online index of 448 RFCs. Therefore, the Abstract must not contain citations. 450 4.4. RFC Editor or Stream Manager Notes 452 The RFC Editor or a stream manager may request that an editorial note 453 be added to an RFC. A note is generally added to explain anything 454 unusual about the process that led to the document's publication or 455 to note a correction. 457 Additionally, the RFC Editor may choose to include a note to 458 highlight special circumstances surrounding an RFC. 460 4.5. Status of This Memo 462 The RFC Editor will supply an appropriate "Status of This Memo" 463 section as defined in RFC 5741 [RFC5741]. 465 4.6. Copyright, Licenses, and IPR Boilerplate 467 The full copyright and license notices are available on the IETF 468 Trust Legal Provisions Documents website [IETFTrust]. 470 4.7. Table of Contents 472 A Table of Contents (TOC) is required in all RFCs. It must be 473 positioned after the Copyright notice and before the Introduction. 475 4.8. Body of the Memo 477 Following the TOC is the body of the memo. 479 Each RFC must include an "Introduction" section that (among other 480 things) explains the motivation for the RFC and (if appropriate) 481 describes the applicability of the document, e.g., whether it 482 specifies a protocol, provides a discussion of some problem, is 483 simply of interest to the Internet community, or provides a status 484 report on some activity. The body of the memo and the Abstract must 485 be self-contained and separable. This may result in some duplication 486 of text between the Abstract and the Introduction; this is 487 acceptable. 489 4.8.1. Introduction 490 The Introduction section should always be the first section following 491 the TOC (except in the case of MIB module documents). While 492 "Introduction" is recommended, authors may choose alternate titles 493 such as "Overview" or "Background". These alternates are acceptable. 495 For MIB module documents, common practice has been for "The Internet- 496 Standard Management Framework" [MIBboiler] text to appear as Section 497 1. 499 4.8.2. Requirement Words (RFC 2119) 501 Some documents use certain capitalized words ("MUST", "SHOULD", etc.) 502 to specify precise requirement levels for technical features. RFC 503 2119 [BCP14] defines a default interpretation of these capitalized 504 words in IETF documents. If this interpretation is used, RFC 2119 505 must be cited (as specified in RFC 2119) and included as a normative 506 reference. Otherwise, the correct interpretation must be specified 507 in the document. 509 This section must appear as part of the body of the text (as defined 510 by this document). It must appear as part of, or subsequent to, the 511 Introduction section. 513 These words are considered part of the technical content of the 514 document and are intended to provide guidance to implementers about 515 specific technical features, generally governed by considerations of 516 interoperability. RFC 2119 says: 518 Imperatives of the type defined in this memo must be used with 519 care and sparingly. In particular, they must only be used 520 where it is actually required for interoperation or to limit 521 behavior which has potential for causing harm (e.g., limiting 522 retransmissions). For example, they must not be used to try to 523 impose a particular method on implementers where the method is 524 not required for interoperability. 526 To simply specify a necessary logical relationship, the normal 527 lowercase words should be used. On the other hand, if the 528 capitalized words are used in a document, choose and use them 529 carefully and consistently. 531 To forestall confusion between uppercase conformance terms and their 532 lowercase equivalents, authors are encouraged to use words and 533 phrases such as "mandatory", "ought to", and "might" instead of 534 "MUST", "SHOULD", and "MAY". 536 4.8.3. IANA Considerations Section 537 See "Guidelines for Writing an IANA Considerations Section in RFCs" 538 [BCP26]. 540 The RFC Editor will update text accordingly after the IANA 541 assignments have been made. It is helpful for authors to clearly 542 identify where text should be updated to reflect the newly assigned 543 values. For example, the use of "TBD1", "TBD2", etc., is recommended 544 in the IANA Considerations section and in the body of the document. 546 If the authors have provided values to be assigned by IANA, the RFC 547 Editor will verify that the values inserted by the authors match 548 those that have actually been registered on the IANA site. When 549 writing a given value, consistent use of decimal or hexadecimal is 550 recommended. 552 If any of the IANA-related information is not clear, the RFC Editor 553 will work with IANA to send queries to the authors to ensure that 554 assignments and values are properly inserted. 556 The RFC Editor will remove an IANA Considerations section that says 557 there are no IANA considerations (although such a section is required 558 in the Internet-Draft preceding the RFC). 560 4.8.4. Security Considerations Section 562 All RFCs must contain a section that discusses the security 563 considerations relevant to the specification; see "Guidelines for 564 Writing RFC Text on Security Considerations" [BCP72] for more 565 information. 567 4.8.5. References 569 The reference list is solely for recording reference entries. 570 Introductory text is not allowed. 572 The RFC style allows the use of any of a variety of reference styles, 573 as long as they are used consistently within a document. However, 574 where necessary, in specific instances, some reference styles have 575 been described for use within the Series. See the examples in this 576 document. 578 The RFC Editor ensures that references to other RFCs refer to the 579 most current RFC available on that topic (unless provided with reason 580 not to do so). It is acceptable for an obsoleted document to be 581 listed as long as the most recent document is referenced also. 583 A reference to an RFC that has been assigned an STD [RFC1311], BCP 584 [RFC1818], or FYI [FYI90] sub-series number must include the sub- 585 series number of the document. Note: the FYI series was ended by RFC 586 6360. RFCs that were published with an FYI sub-series number and 587 still maintain the FYI number must include the sub-series number in 588 the reference. 590 Reference lists must indicate whether each reference is normative or 591 informative, where normative references are essential to implementing 592 or understanding the content of the RFC, and informative references 593 provide additional information. For example, the reference section 594 might be split into two subsections: 596 s. References 598 s.1. Normative References 600 xxx 601 xxx 603 s.2. Informative References 605 xxx 606 xxx 608 References will generally appear in alphanumeric order by citation 609 tag. 611 Normative references to Internet-Drafts will cause publication of the 612 RFC to be suspended until the referenced draft is also ready for 613 publication; the RFC Editor will then update the entry to refer to 614 the RFC and publish both documents simultaneously. 616 4.8.5.1. URLs and DNS Names in RFCs 618 The use of URLs in references is acceptable as long as the URL is the 619 most stable (i.e., unlikely to change and expected to be continuously 620 available) and direct reference possible. The URL will be verified 621 as valid during the RFC editorial process. Personal web pages and 622 web caching services are not considered stable and will not be 623 accepted as a normative reference. Informative references to blogs 624 are acceptable if they are an organizational blog and not a personal 625 space. 627 DNS names, whether or not in URLs, that are used as generic examples 628 in RFCs should use the particular examples defined in "Reserved Top- 629 Level DNS Names" [RFC2606], to avoid accidental conflicts. 631 If a dated URL is available for a referenced web page, its use is 632 required. 634 4.8.5.2. Referencing RFCs 636 The following format is required for citing RFCs. Note the ordering 637 for multiple authors: the last author listed is treated differently 638 than the already listed authors. 640 For 1 Author: 642 [RFCXXXX] Last name, First initial., "RFC Title", 643 BCP/FYI/STD ## (if applicable), RFC ####, 644 Date of Publication. 646 Example: 648 [RFC3080] Rose, M., "The Blocks Extensible Exchange 649 Protocol Core", RFC 3080, March 2001. 651 For 2 Authors: 653 [RFCXXXX] Last name, First initial. and First initial, 654 Last name, "RFC Title", BCP/FYI/STD ## 655 (if applicable), RFC ####, Date of Publication. 657 Example: 659 [RFC6323] Renker, G. and G. Fairhurst, "Sender RTT 660 Estimate Option for the Datagram Congestion 661 Control Protocol (DCCP)", RFC 6323, July 2011. 663 For 3 or more Authors: 665 [RFCXXXX] Last name, First initial., Last name, First 666 initial., and First initial. Last name, "RFC 667 Title", BCP/FYI/STD ## (if applicable), 668 RFC ####, Date of Publication. 670 Example: 672 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, 673 "TCP Sender Clarification for Persist 674 Condition", RFC 6429, December 2011. 676 4.8.5.3. Referencing Internet-Drafts 678 References to Internet-Drafts can only appear as Informative 679 references. Given that several revisions of an I-D may be produced in 680 a short time frame, references must include the publication date 681 (month and year), the full Internet-Draft file name (including the 682 version number), and the use the phrase "Work in Progress". If the 683 I-D referenced has a version published as an RFC, references must 684 also include the RFC. 686 [SYMBOLIC-TAG] Last name, First initial. and First 687 initial, Last name, "I-D Title", Work in 688 Progress, draft-string-NN, Month, Year. 690 Example: 692 [RFC-STYLE] Flanagan, H., and S. Ginoza, "RFC Style Guide", 693 Work in Progress, draft-flanagan-style-01, 694 August 2013. 696 4.8.5.4. Referencing Errata 698 The following format is required when a reference to an errata report 699 is necessary: 701 [ErrNNNN] RFC Errata, Errata ID NNNN, RFC NNNN, 702 . 704 [Err1912] RFC Errata, Errata ID 1912, RFC 2978, 705 . 707 4.8.5.5. Referencing Other Standards Development Organizations (SDOs) 709 The following format is suggested when referencing a document or 710 standard from another SDO in which authors are listed: 712 [W3C.REC-xml11] 713 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., 714 Yergeau, F., and J. Cowan, "Extensible Markup Language 715 (XML) 1.1 (Second Edition)", W3C Recommendation 716 REC-xml11-20060816, August 2006, . 719 Note that the list of authors is ordered as on the actual document 720 and the common, abbreviated form of the SDO is used. 722 Alternatively, when no list of authors is available, the following 723 format is recommended: 725 [SYMBOLIC-TAG] Organization, "Document Title", Document 726 reference number, date of publication. 728 Example: 730 [IEEE802.1Q] IEEE, "Local and Metropolitan Area 731 Networks -- Media Access Control (MAC) 732 Bridges and Virtual Bridged Local Area 733 Networks", IEEE Std 802.1Q-2011, August 2011. 735 4.9. Appendices 737 The RFC Editor recommends placing references before the Appendices. 738 Appendices should be labeled as "Appendix A. Appendix A Title", 739 "A.1. Appendix A.1 Title", "Appendix B. Appendix B Title", etc. 741 4.10. Acknowledgments Section 743 This optional section may be used instead of or in addition to a 744 Contributors section. It is often used by authors to publicly thank 745 those who have provided feedback regarding a document and to note any 746 documents from which text was borrowed. 748 4.11. Contributors Section 750 This optional section acknowledges those who have made significant 751 contributions to the document. 753 In a similar fashion to the Author section, the RFC Editor does not 754 make the determination as to who should be listed as a contributor to 755 an RFC. The determination of who should be listed as a contributor 756 on an RFC is determined by stream policy. 758 The Contributors section may include brief statements about the 759 nature of particular contributions ("Sam contributed Section 3"), and 760 it may also include affiliations of listed contributors. At the 761 discretion of the author(s), contact addresses may also be included 762 in the Contributors section, for those contributors whose knowledge 763 makes them useful future contacts for information about the RFC. Any 764 contact information should be formatted similar to how the 765 information is formatted in the Author's Address section. 767 4.12. "Author's Address" Section 769 This required section gives contact information for the author(s) 770 listed in the first-page header. 772 Contact information must include a long-lived email address and 773 optionally may include a postal address and/or telephone number. If 774 the postal address is included, it should include the country name 775 using the English short name listed by the ISO 3166 Maintenance 776 Agency [ISO3166]. The purpose of this section is to (1) 777 unambiguously define author identity (e.g., the John Smith who works 778 for FooBar Systems) and to (2) provide contact information for future 779 readers who have questions or comments. 781 The practice of munged addresses (i.e., altering an email address to 782 make it less readable to bots and web crawlers to avoid spam) is not 783 appropriate in an archival document series. Author contact 784 information is provided so that readers can easily contact the author 785 with questions and/or comments. Address munging is not allowed in 786 RFCs. 788 5. IANA Considerations 790 No IANA actions required. 792 6. Security Considerations 794 No security considerations. 796 7. References 798 7.1. Normative References 800 [StyleWeb] RFC Editor, "Web Portion of the Style Guide", 801 . 803 7.2. Informative References 805 [ABBR] RFC Editor Abbreviations List, 806 . 809 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, March 1997, 811 . 813 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 814 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 815 May 2008, . 817 [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 818 Text on Security Considerations", BCP 72, RFC 3552, July 819 2003, . 821 [CMOS] Chicago Manual of Style, 16th ed. Chicago: University of 822 Chicago Press, 2010. 824 [FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to 825 the FYI Notes", FYI Notes, RFC 1150, March 1990. 827 Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, 828 August 2011. 830 832 [IDGuide] IETF, "Guidelines to Authors of Internet Drafts", 833 . 835 [IETFTrust] 836 IETF Trust, "Trust Legal Provisions (TLP) Documents", 837 . 839 [ISO3166] ISO, "Country Codes - ISO 3166", . 842 [ISO3297] Technical Committee ISO/TC 46, Information and 843 documentation, Subcommittee SC 9, Identification and 844 description, "Information and documentation - 845 International standard serial number (ISSN)", 09 2007. 847 [MIBboiler] 848 IETF OPS Area, "Boilerplate for IETF MIB Documents", 849 . 851 [PubProcess] 852 RFC Editor, "Publication Process", 853 . 855 [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current 856 Practices", RFC 1818, August 1995, 857 . 859 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 860 RFC 2223, October 1997, . 863 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 864 Names", BCP 32, RFC 2606, June 1999, 865 . 867 [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC 868 Series and RFC Editor", RFC 4844, July 2007, 869 . 871 [RFC5741] Daigle, L., Ed., and Kolkman, O., Ed., and IAB, "RFC 872 Streams, Headers, and Boilerplates", RFC 5741, December 873 2009, . 875 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 876 Model (Version 2)", RFC 6635, June 2012, 877 . 879 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 880 Resource Identifier (URI): Generic Syntax", STD 66, RFC 881 3986, January 2005, 882 . 884 [WEBSTERS] Merriam-Webster Online, . 886 Appendix A. Related Procedures 888 The following procedures are related to the application and updating 889 of the RFC Style Guide. 891 A.1. Dispute Resolution 893 There are competing rationales for some of the rules described in 894 this Guide, and the RFC Editor has selected the ones that work best 895 for the Series. However, at times, an author may have a disagreement 896 with the RFC Production Center (RPC) over the application of style 897 guide conventions. In such cases, the authors should discuss their 898 concerns with the RPC. If no agreement can be reached between the 899 RPC and the authors, the RFC Series Editor will, with input from the 900 appropriate stream manager, make a final determination. If further 901 resolution is required, the dispute resolution process as described 902 in the RFC Editor Model [RFC6635] will be followed. 904 A.2. Returning an I-D to the Stream Manager 906 For a given document, if the RFC Editor determines that it cannot be 907 edited without serious risk of altering the meaning of the technical 908 content or if the RFC Editor does not have the resources to provide 909 the level of editing it needs, it may be sent back to the stream 910 manager with a request to improve the clarity, consistency, and/or 911 readability of the document. This is not to be considered a dispute 912 with the author. 914 A.3. Revising This Document and Associated Web Pages 916 The RFC Series is continually evolving as a document series. This 917 document focuses on the fundamental and stable requirements that must 918 be met by an RFC. From time to time, the RFC Editor may offer less 919 formal recommendations that authors may apply at their discretion; 920 these recommendations may be found on the RFC Editor website 921 "Guidelines for RFC Style" [StyleWeb]. 923 When a new recommendation is made regarding the overall structure and 924 formatting of the RFCs, it will be published on that page and 925 accepted for a period of time before the RFC Editor determines 926 whether it should become part of the fundamental requirements in the 927 RFC Style Guide or remain as a less formal recommendation. That 928 period of time will vary in part depending on the frequency with 929 which authors encounter and apply the guidance. 931 Acknowledgements 932 This document refers heavily to RFC 2223 [RFC2223] and draft-rfc- 933 editor-rfc2223bis-08; as such, we are grateful to the authors of 934 those documents for their time and effort in to the RFC Series. 936 Robert T. Braden 937 USC Information Sciences Institute 939 Joyce Reynolds 941 Jon Postel 943 Contributors 945 Alice Russo 946 RFC Production Center 948 Authors' Addresses 950 Heather Flanagan 951 RFC Series Editor 953 EMail: rse@rfc-editor.org 955 Sandy Ginoza 956 RFC Production Center 958 EMail: rfc-editor@rfc-editor.org