doc: Add RFC documents

1 files changed, 985 insertions, 0 deletions

diff --git a/doc/rfc/rfc8728.txt b/doc/rfc/rfc8728.txt
new file mode 100644
index 0000000..216fe84
--- /dev/null
+++ b/doc/rfc/rfc8728.txt
@@ -0,0 +1,985 @@
+
+
+
+
+Internet Architecture Board (IAB)                        O. Kolkman, Ed.
+Request for Comments: 8728                              Internet Society
+Obsoletes: 6635                                          J. Halpern, Ed.
+Category: Informational                                         Ericsson
+ISSN: 2070-1721                                           R. Hinden, Ed.
+                                                    Check Point Software
+                                                           February 2020
+
+
+                      RFC Editor Model (Version 2)
+
+Abstract
+
+   The RFC Editor model described in this document divides the
+   responsibilities for the RFC Series into three functions: the RFC
+   Series Editor, the RFC Production Center, and the RFC Publisher.
+   Internet Architecture Board (IAB) oversight via the RFC Series
+   Oversight Committee (RSOC) is described, as is the relationship
+   between the IETF Administration Limited Liability Company and the
+   RSOC.  This document reflects the experience gained with "RFC Editor
+   Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to
+   replace all references to the IETF Administrative Support Activity
+   (IASA) and related structures with those defined by the IASA 2.0
+   Model.
+
+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/rfc8728.
+
+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
+     1.1.  The RFC Editor Function
+   2.  RFC Editor Model
+     2.1.  RFC Series Editor
+       2.1.1.  Strategic Leadership and Management of the Publication
+               and Production Functions
+       2.1.2.  Representation of the RFC Series
+         2.1.2.1.  Representation to the IETF
+         2.1.2.2.  External Representation
+       2.1.3.  Development of RFC Production and Publication
+       2.1.4.  Development of the RFC Series
+       2.1.5.  Workload
+       2.1.6.  Qualifications
+       2.1.7.  Conflict of Interest
+     2.2.  RFC Production Center
+     2.3.  RFC Publisher
+   3.  Committees
+     3.1.  RFC Series Oversight Committee (RSOC)
+       3.1.1.  RSOC Composition
+   4.  Administrative Implementation
+     4.1.  Vendor Selection for the Production and Publisher Functions
+     4.2.  Budget
+     4.3.  Disagreements among Entities Related to the RFC Editor
+     4.4.  Issues with Contractual Impact
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   IAB Members at the Time of Approval
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   This document reflects the experience gained with "RFC Editor Model
+   (Version 1)", documented in [RFC5620], and updates the RFC Editor
+   Model (Version 2) to be aligned with the new IASA 2.0 Model [RFC8711]
+   that creates the IETF Administration Limited Liability Company (IETF
+   LLC) managed by a board of directors (IETF LLC Board).  As part of
+   the IASA 2.0 Model, the IETF Administrative Oversight Committee
+   (IAOC) is eliminated, and its oversight and advising functions
+   transferred to the new IETF LLC.  This document obsoletes [RFC6635]
+   to replace all references to the IASA and related structures with
+   those defined by the IASA 2.0 Model.
+
+   The IAB, on behalf of the Internet technical community, is concerned
+   with ensuring the continuity of the RFC Series, orderly RFC Editor
+   succession, RFC quality, and RFC document accessibility.  The IAB is
+   also sensitive to the concerns of the IETF LLC about providing the
+   necessary services in a cost-effective and efficient manner.
+
+   The previous RFC Editor model [RFC5620] was first approved by the IAB
+   in October 2008, and our understanding of the model has evolved with
+   our experience since.  During the implementation of version 1 of the
+   model [RFC5620], it was quickly realized that the role of the RFC
+   Series Editor (RSE) and the oversight responsibilities needed to be
+   structured differently.  In order to gain experience with "running
+   code", a transitional RSE was hired who analyzed the managerial
+   environment and provided recommendations.  This was followed by the
+   appointment of an acting RSE, who ably managed the series while work
+   was undertaken to select and hire a permanent RSE.  This version of
+   the model is based on the recommendations of both temporary RFC
+   Series Editors and the extensive discussion in the IETF community, on
+   the rfc-interest list, and within the IAB.
+
+   This document, and the resulting structures, will be modified as
+   needed through normal procedures.  The RSE, and the IAB, through the
+   RFC Series Oversight Committee (see Section 3.1), will continue to
+   monitor discussions within the community about potential adjustments
+   to the RFC Editor model and recognize that the process described in
+   this document may need to be adjusted to align with any changes that
+   result from such discussions; hence, the version number in the title.
+
+   The IAB maintains its responsibilities as defined in [RFC2850].
+
+1.1.  The RFC Editor Function
+
+   The RFC Series is described in [RFC8729].  Its Section 3.1 defines
+   "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.
+
+   RFC 8729 does not explore the internal organization of the RFC
+   Editor.  However, RFC 8729 envisions changes in the RFC Editor
+   organizational structure.  There have been several iterations on
+   efforts to improve and clarify this structure.  These have been led
+   by the IAB, in consultation with the community and many leadership
+   bodies within the community.  This first resulted in the publication
+   of [RFC5620] and then in further discussions leading to the
+   publication of [RFC6635].  Some of the details on this evolution can
+   be found below.  In undertaking this evolution, the IAB considered
+   changes that increase flexibility and operational support options,
+   provide for the orderly succession of the RFC Editor, and ensure the
+   continuity of the RFC Series, while maintaining RFC quality,
+   maintaining timely processing, ensuring document accessibility,
+   reducing costs, and increasing cost transparency.  The model set
+   forth below describes the internal organization of the RFC Editor,
+   while remaining consistent with RFC 8729.
+
+   Note that RFC 8729 uses the term "RFC Editor function" or "RFC
+   Editor" as the collective set of responsibilities for which this memo
+   provides a model for internal organization.  This memo defines the
+   term "RFC Series Editor" or "Series Editor" for one of the
+   organizational components.
+
+2.  RFC Editor Model
+
+   The RFC Editor model divides the responsibilities for the RFC Series
+   into the following components:
+
+   *  RFC Series Editor (RSE)
+
+   *  RFC Production Center
+
+   *  RFC Publisher
+
+   The structure and relationship of the components of the RFC Series
+   production and process is schematically represented by Figure 1.  The
+   picture does not depict oversight and escalation relations.  It does
+   include the streams and their managers (which are not part of the RFC
+   Series Editor, the RFC Production Center, or Publisher facilities) in
+   order to more fully show the context in which the RFC Series Editor
+   operates.
+
+                                         +-------------+
+                                         |             |
+                          +--------------+     IAB     <----------+
+                          |              |             |          |
+                          |              |=============|          |
+                          |              |             |          |
+                          |              |     RSOC    <----------+
+                          |              |             |          |
+                          |              +-------+-----+     +----+----+
+                          |                      |           |         |
+                          |          +...........|.........+ |Community|
+                          |          .           |         . |   at    |
+                          |          .   +-------V-----+   . |  Large  |
+                          |          .   |             |   . |         |
+                          |          .   |     RFC     |   . +----+----+
+                          |          .   |    Series   |   .      |
+                          |          .   |    Editor   <----------+
+                          |          .   |             |   .
+                          |          .   +-+---------+-+   .
+                          |          .     |         |     .
+   +-------------+  +-----V-------+  .  +--V--+   +--V--+  .     +-----+
+   |             |  |             |  .  |     |   |     |  .     |     |
+   | Independent |  | Independent |  .  | RFC |   |     |  .     |  E  |
+   |   Authors   +--> Submission  +----->     |   |     |  .     |  n  |
+   |             |  |   Editor    |  .  |  P  |   |     |  .     |  d  |
+   |             |  |             |  .  |  r  |   | RFC |  .     |     |
+   +-------------+  +-------------+  .  |  o  |   |     |  .     |  U  |
+   +-------------+  +-------------+  .  |  d  |   |  P  |  .     |  s  |
+   |             |  |             |  .  |  u  |   |  u  |  .     |  e  |
+   |     IAB     +-->     IAB     +----->  c  |   |  b  |  .     |  r  |
+   |             |  |             |  .  |  t  |   |  l  |  .     |  s  |
+   +-------------+  +-------------+  .  |  i  +--->  i  +-------->     |
+   +-------------+  +-------------+  .  |  o  |   |  s  |  .     |  &  |
+   |             |  |             |  .  |  n  |   |  h  |  .     |     |
+   |    IRTF     +-->     IRSG    +---->|     |   |  e  |  .     |  R  |
+   |             |  |             |  .  |  C  |   |  r  |  .     |  e  |
+   +-------------+  +-------------+  .  |  e  |   |     |  .     |  a  |
+   +-------------+  +-------------+  .  |  n  |   |     |  .     |  d  |
+   |             |  |             |  .  |  t  |   |     |  .     |  e  |
+   |    IETF     +-->    IESG     +----->  e  |   |     |  .     |  r  |
+   |             |  |             |  .  |  r  |   |     |  .     |  s  |
+   +-------------+  +-------------+  .  +-----+   +-----+  .     +-----+
+                                     .                     .
+                                     +..... RFC Editor ....+
+
+          Figure 1: Structure of RFC Series Production and Process
+
+   In this model, documents are produced and approved through multiple
+   document streams.  The stream manager for each stream is responsible
+   for the content of that stream.  The four streams that now exist are
+   described in [RFC8729].  The RFC Editor function is responsible for
+   the packaging and distribution of the documents.  As such, documents
+   from these streams are edited and processed by the Production Center
+   and published by the Publisher.  The RFC Series Editor will exercise
+   strategic leadership and management over the activities of the RFC
+   Publisher and the RFC Production Center (both of which can be seen as
+   back-office functions) and will be the entity that:
+
+   *  Represents the RFC Series and the RFC Editor function within the
+      IETF and externally.
+
+   *  Leads the community in the design of improvements to the RFC
+      Series.
+
+   *  Is responsible for planning and seeing to the execution of
+      improvements in the RFC Editor production and access processes.
+
+   *  Is responsible for the content of the rfc-editor.org web site,
+      which is operated and maintained by the RFC Publisher.
+
+   *  Is responsible for developing consensus versions of vision and
+      policy documents.  These documents will be reviewed by the RFC
+      Series Oversight Committee (Section 3.1) and subject to its
+      approval before final publication.
+
+   These responsibilities are defined below, although the specific work
+   items under them are a matter for the actual employment contract and
+   its Statement of Work (SOW).
+
+   The IAB maintain its chartered responsibility as defined in
+   [RFC2850].  More details on the oversight by the IAB via the RFC
+   Series Oversight Committee (RSOC) can be found in Section 3.1.  For
+   example, the RSE does not have the direct authority to hire or fire
+   RFC Editor contractors or personnel.
+
+2.1.  RFC Series Editor
+
+   The RFC Series Editor is the individual with overall responsibility
+   for the quality, continuity, and evolution of the RFC Series.
+
+   The RSE is appointed by the IAB, but formally hired by the IETF LLC.
+   The IAB delegates the direct oversight over the RSE to the RSOC,
+   which it appoints.
+
+   The RSE is expected to cooperate closely with the IETF LLC and the
+   stream managers.
+
+2.1.1.  Strategic Leadership and Management of the Publication and
+        Production Functions
+
+   With respect to the RFC Publisher and Production Center functions,
+   the RSE provides input to the IETF LLC budget, SOWs, and manages
+   vendor selection processes.  The RSE performs annual reviews of the
+   RFC Production Center and Publisher function, which are then provided
+   to the RSOC, the IETF LLC, and the community.  Normally, private
+   financial details would not be included in a public version unless
+   the IETF LLC concludes it is necessary to make such information
+   public.
+
+   The RSE is responsible for the performance of the RFC Production
+   Center and Publisher.  The RSE is responsible for issues that go
+   beyond the RFC Production Center or Publisher functions, such as
+   cross-stream coordination of priorities.  Issues that require changes
+   to the budget or contracts shall be brought to the attention of the
+   IETF LLC by the RSE.
+
+   The RSE is also responsible for creating documentation and structures
+   that will allow for continuity of the RFC Series in the face of
+   changes in contracts and personnel.
+
+   Vendor selection for the RFC Production Center and Publisher
+   functions is done in cooperation with the streams and under final
+   authority of the IETF LLC.  Details on this process can be found in
+   Section 4.1.
+
+2.1.2.  Representation of the RFC Series
+
+   The RSE is the primary representative of the RFC Series.  This
+   representation is important both internally, relative to the IETF,
+   and externally.
+
+2.1.2.1.  Representation to the IETF
+
+   The RSE is the primary point of contact to the IETF on matters
+   relating to the RFC Series in general, or policy matters relating to
+   specific documents.  Issues of practical details in the processing of
+   specific documents are generally worked through directly with the RFC
+   Production Center staff.
+
+   This includes providing suitable reports to the community at large,
+   providing email contact for policy questions and inputs, and enabling
+   and participating in suitable on-line forums for discussion of issues
+   related to the RFC Series.
+
+   Due to the history and nature of the interaction between the RSE and
+   the IETF, certain principles, described in the following subsections,
+   must be understood and adhered to by the RSE in his or her
+   interactions with the community.  These apply to the representation
+   function, as well as to the leadership the RSE provides for
+   production and series development.
+
+2.1.2.1.1.  Volunteerism
+
+   The vast majority of Internet technical community work is led,
+   initiated, and done by community volunteers, including oversight,
+   policy making, and direct production of, for example, many software
+   tools.  The RSE, while not a volunteer, is dependent upon these
+   volunteer participants.  Also, the spirit of the community is heavily
+   focused on and draws from these volunteers.  As such, the RSE needs
+   to support the vitality and effectiveness of volunteer participation.
+
+2.1.2.1.2.  Policy Authority
+
+   All decisions are to be made in the overall interest of the broader
+   Internet community.  The RSE is responsible for identifying
+   materially concerned interest groups within the Internet community
+   and reaching out to them.  Those interest groups include at least the
+   IETF community, the IRTF community, the network research community,
+   and the network operations community.  Other interest groups might
+   also be materially interested.
+
+   The RSE must consult with the community on policy issues.  The RSE
+   works with the community to achieve policy that meets the overall
+   quality, continuity, and evolution goals the RSE is charged with
+   meeting.  As described in Section 3.1, the RSE reports the results of
+   such interactions to the RSOC, including a description of the
+   outreach efforts and the specific recommendations on policy.  This
+   enables the RSOC to provide the oversight the IAB is required to
+   apply, as well as to confirm that the Internet community has been
+   properly consulted and considered in making policy.
+
+2.1.2.2.  External Representation
+
+   From time to time, individuals or organizations external to the IETF
+   need a contact person to talk to about the RFC Series.  The RSE, or
+   the RSE's designate, serves this role.
+
+   Over time, the RSE should determine what, if any, means should be
+   employed to increase end-user awareness of the series, to reinforce
+   the stature of the series, and to provide the contact point for
+   outside parties seeking information on the series or the Editor.
+
+2.1.3.  Development of RFC Production and Publication
+
+   Closely related to providing strategic leadership and management to
+   the RFC Production Center and Publisher functions is the need to
+   develop and improve those functions.  The RSE is responsible for
+   ensuring that such ongoing development takes place.
+
+   This effort must include the dimensions of document quality,
+   timeliness of production, and accessibility of results.  It must also
+   specifically take into account issues raised by the IETF community,
+   including all the streams feeding into the RFC Editor function.
+
+2.1.4.  Development of the RFC Series
+
+   In order to develop the RFC Series, the RSE is expected to develop a
+   relationship with the Internet technical community.  The Editor is
+   expected to engage with the Internet technical community in a process
+   of articulating and refining a vision for the series and its
+   continuous evolution.  The RSE is also expected to engage other users
+   of the RFC Series, in particular, the consumers of these documents,
+   such as those people who use them to specify products, write code,
+   test behaviors, or other related activities.
+
+   Concretely:
+
+      The RSE is responsible for the coordination of discussion on
+      series evolution among the series' stream participants and the
+      broader Internet technical community.
+
+      In time, the RSE is expected to develop and refine a vision for
+      the RFC Series, including examining:
+
+      -  The RFC Series, as it continues to evolve.  The RSE is expected
+         to take a broad view and look for the best ways to evolve the
+         series for the benefit of the entire Internet community.  As
+         such, the RSE may even consider evolution beyond the historical
+         'by engineers for engineers' emphasis; and
+
+      -  Its publication-technical environment, by looking at whether it
+         should be slowly changing in terms of publishing and archiving
+         techniques -- particularly to better serve the communities that
+         produce and depend on the RFC Series.  For example, all of
+         those communities have been slowly changing to include a
+         significant population of multi-lingual individuals or non-
+         native speakers of English.  Another example is that some of
+         these constituencies also have shifted to include significant
+         groups whose primary focus is on the constraints and
+         consequences of network engineering, rather than a primary
+         interest in the engineering issues themselves.
+
+   For this type of responsibility, the RSE cooperates closely with the
+   community, and operates under oversight of the RSOC: thus,
+   ultimately, under oversight of the IAB.
+
+2.1.5.  Workload
+
+   On average, the job is expected to take half of a full-time
+   equivalent position (FTE, thus approximately 20 hrs per week), with
+   the workload per week nearing full time during IETF weeks.  In
+   addition, the job is expected to take more than 20 hours per week in
+   the first few months of the engagement and when involved in special
+   projects.
+
+2.1.6.  Qualifications
+
+   The RFC Series Editor is a senior technology professional.  The
+   following qualifications are desired:
+
+   1.   Strategic leadership and management experience fulfilling the
+        requirements outlined in this document, the many aspects of this
+        role, and the coordination of the overall RFC Editor process.
+
+   2.   Good understanding of the English language and technical
+        terminology related to the Internet.
+
+   3.   Good communication skills.
+
+   4.   Experience with editorial processes.
+
+   5.   Ability to develop strong understanding of the IETF and RFC
+        process.
+
+   6.   Independent worker.
+
+   7.   Willingness to, and availability for, travel.
+
+   8.   The ability to work effectively in a multi-actor and matrixed
+        environment with divided authority and responsibility similar to
+        that described in this document.
+
+   9.   Experience with and ability to participate in, and manage,
+        activities by email and teleconferences, not just face-to-face
+        interactions.
+
+   10.  Demonstrated experience in strategic planning and the management
+        of entire operations.
+
+   11.  Experience as an RFC author.
+
+2.1.7.  Conflict of Interest
+
+   The RSE is expected to avoid even the appearance of conflict of
+   interest or judgment in performing these roles.  To ensure this, the
+   RSE will be subject to a conflict of interest policy established by
+   the IETF LLC.
+
+2.2.  RFC Production Center
+
+   The RFC Production Center function is performed by a paid contractor,
+   and the contractor's responsibilities include the following:
+
+   1.   Editing inputs from all RFC streams to comply with the RFC Style
+        Manual, under the direction of the RSE;
+
+   2.   Creating records of edits performed on documents;
+
+   3.   Identifying where editorial changes might have technical impact
+        and seeking necessary clarification;
+
+   4.   Engaging in dialog with authors, document shepherds, IANA, and/
+        or stream-dependent contacts when clarification is needed;
+
+   5.   Creating records of dialog with document authors;
+
+   6.   Requesting advice from the RFC Series Editor as needed;
+
+   7.   Providing suggestions to the RFC Series Editor as needed;
+
+   8.   Providing sufficient resources to support reviews of RFC
+        Publisher performance by the RFC Series Editor and external
+        reviews of the RFC Editor function initiated by the IAB or IETF
+        LLC;
+
+   9.   Coordinating with IANA to ensure correct documentation of IANA-
+        performed protocol registry actions;
+
+   10.  Assigning RFC numbers;
+
+   11.  Establishing publication readiness of each document through
+        communication with the authors, document shepherds, IANA, and/or
+        stream-dependent contacts, and, if needed, with the RFC Series
+        Editor;
+
+   12.  Forwarding documents that are ready for publication to the RFC
+        Publisher;
+
+   13.  Forwarding records of edits and author dialog to the RFC
+        Publisher so these can be preserved;
+
+   14.  Liaising with the streams as needed.
+
+   All these activities will be done under the general direction, but
+   not day-to-day management, of the RSE and need some level of
+   coordination with various submission streams and the RSE.
+
+   The RFC Production Center contractor is to be selected through an
+   IETF LLC Request for Proposal (RFP) process as described in
+   Section 4.1.
+
+2.3.  RFC Publisher
+
+   The RFC Publisher responsibilities include the following:
+
+   1.  Announcing and providing on-line access to RFCs.
+
+   2.  Providing an on-line system to submit RFC Errata.
+
+   3.  Providing on-line access to approved RFC Errata.
+
+   4.  Providing backups.
+
+   5.  Providing storage and preservation of records.
+
+   6.  Authenticating RFCs for legal proceedings.
+
+   All these activities will be done under the general direction, but
+   not day-to-day management, of the RSE and need some level of
+   coordination with various submission streams and the RSE.
+
+   The RFC Publisher contractor is to be selected through an IETF LLC
+   RFP process as described in Section 4.1.
+
+3.  Committees
+
+3.1.  RFC Series Oversight Committee (RSOC)
+
+   The IAB is responsible for the oversight of the RFC Series and acts
+   as a body for final conflict resolution, including the process
+   described in Section 4.3.
+
+   In order to provide continuity over periods longer than the NomCom
+   appointment cycle [RFC8713] and assure that oversight includes
+   suitable subject matter expertise, the IAB will establish a group
+   that implements oversight for the IAB, the RFC Series Oversight
+   Committee (RSOC).
+
+   The RSOC will act with authority delegated from the IAB: in general,
+   it will be the RSOC that will approve consensus policy and vision
+   documents as developed by the RSE in collaboration with the
+   community.  While it is expected that the IAB will exercise due
+   diligence in its supervision of the RSOC, the RSOC should be allowed
+   the latitude to do its job without undue interference from the IAB.
+   Therefore, it is expected that the IAB will accord RSOC reports and
+   recommendations the benefit of the doubt.
+
+   For all decisions that affect the RSE individually (e.g., hiring and
+   firing), the RSOC prepares recommendations for the IAB.  The final
+   recommendation to the IETF LLC is the responsibility of the IAB,
+   after discussion with RSOC on the recommendations.  For instance the
+   RSOC would do the following:
+
+   *  perform annual reviews of the RSE and report the result of these
+      reviews to the IAB.
+
+   *  manage RSE candidate selection and advise the IAB on candidate
+      appointment (in other words, select the RSE subject to IAB
+      approval).
+
+   RSOC members are expected to recognize potential conflicts of
+   interest and behave accordingly.
+
+   For the actual recruitment and selection of the RSE, the RSOC will
+   propose a budget for the search process.  It will work with the IETF
+   LLC to refine that budget and develop remuneration criteria and an
+   employment agreement or contracting plans, as appropriate.
+
+   The RSOC will be responsible for ensuring that the RFC Series is run
+   in a transparent and accountable manner.
+
+   The RSOC shall develop and publish its own rules of order.
+
+   The initial RSOC was charged with designing and executing a
+   solicitation, search, and selection process for the first actual (not
+   transitional or "acting") RSE appointment.  That process involved
+   iteration on this and related documents and evaluation of various
+   strategies and options.  During the creation of what became
+   [RFC6635], it was expected that the RSOC would describe the process
+   it ultimately selected to the community.  The RSOC did involve the
+   community in interim considerations when that was likely to be of
+   value.  Following completion of the selection process, the RSOC will
+   determine the best way to share information learned and experience
+   gained with the community and determine how to best preserve that
+   information for future use.
+
+3.1.1.  RSOC Composition
+
+   The RSOC will operate under the authority of the IAB, with the IAB
+   retaining final responsibility.  The IAB will delegate authority and
+   responsibility to the RSOC as appropriate and as RSOC and RSE
+   relationships evolve.  The RSOC will include people who are not
+   current IAB members.  Currently, this is aligned with the IAB program
+   structure.  The IAB will designate the membership of the RSOC with
+   the following goals: preserving effective stability; keeping it small
+   enough to be effective, and keeping it large enough to provide
+   general Internet community expertise, specific IETF expertise,
+   publication expertise, and stream expertise.  Members serve at the
+   pleasure of the IAB and are expected to bring a balance between
+   short- and long-term perspectives.  Specific input about, and
+   recommendations of, members will be sought from the streams, the IETF
+   LLC, and the RSE.
+
+   In addition to the members from outside of the IAB appointed to the
+   RSOC, IAB members may participate as full members of the RSOC.  Under
+   most circumstances, there will be a specific individual IAB member
+   appointed by the IAB as the program lead, who will be a full member
+   of the RSOC.  This member's role is distinct from any RSOC-internal
+   organizational roles, such as would be created by the RSOC choosing
+   to appoint a chair from among its members.  Other IAB members may
+   choose to be full members of the RSOC, with the consent of the IAB.
+   This consent is primarily concerned with avoiding overpopulating the
+   RSOC and providing it with relatively stable membership, which will
+   work best if it is not too large a committee.
+
+   The IETF LLC will appoint an individual to serve as its liaison to
+   the RSOC.  The RSE and the IETF LLC Liaison will serve as non-voting
+   ex officio members of the RSOC.  Either or both can be excluded from
+   its discussions if necessary.
+
+4.  Administrative Implementation
+
+   The exact implementation of the administrative and contractual
+   activities described here are a responsibility of the IETF
+   Administration Limited Liability Company [RFC8711] in cooperation
+   with the RFC Series Editor.  The authority structure is described in
+   Figure 2.
+
+                   +----------------+       +----------------+
+                   |                |       |                |
+                   |      IAB       |       |    IETF LLC    |
+                   |                |       |                |
+                   +==========+-----+       +-+--------------+
+                   |          |               .
+                   |   RSOC   |               .
+                   |          |               .
+                   +----+-----+               .
+                        |                     .
+                        |                     .
+                        |   ...................
+                        |   .                 .
+               +--------V---V----+            .
+               |                 |            .
+               |       RFC       |            .
+               |      Series     |            .
+               |      Editor     |            .
+               |                 |            .
+               +--------+--------+            .
+                        |                     .
+                        |        .................
+                        |        .               .
+                        +--+----------------+    .
+                           |     .          |    .
+                           |     .          |    .
+                       +---V-----V--+    +--V----V---+
+                       |    RFC     |    |    RFC    |
+                       | Production |    | Publisher |
+                       |   Center   |    |           |
+                       +------------+    +-----------+
+
+                         Legend:
+
+                         -------    IAB RFC Series Oversight
+                         .......    IETF LLC Contract/Budget Oversight
+
+              Figure 2: Authority Structure of the RFC Series
+
+4.1.  Vendor Selection for the Production and Publisher Functions
+
+   As stated earlier, vendor selection is done in cooperation with the
+   streams and under the final authority of the IETF LLC.
+
+   The RSE owns and develops the work definition (the SOW) and
+   participates in the IETF LLC vendor selection process.  The work
+   definition is created within the IETF LLC budget and takes into
+   account the stream managers and community input.
+
+   The process to select and contract for an RFC Production Center, RFC
+   Publisher, and other RFC-related services, is as follows:
+
+   *  The IETF LLC establishes the contract process, including the steps
+      necessary to issue an RFP when necessary, the timing, and the
+      contracting procedures.
+
+   *  The IETF LLC establishes the Selection Committee, which will
+      consist of the RSE, the IETF LLC Executive Director, and other
+      members selected by the RSOC and the IETF LLC.  The Committee
+      shall be chaired by the RSE.
+
+   *  The Selection Committee selects the vendor, subject to the
+      successful negotiation of a contract approved by the IETF LLC.  In
+      the event that a contract cannot be reached, the matter shall be
+      referred to the Selection Committee for further action.
+
+   *  The Selection Committee may select an RFC Publisher either through
+      the IETF LLC RFP process or, at the Committee's option, the
+      Committee may select the IETF Secretariat to provide RFC Publisher
+      services, subject to negotiations in accordance with the IETF LLC
+      procedures.
+
+4.2.  Budget
+
+   The expenses discussed in this document are not new expenses.  They
+   have been and remain part of the IETF Administration Limited
+   Liability Company [RFC8711] budget.
+
+   The RFC Series portion of the IETF LLC budget shall include funding
+   to support the RSE, RFC Production Center, RFC Publisher, and the
+   Independent Stream.
+
+   The IETF LLC has the responsibility to approve the total RFC Editor
+   budget (and the authority to deny it).  The RSE must work within the
+   IETF LLC budgetary process.
+
+   The RSE is responsible for managing the RFC Editor function to
+   operate within those budgets.  If production needs change, the RSE is
+   responsible for working with the Production Center, and where
+   appropriate, other RFC Editor component institutions, relevant
+   streams, and/or the RSOC to determine what the correct response
+   should be.  If they agree that a budgetary change is needed, that
+   decision needs to be taken to the IETF LLC.
+
+4.3.  Disagreements among Entities Related to the RFC Editor
+
+   The RFC Series Editor and the RFC Production Center and Publisher
+   facilities work with the various streams to produce RFCs.
+   Disagreements may arise between these entities during the execution
+   of the RFC Editor operations.  In particular, different streams may
+   disagree with each other, or disagree with the RFC Editor function.
+   Potentially, even the RSOC or the IETF LLC could find themselves in
+   disagreement with some aspect of the RFC Editor operations.  Note
+   that disagreements between an author and the RFC Production Center
+   are not cross-entity issues, and they are to be resolved by the RSE,
+   in accordance with the rest of this document.
+
+   If such cross-entity disagreements arise, the community would
+   generally hope that they can be resolved politely and directly.
+   However, this is not always possible.  At that point, any relevant
+   party would first formally request a review and reconsideration of
+   the decision.  If the party still disagrees after the
+   reconsideration, that party may ask the RSE to decide or, especially
+   if the RSE is involved, the party may ask the IAB Chair (for a
+   technical or procedural matter) to mediate or appoint a mediator to
+   aid in the discussions, although he or she not is obligated to do so.
+   All parties should work informally and in good faith to reach a
+   mutually agreeable conclusion.  As noted below, any such issues that
+   involve contractual matters must be brought to the attention of the
+   IETF LLC.  If the IAB Chair is asked to assist in resolving the
+   matter, the Chair may ask for advice or seek assistance from anyone
+   the Chair deems helpful.  The Chair may also alert any appropriate
+   individuals or organizations to the existence of the issue.
+
+   If such a conclusion is not possible through the above less formal
+   processes, then the matter must be registered with the RFC Series
+   Oversight Committee.  The RSOC may choose to offer advice to the RSE
+   or more general advice to the parties involved and may ask the RSE to
+   defer a decision until it formulates its advice.  However, if a
+   timely decision cannot be reached through discussion, mediation, and
+   mutual agreement, the RSE is expected to make whatever decisions are
+   needed to ensure the smooth operation of the RFC Editor function;
+   those decisions are final.
+
+   The RSE may make final decisions unilaterally only to assure the
+   functioning of the process, and only while there is an evaluation of
+   current policies to determine whether they are appropriately
+   implemented in the decision or need adjustment.  In particular, it
+   should be noted that final decisions about the technical content of
+   individual documents are the exclusive responsibility of the stream
+   approvers from which those documents originate, as shown in the
+   illustration in Figure 1.
+
+   If informal agreements cannot be reached, then formal RSOC review and
+   decision making may be required.  If so, the RSE must present the
+   issues involved to the community so that the community is aware of
+   the situation.  The RSE will then report the issue to the RSOC for
+   formal resolution by the RSOC with confirmation by the IAB in its
+   oversight capacity.
+
+   IAB and community discussion of any patterns of disputes are expected
+   to inform future changes to RFC Series policies, including possible
+   updates to this document.
+
+4.4.  Issues with Contractual Impact
+
+   If a disagreement or decision has immediate or future contractual
+   consequences, it falls under [RFC8711].  If this happens, the RSE
+   must identify the issue and provide advice to the IETF LLC.
+   Additionally, if the RSOC has also developed advice, it should
+   forward that advice to the IETF LLC.
+
+   The IETF LLC must notify the RSOC and IAB regarding the action it
+   concludes is required to resolve the issue based on its applicable
+   procedures and provisions in the relevant contracts.
+
+5.  IANA Considerations
+
+   This document defines several functions within the overall RFC Editor
+   structure, and it places the responsibility for coordination of
+   registry value assignments with the RFC Production Center.  The IETF
+   LLC will facilitate the establishment of the relationship between the
+   RFC Production Center and IANA.
+
+   This document does not create a new registry nor does it register any
+   values in existing registries, and no IANA action is required.
+
+6.  Security Considerations
+
+   The same security considerations as those in [RFC8729] apply.  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, originals
+   that are not machine readable) need to be secured against any kind of
+   data storage failure.
+
+   The IETF LLC should take these security considerations into account
+   during the implementation and enforcement of the RFC Editor component
+   contracts.
+
+7.  References
+
+7.1.  Normative References
+
+   [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>.
+
+   [RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
+              Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
+              2012, <https://www.rfc-editor.org/info/rfc6635>.
+
+   [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>.
+
+   [RFC8729]  Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and
+              RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February
+              2020, <https://www.rfc-editor.org/info/rfc8729>.
+
+7.2.  Informative References
+
+   [RFC5620]  Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)",
+              RFC 5620, DOI 10.17487/RFC5620, August 2009,
+              <https://www.rfc-editor.org/info/rfc5620>.
+
+   [RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
+              Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
+              Confirmation, and Recall Process: Operation of the IETF
+              Nominating and Recall Committees", BCP 10, RFC 8713,
+              DOI 10.17487/RFC8713, February 2020,
+              <https://www.rfc-editor.org/info/rfc8713>.
+
+IAB Members at the Time of Approval
+
+   Internet Architecture Board Members at the time this document was
+   approved for publication 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
+
+Acknowledgments
+
+   The RFC Editor model was conceived and discussed in hallways and on
+   mailing lists.  The first iteration of the text on which this
+   document is based was first written by Leslie Daigle, Russ Housley,
+   and Ray Pelletier.  In addition to the members of the IAOC and IAB in
+   conjunction with those roles, major and minor contributions were made
+   by (in alphabetical order): Bob Braden, Brian Carpenter, Sandy
+   Ginoza, Joel M. Halpern, Alfred Hoenes, Paul Hoffman, John Klensin,
+   Subramanian Moonesamy, Alice Russo, and Jim Schaad.
+
+   The IAOC members at the time RFC 6635 was approved were (in
+   alphabetical order): Bernard Aboba (ex officio), Eric Burger, Dave
+   Crocker, Marshall Eubanks, Bob Hinden, Russ Housley (ex officio), Ole
+   Jacobsen, Ray Pelletier (non-voting), and Lynn St. Amour (ex
+   officio).
+
+   The IAB members at the time the initial RFC Editor model (Version 1,
+   RFC 5620) 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.
+
+   The IAB members at the time RFC 6635 was approved were (in
+   alphabetical order): Bernard Aboba, Ross Callon, Alissa Cooper,
+   Spencer Dawkins, Joel Halpern, Russ Housley, David Kessens, Olaf
+   Kolkman, Danny McPherson, Jon Peterson, Andrei Robachevsky, Dave
+   Thaler, and Hannes Tschofenig.  In addition, at the time of approval
+   of RFC 6635, the IAB included two ex officio members: Mary Barnes who
+   was serving as the IAB Executive Director, and Lars Eggert, who was
+   serving as the IRTF Chair.
+
+   Bob Hinden served as document editor for this RFC to align it with
+   the IASA 2.0 structure.
+
+Authors' Addresses
+
+   Olaf Kolkman (editor)
+   Internet Society
+
+   Email: kolkman@isoc.org
+
+
+   Joel M. Halpern (editor)
+   Ericsson
+
+   Email: joel.halpern@ericsson.com
+
+
+   Robert M. Hinden (editor)
+   Check Point Software
+   959 Skyway Road
+   San Carlos, CA 94070
+   United States of America
+
+   Email: bob.hinden@gmail.com