Skip to main content

Fifty Years of RFCs
draft-flanagan-fiftyyears-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Heather Flanagan
Last updated 2018-10-20
Replaced by draft-iab-fiftyyears, RFC 8700
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-flanagan-fiftyyears-00
Network Working Group                                   H. Flanagan, Ed.
Internet-Draft                                                RFC Editor
Updates: 2555, 5540 (if approved)                       October 20, 2018
Intended status: Informational
Expires: April 23, 2019

                          Fifty Years of RFCs
                      draft-flanagan-fiftyyears-00

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.

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 April 23, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Flanagan                 Expires April 23, 2019                 [Page 1]
Internet-Draft             Fifty Years of RFCs              October 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Perspectives  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  The Origins of RFCs - by Stephen D. Crocker . . . . . . .   3
     2.2.  Formalizing the RFC Editor Model - Leslie Daigle  . . . .   8
     2.3.  The Continuation, or Creation, of a Stream - Nevil
           Brownlee  . . . . . . . . . . . . . . . . . . . . . . . .  11
     2.4.  A View from Inside the RFC Editor - Sandy Ginoza  . . . .  13
   3.  The Next Fifty Years of   RFCs  . . . . . . . . . . . . . . .  13
     3.1.  Preservation  . . . . . . . . . . . . . . . . . . . . . .  13
     3.2.  Evolution of the RFC Format . . . . . . . . . . . . . . .  14
     3.3.  Stream Structure  . . . . . . . . . . . . . . . . . . . .  14
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The RFC Series began in April 1969 with the publication of "Host
   Software" by Steve Crocker.  Since then, over 8000 RFCs have been
   published, ranging from best practice information, experimental
   protocols, informational material, and, of course, 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.

   Since the very first RFC fifty years ago, the focus of the Series has
   been on that stable record and dissemination of ideas to the world.
   At times there have been conflicts over what is more important - a
   stable, archival record, or making the latest ideas available as soon
   as possible.  As the Internet has evolved, so to have the
   expectations of instant access, faster publication, and ubiquitous
   availability.  It seems that the need for a stable, archival record
   is often deprioritized against those more immediate needs.

   Change does come to the Series, albeit slowly.  First, we saw the
   distribution method change from postal mail to FTP and email.  From
   there, we saw increased guidance for authors on how to write an RFC.
   The editorial staff went from one person, Jon Postel, to a team of

Flanagan                 Expires April 23, 2019                 [Page 2]
Internet-Draft             Fifty Years of RFCs              October 2018

   five to seven.  The actual editing and publishing work split from the
   protocol registration service.  The whole RFC Editor structure was
   reviewed and refined [RFC6635].  And, in the last few years, we have
   started to 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 the other entities that make up the
   community that uses 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 Internet technical
   community.

   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:

      [RFC2441]"Working with Jon, Tribute delivered at UCLA"

      [RFC2555]"30 Years of RFCs"

      [RFC5540]"40 Years of RFCs"

   In this document, several individuals who have been a part of shaping
   the Series offer their observations of key moments in the series.
   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 20xx 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.

2.  Perspectives

2.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

Flanagan                 Expires April 23, 2019                 [Page 3]
Internet-Draft             Fifty Years of RFCs              October 2018

   gleam in the eyes of 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: UCLA in Los Angeles, CA; 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 first exposed to
   that term) would be connected?  What hosts would 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 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

Flanagan                 Expires April 23, 2019                 [Page 4]
Internet-Draft             Fifty Years of RFCs              October 2018

   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 adopted 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 own 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.  I suppose I was the first

Flanagan                 Expires April 23, 2019                 [Page 5]
Internet-Draft             Fifty Years of RFCs              October 2018

   RFC Editor, though I never use that term because we never reviewed or
   changed the content of any of the RFCs.  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 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.  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,

Flanagan                 Expires April 23, 2019                 [Page 6]
Internet-Draft             Fifty Years of RFCs              October 2018

   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
   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:

Flanagan                 Expires April 23, 2019                 [Page 7]
Internet-Draft             Fifty Years of RFCs              October 2018

   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 of 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 ubiquitous 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,
   productive and process that has fueled and guided the Internet
   revolution.

2.2.  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

Flanagan                 Expires April 23, 2019                 [Page 8]
Internet-Draft             Fifty Years of RFCs              October 2018

   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, doing the work 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, 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 and were needed, as well as rationalized funding
   The IANA function was absorbed into a purpose-built international
   not-for-profit organization.  The IETF stepped up to manage its own
   organizational destiny (IASA), and the Secretariat became one of its
   contracted functions.

   This left the RFC Editor function as an ISOC-supported, independent
   effort.

   That independence of 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 it needed to be addressed in its
   own technical publication sream.  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

Flanagan                 Expires April 23, 2019                 [Page 9]
Internet-Draft             Fifty Years of RFCs              October 2018

   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
   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 that I forebear 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

Flanagan                 Expires April 23, 2019                [Page 10]
Internet-Draft             Fifty Years of RFCs              October 2018

   parties to produce [RFC4744].  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).

   The discussions, and the resulting publication of RFC 4744, 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.

2.3.  The Continuation, or Creation, of a Stream - Nevil Brownlee

   Starting in 2006 with [RFC4714], the IAB began working towards a new
   structure for publishing RFCs; in 2009 that emerged as the 'RFC
   Editor (Version 1)' [RFC5629].  In this model the RFC Series Editor
   (RSE) oversees RFC publishing and development, and four separate
   'Streams' produce the documents to be published.  The IETF Stream
   produces standards-related material, all of its output has full IETF
   consensus.  The way each new Stream operates is specified in a
   separate RFC, i.e.,

   [RFC 4845]  IAB: Architecture Reports and Procedures material

   [RFC 5743]  IRTF: Internet Research material

   [RFC 4846]  Independent: Other material

   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) - 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.

Flanagan                 Expires April 23, 2019                [Page 11]
Internet-Draft             Fifty Years of RFCs              October 2018

   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 me 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 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 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, For that
   IANA were always been 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 don't really exist, so 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:

Flanagan                 Expires April 23, 2019                [Page 12]
Internet-Draft             Fifty Years of RFCs              October 2018

      They must relate to the Internet (like all drafts)

      Their readers should reach the end of page two before realising
      this is an April First RFC

      They must actually be funny!

   April First RFCs have a large following, feedback (on the rfc-
   interest list) 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.

2.4.  A View from Inside the RFC Editor - Sandy Ginoza

   Content forthcoming

3.  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.  And anyone
   can 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?

3.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

Flanagan                 Expires April 23, 2019                [Page 13]
Internet-Draft             Fifty Years of RFCs              October 2018

   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.

3.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, started a
   concerted effort in 2012 to bring the RFC Series into alignment with
   a new array of possibilities for preservation and display started.

   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.

3.3.  Stream Structure

   In the eyes of many [this content may be updated based on
   conversations with third-party marketing research groups],
   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.

Flanagan                 Expires April 23, 2019                [Page 14]
Internet-Draft             Fifty Years of RFCs              October 2018

   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.

4.  Conclusion

   As the Internet evolves, expectations and possibilities evolve, too.
   Over the next fifty years, the Series will continue 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.

5.  Informative References

   [RFC0003]  Crocker, S., "Documentation conventions", RFC 3,
              DOI 10.17487/RFC0003, April 1969,
              <https://www.rfc-editor.org/info/rfc3>.

   [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>.

   [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>.

   [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>.

   [RFC4744]  Lear, E. and K. Crozier, "Using the NETCONF Protocol over
              the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,
              DOI 10.17487/RFC4744, December 2006,
              <https://www.rfc-editor.org/info/rfc4744>.

Flanagan                 Expires April 23, 2019                [Page 15]
Internet-Draft             Fifty Years of RFCs              October 2018

   [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>.

   [RFC5629]  Rosenberg, J., "A Framework for Application Interaction in
              the Session Initiation Protocol (SIP)", RFC 5629,
              DOI 10.17487/RFC5629, October 2009,
              <https://www.rfc-editor.org/info/rfc5629>.

   [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>.

   [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>.

   [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>.

Appendix A.  Contributors

   With many thanks to Steve Crocker, 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 April 23, 2019                [Page 16]