Internet DRAFT - draft-iab-fiftyyears
draft-iab-fiftyyears
Network Working Group H. Flanagan, Ed.
Internet-Draft RFC Editor
Updates2555, 5540 (if approved) August 9, 2019
Intended status: Informational
Expires: February 10, 2020
Fifty Years of RFCs
draft-iab-fiftyyears-01
Abstract
This RFC marks the fiftieth anniversary for the RFC Series. It
includes both retrospective material from individuals involved at key
inflection points, as well as a review of the current state of
affairs. It concludes with thoughts on possibilities for the next
fifty years for the Series. This document updates the perspectives
offered in RFCs 2555 and 5540.
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 February 10, 2020.
Copyright Notice
Copyright (c) 2019 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
Flanagan Expires February 10, 2020 [Page 1]
Internet-Draft Fifty Years of RFCs August 2019
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
2. Key Moments in RFC History . . . . . . . . . . . . . . . . . 4
3. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Origins of RFCs - by Stephen D. Crocker . . . . . . 6
3.2. The RFC Management and Editing Team - Vint Cerf . . . . . 11
3.3. Formalizing the RFC Editor Model - Leslie Daigle . . . . 11
3.4. The Continuation, or Creation, of a Stream - Nevil
Brownlee . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. A View from Inside the RFC Editor - Sandy Ginoza . . . . 16
4. The Next Fifty Years of RFCs . . . . . . . . . . . . . . . . 20
4.1. Preservation . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Evolution of the RFC Format . . . . . . . . . . . . . . . 20
4.3. Stream Structure . . . . . . . . . . . . . . . . . . . . 21
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Informative References . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The RFC Series began in April 1969 with the publication of "Host
Software" by Steve Crocker. The early RFCs were, in fact, requests
for comments on ideas and proposals; the goal was to start
conversations, rather than to create an archival record of a standard
or best practice. This goal changed over time, as the formality of
the publication process evolved, and the community consuming the
material grew. Today, over 8500 RFCs have been published, ranging
across best practice information, experimental protocols,
informational material, and, of course, Internet standards. Material
is accepted for publication through the IETF, the IAB, the IRTF, and
the Independent Submissions stream, each with clear processes on how
drafts are submitted and potentially approved for publication as an
RFC. Ultimately, the goal of the RFC Series is to provide a
canonical source for the material published by the RFC Editor, and to
support the preservation of that material in perpetuity.
The RFC Editor as a role came a few years after the first RFC was
published. The actual date when the term was first used is unknown,
but it was formalized by [RFC0902] in July 1984; Jon Postel, the
first RFC Editor, defined the role by his actions and later by
Flanagan Expires February 10, 2020 [Page 2]
Internet-Draft Fifty Years of RFCs August 2019
defining the initial processes surrounding the publication of RFCs.
What is certain is that the RFC Editor is responsible for making sure
that the editorial quality of the RFCs published is high, and that
the archival record of what has been published is maintained.
Change does come to the Series, albeit slowly. First, we saw the
distribution method change from postal mail to FTP and email. RFCs
could not be distributed electronically from the beginning, as the
means to do that distribution would not be defined until years after
the first RFC was published. Not all early RFCs were even created
electronically; some were written out by hand, or on a typewriter.
Eventually the process for creating RFCs became more structured;
authors were provided guidance on how to write an RFC. The editorial
staff went from one person, Jon Postel, to a team of five to seven.
The actual editing and publishing work split from the service for
registration of protocol code points. The whole RFC Editor structure
was reviewed [RFC4844] and refined [RFC5620] and refined again
[RFC6635]. And, in the last few years, we have started the process
to change the format of the RFC documents themselves.
This is evolution, and the Series will continue to adapt in order to
meet the needs and expectations of the community of authors,
operators, historians, and users of the RFC Series. These changes
will be always be balanced against the core mission of the Series: to
maintain a strong, stable, archival record of technical
specifications, protocols, and other information relevant to the
ARPANET and Internet networking communities.
There is more to the history of the RFC Series than can be covered in
this document. Readers interested in earlier perspectives may find
the following RFCs of particular interest that focus on the enormous
contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and
first RFC Editor:
[RFC2441]"Working with Jon, Tribute delivered at UCLA"
[RFC2555]"30 Years of RFCs"
[RFC5540]"40 Years of RFCs"
In this document, the history of the series is viewed through the
eyes of several individuals who have been a part of shaping the
Series. Narratives of this nature offer a limited perspective on
events; there are almost certainly other viewpoints, memories, and
perspective on events that are equally valid and would reflect a
different history. So, while these retrospectives are enormously
valuable and provide an insight to events of the day, they are just
one lens on the history of the RFC Series.
Flanagan Expires February 10, 2020 [Page 3]
Internet-Draft Fifty Years of RFCs August 2019
Steve Crocker, author of RFC 1, offers his thoughts on how and why
the Series began. Leslie Daigle, a major influence in the
development of the RFC Editor model, offers her thoughts on the
change of the RFC Editor to a stronger, contracted function. Nevil
Brownlee, Independent Submissions Editor from 2010 through February
2018, shares his view on the clarification of the IS and its
transition from Bob Braden. As the current RFC Series Editor, I will
put my thoughts in on the most recent changes in formalizing the
digital preservation of the Series, the process to modernize the
format while respecting the need for stability, and my thoughts on
the next fifty years of RFCs.
This document updates the perspectives offered in RFCs 2555 and 5540.
2. Key Moments in RFC History
+--------------------+-----------+---------------------------------+
| Marker | Date | Event |
+====================+===========+=================================+
| [RFC0001] | 1969 | First RFC published |
+--------------------+-----------+---------------------------------+
| [RFC0114] | 1971 | First distribution of RFCs over |
| | | the network |
+--------------------+-----------+---------------------------------+
| [RFC0433] | December | First mention of the Czar of |
| | 1972 | Socket Numbers and the proposal |
| | | for a formal registry |
+--------------------+-----------+---------------------------------+
| [RFC0690] | June 1975 | Relationship starts between ISI |
| | | and the RFC Editor, judging by |
| | | Jon Postel's affiliation change |
+--------------------+-----------+---------------------------------+
| [RFC0748] | March | First April 1st RFC |
| | 1977 | |
+--------------------+-----------+---------------------------------+
| [IETF1] | January | First Internet Engineering Task |
| | 1986 | Force (IETF) meeting |
+--------------------+-----------+---------------------------------+
| [RFC1083] | October | Three stage standards process |
| | 1989 | first defined |
+--------------------+-----------+---------------------------------+
| [RFC1122][RFC1123] | December | First major effort to review |
| | 1988 | key specifications and write |
| | | applicability statements |
+--------------------+-----------+---------------------------------+
| [RFC1150] | March | FYI sub-series started |
| | 1990 | |
+--------------------+-----------+---------------------------------+
Flanagan Expires February 10, 2020 [Page 4]
Internet-Draft Fifty Years of RFCs August 2019
| [RFC1311] | March | STD sub-series started |
| | 1992 | |
+--------------------+-----------+---------------------------------+
| [RFC1818] | August | BCP sub-series started |
| | 1995 | |
+--------------------+-----------+---------------------------------+
| [RFC-ONLINE] | (approx) | RFC Online Project to restore |
| | 1998-2010 | lost early RFCs |
+--------------------+-----------+---------------------------------+
| [IAB-19880712] | July 1988 | IAB approved the creation of an |
| | | Internet Draft series |
+--------------------+-----------+---------------------------------+
| [RFC2441] | 15 | Jon Postel's death |
| | October | |
| | 1998 | |
+--------------------+-----------+---------------------------------+
| [ISI-to-AMS] | October | Transition starts from ISI to |
| | 2009 | Association Management |
| | | Solutions (AMS) |
+--------------------+-----------+---------------------------------+
| [RFC4844] | July 2007 | RFC Stream structure |
+--------------------+-----------+---------------------------------+
| [RFC4846] | July 2007 | Formalize the Independent |
| | | Submission document stream |
+--------------------+-----------+---------------------------------+
| [RFC5743] | December | Formalize the Internet Research |
| | 2009 | Task Force document stream |
+--------------------+-----------+---------------------------------+
| [RFC6360] | August | FYI sub-series ended |
| | 2011 | |
+--------------------+-----------+---------------------------------+
| [RFC6410] | October | Two stage standards process |
| | 2011 | formalized |
+--------------------+-----------+---------------------------------+
| [RFC6949] | May 2013 | RFC Format change project |
| | | started |
+--------------------+-----------+---------------------------------+
| [RFC8153] | April | RFCs no longer printed to paper |
| | 2017 | upon publication |
+--------------------+-----------+---------------------------------+
Table 1: Key Moments in RFC History
3. Perspectives
Flanagan Expires February 10, 2020 [Page 5]
Internet-Draft Fifty Years of RFCs August 2019
3.1. The Origins of RFCs - by Stephen D. Crocker
[This is a revision of material included in [RFC1000] August 1987,
more than thirty years ago.]
The Internet community now includes millions of nodes and billions of
users. It owes its beginning to the ARPANET, which was once but a
gleam in the eyes of J. C. R. Licklider, Bob Taylor, and Larry
Roberts of ARPA. While much of the development proceeded according
to plan, the initial design of the protocols and the creation of the
RFCs was largely accidental.
The procurement of the ARPANET was initiated in the summer of 1968
--remember Vietnam, flower children, etc.? There had been prior
experiments at various ARPA sites to link together computer systems,
but this was the first version to explore packet-switching as a core
part of the communication strategy. ("ARPA" didn't become "DARPA"
until 1972. It briefly changed back to ARPA in 1993 and then back
again to DARPA.) The government's Request for Quotations (RFQ)
called for four packet-switching devices, called Interface Message
Processors ("IMPs"), to be delivered to four sites in the western
part of the United States: University of California, Los Angeles
(UCLA); SRI International in Menlo Park, CA; University of
California, Santa Barbara; the University of Utah in Salt Lake City.
These sites, respectively, were running a Scientific Data Systems
(SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10. These
machines not only had different operating systems, but even details
like character sets and byte sizes varied, and other sites would have
further variations.
The focus was on the basic movement of data. The precise use of the
ARPANET was not spelled out in advance, thus requiring the research
community to take some initiative. To stimulate this process, a
meeting was called in August 1968 with representatives from the
selected sites, chaired by Elmer Shapiro from SRI. Based on
Shapiro's notes from that meeting, the attendees were Dave Hopper and
Jeff Rulifson from SRI, Glen Culler and Gordon Buck from Santa
Barbara, R. Stephenson, C. Stephen Carr and W. Boam from Utah,
Vint Cerf and me from UCLA, and a few others from potential future
sites.
That first meeting was seminal. We had lots of questions. How IMPs
and "hosts" (I think that was the first time I was exposed to that
term) would be connected? What would hosts say to each other? What
applications would be supported? The only concrete answers were
remote login as a replacement for dial-up, telephone based
interactive terminal access, and file transfer, but we knew the
vision had to be larger. We found ourselves imagining all kinds of
Flanagan Expires February 10, 2020 [Page 6]
Internet-Draft Fifty Years of RFCs August 2019
possibilities -- interactive graphics, cooperating processes,
automatic data base query, electronic mail -- but no one knew where
to begin. We weren't sure whether there was really room to think
hard about these problems; surely someone senior and in charge,
likely from the East, would be along by and by to bring the word.
But we did come to one conclusion: we ought to meet again. Over the
next several months, we met at each of our sites, thereby setting the
precedent for regular face to face meetings. We also instantly felt
the irony. This new network was supposed to make it possible to work
together at a distance, and the first thing we did was schedule a
significant amount of travel.
Over the next several months, a small, fairly consistent set of
graduate students and staff members from the first four sites met.
We used the term Network Working Group (NWG) to designate ourselves.
This was the same term Elmer Shapiro had used when he convened our
first meeting, although it had been used until that point to refer to
the principal investigators and ARPA personnel -- senior people who
had been planning the network. Our group was junior and disjoint
from the prior group, except, of course, that each of us worked for
one of the principal investigators.
The first few meetings were quite tenuous, primarily because we
weren't sure how narrow or expansive our goals should be. We had no
official charter or leadership, and it remained unclear, at least to
me, whether someone or some group would show up with the official
authority and responsibility to take over the problems we were
dealing with. Without clear definition of what the host-IMP
interface would look like, or even a precise definition of what
functions the IMP would provide, we focused on broader ideas. We
envisioned the possibility of application specific protocols, with
code downloaded to user sites, and we took a crack at designing a
language to support this. The first version was known as DEL, for
"Decode-Encode Language" and a later version was called NIL, for
"Network Interchange Language."
In late 1968 Bolt Beranek and Newman (BBN) in Cambridge, MA won the
contract for the IMPs and began work in January 1969. A few of us
flew to Boston in the middle of February to meet the BBN crew. The
BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein,
Ben Barker, Will Crowther, Bernie Cosell and Dave Walden. They were
organized, professional and focused. Their first concern was how to
meet their contract schedule of delivering the first IMP to UCLA at
the beginning of September and how to get bits to flow quickly and
reliably. The details of the host-IMP interface were not yet firm;
the specification came a few months later as BBN Report 1822. In
particular, BBN didn't take over our protocol design process, nor did
Flanagan Expires February 10, 2020 [Page 7]
Internet-Draft Fifty Years of RFCs August 2019
any other source of authority appear. Thus, we doggedly continued
debating and designing the protocols.
A month later our small NWG met in Utah. As the meeting came toward
an end, it became clear to us that we should start writing down our
discussions. We had accumulated a few notes on the design of DEL and
other matters, and we decided to put them together in a set of notes.
We assigned writing chores to each of us, and I took on the
additional task of organizing the notes. Though I initiated the
RFCs, my role was far less than an editor. Each of the RFCs were
numbered in sequence. The only rule I imposed was the note had to be
complete before I assigned a number because I wanted to minimize the
number of holes in the sequence.
I tried a couple of times to write a note on how the notes would be
organized, but I found myself full of trepidation. Would these notes
look as if we were asserting authority we didn't have? Would we
unintentionally offend whomever the official protocol designers were?
Finally, unable to sleep, I wrote the a few humble words. The basic
ground rules were that anyone could say anything and that nothing was
official. And to emphasize the point, I used Bill Duvall's
suggestion and labeled the notes "Request for Comments." I never
dreamed these notes would eventually be distributed through the very
medium we were discussing in these notes. Talk about Sorcerer's
Apprentice!
After BBN distributed the specification for the hardware and software
interface to the IMPs to the initial ARPANET sites, our attention
shifted to low-level matters. The ambitious ideas for automatic
downloading of code evaporated. It would be several years before
ideas like mobile code, remote procedure calls, ActiveX, JAVA and
RESTful interfaces appeared.
Over the spring and summer of that year we grappled with the detailed
problems of protocol design. Although we had a vision of the vast
potential for intercomputer communication, designing usable protocols
was another matter. We knew a custom hardware interface and a custom
software addition in the operating system was going to be required
for anything we designed, and we anticipated these would pose some
difficulty at each of the sites. We looked for existing abstractions
to use. It would have been convenient if we could have made the
network simply look like a regular device, e.g., a tape drive, but we
knew that wouldn't do. The essence of this network was peer-to-peer
cooperation among the machines and the processes running inside them,
not a central machine controlling dependent devices. We settled on a
virtual bit stream layer as the basic building block for the
protocols, but even back then we knew that some applications like
voice might need to avoid that layer of software. (Why a virtual bit
Flanagan Expires February 10, 2020 [Page 8]
Internet-Draft Fifty Years of RFCs August 2019
stream instead of a virtual byte stream? Because each computer had
its own notion of how many bits were in a byte. Eight-bit bytes
didn't become standard until a few years later.)
Over the next two years, we developed, exchanged, and implemented
ideas. I took a leave from UCLA in June 1971 to spend time working
at ARPA. Jon Postel took over the care and feeding of the RFCs,
evolving the process and adding collaborators over the next twenty-
seven years.
The rapid growth of the network and the working group also led to a
large pile of RFCs. When the 100th RFC was in sight, Peggy Karp at
MITRE took on the task of indexing them. That seemed like a large
task then, and we could have hardly anticipated seeing more than a
1000 RFCs several years later, and the evolution toward Internet
Drafts yet later.
When we first started working on the protocols, the network did not
exist. Except for our occasional face-to-face meetings, RFCs were
our only means of communication. In [RFC0003], I set the bar as low
as possible:
The content of a NWG note may be any thought, suggestion, etc.
related to the HOST software or other aspect of the network.
Notes are encouraged to be timely rather than polished.
Philosophical positions without examples or other specifics,
specific suggestions or implementation techniques without
introductory or background explication, and explicit questions
without any attempted answers are all acceptable. The minimum
length for a NWG note is one sentence.
These standards (or lack of them) are stated explicitly for two
reasons. First, there is a tendency to view a written statement
as ipso facto authoritative, and we hope to promote the exchange
and discussion of considerably less than authoritative ideas.
Second, there is a natural hesitancy to publish something
unpolished, and we hope to ease this inhibition.
Making the RFCs informal was not only a way of encouraging
participation; it was also important in making the communication
effective. One of the early participants said he was having trouble
writing and sending an RFC because his institution wanted to subject
them to publication review. These are not "publications," I
declared, and the problem went away. Another small detail, handled
instinctively and without debate, was the distribution model. Each
institution was required to send a copy directly to each of the other
handful of participating institutions. Each institution handled
internal copies and distribution itself. Submission to a central
Flanagan Expires February 10, 2020 [Page 9]
Internet-Draft Fifty Years of RFCs August 2019
point for redistribution was not required, so as to minimize delays.
SRI's Network Information Center, however, did maintain a central
repository of everything and provided an invaluable record.
We didn't intentionally set out to challenge the existing standards
organizations, but our natural mode of operation yielded some
striking results. The RFCs are open in two important respects:
anyone can write one for free and anyone get them for free. At the
time, virtually everyone in the ARPANET community was sponsored by
the government, so there was little competition and no need to use
documents as a way of raising money. Of course, as soon as we had
email working on the ARPANET, we distributed RFCs electronically.
When the ARPANET became just a portion of the Internet, this
distribution process became worldwide. The effect of this openness
is often overlooked. Students and young professionals all over the
world have been able to download the RFCs, learn about the many
pieces of technology, and then build the most amazing software. And
they still are. [They are also a fantastic resource for historians.]
Where will it end? The ARPANET begat the Internet and the underlying
technology transitioned from the original host-host protocol to TCP/
IP, but the superstructure of protocol layers, community driven
protocol design, and the RFCs continued. Through the many changes in
physical layer technology - analog copper circuits, digital circuits,
fiber and wireless -- resulting in speed increases from thousands to
billions of bits per second and a similar increase from thousands to
billions of users, this superstructure, including the RFCs has
continued to serve the community. All of the computers have changed,
as have all of the transmission lines. But the RFCs march on. Maybe
I'll write a few words for RFC 10,000.
Quite obviously the circumstances have changed. Email and other
media are most often used for the immediate exchange of inchoate
thoughts. Internet Drafts are the means for exchanging substantial,
albeit sometimes speculative content. And RFCs are reserved for
fully polished, reviewed, edited and approved specifications.
Comments to RFCs are not requested, although usage-related
discussions and other commentary on mailing lists often takes place
nonetheless. Rather than bemoan the change, I take it as a
remarkable example of adaptation. RFCs continue to serve the
protocol development community. Indeed, they are the bedrock of a
very vibrant and productive process that has fueled and guided the
Internet revolution.
Flanagan Expires February 10, 2020 [Page 10]
Internet-Draft Fifty Years of RFCs August 2019
3.2. The RFC Management and Editing Team - Vint Cerf
As Steve Crocker mentions in Section 3.1, Jon Postel assumed the role
of RFC manager in 1971 when Steve left UCLA for ARPA. Jon took on
this role in addition to his subsequent "numbers Czar"
responsibilities. Initially, his focus was largely on assigning RFC
numbers to aspiring writers but with time, and as the standardization
of the ARPANET and Internet protocols continued apace, he began to
serve in an editorial capacity. Moreover, as an accomplished
software engineer, he had opinions about technical content in
addition to writing style and did not hesitate to exercise editorial
discretion as would-be published authors presented their offerings
for his scrutiny. As the load increased, he recruited additional
"volunteer" talent, most notably Joyce K. Reynolds, a fellow
researcher at USC/ISI. Over the ensuing years, he also drafted
Robert (Bob) Braden into the team and when Jon unexpectedly passed
away in October 1998 (see [RFC2468]), Joyce and Bob undertook to
carry on with the RFC work in his stead, adding Sandy Ginoza to the
team. During the period when Jon and Joyce worked closely together,
Joyce would challenge me to tell which edits had been made by Jon and
which by her. I found this impossible, so aligned were they in their
editorial sensibilities. Sadly, three of these tireless Internauts
have passed on and we have only the product of their joint work and
Sandy Ginoza's and others' corporate memory by which to recall
history.
3.3. Formalizing the RFC Editor Model - Leslie Daigle
I was the chair of the Internet Architecture Board, the board
responsible for the general oversight of the RFC Series, at a
particular inflection point in the evolution of all Internet
technology institutions. To understand what we did, and why we had
to, let me first paint a broader picture of the arc of these
institutions.
Like many others who were in decision-making roles in the mid -00's,
I wasn't present when the Internet was born. The lore passed down to
me was that, out of the group of talented researchers that developed
the core specifications and established the direction of the
Internet, different individuals stepped up to take on roles necessary
to keep the process of specification development organized and open.
As the work of specification expanded, those individuals were
generally supported by organizations that carried on in the same
spirit. This was mostly Jon Postel, managing the allocation and
assignment of names and numbers, as well as working as the editor of
RFCs, but there were also individuals and institutions supporting the
IETF's Secretariat function. By the late 20th century, even this
model was wearing thin - the support functions were growing, and
Flanagan Expires February 10, 2020 [Page 11]
Internet-Draft Fifty Years of RFCs August 2019
organizations didn't have the ability to donate even more resources
to run them. In some cases (IANA) there was significant industry and
international dependence on the function and its neutrality.
The IETF, too, had grown in size, stature, and commercial reliance.
This system of institutional pieces "flying in formation" was not
providing the kind of contractual regularity or integrated
development that the IETF needed. People who hadn't been there as
the institutions developed, including IETF decision-makers, didn't
innately understand why things "had to be the way they were", and
were frustrated when trying to get individual systems updated for new
requirements, and better integrated across the spectrum of
activities.
Internet engineering had expanded beyond the point of being
supportable by a loosely-coupled set of organizations of people who
had been there since the beginning and knew each other well. New
forms of governance were needed, as well as a rationalized funding
model. The IANA function was absorbed into a purpose-built
international not-for-profit organization. The IETF stepped up to
manage its own organizational destiny, creating the IETF
Administrative Support Activity (IASA), and the Secretariat became
one of its contracted functions.
This left the RFC Editor function as an Internet Society-supported,
independent effort.
That independent nature was necessary for the historic role of the
RFC Series in considering all technical contributions. But, at that
inflection point in the Series' history, it needed a new governance
and funding model, just as the other Internet technical specification
supporting organizations had. Also, the IETF leadership had some
concerns it felt needed to be addressed in its own technical
publication stream. While the RFC Series had been established before
there was an IETF, and had historically continued to have documents
in it that didn't originate from the IETF, the IETF was its largest
and most organized contributor. There was no particular organization
of independent contributors. Equally, the funding for the RFC Editor
was at that point coming from the Internet Society in the guise of
"support for the IETF". For people who hadn't been involved with the
institution from the outset, it was pretty easy to perceive the RFC
Series uniquely as the IETF's publication series. So, the challenge
was to identify and address the IETF's issues, along with governance
and funding, without sacrificing the fundamental nature of the RFC
Series as a broader-than-IETF publication series.
To give a sense of the kinds of tensions that were prevalent, let me
share that the one phrase that sticks in my mind from those
Flanagan Expires February 10, 2020 [Page 12]
Internet-Draft Fifty Years of RFCs August 2019
discussions is: "push to publish". There were those in IETF
leadership who felt that it would significantly reduce costs and
improve timeliness if an RFC could be published by, literally,
pushing a button on a web interface the moment it was approved by the
IESG. It would also, they argued, remove the specification issues
being introduced by copy-editors that were hired as occasional
workers to help with improving publication rates, but who weren't
necessarily up to speed on terms of art in technical specifications.
(There were some pretty egregious examples of copyeditors introducing
changes that significantly changed the technical meaning of the text
that I forbear from citing here; let's just say it wasn't strictly a
problem of Internet engineers getting uptight about their cheese
being moved.) While "push to publish" would have addressed those
issues, it would not have addressed the loss of clarity from the many
significant text improvements copy editors successfully introduced,
or the fact that not all RFCs are approved by the IESG.
Institutionally, it was clear that the target was to have the RFC
Editor function governance within the reach of the Internet technical
community (as opposed to any particular private organization),
without tying it specifically to the IETF. That was reasonably
achievable by ensuring that the resultant pieces were established
under the oversight of the IAB (which is, itself, independent of the
IETF, even as it is supported by the IASA organization).
The IETF worked on a document outlining functional requirements for
its technical specification publication. This could have been useful
for establishing its own series, but it also was helpful in
establishing awareness of the challenges in document publishing (it
always looks easy when you haven't thought about it), and also to lay
the ground work for dialogue with the RFC Editor. The requirements
document was published as [RFC4714], as an Informational RFC that
stands today to provide guidance in the editing processes surrounding
IETF publications.
There was still, however, a certain lack of clarity about
responsibilities for making decisions and changes in the RFC Series
itself. To that end, I and the IAB worked with the various involved
parties to produce [RFC4844]. That document captured the RFC Series
mission (for a purpose greater than IETF technical specification
publication), as well as the roles and responsibilities of the
parties involved. The RFC Editor has responsibility for ensuring the
implementation of the mission. The IAB continues to have oversight
responsibilities, including policy oversight, which it could act on
by changing the person (organization) in the role of RFC Editor. At
the same time, operational oversight was migrated to the IASA support
function of the IETF (and IAB).
Flanagan Expires February 10, 2020 [Page 13]
Internet-Draft Fifty Years of RFCs August 2019
The discussions, and the resulting publication of RFC 4844, allowed
greater visibility into and commitment to the RFC Series, as a
general Internet publication. It also meant that subsequent
adjustments could be made, as requirements evolved - the responsible
parties are clearly identified.
3.4. The Continuation, or Creation, of a Stream - Nevil Brownlee
Arguably starting in 2006 with [RFC4714], the IAB and the IETF
community spent some time in the mid-2000's evolving the structure of
the RFC Series. This work included defining how those groups that
published into the RFC Series (initially including the IETF, the IAB
[RFC4845], and the Independent Submissions stream [RFC4846], and
later growing to include the IRTF [RFC5743]) would handle approving
documents to be published as RFCs. In 2009, the IAB published 'RFC
Editor (Version 1)' [RFC5620]. In this model, a new role was created
within the RFC Editor, the RFC Series Editor (RSE), an individual
that would oversee RFC publishing and development, while leaving the
process for approving documents for publication outside his or her
mandate. While arguably this was a role long filled by people like
Jon Postel, Bob Braden, and Joyce Reynolds, RFC 5620 saw the role of
RFC Series Editor defined in such a way as to distinctly separate it
from that of the Independent Submissions Editor (ISE).
Before 2009 the RFC Editor could accept 'Independent' submissions
from individuals, and - if he judged they were significant - publish
them as RFCs; the Independent Stream was set up to continue that
function. From February 2010 through February 2018, I was the
Independent Stream Editor (ISE) and I began by reading [RFC4846],
then went on to develop the Independent Stream (IS).
First I spent several days at the RFC Production Centre at ISI in
Marina Del Ray with the RFC Editor (Bob Braden) and Sandy Ginoza and
Alice Hagens, so as to learn how RFCs were actually edited and
published. All RFCs reach the Production Centre as Internet Drafts;
they are copy-edited, until the edited version can be approved by
their authors (AUTH48). At any stage authors can check their draft's
status in the RFC Editor Database.
For the Independent Submissions, Bob kept a journal (a simple ASCII
file) of his interactions with authors for every draft, indexed by
the draft name. Bob also entered the Independent drafts into the RFC
Editor database, so that authors could track their draft's status.
After my few days with his team at ISI, he handed that journal
(covering about 30 drafts) over to me and said "now it's over to
you!"
Flanagan Expires February 10, 2020 [Page 14]
Internet-Draft Fifty Years of RFCs August 2019
I began by following in Bob's footsteps, maintaining a journal and
tracking each draft's status in the RFC Editor database. My first
consideration was that every serious Internet draft submitted needs
several careful reviews. If the ISE knows suitable reviewers, he can
simply ask them. Otherwise, if the draft relates to an IETF or IRTF
Working Group, he can ask Working Group chairs or Area Directors to
suggest reviewers. As well, the ISE has an Independent Submissions
Editorial Board (Ed Board) that he can ask for reviewers. My
experience with reviewers was that most of those I approached were
happy to help.
Most drafts were straightforward, but there were some that needed
extra attention. Often a draft requests IANA code points, and for
that IANA were always quick to offer help and support. Code points
in some IANA Registries require Expert Review - sometimes the
interactions with Expert reviewers took quite a long time! Again,
sometimes a draft seemed to fit better in the IETF Stream; for these
I would suggest that the draft authors try to find an Area Director
to sponsor their work as in Individual submission to the IETF Stream.
After my first few years as ISE, the IETF Tools Team developed the
Data Tracker so that it could keep show draft status, and perform all
the 'housekeeping' tasks for all of the streams. At that stage I
switched to use the Data Tracker rather than the RFC Editor database.
Once a draft has been reviewed, and the authors have revised it in
dialogue with their reviewers, the ISE must submit that draft to the
IESG for their "Conflict Review" [RFC5742]. Overall, each IS draft
benefited from discussions (which were usually simple) with my Ed
Board and the IESG. A (very) few drafts were somewhat controversial
- for those I was able to work with the IESG to negotiate a suitable
'IESG Statement' and/or an 'ISE Statement' to make it clearer why the
ISE published the draft.
One rather special part of the Independent Stream is the April First
drafts. These are humorous RFCs that are never formally posted as
drafts and which have no formal review process. The authors must
send them directly to the ISE or the RFC Editor. Only a few of them
can be published each year; they are reviewed by the ISE and the RSE;
Bob Braden's criteria for April First drafts were:
They must relate to the Internet (like all drafts)
Their readers should reach the end of page two before realizing
this is an April First RFC
They must actually be funny!
Flanagan Expires February 10, 2020 [Page 15]
Internet-Draft Fifty Years of RFCs August 2019
April First RFCs have a large following, and feedback from the
Internet community on 1 April each year has been enthusiastic and
quick!
I published 159 Independent Stream RFCs during my eight years as ISE.
Over those eight years I worked with, and often met with at IETF
meetings, most of their authors. For me that was a very rewarding
experience, so I thank all those contributors. Also, I've worked
with most of the IESG members during those eight years, that also
gave me a lot of helpful interaction. Last, I've always enjoyed
working with the RFC Editor, and all the staff of the RFC Production
Centre. The IETF (as a whole) is very fortunate to have such an
effective team of talented Professional Staff.
3.5. A View from Inside the RFC Editor - Sandy Ginoza
When I joined ISI, shortly after Jon Postel passed away, the RFC
Editor as we know it today (as defined in RFC 5620, and as obsoleted
by [RFC6548] and RFC 6635) did not exist. The RFC Editor functioned
as one unit; there was no RSE, Production Center, Publisher, or
Independent Submissions Editor. All of these roles were performed by
the RFC Editor, which was comprised of four individuals: Bob Braden,
Joyce Reynolds, a part-time student programmer, and me.
Bob provided high-level guidance and reviewed Independent
Submissions. While Bob was a researcher in "Div 7" (Networking) at
ISI, ostensibly, the percentage of time he had for the RFC Editor was
10%, but he invested much more time to keep the series running. He
pitched in where he could, especially when processing times were
getting longer; at one point, he even NROFFed a couple of RFCs-to-be.
Joyce was a full-time employee, but while continuing to ensure RFCs
were published and serve as a User Services Area Director and a
keynote speaker about the Internet, she was also temporarily on loan
to IANA for 50% of her time while IANA was getting established after
separating from ISI. The student programmer performed programming
tasks as requested and was, at the time, responsible for parsing
MIBs. I was a full-time staffer and had to quickly learn the ropes
so RFCs would continue to be published.
My primary tasks were to manage the publication queue, format and
prepare documents for Joyce's review, carry out AUTH48 once Joyce
completed her review, and publish, index, and archive the RFCs (both
soft and hard copies).
The workload increased significantly over the next few years. As the
workload increased, the RFC Editor reacted and slowly grew their
staff over time. To understand the team growth, let's first take a
Flanagan Expires February 10, 2020 [Page 16]
Internet-Draft Fifty Years of RFCs August 2019
look at the publication rates throughout history. The table below
shows average annual publication rates during 5-year periods.
+-------------+-------------------+
| Years | Avg Pubs per Year |
+=============+===================+
| 1969 - 1972 | 80 |
+-------------+-------------------+
| 1973 - 1977 | 55 |
+-------------+-------------------+
| 1978 - 1982 | 20 |
+-------------+-------------------+
| 1983 - 1987 | 39 |
+-------------+-------------------+
| 1988 - 1992 | 69 |
+-------------+-------------------+
| 1993 - 1997 | 171 |
+-------------+-------------------+
| 1998 - 2002 | 237 |
+-------------+-------------------+
| 2003 - 2007 | 325 |
+-------------+-------------------+
| 2008 - 2012 | 333 |
+-------------+-------------------+
| 2013 - 2017 | 295 |
+-------------+-------------------+
Table 2: Annual Publication Rates
There were significant jumps in the publication rates in the 90s and
onward, with the number of publications almost doubling between 1993
and 2007. The annual submission count surpassed the 300 mark for the
first time in 2004 and reached an all-time high of 385 in 2011. The
submission rate did not drop below 300 until 2016 (284).
As the submissions grew, the RFC Editor experienced growing pains.
Processing times began to increase as the existing staff was unable
to keep up with the expanding queue size. In an attempt to reduce
the training hump and to avoid permanently hiring staff in case the
submission burst was a fluke, ISI brought on temporary copy editors -
this way, the staff could easily be resized as needed. However, as
Leslie noted, this didn't work very well. The effects of the
experiment would be lasting, as this led to a form of the process we
have now, where the RFC Editor asks more questions during AUTH/AUTH48
and technical changes require approval from the relevant Area
Directors or stream managers, depending on the document stream.
These changes added to the workload and extended publication times;
Flanagan Expires February 10, 2020 [Page 17]
Internet-Draft Fifty Years of RFCs August 2019
many often now jokingly refer to AUTH48 as the authors' "48 days",
"48 weeks", etc.
Because the workload continued to increase (in more ways than just
document submissions; tool testing, editorial process changes, and
more) and the lessons learned with temporary copy editors, our team
grew more permanently. While we had other editors in between, two
additions are of particular interest, as they experienced much of the
RFC Editor's growing pains, helped work us out of a backlogged state,
shaped the RFC Editor function, and are still with the team today:
Alice Russo joined the team in 2005 and Megan Ferguson joined us in
2007.
With the understanding that the record breaking number of submissions
was not an anomaly, we made significant upgrades to the
infrastructure of the RFC Editor function to facilitate document
tracking and reporting. For example, the illustrious "black binder"
- an actual 3-ring binder used to track number assignment, a manually
edited HTML file for the queue page, and a Rube-Goldberg set of text
files and scripts that created queue statistics, all were eventually
replaced; an errata system was proposed and implemented; and XML
became a newly accepted source file.
In 2009, RFC 5620 was published, introducing the initial version of
the RFC Editor model we have now. While it was published in 2009, it
did not go into effect until 2010, when the RFC Editor project as I
knew it was disbanded and divvied up into four pieces: RFC Series
Editor (RSE), Independent Submissions Editor (ISE), RFC Production
Center (RPC), and Publisher. In addition, the RFC Series Advisory
Group (RSAG) was created to "provide expert, informed guidance
(chiefly, to the RSE) in matters affecting the RFC Series operation
and development."
In 2010, the RPC and Publisher contracts were awarded to Association
Management Systems (AMS); we started with three existing team members
(Alice Russo, Megan Ferguson, and me) and we were pleased to be
joined by Lynne Bartholomew, a new colleague to anchor us in the AMS
office, and later Rebecca VanRheenen shortly thereafter.
I was wary of this model and was especially worried about the hole
Bob Braden's departure would create. Luckily for us, Bob Braden
provided wise counsel and insight during the transition (and beyond).
He gave the staff transitioning to AMS particularly helpful parting
words - "keep the RFCs coming" - and that is what we did.
AMS embraced the RFC Series and helped us quickly get set up on new
servers. The RFC Production Center and Publisher were now part of
the AMS family and it was all hands on deck to make sure the
Flanagan Expires February 10, 2020 [Page 18]
Internet-Draft Fifty Years of RFCs August 2019
transition went smoothly to minimize the impact on document
processing.
Our focus during transition was to 1) keep the trains running; that
is, we wanted to get ourselves up and running with minimal down time
and 2) work with the Transitional RSE, the Independent Submissions
Editor (Nevil Brownlee), RSAG, and the IETF Administrative Director
(IAD) to better understand and implement the newly defined RFC Editor
model.
Though some portions of the transition were challenging and lasted
longer than expected, the Acting RSE (Olaf Kolkman) officially handed
the reins over to the RSE (Heather Flanagan) in 2012. She had to
jump in, learn the RFC Editor and IETF culture, and work through a
backlog of issues that had been left unattended.
Two of the backlogged issues were so old, they were ones someone
asked me about at my first IETF: when is the RFC Editor going to
allow non-ASCII characters in RFCs, and when will the RFC Editor
adopt a more modern publication format.
At that time, while we understood the desire to move toward
supporting a broader range of character sets and to have more modern
outputs, we also routinely received emails from individuals
requesting that we send them plain-text files (instead of pointing
them to the website) because their Internet access was limited. We
also regularly received complaints from rfc-editor.org users whenever
something on the site didn't work correctly with their older
browsers. In short, we could not advance without leaving a large
number of users behind.
However, we now find ourselves on the precipice of change. 2019
promises to be a BIG year for the RFC Series, as we expect to
transition from publishing plaintext, ASCII-only files to publishing
multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both
non-ASCII characters and SVG art.
Interestingly enough, I find that the RFC Editor has been in an
almost constant state of change since I joined the team, even though
the goal of the RFC Editor remains the same: to produce archival
quality RFCs in a timely manner that are easily accessible for future
generations.
Flanagan Expires February 10, 2020 [Page 19]
Internet-Draft Fifty Years of RFCs August 2019
4. The Next Fifty Years of RFCs
As Steve Crocker mentioned, the Series began with a goal of
communication over formality, openness over structure. As the
Internet has grown and become a pervasive, global construct, we still
aim for openness and communication, but recognize that for protocols
and other information to support interoperability, there must be
points of stability to build from. Small-time app developers to
multi-billion dollar companies are on the same footing. Anyone
should be able to look back at a point in time and understand what
was done, and why.
While the informality has given way to increased structure, the
openness and solid foundation that the Series provides must continue.
With that in mind, what is next for the next fifty years of RFCs?
4.1. Preservation
The RFC Editor exists to edit, publish, and maintain an archive of
documents published in the RFC Series. A proper digital archive,
however, is more than just saving RFCs to disk and making sure the
disks are backed up; the field of digital preservation has grown and
transformed into an industry in and of itself. "Digital Preservation
Considerations for the RFC Series" [RFC8153] reviews what a digital
archive means today and describes ways to support the archive into
the future, and recommends ways for the RFC Editor to take advantage
of those organizations that specialize in this field.
The future of digital preservation as far as the RFC Series is
concerned will mean both finding new partners that can absorb and
archive RFCs into a public, maintained digital archive, and reviewing
the RFC format to ensure that the published documents are archivable
according to whatever the industry best practice is over time.
4.2. Evolution of the RFC Format
RFCs have been digital documents since very early in the days of the
Series. While not always published in US-ASCII, that format has been
the canonical format for decades. The fact that this format has
lasted through so much evolution and change is remarkable.
Unfortunately, the old US-ASCII format does not extend enough to meet
the expectations and requirements of users today. The entire field
of online document presentation, consumption, and preservation, has
in some cases only been invented years after the first RFC was
published. While it can (and has) been argued that those newer
fields and their tools have not had a chance to stand the test of
time, the RFC Series Editor (in consultation with the community)
Flanagan Expires February 10, 2020 [Page 20]
Internet-Draft Fifty Years of RFCs August 2019
started a concerted effort in 2012 to bring the RFC Series into
alignment with a new array of possibilities for preservation and
display.
Information about the current RFC format project, the reasoning and
requirements for the changes underway today, can be found in
[RFC7990]. With the advent of these changes, the door has been
opened to consider further changes in the future as the
specifications for archiving digital material evolves, and as the
expectation of web development advances.
4.3. Stream Structure
In the eyes of many, particularly within the IETF, the RFC Series is
synonymous with the IETF. While the Series itself predates the IETF
by eighteen years, over time the IETF has become the source of the
majority of documents submitted for publication to the RFC Editor.
The policies developed for IETF stream drafts tend to apply across
all four document streams, and publication-related tools tend to
focus on the IETF as the primary audience for their use. It is
difficult for people to see how, or even why, there is a distinction
between the Series and the IETF.
We are in the midst of that question now more than ever. What is the
future of the Series? If people cannot tell where the IETF ends and
the Series starts, should we consider this an artificial distinction
and declare them to be the same entity?
Ultimately, this will be something the community decides, and
conversations are underway to consider the ramifications of possible
changes.
5. Conclusion
As the Internet evolves, expectations and possibilities evolve, too.
Over the next fifty years, the Series will continue to demonstrate a
balance between the need to stay true to the original mission of
publication and preservation, while also staying relevant to the
needs of the authors and consumers of RFCs. The tension in balancing
those needs rests on the RFC Editor and the community to resolve. We
will not run short of challenges.
6. IANA Considerations
This document contains no actions for IANA.
Flanagan Expires February 10, 2020 [Page 21]
Internet-Draft Fifty Years of RFCs August 2019
7. Security Considerations
This document has no security considerations.
8. Informative References
[IAB-19880712]
IAB, "IAB Minutes 1988-07-12", July 1988,
<https://www.iab.org/documents/minutes/minutes-1988/iab-
minutes-1988-07-12/>.
[IETF1] "First IETF; January 16-17, 1986; San Diego, California",
January 1986,
<https://www.ietf.org/old/2009/proceedings/prior29/
IETF01.pdf>.
[ISI-to-AMS]
The IETF Administrative Support Activity, "RFC Production
Center Agreement between Association Management Solutions,
LLC, and the Internet Society", October 2009,
<https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-
2009.pdf>.
[RFC-ONLINE]
RFC Editor, "History of RFC Online Project", February
2010, <http://www.rfc-editor.org/rfc-online-2000.html>.
[RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001,
April 1969, <https://www.rfc-editor.org/info/rfc1>.
[RFC0003] Crocker, S.D., "Documentation conventions", RFC 3,
DOI 10.17487/RFC0003, April 1969,
<https://www.rfc-editor.org/info/rfc3>.
[RFC0114] Bhushan, A.K., "File Transfer Protocol", RFC 114,
DOI 10.17487/RFC0114, April 1971,
<https://www.rfc-editor.org/info/rfc114>.
[RFC0433] Postel, J., "Socket number list", RFC 433,
DOI 10.17487/RFC0433, December 1972,
<https://www.rfc-editor.org/info/rfc433>.
[RFC0690] Postel, J., "Comments on the proposed Host/IMP Protocol
changes", RFC 690, DOI 10.17487/RFC0690, June 1975,
<https://www.rfc-editor.org/info/rfc690>.
[RFC0748] Crispin, M.R., "Telnet randomly-lose option", RFC 748,
Flanagan Expires February 10, 2020 [Page 22]
Internet-Draft Fifty Years of RFCs August 2019
DOI 10.17487/RFC0748, April 1978,
<https://www.rfc-editor.org/info/rfc748>.
[RFC0902] Reynolds, J.K. and J. Postel, "ARPA Internet Protocol
policy", RFC 902, DOI 10.17487/RFC0902, July 1984,
<https://www.rfc-editor.org/info/rfc902>.
[RFC1000] Reynolds, J.K. and J. Postel, "Request For Comments
reference guide", RFC 1000, DOI 10.17487/RFC1000, August
1987, <https://www.rfc-editor.org/info/rfc1000>.
[RFC1083] Defense Advanced Research Projects Agency and Internet
Activities Board, "IAB official protocol standards",
RFC 1083, DOI 10.17487/RFC1083, December 1988,
<https://www.rfc-editor.org/info/rfc1083>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC1150] Malkin, G.S. and J.K. Reynolds, "FYI on FYI: Introduction
to the FYI Notes", RFC 1150, DOI 10.17487/RFC1150, March
1990, <https://www.rfc-editor.org/info/rfc1150>.
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
DOI 10.17487/RFC1311, March 1992,
<https://www.rfc-editor.org/info/rfc1311>.
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995,
<https://www.rfc-editor.org/info/rfc1818>.
[RFC2441] Cohen, D., "Working with Jon, Tribute delivered at UCLA,
October 30, 1998", RFC 2441, DOI 10.17487/RFC2441,
November 1998, <https://www.rfc-editor.org/info/rfc2441>.
[RFC2468] Cerf, V., "I REMEMBER IANA", RFC 2468,
DOI 10.17487/RFC2468, October 1998,
<https://www.rfc-editor.org/info/rfc2468>.
[RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555,
Flanagan Expires February 10, 2020 [Page 23]
Internet-Draft Fifty Years of RFCs August 2019
DOI 10.17487/RFC2555, April 1999,
<https://www.rfc-editor.org/info/rfc2555>.
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical
Publication Service", RFC 4714, DOI 10.17487/RFC4714,
October 2006, <https://www.rfc-editor.org/info/rfc4714>.
[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>.
[RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process
for Publication of IAB RFCs", RFC 4845,
DOI 10.17487/RFC4845, July 2007,
<https://www.rfc-editor.org/info/rfc4845>.
[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent
Submissions to the RFC Editor", RFC 4846,
DOI 10.17487/RFC4846, July 2007,
<https://www.rfc-editor.org/info/rfc4846>.
[RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540,
DOI 10.17487/RFC5540, April 2009,
<https://www.rfc-editor.org/info/rfc5540>.
[RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)",
RFC 5620, DOI 10.17487/RFC5620, August 2009,
<https://www.rfc-editor.org/info/rfc5620>.
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
Handling of Independent and IRTF Stream Submissions",
BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
<https://www.rfc-editor.org/info/rfc5742>.
[RFC5743] Falk, A., "Definition of an Internet Research Task Force
(IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743,
December 2009, <https://www.rfc-editor.org/info/rfc5743>.
[RFC6360] Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,
DOI 10.17487/RFC6360, August 2011,
<https://www.rfc-editor.org/info/rfc6360>.
[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>.
Flanagan Expires February 10, 2020 [Page 24]
Internet-Draft Fifty Years of RFCs August 2019
[RFC6548] Brownlee, N., Ed. and IAB, "Independent Submission Editor
Model", RFC 6548, DOI 10.17487/RFC6548, June 2012,
<https://www.rfc-editor.org/info/rfc6548>.
[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>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
Requirements and Future Development", RFC 6949,
DOI 10.17487/RFC6949, May 2013,
<https://www.rfc-editor.org/info/rfc6949>.
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990,
DOI 10.17487/RFC7990, December 2016,
<https://www.rfc-editor.org/info/rfc7990>.
[RFC8153] Flanagan, H., "Digital Preservation Considerations for the
RFC Series", RFC 8153, DOI 10.17487/RFC8153, April 2017,
<https://www.rfc-editor.org/info/rfc8153>.
Acknowledgements
With many thanks to John Klensin for his feedback and insights on the
history of the Series, as someone who directly engaged and influenced
many of the key individuals involved in developing the RFC Series.
Additional thanks to members of the RFC Series Advisory group and the
Independent Submissions Editorial Board, in particular Scott Bradner,
Brian Carpenter, and Adrian Farrel, for their early reviews and input
into the sequence of key moments in the history of the Series.
Contributors
Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil
Brownlee, and Sandy Ginoza for their perspectives on the Series, and
their ongoing support.
Author's Address
Heather Flanagan (editor)
RFC Editor
Email: rse@rfc-editor.org
URI: https://orcid.org/0000-0002-2647-2220
Flanagan Expires February 10, 2020 [Page 25]
