idnits 2.17.1 draft-flanagan-7322bis-04.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 (October 1, 2019) is 1662 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6146' is mentioned on line 319, but not defined == Missing Reference: 'RFC6147' is mentioned on line 320, but not defined == Missing Reference: 'RFC6144' is mentioned on line 322, but not defined == Missing Reference: 'RFC6959' is mentioned on line 325, but not defined == Missing Reference: 'Required' is mentioned on line 428, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 772, but not defined -- Looks like a reference, but probably isn't: '1' on line 1215 == Missing Reference: 'RFC3080' is mentioned on line 747, but not defined -- Looks like a reference, but probably isn't: '2' on line 1217 == Missing Reference: 'RFC8157' is mentioned on line 751, but not defined -- Looks like a reference, but probably isn't: '3' on line 1219 -- Looks like a reference, but probably isn't: '4' on line 1221 == Missing Reference: 'RFC6323' is mentioned on line 765, but not defined -- Looks like a reference, but probably isn't: '5' on line 1223 -- Looks like a reference, but probably isn't: '6' on line 1225 == Missing Reference: 'RFC6429' is mentioned on line 780, but not defined ** Obsolete undefined reference: RFC 6429 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '7' on line 1227 == Missing Reference: 'RFC5741' is mentioned on line 803, but not defined ** Obsolete undefined reference: RFC 5741 (Obsoleted by RFC 7841) == Missing Reference: 'STD13' is mentioned on line 833, but not defined == Missing Reference: 'STDXXX' is mentioned on line 821, but not defined -- Looks like a reference, but probably isn't: '8' on line 1229 == Missing Reference: 'STD72' is mentioned on line 815, but not defined -- Looks like a reference, but probably isn't: '9' on line 1231 == Missing Reference: 'SYMBOLIC-TAG' is mentioned on line 966, but not defined == Missing Reference: 'RFC-STYLE' is mentioned on line 867, but not defined == Missing Reference: 'ErrNumber' is mentioned on line 875, but not defined == Missing Reference: 'Err1912' is mentioned on line 878, but not defined == Missing Reference: 'IANA-SYMBOLIC-TAG' is mentioned on line 886, but not defined == Missing Reference: 'IEEE.802.15.4' is mentioned on line 928, but not defined == Missing Reference: 'IEEE802.1Q' is mentioned on line 935, but not defined == Missing Reference: 'ISOC-MANRS' is mentioned on line 969, 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 H. Flanagan 3 Internet-Draft S. Ginoza 4 Obsoletes: 7322 (if approved) RFC Editor 5 Intended status: Informational October 1, 2019 6 Expires: April 3, 2020 8 RFC Style Guide 9 draft-flanagan-7322bis-04 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 April 3, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.6. Abbreviation Rules . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . 10 69 4.1.2. Organization . . . . . . . . . . . . . . . . . . . . 10 70 4.1.3. ISSN: 2070-1721 . . . . . . . . . . . . . . . . . . . 11 71 4.1.4. Updates and Obsoletes . . . . . . . . . . . . . . . . 11 72 4.2. Document Title . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Abstract Section . . . . . . . . . . . . . . . . . . . . 12 74 4.4. RFC Editor or Stream Notes Section . . . . . . . . . . . 12 75 4.5. Status of This Memo Section . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 13 79 4.8.1. Introduction Section . . . . . . . . . . . . . . . . 13 80 4.8.2. Requirements Language Section . . . . . . . . . . . . 13 81 4.8.3. IANA Considerations Section . . . . . . . . . . . . . 14 82 4.8.4. Internationalization Considerations Section . . . . . 14 83 4.8.5. Security Considerations Section . . . . . . . . . . . 14 84 4.8.6. References Section . . . . . . . . . . . . . . . . . 15 85 4.9. Appendices Section . . . . . . . . . . . . . . . . . . . 21 86 4.10. Acknowledgements Section . . . . . . . . . . . . . . . . 21 87 4.11. Contributors Section . . . . . . . . . . . . . . . . . . 22 88 4.12. Index . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 4.13. Author's Address or Authors' Addresses Section . . . . . 22 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 95 8.2. Informative References . . . . . . . . . . . . . . . . . 23 96 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 Appendix A. Related Procedures . . . . . . . . . . . . . . . . . 27 99 A.1. Dispute Resolution . . . . . . . . . . . . . . . . . . . 27 100 A.2. Returning an I-D to the Document Stream . . . . . . . . . 27 101 A.3. Revising This Document and Associated Web Pages . . . . . 27 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 104 1. Introduction 106 The ultimate goal of the RFC publication process is to produce 107 documents that are readable, clear, and consistent. The basic 108 formatting conventions for RFCs were established in the 1970s by the 109 original RFC Editor, Jon Postel. This document describes the 110 fundamental and unique style conventions and editorial policies 111 currently in use for the RFC Series [RFC4844] and is intended as a 112 stable, infrequently updated reference for authors, editors, and 113 reviewers. 115 The RFC Editor also maintains a web portion of the Style Guide (see 116 Appendix A.3) that describes issues as they are raised and indicates 117 how the RFC Editor intends to address them. As new style issues 118 arise, the RFC Editor will first address them on the web portion of 119 the Style Guide [STYLE-WEB]. These topics may become part of the RFC 120 Style Guide when it is revised. 122 The world of publishing has generally accepted rules for grammar, 123 punctuation, capitalization, sentence length and complexity, etc. 124 The RFC Editor generally follows these accepted rules as defined by 125 the Chicago Manual of Style (CMOS) [CMOS], with a few important 126 exceptions to avoid ambiguity in complex technical prose and to 127 handle mixtures of text and computer languages, or to preserve 128 historical formatting rules. This document presents these exceptions 129 as applied or recommended by the RFC Editor. 131 All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a 132 well-written and properly constructed Internet-Draft [ID-GUIDE] 133 provides a strong basis for a good RFC. The RFC Editor accepts 134 Internet-Drafts from specified streams for publication [RFC4844] and 135 applies the rules and guidelines for the RFC Series during the 136 editorial process. 138 2. RFC Editor's Philosophy 140 Authors may find it helpful to understand the RFC Editor's goals 141 during the publication process, namely to: 143 o Prepare the document according to RFC style and format. 145 o Make the document as clear, consistent, and readable as possible. 147 o Correct larger content/clarity issues; flag any unclear passages 148 for author review. 150 o Fix inconsistencies (e.g., terms that appear in various forms, 151 inconsistent capitalization, discrepancies between a figure and 152 the text that describes it). 154 We strive for consistency within: 156 a. the document, 158 b. a cluster of documents [CLUSTER], and 160 c. the series of RFCs on the subject matter. 162 The editorial process of the RFC Editor is not an additional 163 technical review of the document. Where the RFC Editor may suggest 164 changes in wording for clarity and readability, it is up to the 165 author, working group, or stream-approving body to determine whether 166 the changes have an impact on the technical meaning of the document 167 [RFC4844]. If the original wording is a more accurate representation 168 of the technical content being described in the document, it takes 169 precedence over editorial conventions. 171 The activity of editing sometimes creates a tension between author 172 and editor. The RFC Editor attempts to minimize this conflict for 173 RFC publication while continually striving to produce a uniformly 174 excellent document series. The RFC Editor refers to this fundamental 175 tension as "editorial balance," and maintaining this balance is a 176 continuing concern for the RFC Editor. There is a prime directive 177 that must rule over grammatical conventions: do not change the 178 intended meaning of the text. 180 If the RFC Editor cannot edit a document without serious risk of 181 altering the meaning, it may be returned to the stream-approving body 182 for review. See Appendix A.2 for more information. 184 3. RFC Style Conventions 186 This Style Guide does not use terminology as defined in RFC 2119 187 [BCP14]. In this document, lowercase use of "must" and "should" 188 indicates changes the RFC Editor will make automatically to conform 189 with this Style Guide versus those that may be questioned if not 190 applied. The lowercase "must" indicates those changes that will be 191 applied automatically and are not at the discretion of the authors. 192 The lowercase "should" indicates the RFC Editor's recommended use, 193 but conformance with the recommendations is not required; the RFC 194 Editor may question whether the guidance may be applied. 196 3.1. Language 198 The RFC publication language is English. Spelling may be either 199 American or British, as long as an individual document is internally 200 consistent. Where both American and British English spelling are 201 used within a document or cluster of documents, the text will be 202 modified to be consistent with American English spelling. 204 3.2. Punctuation 206 1. A comma is used before the last item of a series, e.g., 208 "TCP service is reliable, ordered, and full duplex" 210 2. When quoting literal text, punctuation is placed outside 211 quotation marks, e.g., 213 Search for the string "Error Found". 215 When quoting general text, such as general text from another RFC, 216 punctuation may be included within the quotation marks, e.g., 218 RFC 4844 indicates that "RFCs are available free of charge to 219 anyone via the Internet. " 221 Quotation marks are not necessary when text is formatted as a 222 block quotation. 224 3.2.1. RFCs as Compounds 226 Whenever possible: 228 o Hyphenated compounds formed with RFC numbers should be avoided; 229 this can be accomplished by: rewording the sentence (e.g., 230 [RFC5011]-style rollover -> rollover as described in RFC 5011). 232 o adding a note in either the Terminology or Conventions section 233 mentioning the RFC so that other occurrences throughout the text 234 will be understood by the reader to be in the style of said RFC 235 (e.g., This document uses the term "rollover" as defined in RFC 236 5011.). 238 If use of an RFC number in attributive position is unavoidable, the 239 preferred form should appear as in the example "RFC 5011-style 240 rollover". That is: 242 o no hyphen between "RFC" and the number (don't use RFC-5011-style 243 rollover) 245 o avoid hyphenating citations with text (don't use [RFC5011]-style 246 rollover) 248 3.3. DNS Names and URIs 250 DNS names, whether or not in URIs, that are used as generic examples 251 in RFCs should use the particular examples defined in "Reserved Top 252 Level DNS Names" [BCP32], to avoid accidental conflicts. 254 Angle brackets are strongly recommended around URIs [STD66], e.g., 256 258 The use of HTTPS rather than HTTP is strongly encouraged. 260 3.4. Capitalization 262 1. Capitalization must be consistent within the document and ideally 263 should be consistent with related RFCs. Refer to the online 264 table of decisions on consistent usage of terms in RFCs [TERMS]. 266 2. Per CMOS guidelines, the major words in RFC titles and section 267 titles should be capitalized (this is sometimes called "title 268 case"). Typically, all words in a title will be capitalized, 269 except for internal articles, prepositions, and conjunctions. 271 3. Section titles that are in sentence form will follow typical 272 sentence capitalization. 274 4. Titles of figures may be in sentence form or use title case. 276 5. Some terms related to the various roles or parts of the streams 277 authoring RFCs should be used consistently. For example, when 278 the term 'working group' or 'research group' is used as part of a 279 specific group name, it will be capitalized (e.g., kitten Working 280 Group, Crypto Forum Research Group). When used to generally 281 refer to groups, it will be downcased. 283 3.5. Citations 285 The most important function of a citation is to point to a reference 286 so that a reader may follow up on additional material that is 287 important in some way to understanding or implementing the content in 288 an RFC. This section offers guidance on the requirements and 289 recommendations for citation format within an RFC. 291 1. References and citations must match. That is, there must be a 292 reference for each citation used, and vice versa. 294 2. Citations must be enclosed in square brackets (e.g., "[CITE1]"). 296 3. Citations are restricted to ASCII-only characters, as described 297 in "The Use of Non-ASCII Characters in RFCs" [RFC7997]. 299 4. Citations must begin with a number or a letter, and may contain 300 digits, letters, colons, hyphens, underscores, or dots. 302 * Example: "[IEEE.802.15.4]" rather than "[.802.15.4]" 304 * Example: "[RFC2119]" rather than "[RFC 2119]" 306 5. Citations may not include spaces, commas, quotation marks, or 307 other punctuation (!, ?, etc.), and should be in-line with the 308 normal line of type. 310 * Example: "See RFC 2119 [BCP14] for more information." 312 6. Cross-references within the body of the memo and to other RFCs 313 must use section numbers rather than page numbers, as pagination 314 may change per format and device. 316 7. A citation may A) follow the subject to which the citation 317 applies or B) be read as part of the text. For example: 319 A. As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 320 [RFC6147] technologies will be utilized by some access 321 networks to provide IPv4 connectivity for IPv6-only nodes 322 [RFC6144]. 324 B. Note that SAVI raises a number of important privacy 325 considerations that are discussed more fully in [RFC6959]. 327 8. For a document referenced multiple times in running text, the 328 citation anchor must be at first use outside the abstract. 329 Additional citations are allowed at the author's discretion. 331 We recommend using A) and strongly recommend consistent use of one 332 style throughout. 334 3.6. Abbreviation Rules 336 Abbreviations should be expanded in document titles and upon first 337 use in the document. The full expansion of the text should be 338 followed by the abbreviation itself in parentheses. The exception is 339 an abbreviation that is so common that the readership of RFCs can be 340 expected to recognize it immediately; examples include (but are not 341 limited to) TCP, IP, SNMP, and HTTP. The online list of 342 abbreviations [ABBR] provides guidance. Some cases are marginal, and 343 the RFC Editor will make the final judgment, weighing obscurity 344 against complexity. 346 Note: The online list of abbreviations is not exhaustive or 347 definitive. It is a list of abbreviations appearing in RFCs and 348 sometimes reflects discussions with authors, Working Group Chairs, 349 and/or Area Directors (ADs). Note that some abbreviations have 350 multiple expansions. Additionally, this list includes some terms 351 that look like abbreviations but that are actually fixed names for 352 things and hence cannot and should not be expanded. These are noted 353 as "No Expansion". 355 3.7. Images and Figures 357 The goal of having images within an RFC is to convey information. A 358 good diagram or image expresses information quickly, clearly, and 359 with low chance of misunderstanding. Technically correct but 360 confusing images get in the way of understanding and implementation. 362 1. Images should be legible when displayed on a standard screen 363 (1920x1080) and printable on either A4 or US Letter paper. Any 364 text within the diagram should be readable at that resolution. 366 2. Authors should use black on white, not white on black. No color 367 or greyscale [RFC7990][RFC7996] 369 3. Keep your diagrams as simple as possible. If an object in the 370 diagram is not immediately relevant, leave it out. If you have 371 several ideas you want to convey, consider using more than one 372 diagram. 374 4. San-serif fonts are generally considered more readable for 375 digital material. [citation needed] 377 5. The style of diagrams within an RFC should be consistent both 378 within a single RFC and within a cluster of RFCs (fonts, shapes, 379 lines). For example, if you you use a dashed line to indicate a 380 certain type of packet flow, then continue to use that style of 381 line consistently. 383 6. Line styles, including thickness, color, and arrow types, are 384 easy methods to convey a particular meaning to the reader. 385 Consistently use the same line styles to convey a particular 386 meaning throughout all diagrams within an RFC in order to avoid 387 confusing the reader. 389 7. Flowcharts: avoid crossing the lines if possible. 391 8. Captions or alternative text are encouraged for all figures, 392 diagrams, and other artwork. [ALTTEXT] [RFC7991] 394 4. Structure of an RFC 396 A published RFC will largely contain the elements in the following 397 list. Some of these sections are required, as noted. Those sections 398 marked with "*" will be supplied by the RFC Editor during the 399 editorial process when necessary. The rules for each of these 400 elements are described in more detail below. 402 First-page header * [Required] 403 Title [Required] 404 Abstract [Required] 405 RFC Editor or Stream Note * [Upon request] 406 Status of This Memo * [Required] 407 Copyright Notice * [Required] 408 Table of Contents * [Required] 409 Body of the Memo [Required] 411 1. Introduction [Required] 412 2. Requirements Language (RFC 2119) 413 3. ... 414 MAIN BODY OF THE TEXT 415 6. ... 416 7. IANA Considerations [Required] 417 8. Internationalization Considerations 418 9. Security Considerations [Required] 419 10. References 420 10.1. Normative References 421 10.2. Informative References 422 Appendix A. 423 Appendix B. 425 Acknowledgements 426 Contributors 427 Index 428 Author's Address [Required] 430 Within the body of the memo, the order shown above is strongly 431 recommended. Exceptions may be questioned. Outside the body of the 432 memo, the order above is required. The section numbers above are for 433 illustrative purposes; they are not intended to correspond to 434 required numbering in an RFC. 436 The elements preceding the body of the memo should not be numbered. 437 Typically, the body of the memo will have numbered sections and the 438 appendices will be labeled with letters. Any sections that appear 439 after the appendices should not be numbered or labeled (e.g., see 440 "Contributors" above). 442 4.1. First-Page Header 444 Headers will follow the format described in "RFC Streams, Headers, 445 and Boilerplates" [RFC7841] and its successors. In addition, the 446 following conventions will apply. 448 4.1.1. Author/Editor 450 The final determination of who should be listed as an author or 451 editor on an RFC is made by the stream, as is whether or not 452 including author affiliation is required. 454 The author's name (initial followed by family name) appears on the 455 first line of the heading. Some variation, such as additional 456 initials or capitalization of family name, is acceptable. Once the 457 author has selected how their name should appear, they should use 458 that display consistently in all of their documents. 460 The total number of authors or editors on the first page is generally 461 limited to five individuals and their affiliations. If there is a 462 request for more than five authors, the stream-approving body needs 463 to consider if one or two editors should have primary responsibility 464 for this document, with the other individuals listed in the 465 Contributors or Acknowledgements section. There must be a direct 466 correlation of authors and editors in the document header and the 467 Authors' Addresses section. These are the individuals that must sign 468 off on the document during the AUTH48 process and respond to 469 inquiries, such as errata. 471 4.1.2. Organization 473 The author's organization is indicated on the line following the 474 author's name. 476 For multiple authors, each author name appears on its own line, 477 followed by that author's organization. When more than one author is 478 affiliated with the same organization, the organization can be 479 "factored out," appearing only once following the corresponding 480 Author lines. However, such factoring is inappropriate when it would 481 force an unacceptable reordering of author names. 483 If an author cannot or will not provide an affiliation for any 484 reason, "Independent", "Individual Contributor", "Retired", or some 485 other term that appropriately describes the author's affiliation may 486 be used. Alternatively, a blank line may be included in the document 487 header when no affiliation is provided. 489 4.1.3. ISSN: 2070-1721 491 The RFC Series has been assigned an International Standard Serial 492 Number of 2070-1721 [ISO3297]. It will be included by the RFC 493 Editor. 495 4.1.4. Updates and Obsoletes 497 When an RFC obsoletes or updates a previously published RFC or RFCs, 498 this information is included in the document header. For example: 500 "Updates: nnnn" or "Updates: nnnn, ..., nnnn" 502 "Obsoletes: nnnn" or "Obsoletes: nnnn, ..., nnnn" 504 If the document updates or obsoletes more than one document, numbers 505 will be listed in ascending order. 507 4.2. Document Title 509 The title must be centered below the rest of the heading, preceded by 510 two blank lines and followed by one blank line. 512 Choosing a good title for an RFC can be a challenge. A good title 513 should fairly represent the scope and purpose of the document without 514 being either too general or too specific and lengthy. 516 Abbreviations in a title must generally be expanded when first 517 encountered (see Section 3.6 for additional guidance on 518 abbreviations). 520 It is often helpful to follow the expansion with the parenthesized 521 abbreviation, as in the following example: 523 Encoding Rules for the 524 Common Routing Encapsulation Extension Protocol (CREEP) 526 The RFC Editor recommends that documents describing a particular 527 company's private protocol should bear a title of the form "Foo's ... 528 Protocol" (where Foo is a company name), to clearly differentiate it 529 from a protocol of more general applicability. 531 4.3. Abstract Section 533 Every RFC must have an Abstract that provides a concise and 534 comprehensive overview of the purpose and contents of the entire 535 document, to give a technically knowledgeable reader a general 536 overview of the function of the document and some context with 537 regards to its relationship (in particular, whether it updates or 538 obsoletes) any other RFCs. In addition to its function in the RFC 539 itself, the Abstract section text will appear in publication 540 announcements and in the online index of RFCs. 542 Composing a useful Abstract generally requires thought and care. 543 Usually, an Abstract should begin with a phrase like "This memo ..." 544 or "This document ..." A satisfactory Abstract can often be 545 constructed in part from material within the Introduction section, 546 but an effective Abstract may be shorter, less detailed, and perhaps 547 broader in scope than the Introduction. Simply copying and pasting 548 the first few paragraphs of the Introduction is allowed, but it may 549 result in an Abstract that is overly long, incomplete, and redundant. 551 An Abstract is not a substitute for an Introduction; the RFC should 552 be self-contained as if there were no Abstract. Similarly, the 553 Abstract should be complete in itself. Given that the Abstract will 554 appear independently in announcements and indices, mentions of other 555 RFCs within the Abstract should include both an RFC number and either 556 the full or short title. Any documents that are Updated or Obsoleted 557 by the RFC must be mentioned in the Abstract if those documents offer 558 important provisions of, or reasons for, the RFC. These may be 559 presented in a list format if that improves readability. 561 4.4. RFC Editor or Stream Notes Section 563 A stream-approving body may approve the inclusion of an editorial 564 note to explain anything unusual about the process that led to the 565 document's publication or to note a correction. In this case, a 566 stream note section will contain such a note. 568 Additionally, an RFC Editor Note section may contain a note inserted 569 by the RFC Editor to highlight special circumstances surrounding an 570 RFC. 572 4.5. Status of This Memo Section 574 The RFC Editor will supply an appropriate "Status of This Memo" as 575 defined in RFC [RFC7841] and "Format for RFCs in the IAB Stream" 576 [IAB-FORM]. 578 4.6. Copyright, Licenses, and IPR Boilerplate Section 580 The full copyright and license notices are available on the IETF 581 Trust Legal Provisions documents website [IETF-TRUST]. 583 4.7. Table of Contents Section 585 A Table of Contents (TOC) is required in all RFCs. It must be 586 positioned after the Copyright Notice and before the Introduction. 588 4.8. Body of the Memo 590 Following the TOC is the body of the memo. 592 Each RFC must include an Introduction section that (among other 593 things) explains the motivation for the RFC and (if appropriate) 594 describes the applicability of the document, e.g., whether it 595 specifies a protocol, provides a discussion of some problem, is 596 simply of interest to the Internet community, or provides a status 597 report on some activity. The body of the memo and the Abstract must 598 be self-contained and separable. This may result in some duplication 599 of text between the Abstract and the Introduction; this is 600 acceptable. 602 4.8.1. Introduction Section 604 The Introduction section should always be the first section following 605 the TOC (except in the case of MIB module documents). While 606 "Introduction" is recommended, authors may choose alternate titles 607 such as "Overview" or "Background". These alternates are acceptable. 609 For MIB module documents, common practice has been for "The Internet- 610 Standard Management Framework" [MIB-BOILER] text to appear as 611 Section 1. 613 4.8.2. Requirements Language Section 615 Some documents use certain capitalized words ("MUST", "SHOULD", etc.) 616 to specify precise requirement levels for technical features. RFC 617 2119 [BCP14] defines a default interpretation of these capitalized 618 words in IETF documents. If this interpretation is used, RFC 2119 619 must be cited (as specified in RFC 2119) and included as a normative 620 reference. Otherwise, the correct interpretation must be specified 621 in the document. 623 This section must appear as part of the body of the memo (as defined 624 by this document). It must appear as part of, or subsequent to, the 625 Introduction section. 627 These words are considered part of the technical content of the 628 document and are intended to provide guidance to implementers about 629 specific technical features, generally governed by considerations of 630 interoperability. RFC 2119 says: 632 Imperatives of the type defined in this memo must be used with care 633 and sparingly. In particular, they MUST only be used where it is 634 actually required for interoperation or to limit behavior which has 635 potential for causing harm (e.g., limiting retransmisssions) For 636 example, they must not be used to try to impose a particular method 637 on implementers where the method is not required for 638 interoperability. 640 4.8.3. IANA Considerations Section 642 For guidance on how to register IANA-related values or create new 643 registries to be managed by IANA, see "Guidelines for Writing an IANA 644 Considerations Section in RFCs" [BCP26]. 646 The RFC Editor will update text accordingly after the IANA 647 assignments have been made. It is helpful for authors to clearly 648 identify where text should be updated to reflect the newly assigned 649 values. For example, the use of "TBD1", "TBD2", etc., is recommended 650 in the IANA Considerations section and in the body of the memo. 652 If the authors have provided values to be assigned by IANA, the RFC 653 Editor will verify that the values inserted by the authors match 654 those that have actually been registered on the IANA site. When 655 writing a given value, consistent use of decimal or hexadecimal is 656 recommended. 658 If any of the IANA-related information is not clear, the RFC Editor 659 will work with IANA to send queries to the authors to ensure that 660 assignments and values are properly inserted. 662 4.8.4. Internationalization Considerations Section 664 All RFCs that deal with internationalization issues should have a 665 section describing those issues; see "IETF Policy on Character Sets 666 and Languages" [BCP18], Section 6, for more information. 668 4.8.5. Security Considerations Section 670 All RFCs must contain a section that discusses the security 671 considerations relevant to the specification; see "Guidelines for 672 Writing RFC Text on Security Considerations" [BCP72] for more 673 information. 675 Note that additional boilerplate material for RFCs containing MIB and 676 YANG modules also exists. See "Security Guidelines for IETF MIB 677 Modules" [MIB-SEC] and "yang module security considerations" 678 [YANG-SEC] for details. 680 4.8.6. References Section 682 The reference list is solely for recording reference entries. 683 Introductory text or annotations beyond necessary translations 684 [RFC7997] are not allowed. 686 The RFC style allows the use of any of a variety of reference styles, 687 as long as they are used consistently within a document. However, 688 where necessary, some reference styles have been described for use 689 within the Series. See the following subsections as well as the 690 References section of this document. 692 Reference lists must indicate whether each reference is normative or 693 informative, where normative references are essential to implementing 694 or understanding the content of the RFC and informative references 695 provide additional information. More information about normative and 696 informative references may be found in the IESG's statement 697 "Normative and Informative References" [REFS]. When both normative 698 and informative references exist, the references section should be 699 split into two subsections: 701 Templates are available on the RFC Editor website for the XML format 702 of certain references [REFEXAMPLE]. 704 s. References 706 s.1. Normative References 708 xxx 709 ... 710 xxx 712 s.2. Informative References 714 xxx 715 ... 716 xxx 718 References will generally appear in alphanumeric order by citation 719 tag. Where there are only normative or informative references, no 720 subsection is required; the top-level section should say "Normative 721 References" or "Informative References". 723 Normative references to Internet-Drafts will cause publication of the 724 RFC to be suspended until the referenced draft is also ready for 725 publication; the RFC Editor will then update the entry to refer to 726 the RFC and publish both documents simultaneously. 728 4.8.6.1. Referencing RFCs 730 The following format is required for referencing RFCs. The Stream 731 abbreviation should be used; when no stream is available, as with 732 legacy RFCs, this may be left blank. 734 Note the ordering for multiple authors: the format of the name of the 735 last author listed is different than that of all previous authors in 736 the list. 738 For one author or editor: 740 [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC 741 Title", Stream, Sub-series number (if applicable), RFC number, RFC 742 DOI, Date of publication, 743 [1]. 745 Example: 747 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core," 748 IETF, RFC 3080, DOI 10.17487/RFC3080, March 2001, [2]. 751 [RFC8157] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M. 752 Cullen, "Huawei's GRE Tunnel Bonding Protocol", independent, RFC 753 8157, DOI 10.17487/RFC8157, May 2017, [3]. 756 For two authors or editors: 758 [RFCXXXX] Last name, First initial., Ed. (if applicable) and First 759 initial. Last name, Ed. (if applicable), "RFC Title", Stream, Sub- 760 series number (if applicable), RFC number, RFC DOI, Date of 761 publication, [4]. 763 Example: 765 [RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option 766 for the Datagram Congestion Control Protocol (DCCP)", IETF, RFC 6323, 767 DOI 10.17487/RFC6323, July 2011, [5]. 770 For three or more authors or editors: 772 [RFCXXXX] Last name, First initial., Ed. (if applicable), Last name, 773 First initial., Ed. (if applicable), and First initial. Last name, 774 Ed. (if applicable), "RFC Title", Stream, Sub-series number (if 775 applicable), RFC number, RFC DOI, Date of publication, 776 [6]. 778 Example: 780 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender 781 Clarification for Persist Condition", IETF, RFC 6429, DOI 10.17487/ 782 RFC6429, December 2011, >https://www.rfc-editor.org/info/rfc6429 < 783 [7]. 785 4.8.6.2. Referencing RFC(s) in a Subseries (STDs, BCPs, and FYIs 787 Internet Standards (STDs) and Best Current Practices (BCPs) may 788 consist of a single RFC or multiple RFCs. Authors should carefully 789 consider whether they want to point the reader to the specific RFC or 790 the sub series group. In the former case, references should appear 791 as described in Section 4.8.6.2. In the latter case, the sub series 792 number should take precedence as, for example, the citation tag, even 793 in cases where the sub series currently contains only one RFC. 795 When an STD or BCP that contains multiple RFCs is referenced as a sub 796 series group, the reference entry should include ALL of the RFCs 797 comprising that sub-series in a reference grouping under a single 798 citation tag [is it helpful to point them to 7991 or the like on how 799 to do this here?]. The authors should refer to the specific RFC 800 numbers as part of the text in the body of the document and cite the 801 sub series number (for example, "see RFC 2119 of [BCP14]"). 802 Inclusion of the URI to the STD or BCP info page (see Section 3.2.3 803 of [RFC5741]) is recommended. The text should appear as follows: 805 See RFC 1034 [STD13]. 807 For an STD or BCP that contains one RFC: 809 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", 810 Stream, Sub-series number, RFC number, RFC DOI, Date of publication, 811 [8]. 813 Example: 815 [STD72] Gellens, R. and J. Klensin, "Message Submission for Mail", 816 IETF, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 817 [9]. 819 For an STD or BCP that contains two or more RFCs: 821 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", 822 Stream, Sub-series number, RFC number, RFC DOI, Date of publication. 824 Last name, First initial., Ed. (if applicable) 825 and First initial. Last name, Ed. (if applicable), 826 "RFC Title", Stream, Sub-series number, RFC number, RFC DOI, 827 Date of publication. 829 831 Example: 833 [STD13] Mockapetris, P., "Domain names - concepts and facilities", 834 IETF, STD 13, RFC 1034, November 1987. 836 Mockapetris, P., "Domain names - implementation and 837 specification", IETF, STD 13, RFC 1035, DOI 10.17487/RFC1035, 838 November 1987. 840 842 Note - some RFCs contain an FYI sub-series number [FYI90] however, 843 the FYI series was ended by RFC 6360. RFCs that were published with 844 an FYI sub-series number and still maintain the FYI number must 845 include the sub-series number in the reference and may otherwise be 846 treated in the same manner as STDs and BCPs. 848 Grouping references to RFCs or other materials that are not part of a 849 sub-series is discouraged. 851 4.8.6.3. Referencing Internet-Drafts 853 References to Internet Drafts may only appear as informative 854 references. Given that several revisions of an I-D may be produced 855 in a short time frame, references must include the posting date 856 (month and year), the full Internet-Draft file name (including the 857 version number), and the phrase "Internet Draft". Authors may 858 reference multiple versions of an I-D. If the referenced I-D was 859 also later published as an RFC, then that RFC must also be listed. 861 [SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and 862 First initial. Last name, Ed. (if applicable), "I-D Title", Work in 863 Progress, Internet-Draft, draft-string-NN, Day Month Year. 865 Example: 867 [RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in 868 Progress, Internet-Draft, draft-flanagan-style-04, 27 September 2019. 870 4.8.6.4. Referencing Errata 872 The following format is required when a reference to an erratum 873 report is necessary: 875 [ErrNumber] RFC Errata, Erratum ID number, RFC number, 876 . 878 [Err1912] RFC Errata, Erratum ID 1912, RFC 2978, . 881 4.8.6.5. Referencing IANA Registries 883 IANA registries may appear in normative or informative reference 884 sections. 886 [IANA-SYMBOLIC-TAG] 888 IANA, "Registry Name", . 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 909 (XML) 1.1 (Second Edition)", W3C Recommendation 911 REC-xml11-20060816, August 2006, 913 . 915 The order of authors in the list is the same as the order shown on 916 the actual document and that the common, abbreviated form of the SDO 917 is used. 919 Alternatively, when no list of authors is available, the following 920 format is recommended: 922 [SYMBOLIC-TAG] Organization, "Document Title", Document 923 reference number, Date of publication, 924 . 926 Example (undated; see note below): 928 [IEEE.802.15.4] 929 IEEE, "IEEE Standard for Low-Rate Wireless Networks", 930 IEEE 802.15.4, 931 . 933 Example (dated; see note below): 935 [IEEE802.1Q] IEEE, "Local and Metropolitan Area 936 Networks -- Media Access Control (MAC) 937 Bridges and Virtual Bridged Local Area 938 Networks", IEEE Std 802.1Q-2011, August 2011, 939 942 Per the IEEE coordination team, listing dates for IEEE standards is 943 not recommended unless there is a need to cite a particular section, 944 in which case the dated reference is appropriate. An RFC with a 945 dated IEEE reference suggests that the RFC only applies to that 946 specific IEEE specification. 948 4.8.6.7. Referencing Webpages 950 References to webpages acceptable in either the normative or 951 informative sections, as long as the URL provided is the most stable 952 (i.e., unlikely to change and expected to be continuously available) 953 and direct reference possible. The URL will be verified as valid 954 during the RFC editorial process. 956 If a dated URI (one that includes a timestamp for the page) is 957 available for a referenced web page, its use is required. 959 Note that the URL may not be the sole information provided for a 960 reference entry. 962 The use of HTTPS rather than HTTP is strongly encouraged. 964 Example: 966 [SYMBOLIC-TAG] Author (if available), "Page Title (if available)", 967 . 969 [ISOC-MANRS] Internet Society, "Mutually Agreed 970 Norms for Routing Security", 971 973 4.8.6.8. Referencing Email on Mailing Lists 975 When referencing emails to mailing lists, the template provided here 976 should be used: 978 [reftag] Sender, A., "Subject: Subject line", message to the 980 listname mailing list, DD Month YYYY, . 982 4.8.6.9. Referencing Code Repositories 984 References to online code repositories such as GitHub or SourceForge 985 should be used as informative references only. The reference entry 986 should include the repository title, commit hash or similar release 987 marker if available, date of last commit, and URL. 989 Examples: 991 [pysaml] "Python implementation of SAML2", commit 7135d53, 992 6 March 2018, . 994 [linuxlite] "Linux Lite", 9 March 2018, 995 . 997 4.9. Appendices Section 999 The RFC Editor recommends placing references before the Appendices. 1000 Appendices should be labeled as "Appendix A. Title", "A.1. Title", 1001 "Appendix B. Title", etc. 1003 4.10. Acknowledgements Section 1005 This optional section may be used instead of, or in addition to, a 1006 Contributors section. It is often used by authors to publicly thank 1007 those who have provided feedback regarding a document and to note any 1008 documents from which text was borrowed. 1010 4.11. Contributors Section 1012 This optional section acknowledges those who have made significant 1013 contributions to the document. 1015 In a similar fashion to the Author's Address section, the RFC Editor 1016 does not make the determination as to who should be listed as a 1017 contributor to an RFC. The determination of who should be listed as 1018 a contributor is made by the stream. 1020 The Contributors section may include brief statements about the 1021 nature of particular contributions (e.g., "Sam contributed 1022 Section 3"), and it may also include affiliations of listed 1023 contributors. At the discretion of the author(s), contact addresses 1024 may also be included in the Contributors section, for those 1025 contributors whose knowledge makes them useful future contacts for 1026 information about the RFC. The format of any contact information 1027 should be similar to the format of information in the Author's 1028 Address section. 1030 4.12. Index 1032 If included, an index appears at the end of the document, immediately 1033 before Author's Address section. 1035 4.13. Author's Address or Authors' Addresses Section 1037 This required section gives contact information for the author(s) 1038 listed in the first-page header. 1040 Contact information must include a long-lived email address and 1041 optionally may include a postal address and/or telephone number. If 1042 the postal address is included, it should include the country name, 1043 using the English short name listed by the ISO 3166 Maintenance 1044 Agency [ISO_OBP]. The purpose of this section is to (1) 1045 unambiguously define author identity (e.g., the John Smith who works 1046 for FooBar Systems) and (2) provide contact information for future 1047 readers who have questions or comments. 1049 The practice of munged email addresses (i.e., altering an email 1050 address to make it less readable to bots and web crawlers to avoid 1051 spam) is not appropriate in an archival document series. Author 1052 contact information is provided so that readers can easily contact 1053 the author with questions and/or comments. Address munging is not 1054 allowed in RFCs. 1056 5. Security Considerations 1058 This document has no security considerations. 1060 6. IANA Considerations 1062 This document has no IANA considerations. 1064 7. Change Log 1066 This section to be removed before publication. 1068 -00 to -01: Citation tag requirements more tightly specified; 1069 index moved; new errata URI added; capitalization of working/ 1070 research group specified 1072 -01 to -02: update Abstract guidance 1074 -02 to -03: updated citation section; changed list styles; added 1075 angle brackets to reference examples; changed I-D reference 1076 format; clarified sub-series reference format; added guidance on 1077 referencing code repositories 1079 -03 to -04: updated Reference Section guidance; added information 1080 on alt text 1082 8. References 1084 8.1. Normative References 1086 [STYLE-WEB] 1087 RFC Editor, "Web Portion of the Style Guide", 1088 . 1090 8.2. Informative References 1092 [ABBR] RFC Editor, "RFC Editor Abbreviations List", 1093 . 1096 [ALTTEXT] W3C, "Understanding Success Criterion 1.3.1: Info and 1097 Relationships", 1098 . 1101 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997, 1103 . 1105 [BCP18] Alvestrand, H., "IETF Policy on Character Sets and 1106 Languages", BCP 18, RFC 2277, January 1998, 1107 . 1109 [BCP26] Alvestrand, H. and T. Narten, "Guidelines for Writing an 1110 ANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1111 2008, . 1113 [BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1114 Names", BCP 32, RFC 2606, June 1999, 1115 . 1117 [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1118 Text on Security Considerations", BCP 72, RFC 3552, July 1119 2003, . 1121 [CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue", 1122 . 1124 [CMOS] University of Chicago Press, 2010, "Chicago Manual of 1125 Style, 16th ed.", 2010. 1127 [FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to 1128 the FYI Notes", FYI 90, RFC 1150, March 1990, 1129 . 1131 Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, 1132 August 2011. 1134 [IAB-FORM] 1135 IAB, "Format for RFCs in the IAB Stream", 1136 . 1139 [ID-GUIDE] 1140 IETF, "Guidelines to Authors of Internet Drafts", 1141 . 1143 [IETF-TRUST] 1144 IETF Trust, "Trust Legal Provisions (TLP)", 1145 . 1147 [ISO3297] Technical Committee ISO/TC 46, Information and 1148 documentation, Subcommittee SC 9, "Identification and 1149 description, Information and documentation - International 1150 standard serial number (ISSN)", September 2007. 1152 [ISO_OBP] ISO, "Online Browsing Platform (OBP)", 1153 . 1155 [MIB-BOILER] 1156 IETF OPS Area, "Boilerplate for IETF MIB Documents", 1157 . 1159 [MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules", 1160 . 1163 [REFEXAMPLE] 1164 RFC Editor, "Reference Examples", 1165 . 1167 [REFS] IESG, "IESG Statement: Normative and Informative", 1168 . 1171 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 1172 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 1173 July 2007, . 1175 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 1176 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 1177 2012, . 1179 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 1180 "RFC Streams, Headers, and Boilerplates", RFC 7841, 1181 DOI 10.17487/RFC7841, May 2016, 1182 . 1184 [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, 1185 DOI 10.17487/RFC7990, December 2016, 1186 . 1188 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 1189 RFC 7991, DOI 10.17487/RFC7991, December 2016, 1190 . 1192 [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", 1193 RFC 7996, DOI 10.17487/RFC7996, December 2016, 1194 . 1196 [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in 1197 RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, 1198 . 1200 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1201 Resource Identifier (URI): Generic Syntax", STD 66, 1202 RFC 3986, January 2005, 1203 . 1205 [TERMS] RFC Editor, "Terms List", 1206 . 1208 [YANG-SEC] 1209 IETF Ops Area, "yang module security considerations", 1210 . 1213 8.3. URIs 1215 [1] https://www.rfc-editor.org/info/rfc# 1217 [2] https://www.rfc-editor.org/info/rfc3080 1219 [3] https://www.rfc-editor.org/info/rfc8157 1221 [4] https://www.rfc-editor.org/info/rfc# 1223 [5] https://www.rfc-editor.org/info/rfc6323 1225 [6] https://www.rfc-editor.org/info/rfc# 1227 [7] https://www.rfc-editor.org/info/rfc6429 1229 [8] https://www.rfc-editor.org/info/std# 1231 [9] https://www.rfc-editor.org/info/std72 1233 Appendix A. Related Procedures 1235 The following procedures are related to the application and updating 1236 of the RFC Style Guide. 1238 A.1. Dispute Resolution 1240 There are competing rationales for some of the rules described in 1241 this Guide, and the RFC Editor has selected the ones that work best 1242 for the Series. However, at times, an author may have a disagreement 1243 with the RFC Production Center (RPC) over the application of Style 1244 Guide conventions. In such cases, the authors should discuss their 1245 concerns with the RPC. If no agreement can be reached between the 1246 RPC and the authors, the RFC Series Editor will, with input from the 1247 appropriate stream-approving body, make a final determination. If 1248 further resolution is required, the dispute resolution process as 1249 described in the RFC Editor Model [RFC6635] will be followed. 1251 A.2. Returning an I-D to the Document Stream 1253 For a given document, if the RFC Editor determines that it cannot be 1254 edited without serious risk of altering the meaning of the technical 1255 content or if the RFC Editor does not have the resources to provide 1256 the level of editing it needs, it may be sent back to the stream- 1257 approving body with a request to improve the clarity, consistency, 1258 and/or readability of the document. This is not to be considered a 1259 dispute with the author. 1261 A.3. Revising This Document and Associated Web Pages 1263 The RFC Series is continually evolving as a document series. This 1264 document focuses on the fundamental and stable requirements that must 1265 be met by an RFC. From time to time, the RFC Editor may offer less 1266 formal recommendations that authors may apply at their discretion; 1267 these recommendations may be found on the RFC Editor website 1268 "Guidelines for RFC Style" [STYLE-WEB]. 1270 When a new recommendation is made regarding the overall structure and 1271 formatting of RFCs, it will be published on that page and accepted 1272 for a period of time before the RFC Editor determines whether it 1273 should become part of the fundamental requirements in the RFC Style 1274 Guide or remain as a less formal recommendation. That period of time 1275 will vary, in part depending on the frequency with which authors 1276 encounter and apply the guidance. 1278 Authors' Addresses 1280 Heather Flanagan 1281 RFC Editor 1283 EMail: rse@rfc-editor.org 1284 URI: https://orcid.org/0000-0002-2647-2220 1286 Sandy Ginoza 1287 RFC Editor 1289 EMail: rfc-editor@rfc-editor.org 1290 URI: https://www.rfc-editor.org