idnits 2.17.1 draft-saintandre-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 document seems to lack a Security Considerations section. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 05, 2021) is 1109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 500 -- Obsolete informational reference (is this intentional?): RFC 5620 (Obsoleted by RFC 6548, RFC 6635) -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) -- Obsolete informational reference (is this intentional?): RFC 8728 (Obsoleted by RFC 9280) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre, Ed. 3 Internet-Draft Mozilla 4 Obsoletes: RFC8728 (if approved) April 05, 2021 5 Intended status: Informational 6 Expires: October 7, 2021 8 RFC Editor Model (Version 3) 9 draft-saintandre-rfced-model-00 11 Abstract 13 This document describes Version 3 of the RFC Editor model. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on October 7, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 51 3. Overview of the Model . . . . . . . . . . . . . . . . . . . . 3 52 4. Ongoing Operation . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Policy Definition . . . . . . . . . . . . . . . . . . . . . . 4 54 5.1. Structure and Roles . . . . . . . . . . . . . . . . . . . 4 55 5.1.1. RFC Series Working Group (RSWG) . . . . . . . . . . . 4 56 5.1.2. RFC Series Approval Board (RSAB) . . . . . . . . . . 5 57 5.2. Process . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.2.1. Intent . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2.3. Appeals of RSAB Decisions . . . . . . . . . . . . . . 8 61 6. RFC Series Editor/Advisor (RSEA) . . . . . . . . . . . . . . 8 62 6.1. RSEA Selection . . . . . . . . . . . . . . . . . . . . . 8 63 6.2. RSEA Ongoing Performance Evaluation . . . . . . . . . . . 9 64 7. Changes from Version 2 of the RFC Editor Model . . . . . . . 9 65 7.1. RFC Series Editor . . . . . . . . . . . . . . . . . . . . 9 66 7.2. RFC Series Oversight Committee (RSOC) . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 NOTE NOTE NOTE This document is a work in progress. Although it is 78 intended to describe consensus forged in the RFCED-Future Program, 79 many aspects are not yet settled; as a result, this document contains 80 proposals and conjectures that do not yet have consensus. 82 Documents in the Request for Comments (RFC) series have been 83 continually published since 1969 [RFC8700]. The processes and 84 organizational models for publication of these documents have changed 85 significantly over the years. Most recently, in 2009 [RFC5620] 86 defined the RFC Editor Model (Version 1) and in 2012 [RFC6635] 87 defined the RFC Editor Model (Version 2), since modified slightly in 88 2020 by [RFC8728]. 90 In order to provide a sustainable basis for continued publication of 91 the RFC series, this document describes Version 3 of the RFC Editor 92 model, which divides the responsibilities for the RFC series among 93 four primary functions: the IETF Administration LLC (IETF LLC), the 94 RFC Series Working Group (RSWG), the RFC Series Approval Board 95 (RSAB), and the RFC Publication Center (RPC). 97 2. Conventions and Definitions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 3. Overview of the Model 107 Version 2 of the RFC Editor Model [RFC8728] specified a structure 108 consisting of the RFC Series Editor, the RFC Production Center, and 109 the RFC Publisher, with oversight provided by the RFC Series 110 Oversight Committee (RSOC) on behalf of the Internet Architecture 111 Board (IAB). 113 Discussion within the RFCED-Future Program has led in the direction 114 of a more consensus-oriented structure (similar in some respects to 115 the structure of technical work within the IETF) that retains roles 116 for specialized expertise in document editing and publication. 118 Specifically, this document defines a structure in which ultimate 119 authority lies with the IETF LLC, which is the corporate home for the 120 Internet Engineering Task Force (IETF), the Internet Architecture 121 Board (IAB), and the Internet Research Task Force (IRTF). 123 The IETF LLC shall exercise oversight regarding ongoing operation of 124 the final editorial and publication processes that lead to 125 publication of documents in the RFC series. As in Version 2, these 126 processes are the responsibility of the RFC Production Center (RPC) 127 function. 129 The IETF LLC shall also provide a structure for defining policies 130 regarding the RFC series. This document specifies such a structure 131 through a new RFC Series Working Group (RSWG), which shall submit its 132 policy proposals to a new RFC Series Approval Board (RSAB). 134 4. Ongoing Operation 136 Continuing publication of RFCs shall be handled by the RFC Production 137 Center (RPC) function in accordance with current policies in force or 138 future policies defined as specified in the next section of this 139 document. 141 This document does not specify the exact relationship between the 142 IETF LLC and the RPC function; for example, the RPC function could be 143 provided by a separate corporate entity under contract to the IETF 144 LLC, it could be performed by employees of the IETF LLC, or the IETF 145 LLC could work with independent contractors for some or all aspects 146 of the RPC function. The exact relationship is a matter for the IETF 147 LLC and its Executive Director to determine. 149 The IETF LLC has authority over negotiating performance targets for 150 the RPC and also has responsibility for ensuring that those targets 151 are adhered to. The IETF LLC is empowered to appoint a manager or to 152 convene a committee that is responsible for this oversight function. 154 Community members who have concerns about the performance of the RPC 155 can request that the IETF LLC look into the matter. If the IETF LLC 156 opts to delegate the oversight function, concerns can be raised with 157 the IETF LLC. The IETF LLC is ultimately responsible to the 158 community via the mechanisms outlined in its charter. 160 5. Policy Definition 162 Policies governing the RFC series as a whole shall be defined in the 163 open through proposals that are generated by and discussed within the 164 RFC Series Working Group (RSWG) and then approved by the RFC Series 165 Approval Board (RSAB). 167 Policies under the purview of the RSWG and RSAB might include but are 168 not necessarily limited to document formats, tooling, processes for 169 publication and dissemination of RFCs, and overall management of the 170 RFC series. 172 5.1. Structure and Roles 174 5.1.1. RFC Series Working Group (RSWG) 176 The RFC Series Working Group (RSWG) shall formulate proposals 177 regarding policies governing the RFC series. The intent is that the 178 RSWG operate in a way similar to working groups in the IETF and 179 research groups in the IRTF. Therefore, all RSWG meetings shall be 180 open to any participant, subject to intellectual property policies 181 which must be consistent with those of the IETF [RFC8179]. At the 182 initial formation of the RSWG, all discussions shall take place on an 183 open mailing list, and anyone is welcome to participate in 184 discussions on that list. The RSWG may decide by rough consensus to 185 use additional forms of communication (e.g., GitHub as specified in 186 [RFC8874]) that are consistent with [RFC2418]. The RSWG shall 187 conform itself to an anti-harassment policy consistent with [RFC7154] 188 and [RFC7776]. 190 The IETF Chair and the Independent Submissions Editor shall each 191 appoint and oversee a co-chair of the RSWG. 193 All interested parties are welcome to participate in the RSWG. This 194 includes participants in the IETF and IRTF, IAB and IESG members, RFC 195 authors, individuals who use RFCs in procurement decisions, and the 196 like. The IETF LLC Board members, staff, and the Executive Director 197 are invited to participate as community members in the RSWG to the 198 extent permitted by any relevant IETF LLC policies. Members of the 199 RSAB are also expected to participate actively in the RSWG so that 200 they are fully aware of proposals early in the policy definition 201 process. 203 5.1.2. RFC Series Approval Board (RSAB) 205 The RFC Series Approval Board (RSAB) shall act as the approving body 206 for proposals generated within the RSWG. The sole function of RSAB 207 is to review policy proposals generated by the RSWG; it shall have no 208 independent authority to formulate policy on its own. 210 The voting members of the RSAB shall be as follows: 212 o The IETF Chair, representing the IETF stream 214 o The IAB Chair, representing the IAB stream 216 o The IRTF Chair, representing the IRTF stream 218 o The Independent Submissions Editor [RFC8730] 220 o The RFC Series Editor/Advisor 222 OPEN ISSUE: Discussion continues within the RFCED-Future Program 223 regarding the number of members on the RSAB (e.g., whether each 224 stream shall have one representative, whether streams that generate 225 more RFCs such as the IETF stream shall have more member, etc.) as 226 well as the individuals who are voting members (e.g., IETF Chair or 227 someone appointed by the IETF Chair, the RFC Series Editor/Advisor, 228 etc.). 230 The RSAB shall choose a chair from among its members using a method 231 to be determined by the RSAB. The RSAB is expected to operate via 232 email and through any necessary tooling. THE RSAB shall keep a 233 public record of its proceedings, including minutes of all meetings 234 and a record of all decisions. 236 5.2. Process 238 5.2.1. Intent 240 The intent is to provide an open forum by which policies related to 241 the RFC series are defined and evolved. The general expectation is 242 that all interested parties will participate in the RSWG, and that 243 only under extreme circumstances should RSAB members need to hold 244 "CONCERN" positions as described below. 246 Because policy issues can be difficult and contentious, RSWG 247 participants and RSAB members are strongly encouraged to work 248 together in a spirit of good faith and mutual understanding to 249 achieve rough consensus (see [RFC7282]). In particular, RSWG members 250 are encouraged to take RSAB concerns seriously, and RSAB members are 251 encouraged to clearly express their concerns early in the process and 252 to be responsive to the community. All parties are encouraged to 253 respect the value of each stream and the long term health and 254 viability of the RFC series. 256 This process is intended to be one of continuous consultation. RSAB 257 members should consult with their constituent stakeholders (e.g., 258 authors, editors, tool developers, and consumers of RFCs) on an 259 ongoing basis, so that when the time comes to consider a proposal, 260 there should be no surprises. Appointing bodies are expected to 261 establish whatever processes they deem appropriate to facilitate this 262 goal. 264 5.2.2. Specifics 266 The following process shall be used to formulate or modify processes 267 related to the RFC series: 269 1. A individual participant in the RSWG generates a proposal in the 270 form of an Internet-Draft. 272 2. If there is sufficient interest in the proposal, RSWG may adopt 273 the proposal as a draft proposal of the RSWG, much the same way a 274 working group of the IETF or IRTF would. 276 3. The RSWG shall then further develop the proposal. Members of the 277 RSAB are expected to participate in discussion relating to such 278 proposals. 280 4. At some point, if the RSWG chairs believe there may be rough 281 consensus for the proposal to advance, they will issue a working 282 group last call. 284 5. After a suitable period of time, the RSWG chairs will determine 285 whether rough consensus for the proposal exists. If comments 286 have been received and substantial changes have been made, it is 287 expected that additional last calls may be necessary. 289 6. Once consensus is established in the RSWG, the chairs shall issue 290 a community call for comments. Should substantial comments be 291 received, the RSWG will again consider those comments and make 292 revisions as they see fit. At this same time, the RSAB will 293 consider the proposal. OPEN ISSUE: specify what counts as a 294 "community call for consensus". 296 7. Should substantial changes be made, additional community calls 297 for comment should be issued, and again comments considered. 299 8. Once all comments have been been addressed, the RSWG chairs will 300 submit the proposal to the RSAB for its consideration. 302 9. Within a reasonable period of time, the RSAB will then poll on 303 the proposal. Positions may be as follows: * "YES": the proposal 304 should be approved * "CONCERN": the proposal raises substantial 305 concerns that must be addressed. * "RECUSE": the person holding 306 the position has a conflict of interest. 308 Anyone holding a "CONCERN" position MUST explain their concern to the 309 community in detail. The explanation may or may not be actionable. 311 A CONCERN may be made for two reasons: 313 o The proposal represents a serious problem for the group a 314 particular member represents. 316 o The member believes that the proposal would cause serious harm to 317 the overall series, including harm to the long term health and 318 viability of the series. 320 No CONCERN should ever come as a surprise to the RSWG. 322 1. If a CONCERN exists, discussion will take place within the RSWG. 323 Again, all RSAB members MUST participate. 325 2. If all CONCERN positions are addressed, then the proposal is 326 approved. Again, if substantial changes have been made, an 327 additional call for community input should be made. 329 3. If, after a suitable period of time, any CONCERN positions 330 remain, a formal vote of the RSAB is taken. If a majority of 331 RSAB members vote to approve, the proposal is approved. 333 Otherwise, it is returned to the RSWG. In the case of a tie, the 334 proposal is approved. 336 4. When a proposal is approved, a notification is sent to the 337 community, and the document enters the queue for publication as 338 an RFC. 340 OPEN ISSUE: In which stream [RFC8729] are these documents published? 341 Is a new stream (e.g., the "Editorial Stream") needed? 343 5.2.3. Appeals of RSAB Decisions 345 Appeals of RSAB decisions may only be made based on process failures, 346 and not on the substance of a proposal. These appeals SHALL be made 347 to the ISOC Board of Trustees within thirty days of the RSAB 348 decision. The ISOC Board of Trusteers MAY decide only whether a 349 process failure occurred, and what if any corrective action should 350 take place. 352 6. RFC Series Editor/Advisor (RSEA) 354 OPEN ISSUE: Discussion continues within the RFCED-Future Program 355 regarding the roles and responsibilities of an expert in technical 356 publication processes. To retain flexibility (e.g., as to whether 357 this individual plays more of an advisory role or more of a singular 358 leadership role), this document temporarily refers to the individual 359 as the "RFC Series Editor/Advisor" ("RSEA"). 361 The RFC Series Editor/Advisor (RSEA) shall be a senior professional 362 with deep knowledge of technical publishing. 364 The primary responsibilities of the RSEA are as follows: 366 o Provide expert advice regarding policy proposals within the RSWG. 368 o Serve as a voting member on the RSAB (see OPEN ISSUE above). 370 o If requested, provide expert advice to the RPC and IETF LLC. 372 Matters on which the RSEA might be consulted could include proposed 373 changes to the RFC style guide, RFC formatting in general, web 374 presence, copyright matters, and archiving policy. 376 6.1. RSEA Selection 378 The RSEA will be selected by a committee formed by the Executive 379 Director of the IETF LLC, taking into account the role definition [1] 380 and any detailed job description defined by the relevant parties 381 (e.g., the Executive Director, other RSAB members, or RSWG chairs). 382 The search committee may ask others to take part in the selection 383 process in confidence. The initial length of service shall be for 384 one year, but then further extensions will be for three to five 385 years. 387 6.2. RSEA Ongoing Performance Evaluation 389 Periodically, the Executive Director will send out to the community a 390 call for input on the performance of the RSEA. The evaluation will 391 be based on criteria specified in the role definition. Criteria 392 could include matters such as the following: 394 o Was the RSEA an active participant in RSWG/RSAB discussions and 395 meetings? 397 o Did the RSEA provide useful advice to the RSWG and RPC? 399 o Did the RSEA exercise good judgment in RSAB decision making? 401 o Was the RSEA effective in advising the community on policy 402 direction? 404 The Executive Director will review the feedback, consulting with 405 stream manager representatives, and then produce a recommendation to 406 the IETF LLC Board. The LLC will then make a decision, taking into 407 account the Executive Director's recommendation. 409 Whether the RSEA role is structured as a contractual or employee 410 relationship is a matter for the IETF LLC and its Executive Director 411 to determine. 413 7. Changes from Version 2 of the RFC Editor Model 415 7.1. RFC Series Editor 417 The RSWG and RSAB together provide a public process by which policies 418 for the RFC series can be defined. It is expected that these bodies 419 will therefore cover some of the responsibilities of the RFC Series 420 Editor under Version 2. 422 7.2. RFC Series Oversight Committee (RSOC) 424 In practice, the relationships and lines of authority and 425 responsibility between the IAB, RSOC, and RSE have proved unwieldy 426 and somewhat opaque. To overcome some of these issues, this document 427 dispenses with the RSOC. 429 8. IANA Considerations 431 This document has no actions for IANA. 433 9. References 435 9.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 443 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 444 May 2017, . 446 9.2. Informative References 448 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 449 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 450 September 1998, . 452 [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", 453 RFC 5620, DOI 10.17487/RFC5620, August 2009, 454 . 456 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 457 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 458 2012, . 460 [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, 461 RFC 7154, DOI 10.17487/RFC7154, March 2014, 462 . 464 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 465 RFC 7282, DOI 10.17487/RFC7282, June 2014, 466 . 468 [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment 469 Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 470 2016, . 472 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 473 Rights in IETF Technology", BCP 79, RFC 8179, 474 DOI 10.17487/RFC8179, May 2017, 475 . 477 [RFC8700] Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700, 478 DOI 10.17487/RFC8700, December 2019, 479 . 481 [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., 482 "RFC Editor Model (Version 2)", RFC 8728, 483 DOI 10.17487/RFC8728, February 2020, 484 . 486 [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and 487 RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 488 2020, . 490 [RFC8730] Brownlee, N., Ed. and B. Hinden, Ed., "Independent 491 Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730, 492 February 2020, . 494 [RFC8874] Thomson, M. and B. Stark, "Working Group GitHub Usage 495 Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020, 496 . 498 9.3. URIs 500 [1] https://github.com/intarchboard/program-rfced-future/blob/master/ 501 Issue12-RSE-role.md 503 Acknowledgments 505 Portions of this document were borrowed from [RFC5620], [RFC6635], 506 [RFC8728], and earlier proposals within the RFCED-Future Program by 507 Martin Thomson, Brian Carpenter, and Michael StJohns. Thanks also 508 for proposed text from Eliot Lear, Brian Rosen, and other 509 participants yet to be mentioned. (TODO: make this complete.) 511 Author's Address 513 Peter Saint-Andre (editor) 514 Mozilla 516 Email: stpeter@jabber.org