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

Versions: 00 01

Network Working Group                                    B. E. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                               18 May 2020
Expires: 19 November 2020

             Principles of the Request for Comments Series


   This document discusses the underlying principles of the Internet
   technical community's Request for Comments document Series.

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

Carpenter               Expires 19 November 2020                [Page 1]

Internet-Draft            RFC Series Principles                 May 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Proposed Principles . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  The RFC Series as a Whole . . . . . . . . . . . . . . . .   6
     3.2.  The RFC Series Editor . . . . . . . . . . . . . . . . . .   8
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Change log [RFC Editor: Please remove] . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document was written as background material for ongoing
   discussions about the role of the Request for Comments (RFC) Series
   Editor (the RSE).  This version is purely personal opinion, but with
   some community comments incorporated.  The author welcomes further
   comments, best sent to the mailing list rfc-interest@rfc-editor.org
   if they concern the RFC Series in general, or to the mailing list
   rfced-future@iab.org if they concern the role of the RSE

   The RFC Series has a 50 year history, too long to summarise here, so
   the reader is assumed to be familiar with [RFC8700].  However, the
   Series does not appear to have a documented set of principles or a
   full charter.  This will make the obvious first task of the future
   RSE -- developing a strategy for the Series -- hard, if not
   impossible.  The goal of this document is to outline what those
   principles might be, for community debate.  Once the principles are
   clear, the next step could be to draft a full charter based on them,
   also for community debate.  Alternatively, the principles could be
   incorporated in a revision of [RFC8729].

   This document does not aim to provide a problem statement or gap
   analysis, and technical matters such as RFC formatting are completely
   out of scope.  Matters concerning the IETF standards process, and how
   it uses the Series, are also out of scope.  Some problems in the
   standards process are problems in how the IETF uses the RFC Series,
   not problems in the Series itself.  (Interested readers can find
   comments on that topic in [I-D.carpenter-request-for-comments].)

   The document starts with a review of existing background material
   that touches on principles of the Series, and then offers a set of
   proposed principles for debate.

Carpenter               Expires 19 November 2020                [Page 2]

Internet-Draft            RFC Series Principles                 May 2020

2.  Background

   The RFC Editor web site states the following:

      The RFC series contains technical and organizational documents
      about the Internet, including the specifications and policy
      documents produced by four streams: the Internet Engineering
      Task Force (IETF), the Internet Research Task Force (IRTF), the
      Internet Architecture Board (IAB), and Independent Submissions.

   This says little about underlying principles.  Instead, consider the
   original guidance from the author of the first RFC:

   I present here some of the tentative agreements reached and some of
   the open questions encountered.  Very little of what is here is firm
   and reactions are expected.

   [RFC0001], Steve Crocker, 7 April 1969.

   More recently, Steve wrote this in [RFC8700]:

      The basic ground rules were that anyone could say anything and
      that nothing was official. And to emphasize the point, I used
      Bill Duvall's suggestion and labeled the notes "Request for

   Partly as a result of this starting point, the tradition has always
   been that RFCs may be used rather freely, including reproduction in
   their entirety and translation into other languages.  In more recent
   years, the IETF has asserted change control over its own documents,
   even when published as RFCs, by virtue of the IETF Trust's legal
   conditions.  This raises the issue of who owns the copyright.  Some
   RFCs are considered to have been placed in the public domain as a
   result of being part of government funded projects.  Copyright in
   some others presumably belongs to their authors, or to those authors'
   employers.  To the extent legally possible, the copyright in the RFC
   Series currently belongs to the IETF Trust in addition to the

   For completeness, note that each RFC stream has its own policy on
   copyright and change control issues, not discussed in detail here.

   In any case, the question of copyright is not the same as asking who
   "owns" the RFC Series in an overall ethical and societal sense.  It
   is easy to establish who does _not_ own the Series:

   1.  The IETF does not own it, because the Series preceded the IETF by
       17 years.

Carpenter               Expires 19 November 2020                [Page 3]

Internet-Draft            RFC Series Principles                 May 2020

   2.  Therefore the IESG does not own it.

   3.  As noted, the IETF Trust only has limited intellectual property
       rights in some (but not all) RFCs.

   4.  At some point in history, both ARPA (who funded the ARPAnet) and
       USC/ISI (who provided RFC editing under contract) could have made
       a claim.  But that faded when a paid RFC Editor was directly
       contracted by ISOC.

   5.  ISOC could perhaps make a claim, having funded the Series for
       many years now.  ISOC has a broad purpose which certainly
       empowers it to support the RFC Series, but that does not imply
       control or ownership.

   6.  The IETF LLC, technically a subsidiary of ISOC, therefore does
       not own the Series either, although it does channel the contracts
       and money formerly handled directly by ISOC.

   7.  Finally, the Internet Architecture Board could make a claim based
       on its charter [RFC2850], which states that:

       The RFC series constitutes the archival publication channel
       for Internet Standards and for other contributions by the
       Internet research and engineering community. RFCs are available
       free of charge to anyone via the Internet. The IAB must approve
       the appointment of an organization to act as RFC Editor and the
       general policy followed by the RFC Editor.

       This text makes it clear that the RFC Series is much broader in
       scope than the IETF, and limits the IAB's authority to matters of
       general policy.

   A reasonable conclusion from the above is that none of the I*
   organisations (IETF Trust, IETF LLC, IETF, IESG, IAB or ISOC) can
   claim exclusivity of ownership or control over the RFC Series.

   Despite the limited authority granted by its own charter, the IAB has
   published various RFCs about the Series as a whole.  I quote here
   from two in particular.

   Firstly, [RFC8729] states as follows:

Carpenter               Expires 19 November 2020                [Page 4]

Internet-Draft            RFC Series Principles                 May 2020

   The RFC Series is the archival series dedicated to documenting
   Internet technical specifications, including general contributions
   from the Internet research and engineering community as well as
   standards documents.

   RFCs are available free of charge to anyone via the Internet.


   The RFC Editor is an expert technical editor and series editor,
   acting to support the mission of the RFC Series.  As such, the RFC
   Editor is the implementer handling the editorial management of the
   RFC Series, in accordance with the defined processes.  In addition,
   the RFC Editor is expected to be the expert and prime mover in
   discussions about policies for editing, publishing, and archiving


   The IAB monitors the effectiveness of the policies in force and their
   implementation to ensure that the RFC Editor activity meets the
   editorial management and document publication needs as referenced in
   this document.  In the event of serious non-conformance, the IAB,
   either on its own initiative or at the request of the IETF
   Administration LLC Board, may require the IETF Executive Director to
   vary or terminate and renegotiate the arrangements for the RFC Editor

   A second document clarifies that RFC Series Editor has considerable
   independence (in addition to the obvious independence of the
   Independent Series Editor).  To quote from [RFC8728]:

Carpenter               Expires 19 November 2020                [Page 5]

Internet-Draft            RFC Series Principles                 May 2020

   The RFC Editor function is responsible for
   the packaging and distribution of the documents.  As such, documents
   from these streams are edited and processed by the Production Center
   and published by the Publisher.  The RFC Series Editor will exercise
   strategic leadership and management over the activities of the RFC
   Publisher and the RFC Production Center (both of which can be seen as
   back-office functions) and will be the entity that:

   *  Represents the RFC Series and the RFC Editor function within the
      IETF and externally.

   *  Leads the community in the design of improvements to the RFC

   *  Is responsible for planning and seeing to the execution of
      improvements in the RFC Editor production and access processes.

   *  Is responsible for the content of the rfc-editor.org web site,
      which is operated and maintained by the RFC Publisher.

   *  Is responsible for developing consensus versions of vision and
      policy documents.  These documents will be reviewed by the RFC
      Series Oversight Committee (Section 3.1) and subject to its
      approval before final publication.

3.  Proposed Principles

   This section, in particular, needs community review.  Some of it is
   adapted from existing documents.

3.1.  The RFC Series as a Whole

   1.  The RFC Series is the archival series that documents Internet
       technical specifications, descriptions, and commentaries,
       including general contributions from the Internet research and
       engineering community, as well as standards documents.  It also
       includes some organisational documents from the same community.

       *  "Archival" means that the documents must be available for the
          indefinite future in a form that is trusted by all parties.
          In particular there must be no doubt as to the precise
          original text and diagrams, regardless of the format in which
          the documents are stored or displayed.  Errors or omissions
          detected after publication, and subsequent modifications or
          extensions of the document content, do not change the archived
          document itself.

Carpenter               Expires 19 November 2020                [Page 6]

Internet-Draft            RFC Series Principles                 May 2020

   2.  All RFCs are available free of charge to anyone via the Internet.
       They may be freely translated in their entirety into any

   3.  Request for Comments means Request for Comments.

       *  There is an inherent modesty in calling our documents
          "requests for comments".  We get things wrong, we want
          comments, we want errata, we want operational feedback, and we
          want to go round that loop again.  This property is a useful
          counter-balance to any occurrence of groupthink in the

   4.  RFCs come from various streams, i.e. originating organisations.

       *  Each stream has its own policy on change control, copyright,
          and patents, with the IETF Trust generally acting as a
          repository for intellectual property rights that are not
          retained by the authors.

       *  Each stream has full control of the technical content of its

       *  The RFC Editor team has control of editorial matters, subject
          to review by the relevant stream and the document authors.  In
          particular, a badly written document may be returned to its
          stream for improvements if an abnormal amount of copy-editing
          is required.

       *  If an individual member of the RFC Editor team has personal
          comments on the technical content of a draft RFC, they must be
          handled in person, using the appropriate mechanism of the
          stream concerned, not as an RFC Editor matter.

       *  If the RFC Editor team believes that a draft RFC contains a
          serious technical flaw, which the stream declines to change,
          the RFC Editor cannot block the document indefinitely.  Note
          that there is more discussion of such disagreements in
          Section 4.3 of [RFC8728].

       *  New streams may in principle be created, subject to community
          agreement and guidelines to be defined.

       *  Defunct streams may be closed, subject to community agreement.

   5.  The RFC Series is community property and must operate on behalf
       of the community as a whole.

Carpenter               Expires 19 November 2020                [Page 7]

Internet-Draft            RFC Series Principles                 May 2020

       *  The exact definition of the relevant community is open for
          debate.  One definition is: the IETF, the IRTF, the IAB and
          the many other people who have contributed to, or made use of,
          the RFC Series over the last fifty years.  In particular, many
          users of the RFC series, ranging for example from junior
          hardware or software engineers to senior executives overseeing
          procurement decisions, will never participate directly in the
          IETF or IRTF.

   6.  Major decisions about the future of the RFC Series should be
       taken by a rough consensus of this very broad community.

       *  How to reach out to this community and judge its consensus is
          an open question.  The mechanism needs to be open to all
          interested parties, but with a well-defined process and checks
          and balances.  Although the community is broader than the
          IETF, the IETF Working Group rough consensus process may be
          the best model.

3.2.  The RFC Series Editor

   1.  The RFC Series Editor is an independent professional editor,
       serving a much wider community than just the IETF.  Given the
       economic and social importance of the Internet, this is a serious
       responsibility.  Similar roles might be executive leadership
       positions at a technical or academic publisher.

       Five responsibilities adapted from [RFC8728] apply:

       *  Represents the RFC Series and the RFC Editor function within
          the IETF, IRTF and externally.

       *  Leads the community in the design of improvements to the RFC

       *  Is responsible for developing vision and policy documents, and
          establishing community consensus for them.

       *  Is responsible for planning and overseeing the execution of
          improvements in the RFC Editor production and access
          processes, in collaboration with IETF LLC as appropriate.

       *  Is responsible for the content of the RFC Editor web site,
          which is operated and maintained by the RFC Publisher.

Carpenter               Expires 19 November 2020                [Page 8]

Internet-Draft            RFC Series Principles                 May 2020

   2.  The RFC Series Editor, while paid to serve the community, is a
       member of the same professional peer group as IAB members, IESG
       members, IETF and IRTF group chairs, and other experienced
       members of the technical community, each with their own distinct
       professional skills.

   3.  The position of RFC Series Editor answers to the community as a

       *  The grant of authority in the IAB charter should be reviewed
          in this light.

4.  Conclusion

   In summary, the RFC Series exists for the Internet community as a
   whole, must retain its independence, openness and autonomy, and must
   continue to be managed by a senior professional editor.

5.  Security Considerations

   Security issues are discussed in all recent RFCs.  This uniformity
   illustrates the coherence of the RFC Series and the way it has been
   used to ensure a degree of order in the chaotic world of Internet
   design, implementation and deployment.

   An assumption in our community is that all actors act in good faith,
   subject of course to normal human failures.  As far as possible, the
   RFC Editor regime needs to be immune to malicious acts of any kind.
   For that reason, it is important that appropriate organisational
   checks and balances are in place.

6.  IANA Considerations

   This document makes no request of the IANA.

7.  Acknowledgements

   Important comments were received from Carsten Bormann, Nevil
   Brownlee, Adrian Farrel, Stephen Farrell, Joel Halpern, John Klensin,
   Mark Nottingham, Tommy Pauly, Eric Rescorla, Adam Roach, Mike
   StJohns, Martin Thomson, and others.

8.  References

Carpenter               Expires 19 November 2020                [Page 9]

Internet-Draft            RFC Series Principles                 May 2020

              Carpenter, B., "Request for Comments", Work in Progress,
              Internet-Draft, draft-carpenter-request-for-comments-01,
              19 June 2019, <https://tools.ietf.org/html/draft-

   [RFC0001]  Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001,
              April 1969, <https://www.rfc-editor.org/info/rfc1>.

   [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
              "Charter of the Internet Architecture Board (IAB)",
              BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,

   [RFC8700]  Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700,
              DOI 10.17487/RFC8700, December 2019,

   [RFC8728]  Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed.,
              "RFC Editor Model (Version 2)", RFC 8728,
              DOI 10.17487/RFC8728, February 2020,

   [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]

   draft-carpenter-rfc-principles-01, 2020-05-18:

   *  Numerous updates following initial community comments.

   draft-carpenter-rfc-principles-00, 2020-05-09:

   *  Initial version (some content based on draft-carpenter-request-

Author's Address

   Brian Carpenter
   School of Computer Science
   University of Auckland
   PB 92019
   Auckland 1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

Carpenter               Expires 19 November 2020               [Page 10]

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