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