doc: Add RFC documents

1 files changed, 1254 insertions, 0 deletions

diff --git a/doc/rfc/rfc8700.txt b/doc/rfc/rfc8700.txt
new file mode 100644
index 0000000..3368692
--- /dev/null
+++ b/doc/rfc/rfc8700.txt
@@ -0,0 +1,1254 @@
+
+
+
+
+Internet Architecture Board (IAB)                       H. Flanagan, Ed.
+Request for Comments: 8700                                    RFC Editor
+Updates: 2555, 5540                                        December 2019
+Category: Informational                                                 
+ISSN: 2070-1721
+
+
+                          Fifty Years of RFCs
+
+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 document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8700.
+
+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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Key Moments in RFC History
+   3.  Perspectives
+     3.1.  The Origins of RFCs - by Stephen D. Crocker
+     3.2.  The RFC Management and Editing Team - by Vint Cerf
+     3.3.  Formalizing the RFC Editor Model - by Leslie Daigle
+     3.4.  The Continuation, or Creation, of a Stream - by Nevil
+           Brownlee
+     3.5.  A View from inside the RFC Editor - by Sandy Ginoza
+   4.  The Next Fifty Years of RFCs
+     4.1.  Preservation
+     4.2.  Evolution of the RFC Format
+     4.3.  Stream Structure
+   5.  Conclusion
+   6.  IANA Considerations
+   7.  Security Considerations
+   8.  Informative References
+   IAB Members at the Time of Approval
+   Acknowledgements
+   Contributors
+   Author's Address
+
+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 guidance, 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 streams, each of which have 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 the term "RFC Editor" 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
+   defining the initial processes surrounding the publication of RFCs.
+   What is certain is that the goal of the RFC Editor is to produce
+   documents that are readable, clear, consistent, and reasonably
+   uniform, 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 then to email.
+   RFCs could not be distributed electronically in 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
+   effort went from Steve Crocker to a more official model with a
+   designated editor, Jon Postel, and later to a team of five to seven
+   individuals.  The actual editing and publishing work split from the
+   service for registration of protocol code points.  The whole RFC
+   Editor structure was reviewed [RFC4844], refined [RFC5620], and
+   refined again [RFC6635].  And, in the last few years, the process to
+   change the format of the RFC documents themselves has started
+   [RFC7990].
+
+   This is evolution; and the Series will continue to be adapted in
+   order to meet the needs and expectations of the implementers,
+   operators, historians, and community of authors that uses the RFC
+   Series.  These changes will 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 Advanced Research Projects Agency Network (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.  These RFCs 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, October 30,
+      1998"
+
+   *  [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 it.
+   Narratives of this nature offer a limited perspective on events;
+   there are almost certainly other viewpoints, memories, and
+   perspectives 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.
+
+   Steve Crocker, author of [RFC0001], 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 Independent Stream
+   (IS) and its transition upon the retirement of Bob Braden from the
+   position.  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 [RFC2555] and
+   [RFC5540].
+
+2.  Key Moments in RFC History
+
+   +--------------------+----------+-----------------------------------+
+   | Marker             | Date     | Event                             |
+   +====================+==========+===================================+
+   | [RFC0001]          | April    | First RFC published               |
+   |                    | 1969     |                                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC0114]          | April    | First distribution of RFCs        |
+   |                    | 1971     | over the network                  |
+   +--------------------+----------+-----------------------------------+
+   | [RFC0433]          | December | First mention of the Czar of      |
+   |                    | 1972     | Socket Numbers and the            |
+   |                    |          | proposal for a formal             |
+   |                    |          | registry                          |
+   +--------------------+----------+-----------------------------------+
+   | [RFC0690]          | June     | Relationship starts between       |
+   |                    | 1975     | the Information Sciences          |
+   |                    |          | Institute (ISI) and the RFC       |
+   |                    |          | Editor (judging by Jon            |
+   |                    |          | Postel's affiliation change)      |
+   +--------------------+----------+-----------------------------------+
+   | [RFC0748]          | April    | First April 1st RFC               |
+   |                    | 1977     | published                         |
+   +--------------------+----------+-----------------------------------+
+   | [IETF1]            | January  | First Internet Engineering        |
+   |                    | 1986     | Task Force (IETF) meeting         |
+   +--------------------+----------+-----------------------------------+
+   | [IAB-19880712]     | July     | IAB approved the creation of      |
+   |                    | 1988     | an Internet-Draft series          |
+   +--------------------+----------+-----------------------------------+
+   | [RFC1122][RFC1123] | December | First major effort to review      |
+   |                    | 1988     | key specifications and write      |
+   |                    |          | applicability statements          |
+   +--------------------+----------+-----------------------------------+
+   | [RFC1083]          | October  | Three-stage standards             |
+   |                    | 1989     | process first defined             |
+   +--------------------+----------+-----------------------------------+
+   | [RFC1150]          | March    | FYI sub-series started            |
+   |                    | 1990     |                                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC1311]          | March    | STD sub-series started            |
+   |                    | 1992     |                                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC1818]          | August   | BCP sub-series started            |
+   |                    | 1995     |                                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC-ONLINE]       | approx.  | RFC Online Project to             |
+   |                    | 1998     | restore early RFCs that were      |
+   |                    |          | "lost" started                    |
+   +--------------------+----------+-----------------------------------+
+   | [RFC2441]          | 15       | Jon Postel's death                |
+   |                    | October  |                                   |
+   |                    | 1998     |                                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC4844]          | July     | RFC Series administrative         |
+   |                    | 2007     | structure documented              |
+   +--------------------+----------+-----------------------------------+
+   | [RFC4846]          | July     | Independent Submission            |
+   |                    | 2007     | document stream is                |
+   |                    |          | formalized                        |
+   +--------------------+----------+-----------------------------------+
+   | [RFC5620]          | August   | RFC Editor organization           |
+   |                    | 2009     | officially established as         |
+   |                    |          | RFC Series Editor,                |
+   |                    |          | Independent Submission            |
+   |                    |          | Editor, RFC Production            |
+   |                    |          | Center, and RFC Publisher         |
+   +--------------------+----------+-----------------------------------+
+   | [ISI-to-AMS]       | October  | Transition of RFC Production      |
+   |                    | 2009     | Center and RFC Publisher          |
+   |                    |          | starts from Information           |
+   |                    |          | Sciences Institute (ISI) to       |
+   |                    |          | Association Management            |
+   |                    |          | Solutions (AMS)                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC5540]          | January  | Bob Braden retires from RFC       |
+   |                    | 2010     | Editor                            |
+   +--------------------+----------+-----------------------------------+
+   | [RFC5743]          | December | Internet Research Task Force      |
+   |                    | 2009     | document stream formalized        |
+   +--------------------+----------+-----------------------------------+
+   | [RFC-ONLINE]       | approx.  | RFC Online Project to             |
+   |                    | 2010     | restore early RFCs that were      |
+   |                    |          | "lost" finished                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC6360]          | August   | FYI sub-series ended              |
+   |                    | 2011     |                                   |
+   +--------------------+----------+-----------------------------------+
+   | [RFC6410]          | October  | Two-stage standards process       |
+   |                    | 2011     | formalized                        |
+   +--------------------+----------+-----------------------------------+
+   | [RFC6635]          | June     | Updated responsibilities of       |
+   |                    | 2012     | RFC Series allocated to RFC       |
+   |                    |          | Series Editor, RFC                |
+   |                    |          | Production Center, and RFC        |
+   |                    |          | Publisher                         |
+   +--------------------+----------+-----------------------------------+
+   | [RFC6949]          | May 2013 | RFC format change project         |
+   |                    |          | started                           |
+   +--------------------+----------+-----------------------------------+
+   | [RFC8153]          | April    | RFCs no longer printed to         |
+   |                    | 2017     | paper upon publication            |
+   +--------------------+----------+-----------------------------------+
+
+                    Table 1: Key Moments in RFC History
+
+3.  Perspectives
+
+3.1.  The Origins of RFCs - by Stephen D. Crocker
+
+   (This is a revision of material included more than 30 years ago in
+   [RFC1000].)
+
+   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 the Advanced Research Projects Agency (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"
+   (Defense Advanced Research Projects Agency) 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
+   (Stanford Research Institute) in Menlo Park, CA; University of
+   California, Santa Barbara (UCSB); and the University of Utah in Salt
+   Lake City.  These sites were running a Scientific Data Systems (SDS)
+   Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10, respectively.
+   These machines not only had different operating systems, but even
+   details like character sets and byte sizes varied.  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 would
+   IMPs and "hosts" (I think that was the first time I was exposed to
+   that term) 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
+   possibilities: interactive graphics, cooperating processes, automatic
+   database query, electronic mail, etc., 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 disjointed 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
+   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 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!  (See [APPRENTICE].)
+
+   After BBN distributed the specification for the IMP hardware and
+   software interface 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
+   Representational State Transfer (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 stream instead of a virtual byte stream?  Because each
+   computer had its own notion of how many bits were in a byte.  8-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
+   the MIT Research Establishment (MITRE) took on the task of indexing
+   them.  That seemed like a large task then, and we could have hardly
+   anticipated seeing more than 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
+   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 can 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; even now, students and young professionals all
+   over the world have been able to download RFCs, learn about the
+   technology within, and in turn, build the most amazing software.
+   (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 RFCs continued.  Through the
+   changes in physical-layer technology, resulting in speed increases
+   from thousands to billions of bits per second, and similarly 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, while 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 take 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.
+
+3.2.  The RFC Management and Editing Team - by 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 onto the team, and when Jon unexpectedly
+   passed away in October 1998 (see [RFC2468]), Joyce and Bob undertook
+   carrying 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 - by 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 '00s, 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
+   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 as well as 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 along with 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 independent effort supported
+   by the Internet Society.
+
+   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 organizations supporting
+   Internet technical specification 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 kind of tensions that were prevalent, let me
+   share that the one phrase that stuck in my mind from those
+   discussions was "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 copy editors
+   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 in
+   laying the groundwork 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 is responsible 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).
+
+   The discussions, and the resulting publication of [RFC4844], 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 - by Nevil Brownlee
+
+   Arguably starting in 2006 with [RFC4714], the IAB and the IETF
+   community spent some time in the mid-'00s 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 Model (Version 1)" [RFC5620].  In this model, a new role was
+   created within the RFC Editor: the RFC Series Editor (RSE).  This
+   individual 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, [RFC5620] 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 they were judged significant, publish them
+   as RFCs; the Independent Stream was set up to continue that function.
+   From February 2010 through February 2018, I was the ISE.  After
+   reading [RFC4846], I went on to develop the Independent Stream (IS).
+
+   First, I spent several days at the RFC Production Center at the
+   Information Sciences Institute (ISI) in Marina Del Ray with the RFC
+   Editor (Bob Braden), Sandy Ginoza, and Alice Hagens so as to learn
+   how RFCs were actually edited and published.  All RFCs reach the
+   Production Center as Internet-Drafts; they are copy edited until the
+   edited version can be approved by its authors (AUTH48).  At any
+   stage, authors can check their draft's status via the RFC Editor
+   website.
+
+   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!"
+
+   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 needed
+   several careful reviews.  At that time, if the ISE knew of suitable
+   reviewers, he or she could simply ask them.  Otherwise, if the draft
+   related to an IETF or IRTF Working Group, the ISE could ask Working
+   Group Chairs or Area Directors to suggest reviewers.  The Independent
+   Submissions Editorial Board (Ed Board) was another place the ISE
+   could request reviewers from.  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 requested IANA code points, and for
+   that, IANA was always quick to offer help and support.  Code points
+   in some IANA registries require Expert Review [RFC8126]; 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 an individual submission to the
+   IETF Stream.
+
+   After my first few years as ISE, the IETF Tools Team developed the
+   Datatracker [DATATRACKER] to show draft status and perform all the
+   "housekeeping" tasks for all of the streams.  At that stage, I
+   switched to using the Datatracker 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 an "IESG Review" [RFC5742].  Overall, each IS draft
+   benefited from discussions (which were usually simple) with my Ed
+   Board and the IESG.  A (very) few 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 clear why the ISE
+   published the draft.
+
+   One rather special part of the Independent Stream is the April 1st
+   RFCs.  These are humorous RFCs that have no formal review and
+   approval process.  The authors must send them directly to the ISE or
+   the RFC Editor.  Only a few of them can be published each year, and
+   each is reviewed by the ISE and the RSE.  Bob Braden's criteria for
+   April 1st drafts were:
+
+   *  They must relate to the Internet (like all drafts).
+
+   *  Their readers should reach the end of page two before realizing it
+      is an April 1st RFC.
+
+   *  They must actually be funny!
+
+   April 1st RFCs have a large following, and feedback from the Internet
+   community on April 1st of each year has been enthusiastic and quick!
+
+   159 RFCs were published in the Independent Stream during my eight
+   years as ISE.  Over those eight years, I worked with most of their
+   authors and often met with them at IETF meetings.  For me, that was a
+   very rewarding experience, so I thank all those that contributed.
+   During those eight years, I also worked with most of the IESG
+   members, who all also gave me a lot of helpful interaction.  Lastly,
+   I've always enjoyed working with the RSE and all the staff of the RFC
+   Production Center.  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 - by Sandy Ginoza
+
+   When I joined ISI, shortly after Jon Postel passed away, the RFC
+   Editor model as we know it today (as defined in [RFC5620] and as
+   obsoleted by [RFC6548] and [RFC6635]) 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 ISI employee.  However, while continuing to
+   ensure RFCs were published, she was also serving as a User Services
+   Area Director and a keynote speaker about the Internet, and 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
+   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;
+   many often now jokingly refer to AUTH48 as the authors' "48 days",
+   "48 weeks", etc.
+
+   In addition to the increase in document submissions, we engaged in
+   tools testing and went through several editorial process changes.
+   Because of the lesson learned with temporary copy editors, our team
+   grew to be more permanent.  While we added 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 RFC 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, [RFC5620] 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 the Publisher function.  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" [RSAG].
+
+   In 2010, the RPC and Publisher contracts were awarded to Association
+   Management Solutions (AMS).  There, we started with three existing
+   team members (Alice Russo, Megan Ferguson, and me), and we were
+   pleased to be joined by Lynne Bartholomew and Rebecca VanRheenen, new
+   colleagues to anchor us in the AMS office.
+
+   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
+   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 (a role that concluded before
+   the transition ended), the ISE (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 new 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 that they were ones someone
+   had asked me about at my first IETF meeting: When was the RFC Editor
+   going to allow non-ASCII characters in RFCs?  When would 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 having more-modern
+   outputs, we also routinely received emails from individuals
+   requesting that we send them plaintext files (instead of pointing
+   them to the website) because their Internet access was limited.  We
+   also regularly received complaints from users of <https://www.rfc-
+   editor.org> 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.  The next
+   few years promise to be exciting for the RFC Series as we 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.
+
+4.  The Next Fifty Years of RFCs
+
+   As Steve Crocker mentioned, the Series began with goals of
+   communication over formality and 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.  Everyone, from small-time app
+   developers to multi-billion dollar companies, is 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 does the future hold 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.  It also 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 US-ASCII format does not extend enough to meet the
+   expectations and requirements of many 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 be (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)
+   started a concerted effort in 2012 to bring the RFC Series into
+   alignment with a new array of possibilities for preservation and
+   display.
+
+   Information on the RFC format project and the initial reasoning and
+   requirements for the changes underway 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 has no IANA actions.
+
+7.  Security Considerations
+
+   This document has no security considerations.
+
+8.  Informative References
+
+   [APPRENTICE]
+              Wikipedia, "The Sorcerer's Apprentice", December 2019,
+              <https://en.wikipedia.org/w/index.php?title=The_Sorcerer%2
+              7s_Apprentice&oldid=925824658>.
+
+   [DATATRACKER]
+              Internet Engineering Task Force, "IETF Datatracker",
+              <https://datatracker.ietf.org>.
+
+   [IAB-19880712]
+              IAB, "IAB Minutes 1988-07-12", July 1988,
+              <https://www.iab.org/documents/minutes/minutes-1988/iab-
+              minutes-1988-07-12/>.
+
+   [IETF1]    The MITRE Corporation, "Proceedings of the 16-17 January
+              1986 DARPA Gateway Algorithms and Data Structures Task
+              Force", IETF 1, January 1986,
+              <https://www.ietf.org/old/2009/proceedings/prior29/
+              IETF01.pdf>.
+
+   [ISI-to-AMS]
+              IETF Administrative Support Activity (IASA), "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", 2000,
+              <https://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., "Documentation conventions", RFC 3,
+              DOI 10.17487/RFC0003, April 1969,
+              <https://www.rfc-editor.org/info/rfc3>.
+
+   [RFC0114]  Bhushan, A., "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., "Telnet randomly-lose option", RFC 748,
+              DOI 10.17487/RFC0748, April 1978,
+              <https://www.rfc-editor.org/info/rfc748>.
+
+   [RFC0902]  Reynolds, J. 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. 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. and J. 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,
+              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>.
+
+   [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>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [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>.
+
+   [RSAG]     RFC Editor, "RFC Series Advisory Group",
+              <https://www.rfc-editor.org/about/rsag/>.
+
+IAB Members at the Time of Approval
+
+      Jari Arkko
+      Alissa Cooper
+      Stephen Farrell
+      Wes Hardaker
+      Ted Hardie
+      Christian Huitema
+      Zhenbin Li
+      Erik Nordmark
+      Mark Nottingham
+      Melinda Shore
+      Jeff Tantsura
+      Martin Thomson
+      Brian Trammell
+
+Acknowledgements
+
+   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