Network Working Group L. Daigle
Internet-Draft Ed.
Expires: July 15, 2007 Internet Architecture Board
(IAB)
January 11, 2007
The RFC Series and RFC Editor
draft-iab-rfc-editor
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 1]
Internet-Draft draft-iab-rfc-editor-03 January 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . . 6
3. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 7
3.1. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Operational Oversight . . . . . . . . . . . . . . . . . . 7
3.4. Policy Oversight . . . . . . . . . . . . . . . . . . . . . 8
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Document Approval . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Operational Implementation . . . . . . . . . . . . . . 10
4.1.3. Process Change . . . . . . . . . . . . . . . . . . . . 10
4.1.4. Existing Approval Process Documents . . . . . . . . . 10
4.2. Editing, Processing and Publication of Documents . . . . . 10
4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Operational Implementation . . . . . . . . . . . . . . 11
4.2.3. Process Change . . . . . . . . . . . . . . . . . . . . 11
4.2.4. Existing Process Documents . . . . . . . . . . . . . . 11
4.3. Archiving, Indexing and Accessibility . . . . . . . . . . 11
4.3.1. Definition . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Operational Implementation . . . . . . . . . . . . . . 12
4.3.3. Process Change . . . . . . . . . . . . . . . . . . . . 12
4.3.4. Existing Process Documents . . . . . . . . . . . . . . 12
4.4. Series-wide Guidelines and Rules . . . . . . . . . . . . . 12
4.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2. Operational Implementation . . . . . . . . . . . . . . 12
4.4.3. Change Process . . . . . . . . . . . . . . . . . . . . 12
4.4.4. Existing Process Documents . . . . . . . . . . . . . . 13
5. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. RFC Approval Processes . . . . . . . . . . . . . . . . . . 14
5.1.1. IETF Document Stream . . . . . . . . . . . . . . . . . 14
5.1.2. IAB Document Stream . . . . . . . . . . . . . . . . . 15
5.1.3. IRTF Document Stream . . . . . . . . . . . . . . . . . 15
5.1.4. Independent Submission Stream . . . . . . . . . . . . 15
5.2. RFC Technical Publication Requirements . . . . . . . . . . 16
5.2.1. IETF Documents . . . . . . . . . . . . . . . . . . . . 16
5.2.2. IAB Documents . . . . . . . . . . . . . . . . . . . . 16
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 2]
Internet-Draft draft-iab-rfc-editor-03 January 2007
5.2.3. IRTF Documents . . . . . . . . . . . . . . . . . . . . 16
5.2.4. Independent Submissions . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. IAB members at the time of approval . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. A Retrospective of IAB Charters and RFC Editor . . . 23
A.1. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.2. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.3. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 3]
Internet-Draft draft-iab-rfc-editor-03 January 2007
1. Introduction
The first Request for Comment (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 ( [17]),
the RFC series was created for the purpose of capturing the research
and engineering thought that underlies the design of (what we now
know of as) the Internet. As the Internet Engineering Task Force 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 & evolution
across all the whole RFC series (whether originating in the IETF
or not)
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., IETF, or 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 or IESG or 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 & Internet Architecture Board Expires July 15, 2007 [Page 4]
Internet-Draft draft-iab-rfc-editor-03 January 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
research and engineering technical 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 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 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, IAB and 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.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 5]
Internet-Draft draft-iab-rfc-editor-03 January 2007
2. RFC Series Mission
The RFC Series is 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.
RFCs are available free of charge to anyone via the Internet.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 6]
Internet-Draft draft-iab-rfc-editor-03 January 2007
3. Roles and Responsibilities
As this document proposes changes to the framework for supporting the
RFC Series mission, this section reviews the planned 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,
they are expected to be the expert and prime mover in discussions
about policies for editing, publishing and archiving RFCs.
3.2. IAB
The general role of the IAB, in this model, is to ensure that the RFC
Series mission is being appropriately supported, 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, [2]), was created
to provide administrative support for the IETF, the IAB, and the
IRTF. In its role of supporting the IAB, the IASA is tasked with
providing the funding for and operational oversight of the RFC
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 7]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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 for 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, in order 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
agreement(s).
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.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 8]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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.
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.
Responsibility for the individual process documents (maintenance and
update) is defined in more detail below. Generally speaking, 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
guidelines and rules, 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 are
reviewed and approved for acceptance into the series. Section 5.1
describes the different streams of documents that are put to the RFC
Editor for publication as RFCs today.
4.1.1. Definition
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
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 9]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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 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, statement of work,
service level agreement, etc).
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 10]
Internet-Draft draft-iab-rfc-editor-03 January 2007
4.2.2. Operational Implementation
The RFC Editor is responsible for ensuring 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
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 series editing subject matter expertise.
It also is informed by requirements from the using 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, statement of work, service
level agreement, etc).
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 11]
Internet-Draft draft-iab-rfc-editor-03 January 2007
4.3.2. Operational Implementation
The RFC Editor is responsible for ensuring 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 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 informed by series editing
subject matter expertise. It also is 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, 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 the RFC series guidelines
are upheld within the RFC Series.
4.4.3. Change Process
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.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 12]
Internet-Draft draft-iab-rfc-editor-03 January 2007
4.4.4. Existing Process Documents
Existing series-wide rules and guidelines documents include:
o Instructions to RFC Authors (RFC 2223, [5], [13])
o Copyright and intellectual property rules (RFC 3978, [7] and RFC
4748, [18])
o Normative references (RFC 3967, [6] and RFC VVVV, [8])
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 13]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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 today.
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.
Approval of documents in the IETF stream is defined by
o the IETF standards process (RFC2026, [3], and its successors).
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 14]
Internet-Draft draft-iab-rfc-editor-03 January 2007
o the IESG process for sponsoring individual submissions (RFC XXXX,
[9]).
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
YYYY, [10]).
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, (RFC ZZZZ, [11]).
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 Independent Submission
streams documents is defined by
Independent Submissions to the RFC Editor (RFC WWWW, [12])
The IESG and RFC Editor Documents: Procedures (RFC 3932, [4])
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 15]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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 endeavour 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 ([14]).
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 in RFC4714 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
Although they were developed for the IETF standards process, the RFC
Editor will identify the applicable requirements in RFC 4714 for its
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 16]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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).
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 17]
Internet-Draft draft-iab-rfc-editor-03 January 2007
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.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 18]
Internet-Draft draft-iab-rfc-editor-03 January 2007
7. IANA Considerations
This document requires no action on IANA's part.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 19]
Internet-Draft draft-iab-rfc-editor-03 January 2007
8. IAB members at the time of approval
To be filled in.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 20]
Internet-Draft draft-iab-rfc-editor-03 January 2007
9. References
[1] Carpenter, B., "Charter of the Internet Architecture Board
(IAB)", RFC 2850, May 2000.
[2] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, April 2005.
[3] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[4] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", RFC 3932, October 2004.
[5] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[6] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level",
RFC 3967, December 2004.
[7] Bradner, Ed., S., "IETF Rights in Contributions", RFC 3978,
March 2005.
[8] Klensin, J., "A Process Experiment in Normative Reference
Handling", draft-klensin-norm-ref (work in progress),
April 2006.
[9] Arkko, J., "Guidance on Area Director Sponsoring of Documents",
draft-iesg-sponsoring-guidelines (work in progress),
October 2006.
[10] Daigle, L., "Process for Publication of IAB RFCs",
draft-iab-publication (work in progress), December 2006.
[11] Falk, A., "IRTF Research Group RFCs", draft-irtf-rfcs (work in
progress), February 2006.
[12] Klensin, J., "Independent Submissions to the RFC Editor",
draft-klensin-rfc-independent (work in progress), October 2006.
[13] Reynolds, Editor, J. and R. Braden, Editor, "Instructions to
Request for Comments (RFC) Authors",
draft-rfc-editor-rfc2223bis (work in progress), August 2004.
[14] Mankin, A. and S. Hayes, "Requirements for IETF Technical
Publication Service", RFC 4714, October 2006.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 21]
Internet-Draft draft-iab-rfc-editor-03 January 2007
[15] Chapin, L., "Charter of the Internet Architecture Board (IAB)",
RFC 1358, August 1992.
[16] Huitema, C., "Charter of the Internet Architecture Board
(IAB)", RFC 1601, March 1994.
[17] Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.
[18] Bradner, Ed., S., "RFC 3978 Update to Recognize the IETF
Trust", RFC 4748, October 2006.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 22]
Internet-Draft draft-iab-rfc-editor-03 January 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
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 (c.
1992), or appointment of the RFC Editor organization and approval of
general policy (c. 2000).
A.1. 1992
[15] 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
[16] 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.
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 23]
Internet-Draft draft-iab-rfc-editor-03 January 2007
A.3. 2000
[1], 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 & Internet Architecture Board Expires July 15, 2007 [Page 24]
Internet-Draft draft-iab-rfc-editor-03 January 2007
Authors' Addresses
Leslie L. Daigle
Ed.
Email: ledaigle@cisco.com, leslie@thinkingcat.com
(IAB)
Email: iab@iab.org
URI: http://www.iab.org/
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 25]
Internet-Draft draft-iab-rfc-editor-03 January 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Daigle & Internet Architecture Board Expires July 15, 2007 [Page 26]
