[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Network Working Group                                     J. N. Brownlee
Internet-Draft                                                U Auckland
Intended status: Informational                               25 May 2020
Expires: 26 November 2020


                   Changes to the RFC Series and RSE
              draft-brownlee-rfc-series-and-rse-changes-00

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.

Copyright Notice

   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.






Brownlee                Expires 26 November 2020                [Page 1]


Internet-Draft             RFC Series Changes                   May 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  RSE Responsibilities  . . . . . . . . . . . . . . . . . . . .   2
   3.  Changes to the RFC Series . . . . . . . . . . . . . . . . . .   3
   4.  Support for the RSE . . . . . . . . . . . . . . . . . . . . .   3
   5.  Oversight and Administration for the RSE  . . . . . . . . . .   4
   6.  Independence of the RSE . . . . . . . . . . . . . . . . . . .   4
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change log [RFC Editor: Please remove.]  . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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




Brownlee                Expires 26 November 2020                [Page 2]


Internet-Draft             RFC Series Changes                   May 2020


3.  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 [RFC6949], "RFC Series
      Format Requirements," May _2013_.

   *  Another three years for a large design team (at least 8 members)
      to produce [RFC7990], "RFC Format Framework", December _2016_,
      [RFC7991], "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:

   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.






Brownlee                Expires 26 November 2020                [Page 3]


Internet-Draft             RFC Series Changes                   May 2020


   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:

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






Brownlee                Expires 26 November 2020                [Page 4]


Internet-Draft             RFC Series Changes                   May 2020


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

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









Brownlee                Expires 26 November 2020                [Page 5]


Internet-Draft             RFC Series Changes                   May 2020


   [I-D.carpenter-rfc-principles]
              Carpenter, B., "Principles of the Request for Comments
              Series", Work in Progress, Internet-Draft, draft-
              carpenter-rfc-principles-01, 17 May 2020,
              <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, May 2013,
              <https://www.rfc-editor.org/info/rfc6949>.

   [RFC7990]  Flanagan, H., "RFC Format Framework", RFC 7990,
              DOI 10.17487/RFC7990, December 2016,
              <https://www.rfc-editor.org/info/rfc7990>.

   [RFC7991]  Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
              RFC 7991, DOI 10.17487/RFC7991, December 2016,
              <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, February
              2020, <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

   Email: nevil.brownlee@gmail.com











Brownlee                Expires 26 November 2020                [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/