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