idnits 2.17.1 draft-ietf-iasa2-rfc4844-bis-00.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 12, 2018) is 2023 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 15, 2019 October 12, 2018 8 The RFC Series and RFC Editor 9 draft-ietf-iasa2-rfc4844-bis-00 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 15, 2019. 45 Copyright Notice 47 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 13 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-struct]. The 253 IASA is tasked with providing the funding for and operational 254 oversight of the RFC Editor. 256 The IETF LLC Board provides oversight of the IASA, and the IETF 257 Executive Director is the chief actor for the IASA. 259 The IETF Executive Director works with the IAB to identify suitable 260 persons or entities to fulfill the mandate of the RFC Editor. 262 The IETF Executive Director establishes appropriate contractual 263 agreements with the selected persons or entities to carry out the 264 work that will satisfy the technical publication requirements defined 265 for the various RFC input streams (see Section 5.2). The IETF 266 Executive Director may define additional operational requirements and 267 policies for management purposes to meet the requirements defined by 268 the various communities. 270 The IETF Administration LLC Board approves a budget for operation of 271 the RFC Editor activity, and the IETF Executive Director establishes 272 and manages the necessary operational agreements for the RFC Editor 273 activity. 275 3.4. Policy Oversight 277 The IAB monitors the effectiveness of the policies in force and their 278 implementation to ensure that the RFC Editor activity meets the 279 editorial management and document publication needs as referenced in 280 this document. In the event of serious non-conformance, the IAB, 281 either on its own initiative or at the request of the IETF 282 Administration LLC Board, may require the IETF Executive Director to 283 vary or terminate and renegotiate the arrangements for the RFC Editor 284 activity. 286 4. Framework 288 With the RFC Series mission outlined above, this document describes a 289 framework for supporting 291 o the operational implementation of the RFC Series, 293 based on 295 o public process and definition documents, 297 for which there are 299 o clear responsibilities and mechanisms for update and change. 301 Generally speaking, the RFC Editor is responsible for the operational 302 implementation of the RFC Series. As outlined in Section 3.3, the 303 IETF Executive Director provides the oversight of this operational 304 role. 306 The process and definition documents are detailed below, including 307 responsibility for the individual process documents (maintenance and 308 update). The RFC Editor works with the appropriate community to 309 ensure that the process documents reflect current requirements. The 310 IAB is charged with the role of verifying that appropriate community 311 input has been sought and that any changes appropriately account for 312 community requirements. 314 There are three categories of activity, and a fourth category of 315 series-wide rules and guidelines, described for implementing the RFC 316 Series to support its mission: 318 o Approval of documents. 320 o Editing, processing, and publication of documents. 322 o Archiving and indexing the documents and making them accessible. 324 o Series rules and guidelines. 326 4.1. Document Approval 328 The RFC Series mission implicitly requires that documents be reviewed 329 and approved for acceptance into the series. 331 4.1.1. Definition 333 Section 5.1 describes the different streams of documents that are put 334 to the RFC Editor for publication as RFCs today. While there may be 335 general policies for approval of documents as RFCs (to ensure the 336 coherence of the RFC Series), there are also policies defined for the 337 approval of documents in each stream. Generally speaking, there is a 338 different approving body for each stream. The current definitions 339 are catalogued in Section 5.1. 341 4.1.2. Operational Implementation 343 Each stream has its own documented approval process. The RFC Editor 344 is responsible for the approval of documents in one of the streams 345 (Independent Submission stream, see Section 5.1.4) and works with the 346 other approving bodies to ensure smooth passage of approved documents 347 into the next phases, ultimately to publication and archiving as an 348 RFC. 350 4.1.3. Process Change 352 From time to time, it may be necessary to change the approval 353 processes for any given stream, or even add or remove streams. This 354 may occur when the RFC Editor, the IAB, the body responsible for a 355 given stream of documents, or the community determines that there are 356 issues to be resolved in general for RFC approval or for per-stream 357 approval processes. 359 In this framework, the general approach is that the IAB will work 360 with the RFC Editor and other parties to get community input and it 361 will verify that any changes appropriately account for community 362 requirements. 364 4.1.4. Existing Approval Process Documents 366 The existing documents describing the approval processes for each 367 stream are detailed in Section 5.1. 369 4.2. Editing, Processing, and Publication of Documents 371 Producing and maintaining a coherent, well-edited document series 372 requires specialized skills and subject matter expertise. This is 373 the domain of the RFC Editor. Nevertheless, the community served by 374 the RFC Series and the communities served by the individual streams 375 of RFCs have requirements that help define the nature of the series. 377 4.2.1. Definition 379 General and stream-specific requirements for the RFC Series are 380 documented in community-approved documents (catalogued in Section 5.2 381 below). 383 Any specific interfaces, numbers, or concrete values required to make 384 the requirements operational are the subject of agreements between 385 the IASA and the RFC Editor (e.g., contracts, statements of work, 386 service level agreements, etc). 388 4.2.2. Operational Implementation 390 The RFC Editor is responsible for ensuring that editing, processing, 391 and publication of RFCs are carried out in a way that is consistent 392 with the requirements laid out in the appropriate documents. The RFC 393 Editor works with the IASA to provide regular reporting and feedback 394 on these operations. 396 4.2.3. Process Change 398 From time to time, it may be necessary to change the requirements for 399 any given stream, or the RFC Series in general. This may occur when 400 the RFC Editor, the IAB, the approval body for a given stream of 401 documents, or the community determines that there are issues to be 402 resolved in general for RFCs or for per-stream requirements. 404 In this model, the general approach is that the IAB will work with 405 the RFC Editor to get community input and it will approve changes by 406 validating appropriate consideration of community requirements. 408 4.2.4. Existing Process Documents 410 Documents describing existing requirements for the streams are 411 detailed in Section 5.2. 413 4.3. Archiving, Indexing, and Accessibility 415 The activities of archiving, indexing, and making accessible the RFC 416 Series can be informed by specific subject matter expertise in 417 general document series editing. It is also important that they are 418 informed by requirements from the whole community. As long as the 419 RFC Series is to remain coherent, there should be uniform archiving 420 and indexing of RFCs across all streams and a common method of 421 accessing the resulting documents. 423 4.3.1. Definition 425 In principle, there should be a community consensus document 426 describing the archiving, indexing, and accessibility requirements 427 for the RFC Series. In practice, we continue with the archive as 428 built by the capable RFC Editors since the series' inception. 430 Any specific concrete requirements for the archive, index, and 431 accessibility operations are the subject of agreements between the 432 IASA and the RFC Editor (e.g., contracts, statements of work, service 433 level agreements, etc). 435 4.3.2. Operational Implementation 437 The RFC Editor is responsible for ensuring that the RFC archive and 438 index are maintained appropriately and that the resulting documents 439 are made available to anybody wishing to access them via the 440 Internet. The RFC Editor works with the IASA for regular reporting 441 and feedback. 443 4.3.3. Process Change 445 Should there be a community move to propose changes to the 446 requirements for the RFC archive and index or accessibility, the IAB 447 will work with the RFC Editor to get community input and it will 448 approve changes by validating appropriate consideration of community 449 requirements. 451 4.3.4. Existing Process Documents 453 There are no applicable process documents. 455 4.4. Series-Wide Guidelines and Rules 457 The RFC Series style and content can be shaped by subject matter 458 expertise in document series editing. They are also informed by 459 requirements by the using community. As long as the RFC Series is to 460 remain coherent, there should be uniform style and content for RFCs 461 across all streams. This includes, but is not limited to, acceptable 462 language, use of references, and copyright rules. 464 4.4.1. Definition 466 In principle, there should be a community consensus document (or set 467 of documents) describing the content requirements for the RFC Series. 468 In practice, some do exist, though some need reviewing and more may 469 be needed over time. 471 4.4.2. Operational Implementation 473 The RFC Editor is responsible for ensuring that the RFC Series 474 guidelines are upheld within the RFC Series. 476 4.4.3. Process Change 478 When additions or changes are needed to series-wide definitions, the 479 IAB will work with the RFC Editor and stream stakeholders to get 480 community input and review. The IAB will approve changes by 481 validating appropriate consideration of community requirements. 483 4.4.4. Existing Process Documents 485 Existing series-wide rules and guidelines documents include: 487 o RFC Style Guide [RFC7223], 489 o The Use of Non-ASCII Characters in RFCs [RFC7997], 491 o Copyright and intellectual property rules [RFC3978] [RFC4748], 493 o Normative references [RFC3967] [RFC4897]. 495 5. RFC Streams 497 Various contributors provide input to the RFC Series. These 498 contributors come from several different communities, each with its 499 own defined process for approving documents that will be published by 500 the RFC Editor. This is nothing new; however, over time the various 501 communities and document requirements have grown and separated. In 502 order to promote harmony in discussing the collective set of 503 requirements, it is useful to recognize each in their own space -- 504 and they are referred to here as "streams". 506 Note that by identifying separate streams, there is no intention of 507 dividing them or undermining their management as one series. Rather, 508 the opposite is true -- by clarifying the constituent parts, it is 509 easier to make them work together without the friction that sometimes 510 arises when discussing various requirements. 512 The subsections below identify the streams that exist today. There 513 is no immediate expectation of new streams being created, and it is 514 preferable that new streams NOT be created. Creation of streams and 515 all policies surrounding general changes to the RFC Series are 516 discussed above in Section 4. 518 5.1. RFC Approval Processes 520 Processes for approval of documents (or requirements) for each stream 521 are defined by the community that defines the stream. The IAB is 522 charged with the role of verifying that appropriate community input 523 has been sought and that the changes are consistent with the RFC 524 Series mission and this overall framework. 526 The RFC Editor is expected to publish all documents passed to it 527 after appropriate review and approval in one of the identified 528 streams. 530 5.1.1. IETF Document Stream 532 The IETF document stream includes IETF WG documents as well as 533 "individual submissions" sponsored by an IESG area director. Any 534 document being published as part of the IETF standards process must 535 follow this stream -- no other stream can approve Standards-Track 536 RFCs or Best Current Practice (BCP) RFCs. 538 Approval of documents in the IETF stream is defined by 540 o the IETF standards process [RFC2026] (and its successors). 542 o the IESG process for sponsoring individual submissions [SPONSOR]. 544 Changes to the approval process for this stream are made by updating 545 the IETF standards process documents. 547 5.1.2. IAB Document Stream 549 The IAB defines the processes by which it approves documents in its 550 stream. Consistent with the above, any documents that the IAB wishes 551 to publish as part of the IETF Standards Track (Standards or BCPs) 552 are subject to the approval processes referred to in Section 5.1.1. 554 The review and approval process for documents in the IAB stream is 555 described in 557 o the IAB process for review and approval of its documents 558 [RFC4845]. 560 5.1.3. IRTF Document Stream 562 The IRTF is chartered as an activity of the IAB. With the approval 563 of the IAB, the IRTF may publish and update a process for publication 564 of its own, non-IETF Standards-Track, documents. 566 The review and approval process for documents in the IRTF stream is 567 described in 569 o IRTF Research Group RFCs [RFC5743]. 571 5.1.4. Independent Submission Stream 573 The RFC Series has always served a broader Internet technical 574 community than the IETF. The "Independent Submission" stream is 575 defined to provide review and (possible) approval of documents that 576 are outside the scope of the streams identified above. 578 Generally speaking, approval of documents in this stream falls under 579 the purview of the RFC Editor, and the RFC Editor seeks input to its 580 review from the IESG. 582 The process for reviewing and approving documents in the Independent 583 Submission stream is defined by 585 o Independent Submissions to the RFC Editor [RFC4846], 587 o The IESG and RFC Editor Documents: Procedures [RFC3932]. 589 5.2. RFC Technical Publication Requirements 591 The Internet engineering and research community has not only grown, 592 it has become more diverse, and sometimes more demanding. The IETF, 593 as a standards-developing organization, has publication requirements 594 that extend beyond those of an academic journal. The IAB does not 595 have the same interdependence with IANA assignments as the IETF 596 stream does. Therefore, there is the need to both codify the 597 publishing requirements of each stream, and endeavor to harmonize 598 them to the extent that is reasonable. 600 Therefore, it is expected that the community of effort behind each 601 document stream will outline their technical publication 602 requirements. 604 As part of the RFC Editor oversight, the IAB must agree that the 605 requirements are consistent with and implementable as part of the RFC 606 Editor activity. 608 5.2.1. IETF Documents 610 The requirements for this stream are defined in [RFC4714]. 612 5.2.2. IAB Documents 614 Although they were developed for the IETF standards process, the IAB 615 has identified applicable requirements in [RFC4714] for its stream. 616 In addition, procedures related to IPR for the IAB stream are 617 captured in [RFC5745]. 619 If the IAB elects to define other requirements, they should deviate 620 minimally from those (in an effort to keep the collective technical 621 publication requirements reasonably managed by one technical 622 publisher). 624 5.2.3. IRTF Documents 626 The IRTF has identified applicable requirements in [RFC5743] for its 627 stream. 629 If the IRTF 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.4. Independent Submissions 636 Although they were developed for the IETF standards process, the RFC 637 Editor has identified applicable requirements in [RFC4714] for the 638 independent submissions stream. In addition, procedures related to 639 IPR for the independent submissions stream are captured in [RFC5744]. 641 If the RFC Editor elects to define other requirements, they should 642 deviate minimally from those (in an effort to keep the collective 643 technical publication requirements reasonably managed by one 644 technical publisher). 646 6. Security Considerations 648 The processes for the publication of documents must prevent the 649 introduction of unapproved changes. Since the RFC Editor maintains 650 the index of publications, sufficient security must be in place to 651 prevent these published documents from being changed by external 652 parties. The archive of RFC documents, any source documents needed 653 to recreate the RFC documents, and any associated original documents 654 (such as lists of errata, tools, and, for some early items, non- 655 machine readable originals) need to be secured against failure of the 656 storage medium and other similar disasters. 658 7. Changes Since RFC4844 660 Sections 3.3, 3.4, and 4 have been updated to align with the 661 restructuring of the IETF Administrative Support Activity (IASA). 662 Under the new structure, the IETF LLC performs the tasks that were 663 previously assigned to the IETF Administrative Oversight Committee 664 (IAOC) under the old structure. 666 Many references were updated to point to the most recent documents. 668 Minor editorial changes were made to reflect 10 years of using the 669 framework provided in RFC 4884. For example, RFC 4844 said, "... 670 this document sets out a revised framework ...", and it is now more 671 appropriate to say, "... this document sets out the framework ...". 673 8. Informative References 675 [I-D.ietf-iasa2-struct] 676 Haberman, B., Hall, J., and J. Livingood, "Record of 677 Proposed Structure of the IETF Administrative Support 678 Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06 679 (work in progress), September 2018. 681 [RFC1358] Chapin, L., "Charter of the Internet Architecture Board 682 (IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992, 683 . 685 [RFC1601] Huitema, C., "Charter of the Internet Architecture Board 686 (IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994, 687 . 689 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 690 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 691 . 693 [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, 694 DOI 10.17487/RFC2555, April 1999, 695 . 697 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 698 "Charter of the Internet Architecture Board (IAB)", 699 BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 700 . 702 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 703 Procedures", RFC 3932, DOI 10.17487/RFC3932, October 2004, 704 . 706 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 707 Documents may Refer Normatively to Documents at a Lower 708 Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 709 2004, . 711 [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", 712 RFC 3978, DOI 10.17487/RFC3978, March 2005, 713 . 715 [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical 716 Publication Service", RFC 4714, DOI 10.17487/RFC4714, 717 October 2006, . 719 [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF 720 Trust", RFC 4748, DOI 10.17487/RFC4748, October 2006, 721 . 723 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 724 for Publication of IAB RFCs", RFC 4845, 725 DOI 10.17487/RFC4845, July 2007, 726 . 728 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent 729 Submissions to the RFC Editor", RFC 4846, 730 DOI 10.17487/RFC4846, July 2007, 731 . 733 [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References 734 to Standards-Track Documents", BCP 97, RFC 4897, 735 DOI 10.17487/RFC4897, June 2007, 736 . 738 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 739 (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, 740 December 2009, . 742 [RFC5744] Braden, R. and J. Halpern, "Procedures for Rights Handling 743 in the RFC Independent Submission Stream", RFC 5744, 744 DOI 10.17487/RFC5744, December 2009, 745 . 747 [RFC5745] Malis, A., Ed. and IAB, "Procedures for Rights Handling in 748 the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745, 749 December 2009, . 751 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 752 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 753 . 755 [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in 756 RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, 757 . 759 [SPONSOR] IESG, "Guidance on Area Director Sponsoring of Documents", 760 IESG Statement , March 2007, 761 . 764 Appendix A. A Retrospective of IAB Charters and RFC Editor 766 With this document, the IAB's role with respect to the RFC Series and 767 the RFC Editor is being adjusted to work more directly with the RFC 768 Editor and provide oversight to ensure the RFC Series mission 769 principles and communities' input are addressed appropriately. 771 This section provides an overview of the role of the IAB with respect 772 to the RFC Editor as it has been presented in IAB Charter RFCs dating 773 back to 1992. The point of this section is that the IAB's role has 774 historically been substantive -- whether it is supposed to be 775 directly responsible for the RFC Series' editorial management (circa 776 1992, Appendix A.1), or appointment of the RFC Editor organization 777 and approval of general policy (circa 2000, Appendix A.3). 779 A.1. 1992 781 [RFC1358] says: 783 [The IAB's] responsibilities shall include: 784 [...] 785 (2) The editorial management and publication of the Request for 786 Comments (RFC) document series, which constitutes the 787 archival publication series for Internet Standards and 788 related contributions by the Internet research and 789 engineering community. 791 A.2. 1994 793 [RFC1601] says: 795 [The IAB's] responsibilities under this charter include: 797 (d) RFC Series and IANA 799 The IAB is responsible for editorial management and publication of 800 the Request for Comments (RFC) document series, and for 801 administration of the various Internet assigned numbers. 803 which it elaborates as 805 2.4 RFC Series and Assigned Numbers 807 The RFC Series constitutes the archival publication channel for 808 Internet Standards and for other contributions by the Internet 809 research and engineering community. The IAB shall select an RFC 810 Editor, who shall be responsible for the editorial management and 811 publication of the RFC Series. 813 A.3. 2000 815 The most recent IAB Charter [RFC2850] says: 817 (d) RFC Series and IANA 819 The RFC Editor executes editorial management and publication of the 820 IETF "Request for Comment" (RFC) document series, which is the 821 permanent document repository of the IETF. The RFC Series 822 constitutes the archival publication channel for Internet Standards 823 and for other contributions by the Internet research and engineering 824 community. RFCs are available free of charge to anyone via the 825 Internet. The IAB must approve the appointment of an organization to 826 act as RFC Editor and the general policy followed by the RFC Editor. 828 Appendix B. IAB Members at the Time of Approval 830 {{ RFC Editor: Fill in the current membership. }} 832 Authors' Addresses 834 Russ Housley (editor) 835 Vigil Security, LLC 837 EMail: housley@vigilsec.com 839 Leslie L. Daigle (editor) 840 Thinking Cat Enterprises 842 EMail: ldaigle@thinkingcat.com