idnits 2.17.1 draft-thomson-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6635, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4844, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC4844, updated by this document, for RFC5378 checks: 2006-05-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 July 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6635 (ref. 'MODEL') (Obsoleted by RFC 8728) -- Duplicate reference: RFC6635, mentioned in 'RFC-SERIES', was also mentioned in 'MODEL'. -- Obsolete informational reference (is this intentional?): RFC 6635 (ref. 'RFC-SERIES') (Obsoleted by RFC 8728) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rfced-future M. Thomson 3 Internet-Draft Mozilla 4 Updates: 4844, 6635 (if approved) 6 July 2020 5 Intended status: Informational 6 Expires: 7 January 2021 8 A Proposed Model for RFC Editing and Publication 9 draft-thomson-rfced-model-00 11 Abstract 13 The finishing process for a document that is approved for publication 14 as an RFC currently involves a somewhat detailed and lengthy process. 15 The system that executes that process involves a number of different 16 actors, each bringing competency with different aspects of the 17 overall process. Ensuring that this process functions smoothly is 18 critical to the mission of the organizations that publish documents 19 in the RFC series. 21 This document proposes a framework for that system that aims to 22 provide clear delineations of accountability and responsibility for 23 each of the actors in this system. 25 Discussion Venues 27 This note is to be removed before publishing as an RFC. 29 Discussion of this document takes place on the RFC Editor Futures 30 program mailing list (rfced-future@iab.org), which is archived at 31 https://mailarchive.ietf.org/arch/browse/rfced-future/ 32 (https://mailarchive.ietf.org/arch/browse/rfced-future/). 34 Source for this draft and an issue tracker can be found at 35 https://github.com/martinthomson/rfced-model 36 (https://github.com/martinthomson/rfced-model). 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 7 January 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 73 3. Abstract Model . . . . . . . . . . . . . . . . . . . . . . . 3 74 4. Funding and Oversight . . . . . . . . . . . . . . . . . . . . 4 75 4.1. IETF LLC Delegation of Oversight Function . . . . . . . . 5 76 5. Evolution and Setting Policies . . . . . . . . . . . . . . . 6 77 5.1. Individual Interactions . . . . . . . . . . . . . . . . . 8 78 5.2. The Needs of Different Streams . . . . . . . . . . . . . 8 79 5.3. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 8 80 6. Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. Management of Individual Functions . . . . . . . . . . . . . 11 82 8. Other Involved Entities . . . . . . . . . . . . . . . . . . . 12 83 9. Notable Differences from Version 2 . . . . . . . . . . . . . 12 84 10. Documentation Requirements . . . . . . . . . . . . . . . . . 13 85 11. Errors and Omissions . . . . . . . . . . . . . . . . . . . . 13 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 14.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 The RFC Editor Model [MODEL] describes a system that supports the 97 process of editing and publication of RFCs. 99 The process of RFC editing and publication takes inputs in the form 100 of documents that are approved for publication by one of four streams 101 (IETF, IRTF, IAB, and Idependent Submissions). The output is an RFC. 103 Generally speaking, this system is successful if RFCs are produced at 104 a rate approximating the rate that documents are approved for 105 publication. In addition to managing throughput, the overall latency 106 should be minimized and the quality of documents should be sufficient 107 to serve the ends of the consumers of those documents. 109 In practice, the demands placed on the editing and publication 110 process mean that this function is quite involved. Furthermore, the 111 exact goals that this system serves continually evolves. The current 112 system has evolved out of a relatively simple system, into something 113 like what is described in [MODEL] with multiple discrete roles and 114 somewhat complex interactions between each. 116 This document attempts to describe an evolution of the current model, 117 drawing on experience from successes and failures from operating that 118 model, but based purely on the very high-level abstraction of that 119 system. 121 This document starts out by building from a simple (even simplistic) 122 model of the system, then builds that out incrementally. The goal is 123 to progressively expand on the relevance of the model in addressing 124 different problems that have been identified as important, or to draw 125 in each of the relevant actors in the system and to attribute 126 responsibilities (and associated authority) to each. 128 2. Conventions and Definitions 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Abstract Model 138 The highest-level abstraction is shown in Figure 1. 140 +-------------+ +-------------+ 141 | IETF Stream +------->+ +-----> 142 +-------------+ D | | 143 +-------------+ o | | 144 | IRTF Stream +---c--->+ RFC +-----> R 145 +-------------+ u | Editing | F 146 +-------------+ m | and | C 147 | IAB Stream +---e--->+ Publication +-----> s 148 +-------------+ n | | 149 +-------------+ t | | 150 | Independent +---s--->+ +-----> 151 +-------------+ +-------------+ 153 Figure 1: Simplified RFC Production Model 155 In this model, each of the four document streams produce documents 156 that are approved for publication according to the processes of those 157 streams. Each stream is an independent client of a single entity 158 that provides services in support of publishing documents as RFCs. 159 These services have numerous facets, but the core services are copy 160 editing of documents, the preparation of documents for publication, 161 and the publication of documents. 163 At a high level, each of the streams is an independent customer of 164 the function of RFC Editing and Publication (REP). Informally, the 165 entity (or entities) that perform the REP function are contracted to 166 turn approved documents into RFCs. 168 4. Funding and Oversight 170 The entity that performs the REP function holds contracts with the 171 IETF LLC, who also provides payment for those contracted services. 172 This means that the REP function is ultimately answerable to the IETF 173 LLC with respect to performance. 175 Currently, the IETF LLC delegates some of its authority to another 176 body. This allows the IETF LLC to rely on the expertise of 177 volunteers from the community in performing oversight. The IETF LLC 178 currently delegates this function to the RFC Series Oversight 179 Committee (RSOC) via the IAB. This indirection has caused some 180 problems and this document proposes that oversight be a function that 181 the IETF LLC be responsible for, either directly or through a 182 delegation process that is managed by the IETF LLC. 184 The IETF LLC therefore has authority over negotiating performance 185 targets for the REP and the responsibility of ensuring that those 186 targets are adhered to. The IETF LLC is empowered to appoint a 187 manager or to convene a committee that is responsible for this 188 oversight function. 190 Community members who have concerns about the performance of the REP 191 can request that the IETF LLC investigate the matter. If the IETF 192 LLC opts to delegate the oversight function, concerns can be raised 193 with the IETF LLC. The IETF LLC is ultimately responsible to the 194 community via the mechanisms outlined in its charter [LLC]. 196 This results in evolving the basic model as shown in Figure 2. 198 +------+ 199 | IETF | 200 | LLC | 201 +------+ 202 | 203 | Contract & 204 | Oversight 205 v 206 +-------------+ +-------------+ 207 | IETF Stream +------->+ +-----> 208 +-------------+ D | | 209 +-------------+ o | | 210 | IRTF Stream +---c--->+ RFC +-----> R 211 +-------------+ u | Editing | F 212 +-------------+ m | and | C 213 | IAB Stream +---e--->+ Publication +-----> s 214 +-------------+ n | | 215 +-------------+ t | | 216 | Independent +---s--->+ +-----> 217 +-------------+ +-------------+ 219 Figure 2: Oversight and Funding Functions 221 This shows the IETF LLC having budgetary and contractual oversight 222 over the REP. 224 4.1. IETF LLC Delegation of Oversight Function 226 The current organization tasks the RSOC with responsibility for 227 oversight. This has lead to numerous questions about the extent of 228 authority delegated to the RSOC and the responsibilities of various 229 entities that the RSOC is tasked with interacting with. 231 This document avoids these questions by placing this authority 232 directly with the IETF LLC. However, the oversight function is one 233 that the IETF LLC is expected to delegate, either to an individual or 234 committee. 236 Any delegation would ideally result in the creation of a a document 237 governing how the delegation was structured. This is not that 238 document, but this assumes that the person or persons who are given 239 oversight responsibility would be responsible for managing contract 240 and performance for the RSEP. Any appeal or dispute with the actions 241 of this individual or committee would then be taken up with the IETF 242 LLC. 244 5. Evolution and Setting Policies 246 Setting the policies that set targets for REP performance and more 247 detailed requirements for operation of their functions has 248 historically been delegated to the RSOC. This document proposes 249 separating that function. The goal is to improve the ability of the 250 community (across all streams) to set and evolve policies. 252 The requirements of each of the streams changes over time. The goal 253 is to find a system that allows the community to develop consensus 254 around the strategic direction for the evolution of the RFC Series. 256 In terms of structure of this effort, the community has a set of 257 well-understood and tested systems for developing consensus. 258 Therefore, this document proposes that strategic goals for the RFC 259 Series are developed using the working group process [WG] used in the 260 IETF. 262 Concretely, this proposes forming a RFC Series Evolution program of 263 the IAB that uses the auspices of an IAB program, one that closely 264 follows the model proposed in [RSEME]. This results in a group that 265 follows [WG] procedures, with the exception that the functions 266 performed by the IESG are instead performed by the IAB. In 267 particular, selection of chairs and appeals regarding the execution 268 of the process are directed to the IAB to resolve. 270 It is important that this group adopt code of conduct, anti- 271 harrassment, and other policies. Again, existing IETF processes - 272 collectively referred to in the Note Well - are well-suited to this 273 task. 275 Any strategic direction that is produced by this process will be 276 documented in RFCs. These will need to be framed as high-level goals 277 and priorities rather than strict requirements. It will be up to the 278 IETF LLC - or their delegate - to negotiate with the REP function 279 about the execution for any changes. In negotiating the execution of 280 strategy, the IETF LLC is expected to factor in relevant factors such 281 as cost, legal constraints, or schedule. 283 The IETF LLC is also responsible for ensuring that the plans for 284 implementation of strategic goals is published and available to the 285 community. 287 This results in the model shown in Figure 3. 289 +------+ 290 | IAB | 291 +--+---+ 292 | 293 | Oversight 294 v 295 +-----+------+ 296 | RFC Series | 297 | Evolution | 298 | Program | 299 +-----+------+ 300 | 301 | Strategy 302 v 303 +--+---+ 304 | IETF | 305 | LLC | 306 +--+---+ 307 | 308 | Contract & 309 | Oversight 310 v 311 +-------------+ +---------+---+ 312 | IETF Stream +------->+ +-----> 313 +-------------+ D | | 314 +-------------+ o | | 315 | IRTF Stream +---c--->+ RFC +-----> R 316 +-------------+ u | Editing | F 317 +-------------+ m | and | C 318 | IAB Stream +---e--->+ Publication +-----> s 319 +-------------+ n | | 320 +-------------+ t | | 321 | Independent +---s--->+ +-----> 322 +-------------+ +-------------+ 324 Figure 3: Evolution and Strategy Additions 326 5.1. Individual Interactions 328 It is important to recognize that the interface to the REP function 329 is most often through individual authors (or chairs, document 330 shepherds, and area directors) and individual REP staff. 332 In those interactions, those individuals might find problems with 333 processes or might be motivated to make suggestions for improvement. 334 The goal of the RFC Series Evolution program is to provide a single 335 venue for discussion of changes to REP requirements, processes, and 336 procedures. 338 5.2. The Needs of Different Streams 340 The singular group responsible for evolution of the RFC Series as a 341 whole is a simplification that is made to reduce contention in 342 setting strategic goals. It is important to note that the needs of 343 different streams can be different. 345 Several factors motivate a single group that sets strategy. 346 Historically, the IETF stream is responsible for a large proportion 347 of the documents in the series. That is unlikely to change and 348 experience has shown that other streams are - for the most part - 349 willing to accept that strategic direction is largely dictated by the 350 needs of the most prolific user of the REP service. 352 It is important that each stream retain control over the content of 353 documents that are published on that stream. Streams currently 354 appoint a stream manager who is allocated authority over content on 355 that stream and responsibility to manage any problems that might 356 arise in handling documents produced by that stream. This document 357 proposes that this aspect of the role continue. 359 Stream managers are also involved in discussion of changes to REP 360 processes and they contribute to the development of strategic 361 direction for the RFC series. Rather than deal with issues of REP 362 processes directly, stream managers are expected to initiate 363 discussion or make proposals to the RFC Series Evolution program. To 364 avoid conflicts of interest, it is expected that stream managers will 365 be active participants - and not chairs - in this program. 367 5.3. Style Guide 369 One question that arises when considering policy is that of the Style 370 Guide [RFC7322] and supporting material. These materials are 371 critical to the process of editing and therefore require that they be 372 owned and maintained. 374 The current process requires that the RFC Series Editor produce and 375 maintain this material. This document proposes that the RFC Series 376 Evolution program become responsible for ownership of this material. 378 However, it is recognized that the REP service will likely be the 379 ones to encounter the need to make updates to material. The RFC 380 Series Evolution program will need clear processes for reporting 381 problems. As problems of this nature often arise during document 382 processing, they can require expedient solutions. To that end, the 383 process should allow for the REP service to make and record 384 decisions. 386 The nature of the process the RFC Series Evolution program uses might 387 change over time. Any changes need to be clearly communicated and 388 changes negotiated with the REP. This negotiation is to be 389 facilitated by the IETF LLC or their delegate. 391 6. Tooling 393 Producing an RFC relies heavily on tools that help automate many 394 aspects of the process. Using tools contributes to consistency and 395 better performance of the REP function. 397 In one version of this model, the tools that are used by the REP 398 function are the responsibility of the function. However, the larger 399 system benefits from a degree of consistency between the tools used 400 by each stream to produce documents and the tools used in the editing 401 and publication stage. In practice, these tools are shared and a 402 great deal of benefit is derived from that arrangement. 404 A number of different organizational arrangements could be conceived 405 of for arranging this situation. For instance, the REP could be 406 tasked with producing and maintaining tools that it is required to 407 also make available to the community of people that produce 408 documents. The current arrangement is that the REP develops some of 409 its own tools, but it also depends on tools that are maintained by 410 the IETF LLC. 412 Reflecting that arrangement, we have the final composition of 413 functions as shown in Figure 4. 415 +------+ 416 | IAB | 417 +--+---+ 418 | 419 | Oversight 420 v 421 +-----+------+ 422 +-------------+ Participate | RFC Series | 423 | Community +------------->+ Evolution | 424 +-----+-------+ | Program | 425 ^ +-----+------+ 426 | | 427 | Provide Tools | Strategy 428 | v 429 +-----+-------+ +--+---+ 430 | Tools | Contract(s) | IETF | 431 | Maintenance +<----------------+ LLC | 432 +-----+-------+ +--+---+ 433 | | 434 +--Provide-Tools-------+ | Contract & 435 | | Oversight 436 v v 437 +-------------+ +---+-----+---+ 438 | IETF Stream +------->+ +-----> 439 +-------------+ D | | 440 +-------------+ o | | 441 | IRTF Stream +---c--->+ RFC +-----> R 442 +-------------+ u | Editing | F 443 +-------------+ m | and | C 444 | IAB Stream +---e--->+ Publication +-----> s 445 +-------------+ n | | 446 +-------------+ t | | 447 | Independent +---s--->+ +-----> 448 +-------------+ +-------------+ 450 Figure 4: Final Model 452 This arrangement means that any dependencies the REP might have for 453 tools need to be coordinated via the entity responsible for managing 454 the maintenance of tooling. The IETF LLC is ultimately responsible 455 for ensuring that the tools maintenance function has processes for 456 managing the requirements of the REP. As with the REP oversight 457 functions, this might also be delegated at the discretion of the IETF 458 LLC. 460 If meeting new requirements set by the IETF LLC require new or 461 modified tooling, it is the responsibility of the REP to formulate 462 requests regarding to tools to the Tools Maintenance function. 464 Any problems arising from this arrangement will be raised with the 465 IETF LLC as they pertain to meeting operational goals. 467 7. Management of Individual Functions 469 This model does not specify strong requirements on the management of 470 any of the functions it describes. It is expected that each function 471 identified here will be managed in a manner appropriate to the 472 function that it serves. 474 Any choice by the IETF LLC to delegate oversight responsibility to a 475 committee might require that the committee will need decision-making 476 processes. The IETF LLC is ultimately responsible for ensuring that 477 these processes are appropriate and effective. The IETF LLC 478 processes regarding consultation with and accountability to the 479 broader IETF community are deemed sufficient. 481 The choice of leadership for the RFC Series Evolution program could 482 become more important with a move to a system that lacks a single 483 figurehead. Two measures are suggested to mitigate the potential for 484 this position to become a function replacement for the RSE position: 486 * The IAB should appoint at least two co-chairs. This is already 487 good practice for working groups as it provides redundancy in case 488 of absence or conflict of interest. 490 * The IAB should seek new chairs at regular intervals and seek to 491 limit the period over which any one individual might hold a 492 leadership position in the program. 494 These are suggestions to the IAB only, not hard requirements. 496 If the function of the REP is contracted to a single entity, it would 497 be the responsibility of that entity to provide appropriate 498 management. That management would be expected to manage the workload 499 involved in providing core REP functions like editing and 500 publication, arranging and planning for changes in response to 501 upcoming requirements, and reporting on status and performance. 503 For the tools maintenance function, contracting of tools development 504 and maintenance currently involves multiple entities. Therefore, it 505 might be necessary for the IETF LLC to contract for a role to manage 506 coordination of tools maintenance. Arranging for appropriate 507 management, along with systems for establishing accountability to the 508 community, enabling community contributions, and dealing with dispute 509 or contention is left to the IETF LLC. 511 8. Other Involved Entities 513 Many documents involve actions for IANA that are processed as part of 514 the REP processing. These processes need to be captured and 515 documented. 517 This draft describes a model whereby the RFC Series Advisory Group 518 and the RFC Series Editorial Board have no future as these are 519 functions that serve the a role that does not exist in this model. 520 These august bodies embody a great deal of collected wisdom regarding 521 the RFC Series. It is this author's earnest hope that these 522 individuals will continue to lend their efforts in the form of 523 contributions to the development of strategy. 525 This draft proposes that the RFC Series Oversight Committee (RSOC) be 526 disbanded. Many of the functions provided by the RSOC are now an 527 IETF LLC responsibility in this model. If the IETF LLC decides to 528 form a committee, the experience of RSOC procedures and former 529 personnel might be used as a resource. 531 9. Notable Differences from Version 2 533 This proposal does not describe a role for a RFC Series Editor. 535 The functions previously served by this individual are devolved into 536 several pieces. The REP function is expanded to cover both RFC 537 Production Center (RPC) and RFC Publisher as well as the operational 538 management responsibilities formerly adopted by the RFC Series 539 Editor. 541 The responsibility for managing the evolution of the series is 542 delegated to a consensus-based group rather than being vested in an 543 individual. Previous RFC Series Editors achieved much of the 544 strategic and evolutionary functions of their role by building 545 community consensus, so this aspect of the role is essentially 546 transferred to the chairs of the RFC Series Evolution program. 548 Any responsibility for execution of RFC Series strategy that might 549 have been the responsibility of a RFC Series Editor has been 550 distributed: the IETF LLC is responsible for turning strategy into 551 requests; the REP is responsible for executing these requests. As 552 the RPC (or publisher) was previously ultimately responsible for 553 execution of any strategy, the functional difference is minimal. 555 Moving away from a model where a single individual is involved in 556 setting direction for the RFC Series is significant. This proposal 557 vests that control in a consensus-based body instead, which means 558 that decisive action is likely no longer a feature of this system. 559 As the emphasis of the group is on longer-term strategy, this is not 560 anticipated to be a practical problem. 562 This proposal combines the RFC Production Center and RFC Publisher 563 functions. These have been conjoined in practice for many years 564 already and so this merely formalizes a standing arrangement. 566 10. Documentation Requirements 568 This model depends on the production of a document (or set of 569 documents) that outlines the initial set of requirements for the 570 operation of the REP. Much of this already exists in the form of 571 previous service agreements [RPC-SA] and the expectation is that 572 these documents can be adapted. These documents will become the 573 resposibility of the IETF LLC. 575 Over time, some of the material from service agreements and contract 576 are expected to move to strategic documents maintained by the RFC 577 Series Evolution program. 579 The RFC Series Evolution program will be responsible for maintaining 580 this document, along with other documents that describe the RFC 581 Series, such as [MODEL], [RFC-SERIES], and [BOILERPLATE]. Continuing 582 publication of these documents on the IAB represents no change to 583 existing practice. 585 11. Errors and Omissions 587 This is a draft. At this stage, it is intended to just show the 588 general outline of the model. As details are filled in, everything 589 here is liable to change. There are likely many errors, omissions, 590 and inconsistencies. 592 There are lots of small details in [MODEL] that are still likely 593 relevant and would need to be tweaked to fit within the proposed 594 structure. 596 12. Security Considerations 598 Much of the success of systems like this can be attributed to the 599 dilligent work of individuals who strive to resolve issues 600 collaboratively. Generally speaking, it is good to assume that this 601 will continue. However, this document does attempt to establish 602 where authority lies for any particular decision in case of lapses or 603 disagreements. 605 This document aims to provide some measure of security against 606 failure of any single person to execute their function in good faith. 607 That doesn't mean that a malicious actor operating in any of the 608 critical roles could not choose to be extremely disruptive. In 609 addition to some expectation of reasonableness, this system defines 610 entities (often bodies) to whom each actor is answerable or who are 611 empowered to resolve disputes. 613 13. IANA Considerations 615 This document makes no request of IANA. 617 14. References 619 14.1. Normative References 621 [MODEL] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 622 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 623 2012, . 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 631 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 632 May 2017, . 634 [WG] Bradner, S., "IETF Working Group Guidelines and 635 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 636 September 1998, . 638 14.2. Informative References 640 [BOILERPLATE] 641 Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 642 "RFC Streams, Headers, and Boilerplates", RFC 7841, 643 DOI 10.17487/RFC7841, May 2016, 644 . 646 [LLC] Haberman, B., Hall, J., and J. Livingood, "Structure of 647 the IETF Administrative Support Activity, Version 2.0", 648 BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, 649 . 651 [RFC-SERIES] 652 Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 653 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 654 2012, . 656 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 657 DOI 10.17487/RFC7322, September 2014, 658 . 660 [RPC-SA] IAOC, ., "RFC Production Center Services Agreement", 1 661 January 2016, . 664 [RSEME] Flanagan, H., "RFC Series Model Process", Work in 665 Progress, Internet-Draft, draft-flanagan-rseme-03, 19 666 November 2019, . 669 Acknowledgments 671 This is not new thinking. You might, if you were so inclined, find 672 all of these concepts in emails or documents from other people. 674 Author's Address 676 Martin Thomson 677 Mozilla 679 Email: mt@lowentropy.net