Internet-Draft RFC Series Changes May 2020
Brownlee Expires 26 November 2020 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-brownlee-rfc-series-and-rse-changes-00
Published:
Intended Status:
Informational
Expires:
Author:
J. N. Brownlee
U Auckland

Changes to the RFC Series and RSE

Abstract

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

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 26 November 2020.

Table of Contents

1. Introduction

Over the last few weeks the rfced-future mailing list has discussed topics such as:

This draft addresses those topics in a little more detail.

The history of our "new formats" in Section 3 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.

2. RSE Responsibilities

RFC Series Editor Responsibilities are clearly set out in [RFC8729], "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.

3. Changes to the RFC Series

Our last RSE was appointed (and contracted directly by ISOC) in 2011. Her first few years were busy:

RFC 7990 recognised that it would take time to implement these changes; its' section 10.2, "Testing and Transition" said:

Feedback will result in regular iteration of the basic code and XML
vocabulary.  In order to limit the amount of time the RFC Production
Center (RPC) spends on testing and quality assurance (QA), their
priority will be to edit and publish documents; therefore, community
 assistance will be necessary to help move this stage along.

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.

4. 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:

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

5. 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?

6. Independence of the RSE

[I-D.carpenter-rfc-principles], 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:

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

8. Security Considerations

This draft concerns organisational matters rather than networking matters. It therefore does not have any network security concerns.

9. IANA Considerations

This document makes no request of the IANA.

10. 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 [I-D.carpenter-rfc-principles] motivated me to produce this one.

11. References

[I-D.carpenter-rfc-principles]
Carpenter, B., "Principles of the Request for Comments Series", Work in Progress, Internet-Draft, draft-carpenter-rfc-principles-01, , <https://tools.ietf.org/html/draft-carpenter-rfc-principles-01>.
[RFC6949]
Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, , <https://www.rfc-editor.org/info/rfc6949>.
[RFC7990]
Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, , <https://www.rfc-editor.org/info/rfc7990>.
[RFC7991]
Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, , <https://www.rfc-editor.org/info/rfc7991>.
[RFC8729]
Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and RFC Editor", RFC 8729, DOI 10.17487/RFC8729, , <https://www.rfc-editor.org/info/rfc8729>.

Appendix A. Change log [RFC Editor: Please remove.]

  1. draft-brownlee-rfc-changes-and-the-RSE-00

    • Initial version, 25 May 2020

Author's Address

Nevil Brownlee
School of Computer Science
University of Auckland
Private Bag 92019
Auckland 1142
New Zealand