idnits 2.17.1 draft-carpenter-rfced-model-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2020) is 1344 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8728 (Obsoleted by RFC 9280) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rfced-future B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational August 20, 2020 5 Expires: February 21, 2021 7 Alternative Proposed Model for RFC Editing and Publication 8 draft-carpenter-rfced-model-00 10 Abstract 12 The finishing process for a document that is approved for publication 13 as an RFC currently involves a somewhat detailed and lengthy process. 14 The system that executes that process involves a number of different 15 actors, each bringing competency with different aspects of the 16 overall process. Ensuring that this process functions smoothly is 17 critical to the mission of the organizations that publish documents 18 in the RFC series. 20 This document proposes a framework for that system that aims to 21 provide clear delineations of accountability and responsibility for 22 each of the actors in this system. It would require significant 23 updates to RFC 8728 and RFC 8729, and minor updates to RFC 2850 and 24 RFC 7841. 26 Discussion of this document takes place on the RFC Editor Futures 27 mailing list (rfced-future@iab.org). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 21, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Abstract Model . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Funding and Oversight . . . . . . . . . . . . . . . . . . . . 4 66 3.1. IETF LLC Delegation of Oversight Function . . . . . . . . 5 67 4. Evolution and Setting Policies . . . . . . . . . . . . . . . 6 68 4.1. Individual Interactions . . . . . . . . . . . . . . . . . 8 69 4.2. The Needs of Different Streams . . . . . . . . . . . . . 9 70 4.3. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Management of Individual Functions . . . . . . . . . . . . . 12 73 7. Other Involved Entities . . . . . . . . . . . . . . . . . . . 13 74 8. Role of the RFC Series Advisor . . . . . . . . . . . . . . . 13 75 9. Changes from Version 2 of the RFC Model . . . . . . . . . . . 14 76 9.1. No RFC Series Editor . . . . . . . . . . . . . . . . . . 14 77 9.2. No IAB Responsibility . . . . . . . . . . . . . . . . . . 14 78 9.3. Preserved Aspects of Current Practice . . . . . . . . . . 15 79 9.4. Motivating Principles . . . . . . . . . . . . . . . . . . 15 80 10. Documentation Requirements . . . . . . . . . . . . . . . . . 15 81 10.1. New RFC Stream . . . . . . . . . . . . . . . . . . . . . 17 82 11. Errors and Omissions . . . . . . . . . . . . . . . . . . . . 17 83 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 86 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 15.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Please note that large portions of this draft have been copied, with 94 permission, from [I-D.thomson-rfced-model]. However, the two 95 proposals are substantively different. 97 The RFC Editor Model [RFC8728] describes a system that supports the 98 process of editing and publication of RFCs. Its companion document 99 [RFC8729] covers the related organizational roles, including that of 100 the RFC Series Editor (RSE) in person. Both of these documents were 101 issued by the IAB in pursuance of the relevant item in its charter 102 [RFC2850]. 104 The process of RFC editing and publication currently takes inputs in 105 the form of documents that are approved for publication by one of 106 four existing streams (IETF, IRTF, IAB, and Independent Submissions) 107 [RFC7841]. The output is an RFC. 109 Generally speaking, this system is successful if RFCs are produced at 110 a rate approximating the rate that documents are approved for 111 publication. In addition to managing throughput, the overall latency 112 should be minimized and the quality of documents should be sufficient 113 to serve the ends of the consumers of those documents. 115 In practice, the demands placed on the editing and publication 116 process mean that this function is quite involved. Furthermore, the 117 exact goals that this system serves continually evolve. The current 118 system has evolved out of a relatively simple system, into something 119 like what is described in [RFC8728] with multiple discrete roles and 120 somewhat complex interactions between each. 122 The goal of this document is to ensure that the RFC series can 123 continue to serve as a venue for the publication of documents that 124 are relevant to the Internet. To that end, it aims to define a 125 system for administering the editing and publication process. 127 This aims to be a lightweight system that uses community engagement 128 and transparency as the primary mechanisms for ensuring 129 accountability. This system avoids vesting control in an individual 130 or body with closed membership, preferring open processes for 131 critical strategic functions. 133 This document starts out by building from a simple (even simplistic) 134 model of the system, then builds that out incrementally. The goal is 135 to progressively expand on the relevance of the model in addressing 136 different problems that have been identified as important, or to draw 137 in each of the relevant actors in the system and to attribute 138 responsibilities (and associated authority) to each. 140 2. Abstract Model 142 The highest-level abstraction is shown in Figure 1. 144 +-------------+ +-------------+ 145 | IETF Stream +------->+ +-----> 146 +-------------+ D | | 147 +-------------+ o | | 148 | IRTF Stream +---c--->+ RFC +-----> R 149 +-------------+ u | Editing | F 150 +-------------+ m | and | C 151 | IAB Stream +---e--->+ Publication +-----> s 152 +-------------+ n | | 153 +-------------+ t | | 154 | Independent +---s--->+ +-----> 155 +-------------+ +-------------+ 157 Figure 1: RFC Production Model 159 In this model, each of the document streams produce documents that 160 are approved for publication according to the processes of those 161 streams. Each stream is an independent client of a single entity 162 that provides services in support of publishing documents as RFCs. 163 These services have numerous facets, but the core services are copy 164 editing of documents, the preparation of documents for publication, 165 and the publication of documents. 167 At a high level, each of the streams is an independent customer of 168 the function of RFC Editing and Publication (REP). In [RFC8728], two 169 separate functions are identified (RFC Production Center and RFC 170 Publisher) but externally that distinction seems pointless. The 171 entity (or entities) that perform the REP function are contracted to 172 turn approved documents into RFCs. 174 3. Funding and Oversight 176 The entity that performs the REP function holds contracts with the 177 IETF LLC, who also provides payment for those contracted services. 178 This means that the REP function is ultimately answerable to the IETF 179 LLC with respect to performance. 181 Currently, the IETF LLC delegates some of its authority to another 182 body. This allows the IETF LLC to rely on the expertise of 183 volunteers from the community in performing oversight. The IETF LLC 184 currently delegates this function to the RFC Series Oversight 185 Committee (RSOC) via the IAB. This indirection has caused some 186 problems and this document proposes that oversight be a function that 187 the IETF LLC be responsible for, either directly or through a 188 delegation process that is managed by the IETF LLC. 190 The IETF LLC therefore has authority over negotiating performance 191 targets for the REP and the responsibility of ensuring that those 192 targets are adhered to. The IETF LLC is empowered to appoint a 193 manager or to convene a committee that is responsible for this 194 oversight function. 196 Community members who have concerns about the performance of the REP 197 can request that the IETF LLC investigate the matter. If the IETF 198 LLC opts to delegate the oversight function, concerns can be raised 199 with the IETF LLC. The IETF LLC is ultimately responsible to the 200 community via the mechanisms outlined in its charter [RFC8711]. 202 This results in evolving the basic model as shown in Figure 2. 204 +------+ 205 | IETF | 206 | LLC | 207 +------+ 208 | 209 | Contract & 210 | Oversight 211 v 212 +-------------+ +-------------+ 213 | IETF Stream +------->+ +-----> 214 +-------------+ D | | 215 +-------------+ o | | 216 | IRTF Stream +---c--->+ RFC +-----> R 217 +-------------+ u | Editing | F 218 +-------------+ m | and | C 219 | IAB Stream +---e--->+ Publication +-----> s 220 +-------------+ n | | 221 +-------------+ t | | 222 | Independent +---s--->+ +-----> 223 +-------------+ +-------------+ 225 Figure 2: Oversight and Funding Functions 227 This shows the IETF LLC having budgetary and contractual oversight 228 over the REP. 230 3.1. IETF LLC Delegation of Oversight Function 232 The current organization tasks the RSOC with responsibility for 233 oversight. This has lead to numerous questions about the extent of 234 authority delegated to the RSOC and the responsibilities of various 235 entities that the RSOC is tasked with interacting with. 237 This document avoids these questions by placing this authority 238 directly with the IETF LLC. However, the oversight function is one 239 that the IETF LLC might choose to delegate, either to an individual 240 or committee. 242 Any delegation would ideally result in the creation of a a document 243 governing how the delegation was structured. This is not that 244 document, but this assumes that the person or persons who are given 245 oversight responsibility would be responsible for managing contract 246 and performance for the REP. Any appeal or dispute with the actions 247 of this individual or committee would then be taken up with the IETF 248 LLC. 250 4. Evolution and Setting Policies 252 Setting the strategy and policies for REP functions and more detailed 253 requirements for operation of these functions have historically been 254 delegated to the RSE. This document proposes separating these. The 255 goal is to improve the ability of the community (across all streams) 256 to set and evolve policies. Operational details and targets, on the 257 other hand, clearly fall under the LLC. 259 The strategic requirements of each of the streams change over time. 260 The goal is to find a system that allows the community to develop 261 consensus around the strategic direction for the evolution of the RFC 262 Series. 264 In terms of structure of this effort, the community has a set of 265 well-understood and tested systems for developing consensus. 266 Therefore, this document proposes that strategic goals for the RFC 267 Series are developed using the working group process [RFC2418] used 268 in the IETF to the maximum extent possible, given that the community 269 of interest is broader than the IETF. 271 Concretely, this document proposes forming an RFC Series Advisory 272 Working Group (RSAWG) under the auspices of the Internet Society 273 (ISOC). This would be a group that follows [RFC2418] procedures, 274 with the exception that the oversight and conflict resolution 275 functions performed by the IESG are instead performed by ISOC. In 276 particular, selection of chairs and appeals regarding the execution 277 of the process are directed to the ISOC Board of Trustees to resolve. 278 This is intended to underline the community-wide importance of the 279 RFC Series. 281 Like any IETF working group, the RSAWG will be open to any interested 282 person. This explicitly includes staff of the REP. However, in 283 addition to at least two chairs appointed by ISOC, it is important 284 that each RFC stream has a named representative in the RSAWG who is 285 able to present the requirements of that stream. 287 It is important that this group adopt code of conduct, anti- 288 harrassment, and other policies. Again, existing IETF processes - 289 collectively referred to in the Note Well - are well-suited to this 290 task. 292 Much of the strategy will be concerned with the technical needs of 293 the streams or with other matters that protocol engineers are 294 competent to discuss. However, some matters will arise that are 295 questions of technical editing, publishing, archiving, etc. Protocol 296 engineers cannot be assumed to have the necessary expertise for these 297 topics. Therefore, an outside RFC Series Advisor (RSA) is needed. 298 More details are given below. 300 Any strategic direction that is produced by this process will be 301 documented in RFCs. These will need to be framed as high-level goals 302 and priorities rather than strict requirements. It will be up to the 303 IETF LLC - or their delegate - to negotiate with the REP function 304 about the execution for any changes. In negotiating the execution of 305 strategy, the IETF LLC is expected to factor in relevant factors such 306 as cost, legal constraints, or schedule. 308 The IETF LLC is also responsible for ensuring that the plans for 309 implementation of strategic goals is published and available to the 310 community. 312 This results in the model shown in Figure 3. 314 +------+ 315 | ISOC | 316 +--+---+ 317 | 318 | Oversight 319 v 320 +-----+------+ 321 | RFC Series | 322 | Advisory |<------- RFC Series Advisor 323 | WG | (RSA) 324 +-----+------+ 325 | 326 | Strategy 327 v 328 +--+---+ 329 | IETF | 330 | LLC | 331 +--+---+ 332 | 333 | Contract & 334 | Oversight 335 v 336 +-------------+ +---------+---+ 337 | IETF Stream +------->+ +-----> 338 +-------------+ D | | 339 +-------------+ o | | 340 | IRTF Stream +---c--->+ RFC +-----> R 341 +-------------+ u | Editing | F 342 +-------------+ m | and | C 343 | IAB Stream +---e--->+ Publication +-----> s 344 +-------------+ n | | 345 +-------------+ t | | 346 | Independent +---s--->+ +-----> 347 +-------------+ +-------------+ 349 Figure 3: Evolution and Strategy Additions 351 4.1. Individual Interactions 353 It is important to recognize that the interface to the REP function 354 is most often through individual authors (or chairs, document 355 shepherds, and area directors) and individual REP staff. 357 In those interactions, those individuals might find problems with 358 processes or might be motivated to make suggestions for improvement. 359 The goal of the RSAWG is to provide a single venue for discussion of 360 changes to REP requirements, processes, and procedures. 362 4.2. The Needs of Different Streams 364 The singular group responsible for evolution of the RFC Series as a 365 whole is a simplification that is made to reduce contention in 366 setting strategic goals. It is important to note that the needs of 367 different streams can be different. 369 Several factors motivate a single group that sets strategy. 370 Historically, the IETF stream is responsible for a large proportion 371 of the documents in the series. That is unlikely to change and 372 experience has shown that other streams are - for the most part - 373 willing to accept that strategic direction is largely dictated by the 374 needs of the most prolific user of the REP service. 376 It is important that each stream retain control over the content of 377 documents that are published on that stream. Streams currently 378 appoint a stream manager who is allocated authority over content on 379 that stream and responsibility to manage any problems that might 380 arise in handling documents produced by that stream. This document 381 proposes that this aspect of the role continue. 383 Stream managers are also involved in discussion of changes to REP 384 processes and they contribute to the development of strategic 385 direction for the RFC series. Rather than deal with issues of REP 386 processes directly, stream managers are expected to initiate 387 discussion or make proposals to the RSAWG. To avoid conflicts of 388 interest, it is expected that stream managers will be active 389 participants - and not chairs - in this group. 391 4.3. Style Guide 393 One question that arises when considering policy is that of the Style 394 Guide [RFC7322] and supporting material. These materials are 395 critical to the process of editing and therefore require that they be 396 owned and maintained. 398 The current process requires that the RFC Series Editor produce and 399 maintain this material. This document proposes that the RSAWG become 400 responsible for ownership of this material. 402 However, it is recognized that the REP service will likely be the 403 ones to encounter the need to make updates to material. The RSAWG 404 will need clear processes for reporting problems. As problems of 405 this nature often arise during document processing, they can require 406 expedient solutions. To that end, the process should allow for the 407 REP service to make and record decisions. This is also a major 408 reason why REP staff might choose to participate directly in the 409 RSAWG. 411 The nature of the process the RSAWG uses might change over time. Any 412 changes need to be clearly communicated and changes negotiated with 413 the REP. This negotiation is to be facilitated by the IETF LLC or 414 their delegate. 416 5. Tooling 418 Producing an RFC relies heavily on tools that help automate many 419 aspects of the process. Using tools contributes to consistency and 420 better performance of the REP function. 422 In one version of this model, the tools that are used by the REP 423 function are the responsibility of the function. However, the larger 424 system benefits from a degree of consistency between the tools used 425 by each stream to produce documents and the tools used in the editing 426 and publication stage. In practice, these tools are shared and a 427 great deal of benefit is derived from that arrangement. 429 A number of different organizational arrangements could be conceived 430 of for arranging this situation. For instance, the REP could be 431 tasked with producing and maintaining tools that it is required to 432 also make available to the community of people that produce 433 documents. The current arrangement is that the REP develops some of 434 its own tools, but it also depends on tools that are maintained by 435 the IETF LLC. 437 Reflecting that arrangement, we have the final composition of 438 functions as shown in Figure 4. 440 +------+ 441 | ISOC | 442 +--+---+ 443 | 444 | Oversight 445 v 446 +-----+------+ 447 +-------------+ Participate | RFC Series | 448 | Community +------------->+ Advisory |<------- RFC Series Advisor 449 +-----+-------+ | WG | (RSA) 450 ^ +-----+------+ 451 | | 452 | Provide Tools | Strategy 453 | v 454 +-----+-------+ +--+---+ 455 | Tools | Contract(s) | IETF | 456 | Maintenance +<----------------+ LLC | 457 +-----+-------+ +--+---+ 458 | | 459 +--Provide-Tools-------+ | Contract & 460 | | Oversight 461 v v 462 +-------------+ +---+-----+---+ 463 | IETF Stream +------->+ +-----> 464 +-------------+ D | | 465 +-------------+ o | | 466 | IRTF Stream +---c--->+ RFC +-----> R 467 +-------------+ u | Editing | F 468 +-------------+ m | and | C 469 | IAB Stream +---e--->+ Publication +-----> s 470 +-------------+ n | | 471 +-------------+ t | | 472 | Independent +---s--->+ +-----> 473 +-------------+ +-------------+ 475 Figure 4: Final Model 477 This arrangement means that any dependencies the REP might have for 478 tools need to be coordinated via the entity responsible for managing 479 the maintenance of tooling. The IETF LLC is ultimately responsible 480 for ensuring that the tools maintenance function has processes for 481 managing the requirements of the REP. As with the REP oversight 482 functions, this might also be delegated at the discretion of the IETF 483 LLC. 485 If meeting new requirements set by the IETF LLC require new or 486 modified tooling, it is the responsibility of the REP to formulate 487 requests regarding to tools to the Tools Maintenance function. 489 Any problems arising from this arrangement will be raised with the 490 IETF LLC as they pertain to meeting operational goals. 492 6. Management of Individual Functions 494 This model does not specify strong requirements on the management of 495 any of the functions it describes. It is expected that each function 496 identified here will be managed in a manner appropriate to the 497 function that it serves. 499 Any choice by the IETF LLC to delegate oversight responsibility to a 500 committee implies that the committee has adequate decision-making 501 processes. The IETF LLC is ultimately responsible and its processes 502 for consultation with and accountability to the broader community 503 will apply to delegated reponsibility. 505 The choice of leadership for the RSAWG is important with a move to a 506 system that lacks a single figurehead. Two measures are suggested to 507 mitigate the temptation for this leadership to become an effective 508 replacement for the RSE position: 510 o The ISOC should appoint at least two co-chairs. This is generally 511 good practice for working groups as it provides redundancy in case 512 of absence or conflict of interest. 514 o The ISOC should seek new chairs at regular intervals and seek to 515 limit the period over which any one individual might hold a 516 leadership position. 518 These are suggestions to the ISOC only, not hard requirements. 520 If the function of the REP is contracted to a single entity, it would 521 be the responsibility of that entity to provide appropriate 522 management. That management would be expected to manage the workload 523 involved in providing core REP functions like editing and 524 publication, arranging and planning for changes in response to 525 upcoming requirements, and reporting on status and performance. 527 For the tools maintenance function, contracting of tools development 528 and maintenance currently involves multiple entities. Therefore, it 529 might be necessary for the IETF LLC to contract for a role to manage 530 coordination of tools development or maintenance. Arranging for 531 appropriate management, along with systems for establishing 532 accountability to the community, enabling community contributions, 533 and dealing with dispute or contention is left to the IETF LLC. 535 7. Other Involved Entities 537 Many documents involve actions for IANA that are processed in 538 parallel with the REP processing. These processes need to be 539 documented, as for example in [RFC6359]. 541 This draft describes a model whereby the existing RFC Series Advisory 542 Group (which serves at the pleasure of the RSE) has no future as it 543 serves a role that does not exist in this model. This group embodies 544 a great deal of collected wisdom regarding the RFC Series. It is 545 this author's earnest hope that these individuals will continue to 546 lend their efforts in the form of contributions to the development of 547 strategy. 549 This draft proposes that the RFC Series Oversight Committee (RSOC) be 550 disbanded. Many of the functions provided by the RSOC are now an 551 IETF LLC responsibility in this model. If the IETF LLC decides to 552 form a committee, the experience of RSOC procedures and former 553 personnel might be used as a resource. 555 8. Role of the RFC Series Advisor 557 This person will be a senior professional with deep knowledge of 558 technical publishing. 560 The RSA will operate by providing expert advice to the RSAWG, and if 561 requested to the REP, on any relevant matters. For example, the RSA 562 might be consulted about proposed changes to the style guide, RFC 563 formatting in general, web presence, copyright matters, or archiving 564 policy. 566 The RSA is expected to attend and facilitate all RSAWG meetings, and 567 to participate in and facilitate RSAWG on-line discussions. 569 Further, the RSA is expected to ensure that RSAWG consensus is well 570 documented and communicated to the community, the LLC, and the REP. 571 This may include document authorship. 573 The RSA is expected to be a thought leader for improvements to the 574 RFC Series, for developing vision and policy documents, and for 575 establishing community consensus for them. 577 The RSA will operate under a part-time professional services contract 578 with the LLC, with performance review by the LLC in consultation with 579 the RSAWG chairs. 581 9. Changes from Version 2 of the RFC Model 583 This document describes a structure that appears quite different from 584 current practice. This section addresses significant differences and 585 similarities with the existing system. 587 9.1. No RFC Series Editor 589 This proposal does not describe a role for a RFC Series Editor. 591 The functions previously served by this individual are devolved into 592 several pieces. The REP function is expanded to cover both RFC 593 Production Center (RPC) and RFC Publisher as well as the operational 594 management responsibilities formerly adopted by the RFC Series 595 Editor. 597 The responsibility for managing the evolution of the series is 598 delegated to a consensus-based group rather than being vested in an 599 individual. Previous RFC Series Editors achieved much of the 600 strategic and evolutionary functions of their role by building 601 community consensus, so this aspect of the role is essentially 602 transferred to the chairs of the RSAWG. Expert input to the RSAWG 603 will be provided by the RSA. 605 Any responsibility for execution of RFC Series strategy that might 606 have been the responsibility of a RFC Series Editor has been 607 distributed: the IETF LLC is responsible for turning strategy into 608 requests; the REP is responsible for executing these requests. As 609 the RPC (or publisher) was previously ultimately responsible for 610 execution of any strategy, the functional difference is minimal. 612 Moving away from a model where a single individual is charged with 613 setting direction for the RFC Series is significant. This proposal 614 vests that control in a consensus-based body instead, which means 615 that decisive action is likely no longer a feature of this system. 616 As the emphasis of the group is on longer-term strategy, this is not 617 anticipated to be a practical problem. This further assumes that the 618 required rate of change matches that of the recent past in that 619 changes to the operation of the series will be not be extensive or 620 rapid. 622 9.2. No IAB Responsibility 624 The Internet Architecture Board loses its responsibility for 625 oversight of the RFC Series. The managerial and administrative 626 aspects are taken over by the LLC, and the strategic aspects by a 627 community process based on the RSAWG. 629 This is consistent with the disbanding of the RSOC. 631 9.3. Preserved Aspects of Current Practice 633 This document does not disrupt critical functions involved in RFC 634 editing and publication. There is general agreement that the 635 continued publication of RFCs remains an important goal. Disruptive 636 changes to this part of the system would be counterproductive. 638 This proposal combines the RFC Production Center and RFC Publisher 639 functions. These have been conjoined in practice for many years 640 already and so this merely formalizes a standing arrangement. 642 9.4. Motivating Principles 644 The proposed structure is motivated by the following principles. 646 o Community ownership. The community at large owns the outcomes of 647 this process and so it needs to own the process too. 649 o Open participation. The principle of open participation in 650 standardization has been critical to success in the IETF. That 651 provides a template for participation and governance of this 652 process in a wider context. 654 o Transparency. Transparency is the most important part of ensuring 655 that actors are accountable. Avoiding decisions made in closed 656 forums - or by individuals - ensures that the community is best 657 able to understand and contribute to the operation of the system. 659 o Divestiture of responsibility. The title of RFC Series Editor has 660 in the past been held by individuals with a remarkably broad set 661 of skills. Rather than dictate that an individual with such 662 diverse traits be found and selected, this design distributes that 663 responsibility. This allows for more flexibility and 664 specialization. Publishing expertise is not set aside, but will 665 be provided instead by the RFC Series Advisor. 667 o Reducing the IAB's non-technical responsibilities to allow it to 668 focus even more on the technical architecture of the Internet. 670 10. Documentation Requirements 672 At least the following documents need to be updated. 674 o The IAB Charter [RFC2850]. The IAB's responsibility for the RFC 675 Editor and RFC Series is removed. 677 o The RFC Editor Model (Version 2) [RFC8728]. Numerous changes are 678 needed as a direct consequence of the model described above. More 679 fundamentally, the model (or the following document) needs to set 680 out basic principles of the RFC Series, such as: 682 * The RFC Series is the archival series that documents Internet 683 technical specifications, descriptions, and commentaries, 684 including general contributions from the Internet research and 685 engineering community, as well as standards documents. It also 686 includes some organisational documents from the same community. 688 + "Archival" means that the documents must be available for 689 the indefinite future in a form that is trusted by all 690 parties. In particular there must be no doubt as to the 691 precise original text and diagrams, regardless of the format 692 in which the documents are stored or displayed. Errors or 693 omissions detected after publication, and subsequent 694 modifications or extensions of the document content, do not 695 change the archived document itself. 697 * All RFCs are available free of charge to anyone via the 698 Internet. They may be freely translated in their entirety into 699 any language. 701 * Request for Comments means Request for Comments. There is an 702 inherent modesty in calling our documents "requests for 703 comments". We get things wrong, we want comments, we want 704 errata, we want operational feedback, and we want to go round 705 that loop again. This property is a useful counter-balance to 706 any occurrence of groupthink in the community. 708 * RFCs come from various streams, i.e. originating organisations. 710 + Each stream has its own policy on change control, copyright, 711 and patents, with the IETF Trust generally acting as a 712 repository for intellectual property rights that are not 713 retained by the authors. 715 + Each stream has full control of the technical content of its 716 documents.The RFC Editor team has control of editorial 717 matters, subject to review by the relevant stream and the 718 document authors. In particular, a badly written document 719 may be returned to its stream for improvements if an 720 abnormal amount of copy-editing is required.If an individual 721 member of the RFC Editor team has personal comments on the 722 technical content of a draft RFC, they must be handled in 723 person, using the appropriate mechanism of the stream 724 concerned, not as an RFC Editor matter. 726 + If the RFC Editor team believes that a draft RFC contains a 727 serious technical flaw, which the stream declines to change, 728 the RFC Editor cannot block the document indefinitely. Note 729 that there is more discussion of such disagreements in 730 Section 4.3 of [RFC8728]. 732 + New streams may in principle be created, subject to 733 community agreement and guidelines to be defined. 735 + Defunct streams may be closed, subject to community 736 agreement. 738 * The RFC Series is community property and must operate on behalf 739 of the community as a whole. By making the RSAWG an open 740 group, the whole community is welcome to participate in its 741 strategy formation. 743 o The RFC Series and RFC Editor [RFC8729]. This document also needs 744 a major update. Possibly it should be rolled into the previous 745 one. In any case, it needs to be refactored to account for the 746 abolition of the Editor as a notional person rather than as a 747 function (the REP) and the addition of the RSAWG and the RSA. 749 The new model depends on the production of a document (or set of 750 documents) that outlines the initial set of requirements for the 751 operation of the REP. Much of this already exists in the form of 752 existing service agreements and the expectation is that these 753 documents can be adapted. These documents will become the 754 resposibility of the IETF LLC. 756 Over time, some of the material from service agreements and contract 757 are expected to move to strategic documents maintained by the RSAWG. 759 10.1. New RFC Stream 761 There should be a fifth RFC stream, namely the RFC Editorial Stream, 762 in which relevant documents (such as the two just mentioned, future 763 updates of the Style Guide, and documents defining the RFC format) 764 would be published. This will avoid the current anomaly of such 765 documents being published by the IAB. A corresponding update of 766 [RFC7841] will be needed. 768 11. Errors and Omissions 770 This is a draft. At this stage, it is intended to just show the 771 general outline of the model. As details are filled in, everything 772 here is liable to change. There are likely many errors, omissions, 773 and inconsistencies. 775 12. Security Considerations 777 Much of the success of systems like this can be attributed to the 778 dilligent work of individuals who strive to resolve issues 779 collaboratively. Generally speaking, it is good to assume that this 780 will continue. However, this document does attempt to establish 781 where authority lies for any particular decision in case of lapses or 782 disagreements. 784 This document aims to provide some measure of security against 785 failure of any single person to execute their function in good faith. 786 That doesn't mean that a malicious actor operating in any of the 787 critical roles could not choose to be extremely disruptive. In 788 addition to some expectation of reasonableness, this system defines 789 entities (often bodies) to whom each actor is answerable or who are 790 empowered to resolve disputes. 792 13. IANA Considerations 794 This document makes no request of IANA. 796 14. Acknowledgments 798 Large portions of this draft have been copied, with permission, from 799 [I-D.thomson-rfced-model]. 801 The name of the proposed new RFC stream was coined by Mike St Johns. 803 This is not new thinking. You might, if you were so inclined, find 804 all of these concepts in emails or documents from other people. 806 15. References 808 15.1. Normative References 810 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 811 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 812 September 1998, . 814 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 815 "Charter of the Internet Architecture Board (IAB)", 816 BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 817 . 819 15.2. Informative References 821 [I-D.thomson-rfced-model] 822 Thomson, M., "A Proposed Model for RFC Editing and 823 Publication", draft-thomson-rfced-model-01 (work in 824 progress), August 2020. 826 [RFC6359] Ginoza, S., Cotton, M., and A. Morris, "Datatracker 827 Extensions to Include IANA and RFC Editor Processing 828 Information", RFC 6359, DOI 10.17487/RFC6359, September 829 2011, . 831 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 832 DOI 10.17487/RFC7322, September 2014, 833 . 835 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 836 "RFC Streams, Headers, and Boilerplates", RFC 7841, 837 DOI 10.17487/RFC7841, May 2016, 838 . 840 [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of 841 the IETF Administrative Support Activity, Version 2.0", 842 BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, 843 . 845 [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., 846 "RFC Editor Model (Version 2)", RFC 8728, 847 DOI 10.17487/RFC8728, February 2020, 848 . 850 [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and 851 RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 852 2020, . 854 Author's Address 856 Brian E. Carpenter 857 The University of Auckland 858 School of Computer Science 859 PB 92019 860 Auckland 1142 861 New Zealand 863 Email: brian.e.carpenter@gmail.com