Internet-Draft RFC Series Model Process November 2019
Flanagan Expires 23 May 2020 [Page]
Network Working Group
Intended Status:
H. Flanagan
RFC Editor

RFC Series Model Process


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. 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, as well as the RSEME session at IETF 106, and requests a new, open IAB program that will drive consensus around any changes to the RFC Editor model. The program will require extensive community engagement and outreach to a broad set of stakeholder communities. This draft is not intended to become an RFC.

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

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 23 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.

2. Summaries from Virtual Meetings and IETF 106

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.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 is 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), structural issues that will need to be considered: 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 have to be more clearly described.

2.4. RSEME session at IETF 106

The session held during IETF 106 [RSEME] was a review of the ideas generated during the virtual meetings and a discussion on the proposal laid out in the -02 version of this draft. The consensus of the room was, first and foremost, to focus on doing the right thing over making sure an end-to-end process was defined at the start. Some decisions, such as where to ultimately publish any outputs of the proposed program should be made later when there was some idea of what, exactly, would be proposed as the final outcomes of the program.

The proposal below has been revised based on the discussion. This draft is ultimately intended as guidance for next steps, but will not itself turn into an RFC.

3. Proposal - RFC Editor Future Development Program

The proposal, based on the calls and the session at IETF 106, is to request the immediate formation of a new IAB program. The role of the IAB is to convene this program and to ultimately verify that the program and any outputs it generates have followed a consensus process. 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. The meetings themselves should always support remote participation.

This program should be led by a chair and a co-chair, selected from the community. 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, a clear Conflict of Interest statement should be made by both chairs, and the IAB Program Lead must be neutral in all decisions.

Individuals chosen by the IAB, IESG, and the IRSG from among their memberships and with an eye towards program continuity, and 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; consensus will be called by the chairs, and any appeals will be handled by the IAB.[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.

Similarly, members of the IAB and the IESG are welcome to participate as individuals, but should not be in any leadership role within the program (the IAB liaison role should not be considered a leadership role; liaisons are important to communication and transparency). The IAB will ultimately act as the point of appeal (if necessary).

4. Timeline

5. Informative References

IETF, "On Design Teams", , <>.
IAB, "IAB Programs", , <>.
IETF, "Liaisons", , <>.
IAB, "Community Process for RSE Model Evolution (rseme)", , <>.
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, .
Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, , <>.
Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, , <>.
Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, DOI 10.17487/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