Network Working Group L. Daigle Internet-Draft Ed. Expires: November 23, 2006 Internet Architecture Board. (IAB) May 22, 2006 The 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 November 23, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract One of the responsibilities assigned to the IAB in its charter is oversight of the RFC Editor. With this document, the IAB provides an explicit implementation of its oversight role, a model for defining (and updating) processes relating to the RFC Editor, and a brief charter for the RFC Editor. Daigle & (IAB) Expires November 23, 2006 [Page 1]
Internet-Draft draft-iab-rfc-editor-00 May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RFC Editor Charter . . . . . . . . . . . . . . . . . . . . . . 4 3. RFC Approval Processes . . . . . . . . . . . . . . . . . . . . 5 3.1. IETF Document Stream . . . . . . . . . . . . . . . . . . . 5 3.2. IAB Document Stream . . . . . . . . . . . . . . . . . . . 5 3.3. IRTF Document Stream . . . . . . . . . . . . . . . . . . . 5 3.4. Independent Submission Stream . . . . . . . . . . . . . . 6 4. RFC Technical Publication Requirements . . . . . . . . . . . . 7 4.1. IETF Documents . . . . . . . . . . . . . . . . . . . . . . 7 4.2. IAB Documents . . . . . . . . . . . . . . . . . . . . . . 7 4.3. IRTF Documents . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Independent Submissions . . . . . . . . . . . . . . . . . 7 5. Operational Oversight . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IAB members at the time of approval . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Daigle & (IAB) Expires November 23, 2006 [Page 2]
Internet-Draft draft-iab-rfc-editor-00 May 2006 1. Introduction As part of its charter ([1]), the IAB has oversight responsibility for the RFC Editor. The IAB seeks to fulfill that role in a way that respects the long history of the RFC Series, while continuing to move forward in a way that successfully melds the requirements and expectations of the various contributors that provide regular input to the RFC Editor (streams). To that end, this document provides a brief charter for the RFC Editor activity, discusses the streams of input to the RFC Series, and defines the expected relationship between the IAB and its operational support from IASA. Daigle & (IAB) Expires November 23, 2006 [Page 3]
Internet-Draft draft-iab-rfc-editor-00 May 2006 2. RFC Editor Charter The RFC Editor executes editorial management for the publication of the "Request for Comment" (RFC) document series. 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 RFC Editor is expected to publish all approved documents. It is the responsibility of the IAB to approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor. The rest of this document outlines the current set of policies and requirements, as well as the appropriate processes for extending or adjusting them. Daigle & (IAB) Expires November 23, 2006 [Page 4]
Internet-Draft draft-iab-rfc-editor-00 May 2006 3. RFC Approval Processes Various contributors provide input to the RFC series. These contributors come from several different communities, each wtih its own defined process for approving documents that will be published by the RFC Editor. These are referred to as "streams". The subsections below identify the streams that exist today. Creation of new streams is subject to IAB approval. Processes for the approval processes (or requirements) for each stream are defined by the community that defines the stream. Except as noted, the IAB does not have final authority in approving such changes, but the IAB must agree that the changes are consistent with the RFC Editor scope. The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams. 3.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 track must follow this stream. Approval of documents in this stream is defined by the IETF standards process (RFC2026, [3], and its successors). Changes to the approval process for this stream are made by updating the IETF standards process documents. 3.2. IAB Document Stream The IAB defines the processes by which it approves its documents. (This is currently defined on a web page. Going forward, it will be published as an RFC.) Consistent with the above, any documents that the IAB wishes to publish as BCPs (part of the IETF standards track) are subject to the approval processes referred to in Section Section 3.1. 3.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. Current document draft: draft-irtf-rfcs-00.txt Daigle & (IAB) Expires November 23, 2006 [Page 5]
Internet-Draft draft-iab-rfc-editor-00 May 2006 3.4. Independent Submission Stream The RFC series has traditionally 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. Consistent with the rest of the streams, there needs to be a community consensus document to define that process. The IAB will establish a community forum for defining a community consensus based document to define the approval process for this stream. The IAB will be responsible for gauging consensus on that document, as well as providing the forum for any needed future revisions of the document. Daigle & (IAB) Expires November 23, 2006 [Page 6]
Internet-Draft draft-iab-rfc-editor-00 May 2006 4. RFC Technical Publication Requirements The community of effort behind each stream may have a set of requirements for the technical publication of their documents. 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. 4.1. IETF Documents These are defined in an IETF stream document. The current proposed version is documented in draft-mankin-pub-req. 4.2. IAB Documents Unless otherwise specified in a future document, the IAB will use the applicable requirements in Section 4.1. 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). 4.3. IRTF Documents Unless otherwise specified in a future document, the IRTF will use the applicable requirements in Section 4.1. 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). 4.4. Independent Submissions Unless otherwise specified in a future document, the RFC Editor will use the applicable requirements in Section 4.1. 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 & (IAB) Expires November 23, 2006 [Page 7]
Internet-Draft draft-iab-rfc-editor-00 May 2006 5. Operational Oversight With the inception of the IETF Administrative Support Activity (BCP101, [2], which describes IASA's support for the IETF, the IAB, the IRTF), the operational oversight of the RFC Editor is shared with the IAOC. The IAOC works with the IAB to identify suitable persons or entities to carry out the work defined by the technical publication requirements defined for the various RFC input streams (see Section Section 4). The IAOC may define additional operational requirements and policies for management purposes, in order to meet the requirements defined by the various communities. The IAOC establishes appropriate (contractual) agreements with the selected persons or entities for the RFC Editor. In accordance with BCP101, the IAOC provides oversight of the operation of the RFC Editor activity based on the established agreement(s). 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 & (IAB) Expires November 23, 2006 [Page 8]
Internet-Draft draft-iab-rfc-editor-00 May 2006 6. Security Considerations The processes for the publication of documents must prevent the introduction of unapproved changes. Since the IETF publisher maintains the index of publications, sufficient security must be in place to prevent these published documents from being changed by external parties. Daigle & (IAB) Expires November 23, 2006 [Page 9]
Internet-Draft draft-iab-rfc-editor-00 May 2006 7. IAB members at the time of approval To be filled in. 8. 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. Daigle & (IAB) Expires November 23, 2006 [Page 10]
Internet-Draft draft-iab-rfc-editor-00 May 2006 Authors' Addresses Leslie L. Daigle Ed. Email: ledaigle@cisco.com, leslie@thinkingcat.com Internet Architecture Board Email: iab@iab.org URI: http://www.iab.org/ Daigle & (IAB) Expires November 23, 2006 [Page 11]
Internet-Draft draft-iab-rfc-editor-00 May 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daigle & (IAB) Expires November 23, 2006 [Page 12]