idnits 2.17.1 draft-flanagan-7322bis-05.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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 3, 2020) is 1477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6146' is mentioned on line 321, but not defined == Missing Reference: 'RFC6147' is mentioned on line 322, but not defined == Missing Reference: 'RFC6144' is mentioned on line 324, but not defined == Missing Reference: 'RFC6959' is mentioned on line 327, but not defined == Missing Reference: 'Required' is mentioned on line 430, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 773, but not defined -- Looks like a reference, but probably isn't: '1' on line 1218 == Missing Reference: 'RFC3080' is mentioned on line 748, but not defined -- Looks like a reference, but probably isn't: '2' on line 1220 == Missing Reference: 'RFC8157' is mentioned on line 752, but not defined -- Looks like a reference, but probably isn't: '3' on line 1222 -- Looks like a reference, but probably isn't: '4' on line 1224 == Missing Reference: 'RFC6323' is mentioned on line 766, but not defined -- Looks like a reference, but probably isn't: '5' on line 1226 -- Looks like a reference, but probably isn't: '6' on line 1228 == Missing Reference: 'RFC6429' is mentioned on line 781, but not defined ** Obsolete undefined reference: RFC 6429 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '7' on line 1230 == Missing Reference: 'RFC5741' is mentioned on line 804, but not defined ** Obsolete undefined reference: RFC 5741 (Obsoleted by RFC 7841) == Missing Reference: 'STD13' is mentioned on line 834, but not defined == Missing Reference: 'STDXXX' is mentioned on line 822, but not defined -- Looks like a reference, but probably isn't: '8' on line 1232 == Missing Reference: 'STD72' is mentioned on line 816, but not defined -- Looks like a reference, but probably isn't: '9' on line 1234 == Missing Reference: 'SYMBOLIC-TAG' is mentioned on line 967, but not defined == Missing Reference: 'RFC-STYLE' is mentioned on line 868, but not defined == Missing Reference: 'ErrNumber' is mentioned on line 876, but not defined == Missing Reference: 'Err1912' is mentioned on line 879, but not defined == Missing Reference: 'IANA-SYMBOLIC-TAG' is mentioned on line 887, but not defined == Missing Reference: 'IEEE.802.15.4' is mentioned on line 929, but not defined == Missing Reference: 'IEEE802.1Q' is mentioned on line 936, but not defined == Missing Reference: 'ISOC-MANRS' is mentioned on line 970, 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: 2 errors (**), 0 flaws (~~), 24 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine, Ed. 3 Internet-Draft Temporary RFC Series Project Manager 4 Obsoletes: 7322 (if approved) S. Ginoza 5 Intended status: Informational RFC Editor 6 Expires: October 5, 2020 April 3, 2020 8 RFC Style Guide 9 draft-flanagan-7322bis-05 11 Abstract 13 This document describes the fundamental and unique style conventions 14 and editorial policies currently in use for the RFC Series. It 15 captures the RFC Editor's basic requirements and offers guidance 16 regarding the style and structure of an RFC. Additional guidance is 17 captured on a website that reflects the experimental nature of that 18 guidance and prepares it for future inclusion in the RFC Style Guide. 19 This document obsoletes RFC 7322, "RFC Style Guide". 21 Status of This Memo 23 This Internet-Draft is submitted 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 5, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. RFC Editor's Philosophy . . . . . . . . . . . . . . . . . . . 3 57 3. RFC Style Conventions . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Language . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Punctuation . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. RFCs as Compounds . . . . . . . . . . . . . . . . . . 5 61 3.3. DNS Names and URIs . . . . . . . . . . . . . . . . . . . 6 62 3.4. Capitalization . . . . . . . . . . . . . . . . . . . . . 6 63 3.5. Citations . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Abbreviation Rules . . . . . . . . . . . . . . . . . . . 8 65 3.7. Images and Figures . . . . . . . . . . . . . . . . . . . 8 66 4. Structure of an RFC . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. First-Page Header . . . . . . . . . . . . . . . . . . . . 10 68 4.1.1. Author/Editor . . . . . . . . . . . . . . . . . . . . 11 69 4.1.2. Organization . . . . . . . . . . . . . . . . . . . . 11 70 4.1.3. ISSN: 2070-1721 . . . . . . . . . . . . . . . . . . . 11 71 4.1.4. Updates and Obsoletes . . . . . . . . . . . . . . . . 12 72 4.2. Document Title . . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Abstract Section . . . . . . . . . . . . . . . . . . . . 12 74 4.4. RFC Editor or Stream Notes Section . . . . . . . . . . . 13 75 4.5. Status of This Memo Section . . . . . . . . . . . . . . . 13 76 4.6. Copyright, Licenses, and IPR Boilerplate Section . . . . 13 77 4.7. Table of Contents Section . . . . . . . . . . . . . . . . 13 78 4.8. Body of the Memo . . . . . . . . . . . . . . . . . . . . 14 79 4.8.1. Introduction Section . . . . . . . . . . . . . . . . 14 80 4.8.2. Requirements Language Section . . . . . . . . . . . . 14 81 4.8.3. IANA Considerations Section . . . . . . . . . . . . . 15 82 4.8.4. Internationalization Considerations Section . . . . . 15 83 4.8.5. Security Considerations Section . . . . . . . . . . . 15 84 4.8.6. References Section . . . . . . . . . . . . . . . . . 16 85 4.9. Appendices Section . . . . . . . . . . . . . . . . . . . 22 86 4.10. Acknowledgements Section . . . . . . . . . . . . . . . . 22 87 4.11. Contributors Section . . . . . . . . . . . . . . . . . . 23 88 4.12. Index . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 4.13. Author's Address or Authors' Addresses Section . . . . . 23 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 95 8.2. Informative References . . . . . . . . . . . . . . . . . 24 96 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 Appendix A. Related Procedures . . . . . . . . . . . . . . . . . 28 99 A.1. Dispute Resolution . . . . . . . . . . . . . . . . . . . 28 100 A.2. Returning an I-D to the Document Stream . . . . . . . . . 28 101 A.3. Revising This Document and Associated Web Pages . . . . . 28 102 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 29 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Introduction 107 The ultimate goal of the RFC publication process is to produce 108 documents that are readable, clear, and consistent. The basic 109 formatting conventions for RFCs were established in the 1970s by the 110 original RFC Editor, Jon Postel. This document describes the 111 fundamental and unique style conventions and editorial policies 112 currently in use for the RFC Series [RFC4844] and is intended as a 113 stable, infrequently updated reference for authors, editors, and 114 reviewers. 116 The RFC Editor also maintains a web portion of the Style Guide (see 117 Appendix A.3) that describes issues as they are raised and indicates 118 how the RFC Editor intends to address them. As new style issues 119 arise, the RFC Editor will first address them on the web portion of 120 the Style Guide [STYLE-WEB]. These topics may become part of the RFC 121 Style Guide when it is revised. 123 The world of publishing has generally accepted rules for grammar, 124 punctuation, capitalization, sentence length and complexity, etc. 125 The RFC Editor generally follows these accepted rules as defined by 126 the Chicago Manual of Style (CMOS) [CMOS], with a few important 127 exceptions to avoid ambiguity in complex technical prose and to 128 handle mixtures of text and computer languages, or to preserve 129 historical formatting rules. This document presents these exceptions 130 as applied or recommended by the RFC Editor. 132 All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a 133 well-written and properly constructed Internet-Draft [ID-GUIDE] 134 provides a strong basis for a good RFC. The RFC Editor accepts 135 Internet-Drafts from specified streams for publication [RFC4844] and 136 applies the rules and guidelines for the RFC Series during the 137 editorial process. 139 2. RFC Editor's Philosophy 141 Authors may find it helpful to understand the RFC Editor's goals 142 during the publication process, namely to: 144 o Prepare the document according to RFC style and format. 146 o Make the document as clear, consistent, and readable as possible. 148 o Correct larger content/clarity issues; flag any unclear passages 149 for author review. 151 o Fix inconsistencies (e.g., terms that appear in various forms, 152 inconsistent capitalization, discrepancies between a figure and 153 the text that describes it). 155 We strive for consistency within: 157 a. the document, 159 b. a cluster of documents [CLUSTER], and 161 c. the series of RFCs on the subject matter. 163 The editorial process of the RFC Editor is not an additional 164 technical review of the document. Where the RFC Editor may suggest 165 changes in wording for clarity and readability, it is up to the 166 author, working group, or stream-approving body to determine whether 167 the changes have an impact on the technical meaning of the document 168 [RFC4844]. If the original wording is a more accurate representation 169 of the technical content being described in the document, it takes 170 precedence over editorial conventions. 172 The activity of editing sometimes creates a tension between author 173 and editor. The RFC Editor attempts to minimize this conflict for 174 RFC publication while continually striving to produce a uniformly 175 excellent document series. The RFC Editor refers to this fundamental 176 tension as "editorial balance," and maintaining this balance is a 177 continuing concern for the RFC Editor. There is a prime directive 178 that must rule over grammatical conventions: do not change the 179 intended meaning of the text. 181 If the RFC Editor cannot edit a document without serious risk of 182 altering the meaning, it may be returned to the stream-approving body 183 for review. See Appendix A.2 for more information. 185 3. RFC Style Conventions 187 This Style Guide does not use terminology as defined in RFC 2119 188 [BCP14]. In this document, lowercase use of "must" and "should" 189 indicates changes the RFC Editor will make automatically to conform 190 with this Style Guide versus those that may be questioned if not 191 applied. The lowercase "must" indicates those changes that will be 192 applied automatically and are not at the discretion of the authors. 193 The lowercase "should" indicates the RFC Editor's recommended use, 194 but conformance with the recommendations is not required; the RFC 195 Editor may question whether the guidance may be applied. 197 3.1. Language 199 The RFC publication language is English. Spelling may be either 200 American or British, as long as an individual document is internally 201 consistent. Where both American and British English spelling are 202 used within a document or cluster of documents, the text will be 203 modified to be consistent with American English spelling. 205 3.2. Punctuation 207 1. A comma is used before the last item of a series, e.g., 209 "TCP service is reliable, ordered, and full duplex" 211 2. When quoting literal text, punctuation is placed outside 212 quotation marks, e.g., 214 Search for the string "Error Found". 216 When quoting general text, such as general text from another RFC, 217 punctuation may be included within the quotation marks, e.g., 219 RFC 4844 indicates that "RFCs are available free of charge to 220 anyone via the Internet." 222 Quotation marks are not necessary when text is formatted as a 223 block quotation. 225 3.2.1. RFCs as Compounds 227 Whenever possible: 229 o Hyphenated compounds formed with RFC numbers should be avoided; 230 this can be accomplished by: rewording the sentence (e.g., change 231 "[RFC5011]-style rollover" to "rollover as described in RFC 232 5011"). 234 o adding a note in either the Terminology or Conventions section 235 mentioning the RFC so that other occurrences throughout the text 236 will be understood by the reader to be in the style of said RFC 237 (e.g., This document uses the term "rollover" as defined in RFC 238 5011.). 240 If use of an RFC number in attributive position is unavoidable, the 241 preferred form should appear as in the example "RFC 5011-style 242 rollover". That is: 244 o no hyphen between "RFC" and the number (don't use RFC-5011-style 245 rollover) 247 o avoid hyphenating citations with text (don't use [RFC5011]-style 248 rollover) 250 3.3. DNS Names and URIs 252 DNS names, whether or not in URIs, that are used as generic examples 253 in RFCs should use the particular examples defined in "Reserved Top 254 Level DNS Names" [BCP32], to avoid accidental conflicts. 256 Angle brackets are strongly recommended around URIs [STD66], e.g., 258 260 The use of HTTPS rather than HTTP is strongly encouraged. 262 3.4. Capitalization 264 1. Capitalization must be consistent within the document and ideally 265 should be consistent with related RFCs. Refer to the online 266 table of decisions on consistent usage of terms in RFCs [TERMS]. 268 2. Per CMOS guidelines, the major words in RFC titles and section 269 titles should be capitalized (this is sometimes called "title 270 case"). Typically, all words in a title will be capitalized, 271 except for internal articles, prepositions, and conjunctions. 273 3. Section titles that are in sentence form will follow typical 274 sentence capitalization. 276 4. Titles of figures may be in sentence form or use title case. 278 5. Some terms related to the various roles or parts of the streams 279 authoring RFCs should be used consistently. For example, when 280 the term 'working group' or 'research group' is used as part of a 281 specific group name, it will be capitalized (e.g., kitten Working 282 Group, Crypto Forum Research Group). When used to generally 283 refer to groups, it will be downcased. 285 3.5. Citations 287 The most important function of a citation is to point to a reference 288 so that a reader may follow up on additional material that is 289 important in some way to understanding or implementing the content in 290 an RFC. This section offers guidance on the requirements and 291 recommendations for citation format within an RFC. 293 1. References and citations must match. That is, there must be a 294 reference for each citation used, and vice versa. 296 2. Citations must be enclosed in square brackets (e.g., "[CITE1]"). 298 3. Citations are restricted to ASCII-only characters, as described 299 in "The Use of Non-ASCII Characters in RFCs" [RFC7997]. 301 4. Citations must begin with a number or a letter, and may contain 302 digits, letters, colons, hyphens, underscores, or dots. 304 * Example: "[IEEE.802.15.4]" rather than "[.802.15.4]" 306 * Example: "[RFC2119]" rather than "[RFC 2119]" 308 5. Citations may not include spaces, commas, quotation marks, or 309 other punctuation (!, ?, etc.), and should be in-line with the 310 normal line of type. 312 * Example: "See RFC 2119 [BCP14] for more information." 314 6. Cross-references within the body of the memo and to other RFCs 315 must use section numbers rather than page numbers, as pagination 316 may change per format and device. 318 7. A citation may A) follow the subject to which the citation 319 applies or B) be read as part of the text. For example: 321 A. As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 322 [RFC6147] technologies will be utilized by some access 323 networks to provide IPv4 connectivity for IPv6-only nodes 324 [RFC6144]. 326 B. Note that SAVI raises a number of important privacy 327 considerations that are discussed more fully in [RFC6959]. 329 8. For a document referenced multiple times in running text, the 330 citation anchor must be at first use outside the abstract. 331 Additional citations are allowed at the author's discretion. 333 We recommend using A) and strongly recommend consistent use of one 334 style throughout. 336 3.6. Abbreviation Rules 338 Abbreviations should be expanded in document titles and upon first 339 use in the document. The full expansion of the text should be 340 followed by the abbreviation itself in parentheses. The exception is 341 an abbreviation that is so common that the readership of RFCs can be 342 expected to recognize it immediately; examples include (but are not 343 limited to) TCP, IP, SNMP, and HTTP. The online list of 344 abbreviations [ABBR] provides guidance. Some cases are marginal, and 345 the RFC Editor will make the final judgment, weighing obscurity 346 against complexity. 348 Note: The online list of abbreviations is not exhaustive or 349 definitive. It is a list of abbreviations appearing in RFCs and 350 sometimes reflects discussions with authors, Working Group Chairs, 351 and/or Area Directors (ADs). Note that some abbreviations have 352 multiple expansions. Additionally, this list includes some terms 353 that look like abbreviations but that are actually fixed names for 354 things and hence cannot and should not be expanded. These are noted 355 as "No Expansion". 357 3.7. Images and Figures 359 The goal of having images within an RFC is to convey information. A 360 good diagram or image expresses information quickly, clearly, and 361 with low chance of misunderstanding. Technically correct but 362 confusing images get in the way of understanding and implementation. 364 1. Images should be legible when displayed on a standard screen 365 (1920x1080) and printable on either A4 or US Letter paper. Any 366 text within the diagram should be readable at that resolution. 368 2. Authors should use black on white, not white on black. No color 369 or greyscale [RFC7990][RFC7996] 371 3. Keep your diagrams as simple as possible. If an object in the 372 diagram is not immediately relevant, leave it out. If you have 373 several ideas you want to convey, consider using more than one 374 diagram. 376 4. San-serif fonts are generally considered more readable for 377 digital material. [citation needed] 379 5. The style of diagrams within an RFC should be consistent both 380 within a single RFC and within a cluster of RFCs (fonts, shapes, 381 lines). For example, if you you use a dashed line to indicate a 382 certain type of packet flow, then continue to use that style of 383 line consistently. 385 6. Line styles, including thickness, color, and arrow types, are 386 easy methods to convey a particular meaning to the reader. 387 Consistently use the same line styles to convey a particular 388 meaning throughout all diagrams within an RFC in order to avoid 389 confusing the reader. 391 7. Flowcharts: avoid crossing the lines if possible. 393 8. Captions or alternative text are encouraged for all figures, 394 diagrams, and other artwork. [ALTTEXT] [RFC7991] 396 4. Structure of an RFC 398 A published RFC will largely contain the elements in the following 399 list. Some of these sections are required, as noted. Those sections 400 marked with "*" will be supplied by the RFC Editor during the 401 editorial process when necessary. The rules for each of these 402 elements are described in more detail below. 404 First-page header * [Required] 405 Title [Required] 406 Abstract [Required] 407 RFC Editor or Stream Note * [Upon request] 408 Status of This Memo * [Required] 409 Copyright Notice * [Required] 410 Table of Contents * [Required] 411 Body of the Memo [Required] 413 1. Introduction [Required] 414 2. Requirements Language (RFC 2119) 415 3. ... 416 MAIN BODY OF THE TEXT 417 6. ... 418 7. IANA Considerations [Required] 419 8. Internationalization Considerations 420 9. Security Considerations [Required] 421 10. References 422 10.1. Normative References 423 10.2. Informative References 424 Appendix A. 425 Appendix B. 427 Acknowledgements 428 Contributors 429 Index 430 Author's Address [Required] 432 Within the body of the memo, the order shown above is strongly 433 recommended. Exceptions may be questioned. Outside the body of the 434 memo, the order above is required. The section numbers above are for 435 illustrative purposes; they are not intended to correspond to 436 required numbering in an RFC. 438 The elements preceding the body of the memo should not be numbered. 439 Typically, the body of the memo will have numbered sections and the 440 appendices will be labeled with letters. Any sections that appear 441 after the appendices should not be numbered or labeled (e.g., see 442 "Contributors" above). 444 4.1. First-Page Header 446 Headers will follow the format described in "RFC Streams, Headers, 447 and Boilerplates" [RFC7841] and its successors. In addition, the 448 following conventions will apply. 450 4.1.1. Author/Editor 452 The final determination of who should be listed as an author or 453 editor on an RFC is made by the stream, as is whether or not 454 including author affiliation is required. 456 The author's name (initial followed by family name) appears on the 457 first line of the heading. Some variation, such as additional 458 initials or capitalization of family name, is acceptable. Once the 459 author has selected how their name should appear, they should use 460 that display consistently in all of their documents. 462 The total number of authors or editors on the first page is generally 463 limited to five individuals and their affiliations. If there is a 464 request for more than five authors, the stream-approving body needs 465 to consider if one or two editors should have primary responsibility 466 for this document, with the other individuals listed in the 467 Contributors or Acknowledgements section. There must be a direct 468 correlation of authors and editors in the document header and the 469 Authors' Addresses section. These are the individuals that must sign 470 off on the document during the AUTH48 process and respond to 471 inquiries, such as errata. 473 4.1.2. Organization 475 The author's organization is indicated on the line following the 476 author's name. 478 For multiple authors, each author name appears on its own line, 479 followed by that author's organization. When more than one author is 480 affiliated with the same organization, the organization can be 481 "factored out," appearing only once following the corresponding 482 Author lines. However, such factoring is inappropriate when it would 483 force an unacceptable reordering of author names. 485 If an author cannot or will not provide an affiliation for any 486 reason, "Independent", "Individual Contributor", "Retired", or some 487 other term that appropriately describes the author's affiliation may 488 be used. Alternatively, a blank line may be included in the document 489 header when no affiliation is provided. 491 4.1.3. ISSN: 2070-1721 493 The RFC Series has been assigned an International Standard Serial 494 Number of 2070-1721 [ISO3297]. It will be included by the RFC 495 Editor. 497 4.1.4. Updates and Obsoletes 499 When an RFC obsoletes or updates a previously published RFC or RFCs, 500 this information is included in the document header. For example: 502 "Updates: nnnn" or "Updates: nnnn, ..., nnnn" 504 "Obsoletes: nnnn" or "Obsoletes: nnnn, ..., nnnn" 506 If the document updates or obsoletes more than one document, numbers 507 will be listed in ascending order. 509 4.2. Document Title 511 The title must be centered below the rest of the heading, preceded by 512 two blank lines and followed by one blank line. 514 Choosing a good title for an RFC can be a challenge. A good title 515 should fairly represent the scope and purpose of the document without 516 being either too general or too specific and lengthy. 518 Abbreviations in a title must generally be expanded when first 519 encountered (see Section 3.6 for additional guidance on 520 abbreviations). 522 It is often helpful to follow the expansion with the parenthesized 523 abbreviation, as in the following example: 525 Encoding Rules for the 526 Common Routing Encapsulation Extension Protocol (CREEP) 528 The RFC Editor recommends that documents describing a particular 529 company's private protocol should bear a title of the form "Foo's ... 530 Protocol" (where Foo is a company name), to clearly differentiate it 531 from a protocol of more general applicability. 533 4.3. Abstract Section 535 Every RFC must have an Abstract that provides a concise and 536 comprehensive overview of the purpose and contents of the entire 537 document, to give a technically knowledgeable reader a general 538 overview of the function of the document and some context with 539 regards to its relationship (in particular, whether it updates or 540 obsoletes) any other RFCs. In addition to its function in the RFC 541 itself, the Abstract section text will appear in publication 542 announcements and in the online index of RFCs. 544 Composing a useful Abstract generally requires thought and care. 545 Usually, an Abstract should begin with a phrase like "This memo ..." 546 or "This document ..." A satisfactory Abstract can often be 547 constructed in part from material within the Introduction section, 548 but an effective Abstract may be shorter, less detailed, and perhaps 549 broader in scope than the Introduction. Simply copying and pasting 550 the first few paragraphs of the Introduction is allowed, but it may 551 result in an Abstract that is overly long, incomplete, and redundant. 553 An Abstract is not a substitute for an Introduction; the RFC should 554 be self-contained as if there were no Abstract. Similarly, the 555 Abstract should be complete in itself. Given that the Abstract will 556 appear independently in announcements and indices, mentions of other 557 RFCs within the Abstract should include both an RFC number and either 558 the full or short title. Any documents that are Updated or Obsoleted 559 by the RFC must be mentioned in the Abstract if those documents offer 560 important provisions of, or reasons for, the RFC. These may be 561 presented in a list format if that improves readability. 563 4.4. RFC Editor or Stream Notes Section 565 A stream-approving body may approve the inclusion of an editorial 566 note to explain anything unusual about the process that led to the 567 document's publication or to note a correction. In this case, a 568 stream note section will contain such a note. 570 Additionally, an RFC Editor Note section may contain a note inserted 571 by the RFC Editor to highlight special circumstances surrounding an 572 RFC. 574 4.5. Status of This Memo Section 576 The RFC Editor will supply an appropriate "Status of This Memo" as 577 defined in RFC [RFC7841] and "Format for RFCs in the IAB Stream" 578 [IAB-FORM]. 580 4.6. Copyright, Licenses, and IPR Boilerplate Section 582 The full copyright and license notices are available on the IETF 583 Trust Legal Provisions documents website [IETF-TRUST]. 585 4.7. Table of Contents Section 587 A Table of Contents (TOC) is required in all RFCs. It must be 588 positioned after the Copyright Notice and before the Introduction. 590 4.8. Body of the Memo 592 Following the TOC is the body of the memo. 594 Each RFC must include an Introduction section that (among other 595 things) explains the motivation for the RFC and (if appropriate) 596 describes the applicability of the document, e.g., whether it 597 specifies a protocol, provides a discussion of some problem, is 598 simply of interest to the Internet community, or provides a status 599 report on some activity. The body of the memo and the Abstract must 600 be self-contained and separable. This may result in some duplication 601 of text between the Abstract and the Introduction; this is 602 acceptable. 604 4.8.1. Introduction Section 606 The Introduction section should always be the first section following 607 the TOC (except in the case of MIB module documents). While 608 "Introduction" is recommended, authors may choose alternate titles 609 such as "Overview" or "Background". These alternates are acceptable. 611 For MIB module documents, common practice has been for "The Internet- 612 Standard Management Framework" [MIB-BOILER] text to appear as 613 Section 1. 615 4.8.2. Requirements Language Section 617 Some documents use certain capitalized words ("MUST", "SHOULD", etc.) 618 to specify precise requirement levels for technical features. RFC 619 2119 [BCP14] defines a default interpretation of these capitalized 620 words in IETF documents. If this interpretation is used, RFC 2119 621 must be cited (as specified in RFC 2119) and included as a normative 622 reference. Otherwise, the correct interpretation must be specified 623 in the document. 625 This section must appear as part of the body of the memo (as defined 626 by this document). It must appear as part of, or subsequent to, the 627 Introduction section. 629 These words are considered part of the technical content of the 630 document and are intended to provide guidance to implementers about 631 specific technical features, generally governed by considerations of 632 interoperability. RFC 2119 says: 634 Imperatives of the type defined in this memo must be used with care 635 and sparingly. In particular, they MUST only be used where it is 636 actually required for interoperation or to limit behavior which has 637 potential for causing harm (e.g., limiting retransmisssions) For 638 example, they must not be used to try to impose a particular method 639 on implementers where the method is not required for 640 interoperability. 642 4.8.3. IANA Considerations Section 644 For guidance on how to register IANA-related values or create new 645 registries to be managed by IANA, see "Guidelines for Writing an IANA 646 Considerations Section in RFCs" [BCP26]. 648 The RFC Editor will update text accordingly after the IANA 649 assignments have been made. It is helpful for authors to clearly 650 identify where text should be updated to reflect the newly assigned 651 values. For example, the use of "TBD1", "TBD2", etc., is recommended 652 in the IANA Considerations section and in the body of the memo. 654 If the authors have provided values to be assigned by IANA, the RFC 655 Editor will verify that the values inserted by the authors match 656 those that have actually been registered on the IANA site. When 657 writing a given value, consistent use of decimal or hexadecimal is 658 recommended. 660 If any of the IANA-related information is not clear, the RFC Editor 661 will work with IANA to send queries to the authors to ensure that 662 assignments and values are properly inserted. 664 4.8.4. Internationalization Considerations Section 666 All RFCs that deal with internationalization issues should have a 667 section describing those issues; see "IETF Policy on Character Sets 668 and Languages" [BCP18], Section 6, for more information. 670 4.8.5. Security Considerations Section 672 All RFCs must contain a section that discusses the security 673 considerations relevant to the specification; see "Guidelines for 674 Writing RFC Text on Security Considerations" [BCP72] for more 675 information. 677 Note that additional boilerplate material for RFCs containing MIB and 678 YANG modules also exists. See "Security Guidelines for IETF MIB 679 Modules" [MIB-SEC] and "yang module security considerations" 680 [YANG-SEC] for details. 682 4.8.6. References Section 684 The reference list is solely for recording reference entries. 685 Introductory text or annotations beyond necessary translations 686 [RFC7997] are 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 following subsections as well as the 692 References section of this document. 694 Reference lists must indicate whether each reference is normative or 695 informative, where normative references are essential to implementing 696 or understanding the content of the RFC and informative references 697 provide additional information. More information about normative and 698 informative references may be found in the IESG's statement 699 "Normative and Informative References" [REFS]. When both normative 700 and informative references exist, the references section should be 701 split into two subsections: 703 Templates are available on the RFC Editor website for the XML format 704 of certain references [REFEXAMPLE]. 706 s. References 708 s.1. Normative References 710 xxx 711 ... 712 xxx 714 s.2. Informative References 716 xxx 717 ... 718 xxx 720 References will generally appear in alphanumeric order by citation 721 tag. Where there are only normative or informative references, no 722 subsection is required; the top-level section should say "Normative 723 References" or "Informative References". 725 Normative references to Internet-Drafts will cause publication of the 726 RFC to be suspended until the referenced draft is also ready for 727 publication; the RFC Editor will then update the entry to refer to 728 the RFC and publish both documents simultaneously. 730 4.8.6.1. Referencing RFCs 732 The following format is required for referencing RFCs. The Stream 733 abbreviation should be used; when no stream is available, as with 734 legacy RFCs, this may be left blank. 736 Note the ordering for multiple authors: the format of the name of the 737 last author listed is different than that of all previous authors in 738 the list. 740 For one author or editor: 742 [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC 743 Title", Stream, Sub-series number (if applicable), RFC number, RFC 744 DOI, Date of publication, [1]. 746 Example: 748 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core," 749 IETF, RFC 3080, DOI 10.17487/RFC3080, March 2001, [2]. 752 [RFC8157] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M. 753 Cullen, "Huawei's GRE Tunnel Bonding Protocol", independent, RFC 754 8157, DOI 10.17487/RFC8157, May 2017, [3]. 757 For two authors or editors: 759 [RFCXXXX] Last name, First initial., Ed. (if applicable) and First 760 initial. Last name, Ed. (if applicable), "RFC Title", Stream, Sub- 761 series number (if applicable), RFC number, RFC DOI, Date of 762 publication, [4]. 764 Example: 766 [RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option 767 for the Datagram Congestion Control Protocol (DCCP)", IETF, RFC 6323, 768 DOI 10.17487/RFC6323, July 2011, [5]. 771 For three or more authors or editors: 773 [RFCXXXX] Last name, First initial., Ed. (if applicable), Last name, 774 First initial., Ed. (if applicable), and First initial. Last name, 775 Ed. (if applicable), "RFC Title", Stream, Sub-series number (if 776 applicable), RFC number, RFC DOI, Date of publication, 777 [6]. 779 Example: 781 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender 782 Clarification for Persist Condition", IETF, RFC 6429, DOI 10.17487/ 783 RFC6429, December 2011, >https://www.rfc-editor.org/info/rfc6429 < 784 [7]. 786 4.8.6.2. Referencing RFC(s) in a Subseries (STDs, BCPs, and FYIs 788 Internet Standards (STDs) and Best Current Practices (BCPs) may 789 consist of a single RFC or multiple RFCs. Authors should carefully 790 consider whether they want to point the reader to the specific RFC or 791 the sub series group. In the former case, references should appear 792 as described in Section 4.8.6.2. In the latter case, the sub series 793 number should take precedence as, for example, the citation tag, even 794 in cases where the sub series currently contains only one RFC. 796 When an STD or BCP that contains multiple RFCs is referenced as a sub 797 series group, the reference entry should include ALL of the RFCs 798 comprising that sub-series in a reference grouping under a single 799 citation tag [is it helpful to point them to 7991 or the like on how 800 to do this here?]. The authors should refer to the specific RFC 801 numbers as part of the text in the body of the document and cite the 802 sub series number (for example, "see RFC 2119 of [BCP14]"). 803 Inclusion of the URI to the STD or BCP info page (see Section 3.2.3 804 of [RFC5741]) is recommended. The text should appear as follows: 806 See RFC 1034 [STD13]. 808 For an STD or BCP that contains one RFC: 810 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", 811 Stream, Sub-series number, RFC number, RFC DOI, Date of publication, 812 [8]. 814 Example: 816 [STD72] Gellens, R. and J. Klensin, "Message Submission for Mail", 817 IETF, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 818 [9]. 820 For an STD or BCP that contains two or more RFCs: 822 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", 823 Stream, Sub-series number, RFC number, RFC DOI, Date of publication. 825 Last name, First initial., Ed. (if applicable) 826 and First initial. Last name, Ed. (if applicable), 827 "RFC Title", Stream, Sub-series number, RFC number, RFC DOI, 828 Date of publication. 830 832 Example: 834 [STD13] Mockapetris, P., "Domain names - concepts and facilities", 835 IETF, STD 13, RFC 1034, November 1987. 837 Mockapetris, P., "Domain names - implementation and 838 specification", IETF, STD 13, RFC 1035, DOI 10.17487/RFC1035, 839 November 1987. 841 843 Note - some RFCs contain an FYI sub-series number [FYI90] however, 844 the FYI series was ended by RFC 6360. RFCs that were published with 845 an FYI sub-series number and still maintain the FYI number must 846 include the sub-series number in the reference and may otherwise be 847 treated in the same manner as STDs and BCPs. 849 Grouping references to RFCs or other materials that are not part of a 850 sub-series is discouraged. 852 4.8.6.3. Referencing Internet-Drafts 854 References to Internet Drafts may only appear as informative 855 references. Given that several revisions of an I-D may be produced 856 in a short time frame, references must include the posting date 857 (month and year), the full Internet-Draft file name (including the 858 version number), and the phrase "Internet Draft". Authors may 859 reference multiple versions of an I-D. If the referenced I-D was 860 also later published as an RFC, then that RFC must also be listed. 862 [SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and 863 First initial. Last name, Ed. (if applicable), "I-D Title", Work in 864 Progress, Internet-Draft, draft-string-NN, Day Month Year. 866 Example: 868 [RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in 869 Progress, Internet-Draft, draft-flanagan-style-04, 27 September 2019. 871 4.8.6.4. Referencing Errata 873 The following format is required when a reference to an erratum 874 report is necessary: 876 [ErrNumber] RFC Errata, Erratum ID number, RFC number, 877 . 879 [Err1912] RFC Errata, Erratum ID 1912, RFC 2978, . 882 4.8.6.5. Referencing IANA Registries 884 IANA registries may appear in normative or informative reference 885 sections. 887 [IANA-SYMBOLIC-TAG] 889 IANA, "Registry Name", . 891 4.8.6.6. Referencing Other Standards Development Organizations (SDOs) 893 The following format is suggested when referencing a document or 894 standard from another SDO in which authors are listed: 896 [SYMBOLIC-TAG] 898 Last name, First initial. and First initial. Last name, 900 "Document Title", Document reference number, Date of 902 publication, . 904 [W3C.REC-xml11] 906 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., 908 Yergeau, F., and J. Cowan, "Extensible Markup Language 910 (XML) 1.1 (Second Edition)", W3C Recommendation 912 REC-xml11-20060816, August 2006, 914 . 916 The order of authors in the list is the same as the order shown on 917 the actual document and that the common, abbreviated form of the SDO 918 is used. 920 Alternatively, when no list of authors is available, the following 921 format is recommended: 923 [SYMBOLIC-TAG] Organization, "Document Title", Document 924 reference number, Date of publication, 925 . 927 Example (undated; see note below): 929 [IEEE.802.15.4] 930 IEEE, "IEEE Standard for Low-Rate Wireless Networks", 931 IEEE 802.15.4, 932 . 934 Example (dated; see note below): 936 [IEEE802.1Q] IEEE, "Local and Metropolitan Area 937 Networks -- Media Access Control (MAC) 938 Bridges and Virtual Bridged Local Area 939 Networks", IEEE Std 802.1Q-2011, August 2011, 940 943 Per the IEEE coordination team, listing dates for IEEE standards is 944 not recommended unless there is a need to cite a particular section, 945 in which case the dated reference is appropriate. An RFC with a 946 dated IEEE reference suggests that the RFC only applies to that 947 specific IEEE specification. 949 4.8.6.7. Referencing Webpages 951 References to webpages acceptable in either the normative or 952 informative sections, as long as the URL provided is the most stable 953 (i.e., unlikely to change and expected to be continuously available) 954 and direct reference possible. The URL will be verified as valid 955 during the RFC editorial process. 957 If a dated URI (one that includes a timestamp for the page) is 958 available for a referenced web page, its use is required. 960 Note that the URL may not be the sole information provided for a 961 reference entry. 963 The use of HTTPS rather than HTTP is strongly encouraged. 965 Example: 967 [SYMBOLIC-TAG] Author (if available), "Page Title (if available)", 968 . 970 [ISOC-MANRS] Internet Society, "Mutually Agreed 971 Norms for Routing Security", 972 974 4.8.6.8. Referencing Email on Mailing Lists 976 When referencing emails to mailing lists, the template provided here 977 should be used: 979 [reftag] Sender, A., "Subject: Subject line", message to the 981 listname mailing list, DD Month YYYY, . 983 4.8.6.9. Referencing Code Repositories 985 References to online code repositories such as GitHub or SourceForge 986 should be used as informative references only. The reference entry 987 should include the repository title, commit hash or similar release 988 marker if available, date of last commit, and URL. 990 Examples: 992 [pysaml] "Python implementation of SAML2", commit 7135d53, 993 6 March 2018, . 995 [linuxlite] "Linux Lite", 9 March 2018, 996 . 998 4.9. Appendices Section 1000 The RFC Editor recommends placing references before the Appendices. 1001 Appendices should be labeled as "Appendix A. Title", "A.1. Title", 1002 "Appendix B. Title", etc. 1004 4.10. Acknowledgements Section 1006 This optional section may be used instead of, or in addition to, a 1007 Contributors section. It is often used by authors to publicly thank 1008 those who have provided feedback regarding a document and to note any 1009 documents from which text was borrowed. 1011 4.11. Contributors Section 1013 This optional section acknowledges those who have made significant 1014 contributions to the document. 1016 In a similar fashion to the Author's Address section, the RFC Editor 1017 does not make the determination as to who should be listed as a 1018 contributor to an RFC. The determination of who should be listed as 1019 a contributor is made by the stream. 1021 The Contributors section may include brief statements about the 1022 nature of particular contributions (e.g., "Sam contributed 1023 Section 3"), and it may also include affiliations of listed 1024 contributors. At the discretion of the author(s), contact addresses 1025 may also be included in the Contributors section, for those 1026 contributors whose knowledge makes them useful future contacts for 1027 information about the RFC. The format of any contact information 1028 should be similar to the format of information in the Author's 1029 Address section. 1031 4.12. Index 1033 If included, an index appears at the end of the document, immediately 1034 before Author's Address section. 1036 4.13. Author's Address or Authors' Addresses Section 1038 This required section gives contact information for the author(s) 1039 listed in the first-page header. 1041 Contact information must include a long-lived email address and 1042 optionally may include a postal address and/or telephone number. If 1043 the postal address is included, it should include the country name, 1044 using the English short name listed by the ISO 3166 Maintenance 1045 Agency [ISO_OBP]. The purpose of this section is to (1) 1046 unambiguously define author identity (e.g., the John Smith who works 1047 for FooBar Systems) and (2) provide contact information for future 1048 readers who have questions or comments. 1050 The practice of munged email addresses (i.e., altering an email 1051 address to make it less readable to bots and web crawlers to avoid 1052 spam) is not appropriate in an archival document series. Author 1053 contact information is provided so that readers can easily contact 1054 the author with questions and/or comments. Address munging is not 1055 allowed in RFCs. 1057 5. Security Considerations 1059 This document has no security considerations. 1061 6. IANA Considerations 1063 This document has no IANA considerations. 1065 7. Change Log 1067 This section to be removed before publication. 1069 -00 to -01: Citation tag requirements more tightly specified; 1070 index moved; new errata URI added; capitalization of working/ 1071 research group specified 1073 -01 to -02: update Abstract guidance 1075 -02 to -03: updated citation section; changed list styles; added 1076 angle brackets to reference examples; changed I-D reference 1077 format; clarified sub-series reference format; added guidance on 1078 referencing code repositories 1080 -03 to -04: updated Reference Section guidance; added information 1081 on alt text 1083 -04 to -05: change author, add acknowledgement 1085 8. References 1087 8.1. Normative References 1089 [STYLE-WEB] 1090 RFC Editor, "Web Portion of the Style Guide", 1091 . 1093 8.2. Informative References 1095 [ABBR] RFC Editor, "RFC Editor Abbreviations List", 1096 . 1099 [ALTTEXT] W3C, "Understanding Success Criterion 1.3.1: Info and 1100 Relationships", 1101 . 1104 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1105 Requirement Levels", BCP 14, RFC 2119, March 1997, 1106 . 1108 [BCP18] Alvestrand, H., "IETF Policy on Character Sets and 1109 Languages", BCP 18, RFC 2277, January 1998, 1110 . 1112 [BCP26] Alvestrand, H. and T. Narten, "Guidelines for Writing an 1113 ANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1114 2008, . 1116 [BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1117 Names", BCP 32, RFC 2606, June 1999, 1118 . 1120 [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1121 Text on Security Considerations", BCP 72, RFC 3552, July 1122 2003, . 1124 [CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue", 1125 . 1127 [CMOS] University of Chicago Press, 2010, "Chicago Manual of 1128 Style, 16th ed.", 2010. 1130 [FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to 1131 the FYI Notes", FYI 90, RFC 1150, March 1990, 1132 . 1134 Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, 1135 August 2011. 1137 [IAB-FORM] 1138 IAB, "Format for RFCs in the IAB Stream", 1139 . 1142 [ID-GUIDE] 1143 IETF, "Guidelines to Authors of Internet Drafts", 1144 . 1146 [IETF-TRUST] 1147 IETF Trust, "Trust Legal Provisions (TLP)", 1148 . 1150 [ISO3297] Technical Committee ISO/TC 46, Information and 1151 documentation, Subcommittee SC 9, "Identification and 1152 description, Information and documentation - International 1153 standard serial number (ISSN)", September 2007. 1155 [ISO_OBP] ISO, "Online Browsing Platform (OBP)", 1156 . 1158 [MIB-BOILER] 1159 IETF OPS Area, "Boilerplate for IETF MIB Documents", 1160 . 1162 [MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules", 1163 . 1166 [REFEXAMPLE] 1167 RFC Editor, "Reference Examples", 1168 . 1170 [REFS] IESG, "IESG Statement: Normative and Informative", 1171 . 1174 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 1175 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 1176 July 2007, . 1178 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 1179 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 1180 2012, . 1182 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 1183 "RFC Streams, Headers, and Boilerplates", RFC 7841, 1184 DOI 10.17487/RFC7841, May 2016, 1185 . 1187 [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, 1188 DOI 10.17487/RFC7990, December 2016, 1189 . 1191 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 1192 RFC 7991, DOI 10.17487/RFC7991, December 2016, 1193 . 1195 [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", 1196 RFC 7996, DOI 10.17487/RFC7996, December 2016, 1197 . 1199 [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in 1200 RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, 1201 . 1203 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1204 Resource Identifier (URI): Generic Syntax", STD 66, 1205 RFC 3986, January 2005, 1206 . 1208 [TERMS] RFC Editor, "Terms List", 1209 . 1211 [YANG-SEC] 1212 IETF Ops Area, "yang module security considerations", 1213 . 1216 8.3. URIs 1218 [1] https://www.rfc-editor.org/info/rfc# 1220 [2] https://www.rfc-editor.org/info/rfc3080 1222 [3] https://www.rfc-editor.org/info/rfc8157 1224 [4] https://www.rfc-editor.org/info/rfc# 1226 [5] https://www.rfc-editor.org/info/rfc6323 1228 [6] https://www.rfc-editor.org/info/rfc# 1230 [7] https://www.rfc-editor.org/info/rfc6429 1232 [8] https://www.rfc-editor.org/info/std# 1234 [9] https://www.rfc-editor.org/info/std72 1236 Appendix A. Related Procedures 1238 The following procedures are related to the application and updating 1239 of the RFC Style Guide. 1241 A.1. Dispute Resolution 1243 There are competing rationales for some of the rules described in 1244 this Guide, and the RFC Editor has selected the ones that work best 1245 for the Series. However, at times, an author may have a disagreement 1246 with the RFC Production Center (RPC) over the application of Style 1247 Guide conventions. In such cases, the authors should discuss their 1248 concerns with the RPC. If no agreement can be reached between the 1249 RPC and the authors, the RFC Series Editor will, with input from the 1250 appropriate stream-approving body, make a final determination. If 1251 further resolution is required, the dispute resolution process as 1252 described in the RFC Editor Model [RFC6635] will be followed. 1254 A.2. Returning an I-D to the Document Stream 1256 For a given document, if the RFC Editor determines that it cannot be 1257 edited without serious risk of altering the meaning of the technical 1258 content or if the RFC Editor does not have the resources to provide 1259 the level of editing it needs, it may be sent back to the stream- 1260 approving body with a request to improve the clarity, consistency, 1261 and/or readability of the document. This is not to be considered a 1262 dispute with the author. 1264 A.3. Revising This Document and Associated Web Pages 1266 The RFC Series is continually evolving as a document series. This 1267 document focuses on the fundamental and stable requirements that must 1268 be met by an RFC. From time to time, the RFC Editor may offer less 1269 formal recommendations that authors may apply at their discretion; 1270 these recommendations may be found on the RFC Editor website 1271 "Guidelines for RFC Style" [STYLE-WEB]. 1273 When a new recommendation is made regarding the overall structure and 1274 formatting of RFCs, it will be published on that page and accepted 1275 for a period of time before the RFC Editor determines whether it 1276 should become part of the fundamental requirements in the RFC Style 1277 Guide or remain as a less formal recommendation. That period of time 1278 will vary, in part depending on the frequency with which authors 1279 encounter and apply the guidance. 1281 Appendix B. Acknowledgements 1283 Much of this document was written by Heather Flanagan during her term 1284 as RFC Editor. 1286 Authors' Addresses 1288 John Levine (editor) 1289 Temporary RFC Series Project Manager 1291 EMail: standards@standcore.com 1292 URI: http://orcid.org/0000-0001-7553-5024 1294 Sandy Ginoza 1295 RFC Editor 1297 EMail: rfc-editor@rfc-editor.org 1298 URI: https://www.rfc-editor.org