doc: Add RFC documents

1 files changed, 886 insertions, 0 deletions

diff --git a/doc/rfc/rfc8729.txt b/doc/rfc/rfc8729.txt
new file mode 100644
index 0000000..5a25d47
--- /dev/null
+++ b/doc/rfc/rfc8729.txt
@@ -0,0 +1,886 @@
+
+
+
+
+Internet Architecture Board (IAB)                        R. Housley, Ed.
+Request for Comments: 8729                                              
+Obsoletes: 4844                                           L. Daigle, Ed.
+Category: Informational                                    February 2020
+ISSN: 2070-1721
+
+
+                     The RFC Series and RFC Editor
+
+Abstract
+
+   This document describes the framework for an RFC Series and an RFC
+   Editor function that incorporate the principles of organized
+   community involvement and accountability that has become necessary as
+   the Internet technical community has grown, thereby enabling the RFC
+   Series to continue to fulfill its mandate.  This document obsoletes
+   RFC 4844.
+
+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 candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8729.
+
+Copyright Notice
+
+   Copyright (c) 2020 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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  RFC Series Mission
+   3.  Roles and Responsibilities
+     3.1.  RFC Editor
+     3.2.  IAB
+     3.3.  Operational Oversight
+     3.4.  Policy Oversight
+   4.  Framework
+     4.1.  Document Approval
+       4.1.1.  Definition
+       4.1.2.  Operational Implementation
+       4.1.3.  Process Change
+       4.1.4.  Existing Approval Process Documents
+     4.2.  Editing, Processing, and Publication of Documents
+       4.2.1.  Definition
+       4.2.2.  Operational Implementation
+       4.2.3.  Process Change
+       4.2.4.  Existing Process Documents
+     4.3.  Archiving, Indexing, and Accessibility
+       4.3.1.  Definition
+       4.3.2.  Operational Implementation
+       4.3.3.  Process Change
+       4.3.4.  Existing Process Documents
+     4.4.  Series-Wide Guidelines and Rules
+       4.4.1.  Definition
+       4.4.2.  Operational Implementation
+       4.4.3.  Process Change
+       4.4.4.  Existing Process Documents
+   5.  RFC Streams
+     5.1.  RFC Approval Processes
+       5.1.1.  IETF Document Stream
+       5.1.2.  IAB Document Stream
+       5.1.3.  IRTF Document Stream
+       5.1.4.  Independent Submission Stream
+     5.2.  RFC Technical Publication Requirements
+       5.2.1.  IETF Documents
+       5.2.2.  IAB Documents
+       5.2.3.  IRTF Documents
+       5.2.4.  Independent Submissions
+   6.  Security Considerations
+   7.  Changes Since RFC 4844
+   8.  Informative References
+   Appendix A.  A Retrospective of IAB Charters and RFC Editor
+     A.1.  1992
+     A.2.  1994
+     A.3.  2000
+   IAB Members at the Time of Approval
+   Authors' Addresses
+
+1.  Introduction
+
+   The first Request for Comments (RFC) document was published in April
+   of 1969 as part of the effort to design and build what we now know of
+   as the Internet.  Since then, the RFC Series has been the archival
+   series dedicated to documenting Internet technical specifications,
+   including both general contributions from the Internet research and
+   engineering community as well as standards documents.
+
+   As described in the history of the first 30 years of RFCs
+   ([RFC2555]), the RFC Series was created for the purpose of capturing
+   the research and engineering thought that underlie the design of
+   (what we now know of as) the Internet.  As the Internet Engineering
+   Task Force (IETF) was formalized to carry out the discussion and
+   documentation of Internet standards, IETF documents have become a
+   large part (but not the entirety) of the RFC Series.
+
+   As the IETF has grown up and celebrated its own 30 years of history,
+   its requirements for archival publication of its output have changed
+   and become more rigorous.  Perhaps most significantly, the IETF must
+   be able to define (based on its own open consensus discussion
+   processes and leadership directions) and implement adjustments to its
+   publication processes.
+
+   At the same time, the Internet engineering and research community as
+   a whole has grown and come to require more openness and
+   accountability in all organizations supporting it.  More than ever,
+   this community needs an RFC Series that is supported (operationally
+   and in terms of its principles) such that there is a balance of:
+
+   *  expert implementation;
+
+   *  clear management and direction -- for operations and evolution
+      across the whole RFC Series (whether originating in the IETF or
+      not); and
+
+   *  appropriate community input into and review of activities.
+
+   In the past, there has been confusion and therefore sometimes tension
+   over where and how to address RFC issues that are particular to
+   contributing groups (e.g., the IETF, the Internet Architecture Board
+   (IAB), or independent individuals).  It was not always clear where
+   there should be community involvement versus RFC Editor control;
+   depending on the issue, there might be more or less involvement from
+   the IAB, the Internet Engineering Steering Group (IESG), or the
+   community at large.  There are similar issues with handling RFC
+   Series-wide issues -- where to discuss and resolve them in a way that
+   is balanced across the whole series.
+
+   For example, there have been discussions about Intellectual Property
+   Rights (IPR) for IETF-generated documents, but it's not clear when or
+   how to abstract the portions of those discussions that are relevant
+   to the rest of the RFC Series.  Discussions of labeling (of RFCs in
+   general, IETF documents in particular, or some combination thereof)
+   generally must be applied to the whole RFC Series or not at all.
+   Without an agreed-on framework for managing the RFC Series, it is
+   difficult to have those discussions in a non-polarized fashion --
+   either the IETF dictating the reality of the rest of the RFC Series,
+   or the RFC Series imposing undue restrictions on documents from the
+   IETF.
+
+   As part of its charter (see Appendix A), the IAB has a responsibility
+   for the RFC Editor.  Acknowledging the IETF's needs and the general
+   Internet engineering and research community's evolving needs, the IAB
+   supports a future for the RFC Series that continues to meet its
+   original mandate of providing the archival series for the technical
+   research and engineering documentation that describes the Internet.
+
+   With this document, the IAB provides the framework for the RFC Series
+   and an RFC Editor function with the specific purpose of ensuring that
+   the RFC Series is maintained and supported in ways that are
+   consistent with the stated purpose of the RFC Series and the
+   realities of today's Internet research and engineering community.
+   The framework describes the existing "streams" of RFCs, draws a
+   roadmap of existing process documents already defining the
+   implementation, and provides clear direction of how to evolve this
+   framework and its supporting pieces through discussion and future
+   document revision.
+
+   Specifically, this document provides a brief charter for the RFC
+   Series, describes the role of the RFC Editor, the IAB, and the IETF
+   Administrative Support Activity (IASA) in a framework for managing
+   the RFC Series, and discusses the streams of input to the RFC Series
+   from the various constituencies it serves.
+
+2.  RFC Series Mission
+
+   The RFC Series is the archival series dedicated to documenting
+   Internet technical specifications, including general contributions
+   from the Internet research and engineering community as well as
+   standards documents.
+
+   RFCs are available free of charge to anyone via the Internet.
+
+3.  Roles and Responsibilities
+
+   As this document sets out the framework for supporting the RFC Series
+   mission, this section reviews the updated roles and responsibilities
+   of the entities that have had, and will have, involvement in
+   continued support of the mission.
+
+3.1.  RFC Editor
+
+   Originally, there was a single person acting as editor of the RFC
+   Series (the RFC Editor).  The task has grown, and the work now
+   requires the organized activity of several experts, so there are RFC
+   Editors, or an RFC Editor organization.  In time, there may be
+   multiple organizations working together to undertake the work
+   required by the RFC Series.  For simplicity's sake, and without
+   attempting to predict how the role might be subdivided among them,
+   this document refers to this collection of experts and organizations
+   as the "RFC Editor".
+
+   The RFC Editor is an expert technical editor and series editor,
+   acting to support the mission of the RFC Series.  As such, the RFC
+   Editor is the implementer handling the editorial management of the
+   RFC Series, in accordance with the defined processes.  In addition,
+   the RFC Editor is expected to be the expert and prime mover in
+   discussions about policies for editing, publishing, and archiving
+   RFCs.
+
+3.2.  IAB
+
+   In this model, the role of the IAB is to ensure that the RFC Series
+   mission is being appropriately fulfilled for the whole community for
+   which it was created.  The IAB does not, organizationally, have
+   comprehensive publishing or editorial expertise.  Therefore, the role
+   of the IAB is focused on ensuring that principles are met, the
+   appropriate bodies and communities are duly informed and consulted,
+   and the RFC Editor has what it needs in order to execute on the
+   material that is in their mandate.
+
+   It is the responsibility of the IAB to approve the appointment of the
+   RFC Editor and to approve the general policy followed by the RFC
+   Editor.
+
+3.3.  Operational Oversight
+
+   The IETF Administration Limited Liability Company (IETF LLC), as part
+   of the IETF Administrative Support Activity (IASA), is responsible
+   for administrative and financial matters for the IETF, the IAB, and
+   the Internet Research Task Force (IRTF) [RFC8711].  The IASA is
+   tasked with providing the funding for the RFC Editor.  The IASA,
+   through the IETF Executive Director, provides contractual and
+   financial oversight of the RFC Editor.  Additionally, as described in
+   Section 3.1 of [RFC8728], the RFC Series Oversight Committee (RSOC),
+   acting with authority delegated from the IAB, is responsible for
+   ensuring that the RFC Series is run in a transparent and accountable
+   manner, including design and execution of the RFC Series Editor
+   selection process.
+
+   The IETF Executive Director works with the IAB to identify suitable
+   persons or entities to fulfill the mandate of the RFC Production
+   Center and the RFC Publisher roles as defined in [RFC8728].
+
+   The IETF Executive Director establishes appropriate contractual
+   agreements with the selected persons or entities to carry out the
+   work that will satisfy the technical publication requirements defined
+   for the various RFC input streams (see Section 5.2).  The IETF
+   Executive Director may define additional operational requirements and
+   policies for management purposes to meet the requirements defined by
+   the various communities.
+
+   The IETF Administration LLC Board approves a budget for operation of
+   the RFC Editor activity, and the IETF Executive Director establishes
+   and manages the necessary operational agreements for the RFC Editor
+   activity.
+
+3.4.  Policy Oversight
+
+   The IAB monitors the effectiveness of the policies in force and their
+   implementation to ensure that the RFC Editor activity meets the
+   editorial management and document publication needs as referenced in
+   this document.  In the event of serious non-conformance, the IAB,
+   either on its own initiative or at the request of the IETF
+   Administration LLC Board, may require the IETF Executive Director to
+   vary or terminate and renegotiate the arrangements for the RFC Editor
+   activity.
+
+4.  Framework
+
+   With the RFC Series mission outlined above, this document describes a
+   framework for supporting
+
+   *  the operational implementation of the RFC Series,
+
+   based on
+
+   *  public process and definition documents,
+
+   for which there are
+
+   *  clear responsibilities and mechanisms for update and change.
+
+   Generally speaking, the RFC Editor is responsible for the operational
+   implementation of the RFC Series.  As outlined in Section 3.3, the
+   IETF Executive Director provides the oversight of this operational
+   role.
+
+   The process and definition documents are detailed below, including
+   responsibility for the individual process documents (maintenance and
+   update).  The RFC Editor works with the appropriate community to
+   ensure that the process documents reflect current requirements.  The
+   IAB is charged with the role of verifying that appropriate community
+   input has been sought and that any changes appropriately account for
+   community requirements.
+
+   There are three categories of activity, and a fourth category of
+   series-wide rules and guidelines, described for implementing the RFC
+   Series to support its mission:
+
+   *  Approval of documents.
+
+   *  Editing, processing, and publication of documents.
+
+   *  Archiving and indexing the documents and making them accessible.
+
+   *  Series rules and guidelines.
+
+4.1.  Document Approval
+
+   The RFC Series mission implicitly requires that documents be reviewed
+   and approved for acceptance into the series.
+
+4.1.1.  Definition
+
+   Section 5.1 describes the different streams of documents that are put
+   to the RFC Editor for publication as RFCs today.  While there may be
+   general policies for approval of documents as RFCs (to ensure the
+   coherence of the RFC Series), there are also policies defined for the
+   approval of documents in each stream.  Generally speaking, there is a
+   different approving body for each stream.  The current definitions
+   are catalogued in Section 5.1.
+
+4.1.2.  Operational Implementation
+
+   Each stream has its own documented approval process.  The RFC Editor
+   is responsible for the approval of documents in one of the streams
+   (Independent Submission stream, see Section 5.1.4) and works with the
+   other approving bodies to ensure smooth passage of approved documents
+   into the next phases, ultimately to publication and archiving as an
+   RFC.
+
+4.1.3.  Process Change
+
+   From time to time, it may be necessary to change the approval
+   processes for any given stream, or even add or remove streams.  This
+   may occur when the RFC Editor, the IAB, the body responsible for a
+   given stream of documents, or the community determines that there are
+   issues to be resolved in general for RFC approval or for per-stream
+   approval processes.
+
+   In this framework, the general approach is that the IAB will work
+   with the RFC Editor and other parties to get community input, and it
+   will verify that any changes appropriately account for community
+   requirements.
+
+4.1.4.  Existing Approval Process Documents
+
+   The existing documents describing the approval processes for each
+   stream are detailed in Section 5.1.
+
+4.2.  Editing, Processing, and Publication of Documents
+
+   Producing and maintaining a coherent, well-edited document series
+   requires specialized skills and subject matter expertise.  This is
+   the domain of the RFC Editor.  Nevertheless, the community served by
+   the RFC Series and the communities served by the individual streams
+   of RFCs have requirements that help define the nature of the series.
+
+4.2.1.  Definition
+
+   General and stream-specific requirements for the RFC Series are
+   documented in community-approved documents (catalogued in Section 5.2
+   below).
+
+   Any specific interfaces, numbers, or concrete values required to make
+   the requirements operational are the subject of agreements between
+   the IASA and the RFC Editor (e.g., contracts, statements of work,
+   service level agreements, etc).
+
+4.2.2.  Operational Implementation
+
+   The RFC Editor is responsible for ensuring that editing, processing,
+   and publication of RFCs are carried out in a way that is consistent
+   with the requirements laid out in the appropriate documents.  The RFC
+   Editor works with the IASA to provide regular reporting and feedback
+   on these operations.
+
+4.2.3.  Process Change
+
+   From time to time, it may be necessary to change the requirements for
+   any given stream, or the RFC Series in general.  This may occur when
+   the RFC Editor, the IAB, the approval body for a given stream of
+   documents, or the community determines that there are issues to be
+   resolved in general for RFCs or for per-stream requirements.
+
+   In this model, the general approach is that the IAB will work with
+   the RFC Editor to get community input, and it will approve changes by
+   validating appropriate consideration of community requirements.
+
+4.2.4.  Existing Process Documents
+
+   Documents describing existing requirements for the streams are
+   detailed in Section 5.2.
+
+4.3.  Archiving, Indexing, and Accessibility
+
+   The activities of archiving, indexing, and making accessible the RFC
+   Series can be informed by specific subject matter expertise in
+   general document series editing.  It is also important that they are
+   informed by requirements from the whole community.  As long as the
+   RFC Series is to remain coherent, there should be uniform archiving
+   and indexing of RFCs across all streams and a common method of
+   accessing the resulting documents.
+
+4.3.1.  Definition
+
+   In principle, there should be a community consensus document
+   describing the archiving, indexing, and accessibility requirements
+   for the RFC Series.  In practice, we continue with the archive as
+   built by the capable RFC Editors since the series' inception.
+
+   Any specific concrete requirements for the archive, index, and
+   accessibility operations are the subject of agreements between the
+   IASA and the RFC Editor (e.g., contracts, statements of work, service
+   level agreements, etc).
+
+4.3.2.  Operational Implementation
+
+   The RFC Editor is responsible for ensuring that the RFC archive and
+   index are maintained appropriately and that the resulting documents
+   are made available to anybody wishing to access them via the
+   Internet.  The RFC Editor works with the IASA for regular reporting
+   and feedback.
+
+4.3.3.  Process Change
+
+   Should there be a community move to propose changes to the
+   requirements for the RFC archive and index or accessibility, the IAB
+   will work with the RFC Editor to get community input, and it will
+   approve changes by validating appropriate consideration of community
+   requirements.
+
+4.3.4.  Existing Process Documents
+
+   There are no applicable process documents.
+
+4.4.  Series-Wide Guidelines and Rules
+
+   The RFC Series style and content can be shaped by subject matter
+   expertise in document series editing.  They are also informed by
+   requirements by the using community.  As long as the RFC Series is to
+   remain coherent, there should be uniform style and content for RFCs
+   across all streams.  This includes, but is not limited to, acceptable
+   language, use of references, and copyright rules.
+
+4.4.1.  Definition
+
+   In principle, there should be a community consensus document (or set
+   of documents) describing the content requirements for the RFC Series.
+   In practice, some do exist, though some need reviewing and more may
+   be needed over time.
+
+4.4.2.  Operational Implementation
+
+   The RFC Editor is responsible for ensuring that the RFC Series
+   guidelines are upheld within the RFC Series.
+
+4.4.3.  Process Change
+
+   When additions or changes are needed to series-wide definitions, the
+   IAB will work with the RFC Editor and stream stakeholders to get
+   community input and review.  The IAB will approve changes by
+   validating appropriate consideration of community requirements.
+
+4.4.4.  Existing Process Documents
+
+   Existing series-wide rules and guidelines documents include:
+
+   *  RFC Style Guide [RFC7322],
+
+   *  The Use of Non-ASCII Characters in RFCs [RFC7997],
+
+   *  Copyright and intellectual property rules [RFC5378],
+
+   *  Normative references [RFC3967] [RFC4897], [RFC8067].
+
+5.  RFC Streams
+
+   Various contributors provide input to the RFC Series.  These
+   contributors come from several different communities, each with its
+   own defined process for approving documents that will be published by
+   the RFC Editor.  This is nothing new; however, over time the various
+   communities and document requirements have grown and separated.  In
+   order to promote harmony in discussing the collective set of
+   requirements, it is useful to recognize each in their own space --
+   and they are referred to here as "streams".
+
+   Note that by identifying separate streams, there is no intention of
+   dividing them or undermining their management as one series.  Rather,
+   the opposite is true -- by clarifying the constituent parts, it is
+   easier to make them work together without the friction that sometimes
+   arises when discussing various requirements.
+
+   The subsections below identify the streams that exist today.  There
+   is no immediate expectation of new streams being created, and it is
+   preferable that new streams NOT be created.  Creation of streams and
+   all policies surrounding general changes to the RFC Series are
+   discussed above in Section 4.
+
+5.1.  RFC Approval Processes
+
+   Processes for approval of documents (or requirements) for each stream
+   are defined by the community that defines the stream.  The IAB is
+   charged with the role of verifying that appropriate community input
+   has been sought and that the changes are consistent with the RFC
+   Series mission and this overall framework.
+
+   The RFC Editor is expected to publish all documents passed to it
+   after appropriate review and approval in one of the identified
+   streams.
+
+5.1.1.  IETF Document Stream
+
+   The IETF document stream includes IETF WG documents as well as
+   "individual submissions" sponsored by an IESG area director.  Any
+   document being published as part of the IETF standards process must
+   follow this stream -- no other stream can approve Standards-Track
+   RFCs or Best Current Practice (BCP) RFCs.
+
+   Approval of documents in the IETF stream is defined by
+
+   *  the IETF standards process [RFC2026] (and its successors).
+
+   *  the IESG process for sponsoring individual submissions [SPONSOR].
+
+   Changes to the approval process for this stream are made by updating
+   the IETF standards process documents.
+
+5.1.2.  IAB Document Stream
+
+   The IAB defines the processes by which it approves documents in its
+   stream.  Consistent with the above, any documents that the IAB wishes
+   to publish as part of the IETF Standards Track (Standards or BCPs)
+   are subject to the approval processes referred to in Section 5.1.1.
+
+   The review and approval process for documents in the IAB stream is
+   described in
+
+   *  the IAB process for review and approval of its documents
+      [RFC4845].
+
+5.1.3.  IRTF Document Stream
+
+   The IRTF is chartered as an activity of the IAB.  With the approval
+   of the IAB, the IRTF may publish and update a process for publication
+   of its own, non-IETF Standards-Track, documents.
+
+   The review and approval process for documents in the IRTF stream is
+   described in
+
+   *  IRTF Research Group RFCs [RFC5743].
+
+5.1.4.  Independent Submission Stream
+
+   The RFC Series has always served a broader Internet technical
+   community than the IETF.  The "Independent Submission" stream is
+   defined to provide review and (possible) approval of documents that
+   are outside the scope of the streams identified above.
+
+   Generally speaking, approval of documents in this stream falls under
+   the purview of the RFC Editor, and the RFC Editor seeks input to its
+   review from the IESG.
+
+   The process for reviewing and approving documents in the Independent
+   Submission stream is defined by
+
+   *  Procedures for Rights Handling in the RFC Independent Submission
+      Stream [RFC5744],
+
+   *  Independent Submission Editor Model [RFC8730],
+
+   *  Independent Submissions to the RFC Editor [RFC4846],
+
+   *  The IESG and RFC Editor Documents: Procedures [RFC5742].
+
+5.2.  RFC Technical Publication Requirements
+
+   The Internet engineering and research community has not only grown,
+   it has become more diverse, and sometimes more demanding.  The IETF,
+   as a standards-developing organization, has publication requirements
+   that extend beyond those of an academic journal.  The IAB does not
+   have the same interdependence with IANA assignments as the IETF
+   stream does.  Therefore, there is the need to both codify the
+   publishing requirements of each stream, and endeavor to harmonize
+   them to the extent that is reasonable.
+
+   Therefore, it is expected that the community of effort behind each
+   document stream will outline their technical publication
+   requirements.
+
+   As part of the RFC Editor oversight, the IAB must agree that the
+   requirements are consistent with and implementable as part of the RFC
+   Editor activity.
+
+5.2.1.  IETF Documents
+
+   The requirements for this stream are defined in [RFC4714].
+
+5.2.2.  IAB Documents
+
+   Although they were developed for the IETF standards process, the IAB
+   has identified applicable requirements in [RFC4714] for its stream.
+   In addition, procedures related to IPR for the IAB stream are
+   captured in [RFC5745].
+
+   If the IAB elects to define other requirements, they should deviate
+   minimally from those (in an effort to keep the collective technical
+   publication requirements reasonably managed by one technical
+   publisher).
+
+5.2.3.  IRTF Documents
+
+   The IRTF has identified applicable requirements in [RFC5743] for its
+   stream.
+
+   If the IRTF elects to define other requirements, they should deviate
+   minimally from those (in an effort to keep the collective technical
+   publication requirements reasonably managed by one technical
+   publisher).
+
+5.2.4.  Independent Submissions
+
+   Procedures and processes for the Independent Stream are described in
+   [RFC4846] and [RFC8730].
+
+   Although they were developed for the IETF standards process, the RFC
+   Editor has identified applicable requirements in [RFC4714] for the
+   Independent Submissions stream.  In addition, procedures related to
+   IPR for the independent submissions stream are captured in [RFC5744].
+
+   If the RFC Editor elects to define other requirements, they should
+   deviate minimally from those (in an effort to keep the collective
+   technical publication requirements reasonably managed by one
+   technical publisher).
+
+6.  Security Considerations
+
+   The processes for the publication of documents must prevent the
+   introduction of unapproved changes.  Since the RFC Editor maintains
+   the index of publications, sufficient security must be in place to
+   prevent these published documents from being changed by external
+   parties.  The archive of RFC documents, any source documents needed
+   to recreate the RFC documents, and any associated original documents
+   (such as lists of errata, tools, and, for some early items, non-
+   machine readable originals) need to be secured against failure of the
+   storage medium and other similar disasters.
+
+7.  Changes Since RFC 4844
+
+   Sections 3.3, 3.4, and 4 have been updated to align with the
+   restructuring of the IETF Administrative Support Activity (IASA).
+   Under the new structure, the IETF LLC performs the tasks related to
+   IASA that were previously assigned to the IETF Administrative
+   Director and to the Internet Society.
+
+   Many references were updated to point to the most recent documents.
+
+   Minor editorial changes were made to reflect 10 years of using the
+   framework provided in RFC 4884.  For example, RFC 4844 said, "...
+   this document sets out a revised framework ...", and it is now more
+   appropriate to say, "... this document sets out the framework ...".
+
+8.  Informative References
+
+   [RFC1358]  Chapin, L., "Charter of the Internet Architecture Board
+              (IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992,
+              <https://www.rfc-editor.org/info/rfc1358>.
+
+   [RFC1601]  Huitema, C., "Charter of the Internet Architecture Board
+              (IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994,
+              <https://www.rfc-editor.org/info/rfc1601>.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+              <https://www.rfc-editor.org/info/rfc2026>.
+
+   [RFC2555]  Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555,
+              DOI 10.17487/RFC2555, April 1999,
+              <https://www.rfc-editor.org/info/rfc2555>.
+
+   [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
+              "Charter of the Internet Architecture Board (IAB)",
+              BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
+              <https://www.rfc-editor.org/info/rfc2850>.
+
+   [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
+              Documents may Refer Normatively to Documents at a Lower
+              Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December
+              2004, <https://www.rfc-editor.org/info/rfc3967>.
+
+   [RFC4714]  Mankin, A. and S. Hayes, "Requirements for IETF Technical
+              Publication Service", RFC 4714, DOI 10.17487/RFC4714,
+              October 2006, <https://www.rfc-editor.org/info/rfc4714>.
+
+   [RFC4845]  Daigle, L., Ed. and Internet Architecture Board, "Process
+              for Publication of IAB RFCs", RFC 4845,
+              DOI 10.17487/RFC4845, July 2007,
+              <https://www.rfc-editor.org/info/rfc4845>.
+
+   [RFC4846]  Klensin, J., Ed. and D. Thaler, Ed., "Independent
+              Submissions to the RFC Editor", RFC 4846,
+              DOI 10.17487/RFC4846, July 2007,
+              <https://www.rfc-editor.org/info/rfc4846>.
+
+   [RFC4897]  Klensin, J. and S. Hartman, "Handling Normative References
+              to Standards-Track Documents", BCP 97, RFC 4897,
+              DOI 10.17487/RFC4897, June 2007,
+              <https://www.rfc-editor.org/info/rfc4897>.
+
+   [RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
+              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+              DOI 10.17487/RFC5378, November 2008,
+              <https://www.rfc-editor.org/info/rfc5378>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc5742>.
+
+   [RFC5743]  Falk, A., "Definition of an Internet Research Task Force
+              (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743,
+              December 2009, <https://www.rfc-editor.org/info/rfc5743>.
+
+   [RFC5744]  Braden, R. and J. Halpern, "Procedures for Rights Handling
+              in the RFC Independent Submission Stream", RFC 5744,
+              DOI 10.17487/RFC5744, December 2009,
+              <https://www.rfc-editor.org/info/rfc5744>.
+
+   [RFC5745]  Malis, A., Ed. and IAB, "Procedures for Rights Handling in
+              the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745,
+              December 2009, <https://www.rfc-editor.org/info/rfc5745>.
+
+   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
+              DOI 10.17487/RFC7322, September 2014,
+              <https://www.rfc-editor.org/info/rfc7322>.
+
+   [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>.
+
+   [RFC8067]  Leiba, B., "Updating When Standards Track Documents May
+              Refer Normatively to Documents at a Lower Level", BCP 97,
+              RFC 8067, DOI 10.17487/RFC8067, January 2017,
+              <https://www.rfc-editor.org/info/rfc8067>.
+
+   [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
+              the IETF Administrative Support Activity, Version 2.0",
+              BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
+              <https://www.rfc-editor.org/info/rfc8711>.
+
+   [RFC8728]  Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed.,
+              "RFC Editor Model (Version 2)", RFC 8728,
+              DOI 10.17487/RFC8728, February 2020,
+              <https://www.rfc-editor.org/info/rfc8728>.
+
+   [RFC8730]  Brownlee, N., Ed. and R. Hinden, Ed., "Independent
+              Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730,
+              February 2020, <https://www.rfc-editor.org/info/rfc8730>.
+
+   [SPONSOR]  IESG, "Guidance on Area Director Sponsoring of Documents",
+              IESG Statement, March 2007,
+              <http://www.ietf.org/iesg/statement/ad-sponsoring-
+              docs.html>.
+
+Appendix A.  A Retrospective of IAB Charters and RFC Editor
+
+   With this document, the IAB's role with respect to the RFC Series and
+   the RFC Editor is being adjusted to work more directly with the RFC
+   Editor and provide oversight to ensure the RFC Series mission
+   principles and communities' input are addressed appropriately.
+
+   This section provides an overview of the role of the IAB with respect
+   to the RFC Editor as it has been presented in IAB Charter RFCs dating
+   back to 1992.  The point of this section is that the IAB's role has
+   historically been substantive -- whether it is supposed to be
+   directly responsible for the RFC Series' editorial management (circa
+   1992, Appendix A.1), or appointment of the RFC Editor organization
+   and approval of general policy (circa 2000, Appendix A.3).
+
+A.1.  1992
+
+   [RFC1358] says:
+
+   |  [The IAB's] responsibilities shall include:
+   |  [...]
+   |      (2)  The editorial management and publication of the Request
+   |           for Comments (RFC) document series, which constitutes the
+   |           archival publication series for Internet Standards and
+   |           related contributions by the Internet research and
+   |           engineering community.
+
+A.2.  1994
+
+   [RFC1601] says:
+
+   |  [The IAB's] responsibilities under this charter include:
+   |  
+   |  (d) RFC Series and IANA
+   |  
+   |     The IAB is responsible for editorial management and publication
+   |     of the Request for Comments (RFC) document series, and for
+   |     administration of the various Internet assigned numbers.
+
+   Which it elaborates as:
+
+   |   2.4 RFC Series and Assigned Numbers
+   |  
+   |      The RFC Series constitutes the archival publication channel
+   |      for Internet Standards and for other contributions by the
+   |      Internet research and engineering community.  The IAB
+   |      shall select an RFC Editor, who shall be responsible for
+   |      the editorial management and publication of the RFC Series.
+
+A.3.  2000
+
+   The most recent IAB Charter [RFC2850] says:
+
+   |  (d) RFC Series and IANA
+   |  
+   |  The RFC Editor executes editorial management and publication of
+   |  the IETF "Request for Comment" (RFC) document series, which is
+   |  the permanent document repository of the IETF.  The RFC Series
+   |  constitutes the archival publication channel for Internet
+   |  Standards and for other contributions by the Internet research
+   |  and engineering community.  RFCs are available free of charge to
+   |  anyone via the Internet.  The IAB must approve the appointment
+   |  of an organization to act as RFC Editor and the general policy
+   |  followed by the RFC Editor.
+
+IAB Members at the Time of Approval
+
+   The IAB members at the time of approval of RFC 4844 were:
+
+      Bernard Aboba
+      Loa Andersson
+      Brian Carpenter
+      Leslie Daigle
+      Elwyn Davies
+      Kevin Fall
+      Olaf Kolkman
+      Kurtis Lindqvist
+      David Meyer
+      David Oran
+      Eric Rescorla
+      Dave Thaler
+      Lixia Zhang
+
+   The IAB members at the time of approval of this document were:
+
+      Jari Arkko
+      Alissa Cooper
+      Stephen Farrell
+      Wes Hardaker
+      Ted Hardie
+      Christian Huitema
+      Zhenbin Li
+      Erik Nordmark
+      Mark Nottingham
+      Melinda Shore
+      Jeff Tantsura
+      Martin Thomson
+      Brian Trammell
+
+Authors' Addresses
+
+   Russ Housley (editor)
+
+   Email: housley@vigilsec.com
+
+
+   Leslie L. Daigle (editor)
+
+   Email: ldaigle@thinkingcat.com