[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         J. Klensin
Internet-Draft                                             July 13, 2018
Intended status: Informational
Expires: January 14, 2019

           Alternatives to the RFC++ "Switch Labels" Proposal


   A BoF, identified as RFC++ and focused on possible changes to the
   identification of a broad range of documents and sources with the
   term "RFC", has been scheduled for IETF 102 and extensively discussed
   on an associated mailing list.  At least based on the BoF proposal,
   the BoF was expected to accept a particular problem description as
   both adequate and sufficiently important to justify changes and then
   to consider one particular proposal.  Mailing list discussions have
   indicated that neither the problem statement nor the proposal are
   without controversy.  An Internet Draft has been posted that
   describes that particular proposal in more detail.  Without
   significant analysis of the problem statement, this draft mentions
   that proposal as a possible member of a family of similar proposals
   and then outlines some other families of proposals for the
   convenience of BoF participants and the community more generally.

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 14, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Klensin                 Expires January 14, 2019                [Page 1]

Internet-Draft              RFC Alternatives                   July 2018

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Note in Draft for Initial Version . . . . . . . . . . . .   2
     1.2.  Questions about The Problem . . . . . . . . . . . . . . .   2
     1.3.  Discussion List . . . . . . . . . . . . . . . . . . . . .   3
   2.  Possibility 1: Remove the "RFC" name and label from non-IETF
       documents . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Possibility 2: Qualifying Labels Rather than Replacing THem .   3
   4.  Possibility 3: Create and Use More Supplmental Labels,
       Building on STD, BCP, and FYI . . . . . . . . . . . . . . . .   4
   5.  Possibility 4: Treat Problem as an Educational One  . . . . .   5
   6.  Possibility 5: The Really Radical Solution  . . . . . . . . .   7
   7.  Additional Possibilities and Evaluation . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

1.1.  Note in Draft for Initial Version

   This is a very preliminary and hastily-prepared draft, provided in
   the hope of contributing some specific alternatives to the one
   presented in the request for the "The label 'RFC' BOF" at IETF 102,
   now scheduled for 18:10 Montreal time on Monday 16 July 2018.  It is
   also written somewhat more personally than is typical of more mature
   Internet Drafts.  Please forgive typographical errors, poorly-
   constructed sentences, and omissions resulting from the associated

1.2.  Questions about The Problem

   There has been considerable discussion on the RFC++ list
   [RFCplusplus-list] and elsewhere about whether there is actually a
   problem that requires solving and whether, given that any change has

Klensin                 Expires January 14, 2019                [Page 2]

Internet-Draft              RFC Alternatives                   July 2018

   costs, the problems are severe enough that solutions are in order or
   whether we should just live with them.

   Those issues are out of scope for this document.  It assumes
   (contrary to the opinion of the author) that there is a problem,
   largely as described in a 1995 analysis [RFC1796], that measures
   taken since have been ineffective, and that the IETF community will
   conclude that there is a problem worth solving.  If so, the solution
   included in the BOF proposal [RFCplusplus-proposal] and initial
   document [Thomson-RFCplusplus] is only one of several possibilities.
   The balance of this Internet-Draft outlines some of those other

1.3.  Discussion List

   Discussion of this document and related issues should be directed to
   the Rfcplusplus@ietf.org mailing list.

2.  Possibility 1: Remove the "RFC" name and label from non-IETF

   This possibility is described in a document posted just before the
   normal posting cutoff [Thomson-RFCplusplus].  It essentially suggests
   replacing the RFC name and numbers on non-IETF documents with other
   names and numbering series.  It is not further described here other
   than to note that several people have argued that, if a key property
   of an experiment is that it can be undone in a way that leaves things
   at the status quo before the experiment started, it is not an
   experiment but a change that can be reversed only at considerable
   cost if at all.

3.  Possibility 2: Qualifying Labels Rather than Replacing THem

   The following is derived, with permission, from Brian Carpenter's
   email titled "Qualified Labels", Tuesday, July 10, 2018 14:23 +1200.

   1.  Continue to use the RFC series as today for multiple purposes.
       But recognise more clearly that the number is an archival

   2.  For all normal purposes, including citations, use a *qualified*
       label.  Rather than writing a formal definition, there's an
       example of each qualifier below.

   An advantage is that this can be retrofitted straightforwardly to
   *all* RFCs, indexes, citation libraries, etc.  And it could be
   removed just as easily if it proves to be a problem rather than a

Klensin                 Expires January 14, 2019                [Page 3]

Internet-Draft              RFC Alternatives                   July 2018


              RFC8200-STD (or RFC8200-STD86)
              RFC2026-BCP (or RFC2026-BCP9)

              RFC8394-INFO  (for IETF informationals)
              RFC7575-RSCH  (for IRTF informationals)
              RFC8351-INDEP (for Independent informationals)


                                 Figure 1

4.  Possibility 3: Create and Use More Supplmental Labels, Building on
    STD, BCP, and FYI

   Many years ago, the RFC Editor, encouraged by the IETF, introduced
   supplementary numbering systems, overlaid on the archival RFC numbers
   and identifying conceptual documents rather than specific documents
   and instances.  Those series -- "STD", "BCP", and the now-retired
   "FYI" -- have served their original purpose of identifying documents
   and grouping closely-related work together and/or providing a
   reference to current versions rather than specific documents.  They,
   especially STD, have been less successful than its original
   description [RFC1311] or RFC 1796 might have anticipated, i.e., for
   distinguishing between standards and other documents.  At least part
   of the reason has been that those numbers are not assigned to
   Proposed (and, earlier, Draft) Standards and much of the Internet
   continues to run on Proposed Standards and legacy Draft Standards.
   By contrast, "BCP" has worked rather well for identifying those
   documents (although some people still believe that conflating IETF
   process documents with operational best practice ones in the same
   subseries has been a mistake).

   Arguably the main reason those numbering subseries have not been more
   successful is that we have not used them consistently in citations,
   rather than using RFC numbers.  At least part of the problem is that
   our tooling has historically favored use of RFC numbers rather than
   the subseries ones and there has not been good guidance as to when to
   use RFC numbers and when to use the subseries ones, especially when
   the subseries designation refers to more than one document.  It is
   probably worth noting that a document that is a good candidate for

Klensin                 Expires January 14, 2019                [Page 4]

Internet-Draft              RFC Alternatives                   July 2018

   the RFC most-cited by others, RFC 2119, is almost always referred to
   by its RFC number rather than as BCP 14, a situation that is actually
   a source of confusion since BCP 14 now includes the modifications in
   RFC 8174.  The issues of what should be referenced and how, and
   appropriate tooling to reinforce whatever decisions are made, would
   face almost any new system, including qualifying labels, as well.

   A very high-level overview of the proposal is to assign the same
   sorts of labels contemplated in Section 2 and Section 3, but to treat
   them as additional subseries labels rather than suffixes or
   replacements.  All traditional RFC Servies documents would continue
   to receive RFC numbers, building on our experience with STD, BCP, and
   FYI.  As part of that process, the IETF would be required to consider
   whether to apply "STD" to all standards-track documents as
   contemplated by various proposals over the years
   [Klensin-std-numbers] or to invent a separate category, e.g., "PSTD",
   to distinguish between Proposed and Full Standards.

   As with the Qualified Labels proposal, one of the advantages of this
   approach is that we understand how to back away from if it turns out
   to be either problematic or not worth the trouble.  This proposal,
   and both of those above, would commit us to maintaining, long-term,
   effective and working cross-reference tables and collections of links
   to find older documents together with newer ones (even if only to
   resolve citations from documents that are not under the contorl of
   the IETF community).  That would not be a cost-free activity.  Recent
   experience with changes in the organization of the IETF's own web
   pages suggest that we are not (or at least historically have not
   been) good at similar tasks.

5.  Possibility 4: Treat Problem as an Educational One

   This possibility is somewhat different from the preceding two because
   it makes a very different assumption about the problem to be solved.
   The assumption is that most of those who are confused by the current
   arrangements can be plausibly divided into three categories:

   o  Those who have been deliberately confused by others and who do not
      actually read the documents, read only those sections suggested by
      others, or read them very superficially.

   o  Those who read contemporary documents (as distinct from those
      published before the latest revisions of status explanations
      [RFC7841]) with a reasonable amount of care and who are still
      confused about the status or origins of particular documents.

   o  Those who are confused about general relationships in the series
      as distinct from about the status of particular documents.

Klensin                 Expires January 14, 2019                [Page 5]

Internet-Draft              RFC Alternatives                   July 2018

   This author and several others have suggested that the first category
   above is hopeless, first because eliminating deliberate deception
   (especially where lazy, willing, or stupid victims are involved) is
   impossible without changes in human nature.  Second, there is enough
   evidence of sometimes-successful efforts to get people to believe
   that very preliminary, non-WG, Internet Drafts are IETF products or
   standards that it is almost certain that driving the deceivers away
   from the RFC Series would simply cause more of the focus of their
   efforts to shift to Internet Drafts.  It is perhaps worth noting
   that, no matter what we do about labels, as long as every RFC-like
   document and every Internet Draft bears a notice claiming copyright
   for the IETF Trust it will provide a foundation for those who want to
   claim that all of them are IETF products (see Section 6 below).
   Certainly neither of the possibilities above would be likely to
   significantly impede efforts to deliberately confuse people.

   The second category is problematic because there is little evidence
   so far that, with regard to contemporary documents, its membership is
   non-trivial.  The language of the current statements and additional
   hints in document structure appear to be very clear and, according to
   the introductory material in RFC 7841, were adopted precisely to
   address earlier text and arrangements that were less so.  RFC 7841
   was published only a bit over two years ago, some documents in the
   RFC Series that were posted after it (or at least with higher
   numbers) do not appear to support the new requirements, and it is
   likely too early to tell how effective it will be in clarifying
   differences about document origin and levels of consensus.  The need
   for more time to evaluate its success actually cuts both ways -- it
   is possible that the new text and organization got extra attention
   because it was new and that, as people get used to it, it will just
   be skimmed over as more pointless boilerplate.  That might require
   other corrections in the future almost independent of what is done
   with labels or other series identifiers.

   Nonetheless, if the explanations in current RFCs (deriving from RFC
   7841) are inadequate, the correct fix is probably to re-open and
   rethink that document instead of, or possibly in addition to,
   attempting to reorganize the RFC Series or its labels.

   The third category relates primarily to how the RFC Series is
   organized and what documents appear in it.  That appears to be a
   rather different problem from the claimed one that was described in
   the BOF request.  If new labeling models are added to the connection
   handled through the RFC Editor function, copyrighted by the IETF
   Trust, etc., it is quite likely that confusion about different
   sources and status within that collection of documents will increase
   rather than decrease, at least in the short to medium term.  Unless
   we do something far more radical than I believe has been seriously

Klensin                 Expires January 14, 2019                [Page 6]

Internet-Draft              RFC Alternatives                   July 2018

   proposed (see Section 6), the solution to confusion about
   relationships among documents processed by the RFC Editor is more
   likely to lie in better explanatory materials (RFC 4844 [RFC4844] is
   definitely not a tutorial and was not intended to be) and more
   obvious references to them, not, or not just, in tinkering with
   document names.

6.  Possibility 5: The Really Radical Solution

   This proposal is a strawman to help clarify the options.  I believe
   it would be a terrible idea but can imagine that some people would
   disagree.  Certainly there have been suggestions on the mailing list
   that could lead in this direction, but I'm not aware of anyone going
   all the way to this approach as a conclusion.

   The RFC Series was intended, at the beginning, to be a very broad
   collection of notes and thoughts about aspects of the network
   considered very broadly [RFC0003] and evolved considerably over the
   next decade and a half [RFC0825], with IETF documents included after
   the IETF got started a few years later and only later including what
   became known as standards or standards track documents.  Subsequent
   to that, we've explicitly distinguished between types of documents
   (Standards Track, BCP, Informational, Experimental) and then made the
   relationships we call Streams explicit.  We have also spent a lot of
   time and other resources trying to get copyrights and other IPR
   issues associated with the Series just right and, as noted above,
   have made some decisions that may aid those who benefit from
   confusion.  Most of us who have been involved with software and
   protocols for many years know that patching, and adding patches on
   top of patches, eventually turns into a problem of its own.  It may
   still be the right solution to keep doing that, but perhaps it is
   time to ask the question of whether, if we actually have a serious
   problem, the RFC Series, as a series and as an RFC Editor Function
   that serves different streams with at least slightly different
   conventions, priorities, and authority models is reaching the end of
   its useful life or that the community has outgrown it.  If so, rather
   than trying to sort out the best, or least problematic, next patch
   while acknowledging that it will leave problems unsolved, we should
   be thinking through how to retire the "RFC" concept and Series.  That
   would imply putting the IETF Stream (presumably with new names) more
   squarely under the control of the IETF, IESG, and, where relevant,
   the IETF Trust, rather than having a mostly-independent RFC Series
   Editor and RFC Editor Function, and thinking about ways to deal with
   what we have been calling other streams as entirely separate document
   collections with their own (or at least separate from the IETF)
   editorial and publishing arrangements and so on.

Klensin                 Expires January 14, 2019                [Page 7]

Internet-Draft              RFC Alternatives                   July 2018

   As has been pointed out on-list in another context, history would
   strongly suggest that, if we were to move in that direction, the IETF
   should effectively reverse the decisions made years ago, first to
   publish its documents in the RFC Series and then to publish its
   standards there, create its own names, and leave the "RFC" title (and
   whatever was useful of the RFC Editor Function) to the other streams
   if they could agree, but maybe it is too late for that.

   Again, I don't believe that is a good idea.  I believe that sorting
   out a transition and doing a lot of retroactive work, keeping new
   documents properly linked to older ones, or both, would prove
   incredibly painful and costly in terms of community time and,
   specifically, IETF, IAB, RFC Editor, and IASA time and other
   resources.  Almost certainly, there would be a great deal of
   confusion during the transition period, which might be longer than we
   would expect.  However, it is not completely obvious that, for
   example, sorting out all of the issues with the initial proposal made
   for the BOF (as in Section 2 above, in the associated Internet Draft
   [Thomson-RFCplusplus], or other small variations), including those
   with references among documents and actually being ready to
   transition out of the experiment should that prove necessary, would
   be enough less painful and costly that, if giving up on the RFC model
   had enough other potential benefits, it should not be considered as
   an alternative.

7.  Additional Possibilities and Evaluation

   The possibilities listed above are, of course, not exhaustive and
   more ideas may be suggested that are preferable to any of them.  The
   author of this draft would urge that people balance the choices
   against whatever is agreed about the problem to be solved (i.e.,
   whether the proposed solution will really solve or significantly
   mitigate that problem), the costs of making changes and conversions
   (noting that any change involves costs including creating confusion
   for those who are used to the current system), and the risks if any
   changes (whether couched as experiments or not) fail and we have to
   back out of those changes.

8.  Acknowledgements

   Brian Carpenter's analysis of the issues involved in suggested
   changes to the RFC Series and his specific proposal (in Section 3
   above) were essential to motivating this draft and much of its
   content.  Late posting of thise draft would have been impossible
   without Alissa Cooper's agreement, which is greatly appreciated

Klensin                 Expires January 14, 2019                [Page 8]

Internet-Draft              RFC Alternatives                   July 2018

9.  IANA Considerations

   [[CREF1: RFC Editor: Please remove this section before publication.]]

   This memo includes no requests to or actions for IANA However, those
   considering the costs of various possible changes should note that
   changing our document model will likely require some corresponding
   changes for IANA's registries and tools, an update to our IANA
   Considerations model [RFC8126], or other adjustments.

10.  Security Considerations

   -- To be supplied in later iterations if there are any --

11.  Informative References

              klensin, J., "STD Numbers and the IETF Standards Track",
              July 2018, <https://datatracker.ietf.org/doc/

   [RFC0003]  Crocker, S., "Documentation conventions", RFC 3,
              DOI 10.17487/RFC0003, April 1969,

   [RFC0825]  Postel, J., "Request for comments on Requests For
              Comments", RFC 825, DOI 10.17487/RFC0825, November 1982,

   [RFC1311]  Postel, J., "Introduction to the STD Notes", RFC 1311,
              DOI 10.17487/RFC1311, March 1992,

   [RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
              Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995,

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

   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
              "RFC Streams, Headers, and Boilerplates", RFC 7841,
              DOI 10.17487/RFC7841, May 2016,

Klensin                 Expires January 14, 2019                [Page 9]

Internet-Draft              RFC Alternatives                   July 2018

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

              IETF, "Mailing list for the RFC++ BoF",
              email rfcplusplus@ietf.org, July 2018.

              Thomson, M. and M. Shore, "The label "RFC" (RFCplusplus)",
              June 2018, <https://trac.tools.ietf.org/bof/trac/>.

              Thomson, M., "The Label 'RFC'", draft-thomson-rfcplusplus-
              label (work in progress), July 2018,

Author's Address

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com

Klensin                 Expires January 14, 2019               [Page 10]