[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 7322) 00 01 02

Network Working Group                                        H. Flanagan
Internet-Draft                                                 S. Ginoza
Intended status: Informational                                RFC Editor
Expires: March 16, 2018                               September 12, 2017


                            RFC Style Guide
                       draft-flanagan-7322bis-02

Abstract

   This document describes the fundamental and unique style conventions
   and editorial policies currently in use for the RFC Series.  It
   captures the RFC Editor's basic requirements and offers guidance
   regarding the style and structure of an RFC.  Additional guidance is
   captured on a website that reflects the experimental nature of that
   guidance and prepares it for future inclusion in the RFC Style Guide.
   This document obsoletes RFC 7322, "RFC Style Guide".

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 16, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Flanagan & Ginoza        Expires March 16, 2018                 [Page 1]


Internet-Draft                  7322-bis                  September 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  RFC Editor's Philosophy . . . . . . . . . . . . . . . . . . .   3
   3.  RFC Style Conventions . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Language  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Punctuation . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  RFCs as Compounds . . . . . . . . . . . . . . . . . .   5
     3.3.  DNS Names and URIs  . . . . . . . . . . . . . . . . . . .   6
     3.4.  Capitalization  . . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Citations . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Abbreviation Rules  . . . . . . . . . . . . . . . . . . .   7
     3.7.  Images and Figures  . . . . . . . . . . . . . . . . . . .   8
   4.  Structure of an RFC . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  First-Page Header . . . . . . . . . . . . . . . . . . . .  10
       4.1.1.  Author/Editor . . . . . . . . . . . . . . . . . . . .  10
       4.1.2.  Organization  . . . . . . . . . . . . . . . . . . . .  11
       4.1.3.  ISSN: 2070-1721 . . . . . . . . . . . . . . . . . . .  11
       4.1.4.  Updates and Obsoletes . . . . . . . . . . . . . . . .  11
     4.2.  Document Title  . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Abstract Section  . . . . . . . . . . . . . . . . . . . .  12
     4.4.  RFC Editor or Stream Notes Section  . . . . . . . . . . .  12
     4.5.  Status of This Memo Section . . . . . . . . . . . . . . .  13
     4.6.  Copyright, Licenses, and IPR Boilerplate Section  . . . .  13
     4.7.  Table of Contents Section . . . . . . . . . . . . . . . .  13
     4.8.  Body of the Memo  . . . . . . . . . . . . . . . . . . . .  13
       4.8.1.  Introduction Section  . . . . . . . . . . . . . . . .  13
       4.8.2.  Requirements Language Section . . . . . . . . . . . .  14
       4.8.3.  IANA Considerations Section . . . . . . . . . . . . .  14
       4.8.4.  Internationalization Considerations Section . . . . .  15
       4.8.5.  Security Considerations Section . . . . . . . . . . .  15
       4.8.6.  References Section  . . . . . . . . . . . . . . . . .  15
     4.9.  Appendices Section  . . . . . . . . . . . . . . . . . . .  21
     4.10. Acknowledgements Section  . . . . . . . . . . . . . . . .  21
     4.11. Contributors Section  . . . . . . . . . . . . . . . . . .  21
     4.12. Index . . . . . . . . . . . . . . . . . . . . . . . . . .  21
     4.13. Author's Address or Authors' Addresses Section  . . . . .  21
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   7.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
     8.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Appendix A.  Related Procedures . . . . . . . . . . . . . . . . .  26



Flanagan & Ginoza        Expires March 16, 2018                 [Page 2]


Internet-Draft                  7322-bis                  September 2017


     A.1.  Dispute Resolution  . . . . . . . . . . . . . . . . . . .  26
     A.2.  Returning an I-D to the Document Stream . . . . . . . . .  26
     A.3.  Revising This Document and Associated Web Pages . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   The ultimate goal of the RFC publication process is to produce
   documents that are readable, clear, and consistent.  The basic
   formatting conventions for RFCs were established in the 1970s by the
   original RFC Editor, Jon Postel.  This document describes the
   fundamental and unique style conventions and editorial policies
   currently in use for the RFC Series [RFC4844] and is intended as a
   stable, infrequently updated reference for authors, editors, and
   reviewers.

   The RFC Editor also maintains a web portion of the Style Guide (see
   Appendix A.3) that describes issues as they are raised and indicates
   how the RFC Editor intends to address them.  As new style issues
   arise, the RFC Editor will first address them on the web portion of
   the Style Guide [STYLE-WEB].  These topics may become part of the RFC
   Style Guide when it is revised.

   The world of publishing has generally accepted rules for grammar,
   punctuation, capitalization, sentence length and complexity, etc.
   The RFC Editor generally follows these accepted rules as defined by
   the Chicago Manual of Style (CMOS) [CMOS], with a few important
   exceptions to avoid ambiguity in complex technical prose and to
   handle mixtures of text and computer languages, or to preserve
   historical formatting rules.  This document presents these exceptions
   as applied or recommended by the RFC Editor.

   All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a
   well-written and properly constructed Internet-Draft [ID-GUIDE]
   provides a strong basis for a good RFC.  The RFC Editor accepts
   Internet-Drafts from specified streams for publication [RFC4844] and
   applies the rules and guidelines for the RFC Series during the
   editorial process.

2.  RFC Editor's Philosophy

   Authors may find it helpful to understand the RFC Editor's goals
   during the publication process, namely to:

   o  Prepare the document according to RFC style and format.

   o  Make the document as clear, consistent, and readable as possible.




Flanagan & Ginoza        Expires March 16, 2018                 [Page 3]


Internet-Draft                  7322-bis                  September 2017


   o  Correct larger content/clarity issues; flag any unclear passages
      for author review.

   o  Fix inconsistencies (e.g., terms that appear in various forms,
      inconsistent capitalization, discrepancies between a figure and
      the text that describes it).

   We strive for consistency within:

   a. the document,

   b. a cluster of documents [CLUSTER], and

   c. the series of RFCs on the subject matter.

   The editorial process of the RFC Editor is not an additional
   technical review of the document.  Where the RFC Editor may suggest
   changes in wording for clarity and readability, it is up to the
   author, working group, or stream-approving body to determine whether
   the changes have an impact on the technical meaning of the document
   [RFC4844].  If the original wording is a more accurate representation
   of the technical content being described in the document, it takes
   precedence over editorial conventions.

   The activity of editing sometimes creates a tension between author
   and editor.  The RFC Editor attempts to minimize this conflict for
   RFC publication while continually striving to produce a uniformly
   excellent document series.  The RFC Editor refers to this fundamental
   tension as "editorial balance,"" and maintaining this balance is a
   continuing concern for the RFC Editor.  There is a prime directive
   that must rule over grammatical conventions: do not change the
   intended meaning of the text.

   If the RFC Editor cannot edit a document without serious risk of
   altering the meaning, it may be returned to the stream-approving body
   for review.  See Appendix A.2 for more information.

3.  RFC Style Conventions

   This Style Guide does not use terminology as defined in RFC 2119
   [BCP14].  In this document, lowercase use of "must" and "should"
   indicates changes the RFC Editor will make automatically to conform
   with this Style Guide versus those that may be questioned if not
   applied.  The lowercase "must" indicates those changes that will be
   applied automatically and are not at the discretion of the authors.
   The lowercase "should" indicates the RFC Editor's recommended use,
   but conformance with the recommendations is not required; the RFC
   Editor may question whether the guidance may be applied.



Flanagan & Ginoza        Expires March 16, 2018                 [Page 4]


Internet-Draft                  7322-bis                  September 2017


3.1.  Language

   The RFC publication language is English.  Spelling may be either
   American or British, as long as an individual document is internally
   consistent.  Where both American and British English spelling are
   used within a document or cluster of documents, the text will be
   modified to be consistent with American English spelling.

3.2.  Punctuation

   o  A comma is used before the last item of a series, e.g.,

      "TCP service is reliable, ordered, and full duplex"

   o  When quoting literal text, punctuation is placed outside quotation
      marks, e.g.,

      Search for the string "Error Found".

      When quoting general text, such as general text from another RFC,
      punctuation may be included within the quotation marks, e.g.,

      RFC 4844 indicates that "RFCs are available free of charge to
      anyone via the Internet. "

      Quotation marks are not necessary when text is formatted as a
      block quotation.

3.2.1.  RFCs as Compounds

   Whenever possible:

   o  Hyphenated compounds formed with RFC numbers should be avoided;
      this can be accomplished by: rewording the sentence (e.g.,
      [RFC5011]-style rollover -> rollover as described in RFC 5011).

   o  adding a note in either the Terminology or Conventions section
      mentioning the RFC so that other occurrences throughout the text
      will be understood by the reader to be in the style of said RFC
      (e.g., This document uses the term "rollover" as defined in RFC
      5011.).

   If use of an RFC number in attributive position is unavoidable, the
   preferred form should appear as in the example "RFC 5011-style
   rollover".  That is:

   o  no hyphen between "RFC" and the number (don't use RFC-5011-style
      rollover)



Flanagan & Ginoza        Expires March 16, 2018                 [Page 5]


Internet-Draft                  7322-bis                  September 2017


   o  avoid hyphenating citations with text (don't use [RFC5011]-style
      rollover)

3.3.  DNS Names and URIs

   DNS names, whether or not in URIs, that are used as generic examples
   in RFCs should use the particular examples defined in "Reserved Top
   Level DNS Names" [BCP32], to avoid accidental conflicts.

   Angle brackets are strongly recommended around URIs [STD66], e.g.,

   <https://example.com/ >

   The use of HTTPS rather than HTTP is strongly encouraged.

3.4.  Capitalization

   o  Capitalization must be consistent within the document and ideally
      should be consistent with related RFCs.  Refer to the online table
      of decisions on consistent usage of terms in RFCs [TERMS].

   o  Per CMOS guidelines, the major words in RFC titles and section
      titles should be capitalized (this is sometimes called "title
      case").  Typically, all words in a title will be capitalized,
      except for internal articles, prepositions, and conjunctions.

   o  Section titles that are in sentence form will follow typical
      sentence capitalization.

   o  Titles of figures may be in sentence form or use title case.

   o  Some terms related to the various roles or parts of the streams
      authoring RFCs should be used consistently.  For example, when the
      term 'working group' or 'research group' is used as part of a
      specific group name, it will be capitalized (e.g., kitten Working
      Group, Crypto Forum Research Group).  When used to generally refer
      to groups, it will be downcased.

3.5.  Citations

   o  References and citations must match.  That is, there must be a
      reference for each citation used, and vice versa.

   o  Citations must be enclosed in square brackets (e.g., "[CITE1]").

   o  Citations are restricted to ASCII-only characters.[RFC7997]





Flanagan & Ginoza        Expires March 16, 2018                 [Page 6]


Internet-Draft                  7322-bis                  September 2017


   o  Citations must begin with a number or a letter, and may contain
      digits, letters, colons, hyphens, underscores, or dots.

      *  Example: "[IEEE.802.15.4]" rather than "[.802.15.4]"

      *  Example: "[RFC2119]" rather than "[RFC 2119]"

   o  Citations may not include spaces, commas, quotation marks, or
      other punctuation (!, ?, etc.).

      *  Example: "See RFC 2119 [BCP14] for more information."

   o  Cross-references within the body of the memo and to other RFCs
      must use section numbers rather than page numbers, as pagination
      may change per format and device.

   o  An citation may a) follow the subject for which it is being cited
      or b) be read as part of the text.  For example:

      *  a) As part of the transition to IPv6, NAT64 [RFC6146] and DNS64
         [RFC6147] technologies will be utilized by some access networks
         to provide IPv4 connectivity for IPv6-only nodes [RFC6144].

   or

      b) Note that SAVI raises a number of important privacy
      considerations that are discussed more fully in [RFC6959].

   We recommend using a) and strongly recommend consistent use of one
   style throughout.

3.6.  Abbreviation Rules

   Abbreviations should be expanded in document titles and upon first
   use in the document.  The full expansion of the text should be
   followed by the abbreviation itself in parentheses.  The exception is
   an abbreviation that is so common that the readership of RFCs can be
   expected to recognize it immediately; examples include (but are not
   limited to) TCP, IP, SNMP, and HTTP.  The online list of
   abbreviations [ABBR] provides guidance.  Some cases are marginal, and
   the RFC Editor will make the final judgment, weighing obscurity
   against complexity.

   Note: The online list of abbreviations is not exhaustive or
   definitive.  It is a list of abbreviations appearing in RFCs and
   sometimes reflects discussions with authors, Working Group Chairs,
   and/or Area Directors (ADs).  Note that some abbreviations have
   multiple expansions.  Additionally, this list includes some terms



Flanagan & Ginoza        Expires March 16, 2018                 [Page 7]


Internet-Draft                  7322-bis                  September 2017


   that look like abbreviations but that are actually fixed names for
   things and hence cannot and should not be expanded.  These are noted
   as "No Expansion".

3.7.  Images and Figures

   The goal of having images within an RFC is to convey information.  A
   good diagram or image expresses information quickly, clearly, and
   with low chance of misunderstanding.  Technically correct but
   confusing images get in the way of understanding and implementation.

   o  Images should be legible when displayed on a standard screen
      (1920x1080) and printable on either A4 or US Letter paper.  Any
      text within the diagram should be readable at that resolution.

   o  Authors should use black on white, not white on black.  No color
      or greyscale [RFC7990][RFC7996]

   o  Keep your diagrams as simple as possible.  If an object in the
      diagram is not immediately relevant, leave it out.  If you have
      several ideas you want to convey, consider using more than one
      diagram.

   o  San-serif fonts are generally considered more readable for digital
      material. [citation needed]

   o  The style of diagrams within an RFC should be consistent both
      within a single RFC and within a cluster of RFCs (fonts, shapes,
      lines).  For example, if you you use a dashed line to indicate a
      certain type of packet flow, then continue to use that style of
      line consistently.

   o  Line styles, including thickness, color, and arrow types, are easy
      methods to convey a particular meaning to the reader.
      Consistently use the same line styles to convey a particular
      meaning throughout all diagrams within an RFC in order to avoid
      confusing the reader.

   o  Flowcharts: avoid crossing the lines if possible.

4.  Structure of an RFC

   A published RFC will largely contain the elements in the following
   list.  Some of these sections are required, as noted.  Those sections
   marked with "*" will be supplied by the RFC Editor during the
   editorial process when necessary.  The rules for each of these
   elements are described in more detail below.




Flanagan & Ginoza        Expires March 16, 2018                 [Page 8]


Internet-Draft                  7322-bis                  September 2017


      First-page header * [Required]

      Title [Required]

      Abstract [Required]

      RFC Editor or Stream Note * [Upon request]

      Status of This Memo * [Required]

      Copyright Notice * [Required]

      Table of Contents * [Required]

      Body of the Memo [Required]



         1.  Introduction [Required]

         2.  Requirements Language (RFC 2119)

         3.  ...

         MAIN BODY OF THE TEXT

         6.  ...

         7.  IANA Considerations [Required]

         8.  Internationalization Considerations

         9.  Security Considerations [Required]

         10.  References

         10.1.  Normative References

         10.2.  Informative References

         Appendix A.

         Appendix B.

      Acknowledgements

      Contributors




Flanagan & Ginoza        Expires March 16, 2018                 [Page 9]


Internet-Draft                  7322-bis                  September 2017


      Index

      Author's Address [Required]

   Within the body of the memo, the order shown above is strongly
   recommended.  Exceptions may be questioned.  Outside the body of the
   memo, the order above is required.  The section numbers above are for
   illustrative purposes; they are not intended to correspond to
   required numbering in an RFC.

   The elements preceding the body of the memo should not be numbered.
   Typically, the body of the memo will have numbered sections and the
   appendices will be labeled with letters.  Any sections that appear
   after the appendices should not be numbered or labeled (e.g., see
   "Contributors" above).

4.1.  First-Page Header

   Headers will follow the format described in "RFC Streams, Headers,
   and Boilerplates" [RFC7841] and its successors.  In addition, the
   following conventions will apply.

4.1.1.  Author/Editor

   The final determination of who should be listed as an author or
   editor on an RFC is made by the stream, as is whether or not
   including author affiliation is required.

   The author's name (initial followed by family name) appears on the
   first line of the heading.  Some variation, such as additional
   initials or capitalization of family name, is acceptable.  Once the
   author has selected how their name should appear, they should use
   that display consistently in all of their documents.

   The total number of authors or editors on the first page is generally
   limited to five individuals and their affiliations.  If there is a
   request for more than five authors, the stream-approving body needs
   to consider if one or two editors should have primary responsibility
   for this document, with the other individuals listed in the
   Contributors or Acknowledgements section.  There must be a direct
   correlation of authors and editors in the document header and the
   Authors' Addresses section.  These are the individuals that must sign
   off on the document during the AUTH48 process and respond to
   inquiries, such as errata.







Flanagan & Ginoza        Expires March 16, 2018                [Page 10]


Internet-Draft                  7322-bis                  September 2017


4.1.2.  Organization

   The author's organization is indicated on the line following the
   author's name.

   For multiple authors, each author name appears on its own line,
   followed by that author's organization.  When more than one author is
   affiliated with the same organization, the organization can be
   "factored out," appearing only once following the corresponding
   Author lines.  However, such factoring is inappropriate when it would
   force an unacceptable reordering of author names.

   If an author cannot or will not provide an affiliation for any
   reason, "Independent", "Individual Contributor", "Retired", or some
   other term that appropriately describes the author's affiliation may
   be used.  Alternatively, a blank line may be included in the document
   header when no affiliation is provided.

4.1.3.  ISSN: 2070-1721

   The RFC Series has been assigned an International Standard Serial
   Number of 2070-1721 [ISO3297].  It will be included by the RFC
   Editor.

4.1.4.  Updates and Obsoletes

   When an RFC obsoletes or updates a previously published RFC or RFCs,
   this information is included in the document header.  For example:

   "Updates: nnnn" or "Updates: nnnn, ..., nnnn"

   "Obsoletes: nnnn" or "Obsoletes: nnnn, ..., nnnn"

   If the document updates or obsoletes more than one document, numbers
   will be listed in ascending order.

4.2.  Document Title

   The title must be centered below the rest of the heading, preceded by
   two blank lines and followed by one blank line.

   Choosing a good title for an RFC can be a challenge.  A good title
   should fairly represent the scope and purpose of the document without
   being either too general or too specific and lengthy.

   Abbreviations in a title must generally be expanded when first
   encountered (see Section 3.6 for additional guidance on
   abbreviations).



Flanagan & Ginoza        Expires March 16, 2018                [Page 11]


Internet-Draft                  7322-bis                  September 2017


   It is often helpful to follow the expansion with the parenthesized
   abbreviation, as in the following example:

                     Encoding Rules for the
     Common Routing Encapsulation Extension Protocol (CREEP)

   The RFC Editor recommends that documents describing a particular
   company's private protocol should bear a title of the form "Foo's ...
   Protocol" (where Foo is a company name), to clearly differentiate it
   from a protocol of more general applicability.

4.3.  Abstract Section

   Every RFC must have an Abstract that provides a concise and
   comprehensive overview of the purpose and contents of the entire
   document, to give a technically knowledgeable reader a general
   overview of the function of the document and some context with
   regards to its relationship (in particular, whether it updates or
   obsoletes) any other RFCs.  In addition to its function in the RFC
   itself, the Abstract section text will appear in publication
   announcements and in the online index of RFCs.

   Composing a useful Abstract generally requires thought and care.
   Usually, an Abstract should begin with a phrase like "This memo ..."
   or "This document ..." A satisfactory Abstract can often be
   constructed in part from material within the Introduction section,
   but an effective Abstract may be shorter, less detailed, and perhaps
   broader in scope than the Introduction.  Simply copying and pasting
   the first few paragraphs of the Introduction is allowed, but it may
   result in an Abstract that is overly long, incomplete, and redundant.

   An Abstract is not a substitute for an Introduction; the RFC should
   be self-contained as if there were no Abstract.  Similarly, the
   Abstract should be complete in itself.  Given that the Abstract will
   appear independently in announcements and indices, mentions of other
   RFCs within the Abstract should include both an RFC number and either
   the full or short title.  Any documents that are Updated or Obsoleted
   by the RFC must be mentioned in the Abstract.  These may be presented
   in a list format if that improves readability.

4.4.  RFC Editor or Stream Notes Section

   A stream-approving body may approve the inclusion of an editorial
   note to explain anything unusual about the process that led to the
   document's publication or to note a correction.  In this case, a
   stream note section will contain such a note.





Flanagan & Ginoza        Expires March 16, 2018                [Page 12]


Internet-Draft                  7322-bis                  September 2017


   Additionally, an RFC Editor Note section may contain a note inserted
   by the RFC Editor to highlight special circumstances surrounding an
   RFC.

4.5.  Status of This Memo Section

   The RFC Editor will supply an appropriate "Status of This Memo" as
   defined in RFC [RFC7841] and "Format for RFCs in the IAB Stream"
   [IAB-FORM].

4.6.  Copyright, Licenses, and IPR Boilerplate Section

   The full copyright and license notices are available on the IETF
   Trust Legal Provisions documents website [IETF-TRUST].

4.7.  Table of Contents Section

   A Table of Contents (TOC) is required in all RFCs.  It must be
   positioned after the Copyright Notice and before the Introduction.

4.8.  Body of the Memo

   Following the TOC is the body of the memo.

   Each RFC must include an Introduction section that (among other
   things) explains the motivation for the RFC and (if appropriate)
   describes the applicability of the document, e.g., whether it
   specifies a protocol, provides a discussion of some problem, is
   simply of interest to the Internet community, or provides a status
   report on some activity.  The body of the memo and the Abstract must
   be self-contained and separable.  This may result in some duplication
   of text between the Abstract and the Introduction; this is
   acceptable.

4.8.1.  Introduction Section

   The Introduction section should always be the first section following
   the TOC (except in the case of MIB module documents).  While
   "Introduction" is recommended, authors may choose alternate titles
   such as "Overview" or "Background".  These alternates are acceptable.

   For MIB module documents, common practice has been for "The Internet-
   Standard Management Framework" [MIB-BOILER] text to appear as
   Section 1.







Flanagan & Ginoza        Expires March 16, 2018                [Page 13]


Internet-Draft                  7322-bis                  September 2017


4.8.2.  Requirements Language Section

   Some documents use certain capitalized words ("MUST", "SHOULD", etc.)
   to specify precise requirement levels for technical features.  RFC
   2119 [BCP14] defines a default interpretation of these capitalized
   words in IETF documents.  If this interpretation is used, RFC 2119
   must be cited (as specified in RFC 2119) and included as a normative
   reference.  Otherwise, the correct interpretation must be specified
   in the document.

   This section must appear as part of the body of the memo (as defined
   by this document).  It must appear as part of, or subsequent to, the
   Introduction section.

   These words are considered part of the technical content of the
   document and are intended to provide guidance to implementers about
   specific technical features, generally governed by considerations of
   interoperability.  RFC 2119 says:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions) For
   example, they must not be used to try to impose a particular method
   on implementers where the method is not required for
   interoperability.

4.8.3.  IANA Considerations Section

   For guidance on how to register IANA-related values or create new
   registries to be managed by IANA, see "Guidelines for Writing an IANA
   Considerations Section in RFCs" [BCP26].

   The RFC Editor will update text accordingly after the IANA
   assignments have been made.  It is helpful for authors to clearly
   identify where text should be updated to reflect the newly assigned
   values.  For example, the use of "TBD1", "TBD2", etc., is recommended
   in the IANA Considerations section and in the body of the memo.

   If the authors have provided values to be assigned by IANA, the RFC
   Editor will verify that the values inserted by the authors match
   those that have actually been registered on the IANA site.  When
   writing a given value, consistent use of decimal or hexadecimal is
   recommended.

   If any of the IANA-related information is not clear, the RFC Editor
   will work with IANA to send queries to the authors to ensure that
   assignments and values are properly inserted.



Flanagan & Ginoza        Expires March 16, 2018                [Page 14]


Internet-Draft                  7322-bis                  September 2017


4.8.4.  Internationalization Considerations Section

   All RFCs that deal with internationalization issues should have a
   section describing those issues; see "IETF Policy on Character Sets
   and Languages" [BCP18], Section 6, for more information.

4.8.5.  Security Considerations Section

   All RFCs must contain a section that discusses the security
   considerations relevant to the specification; see "Guidelines for
   Writing RFC Text on Security Considerations" [BCP72] for more
   information.

   Note that additional boilerplate material for RFCs containing MIB and
   YANG modules also exists.  See "Security Guidelines for IETF MIB
   Modules" [MIB-SEC] and "yang module security considerations"
   [YANG-SEC] for details.

4.8.6.  References Section

   The reference list is solely for recording reference entries.
   Introductory text is not allowed.

   The RFC style allows the use of any of a variety of reference styles,
   as long as they are used consistently within a document.  However,
   where necessary, some reference styles have been described for use
   within the Series.  See the examples in this document.

   The RFC Editor ensures that references to other RFCs refer to the
   most current RFC available on that topic (unless provided with a
   reason not to do so).  When referring to an obsoleted document, it is
   common practice to also refer to the most recent version.

   A reference to an RFC that has been assigned an STD [RFC1311], BCP
   [RFC1818], or FYI [FYI90] sub-series number must include the sub-
   series number of the document.  Note that the FYI series was ended by
   RFC 6360.  RFCs that were published with an FYI sub-series number and
   still maintain the FYI number must include the sub-series number in
   the reference.

   Reference lists must indicate whether each reference is normative or
   informative, where normative references are essential to implementing
   or understanding the content of the RFC and informative references
   provide additional information.  More information about normative and
   informative references may be found in the IESG's statement
   "Normative and Informative References" [REFS].  When both normative
   and informative references exist, the references section should be
   split into two subsections:



Flanagan & Ginoza        Expires March 16, 2018                [Page 15]


Internet-Draft                  7322-bis                  September 2017


   Templates are available on the RFC Editor website for the XML format
   of certain references [REFEXAMPLE].

   s.  References

   s.1.  Normative References

           xxx
           ...
           xxx

   s.2.  Informative References

           xxx
           ...
           xxx

   References will generally appear in alphanumeric order by citation
   tag.  Where there are only normative or informative references, no
   subsection is required; the top-level section should say "Normative
   References" or "Informative References".

   Normative references to Internet-Drafts will cause publication of the
   RFC to be suspended until the referenced draft is also ready for
   publication; the RFC Editor will then update the entry to refer to
   the RFC and publish both documents simultaneously.

4.8.6.1.  URIs in RFCs

   The use of URIs in references is acceptable, as long as the URI is
   the most stable (i.e., unlikely to change and expected to be
   continuously available) and direct reference possible.  The URI will
   be verified as valid during the RFC editorial process.

   If a dated URI (one that includes a timestamp for the page) is
   available for a referenced web page, its use is required.

   Note that URIs may not be the sole information provided for a
   reference entry.

   The use of HTTPS rather than HTTP is strongly encouraged.

4.8.6.2.  Referencing RFCs

   The following format is required for referencing RFCs.  The Stream
   abbreviation should be used; when no stream is available, as with
   legacy RFCs, this may be left blank.




Flanagan & Ginoza        Expires March 16, 2018                [Page 16]


Internet-Draft                  7322-bis                  September 2017


   Note the ordering for multiple authors: the format of the name of the
   last author listed is different than that of all previous authors in
   the list.

   For one author or editor:

   [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC
   Title", Stream, Sub-series number (if applicable), RFC number, DOI,
   Date of publication, https://www.rfc-editor.org/info/rfc# [1].

   Example:

   [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core,"
   IETF, RFC 3080, DOI 10.17487/RFC3080, March 2001, https://www.rfc-
   editor.org/info/rfc3080 [2].

   [RFC8157] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M.
   Cullen, "Huawei's GRE Tunnel Bonding Protocol", independent, RFC
   8157, DOI 10.17487/RFC8157, May 2017, https://www.rfc-
   editor.org/info/rfc8157 [3].

   For two authors or editors:

   [RFCXXXX] Last name, First initial., Ed. (if applicable) and First
   initial.  Last name, Ed. (if applicable), "RFC Title", Stream, Sub-
   series number (if applicable), RFC number, DOI, Date of publication,
   https://www.rfc-editor.org/info/rfc# [4].

   Example:

   [RFC6323] Renker, G. and G.  Fairhurst, "Sender RTT Estimate Option
   for the Datagram Congestion Control Protocol (DCCP)", IETF, RFC 6323,
   DOI 10.17487/RFC6323, July 2011, https://www.rfc-editor.org/info/
   rfc6323 [5].

   For three or more authors or editors:

   [RFCXXXX] Last name, First initial., Ed. (if applicable), Last name,
   First initial., Ed. (if applicable), and First initial.  Last name,
   Ed. (if applicable), "RFC Title", Stream, Sub-series number (if
   applicable), RFC number, DOI, Date of publication, https://www.rfc-
   editor.org/info/rfc# [6].

   Example:

   [RFC6429] Bashyam, M., Jethanandani, M., and A.  Ramaiah, "TCP Sender
   Clarification for Persist Condition", IETF, RFC 6429, DOI 10.17487/
   RFC6429, December 2011, https://www.rfc-editor.org/info/rfc6429 [7].



Flanagan & Ginoza        Expires March 16, 2018                [Page 17]


Internet-Draft                  7322-bis                  September 2017


4.8.6.3.  Referencing STDs and BCPs

   Internet Standards (STDs) and Best Current Practices (BCPs) may
   consist of a single RFC or multiple RFCs.  When an STD or BCP that
   contains multiple RFCs is referenced, the reference entry should
   include ALL of the RFCs comprising that sub-series.  The authors
   should refer to specific RFC numbers as part of the text (not as
   citations) and cite the sub-series number.  Inclusion of the URI to
   the STD or BCP info page is recommended.  The text should appear as
   follows:

   See RFC 1034 [STD13].

   For an STD or BCP that contains one RFC:

   [STDXXX]  Last name, First initial., Ed. (if applicable), "RFC
   Title", Stream, Sub-series number, RFC number, DOI, Date of
   publication, https://www.rfc-editor.org/info/std# [8].

   Example:

   [STD72]  Gellens, R. and J.  Klensin, "Message Submission for Mail",
   IETF, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
   https://www.rfc-editor.org/info/std72 [9].

   For an STD or BCP that contains two or more RFCs:

   [STDXXX]  Last name, First initial., Ed. (if applicable), "RFC
   Title", Stream, Sub-series number, RFC number, DOI, Date of
   publication.

            Last name, First initial., Ed. (if applicable)
            and First initial. Last name, Ed. (if applicable),
            "RFC Title", Stream, Sub-series number, RFC number, DOI,
            Date of publication.

            <https://www.rfc-editor.org/info/std#>

   Example:

   [STD13]  Mockapetris, P., "Domain names - concepts and facilities",
   IETF, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.

     Mockapetris, P., "Domain names - implementation and
     specification", IETF, STD 13, RFC 1035, DOI 10.17487/RFC1035,
     November 1987.

            <https://www.rfc-editor.org/info/std13>



Flanagan & Ginoza        Expires March 16, 2018                [Page 18]


Internet-Draft                  7322-bis                  September 2017


4.8.6.4.  Referencing Internet-Drafts

   References to Internet-Drafts may only appear as informative
   references.  Given that several revisions of an I-D may be produced
   in a short time frame, references must include the posting date
   (month and year), the full Internet-Draft file name (including the
   version number), and the phrase "Work in Progress".  Authors may
   reference multiple versions of an I-D.  If the referenced I-D was
   also later published as an RFC, then that RFC must also be listed.

   [SYMBOLIC-TAG]  Last name, First initial., Ed. (if applicable) and
   First initial.  Last name, Ed. (if applicable), "I-D Title", Work in
   Progress, draft-string-NN, Month Year.

   Example:

   [RFC-STYLE] Flanagan, H. and S.  Ginoza, "RFC Style Guide", Work in
   Progress, draft-flanagan-style-01, June 2013.

4.8.6.5.  Referencing Errata

   The following format is required when a reference to an erratum
   report is necessary:

   [ErrNumber]  RFC Errata, Erratum ID number, RFC number,
   <https://www.rfc-editor.org/errata/eid#>.

   [Err1912]  RFC Errata, Erratum ID 1912, RFC 2978, <https://www.rfc-
   editor.org/errata/eid1912 >.

4.8.6.6.  Referencing Other Standards Development Organizations (SDOs)

   The following format is suggested when referencing a document or
   standard from another SDO in which authors are listed:

   [SYMBOLIC-TAG]

      Last name, First initial. and First initial.  Last name,

      "Document Title", Document reference number, Date of

      publication, <URI if available >.

   [W3C.REC-xml11]

      Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,

      Yergeau, F., and J.  Cowan, "Extensible Markup Language



Flanagan & Ginoza        Expires March 16, 2018                [Page 19]


Internet-Draft                  7322-bis                  September 2017


      (XML) 1.1 (Second Edition)", W3C Recommendation

      REC-xml11-20060816, August 2006,

      <https://www.w3.org/TR/2006/REC-xml11-20060816 >.

   The order of authors in the list is the same as the order shown on
   the actual document and that the common, abbreviated form of the SDO
   is used.

   Alternatively, when no list of authors is available, the following
   format is recommended:

   [SYMBOLIC-TAG]  Organization, "Document Title", Document
                      reference number, Date of publication,
                      <URI if available>.

   Example (undated; see note below):

   [IEEE.802.15.4]
              IEEE, "IEEE Standard for Low-Rate Wireless Networks",
              IEEE 802.15.4,
              <https://ieeexplore.ieee.org/document/7460875/>.

   Example (dated; see note below):

   [IEEE802.1Q]  IEEE, "Local and Metropolitan Area
                    Networks -- Media Access Control (MAC)
                    Bridges and Virtual Bridged Local Area
                    Networks", IEEE Std 802.1Q-2011, August 2011,
                    <https://standards.ieee.org/findstds/standard/
                    802.1Q-2011.html>

   Per the IEEE coordination team, listing dates for IEEE standards is
   not recommended unless there is a need to cite a particular section,
   in which case the dated reference is appropriate.  An RFC with a
   dated IEEE reference suggests that the RFC only applies to that
   specific IEEE specification.

4.8.6.7.  Referencing Email on Mailing Lists

   When referencing emails to mailing lists, the template provided here
   should be used:

      [reftag] Sender, A., "Subject: Subject line", message to the

      listname mailing list, DD Month YYYY, <URL >.




Flanagan & Ginoza        Expires March 16, 2018                [Page 20]


Internet-Draft                  7322-bis                  September 2017


4.9.  Appendices Section

   The RFC Editor recommends placing references before the Appendices.
   Appendices should be labeled as "Appendix A.  Title", "A.1.  Title",
   "Appendix B.  Title", etc.

4.10.  Acknowledgements Section

   This optional section may be used instead of, or in addition to, a
   Contributors section.  It is often used by authors to publicly thank
   those who have provided feedback regarding a document and to note any
   documents from which text was borrowed.

4.11.  Contributors Section

   This optional section acknowledges those who have made significant
   contributions to the document.

   In a similar fashion to the Author's Address section, the RFC Editor
   does not make the determination as to who should be listed as a
   contributor to an RFC.  The determination of who should be listed as
   a contributor is made by the stream.

   The Contributors section may include brief statements about the
   nature of particular contributions (e.g., "Sam contributed
   Section 3"), and it may also include affiliations of listed
   contributors.  At the discretion of the author(s), contact addresses
   may also be included in the Contributors section, for those
   contributors whose knowledge makes them useful future contacts for
   information about the RFC.  The format of any contact information
   should be similar to the format of information in the Author's
   Address section.

4.12.  Index

   If included, an index appears at the end of the document, immediately
   before Author's Address section.

4.13.  Author's Address or Authors' Addresses Section

   This required section gives contact information for the author(s)
   listed in the first-page header.

   Contact information must include a long-lived email address and
   optionally may include a postal address and/or telephone number.  If
   the postal address is included, it should include the country name,
   using the English short name listed by the ISO 3166 Maintenance
   Agency [ISO_OBP].  The purpose of this section is to (1)



Flanagan & Ginoza        Expires March 16, 2018                [Page 21]


Internet-Draft                  7322-bis                  September 2017


   unambiguously define author identity (e.g., the John Smith who works
   for FooBar Systems) and (2) provide contact information for future
   readers who have questions or comments.

   The practice of munged email addresses (i.e., altering an email
   address to make it less readable to bots and web crawlers to avoid
   spam) is not appropriate in an archival document series.  Author
   contact information is provided so that readers can easily contact
   the author with questions and/or comments.  Address munging is not
   allowed in RFCs.

5.  Security Considerations

   This document has no security considerations.

6.  IANA Considerations

   This document has no IANA considerations.

7.  Change Log

   This section to be removed before publication.

      -00 to -01: Citation tag requirements more tightly specified;
      index moved; new errata URI added; capitalization of working/
      research group specified; update Abstract guidance

8.  References

8.1.  Normative References

   [STYLE-WEB]
              RFC Editor, "Web Portion of the Style Guide",
              <https://www.rfc-editor.org/rfc-style-guide/part2.html>.

8.2.  Informative References

   [ABBR]     RFC Editor, "RFC Editor Abbreviations List",
              <https://www.rfc-editor.org/rfc-style-guide/
              abbrev.expansion.txt>.

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/bcp14>.

   [BCP18]    Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, January 1998,
              <https://www.rfc-editor.org/info/bcp18>.



Flanagan & Ginoza        Expires March 16, 2018                [Page 22]


Internet-Draft                  7322-bis                  September 2017


   [BCP26]    Alvestrand, H. and T. Narten, "Guidelines for Writing an
              ANA Considerations Section in RFCs", BCP 26, RFC 5226, May
              2008, <https://www.rfc-editor.org/info/bcp26>.

   [BCP32]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999,
              <https://www.rfc-editor.org/info/bcp32>.

   [BCP72]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, July
              2003, <https://www.rfc-editor.org/info/bcp72>.

   [CLUSTER]  RFC Editor, "Clusters in the RFC Editor Queue",
              <https://www.rfc-editor.org/cluster_def.html>.

   [CMOS]     University of Chicago Press, 2010, "Chicago Manual of
              Style, 16th ed.", 2010.

   [FYI90]    Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to
              the FYI Notes", FYI 90, RFC 1150, March 1990,
              <https://www.rfc-editor.org/info/fyi90>.

              Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,
              August 2011.

   [IAB-FORM]
              IAB, "Format for RFCs in the IAB Stream",
              <https://www.rfc-editor.org/rfc-style-guide/
              iab-format.txt>.

   [ID-GUIDE]
              IETF, "Guidelines to Authors of Internet Drafts",
              <https://www.ietf.org/ietf-ftp/1id-guidelines.txt>.

   [IETF-TRUST]
              IETF Trust, "Trust Legal Provisions (TLP)",
              <https://trustee.ietf.org/license-info/>.

   [ISO3297]  Technical Committee ISO/TC 46, Information and
              documentation, Subcommittee SC 9, "Identification and
              description, Information and documentation - International
              standard serial number (ISSN)", September 2007.

   [ISO_OBP]  ISO, "Online Browsing Platform (OBP)",
              <https://www.iso.org/obp/ui/>.






Flanagan & Ginoza        Expires March 16, 2018                [Page 23]


Internet-Draft                  7322-bis                  September 2017


   [MIB-BOILER]
              IETF OPS Area, "Boilerplate for IETF MIB Documents",
              <https://www.ops.ietf.org/mib-boilerplate.html>.

   [MIB-SEC]  IETF OPS Area, "Security Guidelines for IETF MIB Modules",
              <https://trac.tools.ietf.org/area/ops/trac/wiki/
              mib-security>.

   [REFEXAMPLE]
              RFC Editor, "Reference Examples",
              <https://www.rfc-editor.org/ref-example/>.

   [REFS]     IESG, "IESG Statement: Normative and Informative",
              <https://www.ietf.org/iesg/statement/
              normative-informative.html>.

   [RFC1311]  Postel, J., "Introduction to the STD Notes", RFC 1311,
              DOI 10.17487/RFC1311, March 1992,
              <https://www.rfc-editor.org/info/rfc1311>.

   [RFC1818]  Postel, J., Li, T., and Y. Rekhter, "Best Current
              Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995,
              <https://www.rfc-editor.org/info/rfc1818>.

   [RFC4844]  Daigle, L., Ed. and Internet Architecture Board, "The RFC
              Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
              July 2007, <https://www.rfc-editor.org/info/rfc4844>.

   [RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
              Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
              2012, <https://www.rfc-editor.org/info/rfc6635>.

   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
              "RFC Streams, Headers, and Boilerplates", RFC 7841,
              DOI 10.17487/RFC7841, May 2016,
              <https://www.rfc-editor.org/info/rfc7841>.

   [RFC7990]  Flanagan, H., "RFC Format Framework", RFC 7990,
              DOI 10.17487/RFC7990, December 2016,
              <https://www.rfc-editor.org/info/rfc7990>.

   [RFC7996]  Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
              RFC 7996, DOI 10.17487/RFC7996, December 2016,
              <https://www.rfc-editor.org/info/rfc7996>.

   [RFC7997]  Flanagan, H., Ed., "The Use of Non-ASCII Characters in
              RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
              <https://www.rfc-editor.org/info/rfc7997>.



Flanagan & Ginoza        Expires March 16, 2018                [Page 24]


Internet-Draft                  7322-bis                  September 2017


   [STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005,
              <https://www.rfc-editor.org/info/std66>.

   [TERMS]    RFC Editor, "Terms List",
              <https://www.rfc-editor.org/styleguide.html>.

   [YANG-SEC]
              IETF Ops Area, "yang module security considerations",
              <https://trac.tools.ietf.org/area/ops/trac/wiki/
              yang-security-guidelines>.

8.3.  URIs

   [1] https://www.rfc-editor.org/info/rfc#

   [2] https://www.rfc-editor.org/info/rfc3080

   [3] https://www.rfc-editor.org/info/rfc8157

   [4] https://www.rfc-editor.org/info/rfc#

   [5] https://www.rfc-editor.org/info/rfc6323

   [6] https://www.rfc-editor.org/info/rfc#

   [7] https://www.rfc-editor.org/info/rfc6429

   [8] https://www.rfc-editor.org/info/std#

   [9] https://www.rfc-editor.org/info/std72



















Flanagan & Ginoza        Expires March 16, 2018                [Page 25]


Internet-Draft                  7322-bis                  September 2017


Appendix A.  Related Procedures

   The following procedures are related to the application and updating
   of the RFC Style Guide.

A.1.  Dispute Resolution

   There are competing rationales for some of the rules described in
   this Guide, and the RFC Editor has selected the ones that work best
   for the Series.  However, at times, an author may have a disagreement
   with the RFC Production Center (RPC) over the application of Style
   Guide conventions.  In such cases, the authors should discuss their
   concerns with the RPC.  If no agreement can be reached between the
   RPC and the authors, the RFC Series Editor will, with input from the
   appropriate stream-approving body, make a final determination.  If
   further resolution is required, the dispute resolution process as
   described in the RFC Editor Model [RFC6635] will be followed.

A.2.  Returning an I-D to the Document Stream

   For a given document, if the RFC Editor determines that it cannot be
   edited without serious risk of altering the meaning of the technical
   content or if the RFC Editor does not have the resources to provide
   the level of editing it needs, it may be sent back to the stream-
   approving body with a request to improve the clarity, consistency,
   and/or readability of the document.  This is not to be considered a
   dispute with the author.

A.3.  Revising This Document and Associated Web Pages

   The RFC Series is continually evolving as a document series.  This
   document focuses on the fundamental and stable requirements that must
   be met by an RFC.  From time to time, the RFC Editor may offer less
   formal recommendations that authors may apply at their discretion;
   these recommendations may be found on the RFC Editor website
   "Guidelines for RFC Style" [STYLE-WEB].

   When a new recommendation is made regarding the overall structure and
   formatting of RFCs, it will be published on that page and accepted
   for a period of time before the RFC Editor determines whether it
   should become part of the fundamental requirements in the RFC Style
   Guide or remain as a less formal recommendation.  That period of time
   will vary, in part depending on the frequency with which authors
   encounter and apply the guidance.







Flanagan & Ginoza        Expires March 16, 2018                [Page 26]


Internet-Draft                  7322-bis                  September 2017


Authors' Addresses

   Heather Flanagan
   RFC Editor

   EMail: rse@rfc-editor.org
   URI:   https://orcid.org/0000-0002-2647-2220


   Sandy Ginoza
   RFC Editor

   EMail: rfc-editor@rfc-editor.org
   URI:   https://www.rfc-editor.org





































Flanagan & Ginoza        Expires March 16, 2018                [Page 27]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/