Principles of the Request for Comments Series
School of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
This document discusses the underlying principles
of the Internet technical community's
Request for Comments document Series.
Introduction
This document was written as background material for ongoing discussions about the role of the Request
for Comments (RFC) Series Editor (the RSE). This version is purely personal opinion, but with some
community comments incorporated. The author welcomes further
comments, best sent to the mailing list rfc-interest@rfc-editor.org if they concern the RFC Series in general,
or to the mailing list rfced-future@iab.org if they concern the role of the RSE specifically.
The RFC Series has a 50 year history, too long to summarise here, so the reader is assumed
to be familiar with . However, the Series does not appear
to have a documented set of principles or a full charter. This will make the obvious first task of the future
RSE -- developing a strategy for the Series -- hard, if not impossible. The goal of this document
is to outline what those principles might be, for community debate. Once the principles are clear,
the next step could be to draft a full charter based on them, also for community debate.
Alternatively, the principles could be incorporated in a revision of .
This document does not aim to provide a problem statement or gap analysis, and technical
matters such as RFC formatting are completely out of scope. Matters concerning the IETF standards
process, and how it uses the Series, are also out of scope. Some problems in the standards
process are problems in how the IETF uses the RFC Series, not problems in the Series itself.
(Interested readers can find comments on that topic in
.)
The document starts with a review of existing background
material that touches on principles of the Series, and then offers a set of proposed principles
for debate.
Background
The RFC Editor web site states the following:
This says little about underlying principles.
Instead, consider the original guidance from the author of the
first RFC:
, Steve Crocker, 7 April 1969.
More recently, Steve wrote this in :
Partly as a result of this starting point, the tradition has always been
that RFCs may be used rather freely, including reproduction
in their entirety and translation into other languages. In more recent years,
the IETF has asserted change control over its own documents, even when
published as RFCs, by virtue of the IETF Trust's legal conditions. This
raises the issue of who owns the copyright. Some RFCs are considered to have been
placed in the public domain as a result of being part of government funded projects. Copyright
in some others presumably belongs to their authors, or to those authors' employers. To the
extent legally possible, the copyright in the RFC Series currently belongs to the IETF
Trust in addition to the authors.
For completeness, note that each RFC stream has its own policy on copyright and change
control issues, not discussed in detail here.
In any case, the question of copyright is not the same as asking
who "owns" the RFC Series in an overall ethical and societal sense.
It is easy to establish who does not own the Series:
- The IETF does not own it, because the Series preceded the IETF by 17 years.
- Therefore the IESG does not own it.
- As noted, the IETF Trust only has limited intellectual property rights
in some (but not all) RFCs.
- At some point in history, both ARPA (who funded the ARPAnet)
and USC/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.
-
ISOC could perhaps make a claim, having funded the Series for many years now.
ISOC has a broad purpose which certainly empowers it to
support the RFC Series, but that does not imply control or ownership.
- The IETF LLC, technically a subsidiary of ISOC, therefore
does not own the Series either, although it does channel the contracts
and money formerly handled directly by ISOC.
-
Finally, the Internet Architecture Board could make a claim based
on its charter , which states that:
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.
A reasonable conclusion from the above is that none of the I* organisations
(IETF Trust, IETF LLC, IETF, IESG, IAB or ISOC) can claim exclusivity of ownership or
control over the RFC Series.
Despite the limited authority granted by its own charter, the IAB
has published various RFCs about the Series as a whole. I quote here from
two in particular.
Firstly, states as follows:
A second document clarifies that RFC Series Editor has considerable
independence (in addition to
the obvious independence of the Independent Series Editor). To quote from
:
Proposed Principles
This section, in particular, needs community review. Some of it is adapted from existing documents.
The RFC Series as a Whole
- The RFC Series is the archival series that documents
Internet technical specifications, descriptions, and commentaries,
including general contributions
from the Internet research and engineering community, as well as
standards documents. It also includes some organisational documents
from the same community.
- "Archival" means that the documents must be available for the
indefinite future in a form that is trusted by
all parties. In particular there must be no doubt as to the precise
original text and diagrams, regardless of the format in which the
documents are stored or displayed. Errors or omissions detected after
publication, and subsequent modifications or extensions of the document
content, do not change the archived document itself.
- All RFCs are available free of charge to anyone via the Internet. They may
be freely translated in their entirety into any language.
- Request for Comments means Request for Comments.
- There is an inherent modesty in calling our documents
"requests for comments". We get things wrong, we want comments, we want errata,
we want operational feedback, and we want to go round that loop again.
This property is a useful counter-balance
to any occurrence of groupthink in the community.
- RFCs come from various streams, i.e. originating organisations.
- Each stream has its own policy on change control, copyright, and
patents, with the IETF Trust generally acting as a repository
for intellectual property rights that are not retained by the authors.
- Each stream has full control of the technical content of its documents.
- The RFC Editor team has control of editorial matters, subject to review by
the relevant stream and the document authors. In particular, a badly written
document may be returned to its stream for improvements if an abnormal amount
of copy-editing is required.
- If an individual member of the RFC Editor team has personal comments
on the technical content of a draft RFC, they must be handled in person,
using the appropriate mechanism of the stream concerned, not as an RFC Editor matter.
- If the RFC Editor team believes that a draft RFC contains a serious technical
flaw, which the stream declines to change, the RFC Editor cannot block the
document indefinitely. Note that there is more discussion of such disagreements in
Section 4.3 of .
- New streams may in principle be created, subject to community agreement
and guidelines to be defined.
- Defunct streams may be closed, subject to community agreement.
- The RFC Series is community property and must operate on behalf of
the community as a whole.
- The exact definition of the relevant community is open for debate. One
definition is: the IETF, the IRTF, the IAB and the many
other people who have contributed to, or made use of, the RFC Series
over the last fifty years. In particular, many users of the RFC series,
ranging for example from junior hardware or software engineers to senior executives
overseeing procurement decisions,
will never participate directly in the IETF or IRTF.
- Major decisions about the future of the RFC Series should be taken by
a rough consensus of this very broad community.
- How to reach out to this community and judge its consensus
is an open question. The mechanism needs to be open to all
interested parties, but with a well-defined process and checks and balances.
Although the community is broader than the IETF, the IETF Working
Group rough consensus process may be the best model.
The RFC Series Editor
- The RFC Series Editor is an independent professional editor, serving a much wider
community than just the IETF. Given the economic and social importance of the
Internet, this is a serious responsibility. Similar roles might be executive leadership
positions at a technical or academic publisher.
Five responsibilities adapted from apply:
- Represents the RFC Series and the RFC Editor function within the
IETF, IRTF and externally.
- Leads the community in the design of improvements to the RFC Series.
- Is responsible for developing vision and policy documents, and
establishing community consensus for them.
- Is responsible for planning and overseeing the execution of improvements
in the RFC Editor production and access processes, in collaboration
with IETF LLC as appropriate.
- Is responsible for the content of the RFC Editor web site,
which is operated and maintained by the RFC Publisher.
- The RFC Series Editor, while paid to serve the community, is a member of the same
professional peer group as IAB members, IESG members, IETF and IRTF group chairs,
and other experienced members of the technical community, each with their own
distinct professional skills.
- The position of RFC Series Editor answers to the community as a whole.
- The grant of authority in the IAB charter should be reviewed in this light.
Conclusion
In summary, the RFC Series exists for the Internet community as a whole, must retain
its independence, openness and autonomy, and must continue to be managed by a senior professional editor.
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.
An assumption in our community is that all actors act in good faith, subject
of course to normal human failures. As far as possible, the RFC Editor regime
needs to be immune to malicious acts of any kind. For that reason, it is important
that appropriate organisational checks and balances are in place.
IANA Considerations
This document makes no request of the IANA.
Acknowledgements
Important comments were received from
Carsten Bormann,
Nevil Brownlee,
Adrian Farrel,
Stephen Farrell,
Joel Halpern,
John Klensin,
Mark Nottingham,
Tommy Pauly,
Eric Rescorla,
Adam Roach,
Mike StJohns,
Martin Thomson,
and others.
References
Change log [RFC Editor: Please remove]
draft-carpenter-rfc-principles-01, 2020-05-18:
- Numerous updates following initial community comments.
draft-carpenter-rfc-principles-00, 2020-05-09:
- Initial version (some content based on draft-carpenter-request-for-comments-01).