Internet-Draft RFC Series Model Process November 2019
Flanagan Expires 6 May 2020 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-flanagan-rseme-02
Published:
Intended Status:
Informational
Expires:
Author:
H. Flanagan
RFC Editor

RFC Series Model Process

Abstract

This draft offers a proposal to form a new IAB program called the RFC Editor Future Development Program. This proposal is based on the discussions held during three virtual meetings in September and October 2019, and requests a new program, open to all, that will drive consensus around any changes to the RFC Editor model through extensive community engagement and outreach to a broad set of stakeholder communities.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 May 2020.

Table of Contents

1. Introduction

The RFC Series has come to a crossroads where questions must be answered regarding how the Series should be managed, the role of the RFC Series Editor, and the oversight of the RFC Editor function. The RFC Editor, editor and publisher of the Series, publishes RFCs for the IETF, the IRTF, the IAB, and the Independent Submissions streams. Those RFCs are referred to by other Standards Development Organizations (SDOs) and the users of their documents, by organizations and governments in their procurement processes, by academics, by network operators, and more. Decisions on the future of the RFC Editor and the RFC Series must include input from, and reflect considerations of the needs and uses of, both the producers and the consumers of RFCs.

Three virtual meetings were organized, scheduled to be sensitive to a wide range of time zones, to discuss the process by which the communities of interest can determine consensus on the RFC Series model. These meetings were coordinated by Heather Flanagan, RFC Series Editor, and explicit invitations were sent to:

Invitations were considered for ISOC chapter heads and NANOG Board leadership, but the invitations were not delivered in time for the meetings.

2. Summaries from Virtual Meetings

2.1. First Virtual Meeting Summary

Approximately 24 people attended this meeting.

The stream managers and and a small number of community at-large members should be part of a committee that would work much like a design team [DESIGN]. A chair and a co-chair should be chosen from within that committee to run a working group. That working group is not to be part of the IETF (though much participation is expected from within the IETF community). An important characteristic of the chair (and possibly co-chair) is clearly identifying any potential Conflict of Interest that the chair(s) have before they call consensus.

A key characteristic and requirement of the working group is openness of participation and process.

While external stakeholders may not be interested in defining and developing the RFC Editor model, they should still be offered another opportunity to comment on any plans after those plans are developed (and before a full consensus call is made).

2.2. Second Virtual Meeting Summary

Approximately 12 people attended this meeting.

Despite the current tension between the community and the IAB, the IAB is the correct home, from a logical and organizational architecture perspective, to host the discussion for the RFC Editor model. The IAB should organize a program that follows the principles of open participation (e.g., the model of an IETF working group), and run a community-wide call for volunteers to both find chairs for this group and to invite participation. The program should have a clear, concrete, and objective charter that can be published as an Internet-Draft. Organizations external to the IETF should be invited to participate as well as to offer feedback on any proposed products from the group (assuming the external organizations do not actively participate in developing those final products).

Reaching consensus through this group should be expected to take a long time, but it is important that that time be taken so as to avoid a bigger mess in the future.

2.3. Third Virtual Meeting Summary

Approximately 6 people attended this meeting.

While there was no agreement on whether or not the group that drives the discussion and consensus needs to be an entirely new group outside the existing leadership structure, there was consensus that some IAB involvement was critical. One suggestion was to bring in past IAB and IETF chairs as core membership to the group, and that the group must look to the long-term structure of the RFC Editor (as opposed to looking at short-term, tactical matters).

In terms of what needs to be decided for the long-term (where 'long-term' was defined as 6-8 years), decisions that will need to be made include: business (funding), administration (hiring/firing) as well as more about publishing documents (who gets to say no to publishing something). There will be a role for many of the existing groups (e.g., IETF LLC Board, since they hold contracts). The model must be clear around when the RSE can be overridden (and when they can't be). The model cannot be designed around one individual or entity, which means the roles themselves has to be more clearly described.

3. Proposal - RFC Editor Future Development Program

Based on the discussions from the virtual meetings, this proposal suggest the immediate formation of a new IAB program. The role of the IAB is to convene this program; the work and the participation should be open and transparent, and must focus on the long-term needs of the RFC Series and the communities it serves.

An IAB program, run correctly and with community accountability, covers many of the required characteristic of this group. For example, an IAB program is designed to support a long-term perspective, and to exist beyond any given IAB cohort.[IAB-PROGRAM]

Note that while programs are not generally required to produce minutes, this group should regularly offer updates on its activities, either in the form of minutes, blog posts, or other easily found community reports, for the sake of individuals and organizational entities who cannot actively participate, and to support a historic record of discussions and decisions.

This program should be led by a chair and a co-chair, selected from the community. Past IAB or IETF chairs would likely be good choices. The chair/co-chair roles are responsible for general outreach, whereas the IAB Program Lead will act as the liaison to the IAB. In all cases, clear Conflict of Interest statement should be made by both chairs, and the IAB Program Lead must be neutral in all decisions.

Stream managers -- the IETF Chair or their delegate, the IAB Chair or their delegate, the IRTF Chair or their delegate, or the Independent Submissions Editor -- are strongly encouraged to participate in this program, as recommendations will be made that impact all document streams.

The program should be modeled closely on an IETF working group [BCP25], using a mailing list to validate consensus among the participants, and adhering to the IETF Note Well [BCP78] [BCP79]. Decisions are expected to be made using rough consensus.[RFC7282].

The program may choose to create one or more design teams to focus on specific aspects of the questions being raised; this model should definitely be supported if the community decides it to be useful.

The scope of work for this group includes:

A note about the RFC Series Oversight Committee (RSOC), also a program of the IAB: the RSOC should continue to oversee day-to-day running of the RFC Editor, and be available to assist with any immediate, tactical questions, as well as acting as the search committee for any of the roles defined by the new program. RSOC members are encouraged to participate in the new program, and equally encouraged to request subject matter expertise from participants in this program on matters of job descriptions, statements of work, and any other areas impacted by changes in the RFC Editor model as recommended by this program.

4. Timeline

5. Informative References

[DESIGN]
IETF, "On Design Teams", , <https://www.ietf.org/about/groups/iesg/statements/design-teams/>.
[IAB-PROGRAM]
IAB, "IAB Programs", , <https://www.iab.org/activities/programs/>.
[IETF-LIAISONS]
IETF, "Liaisons", , <https://www.ietf.org/about/liaisons/>.
[REFEDS]
REFEDS, "REFEDS", , <https://refeds.org>.
[BCP25]
Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, .
Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, .
Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, .
<https://www.rfc-editor.org/info/bcp25>
[BCP78]
Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, , <https://www.rfc-editor.org/info/bcp78>.
[BCP79]
Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, , <https://www.rfc-editor.org/info/bcp79>.
[RFC7282]
Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, DOI 10.17487/RFC7282, , <https://www.rfc-editor.org/info/rfc7282>.

Appendix A. Acknowledgments

With many thanks to the individuals who attended the virtual calls and who engaged constructively on the mailing lists.

Author's Address

Heather Flanagan
RFC Editor