rfc8700xml2.original.xml   rfc8700.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl"
href="rfc2629.xslt" ?> <?rfc toc="true"?>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<!ENTITY RFC0001 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC ipr="trust200902" number="8700" docName="draft-iab-fiftyyears-01" category
.0001.xml"> ="info"
<!ENTITY RFC0003 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC updates="2555, 5540" obsoletes="" consensus="true" sortRefs="true"
.0003.xml"> tocInclude="true" symRefs="true" submissionType="IAB" xml:lang="en" versio
<!ENTITY RFC0114 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC n="3">
.0114.xml">
<!ENTITY RFC0433 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.0433.xml">
<!ENTITY RFC0690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.0690.xml">
<!ENTITY RFC0748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.0748.xml">
<!ENTITY RFC0902 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.0902.xml">
<!ENTITY RFC1000 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1000.xml">
<!ENTITY RFC1083 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1083.xml">
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1122.xml">
<!ENTITY RFC1123 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1123.xml">
<!ENTITY RFC1150 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1150.xml">
<!ENTITY RFC1311 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1311.xml">
<!ENTITY RFC1818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1818.xml">
<!ENTITY RFC2441 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2441.xml">
<!ENTITY RFC2468 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2468.xml">
<!ENTITY RFC2555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2555.xml">
<!ENTITY RFC4714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4714.xml">
<!ENTITY RFC4844 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4844.xml">
<!ENTITY RFC4845 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4845.xml">
<!ENTITY RFC4846 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4846.xml">
<!ENTITY RFC5540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5540.xml">
<!ENTITY RFC5620 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5620.xml">
<!ENTITY RFC5742 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5742.xml">
<!ENTITY RFC5743 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5743.xml">
<!ENTITY RFC6360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6360.xml">
<!ENTITY RFC6410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6410.xml">
<!ENTITY RFC6548 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6548.xml">
<!ENTITY RFC6635 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6635.xml">
<!ENTITY RFC6949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6949.xml">
<!ENTITY RFC7990 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7990.xml">
<!ENTITY RFC8153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8153.xml">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-iab-fiftyyears-01" category="info" updates="2555, 5540" obsoletes="" submission
Type="IETF" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 2.22.2 -->
<front> <front>
<title abbrev="Fifty Years of RFCs">Fifty Years of RFCs</title> <title abbrev="Fifty Years of RFCs">Fifty Years of RFCs</title>
<seriesInfo name="Internet-Draft" value="draft-iab-fiftyyears-01"/> <seriesInfo name="RFC" value="8700"/>
<author initials="H." surname="Flanagan" fullname="Heather Flanagan" role="e ditor"> <author initials="H." surname="Flanagan" fullname="Heather Flanagan" role="e ditor">
<organization>RFC Editor</organization> <organization>RFC Editor</organization>
<address> <address>
<email>rse@rfc-editor.org</email> <email>rse@rfc-editor.org</email>
<uri>https://orcid.org/0000-0002-2647-2220</uri> <uri>https://orcid.org/0000-0002-2647-2220</uri>
</address> </address>
</author> </author>
<date year="2019" month="August" day="9"/> <date year="2019" month="December"/>
<abstract>
<keyword>History, RFC Series, Retrospective</keyword>
<abstract>
<t>This RFC marks the fiftieth anniversary for the RFC Series. It includes both <t>This RFC marks the fiftieth anniversary for the RFC Series. It includes both
retrospective material from individuals involved at key inflection points, as retrospective material from individuals involved at key inflection points as
well as a review of the current state of affairs. It concludes with thoughts well as a review of the current state of affairs. It concludes with thoughts
on possibilities for the next fifty years for the Series. on possibilities for the next fifty years for the Series.
This document updates the perspectives offered in RFCs 2555 and 5540. This document updates the perspectives offered in RFCs 2555 and 5540.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Introduction</name> <name>Introduction</name>
<t>The RFC Series began in April 1969 with the publication of "Host <t>The RFC Series began in April 1969 with the publication of "Host
Software" by Steve Crocker. The early RFCs were, in fact, requests for Software" by Steve Crocker. The early RFCs were, in fact, requests for
comments on ideas and proposals; the goal was to start conversations, comments on ideas and proposals; the goal was to start conversations
rather than to create an archival record of a standard or best practice. rather than to create an archival record of a standard or best practice.
This goal changed over time, as the formality of the publication process This goal changed over time, as the formality of the publication process
evolved, and the community consuming the material grew. Today, over 8500 evolved and the community consuming the material grew.
RFCs have been published, ranging across best practice information,
experimental protocols, informational material, and, of course, Internet
standards. Material is accepted for publication through the IETF, the IAB,
the IRTF, and the Independent Submissions stream, each with clear
processes on how drafts are submitted and potentially approved for
publication as an RFC. Ultimately, the goal of the RFC Series is to
provide a canonical source for the material published by the RFC Editor,
and to support the preservation of that material in perpetuity. </t>
Today, over 8500 RFCs have been published, ranging across best practice
guidance, experimental protocols, informational material, and, of
course, Internet standards. Material is accepted for publication through
the IETF, the IAB, the IRTF, and the Independent Submissions streams,
each of which have clear processes on how drafts are submitted and
potentially approved for publication as an RFC. Ultimately, the goal of
the RFC Series is to provide a canonical source for the material
published by the RFC Editor and to support the preservation of that
material in perpetuity. </t>
<t>The RFC Editor as a role came a few years after the first RFC was <t>The RFC Editor as a role came a few years after the first RFC was
published. The actual date when the term was first used is unknown, but it published.
The actual date the term "RFC Editor" was first used is unknown, but it
was formalized by <xref target="RFC0902" format="default"/> in July 1984; was formalized by <xref target="RFC0902" format="default"/> in July 1984;
Jon Postel, the first RFC Editor, defined the role by his actions and Jon Postel, the first RFC Editor, defined the role by his actions and
later by defining the initial processes surrounding the publication of later by defining the initial processes surrounding the publication of
RFCs. What is certain is that the RFC Editor is responsible for making RFCs. What is certain is that the goal of the RFC Editor is to produce
sure that the editorial quality of the RFCs published is high, and that documents that are readable, clear, consistent, and reasonably uniform,
the archival record of what has been published is maintained. </t> and that the archival record of what has been published is maintained.
</t>
<t>Change does come to the Series, albeit slowly. First, we saw the <t>Change does come to the Series, albeit slowly. First, we saw the
distribution method change from postal mail to FTP and email. RFCs could distribution method change from postal mail to FTP and then to
not be distributed electronically email. RFCs could not be distributed electronically in the beginning, as
from the beginning, as the means to do that distribution would not be the means to do that distribution would not be defined until years after
defined until years after the first RFC was published. Not all early RFCs the first RFC was "published".
were even created electronically; some were written out by hand, or on a
typewriter. Eventually the process for creating RFCs became more Not all early RFCs were even created electronically; some were written
structured; authors were provided guidance on how to write an RFC. The out by hand or on a typewriter. Eventually, the process for creating
editorial staff went from one person, Jon Postel, to a team of five to RFCs became more structured; authors were provided guidance on how to
seven. The actual editing and publishing work split from the service for write an RFC. The editorial effort went from Steve Crocker to a more
official model with a designated editor, Jon Postel, and later to a team
of five to seven individuals.
The actual editing and publishing work split from the service for
registration of protocol code points. The whole RFC Editor structure was registration of protocol code points. The whole RFC Editor structure was
reviewed <xref target="RFC4844" format="default"/> and refined <xref reviewed <xref target="RFC4844" format="default"/>, refined <xref
target="RFC5620" format="default"/> and refined again <xref target="RFC5620" format="default"/>, and refined again <xref
target="RFC6635" format="default"/>. And, in the last few years, we have target="RFC6635" format="default"/>. And, in the last few years, the
started the process to change the format of the RFC documents process to change the format of the RFC documents themselves has
themselves.</t> started <xref target="RFC7990"/>.</t>
<t>This is evolution, and the Series will continue to adapt in order to <t>This is evolution; and the Series will continue to be adapted in order
meet the needs and expectations of the community of authors, operators, to
historians, and users of the RFC Series. These changes will be always be meet the needs and expectations of the implementers, operators, historians
,
and community of authors that uses the RFC Series. These changes will alwa
ys be
balanced against the core mission of the Series: to maintain a strong, balanced against the core mission of the Series: to maintain a strong,
stable, archival record of technical specifications, protocols, and other stable, archival record of technical specifications, protocols, and other
information relevant to the ARPANET and Internet networking information relevant to the Advanced Research Projects Agency Network (ARP ANET) and Internet networking
communities.</t> communities.</t>
<t>There is more to the history of the RFC Series than can be covered in <t>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 this document. Readers interested in earlier perspectives may find the
following RFCs of particular interest that focus on the enormous following RFCs of particular interest. These RFCs focus on the enormous
contributions of Jon Postel, Czar of Socket Numbers <xref target="RFC0433" contributions of Jon Postel, Czar of Socket Numbers <xref target="RFC0433"
format="default"/> and first RFC Editor: format="default"/> and first RFC Editor:
<!-- v2v3: Replaced <list style="empty"/> with <ul/> -->
</t> </t>
<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/
> split. --> <ul empty="false" spacing="normal">
<ul empty="true" spacing="normal">
<!-- v2v3: Replaced <t/> with <li/> --> <li><xref target="RFC2441" format="default"/>"Working with Jon,
<li> Tribute delivered at UCLA, October 30, 1998"</li>
<xref target="RFC2441" format="default"/>"Working with Jon, Tribute de
livered at UCLA"</li> <li><xref target="RFC2555" format="default"/>"30 Years of RFCs"</li>
<!-- v2v3: Replaced <t/> with <li/> -->
<li> <li><xref target="RFC5540" format="default"/>"40 Years of RFCs"</li>
<xref target="RFC2555" format="default"/>"30 Years of RFCs"</li>
<!-- v2v3: Replaced <t/> with <li/> -->
<li>
<xref target="RFC5540" format="default"/>"40 Years of RFCs"</li>
</ul> </ul>
<t> <t>
In this document, the history of the series is viewed through the eyes In this document, the history of the Series is viewed through the eyes
of several individuals who have been a part of shaping the Series. of several individuals who have been a part of shaping it.
Narratives of this nature offer a limited perspective on events; there Narratives of this nature offer a limited perspective on events; there
are almost certainly other viewpoints, memories, and perspective on are almost certainly other viewpoints, memories, and perspectives on
events that are equally valid and would reflect a different history. So, events that are equally valid and would reflect a different history. So,
while these retrospectives are enormously valuable and provide an while these retrospectives are enormously valuable and provide an
insight to events of the day, they are just one lens on the history of insight to events of the day, they are just one lens on the history of
the RFC Series. the RFC Series.
</t> </t>
<t>Steve Crocker, author of RFC 1, offers his <t>Steve Crocker, author of <xref target="RFC0001"/>, offers his
thoughts on how and why the Series began. Leslie Daigle, a major thoughts on how and why the Series began. Leslie Daigle, a major
influence in the development of the RFC Editor model, offers her influence in the development of the RFC Editor model, offers her
thoughts on the change of the RFC Editor to a stronger, contracted thoughts on the change of the RFC Editor to a stronger, contracted
function. Nevil Brownlee, Independent Submissions Editor from 2010 function. Nevil Brownlee, Independent Submissions Editor from 2010
through February 2018, shares his view on the clarification of the IS through February 2018, shares his view on the clarification of
and its transition from Bob Braden. As the current RFC Series Editor, I the Independent Stream (IS)
and its transition upon the retirement of Bob Braden from the position.
As the current RFC Series Editor, I
will put my thoughts in on the most recent changes in formalizing the will put my thoughts in on the most recent changes in formalizing the
digital preservation of the Series, the process to modernize the format digital preservation of the Series, the process to modernize the format
while respecting the need for stability, and my thoughts on the next while respecting the need for stability, and my thoughts on the next
fifty years of RFCs. fifty years of RFCs.
</t> </t>
<t>This document updates the perspectives offered in RFCs 2555 and 5540.</
t> <t>This document updates the perspectives offered in <xref
target="RFC2555"/> and <xref target="RFC5540"
/>.</t>
</section> </section>
<section anchor="keymoments" numbered="true" toc="default"> <section anchor="keymoments" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Key Moments in RFC History</name> <name>Key Moments in RFC History</name>
<table anchor="keymoments-table" align="center"> <table anchor="keymoments-table" align="center">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Key Moments in RFC History</name> <name>Key Moments in RFC History</name>
<thead> <thead>
<tr> <tr>
<th align="left">Marker</th> <th align="left">Marker</th>
<th align="left">Date</th> <th align="left">Date</th>
<th align="left">Event</th> <th align="left">Event</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC0001" format="default"/></td> <xref target="RFC0001" format="default"/>
<td align="left">1969</td> </td>
<td align="left">April 1969</td>
<td align="left">First RFC published</td> <td align="left">First RFC published</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC0114" format="default"/></td> <xref target="RFC0114" format="default"/>
<td align="left">1971</td> </td>
<td align="left">April 1971</td>
<td align="left">First distribution of RFCs over the network</td> <td align="left">First distribution of RFCs over the network</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC0433" format="default"/></td> <xref target="RFC0433" format="default"/>
</td>
<td align="left">December 1972</td> <td align="left">December 1972</td>
<td align="left">First mention of the Czar of Socket Numbers and the proposal for a formal registry</td> <td align="left">First mention of the Czar of Socket Numbers and the proposal for a formal registry</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC0690" format="default"/></td> <xref target="RFC0690" format="default"/>
</td>
<td align="left">June 1975</td> <td align="left">June 1975</td>
<td align="left">Relationship starts between ISI and the RFC Editor, <td align="left">Relationship starts between the Information Science
judging by Jon Postel's affiliation change</td> s
Institute (ISI) and the RFC Editor (judging by Jon Postel's affiliati
on change)</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC0748" format="default"/></td> <xref target="RFC0748" format="default"/>
<td align="left">March 1977</td> </td>
<td align="left">First April 1st RFC</td> <td align="left">April 1977</td>
<td align="left">First April 1st RFC published</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="IETF1" format="default"/></td> <xref target="IETF1" format="default"/>
<td align="left">January 1986</td> </td>
<td align="left">First Internet Engineering Task Force (IETF) meet <td align="left">January 1986</td>
ing</td> <td align="left">First Internet Engineering Task Force (IETF) meetin
g</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC1083" format="default"/></td> <xref target="IAB-19880712" format="default"/>
<td align="left">October 1989</td> </td>
<td align="left">Three stage standards process first defined</td> <td align="left">July 1988</td>
<td align="left">IAB approved the creation of an Internet-Draft seri
es</td>
</tr> </tr>
<tr>
<tr>
<td align="left"> <td align="left">
<xref target="RFC1122" format="default"/> <xref target="RFC1123" f <xref target="RFC1122" format="default"/>
ormat="default"/></td> <xref target="RFC1123" format="default"/>
</td>
<td align="left">December 1988</td> <td align="left">December 1988</td>
<td align="left">First major effort to review key specifications and write applicability statements</td> <td align="left">First major effort to review key specifications and write applicability statements</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC1150" format="default"/></td> <xref target="RFC1083" format="default"/>
</td>
<td align="left">October 1989</td>
<td align="left">Three-stage standards process first defined</td>
</tr>
<tr>
<td align="left">
<xref target="RFC1150" format="default"/>
</td>
<td align="left">March 1990</td> <td align="left">March 1990</td>
<td align="left">FYI sub-series started</td> <td align="left">FYI sub-series started</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC1311" format="default"/></td> <xref target="RFC1311" format="default"/>
</td>
<td align="left">March 1992</td> <td align="left">March 1992</td>
<td align="left">STD sub-series started</td> <td align="left">STD sub-series started</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC1818" format="default"/></td> <xref target="RFC1818" format="default"/>
</td>
<td align="left">August 1995</td> <td align="left">August 1995</td>
<td align="left">BCP sub-series started</td> <td align="left">BCP sub-series started</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC-ONLINE" format="default"/></td> <xref target="RFC-ONLINE" format="default"/>
<td align="left">(approx) 1998-2010</td> </td>
<td align="left">RFC Online Project to restore lost early RFCs</td> <td align="left">approx. 1998</td>
<td align="left">RFC Online Project to restore early RFCs
that were "lost" started</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="IAB-19880712" format="default"/></td> <xref target="RFC2441" format="default"/>
<td align="left">July 1988</td> </td>
<td align="left">IAB approved the creation of an Internet Draft seri <td align="left">15 October 1998</td>
es</td> <td align="left">Jon Postel's death</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC2441" format="default"/></td> <xref target="RFC4844" format="default"/>
<td align="left">15 October 1998</td> </td>
<td align="left">Jon Postel's death</td> <td align="left">July 2007 </td>
<td align="left">RFC Series administrative structure documented</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="ISI-to-AMS" format="default"/></td> <xref target="RFC4846" format="default"/>
</td>
<td align="left">July 2007</td>
<td align="left">Independent Submission document stream is formalize
d</td>
</tr>
<tr>
<td align="left">
<xref target="RFC5620" format="default"/>
</td>
<td align="left">August 2009</td>
<td align="left">RFC Editor organization officially established as
RFC Series Editor, Independent Submission Editor, RFC
Production Center, and RFC Publisher</td>
</tr>
<tr>
<td align="left">
<xref target="ISI-to-AMS" format="default"/>
</td>
<td align="left">October 2009</td> <td align="left">October 2009</td>
<td align="left">Transition starts from ISI to Association Managemen <td align="left">Transition of RFC Production Center and RFC Publish
t Solutions (AMS)</td> er
starts from Information Sciences Institute (ISI) to
Association Management Solutions (AMS)</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC4844" format="default"/></td> <xref target="RFC5540" format="default"/>
<td align="left">July 2007 </td> </td>
<td align="left">RFC Stream structure</td> <td align="left">January 2010</td>
<td align="left">Bob Braden retires from RFC Editor</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC4846" format="default"/></td> <xref target="RFC5743" format="default"/>
<td align="left">July 2007</td> </td>
<td align="left">Formalize the Independent Submission document strea <td align="left">December 2009</td>
m</td> <td align="left">Internet Research Task Force document stream formal
ized</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC5743" format="default"/></td> <xref target="RFC-ONLINE" format="default"/>
<td align="left">December 2009</td> </td>
<td align="left">Formalize the Internet Research Task Force document <td align="left">approx. 2010</td>
stream</td> <td align="left">RFC Online Project to restore early RFCs that
were "lost" finished</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC6360" format="default"/></td> <xref target="RFC6360" format="default"/>
</td>
<td align="left">August 2011</td> <td align="left">August 2011</td>
<td align="left">FYI sub-series ended</td> <td align="left">FYI sub-series ended</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC6410" format="default"/></td> <xref target="RFC6410" format="default"/>
</td>
<td align="left">October 2011</td> <td align="left">October 2011</td>
<td align="left">Two stage standards process formalized</td> <td align="left">Two-stage standards process formalized</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC6949" format="default"/></td> <xref target="RFC6635" format="default"/>
</td>
<td align="left">June 2012</td>
<td align="left">Updated responsibilities of RFC Series allocated
to RFC Series Editor, RFC Production Center, and RFC
Publisher</td>
</tr>
<tr>
<td align="left">
<xref target="RFC6949" format="default"/>
</td>
<td align="left">May 2013</td> <td align="left">May 2013</td>
<td align="left">RFC Format change project started</td> <td align="left">RFC format change project started</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<xref target="RFC8153" format="default"/></td> <xref target="RFC8153" format="default"/>
</td>
<td align="left">April 2017</td> <td align="left">April 2017</td>
<td align="left">RFCs no longer printed to paper upon publication</t d> <td align="left">RFCs no longer printed to paper upon publication</t d>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="perspectives" numbered="true" toc="default"> <section anchor="perspectives" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Perspectives</name> <name>Perspectives</name>
<section anchor="the-origins-of-rfcs-by-stephen-d-crocker" numbered="true" toc="default"> <section anchor="the-origins-of-rfcs-by-stephen-d-crocker" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>The Origins of RFCs - by Stephen D. Crocker</name> <name>The Origins of RFCs - by Stephen D.&nbsp;Crocker</name>
<t>[This is a revision of material included in <xref target="RFC1000" fo <t>(This is a revision of material included more than 30 years
rmat="default"/> August ago in <xref target="RFC1000"
1987, more than thirty years ago.]</t> format="default"/>.)</t>
<t>The Internet community now includes millions of nodes and billions of <t>The Internet community now includes millions of nodes and billions
users. of users. It owes its beginning to the ARPANET, which was once but a
It owes its beginning to the ARPANET, which was once but a gleam in the eyes of gleam in the eyes of J.&nbsp;C.&nbsp;R.&nbsp;Licklider, Bob Taylor,
J. C. R. Licklider, Bob Taylor, and Larry Roberts of ARPA. While much of the de and Larry Roberts of the Advanced Research Projects Agency (ARPA).
velopment proceeded While much of the development proceeded according to plan, the initial
according to plan, the initial design of the protocols and the creation of the design of the protocols and the creation of the RFCs was largely
RFCs was largely accidental.</t> accidental.</t>
<t>The procurement of the ARPANET was initiated in the summer of 1968 -- <t>The procurement of the ARPANET was initiated in the summer of 1968;
remember remember Vietnam, flower children, etc.? There had been prior
Vietnam, flower children, etc.? There had been prior experiments at various ARPA experiments at various ARPA sites to link together computer systems,
sites to link together computer systems, but this was the first version to but this was the first version to explore packet switching as a core
explore packet-switching as a core part of the communication strategy. ("ARPA" part of the communication strategy. ("ARPA" didn't become "DARPA"
didn't become "DARPA" until 1972. It briefly changed back to ARPA in 1993 and (Defense Advanced Research Projects Agency) until 1972. It briefly
then back again to DARPA.) The government's Request for Quotations (RFQ) changed back to ARPA in 1993 and then back again to DARPA.) The
called for four packet-switching devices, called Interface Message Processors government's Request for Quotations (RFQ) called for four
("IMPs"), to be delivered to four sites in the western part of the United packet-switching devices, called Interface Message Processors
States: University of California, Los Angeles (UCLA); SRI International in Menlo ("IMPs"), to be delivered to four sites in the western part of the
Park, CA; University United States: University of California, Los Angeles (UCLA); SRI Interna
of California, Santa Barbara; the University of Utah in Salt Lake City. These tional
sites, respectively, were running a Scientific Data Systems (SDS) Sigma 7, an (Stanford Research Institute) in Menlo Park, CA;
SDS 940, an IBM 360/75, and a DEC PDP-10. These machines not only had different University of California, Santa Barbara (UCSB); and the University of
operating systems, but even details like character sets and byte sizes varied, Utah in Salt Lake City. These sites were running a Scientific Data
and other sites would have further variations. </t> Systems (SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10,
<t>The focus was on the basic movement of data. The precise use of the respectively. These machines not only had different operating
ARPANET systems, but even details like character sets and byte sizes
was not spelled out in advance, thus requiring the research community to take varied. Other sites would have further variations. </t>
some initiative. To stimulate this process, a meeting was called in August 1968 <t>The focus was on the basic movement of data. The precise use of
with representatives from the selected sites, chaired by Elmer Shapiro from SRI. the ARPANET was not spelled out in advance, thus requiring the
Based on Shapiro's notes from that meeting, the attendees were Dave Hopper and research community to take some initiative. To stimulate this
Jeff Rulifson from SRI, Glen Culler and Gordon Buck from Santa Barbara, R. process, a meeting was called in August 1968 with representatives from
Stephenson, C. Stephen Carr and W. Boam from Utah, Vint Cerf and me from UCLA, the selected sites, chaired by Elmer Shapiro from SRI. Based on
and a few others from potential future sites.</t> Shapiro's notes from that meeting, the attendees were Dave Hopper and
<t>That first meeting was seminal. We had lots of questions. How IMPs Jeff Rulifson from SRI; Glen Culler and Gordon Buck from Santa
and Barbara; R. Stephenson, C. Stephen Carr, and W. Boam from Utah; Vint
"hosts" (I think that was the first time I was exposed to that term) would Cerf and me from UCLA; and a few others from potential future
be connected? What would hosts say to each other? What applications would be sites.</t>
supported? The only concrete answers were remote login as a replacement for
dial-up, telephone based interactive terminal access, and file transfer, but we <t>That first meeting was seminal. We had lots of questions. How
knew the vision had to be larger. We found ourselves imagining all kinds of would IMPs and "hosts" (I think that was the first time I was exposed
possibilities -- interactive graphics, cooperating processes, automatic data bas to that term) be connected? What would hosts say to each other? What
e applications would be supported? The only concrete answers were
query, electronic mail -- but no one knew where to begin. We weren't sure remote login as a replacement for dial-up, telephone-based interactive
whether there was really room to think hard about these problems; surely someone terminal access, and file transfer, but we knew the vision had to be
senior and in charge, likely from the East, would be along by and by to bring larger. We found ourselves imagining all kinds of possibilities:
the word. But we did come to one conclusion: we ought to meet again. Over the interactive graphics, cooperating processes, automatic database
next several months, we met at each of our sites, thereby setting the precedent query, electronic mail, etc., but no one knew where to begin. We weren'
for regular face to face meetings. We also instantly felt the irony. This new t
network was supposed to make it possible to work together at a distance, and the sure whether there was really room to think hard about these problems;
first thing we did was schedule a significant amount of travel.</t> surely someone senior and in charge, likely from the East, would be
<t>Over the next several months, a small, fairly consistent set of gradu along by and by to bring the word. But we did come to one conclusion:
ate we ought to meet again. Over the next several months, we met at each
students and staff members from the first four sites met. We used the term of our sites, thereby setting the precedent for regular face-to-face
Network Working Group (NWG) to designate ourselves. This was the same term meetings. We also instantly felt the irony. This new network was
Elmer Shapiro had used when he convened our first meeting, although it had been supposed to make it possible to work together at a distance, and the
used until that point to refer to the principal investigators and ARPA personnel first thing we did was schedule a significant amount of travel.</t>
disjoint from the prior group, except, of course, that each of us worked for one <t>Over the next several months, a small, fairly consistent set of
of the principal investigators.</t> graduate students and staff members from the first four sites met. We
<t>The first few meetings were quite tenuous, primarily because we weren used the term Network Working Group (NWG) to designate ourselves.
't sure This was the same term Elmer Shapiro had used when he convened our
how narrow or expansive our goals should be. We had no official charter or first meeting, although it had been used until that point to refer to
leadership, and it remained unclear, at least to me, whether someone or some the principal investigators and ARPA personnel: senior people who
group would show up with the official authority and responsibility to take over had been planning the network. Our group was junior and disjointed from
the problems we were dealing with. Without clear definition of what the the prior group, except, of course, that each of us worked for one of
host-IMP interface would look like, or even a precise definition of what the principal investigators.</t>
functions the IMP would provide, we focused on broader ideas. We envisioned the
possibility of application specific protocols, with code downloaded to user <t>The first few meetings were quite tenuous, primarily because we
sites, and we took a crack at designing a language to support this. The first weren't sure how narrow or expansive our goals should be. We had no
version was known as DEL, for "Decode-Encode Language" and a later version was official charter or leadership, and it remained unclear, at least to
called NIL, for "Network Interchange Language."</t> me, whether someone or some group would show up with the official
<t>In late 1968 Bolt Beranek and Newman (BBN) in Cambridge, MA won the c authority and responsibility to take over the problems we were dealing
ontract with. Without clear definition of what the host-IMP interface would
for the IMPs and began work in January 1969. A few of us flew to Boston in the look like, or even a precise definition of what functions the IMP
middle of February to meet the BBN crew. The BBN folks, led by Frank Heart, would provide, we focused on broader ideas. We envisioned the
included Bob Kahn, Severo Ornstein, Ben Barker, Will Crowther, Bernie Cosell and possibility of application-specific protocols, with code downloaded to
Dave Walden. They were organized, professional and focused. Their first user sites, and we took a crack at designing a language to support
concern was how to meet their contract schedule of delivering the first IMP to this. The first version was known as DEL, for "Decode-Encode
UCLA at the beginning of September and how to get bits to flow quickly and Language" and a later version was called NIL, for "Network Interchange
reliably. The details of the host-IMP interface were not yet firm; the Language".</t>
specification came a few months later as BBN Report 1822. In particular, BBN <t>In late 1968, Bolt Beranek and Newman (BBN) in Cambridge, MA won the
didn't take over our protocol design process, nor did any other source of contract for the IMPs and began work in January 1969. A few of us
authority appear. Thus, we doggedly continued debating and designing the flew to Boston in the middle of February to meet the BBN crew. The
protocols.</t> BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein, Ben
<t>A month later our small NWG met in Utah. As the meeting came toward Barker, Will Crowther, Bernie Cosell, and Dave Walden. They were
an end, organized, professional, and focused. Their first concern was how to
it became clear to us that we should start writing down our discussions. We had meet their contract schedule of delivering the first IMP to UCLA at
accumulated a few notes on the design of DEL and other matters, and we decided the beginning of September and how to get bits to flow quickly and
to put them together in a set of notes. We assigned writing chores to each of reliably. The details of the host-IMP interface were not yet firm;
us, and I took on the additional task of organizing the notes. Though I the specification came a few months later as BBN Report 1822. In
initiated the RFCs, my role was far less than an editor. Each of the RFCs were particular, BBN didn't take over our protocol design process, nor did
numbered in any other source of authority appear. Thus, we doggedly continued
sequence. The only rule I imposed was the note had to be complete before I debating and designing the protocols.</t>
assigned a number because I wanted to minimize the number of holes in the
sequence.</t> <t>A month later, our small NWG met in Utah. As the meeting came
toward an end, it became clear to us that we should start writing down
our discussions. We had accumulated a few notes on the design of DEL
and other matters, and we decided to put them together in a set of
notes. We assigned writing chores to each of us, and I took on the
additional task of organizing the notes. Though I initiated the RFCs,
my role was far less than an editor. Each of the RFCs were numbered
in sequence. The only rule I imposed was the note had to be complete
before I assigned a number because I wanted to minimize the number of
holes in the sequence.</t>
<t>I tried a couple of times to write a note on how the notes would be <t>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 organized, but I found myself full of trepidation. Would these notes
we were asserting authority we didn't have? Would we unintentionally offend look as if we were asserting authority we didn't have? Would we
whomever the official protocol designers were? Finally, unable to sleep, I unintentionally offend whomever the official protocol designers were?
wrote the a few humble words. The basic ground rules were that anyone could say Finally, unable to sleep, I wrote a few humble words. The basic
anything and that nothing was official. And to emphasize the point, I used Bill ground rules were that anyone could say anything and that nothing was
Duvall's suggestion and labeled the notes "Request for Comments." I never official. And to emphasize the point, I used Bill Duvall's suggestion
dreamed these notes would eventually be distributed through the very medium we and labeled the notes "Request for Comments". I never dreamed these
were discussing in these notes. Talk about Sorcerer's Apprentice!</t> notes would eventually be distributed through the very medium we were
<t>After BBN distributed the specification for the hardware and software discussing in these notes: talk about Sorcerer's
interface to the IMPs to the initial ARPANET sites, our attention shifted to Apprentice! (See <xref target="APPRENTICE"/>.)</t>
low-level matters. The ambitious ideas for automatic downloading of code
evaporated. It would be several years before ideas like mobile code, remote <t>After BBN distributed the specification for the IMP hardware and
procedure calls, ActiveX, JAVA and RESTful interfaces appeared.</t> software interface to the initial ARPANET sites, our attention shifted
<t>Over the spring and summer of that year we grappled with the detailed to low-level matters. The ambitious ideas for automatic downloading
problems of protocol design. Although we had a vision of the vast potential for of code evaporated. It would be several years before ideas like
intercomputer communication, designing usable protocols was another matter. We mobile code, remote procedure calls, ActiveX, JAVA, and
knew a custom hardware interface and a custom software addition in the operating Representational State Transfer (RESTful) interfaces appeared.</t>
system was going to be required for anything we designed, and we anticipated <t>Over the spring and summer of that year, we grappled with the
these would pose some difficulty at each of the sites. We looked for existing detailed problems of protocol design. Although we had a vision of the
abstractions to use. It would have been convenient if we could have made the vast potential for intercomputer communication, designing usable
network simply look like a regular device, e.g., a tape drive, but we knew that protocols was another matter. We knew a custom hardware interface and
wouldn't do. The essence of this network was peer-to-peer cooperation among the a custom software addition in the operating system was going to be
machines and the processes running inside them, not a central machine required for anything we designed, and we anticipated these would pose
controlling dependent devices. We settled on a virtual bit stream layer as the some difficulty at each of the sites. We looked for existing
basic building block for the protocols, but even back then we knew that some abstractions to use. It would have been convenient if we could have
applications like voice might need to avoid that layer of software. (Why a made the network simply look like a regular device, e.g., a tape
virtual bit stream instead of a virtual byte stream? Because each computer had drive, but we knew that wouldn't do. The essence of this network was
its own notion of how many bits were in a byte. Eight-bit bytes didn't become peer-to-peer cooperation among the machines and the processes running
standard until a few years later.)</t> inside them, not a central machine controlling dependent devices. We
<t>Over the next two years, we developed, exchanged, and implemented ide settled on a virtual bit stream layer as the basic building block for
as. I the protocols; but even back then, we knew that some applications like
took a leave from UCLA in June 1971 to spend time working at ARPA. Jon Postel voice might need to avoid that layer of software. (Why a virtual bit
took over the care and feeding of the RFCs, evolving the process and adding stream instead of a virtual byte stream? Because each computer had
collaborators over the next twenty-seven years.</t> its own notion of how many bits were in a byte. 8-bit bytes
<t>The rapid growth of the network and the working group also led to a l didn't become standard until a few years later.)</t>
arge <t>Over the next two years, we developed, exchanged, and implemented
pile of RFCs. When the 100th RFC was in sight, Peggy Karp at MITRE took on the ideas. I took a leave from UCLA in June 1971 to spend time working at
task of indexing them. That seemed like a large task then, and we could have ARPA. Jon Postel took over the care and feeding of the RFCs, evolving
hardly anticipated seeing more than a 1000 RFCs several years later, and the the process and adding collaborators over the next twenty-seven
evolution toward Internet Drafts yet later.</t> years.</t>
<t>The rapid growth of the network and the working group also led to a
large pile of RFCs. When the 100th RFC was in sight, Peggy Karp at
the MIT Research Establishment (MITRE) took on the task of indexing them
.
That seemed like a large task then, and we could have hardly
anticipated seeing more than 1000 RFCs several years later and the
evolution toward Internet-Drafts yet later.</t>
<t>When we first started working on the protocols, the network did not e xist. <t>When we first started working on the protocols, the network did not e xist.
Except for our occasional face-to-face meetings, RFCs were our only means of Except for our occasional face-to-face meetings, RFCs were our only means of
communication. In <xref target="RFC0003" format="default"/>, I set the bar as l ow as communication. In <xref target="RFC0003" format="default"/>, I set the bar as l ow as
possible:</t> possible:</t>
<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing < <aside>
t/> split. --> <t>
<ul empty="true" spacing="normal"> The content of a NWG note may be any thought,
<!-- v2v3: Replaced <t/> with <li/> -->
<li>The content of a NWG note may be any thought,
suggestion, etc. related to the HOST software or other aspect of the suggestion, etc. related to the HOST software or other aspect of the
network. Notes are encouraged to be timely rather than network. Notes are encouraged to be timely rather than
polished. Philosophical positions without examples or other specifics, polished. Philosophical positions without examples or other specifics,
specific suggestions or implementation techniques without introductory or specific suggestions or implementation techniques without introductory or
background explication, and explicit questions without any attempted answers background explication, and explicit questions without any attempted answers
are all acceptable. The minimum length for a NWG note is one sentence.</li> are all acceptable. The minimum length for a NWG note is one sentence.
<!-- v2v3: Replaced <t/> with <li/> --> </t>
<li>These standards (or lack of them) are stated explicitly for two re <t>
asons. 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 First, there is a tendency to view a written statement as ipso facto
authoritative, and we hope to promote the exchange and discussion of authoritative, and we hope to promote the exchange and discussion of
considerably less than authoritative ideas. Second, there is a natural considerably less than authoritative ideas. Second, there is a natural
hesitancy to publish something unpolished, and we hope to ease this hesitancy to publish something unpolished, and we hope to ease this
inhibition.</li> inhibition.
</ul> </t>
</aside>
<t>Making the RFCs informal was not only a way of encouraging participat ion; it <t>Making the RFCs informal was not only a way of encouraging participat ion; it
was also important in making the communication effective. One of the early 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 participants said he was having trouble writing and sending an RFC because his
institution wanted to subject them to publication review. These are not institution wanted to subject them to publication review. These are not
"publications," I declared, and the problem went away. Another small detail, "publications", I declared, and the problem went away. Another small detail,
handled instinctively and without debate, was the distribution model. Each 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 institution was required to send a copy directly to each of the other handful of
participating institutions. Each institution handled internal copies and participating institutions. Each institution handled internal copies and
distribution itself. Submission to a central point for redistribution was not distribution itself. Submission to a central point for redistribution was not
required, so as to minimize delays. SRI's Network Information Center, however, required so as to minimize delays. SRI's Network Information Center, however,
did maintain a central repository of everything and provided an invaluable did maintain a central repository of everything and provided an invaluable
record.</t> record.</t>
<t>We didn't intentionally set out to challenge the existing standards <t>We didn't intentionally set out to challenge the existing standards
organizations, but our natural mode of operation yielded some striking results. organizations, but our natural mode of operation yielded some striking
The RFCs are open in two important respects: anyone can write one for free and results. The RFCs are open in two important respects: anyone can
anyone get them for free. At the time, virtually everyone in the ARPANET write one for free and anyone can get them for free. At the time,
community was sponsored by the government, so there was little competition and virtually everyone in the ARPANET community was sponsored by the
no need to use documents as a way of raising money. Of course, as soon as we government, so there was little competition and no need to use
had email working on the ARPANET, we distributed RFCs electronically. When the documents as a way of raising money. Of course, as soon as we had
ARPANET became just a portion of the Internet, this distribution process became email working on the ARPANET, we distributed RFCs electronically.
worldwide. The effect of this openness is often overlooked. Students and young When the ARPANET became just a portion of the Internet, this
professionals all over the world have been able to download the RFCs, learn distribution process became worldwide. The effect of this openness is
about the many pieces of technology, and then build the most amazing software. often overlooked; even now, students and young professionals all over
And they still are. [They are also a fantastic resource for historians.]</t> the world have been able to download RFCs, learn about the technology
<t>Where will it end? The ARPANET begat the Internet and the underlying within, and in turn, build the most amazing software. (They are also
technology transitioned from the original host-host protocol to TCP/IP, but the a fantastic resource for historians.)</t>
superstructure of protocol layers, community driven protocol design, and the
RFCs continued. Through the many changes in physical layer technology - analog <t>Where will it end? The ARPANET begat the Internet, and the
copper circuits, digital circuits, fiber and wireless -- resulting in speed underlying technology transitioned from the original host-host
increases from thousands to billions of bits per second and a similar increase protocol to TCP/IP. But, the superstructure of protocol layers,
from thousands to billions of users, this superstructure, including the RFCs has community-driven protocol design, and RFCs continued. Through the
continued to serve the community. All of the computers have changed, as have changes in physical-layer technology, resulting in speed increases
all of the transmission lines. But the RFCs march on. Maybe I'll write a few from thousands to billions of bits per second, and similarly from
words for RFC 10,000.</t> thousands to billions of users, this superstructure, including the
<t>Quite obviously the circumstances have changed. Email and other media RFCs, has continued to serve the community. All of the computers have
are most changed, as have all of the transmission lines, but the RFCs march on.
often used for the immediate exchange of inchoate thoughts. Internet Drafts a Maybe I'll write a few words for RFC 10,000.</t>
re <t>Quite obviously, the circumstances have changed. Email and other
the means for exchanging substantial, albeit sometimes speculative content. And media are most often used for the immediate exchange of inchoate
RFCs are reserved for fully polished, reviewed, edited and approved thoughts. Internet-Drafts are the means for exchanging substantial,
specifications. Comments to RFCs are not requested, although usage-related albeit sometimes speculative, content, while RFCs are reserved for fully
discussions and other commentary on mailing lists often takes place nonetheless. polished, reviewed, edited, and approved specifications. Comments to
Rather than bemoan the change, I take it as a remarkable example of adaptation. RFCs are not requested, although usage-related discussions and other
RFCs continue to serve the protocol development community. Indeed, they are the commentary on mailing lists often take place nonetheless. Rather
bedrock of a very vibrant and productive process that has fueled and guided the than bemoan the change, I take it as a remarkable example of
Internet revolution.</t> adaptation. RFCs continue to serve the protocol development
community. Indeed, they are the bedrock of a very vibrant and
productive process that has fueled and guided the Internet
revolution.</t>
</section> </section>
<section anchor="rfcmgmtteam" numbered="true" toc="default"> <section anchor="rfcmgmtteam" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>The RFC Management and Editing Team - Vint Cerf</name> <name>The RFC Management and Editing Team - by Vint Cerf</name>
<t>As Steve Crocker mentions in Section 3.1, Jon Postel assumed the role <t>As Steve Crocker mentions in <xref
of RFC target="the-origins-of-rfcs-by-stephen-d-crocker"/>, Jon Postel
manager in 1971 when Steve left UCLA for ARPA. Jon took on this role in addition assumed the role of RFC manager in 1971 when Steve left UCLA for
to his subsequent "numbers Czar" responsibilities. Initially, his focus was ARPA. Jon took on this role in addition to his subsequent "numbers
largely on assigning RFC numbers to aspiring writers but with time, and as the Czar" responsibilities. Initially, his focus was largely on assigning
standardization of the ARPANET and Internet protocols continued apace, he began RFC numbers to aspiring writers, but with time, and as the
to serve in an editorial capacity. Moreover, as an accomplished software standardization of the ARPANET and Internet protocols continued apace,
engineer, he had opinions about technical content in addition to writing style he began to serve in an editorial capacity. Moreover, as an
and did not hesitate to exercise editorial discretion as would-be published accomplished software engineer, he had opinions about technical
authors presented their offerings for his scrutiny. As the load increased, he content in addition to writing style and did not hesitate to exercise
recruited additional "volunteer" talent, most notably Joyce K. Reynolds, a editorial discretion as would-be published authors presented their
fellow researcher at USC/ISI. Over the ensuing years, he also drafted Robert offerings for his scrutiny. As the load increased, he recruited
(Bob) Braden into the team and when Jon unexpectedly passed away in October 1998 additional "volunteer" talent, most notably Joyce K.&nbsp;Reynolds, a
(see <xref target="RFC2468" format="default"/>), Joyce and Bob undertook to carr fellow researcher at USC/ISI. Over the ensuing years, he also drafted
y on with the RFC work in his Robert (Bob) Braden onto the team, and when Jon unexpectedly passed
stead, adding Sandy Ginoza to the team. During the period when Jon and Joyce away in October 1998 (see <xref target="RFC2468" format="default"/>),
worked closely together, Joyce would challenge me to tell which edits had been Joyce and Bob undertook carrying on with the RFC work in his stead,
made by Jon and which by her. I found this impossible, so aligned were they in adding Sandy Ginoza to the team. During the period when Jon and Joyce
their editorial sensibilities. Sadly, three of these tireless Internauts have worked closely together, Joyce would challenge me to tell which edits
passed on and we have only the product of their joint work and Sandy Ginoza's had been made by Jon and which by her. I found this impossible, so
and others' corporate memory by which to recall history. </t> aligned were they in their editorial sensibilities. Sadly, three of
these tireless Internauts have passed on, and we have only the product
of their joint work and Sandy Ginoza's and others' corporate memory by
which to recall history. </t>
</section> </section>
<section anchor="formalizing-the-rfc-editor-model-leslie-daigle" numbered= "true" toc="default"> <section anchor="formalizing-the-rfc-editor-model-leslie-daigle" numbered= "true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Formalizing the RFC Editor Model - Leslie Daigle</name> <name>Formalizing the RFC Editor Model - by Leslie Daigle</name>
<t>I was the chair of the Internet Architecture Board, the board respons <t>I was the chair of the Internet Architecture Board, the board
ible for responsible for the general oversight of the RFC Series, at a
the general oversight of the RFC Series, at a particular inflection point in the particular inflection point in the evolution of all Internet
evolution of all Internet technology institutions. To understand what we did, technology institutions. To understand what we did, and why we had to,
and why we had to, let me first paint a broader picture of the arc of these let me first paint a broader picture of the arc of these
institutions.</t> institutions.</t>
<t>Like many others who were in decision-making roles in the mid -00's, <t>Like many others who were in decision-making roles in the mid '00s,
I wasn't I wasn't present when the Internet was born. The lore passed down to
present when the Internet was born. The lore passed down to me was that, out of me was that, out of the group of talented researchers that developed
the group of talented researchers that developed the core specifications and the core specifications and established the direction of the Internet,
established the direction of the Internet, different individuals stepped up to different individuals stepped up to take on roles necessary to keep
take on roles necessary to keep the process of specification development the process of specification development organized and open. As the
organized and open. As the work of specification expanded, those individuals work of specification expanded, those individuals were generally
were generally supported by organizations that carried on in the same spirit. supported by organizations that carried on in the same spirit. This
This was mostly Jon Postel, managing the allocation and assignment of names and was mostly Jon Postel, managing the allocation and assignment of names
numbers, as well as and numbers, as well as working as the editor of RFCs, but there were
working as the editor of RFCs, but there were also individuals and institutions also individuals and institutions supporting the IETF's Secretariat
supporting the IETF's Secretariat function. By the late 20th century, even this function. By the late 20th century, even this model was wearing thin;
model was wearing thin - the support functions were growing, and organizations the support functions were growing, and organizations didn't have the
didn't have the ability to donate even more resources to run them. In some cases ability to donate even more resources to run them. In some cases
(IANA) there was significant industry and international dependence on the (IANA), there was significant industry and international dependence on
function and its neutrality.</t> the function and its neutrality.</t>
<t>The IETF, too, had grown in size, stature, and commercial reliance. T <t>The IETF, too, had grown in size, stature, and commercial
his reliance. This system of institutional pieces "flying in formation"
system of institutional pieces "flying in formation" was not providing the kind was not providing the kind of contractual regularity or integrated
of contractual regularity or integrated development that the IETF needed. People development that the IETF needed. People who hadn't been there as the
who hadn't been there as the institutions developed, including IETF institutions developed, including IETF decision makers, didn't
decision-makers, didn't innately understand why things "had to be the way they innately understand why things "had to be the way they were" and were
were", and were frustrated when trying to get individual systems updated for new frustrated when trying to get individual systems updated for new
requirements, and better integrated across the spectrum of activities.</t> requirements as well as better integrated across the spectrum of
<t>Internet engineering had expanded beyond the point of being supportab activities.</t>
le by a <t>Internet engineering had expanded beyond the point of being
loosely-coupled set of organizations of people who had been there since the supportable by a loosely coupled set of organizations of people who
beginning and knew each other well. New forms of governance were needed, as had been there since the beginning and knew each other well. New forms
well as a rationalized funding model. The IANA function was absorbed into a purp of governance were needed along with a rationalized funding
ose-built model. The IANA function was absorbed into a purpose-built
international not-for-profit organization. The IETF stepped up to manage its own international not-for-profit organization. The IETF stepped up to
organizational destiny, creating the IETF Administrative Support Activity (IASA) manage its own organizational destiny, creating the IETF
, Administrative Support Activity (IASA), and the Secretariat became one
and the Secretariat became one of its contracted functions.</t> of its contracted functions.</t>
<t>This left the RFC Editor function as an Internet Society-supported, i <t>This left the RFC Editor function as an independent effort
ndependent supported by the Internet Society.</t>
effort.</t> <t>That independent nature was necessary for the historic role of the
<t>That independent nature was necessary for the historic role of the RF RFC Series in considering all technical contributions. But, at that
C inflection point in the Series' history, it needed a new governance
Series in considering all technical contributions. But, at that inflection point and funding model, just as the other organizations supporting
in the Series' history, it needed a new governance and funding model, just as Internet technical specification had. Also, the IETF leadership had some
the other Internet technical specification supporting organizations had. Also, concerns it felt needed to be addressed in its own technical
the IETF leadership had some concerns it felt needed to be addressed in its publication stream. While the RFC Series had been established before
own technical publication stream. While the RFC Series had been established there was an IETF, and had historically continued to have documents in
before there was an IETF, and had historically continued to have documents in it it that didn't originate from the IETF, the IETF was its largest and
that didn't originate from the IETF, the IETF was its largest and most organized most organized contributor. There was no particular organization of
contributor. There was no particular organization of independent contributors. independent contributors. Equally, the funding for the RFC Editor was
Equally, the funding for the RFC Editor was at that point coming from the at that point coming from the Internet Society in the guise of
Internet Society in the guise of "support for the IETF". For people who hadn't "support for the IETF". For people who hadn't been involved with the
been involved with the institution from the outset, it was pretty easy to institution from the outset, it was pretty easy to perceive the RFC
perceive the RFC Series uniquely as the IETF's publication series. So, the Series uniquely as the IETF's publication series. So, the challenge
challenge was to identify and address the IETF's issues, along with governance 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 and funding, without sacrificing the fundamental nature of the RFC
broader-than-IETF publication series.</t> Series as a broader-than-IETF publication series.</t>
<t>To give a sense of the kinds of tensions that were prevalent, let me <t>To give a sense of the kind of tensions that were prevalent, let
share me share that the one phrase that stuck in my mind from those
that the one phrase that sticks in my mind from those discussions is: "push to discussions was "push to publish". There were those in IETF leadership
publish". There were those in IETF leadership who felt that it would who felt that it would significantly reduce costs and improve
significantly reduce costs and improve timeliness if an RFC could be published timeliness if an RFC could be published by, literally, pushing a
by, literally, pushing a button on a web interface the moment it was approved by button on a web interface the moment it was approved by the IESG. It
the IESG. It would also, they argued, remove the specification issues being would also, they argued, remove the specification issues being
introduced by copy-editors that were hired as occasional workers to help with introduced by copy editors that were hired as occasional workers to
improving publication rates, but who weren't necessarily up to speed on terms of help with improving publication rates but who weren't necessarily up
art in technical specifications. (There were some pretty egregious examples of to speed on terms of art in technical specifications. (There were some
copyeditors introducing changes that significantly changed the technical meaning pretty egregious examples of copy editors introducing changes that
of the text that significantly changed the technical meaning of the text that I forbear
I forbear from citing here; let's just say it wasn't strictly a problem of 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 Internet engineers getting uptight about their cheese being moved.)
to publish" would have addressed those issues, it would not have addressed the While "push to publish" would have addressed those issues, it would
loss of clarity from the many significant text improvements copy editors not have addressed the loss of clarity from the many significant text
successfully introduced, or the fact that not all RFCs are approved by the improvements copy editors successfully introduced, or the fact that
IESG.</t> not all RFCs are approved by the IESG.</t>
<t>Institutionally, it was clear that the target was to have the RFC Edi <t>Institutionally, it was clear that the target was to have the RFC
tor Editor function governance within the reach of the Internet technical
function governance within the reach of the Internet technical community (as community (as opposed to any particular private organization) without
opposed to any particular private organization), without tying it specifically tying it specifically to the IETF. That was reasonably achievable by
to the IETF. That was reasonably achievable by ensuring that the resultant ensuring that the resultant pieces were established under the
pieces were established under the oversight of the IAB (which is, itself, oversight of the IAB (which is, itself, independent of the IETF even
independent of the IETF, even as it is supported by the IASA organization).</t> as it is supported by the IASA organization).</t>
<t>The IETF worked on a document outlining functional requirements for i <t>The IETF worked on a document outlining functional requirements for
ts its technical specification publication. This could have been useful
technical specification publication. This could have been useful for for establishing its own series, but it also was helpful in
establishing its own series, but it also was helpful in establishing awareness establishing awareness of the challenges in document publishing (it
of the challenges in document publishing (it always looks easy when you haven't always looks easy when you haven't thought about it) and also in
thought about it), and also to lay the ground work for dialogue with the RFC laying the groundwork for dialogue with the RFC Editor. The
Editor. The requirements document was published as <xref target="RFC4714" format requirements document was published as <xref target="RFC4714"
="default"/>, as format="default"/> as an Informational RFC that stands today to
an Informational RFC that stands today to provide guidance in the editing provide guidance in the editing processes surrounding IETF
processes surrounding IETF publications.</t> publications.</t>
<t>There was still, however, a certain lack of clarity about responsibil <t>There was still, however, a certain lack of clarity about
ities responsibilities for making decisions and changes in the RFC Series
for making decisions and changes in the RFC Series itself. To that end, I and itself. To that end, I and the IAB worked with the various involved
the IAB worked with the various involved parties to produce <xref target="RFC484 parties to produce <xref target="RFC4844" format="default"/>. That
4" format="default"/>. That document captured the RFC Series mission (for a purp document captured the RFC Series mission (for a purpose greater than
ose IETF technical specification publication) as well as the roles and
greater than IETF technical specification publication), as well as the roles and responsibilities of the parties involved. The RFC Editor is
responsibilities of the parties involved. The RFC Editor has responsibility for responsible for ensuring the implementation of the mission. The IAB
ensuring the implementation of the mission. The IAB continues to have oversight continues to have oversight responsibilities, including policy
responsibilities, including policy oversight, which it could act on by changing oversight, which it could act on by changing the person (organization)
the person (organization) in the role of RFC Editor. At the same time, in the role of RFC Editor. At the same time, operational oversight was
operational oversight was migrated to the IASA support function of the IETF (and migrated to the IASA support function of the IETF (and IAB).</t>
IAB).</t> <t>The discussions, and the resulting publication of <xref
<t>The discussions, and the resulting publication of RFC 4844, allowed g target="RFC4844"/>, allowed greater visibility into and commitment to
reater the RFC Series as a general Internet publication. It also meant that
visibility into and commitment to the RFC Series, as a general Internet subsequent adjustments could be made as requirements evolved; the
publication. It also meant that subsequent adjustments could be made, as responsible parties are clearly identified. </t>
requirements evolved - the responsible parties are clearly identified. </t>
</section> </section>
<section anchor="the-continuation-or-creation-of-a-stream-nevil-brownlee" <section
numbered="true" toc="default"> anchor="the-continuation-or-creation-of-a-stream-nevil-brownlee"
<!-- v2v3: Moved attribute title to <name/> --> numbered="true" toc="default">
<name>The Continuation, or Creation, of a Stream - Nevil Brownlee</name>
<t>Arguably starting in 2006 with <xref target="RFC4714" format="default <name>The Continuation, or Creation, of a Stream - by Nevil Brownlee</na
"/>, the IAB and the IETF community me>
spent some time in the mid-2000's evolving the structure of the RFC Series. This <t>Arguably starting in 2006 with <xref target="RFC4714"
work format="default"/>, the IAB and the IETF community spent some time in
included defining how those groups that published into the RFC Series (initially the mid-'00s evolving the structure of the RFC Series. This work
including the IETF, the IAB <xref target="RFC4845" format="default"/>, and the I included defining how those groups that published into the RFC Series
ndependent Submissions (initially including the IETF, the IAB <xref target="RFC4845"
stream <xref target="RFC4846" format="default"/>, and later growing to include t format="default"/>, and the Independent Submissions Stream <xref
he IRTF <xref target="RFC5743" format="default"/>) target="RFC4846" format="default"/>, and later growing to include the
would handle approving documents to be published as RFCs. In 2009, the IAB publi IRTF <xref target="RFC5743" format="default"/>) would handle approving
shed documents to be published as RFCs. In 2009, the IAB published "RFC
'RFC Editor (Version 1)' <xref target="RFC5620" format="default"/>. In this mod Editor Model (Version 1)" <xref target="RFC5620" format="default"/>. In
el, a new role was this model, a new role was created within the RFC Editor: the RFC
created within the RFC Editor, the RFC Series Editor (RSE), an individual that w Series Editor (RSE). This individual would oversee RFC publishing
ould oversee RFC and development while leaving the process for approving documents for
publishing and development, while leaving the process for approving documents fo publication outside his or her mandate. While, arguably, this was a role
r publication long filled by people like Jon Postel, Bob Braden, and Joyce Reynolds,
outside his or her mandate. While arguably this was a role long filled by people <xref target="RFC5620"/> saw the role of RFC Series Editor defined in
like Jon Postel, such a way as to distinctly separate it from that of the Independent
Bob Braden, and Joyce Reynolds, RFC 5620 saw the role of RFC Series Editor defin Submissions Editor (ISE). </t>
ed in such a
way as to distinctly separate it from that of the Independent Submissions Editor <t>Before 2009, the RFC Editor could accept "Independent" submissions
(ISE). </t> from individuals and, if they were judged significant, publish them as
<t>Before 2009 the RFC Editor could accept 'Independent' submissions fro RFCs; the Independent Stream was set up to continue that function.
m From February 2010 through February 2018, I was the ISE. After reading
individuals, and - if he judged they were significant - publish them as RFCs; <xref target="RFC4846" format="default"/>, I went on to develop the
the Independent Stream was set up to continue that function. From February 2010 Independent Stream (IS).</t>
through February 2018, I was the Independent Stream Editor (ISE) and I began by <t>First, I spent several days at the RFC Production Center at the
reading <xref target="RFC4846" format="default"/>, then went on to develop the I Information Sciences Institute (ISI) in Marina Del Ray with the RFC
ndependent Stream (IS).</t> Editor (Bob Braden), Sandy Ginoza, and Alice Hagens so as to learn how
<t>First I spent several days at the RFC Production Centre at ISI in Mar RFCs were actually edited and published. All RFCs reach the Production
ina Del Center as Internet-Drafts; they are copy edited until the edited
Ray with the RFC Editor (Bob Braden) and Sandy Ginoza and Alice Hagens, so as to version can be approved by its authors (AUTH48). At any stage,
learn how RFCs were actually edited and published. All RFCs reach the Production authors can check their draft's status via the RFC Editor website.</t>
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 <t>For the Independent Submissions, Bob kept a journal (a simple ASCII
draft's status in the RFC Editor Database.</t> file) of his interactions with authors for every draft, indexed by the
<t>For the Independent Submissions, Bob kept a journal (a simple ASCII f draft name. Bob also entered the Independent drafts into the RFC
ile) of Editor database so that authors could track their draft's
his interactions with authors for every draft, indexed by the draft name. Bob status. After my few days with his team at ISI, he handed that journal
also entered the Independent drafts into the RFC Editor database, so that (covering about 30 drafts) over to me and said, "Now it's over to
authors could track their draft's status. After my few days with his team at you!"</t>
ISI, he handed that journal (covering about 30 drafts) over to me and said <t>I began by following in Bob's footsteps, maintaining a journal and
"now it's over to you!"</t> tracking each draft's status in the RFC Editor database. My first
<t>I began by following in Bob's footsteps, maintaining a journal and tr consideration was that every serious Internet-Draft submitted needed
acking several careful reviews. At that time, if the ISE knew of suitable revi
each draft's status in the RFC Editor database. My first consideration was that ewers, he or
every serious Internet draft submitted needs several careful reviews. If the she could simply ask them. Otherwise, if the draft related to an IETF
ISE knows suitable reviewers, he can simply ask them. Otherwise, if the draft or IRTF Working Group, the ISE could ask Working Group Chairs or Area
relates to an IETF or IRTF Working Group, he can ask Working Group chairs or Directors to suggest reviewers. The Independent Submissions Editorial
Area Directors to suggest reviewers. As well, the ISE has an Independent Board (Ed Board) was another place the ISE could request reviewers from.
Submissions Editorial Board (Ed Board) that he can ask for reviewers. My My experience with reviewers was that most of those I approached were
experience with reviewers was that most of those I approached were happy to happy to help.</t>
help.</t>
<t>Most drafts were straightforward, but there were some that needed ext <t>Most drafts were straightforward, but there were some that needed
ra extra attention. Often, a draft requested IANA code points, and for
attention. Often a draft requests IANA code points, and for that IANA were alway that, IANA was always quick to offer help and support. Code points in
s some IANA registries require Expert Review <xref target="RFC8126"/>;
quick to offer help and support. Code points in some IANA Registries sometimes the interactions with Expert Reviewers took quite a long
require Expert Review - sometimes the interactions with Expert reviewers took time! Again, sometimes a draft seemed to fit better in the IETF
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
Stream; for these I would suggest that the draft authors try to find an Area an Area Director to sponsor their work as an individual submission to
Director to sponsor their work as in Individual submission to the IETF the IETF Stream.</t>
Stream.</t> <t>After my first few years as ISE, the IETF Tools Team developed the
<t>After my first few years as ISE, the IETF Tools Team developed the Da Datatracker <xref target="DATATRACKER"/> to show draft status and
ta perform all the "housekeeping" tasks for all of the streams. At that
Tracker so that it could keep show draft status, and perform all the stage, I switched to using the Datatracker rather than the RFC Editor
'housekeeping' tasks for all of the streams. At that stage I switched to use database.</t>
the Data Tracker rather than the RFC Editor database.</t>
<t>Once a draft has been reviewed, and the authors have revised it in di <t>Once a draft has been reviewed and the authors have revised it in
alogue dialogue with their reviewers, the ISE must submit that draft to the
with their reviewers, the ISE must submit that draft to the IESG for their IESG for an "IESG Review" <xref target="RFC5742"
"Conflict Review" <xref target="RFC5742" format="default"/>. Overall, each IS dr format="default"/>. Overall, each IS draft benefited from discussions
aft benefited from discussions (which were usually simple) with my Ed Board and the IESG. A (very)
(which were usually simple) with my Ed Board and the IESG. A (very) few drafts few were somewhat controversial; for those, I was able to work
were somewhat controversial - for those I was able to work with the IESG to with the IESG to negotiate a suitable "IESG Statement" and/or an "ISE
negotiate a suitable 'IESG Statement' and/or an 'ISE Statement' to make it Statement" to make it clear why the ISE published the draft.</t>
clearer why the ISE published the draft.</t> <t>One rather special part of the Independent Stream is the April 1st
<t>One rather special part of the Independent Stream is the April First RFCs. These are humorous RFCs that have no formal review and approval
drafts. process. The authors must send them directly to the ISE or the RFC
These are humorous RFCs that are never formally posted as drafts and which have Editor. Only a few of them can be published each year, and each is
no formal reviewed by the ISE and the RSE. Bob Braden's criteria for April 1st
review process. The authors must send them directly to the ISE or the drafts were:
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:
<!-- v2v3: Replaced <list style="empty"/> with <ul/> -->
</t> </t>
<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <
t/> split. --> <ul empty="false" spacing="normal">
<ul empty="true" spacing="normal">
<!-- v2v3: Replaced <t/> with <li/> --> <li> They must relate to the Internet (like all drafts).</li>
<li> They must relate to the Internet (like all drafts)</li>
<!-- v2v3: Replaced <t/> with <li/> --> <li> Their readers should reach the end of page two before realizing i
<li> Their readers should reach the end of page two before realizing t t is an April 1st RFC.</li>
his is an April First RFC</li>
<!-- v2v3: Replaced <t/> with <li/> -->
<li> They must actually be funny!</li> <li> They must actually be funny!</li>
</ul> </ul>
<t> <t>
April First RFCs have a large following, and feedback from the Internet communit April 1st RFCs have a large following, and feedback from the Internet
y on community on April 1st of each year has been enthusiastic and quick! </t>
1 April each year has been enthusiastic and quick! </t> <t>159 RFCs were published in the Independent Stream during my eight
<t>I published 159 Independent Stream RFCs during my eight years as ISE. years as ISE. Over those eight years, I worked with most of their
Over authors and often met with them at IETF meetings. For me, that was a
those eight years I worked with, and often met with at IETF meetings, most of very rewarding experience, so I thank all those that
their authors. For me that was a very rewarding experience, so I thank all contributed. During those eight years, I also worked with most of the
those contributors. Also, I've worked with most of the IESG members during those IESG members, who all also gave me a lot of helpful
eight years, that also gave me a lot of helpful interaction. Last, I've always interaction. Lastly, I've always enjoyed working with the RSE and all
enjoyed working with the RFC Editor, and all the staff of the RFC Production the staff of the RFC Production Center.
Centre. The IETF (as a whole) is very fortunate to have such an effective team
of talented Professional Staff.</t> The IETF (as a whole) is very fortunate to have such an
effective team of talented professional staff.</t>
</section> </section>
<section anchor="a-view-from-inside-the-rfc-editor-sandy-ginoza" numbered= "true" toc="default"> <section anchor="a-view-from-inside-the-rfc-editor-sandy-ginoza" numbered= "true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>A View from Inside the RFC Editor - Sandy Ginoza</name> <name>A View from inside the RFC Editor - by Sandy
<t>When I joined ISI, shortly after Jon Postel passed away, the RFC Edit Ginoza</name>
or as
we know it today (as defined in RFC 5620, and as obsoleted by <xref target="RF <t>When I joined ISI, shortly after Jon Postel passed away,
C6548" format="default"/> and the RFC Editor model as
RFC 6635) did not exist. The RFC Editor functioned as one unit; there was no we know it today (as defined in <xref target="RFC5620"/> and as obsoleted by <
RSE, Production Center, Publisher, or Independent Submissions Editor. All of xref target="RFC6548" format="default"/> and
these roles were performed by the RFC Editor, which was comprised of four <xref target="RFC6635"/>) did not exist. The RFC Editor functioned as one unit
individuals: Bob Braden, Joyce Reynolds, a part-time student programmer, and : there was no
me. RSE, Production Center, Publisher, or Independent Submissions
Editor.
All of these roles were performed by the "RFC Editor", which was comprised
of four individuals: Bob Braden, Joyce Reynolds, a part-time student
programmer, and me.
</t> </t>
<t>Bob provided high-level guidance and reviewed Independent Submissions <t>Bob provided high-level guidance and reviewed Independent
. While Submissions. While Bob was a researcher in "Div 7" (Networking) at
Bob was a researcher in "Div 7" (Networking) at ISI, ostensibly, the ISI, ostensibly, the percentage of time he had for the RFC Editor was
percentage of time he had for the RFC Editor was 10%, but he invested much 10%, but he invested much more time to keep the Series running. He
more time to keep the series running. He pitched in where he could, pitched in where he could, especially when processing times were
especially when processing times were getting longer; at one point, he even getting longer; at one point, he even NROFFed a couple of RFCs-to-be.
NROFFed a couple of RFCs-to-be. Joyce was a full-time employee, but while
continuing to ensure RFCs were published and serve as a User Services Area
Director and a keynote speaker about the Internet, she was also temporarily
on loan to IANA for 50% of her time while IANA was getting established after
separating from ISI. The student programmer performed programming tasks as
requested and was, at the time, responsible for parsing MIBs. I was a
full-time staffer and had to quickly learn the ropes so RFCs would continue
to be published.
</t> </t>
<t>My primary tasks were to manage the publication queue, format and pre <t> Joyce was a full-time ISI employee. However, while continuing to
pare ensure RFCs were published, she was also serving as a User Services Area
documents for Joyce's review, carry out AUTH48 once Joyce completed her Director and a keynote speaker about the Internet, and she was also
review, and publish, index, and archive the RFCs (both soft and hard copies). temporarily on loan to IANA for 50% of her time while IANA was getting
established after separating from ISI. The student programmer performed
programming tasks as requested and was, at the time, responsible for
parsing MIBs.
</t>
<t> I was a full-time staffer and had to quickly learn the ropes so
RFCs would continue to be published. My primary tasks were to manage
the publication queue, format and prepare documents for Joyce's
review, carry out AUTH48 once Joyce completed her review, and publish,
index, and archive the RFCs (both soft and hard copies).
</t> </t>
<t>The workload increased significantly over the next few years. As the <t>The workload increased significantly over the next few years. As the
workload increased, the RFC Editor reacted and slowly grew their staff over workload increased, the RFC Editor reacted and slowly grew their staff over
time. To understand the team growth, let's first take a look at the time. To understand the team growth, let's first take a look at the
publication rates throughout history. The table below shows average annual publication rates throughout history. The table below shows average annual
publication rates during 5-year periods. publication rates during 5-year periods.
</t> </t>
<table anchor="AvgPubs" align="center"> <table anchor="AvgPubs" align="center">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Annual Publication Rates</name> <name>Annual Publication Rates</name>
<thead> <thead>
<tr> <tr>
<th align="center">Years</th> <th align="center">Years</th>
<th align="center">Avg Pubs per Year</th> <th align="center">Avg. Pubs per Year</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">1969 - 1972</td> <td align="center">1969 - 1972</td>
<td align="center">80</td> <td align="center">80</td>
</tr> </tr>
<tr> <tr>
<td align="center">1973 - 1977</td> <td align="center">1973 - 1977</td>
<td align="center">55</td> <td align="center">55</td>
skipping to change at line 802 skipping to change at line 956
<tr> <tr>
<td align="center">2008 - 2012</td> <td align="center">2008 - 2012</td>
<td align="center">333</td> <td align="center">333</td>
</tr> </tr>
<tr> <tr>
<td align="center">2013 - 2017</td> <td align="center">2013 - 2017</td>
<td align="center">295</td> <td align="center">295</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>There were significant jumps in the publication rates in the 90s and onward, <t>There were significant jumps in the publication rates in the '90s and onward,
with the number of publications almost doubling between 1993 and 2007. The with the number of publications almost doubling between 1993 and 2007. The
annual submission count surpassed the 300 mark for the first time in 2004 and annual submission count surpassed the 300 mark for the first time in 2004 and
reached an all-time high of 385 in 2011. The submission rate did not drop reached an all-time high of 385 in 2011. The submission rate did not drop
below 300 until 2016 (284). below 300 until 2016 (284).
</t> </t>
<t>As the submissions grew, the RFC Editor experienced growing pains. Pr ocessing <t>As the submissions grew, the RFC Editor experienced growing pains. Pr ocessing
times began to increase as the existing staff was unable to keep up with the times began to increase as the existing staff was unable to keep up with the
expanding queue size. In an attempt to reduce the training hump and to avoid expanding queue size. In an attempt to reduce the training hump and to avoid
permanently hiring staff in case the submission burst was a fluke, ISI brought permanently hiring staff in case the submission burst was a fluke, ISI brought
on temporary copy editors - this way, the staff could easily be resized as on temporary copy editors; this way, the staff could easily be resized as
needed. However, as Leslie noted, this didn't work very well. The effects of needed. However, as Leslie noted, this didn't work very well. The effects of
the experiment would be lasting, as this led to a form of the process we have the experiment would be lasting, as this led to a form of the process we have
now, where the RFC Editor asks more questions during AUTH/AUTH48 and technical now, where the RFC Editor asks more questions during AUTH/AUTH48 and technical
changes require approval from the relevant Area Directors or stream managers, changes require approval from the relevant Area Directors or stream managers,
depending on the document stream. These changes added depending on the document stream. These changes added
to the workload and extended publication times; many often now jokingly refer to the workload and extended publication times; many often now jokingly refer
to AUTH48 as the authors' "48 days", "48 weeks", etc. to AUTH48 as the authors' "48 days", "48 weeks", etc.
</t>
<t>In addition to the increase in document submissions, we
engaged in tools testing and went through several editorial
process changes. Because of the lesson learned with temporary
copy editors, our team grew to be more permanent. While we added other
editors in between, two additions are of particular interest, as they
experienced much of the RFC Editor's growing pains, helped work us out
of a backlogged state, shaped the RFC Editor function, and are still
with the team today: Alice Russo joined the team in 2005 and Megan
Ferguson joined us in 2007.
</t> </t>
<t>Because the workload continued to increase (in more ways than just do <t>With the understanding that the record-breaking number of submissions
cument was not an
submissions; tool testing, editorial process changes, and more) and the lesson
s
learned with temporary copy editors, our team
grew more permanently. While we had other editors in between, two additions
are of particular interest, as they experienced much of the RFC Editor's
growing pains, helped work us out of a backlogged state, shaped the RFC Editor
function, and are still with the team today: Alice Russo joined the team in
2005 and Megan Ferguson joined us in 2007.
</t>
<t>With the understanding that the record breaking number of submissions
was not an
anomaly, we made significant upgrades to the infrastructure of the RFC Editor anomaly, we made significant upgrades to the infrastructure of the RFC Editor
function to facilitate document tracking and reporting. For example, the function to facilitate document tracking and reporting. For example, the
illustrious "black binder" - an actual 3-ring binder used to track number illustrious "black binder" (an actual 3-ring binder used to track
assignment, a manually edited HTML file for the queue page, and a Rube-Goldber RFC number
g assignment), a manually edited HTML file for the queue page, and a
Rube Goldberg
set of text files and scripts that created queue statistics, all were eventual ly set of text files and scripts that created queue statistics, all were eventual ly
replaced; an errata system was proposed and implemented; and XML became a newl y replaced; an errata system was proposed and implemented; and XML became a newl y
accepted source file. accepted source file.
</t> </t>
<t>In 2009, RFC 5620 was published, introducing the initial version of t he RFC <t>In 2009, <xref target="RFC5620"/> was published, introducing the init ial version of the RFC
Editor model we have now. While it was published in 2009, it did not go into Editor model we have now. While it was published in 2009, it did not go into
effect until 2010, when the RFC Editor project as I knew it was disbanded and effect until 2010, when the RFC Editor project as I knew it was disbanded and
divvied up into four pieces: RFC Series Editor (RSE), Independent Submissions divvied up into four pieces: RFC Series Editor (RSE), Independent Submissions
Editor (ISE), RFC Production Center (RPC), and Publisher. In addition, the Editor (ISE), RFC Production Center (RPC), and the Publisher function. In add ition, the
RFC Series Advisory Group (RSAG) was created to "provide expert, informed RFC Series Advisory Group (RSAG) was created to "provide expert, informed
guidance (chiefly, to the RSE) in matters affecting the RFC Series operation guidance (chiefly, to the RSE) in matters affecting the RFC Series operation
and development." and development" <xref target="RSAG"/>.
</t> </t>
<t>In 2010, the RPC and Publisher contracts were awarded to Association
Management Systems (AMS); we <t>In 2010, the RPC and Publisher contracts were awarded to
started with three existing team members (Alice Russo, Megan Association Management Solutions (AMS). There, we started with three ex
Ferguson, and me) and we were pleased to be joined by Lynne isting
Bartholomew, a new colleague to anchor us in the AMS office, and team members (Alice Russo, Megan Ferguson, and me), and we were pleased
later Rebecca VanRheenen shortly thereafter. to be joined by Lynne Bartholomew and Rebecca VanRheenen, new colleagues
to anchor us in the
AMS office.
</t> </t>
<t>I was wary of this model and was especially worried about the hole Bo b <t>I was wary of this model and was especially worried about the hole Bo b
Braden's departure would create. Luckily for us, Bob Braden provided wise Braden's departure would create. Luckily for us, Bob Braden provided wise
counsel and insight during the transition (and beyond). He gave the staff counsel and insight during the transition (and beyond). He gave the staff
transitioning to AMS particularly helpful parting words - "keep the RFCs transitioning to AMS particularly helpful parting words, "keep the RFCs
coming" - and that is what we did. coming", and that is what we did.
</t> </t>
<t>AMS embraced the RFC Series and helped us quickly get set up on new s ervers. <t>AMS embraced the RFC Series and helped us quickly get set up on new s ervers.
The RFC Production Center and Publisher were now part of the AMS family and The RFC Production Center and Publisher were now part of the AMS family and
it was all hands on deck to make sure the transition went smoothly to minimize it was all hands on deck to make sure the transition went smoothly to minimize
the impact on document processing. the impact on document processing.
</t> </t>
<t>Our focus during transition was to 1) keep the trains running; that i <t>Our focus during transition was to 1) keep the trains running; that
s, we is, we wanted to get ourselves up and running with minimal down time,
wanted to get ourselves up and running with minimal down time and 2) work with and 2) work with the Transitional RSE (a role that concluded before
the Transitional RSE, the Independent Submissions Editor (Nevil Brownlee), the transition ended), the ISE (Nevil Brownlee), RSAG, and the IETF
RSAG, and the IETF Administrative Director (IAD) to better understand and Administrative Director (IAD) to better understand and implement the
implement the newly defined RFC Editor model. newly defined RFC Editor model.
</t>
<t>Though some portions of the transition were challenging and lasted lo
nger
than expected, the Acting RSE (Olaf Kolkman) officially handed the reins over
to the RSE
(Heather Flanagan) in 2012. She had to jump in, learn the RFC Editor and IETF
culture, and work through a backlog of issues that had been left unattended.
</t>
<t>Two of the backlogged issues were so old, they were ones someone aske
d me
about at my first IETF: when is the RFC Editor going to allow non-ASCII
characters in RFCs, and when will the RFC Editor adopt a more modern
publication format.
</t> </t>
<t>At that time, while we understood the desire to move toward supportin
g a <t>Though some portions of the transition were challenging and lasted
broader range of character sets and to longer than expected, the Acting RSE (Olaf Kolkman) officially handed
have more modern outputs, we also routinely received emails from individuals the reins over to the new RSE (Heather Flanagan) in 2012. She had to
requesting that we send them plain-text files (instead of pointing them to the jump in, learn the RFC Editor and IETF culture, and work through a
website) because their Internet access was limited. We also regularly backlog of issues that had been left unattended.
received complaints from rfc-editor.org users whenever something on the site
didn't work correctly with their older browsers. In short, we could not
advance without leaving a large number of users behind.
</t> </t>
<t>However, we now find ourselves on the precipice of change. 2019 prom
ises to <t>Two of the backlogged issues were so old that they were ones someone
be a BIG year for the RFC Series, as we expect to transition from publishing had asked me about at my first IETF meeting: When was the RFC Editor goi
plaintext, ASCII-only files to publishing multiple file formats (XML, HTML, ng to
PDF/A-3, and TXT) that allow both non-ASCII characters and SVG art. allow non-ASCII characters in RFCs? When would the RFC Editor adopt
a more modern publication format?
</t> </t>
<t>At that time, while we understood the desire to move toward
supporting a broader range of character sets and having more-modern
outputs, we also routinely received emails from individuals requesting
that we send them plaintext files (instead of pointing them to the
website) because their Internet access was limited. We also regularly
received complaints from users of <eref target="https://www.rfc-editor.o
rg" brackets="angle"/>
whenever something on the site didn't work correctly with their
older browsers. In short, we could not advance without leaving a
large number of users behind.
</t>
<t>However, we now find ourselves on the precipice of change. The next
few years promise to be exciting for the RFC Series as we transition
from publishing plaintext, ASCII-only files to publishing multiple
file formats (XML, HTML, PDF/A-3, and TXT) that allow both non-ASCII
characters and SVG art.
</t>
<t>Interestingly enough, I find that the RFC Editor has been in an almos t <t>Interestingly enough, I find that the RFC Editor has been in an almos t
constant state of change since I joined the team, even though the goal of the constant state of change since I joined the team, even though the goal of the
RFC Editor remains the same: to produce archival quality RFCs in a timely RFC Editor remains the same: to produce archival quality RFCs in a timely
manner that are easily accessible for future generations. manner that are easily accessible for future generations.
</t> </t>
</section> </section>
</section> </section>
<section anchor="the-next-fifty-years-of-rfcs" numbered="true" toc="default" > <section anchor="the-next-fifty-years-of-rfcs" numbered="true" toc="default" >
<!-- v2v3: Moved attribute title to <name/> -->
<name>The Next Fifty Years of RFCs</name> <name>The Next Fifty Years of RFCs</name>
<t>As Steve Crocker mentioned, the Series began with a goal of communicati <t>As Steve Crocker mentioned, the Series began with goals of communicatio
on n
over formality, openness over structure. As the Internet has grown and becom over formality and openness over structure. As the Internet has grown and be
e a come a
pervasive, global construct, we still aim for openness and communication, bu t pervasive, global construct, we still aim for openness and communication, bu t
recognize that for protocols and other information to support interoperabili ty, recognize that for protocols and other information to support interoperabili ty,
there must be points of stability to build from. Small-time app developers t there must be points of stability to build from. Everyone, from small-time a
o pp developers to
multi-billion dollar companies are on the same footing. Anyone should be abl multi-billion dollar companies, is on the same footing. Anyone should be abl
e to look back e to look back
at a point in time and understand what was done, and why. at a point in time and understand what was done and why.
</t> </t>
<t>While the informality has given way to increased structure, the opennes s and <t>While the informality has given way to increased structure, the opennes s and
solid foundation that the Series provides must continue. With that in mind, solid foundation that the Series provides must continue. With that in mind,
what is next for the next fifty years of RFCs? what does the future hold for the next fifty years of RFCs?
</t> </t>
<section anchor="preservation" numbered="true" toc="default"> <section anchor="preservation" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Preservation</name> <name>Preservation</name>
<t>The RFC Editor exists to edit, publish, and maintain an archive of do cuments <t>The RFC Editor exists to edit, publish, and maintain an archive of do cuments
published in the RFC Series. A proper digital archive, however, is more than 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 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 of digital preservation has grown and transformed into an industry in and of
itself. "Digital Preservation Considerations for the RFC Series" <xref targe t="RFC8153" format="default"/> itself. "Digital Preservation Considerations for the RFC Series" <xref targe t="RFC8153" format="default"/>
reviews what a digital archive means today and describes ways to support the reviews what a digital archive means today and describes ways to support the
archive into the future, and recommends ways for the RFC Editor to take archive into the future. It also recommends ways for the RFC Editor to take
advantage of those organizations that specialize in this field.</t> advantage of those organizations that specialize in this field.</t>
<t>The future of digital preservation as far as the RFC Series is concer ned <t>The future of digital preservation, as far as the RFC Series is conce rned,
will mean both finding new partners that can absorb and archive RFCs into 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 a public, maintained digital archive and reviewing the RFC format to ensure
that the published documents are archivable according to whatever the that the published documents are archivable according to whatever the
industry best practice is over time. industry best practice is over time.
</t> </t>
</section> </section>
<section anchor="futureformat" numbered="true" toc="default"> <section anchor="futureformat" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Evolution of the RFC Format</name> <name>Evolution of the RFC Format</name>
<t>RFCs have been digital documents since very early in the days of the <t>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 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 canonical format for decades. The fact that this format has lasted through
so much evolution and change is remarkable. so much evolution and change is remarkable.
</t> </t>
<t>Unfortunately, the old US-ASCII format does not extend enough to meet <t>Unfortunately, the US-ASCII format does not extend enough to meet
the expectations and requirements of users today. The entire field of the expectations and requirements of many users today.
online document presentation, consumption, and preservation, has in some
cases only been invented years after the first RFC was published. While The entire field of online document presentation, consumption, and
it can (and has) been argued that those newer fields and their tools preservation has, in some cases, only been invented years after the
have not had a chance to stand the test of time, the RFC Series Editor first RFC was published. While it can be (and has been) argued that
(in consultation with the community) started a concerted effort in 2012 those newer fields and their tools have not had a chance to stand the
to bring the RFC Series into alignment with a new array of possibilities test of time, the RFC Series Editor (in consultation with the
for preservation and display. community) started a concerted effort in 2012 to bring the RFC Series
into alignment with a new array of possibilities for preservation and
display.
</t> </t>
<t>Information about the current RFC format project, the reasoning and
requirements for the changes underway today, can be found in <xref target="R <t>Information on the RFC format project and the initial reasoning and
FC7990" format="default"/>. requirements for the changes underway can be found in <xref
With the advent of these changes, the door has been opened to consider target="RFC7990" format="default"/>. With the advent of these
further changes in the future as the specifications for archiving digital changes, the door has been opened to consider further changes in the
material evolves, and as the expectation of web development advances. future as the specifications for archiving digital material evolves,
and as the expectation of web development advances.
</t> </t>
</section> </section>
<section anchor="streamstructure" numbered="true" toc="default"> <section anchor="streamstructure" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Stream Structure</name> <name>Stream Structure</name>
<t>In the eyes of many, particularly within the IETF, the <t>In the eyes of many, particularly within the IETF, the
RFC Series is synonymous with the IETF. While the Series itself predates 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 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 majority of documents submitted for publication to the RFC Editor. The
policies developed for IETF stream drafts tend to apply across all four 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 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 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.</t> even why, there is a distinction between the Series and the IETF.</t>
<t>We are in the midst of that question now more than ever. What is the future <t>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 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 starts, should we consider this an artificial distinction and declare them to
be the same entity? </t> be the same entity? </t>
<t>Ultimately, this will be something the community decides, and convers ations <t>Ultimately, this will be something the community decides, and convers ations
are underway to consider the ramifications of possible changes. </t> are underway to consider the ramifications of possible changes. </t>
</section> </section>
</section> </section>
<section anchor="conclusion" numbered="true" toc="default"> <section anchor="conclusion" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Conclusion</name> <name>Conclusion</name>
<t>As the Internet evolves, expectations and possibilities evolve, too. Ov er <t>As the Internet evolves, expectations and possibilities evolve, too. Ov er
the next fifty years, the Series will continue to demonstrate a balance betw een the next fifty years, the Series will continue to demonstrate a balance betw een
the need to stay true to the original mission of publication and the need to stay true to the original mission of publication and
preservation, while also staying relevant to the needs of the authors 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 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. Editor and the community to resolve. We will not run short of challenges.
</t> </t>
</section> </section>
<section anchor="iana-considerations" title="IANA Considerations"> <section anchor="iana-considerations" title="IANA Considerations">
<t>This document contains no actions for IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations" title="Security Considerations"> <section anchor="security-considerations" title="Security Considerations">
<t>This document has no security considerations.</t> <t>This document has no security considerations.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC0001" target="https://www.rfc-editor.org/info/rfc1" <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0001.xm ce.RFC.0001.xml"/>
l"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0003.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0114.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0433.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0690.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0748.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0902.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1000.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1083.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1122.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1123.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1150.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1311.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1818.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2441.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2468.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2555.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4714.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4844.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4845.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4846.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5540.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5620.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5742.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5743.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6360.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6410.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6548.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6635.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6949.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7990.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8153.xml"/>
<reference anchor="APPRENTICE" target="https://en.wikipedia.org/w/index.ph
p?title=The_Sorcerer%27s_Apprentice&#x26;oldid=925824658">
<front> <front>
<title>Host Software</title> <title>The Sorcerer's Apprentice</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <author>
<seriesInfo name="DOI" value="10.17487/RFC0001"/> <organization>Wikipedia</organization>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1"/>
<author initials="S." surname="Crocker" fullname="S. Crocker">
<organization/>
</author> </author>
<date year="1969" month="April"/> <date year="2019" month="December"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC0003" target="https://www.rfc-editor.org/info/rfc3"
xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0003.xm <reference anchor="DATATRACKER" target="https://datatracker.ietf.org">
l">
<front> <front>
<title>Documentation conventions</title> <title>IETF Datatracker</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <author>
<seriesInfo name="DOI" value="10.17487/RFC0003"/> <organization>Internet Engineering Task Force</organization>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="3"/>
<author initials="S.D." surname="Crocker" fullname="S.D. Crocker">
<organization/>
</author> </author>
<date year="1969" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC0114" target="https://www.rfc-editor.org/info/rfc114
" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0114. <reference anchor="RSAG" target="https://www.rfc-editor.org/about/rsag/">
xml">
<front> <front>
<title>File Transfer Protocol</title> <title>RFC Series Advisory Group</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <author>
<seriesInfo name="DOI" value="10.17487/RFC0114"/> <organization>RFC Editor</organization>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="114"/>
<author initials="A.K." surname="Bhushan" fullname="A.K. Bhushan">
<organization/>
</author> </author>
<date year="1971" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC0433" target="https://www.rfc-editor.org/info/rfc433
" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0433. <reference anchor="IAB-19880712" target="https://www.iab.org/documents/min
xml"> utes/minutes-1988/iab-minutes-1988-07-12/">
<front> <front>
<title>Socket number list</title> <title>IAB Minutes 1988-07-12</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <author>
<seriesInfo name="DOI" value="10.17487/RFC0433"/> <organization>IAB</organization>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="433"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author> </author>
<date year="1972" month="December"/> <date year="1988" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC0690" target="https://www.rfc-editor.org/info/rfc690
" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0690. <reference anchor="RFC-ONLINE" target="https://www.rfc-editor.org/rfc-onli
xml"> ne-2000.html">
<front> <front>
<title>Comments on the proposed Host/IMP Protocol changes</title> <title>History of RFC Online Project</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <author>
<seriesInfo name="DOI" value="10.17487/RFC0690"/> <organization>RFC Editor</organization>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="690"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author> </author>
<date year="1975" month="June"/> <date year="2000"/>
<abstract>
<t>Comments on suggestions in RFC 687; see also RFCs 692 and 696.</t
>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="RFC0748" target="https://www.rfc-editor.org/info/rfc748
" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0748. <reference anchor="ISI-to-AMS" target="https://iaoc.ietf.org/documents/AMS
xml"> -RPC-Public-Final-2009.pdf">
<front> <front>
<title>Telnet randomly-lose option</title> <title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> RFC Production Center Agreement between Association
<seriesInfo name="DOI" value="10.17487/RFC0748"/> Management Solutions, LLC and The Internet Society</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <author>
<seriesInfo name="RFC" value="748"/> <organization>IETF Administrative Support Activity (IASA)</organizat
<author initials="M.R." surname="Crispin" fullname="M.R. Crispin"> ion>
<organization/>
</author> </author>
<date year="1978" month="April"/> <date year="2009" month="October"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC0902" target="https://www.rfc-editor.org/info/rfc902
" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0902. <reference anchor="IETF1" target="https://www.ietf.org/old/2009/proceeding
xml"> s/prior29/IETF01.pdf">
<front> <front>
<title>ARPA Internet Protocol policy </title> <title>Proceedings of the 16-17 January 1986 DARPA Gateway
<seriesInfo name="DOI" value="10.17487/RFC0902"/> Algorithms and Data Structures Task Force
<seriesInfo name="RFC" value="902"/> </title>
<author initials="J.K." surname="Reynolds" fullname="J.K. Reynolds"> <author>
<organization/> <organization>The MITRE Corporation
</author> </organization>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author> </author>
<date year="1984" month="July"/> <date year="1986" month="January"/>
</front> </front>
</reference> <refcontent>IETF 1
<reference anchor="RFC1000" target="https://www.rfc-editor.org/info/rfc </refcontent>
1000" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1 </reference>
000.xml">
<front>
<title>Request For Comments reference guide</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1000"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1000"/>
<author initials="J.K." surname="Reynolds" fullname="J.K. Reynolds"
>
<organization/>
</author>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1987" month="August"/>
<abstract>
<t>This RFC Reference Guide is intended to provide a historical a
ccount by categorizing and summarizing of the Request for Comments numbers 1 thr
ough 999 issued between the years 1969-1987. These documents have been crossed
referenced to indicate which RFCs are current, obsolete, or revised.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1083" target="https://www.rfc-editor.org/info/rfc
1083" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1
083.xml">
<front>
<title>IAB official protocol standards</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1083"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1083"/>
<author>
<organization>Defense Advanced Research Projects Agency</organiza
tion>
</author>
<author>
<organization>Internet Activities Board</organization>
</author>
<date year="1988" month="December"/>
<abstract>
<t>This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Activities Board (IAB). An o
verview of the standards procedures is presented first, followed by discussions
of the standardization process and the RFC document series, then the explanation
of the terms is presented, the lists of protocols in each stage of standardizat
ion follows, and finally pointers to references and contacts for further informa
tion. This memo is issued quarterly, please be sure the copy you are reading is
dated within the last three months.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1122" target="https://www.rfc-editor.org/info/rfc
1122" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1
122.xml">
<front>
<title>Requirements for Internet Hosts - Communication Layers</titl
e>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1122"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1122"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="STD" value="3"/>
<author initials="R." surname="Braden" fullname="R. Braden" role="e
ditor">
<organization/>
</author>
<date year="1989" month="October"/>
<abstract>
<t>This RFC is an official specification for the Internet communi
ty. It incorporates by reference, amends, corrects, and supplements the primary
protocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1123" target="https://www.rfc-editor.org/info/rfc
1123" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1
123.xml">
<front>
<title>Requirements for Internet Hosts - Application and Support</t
itle>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1123"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1123"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="STD" value="3"/>
<author initials="R." surname="Braden" fullname="R. Braden" role="e
ditor">
<organization/>
</author>
<date year="1989" month="October"/>
<abstract>
<t>This RFC is an official specification for the Internet communi
ty. It incorporates by reference, amends, corrects, and supplements the primary
protocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1150" target="https://www.rfc-editor.org/info/rfc
1150" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1
150.xml">
<front>
<title>FYI on FYI: Introduction to the FYI Notes</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1150"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1150"/>
<author initials="G.S." surname="Malkin" fullname="G.S. Malkin">
<organization/>
</author>
<author initials="J.K." surname="Reynolds" fullname="J.K. Reynolds"
>
<organization/>
</author>
<date year="1990" month="March"/>
<abstract>
<t>This memo is the first in a new sub-series of RFCs called FYIs
(For Your Information). This memo provides information for the Internet commun
ity. It does not specify any standard. [Also FYI 1.]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1311" target="https://www.rfc-editor.org/info/rfc
1311" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1
311.xml">
<front>
<title>Introduction to the STD Notes</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1311"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1311"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1992" month="March"/>
<abstract>
<t>The STDs are a subseries of notes within the RFC series that a
re the Internet standards. The intent is to identify clearly for the Internet c
ommunity those RFCs which document Internet standards. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1818" target="https://www.rfc-editor.org/info/rfc
1818" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1
818.xml">
<front>
<title>Best Current Practices</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC1818"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="1818"/>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/>
</author>
<date year="1995" month="August"/>
<abstract>
<t>This document describes a new series of documents which descri
be best current practices for the Internet community. Documents in this series
carry the endorsement of the Internet Engineering Steering Group (IESG).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2441" target="https://www.rfc-editor.org/info/rfc
2441" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2
441.xml">
<front>
<title>Working with Jon, Tribute delivered at UCLA, October 30, 199
8</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC2441"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="2441"/>
<author initials="D." surname="Cohen" fullname="D. Cohen">
<organization/>
</author>
<date year="1998" month="November"/>
<abstract>
<t>This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2468" target="https://www.rfc-editor.org/info/rfc
2468" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2
468.xml">
<front>
<title>I REMEMBER IANA</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC2468"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="2468"/>
<author initials="V." surname="Cerf" fullname="V. Cerf">
<organization/>
</author>
<date year="1998" month="October"/>
<abstract>
<t>A long time ago, in a network, far far away, a great adventure
took place!. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2555" target="https://www.rfc-editor.org/info/rfc
2555" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2
555.xml">
<front>
<title>30 Years of RFCs</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC2555"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="2555"/>
<author initials="RFC" surname="Editor" fullname="RFC Editor">
<organization/>
</author>
<author initials="et" surname="al." fullname="et al.">
<organization/>
</author>
<date year="1999" month="April"/>
<abstract>
<t>The rest of this document contains a brief recollection from t
he present RFC Editor Joyce K. Reynolds, followed by recollections from three pi
oneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continu
es to guide us, and Jake Feinler who played a key role in the middle years of th
e RFC series. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4714" target="https://www.rfc-editor.org/info/rfc
4714" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4
714.xml">
<front>
<title>Requirements for IETF Technical Publication Service</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC4714"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="4714"/>
<author initials="A." surname="Mankin" fullname="A. Mankin">
<organization/>
</author>
<author initials="S." surname="Hayes" fullname="S. Hayes">
<organization/>
</author>
<date year="2006" month="October"/>
<abstract>
<t>The work of the IETF is to discuss, develop, and disseminate t
echnical specifications to support the Internet's operation. Technical publicati
on is the process by which that output is disseminated to the community at large
. As such, it is important to understand the requirements on the publication pr
ocess. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4844" target="https://www.rfc-editor.org/info/rfc
4844" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4
844.xml">
<front>
<title>The RFC Series and RFC Editor</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC4844"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="4844"/>
<author initials="L." surname="Daigle" fullname="L. Daigle" role="e
ditor">
<organization/>
</author>
<author>
<organization>Internet Architecture Board</organization>
</author>
<date year="2007" month="July"/>
<abstract>
<t>This document describes the framework for an RFC Series and an
RFC Editor function that incorporate the principles of organized community invo
lvement and accountability that has become necessary as the Internet technical c
ommunity has grown, thereby enabling the RFC Series to continue to fulfill its m
andate. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4845" target="https://www.rfc-editor.org/info/rfc
4845" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4
845.xml">
<front>
<title>Process for Publication of IAB RFCs</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC4845"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="4845"/>
<author initials="L." surname="Daigle" fullname="L. Daigle" role="e
ditor">
<organization/>
</author>
<author>
<organization>Internet Architecture Board</organization>
</author>
<date year="2007" month="July"/>
<abstract>
<t>From time to time, the Internet Architecture Board (IAB) publi
shes documents as Requests for Comments (RFCs). This document defines the proce
ss by which those documents are produced, reviewed, and published in the RFC Ser
ies. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4846" target="https://www.rfc-editor.org/info/rfc
4846" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4
846.xml">
<front>
<title>Independent Submissions to the RFC Editor</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC4846"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="4846"/>
<author initials="J." surname="Klensin" fullname="J. Klensin" role=
"editor">
<organization/>
</author>
<author initials="D." surname="Thaler" fullname="D. Thaler" role="e
ditor">
<organization/>
</author>
<date year="2007" month="July"/>
<abstract>
<t>There is a long-standing tradition in the Internet community,
predating the Internet Engineering Task Force (IETF) by many years, of use of th
e RFC Series to publish materials that are not rooted in the IETF standards proc
ess and its review and approval mechanisms. These documents, known as "Independe
nt Submissions", serve a number of important functions for the Internet communit
y, both inside and outside of the community of active IETF participants. This d
ocument discusses the Independent Submission model and some reasons why it is im
portant. It then describes editorial and processing norms that can be used for
Independent Submissions as the community goes forward into new relationships bet
ween the IETF community and its primary technical publisher. This memo provides
information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5540" target="https://www.rfc-editor.org/info/rfc
5540" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5
540.xml">
<front>
<title>40 Years of RFCs</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC5540"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="5540"/>
<author initials="RFC" surname="Editor" fullname="RFC Editor">
<organization/>
</author>
<date year="2009" month="April"/>
<abstract>
<t>This RFC marks the 40th anniversary of the RFC document series
. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5620" target="https://www.rfc-editor.org/info/rfc
5620" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5
620.xml">
<front>
<title>RFC Editor Model (Version 1)</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC5620"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="5620"/>
<author initials="O." surname="Kolkman" fullname="O. Kolkman" role=
"editor">
<organization/>
</author>
<author>
<organization>IAB</organization>
</author>
<date year="2009" month="August"/>
<abstract>
<t>The RFC Editor performs a number of functions that may be carr
ied out by various persons or entities. The RFC Editor model presented in this
document divides the responsibilities for the RFC Series into four functions: Th
e RFC Series Editor, the Independent Submission Editor, the RFC Production Cente
r, and the RFC Publisher. It also introduces the RFC Series Advisory Group and
an (optional) Independent Submission Stream Editorial Board. The model outlined
here is intended to increase flexibility and operational support options, provi
de for the orderly succession of the RFC Editor, and ensure the continuity of th
e RFC series, while maintaining RFC quality and timely processing, ensuring docu
ment accessibility, reducing costs, and increasing cost transparency. This memo
provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5742" target="https://www.rfc-editor.org/info/rfc
5742" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5
742.xml">
<front>
<title>IESG Procedures for Handling of Independent and IRTF Stream
Submissions</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC5742"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="5742"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="BCP" value="92"/>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand"
>
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<date year="2009" month="December"/>
<abstract>
<t>This document describes the procedures used by the IESG for ha
ndling documents submitted for RFC publication from the Independent Submission a
nd IRTF streams. </t>
<t>This document updates procedures described in RFC 2026 and RFC
3710. This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5743" target="https://www.rfc-editor.org/info/rfc
5743" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5
743.xml">
<front>
<title>Definition of an Internet Research Task Force (IRTF) Documen
t Stream</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC5743"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="5743"/>
<author initials="A." surname="Falk" fullname="A. Falk">
<organization/>
</author>
<date year="2009" month="December"/>
<abstract>
<t>This memo defines the publication stream for RFCs from the Int
ernet Research Task Force. Most documents undergoing this process will come fro
m IRTF Research Groups, and it is expected that they will be published as Inform
ational or Experimental RFCs by the RFC Editor. This document is not an Intern
et Standards Track specification; it is published for informational purposes.</t
>
</abstract>
</front>
</reference>
<reference anchor="RFC6360" target="https://www.rfc-editor.org/info/rfc </references>
6360" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6
360.xml"> <section title="IAB Members at the Time of Approval"
<front> numbered="false" toc="default">
<title>Conclusion of FYI RFC Sub-Series</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> <ul empty="true">
<seriesInfo name="DOI" value="10.17487/RFC6360"/> <li>Jari Arkko</li>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="6360"/> <li>Alissa Cooper</li>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/> <li>Stephen Farrell</li>
</author>
<date year="2011" month="August"/> <li>Wes Hardaker</li>
<abstract>
<t>This document concludes the For Your Information (FYI) sub-ser <li>Ted Hardie</li>
ies of RFCs, established by RFC 1150 for use by the IETF User Services Area, whi
ch no longer exists. The IESG does not intend to make any further additions to <li>Christian Huitema</li>
this RFC sub-series, and this document provides a record of this decision. This
document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic <li>Zhenbin Li</li>
. This document is not an Internet Standards Track specification; it is publis
hed for informational purposes.</t> <li>Erik Nordmark</li>
</abstract>
</front> <li>Mark Nottingham</li>
</reference>
<reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rfc <li>Melinda Shore</li>
6410" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6
410.xml"> <li>Jeff Tantsura</li>
<front>
<title>Reducing the Standards Track to Two Maturity Levels</title> <li>Martin Thomson</li>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC6410"/> <li>Brian Trammell</li>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="6410"/> </ul>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="BCP" value="9"/> </section>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/> <section anchor="Acknowledgements" numbered="false" toc="default">
</author> <name>Acknowledgements</name>
<author initials="D." surname="Crocker" fullname="D. Crocker"> <t>Many thanks to John Klensin for his feedback and insights on the
<organization/> history of the Series, as someone who directly engaged and influenced
</author> many of the key individuals involved in developing the RFC Series. </t>
<author initials="E." surname="Burger" fullname="E. Burger"> <t>Additional thanks to members of the RFC Series Advisory group and the
<organization/> Independent Submissions Editorial Board, in particular, Scott Bradner,
</author> Brian Carpenter, and Adrian Farrel, for their early reviews and input
<date year="2011" month="October"/> into the sequence of key moments in the history of the Series. </t>
<abstract> </section>
<t>This document updates the Internet Engineering Task Force (IET
F) Standards Process defined in RFC 2026. Primarily, it reduces the Standards P <section anchor="contributors" numbered="false" toc="default">
rocess from three Standards Track maturity levels to two. This memo documents an
Internet Best Current Practice.</t> <name>Contributors</name>
</abstract> <t>Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil Brownlee,
</front> and
</reference> Sandy Ginoza for their perspectives on the Series and their ongoing suppo
<reference anchor="RFC6548" target="https://www.rfc-editor.org/info/rfc rt.
6548" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6 </t>
548.xml">
<front> </section>
<title>Independent Submission Editor Model</title> </back>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element --> </rfc>
<seriesInfo name="DOI" value="10.17487/RFC6548"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="6548"/>
<author initials="N." surname="Brownlee" fullname="N. Brownlee" rol
e="editor">
<organization/>
</author>
<author>
<organization>IAB</organization>
</author>
<date year="2012" month="June"/>
<abstract>
<t>This document describes the function and responsibilities
of the RFC Independent Submission Editor (ISE). The Independent
Submission stream is one of the stream producers that create
draft RFCs, with the ISE as its stream approver. The ISE is
overall responsible for activities within the Independent
Submission stream, working with draft editors and reviewers, and
interacts with the RFC Production Center and Publisher, and the
RFC Series Editor (RSE). The ISE is appointed by the IAB, and
also interacts with the IETF Administrative Oversight Committee
(IAOC).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6635" target="https://www.rfc-editor.org/info/rfc
6635" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6
635.xml">
<front>
<title>RFC Editor Model (Version 2)</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC6635"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="6635"/>
<author initials="O." surname="Kolkman" fullname="O. Kolkman" role=
"editor">
<organization/>
</author>
<author initials="J." surname="Halpern" fullname="J. Halpern" role=
"editor">
<organization/>
</author>
<author>
<organization>IAB</organization>
</author>
<date year="2012" month="June"/>
<abstract>
<t>The RFC Editor model described in this document divides the re
sponsibilities for the RFC Series into three functions: the RFC Series Editor, t
he RFC Production Center, and the RFC Publisher. Internet Architecture Board (IA
B) oversight via the RFC Series Oversight Committee (RSOC) is described, as is t
he relationship between the IETF Administrative Oversight Committee (IAOC) and t
he RSOC. This document reflects the experience gained with "RFC Editor Model (V
ersion 1)", documented in RFC 5620, and obsoletes that document. This document
is not an Internet Standards Track specification; it is published for informati
onal purposes.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6949" target="https://www.rfc-editor.org/info/rfc
6949" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6
949.xml">
<front>
<title>RFC Series Format Requirements and Future Development</title
>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC6949"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="6949"/>
<author initials="H." surname="Flanagan" fullname="H. Flanagan">
<organization/>
</author>
<author initials="N." surname="Brownlee" fullname="N. Brownlee">
<organization/>
</author>
<date year="2013" month="May"/>
<abstract>
<t>This document describes the current requirements and requests
for enhancements for the format of the canonical version of RFCs. Terms are def
ined to help clarify exactly which stages of document production are under discu
ssion for format changes. The requirements described in this document will dete
rmine what changes will be made to RFC format. This document updates RFC 2223.<
/t>
</abstract>
</front>
</reference>
<reference anchor="RFC7990" target="https://www.rfc-editor.org/info/rfc
7990" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7
990.xml">
<front>
<title>RFC Format Framework</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC7990"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="7990"/>
<author initials="H." surname="Flanagan" fullname="H. Flanagan">
<organization/>
</author>
<date year="2016" month="December"/>
<abstract>
<t>In order to improve the readability of RFCs while supporting t
heir archivability, the canonical format of the RFC Series will be transitioning
from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different
publication formats will be rendered from that base document. With these change
s comes an increase in complexity for authors, consumers, and the publisher of R
FCs. This document serves as the framework that provides the problem statement,
lays out a road map of the documents that capture the specific requirements, an
d describes the transition plan.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8153" target="https://www.rfc-editor.org/info/rfc
8153" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8
153.xml">
<front>
<title>Digital Preservation Considerations for the RFC Series</titl
e>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="DOI" value="10.17487/RFC8153"/>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<seriesInfo name="RFC" value="8153"/>
<author initials="H." surname="Flanagan" fullname="H. Flanagan">
<organization/>
</author>
<date year="2017" month="April"/>
<abstract>
<t>The RFC Editor is both the publisher and the archivist for the
RFC Series. This document applies specifically to the archivist role of the RF
C Editor. It provides guidance on when and how to preserve RFCs and describes t
he tools required to view or re-create RFCs as necessary. This document also hi
ghlights gaps in the current process and suggests compromises to balance cost wi
th best practice.</t>
</abstract>
</front>
</reference>
<reference anchor="IAB-19880712" target="https://www.iab.org/documents/
minutes/minutes-1988/iab-minutes-1988-07-12/">
<front>
<title>IAB Minutes 1988-07-12</title>
<author>
<organization>IAB</organization>
</author>
<date year="1988" month="July"/>
</front>
</reference>
<reference anchor="RFC-ONLINE" target="http://www.rfc-editor.org/rfc-on
line-2000.html">
<front>
<title>History of RFC Online Project</title>
<author>
<organization>RFC Editor</organization>
</author>
<date year="2010" month="February"/>
</front>
</reference>
<reference anchor="ISI-to-AMS" target="https://iaoc.ietf.org/documents/
AMS-RPC-Public-Final-2009.pdf">
<front>
<title>RFC Production Center Agreement between Association Manageme
nt Solutions, LLC, and the Internet Society</title>
<author>
<organization>The IETF Administrative Support Activity</organizat
ion>
</author>
<date year="2009" month="October"/>
</front>
</reference>
<reference anchor="IETF1" target="https://www.ietf.org/old/2009/proceed
ings/prior29/IETF01.pdf">
<front>
<title>First IETF; January 16-17, 1986; San Diego, California</titl
e>
<author>
<organization/>
</author>
<date year="1986" month="January"/>
</front>
</reference>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>With many thanks to John Klensin for his feedback and insights on th
e
history of the Series, as someone who directly engaged and influenced
many of the key individuals involved in developing the RFC Series. </
t>
<t>Additional thanks to members of the RFC Series Advisory group and th
e
Independent Submissions Editorial Board, in particular Scott Bradner,
Brian Carpenter, and Adrian Farrel, for their early reviews and input
into the sequence of key moments in the history of the Series. </t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Contributors</name>
<t>Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil Brownl
ee, and
Sandy Ginoza for their perspectives on the Series, and their ongoing supp
ort.
</t>
</section>
</back>
</rfc>
 End of changes. 145 change blocks. 
1292 lines changed or deleted 956 lines changed or added

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