GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4844

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4844.txt · Last modified: 2007/07/17 00:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki