idnits 2.17.1 draft-flanagan-7322bis-02.txt: 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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC7322, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (September 12, 2017) is 2417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6146' is mentioned on line 308, but not defined == Missing Reference: 'RFC6147' is mentioned on line 309, but not defined == Missing Reference: 'RFC6144' is mentioned on line 310, but not defined == Missing Reference: 'RFC6959' is mentioned on line 315, but not defined == Missing Reference: 'Required' is mentioned on line 432, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 799, but not defined -- Looks like a reference, but probably isn't: '1' on line 1163 == Missing Reference: 'RFC3080' is mentioned on line 774, but not defined -- Looks like a reference, but probably isn't: '2' on line 1165 == Missing Reference: 'RFC8157' is mentioned on line 778, but not defined -- Looks like a reference, but probably isn't: '3' on line 1167 -- Looks like a reference, but probably isn't: '4' on line 1169 == Missing Reference: 'RFC6323' is mentioned on line 792, but not defined -- Looks like a reference, but probably isn't: '5' on line 1171 -- Looks like a reference, but probably isn't: '6' on line 1173 == Missing Reference: 'RFC6429' is mentioned on line 807, but not defined ** Obsolete undefined reference: RFC 6429 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '7' on line 1175 == Missing Reference: 'STD13' is mentioned on line 851, but not defined == Missing Reference: 'STDXXX' is mentioned on line 838, but not defined -- Looks like a reference, but probably isn't: '8' on line 1177 == Missing Reference: 'STD72' is mentioned on line 832, but not defined -- Looks like a reference, but probably isn't: '9' on line 1179 == Missing Reference: 'SYMBOLIC-TAG' is mentioned on line 921, but not defined == Missing Reference: 'RFC-STYLE' is mentioned on line 876, but not defined == Missing Reference: 'ErrNumber' is mentioned on line 884, but not defined == Missing Reference: 'Err1912' is mentioned on line 887, but not defined == Missing Reference: 'IEEE.802.15.4' is mentioned on line 927, but not defined == Missing Reference: 'IEEE802.1Q' is mentioned on line 934, but not defined -- 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 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) Summary: 1 error (**), 0 flaws (~~), 21 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Flanagan 3 Internet-Draft S. Ginoza 4 Intended status: Informational RFC Editor 5 Expires: March 16, 2018 September 12, 2017 7 RFC Style Guide 8 draft-flanagan-7322bis-02 10 Abstract 12 This document describes the fundamental and unique style conventions 13 and editorial policies currently in use for the RFC Series. It 14 captures the RFC Editor's basic requirements and offers guidance 15 regarding the style and structure of an RFC. Additional guidance is 16 captured on a website that reflects the experimental nature of that 17 guidance and prepares it for future inclusion in the RFC Style Guide. 18 This document obsoletes RFC 7322, "RFC Style Guide". 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 16, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. RFC Editor's Philosophy . . . . . . . . . . . . . . . . . . . 3 56 3. RFC Style Conventions . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Language . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Punctuation . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.1. RFCs as Compounds . . . . . . . . . . . . . . . . . . 5 60 3.3. DNS Names and URIs . . . . . . . . . . . . . . . . . . . 6 61 3.4. Capitalization . . . . . . . . . . . . . . . . . . . . . 6 62 3.5. Citations . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.6. Abbreviation Rules . . . . . . . . . . . . . . . . . . . 7 64 3.7. Images and Figures . . . . . . . . . . . . . . . . . . . 8 65 4. Structure of an RFC . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. First-Page Header . . . . . . . . . . . . . . . . . . . . 10 67 4.1.1. Author/Editor . . . . . . . . . . . . . . . . . . . . 10 68 4.1.2. Organization . . . . . . . . . . . . . . . . . . . . 11 69 4.1.3. ISSN: 2070-1721 . . . . . . . . . . . . . . . . . . . 11 70 4.1.4. Updates and Obsoletes . . . . . . . . . . . . . . . . 11 71 4.2. Document Title . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Abstract Section . . . . . . . . . . . . . . . . . . . . 12 73 4.4. RFC Editor or Stream Notes Section . . . . . . . . . . . 12 74 4.5. Status of This Memo Section . . . . . . . . . . . . . . . 13 75 4.6. Copyright, Licenses, and IPR Boilerplate Section . . . . 13 76 4.7. Table of Contents Section . . . . . . . . . . . . . . . . 13 77 4.8. Body of the Memo . . . . . . . . . . . . . . . . . . . . 13 78 4.8.1. Introduction Section . . . . . . . . . . . . . . . . 13 79 4.8.2. Requirements Language Section . . . . . . . . . . . . 14 80 4.8.3. IANA Considerations Section . . . . . . . . . . . . . 14 81 4.8.4. Internationalization Considerations Section . . . . . 15 82 4.8.5. Security Considerations Section . . . . . . . . . . . 15 83 4.8.6. References Section . . . . . . . . . . . . . . . . . 15 84 4.9. Appendices Section . . . . . . . . . . . . . . . . . . . 21 85 4.10. Acknowledgements Section . . . . . . . . . . . . . . . . 21 86 4.11. Contributors Section . . . . . . . . . . . . . . . . . . 21 87 4.12. Index . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.13. Author's Address or Authors' Addresses Section . . . . . 21 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 94 8.2. Informative References . . . . . . . . . . . . . . . . . 22 95 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 Appendix A. Related Procedures . . . . . . . . . . . . . . . . . 26 97 A.1. Dispute Resolution . . . . . . . . . . . . . . . . . . . 26 98 A.2. Returning an I-D to the Document Stream . . . . . . . . . 26 99 A.3. Revising This Document and Associated Web Pages . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 102 1. Introduction 104 The ultimate goal of the RFC publication process is to produce 105 documents that are readable, clear, and consistent. The basic 106 formatting conventions for RFCs were established in the 1970s by the 107 original RFC Editor, Jon Postel. This document describes the 108 fundamental and unique style conventions and editorial policies 109 currently in use for the RFC Series [RFC4844] and is intended as a 110 stable, infrequently updated reference for authors, editors, and 111 reviewers. 113 The RFC Editor also maintains a web portion of the Style Guide (see 114 Appendix A.3) that describes issues as they are raised and indicates 115 how the RFC Editor intends to address them. As new style issues 116 arise, the RFC Editor will first address them on the web portion of 117 the Style Guide [STYLE-WEB]. These topics may become part of the RFC 118 Style Guide when it is revised. 120 The world of publishing has generally accepted rules for grammar, 121 punctuation, capitalization, sentence length and complexity, etc. 122 The RFC Editor generally follows these accepted rules as defined by 123 the Chicago Manual of Style (CMOS) [CMOS], with a few important 124 exceptions to avoid ambiguity in complex technical prose and to 125 handle mixtures of text and computer languages, or to preserve 126 historical formatting rules. This document presents these exceptions 127 as applied or recommended by the RFC Editor. 129 All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a 130 well-written and properly constructed Internet-Draft [ID-GUIDE] 131 provides a strong basis for a good RFC. The RFC Editor accepts 132 Internet-Drafts from specified streams for publication [RFC4844] and 133 applies the rules and guidelines for the RFC Series during the 134 editorial process. 136 2. RFC Editor's Philosophy 138 Authors may find it helpful to understand the RFC Editor's goals 139 during the publication process, namely to: 141 o Prepare the document according to RFC style and format. 143 o Make the document as clear, consistent, and readable as possible. 145 o Correct larger content/clarity issues; flag any unclear passages 146 for author review. 148 o Fix inconsistencies (e.g., terms that appear in various forms, 149 inconsistent capitalization, discrepancies between a figure and 150 the text that describes it). 152 We strive for consistency within: 154 a. the document, 156 b. a cluster of documents [CLUSTER], and 158 c. the series of RFCs on the subject matter. 160 The editorial process of the RFC Editor is not an additional 161 technical review of the document. Where the RFC Editor may suggest 162 changes in wording for clarity and readability, it is up to the 163 author, working group, or stream-approving body to determine whether 164 the changes have an impact on the technical meaning of the document 165 [RFC4844]. If the original wording is a more accurate representation 166 of the technical content being described in the document, it takes 167 precedence over editorial conventions. 169 The activity of editing sometimes creates a tension between author 170 and editor. The RFC Editor attempts to minimize this conflict for 171 RFC publication while continually striving to produce a uniformly 172 excellent document series. The RFC Editor refers to this fundamental 173 tension as "editorial balance,"" and maintaining this balance is a 174 continuing concern for the RFC Editor. There is a prime directive 175 that must rule over grammatical conventions: do not change the 176 intended meaning of the text. 178 If the RFC Editor cannot edit a document without serious risk of 179 altering the meaning, it may be returned to the stream-approving body 180 for review. See Appendix A.2 for more information. 182 3. RFC Style Conventions 184 This Style Guide does not use terminology as defined in RFC 2119 185 [BCP14]. In this document, lowercase use of "must" and "should" 186 indicates changes the RFC Editor will make automatically to conform 187 with this Style Guide versus those that may be questioned if not 188 applied. The lowercase "must" indicates those changes that will be 189 applied automatically and are not at the discretion of the authors. 190 The lowercase "should" indicates the RFC Editor's recommended use, 191 but conformance with the recommendations is not required; the RFC 192 Editor may question whether the guidance may be applied. 194 3.1. Language 196 The RFC publication language is English. Spelling may be either 197 American or British, as long as an individual document is internally 198 consistent. Where both American and British English spelling are 199 used within a document or cluster of documents, the text will be 200 modified to be consistent with American English spelling. 202 3.2. Punctuation 204 o A comma is used before the last item of a series, e.g., 206 "TCP service is reliable, ordered, and full duplex" 208 o When quoting literal text, punctuation is placed outside quotation 209 marks, e.g., 211 Search for the string "Error Found". 213 When quoting general text, such as general text from another RFC, 214 punctuation may be included within the quotation marks, e.g., 216 RFC 4844 indicates that "RFCs are available free of charge to 217 anyone via the Internet. " 219 Quotation marks are not necessary when text is formatted as a 220 block quotation. 222 3.2.1. RFCs as Compounds 224 Whenever possible: 226 o Hyphenated compounds formed with RFC numbers should be avoided; 227 this can be accomplished by: rewording the sentence (e.g., 228 [RFC5011]-style rollover -> rollover as described in RFC 5011). 230 o adding a note in either the Terminology or Conventions section 231 mentioning the RFC so that other occurrences throughout the text 232 will be understood by the reader to be in the style of said RFC 233 (e.g., This document uses the term "rollover" as defined in RFC 234 5011.). 236 If use of an RFC number in attributive position is unavoidable, the 237 preferred form should appear as in the example "RFC 5011-style 238 rollover". That is: 240 o no hyphen between "RFC" and the number (don't use RFC-5011-style 241 rollover) 243 o avoid hyphenating citations with text (don't use [RFC5011]-style 244 rollover) 246 3.3. DNS Names and URIs 248 DNS names, whether or not in URIs, that are used as generic examples 249 in RFCs should use the particular examples defined in "Reserved Top 250 Level DNS Names" [BCP32], to avoid accidental conflicts. 252 Angle brackets are strongly recommended around URIs [STD66], e.g., 254 256 The use of HTTPS rather than HTTP is strongly encouraged. 258 3.4. Capitalization 260 o Capitalization must be consistent within the document and ideally 261 should be consistent with related RFCs. Refer to the online table 262 of decisions on consistent usage of terms in RFCs [TERMS]. 264 o Per CMOS guidelines, the major words in RFC titles and section 265 titles should be capitalized (this is sometimes called "title 266 case"). Typically, all words in a title will be capitalized, 267 except for internal articles, prepositions, and conjunctions. 269 o Section titles that are in sentence form will follow typical 270 sentence capitalization. 272 o Titles of figures may be in sentence form or use title case. 274 o Some terms related to the various roles or parts of the streams 275 authoring RFCs should be used consistently. For example, when the 276 term 'working group' or 'research group' is used as part of a 277 specific group name, it will be capitalized (e.g., kitten Working 278 Group, Crypto Forum Research Group). When used to generally refer 279 to groups, it will be downcased. 281 3.5. Citations 283 o References and citations must match. That is, there must be a 284 reference for each citation used, and vice versa. 286 o Citations must be enclosed in square brackets (e.g., "[CITE1]"). 288 o Citations are restricted to ASCII-only characters.[RFC7997] 289 o Citations must begin with a number or a letter, and may contain 290 digits, letters, colons, hyphens, underscores, or dots. 292 * Example: "[IEEE.802.15.4]" rather than "[.802.15.4]" 294 * Example: "[RFC2119]" rather than "[RFC 2119]" 296 o Citations may not include spaces, commas, quotation marks, or 297 other punctuation (!, ?, etc.). 299 * Example: "See RFC 2119 [BCP14] for more information." 301 o Cross-references within the body of the memo and to other RFCs 302 must use section numbers rather than page numbers, as pagination 303 may change per format and device. 305 o An citation may a) follow the subject for which it is being cited 306 or b) be read as part of the text. For example: 308 * a) As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 309 [RFC6147] technologies will be utilized by some access networks 310 to provide IPv4 connectivity for IPv6-only nodes [RFC6144]. 312 or 314 b) Note that SAVI raises a number of important privacy 315 considerations that are discussed more fully in [RFC6959]. 317 We recommend using a) and strongly recommend consistent use of one 318 style throughout. 320 3.6. Abbreviation Rules 322 Abbreviations should be expanded in document titles and upon first 323 use in the document. The full expansion of the text should be 324 followed by the abbreviation itself in parentheses. The exception is 325 an abbreviation that is so common that the readership of RFCs can be 326 expected to recognize it immediately; examples include (but are not 327 limited to) TCP, IP, SNMP, and HTTP. The online list of 328 abbreviations [ABBR] provides guidance. Some cases are marginal, and 329 the RFC Editor will make the final judgment, weighing obscurity 330 against complexity. 332 Note: The online list of abbreviations is not exhaustive or 333 definitive. It is a list of abbreviations appearing in RFCs and 334 sometimes reflects discussions with authors, Working Group Chairs, 335 and/or Area Directors (ADs). Note that some abbreviations have 336 multiple expansions. Additionally, this list includes some terms 337 that look like abbreviations but that are actually fixed names for 338 things and hence cannot and should not be expanded. These are noted 339 as "No Expansion". 341 3.7. Images and Figures 343 The goal of having images within an RFC is to convey information. A 344 good diagram or image expresses information quickly, clearly, and 345 with low chance of misunderstanding. Technically correct but 346 confusing images get in the way of understanding and implementation. 348 o Images should be legible when displayed on a standard screen 349 (1920x1080) and printable on either A4 or US Letter paper. Any 350 text within the diagram should be readable at that resolution. 352 o Authors should use black on white, not white on black. No color 353 or greyscale [RFC7990][RFC7996] 355 o Keep your diagrams as simple as possible. If an object in the 356 diagram is not immediately relevant, leave it out. If you have 357 several ideas you want to convey, consider using more than one 358 diagram. 360 o San-serif fonts are generally considered more readable for digital 361 material. [citation needed] 363 o The style of diagrams within an RFC should be consistent both 364 within a single RFC and within a cluster of RFCs (fonts, shapes, 365 lines). For example, if you you use a dashed line to indicate a 366 certain type of packet flow, then continue to use that style of 367 line consistently. 369 o Line styles, including thickness, color, and arrow types, are easy 370 methods to convey a particular meaning to the reader. 371 Consistently use the same line styles to convey a particular 372 meaning throughout all diagrams within an RFC in order to avoid 373 confusing the reader. 375 o Flowcharts: avoid crossing the lines if possible. 377 4. Structure of an RFC 379 A published RFC will largely contain the elements in the following 380 list. Some of these sections are required, as noted. Those sections 381 marked with "*" will be supplied by the RFC Editor during the 382 editorial process when necessary. The rules for each of these 383 elements are described in more detail below. 385 First-page header * [Required] 387 Title [Required] 389 Abstract [Required] 391 RFC Editor or Stream Note * [Upon request] 393 Status of This Memo * [Required] 395 Copyright Notice * [Required] 397 Table of Contents * [Required] 399 Body of the Memo [Required] 401 1. Introduction [Required] 403 2. Requirements Language (RFC 2119) 405 3. ... 407 MAIN BODY OF THE TEXT 409 6. ... 411 7. IANA Considerations [Required] 413 8. Internationalization Considerations 415 9. Security Considerations [Required] 417 10. References 419 10.1. Normative References 421 10.2. Informative References 423 Appendix A. 425 Appendix B. 427 Acknowledgements 429 Contributors 430 Index 432 Author's Address [Required] 434 Within the body of the memo, the order shown above is strongly 435 recommended. Exceptions may be questioned. Outside the body of the 436 memo, the order above is required. The section numbers above are for 437 illustrative purposes; they are not intended to correspond to 438 required numbering in an RFC. 440 The elements preceding the body of the memo should not be numbered. 441 Typically, the body of the memo will have numbered sections and the 442 appendices will be labeled with letters. Any sections that appear 443 after the appendices should not be numbered or labeled (e.g., see 444 "Contributors" above). 446 4.1. First-Page Header 448 Headers will follow the format described in "RFC Streams, Headers, 449 and Boilerplates" [RFC7841] and its successors. In addition, the 450 following conventions will apply. 452 4.1.1. Author/Editor 454 The final determination of who should be listed as an author or 455 editor on an RFC is made by the stream, as is whether or not 456 including author affiliation is required. 458 The author's name (initial followed by family name) appears on the 459 first line of the heading. Some variation, such as additional 460 initials or capitalization of family name, is acceptable. Once the 461 author has selected how their name should appear, they should use 462 that display consistently in all of their documents. 464 The total number of authors or editors on the first page is generally 465 limited to five individuals and their affiliations. If there is a 466 request for more than five authors, the stream-approving body needs 467 to consider if one or two editors should have primary responsibility 468 for this document, with the other individuals listed in the 469 Contributors or Acknowledgements section. There must be a direct 470 correlation of authors and editors in the document header and the 471 Authors' Addresses section. These are the individuals that must sign 472 off on the document during the AUTH48 process and respond to 473 inquiries, such as errata. 475 4.1.2. Organization 477 The author's organization is indicated on the line following the 478 author's name. 480 For multiple authors, each author name appears on its own line, 481 followed by that author's organization. When more than one author is 482 affiliated with the same organization, the organization can be 483 "factored out," appearing only once following the corresponding 484 Author lines. However, such factoring is inappropriate when it would 485 force an unacceptable reordering of author names. 487 If an author cannot or will not provide an affiliation for any 488 reason, "Independent", "Individual Contributor", "Retired", or some 489 other term that appropriately describes the author's affiliation may 490 be used. Alternatively, a blank line may be included in the document 491 header when no affiliation is provided. 493 4.1.3. ISSN: 2070-1721 495 The RFC Series has been assigned an International Standard Serial 496 Number of 2070-1721 [ISO3297]. It will be included by the RFC 497 Editor. 499 4.1.4. Updates and Obsoletes 501 When an RFC obsoletes or updates a previously published RFC or RFCs, 502 this information is included in the document header. For example: 504 "Updates: nnnn" or "Updates: nnnn, ..., nnnn" 506 "Obsoletes: nnnn" or "Obsoletes: nnnn, ..., nnnn" 508 If the document updates or obsoletes more than one document, numbers 509 will be listed in ascending order. 511 4.2. Document Title 513 The title must be centered below the rest of the heading, preceded by 514 two blank lines and followed by one blank line. 516 Choosing a good title for an RFC can be a challenge. A good title 517 should fairly represent the scope and purpose of the document without 518 being either too general or too specific and lengthy. 520 Abbreviations in a title must generally be expanded when first 521 encountered (see Section 3.6 for additional guidance on 522 abbreviations). 524 It is often helpful to follow the expansion with the parenthesized 525 abbreviation, as in the following example: 527 Encoding Rules for the 528 Common Routing Encapsulation Extension Protocol (CREEP) 530 The RFC Editor recommends that documents describing a particular 531 company's private protocol should bear a title of the form "Foo's ... 532 Protocol" (where Foo is a company name), to clearly differentiate it 533 from a protocol of more general applicability. 535 4.3. Abstract Section 537 Every RFC must have an Abstract that provides a concise and 538 comprehensive overview of the purpose and contents of the entire 539 document, to give a technically knowledgeable reader a general 540 overview of the function of the document and some context with 541 regards to its relationship (in particular, whether it updates or 542 obsoletes) any other RFCs. In addition to its function in the RFC 543 itself, the Abstract section text will appear in publication 544 announcements and in the online index of RFCs. 546 Composing a useful Abstract generally requires thought and care. 547 Usually, an Abstract should begin with a phrase like "This memo ..." 548 or "This document ..." A satisfactory Abstract can often be 549 constructed in part from material within the Introduction section, 550 but an effective Abstract may be shorter, less detailed, and perhaps 551 broader in scope than the Introduction. Simply copying and pasting 552 the first few paragraphs of the Introduction is allowed, but it may 553 result in an Abstract that is overly long, incomplete, and redundant. 555 An Abstract is not a substitute for an Introduction; the RFC should 556 be self-contained as if there were no Abstract. Similarly, the 557 Abstract should be complete in itself. Given that the Abstract will 558 appear independently in announcements and indices, mentions of other 559 RFCs within the Abstract should include both an RFC number and either 560 the full or short title. Any documents that are Updated or Obsoleted 561 by the RFC must be mentioned in the Abstract. These may be presented 562 in a list format if that improves readability. 564 4.4. RFC Editor or Stream Notes Section 566 A stream-approving body may approve the inclusion of an editorial 567 note to explain anything unusual about the process that led to the 568 document's publication or to note a correction. In this case, a 569 stream note section will contain such a note. 571 Additionally, an RFC Editor Note section may contain a note inserted 572 by the RFC Editor to highlight special circumstances surrounding an 573 RFC. 575 4.5. Status of This Memo Section 577 The RFC Editor will supply an appropriate "Status of This Memo" as 578 defined in RFC [RFC7841] and "Format for RFCs in the IAB Stream" 579 [IAB-FORM]. 581 4.6. Copyright, Licenses, and IPR Boilerplate Section 583 The full copyright and license notices are available on the IETF 584 Trust Legal Provisions documents website [IETF-TRUST]. 586 4.7. Table of Contents Section 588 A Table of Contents (TOC) is required in all RFCs. It must be 589 positioned after the Copyright Notice and before the Introduction. 591 4.8. Body of the Memo 593 Following the TOC is the body of the memo. 595 Each RFC must include an Introduction section that (among other 596 things) explains the motivation for the RFC and (if appropriate) 597 describes the applicability of the document, e.g., whether it 598 specifies a protocol, provides a discussion of some problem, is 599 simply of interest to the Internet community, or provides a status 600 report on some activity. The body of the memo and the Abstract must 601 be self-contained and separable. This may result in some duplication 602 of text between the Abstract and the Introduction; this is 603 acceptable. 605 4.8.1. Introduction Section 607 The Introduction section should always be the first section following 608 the TOC (except in the case of MIB module documents). While 609 "Introduction" is recommended, authors may choose alternate titles 610 such as "Overview" or "Background". These alternates are acceptable. 612 For MIB module documents, common practice has been for "The Internet- 613 Standard Management Framework" [MIB-BOILER] text to appear as 614 Section 1. 616 4.8.2. Requirements Language Section 618 Some documents use certain capitalized words ("MUST", "SHOULD", etc.) 619 to specify precise requirement levels for technical features. RFC 620 2119 [BCP14] defines a default interpretation of these capitalized 621 words in IETF documents. If this interpretation is used, RFC 2119 622 must be cited (as specified in RFC 2119) and included as a normative 623 reference. Otherwise, the correct interpretation must be specified 624 in the document. 626 This section must appear as part of the body of the memo (as defined 627 by this document). It must appear as part of, or subsequent to, the 628 Introduction section. 630 These words are considered part of the technical content of the 631 document and are intended to provide guidance to implementers about 632 specific technical features, generally governed by considerations of 633 interoperability. RFC 2119 says: 635 Imperatives of the type defined in this memo must be used with care 636 and sparingly. In particular, they MUST only be used where it is 637 actually required for interoperation or to limit behavior which has 638 potential for causing harm (e.g., limiting retransmisssions) For 639 example, they must not be used to try to impose a particular method 640 on implementers where the method is not required for 641 interoperability. 643 4.8.3. IANA Considerations Section 645 For guidance on how to register IANA-related values or create new 646 registries to be managed by IANA, see "Guidelines for Writing an IANA 647 Considerations Section in RFCs" [BCP26]. 649 The RFC Editor will update text accordingly after the IANA 650 assignments have been made. It is helpful for authors to clearly 651 identify where text should be updated to reflect the newly assigned 652 values. For example, the use of "TBD1", "TBD2", etc., is recommended 653 in the IANA Considerations section and in the body of the memo. 655 If the authors have provided values to be assigned by IANA, the RFC 656 Editor will verify that the values inserted by the authors match 657 those that have actually been registered on the IANA site. When 658 writing a given value, consistent use of decimal or hexadecimal is 659 recommended. 661 If any of the IANA-related information is not clear, the RFC Editor 662 will work with IANA to send queries to the authors to ensure that 663 assignments and values are properly inserted. 665 4.8.4. Internationalization Considerations Section 667 All RFCs that deal with internationalization issues should have a 668 section describing those issues; see "IETF Policy on Character Sets 669 and Languages" [BCP18], Section 6, for more information. 671 4.8.5. Security Considerations Section 673 All RFCs must contain a section that discusses the security 674 considerations relevant to the specification; see "Guidelines for 675 Writing RFC Text on Security Considerations" [BCP72] for more 676 information. 678 Note that additional boilerplate material for RFCs containing MIB and 679 YANG modules also exists. See "Security Guidelines for IETF MIB 680 Modules" [MIB-SEC] and "yang module security considerations" 681 [YANG-SEC] for details. 683 4.8.6. References Section 685 The reference list is solely for recording reference entries. 686 Introductory text is not allowed. 688 The RFC style allows the use of any of a variety of reference styles, 689 as long as they are used consistently within a document. However, 690 where necessary, some reference styles have been described for use 691 within the Series. See the examples in this document. 693 The RFC Editor ensures that references to other RFCs refer to the 694 most current RFC available on that topic (unless provided with a 695 reason not to do so). When referring to an obsoleted document, it is 696 common practice to also refer to the most recent version. 698 A reference to an RFC that has been assigned an STD [RFC1311], BCP 699 [RFC1818], or FYI [FYI90] sub-series number must include the sub- 700 series number of the document. Note that the FYI series was ended by 701 RFC 6360. RFCs that were published with an FYI sub-series number and 702 still maintain the FYI number must include the sub-series number in 703 the reference. 705 Reference lists must indicate whether each reference is normative or 706 informative, where normative references are essential to implementing 707 or understanding the content of the RFC and informative references 708 provide additional information. More information about normative and 709 informative references may be found in the IESG's statement 710 "Normative and Informative References" [REFS]. When both normative 711 and informative references exist, the references section should be 712 split into two subsections: 714 Templates are available on the RFC Editor website for the XML format 715 of certain references [REFEXAMPLE]. 717 s. References 719 s.1. Normative References 721 xxx 722 ... 723 xxx 725 s.2. Informative References 727 xxx 728 ... 729 xxx 731 References will generally appear in alphanumeric order by citation 732 tag. Where there are only normative or informative references, no 733 subsection is required; the top-level section should say "Normative 734 References" or "Informative References". 736 Normative references to Internet-Drafts will cause publication of the 737 RFC to be suspended until the referenced draft is also ready for 738 publication; the RFC Editor will then update the entry to refer to 739 the RFC and publish both documents simultaneously. 741 4.8.6.1. URIs in RFCs 743 The use of URIs in references is acceptable, as long as the URI is 744 the most stable (i.e., unlikely to change and expected to be 745 continuously available) and direct reference possible. The URI will 746 be verified as valid during the RFC editorial process. 748 If a dated URI (one that includes a timestamp for the page) is 749 available for a referenced web page, its use is required. 751 Note that URIs may not be the sole information provided for a 752 reference entry. 754 The use of HTTPS rather than HTTP is strongly encouraged. 756 4.8.6.2. Referencing RFCs 758 The following format is required for referencing RFCs. The Stream 759 abbreviation should be used; when no stream is available, as with 760 legacy RFCs, this may be left blank. 762 Note the ordering for multiple authors: the format of the name of the 763 last author listed is different than that of all previous authors in 764 the list. 766 For one author or editor: 768 [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC 769 Title", Stream, Sub-series number (if applicable), RFC number, DOI, 770 Date of publication, https://www.rfc-editor.org/info/rfc# [1]. 772 Example: 774 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core," 775 IETF, RFC 3080, DOI 10.17487/RFC3080, March 2001, https://www.rfc- 776 editor.org/info/rfc3080 [2]. 778 [RFC8157] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M. 779 Cullen, "Huawei's GRE Tunnel Bonding Protocol", independent, RFC 780 8157, DOI 10.17487/RFC8157, May 2017, https://www.rfc- 781 editor.org/info/rfc8157 [3]. 783 For two authors or editors: 785 [RFCXXXX] Last name, First initial., Ed. (if applicable) and First 786 initial. Last name, Ed. (if applicable), "RFC Title", Stream, Sub- 787 series number (if applicable), RFC number, DOI, Date of publication, 788 https://www.rfc-editor.org/info/rfc# [4]. 790 Example: 792 [RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option 793 for the Datagram Congestion Control Protocol (DCCP)", IETF, RFC 6323, 794 DOI 10.17487/RFC6323, July 2011, https://www.rfc-editor.org/info/ 795 rfc6323 [5]. 797 For three or more authors or editors: 799 [RFCXXXX] Last name, First initial., Ed. (if applicable), Last name, 800 First initial., Ed. (if applicable), and First initial. Last name, 801 Ed. (if applicable), "RFC Title", Stream, Sub-series number (if 802 applicable), RFC number, DOI, Date of publication, https://www.rfc- 803 editor.org/info/rfc# [6]. 805 Example: 807 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender 808 Clarification for Persist Condition", IETF, RFC 6429, DOI 10.17487/ 809 RFC6429, December 2011, https://www.rfc-editor.org/info/rfc6429 [7]. 811 4.8.6.3. Referencing STDs and BCPs 813 Internet Standards (STDs) and Best Current Practices (BCPs) may 814 consist of a single RFC or multiple RFCs. When an STD or BCP that 815 contains multiple RFCs is referenced, the reference entry should 816 include ALL of the RFCs comprising that sub-series. The authors 817 should refer to specific RFC numbers as part of the text (not as 818 citations) and cite the sub-series number. Inclusion of the URI to 819 the STD or BCP info page is recommended. The text should appear as 820 follows: 822 See RFC 1034 [STD13]. 824 For an STD or BCP that contains one RFC: 826 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC 827 Title", Stream, Sub-series number, RFC number, DOI, Date of 828 publication, https://www.rfc-editor.org/info/std# [8]. 830 Example: 832 [STD72] Gellens, R. and J. Klensin, "Message Submission for Mail", 833 IETF, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 834 https://www.rfc-editor.org/info/std72 [9]. 836 For an STD or BCP that contains two or more RFCs: 838 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC 839 Title", Stream, Sub-series number, RFC number, DOI, Date of 840 publication. 842 Last name, First initial., Ed. (if applicable) 843 and First initial. Last name, Ed. (if applicable), 844 "RFC Title", Stream, Sub-series number, RFC number, DOI, 845 Date of publication. 847 849 Example: 851 [STD13] Mockapetris, P., "Domain names - concepts and facilities", 852 IETF, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. 854 Mockapetris, P., "Domain names - implementation and 855 specification", IETF, STD 13, RFC 1035, DOI 10.17487/RFC1035, 856 November 1987. 858 860 4.8.6.4. Referencing Internet-Drafts 862 References to Internet-Drafts may only appear as informative 863 references. Given that several revisions of an I-D may be produced 864 in a short time frame, references must include the posting date 865 (month and year), the full Internet-Draft file name (including the 866 version number), and the phrase "Work in Progress". Authors may 867 reference multiple versions of an I-D. If the referenced I-D was 868 also later published as an RFC, then that RFC must also be listed. 870 [SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and 871 First initial. Last name, Ed. (if applicable), "I-D Title", Work in 872 Progress, draft-string-NN, Month Year. 874 Example: 876 [RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in 877 Progress, draft-flanagan-style-01, June 2013. 879 4.8.6.5. Referencing Errata 881 The following format is required when a reference to an erratum 882 report is necessary: 884 [ErrNumber] RFC Errata, Erratum ID number, RFC number, 885 . 887 [Err1912] RFC Errata, Erratum ID 1912, RFC 2978, . 890 4.8.6.6. Referencing Other Standards Development Organizations (SDOs) 892 The following format is suggested when referencing a document or 893 standard from another SDO in which authors are listed: 895 [SYMBOLIC-TAG] 897 Last name, First initial. and First initial. Last name, 899 "Document Title", Document reference number, Date of 901 publication, . 903 [W3C.REC-xml11] 905 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., 907 Yergeau, F., and J. Cowan, "Extensible Markup Language 908 (XML) 1.1 (Second Edition)", W3C Recommendation 910 REC-xml11-20060816, August 2006, 912 . 914 The order of authors in the list is the same as the order shown on 915 the actual document and that the common, abbreviated form of the SDO 916 is used. 918 Alternatively, when no list of authors is available, the following 919 format is recommended: 921 [SYMBOLIC-TAG] Organization, "Document Title", Document 922 reference number, Date of publication, 923 . 925 Example (undated; see note below): 927 [IEEE.802.15.4] 928 IEEE, "IEEE Standard for Low-Rate Wireless Networks", 929 IEEE 802.15.4, 930 . 932 Example (dated; see note below): 934 [IEEE802.1Q] IEEE, "Local and Metropolitan Area 935 Networks -- Media Access Control (MAC) 936 Bridges and Virtual Bridged Local Area 937 Networks", IEEE Std 802.1Q-2011, August 2011, 938 941 Per the IEEE coordination team, listing dates for IEEE standards is 942 not recommended unless there is a need to cite a particular section, 943 in which case the dated reference is appropriate. An RFC with a 944 dated IEEE reference suggests that the RFC only applies to that 945 specific IEEE specification. 947 4.8.6.7. Referencing Email on Mailing Lists 949 When referencing emails to mailing lists, the template provided here 950 should be used: 952 [reftag] Sender, A., "Subject: Subject line", message to the 954 listname mailing list, DD Month YYYY, . 956 4.9. Appendices Section 958 The RFC Editor recommends placing references before the Appendices. 959 Appendices should be labeled as "Appendix A. Title", "A.1. Title", 960 "Appendix B. Title", etc. 962 4.10. Acknowledgements Section 964 This optional section may be used instead of, or in addition to, a 965 Contributors section. It is often used by authors to publicly thank 966 those who have provided feedback regarding a document and to note any 967 documents from which text was borrowed. 969 4.11. Contributors Section 971 This optional section acknowledges those who have made significant 972 contributions to the document. 974 In a similar fashion to the Author's Address section, the RFC Editor 975 does not make the determination as to who should be listed as a 976 contributor to an RFC. The determination of who should be listed as 977 a contributor is made by the stream. 979 The Contributors section may include brief statements about the 980 nature of particular contributions (e.g., "Sam contributed 981 Section 3"), and it may also include affiliations of listed 982 contributors. At the discretion of the author(s), contact addresses 983 may also be included in the Contributors section, for those 984 contributors whose knowledge makes them useful future contacts for 985 information about the RFC. The format of any contact information 986 should be similar to the format of information in the Author's 987 Address section. 989 4.12. Index 991 If included, an index appears at the end of the document, immediately 992 before Author's Address section. 994 4.13. Author's Address or Authors' Addresses Section 996 This required section gives contact information for the author(s) 997 listed in the first-page header. 999 Contact information must include a long-lived email address and 1000 optionally may include a postal address and/or telephone number. If 1001 the postal address is included, it should include the country name, 1002 using the English short name listed by the ISO 3166 Maintenance 1003 Agency [ISO_OBP]. The purpose of this section is to (1) 1004 unambiguously define author identity (e.g., the John Smith who works 1005 for FooBar Systems) and (2) provide contact information for future 1006 readers who have questions or comments. 1008 The practice of munged email addresses (i.e., altering an email 1009 address to make it less readable to bots and web crawlers to avoid 1010 spam) is not appropriate in an archival document series. Author 1011 contact information is provided so that readers can easily contact 1012 the author with questions and/or comments. Address munging is not 1013 allowed in RFCs. 1015 5. Security Considerations 1017 This document has no security considerations. 1019 6. IANA Considerations 1021 This document has no IANA considerations. 1023 7. Change Log 1025 This section to be removed before publication. 1027 -00 to -01: Citation tag requirements more tightly specified; 1028 index moved; new errata URI added; capitalization of working/ 1029 research group specified; update Abstract guidance 1031 8. References 1033 8.1. Normative References 1035 [STYLE-WEB] 1036 RFC Editor, "Web Portion of the Style Guide", 1037 . 1039 8.2. Informative References 1041 [ABBR] RFC Editor, "RFC Editor Abbreviations List", 1042 . 1045 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997, 1047 . 1049 [BCP18] Alvestrand, H., "IETF Policy on Character Sets and 1050 Languages", BCP 18, RFC 2277, January 1998, 1051 . 1053 [BCP26] Alvestrand, H. and T. Narten, "Guidelines for Writing an 1054 ANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1055 2008, . 1057 [BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1058 Names", BCP 32, RFC 2606, June 1999, 1059 . 1061 [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1062 Text on Security Considerations", BCP 72, RFC 3552, July 1063 2003, . 1065 [CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue", 1066 . 1068 [CMOS] University of Chicago Press, 2010, "Chicago Manual of 1069 Style, 16th ed.", 2010. 1071 [FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to 1072 the FYI Notes", FYI 90, RFC 1150, March 1990, 1073 . 1075 Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, 1076 August 2011. 1078 [IAB-FORM] 1079 IAB, "Format for RFCs in the IAB Stream", 1080 . 1083 [ID-GUIDE] 1084 IETF, "Guidelines to Authors of Internet Drafts", 1085 . 1087 [IETF-TRUST] 1088 IETF Trust, "Trust Legal Provisions (TLP)", 1089 . 1091 [ISO3297] Technical Committee ISO/TC 46, Information and 1092 documentation, Subcommittee SC 9, "Identification and 1093 description, Information and documentation - International 1094 standard serial number (ISSN)", September 2007. 1096 [ISO_OBP] ISO, "Online Browsing Platform (OBP)", 1097 . 1099 [MIB-BOILER] 1100 IETF OPS Area, "Boilerplate for IETF MIB Documents", 1101 . 1103 [MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules", 1104 . 1107 [REFEXAMPLE] 1108 RFC Editor, "Reference Examples", 1109 . 1111 [REFS] IESG, "IESG Statement: Normative and Informative", 1112 . 1115 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 1116 DOI 10.17487/RFC1311, March 1992, 1117 . 1119 [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current 1120 Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995, 1121 . 1123 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 1124 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 1125 July 2007, . 1127 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 1128 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 1129 2012, . 1131 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 1132 "RFC Streams, Headers, and Boilerplates", RFC 7841, 1133 DOI 10.17487/RFC7841, May 2016, 1134 . 1136 [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, 1137 DOI 10.17487/RFC7990, December 2016, 1138 . 1140 [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", 1141 RFC 7996, DOI 10.17487/RFC7996, December 2016, 1142 . 1144 [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in 1145 RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, 1146 . 1148 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1149 Resource Identifier (URI): Generic Syntax", STD 66, 1150 RFC 3986, January 2005, 1151 . 1153 [TERMS] RFC Editor, "Terms List", 1154 . 1156 [YANG-SEC] 1157 IETF Ops Area, "yang module security considerations", 1158 . 1161 8.3. URIs 1163 [1] https://www.rfc-editor.org/info/rfc# 1165 [2] https://www.rfc-editor.org/info/rfc3080 1167 [3] https://www.rfc-editor.org/info/rfc8157 1169 [4] https://www.rfc-editor.org/info/rfc# 1171 [5] https://www.rfc-editor.org/info/rfc6323 1173 [6] https://www.rfc-editor.org/info/rfc# 1175 [7] https://www.rfc-editor.org/info/rfc6429 1177 [8] https://www.rfc-editor.org/info/std# 1179 [9] https://www.rfc-editor.org/info/std72 1181 Appendix A. Related Procedures 1183 The following procedures are related to the application and updating 1184 of the RFC Style Guide. 1186 A.1. Dispute Resolution 1188 There are competing rationales for some of the rules described in 1189 this Guide, and the RFC Editor has selected the ones that work best 1190 for the Series. However, at times, an author may have a disagreement 1191 with the RFC Production Center (RPC) over the application of Style 1192 Guide conventions. In such cases, the authors should discuss their 1193 concerns with the RPC. If no agreement can be reached between the 1194 RPC and the authors, the RFC Series Editor will, with input from the 1195 appropriate stream-approving body, make a final determination. If 1196 further resolution is required, the dispute resolution process as 1197 described in the RFC Editor Model [RFC6635] will be followed. 1199 A.2. Returning an I-D to the Document Stream 1201 For a given document, if the RFC Editor determines that it cannot be 1202 edited without serious risk of altering the meaning of the technical 1203 content or if the RFC Editor does not have the resources to provide 1204 the level of editing it needs, it may be sent back to the stream- 1205 approving body with a request to improve the clarity, consistency, 1206 and/or readability of the document. This is not to be considered a 1207 dispute with the author. 1209 A.3. Revising This Document and Associated Web Pages 1211 The RFC Series is continually evolving as a document series. This 1212 document focuses on the fundamental and stable requirements that must 1213 be met by an RFC. From time to time, the RFC Editor may offer less 1214 formal recommendations that authors may apply at their discretion; 1215 these recommendations may be found on the RFC Editor website 1216 "Guidelines for RFC Style" [STYLE-WEB]. 1218 When a new recommendation is made regarding the overall structure and 1219 formatting of RFCs, it will be published on that page and accepted 1220 for a period of time before the RFC Editor determines whether it 1221 should become part of the fundamental requirements in the RFC Style 1222 Guide or remain as a less formal recommendation. That period of time 1223 will vary, in part depending on the frequency with which authors 1224 encounter and apply the guidance. 1226 Authors' Addresses 1228 Heather Flanagan 1229 RFC Editor 1231 EMail: rse@rfc-editor.org 1232 URI: https://orcid.org/0000-0002-2647-2220 1234 Sandy Ginoza 1235 RFC Editor 1237 EMail: rfc-editor@rfc-editor.org 1238 URI: https://www.rfc-editor.org