summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4844.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4844.txt')
-rw-r--r--doc/rfc/rfc4844.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc4844.txt b/doc/rfc/rfc4844.txt
new file mode 100644
index 0000000..627b802
--- /dev/null
+++ b/doc/rfc/rfc4844.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group L. Daigle, Ed.
+Request for Comments: 4844
+Category: Informational Internet Architecture Board
+ (IAB)
+ July 2007
+
+
+ The RFC Series and RFC Editor
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 1]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 5
+ 3.1. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3. Operational Oversight . . . . . . . . . . . . . . . . . . 5
+ 3.4. Policy Oversight . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.1. Document Approval . . . . . . . . . . . . . . . . . . . . 7
+ 4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1.2. Operational Implementation . . . . . . . . . . . . . . 7
+ 4.1.3. Process Change . . . . . . . . . . . . . . . . . . . . 8
+ 4.1.4. Existing Approval Process Documents . . . . . . . . . 8
+ 4.2. Editing, Processing, and Publication of Documents . . . . 8
+ 4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2.2. Operational Implementation . . . . . . . . . . . . . . 8
+ 4.2.3. Process Change . . . . . . . . . . . . . . . . . . . . 9
+ 4.2.4. Existing Process Documents . . . . . . . . . . . . . . 9
+ 4.3. Archiving, Indexing, and Accessibility . . . . . . . . . . 9
+ 4.3.1. Definition . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.3.2. Operational Implementation . . . . . . . . . . . . . . 9
+ 4.3.3. Process Change . . . . . . . . . . . . . . . . . . . . 10
+ 4.3.4. Existing Process Documents . . . . . . . . . . . . . . 10
+ 4.4. Series-Wide Guidelines and Rules . . . . . . . . . . . . . 10
+ 4.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.4.2. Operational Implementation . . . . . . . . . . . . . . 10
+ 4.4.3. Process Change . . . . . . . . . . . . . . . . . . . . 10
+ 4.4.4. Existing Process Documents . . . . . . . . . . . . . . 10
+ 5. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.1. RFC Approval Processes . . . . . . . . . . . . . . . . . . 11
+ 5.1.1. IETF Document Stream . . . . . . . . . . . . . . . . . 11
+ 5.1.2. IAB Document Stream . . . . . . . . . . . . . . . . . 12
+ 5.1.3. IRTF Document Stream . . . . . . . . . . . . . . . . . 12
+ 5.1.4. Independent Submission Stream . . . . . . . . . . . . 12
+ 5.2. RFC Technical Publication Requirements . . . . . . . . . . 13
+ 5.2.1. IETF Documents . . . . . . . . . . . . . . . . . . . . 13
+ 5.2.2. IAB Documents . . . . . . . . . . . . . . . . . . . . 13
+ 5.2.3. IRTF Documents . . . . . . . . . . . . . . . . . . . . 13
+ 5.2.4. Independent Submissions . . . . . . . . . . . . . . . 14
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 7. IAB Members at the Time of Approval . . . . . . . . . . . . . 14
+ 8. Informative References . . . . . . . . . . . . . . . . . . . . 15
+ Appendix A. A Retrospective of IAB Charters and RFC Editor . . . 17
+ A.1. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ A.2. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ A.3. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Daigle & IAB Informational [Page 2]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+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 20 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:
+
+ o expert implementation;
+
+ o clear management and direction -- for operations and evolution
+ across the whole RFC Series (whether originating in the IETF or
+ not); and
+
+ o appropriate community input into and review of activities.
+
+ Today, there is 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 isn't 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.
+
+
+
+Daigle & IAB Informational [Page 3]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ For example, there are current 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 on an RFC Series-wide
+ basis 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 the IETF document series.
+
+ As part of its charter (see Appendix A), the IAB has a responsibility
+ for the RFC Editor. Acknowledging the IETF's and the general
+ Internet engineering and research community's evolving needs, the IAB
+ would like to see 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.
+
+
+
+
+
+
+Daigle & IAB Informational [Page 4]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+3. Roles and Responsibilities
+
+ As this document sets out a revised 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 as put forward in this document 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 Administrative Support Activity (BCP 101, [BCP101]) was
+ created to provide administrative support for the IETF, the IAB, and
+ the Internet Research Task Force (IRTF). In its role of supporting
+
+
+
+
+Daigle & IAB Informational [Page 5]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ the IAB, the IASA is tasked with providing the funding for and
+ operational oversight of the RFC Editor.
+
+ The IAOC (IETF Administrative Oversight Committee) is the oversight
+ board of the IASA, and the IAD (IETF Administrative Director) is the
+ chief actor for the IASA.
+
+ The IAOC works with the IAB to identify suitable persons or entities
+ to fulfill the mandate of the RFC Editor.
+
+ The IAOC 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 IAOC may define additional
+ operational requirements and policies for management purposes to meet
+ the requirements defined by the various communities.
+
+ In accordance with BCP 101, the IAOC provides oversight of the
+ operation of the RFC Editor activity based on the established
+ agreements.
+
+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 IAOC, may
+ require the IAOC 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
+
+ o the operational implementation of the RFC Series,
+
+ based on
+
+ o public process and definition documents,
+
+ for which there are
+
+ o clear responsibilities and mechanisms for update and change.
+
+
+
+
+
+
+Daigle & IAB Informational [Page 6]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ Generally speaking, the RFC Editor is responsible for the operational
+ implementation of the RFC Series. As outlined in Section 3.3, the
+ IAD 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 3 categories of activity, and a 4th category of series-wide
+ rules and guidelines, described for implementing the RFC Series to
+ support its mission:
+
+ o Approval of documents.
+
+ o Editing, processing, and publication of documents.
+
+ o Archiving and indexing the documents and making them accessible.
+
+ o 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.
+
+
+
+
+Daigle & IAB Informational [Page 7]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+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.
+
+
+
+
+
+
+Daigle & IAB Informational [Page 8]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+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.
+
+
+
+
+
+Daigle & IAB Informational [Page 9]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+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:
+
+ o Instructions to RFC Authors (RFC 2223 [RFC2223], [RFC2223BIS])
+
+ o Copyright and intellectual property rules (RFC 3978 [RFC3978] and
+ RFC 4748 [RFC4748])
+
+
+
+Daigle & IAB Informational [Page 10]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ o Normative references (RFC 3967 [RFC3967] and RFC 4897 [RFC4897])
+
+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 or
+ Best Current Practice (BCP) RFCs.
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 11]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ Approval of documents in the IETF stream is defined by
+
+ o the IETF standards process (RFC 2026 [RFC2026] and its
+ successors).
+
+ o 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
+
+ o the IAB process for review and approval of its documents (RFC 4845
+ [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
+
+ o IRTF Research Group RFCs [IRTF-DOCS].
+
+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.
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 12]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ The process for reviewing and approving documents in the Independent
+ Submission stream is defined by
+
+ o Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]).
+
+ o The IESG and RFC Editor Documents: Procedures (RFC 3932
+ [RFC3932]).
+
+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 RFC 4714 [RFC4714].
+
+5.2.2. IAB Documents
+
+ Although they were developed for the IETF standards process, the IAB
+ will identify the applicable requirements in RFC 4714 for its stream.
+
+ 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
+
+ Although they were developed for the IETF standards process, the IRTF
+ will identify the applicable requirements in RFC 4714 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
+
+
+
+Daigle & IAB Informational [Page 13]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ publication requirements reasonably managed by one technical
+ publisher).
+
+5.2.4. Independent Submissions
+
+ Although they were developed for the IETF standards process, the RFC
+ Editor will identify the applicable requirements in RFC 4714 for its
+ stream.
+
+ 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. IAB Members at the Time of Approval
+
+ 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
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 14]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+8. Informative References
+
+ [BCP101] Austein, R. and B. Wijnen, "Structure of the IETF
+ Administrative Support Activity (IASA)", RFC 4071,
+ BCP 101, April 2005.
+
+ [IABCHARTER] Carpenter, B., "Charter of the Internet Architecture
+ Board (IAB)", RFC 2850, May 2000.
+
+ [IRTF-DOCS] Falk, A., "IRTF Research Group RFCs", Work in Progress,
+ February 2006.
+
+ [RFC1358] Chapin, L., "Charter of the Internet Architecture Board
+ (IAB)", RFC 1358, August 1992.
+
+ [RFC1601] Huitema, C., "Charter of the Internet Architecture
+ Board (IAB)", RFC 1601, March 1994.
+
+ [RFC2026] Bradner, S., Ed., "The Internet Standards Process --
+ Revision 3", RFC 2026, October 1996.
+
+ [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
+ Authors", RFC 2223, October 1997.
+
+ [RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
+ Request for Comments (RFC) Authors", Work in Progress,
+ August 2004.
+
+ [RFC2555] Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.
+
+ [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
+ Procedures", RFC 3932, October 2004.
+
+ [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards
+ Track Documents may Refer Normatively to Documents at a
+ Lower Level", RFC 3967, December 2004.
+
+ [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions",
+ RFC 3978, March 2005.
+
+ [RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693,
+ October 2006.
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 15]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+ [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF
+ Technical Publication Service", RFC 4714, October 2006.
+
+ [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the
+ IETF Trust", RFC 4748, October 2006.
+
+ [RFC4845] Daigle, L., "Process for Publication of IAB RFCs",
+ RFC 4845, July 2007.
+
+ [RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to
+ the RFC Editor", RFC 4846, July 2007.
+
+ [RFC4897] Klensin, J., "Handling Normative References to
+ Standards Track Documents", BCP 97, RFC 4897,
+ June 2007.
+
+ [SPONSOR] Arkko, J., "Guidance on Area Director Sponsoring of
+ Documents", ION, October 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 16]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 17]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+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
+
+ [IABCHARTER], which is the most recent IAB Charter document, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 18]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+Authors' Addresses
+
+ Leslie L. Daigle (editor)
+
+ EMail: ledaigle@cisco.com, leslie@thinkingcat.com
+
+
+ IAB
+
+ EMail: iab@iab.org
+ URI: http://www.iab.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 19]
+
+RFC 4844 The RFC Series and RFC Editor July 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Daigle & IAB Informational [Page 20]
+