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, and the need for the RFC Series Editor
to be independent of the Series Input Streams (the I* groups).
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?
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:
- Changes must not impact productivity of the RPC.
- Development and testing of any changes will take
significant time.
- 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 Working Group,
using the rfced-future mailing list for RFC Series discussions,
end for calling consensus once a change has been discussed
on that list.
If consensus-agreed changes require new tools:
- If suitable (open-source) tools exist, we should use them.
- Otherwise, a (part-time) Project Manager should be employed
to oversee their implementation.
Oversight and Administration for the RSE
Of course the RSE needs to report on each year's activities,
at least to members of all the RFC input Streams,
at the last IETF meeting's Plenary in each year.
As well, employment matters such as contract negotiation and
extension or replacement are needed. Perhaps the LLC Executive
Director - for example - could handle these?
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.]
- draft-brownlee-rfc-changes-and-the-RSE-00
- Initial version, 25 May 2020