< draft-flanagan-fiftyyears-02.txt   draft-flanagan-fiftyyears-03.txt >
Network Working Group H. Flanagan, Ed. Network Working Group H. Flanagan, Ed.
Internet-Draft RFC Editor Internet-Draft RFC Editor
Updates2555, 5540 (if approved) 25 March 2019 Updates2555, 5540 (if approved) 3 April 2019
Intended status: Informational Intended status: Informational
Expires: 26 September 2019 Expires: 5 October 2019
Fifty Years of RFCs Fifty Years of RFCs
draft-flanagan-fiftyyears-02 draft-flanagan-fiftyyears-03
Abstract Abstract
This RFC marks the fiftieth anniversary for the RFC Series. It This RFC marks the fiftieth anniversary for the RFC Series. It
includes both retrospective material from individuals involved at key includes both retrospective material from individuals involved at key
inflection points, as well as a review of the current state of inflection points, as well as a review of the current state of
affairs. It concludes with thoughts on possibilities for the next affairs. It concludes with thoughts on possibilities for the next
fifty years for the Series. This document updates and brings current fifty years for the Series. This document updates and brings current
the history started in RFCs 2555 and 5540. the history started in RFCs 2555 and 5540.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 September 2019. This Internet-Draft will expire on 5 October 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Moments in RFC History . . . . . . . . . . . . . . . . . 4 2. Key Moments in RFC History . . . . . . . . . . . . . . . . . 4
3. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Origins of RFCs - by Stephen D. Crocker . . . . . 5 3.1. The Origins of RFCs - by Stephen D. Crocker . . . . . 5
3.2. The RFC Management and Editing Team - Vint Cerf . . . . 10 3.2. The RFC Management and Editing Team - Vint Cerf . . . . 10
3.3. Formalizing the RFC Editor Model - Leslie Daigle 3.3. Formalizing the RFC Editor Model - Leslie Daigle
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. The Continuation, or Creation, of a Stream - Nevil 3.4. The Continuation, or Creation, of a Stream - Nevil
Brownlee . . . . . . . . . . . . . . . . . . . . . . . 13 Brownlee . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. A View from Inside the RFC Editor - Sandy Ginoza 3.5. A View from Inside the RFC Editor - Sandy Ginoza
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. The Next Fifty Years of RFCs . . . . . . . . . . . . . . . . 19 4. The Next Fifty Years of RFCs . . . . . . . . . . . . . . . . 19
4.1. Preservation . . . . . . . . . . . . . . . . . . . . . 19 4.1. Preservation . . . . . . . . . . . . . . . . . . . . . 20
4.2. Evolution of the RFC Format . . . . . . . . . . . . . . 20 4.2. Evolution of the RFC Format . . . . . . . . . . . . . . 20
4.3. Stream Structure . . . . . . . . . . . . . . . . . . . 20 4.3. Stream Structure . . . . . . . . . . . . . . . . . . . 21
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Informative References . . . . . . . . . . . . . . . . . . . 21 6. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The RFC Series began in April 1969 with the publication of "Host The RFC Series began in April 1969 with the publication of "Host
Software" by Steve Crocker. The early RFCs were extremely informal Software" by Steve Crocker. The early RFCs were, in fact, requests
and included poems, satires, and April 1 jokes, to name a few. Since for comments on ideas and proposals; the goal was to start
then, over 8000 RFCs have been published, ranging across best conversations, rather than to create an archival record of a standard
practice information, experimental protocols, informational material, or best practice. This goal changed over time, as the formality of
and, of course, standards. Material is accepted for publication the publication process evolved, and the community consuming the
through the IETF, the IAB, the IRTF, and the Independent Submissions material grew. Today, over 8500 RFCs have been published, ranging
stream, each with clear processes on how drafts are submitted and across best practice information, experimental protocols,
potentially approved for publication as an RFC. Ultimately, the goal informational material, and, of course, Internet standards. Material
of the RFC Series is to provide a canonical source for the material is accepted for publication through the IETF, the IAB, the IRTF, and
published by the RFC Editor, and to support the preservation of that the Independent Submissions stream, each with clear processes on how
material in perpetuity. 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 was published fifty years ago, the focus of The RFC Editor as a role came a few years after the first RFC was
the Series has evolved to be a stable record of what has been published. The actual date when the term was first used is murky;
published and to provide a source for the dissemination to the world Jon Postel, the first RFC Editor, defined the role by his actions and
of the ideas contained in the RFCs. In particular, when Internet later by defining the initial processes surrounding the publication
Drafts first started being produced [need a date check], RFCs became of RFCs. What is certain is that the RFC Editor is responsible for
a much more formal body of material requiring serious curation, from making sure that the editorial quality of the RFCs published is high,
the editing process through to the curation and archiving of the and that the archival record of what has been published is
documents. Today, there is still a tension between having that maintained.
stable, archival record, versus making the latest ideas available as
soon as possible; evolution will continue, in no small part driven by
that tension.
Change does come to the Series, albeit slowly. First, we saw the Change does come to the Series, albeit slowly. First, we saw the
distribution method change from postal mail to FTP and email. From distribution method change from postal mail to FTP and email. From
there, we saw increased guidance for authors on how to write an RFC. 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 The editorial staff went from one person, Jon Postel, to a team of
five to seven. The actual editing and publishing work split from the five to seven. The actual editing and publishing work split from the
service for registration of protocol codepoints. The whole RFC service for registration of protocol code points. The whole RFC
Editor structure was reviewed and refined [RFC6635]. And, in the Editor structure was reviewed [RFC4844] and refined [RFC5620] and
last few years, we have started the process to change the format of refined again[RFC6635]. And, in the last few years, we have started
the RFC documents themselves. the process to change the format of the RFC documents themselves.
This is evolution, and the Series will continue to adapt in order to This is evolution, and the Series will continue to adapt in order to
meet the needs and expectations of the community of authors, meet the needs and expectations of the community of authors,
operators, historians, and users of the RFC Series. These changes operators, historians, and users of the RFC Series. These changes
will be always be balanced against the core mission of the Series: to will be always be balanced against the core mission of the Series: to
maintain a strong, stable, archival record of technical maintain a strong, stable, archival record of technical
specifications, protocols, and other information relevant to the specifications, protocols, and other information relevant to the
Arpanet and Internet networking communities. ARPANET and Internet networking communities.
There is more to the history of the RFC Series than can be covered in There is more to the history of the RFC Series than can be covered in
this document. Readers interested in earlier perspectives may find this document. Readers interested in earlier perspectives may find
the following RFCs of particular interest that focus on the enormous the following RFCs of particular interest that focus on the enormous
contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and
first RFC Editor: first RFC Editor:
[RFC2441]"Working with Jon, Tribute delivered at UCLA" [RFC2441]"Working with Jon, Tribute delivered at UCLA"
[RFC2555]"30 Years of RFCs" [RFC2555]"30 Years of RFCs"
skipping to change at page 4, line 10 skipping to change at page 4, line 10
put my thoughts in on the most recent changes in formalizing the put my thoughts in on the most recent changes in formalizing the
digital preservation of the Series, the process to modernize the digital preservation of the Series, the process to modernize the
format while respecting the need for stability, and my thoughts on format while respecting the need for stability, and my thoughts on
the next fifty years of RFCs. the next fifty years of RFCs.
This document brings up to date the historical records started in This document brings up to date the historical records started in
RFCs 2555 and 5540. RFCs 2555 and 5540.
2. Key Moments in RFC History 2. Key Moments in RFC History
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| Marker | Date | Event | | Marker | Date | Event |
+================+===========+=================================+ +====================+================+=============================+
| [RFC0001] | 1969 | First RFC published | | [RFC0001] | 1969 | First RFC published |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC0114] | 1971 | First distribution of RFCs over | | [RFC0114] | 1971 | First distribution of |
| | | the network | | | | RFCs over the network |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC0433] | December | First mention of the Czar of | | [RFC0433] | December 1972 | First mention of the |
| | 1972 | Socket Numbers and the proposal | | | | Czar of Socket Numbers |
| | | for a formal registry | | | | and the proposal for a |
+----------------+-----------+---------------------------------+ | | | formal registry |
| [RFC0690] | June 1975 | Relationship starts between ISI | +--------------------+----------------+-----------------------------+
| | | and the RFC Editor, judging by | | [RFC0690] | June 1975 | Relationship starts |
| | | Jon Postel's affiliation change | | | | between ISI and the |
+----------------+-----------+---------------------------------+ | | | RFC Editor, judging by |
| [RFC0748] | March | First April 1st RFC | | | | Jon Postel's |
| | 1977 | | | | | affiliation change |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC1083] | December | Three stage standards process | | [RFC0748] | March 1977 | First Internet |
| | 1988 | defined | | | | Engineering Task Force |
+----------------+-----------+---------------------------------+ | | | (IETF) meeting |
| [RFC1150] | March | FYI sub-series started | +--------------------+----------------+-----------------------------+
| | 1990 | | | [IETF1] | January 1986 | First April 1st RFC |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC1311] | March | STD sub-series started | | [RFC1083] | December 1988 | First major effort to |
| | 1992 | | | | | review key |
+----------------+-----------+---------------------------------+ | | | specifications and |
| [RFC1818] | August | BCP sub-series started | | | | write applicability |
| | 1995 | | | | | statements |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC-ONLINE] | (approx) | RFC Online Project | | [RFC1122][RFC1123] | October 1989 | Three stage standards |
| | 1998-2010 | | | | | process defined |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [IAB-19880712] | July 1988 | IAB approves the creation of an | | [RFC1150] | March 1990 | FYI sub-series started |
| | | Internet Draft series | +--------------------+----------------+-----------------------------+
+----------------+-----------+---------------------------------+ | [RFC1311] | March 1992 | STD sub-series started |
| [RFC2441] | 15 | Jon Postel's death | +--------------------+----------------+-----------------------------+
| | October | | | [RFC1818] | August 1995 | BCP sub-series started |
| | 1998 | | +--------------------+----------------+-----------------------------+
+----------------+-----------+---------------------------------+ | [RFC-ONLINE] | (approx) | RFC Online Project |
| [ISI-to-AMS] | October | Transition starts from ISI to | | | 1998-2010 | |
| | 2009 | Association Management | +--------------------+----------------+-----------------------------+
| | | Solutions (AMS) | | [IAB-19880712] | July 1988 | IAB approves the |
+----------------+-----------+---------------------------------+ | | | creation of an |
| [RFC4844] | July 2007 | RFC Stream structure | | | | Internet Draft series |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC6360] | August | FYI sub-series ended | | [RFC2441] | 15 October | Jon Postel's death |
| | 2011 | | | | 1998 | |
+----------------+-----------+---------------------------------+ +--------------------+----------------+-----------------------------+
| [RFC6410] | October | Two stage standards process | | [ISI-to-AMS] | October 2009 | Transition starts from |
| | 2011 | formalized | | | | ISI to Association |
+----------------+-----------+---------------------------------+ | | | Management Solutions |
| [RFC6949] | May 2013 | RFC Format change project | | | | (AMS) |
| | | started | +--------------------+----------------+-----------------------------+
+----------------+-----------+---------------------------------+ | [RFC4844] | July 2007 | RFC Stream structure |
| [RFC8153] | April | RFCs no longer printed to paper | +--------------------+----------------+-----------------------------+
| | 2017 | upon publication | | [RFC4846] | Formalize the | July 2007 |
+----------------+-----------+---------------------------------+ | | Independent | |
| | Submission | |
| | document | |
| | stream | |
+--------------------+----------------+-----------------------------+
| [RFC5746] | Formalize the | December 2009 |
| | Internet | |
| | Research Task | |
| | Force document | |
| | stream | |
+--------------------+----------------+-----------------------------+
| [RFC6360] | August 2011 | FYI sub-series ended |
+--------------------+----------------+-----------------------------+
| [RFC6410] | October 2011 | Two stage standards |
| | | process formalized |
+--------------------+----------------+-----------------------------+
| [RFC6949] | May 2013 | RFC Format change |
| | | project started |
+--------------------+----------------+-----------------------------+
| [RFC8153] | April 2017 | RFCs no longer printed |
| | | to paper upon |
| | | publication |
+--------------------+----------------+-----------------------------+
Table 1 Table 1
3. Perspectives 3. Perspectives
3.1. The Origins of RFCs - by Stephen D. Crocker 3.1. The Origins of RFCs - by Stephen D. Crocker
[This is a revision of material included in [RFC1000] August 1987, [This is a revision of material included in [RFC1000] August 1987,
more than thirty years ago.] more than thirty years ago.]
The Internet community now includes millions of nodes and billions of The Internet community now includes millions of nodes and billions of
users. It owes its beginning to the Arpanet, which was once but a users. It owes its beginning to the ARPANET, which was once but a
gleam in the eyes of Bob Taylor, Larry Roberts, and J. C. R. gleam in the eyes of J. C. R. Licklider, Bob Taylor, and Larry
Licklider of ARPA. While much of the development proceeded according Roberts of ARPA. While much of the development proceeded according
to plan, the initial design of the protocols and the creation of the to plan, the initial design of the protocols and the creation of the
RFCs was largely accidental. RFCs was largely accidental.
The procurement of the ARPANET was initiated in the summer of 1968 The procurement of the ARPANET was initiated in the summer of 1968
--remember Vietnam, flower children, etc.? There had been prior --remember Vietnam, flower children, etc.? There had been prior
experiments at various ARPA sites to link together computer systems, experiments at various ARPA sites to link together computer systems,
but this was the first version to explore packet-switching as a core but this was the first version to explore packet-switching as a core
part of the communication strategy. ("ARPA" didn't become "DARPA" part of the communication strategy. ("ARPA" didn't become "DARPA"
until 1972. It briefly changed back to ARPA in 1993 and then back until 1972. It briefly changed back to ARPA in 1993 and then back
again to DARPA.) The government's Request for Quotations (RFQ) again to DARPA.) The government's Request for Quotations (RFQ)
skipping to change at page 9, line 45 skipping to change at page 10, line 20
the government, so there was little competition and no need to use 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 documents as a way of raising money. Of course, as soon as we had
email working on the ARPANET, we distributed RFCs electronically. email working on the ARPANET, we distributed RFCs electronically.
When the ARPANET became just a portion of the Internet, this When the ARPANET became just a portion of the Internet, this
distribution process became worldwide. The effect of this openness distribution process became worldwide. The effect of this openness
is often overlooked. Students and young professionals all over the is often overlooked. Students and young professionals all over the
world have been able to download the RFCs, learn about the many world have been able to download the RFCs, learn about the many
pieces of technology, and then build the most amazing software. And pieces of technology, and then build the most amazing software. And
they still are. [They are also a fantastic resource for historians.] they still are. [They are also a fantastic resource for historians.]
Where will it end? The Arpanet begat the Internet and the underlying Where will it end? The ARPANET begat the Internet and the underlying
technology transitioned from the original host-host protocol to TCP/ technology transitioned from the original host-host protocol to TCP/
IP, but the superstructure of protocol layers, community driven IP, but the superstructure of protocol layers, community driven
protocol design, and the RFCs continued. Through the many changes in protocol design, and the RFCs continued. Through the many changes in
physical layer technology - analog copper circuits, digital circuits, physical layer technology - analog copper circuits, digital circuits,
fiber and wireless -- resulting in speed increases from thousands to fiber and wireless -- resulting in speed increases from thousands to
billions of bits per second and a similar increase from thousands to billions of bits per second and a similar increase from thousands to
billions of users, this superstructure, including the RFCs has billions of users, this superstructure, including the RFCs has
continued to serve the community. All of the computers have changed, continued to serve the community. All of the computers have changed,
as have all of the transmission lines. But the RFCs march on. Maybe as have all of the transmission lines. But the RFCs march on. Maybe
I'll write a few words for RFC 10,000. I'll write a few words for RFC 10,000.
skipping to change at page 13, line 15 skipping to change at page 13, line 35
establishing awareness of the challenges in document publishing (it establishing awareness of the challenges in document publishing (it
always looks easy when you haven't thought about it), and also to lay 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 the ground work for dialogue with the RFC Editor. The requirements
document was published as [RFC4714], as an Informational RFC that document was published as [RFC4714], as an Informational RFC that
stands today to provide guidance in the editing processes surrounding stands today to provide guidance in the editing processes surrounding
IETF publications. IETF publications.
There was still, however, a certain lack of clarity about There was still, however, a certain lack of clarity about
responsibilities for making decisions and changes in the RFC Series responsibilities for making decisions and changes in the RFC Series
itself. To that end, I and the IAB worked with the various involved itself. To that end, I and the IAB worked with the various involved
parties to produce [RFC4744]. That document captured the RFC Series parties to produce [RFC4844]. That document captured the RFC Series
mission (for a purpose greater than IETF technical specification mission (for a purpose greater than IETF technical specification
publication), as well as the roles and responsibilities of the publication), as well as the roles and responsibilities of the
parties involved. The RFC Editor has responsibility for ensuring the parties involved. The RFC Editor has responsibility for ensuring the
implementation of the mission. The IAB continues to have oversight implementation of the mission. The IAB continues to have oversight
responsibilities, including policy oversight, which it could act on responsibilities, including policy oversight, which it could act on
by changing the person (organization) in the role of RFC Editor. At by changing the person (organization) in the role of RFC Editor. At
the same time, operational oversight was migrated to the IASA support the same time, operational oversight was migrated to the IASA support
function of the IETF (and IAB). function of the IETF (and IAB).
The discussions, and the resulting publication of RFC 4744, allowed The discussions, and the resulting publication of RFC 4844, allowed
greater visibility into and commitment to the RFC Series, as a greater visibility into and commitment to the RFC Series, as a
general Internet publication. It also meant that subsequent general Internet publication. It also meant that subsequent
adjustments could be made, as requirements evolved - the responsible adjustments could be made, as requirements evolved - the responsible
parties are clearly identified. parties are clearly identified.
3.4. The Continuation, or Creation, of a Stream - Nevil Brownlee 3.4. The Continuation, or Creation, of a Stream - Nevil Brownlee
Starting in 2006 with [RFC4714], the IAB began working towards a new Arguably starting in 2006 with [RFC4714], the IAB and the IETF
structure for publishing RFCs; in 2009 that emerged as the 'RFC community spent some time in the mid-2000's evolving the structure of
Editor (Version 1)' [RFC5629]. In this model the RFC Series Editor the RFC Series. This work included defining how those groups that
(RSE) oversees RFC publishing and development, and four separate published into the RFC Series (initially including the IETF, the IAB
'Streams' produce the documents to be published. The IETF Stream [RFC4845], and the Independent Submissions stream [RFC4846], and
produces standards-related material, all of its output has full IETF later growing to include the IRTF [RFC5743]) would handle approving
consensus. The way each new Stream operates is specified in a documents to be published as RFCs. In 2009, the IAB published 'RFC
separate RFC, i.e., Editor (Version 1)' [RFC5620]. In this model, a new role was created
within the RFC Editor, the RFC Series Editor (RSE), an individual
[RFC 4845] IAB: Architecture Reports and Procedures material that would oversee RFC publishing and development, while leaving the
process for approving documents for publication outside his or her
[RFC 5743] IRTF: Internet Research material mandate. While arguably this was a role long filled by people like
Jon Postel, Bob Braden, and Joyce Reynolds, RFC 5620 saw the role of
[RFC 4846] Independent: Other material 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 Before 2009 the RFC Editor could accept 'Independent' submissions
from individuals, and - if he judged they were significant - publish from individuals, and - if he judged they were significant - publish
them as RFCs; the Independent Stream was set up to continue that them as RFCs; the Independent Stream was set up to continue that
function. From February 2010 through February 2018 I was the function. From February 2010 through February 2018, I was the
Independent Stream Editor (ISE) - I began by reading [RFC4846], then Independent Stream Editor (ISE) and I began by reading [RFC4846],
went on to develop the Independent Stream (IS). then went on to develop the Independent Stream (IS).
First I spent several days at the RFC Production Centre at ISI in 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 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 Alice Hagens, so as to learn how RFCs were actually edited and
published. All RFCs reach the Production Centre as Internet Drafts; published. All RFCs reach the Production Centre as Internet Drafts;
they are copy-edited, until the edited version can be approved by they are copy-edited, until the edited version can be approved by
their authors (AUTH48). At any stage authors can check their draft's their authors (AUTH48). At any stage authors can check their draft's
status in the RFC Editor Database. status in the RFC Editor Database.
For the Independent Submissions, Bob kept a journal (a simple ASCII For the Independent Submissions, Bob kept a journal (a simple ASCII
skipping to change at page 15, line 18 skipping to change at page 15, line 40
One rather special part of the Independent Stream is the April First One rather special part of the Independent Stream is the April First
drafts. These are humorous RFCs that are never formally posted as drafts. These are humorous RFCs that are never formally posted as
drafts and which have no formal review process. The authors must drafts and which have no formal review process. The authors must
send them directly to the ISE or the RFC Editor. Only a few of them 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; can be published each year; they are reviewed by the ISE and the RSE;
Bob Braden's criteria for April First drafts were: Bob Braden's criteria for April First drafts were:
They must relate to the Internet (like all drafts) They must relate to the Internet (like all drafts)
Their readers should reach the end of page two before realising Their readers should reach the end of page two before realizing
this is an April First RFC this is an April First RFC
They must actually be funny! They must actually be funny!
April First RFCs have a large following, feedback (on the rfc- April First RFCs have a large following, and feedback from the
interest list) on 1 April each year has been enthusiastic and quick! Internet community on 1 April each year has been enthusiastic and
quick!
I published 159 Independent Stream RFCs during my eight years as ISE. 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 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 meetings, most of their authors. For me that was a very rewarding
experience, so I thank all those contributors. Also, I've worked experience, so I thank all those contributors. Also, I've worked
with most of the IESG members during those eight years, that also with most of the IESG members during those eight years, that also
gave me a lot of helpful interaction. Last, I've always enjoyed 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 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 Centre. The IETF (as a whole) is very fortunate to have such an
effective team of talented Professional Staff. effective team of talented Professional Staff.
skipping to change at page 17, line 18 skipping to change at page 17, line 47
As the submissions grew, the RFC Editor experienced growing pains. As the submissions grew, the RFC Editor experienced growing pains.
Processing times began to increase as the existing staff was unable Processing times began to increase as the existing staff was unable
to keep up with the expanding queue size. In an attempt to reduce 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 the training hump and to avoid permanently hiring staff in case the
submission burst was a fluke, ISI brought on temporary copy editors - submission burst was a fluke, ISI brought on temporary copy editors -
this way, the staff could easily be resized as needed. However, as this way, the staff could easily be resized as needed. However, as
Leslie noted, this didn't work very well. The effects of the 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 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 have now, where the RFC Editor asks more questions during AUTH/AUTH48
and technical changes require approval from the relevant Area and technical changes require approval from the relevant Area
Directors. These changes added to the workload and extended Directors or stream managers, depending on the document stream.
publication times; many often now jokingly refer to AUTH48 as the These changes added to the workload and extended publication times;
authors' "48 days", "48 weeks", etc. many often now jokingly refer to AUTH48 as the authors' "48 days",
"48 weeks", etc.
Because the workload continued to increase (in more ways than just Because the workload continued to increase (in more ways than just
document submissions; tool testing, editorial process changes, and document submissions; tool testing, editorial process changes, and
more) and the lessons learned with temporary copy editors, our team more) and the lessons learned with temporary copy editors, our team
grew more permanently. While we had other editors in between, two grew more permanently. While we had other editors in between, two
additions are of particular interest, as they experienced much of the additions are of particular interest, as they experienced much of the
RFC Editor's growing pains, helped work us out of a backlogged state, 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: 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 Alice Russo joined the team in 2005 and Megan Ferguson joined us in
2007. 2007.
skipping to change at page 18, line 36 skipping to change at page 19, line 19
implement the newly defined RFC Editor model. implement the newly defined RFC Editor model.
Though some portions of the transition were challenging and lasted Though some portions of the transition were challenging and lasted
longer than expected, the Acting RSE officially handed the reigns longer than expected, the Acting RSE officially handed the reigns
over to the RSE (Heather Flanagan) in 2012. She had to jump in, over to the RSE (Heather Flanagan) in 2012. She had to jump in,
learn the RFC Editor and IETF culture, and work through a backlog of learn the RFC Editor and IETF culture, and work through a backlog of
issues that had been left unattended. issues that had been left unattended.
Two of the backlogged issues were so old, they were ones someone Two of the backlogged issues were so old, they were ones someone
asked me about at my first IETF: when is the RFC Editor going to asked me about at my first IETF: when is the RFC Editor going to
allow UTF-8 in RFCs and when will the RFC Editor adopt a more modern allow non-ASCII characters in RFCs, and when will the RFC Editor
publication format. adopt a more modern publication format.
At that time, while we understood the desire to move toward UTF-8 and At that time, while we understood the desire to move toward
to have more modern outputs, we also routinely received emails from supporting a broader range of character sets and to have more modern
individuals requesting that we send them plain-text files (instead of outputs, we also routinely received emails from individuals
pointing them to the website) because their Internet access was requesting that we send them plain-text files (instead of pointing
limited. We also regularly received complaints from rfc-editor.org them to the website) because their Internet access was limited. We
users whenever something on the site didn't work correctly with their also regularly received complaints from rfc-editor.org users whenever
older browsers. In short, we could not advance without leaving a something on the site didn't work correctly with their older
large number of users behind. browsers. In short, we could not advance without leaving a large
number of users behind.
However, we now find ourselves on the precipice of change. 2019 However, we now find ourselves on the precipice of change. 2019
promises to be a BIG year for the RFC Series, as we expect to promises to be a BIG year for the RFC Series, as we expect to
transition from publishing plaintext, ASCII-only files to publishing transition from publishing plaintext, ASCII-only files to publishing
multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both
UTF-8 and SVG art. non-ASCII characters and SVG art.
Interestingly enough, I find that the RFC Editor has been in an Interestingly enough, I find that the RFC Editor has been in an
almost constant state of change since I joined the team, even though almost constant state of change since I joined the team, even though
the goal of the RFC Editor remains the same: to produce archival the goal of the RFC Editor remains the same: to produce archival
quality RFCs in a timely manner that are easily accessible for future quality RFCs in a timely manner that are easily accessible for future
generations. generations.
4. The Next Fifty Years of RFCs 4. The Next Fifty Years of RFCs
As Steve Crocker mentioned, the Series began with a goal of As Steve Crocker mentioned, the Series began with a goal of
communication over formality, openness over structure. As the communication over formality, openness over structure. As the
Internet has grown and become a pervasive, global construct, we still Internet has grown and become a pervasive, global construct, we still
aim for openness and communication, but recognize that for protocols aim for openness and communication, but recognize that for protocols
and other information to support interoperability, there must be and other information to support interoperability, there must be
points of stability to build from. Small-time app developers to points of stability to build from. Small-time app developers to
multi-billion dollar companies are on the same footing. And anyone multi-billion dollar companies are on the same footing. Anyone
can look back at a point in time and understand what was done, and should be able to look back at a point in time and understand what
why. was done, and why.
While the informality has given way to increased structure, the While the informality has given way to increased structure, the
openness and solid foundation that the Series provides must continue. openness and solid foundation that the Series provides must continue.
With that in mind, what is next for the next fifty years of RFCs? With that in mind, what is next for the next fifty years of RFCs?
4.1. Preservation 4.1. Preservation
The RFC Editor exists to edit, publish, and maintain an archive of The RFC Editor exists to edit, publish, and maintain an archive of
documents published in the RFC Series. A proper digital archive, documents published in the RFC Series. A proper digital archive,
however, is more than just saving RFCs to disk and making sure the however, is more than just saving RFCs to disk and making sure the
skipping to change at page 20, line 16 skipping to change at page 20, line 40
RFCs have been digital documents since very early in the days of the 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 Series. While not always published in US-ASCII, that format has been
the canonical format for decades. The fact that this format has the canonical format for decades. The fact that this format has
lasted through so much evolution and change is remarkable. lasted through so much evolution and change is remarkable.
Unfortunately, the old US-ASCII format does not extend enough to meet Unfortunately, the old US-ASCII format does not extend enough to meet
the expectations and requirements of users today. The entire field the expectations and requirements of users today. The entire field
of online document presentation, consumption, and preservation, has of online document presentation, consumption, and preservation, has
in some cases only been invented years after the first RFC was in some cases only been invented years after the first RFC was
published. While it can and has) been argued that those newer fields published. While it can (and has) been argued that those newer
and their tools have not had a chance to stand the test of time, the fields and their tools have not had a chance to stand the test of
RFC Series Editor, in consultation with the community, started a time, the RFC Series Editor, in consultation with the community,
concerted effort in 2012 to bring the RFC Series into alignment with started a concerted effort in 2012 to bring the RFC Series into
a new array of possibilities for preservation and display started. alignment with a new array of possibilities for preservation and
display.
Information about the current RFC format project, the reasoning and Information about the current RFC format project, the reasoning and
requirements for the changes underway today, can be found in requirements for the changes underway today, can be found in
[RFC7990]. With the advent of these changes, the door has been [RFC7990]. With the advent of these changes, the door has been
opened to consider further changes in the future as the opened to consider further changes in the future as the
specifications for archiving digital material evolves, and as the specifications for archiving digital material evolves, and as the
expectation of web development advances. expectation of web development advances.
4.3. Stream Structure 4.3. Stream Structure
skipping to change at page 21, line 23 skipping to change at page 21, line 48
will not run short of challenges. will not run short of challenges.
6. 6.
Informative References Informative References
[IAB-19880712] [IAB-19880712]
IAB, ""IAB Minutes 1988-07-12"", July 1988, IAB, ""IAB Minutes 1988-07-12"", July 1988,
<https://www.iab.org/documents/minutes/minutes-1988/iab- <https://www.iab.org/documents/minutes/minutes-1988/iab-
minutes-1988-07-12/>. minutes-1988-07-12/>.
[IETF1] "First IETF; January 16-17, 1986; San Diego, California",
January 1986,
<https://www.ietf.org/old/2009/proceedings/prior29/
IETF01.pdf>.
[ISI-to-AMS] [ISI-to-AMS]
The IETF Administrative Support Activity, "RFC Production The IETF Administrative Support Activity, "RFC Production
Center Agreement between Association Management Solutions, Center Agreement between Association Management Solutions,
LLC, and the Internet Society", October 2009, LLC, and the Internet Society", October 2009,
<https://iaoc.ietf.org/documents/AMS-RPC-Public-Final- <https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-
2009.pdf>. 2009.pdf>.
[RFC-ONLINE] [RFC-ONLINE]
RFC Editor, "History of RFC Online Project", March 2019, RFC Editor, "History of RFC Online Project", April 2019,
<http://www.rfc-editor.org/rfc-online-2000.html>. <http://www.rfc-editor.org/rfc-online-2000.html>.
[RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001,
April 1969, <https://www.rfc-editor.org/info/rfc1>. April 1969, <https://www.rfc-editor.org/info/rfc1>.
[RFC0003] Crocker, S.D., "Documentation conventions", RFC 3, [RFC0003] Crocker, S.D., "Documentation conventions", RFC 3,
DOI 10.17487/RFC0003, April 1969, DOI 10.17487/RFC0003, April 1969,
<https://www.rfc-editor.org/info/rfc3>. <https://www.rfc-editor.org/info/rfc3>.
[RFC0114] Bhushan, A.K., "File Transfer Protocol", RFC 114, [RFC0114] Bhushan, A.K., "File Transfer Protocol", RFC 114,
skipping to change at page 22, line 18 skipping to change at page 22, line 48
[RFC1000] Reynolds, J.K. and J. Postel, "Request For Comments [RFC1000] Reynolds, J.K. and J. Postel, "Request For Comments
reference guide", RFC 1000, DOI 10.17487/RFC1000, August reference guide", RFC 1000, DOI 10.17487/RFC1000, August
1987, <https://www.rfc-editor.org/info/rfc1000>. 1987, <https://www.rfc-editor.org/info/rfc1000>.
[RFC1083] Defense Advanced Research Projects Agency and Internet [RFC1083] Defense Advanced Research Projects Agency and Internet
Activities Board, "IAB official protocol standards", Activities Board, "IAB official protocol standards",
RFC 1083, DOI 10.17487/RFC1083, December 1988, RFC 1083, DOI 10.17487/RFC1083, December 1988,
<https://www.rfc-editor.org/info/rfc1083>. <https://www.rfc-editor.org/info/rfc1083>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC1150] Malkin, G.S. and J.K. Reynolds, "FYI on FYI: Introduction [RFC1150] Malkin, G.S. and J.K. Reynolds, "FYI on FYI: Introduction
to the FYI Notes", RFC 1150, DOI 10.17487/RFC1150, March to the FYI Notes", RFC 1150, DOI 10.17487/RFC1150, March
1990, <https://www.rfc-editor.org/info/rfc1150>. 1990, <https://www.rfc-editor.org/info/rfc1150>.
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
DOI 10.17487/RFC1311, March 1992, DOI 10.17487/RFC1311, March 1992,
<https://www.rfc-editor.org/info/rfc1311>. <https://www.rfc-editor.org/info/rfc1311>.
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995, Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995,
skipping to change at page 22, line 46 skipping to change at page 23, line 38
<https://www.rfc-editor.org/info/rfc2468>. <https://www.rfc-editor.org/info/rfc2468>.
[RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555,
DOI 10.17487/RFC2555, April 1999, DOI 10.17487/RFC2555, April 1999,
<https://www.rfc-editor.org/info/rfc2555>. <https://www.rfc-editor.org/info/rfc2555>.
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical
Publication Service", RFC 4714, DOI 10.17487/RFC4714, Publication Service", RFC 4714, DOI 10.17487/RFC4714,
October 2006, <https://www.rfc-editor.org/info/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>.
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <https://www.rfc-editor.org/info/rfc4844>. July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[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 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent
Submissions to the RFC Editor", RFC 4846, Submissions to the RFC Editor", RFC 4846,
DOI 10.17487/RFC4846, July 2007, DOI 10.17487/RFC4846, July 2007,
<https://www.rfc-editor.org/info/rfc4846>. <https://www.rfc-editor.org/info/rfc4846>.
[RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540, [RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540,
DOI 10.17487/RFC5540, April 2009, DOI 10.17487/RFC5540, April 2009,
<https://www.rfc-editor.org/info/rfc5540>. <https://www.rfc-editor.org/info/rfc5540>.
[RFC5629] Rosenberg, J., "A Framework for Application Interaction in [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)",
the Session Initiation Protocol (SIP)", RFC 5629, RFC 5620, DOI 10.17487/RFC5620, August 2009,
DOI 10.17487/RFC5629, October 2009, <https://www.rfc-editor.org/info/rfc5620>.
<https://www.rfc-editor.org/info/rfc5629>.
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
Handling of Independent and IRTF Stream Submissions", Handling of Independent and IRTF Stream Submissions",
BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
<https://www.rfc-editor.org/info/rfc5742>. <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>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<https://www.rfc-editor.org/info/rfc5746>.
[RFC6360] Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, [RFC6360] Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,
DOI 10.17487/RFC6360, August 2011, DOI 10.17487/RFC6360, August 2011,
<https://www.rfc-editor.org/info/rfc6360>. <https://www.rfc-editor.org/info/rfc6360>.
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410, Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
DOI 10.17487/RFC6410, October 2011, DOI 10.17487/RFC6410, October 2011,
<https://www.rfc-editor.org/info/rfc6410>. <https://www.rfc-editor.org/info/rfc6410>.
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
 End of changes. 37 change blocks. 
156 lines changed or deleted 205 lines changed or added

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