doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7841.txt b/doc/rfc/rfc7841.txt
new file mode 100644
index 0000000..7b1959d
--- /dev/null
+++ b/doc/rfc/rfc7841.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                        J. Halpern, Ed.
+Request for Comments: 7841                                L. Daigle, Ed.
+Obsoletes: 5741                                          O. Kolkman, Ed.
+Category: Informational                                         May 2016
+ISSN: 2070-1721
+
+
+                 RFC Streams, Headers, and Boilerplates
+
+Abstract
+
+   RFC documents contain a number of fixed elements such as the title
+   page header, standard boilerplates, and copyright/IPR statements.
+   This document describes them and introduces some updates to reflect
+   current usage and requirements of RFC publication.  In particular,
+   this updated structure is intended to communicate clearly the source
+   of RFC creation and review.  This document obsoletes RFC 5741, moving
+   detailed content to an IAB web page and preparing for more flexible
+   output formats.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7841.
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   (http://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.
+
+
+
+
+Halpern, et al.               Informational                     [Page 1]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  RFC Streams and Internet Standards  . . . . . . . . . . . . .   3
+   3.  RFC Structural Elements . . . . . . . . . . . . . . . . . . .   3
+     3.1.  The Title Page Header . . . . . . . . . . . . . . . . . .   4
+     3.2.  The Status of This Memo . . . . . . . . . . . . . . . . .   5
+     3.3.  Paragraph 1 . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.4.  Paragraph 2 . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.5.  Paragraph 3 . . . . . . . . . . . . . . . . . . . . . . .   6
+     3.6.  Noteworthy  . . . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Additional Notes  . . . . . . . . . . . . . . . . . . . . . .   6
+   5.  Other Structural Information in RFCs  . . . . . . . . . . . .   6
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   7.  RFC Editor Considerations . . . . . . . . . . . . . . . . . .   7
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+   Appendix A.  Initial Formatting Details . . . . . . . . . . . . .  10
+     A.1.  RFC Title Page Header . . . . . . . . . . . . . . . . . .  10
+     A.2.  Constructing a "Status of This Memo" Section  . . . . . .  10
+       A.2.1.  First Paragraph . . . . . . . . . . . . . . . . . . .  11
+       A.2.2.  Second Paragraph  . . . . . . . . . . . . . . . . . .  11
+       A.2.3.  Third Paragraph . . . . . . . . . . . . . . . . . . .  13
+   IAB Members at Time of Approval . . . . . . . . . . . . . . . . .  13
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14
+
+1.  Introduction
+
+   Previously, RFCs (e.g., [RFC4844]) contained a number of elements
+   that were there for historical, practical, and legal reasons.  They
+   also contained boilerplate material to clearly indicate the status of
+   the document and possibly contained "Notes" to indicate how the
+   document interacts with IETF Standards-Track documents.
+
+   As the RFC Series has evolved over the years, there has been
+   increasing concern over appropriate labeling of the publications to
+   make clear the status of each RFC and the status of the work it
+   describes.  Chiefly, there is a requirement that RFCs published as
+   part of the IETF's review process not be easily confused with RFCs
+   that may have had a very different review and approval process.
+   Various adjustments have been made over the years, including evolving
+   text of "Notes" included in the published RFC.
+
+   With the definition of the different RFC streams [RFC4844], it is
+   appropriate to formalize the definition of the various pieces of
+   standard RFC boilerplate and introduce some adjustments to ensure
+
+
+
+Halpern, et al.               Informational                     [Page 2]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   better clarity of expression of document status, aligned with the
+   review and approval processes defined for each stream.
+
+   This memo identifies and describes the common elements of RFC
+   boilerplate structure.  It describes the content required for each
+   kind of information.  Details of the exact textual and layout
+   requirements are left to a web page maintained by the IAB, with due
+   consultation with the community, for ease of maintenance.  This
+   document obsoletes [RFC5741].
+
+   The changes introduced by this memo should be implemented as soon as
+   practically possible after the document has been approved for
+   publication.
+
+2.  RFC Streams and Internet Standards
+
+   Users of RFCs should be aware that while all Internet Standards-
+   related documents are published as RFCs, not all RFCs are Internet
+   Standards-related documents.
+
+   The IETF is responsible for maintaining the Internet Standards
+   Process, which includes the requirements for developing, reviewing,
+   and approving Standards Track and BCP RFCs.  The IETF also produces
+   non-Standards-Track documents (Informational, Experimental, and
+   Historic).  All documents published as part of the IETF Stream are
+   reviewed by the appropriate IETF bodies.
+
+   Documents published in streams other than the IETF stream are not
+   generally reviewed by the IETF for such things as security,
+   congestion control, or inappropriate interaction with deployed
+   protocols.  They have also not been subject to approval by the
+   Internet Engineering Steering Group (IESG), including an IETF-wide
+   last call.  Therefore, the IETF disclaims, for any of the non-IETF
+   stream documents, any knowledge of the fitness of those RFCs for any
+   purpose.
+
+   Refer to [RFC2026], [RFC5742], [RFC4844], [RFC6410], and [RFC7127]
+   and their successors for current details of the IETF process and RFC
+   streams.
+
+3.  RFC Structural Elements
+
+   This section describes the elements that are commonly found in RFCs
+   published today.  This document specifies information that is
+   required in these publications.  Exact specification of the textual
+   values required therein are provided by an IAB web page
+   (https://www.iab.org/documents/headers-boilerplate).
+
+
+
+
+Halpern, et al.               Informational                     [Page 3]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   As noted above, this web page is maintained by the IAB with due
+   consultation with the community.  Following such consultation, if the
+   IAB decides to make any changes to this material, the changes will be
+   announced in a similar fashion to other IAB statements.  The initial
+   text to be used in that web page is included in Appendix A.
+
+3.1.  The Title Page Header
+
+   The information at the front of the RFC includes the name and
+   affiliation of the authors as well as the RFC publication month and
+   year.
+
+   There is a set of additional information that is needed at the front
+   of the RFC.  Historically, this has been presented with the
+   information below in a left hand column, and the author-related
+   information described above in the right.
+
+   <document source>  This describes the area where the work originates.
+      Historically, all RFCs were labeled "Network Working Group".
+      Network Working Group refers to the original version of today's
+      IETF when people from the original set of ARPANET sites and
+      whomever else was interested -- the meetings were open -- got
+      together to discuss, design, and document proposed protocols
+      [RFC3].  Here, we obsolete the term "Network Working Group" in
+      order to indicate the originating stream.
+
+      The <document source> is the name of the RFC stream, as defined in
+      [RFC4844] and its successors.  At the time of this publication,
+      the streams, and therefore the possible entries are:
+
+      *  Internet Engineering Task Force
+      *  Internet Architecture Board
+      *  Internet Research Task Force
+      *  Independent Submission
+
+   Request for Comments:  <RFC number>  This indicates the RFC number,
+      assigned by the RFC Editor upon publication of the document.  This
+      element is unchanged.
+
+   <subseries ID> <subseries number>  Some document categories are also
+      labeled as a subseries of RFCs.  These elements appear as
+      appropriate for such categories, indicating the subseries and the
+      documents number within that series.  Currently, there are
+      subseries for BCPs [RFC2026] and STDs [RFC1311].  These subseries
+      numbers may appear in several RFCs.  For example, when a new RFC
+      obsoletes or updates an old one, the same subseries number is
+      used.  Also, several RFCs may be assigned the same subseries
+      number: a single STD, for example, may be composed of several
+
+
+
+Halpern, et al.               Informational                     [Page 4]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+      RFCs, each of which will bear the same STD number.  This element
+      is unchanged.
+
+   [<RFC relation>:<RFC number[s]>]  Some relations between RFCs in the
+      series are explicitly noted in the RFC header.  For example, a new
+      RFC may update one or more earlier RFCs.  Currently two
+      relationships are defined: "Updates" and "Obsoletes" [RFC7322].
+      Variants like "Obsoleted by" are also used (e.g, in [RFC5143]).
+      Other types of relationships may be defined by the RFC Editor and
+      may appear in future RFCs.
+
+   Category: <category>  This indicates the initial RFC document
+      category of the publication.  These are defined in [RFC2026].
+      Currently, this is always one of: Standards Track, Best Current
+      Practice, Experimental, Informational, or Historic.  This element
+      is unchanged.
+
+3.2.  The Status of This Memo
+
+   The "Status of This Memo" describes the category of the RFC,
+   including the distribution statement.
+
+   The "Status of This Memo" will start with a single sentence
+   describing the status.  It will also include a statement describing
+   the stream-specific review of the material (which is stream
+   dependent).  This is an important component of status, insofar as it
+   clarifies the breadth and depth of review, and gives the reader an
+   understanding of how to consider its content.
+
+3.3.  Paragraph 1
+
+   The first paragraph of the "Status of This Memo" section contains a
+   single sentence, clearly standing out.  The sentence will clearly
+   identify the stream-specific status of the document.  The text to be
+   used is defined by the stream, with a review for clarity by the IAB
+   and RFC Series Editor.
+
+3.4.  Paragraph 2
+
+   The second paragraph of the "Status of This Memo" will include a
+   paragraph describing the type of review and exposure the document has
+   received.  This is defined on a per-stream basis, subject to general
+   review and oversight by the RFC Editor and IAB.  The IAB defines a
+   specific structure defined to ensure there is clarity about review
+   processes and document types.
+
+
+
+
+
+
+Halpern, et al.               Informational                     [Page 5]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+3.5.  Paragraph 3
+
+   The boilerplate ends with a reference to where further relevant
+   information can be found.  This information may include, subject to
+   the RFC Editor's discretion, information about whether the RFC has
+   been updated or obsoleted, the RFC's origin, a listing of possible
+   errata, information about how to provide feedback and suggestion, and
+   information on how to submit errata as described in [ERRATA].  The
+   exact wording and URL is subject to change (at the RFC Editor's
+   discretion), but the current text is:
+
+      Information about the current status of this document, any errata,
+      and how to provide feedback on it may be obtained at
+      http://www.rfc-editor.org/<static-path>/rfc<rfc-no>.
+
+3.6.  Noteworthy
+
+   Note that the text in paragraph 1 and 2 of the boilerplate indicate
+   the initial status of a document.  During their lifetime, documents
+   can change status to, for example, Historic.  This cannot be
+   reflected in the document itself and will need be reflected in the
+   information referred to in Section 5.
+
+4.  Additional Notes
+
+   Exceptionally, a review and publication process may prescribe
+   additional notes that will appear as labeled notes after the
+   "Abstract".
+
+   This is no longer a common feature of recent RFCs.  It is the goal of
+   this document to continue to ensure that the overall RFC structure is
+   adequately clear so that such notes are unnecessary or (at least)
+   truly exceptional.
+
+5.  Other Structural Information in RFCs
+
+   RFCs contain other structural informational elements.  The RFC Editor
+   is responsible for the positioning and layout of these structural
+   elements.  Note also that new elements may be introduced or obsoleted
+   using a process consistent with [RFC4844].  These additions may or
+   may not require documentation in an RFC.
+
+   Currently, the following structural information is available in RFCs:
+
+   Copyright Notice:  A copyright notice with a reference to BCP 78
+      [BCP78] and an Intellectual Property statement referring to BCP 78
+      and BCP 79 [BCP79].  The content of these statements are defined
+      by those BCPs.
+
+
+
+Halpern, et al.               Informational                     [Page 6]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   ISSN:  The International Standard Serial Number [ISO.3297.2007]:
+      ISSN 2070-1721.  The ISSN uniquely identifies the RFC series as
+      title regardless of language or country in which it is published.
+      The ISSN itself has no significance other than the unique
+      identification of a serial publication.
+
+6.  Security Considerations
+
+   This document tries to clarify the descriptions of the status of an
+   RFC.  Misunderstanding the status of a memo could cause
+   interoperability problems, hence security and stability problems.
+
+7.  RFC Editor Considerations
+
+   The RFC Editor is responsible for maintaining the consistency of the
+   RFC series.  To that end, the RFC Editor maintains an "RFC Style
+   Guide" [RFC7322].  In this memo, we mention a few explicit structural
+   elements that the RFC Editor needs to maintain.  The conventions for
+   the content and use of all current and future elements are documented
+   in the style guide.
+
+   Adding a reference to the stream in the header of RFCs is only one
+   method for clarifying from which stream an RFC originated.  The RFC
+   Editor is encouraged to add such indication in, for example, indices
+   and interfaces.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+              <http://www.rfc-editor.org/info/rfc2026>.
+
+   [RFC5742]  Alvestrand, H. and R. Housley, "IESG Procedures for
+              Handling of Independent and IRTF Stream Submissions",
+              BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
+              <http://www.rfc-editor.org/info/rfc5742>.
+
+8.2.  Informative References
+
+   [ISO.3297.2007]
+              Technical Committee ISO/TC 46, Information and
+              documentation, Subcommittee SC 9, Identification and
+              description., "Information and documentation -
+              International standard serial number (ISSN)", ISO Standard
+              3297, 09 2007.
+
+
+
+
+Halpern, et al.               Informational                     [Page 7]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   [RFC3]     Crocker, S., "Documentation conventions", RFC 3,
+              DOI 10.17487/RFC0003, April 1969,
+              <http://www.rfc-editor.org/info/rfc3>.
+
+   [RFC1311]  Postel, J., "Introduction to the STD Notes", RFC 1311,
+              DOI 10.17487/RFC1311, March 1992,
+              <http://www.rfc-editor.org/info/rfc1311>.
+
+   [RFC4844]  Daigle, L., Ed. and Internet Architecture Board, "The RFC
+              Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
+              July 2007, <http://www.rfc-editor.org/info/rfc4844>.
+
+   [RFC5143]  Malis, A., Brayley, J., Shirron, J., Martini, L., and S.
+              Vogelsang, "Synchronous Optical Network/Synchronous
+              Digital Hierarchy (SONET/SDH) Circuit Emulation Service
+              over MPLS (CEM) Encapsulation", RFC 5143,
+              DOI 10.17487/RFC5143, February 2008,
+              <http://www.rfc-editor.org/info/rfc5143>.
+
+   [RFC5741]  Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
+              Headers, and Boilerplates", RFC 5741,
+              DOI 10.17487/RFC5741, December 2009,
+              <http://www.rfc-editor.org/info/rfc5741>.
+
+   [RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
+              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+              DOI 10.17487/RFC6410, October 2011,
+              <http://www.rfc-editor.org/info/rfc6410>.
+
+   [RFC7127]  Kolkman, O., Bradner, S., and S. Turner, "Characterization
+              of Proposed Standards", BCP 9, RFC 7127,
+              DOI 10.17487/RFC7127, January 2014,
+              <http://www.rfc-editor.org/info/rfc7127>.
+
+   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
+              DOI 10.17487/RFC7322, September 2014,
+              <http://www.rfc-editor.org/info/rfc7322>.
+
+   [ERRATA]   Hagens, A., Ginoza, S., and R. Braden, "RFC Editor
+              Proposal for Handling RFC Errata", Work in Progress,
+              draft-rfc-editor-errata-process-02, May 2008.
+
+   [BCP78]    Bradner, S., Ed. and J. Contreras, Ed., "Rights
+              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+              November 2008, <http://www.rfc-editor.org/info/bcp78>.
+
+
+
+
+
+
+Halpern, et al.               Informational                     [Page 8]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   [BCP79]    Bradner, S., Ed., "Intellectual Property Rights in IETF
+              Technology", BCP 79, RFC 3979, DOI 10.17487/RFC3979, March
+              2005.
+
+              Narten, T., "Clarification of the Third Party Disclosure
+              Procedure in RFC 3979", BCP 79, RFC 4879,
+              DOI 10.17487/RFC4879, April 2007.
+
+              <http://www.rfc-editor.org/info/bcp79>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern, et al.               Informational                     [Page 9]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+Appendix A.  Initial Formatting Details
+
+   This section contains the text the IAB used to initially populate the
+   web page used to maintain the list of required verbiage.
+
+A.1.  RFC Title Page Header
+
+   An RFC title page header can be described as follows:
+
+------------------------------------------------------------------------
+<document source>                                          <author name>
+Request for Comments: <RFC number>                [<author affiliation>]
+[<subseries ID> <subseries number>]    [more author info as appropriate]
+[<RFC relation>:<RFC number[s]>]
+Category: <category>
+                                                            <month year>
+
+------------------------------------------------------------------------
+
+   For example, the header for RFC 6410 appears as follows:
+
+------------------------------------------------------------------------
+
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 6410                                Vigil Security
+BCP: 9                                                        D. Crocker
+Updates: 2026                                Brandenburg InternetWorking
+Category: Best Current Practice                                E. Burger
+ISSN: 2070-1721                                    Georgetown University
+                                                            October 2011
+
+------------------------------------------------------------------------
+
+A.2.  Constructing a "Status of This Memo" Section
+
+   The following sections describe mandated text for use in specific
+   parts of the "Status of This Memo" portion of an RFC.  For
+   convenience, the RFC Editor maintains example expansions of all
+   permutations of the paragraphs described in this document (at the
+   time of publication, at http://www.rfc-editor.org/materials/status-
+   memos.txt).  When in conflict, the following sections are
+   authoritative.
+
+
+
+
+
+
+
+
+
+Halpern, et al.               Informational                    [Page 10]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+A.2.1.  First Paragraph
+
+   The following are the approved texts for use in the first paragraph
+   of the "Status of This Memo" portion of an RFC.  See Section 3.3 of
+   RFC 7841.
+
+   For 'Standards Track' documents:  "This is an Internet Standards
+      Track document."
+
+   For 'Best Current Practices' documents:  "This memo documents an
+      Internet Best Current Practice."
+
+   For other categories  "This document is not an Internet Standards
+      Track specification; <it is published for other purposes>."
+
+   For Informational, Experimental, Historic, and future categories of
+   RFCs, the RFC Editor will maintain an appropriate text for <it is
+   published for other purposes>.  Initial values are:
+
+   Informational:   "it is published for informational purposes."
+
+   Historic:   "it is published for the historical record."
+
+   Experimental:   "it is published for examination, experimental
+      implementation, and evaluation."
+
+A.2.2.  Second Paragraph
+
+   See Section 3.4 of RFC 7841.
+
+   The second paragraph may include some text that is specific to the
+   initial document category.  When a document is Experimental or
+   Historic, the second paragraph opens with:
+
+   Experimental:  "This document defines an Experimental Protocol for
+      the Internet community."
+
+   Historic:  "This document defines a Historic Document for the
+      Internet community."
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern, et al.               Informational                    [Page 11]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   The text that follows is stream dependent -- these are initial values
+   and may be updated by stream definition document updates and recorded
+   by the IAB on the web page.
+
+   IETF Stream:  "This document is a product of the Internet Engineering
+      Task Force (IETF)."
+
+      If there has been an IETF consensus call per IETF process, this
+      additional text should be added: "It represents the consensus of
+      the IETF community.  It has received public review and has been
+      approved for publication by the Internet Engineering Steering
+      Group (IESG)."  If there has not been such a consensus call, then
+      this simply reads: "It has been approved for publication by the
+      Internet Engineering Steering Group (IESG)."
+
+   IAB Stream:  "This document is a product of the Internet Architecture
+      Board (IAB), and represents information that the IAB has deemed
+      valuable to provide for permanent record."
+
+      If the document represents IAB consensus, this additional text
+      should be added: "It represents the consensus of the Internet
+      Architecture Board (IAB)."
+
+   IRTF Stream:  "This document is a product of the Internet Research
+      Task Force (IRTF).  The IRTF publishes the results of Internet-
+      related research and development activities.  These results might
+      not be suitable for deployment."
+
+      In addition, a sentence indicating the consensus base within the
+      IRTF may be added: "This RFC represents the consensus of the
+      <insert_name> Research Group of the Internet Research Task Force
+      (IRTF)." or alternatively "This RFC represents the individual
+      opinion(s) of one or more members of the <insert_name> Research
+      Group of the Internet Research Task Force (IRTF)".
+
+   Independent Submission Stream:  "This is a contribution to the RFC
+      Series, independently of any other RFC stream.  The RFC Editor has
+      chosen to publish this document at its discretion and makes no
+      statement about its value for implementation or deployment."
+
+   For non-IETF stream documents, a reference to Section 2 of this RFC
+   is added with the following sentence: "Documents approved for
+   publication by the [stream approver -- currently, one of: "IAB",
+   "IRSG", or "RFC Editor"] are not a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841."
+
+
+
+
+
+
+Halpern, et al.               Informational                    [Page 12]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+   For IETF stream documents, a similar reference is added: "Further
+   information on (BCPs or Internet Standards) is available in Section 2
+   of RFC 7841." for BCP and Standard Track documents; "Not all
+   documents approved by the IESG are a candidate for any level of
+   Internet Standards; see Section 2 of RFC 7841." for all other
+   categories.
+
+A.2.3.  Third Paragraph
+
+   See Section 3.5 of RFC 7841.
+
+IAB Members at Time of Approval
+
+   The IAB members at the time this memo was approved were (in
+   alphabetical order):
+
+      Jari Arkko
+      Mary Barnes
+      Marc Blanchet
+      Ralph Droms
+      Ted Hardie
+      Joe Hildebrand
+      Russ Housley
+      Erik Nordmark
+      Robert Sparks
+      Andrew Sullivan
+      Dave Thaler
+      Brian Trammell
+      Suzanne Woolf
+
+Acknowledgements
+
+   Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy Ginoza,
+   and John Klensin who provided background information and inspiration.
+
+   Thanks to the members of the RFC Series Oversight Committee (RSOC)
+   for assistance and review: Alexey Melnikov, Nevil Brownlee, Bob
+   Hinden, Sarah Banks, Robert Sparks, Tony Hansen, and Joe Hildebrand.
+
+   Various people have made suggestions that improved the document.
+   Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch.
+
+
+
+
+
+
+
+
+
+
+Halpern, et al.               Informational                    [Page 13]
+
+RFC 7841           RFC Streams, Headers, Boilerplates           May 2016
+
+
+Authors' Addresses
+
+   Joel M. Halpern (editor)
+
+   Email: jmh@joelhalpern.com
+
+
+   Leslie Daigle (editor)
+
+   Email: ldaigle@thinkingcat.com
+
+
+   Olaf M. Kolkman (editor)
+
+   Email: kolkman@isoc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern, et al.               Informational                    [Page 14]
+