idnits 2.17.1
draft-flanagan-7322bis-07.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 (7 April 2021) is 1107 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 779, but not defined
== Missing Reference: 'RFC3080' is mentioned on line 753, but not defined
== Missing Reference: 'RFC8157' is mentioned on line 757, but not defined
== Missing Reference: 'RFC6323' is mentioned on line 772, but not defined
== Missing Reference: 'RFC6429' is mentioned on line 788, but not defined
** Obsolete undefined reference: RFC 6429 (Obsoleted by RFC 9293)
== Missing Reference: 'RFC5741' is mentioned on line 811, but not defined
** Obsolete undefined reference: RFC 5741 (Obsoleted by RFC 7841)
== Missing Reference: 'STD13' is mentioned on line 843, but not defined
== Missing Reference: 'STDXXX' is mentioned on line 831, but not defined
== Missing Reference: 'STD72' is mentioned on line 824, but not defined
== Missing Reference: 'SYMBOLIC-TAG' is mentioned on line 979, but not
defined
== Missing Reference: 'RFC-STYLE' is mentioned on line 880, but not defined
== Missing Reference: 'ErrNumber' is mentioned on line 889, but not defined
== Missing Reference: 'Err1912' is mentioned on line 892, but not defined
== Missing Reference: 'IANA-SYMBOLIC-TAG' is mentioned on line 900, but not
defined
== Missing Reference: 'IEEE.802.15.4' is mentioned on line 941, but not
defined
== Missing Reference: 'IEEE802.1Q' is mentioned on line 948, but not defined
== Missing Reference: 'ISOC-MANRS' is mentioned on line 982, but not defined
-- Obsolete informational reference (is this intentional?): RFC 5226 (ref.
'BCP26') (Obsoleted by RFC 8126)
-- 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 (==), 4 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: 9 October 2021 7 April 2021
8 RFC Style Guide
9 draft-flanagan-7322bis-07
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 9 October 2021.
38 Copyright Notice
40 Copyright (c) 2021 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 (https://trustee.ietf.org/
45 license-info) in effect on the date of publication of this document.
46 Please review these documents carefully, as they describe your rights
47 and restrictions with respect to this document. Code Components
48 extracted from this document must include Simplified BSD License text
49 as described in Section 4.e of the Trust Legal Provisions and are
50 provided without warranty as described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. RFC Editor's Philosophy . . . . . . . . . . . . . . . . . . . 4
56 3. RFC Style Conventions . . . . . . . . . . . . . . . . . . . . 5
57 3.1. Language . . . . . . . . . . . . . . . . . . . . . . . . 5
58 3.2. Punctuation . . . . . . . . . . . . . . . . . . . . . . . 5
59 3.2.1. RFCs as Compounds . . . . . . . . . . . . . . . . . . 5
60 3.3. DNS Names and URIs . . . . . . . . . . . . . . . . . . . 6
61 3.4. Capitalization . . . . . . . . . . . . . . . . . . . . . 6
62 3.5. Citations . . . . . . . . . . . . . . . . . . . . . . . . 7
63 3.6. Abbreviation Rules . . . . . . . . . . . . . . . . . . . 8
64 3.7. Images and Figures . . . . . . . . . . . . . . . . . . . 8
65 4. Structure of an RFC . . . . . . . . . . . . . . . . . . . . . 9
66 4.1. First-Page Header . . . . . . . . . . . . . . . . . . . . 10
67 4.1.1. Author/Editor . . . . . . . . . . . . . . . . . . . . 11
68 4.1.2. Organization . . . . . . . . . . . . . . . . . . . . 11
69 4.1.3. ISSN: 2070-1721 . . . . . . . . . . . . . . . . . . . 11
70 4.1.4. Digital Object Identifier 10.17487 . . . . . . . . . 12
71 4.1.5. Updates and Obsoletes . . . . . . . . . . . . . . . . 12
72 4.2. Document Title . . . . . . . . . . . . . . . . . . . . . 12
73 4.3. Abstract Section . . . . . . . . . . . . . . . . . . . . 13
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 . . . . 14
77 4.7. Table of Contents Section . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . 23
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 Appendix A. Related Procedures . . . . . . . . . . . . . . . . . 27
97 A.1. Dispute Resolution . . . . . . . . . . . . . . . . . . . 27
98 A.2. Returning an I-D to the Document Stream . . . . . . . . . 27
99 A.3. Revising This Document and Associated Web Pages . . . . . 28
100 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 28
101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
103 1. Introduction
105 The ultimate goal of the RFC publication process is to produce
106 documents that are readable, clear, and consistent. The basic
107 formatting conventions for RFCs were established in the 1970s by the
108 original RFC Editor, Jon Postel. This document describes the
109 fundamental and unique style conventions and editorial policies
110 currently in use for the RFC Series [RFC4844] and is intended as a
111 stable, infrequently updated reference for authors, editors, and
112 reviewers.
114 The RFC Editor also maintains a web portion of the Style Guide (see
115 Appendix A.3) that describes issues as they are raised and indicates
116 how the RFC Editor intends to address them. As new style issues
117 arise, the RFC Editor will first address them on the web portion of
118 the Style Guide [STYLE-WEB]. These topics may become part of the RFC
119 Style Guide when it is revised.
121 The world of publishing has generally accepted rules for grammar,
122 punctuation, capitalization, sentence length and complexity, etc.
123 The RFC Editor generally follows these accepted rules as defined by
124 the Chicago Manual of Style (CMOS) [CMOS], with a few important
125 exceptions to avoid ambiguity in complex technical prose and to
126 handle mixtures of text and computer languages, or to preserve
127 historical formatting rules. This document presents these exceptions
128 as applied or recommended by the RFC Editor.
130 All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a
131 well-written and properly constructed Internet-Draft [ID-GUIDE]
132 provides a strong basis for a good RFC. The RFC Editor accepts
133 Internet-Drafts from specified streams for publication [RFC4844] and
134 applies the rules and guidelines for the RFC Series during the
135 editorial process.
137 2. RFC Editor's Philosophy
139 Authors may find it helpful to understand the RFC Editor's goals
140 during the publication process, namely to:
142 * Prepare the document according to RFC style and format.
144 * Make the document as clear, consistent, and readable as possible.
146 * Correct larger content/clarity issues; flag any unclear passages
147 for author review.
149 * Fix inconsistencies (e.g., terms that appear in various forms,
150 inconsistent capitalization, discrepancies between a figure and
151 the text that describes it).
153 We strive for consistency within:
155 a. the document,
157 b. a cluster of documents [CLUSTER], and
159 c. the series of RFCs on the subject matter.
161 The editorial process of the RFC Editor is not an additional
162 technical review of the document. Where the RFC Editor may suggest
163 changes in wording for clarity and readability, it is up to the
164 author, working group, or stream-approving body to determine whether
165 the changes have an impact on the technical meaning of the document
166 [RFC4844]. If the original wording is a more accurate representation
167 of the technical content being described in the document, it takes
168 precedence over editorial conventions.
170 The activity of editing sometimes creates a tension between author
171 and editor. The RFC Editor attempts to minimize this conflict for
172 RFC publication while continually striving to produce a uniformly
173 excellent document series. The RFC Editor refers to this fundamental
174 tension as "editorial balance," and maintaining this balance is a
175 continuing concern for the RFC Editor. There is a prime directive
176 that must rule over grammatical conventions: do not change the
177 intended meaning of the text.
179 If the RFC Editor cannot edit a document without serious risk of
180 altering the meaning, it may be returned to the stream-approving body
181 for review. See Appendix A.2 for more information.
183 3. RFC Style Conventions
185 This Style Guide does not use terminology as defined in RFC 2119
186 [BCP14]. In this document, lowercase use of "must" and "should"
187 indicates changes the RFC Editor will make automatically to conform
188 with this Style Guide versus those that may be questioned if not
189 applied. The lowercase "must" indicates those changes that will be
190 applied automatically and are not at the discretion of the authors.
191 The lowercase "should" indicates the RFC Editor's recommended use,
192 but conformance with the recommendations is not required; the RFC
193 Editor may question whether the guidance may be applied.
195 3.1. Language
197 The RFC publication language is English. Spelling may be either
198 American or British, as long as an individual document is internally
199 consistent. Where both American and British English spelling are
200 used within a document or cluster of documents, the text will be
201 modified to be consistent with American English spelling.
203 3.2. Punctuation
205 1. A comma is used before the last item of a series, e.g.,
207 "TCP service is reliable, ordered, and full duplex"
209 2. When quoting literal text, punctuation is placed outside
210 quotation marks, e.g.,
212 Search for the string "Error Found".
214 When quoting general text, such as general text from another RFC,
215 punctuation may be included within the quotation marks, e.g.,
217 RFC 4844 indicates that "RFCs are available free of charge to
218 anyone via the Internet."
220 Quotation marks are not necessary when text is formatted as a
221 block quotation.
223 3.2.1. RFCs as Compounds
225 Whenever possible:
227 * Hyphenated compounds formed with RFC numbers should be avoided;
228 this can be accomplished by: rewording the sentence (e.g., change
229 "[RFC5011]-style rollover" to "rollover as described in RFC
230 5011").
232 * 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 * no hyphen between "RFC" and the number (don't use RFC-5011-style
243 rollover)
245 * 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. Digital Object Identifier 10.17487
497 The RFC Series has been assigned a Digital Object Identifier prefix
498 of 10.17487 [RFC7669]. A DOI will be assigned and included by the
499 RFC Editor.
501 4.1.5. Updates and Obsoletes
503 When an RFC obsoletes or updates a previously published RFC or RFCs,
504 this information is included in the document header. For example:
506 "Updates: nnnn" or "Updates: nnnn, ..., nnnn"
508 "Obsoletes: nnnn" or "Obsoletes: nnnn, ..., nnnn"
510 If the document updates or obsoletes more than one document, numbers
511 will be listed in ascending order.
513 4.2. Document Title
515 The title must be centered below the rest of the heading, preceded by
516 two blank lines and followed by one blank line.
518 Choosing a good title for an RFC can be a challenge. A good title
519 should fairly represent the scope and purpose of the document without
520 being either too general or too specific and lengthy.
522 Abbreviations in a title must generally be expanded when first
523 encountered (see Section 3.6 for additional guidance on
524 abbreviations).
526 It is often helpful to follow the expansion with the parenthesized
527 abbreviation, as in the following example:
529 Encoding Rules for the
530 Common Routing Encapsulation Extension Protocol (CREEP)
532 The RFC Editor recommends that documents describing a particular
533 company's private protocol should bear a title of the form "Foo's ...
534 Protocol" (where Foo is a company name), to clearly differentiate it
535 from a protocol of more general applicability.
537 4.3. Abstract Section
539 Every RFC must have an Abstract that provides a concise and
540 comprehensive overview of the purpose and contents of the entire
541 document, to give a technically knowledgeable reader a general
542 overview of the function of the document and some context with
543 regards to its relationship (in particular, whether it updates or
544 obsoletes) any other RFCs. In addition to its function in the RFC
545 itself, the Abstract section text will appear in publication
546 announcements and in the online index of RFCs.
548 Composing a useful Abstract generally requires thought and care.
549 Usually, an Abstract should begin with a phrase like "This memo ..."
550 or "This document ..." A satisfactory Abstract can often be
551 constructed in part from material within the Introduction section,
552 but an effective Abstract may be shorter, less detailed, and perhaps
553 broader in scope than the Introduction. Simply copying and pasting
554 the first few paragraphs of the Introduction is allowed, but it may
555 result in an Abstract that is overly long, incomplete, and redundant.
557 An Abstract is not a substitute for an Introduction; the RFC should
558 be self-contained as if there were no Abstract. Similarly, the
559 Abstract should be complete in itself. Given that the Abstract will
560 appear independently in announcements and indices, mentions of other
561 RFCs within the Abstract should include both an RFC number and either
562 the full or short title. Any documents that are Updated or Obsoleted
563 by the RFC must be mentioned in the Abstract if those documents offer
564 important provisions of, or reasons for, the RFC. These may be
565 presented in a list format if that improves readability.
567 4.4. RFC Editor or Stream Notes Section
569 A stream-approving body may approve the inclusion of an editorial
570 note to explain anything unusual about the process that led to the
571 document's publication or to note a correction. In this case, a
572 stream note section will contain such a note.
574 Additionally, an RFC Editor Note section may contain a note inserted
575 by the RFC Editor to highlight special circumstances surrounding an
576 RFC.
578 4.5. Status of This Memo Section
580 The RFC Editor will supply an appropriate "Status of This Memo" as
581 defined in RFC [RFC7841] and "Format for RFCs in the IAB Stream"
582 [IAB-FORM].
584 4.6. Copyright, Licenses, and IPR Boilerplate Section
586 The full copyright and license notices are available on the IETF
587 Trust Legal Provisions documents website [IETF-TRUST].
589 4.7. Table of Contents Section
591 A Table of Contents (TOC) is required in all RFCs. It must be
592 positioned after the Copyright Notice and before the Introduction.
594 4.8. Body of the Memo
596 Following the TOC is the body of the memo.
598 Each RFC must include an Introduction section that (among other
599 things) explains the motivation for the RFC and (if appropriate)
600 describes the applicability of the document, e.g., whether it
601 specifies a protocol, provides a discussion of some problem, is
602 simply of interest to the Internet community, or provides a status
603 report on some activity. The body of the memo and the Abstract must
604 be self-contained and separable. This may result in some duplication
605 of text between the Abstract and the Introduction; this is
606 acceptable.
608 4.8.1. Introduction Section
610 The Introduction section should always be the first section following
611 the TOC (except in the case of MIB module documents). While
612 "Introduction" is recommended, authors may choose alternate titles
613 such as "Overview" or "Background". These alternates are acceptable.
615 For MIB module documents, common practice has been for "The Internet-
616 Standard Management Framework" [MIB-BOILER] text to appear as
617 Section 1.
619 4.8.2. Requirements Language Section
621 Some documents use certain capitalized words ("MUST", "SHOULD", etc.)
622 to specify precise requirement levels for technical features. RFC
623 2119 [BCP14] defines a default interpretation of these capitalized
624 words in IETF documents. If this interpretation is used, RFC 2119
625 must be cited (as specified in RFC 2119) and included as a normative
626 reference. Otherwise, the correct interpretation must be specified
627 in the document.
629 This section must appear as part of the body of the memo (as defined
630 by this document). It must appear as part of, or subsequent to, the
631 Introduction section.
633 These words are considered part of the technical content of the
634 document and are intended to provide guidance to implementers about
635 specific technical features, generally governed by considerations of
636 interoperability. RFC 2119 says:
638 Imperatives of the type defined in this memo must be used with care
639 and sparingly. In particular, they MUST only be used where it is
640 actually required for interoperation or to limit behavior which has
641 potential for causing harm (e.g., limiting retransmisssions) For
642 example, they must not be used to try to impose a particular method
643 on implementers where the method is not required for
644 interoperability.
646 4.8.3. IANA Considerations Section
648 For guidance on how to register IANA-related values or create new
649 registries to be managed by IANA, see "Guidelines for Writing an IANA
650 Considerations Section in RFCs" [BCP26].
652 The RFC Editor will update text accordingly after the IANA
653 assignments have been made. It is helpful for authors to clearly
654 identify where text should be updated to reflect the newly assigned
655 values. For example, the use of "TBD1", "TBD2", etc., is recommended
656 in the IANA Considerations section and in the body of the memo.
658 If the authors have provided values to be assigned by IANA, the RFC
659 Editor will verify that the values inserted by the authors match
660 those that have actually been registered on the IANA site. When
661 writing a given value, consistent use of decimal or hexadecimal is
662 recommended.
664 If any of the IANA-related information is not clear, the RFC Editor
665 will work with IANA to send queries to the authors to ensure that
666 assignments and values are properly inserted.
668 4.8.4. Internationalization Considerations Section
670 All RFCs that deal with internationalization issues should have a
671 section describing those issues; see "IETF Policy on Character Sets
672 and Languages" [BCP18], Section 6, for more information.
674 4.8.5. Security Considerations Section
676 All RFCs must contain a section that discusses the security
677 considerations relevant to the specification; see "Guidelines for
678 Writing RFC Text on Security Considerations" [BCP72] for more
679 information.
681 Note that additional boilerplate material for RFCs containing MIB and
682 YANG modules also exists. See "Security Guidelines for IETF MIB
683 Modules" [MIB-SEC] and "yang module security considerations"
684 [YANG-SEC] for details.
686 4.8.6. References Section
688 The reference list is solely for recording reference entries.
689 Introductory text or annotations beyond necessary translations
690 [RFC7997] are not allowed.
692 The RFC style allows the use of any of a variety of reference styles,
693 as long as they are used consistently within a document. However,
694 where necessary, some reference styles have been described for use
695 within the Series. See the following subsections as well as the
696 References section of this document.
698 Reference lists must indicate whether each reference is normative or
699 informative, where normative references are essential to implementing
700 or understanding the content of the RFC and informative references
701 provide additional information. More information about normative and
702 informative references may be found in the IESG's statement
703 "Normative and Informative References" [REFS]. When both normative
704 and informative references exist, the references section should be
705 split into two subsections:
707 Templates are available on the RFC Editor website for the XML format
708 of certain references [REFEXAMPLE].
710 s. References
712 s.1. Normative References
714 xxx
715 ...
716 xxx
718 s.2. Informative References
720 xxx
721 ...
722 xxx
724 References will generally appear in alphanumeric order by citation
725 tag. Where there are only normative or informative references, no
726 subsection is required; the top-level section should say "Normative
727 References" or "Informative References".
729 Normative references to Internet-Drafts will cause publication of the
730 RFC to be suspended until the referenced draft is also ready for
731 publication; the RFC Editor will then update the entry to refer to
732 the RFC and publish both documents simultaneously.
734 4.8.6.1. Referencing RFCs
736 The following format is required for referencing RFCs. The Stream
737 abbreviation should be used; when no stream is available, as with
738 legacy RFCs, this may be left blank.
740 Note the ordering for multiple authors: the format of the name of the
741 last author listed is different than that of all previous authors in
742 the list.
744 For one author or editor:
746 [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC
747 Title", Stream, Sub-series number (if applicable), RFC number, RFC
748 DOI, Date of publication,
749 (https://www.rfc-editor.org/info/rfc#).
751 Example:
753 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core,"
754 IETF, RFC 3080, DOI 10.17487/RFC3080, March 2001, (https://www.rfc-editor.org/info/rfc3080).
757 [RFC8157] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M.
758 Cullen, "Huawei's GRE Tunnel Bonding Protocol", independent, RFC
759 8157, DOI 10.17487/RFC8157, May 2017, (https://www.rfc-editor.org/info/rfc8157).
762 For two authors or editors:
764 [RFCXXXX] Last name, First initial., Ed. (if applicable) and First
765 initial. Last name, Ed. (if applicable), "RFC Title", Stream, Sub-
766 series number (if applicable), RFC number, RFC DOI, Date of
767 publication, (https://www.rfc-
768 editor.org/info/rfc#).
770 Example:
772 [RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option
773 for the Datagram Congestion Control Protocol (DCCP)", IETF, RFC 6323,
774 DOI 10.17487/RFC6323, July 2011, (https://www.rfc-editor.org/info/rfc6323).
777 For three or more authors or editors:
779 [RFCXXXX] Last name, First initial., Ed. (if applicable), Last name,
780 First initial., Ed. (if applicable), and First initial. Last name,
781 Ed. (if applicable), "RFC Title", Stream, Sub-series number (if
782 applicable), RFC number, RFC DOI, Date of publication,
783 (https://www.rfc-
784 editor.org/info/rfc#).
786 Example:
788 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender
789 Clarification for Persist Condition", IETF, RFC 6429, DOI 10.17487/
790 RFC6429, December 2011, >https://www.rfc-editor.org/info/rfc6429 <
791 (https://www.rfc-editor.org/info/rfc6429).
793 4.8.6.2. Referencing RFC(s) in a Subseries (STDs, BCPs, and FYIs
795 Internet Standards (STDs) and Best Current Practices (BCPs) may
796 consist of a single RFC or multiple RFCs. Authors should carefully
797 consider whether they want to point the reader to the specific RFC or
798 the sub series group. In the former case, references should appear
799 as described in Section 4.8.6.2. In the latter case, the sub series
800 number should take precedence as, for example, the citation tag, even
801 in cases where the sub series currently contains only one RFC.
803 When an STD or BCP that contains multiple RFCs is referenced as a sub
804 series group, the reference entry should include ALL of the RFCs
805 comprising that sub-series in a reference grouping under a single
806 citation tag [is it helpful to point them to 7991 or the like on how
807 to do this here?]. The authors should refer to the specific RFC
808 numbers as part of the text in the body of the document and cite the
809 sub series number (for example, "see RFC 2119 of [BCP14]").
810 Inclusion of the URI to the STD or BCP info page (see Section 3.2.3
811 of [RFC5741]) is recommended. The text should appear as follows:
813 See RFC 1034 [STD13].
815 For an STD or BCP that contains one RFC:
817 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title",
818 Stream, Sub-series number, RFC number, RFC DOI, Date of publication,
819 (https://www.rfc-
820 editor.org/info/std#).
822 Example:
824 [STD72] Gellens, R. and J. Klensin, "Message Submission for Mail",
825 IETF, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
826 (https://www.rfc-
827 editor.org/info/std72).
829 For an STD or BCP that contains two or more RFCs:
831 [STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title",
832 Stream, Sub-series number, RFC number, RFC DOI, Date of publication.
834 Last name, First initial., Ed. (if applicable)
835 and First initial. Last name, Ed. (if applicable),
836 "RFC Title", Stream, Sub-series number, RFC number, RFC DOI,
837 Date of publication.
839
841 Example:
843 [STD13] Mockapetris, P., "Domain names - concepts and facilities",
844 IETF, STD 13, RFC 1034, November 1987.
846 Mockapetris, P., "Domain names - implementation and
847 specification", IETF, STD 13, RFC 1035, DOI 10.17487/RFC1035,
848 November 1987.
850
852 Note - some RFCs contain an FYI sub-series number [FYI90] however,
853 the FYI series was ended by RFC 6360. RFCs that were published with
854 an FYI sub-series number and still maintain the FYI number must
855 include the sub-series number in the reference and may otherwise be
856 treated in the same manner as STDs and BCPs.
858 Grouping references to RFCs or other materials that are not part of a
859 sub-series is discouraged.
861 4.8.6.3. Referencing Internet-Drafts
863 References to Internet Drafts may only appear as informative
864 references. Given that several revisions of an I-D may be produced
865 in a short time frame, references must include the posting date
866 (month and year), the full Internet-Draft file name (including the
867 version number), and the phrase "Internet Draft". Authors may
868 reference multiple versions of an I-D. If the referenced I-D was
869 also later published as an RFC, then that RFC must also be listed.
870 The reference should include a stable URL for the draft, if
871 available.
873 [SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and
874 First initial. Last name, Ed. (if applicable), "I-D Title", Work in
875 Progress, Internet-Draft, draft-string-NN, Day Month Year,
876 https://datatracker.ietf.org/doc/html/draft-something.
878 Example:
880 [RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in
881 Progress, Internet-Draft, draft-flanagan-style-04, 27 September 2019,
882 https://datatracker.ietf.org/doc/html/draft-flanagan-style-04.
884 4.8.6.4. Referencing Errata
886 The following format is required when a reference to an erratum
887 report is necessary:
889 [ErrNumber] RFC Errata, Erratum ID number, RFC number,
890 .
892 [Err1912] RFC Errata, Erratum ID 1912, RFC 2978, .
895 4.8.6.5. Referencing IANA Registries
897 IANA registries may appear in normative or informative reference
898 sections.
900 [IANA-SYMBOLIC-TAG]
902 IANA, "Registry Name", .
904 4.8.6.6. Referencing Other Standards Development Organizations (SDOs)
906 The following format is suggested when referencing a document or
907 standard from another SDO in which authors are listed:
909 [SYMBOLIC-TAG]
911 Last name, First initial. and First initial. Last name,
913 "Document Title", Document reference number, Date of
915 publication, .
917 [W3C.REC-xml11]
919 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
920 Yergeau, F., and J. Cowan, "Extensible Markup Language
922 (XML) 1.1 (Second Edition)", W3C Recommendation
924 REC-xml11-20060816, August 2006,
926 .
928 The order of authors in the list is the same as the order shown on
929 the actual document and that the common, abbreviated form of the SDO
930 is used.
932 Alternatively, when no list of authors is available, the following
933 format is recommended:
935 [SYMBOLIC-TAG] Organization, "Document Title", Document
936 reference number, Date of publication,
937 .
939 Example (undated; see note below):
941 [IEEE.802.15.4]
942 IEEE, "IEEE Standard for Low-Rate Wireless Networks",
943 IEEE 802.15.4,
944 .
946 Example (dated; see note below):
948 [IEEE802.1Q] IEEE, "Local and Metropolitan Area
949 Networks -- Media Access Control (MAC)
950 Bridges and Virtual Bridged Local Area
951 Networks", IEEE Std 802.1Q-2011, August 2011,
952
955 Per the IEEE coordination team, listing dates for IEEE standards is
956 not recommended unless there is a need to cite a particular section,
957 in which case the dated reference is appropriate. An RFC with a
958 dated IEEE reference suggests that the RFC only applies to that
959 specific IEEE specification.
961 4.8.6.7. Referencing Webpages
963 References to webpages acceptable in either the normative or
964 informative sections, as long as the URL provided is the most stable
965 (i.e., unlikely to change and expected to be continuously available)
966 and direct reference possible. The URL will be verified as valid
967 during the RFC editorial process.
969 If a dated URI (one that includes a timestamp for the page) is
970 available for a referenced web page, its use is required.
972 Note that the URL may not be the sole information provided for a
973 reference entry.
975 The use of HTTPS rather than HTTP is strongly encouraged.
977 Example:
979 [SYMBOLIC-TAG] Author (if available), "Page Title (if available)",
980 .
982 [ISOC-MANRS] Internet Society, "Mutually Agreed
983 Norms for Routing Security",
984
986 4.8.6.8. Referencing Email on Mailing Lists
988 When referencing emails to mailing lists, the template provided here
989 should be used:
991 [reftag] Sender, A., "Subject: Subject line", message to the
993 listname mailing list, DD Month YYYY, .
995 4.8.6.9. Referencing Code Repositories
997 References to online code repositories such as GitHub or SourceForge
998 should be used as informative references only. The reference entry
999 should include the repository title, commit hash or similar release
1000 marker if available, date of last commit, and URL.
1002 Examples:
1004 [pysaml] "Python implementation of SAML2", commit 7135d53,
1005 6 March 2018, .
1007 [linuxlite] "Linux Lite", 9 March 2018,
1008 .
1010 4.9. Appendices Section
1012 The RFC Editor recommends placing references before the Appendices.
1013 Appendices should be labeled as "Appendix A. Title", "A.1. Title",
1014 "Appendix B. Title", etc.
1016 4.10. Acknowledgements Section
1018 This optional section may be used instead of, or in addition to, a
1019 Contributors section. It is often used by authors to publicly thank
1020 those who have provided feedback regarding a document and to note any
1021 documents from which text was borrowed.
1023 4.11. Contributors Section
1025 This optional section acknowledges those who have made significant
1026 contributions to the document.
1028 In a similar fashion to the Author's Address section, the RFC Editor
1029 does not make the determination as to who should be listed as a
1030 contributor to an RFC. The determination of who should be listed as
1031 a contributor is made by the stream.
1033 The Contributors section may include brief statements about the
1034 nature of particular contributions (e.g., "Sam contributed
1035 Section 3"), and it may also include affiliations of listed
1036 contributors. At the discretion of the author(s), contact addresses
1037 may also be included in the Contributors section, for those
1038 contributors whose knowledge makes them useful future contacts for
1039 information about the RFC. The format of any contact information
1040 should be similar to the format of information in the Author's
1041 Address section.
1043 4.12. Index
1045 If included, an index appears at the end of the document, immediately
1046 before Author's Address section.
1048 4.13. Author's Address or Authors' Addresses Section
1050 This required section gives contact information for the author(s)
1051 listed in the first-page header.
1053 Contact information must include a long-lived email address and
1054 optionally may include a postal address and/or telephone number. If
1055 the postal address is included, it should include the country name,
1056 using the English short name listed by the ISO 3166 Maintenance
1057 Agency [ISO_OBP]. The purpose of this section is to (1)
1058 unambiguously define author identity (e.g., the John Smith who works
1059 for FooBar Systems) and (2) provide contact information for future
1060 readers who have questions or comments.
1062 The practice of munged email addresses (i.e., altering an email
1063 address to make it less readable to bots and web crawlers to avoid
1064 spam) is not appropriate in an archival document series. Author
1065 contact information is provided so that readers can easily contact
1066 the author with questions and/or comments. Address munging is not
1067 allowed in RFCs.
1069 5. Security Considerations
1071 This document has no security considerations.
1073 6. IANA Considerations
1075 This document has no IANA considerations.
1077 7. Change Log
1079 This section to be removed before publication.
1081 -00 to -01: Citation tag requirements more tightly specified;
1082 index moved; new errata URI added; capitalization of working/
1083 research group specified
1085 -01 to -02: update Abstract guidance
1087 -02 to -03: updated citation section; changed list styles; added
1088 angle brackets to reference examples; changed I-D reference
1089 format; clarified sub-series reference format; added guidance on
1090 referencing code repositories
1092 -03 to -04: updated Reference Section guidance; added information
1093 on alt text
1095 -04 to -05: change author, add acknowledgement
1097 8. References
1099 8.1. Normative References
1101 [STYLE-WEB]
1102 RFC Editor, "Web Portion of the Style Guide",
1103 .
1105 8.2. Informative References
1107 [ABBR] RFC Editor, "RFC Editor Abbreviations List",
1108 .
1111 [ALTTEXT] W3C, "Understanding Success Criterion 1.3.1: Info and
1112 Relationships",
1113 .
1116 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
1117 Requirement Levels", BCP 14, RFC 2119, March 1997,
1118 .
1120 [BCP18] Alvestrand, H., "IETF Policy on Character Sets and
1121 Languages", BCP 18, RFC 2277, January 1998,
1122 .
1124 [BCP26] Alvestrand, H. and T. Narten, "Guidelines for Writing an
1125 ANA Considerations Section in RFCs", BCP 26, RFC 5226, May
1126 2008, .
1128 [BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
1129 Names", BCP 32, RFC 2606, June 1999,
1130 .
1132 [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
1133 Text on Security Considerations", BCP 72, RFC 3552, July
1134 2003, .
1136 [CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue",
1137 .
1139 [CMOS] University of Chicago Press, 2010, "Chicago Manual of
1140 Style, 16th ed.", 2010.
1142 [FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to
1143 the FYI Notes", FYI 90, RFC 1150, March 1990,
1144 . Housley, R.,
1145 "Conclusion of FYI RFC Sub-Series", RFC 6360, August 2011.
1147 [IAB-FORM] IAB, "Format for RFCs in the IAB Stream",
1148 .
1151 [ID-GUIDE] IETF, "Guidelines to Authors of Internet Drafts",
1152 .
1154 [IETF-TRUST]
1155 IETF Trust, "Trust Legal Provisions (TLP)",
1156 .
1158 [ISO3297] Technical Committee ISO/TC 46, Information and
1159 documentation, Subcommittee SC 9, "Identification and
1160 description, Information and documentation - International
1161 standard serial number (ISSN)", September 2007.
1163 [ISO_OBP] ISO, "Online Browsing Platform (OBP)",
1164 .
1166 [MIB-BOILER]
1167 IETF OPS Area, "Boilerplate for IETF MIB Documents",
1168 .
1170 [MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules",
1171 .
1174 [REFEXAMPLE]
1175 RFC Editor, "Reference Examples",
1176 .
1178 [REFS] IESG, "IESG Statement: Normative and Informative",
1179 .
1182 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
1183 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
1184 July 2007, .
1186 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
1187 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
1188 2012, .
1190 [RFC7669] Levine, J., "Assigning Digital Object Identifiers to
1191 RFCs", RFC 7669, DOI 10.17487/RFC7669, October 2015,
1192 .
1194 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
1195 "RFC Streams, Headers, and Boilerplates", RFC 7841,
1196 DOI 10.17487/RFC7841, May 2016,
1197 .
1199 [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990,
1200 DOI 10.17487/RFC7990, December 2016,
1201 .
1203 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
1204 RFC 7991, DOI 10.17487/RFC7991, December 2016,
1205 .
1207 [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
1208 RFC 7996, DOI 10.17487/RFC7996, December 2016,
1209 .
1211 [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in
1212 RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
1213 .
1215 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1216 Resource Identifier (URI): Generic Syntax", STD 66,
1217 RFC 3986, January 2005,
1218 .
1220 [TERMS] RFC Editor, "Terms List",
1221 .
1223 [YANG-SEC] IETF Ops Area, "yang module security considerations",
1224 .
1227 Appendix A. Related Procedures
1229 The following procedures are related to the application and updating
1230 of the RFC Style Guide.
1232 A.1. Dispute Resolution
1234 There are competing rationales for some of the rules described in
1235 this Guide, and the RFC Editor has selected the ones that work best
1236 for the Series. However, at times, an author may have a disagreement
1237 with the RFC Production Center (RPC) over the application of Style
1238 Guide conventions. In such cases, the authors should discuss their
1239 concerns with the RPC. If no agreement can be reached between the
1240 RPC and the authors, the RFC Series Editor will, with input from the
1241 appropriate stream-approving body, make a final determination. If
1242 further resolution is required, the dispute resolution process as
1243 described in the RFC Editor Model [RFC6635] will be followed.
1245 A.2. Returning an I-D to the Document Stream
1247 For a given document, if the RFC Editor determines that it cannot be
1248 edited without serious risk of altering the meaning of the technical
1249 content or if the RFC Editor does not have the resources to provide
1250 the level of editing it needs, it may be sent back to the stream-
1251 approving body with a request to improve the clarity, consistency,
1252 and/or readability of the document. This is not to be considered a
1253 dispute with the author.
1255 A.3. Revising This Document and Associated Web Pages
1257 The RFC Series is continually evolving as a document series. This
1258 document focuses on the fundamental and stable requirements that must
1259 be met by an RFC. From time to time, the RFC Editor may offer less
1260 formal recommendations that authors may apply at their discretion;
1261 these recommendations may be found on the RFC Editor website
1262 "Guidelines for RFC Style" [STYLE-WEB].
1264 When a new recommendation is made regarding the overall structure and
1265 formatting of RFCs, it will be published on that page and accepted
1266 for a period of time before the RFC Editor determines whether it
1267 should become part of the fundamental requirements in the RFC Style
1268 Guide or remain as a less formal recommendation. That period of time
1269 will vary, in part depending on the frequency with which authors
1270 encounter and apply the guidance.
1272 Appendix B. Acknowledgements
1274 Much of this document was written by Heather Flanagan during her term
1275 as RFC Editor.
1277 Authors' Addresses
1279 John Levine (editor)
1280 Temporary RFC Series Project Manager
1282 Email: standards@standcore.com
1283 URI: http://orcid.org/0000-0001-7553-5024
1285 Sandy Ginoza
1286 RFC Editor
1288 Email: rfc-editor@rfc-editor.org
1289 URI: https://www.rfc-editor.org