doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc5741.txt b/doc/rfc/rfc5741.txt
new file mode 100644
index 0000000..8ae1a40
--- /dev/null
+++ b/doc/rfc/rfc5741.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                         L. Daigle, Ed.
+Request for Comments: 5741                               O. Kolkman, Ed.
+Updates: 2223, 4844                                          For the IAB
+Category: Informational                                    December 2009
+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.
+
+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.  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/rfc5741.
+
+Copyright Notice
+
+   Copyright (c) 2009 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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+
+Daigle, et al.               Informational                      [Page 1]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  RFC Streams and Internet Standards . . . . . . . . . . . . . .  3
+   3.  RFC Structural Elements  . . . . . . . . . . . . . . . . . . .  3
+     3.1.  The Title Page Header  . . . . . . . . . . . . . . . . . .  3
+     3.2.  The Status of this Memo  . . . . . . . . . . . . . . . . .  5
+       3.2.1.  Paragraph 1  . . . . . . . . . . . . . . . . . . . . .  6
+       3.2.2.  Paragraph 2  . . . . . . . . . . . . . . . . . . . . .  6
+       3.2.3.  Paragraph 3  . . . . . . . . . . . . . . . . . . . . .  8
+       3.2.4.  Noteworthy . . . . . . . . . . . . . . . . . . . . . .  9
+     3.3.  Additional Notes . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  Other Structural Information in RFCs . . . . . . . . . . .  9
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   5.  RFC Editor Considerations  . . . . . . . . . . . . . . . . . . 10
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Appendix A.  Some Example 'Status of This Memo' Boilerplates . . . 12
+     A.1.  IETF Standards Track . . . . . . . . . . . . . . . . . . . 12
+     A.2.  IETF Experimental, with Consensus Call . . . . . . . . . . 12
+     A.3.  IETF Experimental, No Consensus Call . . . . . . . . . . . 13
+     A.4.  IAB Informational  . . . . . . . . . . . . . . . . . . . . 13
+     A.5.  IRTF Experimental, No Consensus Call . . . . . . . . . . . 14
+     A.6.  Independent Submission Informational . . . . . . . . . . . 15
+   Appendix B.  IAB Members at Time of Approval . . . . . . . . . . . 15
+   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 15
+
+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
+
+
+
+Daigle, et al.               Informational                      [Page 2]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+   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, and provides a comprehensive approach to
+   updating and using those elements to communicate, with clarity, RFC
+   document and content status.  Most of the historical structure
+   information is collected from [RFC2223].
+
+   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], and [RFC4844] and their successors for
+   current details of the IETF process and RFC streams.
+
+3.  RFC Structural Elements
+
+3.1.  The Title Page Header
+
+   This section describes the elements that are commonly found in RFCs
+   published today.  For the sake of clarity, this document specifies
+   the elements precisely as a specification.  However, this is not
+   intended to specify a single, static format.  Details of formatting
+   are decided by the RFC Editor.  Substantive changes to the header and
+
+
+
+
+Daigle, et al.               Informational                      [Page 3]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+   boilerplate structure and content may be undertaken in the future,
+   and are subject to general oversight and review by the IAB.
+
+   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, a sample earlier RFC header is as follows:
+
+------------------------------------------------------------------------
+Network Working Group                                          T. Dierks
+Request for Comments: 4346                                   Independent
+Obsoletes: 2246                                              E. Rescorla
+Category: Standards Track                                     RTFM, Inc.
+                                                              April 2006
+------------------------------------------------------------------------
+
+   The right column contains author name and affiliation information as
+   well as the RFC publication month.  Conventions and restrictions for
+   these elements are described in RFC style norms and some individual
+   stream definitions.
+
+   This section is primarily concerned with the information in the left
+   column:
+
+   <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 [RFC0003].  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:
+
+
+
+
+
+
+Daigle, et al.               Informational                      [Page 4]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+      *  Internet Engineering Task Force (IETF)
+
+      *  Internet Architecture Board (IAB)
+
+      *  Internet Research Task Force (IRTF)
+
+      *  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], STDs
+      [RFC1311], and FYIs [RFC1150].  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 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" [RFC2223].  Alternatives 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.  This text is included
+   irrespective of the source stream of the RFC.
+
+   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-
+
+
+
+Daigle, et al.               Informational                      [Page 5]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+   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.2.1.  Paragraph 1
+
+   The first paragraph of the Status of this Memo section contains a
+   single sentence, clearly standing out.  It depends on the category of
+   the document.
+
+   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>.  Suggested 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."
+
+3.2.2.  Paragraph 2
+
+   The second paragraph of the "Status of This Memo" will now 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.  There is a specific
+   structure defined here to ensure there is clarity about review
+   processes and document types.  These paragraphs will need to be
+   defined and maintained as part of RFC stream definitions.  Suggested
+   initial text, for current streams, is provided below.
+
+   The 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:
+
+
+
+Daigle, et al.               Informational                      [Page 6]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+   Experimental:
+      "This document defines an Experimental Protocol for the Internet
+      community."
+
+   Historic:
+      "This document defines a Historic Document for the Internet
+      community."
+
+   The text that follows is stream dependent -- these are suggested
+   initial values and may be updated by stream definition document
+   updates.
+
+   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, an
+      additional sentence 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."
+
+   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
+
+
+
+
+Daigle, et al.               Informational                      [Page 7]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+         "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 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
+      5741."
+
+   For IETF stream documents, a similar reference is added for BCP and
+   Standards Track documents:
+
+      "Further information on [BCPs or Internet Standards] is available
+      in Section 2 of RFC 5741."
+
+   For all other categories:
+
+      "Not all documents approved by the IESG are a candidate for any
+      level of Internet Standard; see Section 2 of RFC 5741."
+
+3.2.3.  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 [RFC-ERRATA].
+   The exact wording and URL is subject to change (at the RFC Editor's
+   discretion), but 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/info/rfc<rfc-no>."
+
+
+
+
+
+
+
+
+Daigle, et al.               Informational                      [Page 8]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+3.2.4.  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 e.g., Historic.  This cannot be reflected in the
+   document itself and will need be reflected in the information
+   referred to in Section 3.2.3.
+
+3.3.  Additional Notes
+
+   Exceptionally, a review and publication process may prescribe
+   additional notes that will appear as labeled notes after the "Status
+   of This Memo".
+
+   While this has been a common feature of recent RFCs, it is the goal
+   of this document to make the overall RFC structure adequately clear
+   to remove the need for such notes, or at least make their usage truly
+   exceptional.
+
+3.4.  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 or is
+   being considered for inclusion 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.
+
+   ISSN
+      The International Standard Serial Number [ISO3297]:
+      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.
+
+4.  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.
+
+
+
+Daigle, et al.               Informational                      [Page 9]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+5.  RFC Editor Considerations
+
+   The RFC Editor is responsible for maintaining the consistency of the
+   RFC series.  To that end the RFC Editor maintains a style manual
+   [RFC-style].  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 to be
+   documented in the style manual.
+
+   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 e.g., indices and
+   interfaces.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2026]     Bradner, S., "The Internet Standards Process --
+                 Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC5742]     Alvestrand, H. and R. Housley, "IESG Procedures for
+                 Handling of Independent and IRTF Stream Submissions",
+                 BCP 92, RFC 5742, December 2009.
+
+6.2.  Informative References
+
+   [ISO3297]     Technical Committee ISO/TC 46, Information and
+                 documentation, Subcommittee SC 9, Identification and
+                 description., "Information and documentation -
+                 International standard serial number (ISSN)", 09 2007.
+
+   [RFC0003]     Crocker, S., "Documentation conventions", RFC 3,
+                 April 1969.
+
+   [RFC1311]     Postel, J., "Introduction to the STD Notes", RFC 1311,
+                 March 1992.
+
+   [RFC1150]     Malkin, G. and J. Reynolds, "FYI on FYI: Introduction
+                 to the FYI Notes", RFC 1150, March 1990.
+
+   [RFC2223]     Postel, J. and J. Reynolds, "Instructions to RFC
+                 Authors", RFC 2223, October 1997.
+
+   [RFC2629]     Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+                 June 1999.
+
+
+
+
+
+Daigle, et al.               Informational                     [Page 10]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+   [RFC4844]     Daigle, L. and Internet Architecture Board, "The RFC
+                 Series and RFC Editor", RFC 4844, July 2007.
+
+   [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,
+                 February 2008.
+
+   [RFC-ERRATA]  Hagens, A., Ginoza, S., and R. Braden, "RFC Editor
+                 Proposal for Handling RFC Errata", Work in Progress,
+                 May 2008.
+
+   [BCP78]       Bradner, S., Ed. and J. Contreras, Ed., "Rights
+                 Contributors Provide to the IETF Trust", BCP 78,
+                 RFC 5378, November 2008.
+
+   [BCP79]       Bradner, S., Ed. and T. Narten, Ed., "Intellectual
+                 Property Rights in IETF Technology", BCP 79, RFC 3979,
+                 April 2007.
+
+                 Narten, T., "Clarification of the Third Party
+                 Disclosure Procedure in RFC 3979", BCP 79, RFC 4879,
+                 April 2007.
+
+   [RFC-style]   RFC Editor, "RFC Style Guide",
+                 <http://www.rfc-editor.org/styleguide.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle, et al.               Informational                     [Page 11]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+Appendix A.  Some Example 'Status of This Memo' Boilerplates
+
+A.1.  IETF Standards Track
+
+   The boilerplate for a Standards Track document that (by definition)
+   has been subject to an IETF consensus call.
+
+------------------------------------------------------------------------
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  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).  Further
+   information on Internet Standards is available in 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/rfc<rfc-no>.
+------------------------------------------------------------------------
+
+A.2.  IETF Experimental, with Consensus Call
+
+   The boilerplate for an Experimental document that has been subject to
+   an IETF consensus call.
+
+------------------------------------------------------------------------
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  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).  Not
+   all documents approved by the IESG are 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/rfc<rfc-no>.
+------------------------------------------------------------------------
+
+
+
+Daigle, et al.               Informational                     [Page 12]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+A.3.  IETF Experimental, No Consensus Call
+
+   The boilerplate for an Experimental document that not has been
+   subject to an IETF consensus call.
+
+------------------------------------------------------------------------
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are 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/rfc<rfc-no>.
+------------------------------------------------------------------------
+
+A.4.  IAB Informational
+
+   The boilerplate for an Informational IAB document.
+
+------------------------------------------------------------------------
+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.  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/rfc<rfc-no>.
+------------------------------------------------------------------------
+
+
+
+
+
+
+
+Daigle, et al.               Informational                     [Page 13]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+A.5.  IRTF Experimental, No Consensus Call
+
+   The boilerplate for an Experimental document that has been produced
+   by the IRTF and for which there was no RG consensus.  This variation
+   is the most verbose boilerplate in the current set.
+
+------------------------------------------------------------------------
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  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.  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).  Documents approved for
+   publication by the IRSG 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/rfc<rfc-no>.
+------------------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle, et al.               Informational                     [Page 14]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+A.6.  Independent Submission Informational
+
+   The boilerplate for an Informational document that has been produced
+   by the Independent Submission stream.
+
+------------------------------------------------------------------------
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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.  Documents approved for
+   publication by the RFC Editor 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/rfc<rfc-no>.
+------------------------------------------------------------------------
+
+Appendix B.  IAB Members at Time of Approval
+
+   The IAB members at the time this memo was approved were (in
+   alphabetical order): Loa Andersson, Gonzalo Camarillo, Stuart
+   Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry Leiba,
+   Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, Dave
+   Thaler, and Lixia Zhang.  In addition, the IAB included two
+   ex-officio members: Dow Street, who was serving as the IAB Executive
+   Director, and Aaron Falk, who was serving as the IRTF Chair.
+
+Appendix C.  Acknowledgements
+
+   Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy Ginoza,
+   and John Klensin who provided background information and inspiration.
+
+   Various people have made suggestions that improved the document.
+   Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch.
+
+   This document was produced using the xml2rfc tool [RFC2629].
+
+
+
+
+
+
+
+
+
+Daigle, et al.               Informational                     [Page 15]
+
+RFC 5741           RFC Streams, Headers, Boilerplates      December 2009
+
+
+Authors' Addresses
+
+   Leslie Daigle (editor)
+   EMail: daigle@isoc.org, leslie@thinkingcat.com
+
+
+   Olaf M. Kolkman (editor)
+   EMail: olaf@nlnetlabs.nl
+
+
+   Internet Architecture Board
+   EMail: iab@iab.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle, et al.               Informational                     [Page 16]
+