Internet DRAFT - draft-klensin-rfcplusplus-alternatives
draft-klensin-rfcplusplus-alternatives
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, <https://datatracker.ietf.org/doc/
draft-klensin-std-numbers>.
[RFC0003] Crocker, S., "Documentation conventions", RFC 3,
DOI 10.17487/RFC0003, April 1969,
<https://www.rfc-editor.org/info/rfc3>.
[RFC0825] Postel, J., "Request for comments on Requests For
Comments", RFC 825, DOI 10.17487/RFC0825, November 1982,
<https://www.rfc-editor.org/info/rfc825>.
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
DOI 10.17487/RFC1311, March 1992,
<https://www.rfc-editor.org/info/rfc1311>.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc7841>.
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,
<https://www.rfc-editor.org/info/rfc8126>.
[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, <https://trac.tools.ietf.org/bof/trac/>.
[Thomson-RFCplusplus]
Thomson, M., "The Label 'RFC'", draft-thomson-rfcplusplus-
label (work in progress), July 2018,
<https://datatracker.ietf.org/doc/
draft-thomson-rfcplusplus-label/>.
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]
