Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland
Intended status: Informational June 6, 2018
Expires: December 8, 2018
Request for Comments
draft-carpenter-request-for-comments-00
Abstract
This document discusses the Internet technical community's common
document series.
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 8, 2018.
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.
Carpenter Expires December 8, 2018 [Page 1]
Internet-Draft Request for Comments June 2018
Table of Contents
1. TL;DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problems with the RFC Series . . . . . . . . . . . . . . 2
3. Who Owns the RFC Series? . . . . . . . . . . . . . . . . . . 3
4. Request for Comments means Request for Comments . . . . . . . 5
5. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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 RFC Series
It's very clear that there are problems with 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. 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 has been 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 more than likely to end up consulting
the obsolete RFC2460. (The IETF web site's search tool returns no
results for "IPv6 standard".)
A major gripe about the RFC series is its limitation to ASCII and its
reliance on typewriter-friendly formatting. 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
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
Carpenter Expires December 8, 2018 [Page 2]
Internet-Draft Request for Comments June 2018
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.
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.)
3. Who Owns the RFC Series?
I am not asking this question in a legal sense. The copyright in the
RFC series currently belongs to the IETF Trust in addition to the
authors, but the Trust's purposes are broad:
"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?
Carpenter Expires December 8, 2018 [Page 3]
Internet-Draft Request for Comments June 2018
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)
5. 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, IESG, IAB or ISOC) can claim
Carpenter Expires December 8, 2018 [Page 4]
Internet-Draft Request for Comments June 2018
exclusivity of ownership or control over the RFC series. It is
community property.
An 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.
4. Request for Comments means Request for Comments
Politicians make such absurd statements, so I reckon I can too.
There is an inherent modesty in calling IETF consensus 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 each time we update a standard. 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.
Carpenter Expires December 8, 2018 [Page 5]
Internet-Draft Request for Comments June 2018
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. 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.
7. 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.
8. Acknowledgements
Useful comments were received from John Klensin, ...
9. Informative References
[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-01 (work in progress), February
2011.
[RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001,
April 1969, <https://www.rfc-editor.org/info/rfc1>.
[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>.
Carpenter Expires December 8, 2018 [Page 6]
Internet-Draft Request for Comments June 2018
[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>.
Appendix A. Change log [RFC Editor: Please remove]
draft-carpenter-request-for-comments-00, 2018-06-06:
Initial version
Author's Address
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Carpenter Expires December 8, 2018 [Page 7]