Internet DRAFT - draft-thomson-rfcplusplus-label

draft-thomson-rfcplusplus-label







Network Working Group                                         M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Experimental                              July 02, 2018
Expires: January 3, 2019


                            The Label "RFC"
                   draft-thomson-rfcplusplus-label-00

Abstract

   The perception and reality of the RFC series have long been separate.
   More than 20 years of attempts to correct perception, starting with
   RFC 1796, have been unsuccessful.  This document proposes an
   experiment to see if changing the labels on document will have any
   effect on fixing that problem.

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 January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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.



Thomson                  Expires January 3, 2019                [Page 1]

Internet-Draft               The Label "RFC"                   July 2018


1.  Introduction

   RFC 1796 [RFCS] was published in April of 1995.  At that time, it was
   clear that there was an "regrettably well spread misconception" that
   the label "RFC" implied "some level of recognition".  Not a lot has
   changed in the 23 years since that statement.

   The common perception of the significance of the "RFC" label is
   simple.  That simple interpretation doesn't capture the broad range
   of uses that the label is applied to.  The view expressed in RFC 1796
   was that this loss of information was adequately addressed by further
   engaging in dialog.  This includes the provision of prominent notices
   in documents, such as the "Status of this Note" section, as well as
   providing explanations about what documents mean.  This view further
   holds that the merits of a document do not solely derive from the
   status of the document, but from the quality and substance of its
   contents.

   This document suggests that this view to some degree underestimates
   the value of a label (or "brand").  It also overestimates the
   willingness of audiences to engage with the nuanced interpretation
   that is required to appreciate the complexity of a document.  An RFC
   can address complex technical matters that require considerable
   expertise in the field to understand with enough detail to appreciate
   the full implications.

   The Internet Standards Process [RFC2026] describes a process that has
   consistently produced quality documents.  This document proposes an
   experiment that limits the use of the "RFC" label to the product of
   that process.

   The value of the other documents currently published on the RFC
   series is undeniable.  The creation of new series' for documents
   produced by different processes will ensure that critical information
   - and dissenting viewpoints - retain a venue for reaching an
   audience.

2.  Nuance in Interpretation

   Misconceptions about the significance of publication as an RFC is
   commonplace.  This isn't a design failure, but an inherent property
   of the current system of document streams.  However, that potential
   for misunderstanding can be problematic.

   Capturing the nuance required to properly understand a protocol is
   difficult, and a large number of documents fail to properly convey
   that status.




Thomson                  Expires January 3, 2019                [Page 2]

Internet-Draft               The Label "RFC"                   July 2018


   For example, ZRTP [RFC6189] was published as an informational RFC on
   the IETF stream after the IETF reached consensus to develop DTLS-SRTP
   [RFC5764] for the same use case.

   Similarly, HTTP Live Streaming (HLS) [RFC8216] was published on the
   Independent Submissions Stream in defiance of a standardized
   protocol, MPEG-DASH [DASH].

   Both describe de-facto standards, each of which are implemented in
   more than one product and deployed.  Both are also highly
   contentious.

   Each captures a range of design decisions that differ from the
   commonly-accepted view.  Aspects of these designs have merit and
   documenting them has value, if only from the perspective of
   understanding alternative approaches.

   That value does not naturally extend to deployment, even if each
   document contains enough detail to implement and deploy the protocol
   they describe.  If nothing else, the deployment of these protocols
   could adversely affect interoperability relative to implementations
   of their more widely accepted alternatives.

   Information about the status of the document is contained entirely in
   the "Status of this Note" section.  For instance, ZRTP is published
   with IETF consensus, so the significance of it not being an "Internet
   Standards Track specification" is easily lost.  That it also limits
   its mention of DTLS-SRTP to comparative criticisms makes it possible
   to interpret the document as it represents itself: a newer, superior
   technique.

   There are numerous examples of RFCs that make an honest
   representation of their status in more than just the boilerplate.  In
   addition to those proprietary documents that identify that status in
   their title, a number of documents are clear about status and intent.
   For example, though RFC 6886 [NAT-PMP] was deployed, it includes
   clear statements on status, as well as sections on how to migrate to
   the IETF consensus protocol [RFC6887]; to go further, because RFC
   5690 [ACK-CONGESTION] was never deployed, it avoids any
   misapprehension by not requesting allocation of necessary codepoints.

3.  No Shortage of Venues for Publication

   So why is the publication of an RFC so keenly sought, when the
   document doesn't capture the output of the Internet Standards
   Process?





Thomson                  Expires January 3, 2019                [Page 3]

Internet-Draft               The Label "RFC"                   July 2018


   It might be reasonable to say that the goal is to create a stable,
   referenceable specification for a technology that might be of
   interest to the Internet community.  This view is consistent with the
   rationale given in the Section 2 of [RFC4846], which formalized the
   Independent Submissions Stream.

   For the examples given, a principled reason for publication is well
   justified.  While neither document represents IETF consensus, they
   are both technical contributions of some value.

   It's not obvious that this goal is not accomplished by publishing
   specifications on a web site.  For instance, the examples from
   Section 2 both ZRTP and HLS have a presence on the Internet where
   specifications and related material are published
   (http://zfoneproject.com/zrtp_ietf.html [1] and
   https://developer.apple.com/streaming/ [2] respectively).  The
   Internet Archive (https://web.archive.org/ [3]) shows that these
   sites have been available and stable for an extended period.
   Furthermore, both websites publish links to updated specifications
   ([ZRTPBIS] and [HLSBIS]).

   If the intent is to reach an IETF audience, then there are many other
   venues for publication that achieve the same goal.  For instance,
   input from the academic community is often provided in the form of
   papers.  Other inputs variously use blogs, journal articles, source
   code repositories, and even posts to mailing lists.  For work that is
   taken as a normative dependency a higher standard of publication is
   likely necessary, but most of these alternative forms can be cited
   informatively.

4.  RFC == Standards Track

   This documents proposes reserving the "RFC" label for those documents
   that are the product of the Internet Standards Process [RFC2026].

   It's true that the Internet Standards Process isn't perfect and it
   cannot guarantee a particular level of quality.  Any failings can
   (and should) be addressed by improving the process.

   Reserving the RFC Series for the publication of products of the
   Internet Standards Process would ensure clarity about what "RFC"
   means.

4.1.  New Labels for Other Documents

   The IETF publishes informational and experimental documents.  The
   expectations around what level of agreement is necessary to publish




Thomson                  Expires January 3, 2019                [Page 4]

Internet-Draft               The Label "RFC"                   July 2018


   these documents differs from documents published on the standards
   track.  These documents should use other labels.

   The IETF publishes best current practice (BCP) documents that
   describe its own processes.  These don't codify agreement about a
   protocol inasmuch as they don't describe something implemented in
   software.  They do follow the same processes and require similar
   levels of agreement.  Use of the RFC label for BCP documents is
   appropriate, though there is no inherent reason not to use another
   label either.

   Similarly, the IRTF and IAB produce documents that do not represent
   an agreement in the same way.  These documents should use other
   labels.

   The possible exception to this are the documents produced by the
   Crypto-Forum Research Group (CFRG).  If it is considered important to
   publish CFRG documents with the "RFC" label, then it should be
   possible to attain IETF consensus for publication in the RFC Series.

   The Independent Submissions Editor also publishes RFCs.  These
   documents should use other labels.

4.2.  No Change to Existing Documents

   There is no point in revising existing documents.  These documents
   were published with an expectation of immutability.  Thus, any
   attempt to relabel these would be limited to changing document
   metadata.  Copies of documents taken prior to any updates might not
   be updated.

   Any misconception that might exist in relation to existing documents
   is likely irreparable.  Retracting the issuance of RFC numbers for
   the hundreds of documents that might need to be assigned new labels
   retrospectively isn't realistic.  Thus, this document does not
   propose any action for documents already published.

4.3.  Should the Experiment Fail

   If the community determines that the negative consequences of this
   experiment outweigh the benefits, then documents published with new
   labels will be allocated RFC numbers.  This requires that during the
   experiment:

   o  the altered publication system needs to produce an output for
      affected documents that would be compatible with later publication
      as RFC; and




Thomson                  Expires January 3, 2019                [Page 5]

Internet-Draft               The Label "RFC"                   July 2018


   o  the ongoing experiment - specifically its potential for failure -
      be considered when implementing changes to processes on affected
      streams.

   It might also be possible to reserve RFC numbers, which would
   preserve the loosely chronological ordering of RFCs by number.  This
   document does not take any position on whether this effort would be
   worthwhile.

4.4.  A New Label is Necessary

   Almost every RFC published in the last 35 years contains a "Status of
   this Memo" section.  Recent documents include a markings in the
   header, signifying the stream and status (or category).  In addition,
   the most widely used source for RFCs, https://tools.ietf.org/html/
   [4], uses a colour-coding scheme to highlight the status of
   documents.

   The "STD" label hasn't been especially effective in distinguishing
   those documents that attain the rare status of Full Internet
   Standard.  The BCP subseries has been more effective, perhaps because
   of the greater familiarity of its primary audience with its meaning.

   It's possible that with a move to presenting RFCs in HTML rather than
   text, new methods of signaling status could be developed.  For
   instance, using styling such as colour, layout, or font choice to
   represent origin and status.  However, the choice of rendering is not
   part of the canonical XML document.  Alternative renderings could
   legitimately erase that information.

   That leads to the conclusion that clearer marking for status, while
   possibly helpful, would not be sufficiently effective in addressing
   the problem.

5.  How To Measure Success

   A term of 3 years is proposed as being long enough to provide enough
   evidence to assess the effect of a change of labels.

   One hypothesis this experiment proposes to test is the degree to
   which the "RFC" label motivates authors seeking publication.  Though
   numbers are unlikely to provide a clear answer when so much of the
   problem is subjective, measuring the rate of submission and
   publication for affected documents could provide some insight.

   Measuring different sources gives a multiple perspectives relative to
   the output of the standards process.  For instance, informational
   documents are closely related to the standards process and so are



Thomson                  Expires January 3, 2019                [Page 6]

Internet-Draft               The Label "RFC"                   July 2018


   hypothesized to be relatively unaffected by any change, whereas IAB
   documents might follow a separate cadence and could be unaffected.

   Documents published by the IETF as Informational, and those published
   on the Independent Submissions Stream are most likely to have a high
   enough volume to produce a large enough sample.  Publication rates
   for other sources might not be high enough to observe differences.

   In the first test, the rate of requests for publication over time is
   recorded.  If the introduction of the experiment causes the number to
   drop relative to long-term trends, then that drop might indicate that
   interest in publication is driven in part by the label.

   The second test will record the number of documents published using
   new labels.  A drop in publication rate relative to that of those
   documents published with the "RFC" label could also indicate that a
   change of label has some effect.

   Trends in publication rates are easy to gather; some work might be
   required to establish the rate of submissions prior to the
   commencement of any experiment.

   Any measurement is susceptible to noise, and the rate of publication
   on many streams is not high, nor is it consistent.  Some allowance
   should be made for fluctuations as the experiment is commenced, or as
   processes change to support the experiment.

6.  Security and Privacy Considerations

   It is believed that there are none.

7.  IANA Considerations

   This document makes no request of IANA.

8.  References

8.1.  Informative References

   [ACK-CONGESTION]
              Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
              Acknowledgement Congestion Control to TCP", RFC 5690,
              DOI 10.17487/RFC5690, February 2010,
              <https://www.rfc-editor.org/info/rfc5690>.

   [DASH]     "Dynamic adaptive streaming over HTTP (DASH)", ISO/
              IEC 23009-1, May 2014.




Thomson                  Expires January 3, 2019                [Page 7]

Internet-Draft               The Label "RFC"                   July 2018


   [HLSBIS]   Pantos, R., "HTTP Live Streaming 2nd Edition", draft-
              pantos-hls-rfc8216bis-02 (work in progress), June 2018.

   [NAT-PMP]  Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
              (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013,
              <https://www.rfc-editor.org/info/rfc6886>.

   [NEWTRK-RFC]
              Rosenberg, J. and A. Mankin, "What's In a Name: RFC",
              draft-rosenberg-mankin-newtrk-rfc-00 (work in progress),
              October 2004.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

   [RFC4846]  Klensin, J., Ed. and D. Thaler, Ed., "Independent
              Submissions to the RFC Editor", RFC 4846,
              DOI 10.17487/RFC4846, July 2007,
              <https://www.rfc-editor.org/info/rfc4846>.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764,
              DOI 10.17487/RFC5764, May 2010,
              <https://www.rfc-editor.org/info/rfc5764>.

   [RFC6189]  Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
              Media Path Key Agreement for Unicast Secure RTP",
              RFC 6189, DOI 10.17487/RFC6189, April 2011,
              <https://www.rfc-editor.org/info/rfc6189>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <https://www.rfc-editor.org/info/rfc6887>.

   [RFC8216]  Pantos, R., Ed. and W. May, "HTTP Live Streaming",
              RFC 8216, DOI 10.17487/RFC8216, August 2017,
              <https://www.rfc-editor.org/info/rfc8216>.

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

   [ZRTPBIS]  Zimmermann, P., Johnston, A., and T. Cross, "ZRTP: Media
              Path Key Agreement for Unicast Secure RTP", draft-
              zimmermann-rfc6189bis-00 (work in progress), July 2016.



Thomson                  Expires January 3, 2019                [Page 8]

Internet-Draft               The Label "RFC"                   July 2018


8.2.  URIs

   [1] http://zfoneproject.com/zrtp_ietf.html

   [2] https://developer.apple.com/streaming/

   [3] https://web.archive.org/

   [4] https://tools.ietf.org/html/

Acknowledgments

   This isn't really a new position.  It's a little embarrassing to find
   that all these arguments are merely a reiteration of arguments
   articulated more than a decade ago.  [NEWTRK-RFC] contains many of
   the same arguments.

Author's Address

   Martin Thomson
   Mozilla

   Email: martin.thomson@gmail.com




























Thomson                  Expires January 3, 2019                [Page 9]