idnits 2.17.1 draft-ietf-iasa2-rfc4844-bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC4844, but the abstract doesn't seem to directly say this. It does mention RFC4844 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2019) is 1627 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1358 (Obsoleted by RFC 1601) -- Obsolete informational reference (is this intentional?): RFC 1601 (Obsoleted by RFC 2850) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 4748 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley, Ed. 3 Internet-Draft Vigil Security 4 Obsoletes: 4844 (if approved) L. Daigle, Ed. 5 Intended status: Informational Thinking Cat 6 Expires: April 17, 2020 October 15, 2019 8 The RFC Series and RFC Editor 9 draft-ietf-iasa2-rfc4844-bis-04 11 Abstract 13 This document describes the framework for an RFC Series and an RFC 14 Editor function that incorporate the principles of organized 15 community involvement and accountability that has become necessary as 16 the Internet technical community has grown, thereby enabling the RFC 17 Series to continue to fulfill its mandate. 19 Cover Note: 21 {{ RFC Editor: Please remove this cover note prior to publication. }} 23 The IASA2 WG asks the IAB to publish this replacement for RFC 4844. 24 The document is changed for alignment with the new structure for the 25 IETF Administrative Support Activity (IASA), eliminating all 26 references to the IETF Administrative Oversight Committee (IAOC). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 17, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . 5 64 3. Roles and Responsibilities . . . . . . . . . . . . . . . . . 5 65 3.1. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Operational Oversight . . . . . . . . . . . . . . . . . . 6 68 3.4. Policy Oversight . . . . . . . . . . . . . . . . . . . . 6 69 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Document Approval . . . . . . . . . . . . . . . . . . . . 8 71 4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.2. Operational Implementation . . . . . . . . . . . . . 8 73 4.1.3. Process Change . . . . . . . . . . . . . . . . . . . 8 74 4.1.4. Existing Approval Process Documents . . . . . . . . . 8 75 4.2. Editing, Processing, and Publication of Documents . . . . 8 76 4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . 9 77 4.2.2. Operational Implementation . . . . . . . . . . . . . 9 78 4.2.3. Process Change . . . . . . . . . . . . . . . . . . . 9 79 4.2.4. Existing Process Documents . . . . . . . . . . . . . 9 80 4.3. Archiving, Indexing, and Accessibility . . . . . . . . . 9 81 4.3.1. Definition . . . . . . . . . . . . . . . . . . . . . 10 82 4.3.2. Operational Implementation . . . . . . . . . . . . . 10 83 4.3.3. Process Change . . . . . . . . . . . . . . . . . . . 10 84 4.3.4. Existing Process Documents . . . . . . . . . . . . . 10 85 4.4. Series-Wide Guidelines and Rules . . . . . . . . . . . . 10 86 4.4.1. Definition . . . . . . . . . . . . . . . . . . . . . 10 87 4.4.2. Operational Implementation . . . . . . . . . . . . . 11 88 4.4.3. Process Change . . . . . . . . . . . . . . . . . . . 11 89 4.4.4. Existing Process Documents . . . . . . . . . . . . . 11 90 5. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 5.1. RFC Approval Processes . . . . . . . . . . . . . . . . . 12 92 5.1.1. IETF Document Stream . . . . . . . . . . . . . . . . 12 93 5.1.2. IAB Document Stream . . . . . . . . . . . . . . . . . 12 94 5.1.3. IRTF Document Stream . . . . . . . . . . . . . . . . 12 95 5.1.4. Independent Submission Stream . . . . . . . . . . . . 13 96 5.2. RFC Technical Publication Requirements . . . . . . . . . 13 97 5.2.1. IETF Documents . . . . . . . . . . . . . . . . . . . 14 98 5.2.2. IAB Documents . . . . . . . . . . . . . . . . . . . . 14 99 5.2.3. IRTF Documents . . . . . . . . . . . . . . . . . . . 14 100 5.2.4. Independent Submissions . . . . . . . . . . . . . . . 14 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 102 7. Changes Since RFC4844 . . . . . . . . . . . . . . . . . . . . 15 103 8. Informative References . . . . . . . . . . . . . . . . . . . 15 104 Appendix A. A Retrospective of IAB Charters and RFC Editor . . . 18 105 A.1. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 A.2. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 A.3. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 108 Appendix B. IAB Members at the Time of Approval . . . . . . . . 19 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 111 1. Introduction 113 The first Request for Comments (RFC) document was published in April 114 of 1969 as part of the effort to design and build what we now know of 115 as the Internet. Since then, the RFC Series has been the archival 116 series dedicated to documenting Internet technical specifications, 117 including both general contributions from the Internet research and 118 engineering community as well as standards documents. 120 As described in the history of the first 30 years of RFCs 121 ([RFC2555]), the RFC Series was created for the purpose of capturing 122 the research and engineering thought that underlie the design of 123 (what we now know of as) the Internet. As the Internet Engineering 124 Task Force (IETF) was formalized to carry out the discussion and 125 documentation of Internet standards, IETF documents have become a 126 large part (but not the entirety) of the RFC Series. 128 As the IETF has grown up and celebrated its own 30 years of history, 129 its requirements for archival publication of its output have changed 130 and become more rigorous. Perhaps most significantly, the IETF must 131 be able to define (based on its own open consensus discussion 132 processes and leadership directions) and implement adjustments to its 133 publication processes. 135 At the same time, the Internet engineering and research community as 136 a whole has grown and come to require more openness and 137 accountability in all organizations supporting it. More than ever, 138 this community needs an RFC Series that is supported (operationally 139 and in terms of its principles) such that there is a balance of: 141 o expert implementation; 143 o clear management and direction -- for operations and evolution 144 across the whole RFC Series (whether originating in the IETF or 145 not); and 147 o appropriate community input into and review of activities. 149 In the past, there has been confusion and therefore sometimes tension 150 over where and how to address RFC issues that are particular to 151 contributing groups (e.g., the IETF, the Internet Architecture Board 152 (IAB), or independent individuals). It was not always clear where 153 there should be community involvement versus RFC Editor control; 154 depending on the issue, there might be more or less involvement from 155 the IAB, the Internet Engineering Steering Group (IESG), or the 156 community at large. There are similar issues with handling RFC 157 Series-wide issues -- where to discuss and resolve them in a way that 158 is balanced across the whole series. 160 For example, there have been discussions about Intellectual Property 161 Rights (IPR) for IETF-generated documents, but it's not clear when or 162 how to abstract the portions of those discussions that are relevant 163 to the rest of the RFC Series. Discussions of labeling (of RFCs in 164 general, IETF documents in particular, or some combination thereof) 165 generally must be applied to the whole RFC Series-wide or not at all. 166 Without an agreed-on framework for managing the RFC Series, it is 167 difficult to have those discussions in a non-polarized fashion -- 168 either the IETF dictating the reality of the rest of the RFC Series, 169 or the RFC Series imposing undue restrictions on documents from the 170 IETF. 172 As part of its charter (see Appendix A), the IAB has a responsibility 173 for the RFC Editor. Acknowledging the IETF's needs and the general 174 Internet engineering and research community's evolving needs, the IAB 175 supports a future for the RFC Series that continues to meet its 176 original mandate of providing the archival series for the technical 177 research and engineering documentation that describes the Internet. 179 With this document, the IAB provides the framework for the RFC Series 180 and an RFC Editor function with the specific purpose of ensuring that 181 the RFC Series is maintained and supported in ways that are 182 consistent with the stated purpose of the RFC Series and the 183 realities of today's Internet research and engineering community. 184 The framework describes the existing "streams" of RFCs, draws a 185 roadmap of existing process documents already defining the 186 implementation, and provides clear direction of how to evolve this 187 framework and its supporting pieces through discussion and future 188 document revision. 190 Specifically, this document provides a brief charter for the RFC 191 Series, describes the role of the RFC Editor, the IAB, and the IETF 192 Administrative Support Activity (IASA) in a framework for managing 193 the RFC Series, and discusses the streams of input to the RFC Series 194 from the various constituencies it serves. 196 2. RFC Series Mission 198 The RFC Series is the archival series dedicated to documenting 199 Internet technical specifications, including general contributions 200 from the Internet research and engineering community as well as 201 standards documents. 203 RFCs are available free of charge to anyone via the Internet. 205 3. Roles and Responsibilities 207 As this document sets out the framework for supporting the RFC Series 208 mission, this section reviews the updated roles and responsibilities 209 of the entities that have had, and will have, involvement in 210 continued support of the mission. 212 3.1. RFC Editor 214 Originally, there was a single person acting as editor of the RFC 215 Series (the RFC Editor). The task has grown, and the work now 216 requires the organized activity of several experts, so there are RFC 217 Editors, or an RFC Editor organization. In time, there may be 218 multiple organizations working together to undertake the work 219 required by the RFC Series. For simplicity's sake, and without 220 attempting to predict how the role might be subdivided among them, 221 this document refers to this collection of experts and organizations 222 as the "RFC Editor". 224 The RFC Editor is an expert technical editor and series editor, 225 acting to support the mission of the RFC Series. As such, the RFC 226 Editor is the implementer handling the editorial management of the 227 RFC Series, in accordance with the defined processes. In addition, 228 the RFC Editor is expected to be the expert and prime mover in 229 discussions about policies for editing, publishing, and archiving 230 RFCs. 232 3.2. IAB 234 In this model, the role of the IAB is to ensure that the RFC Series 235 mission is being appropriately fulfilled for the whole community for 236 which it was created. The IAB does not, organizationally, have 237 comprehensive publishing or editorial expertise. Therefore, the role 238 of the IAB is focused on ensuring that principles are met, the 239 appropriate bodies and communities are duly informed and consulted, 240 and the RFC Editor has what it needs in order to execute on the 241 material that is in their mandate. 243 It is the responsibility of the IAB to approve the appointment of the 244 RFC Editor and to approve the general policy followed by the RFC 245 Editor. 247 3.3. Operational Oversight 249 The IETF Administration Limited Liability Company (IETF LLC), as part 250 of the IETF Administrative Support Activity (IASA), is responsible 251 for administrative and financial matters for the IETF, the IAB, and 252 the Internet Research Task Force (IRTF) [I-D.ietf-iasa2-rfc4071bis]. 253 The IASA is tasked with providing the funding for the RFC Editor. 254 The IASA, through the IETF Executive Director, provides contractual 255 and financial oversight of the RFC Editor. Additionally, as 256 described in Section 3.1 of [I-D.ietf-iasa2-rfc6635bis], RFC Series 257 Oversight Committee (RSOC), acting with authority delegated from the 258 IAB, is responsible for ensuring that the RFC Series is run in a 259 transparent and accountable manner, including design and execution of 260 the RFC Series Editor selection process. 262 The IETF Executive Director works with the IAB to identify suitable 263 persons or entities to fulfill the mandate of the RFC Production 264 Center and the RFC Publisher roles as defined in 265 [I-D.ietf-iasa2-rfc6635bis]. 267 The IETF Executive Director establishes appropriate contractual 268 agreements with the selected persons or entities to carry out the 269 work that will satisfy the technical publication requirements defined 270 for the various RFC input streams (see Section 5.2). The IETF 271 Executive Director may define additional operational requirements and 272 policies for management purposes to meet the requirements defined by 273 the various communities. 275 The IETF Administration LLC Board approves a budget for operation of 276 the RFC Editor activity, and the IETF Executive Director establishes 277 and manages the necessary operational agreements for the RFC Editor 278 activity. 280 3.4. Policy Oversight 282 The IAB monitors the effectiveness of the policies in force and their 283 implementation to ensure that the RFC Editor activity meets the 284 editorial management and document publication needs as referenced in 285 this document. In the event of serious non-conformance, the IAB, 286 either on its own initiative or at the request of the IETF 287 Administration LLC Board, may require the IETF Executive Director to 288 vary or terminate and renegotiate the arrangements for the RFC Editor 289 activity. 291 4. Framework 293 With the RFC Series mission outlined above, this document describes a 294 framework for supporting 296 o the operational implementation of the RFC Series, 298 based on 300 o public process and definition documents, 302 for which there are 304 o clear responsibilities and mechanisms for update and change. 306 Generally speaking, the RFC Editor is responsible for the operational 307 implementation of the RFC Series. As outlined in Section 3.3, the 308 IETF Executive Director provides the oversight of this operational 309 role. 311 The process and definition documents are detailed below, including 312 responsibility for the individual process documents (maintenance and 313 update). The RFC Editor works with the appropriate community to 314 ensure that the process documents reflect current requirements. The 315 IAB is charged with the role of verifying that appropriate community 316 input has been sought and that any changes appropriately account for 317 community requirements. 319 There are three categories of activity, and a fourth category of 320 series-wide rules and guidelines, described for implementing the RFC 321 Series to support its mission: 323 o Approval of documents. 325 o Editing, processing, and publication of documents. 327 o Archiving and indexing the documents and making them accessible. 329 o Series rules and guidelines. 331 4.1. Document Approval 333 The RFC Series mission implicitly requires that documents be reviewed 334 and approved for acceptance into the series. 336 4.1.1. Definition 338 Section 5.1 describes the different streams of documents that are put 339 to the RFC Editor for publication as RFCs today. While there may be 340 general policies for approval of documents as RFCs (to ensure the 341 coherence of the RFC Series), there are also policies defined for the 342 approval of documents in each stream. Generally speaking, there is a 343 different approving body for each stream. The current definitions 344 are catalogued in Section 5.1. 346 4.1.2. Operational Implementation 348 Each stream has its own documented approval process. The RFC Editor 349 is responsible for the approval of documents in one of the streams 350 (Independent Submission stream, see Section 5.1.4) and works with the 351 other approving bodies to ensure smooth passage of approved documents 352 into the next phases, ultimately to publication and archiving as an 353 RFC. 355 4.1.3. Process Change 357 From time to time, it may be necessary to change the approval 358 processes for any given stream, or even add or remove streams. This 359 may occur when the RFC Editor, the IAB, the body responsible for a 360 given stream of documents, or the community determines that there are 361 issues to be resolved in general for RFC approval or for per-stream 362 approval processes. 364 In this framework, the general approach is that the IAB will work 365 with the RFC Editor and other parties to get community input and it 366 will verify that any changes appropriately account for community 367 requirements. 369 4.1.4. Existing Approval Process Documents 371 The existing documents describing the approval processes for each 372 stream are detailed in Section 5.1. 374 4.2. Editing, Processing, and Publication of Documents 376 Producing and maintaining a coherent, well-edited document series 377 requires specialized skills and subject matter expertise. This is 378 the domain of the RFC Editor. Nevertheless, the community served by 379 the RFC Series and the communities served by the individual streams 380 of RFCs have requirements that help define the nature of the series. 382 4.2.1. Definition 384 General and stream-specific requirements for the RFC Series are 385 documented in community-approved documents (catalogued in Section 5.2 386 below). 388 Any specific interfaces, numbers, or concrete values required to make 389 the requirements operational are the subject of agreements between 390 the IASA and the RFC Editor (e.g., contracts, statements of work, 391 service level agreements, etc). 393 4.2.2. Operational Implementation 395 The RFC Editor is responsible for ensuring that editing, processing, 396 and publication of RFCs are carried out in a way that is consistent 397 with the requirements laid out in the appropriate documents. The RFC 398 Editor works with the IASA to provide regular reporting and feedback 399 on these operations. 401 4.2.3. Process Change 403 From time to time, it may be necessary to change the requirements for 404 any given stream, or the RFC Series in general. This may occur when 405 the RFC Editor, the IAB, the approval body for a given stream of 406 documents, or the community determines that there are issues to be 407 resolved in general for RFCs or for per-stream requirements. 409 In this model, the general approach is that the IAB will work with 410 the RFC Editor to get community input and it will approve changes by 411 validating appropriate consideration of community requirements. 413 4.2.4. Existing Process Documents 415 Documents describing existing requirements for the streams are 416 detailed in Section 5.2. 418 4.3. Archiving, Indexing, and Accessibility 420 The activities of archiving, indexing, and making accessible the RFC 421 Series can be informed by specific subject matter expertise in 422 general document series editing. It is also important that they are 423 informed by requirements from the whole community. As long as the 424 RFC Series is to remain coherent, there should be uniform archiving 425 and indexing of RFCs across all streams and a common method of 426 accessing the resulting documents. 428 4.3.1. Definition 430 In principle, there should be a community consensus document 431 describing the archiving, indexing, and accessibility requirements 432 for the RFC Series. In practice, we continue with the archive as 433 built by the capable RFC Editors since the series' inception. 435 Any specific concrete requirements for the archive, index, and 436 accessibility operations are the subject of agreements between the 437 IASA and the RFC Editor (e.g., contracts, statements of work, service 438 level agreements, etc). 440 4.3.2. Operational Implementation 442 The RFC Editor is responsible for ensuring that the RFC archive and 443 index are maintained appropriately and that the resulting documents 444 are made available to anybody wishing to access them via the 445 Internet. The RFC Editor works with the IASA for regular reporting 446 and feedback. 448 4.3.3. Process Change 450 Should there be a community move to propose changes to the 451 requirements for the RFC archive and index or accessibility, the IAB 452 will work with the RFC Editor to get community input and it will 453 approve changes by validating appropriate consideration of community 454 requirements. 456 4.3.4. Existing Process Documents 458 There are no applicable process documents. 460 4.4. Series-Wide Guidelines and Rules 462 The RFC Series style and content can be shaped by subject matter 463 expertise in document series editing. They are also informed by 464 requirements by the using community. As long as the RFC Series is to 465 remain coherent, there should be uniform style and content for RFCs 466 across all streams. This includes, but is not limited to, acceptable 467 language, use of references, and copyright rules. 469 4.4.1. Definition 471 In principle, there should be a community consensus document (or set 472 of documents) describing the content requirements for the RFC Series. 473 In practice, some do exist, though some need reviewing and more may 474 be needed over time. 476 4.4.2. Operational Implementation 478 The RFC Editor is responsible for ensuring that the RFC Series 479 guidelines are upheld within the RFC Series. 481 4.4.3. Process Change 483 When additions or changes are needed to series-wide definitions, the 484 IAB will work with the RFC Editor and stream stakeholders to get 485 community input and review. The IAB will approve changes by 486 validating appropriate consideration of community requirements. 488 4.4.4. Existing Process Documents 490 Existing series-wide rules and guidelines documents include: 492 o RFC Style Guide [RFC7223], 494 o The Use of Non-ASCII Characters in RFCs [RFC7997], 496 o Copyright and intellectual property rules [RFC3978] [RFC4748], 498 o Normative references [RFC3967] [RFC4897]. 500 5. RFC Streams 502 Various contributors provide input to the RFC Series. These 503 contributors come from several different communities, each with its 504 own defined process for approving documents that will be published by 505 the RFC Editor. This is nothing new; however, over time the various 506 communities and document requirements have grown and separated. In 507 order to promote harmony in discussing the collective set of 508 requirements, it is useful to recognize each in their own space -- 509 and they are referred to here as "streams". 511 Note that by identifying separate streams, there is no intention of 512 dividing them or undermining their management as one series. Rather, 513 the opposite is true -- by clarifying the constituent parts, it is 514 easier to make them work together without the friction that sometimes 515 arises when discussing various requirements. 517 The subsections below identify the streams that exist today. There 518 is no immediate expectation of new streams being created, and it is 519 preferable that new streams NOT be created. Creation of streams and 520 all policies surrounding general changes to the RFC Series are 521 discussed above in Section 4. 523 5.1. RFC Approval Processes 525 Processes for approval of documents (or requirements) for each stream 526 are defined by the community that defines the stream. The IAB is 527 charged with the role of verifying that appropriate community input 528 has been sought and that the changes are consistent with the RFC 529 Series mission and this overall framework. 531 The RFC Editor is expected to publish all documents passed to it 532 after appropriate review and approval in one of the identified 533 streams. 535 5.1.1. IETF Document Stream 537 The IETF document stream includes IETF WG documents as well as 538 "individual submissions" sponsored by an IESG area director. Any 539 document being published as part of the IETF standards process must 540 follow this stream -- no other stream can approve Standards-Track 541 RFCs or Best Current Practice (BCP) RFCs. 543 Approval of documents in the IETF stream is defined by 545 o the IETF standards process [RFC2026] (and its successors). 547 o the IESG process for sponsoring individual submissions [SPONSOR]. 549 Changes to the approval process for this stream are made by updating 550 the IETF standards process documents. 552 5.1.2. IAB Document Stream 554 The IAB defines the processes by which it approves documents in its 555 stream. Consistent with the above, any documents that the IAB wishes 556 to publish as part of the IETF Standards Track (Standards or BCPs) 557 are subject to the approval processes referred to in Section 5.1.1. 559 The review and approval process for documents in the IAB stream is 560 described in 562 o the IAB process for review and approval of its documents 563 [RFC4845]. 565 5.1.3. IRTF Document Stream 567 The IRTF is chartered as an activity of the IAB. With the approval 568 of the IAB, the IRTF may publish and update a process for publication 569 of its own, non-IETF Standards-Track, documents. 571 The review and approval process for documents in the IRTF stream is 572 described in 574 o IRTF Research Group RFCs [RFC5743]. 576 5.1.4. Independent Submission Stream 578 The RFC Series has always served a broader Internet technical 579 community than the IETF. The "Independent Submission" stream is 580 defined to provide review and (possible) approval of documents that 581 are outside the scope of the streams identified above. 583 Generally speaking, approval of documents in this stream falls under 584 the purview of the RFC Editor, and the RFC Editor seeks input to its 585 review from the IESG. 587 The process for reviewing and approving documents in the Independent 588 Submission stream is defined by 590 o Procedures for Rights Handling in the RFC Independent Submission 591 Stream [RFC5744], 593 o Independent Submission Editor Model [I-D.ietf-iasa2-rfc6548bis], 595 o Independent Submissions to the RFC Editor [RFC4846], 597 o The IESG and RFC Editor Documents: Procedures [RFC3932]. 599 5.2. RFC Technical Publication Requirements 601 The Internet engineering and research community has not only grown, 602 it has become more diverse, and sometimes more demanding. The IETF, 603 as a standards-developing organization, has publication requirements 604 that extend beyond those of an academic journal. The IAB does not 605 have the same interdependence with IANA assignments as the IETF 606 stream does. Therefore, there is the need to both codify the 607 publishing requirements of each stream, and endeavor to harmonize 608 them to the extent that is reasonable. 610 Therefore, it is expected that the community of effort behind each 611 document stream will outline their technical publication 612 requirements. 614 As part of the RFC Editor oversight, the IAB must agree that the 615 requirements are consistent with and implementable as part of the RFC 616 Editor activity. 618 5.2.1. IETF Documents 620 The requirements for this stream are defined in [RFC4714]. 622 5.2.2. IAB Documents 624 Although they were developed for the IETF standards process, the IAB 625 has identified applicable requirements in [RFC4714] for its stream. 626 In addition, procedures related to IPR for the IAB stream are 627 captured in [RFC5745]. 629 If the IAB elects to define other requirements, they should deviate 630 minimally from those (in an effort to keep the collective technical 631 publication requirements reasonably managed by one technical 632 publisher). 634 5.2.3. IRTF Documents 636 The IRTF has identified applicable requirements in [RFC5743] for its 637 stream. 639 If the IRTF elects to define other requirements, they should deviate 640 minimally from those (in an effort to keep the collective technical 641 publication requirements reasonably managed by one technical 642 publisher). 644 5.2.4. Independent Submissions 646 Procedures and processes for the Independent Stream are described in 647 [RFC4846] and [I-D.ietf-iasa2-rfc6548bis]. 649 Although they were developed for the IETF standards process, the RFC 650 Editor has identified applicable requirements in [RFC4714] for the 651 independent submissions stream. In addition, procedures related to 652 IPR for the independent submissions stream are captured in [RFC5744]. 654 If the RFC Editor elects to define other requirements, they should 655 deviate minimally from those (in an effort to keep the collective 656 technical publication requirements reasonably managed by one 657 technical publisher). 659 6. Security Considerations 661 The processes for the publication of documents must prevent the 662 introduction of unapproved changes. Since the RFC Editor maintains 663 the index of publications, sufficient security must be in place to 664 prevent these published documents from being changed by external 665 parties. The archive of RFC documents, any source documents needed 666 to recreate the RFC documents, and any associated original documents 667 (such as lists of errata, tools, and, for some early items, non- 668 machine readable originals) need to be secured against failure of the 669 storage medium and other similar disasters. 671 7. Changes Since RFC4844 673 Sections 3.3, 3.4, and 4 have been updated to align with the 674 restructuring of the IETF Administrative Support Activity (IASA). 675 Under the new structure, the IETF LLC performs the tasks related to 676 IASA that were previously assigned to the IETF Administrative 677 Director and to the Internet Society. 679 Many references were updated to point to the most recent documents. 681 Minor editorial changes were made to reflect 10 years of using the 682 framework provided in RFC 4884. For example, RFC 4844 said, "... 683 this document sets out a revised framework ...", and it is now more 684 appropriate to say, "... this document sets out the framework ...". 686 8. Informative References 688 [I-D.ietf-iasa2-rfc4071bis] 689 Haberman, B., Hall, J., and J. Livingood, "Structure of 690 the IETF Administrative Support Activity, Version 2.0", 691 draft-ietf-iasa2-rfc4071bis-11 (work in progress), April 692 2019. 694 [I-D.ietf-iasa2-rfc6548bis] 695 Brownlee, N. and R. Hinden, "Independent Submission Editor 696 Model", draft-ietf-iasa2-rfc6548bis-02 (work in progress), 697 January 2019. 699 [I-D.ietf-iasa2-rfc6635bis] 700 Kolkman, O., Halpern, J., and R. Hinden, "RFC Editor Model 701 (Version 2)", draft-ietf-iasa2-rfc6635bis-04 (work in 702 progress), October 2019. 704 [RFC1358] Chapin, L., "Charter of the Internet Architecture Board 705 (IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992, 706 . 708 [RFC1601] Huitema, C., "Charter of the Internet Architecture Board 709 (IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994, 710 . 712 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 713 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 714 . 716 [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, 717 DOI 10.17487/RFC2555, April 1999, 718 . 720 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 721 "Charter of the Internet Architecture Board (IAB)", 722 BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 723 . 725 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 726 Procedures", RFC 3932, DOI 10.17487/RFC3932, October 2004, 727 . 729 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 730 Documents may Refer Normatively to Documents at a Lower 731 Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 732 2004, . 734 [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", 735 RFC 3978, DOI 10.17487/RFC3978, March 2005, 736 . 738 [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical 739 Publication Service", RFC 4714, DOI 10.17487/RFC4714, 740 October 2006, . 742 [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF 743 Trust", RFC 4748, DOI 10.17487/RFC4748, October 2006, 744 . 746 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 747 for Publication of IAB RFCs", RFC 4845, 748 DOI 10.17487/RFC4845, July 2007, 749 . 751 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent 752 Submissions to the RFC Editor", RFC 4846, 753 DOI 10.17487/RFC4846, July 2007, 754 . 756 [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References 757 to Standards-Track Documents", BCP 97, RFC 4897, 758 DOI 10.17487/RFC4897, June 2007, 759 . 761 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 762 (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, 763 December 2009, . 765 [RFC5744] Braden, R. and J. Halpern, "Procedures for Rights Handling 766 in the RFC Independent Submission Stream", RFC 5744, 767 DOI 10.17487/RFC5744, December 2009, 768 . 770 [RFC5745] Malis, A., Ed. and IAB, "Procedures for Rights Handling in 771 the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745, 772 December 2009, . 774 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 775 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 776 . 778 [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in 779 RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, 780 . 782 [SPONSOR] IESG, "Guidance on Area Director Sponsoring of Documents", 783 IESG Statement , March 2007, 784 . 787 Appendix A. A Retrospective of IAB Charters and RFC Editor 789 With this document, the IAB's role with respect to the RFC Series and 790 the RFC Editor is being adjusted to work more directly with the RFC 791 Editor and provide oversight to ensure the RFC Series mission 792 principles and communities' input are addressed appropriately. 794 This section provides an overview of the role of the IAB with respect 795 to the RFC Editor as it has been presented in IAB Charter RFCs dating 796 back to 1992. The point of this section is that the IAB's role has 797 historically been substantive -- whether it is supposed to be 798 directly responsible for the RFC Series' editorial management (circa 799 1992, Appendix A.1), or appointment of the RFC Editor organization 800 and approval of general policy (circa 2000, Appendix A.3). 802 A.1. 1992 804 [RFC1358] says: 806 [The IAB's] responsibilities shall include: 807 [...] 808 (2) The editorial management and publication of the Request for 809 Comments (RFC) document series, which constitutes the 810 archival publication series for Internet Standards and 811 related contributions by the Internet research and 812 engineering community. 814 A.2. 1994 816 [RFC1601] says: 818 [The IAB's] responsibilities under this charter include: 820 (d) RFC Series and IANA 822 The IAB is responsible for editorial management and publication of 823 the Request for Comments (RFC) document series, and for 824 administration of the various Internet assigned numbers. 826 which it elaborates as 828 2.4 RFC Series and Assigned Numbers 830 The RFC Series constitutes the archival publication channel for 831 Internet Standards and for other contributions by the Internet 832 research and engineering community. The IAB shall select an RFC 833 Editor, who shall be responsible for the editorial management and 834 publication of the RFC Series. 836 A.3. 2000 838 The most recent IAB Charter [RFC2850] says: 840 (d) RFC Series and IANA 842 The RFC Editor executes editorial management and publication of the 843 IETF "Request for Comment" (RFC) document series, which is the 844 permanent document repository of the IETF. The RFC Series 845 constitutes the archival publication channel for Internet Standards 846 and for other contributions by the Internet research and engineering 847 community. RFCs are available free of charge to anyone via the 848 Internet. The IAB must approve the appointment of an organization to 849 act as RFC Editor and the general policy followed by the RFC Editor. 851 Appendix B. IAB Members at the Time of Approval 853 {{ RFC Editor: Fill in the current membership. }} 855 Authors' Addresses 857 Russ Housley (editor) 858 Vigil Security, LLC 860 EMail: housley@vigilsec.com 862 Leslie L. Daigle (editor) 863 Thinking Cat Enterprises 865 EMail: ldaigle@thinkingcat.com