Internet DRAFT - draft-carpenter-request-for-comments

draft-carpenter-request-for-comments







Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                             June 20, 2019
Expires: December 22, 2019


                          Request for Comments
                draft-carpenter-request-for-comments-01

Abstract

   This document discusses the Internet technical community's common
   document series and why its independence, and the professional status
   of the RFC Series Editor, must be stoutly defended.

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 December 22, 2019.

Copyright Notice

   Copyright (c) 2019 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 December 22, 2019               [Page 1]

Internet-Draft            Request for Comments                 June 2019


Table of Contents

   1.  TL;DR . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Problems with the IETF's use of the RFC Series  . . . . .   2
   3.  Who Owns the RFC Series?  . . . . . . . . . . . . . . . . . .   3
   4.  Request for Comments means Request for Comments . . . . . . .   6
   5.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change log [RFC Editor: Please remove] . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  TL;DR

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

2.  The Problems with the IETF's use of the RFC Series

   It's very clear that there are problems with the way the IETF uses
   the RFC series.  For example, [RFC0791] is so badly written that it
   would never pass an IETF working group last call, let alone an IETF
   last call or an IESG review today.  Although updated by three other
   RFCs and having a dozen errata, it has never been replaced.  Yet it
   will be exercised billions of times today and every day.  Another
   example is that a newcomer wishing to implement even the simplest
   mail user agent will not find an RFC telling her how to do so.  A
   method to mitigate this problem was proposed but not adopted
   [I-D.ietf-newtrk-sample-isd].  A related problem is that finding the
   latest version of a standard requires arcane knowledge; for example,
   someone looking for the latest IPv6 standard via the popular search
   tools is still quite likely to end up consulting RFC2460, although it
   was obsoleted almost two years ago.  Another example is the frequency
   of references to RFC2616 for HTTP, obsoleted in 2014.

   A major gripe about the RFC series is its limitation to ASCII and its
   reliance on typewriter-friendly formatting and its lack of good
   diagrams.  Fortunately this is being worked on actively, so is not
   further discussed here.

   An occasional annoyance is that since the RFC series is long
   established and serves a very wide community of authors, it includes
   only some documents that are formally agreed statements of IETF rough
   consensus and even fewer that are formally agreed statements of IETF



Carpenter               Expires December 22, 2019               [Page 2]

Internet-Draft            Request for Comments                 June 2019


   rough consensus about proposed standards or best current practice.
   The IETF has preferred to maintain a distinction between proposed
   standards and Internet standards, which means that there are even
   fewer RFCs designated as Internet standards.  An attempt to fix that
   particular problem by reducing the number and hence complexity of the
   categories [RFC6410] has not appeared to make significant
   improvements in either the confusion or the ratio of Internet
   Standards to Proposed ones.  Efforts to reduce the distinction and
   provide stable references to at least the current versions of updated
   standards (e.g., [I-D.klensin-std-numbers]) have received little
   interest.  A proposal that reached IETF Working Group consensus to
   publish a new form of document summarising the status of particular
   complex standards [I-D.ietf-newtrk-repurposing-isd] did not satisfy
   the IESG and was not advanced.

   This problem area has been well known for many years [RFC1796] and
   has occasionally led to concern that some vendors might mislead
   customers by claiming conformance with a non-standard RFC.  For this
   reason, the header text on RFCs was clarified some years ago such
   that readers can clearly distinguish standards from non-standards.
   The original version of this was "This memo provides information for
   the Internet community.  This memo does not specify an Internet
   standard of any kind." and has been used (with occasional updates to
   the wording) since 1994, well before [RFC1796] was published.

   There is therefore no lack of clarity, and has been none since 1994,
   about which RFCs are normative statements of consensus and which are
   not.  Certainly, some readers will bypass the header text as "TL;DR"
   (too long; didn't read) or ignore it as "DK;DC" (don't know; don't
   care) but there is literally nothing the IETF can do about that.  (In
   the new RFC format, it would be possible and perhaps desirable to use
   special typography to emphasise the document status, but it doesn't
   solve the underlying problem of human behaviour, because nothing
   can.)

   I conclude that this set of problems is really nothing to do with the
   RFC series as a publication venue and nothing to do with the format
   of RFCs.  It is entirely the result of the IETF's standards process;
   if the IETF wants it fixed, it must look inwards at that process, and
   not outwards at the community's open publication process.

3.  Who Owns the RFC Series?

   I am not asking this question in a legal sense.  To the extent
   legally possible, the copyright in the RFC series currently belongs
   to the IETF Trust in addition to the authors, but the Trust's
   purposes are broad:




Carpenter               Expires December 22, 2019               [Page 3]

Internet-Draft            Request for Comments                 June 2019


         "Such purposes include, but are not limited to, the advancement
         of education and public interest by acquiring, holding,
         maintaining and licensing certain existing and future
         intellectual property and other property used in connection
         with the Internet standards process and its administration, for
         the advancement of the science and technology associated with
         the Internet and related technology."
         (IETF Trust Agreement, 2005)

   In any case, the important question is who "owns" the RFC series in
   an overall ethical and societal sense.

   It's easier to answer the converse question: who doesn't own the RFC
   series?

   1.  It's clear that the IETF doesn't own it, because the series
       preceded the IETF by 17 years.

   2.  Therefore, of course, the IESG doesn't own it.

   3.  At some point in history, both ARPA (who funded the ARPAnet) and
       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.

   4.  ISOC could certainly make a claim, having funded the series for
       many years now.  However, ISOC, like the IETF Trust, has a broad
       mission:

         "Such educational, charitable, and scientific purposes
         shall include carrying on activities:

         1. To facilitate and support the technical evolution of the
         Internet as a research and education infrastructure, and to
         stimulate the involvement of the scientific community, industry,
         government and others in the evolution of the Internet;
         2. To educate the scientific community, industry and the public
         at large concerning the technology, use and application of the
         Internet;
         3. To promote educational applications of Internet technology
         for the benefit of government, colleges and universities,
         industry, and the public at large;
         4. To provide a forum for exploration of new Internet
         applications, and to stimulate collaboration among organizations
         in their operational use of the global Internet."
         (Articles of Incorporation of the Internet Society)





Carpenter               Expires December 22, 2019               [Page 4]

Internet-Draft            Request for Comments                 June 2019


   5.  The recently formed IETF LLC certainly doesn't own the series,
       although it does channel the contracts and money formerly handled
       directly by ISOC.

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

   The 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.  It is
   community property and must operate on behalf of the community as a
   whole.

   A first important consequence is that major decisions about the
   future of the RFC Series must be taken by a consensus of a very broad
   community.  That doesn't mean the IETF or the IAB.  It means the IETF
   and IAB, plus the IRTF, plus many other people who have contributed
   to, or made use of, the RFC Series over the last fifty years.  How to
   reach out to this community is in itself a big question.

   A second important consequence is that the position of RFC Series
   Editor answers to the community as a whole, not narrowly to the IAB.
   In particular the RFC Series Editor has considerable independence (in
   addition to the obvious independence of the Independent Series
   Editor).  To quote from [RFC6635]:















Carpenter               Expires December 22, 2019               [Page 5]

Internet-Draft            Request for Comments                 June 2019


     "The RFC Series Editor will exercise
     strategic leadership and management over the activities of the RFC
     Publisher and the RFC Production Center... [and]

     o  Represents the RFC Series and the RFC Editor Function within the
        IETF and externally.

     o  Leads the community in the design of improvements to the RFC
        Series.

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

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

     o  Is responsible for developing consensus versions of vision and
        policy documents."

   In other words, the RFC Series Editor must be a highly respected
   independent professional editor, not acting under orders, and serving
   a much wider community than just the IETF.  Given the economic and
   social importance of the Internet, this is a very serious
   responsibility, comparable to the editorship of a major newspaper of
   record.

   The community was very fortunate that the progenitors of the RFC
   Editor function, in particular but not exclusively Steve Crocker, Jon
   Postel, Joyce Reynolds and Bob Braden [I-D.flanagan-fiftyyears], were
   modest and wise enough to know their own limitations, to learn about
   professional editing as they went along, and to remain open and
   sensitive to the needs of the whole Internet technical community.
   When it eventually came time to appoint a professional series editor,
   this proved very hard and fundamentally different from either
   recruiting for technical leadership positions
   [I-D.carpenter-community-leaders] or for administrative or
   operational needs.  Indeed the RFC Series Editor has always been, and
   must remain, a member of the same peer group as IAB members, IESG
   members, IETF and IRTF group chairs, and indeed participants in
   general, each with their own professional skills.

4.  Request for Comments means Request for Comments

   There is an inherent modesty in calling our documents "requests for
   comments".  As the above quotation from RFC1 said right at the
   beginning, we get things wrong.  We want comments, we want errata, we
   want operational feedback, and we want to go round that loop again




Carpenter               Expires December 22, 2019               [Page 6]

Internet-Draft            Request for Comments                 June 2019


   each time we update a specification.  When we forget that, we are
   getting dangerously close to arrogance and hubris.

   Avoiding this trap is indeed the reason that the community has always
   published a number of RFCs that are not the product of organised
   groups, formalised some years ago as the Independent Stream of RFCs
   [RFC4844].  Whether they document deployed solutions not invented in
   the IETF, or alternative solutions not accepted by the IETF, or
   informed technical opinions not discussed in the IETF, they remain
   part of the broader community's open record, and a useful counter-
   balance to any occurrence of groupthink in the IETF, IRTF or IAB.

   Calling IETF standards "requests for comments" is what distinguishes
   the IETF from most other standards organisations, and it's the right
   thing to do.

5.  Experiments

   RFC1 started an experiment, which has been fairly successful so far,
   certainly with consequences that were not foreseen at the time.
   Another experiment was the IEN (Internet Experiment Note) series,
   which ran from 1977 to 1982.  Another one was the ION (IETF
   Operational Notes) series, which ran briefly in 2006/7 [RFC4693].
   Finally, the usage of the RFC subseries designated "FYI", "STD", or
   "BCP" has had limited success.  "FYI" has been dropped, "STD" is
   fairly useless as it is only applied to full Internet standards
   (despite proposals to widen it, as mentioned above), and "BCP" has
   been reasonably successful.

   The next planned experiment is the major upgrade of RFC formatting,
   which will inevitably cause some disturbance to the document
   production process when it goes live.

   A full analysis of these various experiments, their goals, and their
   successes and failures, seems necessary before designing any future
   experiment in the area of document series.

6.  Conclusion

   The IETF has not made a serious attempt to fix known major bugs in
   its standards publication process in the last 15 years.  These are
   not bugs in the RFC Series but in the way the IETF uses the Series.
   The RFC Series exists for the Internet community as a whole, must
   retain its independence and autonomy, and must continue to be managed
   by a senior professional editor.






Carpenter               Expires December 22, 2019               [Page 7]

Internet-Draft            Request for Comments                 June 2019


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

8.  IANA Considerations

   This document makes no request of the IANA.  Like the RFC series, the
   IANA is a service provided for the benefit of the entire Internet
   technical community in a coherent and consistent way.

9.  Acknowledgements

   Useful comments were received from various sources, but this document
   is very much a personal statement.

10.  References

   [I-D.carpenter-community-leaders]
              Carpenter, B., "Some Thoughts on IETF Community
              Leadership", draft-carpenter-community-leaders-01 (work in
              progress), June 2019.

   [I-D.flanagan-fiftyyears]
              Flanagan, H., "Fifty Years of RFCs", draft-flanagan-
              fiftyyears-07 (work in progress), June 2019.

   [I-D.ietf-newtrk-repurposing-isd]
              Klensin, J. and J. Loughney, "Internet Standards
              Documentation (ISDs)", draft-ietf-newtrk-repurposing-
              isd-04 (work in progress), March 2006.

   [I-D.ietf-newtrk-sample-isd]
              Klensin, J., "Internet Standards Documentation (ISDs) -
              Examples", draft-ietf-newtrk-sample-isd-00 (work in
              progress), October 2004.

   [I-D.klensin-std-numbers]
              Klensin, J., "STD Numbers and the IETF Standards Track",
              draft-klensin-std-numbers-02 (work in progress), July
              2018.

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





Carpenter               Expires December 22, 2019               [Page 8]

Internet-Draft            Request for Comments                 June 2019


   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
              Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995,
              <https://www.rfc-editor.org/info/rfc1796>.

   [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,
              <https://www.rfc-editor.org/info/rfc2850>.

   [RFC4693]  Alvestrand, H., "IETF Operational Notes", RFC 4693,
              DOI 10.17487/RFC4693, October 2006,
              <https://www.rfc-editor.org/info/rfc4693>.

   [RFC4844]  Daigle, L., Ed. and Internet Architecture Board, "The RFC
              Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
              July 2007, <https://www.rfc-editor.org/info/rfc4844>.

   [RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
              DOI 10.17487/RFC6410, October 2011,
              <https://www.rfc-editor.org/info/rfc6410>.

   [RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
              Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
              2012, <https://www.rfc-editor.org/info/rfc6635>.

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

   draft-carpenter-request-for-comments-00, 2018-06-06:

   Initial version

   draft-carpenter-request-for-comments-01, 2019-06-20:

   Updated and extended.

Author's Address










Carpenter               Expires December 22, 2019               [Page 9]

Internet-Draft            Request for Comments                 June 2019


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

   Email: brian.e.carpenter@gmail.com











































Carpenter               Expires December 22, 2019              [Page 10]