< draft-carpenter-request-for-comments-00.txt   draft-carpenter-request-for-comments-01.txt >
Network Working Group B. Carpenter Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational June 6, 2018 Intended status: Informational June 20, 2019
Expires: December 8, 2018 Expires: December 22, 2019
Request for Comments Request for Comments
draft-carpenter-request-for-comments-00 draft-carpenter-request-for-comments-01
Abstract Abstract
This document discusses the Internet technical community's common This document discusses the Internet technical community's common
document series. document series and why its independence, and the professional status
of the RFC Series Editor, must be stoutly defended.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2018. This Internet-Draft will expire on December 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. TL;DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. TL;DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problems with the RFC Series . . . . . . . . . . . . . . 2 2. The Problems with the IETF's use of the RFC Series . . . . . 2
3. Who Owns the RFC Series? . . . . . . . . . . . . . . . . . . 3 3. Who Owns the RFC Series? . . . . . . . . . . . . . . . . . . 3
4. Request for Comments means Request for Comments . . . . . . . 5 4. Request for Comments means Request for Comments . . . . . . . 6
5. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. TL;DR 1. TL;DR
"I present here some of the tentative agreements reached and some of "I present here some of the tentative agreements reached and some of
the open questions encountered. Very little of what is here is firm the open questions encountered. Very little of what is here is firm
and reactions are expected." [RFC0001], Steve Crocker, 7 April 1969. and reactions are expected." [RFC0001], Steve Crocker, 7 April 1969.
2. The Problems with the RFC Series 2. The Problems with the IETF's use of the RFC Series
It's very clear that there are problems with the RFC series. For It's very clear that there are problems with the way the IETF uses
example, [RFC0791] is so badly written that it would never pass an the RFC series. For example, [RFC0791] is so badly written that it
IETF working group last call, let alone an IETF last call or an IESG would never pass an IETF working group last call, let alone an IETF
review today. Yet it will be exercised billions of times today and last call or an IESG review today. Although updated by three other
every day. Another example is that a newcomer wishing to implement RFCs and having a dozen errata, it has never been replaced. Yet it
even the simplest mail user agent will not find an RFC telling her will be exercised billions of times today and every day. Another
how to do so. A method to mitigate this problem has been proposed example is that a newcomer wishing to implement even the simplest
but not adopted [I-D.ietf-newtrk-sample-isd]. A related problem is mail user agent will not find an RFC telling her how to do so. A
that finding the latest version of a standard requires arcane method to mitigate this problem was proposed but not adopted
knowledge; for example, someone looking for the latest IPv6 standard [I-D.ietf-newtrk-sample-isd]. A related problem is that finding the
via the popular search tools is more than likely to end up consulting latest version of a standard requires arcane knowledge; for example,
the obsolete RFC2460. (The IETF web site's search tool returns no someone looking for the latest IPv6 standard via the popular search
results for "IPv6 standard".) tools is still quite likely to end up consulting RFC2460, although it
was obsoleted almost two years ago. Another example is the frequency
of references to RFC2616 for HTTP, obsoleted in 2014.
A major gripe about the RFC series is its limitation to ASCII and its A major gripe about the RFC series is its limitation to ASCII and its
reliance on typewriter-friendly formatting. Fortunately this is reliance on typewriter-friendly formatting and its lack of good
being worked on actively, so is not further discussed here. diagrams. Fortunately this is being worked on actively, so is not
further discussed here.
An occasional annoyance is that since the RFC series is long An occasional annoyance is that since the RFC series is long
established and serves a very wide community of authors, it includes established and serves a very wide community of authors, it includes
only some documents that are formally agreed statements of IETF rough only some documents that are formally agreed statements of IETF rough
consensus and even fewer that are formally agreed statements of IETF consensus and even fewer that are formally agreed statements of IETF
rough consensus about proposed standards or best current practice. rough consensus about proposed standards or best current practice.
The IETF has preferred to maintain a distinction between proposed The IETF has preferred to maintain a distinction between proposed
standards and Internet standards, which means that there are even standards and Internet standards, which means that there are even
fewer RFCs designated as Internet standards. An attempt to fix that fewer RFCs designated as Internet standards. An attempt to fix that
particular problem by reducing the number and hence complexity of the particular problem by reducing the number and hence complexity of the
categories [RFC6410] has not appeared to make significant categories [RFC6410] has not appeared to make significant
improvements in either the confusion or the ratio of Internet improvements in either the confusion or the ratio of Internet
Standards to Proposed ones. Efforts to reduce the distinction and Standards to Proposed ones. Efforts to reduce the distinction and
provide stable references to at least the current versions of updated provide stable references to at least the current versions of updated
standards (e.g., [I-D.klensin-std-numbers]) have received little standards (e.g., [I-D.klensin-std-numbers]) have received little
interest. interest. A proposal that reached IETF Working Group consensus to
publish a new form of document summarising the status of particular
complex standards [I-D.ietf-newtrk-repurposing-isd] did not satisfy
the IESG and was not advanced.
This problem area has been well known for many years [RFC1796] and This problem area has been well known for many years [RFC1796] and
has occasionally led to concern that some vendors might mislead has occasionally led to concern that some vendors might mislead
customers by claiming conformance with a non-standard RFC. For this customers by claiming conformance with a non-standard RFC. For this
reason, the header text on RFCs was clarified some years ago such reason, the header text on RFCs was clarified some years ago such
that readers can clearly distinguish standards from non-standards. that readers can clearly distinguish standards from non-standards.
The original version of this was "This memo provides information for The original version of this was "This memo provides information for
the Internet community. This memo does not specify an Internet the Internet community. This memo does not specify an Internet
standard of any kind." and has been used (with occasional updates to standard of any kind." and has been used (with occasional updates to
the wording) since 1994, well before [RFC1796] was published. the wording) since 1994, well before [RFC1796] was published.
skipping to change at page 3, line 32 skipping to change at page 3, line 39
There is therefore no lack of clarity, and has been none since 1994, There is therefore no lack of clarity, and has been none since 1994,
about which RFCs are normative statements of consensus and which are about which RFCs are normative statements of consensus and which are
not. Certainly, some readers will bypass the header text as "TL;DR" 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 (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 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 the new RFC format, it would be possible and perhaps desirable to use
special typography to emphasise the document status, but it doesn't special typography to emphasise the document status, but it doesn't
solve the underlying problem of human behaviour, because nothing solve the underlying problem of human behaviour, because nothing
can.) can.)
I conclude that this set of problems is really nothing to do with the
RFC series as a publication venue and nothing to do with the format
of RFCs. It is entirely the result of the IETF's standards process;
if the IETF wants it fixed, it must look inwards at that process, and
not outwards at the community's open publication process.
3. Who Owns the RFC Series? 3. Who Owns the RFC Series?
I am not asking this question in a legal sense. The copyright in the I am not asking this question in a legal sense. To the extent
RFC series currently belongs to the IETF Trust in addition to the legally possible, the copyright in the RFC series currently belongs
authors, but the Trust's purposes are broad: 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 "Such purposes include, but are not limited to, the advancement
of education and public interest by acquiring, holding, of education and public interest by acquiring, holding,
maintaining and licensing certain existing and future maintaining and licensing certain existing and future
intellectual property and other property used in connection intellectual property and other property used in connection
with the Internet standards process and its administration, for with the Internet standards process and its administration, for
the advancement of the science and technology associated with the advancement of the science and technology associated with
the Internet and related technology." the Internet and related technology."
(IETF Trust Agreement, 2005) (IETF Trust Agreement, 2005)
skipping to change at page 4, line 36 skipping to change at page 5, line 5
at large concerning the technology, use and application of the at large concerning the technology, use and application of the
Internet; Internet;
3. To promote educational applications of Internet technology 3. To promote educational applications of Internet technology
for the benefit of government, colleges and universities, for the benefit of government, colleges and universities,
industry, and the public at large; industry, and the public at large;
4. To provide a forum for exploration of new Internet 4. To provide a forum for exploration of new Internet
applications, and to stimulate collaboration among organizations applications, and to stimulate collaboration among organizations
in their operational use of the global Internet." in their operational use of the global Internet."
(Articles of Incorporation of the Internet Society) (Articles of Incorporation of the Internet Society)
5. Finally, the Internet Architecture Board could make a claim based 5. The recently formed IETF LLC certainly doesn't own the series,
although it does channel the contracts and money formerly handled
directly by ISOC.
6. Finally, the Internet Architecture Board could make a claim based
on its charter [RFC2850], which states that: on its charter [RFC2850], which states that:
"The RFC series constitutes the archival publication channel "The RFC series constitutes the archival publication channel
for Internet Standards and for other contributions by the for Internet Standards and for other contributions by the
Internet research and engineering community. RFCs are available Internet research and engineering community. RFCs are available
free of charge to anyone via the Internet. The IAB must approve free of charge to anyone via the Internet. The IAB must approve
the appointment of an organization to act as RFC Editor and the the appointment of an organization to act as RFC Editor and the
general policy followed by the RFC Editor." general policy followed by the RFC Editor."
This text makes it clear that the RFC series is much broader in 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 scope than the IETF, and limits the IAB's authority to matters of
general policy. general policy.
The reasonable conclusion from the above is that none of the I* The reasonable conclusion from the above is that none of the I*
organisations (IETF Trust, IETF, IESG, IAB or ISOC) can claim organisations (IETF Trust, IETF LLC, IETF, IESG, IAB or ISOC) can
exclusivity of ownership or control over the RFC series. It is claim exclusivity of ownership or control over the RFC series. It is
community property. community property and must operate on behalf of the community as a
whole.
An important consequence is that major decisions about the future of A first important consequence is that major decisions about the
the RFC Series must be taken by a consensus of a very broad 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 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 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 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. reach out to this community is in itself a big question.
4. Request for Comments means Request for Comments A second important consequence is that the position of RFC Series
Editor answers to the community as a whole, not narrowly to the IAB.
In particular the RFC Series Editor has considerable independence (in
addition to the obvious independence of the Independent Series
Editor). To quote from [RFC6635]:
Politicians make such absurd statements, so I reckon I can too. "The RFC Series Editor will exercise
strategic leadership and management over the activities of the RFC
Publisher and the RFC Production Center... [and]
There is an inherent modesty in calling IETF consensus documents o Represents the RFC Series and the RFC Editor Function within the
"requests for comments". As the above quotation from RFC1 said right IETF and externally.
at the beginning, we get things wrong. We want comments, we want
errata, we want operational feedback, and we want to go round that o Leads the community in the design of improvements to the RFC
loop again each time we update a standard. When we forget that, we Series.
are getting dangerously close to arrogance and hubris.
o Is responsible for planning and seeing to the execution of
improvements in the RFC Editor production and access processes.
o Is responsible for the content of the rfc-editor.org web site,
which is operated and maintained by the RFC Publisher.
o Is responsible for developing consensus versions of vision and
policy documents."
In other words, the RFC Series Editor must be a highly respected
independent professional editor, not acting under orders, and serving
a much wider community than just the IETF. Given the economic and
social importance of the Internet, this is a very serious
responsibility, comparable to the editorship of a major newspaper of
record.
The community was very fortunate that the progenitors of the RFC
Editor function, in particular but not exclusively Steve Crocker, Jon
Postel, Joyce Reynolds and Bob Braden [I-D.flanagan-fiftyyears], were
modest and wise enough to know their own limitations, to learn about
professional editing as they went along, and to remain open and
sensitive to the needs of the whole Internet technical community.
When it eventually came time to appoint a professional series editor,
this proved very hard and fundamentally different from either
recruiting for technical leadership positions
[I-D.carpenter-community-leaders] or for administrative or
operational needs. Indeed the RFC Series Editor has always been, and
must remain, a member of the same peer group as IAB members, IESG
members, IETF and IRTF group chairs, and indeed participants in
general, each with their own professional skills.
4. Request for Comments means Request for Comments
There is an inherent modesty in calling our 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 specification. 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 Avoiding this trap is indeed the reason that the community has always
published a number of RFCs that are not the product of organised published a number of RFCs that are not the product of organised
groups, formalised some years ago as the Independent Stream of RFCs groups, formalised some years ago as the Independent Stream of RFCs
[RFC4844]. Whether they document deployed solutions not invented in [RFC4844]. Whether they document deployed solutions not invented in
the IETF, or alternative solutions not accepted by the IETF, or the IETF, or alternative solutions not accepted by the IETF, or
informed technical opinions not discussed in the IETF, they remain informed technical opinions not discussed in the IETF, they remain
part of the broader community's open record, and a useful counter- part of the broader community's open record, and a useful counter-
balance to any occurrence of groupthink in the IETF, IRTF or IAB. balance to any occurrence of groupthink in the IETF, IRTF or IAB.
skipping to change at page 6, line 13 skipping to change at page 7, line 41
been reasonably successful. been reasonably successful.
The next planned experiment is the major upgrade of RFC formatting, The next planned experiment is the major upgrade of RFC formatting,
which will inevitably cause some disturbance to the document which will inevitably cause some disturbance to the document
production process when it goes live. production process when it goes live.
A full analysis of these various experiments, their goals, and their A full analysis of these various experiments, their goals, and their
successes and failures, seems necessary before designing any future successes and failures, seems necessary before designing any future
experiment in the area of document series. experiment in the area of document series.
6. Security Considerations 6. Conclusion
The IETF has not made a serious attempt to fix known major bugs in
its standards publication process in the last 15 years. These are
not bugs in the RFC Series but in the way the IETF uses the Series.
The RFC Series exists for the Internet community as a whole, must
retain its independence and autonomy, and must continue to be managed
by a senior professional editor.
7. Security Considerations
Security issues are discussed in all recent RFCs. This uniformity Security issues are discussed in all recent RFCs. This uniformity
illustrates the coherence of the RFC series and the way it has been 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 used to ensure a degree of order in the chaotic world of Internet
design, implementation and deployment. design, implementation and deployment.
7. IANA Considerations 8. IANA Considerations
This document makes no request of the IANA. Like the RFC series, the 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 IANA is a service provided for the benefit of the entire Internet
technical community in a coherent and consistent way. technical community in a coherent and consistent way.
8. Acknowledgements 9. Acknowledgements
Useful comments were received from John Klensin, ... Useful comments were received from various sources, but this document
is very much a personal statement.
9. Informative References 10. References
[I-D.carpenter-community-leaders]
Carpenter, B., "Some Thoughts on IETF Community
Leadership", draft-carpenter-community-leaders-01 (work in
progress), June 2019.
[I-D.flanagan-fiftyyears]
Flanagan, H., "Fifty Years of RFCs", draft-flanagan-
fiftyyears-07 (work in progress), June 2019.
[I-D.ietf-newtrk-repurposing-isd]
Klensin, J. and J. Loughney, "Internet Standards
Documentation (ISDs)", draft-ietf-newtrk-repurposing-
isd-04 (work in progress), March 2006.
[I-D.ietf-newtrk-sample-isd] [I-D.ietf-newtrk-sample-isd]
Klensin, J., "Internet Standards Documentation (ISDs) - Klensin, J., "Internet Standards Documentation (ISDs) -
Examples", draft-ietf-newtrk-sample-isd-00 (work in Examples", draft-ietf-newtrk-sample-isd-00 (work in
progress), October 2004. progress), October 2004.
[I-D.klensin-std-numbers] [I-D.klensin-std-numbers]
Klensin, J., "STD Numbers and the IETF Standards Track", Klensin, J., "STD Numbers and the IETF Standards Track",
draft-klensin-std-numbers-01 (work in progress), February draft-klensin-std-numbers-02 (work in progress), July
2011. 2018.
[RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001,
April 1969, <https://www.rfc-editor.org/info/rfc1>. April 1969, <https://www.rfc-editor.org/info/rfc1>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995, Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995,
skipping to change at page 7, line 23 skipping to change at page 9, line 31
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <https://www.rfc-editor.org/info/rfc4844>. July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410, Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
DOI 10.17487/RFC6410, October 2011, DOI 10.17487/RFC6410, October 2011,
<https://www.rfc-editor.org/info/rfc6410>. <https://www.rfc-editor.org/info/rfc6410>.
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
2012, <https://www.rfc-editor.org/info/rfc6635>.
Appendix A. Change log [RFC Editor: Please remove] Appendix A. Change log [RFC Editor: Please remove]
draft-carpenter-request-for-comments-00, 2018-06-06: draft-carpenter-request-for-comments-00, 2018-06-06:
Initial version Initial version
Author's Address draft-carpenter-request-for-comments-01, 2019-06-20:
Updated and extended.
Author's Address
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 28 change blocks. 
57 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/