idnits 2.17.1 draft-stjohns-rfced-rseb-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 (24 August 2020) is 1341 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6548 (Obsoleted by RFC 8730) -- Obsolete informational reference (is this intentional?): RFC 8728 (Obsoleted by RFC 9280) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RFC Editor Futures M. StJohns 3 Internet-Draft NthPermutation Security LLC 4 Intended status: Informational 24 August 2020 5 Expires: 25 February 2021 7 An Editorial Board-based Management Structure for the RFC Series 8 draft-stjohns-rfced-rseb-00 10 Abstract 12 This document describes a revised model for the management, evolution 13 and improvement of the RFC Series led by an RFC Series Editor (RSE) 14 assisted by an RFC Series Editorial Board (RSEB). The model removes 15 the IAB and its appointed RFC Series Oversight Committee (RSOC) from 16 direct control of the RFC Series and the RFC Series Editor, replacing 17 them on the publication evolution side with the RSEB, and on the 18 financial and personnel management side with the IETF Administration 19 Limited Liability Company or its board as appropriate (LLC). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 25 February 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. The RFC Series Editorial Board . . . . . . . . . . . . . . . 4 57 2.1. Role of the RSEB . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Composition of the RSEB . . . . . . . . . . . . . . . . . 4 59 2.2.1. RFC Series Editor . . . . . . . . . . . . . . . . . . 5 60 2.2.2. Independent Series Editor . . . . . . . . . . . . . . 5 61 2.2.3. Stream Managers . . . . . . . . . . . . . . . . . . . 5 62 2.2.4. At-Large Members . . . . . . . . . . . . . . . . . . 6 63 3. RFC Series Resources . . . . . . . . . . . . . . . . . . . . 7 64 3.1. RFC Production Center . . . . . . . . . . . . . . . . . . 7 65 3.2. Other Contracts . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Contract Monitors . . . . . . . . . . . . . . . . . . . . 8 67 4. Selection of the RSE . . . . . . . . . . . . . . . . . . . . 8 68 4.1. RSE Search Committee . . . . . . . . . . . . . . . . . . 9 69 4.2. Approval by the RSEB . . . . . . . . . . . . . . . . . . 9 70 4.3. Engagement Model for the RSE . . . . . . . . . . . . . . 10 71 5. Operation of the RSEB . . . . . . . . . . . . . . . . . . . . 10 72 6. The Editorial Stream . . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 This document is submitted in response to the request by the chairs 84 of the RFC Series Future Development Program for proposals for the 85 revision for the RFC Series model. 87 This document should be read primarily as a proposal for the 88 replacement of section 3 and appropriate revisions to section 4 of 89 [RFC8728]. Specifically, this removes from the IAB (and its 90 delegates) primary responsibility for both the evolution and 91 management of the RFC Series and for the oversight of the contractual 92 or employed resources supporting the RFC Series. Those resources are 93 the RFC Series Editor (RSE), the RFC Production Center (RPC), and, if 94 any, other task-specific contracts related to the RFC Series. In 95 general, any task previously assigned to the RSOC or the IAB in 96 whatever section shall devolve on the RSEB, LLC or the RSE as 97 appropriate. Additional word-smithing will be required to review the 98 merged documents for consistency, and such disconnects should not be 99 read to be intentional at this time. 101 In the 50+ years of its existence, the RFC Series been under the 102 direct control of the IAB only in the last 10 years, and only in the 103 last few years has the IETF community directly, through the RSE LLC 104 contract, had a mechanism to exert contractual control over the RSE. 105 The IAB's role was originally conceived as technical in nature, but 106 has gradually ended up, perhaps to our detriment, deeper in 107 administrivia and policy. Considering that in view of the IAB's 108 recent missteps with respect to the RSE, it should not come as a 109 surprise that the author believes that the IAB is the incorrect place 110 to home either part of the management of the RFC Series. 112 This document proposes a model which creates an RFC Series Editorial 113 Board (RSEB) as the proper home for the evolution and sustainment of 114 the RFC Series. However, unlike the current model, the RSEB has no 115 oversight or management responsibility with respect to the RSE, 116 vesting that instead in the contract holder or employer of the RSE. 117 In this initial iteration the contract holder/employer shall be the 118 IETF LLC. As described here, the RSEB becomes another organization 119 at the top level of the IETF community along with the IAB, IESG and 120 LLC. 122 This document also creates a new stream, the Editorial Stream, under 123 the control of the RSEB and for the publication of documents that 124 create, direct, modify or describe functions specific to the RFC 125 Series System. 127 Lastly, this document from time to time refers to an RFC Series 128 Organization (RSO). That term is used only as a short-hand to refer 129 to the RSE, the RSEB and any contracted-for resources involved in the 130 production of RFCs and should not be taken as creating an actual 131 organization. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. The RFC Series Editorial Board 141 2.1. Role of the RSEB 143 The RSEB is a policy and strategy board within the general umbrella 144 of the IETF organization. Its primary role is to provide advice to 145 the RSE on the evolution of the RFC Series, and to approve such 146 documents for publication within the Editorial stream as may be 147 necessary to accomplish that evolution. 149 The composition of the RSEB was chosen to explicitly enfranchise more 150 members of the RFC Series community than just the IAB. It contains 151 direct representation for all of the current RFC publication streams, 152 and includes at-large members selected by the community through the 153 Nomcom process to directly represent the community. 155 The RSEB is meant to be tightly focused on the RFC Series as the 156 structure for enabling world-class publishing of Internet Standards, 157 technical and research proposals, and the minutia of the IETF 158 operating procedures. The RSEB may suggest to the RSE topics for 159 their consideration, and may request that the RSE add those topics to 160 tasks approved under the RSE's work agreement. The RSE, RSEB and LLC 161 should occasionally meet together to review current tasking. 163 Note: As the RSEB has no contractual relationship with the RSE, the 164 RSEB does not exercise any form of work direction over the RSE nor 165 does it have any role in evaluating the RSE's performance. The 166 individuals of the RSEB may provide commentary to the LLC or the CM 167 on their perception of the RSE's performance, but those comments 168 should not be given any more weight than comments from other 169 community members. The RSE and RSEB are co-equal partners and 170 collegues. If any member of the RSEB has an issue with the RSE's job 171 performance the appropriate approach is providing their concerns to 172 the LLC board or the RSE's CM. 174 For avoidance of doubt: The LLC has no oversight or management role 175 with respect to the strategic development of the RFC Series. The 176 funding of the RSE, RPC and other tasks within the RSO does not 177 expand the LLC's current administrative remit to oversight of the RFC 178 Series. 180 2.2. Composition of the RSEB 182 The RSEB consists of the RSE, the ISE, three stream managers who 183 represent their streams, and three at-large members. 185 2.2.1. RFC Series Editor 187 The RSE role is described in [RFC8728], and this document is in 188 general agreement with that description. The RSE role is conceived 189 as a funded position for a senior subject matter expert in the field 190 of technical publication, with primary responsibility for the smooth 191 functioning of the operation and evolution of the RFC Series. See 192 section 2.1.6 of that RFC for a detailed list of qualifications. 194 The RSE is the Editor in Chief of the RFC Series, and 195 responsibilities and authorities commensurate with that role. In 196 particular, the RSE will be responsible for the authoring, 197 improvement and upkeep of documents that describe the RFC Series 198 processes and its look and feel (e.g. RFC Style Guide, XML 199 vocabulary, publication process), as well as working with volunteers 200 and contractors to ensure tools exist to support those processes. 201 The LLC may also, with the RSE's agreement, designate the RSE as 202 Contract Monitor for one or more RSO contracts. 204 2.2.2. Independent Series Editor 206 The ISE role is described within [RFC6548] and this document does not 207 modify the responsibilities described there, nor the process for 208 selecting the ISE. However, the ISE gains an additional 209 responsibility with the formation of the RSEB. 211 The ISE serves as the vice-chair of the RSEB, and, if the RSE role is 212 vacant, serves as acting chair of the RSEB and acting Editor in Chief 213 of the RFC Series. 215 If the ISE role is vacant, the responsibilities and authorities 216 delegated to the ISE devolve onto the RSE. If both roles are vacant, 217 the remainder of the RSEB shall select one of its number to act as 218 RSE and ISE until one or the other of the roles is filled. 220 2.2.3. Stream Managers 222 Stream managers are selected from the membership of the IESG, the IAB 223 and the IRSG as their body's representative to the RSEB as stream 224 managers for their respective streams. The chairs of the respective 225 bodies should not serve as stream managers as their chair duties are 226 unlikely to allow them sufficient time to focus on the needs of the 227 RFC Series. 229 Stream managers must be reappointed by their bodies annually and will 230 notify the RSE of their selections upon the conclusion of the First 231 IETF meeting of the year. Any stream manager may be replaced by 232 their body with 30 days notice, or upon the stream manager leaving 233 their position on the respective body. 235 While the selection of the stream manager is completely within the 236 purview of the owning body, the member chosen should have some 237 background with the RFC system beyond publishing an RFC, or should 238 have equivalent background in other publication systems. 240 Stream managers represent their body to the RSEB and, as such, are 241 expected to coordinate with them on other than trivial actions taken 242 by the RSEB. 244 2.2.4. At-Large Members 246 Two At-Large members of the RSEB shall be nominated by the Nomcom and 247 confirmed by the ISOC Board of Trustees. The initial members shall 248 be selected to serve for 2 and 4 years respectively. Subsequent 249 members shall serve for a nominal term of 3 years and may be 250 reappointed for a maximum of three terms. Those terms shall end at 251 the conclusion of the First IETF meeting of the year in which their 252 term expires. 254 One At-Large member shall be selected by the ISOC Board of Trustees 255 (BOT) and shall serve for a term of three years. IETF-appointed 256 members of the ISOC board are not eligible to serve as the ISOC At- 257 Large member of the RSEB. An RSEB member who is appointed to the 258 ISOC board by the IETF and accepts the appointment is considered to 259 have resigned from the RSEB. The term of this member runs from the 260 date of appointment. 262 Consistent with the normal requirements for other Nomcom selected 263 positions, an At-Large member of the RSEB shall not serve in any 264 other Nomcom selected position. 266 The RSEB is responsible for writing and updating the position 267 description used by the Nomcom to select the at-large members. This 268 description shall also be provided to the ISOC BOT for assistance in 269 selecting their member. 271 For the initial selection process, the position description shall be 272 written collaboratively by the ISE and the stream managers with 273 community input, but should generally describe someone with interests 274 or experience in technical publication. As the scope of the RSO is 275 intended to extend beyond the IETF's interests, the Nomcom is highly 276 encouraged (as it has done with the LLC board) to consider for 277 selection to the the RSEB those who are not currently participants 278 within the IETF community, but who might bring in needed publication 279 expertise. 281 The Nomcom is expected to explicitly seek out the input of the RSEB 282 members with respect to any RSEB member that is being considered for 283 appointment or reappointment. The Nomcom should also consult the 284 record of the RSEB during its deliberations with respect to 285 candidates for reappointment. This is in addition to the usual call 286 for community input. 288 3. RFC Series Resources 290 3.1. RFC Production Center 292 The general model of the RFC Production and Publication (RPC) system 293 is as described in sections 2.2 and 2.3 of [RFC8728] and this 294 document does not change that model except to note that the 295 relationship of the RSE to the RPC is subject to the contractual 296 language between the LLC and the RSE. The LLC may chose to place the 297 RSE in a directive position over the RPC as a Contract Monitor, or it 298 may place the RSE in an advisory role with respect to the RPC. If 299 the RSE is designated as CM for the RPC, then there must be specific 300 contractual language spelling out the RSE's responsibilities and 301 authorities wit respect to the RPC. The exact relationship is 302 subject to negotiation between the RSE, the LLC and the RPC. 304 3.2. Other Contracts 306 The RSE may recommend the outsourcing of specific tasks related to 307 the RFC Series production and development. A current example of this 308 might be hiring an XML expert to assist with the V3 XML2RFC language. 310 The RSE will create a budget, a Request for Proposal (RFP) and a 311 draft Statement of Work, and shall provide them to the LLC for 312 initial approval prior to sending the task out for bid. 314 Upon receipt of the bids, the RSEB shall review the proposals and 315 indicate their preference for one or two of the responses along with 316 their reasoning. The LLC, as the contracting entity, will do its due 317 diligence and, if acceptable, shall issue a contract for those tasks. 318 The interaction of the RSEB with the contract ends with the 319 submission of the selection material to the LLC. 321 Whether the RSE should act as contract monitor for any short-term 322 contracted tasks is left to be resolved on a case by case basis. 323 Notwithstanding this section, the LLC has full authority to choose 324 CM's as appropriate to the LLC's needs. 326 3.3. Contract Monitors 328 The contracting entity (i.e., the LLC) may select an individual to 329 act as a contract monitor (CM) for any given RSO resource. As the CM 330 role is, or should be, one of a fiduciary for the contracting entity, 331 the delegation of authority and responsibility from the contracting 332 entity to the CM must be written, contractually binding, and 333 acceptable (as to the role, not the individual) to the contractor. 334 The delegation of authority and responsibility shall be a public 335 document accessible to the community. 337 As a fiduciary, this document anticipates that any CMs will generally 338 be either contractors or employees of the LLC and not unpaid 339 volunteers from the community. 341 For avoidance of doubt: 343 * The ISE SHALL NOT be a CM for the RSE. 345 * The RSE SHALL NOT be a CM for the ISE. 347 * The RSE MAY be a CM for the RPC 349 * The RSE MAY be a CM for any task contracts. 351 * No other member of the RSEB may be a CM for any RSO contract. 353 * Hiring and firing decisions or contract termination or renewal 354 decisions SHALL NOT be made by the CM. 356 * The RSE is not "just a contractor", but a senior member of the 357 community. Any delegation from the LLC to a CM SHALL be limited 358 to the minimum functions necessary. See the last paragraph of 359 Section 2.1 for a brief comment on the limits of the LLC's role. 361 4. Selection of the RSE 362 4.1. RSE Search Committee 364 In the event of a vacancy or pending vacancy in the RSE, the RSEB 365 shall select and convene a search committee consisting of the ISE (as 366 an advisor), one of the stream managers, and one of the at-large 367 members. Those three shall select a search committee chairman from 368 set of solicited volunteers who shall not currently be serving on any 369 of the IETF boards (e.g., IAB, IESG, LLC, Trust, IRSG, RSEB) and who 370 shall have specific experience and contacts in the technical 371 publication space. In addition, if appropriate, the search committee 372 may engage the assistance of an outgoing or previous RSE to aid in 373 the search as a second advisor to the committee. 375 Note: A hired search firm or principal may be the best approach to 376 finding good quality candidates. 378 The search committee is responsible for creating the RFP and 379 Statement of Work (SOW) documentation to fill the position of RSE, 380 and for seeking the approval for the search to proceed from the LLC 381 board. Any proposed SOW is expected to consistent with the documents 382 that set out the roles and responsibilities of the RSE. Upon 383 publication of the RFP, the search committee is expected to make an 384 active search for viable candidates and is expected to reach out to 385 other technical publication organizations for leads on candidates. 387 If the existing RSE continues to remain a good fit for the community 388 at the end of an existing contract, the appropriate action is to 389 negotiate a renewal of the engagement terms rather than opening up a 390 search. The decision as to which approach to take lies with the LLC. 392 4.2. Approval by the RSEB 394 Once the search committee has found one or more appropriate 395 candidates, the full RSEB shall vote on acceptance, rejection and 396 preference with respect to each of the candidates. The results of 397 that vote along with any recommendations or comments shall be sent to 398 the LLC for its action. The general goal is for the RSEB to approve 399 all well qualified candidates, and to leave the LLC the flexibility 400 to resolve the balance between contractual needs, funding and scope. 402 In the event the LLC declines to engage any of the candidates, the 403 search committee will restart its process and attempt to find other 404 viable candidates. In the result of a failure, the RSEB shall meet 405 with the LLC, IAB and IESG to determine a path forward. 407 4.3. Engagement Model for the RSE 409 Consistent with the description in section 2.1 of [RFC8728], the RSE 410 is a senior-level subject matter expert within the realm of technical 411 publication. And consistent with past experience, the RSE role as 412 currently scoped requires approximately 50% of a full time equivalent 413 to service that function. That suggests that the appropriate 414 engagement model for the RSE is either as an independent contractor, 415 or as a board employee. 417 While it is ultimately the LLC's decision, the RSE should be engaged 418 via either a personal services contract or an employment contract for 419 a given term. Engagement as an at-will employee would not be 420 appropriate for a senior-level resource with these strategic 421 responsibilities and would not provide any measure of consistency and 422 continuity over the RFC Series. 424 5. Operation of the RSEB 426 Within the constraints of the following items, the RSEB shall set its 427 own form of operation: 429 * The RSEB meets at least annually in public session during an IETF 430 meeting (if physical) or alternately, in the week prior to or 431 after a virtual meeting (if schedule time is tight during IETF 432 week). This will allow the RSEB to hear community input and 433 concerns in a formalized session, and to discuss planned work and 434 work in progress. 436 * All meetings of the RSEB SHALL be open and complete proceedings 437 shall be published, with the sole exception of proceedings 438 directly related to the search process for a RSE or the selection 439 of other sub-contractors. The intent is that the should be no 440 closed or partially closed deliberations by the RSEB excepting 441 those searches. 443 * The RSE and ISE act as chair and vice chair respectively, and the 444 RSEB shall not override that model except as provided above. 446 * The RSEB SHALL act via recorded vote with a majority vote of all 447 members being required for most actions. The voting record shall 448 be public except for votes related to searches. 450 * A quorum of the RSEB consists of a majority of the members which 451 includes at least one stream manager member, one at-large member 452 and either the chair or vice-chair. The RSEB shall document any 453 actions for which only a quorum majority is sufficient vice a 454 majority of the whole membership. 456 * The RSEB shall encourage community input for any documents 457 produced, however, similar to documents produced by the IAB, the 458 RSEB is not required to determine community consensus prior to 459 publication of their documents. Given the initial configuration 460 of the RSEB, at least one stream manager member and one At-Large 461 member will need to give their consent for any document to be 462 published. 464 * [RFC8728] sections 2.1.2 and 2.1.4 (substituting RSEB for RSOC or 465 IAB) describes the general interaction between the community and 466 the RFC series and this section does not purport to modify that 467 interaction, only clarify that the community has delegated certain 468 responsibilities to the RSE and RSEB, similar to the way the 469 community has delegated responsibilities to the IAB, IESG and LLC. 471 Once the RSEB is chartered, the charter may only be revoked by a 2/3 472 vote of the IAB, IESG and LLC members voting individually and such 473 vote may not be proposed more than once annually. 475 6. The Editorial Stream 477 The Editorial Stream (ES) is created as the designated stream for 478 publication of documents that describe, develop, amend, or explain 479 the RFC Series, the roles, responsibilities and authorities of the 480 RSO elements, and the general engagement model between the RSO and 481 the IETF and broader community. The content of the ES shall be 482 limited to just those topics. The RSEB shall approve by 2/3s 483 majority vote most publications in that stream. The exception is 484 that the RSE has the right of publication of documents authored by 485 the RSE as commentary or analysis of the RFC Series and its progress. 486 The RSE may publish those without RSEB approval, but the RSEB may 487 require a note be added to the abstract indicating any issues agreed 488 to by a majority of the RSEB. 490 While the RSEB bears sole authority to approve publications in that 491 stream, the RSEB (or the RSE acting on behalf of the RSEB) is 492 expected to solicit community input and involvement for the 493 improvement of documents that affect long-term evolution of the 494 series, or documents that affect how and when any stream approved 495 document is published. 497 7. Acknowledgments 499 Thanks to Brian Carpenter, Bob Hinden, Scott Bradner and John Klensin 500 for reading and commenting on the first draft of this document. 502 8. IANA Considerations 504 This memo includes no request to IANA. 506 9. Security Considerations 508 There are no security considerations. 510 10. References 512 10.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 10.2. Informative References 521 [RFC6548] Brownlee, N., Ed. and IAB, "Independent Submission Editor 522 Model", RFC 6548, DOI 10.17487/RFC6548, June 2012, 523 . 525 [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., 526 "RFC Editor Model (Version 2)", RFC 8728, 527 DOI 10.17487/RFC8728, February 2020, 528 . 530 Author's Address 532 Michael StJohns 533 NthPermutation Security LLC 534 Germantown, MD 20874 535 United States of America 537 Email: msj@nthpermutation.com