From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4844.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc4844.txt (limited to 'doc/rfc/rfc4844.txt') 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] + -- cgit v1.2.3