| Internet-Draft | RFC Series Management | August 2020 |
| StJohns | Expires 25 February 2021 | [Page] |
This document describes a revised model for the management, evolution and improvement of the RFC Series led by an RFC Series Editor (RSE) assisted by an RFC Series Editorial Board (RSEB). The model removes the IAB and its appointed RFC Series Oversight Committee (RSOC) from direct control of the RFC Series and the RFC Series Editor, replacing them on the publication evolution side with the RSEB, and on the financial and personnel management side with the IETF Administration Limited Liability Company or its board as appropriate (LLC).¶
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 25 February 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document is submitted in response to the request by the chairs of the RFC Series Future Development Program for proposals for the revision for the RFC Series model.¶
This document should be read primarily as a proposal for the replacement of section 3 and appropriate revisions to section 4 of [RFC8728]. Specifically, this removes from the IAB (and its delegates) primary responsibility for both the evolution and management of the RFC Series and for the oversight of the contractual or employed resources supporting the RFC Series. Those resources are the RFC Series Editor (RSE), the RFC Production Center (RPC), and, if any, other task-specific contracts related to the RFC Series. In general, any task previously assigned to the RSOC or the IAB in whatever section shall devolve on the RSEB, LLC or the RSE as appropriate. Additional word-smithing will be required to review the merged documents for consistency, and such disconnects should not be read to be intentional at this time.¶
In the 50+ years of its existence, the RFC Series been under the direct control of the IAB only in the last 10 years, and only in the last few years has the IETF community directly, through the RSE LLC contract, had a mechanism to exert contractual control over the RSE. The IAB's role was originally conceived as technical in nature, but has gradually ended up, perhaps to our detriment, deeper in administrivia and policy. Considering that in view of the IAB's recent missteps with respect to the RSE, it should not come as a surprise that the author believes that the IAB is the incorrect place to home either part of the management of the RFC Series.¶
This document proposes a model which creates an RFC Series Editorial Board (RSEB) as the proper home for the evolution and sustainment of the RFC Series. However, unlike the current model, the RSEB has no oversight or management responsibility with respect to the RSE, vesting that instead in the contract holder or employer of the RSE. In this initial iteration the contract holder/employer shall be the IETF LLC. As described here, the RSEB becomes another organization at the top level of the IETF community along with the IAB, IESG and LLC.¶
This document also creates a new stream, the Editorial Stream, under the control of the RSEB and for the publication of documents that create, direct, modify or describe functions specific to the RFC Series System.¶
Lastly, this document from time to time refers to an RFC Series Organization (RSO). That term is used only as a short-hand to refer to the RSE, the RSEB and any contracted-for resources involved in the production of RFCs and should not be taken as creating an actual organization.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
The RSEB is a policy and strategy board within the general umbrella of the IETF organization. Its primary role is to provide advice to the RSE on the evolution of the RFC Series, and to approve such documents for publication within the Editorial stream as may be necessary to accomplish that evolution.¶
The composition of the RSEB was chosen to explicitly enfranchise more members of the RFC Series community than just the IAB. It contains direct representation for all of the current RFC publication streams, and includes at-large members selected by the community through the Nomcom process to directly represent the community.¶
The RSEB is meant to be tightly focused on the RFC Series as the structure for enabling world-class publishing of Internet Standards, technical and research proposals, and the minutia of the IETF operating procedures. The RSEB may suggest to the RSE topics for their consideration, and may request that the RSE add those topics to tasks approved under the RSE's work agreement. The RSE, RSEB and LLC should occasionally meet together to review current tasking.¶
Note: As the RSEB has no contractual relationship with the RSE, the RSEB does not exercise any form of work direction over the RSE nor does it have any role in evaluating the RSE's performance. The individuals of the RSEB may provide commentary to the LLC or the CM on their perception of the RSE's performance, but those comments should not be given any more weight than comments from other community members. The RSE and RSEB are co-equal partners and collegues. If any member of the RSEB has an issue with the RSE's job performance the appropriate approach is providing their concerns to the LLC board or the RSE's CM.¶
For avoidance of doubt: The LLC has no oversight or management role with respect to the strategic development of the RFC Series. The funding of the RSE, RPC and other tasks within the RSO does not expand the LLC's current administrative remit to oversight of the RFC Series.¶
The RSEB consists of the RSE, the ISE, three stream managers who represent their streams, and three at-large members.¶
The RSE role is described in [RFC8728], and this document is in general agreement with that description. The RSE role is conceived as a funded position for a senior subject matter expert in the field of technical publication, with primary responsibility for the smooth functioning of the operation and evolution of the RFC Series. See section 2.1.6 of that RFC for a detailed list of qualifications.¶
The RSE is the Editor in Chief of the RFC Series, and responsibilities and authorities commensurate with that role. In particular, the RSE will be responsible for the authoring, improvement and upkeep of documents that describe the RFC Series processes and its look and feel (e.g. RFC Style Guide, XML vocabulary, publication process), as well as working with volunteers and contractors to ensure tools exist to support those processes. The LLC may also, with the RSE's agreement, designate the RSE as Contract Monitor for one or more RSO contracts.¶
The ISE role is described within [RFC6548] and this document does not modify the responsibilities described there, nor the process for selecting the ISE. However, the ISE gains an additional responsibility with the formation of the RSEB.¶
The ISE serves as the vice-chair of the RSEB, and, if the RSE role is vacant, serves as acting chair of the RSEB and acting Editor in Chief of the RFC Series.¶
If the ISE role is vacant, the responsibilities and authorities delegated to the ISE devolve onto the RSE. If both roles are vacant, the remainder of the RSEB shall select one of its number to act as RSE and ISE until one or the other of the roles is filled.¶
Stream managers are selected from the membership of the IESG, the IAB and the IRSG as their body's representative to the RSEB as stream managers for their respective streams. The chairs of the respective bodies should not serve as stream managers as their chair duties are unlikely to allow them sufficient time to focus on the needs of the RFC Series.¶
Stream managers must be reappointed by their bodies annually and will notify the RSE of their selections upon the conclusion of the First IETF meeting of the year. Any stream manager may be replaced by their body with 30 days notice, or upon the stream manager leaving their position on the respective body.¶
While the selection of the stream manager is completely within the purview of the owning body, the member chosen should have some background with the RFC system beyond publishing an RFC, or should have equivalent background in other publication systems.¶
Stream managers represent their body to the RSEB and, as such, are expected to coordinate with them on other than trivial actions taken by the RSEB.¶
Two At-Large members of the RSEB shall be nominated by the Nomcom and confirmed by the ISOC Board of Trustees. The initial members shall be selected to serve for 2 and 4 years respectively. Subsequent members shall serve for a nominal term of 3 years and may be reappointed for a maximum of three terms. Those terms shall end at the conclusion of the First IETF meeting of the year in which their term expires.¶
One At-Large member shall be selected by the ISOC Board of Trustees (BOT) and shall serve for a term of three years. IETF-appointed members of the ISOC board are not eligible to serve as the ISOC At-Large member of the RSEB. An RSEB member who is appointed to the ISOC board by the IETF and accepts the appointment is considered to have resigned from the RSEB. The term of this member runs from the date of appointment.¶
Consistent with the normal requirements for other Nomcom selected positions, an At-Large member of the RSEB shall not serve in any other Nomcom selected position.¶
The RSEB is responsible for writing and updating the position description used by the Nomcom to select the at-large members. This description shall also be provided to the ISOC BOT for assistance in selecting their member.¶
For the initial selection process, the position description shall be written collaboratively by the ISE and the stream managers with community input, but should generally describe someone with interests or experience in technical publication. As the scope of the RSO is intended to extend beyond the IETF's interests, the Nomcom is highly encouraged (as it has done with the LLC board) to consider for selection to the the RSEB those who are not currently participants within the IETF community, but who might bring in needed publication expertise.¶
The Nomcom is expected to explicitly seek out the input of the RSEB members with respect to any RSEB member that is being considered for appointment or reappointment. The Nomcom should also consult the record of the RSEB during its deliberations with respect to candidates for reappointment. This is in addition to the usual call for community input.¶
The general model of the RFC Production and Publication (RPC) system is as described in sections 2.2 and 2.3 of [RFC8728] and this document does not change that model except to note that the relationship of the RSE to the RPC is subject to the contractual language between the LLC and the RSE. The LLC may chose to place the RSE in a directive position over the RPC as a Contract Monitor, or it may place the RSE in an advisory role with respect to the RPC. If the RSE is designated as CM for the RPC, then there must be specific contractual language spelling out the RSE's responsibilities and authorities wit respect to the RPC. The exact relationship is subject to negotiation between the RSE, the LLC and the RPC.¶
The RSE may recommend the outsourcing of specific tasks related to the RFC Series production and development. A current example of this might be hiring an XML expert to assist with the V3 XML2RFC language.¶
The RSE will create a budget, a Request for Proposal (RFP) and a draft Statement of Work, and shall provide them to the LLC for initial approval prior to sending the task out for bid.¶
Upon receipt of the bids, the RSEB shall review the proposals and indicate their preference for one or two of the responses along with their reasoning. The LLC, as the contracting entity, will do its due diligence and, if acceptable, shall issue a contract for those tasks. The interaction of the RSEB with the contract ends with the submission of the selection material to the LLC.¶
Whether the RSE should act as contract monitor for any short-term contracted tasks is left to be resolved on a case by case basis. Notwithstanding this section, the LLC has full authority to choose CM's as appropriate to the LLC's needs.¶
The contracting entity (i.e., the LLC) may select an individual to act as a contract monitor (CM) for any given RSO resource. As the CM role is, or should be, one of a fiduciary for the contracting entity, the delegation of authority and responsibility from the contracting entity to the CM must be written, contractually binding, and acceptable (as to the role, not the individual) to the contractor. The delegation of authority and responsibility shall be a public document accessible to the community.¶
As a fiduciary, this document anticipates that any CMs will generally be either contractors or employees of the LLC and not unpaid volunteers from the community.¶
For avoidance of doubt:¶
In the event of a vacancy or pending vacancy in the RSE, the RSEB shall select and convene a search committee consisting of the ISE (as an advisor), one of the stream managers, and one of the at-large members. Those three shall select a search committee chairman from set of solicited volunteers who shall not currently be serving on any of the IETF boards (e.g., IAB, IESG, LLC, Trust, IRSG, RSEB) and who shall have specific experience and contacts in the technical publication space. In addition, if appropriate, the search committee may engage the assistance of an outgoing or previous RSE to aid in the search as a second advisor to the committee.¶
Note: A hired search firm or principal may be the best approach to finding good quality candidates.¶
The search committee is responsible for creating the RFP and Statement of Work (SOW) documentation to fill the position of RSE, and for seeking the approval for the search to proceed from the LLC board. Any proposed SOW is expected to consistent with the documents that set out the roles and responsibilities of the RSE. Upon publication of the RFP, the search committee is expected to make an active search for viable candidates and is expected to reach out to other technical publication organizations for leads on candidates.¶
If the existing RSE continues to remain a good fit for the community at the end of an existing contract, the appropriate action is to negotiate a renewal of the engagement terms rather than opening up a search. The decision as to which approach to take lies with the LLC.¶
Once the search committee has found one or more appropriate candidates, the full RSEB shall vote on acceptance, rejection and preference with respect to each of the candidates. The results of that vote along with any recommendations or comments shall be sent to the LLC for its action. The general goal is for the RSEB to approve all well qualified candidates, and to leave the LLC the flexibility to resolve the balance between contractual needs, funding and scope.¶
In the event the LLC declines to engage any of the candidates, the search committee will restart its process and attempt to find other viable candidates. In the result of a failure, the RSEB shall meet with the LLC, IAB and IESG to determine a path forward.¶
Consistent with the description in section 2.1 of [RFC8728], the RSE is a senior-level subject matter expert within the realm of technical publication. And consistent with past experience, the RSE role as currently scoped requires approximately 50% of a full time equivalent to service that function. That suggests that the appropriate engagement model for the RSE is either as an independent contractor, or as a board employee.¶
While it is ultimately the LLC's decision, the RSE should be engaged via either a personal services contract or an employment contract for a given term. Engagement as an at-will employee would not be appropriate for a senior-level resource with these strategic responsibilities and would not provide any measure of consistency and continuity over the RFC Series.¶
Within the constraints of the following items, the RSEB shall set its own form of operation:¶
Once the RSEB is chartered, the charter may only be revoked by a 2/3 vote of the IAB, IESG and LLC members voting individually and such vote may not be proposed more than once annually.¶
The Editorial Stream (ES) is created as the designated stream for publication of documents that describe, develop, amend, or explain the RFC Series, the roles, responsibilities and authorities of the RSO elements, and the general engagement model between the RSO and the IETF and broader community. The content of the ES shall be limited to just those topics. The RSEB shall approve by 2/3s majority vote most publications in that stream. The exception is that the RSE has the right of publication of documents authored by the RSE as commentary or analysis of the RFC Series and its progress. The RSE may publish those without RSEB approval, but the RSEB may require a note be added to the abstract indicating any issues agreed to by a majority of the RSEB.¶
While the RSEB bears sole authority to approve publications in that stream, the RSEB (or the RSE acting on behalf of the RSEB) is expected to solicit community input and involvement for the improvement of documents that affect long-term evolution of the series, or documents that affect how and when any stream approved document is published.¶
Thanks to Brian Carpenter, Bob Hinden, Scott Bradner and John Klensin for reading and commenting on the first draft of this document.¶
This memo includes no request to IANA.¶
There are no security considerations.¶