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: [email protected]


  Leslie L. Daigle (editor)

  Email: [email protected]

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.