idnits 2.17.1 draft-flanagan-rseme-03.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 November 2019) is 1611 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Flanagan 3 Internet-Draft RFC Editor 4 Intended status: Informational 20 November 2019 5 Expires: 23 May 2020 7 RFC Series Model Process 8 draft-flanagan-rseme-03 10 Abstract 12 The RFC Series has come to a crossroads where questions must be 13 answered regarding how the Series should be managed, the role of the 14 RFC Series Editor, and the oversight of the RFC Editor function. 15 This draft offers a proposal to form a new IAB program called the RFC 16 Editor Future Development Program. This proposal is based on the 17 discussions held during three virtual meetings in September and 18 October 2019, as well as the RSEME session at IETF 106, and requests 19 a new, open IAB program that will drive consensus around any changes 20 to the RFC Editor model. The program will require extensive 21 community engagement and outreach to a broad set of stakeholder 22 communities. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 23 May 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Summaries from Virtual Meetings and IETF 106 . . . . . . . . 2 59 2.1. First Virtual Meeting Summary . . . . . . . . . . . . . . 3 60 2.2. Second Virtual Meeting Summary . . . . . . . . . . . . . 3 61 2.3. Third Virtual Meeting Summary . . . . . . . . . . . . . . 4 62 2.4. RSEME session at IETF 106 . . . . . . . . . . . . . . . . 4 63 3. Proposal - RFC Editor Future Development Program . . . . . . 4 64 4. Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Informative References . . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 The RFC Series has come to a crossroads where questions must be 72 answered regarding how the Series should be managed, the role of the 73 RFC Series Editor, and the oversight of the RFC Editor function. The 74 RFC Editor, editor and publisher of the Series, publishes RFCs for 75 the IETF, the IRTF, the IAB, and the Independent Submissions streams. 76 Those RFCs are referred to by other Standards Development 77 Organizations (SDOs) and the users of their documents, by 78 organizations and governments in their procurement processes, by 79 academics, by network operators, and more. Decisions on the future 80 of the RFC Editor and the RFC Series must include input from, and 81 reflect considerations of the needs and uses of, both the producers 82 and the consumers of RFCs. 84 2. Summaries from Virtual Meetings and IETF 106 86 Three virtual meetings were organized, scheduled to be sensitive to a 87 wide range of time zones, to discuss the process by which the 88 communities of interest can determine consensus on the RFC Series 89 model. These meetings were coordinated by Heather Flanagan, RFC 90 Series Editor, and explicit invitations were sent to: 92 * IETF, IRTF, IAB, and Independent Submission authors and 93 participants via various mailing lists, including the rfc- 94 interest, ietf-announce, and wgchairs mailing lists 96 * IETF liaison contacts [IETF-LIAISONS] 97 * REFEDS [REFEDS] 99 Invitations were considered for ISOC chapter heads and NANOG Board 100 leadership, but the invitations were not delivered in time for the 101 meetings. 103 2.1. First Virtual Meeting Summary 105 Approximately 24 people attended this meeting. 107 The stream managers and and a small number of community at-large 108 members should be part of a committee that would work much like a 109 design team [DESIGN]. A chair and a co-chair should be chosen from 110 within that committee to run a working group. That working group is 111 not to be part of the IETF (though much participation is expected 112 from within the IETF community). An important characteristic of the 113 chair (and possibly co-chair) is clearly identifying any potential 114 Conflict of Interest that the chair(s) have before they call 115 consensus. 117 A key characteristic and requirement of the working group is openness 118 of participation and process. 120 While external stakeholders may not be interested in defining and 121 developing the RFC Editor model, they should still be offered another 122 opportunity to comment on any plans after those plans are developed 123 (and before a full consensus call is made). 125 2.2. Second Virtual Meeting Summary 127 Approximately 12 people attended this meeting. 129 Despite the current tension between the community and the IAB, the 130 IAB is the correct home, from a logical and organizational 131 architecture perspective, to host the discussion for the RFC Editor 132 model. The IAB should organize a program that follows the principles 133 of open participation (e.g., the model of an IETF working group), and 134 run a community-wide call for volunteers to both find chairs for this 135 group and to invite participation. The program should have a clear, 136 concrete, and objective charter that can be published as an Internet- 137 Draft. Organizations external to the IETF should be invited to 138 participate as well as to offer feedback on any proposed products 139 from the group (assuming the external organizations do not actively 140 participate in developing those final products). 142 Reaching consensus through this group should be expected to take a 143 long time, but it is important that that time be taken so as to avoid 144 a bigger mess in the future. 146 2.3. Third Virtual Meeting Summary 148 Approximately 6 people attended this meeting. 150 While there was no agreement on whether or not the group that drives 151 the discussion and consensus needs to be an entirely new group 152 outside the existing leadership structure, there was consensus that 153 some IAB involvement is critical. One suggestion was to bring in 154 past IAB and IETF chairs as core membership to the group, and that 155 the group must look to the long-term structure of the RFC Editor (as 156 opposed to looking at short-term, tactical matters). 158 In terms of what needs to be decided for the long-term (where 'long- 159 term' was defined as 6-8 years), structural issues that will need to 160 be considered: business (funding), administration (hiring/firing) as 161 well as more about publishing documents (who gets to say no to 162 publishing something). There will be a role for many of the existing 163 groups (e.g., IETF LLC Board, since they hold contracts). The model 164 must be clear around when the RSE can be overridden (and when they 165 can't be). The model cannot be designed around one individual or 166 entity, which means the roles themselves have to be more clearly 167 described. 169 2.4. RSEME session at IETF 106 171 The session held during IETF 106 [RSEME] was a review of the ideas 172 generated during the virtual meetings and a discussion on the 173 proposal laid out in the -02 version of this draft. The consensus of 174 the room was, first and foremost, to focus on doing the right thing 175 over making sure an end-to-end process was defined at the start. 176 Some decisions, such as where to ultimately publish any outputs of 177 the proposed program should be made later when there was some idea of 178 what, exactly, would be proposed as the final outcomes of the 179 program. 181 The proposal below has been revised based on the discussion. This 182 draft is ultimately intended as guidance for next steps, but will not 183 itself turn into an RFC. 185 3. Proposal - RFC Editor Future Development Program 187 The proposal, based on the calls and the session at IETF 106, is to 188 request the immediate formation of a new IAB program. The role of 189 the IAB is to convene this program and to ultimately verify that the 190 program and any outputs it generates have followed a consensus 191 process. The work and the participation should be open and 192 transparent, and must focus on the long-term needs of the RFC Series 193 and the communities it serves. 195 An IAB program, run correctly and with community accountability, 196 covers many of the required characteristic of this group. For 197 example, an IAB program is designed to support a long-term 198 perspective, and to exist beyond any given IAB cohort.[IAB-PROGRAM] 200 Note that while programs are not generally required to produce 201 minutes, this group should regularly offer updates on its activities, 202 either in the form of minutes, blog posts, or other easily found 203 community reports, for the sake of individuals and organizational 204 entities who cannot actively participate, and to support a historic 205 record of discussions and decisions. The meetings themselves should 206 always support remote participation. 208 This program should be led by a chair and a co-chair, selected from 209 the community. The chair/co-chair roles are responsible for general 210 outreach, whereas the IAB Program Lead will act as the liaison to the 211 IAB. In all cases, a clear Conflict of Interest statement should be 212 made by both chairs, and the IAB Program Lead must be neutral in all 213 decisions. 215 Individuals chosen by the IAB, IESG, and the IRSG from among their 216 memberships and with an eye towards program continuity, and the 217 Independent Submissions Editor, are strongly encouraged to 218 participate in this program, as recommendations will be made that 219 impact all document streams. 221 The program should be modeled closely on an IETF working group 222 [BCP25], using a mailing list to validate consensus among the 223 participants, and adhering to the IETF Note Well [BCP78] [BCP79]. 224 Decisions are expected to be made using rough consensus; consensus 225 will be called by the chairs, and any appeals will be handled by the 226 IAB.[RFC7282]. 228 The program may choose to create one or more design teams to focus on 229 specific aspects of the questions being raised; this model should 230 definitely be supported if the community decides it to be useful. 232 The scope of work for this group includes: 234 * Clearly defining the guiding principles that will drive any 235 further decisions and discussions. 237 * Determining the full scope of responsibilities and authority 238 within the RFC Editor, in particular focusing on the RFC Series 239 Editor. What is the actual driving problem? 241 * Considering and proposing business and administrative requirements 242 to support any proposed changes (e.g., who decides on budget). 244 * Soliciting input from organizations that are expected to be 245 directly impacted by any changes to the RFC Editor model. 247 A note about the RFC Series Oversight Committee (RSOC), also a 248 program of the IAB: the RSOC should continue to oversee day-to-day 249 running of the RFC Editor, and be available to assist with any 250 immediate, tactical questions, as well as acting as the search 251 committee for any of the roles defined by the new program. RSOC 252 members are encouraged to participate in the new program, and equally 253 encouraged to request subject matter expertise from participants in 254 this program on matters of job descriptions, statements of work, and 255 any other areas impacted by changes in the RFC Editor model as 256 recommended by this program. 258 Similarly, members of the IAB and the IESG are welcome to participate 259 as individuals, but should not be in any leadership role within the 260 program (the IAB liaison role should not be considered a leadership 261 role; liaisons are important to communication and transparency). The 262 IAB will ultimately act as the point of appeal (if necessary). 264 4. Timeline 266 * IETF 106: community discussion, complete proposal 268 * November 2019: IAB to announce new program, open a community-wide 269 call for volunteers for the chair and co-chair roles 271 * December 2019: IAB to create a new mailing list, select chairs, 272 and solicit membership. 274 * No later than IETF 107: Program to have its initial meeting 275 (interim meetings are also encouraged) 277 * No later than IETF 108: First draft(s) of defining principles; 278 iterate on improvements 280 * No later than IETF 109: First draft(s) of recommendations 281 regarding any changes in the RFC Editor model 283 5. Informative References 285 [DESIGN] IETF, "On Design Teams", 286 . 289 [IAB-PROGRAM] 290 IAB, "IAB Programs", 291 . 293 [IETF-LIAISONS] 294 IETF, "Liaisons", . 296 [REFEDS] REFEDS, "REFEDS", . 298 [RSEME] IAB, "Community Process for RSE Model Evolution (rseme)", 299 . 301 [BCP25] Bradner, S., "IETF Working Group Guidelines and 302 Procedures", BCP 25, RFC 2418, September 1998. 304 Wasserman, M., "Updates to RFC 2418 Regarding the 305 Management of IETF Mailing Lists", BCP 25, RFC 3934, 306 October 2004. 308 Resnick, P. and A. Farrel, "IETF Anti-Harassment 309 Procedures", BCP 25, RFC 7776, March 2016. 311 313 [BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights 314 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 315 DOI 10.17487/RFC5378, November 2008, 316 . 318 [BCP79] Bradner, S. and J. Contreras, "Intellectual Property 319 Rights in IETF Technology", BCP 79, RFC 8179, 320 DOI 10.17487/RFC8179, May 2017, 321 . 323 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 324 RFC 7282, DOI 10.17487/RFC7282, June 2014, 325 . 327 Appendix A. Acknowledgments 329 With many thanks to the individuals who attended the virtual calls 330 and who engaged constructively on the mailing lists. 332 Author's Address 334 Heather Flanagan 335 RFC Editor 337 Email: rse@rfc-editor.org 338 URI: https://orcid.org/0000-0002-2647-2220