Changes to the RFC Series and RSE
School of Computer Science University of Auckland Private Bag 92019 Auckland 1142 New Zealand nevil.brownlee@gmail.com
This document discusses the impact of changes to the RFC Series on the RFC Production Centre, the need for the RFC Series Editor to be independent of the Series Input Streams (the I* groups), and a suggested Editorial Board for the Series Editor.
Introduction Over the last few weeks the rfced-future mailing list has discussed topics such as:
  • What are the responsibilities of the RFC Series Editor?
  • How should changes to the RFC Series be handled?
  • Where does the RFC Series Editor (RSE) fit, relative to the RFC input Streams, i.e. the IAB, IESG, IRTF and Independent Submissions Editor (ISE)?
  • What does independent mean for the RSE?
  • How could the RSE be effectively supported?
This draft addresses those topics in a little more detail. The history of our "new formats" in of this draft comes from my own experiences on their Design Team. I present them here because I feel that many IETF participants have not considered just how much work is required to make changes to the RFC Series. Otherwise, opinions expressed in this draft are purely my own.
RSE Responsibilities RFC Series Editor Responsibilities are clearly set out in , "The RFC Series and RFC Editor", February 2020. These responsibilities have been discussed extensively on the rfced-future@iab.org mailing list. I believe that they do not need to be further discussed at this time.
Changes to the RFC Series Our last RSE was appointed (and contracted directly by ISOC) in 2011. Her first few years were busy:
  • About one year to get up to speed with the RFC Production Centre (RPC).
  • Two years and three BOFs to come up with , "RFC Series Format Requirements," May 2013.
  • Another three years for a large design team (at least 8 members) to produce , "RFC Format Framework", December 2016, , "The 'xml2rfc' Version 3 Vocabulary", and RFCs 7992 to 7998, which covered other details of the "new" formats.
  • Implementation of xml2rfc v3 tools by the IETF Tools Team, mostly as contracted work.
RFC 7990 recognised that it would take time to implement these changes; its' section 10.2, "Testing and Transition" said: The critical points here are:
  1. Changes must not impact productivity of the RPC.
  2. Development and testing of any changes will take significant time.
  3. Development will need regular iterations.
Support for the RSE Because changes to the RFC Series take months or years, the RSE's term needs to be for a minimum term of - say - five years. The RSE needs a Support Group, similar to an IETF WG, that the RSE can use to discuss issues arising, and to determine community support for any new change proposals. That Support Group must be independent of any of our I* groups, e.g. of the IAB, IETF, IRTF and ISE. The RSE has such a group already, that's the RFC Series Advisory Group (RSAG), its members all have extensive knowledge of publishing in general and the RFC Series in particular. However, its members have all been recruited over the years by successive RFC Editors, and they provide advice, not oversight. Right now the RFC Editor Future Development Program seems to be an effective oversight group for the RSE, however it's an IAB Program, which implies that the IAB has oversight of it. I suggest that:
  • The RFC Editor Future Development Program should be separated from the IAB, to become a free-standing 'RFC Series Editorial Board' (RSEB). The RSEB is not an oversight or management committee. It is constituted as follows:
    1. Each of the Series Input Streams appoints an ex officio representative (non-voting).
    2. The RSEB has 5 voting members, with staggered 3-year terms.
    3. The voting members are selected by a NomCom, preferably an ISOC NomCom, and approved by the IAB. (The term "voting" is used here only as a way to minimise demands from any of the Streams - we don't believe in voting!)
    4. The RSAB is responsible for approving the RSE's general policy; RPC contracts and performance are handled by the IETF Administration LLC.
  • When suggestions for changes to the RFC Series arise, the RSE and RSEB will discuss them so as to achieve rough consensus within the RSEB. Any such consensus will be further discussed on the rfc-interest list, so as to reach a wider consensus within the IETF participants, as well as the IRTF and the RFC-using community, as far as practicable.
  • If consensus-agreed changes require new tools:
    1. If suitable (open-source) tools exist, we should use them.
    2. Otherwise, a (part-time) Project Manager should be employed to oversee their implementation.
Independence of the RSE , section 3.2 "The RFC Series Editor," describes the RSE as "an independent professional editor, serving a much wider community than just the IETF." Independence, in this context, has been extensively discussed on the rfced-future mailing list. To summarise:
  • The RSE cannot refuse to publish a submission from any of the four Input Streams for technical reasons. Technical consensus will already have been reached within the submitting Stream.
  • The RSE, however, may send back a submission because it would require an unreasonable amount of editing to conform to a proper RFC Style. In such a case the submitting Stream should help the submission's authors to improve it before resubmitting it to the RSE.
Conclusion This draft recounts the history of the RFC's "new formats" work from about 2012 to 2018, making the point that such changes can be large-scale projects that take several years to complete. Any further changes to the Series must therefore be carefully considered, with the RSE overseeing a clear consensus process before any implementation work is begun. Other issues such as where the RSE belongs relative to our I* groups, and what degree of independence the RSE should have, are discussed. As well, some suggestions are made as to how they could be addressed. Feedback for improvements on those suggestions, or any other aspects of this draft, will help it's author to improve it; please send comments to me at the "Author's Address" below.
Security Considerations This draft concerns organisational matters rather than networking matters. It therefore does not have any network security concerns.
IANA Considerations This document makes no request of the IANA.
Acknowledgements Thanks to all those contributing to discussions on the rfced-future mailing list. Those discussions have been wide-ranging, informative and useful. Thanks especially to Brian Carpenter. His draft motivated me to produce this one.
References
Change log [RFC Editor: Please remove.]
  1. draft-brownlee-rfc-changes-and-the-RSE-00
    • Initial version, 25 May 2020
  2. draft-brownlee-rfc-changes-and-the-RSE-01
    • Revision 1, 26 June 2020. Removed 'Oversight' section, replaced it with 'RSEB' section.