Network Working Group J. Klensin Internet-Draft July 13, 2018 Intended status: Informational Expires: January 14, 2019 Alternatives to the RFC++ "Switch Labels" Proposal draft-klensin-rfcplusplus-alternatives-00 Abstract 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 constraints. 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 possibilities. 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 documents 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 reference. 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 solution. Klensin Expires January 14, 2019 [Page 3] Internet-Draft RFC Alternatives July 2018 Examples RFC8200-STD (or RFC8200-STD86) RFC8414-PS RFC5681-DS RFC2026-BCP (or RFC2026-BCP9) RFC7557-EXPT RFC8394-INFO (for IETF informationals) RFC7663-IAB RFC7575-RSCH (for IRTF informationals) RFC8351-INDEP (for Independent informationals) RFC2460-OBS RFC1128-UNK RFC1130-HIST 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-std-numbers] klensin, J., "STD Numbers and the IETF Standards Track", July 2018, . [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, . [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, . [RFCplusplus-list] IETF, "Mailing list for the RFC++ BoF", email rfcplusplus@ietf.org, July 2018. [RFCplusplus-proposal] Thomson, M. and M. Shore, "The label "RFC" (RFCplusplus)", June 2018, . [Thomson-RFCplusplus] 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 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires January 14, 2019 [Page 10]