draft-ietf-iasa2-rfc4844-bis-02.txt   rfc8729.txt 
Network Working Group R. Housley, Ed. Internet Architecture Board (IAB) R. Housley, Ed.
Internet-Draft Vigil Security Request for Comments: 8729
Obsoletes: 4844 (if approved) L. Daigle, Ed. Obsoletes: 4844 L. Daigle, Ed.
Intended status: Informational Thinking Cat Category: Informational February 2020
Expires: October 17, 2019 April 15, 2019 ISSN: 2070-1721
The RFC Series and RFC Editor The RFC Series and RFC Editor
draft-ietf-iasa2-rfc4844-bis-02
Abstract Abstract
This document describes the framework for an RFC Series and an RFC This document describes the framework for an RFC Series and an RFC
Editor function that incorporate the principles of organized Editor function that incorporate the principles of organized
community involvement and accountability that has become necessary as community involvement and accountability that has become necessary as
the Internet technical community has grown, thereby enabling the RFC the Internet technical community has grown, thereby enabling the RFC
Series to continue to fulfill its mandate. Series to continue to fulfill its mandate. This document obsoletes
RFC 4844.
Cover Note:
{{ RFC Editor: Please remove this cover note prior to publication. }}
The IASA2 WG asks the IAB to publish this replacement for RFC 4844.
The document is changed for alignment with the new structure for the
IETF Administrative Support Activity (IASA), eliminating all
references to the IETF Administrative Oversight Committee (IAOC).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on October 17, 2019. 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . 5 2. RFC Series Mission
3. Roles and Responsibilities . . . . . . . . . . . . . . . . . 5 3. Roles and Responsibilities
3.1. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. RFC Editor
3.2. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. IAB
3.3. Operational Oversight . . . . . . . . . . . . . . . . . . 6 3.3. Operational Oversight
3.4. Policy Oversight . . . . . . . . . . . . . . . . . . . . 6 3.4. Policy Oversight
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Framework
4.1. Document Approval . . . . . . . . . . . . . . . . . . . . 7 4.1. Document Approval
4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Definition
4.1.2. Operational Implementation . . . . . . . . . . . . . 8 4.1.2. Operational Implementation
4.1.3. Process Change . . . . . . . . . . . . . . . . . . . 8 4.1.3. Process Change
4.1.4. Existing Approval Process Documents . . . . . . . . . 8 4.1.4. Existing Approval Process Documents
4.2. Editing, Processing, and Publication of Documents . . . . 8 4.2. Editing, Processing, and Publication of Documents
4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Definition
4.2.2. Operational Implementation . . . . . . . . . . . . . 9 4.2.2. Operational Implementation
4.2.3. Process Change . . . . . . . . . . . . . . . . . . . 9 4.2.3. Process Change
4.2.4. Existing Process Documents . . . . . . . . . . . . . 9 4.2.4. Existing Process Documents
4.3. Archiving, Indexing, and Accessibility . . . . . . . . . 9 4.3. Archiving, Indexing, and Accessibility
4.3.1. Definition . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Definition
4.3.2. Operational Implementation . . . . . . . . . . . . . 10 4.3.2. Operational Implementation
4.3.3. Process Change . . . . . . . . . . . . . . . . . . . 10 4.3.3. Process Change
4.3.4. Existing Process Documents . . . . . . . . . . . . . 10 4.3.4. Existing Process Documents
4.4. Series-Wide Guidelines and Rules . . . . . . . . . . . . 10 4.4. Series-Wide Guidelines and Rules
4.4.1. Definition . . . . . . . . . . . . . . . . . . . . . 10 4.4.1. Definition
4.4.2. Operational Implementation . . . . . . . . . . . . . 11 4.4.2. Operational Implementation
4.4.3. Process Change . . . . . . . . . . . . . . . . . . . 11 4.4.3. Process Change
4.4.4. Existing Process Documents . . . . . . . . . . . . . 11 4.4.4. Existing Process Documents
5. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. RFC Streams
5.1. RFC Approval Processes . . . . . . . . . . . . . . . . . 12 5.1. RFC Approval Processes
5.1.1. IETF Document Stream . . . . . . . . . . . . . . . . 12 5.1.1. IETF Document Stream
5.1.2. IAB Document Stream . . . . . . . . . . . . . . . . . 12 5.1.2. IAB Document Stream
5.1.3. IRTF Document Stream . . . . . . . . . . . . . . . . 12 5.1.3. IRTF Document Stream
5.1.4. Independent Submission Stream . . . . . . . . . . . . 13 5.1.4. Independent Submission Stream
5.2. RFC Technical Publication Requirements . . . . . . . . . 13 5.2. RFC Technical Publication Requirements
5.2.1. IETF Documents . . . . . . . . . . . . . . . . . . . 14 5.2.1. IETF Documents
5.2.2. IAB Documents . . . . . . . . . . . . . . . . . . . . 14 5.2.2. IAB Documents
5.2.3. IRTF Documents . . . . . . . . . . . . . . . . . . . 14 5.2.3. IRTF Documents
5.2.4. Independent Submissions . . . . . . . . . . . . . . . 14 5.2.4. Independent Submissions
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations
7. Changes Since RFC4844 . . . . . . . . . . . . . . . . . . . . 15 7. Changes Since RFC 4844
8. Informative References . . . . . . . . . . . . . . . . . . . 15 8. Informative References
Appendix A. A Retrospective of IAB Charters and RFC Editor . . . 18 Appendix A. A Retrospective of IAB Charters and RFC Editor
A.1. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. 1992
A.2. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. 1994
A.3. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. 2000
Appendix B. IAB Members at the Time of Approval . . . . . . . . 19 IAB Members at the Time of Approval
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses
1. Introduction 1. Introduction
The first Request for Comments (RFC) document was published in April 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 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 as the Internet. Since then, the RFC Series has been the archival
series dedicated to documenting Internet technical specifications, series dedicated to documenting Internet technical specifications,
including both general contributions from the Internet research and including both general contributions from the Internet research and
engineering community as well as standards documents. engineering community as well as standards documents.
skipping to change at page 4, line 5 skipping to change at line 128
be able to define (based on its own open consensus discussion be able to define (based on its own open consensus discussion
processes and leadership directions) and implement adjustments to its processes and leadership directions) and implement adjustments to its
publication processes. publication processes.
At the same time, the Internet engineering and research community as At the same time, the Internet engineering and research community as
a whole has grown and come to require more openness and a whole has grown and come to require more openness and
accountability in all organizations supporting it. More than ever, accountability in all organizations supporting it. More than ever,
this community needs an RFC Series that is supported (operationally this community needs an RFC Series that is supported (operationally
and in terms of its principles) such that there is a balance of: and in terms of its principles) such that there is a balance of:
o expert implementation; * expert implementation;
o clear management and direction -- for operations and evolution * clear management and direction -- for operations and evolution
across the whole RFC Series (whether originating in the IETF or across the whole RFC Series (whether originating in the IETF or
not); and not); and
o appropriate community input into and review of activities. * appropriate community input into and review of activities.
In the past, there has been confusion and therefore sometimes tension In the past, there has been confusion and therefore sometimes tension
over where and how to address RFC issues that are particular to over where and how to address RFC issues that are particular to
contributing groups (e.g., the IETF, the Internet Architecture Board contributing groups (e.g., the IETF, the Internet Architecture Board
(IAB), or independent individuals). It was not always clear where (IAB), or independent individuals). It was not always clear where
there should be community involvement versus RFC Editor control; there should be community involvement versus RFC Editor control;
depending on the issue, there might be more or less involvement from depending on the issue, there might be more or less involvement from
the IAB, the Internet Engineering Steering Group (IESG), or the the IAB, the Internet Engineering Steering Group (IESG), or the
community at large. There are similar issues with handling RFC community at large. There are similar issues with handling RFC
Series-wide issues -- where to discuss and resolve them in a way that Series-wide issues -- where to discuss and resolve them in a way that
is balanced across the whole series. is balanced across the whole series.
For example, there have been discussions about Intellectual Property For example, there have been discussions about Intellectual Property
Rights (IPR) for IETF-generated documents, but it's not clear when or Rights (IPR) for IETF-generated documents, but it's not clear when or
how to abstract the portions of those discussions that are relevant how to abstract the portions of those discussions that are relevant
to the rest of the RFC Series. Discussions of labeling (of RFCs in to the rest of the RFC Series. Discussions of labeling (of RFCs in
general, IETF documents in particular, or some combination thereof) general, IETF documents in particular, or some combination thereof)
generally must be applied to the whole RFC Series-wide or not at all. 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 Without an agreed-on framework for managing the RFC Series, it is
difficult to have those discussions in a non-polarized fashion -- difficult to have those discussions in a non-polarized fashion --
either the IETF dictating the reality of the rest of the RFC Series, either the IETF dictating the reality of the rest of the RFC Series,
or the RFC Series imposing undue restrictions on documents from the or the RFC Series imposing undue restrictions on documents from the
IETF. IETF.
As part of its charter (see Appendix A), the IAB has a responsibility 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 for the RFC Editor. Acknowledging the IETF's needs and the general
Internet engineering and research community's evolving needs, the IAB Internet engineering and research community's evolving needs, the IAB
supports a future for the RFC Series that continues to meet its supports a future for the RFC Series that continues to meet its
skipping to change at page 6, line 18 skipping to change at line 239
It is the responsibility of the IAB to approve the appointment of the 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 RFC Editor and to approve the general policy followed by the RFC
Editor. Editor.
3.3. Operational Oversight 3.3. Operational Oversight
The IETF Administration Limited Liability Company (IETF LLC), as part The IETF Administration Limited Liability Company (IETF LLC), as part
of the IETF Administrative Support Activity (IASA), is responsible of the IETF Administrative Support Activity (IASA), is responsible
for administrative and financial matters for the IETF, the IAB, and for administrative and financial matters for the IETF, the IAB, and
the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. the Internet Research Task Force (IRTF) [RFC8711]. The IASA is
The IASA is tasked with providing the funding for and operational tasked with providing the funding for the RFC Editor. The IASA,
oversight of the RFC Editor. through the IETF Executive Director, provides contractual and
financial oversight of the RFC Editor. Additionally, as described in
The IETF LLC Board provides oversight of the IASA, and the IETF Section 3.1 of [RFC8728], the RFC Series Oversight Committee (RSOC),
Executive Director is the chief actor for the IASA. 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 The IETF Executive Director works with the IAB to identify suitable
persons or entities to fulfill the mandate of the RFC Editor. 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 The IETF Executive Director establishes appropriate contractual
agreements with the selected persons or entities to carry out the agreements with the selected persons or entities to carry out the
work that will satisfy the technical publication requirements defined work that will satisfy the technical publication requirements defined
for the various RFC input streams (see Section 5.2). The IETF for the various RFC input streams (see Section 5.2). The IETF
Executive Director may define additional operational requirements and Executive Director may define additional operational requirements and
policies for management purposes to meet the requirements defined by policies for management purposes to meet the requirements defined by
the various communities. the various communities.
The IETF Administration LLC Board approves a budget for operation of The IETF Administration LLC Board approves a budget for operation of
skipping to change at page 7, line 10 skipping to change at line 282
either on its own initiative or at the request of the IETF either on its own initiative or at the request of the IETF
Administration LLC Board, may require the IETF Executive Director to Administration LLC Board, may require the IETF Executive Director to
vary or terminate and renegotiate the arrangements for the RFC Editor vary or terminate and renegotiate the arrangements for the RFC Editor
activity. activity.
4. Framework 4. Framework
With the RFC Series mission outlined above, this document describes a With the RFC Series mission outlined above, this document describes a
framework for supporting framework for supporting
o the operational implementation of the RFC Series, * the operational implementation of the RFC Series,
based on based on
o public process and definition documents, * public process and definition documents,
for which there are for which there are
o clear responsibilities and mechanisms for update and change. * clear responsibilities and mechanisms for update and change.
Generally speaking, the RFC Editor is responsible for the operational Generally speaking, the RFC Editor is responsible for the operational
implementation of the RFC Series. As outlined in Section 3.3, the implementation of the RFC Series. As outlined in Section 3.3, the
IETF Executive Director provides the oversight of this operational IETF Executive Director provides the oversight of this operational
role. role.
The process and definition documents are detailed below, including The process and definition documents are detailed below, including
responsibility for the individual process documents (maintenance and responsibility for the individual process documents (maintenance and
update). The RFC Editor works with the appropriate community to update). The RFC Editor works with the appropriate community to
ensure that the process documents reflect current requirements. The ensure that the process documents reflect current requirements. The
IAB is charged with the role of verifying that appropriate community IAB is charged with the role of verifying that appropriate community
input has been sought and that any changes appropriately account for input has been sought and that any changes appropriately account for
community requirements. community requirements.
There are three categories of activity, and a fourth category of There are three categories of activity, and a fourth category of
series-wide rules and guidelines, described for implementing the RFC series-wide rules and guidelines, described for implementing the RFC
Series to support its mission: Series to support its mission:
o Approval of documents. * Approval of documents.
o Editing, processing, and publication of documents. * Editing, processing, and publication of documents.
o Archiving and indexing the documents and making them accessible. * Archiving and indexing the documents and making them accessible.
o Series rules and guidelines. * Series rules and guidelines.
4.1. Document Approval 4.1. Document Approval
The RFC Series mission implicitly requires that documents be reviewed The RFC Series mission implicitly requires that documents be reviewed
and approved for acceptance into the series. and approved for acceptance into the series.
4.1.1. Definition 4.1.1. Definition
Section 5.1 describes the different streams of documents that are put 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 to the RFC Editor for publication as RFCs today. While there may be
skipping to change at page 8, line 34 skipping to change at line 351
4.1.3. Process Change 4.1.3. Process Change
From time to time, it may be necessary to change the approval From time to time, it may be necessary to change the approval
processes for any given stream, or even add or remove streams. This 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 may occur when the RFC Editor, the IAB, the body responsible for a
given stream of documents, or the community determines that there are given stream of documents, or the community determines that there are
issues to be resolved in general for RFC approval or for per-stream issues to be resolved in general for RFC approval or for per-stream
approval processes. approval processes.
In this framework, the general approach is that the IAB will work 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 with the RFC Editor and other parties to get community input, and it
will verify that any changes appropriately account for community will verify that any changes appropriately account for community
requirements. requirements.
4.1.4. Existing Approval Process Documents 4.1.4. Existing Approval Process Documents
The existing documents describing the approval processes for each The existing documents describing the approval processes for each
stream are detailed in Section 5.1. stream are detailed in Section 5.1.
4.2. Editing, Processing, and Publication of Documents 4.2. Editing, Processing, and Publication of Documents
skipping to change at page 9, line 33 skipping to change at line 396
4.2.3. Process Change 4.2.3. Process Change
From time to time, it may be necessary to change the requirements for 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 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 the RFC Editor, the IAB, the approval body for a given stream of
documents, or the community determines that there are issues to be documents, or the community determines that there are issues to be
resolved in general for RFCs or for per-stream requirements. resolved in general for RFCs or for per-stream requirements.
In this model, the general approach is that the IAB will work with 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 the RFC Editor to get community input, and it will approve changes by
validating appropriate consideration of community requirements. validating appropriate consideration of community requirements.
4.2.4. Existing Process Documents 4.2.4. Existing Process Documents
Documents describing existing requirements for the streams are Documents describing existing requirements for the streams are
detailed in Section 5.2. detailed in Section 5.2.
4.3. Archiving, Indexing, and Accessibility 4.3. Archiving, Indexing, and Accessibility
The activities of archiving, indexing, and making accessible the RFC The activities of archiving, indexing, and making accessible the RFC
skipping to change at page 10, line 29 skipping to change at line 438
The RFC Editor is responsible for ensuring that the RFC archive and The RFC Editor is responsible for ensuring that the RFC archive and
index are maintained appropriately and that the resulting documents index are maintained appropriately and that the resulting documents
are made available to anybody wishing to access them via the are made available to anybody wishing to access them via the
Internet. The RFC Editor works with the IASA for regular reporting Internet. The RFC Editor works with the IASA for regular reporting
and feedback. and feedback.
4.3.3. Process Change 4.3.3. Process Change
Should there be a community move to propose changes to the Should there be a community move to propose changes to the
requirements for the RFC archive and index or accessibility, the IAB requirements for the RFC archive and index or accessibility, the IAB
will work with the RFC Editor to get community input and it will will work with the RFC Editor to get community input, and it will
approve changes by validating appropriate consideration of community approve changes by validating appropriate consideration of community
requirements. requirements.
4.3.4. Existing Process Documents 4.3.4. Existing Process Documents
There are no applicable process documents. There are no applicable process documents.
4.4. Series-Wide Guidelines and Rules 4.4. Series-Wide Guidelines and Rules
The RFC Series style and content can be shaped by subject matter The RFC Series style and content can be shaped by subject matter
skipping to change at page 11, line 21 skipping to change at line 478
When additions or changes are needed to series-wide definitions, the When additions or changes are needed to series-wide definitions, the
IAB will work with the RFC Editor and stream stakeholders to get IAB will work with the RFC Editor and stream stakeholders to get
community input and review. The IAB will approve changes by community input and review. The IAB will approve changes by
validating appropriate consideration of community requirements. validating appropriate consideration of community requirements.
4.4.4. Existing Process Documents 4.4.4. Existing Process Documents
Existing series-wide rules and guidelines documents include: Existing series-wide rules and guidelines documents include:
o RFC Style Guide [RFC7223], * RFC Style Guide [RFC7322],
o The Use of Non-ASCII Characters in RFCs [RFC7997], * The Use of Non-ASCII Characters in RFCs [RFC7997],
o Copyright and intellectual property rules [RFC3978] [RFC4748], * Copyright and intellectual property rules [RFC5378],
o Normative references [RFC3967] [RFC4897]. * Normative references [RFC3967] [RFC4897], [RFC8067].
5. RFC Streams 5. RFC Streams
Various contributors provide input to the RFC Series. These Various contributors provide input to the RFC Series. These
contributors come from several different communities, each with its contributors come from several different communities, each with its
own defined process for approving documents that will be published by own defined process for approving documents that will be published by
the RFC Editor. This is nothing new; however, over time the various the RFC Editor. This is nothing new; however, over time the various
communities and document requirements have grown and separated. In communities and document requirements have grown and separated. In
order to promote harmony in discussing the collective set of order to promote harmony in discussing the collective set of
requirements, it is useful to recognize each in their own space -- requirements, it is useful to recognize each in their own space --
skipping to change at page 12, line 27 skipping to change at line 531
5.1.1. IETF Document Stream 5.1.1. IETF Document Stream
The IETF document stream includes IETF WG documents as well as The IETF document stream includes IETF WG documents as well as
"individual submissions" sponsored by an IESG area director. Any "individual submissions" sponsored by an IESG area director. Any
document being published as part of the IETF standards process must document being published as part of the IETF standards process must
follow this stream -- no other stream can approve Standards-Track follow this stream -- no other stream can approve Standards-Track
RFCs or Best Current Practice (BCP) RFCs. RFCs or Best Current Practice (BCP) RFCs.
Approval of documents in the IETF stream is defined by Approval of documents in the IETF stream is defined by
o the IETF standards process [RFC2026] (and its successors). * the IETF standards process [RFC2026] (and its successors).
o the IESG process for sponsoring individual submissions [SPONSOR]. * the IESG process for sponsoring individual submissions [SPONSOR].
Changes to the approval process for this stream are made by updating Changes to the approval process for this stream are made by updating
the IETF standards process documents. the IETF standards process documents.
5.1.2. IAB Document Stream 5.1.2. IAB Document Stream
The IAB defines the processes by which it approves documents in its The IAB defines the processes by which it approves documents in its
stream. Consistent with the above, any documents that the IAB wishes stream. Consistent with the above, any documents that the IAB wishes
to publish as part of the IETF Standards Track (Standards or BCPs) 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. 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 The review and approval process for documents in the IAB stream is
described in described in
o the IAB process for review and approval of its documents * the IAB process for review and approval of its documents
[RFC4845]. [RFC4845].
5.1.3. IRTF Document Stream 5.1.3. IRTF Document Stream
The IRTF is chartered as an activity of the IAB. With the approval 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 the IAB, the IRTF may publish and update a process for publication
of its own, non-IETF Standards-Track, documents. of its own, non-IETF Standards-Track, documents.
The review and approval process for documents in the IRTF stream is The review and approval process for documents in the IRTF stream is
described in described in
o IRTF Research Group RFCs [RFC5743]. * IRTF Research Group RFCs [RFC5743].
5.1.4. Independent Submission Stream 5.1.4. Independent Submission Stream
The RFC Series has always served a broader Internet technical The RFC Series has always served a broader Internet technical
community than the IETF. The "Independent Submission" stream is community than the IETF. The "Independent Submission" stream is
defined to provide review and (possible) approval of documents that defined to provide review and (possible) approval of documents that
are outside the scope of the streams identified above. are outside the scope of the streams identified above.
Generally speaking, approval of documents in this stream falls under Generally speaking, approval of documents in this stream falls under
the purview of the RFC Editor, and the RFC Editor seeks input to its the purview of the RFC Editor, and the RFC Editor seeks input to its
review from the IESG. review from the IESG.
The process for reviewing and approving documents in the Independent The process for reviewing and approving documents in the Independent
Submission stream is defined by Submission stream is defined by
o Procedures for Rights Handling in the RFC Independent Submission * Procedures for Rights Handling in the RFC Independent Submission
Stream [RFC5744], Stream [RFC5744],
o Independent Submission Editor Model [I-D.ietf-iasa2-rfc6548bis], * Independent Submission Editor Model [RFC8730],
o Independent Submissions to the RFC Editor [RFC4846], * Independent Submissions to the RFC Editor [RFC4846],
o The IESG and RFC Editor Documents: Procedures [RFC3932]. * The IESG and RFC Editor Documents: Procedures [RFC5742].
5.2. RFC Technical Publication Requirements 5.2. RFC Technical Publication Requirements
The Internet engineering and research community has not only grown, The Internet engineering and research community has not only grown,
it has become more diverse, and sometimes more demanding. The IETF, it has become more diverse, and sometimes more demanding. The IETF,
as a standards-developing organization, has publication requirements as a standards-developing organization, has publication requirements
that extend beyond those of an academic journal. The IAB does not that extend beyond those of an academic journal. The IAB does not
have the same interdependence with IANA assignments as the IETF have the same interdependence with IANA assignments as the IETF
stream does. Therefore, there is the need to both codify the stream does. Therefore, there is the need to both codify the
publishing requirements of each stream, and endeavor to harmonize publishing requirements of each stream, and endeavor to harmonize
skipping to change at page 14, line 34 skipping to change at line 633
stream. stream.
If the IRTF elects to define other requirements, they should deviate If the IRTF elects to define other requirements, they should deviate
minimally from those (in an effort to keep the collective technical minimally from those (in an effort to keep the collective technical
publication requirements reasonably managed by one technical publication requirements reasonably managed by one technical
publisher). publisher).
5.2.4. Independent Submissions 5.2.4. Independent Submissions
Procedures and processes for the Independent Stream are described in Procedures and processes for the Independent Stream are described in
[RFC4846] and [I-D.ietf-iasa2-rfc6548bis]. [RFC4846] and [RFC8730].
Although they were developed for the IETF standards process, the RFC Although they were developed for the IETF standards process, the RFC
Editor has identified applicable requirements in [RFC4714] for the Editor has identified applicable requirements in [RFC4714] for the
independent submissions stream. In addition, procedures related to Independent Submissions stream. In addition, procedures related to
IPR for the independent submissions stream are captured in [RFC5744]. IPR for the independent submissions stream are captured in [RFC5744].
If the RFC Editor elects to define other requirements, they should If the RFC Editor elects to define other requirements, they should
deviate minimally from those (in an effort to keep the collective deviate minimally from those (in an effort to keep the collective
technical publication requirements reasonably managed by one technical publication requirements reasonably managed by one
technical publisher). technical publisher).
6. Security Considerations 6. Security Considerations
The processes for the publication of documents must prevent the The processes for the publication of documents must prevent the
introduction of unapproved changes. Since the RFC Editor maintains introduction of unapproved changes. Since the RFC Editor maintains
the index of publications, sufficient security must be in place to the index of publications, sufficient security must be in place to
prevent these published documents from being changed by external prevent these published documents from being changed by external
parties. The archive of RFC documents, any source documents needed parties. The archive of RFC documents, any source documents needed
to recreate the RFC documents, and any associated original documents to recreate the RFC documents, and any associated original documents
(such as lists of errata, tools, and, for some early items, non- (such as lists of errata, tools, and, for some early items, non-
machine readable originals) need to be secured against failure of the machine readable originals) need to be secured against failure of the
storage medium and other similar disasters. storage medium and other similar disasters.
7. Changes Since RFC4844 7. Changes Since RFC 4844
Sections 3.3, 3.4, and 4 have been updated to align with the Sections 3.3, 3.4, and 4 have been updated to align with the
restructuring of the IETF Administrative Support Activity (IASA). restructuring of the IETF Administrative Support Activity (IASA).
Under the new structure, the IETF LLC performs the tasks that were Under the new structure, the IETF LLC performs the tasks related to
previously assigned to the IETF Administrative Oversight Committee IASA that were previously assigned to the IETF Administrative
(IAOC) under the old structure. Director and to the Internet Society.
Many references were updated to point to the most recent documents. Many references were updated to point to the most recent documents.
Minor editorial changes were made to reflect 10 years of using the Minor editorial changes were made to reflect 10 years of using the
framework provided in RFC 4884. For example, RFC 4844 said, "... framework provided in RFC 4884. For example, RFC 4844 said, "...
this document sets out a revised framework ...", and it is now more this document sets out a revised framework ...", and it is now more
appropriate to say, "... this document sets out the framework ...". appropriate to say, "... this document sets out the framework ...".
8. Informative References 8. Informative References
[I-D.ietf-iasa2-rfc4071bis]
Haberman, B., Hall, J., and J. Livingood, "Structure of
the IETF Administrative Support Activity, Version 2.0",
draft-ietf-iasa2-rfc4071bis-11 (work in progress), April
2019.
[I-D.ietf-iasa2-rfc6548bis]
Brownlee, N. and R. Hinden, "Independent Submission Editor
Model", draft-ietf-iasa2-rfc6548bis-02 (work in progress),
January 2019.
[RFC1358] Chapin, L., "Charter of the Internet Architecture Board [RFC1358] Chapin, L., "Charter of the Internet Architecture Board
(IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992, (IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992,
<https://www.rfc-editor.org/info/rfc1358>. <https://www.rfc-editor.org/info/rfc1358>.
[RFC1601] Huitema, C., "Charter of the Internet Architecture Board [RFC1601] Huitema, C., "Charter of the Internet Architecture Board
(IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994, (IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994,
<https://www.rfc-editor.org/info/rfc1601>. <https://www.rfc-editor.org/info/rfc1601>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
skipping to change at page 16, line 10 skipping to change at line 695
[RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555,
DOI 10.17487/RFC2555, April 1999, DOI 10.17487/RFC2555, April 1999,
<https://www.rfc-editor.org/info/rfc2555>. <https://www.rfc-editor.org/info/rfc2555>.
[RFC2850] Internet Architecture Board and B. Carpenter, Ed., [RFC2850] Internet Architecture Board and B. Carpenter, Ed.,
"Charter of the Internet Architecture Board (IAB)", "Charter of the Internet Architecture Board (IAB)",
BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
<https://www.rfc-editor.org/info/rfc2850>. <https://www.rfc-editor.org/info/rfc2850>.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", RFC 3932, DOI 10.17487/RFC3932, October 2004,
<https://www.rfc-editor.org/info/rfc3932>.
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Documents may Refer Normatively to Documents at a Lower
Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December
2004, <https://www.rfc-editor.org/info/rfc3967>. 2004, <https://www.rfc-editor.org/info/rfc3967>.
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions",
RFC 3978, DOI 10.17487/RFC3978, March 2005,
<https://www.rfc-editor.org/info/rfc3978>.
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical
Publication Service", RFC 4714, DOI 10.17487/RFC4714, Publication Service", RFC 4714, DOI 10.17487/RFC4714,
October 2006, <https://www.rfc-editor.org/info/rfc4714>. October 2006, <https://www.rfc-editor.org/info/rfc4714>.
[RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF
Trust", RFC 4748, DOI 10.17487/RFC4748, October 2006,
<https://www.rfc-editor.org/info/rfc4748>.
[RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process
for Publication of IAB RFCs", RFC 4845, for Publication of IAB RFCs", RFC 4845,
DOI 10.17487/RFC4845, July 2007, DOI 10.17487/RFC4845, July 2007,
<https://www.rfc-editor.org/info/rfc4845>. <https://www.rfc-editor.org/info/rfc4845>.
[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent
Submissions to the RFC Editor", RFC 4846, Submissions to the RFC Editor", RFC 4846,
DOI 10.17487/RFC4846, July 2007, DOI 10.17487/RFC4846, July 2007,
<https://www.rfc-editor.org/info/rfc4846>. <https://www.rfc-editor.org/info/rfc4846>.
[RFC4897] Klensin, J. and S. Hartman, "Handling Normative References [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References
to Standards-Track Documents", BCP 97, RFC 4897, to Standards-Track Documents", BCP 97, RFC 4897,
DOI 10.17487/RFC4897, June 2007, DOI 10.17487/RFC4897, June 2007,
<https://www.rfc-editor.org/info/rfc4897>. <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 [RFC5743] Falk, A., "Definition of an Internet Research Task Force
(IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743,
December 2009, <https://www.rfc-editor.org/info/rfc5743>. December 2009, <https://www.rfc-editor.org/info/rfc5743>.
[RFC5744] Braden, R. and J. Halpern, "Procedures for Rights Handling [RFC5744] Braden, R. and J. Halpern, "Procedures for Rights Handling
in the RFC Independent Submission Stream", RFC 5744, in the RFC Independent Submission Stream", RFC 5744,
DOI 10.17487/RFC5744, December 2009, DOI 10.17487/RFC5744, December 2009,
<https://www.rfc-editor.org/info/rfc5744>. <https://www.rfc-editor.org/info/rfc5744>.
[RFC5745] Malis, A., Ed. and IAB, "Procedures for Rights Handling in [RFC5745] Malis, A., Ed. and IAB, "Procedures for Rights Handling in
the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745, the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745,
December 2009, <https://www.rfc-editor.org/info/rfc5745>. December 2009, <https://www.rfc-editor.org/info/rfc5745>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, DOI 10.17487/RFC7322, September 2014,
<https://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7322>.
[RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in
RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
<https://www.rfc-editor.org/info/rfc7997>. <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", [SPONSOR] IESG, "Guidance on Area Director Sponsoring of Documents",
IESG Statement , March 2007, IESG Statement, March 2007,
<http://www.ietf.org/iesg/statement/ <http://www.ietf.org/iesg/statement/ad-sponsoring-
ad-sponsoring-docs.html>. docs.html>.
Appendix A. A Retrospective of IAB Charters and RFC Editor Appendix A. A Retrospective of IAB Charters and RFC Editor
With this document, the IAB's role with respect to the RFC Series and 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 the RFC Editor is being adjusted to work more directly with the RFC
Editor and provide oversight to ensure the RFC Series mission Editor and provide oversight to ensure the RFC Series mission
principles and communities' input are addressed appropriately. principles and communities' input are addressed appropriately.
This section provides an overview of the role of the IAB with respect 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 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 back to 1992. The point of this section is that the IAB's role has
historically been substantive -- whether it is supposed to be historically been substantive -- whether it is supposed to be
directly responsible for the RFC Series' editorial management (circa directly responsible for the RFC Series' editorial management (circa
1992, Appendix A.1), or appointment of the RFC Editor organization 1992, Appendix A.1), or appointment of the RFC Editor organization
and approval of general policy (circa 2000, Appendix A.3). and approval of general policy (circa 2000, Appendix A.3).
A.1. 1992 A.1. 1992
[RFC1358] says: [RFC1358] says:
[The IAB's] responsibilities shall include: | [The IAB's] responsibilities shall include:
[...] | [...]
(2) The editorial management and publication of the Request for | (2) The editorial management and publication of the Request
Comments (RFC) document series, which constitutes the | for Comments (RFC) document series, which constitutes the
archival publication series for Internet Standards and | archival publication series for Internet Standards and
related contributions by the Internet research and | related contributions by the Internet research and
engineering community. | engineering community.
A.2. 1994 A.2. 1994
[RFC1601] says: [RFC1601] says:
[The IAB's] responsibilities under this charter include: | [The IAB's] responsibilities under this charter include:
|
(d) RFC Series and IANA | (d) RFC Series and IANA
|
The IAB is responsible for editorial management and publication of | The IAB is responsible for editorial management and publication
the Request for Comments (RFC) document series, and for | of the Request for Comments (RFC) document series, and for
administration of the various Internet assigned numbers. | administration of the various Internet assigned numbers.
which it elaborates as
2.4 RFC Series and Assigned Numbers Which it elaborates as:
The RFC Series constitutes the archival publication channel for | 2.4 RFC Series and Assigned Numbers
Internet Standards and for other contributions by the Internet |
research and engineering community. The IAB shall select an RFC | The RFC Series constitutes the archival publication channel
Editor, who shall be responsible for the editorial management and | for Internet Standards and for other contributions by the
publication of the RFC Series. | 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 A.3. 2000
The most recent IAB Charter [RFC2850] says: The most recent IAB Charter [RFC2850] says:
(d) RFC Series and IANA | (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.
The RFC Editor executes editorial management and publication of the IAB Members at the Time of Approval
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.
Appendix B. IAB Members at the Time of Approval The IAB members at the time of approval of RFC 4844 were:
{{ RFC Editor: Fill in the current membership. }} 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 Authors' Addresses
Russ Housley (editor) Russ Housley (editor)
Vigil Security, LLC
EMail: housley@vigilsec.com Email: housley@vigilsec.com
Leslie L. Daigle (editor) Leslie L. Daigle (editor)
Thinking Cat Enterprises
EMail: ldaigle@thinkingcat.com Email: ldaigle@thinkingcat.com
 End of changes. 61 change blocks. 
185 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/