idnits 2.17.1 draft-iab-rfc-editor-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 841. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-iab-rfc-editor', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-iab-rfc-editor', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-iab-rfc-editor', but the file name used is 'draft-iab-rfc-editor-04' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2007) is 6228 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 3932 (ref. '4') (Obsoleted by RFC 5742) ** Obsolete normative reference: RFC 2223 (ref. '5') (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3978 (ref. '7') (Obsoleted by RFC 5378) ** Downref: Normative reference to an Informational draft: draft-iesg-sponsoring-guidelines (ref. '9') ** Downref: Normative reference to an Informational draft: draft-iab-publication (ref. '10') ** Downref: Normative reference to an Informational draft: draft-irtf-rfcs (ref. '11') -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational draft: draft-rfc-editor-rfc2223bis (ref. '13') ** Downref: Normative reference to an Informational RFC: RFC 4714 (ref. '14') ** Obsolete normative reference: RFC 1358 (ref. '15') (Obsoleted by RFC 1601) ** Obsolete normative reference: RFC 1601 (ref. '16') (Obsoleted by RFC 2850) ** Downref: Normative reference to an Informational RFC: RFC 2555 (ref. '17') ** Obsolete normative reference: RFC 4748 (ref. '18') (Obsoleted by RFC 5378) Summary: 15 errors (**), 1 flaw (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Daigle 3 Internet-Draft Ed. 4 Expires: September 2, 2007 Internet Architecture Board 5 (IAB) 6 March 1, 2007 8 The RFC Series and RFC Editor 9 draft-iab-rfc-editor 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes the framework for an RFC Series and an RFC 43 Editor function that incorporate the principles of organized 44 community involvement and accountability that has become necessary as 45 the Internet technical community has grown, thereby enabling the RFC 46 Series to continue to fulfill its mandate. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . . 6 52 3. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 7 53 3.1. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.2. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.3. Operational Oversight . . . . . . . . . . . . . . . . . . 7 56 3.4. Policy Oversight . . . . . . . . . . . . . . . . . . . . . 8 57 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Document Approval . . . . . . . . . . . . . . . . . . . . 9 59 4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1.2. Operational Implementation . . . . . . . . . . . . . . 10 61 4.1.3. Process Change . . . . . . . . . . . . . . . . . . . . 10 62 4.1.4. Existing Approval Process Documents . . . . . . . . . 10 63 4.2. Editing, Processing and Publication of Documents . . . . . 10 64 4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2.2. Operational Implementation . . . . . . . . . . . . . . 11 66 4.2.3. Process Change . . . . . . . . . . . . . . . . . . . . 11 67 4.2.4. Existing Process Documents . . . . . . . . . . . . . . 11 68 4.3. Archiving, Indexing and Accessibility . . . . . . . . . . 11 69 4.3.1. Definition . . . . . . . . . . . . . . . . . . . . . . 11 70 4.3.2. Operational Implementation . . . . . . . . . . . . . . 12 71 4.3.3. Process Change . . . . . . . . . . . . . . . . . . . . 12 72 4.3.4. Existing Process Documents . . . . . . . . . . . . . . 12 73 4.4. Series-wide Guidelines and Rules . . . . . . . . . . . . . 12 74 4.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 12 75 4.4.2. Operational Implementation . . . . . . . . . . . . . . 12 76 4.4.3. Change Process . . . . . . . . . . . . . . . . . . . . 12 77 4.4.4. Existing Process Documents . . . . . . . . . . . . . . 13 78 5. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.1. RFC Approval Processes . . . . . . . . . . . . . . . . . . 14 80 5.1.1. IETF Document Stream . . . . . . . . . . . . . . . . . 14 81 5.1.2. IAB Document Stream . . . . . . . . . . . . . . . . . 15 82 5.1.3. IRTF Document Stream . . . . . . . . . . . . . . . . . 15 83 5.1.4. Independent Submission Stream . . . . . . . . . . . . 15 84 5.2. RFC Technical Publication Requirements . . . . . . . . . . 16 85 5.2.1. IETF Documents . . . . . . . . . . . . . . . . . . . . 16 86 5.2.2. IAB Documents . . . . . . . . . . . . . . . . . . . . 16 87 5.2.3. IRTF Documents . . . . . . . . . . . . . . . . . . . . 16 88 5.2.4. Independent Submissions . . . . . . . . . . . . . . . 16 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 8. IAB members at the time of approval . . . . . . . . . . . . . 20 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 Appendix A. A Retrospective of IAB Charters and RFC Editor . . . 23 94 A.1. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 A.2. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 A.3. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 98 Intellectual Property and Copyright Statements . . . . . . . . . . 26 100 1. Introduction 102 The first Request for Comment (RFC) document was published in April 103 of 1969 as part of the effort to design and build what we now know of 104 as the Internet. Since then, the RFC series has been the archival 105 series dedicated to documenting Internet technical specifications, 106 including both general contributions from the Internet research and 107 engineering community as well as standards documents. 109 As described in the history of the first 30 years of RFCs ([17]), the 110 RFC series was created for the purpose of capturing the research and 111 engineering thought that underlies the design of (what we now know of 112 as) the Internet. As the Internet Engineering Task Force was 113 formalized to carry out the discussion and documentation of Internet 114 standards, IETF documents have become a large part (but not the 115 entirety) of the RFC series. 117 As the IETF has grown up and celebrated its own 20 years of history, 118 its requirements for archival publication of its output have changed 119 and become more rigorous. Perhaps most significantly, the IETF must 120 be able to define (based on its own open consensus discussion 121 processes and leadership directions) and implement adjustments to its 122 publication processes. 124 At the same time, the Internet engineering and research community as 125 a whole has grown and come to require more openness and 126 accountability in all organizations supporting it. More than ever, 127 this community needs an RFC Series that is supported (operationally 128 and in terms of its principles) such that there is a balance of: 130 o expert implementation; 132 o clear management and direction -- for operations & evolution 133 across all the whole RFC series (whether originating in the IETF 134 or not); and 136 o appropriate community input into and review of activities. 138 Today, there is confusion and therefore sometimes tension over where 139 and how to address RFC issues that are particular to contributing 140 groups (e.g., IETF, or IAB, or independent individuals). It isn't 141 clear where there should be community involvement versus RFC Editor 142 control; depending on the issue, there might be more or less 143 involvement from the IAB or IESG or community at large. There are 144 similar issues with handling RFC Series-wide issues -- where to 145 discuss and resolve them in a way that is balanced across the whole 146 series? 147 For example, there are current discussions about Intellectual 148 Property Rights (IPR) for IETF-generated documents, but it's not 149 clear when or how to abstract the portions of those discussions that 150 are relevant to the rest of the RFC Series. Discussions of labeling 151 (of RFCs in general, IETF documents in particular, or some 152 combination thereof) generally must be applied on an RFC Series-wide 153 basis or not at all. Without an agreed-on framework for managing the 154 RFC Series, it is difficult to have those discussions in a non- 155 polarized fashion -- either the IETF dictating the reality of the 156 rest of the RFC Series, or the RFC Series imposing undue restrictions 157 on the IETF document series. 159 As part of its charter (see Appendix A), the IAB has a responsibility 160 for the RFC Editor. Acknowledging the IETF's and the general 161 Internet engineering and research community's evolving needs, the IAB 162 would like to see a future for the RFC series that continues to meet 163 its original mandate of providing the archival series for the 164 technical research and engineering documentation that describes the 165 Internet. 167 With this document, the IAB provides the framework for the RFC series 168 and an RFC Editor function with the specific purpose of ensuring the 169 RFC series is maintained and supported in ways that are consistent 170 with the stated purpose of the RFC series and the realities of 171 today's Internet research and engineering community. The framework 172 describes the existing "streams" of RFCs, draws a roadmap of existing 173 process documents already defining the implementation, and provides 174 clear direction of how to evolve this framework and its supporting 175 pieces through discussion and future document revision. 177 Specifically, this document provides a brief charter for the RFC 178 Series, describes the role of the RFC Editor, IAB and IASA in a 179 framework for managing the RFC Series, and discusses the streams of 180 input to the RFC series from the various constituencies it serves. 182 2. RFC Series Mission 184 The RFC Series is the archival series dedicated to documenting 185 Internet technical specifications, including both general 186 contributions from the Internet research and engineering community as 187 well as standards documents. 189 RFCs are available free of charge to anyone via the Internet. 191 3. Roles and Responsibilities 193 As this document proposes changes to the framework for supporting the 194 RFC Series mission, this section reviews the planned roles and 195 responsibilities of the entities that have had, and will have, 196 involvement in continued support of the mission. 198 3.1. RFC Editor 200 Originally, there was a single person acting as editor of the RFC 201 Series (the RFC Editor). The task has grown, and the work now 202 requires the organized activity of several experts, so there are RFC 203 Editors, or an RFC Editor organization. In time, there may be 204 multiple organizations working together to undertake the work 205 required by the RFC Series. For simplicity's sake, and without 206 attempting to predict how the role might be subdivided among them, 207 this document refers to this collection of experts and organizations 208 as "the RFC Editor". 210 The RFC Editor is an expert technical editor and series editor, 211 acting to support the mission of the RFC Series. As such, the RFC 212 Editor is the implementer handling the editorial management of the 213 RFC Series, in accordance with the defined processes. In addition, 214 the RFC Editor is expected to be the expert and prime mover in 215 discussions about policies for editing, publishing and archiving 216 RFCs. 218 3.2. IAB 220 In this model, the role of the IAB is to ensure that the RFC Series 221 mission is being appropriately fulfilled for the whole community for 222 which it was created. The IAB does not, organizationally, have 223 comprehensive publishing or editorial expertise. Therefore, the role 224 of the IAB as put forward in this document is focused on ensuring 225 that principles are met, the appropriate bodies and communities are 226 duly informed and consulted, and the RFC Editor has what it needs in 227 order to execute on the material that is in their mandate. 229 It is the responsibility of the IAB to approve the appointment of the 230 RFC Editor and to approve the general policy followed by the RFC 231 Editor. 233 3.3. Operational Oversight 235 The IETF Administrative Support Activity (BCP 101, [2]), was created 236 to provide administrative support for the IETF, the IAB, and the 237 IRTF. In its role of supporting the IAB, the IASA is tasked with 238 providing the funding for and operational oversight of the RFC 239 Editor. 241 The IAOC (IETF Administrative Oversight Committee) is the oversight 242 board of the IASA, and the IAD (IETF Administrative Director) is the 243 chief actor for the IASA. 245 The IAOC works with the IAB to identify suitable persons or entities 246 to fulfill the mandate of the RFC Editor. 248 The IAOC establishes appropriate contractual agreements with the 249 selected persons or entities to carry out the work that will satisfy 250 the technical publication requirements defined for the various RFC 251 input streams (see Section 5.2). The IAOC may define additional 252 operational requirements and policies for management purposes, in 253 order to meet the requirements defined by the various communities. 255 In accordance with BCP 101, the IAOC provides oversight of the 256 operation of the RFC Editor activity based on the established 257 agreements. 259 3.4. Policy Oversight 261 The IAB monitors the effectiveness of the policies in force and their 262 implementation to ensure that the RFC Editor activity meets the 263 editorial management and document publication needs as referenced in 264 this document. In the event of serious non-conformance, the IAB, 265 either on its own initiative or at the request of the IAOC, may 266 require the IAOC to vary or terminate and renegotiate the 267 arrangements for the RFC Editor activity. 269 4. Framework 271 With the RFC Series mission outlined above, this document describes a 272 framework for supporting 274 o the operational implementation of the RFC Series, 276 based on 278 o public process and definition documents, 280 for which there are 282 o clear responsibilities and mechanisms for update and change. 284 Generally speaking, the RFC Editor is responsible for the operational 285 implementation of the RFC Series. As outlined in Section 3.3, the 286 IAD provides the oversight of this operational role. 288 The process and definition documents are detailed below, including 289 responsibility for the individual process documents (maintenance and 290 update). The RFC Editor works with the appropriate community to 291 ensure that the process documents reflect current requirements. The 292 IAB is charged with the role of verifying that appropriate community 293 input has been sought and that any changes appropriately account for 294 community requirements. 296 There are 3 categories of activity, and a 4th category of series-wide 297 rules and guidelines, described for implementing the RFC Series to 298 support its mission: 300 o Approval of documents. 302 o Editing, processing, and publication of documents. 304 o Archiving and indexing the documents and making them accessible. 306 o Series rules and guidelines. 308 4.1. Document Approval 310 The RFC Series mission implicitly requires that documents are 311 reviewed and approved for acceptance into the series. 313 4.1.1. Definition 315 Section 5.1 describes the different streams of documents that are put 316 to the RFC Editor for publication as RFCs today. While there may be 317 general policies for approval of documents as RFCs (to ensure the 318 coherence of the RFC Series), there are also policies defined for the 319 approval of documents in each stream. Generally speaking, there is a 320 different approving body for each stream. The current definitions 321 are catalogued in Section 5.1. 323 4.1.2. Operational Implementation 325 Each stream has its own documented approval process. The RFC Editor 326 is responsible for the approval of documents in one of the streams 327 (Independent Submission stream, see Section 5.1.4), and works with 328 the other approving bodies to ensure smooth passage of approved 329 documents into the next phases, ultimately to publication and 330 archiving as an RFC. 332 4.1.3. Process Change 334 From time to time, it may be necessary to change the approval 335 processes for any given stream, or even add or remove streams. This 336 may occur when the RFC Editor, the IAB, the body responsible for a 337 given stream of documents, or the community determines that there are 338 issues to be resolved in general for RFC approval, or for per-stream 339 approval processes. 341 In this framework, the general approach is that the IAB will work 342 with the RFC Editor and other parties to get community input and it 343 will verify that any changes appropriately account for community 344 requirements. 346 4.1.4. Existing Approval Process Documents 348 The existing documents describing the approval processes for each 349 stream are detailed in Section 5.1. 351 4.2. Editing, Processing and Publication of Documents 353 Producing and maintaining a coherent, well-edited document series 354 requires specialized skills and subject matter expertise. This is 355 the domain of the RFC Editor. Nevertheless, the community served by 356 the RFC Series, and the communities served by the individual streams 357 of RFCs, have requirements that help define the nature of the series. 359 4.2.1. Definition 361 General and stream-specific requirements for the RFC Series are 362 documented in community approved documents (catalogued in Section 5.2 363 below). 365 Any specific interfaces, numbers or concrete values required to make 366 the requirements operational are the subject of agreements between 367 the IASA and the RFC Editor (e.g., contracts, statement of work, 368 service level agreement, etc). 370 4.2.2. Operational Implementation 372 The RFC Editor is responsible for ensuring that editing, processing 373 and publication of RFCs are carried out in a way that is consistent 374 with the requirements laid out in the appropriate documents. The RFC 375 Editor works with the IASA to provide regular reporting and feedback 376 on these operations. 378 4.2.3. Process Change 380 From time to time, it may be necessary to change the requirements for 381 any given stream, or the RFC series in general. This may occur when 382 the RFC Editor, the IAB, the approval body for a given stream of 383 documents, or the community determines that there are issues to be 384 resolved in general for RFCs, or for per-stream requirements. 386 In this model, the general approach is that the IAB will work with 387 the RFC Editor to get community input and it will approve changes by 388 validating appropriate consideration of community requirements. 390 4.2.4. Existing Process Documents 392 Documents describing existing requirements for the streams are 393 detailed in Section 5.2. 395 4.3. Archiving, Indexing and Accessibility 397 The activities of archiving, indexing and making accessible the RFC 398 Series can be informed by series editing subject matter expertise. 399 It is also important that they are informed by requirements from the 400 whole community. As long as the RFC Series is to remain coherent, 401 there should be uniform archiving and indexing of RFCs across all 402 streams and a common method of accessing the resulting documents. 404 4.3.1. Definition 406 In principle, there should be a community consensus document 407 describing the archiving, indexing and accessibility requirements for 408 the RFC Series. In practice, we continue with the archive as built 409 by the capable RFC Editors since the series' inception. 411 Any specific concrete requirements for the archive, index, and 412 accessibility operations are the subject of agreements between the 413 IASA and the RFC Editor (e.g., contracts, statement of work, service 414 level agreement, etc). 416 4.3.2. Operational Implementation 418 The RFC Editor is responsible for ensuring the RFC archive and index 419 are maintained appropriately and that the resulting documents are 420 made available to anybody wishing to access them via the Internet. 421 The RFC Editor works with the IASA for regular reporting and 422 feedback. 424 4.3.3. Process Change 426 Should there be a community move to propose changes to the 427 requirements for the RFC archive and index or accessibility, the IAB 428 will work with the RFC Editor to get community input and it will 429 approve changes by validating appropriate consideration of community 430 requirements. 432 4.3.4. Existing Process Documents 434 There are no applicable process documents. 436 4.4. Series-wide Guidelines and Rules 438 The RFC Series style and content can be shaped by series editing 439 subject matter expertise. They are also informed by requirements by 440 the using community. As long as the RFC Series is to remain 441 coherent, there should be uniform style and content for RFCs across 442 all streams. This includes, but is not limited to, acceptable 443 language, use of references, copyright rules. 445 4.4.1. Definition 447 In principle, there should be a community consensus document (or set 448 of documents) describing the content requirements for the RFC Series. 449 In practice, some do exist, though some need reviewing and more may 450 be needed over time. 452 4.4.2. Operational Implementation 454 The RFC Editor is responsible for ensuring the RFC series guidelines 455 are upheld within the RFC Series. 457 4.4.3. Change Process 459 When additions or changes are needed to series-wide definitions, the 460 IAB will work with the RFC Editor and stream stakeholders to get 461 community input and review. The IAB will approve changes by 462 validating appropriate consideration of community requirements. 464 4.4.4. Existing Process Documents 466 Existing series-wide rules and guidelines documents include: 468 o Instructions to RFC Authors (RFC 2223, [5], [13]) 470 o Copyright and intellectual property rules (RFC 3978, [7] and RFC 471 4748, [18]) 473 o Normative references (RFC 3967, [6] and RFC VVVV, [8]) 475 5. RFC Streams 477 Various contributors provide input to the RFC series. These 478 contributors come from several different communities, each with its 479 own defined process for approving documents that will be published by 480 the RFC Editor. This is nothing new; however, over time, the various 481 communities and document requirements have grown and separated. In 482 order to promote harmony in discussing the collective set of 483 requirements, it is useful to recognize each in their own space -- 484 and they are referred to here as "streams". 486 Note that by identifying separate streams, there is no intention of 487 dividing them or undermining their management as one series. Rather, 488 the opposite is true -- by clarifying the constituent parts, it is 489 easier to make them work together without the friction that sometimes 490 arises when discussing various requirements today. 492 The subsections below identify the streams that exist today. There 493 is no immediate expectation of new streams being created and it is 494 preferable that new streams NOT be created. Creation of streams, and 495 all policies surrounding general changes to the RFC Series, are 496 discussed above in Section 4. 498 5.1. RFC Approval Processes 500 Processes for approval of documents (or requirements) for each stream 501 are defined by the community that defines the stream. The IAB is 502 charged with the role of verifying that appropriate community input 503 has been sought and that the changes are consistent with the RFC 504 Series mission and this overall framework. 506 The RFC Editor is expected to publish all documents passed to it 507 after appropriate review and approval in one of the identified 508 streams. 510 5.1.1. IETF Document Stream 512 The IETF document stream includes IETF WG documents as well as 513 "individual submissions" sponsored by an IESG area director. Any 514 document being published as part of the IETF standards process must 515 follow this stream -- no other stream can approve Standards track or 516 Best Current Practice (BCP) RFCs. 518 Approval of documents in the IETF stream is defined by 520 o the IETF standards process (RFC2026, [3], and its successors). 522 o the IESG process for sponsoring individual submissions (RFC XXXX, 523 [9]). 525 Changes to the approval process for this stream are made by updating 526 the IETF standards process documents. 528 5.1.2. IAB Document Stream 530 The IAB defines the processes by which it approves documents in its 531 stream. Consistent with the above, any documents that the IAB wishes 532 to publish as part of the IETF standards track (Standards or BCPs) 533 are subject to the approval processes referred to in Section 5.1.1. 535 The review and approval process for documents in the IAB stream is 536 described in 538 o the IAB process for review and approval of its documents (RFC 539 YYYY, [10]). 541 5.1.3. IRTF Document Stream 543 The IRTF is chartered as an activity of the IAB. With the approval 544 of the IAB, the IRTF may publish and update a process for publication 545 of its own, non-IETF standards track, documents. 547 The review and approval process for documents in the IRTF stream is 548 described in 550 o IRTF Research Group RFCs, (RFC ZZZZ, [11]). 552 5.1.4. Independent Submission Stream 554 The RFC series has always served a broader Internet technical 555 community than the IETF. The "independent submission" stream is 556 defined to provide review and (possible) approval of documents that 557 are outside the scope of the streams identified above. 559 Generally speaking, approval of documents in this stream falls under 560 the purview of the RFC Editor, and the RFC Editor seeks input to its 561 review from the IESG. 563 The process for reviewing and approving Independent Submission 564 streams documents is defined by 566 Independent Submissions to the RFC Editor (RFC WWWW, [12]) 568 The IESG and RFC Editor Documents: Procedures (RFC 3932, [4]) 570 5.2. RFC Technical Publication Requirements 572 The Internet engineering and research community has not only grown, 573 it has become more diverse, and sometimes more demanding. The IETF, 574 as a standards developing organization, has publication requirements 575 that extend beyond those of an academic journal. The IAB does not 576 have the same interdependence with IANA assignments as the IETF 577 stream does. Therefore, there is the need to both codify the 578 publishing requirements of each stream, and endeavour to harmonize 579 them to the extent that is reasonable. 581 Therefore, it is expected that the community of effort behind each 582 document stream will outline their technical publication 583 requirements. 585 As part of the RFC Editor oversight, the IAB must agree that the 586 requirements are consistent with and implementable as part of the RFC 587 Editor activity. 589 5.2.1. IETF Documents 591 The requirements for this stream are defined in RFC 4714 ([14]). 593 5.2.2. IAB Documents 595 Although they were developed for the IETF standards process, the IAB 596 will identify the applicable requirements in RFC 4714 for its stream. 598 If the IAB elects to define other requirements, they should deviate 599 minimally from those (in an effort to keep the collective technical 600 publication requirements reasonably managed by one technical 601 publisher). 603 5.2.3. IRTF Documents 605 Although they were developed for the IETF standards process, the IRTF 606 will identify the applicable requirements in RFC4714 for its stream. 608 If the IRTF elects to define other requirements, they should deviate 609 minimally from those (in an effort to keep the collective technical 610 publication requirements reasonably managed by one technical 611 publisher). 613 5.2.4. Independent Submissions 615 Although they were developed for the IETF standards process, the RFC 616 Editor will identify the applicable requirements in RFC 4714 for its 617 stream. 619 If the RFC Editor elects to define other requirements, they should 620 deviate minimally from those (in an effort to keep the collective 621 technical publication requirements reasonably managed by one 622 technical publisher). 624 6. Security Considerations 626 The processes for the publication of documents must prevent the 627 introduction of unapproved changes. Since the RFC Editor maintains 628 the index of publications, sufficient security must be in place to 629 prevent these published documents from being changed by external 630 parties. The archive of RFC documents, any source documents needed 631 to recreate the RFC documents and any associated original documents 632 (such as lists of errata, tools, and, for some early items, non- 633 machine readable originals) need to be secured against failure of the 634 storage medium and other similar disasters. 636 7. IANA Considerations 638 This document requires no action on IANA's part. 640 8. IAB members at the time of approval 642 Bernard Aboba 644 Loa Andersson 646 Brian Carpenter 648 Leslie Daigle 650 Elwyn Davies 652 Kevin Fall 654 Olaf Kolkman 656 Kurtis Lindqvist 658 David Meyer 660 David Oran 662 Eric Rescorla 664 Dave Thaler 666 Lixia Zhang 668 9. References 670 [1] Carpenter, B., "Charter of the Internet Architecture Board 671 (IAB)", RFC 2850, May 2000. 673 [2] Austein, R. and B. Wijnen, "Structure of the IETF 674 Administrative Support Activity (IASA)", BCP 101, April 2005. 676 [3] Bradner, S., "The Internet Standards Process -- Revision 3", 677 RFC 2026, October 1996. 679 [4] Alvestrand, H., "The IESG and RFC Editor Documents: 680 Procedures", RFC 3932, October 2004. 682 [5] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 683 RFC 2223, October 1997. 685 [6] Bush, R. and T. Narten, "Clarifying when Standards Track 686 Documents may Refer Normatively to Documents at a Lower Level", 687 RFC 3967, December 2004. 689 [7] Bradner, Ed., S., "IETF Rights in Contributions", RFC 3978, 690 March 2005. 692 [8] Klensin, J., "A Process Experiment in Normative Reference 693 Handling", draft-klensin-norm-ref (work in progress), 694 April 2006. 696 [9] Arkko, J., "Guidance on Area Director Sponsoring of Documents", 697 draft-iesg-sponsoring-guidelines (work in progress), 698 October 2006. 700 [10] Daigle, L., "Process for Publication of IAB RFCs", 701 draft-iab-publication (work in progress), December 2006. 703 [11] Falk, A., "IRTF Research Group RFCs", draft-irtf-rfcs (work in 704 progress), February 2006. 706 [12] Klensin, J., "Independent Submissions to the RFC Editor", 707 draft-klensin-rfc-independent (work in progress), October 2006. 709 [13] Reynolds, Editor, J. and R. Braden, Editor, "Instructions to 710 Request for Comments (RFC) Authors", 711 draft-rfc-editor-rfc2223bis (work in progress), August 2004. 713 [14] Mankin, A. and S. Hayes, "Requirements for IETF Technical 714 Publication Service", RFC 4714, October 2006. 716 [15] Chapin, L., "Charter of the Internet Architecture Board (IAB)", 717 RFC 1358, August 1992. 719 [16] Huitema, C., "Charter of the Internet Architecture Board 720 (IAB)", RFC 1601, March 1994. 722 [17] Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999. 724 [18] Bradner, Ed., S., "RFC 3978 Update to Recognize the IETF 725 Trust", RFC 4748, October 2006. 727 Appendix A. A Retrospective of IAB Charters and RFC Editor 729 With this document, the IAB's role with respect to the RFC Series and 730 the RFC Editor is being adjusted to work more directly with the RFC 731 Editor and provide oversight to ensure the RFC Series mission 732 principles and communities' input are addressed appropriately. 734 This section provides an overview of the role of the IAB with respect 735 to the RFC Editor as it has been presented in IAB Charter RFCs dating 736 back to 1992. The point of this section is that the IAB's role has 737 historically been substantive -- whether it is supposed to be 738 directly responsible for the RFC series' editorial management (circa 739 1992, Appendix A.1), or appointment of the RFC Editor organization 740 and approval of general policy (circa 2000, Appendix A.3). 742 A.1. 1992 744 [15] says: 746 [The IAB's] responsibilities shall include: 747 [...] 748 (2) The editorial management and publication of the Request for 749 Comments (RFC) document series, which constitutes the 750 archival publication series for Internet Standards and 751 related contributions by the Internet research and 752 engineering community. 754 A.2. 1994 756 [16] says: 758 [The IAB's] responsibilities under this charter include: 760 (d) RFC Series and IANA 762 The IAB is responsible for editorial management and publication of 763 the Request for Comments (RFC) document series, and for 764 administration of the various Internet assigned numbers. 766 which it elaborates as 768 2.4 RFC Series and Assigned Numbers 770 The RFC series constitutes the archival publication channel for 771 Internet Standards and for other contributions by the Internet 772 research and engineering community. The IAB shall select an RFC 773 Editor, who shall be responsible for the editorial management and 774 publication of the RFC series. 776 A.3. 2000 778 [1], which is the most recent IAB Charter document, says: 780 (d) RFC Series and IANA 782 The RFC Editor executes editorial management and publication of the 783 IETF "Request for Comment" (RFC) document series, which is the 784 permanent document repository of the IETF. The RFC series 785 constitutes the archival publication channel for Internet Standards 786 and for other contributions by the Internet research and engineering 787 community. RFCs are available free of charge to anyone via the 788 Internet. The IAB must approve the appointment of an organization to 789 act as RFC Editor and the general policy followed by the RFC Editor. 791 Authors' Addresses 793 Leslie L. Daigle 794 Ed. 796 Email: ledaigle@cisco.com, leslie@thinkingcat.com 798 (IAB) 800 Email: iab@iab.org 801 URI: http://www.iab.org/ 803 Full Copyright Statement 805 Copyright (C) The IETF Trust (2007). 807 This document is subject to the rights, licenses and restrictions 808 contained in BCP 78, and except as set forth therein, the authors 809 retain all their rights. 811 This document and the information contained herein are provided on an 812 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 813 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 814 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 815 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 816 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 817 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Intellectual Property 821 The IETF takes no position regarding the validity or scope of any 822 Intellectual Property Rights or other rights that might be claimed to 823 pertain to the implementation or use of the technology described in 824 this document or the extent to which any license under such rights 825 might or might not be available; nor does it represent that it has 826 made any independent effort to identify any such rights. Information 827 on the procedures with respect to rights in RFC documents can be 828 found in BCP 78 and BCP 79. 830 Copies of IPR disclosures made to the IETF Secretariat and any 831 assurances of licenses to be made available, or the result of an 832 attempt made to obtain a general license or permission for the use of 833 such proprietary rights by implementers or users of this 834 specification can be obtained from the IETF on-line IPR repository at 835 http://www.ietf.org/ipr. 837 The IETF invites any interested party to bring to its attention any 838 copyrights, patents or patent applications, or other proprietary 839 rights that may cover technology that may be required to implement 840 this standard. Please address the information to the IETF at 841 ietf-ipr@ietf.org. 843 Acknowledgment 845 Funding for the RFC Editor function is provided by the IETF 846 Administrative Support Activity (IASA).