File: rfc8700.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2550 lines) | stat: -rw-r--r-- 127,738 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8700: Fifty Years of RFCs</title>
<meta content="Heather Flanagan" name="author">
<meta content="
       This RFC marks the fiftieth anniversary for the RFC Series. It includes both
  retrospective material from individuals involved at key inflection points as
  well as a review of the current state of affairs. It concludes with thoughts
  on possibilities for the next fifty years for the Series.
  This document updates the perspectives offered in RFCs 2555 and 5540.
 
    " name="description">
<meta content="xml2rfc 2.37.3" name="generator">
<meta content="History, RFC Series, Retrospective" name="keyword">
<meta content="8700" name="rfc.number">
<link href="rfc8700.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/*
  The margin-left: 0 on <dd> removes all distinction
  between levels from nested <dl>s.  Undo that.
*/
dl.olPercent > dd,
dd {
  margin-left: revert;
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8700" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-iab-fiftyyears-01" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8700</td>
<td class="center">Fifty Years of RFCs</td>
<td class="right">December 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Flanagan</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Architecture Board (IAB)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8700" class="eref">8700</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc2555" class="eref">2555</a>, <a href="https://www.rfc-editor.org/rfc/rfc5540" class="eref">5540</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-12" class="published">December 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">H. Flanagan, <span class="editor">Ed.</span>
</div>
<div class="org">RFC Editor</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8700</h1>
<h1 id="title">Fifty Years of RFCs</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This RFC marks the fiftieth anniversary for the RFC Series. It includes both
  retrospective material from individuals involved at key inflection points as
  well as a review of the current state of affairs. It concludes with thoughts
  on possibilities for the next fifty years for the Series.
  This document updates the perspectives offered in RFCs 2555 and 5540.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Architecture Board
            (IAB) and represents information that the IAB has deemed valuable
            to provide for permanent record.  It represents the consensus of the Internet
            Architecture Board (IAB).  Documents approved for publication
            by the IAB are not candidates for any level of Internet Standard; see
            Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8700">https://www.rfc-editor.org/info/rfc8700</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (https://trustee.ietf.org/license-info) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-key-moments-in-rfc-history" class="xref">Key Moments in RFC History</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-perspectives" class="xref">Perspectives</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-the-origins-of-rfcs-by-step" class="xref">The Origins of RFCs - by Stephen D. Crocker</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-the-rfc-management-and-edit" class="xref">The RFC Management and Editing Team - by Vint Cerf</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-formalizing-the-rfc-editor-" class="xref">Formalizing the RFC Editor Model - by Leslie Daigle</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-the-continuation-or-creatio" class="xref">The Continuation, or Creation, of a Stream - by Nevil Brownlee</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-a-view-from-inside-the-rfc-" class="xref">A View from inside the RFC Editor - by Sandy
 Ginoza</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-the-next-fifty-years-of-rfc" class="xref">The Next Fifty Years of   RFCs</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-preservation" class="xref">Preservation</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-evolution-of-the-rfc-format" class="xref">Evolution of the RFC Format</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-stream-structure" class="xref">Stream Structure</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-conclusion" class="xref">Conclusion</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-iab-members-at-the-time-of-" class="xref">IAB Members at the Time of Approval</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The RFC Series began in April 1969 with the publication of "Host
      Software" by Steve Crocker. The early RFCs were, in fact, requests for
      comments on ideas and proposals; the goal was to start conversations
      rather than to create an archival record of a standard or best practice.
      This goal changed over time, as the formality of the publication process
      evolved and the community consuming the material grew.

      Today, over 8500 RFCs have been published, ranging across best practice
      guidance, experimental protocols, informational material, and, of
      course, Internet standards. Material is accepted for publication through
      the IETF, the IAB, the IRTF, and the Independent Submissions streams,
      each of which have clear processes on how drafts are submitted and
      potentially approved for publication as an RFC.  Ultimately, the goal of
      the RFC Series is to provide a canonical source for the material
      published by the RFC Editor and to support the preservation of that
      material in perpetuity.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The RFC Editor as a role came a few years after the first RFC was
      published.


      The actual date the term "RFC Editor" was first used is unknown, but it
      was formalized by <span>[<a href="#RFC0902" class="xref">RFC0902</a>]</span> in July 1984;
      Jon Postel, the first RFC Editor, defined the role by his actions and
      later by defining the initial processes surrounding the publication of
      RFCs. What is certain is that the goal of the RFC Editor is to produce
      documents that are readable, clear, consistent, and reasonably uniform,
      and that the archival record of what has been published is maintained.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Change does come to the Series, albeit slowly. First, we saw the
      distribution method change from postal mail to FTP and then to
      email. RFCs could not be distributed electronically in the beginning, as
      the means to do that distribution would not be defined until years after
      the first RFC was "published".

      Not all early RFCs were even created electronically; some were written
      out by hand or on a typewriter. Eventually, the process for creating
      RFCs became more structured; authors were provided guidance on how to
      write an RFC. The editorial effort went from Steve Crocker to a more
      official model with a designated editor, Jon Postel, and later to a team
      of five to seven individuals.

      The actual editing and publishing work split from the service for
      registration of protocol code points. The whole RFC Editor structure was
      reviewed <span>[<a href="#RFC4844" class="xref">RFC4844</a>]</span>, refined <span>[<a href="#RFC5620" class="xref">RFC5620</a>]</span>, and refined again <span>[<a href="#RFC6635" class="xref">RFC6635</a>]</span>. And, in the last few years, the
      process to change the format of the RFC documents themselves has
      started <span>[<a href="#RFC7990" class="xref">RFC7990</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This is evolution; and the Series will continue to be adapted in order to
      meet the needs and expectations of the implementers, operators, historians,
      and community of authors that uses the RFC Series. These changes will always be
      balanced against the core mission of the Series: to maintain a strong,
      stable, archival record of technical specifications, protocols, and other
      information relevant to the Advanced Research Projects Agency Network (ARPANET) and Internet networking
      communities.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">There is more to the history of the RFC Series than can be covered in
      this document. Readers interested in earlier perspectives may find the
      following RFCs of particular interest. These RFCs focus on the enormous
      contributions of Jon Postel, Czar of Socket Numbers <span>[<a href="#RFC0433" class="xref">RFC0433</a>]</span> and first RFC Editor:<a href="#section-1-5" class="pilcrow">¶</a></p>
<ul>
<li id="section-1-6.1">
          <span>[<a href="#RFC2441" class="xref">RFC2441</a>]</span>"Working with Jon,
 Tribute delivered at UCLA, October 30, 1998"<a href="#section-1-6.1" class="pilcrow">¶</a>
</li>
<li id="section-1-6.2">
          <span>[<a href="#RFC2555" class="xref">RFC2555</a>]</span>"30 Years of RFCs"<a href="#section-1-6.2" class="pilcrow">¶</a>
</li>
<li id="section-1-6.3">
          <span>[<a href="#RFC5540" class="xref">RFC5540</a>]</span>"40 Years of RFCs"<a href="#section-1-6.3" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-1-7">
        In this document, the history of the Series is viewed through the eyes
        of several individuals who have been a part of shaping it.
        Narratives of this nature offer a limited perspective on events; there
        are almost certainly other viewpoints, memories, and perspectives on
        events that are equally valid and would reflect a different history. So,
        while these retrospectives are enormously valuable and provide an
        insight to events of the day, they are just one lens on the history of
        the RFC Series.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">Steve Crocker, author of <span>[<a href="#RFC0001" class="xref">RFC0001</a>]</span>, offers his
        thoughts on how and why the Series began. Leslie Daigle, a major
        influence in the development of the RFC Editor model, offers her
        thoughts on the change of the RFC Editor to a stronger, contracted
        function. Nevil Brownlee, Independent Submissions Editor from 2010
        through February 2018, shares his view on the clarification of
 the Independent Stream (IS)
        and its transition upon the retirement of Bob Braden from the position.

 As the current RFC Series Editor, I
        will put my thoughts in on the most recent changes in formalizing the
        digital preservation of the Series, the process to modernize the format
        while respecting the need for stability, and my thoughts on the next
        fifty years of RFCs.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">This document updates the perspectives offered in <span>[<a href="#RFC2555" class="xref">RFC2555</a>]</span> and <span>[<a href="#RFC5540" class="xref">RFC5540</a>]</span>.<a href="#section-1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="keymoments">
<section id="section-2">
      <h2 id="name-key-moments-in-rfc-history">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-key-moments-in-rfc-history" class="section-name selfRef">Key Moments in RFC History</a>
      </h2>
<span id="name-key-moments-in-rfc-history-2"></span><div id="keymoments-table">
<table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-key-moments-in-rfc-history-2" class="selfRef">Key Moments in RFC History</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Marker</th>
            <th class="text-left" rowspan="1" colspan="1">Date</th>
            <th class="text-left" rowspan="1" colspan="1">Event</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC0001" class="xref">RFC0001</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">April 1969</td>
            <td class="text-left" rowspan="1" colspan="1">First RFC published</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC0114" class="xref">RFC0114</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">April 1971</td>
            <td class="text-left" rowspan="1" colspan="1">First distribution of RFCs over the network</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC0433" class="xref">RFC0433</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">December 1972</td>
            <td class="text-left" rowspan="1" colspan="1">First mention of the Czar of Socket Numbers and the proposal for a formal registry</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC0690" class="xref">RFC0690</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">June 1975</td>
            <td class="text-left" rowspan="1" colspan="1">Relationship starts between the Information Sciences
     Institute (ISI) and the RFC Editor (judging by Jon Postel's affiliation change)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC0748" class="xref">RFC0748</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">April 1977</td>
            <td class="text-left" rowspan="1" colspan="1">First April 1st RFC published</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#IETF1" class="xref">IETF1</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">January 1986</td>
            <td class="text-left" rowspan="1" colspan="1">First Internet Engineering Task Force (IETF) meeting</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#IAB-19880712" class="xref">IAB-19880712</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">July 1988</td>
            <td class="text-left" rowspan="1" colspan="1">IAB approved the creation of an Internet-Draft series</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span><span>[<a href="#RFC1123" class="xref">RFC1123</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">December 1988</td>
            <td class="text-left" rowspan="1" colspan="1">First major effort to review key specifications and write applicability statements</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC1083" class="xref">RFC1083</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">October 1989</td>
            <td class="text-left" rowspan="1" colspan="1">Three-stage standards process first defined</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC1150" class="xref">RFC1150</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">March 1990</td>
            <td class="text-left" rowspan="1" colspan="1">FYI sub-series started</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC1311" class="xref">RFC1311</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">March 1992</td>
            <td class="text-left" rowspan="1" colspan="1">STD sub-series started</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC1818" class="xref">RFC1818</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">August 1995</td>
            <td class="text-left" rowspan="1" colspan="1">BCP sub-series started</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC-ONLINE" class="xref">RFC-ONLINE</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">approx. 1998</td>
            <td class="text-left" rowspan="1" colspan="1">RFC Online Project to restore early RFCs
     that were "lost" started</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC2441" class="xref">RFC2441</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">15 October 1998</td>
            <td class="text-left" rowspan="1" colspan="1">Jon Postel's death</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC4844" class="xref">RFC4844</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">July 2007 </td>
            <td class="text-left" rowspan="1" colspan="1">RFC Series administrative structure documented</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC4846" class="xref">RFC4846</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">July 2007</td>
            <td class="text-left" rowspan="1" colspan="1">Independent Submission document stream is formalized</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC5620" class="xref">RFC5620</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">August 2009</td>
            <td class="text-left" rowspan="1" colspan="1">RFC Editor organization officially established as
            RFC Series Editor, Independent Submission Editor, RFC
            Production Center, and RFC Publisher</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#ISI-to-AMS" class="xref">ISI-to-AMS</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">October 2009</td>
            <td class="text-left" rowspan="1" colspan="1">Transition of RFC Production Center and RFC Publisher
            starts from Information Sciences Institute (ISI) to
            Association Management Solutions (AMS)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC5540" class="xref">RFC5540</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">January 2010</td>
            <td class="text-left" rowspan="1" colspan="1">Bob Braden retires from RFC Editor</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC5743" class="xref">RFC5743</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">December 2009</td>
            <td class="text-left" rowspan="1" colspan="1">Internet Research Task Force document stream formalized</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC-ONLINE" class="xref">RFC-ONLINE</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">approx. 2010</td>
            <td class="text-left" rowspan="1" colspan="1">RFC Online Project to restore early RFCs that
     were "lost" finished</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC6360" class="xref">RFC6360</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">August 2011</td>
            <td class="text-left" rowspan="1" colspan="1">FYI sub-series ended</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC6410" class="xref">RFC6410</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">October 2011</td>
            <td class="text-left" rowspan="1" colspan="1">Two-stage standards process formalized</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC6635" class="xref">RFC6635</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">June 2012</td>
            <td class="text-left" rowspan="1" colspan="1">Updated responsibilities of RFC Series allocated
            to RFC Series Editor, RFC Production Center, and RFC
            Publisher</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC6949" class="xref">RFC6949</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">May 2013</td>
            <td class="text-left" rowspan="1" colspan="1">RFC format change project started</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <span>[<a href="#RFC8153" class="xref">RFC8153</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">April 2017</td>
            <td class="text-left" rowspan="1" colspan="1">RFCs no longer printed to paper upon publication</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="perspectives">
<section id="section-3">
      <h2 id="name-perspectives">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-perspectives" class="section-name selfRef">Perspectives</a>
      </h2>
<div id="the-origins-of-rfcs-by-stephen-d-crocker">
<section id="section-3.1">
        <h3 id="name-the-origins-of-rfcs-by-step">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-the-origins-of-rfcs-by-step" class="section-name selfRef">The Origins of RFCs - by Stephen D. Crocker</a>
        </h3>
<p id="section-3.1-1">(This is a revision of material included more than 30 years
 ago in <span>[<a href="#RFC1000" class="xref">RFC1000</a>]</span>.)<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">The Internet community now includes millions of nodes and billions
        of users.  It owes its beginning to the ARPANET, which was once but a
        gleam in the eyes of J. C. R. Licklider, Bob Taylor,
        and Larry Roberts of the Advanced Research Projects Agency (ARPA).
        While much of the development proceeded according to plan, the initial
        design of the protocols and the creation of the RFCs was largely
        accidental.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">The procurement of the ARPANET was initiated in the summer of 1968;
        remember Vietnam, flower children, etc.? There had been prior
        experiments at various ARPA sites to link together computer systems,
        but this was the first version to explore packet switching as a core
        part of the communication strategy.  ("ARPA" didn't become "DARPA"
        (Defense Advanced Research Projects Agency) until 1972.  It briefly
        changed back to ARPA in 1993 and then back again to DARPA.)  The
        government's Request for Quotations (RFQ) called for four
        packet-switching devices, called Interface Message Processors
        ("IMPs"), to be delivered to four sites in the western part of the
        United States: University of California, Los Angeles (UCLA); SRI International
        (Stanford Research Institute) in Menlo Park, CA;
        University of California, Santa Barbara (UCSB); and the University of
        Utah in Salt Lake City.  These sites were running a Scientific Data
        Systems (SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10,
        respectively.  These machines not only had different operating
        systems, but even details like character sets and byte sizes
        varied. Other sites would have further variations.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">The focus was on the basic movement of data.  The precise use of
        the ARPANET was not spelled out in advance, thus requiring the
        research community to take some initiative.  To stimulate this
        process, a meeting was called in August 1968 with representatives from
        the selected sites, chaired by Elmer Shapiro from SRI.  Based on
        Shapiro's notes from that meeting, the attendees were Dave Hopper and
        Jeff Rulifson from SRI; Glen Culler and Gordon Buck from Santa
        Barbara; R.  Stephenson, C. Stephen Carr, and W. Boam from Utah; Vint
        Cerf and me from UCLA; and a few others from potential future
        sites.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">That first meeting was seminal.  We had lots of questions.  How
        would IMPs and "hosts" (I think that was the first time I was exposed
        to that term) be connected?  What would hosts say to each other?  What
        applications would be supported?  The only concrete answers were
        remote login as a replacement for dial-up, telephone-based interactive
        terminal access, and file transfer, but we knew the vision had to be
        larger.  We found ourselves imagining all kinds of possibilities:
        interactive graphics, cooperating processes, automatic database
        query, electronic mail, etc., but no one knew where to begin.  We weren't
        sure whether there was really room to think hard about these problems;
        surely someone senior and in charge, likely from the East, would be
        along by and by to bring the word.  But we did come to one conclusion:
        we ought to meet again.  Over the next several months, we met at each
        of our sites, thereby setting the precedent for regular face-to-face
        meetings.  We also instantly felt the irony.  This new network was
        supposed to make it possible to work together at a distance, and the
        first thing we did was schedule a significant amount of travel.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">Over the next several months, a small, fairly consistent set of
        graduate students and staff members from the first four sites met.  We
        used the term Network Working Group (NWG) to designate ourselves.
        This was the same term Elmer Shapiro had used when he convened our
        first meeting, although it had been used until that point to refer to
        the principal investigators and ARPA personnel: senior people who
        had been planning the network.  Our group was junior and disjointed from
        the prior group, except, of course, that each of us worked for one of
        the principal investigators.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">The first few meetings were quite tenuous, primarily because we
        weren't sure how narrow or expansive our goals should be.  We had no
        official charter or leadership, and it remained unclear, at least to
        me, whether someone or some group would show up with the official
        authority and responsibility to take over the problems we were dealing
        with.  Without clear definition of what the host-IMP interface would
        look like, or even a precise definition of what functions the IMP
        would provide, we focused on broader ideas.  We envisioned the
        possibility of application-specific protocols, with code downloaded to
        user sites, and we took a crack at designing a language to support
        this.  The first version was known as DEL, for "Decode-Encode
        Language" and a later version was called NIL, for "Network Interchange
        Language".<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<p id="section-3.1-8">In late 1968, Bolt Beranek and Newman (BBN) in Cambridge, MA won the
        contract for the IMPs and began work in January 1969.  A few of us
        flew to Boston in the middle of February to meet the BBN crew.  The
        BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein, Ben
        Barker, Will Crowther, Bernie Cosell, and Dave Walden.  They were
        organized, professional, and focused.  Their first concern was how to
        meet their contract schedule of delivering the first IMP to UCLA at
        the beginning of September and how to get bits to flow quickly and
        reliably.  The details of the host-IMP interface were not yet firm;
        the specification came a few months later as BBN Report 1822.  In
        particular, BBN didn't take over our protocol design process, nor did
        any other source of authority appear.  Thus, we doggedly continued
        debating and designing the protocols.<a href="#section-3.1-8" class="pilcrow">¶</a></p>
<p id="section-3.1-9">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.<a href="#section-3.1-9" class="pilcrow">¶</a></p>
<p id="section-3.1-10">I tried a couple of times to write a note on how the notes would be
        organized, but I found myself full of trepidation.  Would these notes
        look as if we were asserting authority we didn't have?  Would we
        unintentionally offend whomever the official protocol designers were?
        Finally, unable to sleep, I wrote a few humble words.  The basic
        ground rules were that anyone could say anything and that nothing was
        official.  And to emphasize the point, I used Bill Duvall's suggestion
        and labeled the notes "Request for Comments". I never dreamed these
        notes would eventually be distributed through the very medium we were
        discussing in these notes: talk about Sorcerer's
 Apprentice! (See <span>[<a href="#APPRENTICE" class="xref">APPRENTICE</a>]</span>.)<a href="#section-3.1-10" class="pilcrow">¶</a></p>
<p id="section-3.1-11">After BBN distributed the specification for the IMP hardware and
        software interface to the initial ARPANET sites, our attention shifted
        to low-level matters.  The ambitious ideas for automatic downloading
        of code evaporated.  It would be several years before ideas like
        mobile code, remote procedure calls, ActiveX, JAVA, and
        Representational State Transfer (RESTful) interfaces appeared.<a href="#section-3.1-11" class="pilcrow">¶</a></p>
<p id="section-3.1-12">Over the spring and summer of that year, we grappled with the
        detailed problems of protocol design.  Although we had a vision of the
        vast potential for intercomputer communication, designing usable
        protocols was another matter. We knew a custom hardware interface and
        a custom software addition in the operating system was going to be
        required for anything we designed, and we anticipated these would pose
        some difficulty at each of the sites.  We looked for existing
        abstractions to use.  It would have been convenient if we could have
        made the network simply look like a regular device, e.g., a tape
        drive, but we knew that wouldn't do.  The essence of this network was
        peer-to-peer cooperation among the machines and the processes running
        inside them, not a central machine controlling dependent devices.  We
        settled on a virtual bit stream layer as the basic building block for
        the protocols; but even back then, we knew that some applications like
        voice might need to avoid that layer of software.  (Why a virtual bit
        stream instead of a virtual byte stream?  Because each computer had
        its own notion of how many bits were in a byte.  8-bit bytes
        didn't become standard until a few years later.)<a href="#section-3.1-12" class="pilcrow">¶</a></p>
<p id="section-3.1-13">Over the next two years, we developed, exchanged, and implemented
        ideas.  I took a leave from UCLA in June 1971 to spend time working at
        ARPA.  Jon Postel took over the care and feeding of the RFCs, evolving
        the process and adding collaborators over the next twenty-seven
        years.<a href="#section-3.1-13" class="pilcrow">¶</a></p>
<p id="section-3.1-14">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.<a href="#section-3.1-14" class="pilcrow">¶</a></p>
<p id="section-3.1-15">When we first started working on the protocols, the network did not exist.
Except for our occasional face-to-face meetings, RFCs were our only means of
communication.  In <span>[<a href="#RFC0003" class="xref">RFC0003</a>]</span>, I set the bar as low as
possible:<a href="#section-3.1-15" class="pilcrow">¶</a></p>
<aside id="section-3.1-16">
          <p id="section-3.1-16.1">
The content of a NWG note may be any thought,
suggestion, etc. related to the HOST software or other aspect of the
network. Notes are encouraged to be timely rather than
polished. Philosophical positions without examples or other specifics,
specific suggestions or implementation techniques without  introductory or
background explication, and explicit questions  without any attempted answers
are all acceptable.  The minimum  length for a NWG note is one sentence.<a href="#section-3.1-16.1" class="pilcrow">¶</a></p>
<p id="section-3.1-16.2">
These standards (or lack of them) are stated explicitly for two reasons.
First, there is a tendency to view a written statement as ipso facto
authoritative, and we hope to promote the exchange and discussion of
considerably less than authoritative ideas.  Second, there is a natural
hesitancy to publish something unpolished, and we hope to ease this
inhibition.<a href="#section-3.1-16.2" class="pilcrow">¶</a></p>
</aside>
<p id="section-3.1-17">Making the RFCs informal was not only a way of encouraging participation; it
was also important in making the communication effective.  One of the early
participants said he was having trouble writing and sending an RFC because his
institution wanted to subject them to publication review.  These are not
"publications", I declared, and the problem went away.  Another small detail,
handled instinctively and without debate, was the distribution model.  Each
institution was required to send a copy directly to each of the other handful of
participating institutions.  Each institution handled internal copies and
distribution itself.  Submission to a central point for redistribution was not
required so as to minimize delays.  SRI's Network Information Center, however,
did maintain a central repository of everything and provided an invaluable
record.<a href="#section-3.1-17" class="pilcrow">¶</a></p>
<p id="section-3.1-18">We didn't intentionally set out to challenge the existing standards
        organizations, but our natural mode of operation yielded some striking
        results.  The RFCs are open in two important respects: anyone can
        write one for free and anyone can get them for free.  At the time,
        virtually everyone in the ARPANET community was sponsored by the
        government, so there was little competition and no need to use
        documents as a way of raising money.  Of course, as soon as we had
        email working on the ARPANET, we distributed RFCs electronically.
        When the ARPANET became just a portion of the Internet, this
        distribution process became worldwide.  The effect of this openness is
        often overlooked; even now, students and young professionals all over
        the world have been able to download RFCs, learn about the technology
        within, and in turn, build the most amazing software. (They are also
        a fantastic resource for historians.)<a href="#section-3.1-18" class="pilcrow">¶</a></p>
<p id="section-3.1-19">Where will it end? The ARPANET begat the Internet, and the
        underlying technology transitioned from the original host-host
        protocol to TCP/IP. But, the superstructure of protocol layers,
        community-driven protocol design, and RFCs continued.  Through the
        changes in physical-layer technology, resulting in speed increases
        from thousands to billions of bits per second, and similarly from
        thousands to billions of users, this superstructure, including the
        RFCs, has continued to serve the community.  All of the computers have
        changed, as have all of the transmission lines, but the RFCs march on.
        Maybe I'll write a few words for RFC 10,000.<a href="#section-3.1-19" class="pilcrow">¶</a></p>
<p id="section-3.1-20">Quite obviously, the circumstances have changed. Email and other
        media are most often used for the immediate exchange of inchoate
        thoughts.  Internet-Drafts are the means for exchanging substantial,
        albeit sometimes speculative, content, while RFCs are reserved for fully
        polished, reviewed, edited, and approved specifications.  Comments to
        RFCs are not requested, although usage-related discussions and other
        commentary on mailing lists often take place nonetheless.  Rather
        than bemoan the change, I take it as a remarkable example of
        adaptation.  RFCs continue to serve the protocol development
        community.  Indeed, they are the bedrock of a very vibrant and
        productive process that has fueled and guided the Internet
        revolution.<a href="#section-3.1-20" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rfcmgmtteam">
<section id="section-3.2">
        <h3 id="name-the-rfc-management-and-edit">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-the-rfc-management-and-edit" class="section-name selfRef">The RFC Management and Editing Team - by Vint Cerf</a>
        </h3>
<p id="section-3.2-1">As Steve Crocker mentions in <a href="#the-origins-of-rfcs-by-stephen-d-crocker" class="xref">Section 3.1</a>, Jon Postel
        assumed the role of RFC manager in 1971 when Steve left UCLA for
        ARPA. Jon took on this role in addition to his subsequent "numbers
        Czar" responsibilities. Initially, his focus was largely on assigning
        RFC numbers to aspiring writers, but with time, and as the
        standardization of the ARPANET and Internet protocols continued apace,
        he began to serve in an editorial capacity. Moreover, as an
        accomplished software engineer, he had opinions about technical
        content in addition to writing style and did not hesitate to exercise
        editorial discretion as would-be published authors presented their
        offerings for his scrutiny. As the load increased, he recruited
        additional "volunteer" talent, most notably Joyce K. Reynolds, a
        fellow researcher at USC/ISI. Over the ensuing years, he also drafted
        Robert (Bob) Braden onto the team, and when Jon unexpectedly passed
        away in October 1998 (see <span>[<a href="#RFC2468" class="xref">RFC2468</a>]</span>),
        Joyce and Bob undertook carrying on with the RFC work in his stead,
        adding Sandy Ginoza to the team. During the period when Jon and Joyce
        worked closely together, Joyce would challenge me to tell which edits
        had been made by Jon and which by her. I found this impossible, so
        aligned were they in their editorial sensibilities. Sadly, three of
        these tireless Internauts have passed on, and we have only the product
        of their joint work and Sandy Ginoza's and others' corporate memory by
        which to recall history.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="formalizing-the-rfc-editor-model-leslie-daigle">
<section id="section-3.3">
        <h3 id="name-formalizing-the-rfc-editor-">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-formalizing-the-rfc-editor-" class="section-name selfRef">Formalizing the RFC Editor Model - by Leslie Daigle</a>
        </h3>
<p id="section-3.3-1">I was the chair of the Internet Architecture Board, the board
        responsible for the general oversight of the RFC Series, at a
        particular inflection point in the evolution of all Internet
        technology institutions. To understand what we did, and why we had to,
        let me first paint a broader picture of the arc of these
        institutions.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">Like many others who were in decision-making roles in the mid '00s,
        I wasn't present when the Internet was born. The lore passed down to
        me was that, out of the group of talented researchers that developed
        the core specifications and established the direction of the Internet,
        different individuals stepped up to take on roles necessary to keep
        the process of specification development organized and open. As the
        work of specification expanded, those individuals were generally
        supported by organizations that carried on in the same spirit.  This
        was mostly Jon Postel, managing the allocation and assignment of names
        and numbers, as well as working as the editor of RFCs, but there were
        also individuals and institutions supporting the IETF's Secretariat
        function. By the late 20th century, even this model was wearing thin;
        the support functions were growing, and organizations didn't have the
        ability to donate even more resources to run them. In some cases
        (IANA), there was significant industry and international dependence on
        the function and its neutrality.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">The IETF, too, had grown in size, stature, and commercial
        reliance. This system of institutional pieces "flying in formation"
        was not providing the kind of contractual regularity or integrated
        development that the IETF needed. People who hadn't been there as the
        institutions developed, including IETF decision makers, didn't
        innately understand why things "had to be the way they were" and were
        frustrated when trying to get individual systems updated for new
        requirements as well as better integrated across the spectrum of
        activities.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3-4">Internet engineering had expanded beyond the point of being
        supportable by a loosely coupled set of organizations of people who
        had been there since the beginning and knew each other well. New forms
        of governance were needed along with a rationalized funding
        model. The IANA function was absorbed into a purpose-built
        international not-for-profit organization. The IETF stepped up to
        manage its own organizational destiny, creating the IETF
        Administrative Support Activity (IASA), and the Secretariat became one
        of its contracted functions.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">This left the RFC Editor function as an independent effort
 supported by the Internet Society.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<p id="section-3.3-6">That independent nature was necessary for the historic role of the
        RFC Series in considering all technical contributions. But, at that
        inflection point in the Series' history, it needed a new governance
        and funding model, just as the other organizations supporting
 Internet technical specification had. Also, the IETF leadership had some
        concerns it felt needed to be addressed in its own technical
        publication stream. While the RFC Series had been established before
        there was an IETF, and had historically continued to have documents in
        it that didn't originate from the IETF, the IETF was its largest and
        most organized contributor. There was no particular organization of
        independent contributors.  Equally, the funding for the RFC Editor was
        at that point coming from the Internet Society in the guise of
        "support for the IETF". For people who hadn't been involved with the
        institution from the outset, it was pretty easy to perceive the RFC
        Series uniquely as the IETF's publication series. So, the challenge
        was to identify and address the IETF's issues, along with governance
        and funding, without sacrificing the fundamental nature of the RFC
        Series as a broader-than-IETF publication series.<a href="#section-3.3-6" class="pilcrow">¶</a></p>
<p id="section-3.3-7">To give a sense of the kind of tensions that were prevalent, let
        me share that the one phrase that stuck in my mind from those
        discussions was "push to publish". There were those in IETF leadership
        who felt that it would significantly reduce costs and improve
        timeliness if an RFC could be published by, literally, pushing a
        button on a web interface the moment it was approved by the IESG. It
        would also, they argued, remove the specification issues being
        introduced by copy editors that were hired as occasional workers to
        help with improving publication rates but who weren't necessarily up
        to speed on terms of art in technical specifications. (There were some
        pretty egregious examples of copy editors introducing changes that
        significantly changed the technical meaning of the text that I forbear
        from citing here; let's just say it wasn't strictly a problem of
        Internet engineers getting uptight about their cheese being moved.)
        While "push to publish" would have addressed those issues, it would
        not have addressed the loss of clarity from the many significant text
        improvements copy editors successfully introduced, or the fact that
        not all RFCs are approved by the IESG.<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<p id="section-3.3-8">Institutionally, it was clear that the target was to have the RFC
        Editor function governance within the reach of the Internet technical
        community (as opposed to any particular private organization) without
        tying it specifically to the IETF. That was reasonably achievable by
        ensuring that the resultant pieces were established under the
        oversight of the IAB (which is, itself, independent of the IETF even
        as it is supported by the IASA organization).<a href="#section-3.3-8" class="pilcrow">¶</a></p>
<p id="section-3.3-9">The IETF worked on a document outlining functional requirements for
        its technical specification publication. This could have been useful
        for establishing its own series, but it also was helpful in
        establishing awareness of the challenges in document publishing (it
        always looks easy when you haven't thought about it) and also in
        laying the groundwork for dialogue with the RFC Editor. The
        requirements document was published as <span>[<a href="#RFC4714" class="xref">RFC4714</a>]</span> as an Informational RFC that stands today to
        provide guidance in the editing processes surrounding IETF
        publications.<a href="#section-3.3-9" class="pilcrow">¶</a></p>
<p id="section-3.3-10">There was still, however, a certain lack of clarity about
        responsibilities for making decisions and changes in the RFC Series
        itself. To that end, I and the IAB worked with the various involved
        parties to produce <span>[<a href="#RFC4844" class="xref">RFC4844</a>]</span>. That
        document captured the RFC Series mission (for a purpose greater than
        IETF technical specification publication) as well as the roles and
        responsibilities of the parties involved. The RFC Editor is
        responsible for ensuring the implementation of the mission. The IAB
        continues to have oversight responsibilities, including policy
        oversight, which it could act on by changing the person (organization)
        in the role of RFC Editor. At the same time, operational oversight was
        migrated to the IASA support function of the IETF (and IAB).<a href="#section-3.3-10" class="pilcrow">¶</a></p>
<p id="section-3.3-11">The discussions, and the resulting publication of <span>[<a href="#RFC4844" class="xref">RFC4844</a>]</span>, allowed greater visibility into and commitment to
        the RFC Series as a general Internet publication. It also meant that
        subsequent adjustments could be made as requirements evolved; the
        responsible parties are clearly identified.<a href="#section-3.3-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-continuation-or-creation-of-a-stream-nevil-brownlee">
<section id="section-3.4">
        <h3 id="name-the-continuation-or-creatio">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-the-continuation-or-creatio" class="section-name selfRef">The Continuation, or Creation, of a Stream - by Nevil Brownlee</a>
        </h3>
<p id="section-3.4-1">Arguably starting in 2006 with <span>[<a href="#RFC4714" class="xref">RFC4714</a>]</span>, the IAB and the IETF community spent some time in
        the mid-'00s evolving the structure of the RFC Series. This work
        included defining how those groups that published into the RFC Series
        (initially including the IETF, the IAB <span>[<a href="#RFC4845" class="xref">RFC4845</a>]</span>, and the Independent Submissions Stream <span>[<a href="#RFC4846" class="xref">RFC4846</a>]</span>, and later growing to include the
        IRTF <span>[<a href="#RFC5743" class="xref">RFC5743</a>]</span>) would handle approving
        documents to be published as RFCs. In 2009, the IAB published "RFC
 Editor Model (Version 1)" <span>[<a href="#RFC5620" class="xref">RFC5620</a>]</span>.  In
        this model, a new role was created within the RFC Editor: the RFC
        Series Editor (RSE). This individual would oversee RFC publishing
        and development while leaving the process for approving documents for
        publication outside his or her mandate. While, arguably, this was a role
        long filled by people like Jon Postel, Bob Braden, and Joyce Reynolds,
        <span>[<a href="#RFC5620" class="xref">RFC5620</a>]</span> saw the role of RFC Series Editor defined in
        such a way as to distinctly separate it from that of the Independent
        Submissions Editor (ISE).<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">Before 2009, the RFC Editor could accept "Independent" submissions
        from individuals and, if they were judged significant, publish them as
        RFCs; the Independent Stream was set up to continue that function.
        From February 2010 through February 2018, I was the ISE. After reading
        <span>[<a href="#RFC4846" class="xref">RFC4846</a>]</span>, I went on to develop the
        Independent Stream (IS).<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">First, I spent several days at the RFC Production Center at the
        Information Sciences Institute (ISI) in Marina Del Ray with the RFC
        Editor (Bob Braden), Sandy Ginoza, and Alice Hagens so as to learn how
        RFCs were actually edited and published. All RFCs reach the Production
        Center as Internet-Drafts; they are copy edited until the edited
        version can be approved by its authors (AUTH48).  At any stage,
        authors can check their draft's status via the RFC Editor website.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">For the Independent Submissions, Bob kept a journal (a simple ASCII
        file) of his interactions with authors for every draft, indexed by the
        draft name.  Bob also entered the Independent drafts into the RFC
        Editor database so that authors could track their draft's
        status. After my few days with his team at ISI, he handed that journal
        (covering about 30 drafts) over to me and said, "Now it's over to
        you!"<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<p id="section-3.4-5">I began by following in Bob's footsteps, maintaining a journal and
        tracking each draft's status in the RFC Editor database. My first
        consideration was that every serious Internet-Draft submitted needed
        several careful reviews.  At that time, if the ISE knew of suitable reviewers, he or
        she could simply ask them.  Otherwise, if the draft related to an IETF
        or IRTF Working Group, the ISE could ask Working Group Chairs or Area
        Directors to suggest reviewers. The Independent Submissions Editorial
        Board (Ed Board) was another place the ISE could request reviewers from.
        My experience with reviewers was that most of those I approached were
        happy to help.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
<p id="section-3.4-6">Most drafts were straightforward, but there were some that needed
        extra attention. Often, a draft requested IANA code points, and for
        that, IANA was always quick to offer help and support. Code points in
        some IANA registries require Expert Review <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>;
        sometimes the interactions with Expert Reviewers took quite a long
        time! Again, sometimes a draft seemed to fit better in the IETF
        Stream; for these, I would suggest that the draft authors try to find
        an Area Director to sponsor their work as an individual submission to
        the IETF Stream.<a href="#section-3.4-6" class="pilcrow">¶</a></p>
<p id="section-3.4-7">After my first few years as ISE, the IETF Tools Team developed the
        Datatracker <span>[<a href="#DATATRACKER" class="xref">DATATRACKER</a>]</span> to show draft status and
        perform all the "housekeeping" tasks for all of the streams.  At that
        stage, I switched to using the Datatracker rather than the RFC Editor
        database.<a href="#section-3.4-7" class="pilcrow">¶</a></p>
<p id="section-3.4-8">Once a draft has been reviewed and the authors have revised it in
        dialogue with their reviewers, the ISE must submit that draft to the
        IESG for an "IESG Review" <span>[<a href="#RFC5742" class="xref">RFC5742</a>]</span>. Overall, each IS draft benefited from discussions
        (which were usually simple) with my Ed Board and the IESG. A (very)
        few were somewhat controversial; for those, I was able to work
        with the IESG to negotiate a suitable "IESG Statement" and/or an "ISE
        Statement" to make it clear why the ISE published the draft.<a href="#section-3.4-8" class="pilcrow">¶</a></p>
<p id="section-3.4-9">One rather special part of the Independent Stream is the April 1st
        RFCs.  These are humorous RFCs that have no formal review and approval
        process.  The authors must send them directly to the ISE or the RFC
        Editor.  Only a few of them can be published each year, and each is
        reviewed by the ISE and the RSE. Bob Braden's criteria for April 1st
        drafts were:<a href="#section-3.4-9" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.4-10.1"> They must relate to the Internet (like all drafts).<a href="#section-3.4-10.1" class="pilcrow">¶</a>
</li>
<li id="section-3.4-10.2"> Their readers should reach the end of page two before realizing it is an April 1st RFC.<a href="#section-3.4-10.2" class="pilcrow">¶</a>
</li>
<li id="section-3.4-10.3"> They must actually be funny!<a href="#section-3.4-10.3" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-3.4-11">

April 1st RFCs have a large following, and feedback from the Internet
community on April 1st of each year has been enthusiastic and quick!<a href="#section-3.4-11" class="pilcrow">¶</a></p>
<p id="section-3.4-12">159 RFCs were published in the Independent Stream during my eight
        years as ISE. Over those eight years, I worked with most of their
        authors and often met with them at IETF meetings. For me, that was a
        very rewarding experience, so I thank all those that
        contributed. During those eight years, I also worked with most of the
        IESG members, who all also gave me a lot of helpful
        interaction. Lastly, I've always enjoyed working with the RSE and all
        the staff of the RFC Production Center.

 The IETF (as a whole) is very fortunate to have such an
        effective team of talented professional staff.<a href="#section-3.4-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="a-view-from-inside-the-rfc-editor-sandy-ginoza">
<section id="section-3.5">
        <h3 id="name-a-view-from-inside-the-rfc-">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-a-view-from-inside-the-rfc-" class="section-name selfRef">A View from inside the RFC Editor - by Sandy
 Ginoza</a>
        </h3>
<p id="section-3.5-1">When I joined ISI, shortly after Jon Postel passed away,
 the RFC Editor model as
  we know it today (as defined in <span>[<a href="#RFC5620" class="xref">RFC5620</a>]</span> and as obsoleted by <span>[<a href="#RFC6548" class="xref">RFC6548</a>]</span> and
  <span>[<a href="#RFC6635" class="xref">RFC6635</a>]</span>) did not exist. The RFC Editor functioned as one unit: there was no
  RSE, Production Center, Publisher, or Independent Submissions
  Editor.

  All of these roles were performed by the "RFC Editor", which was comprised
  of four individuals: Bob Braden, Joyce Reynolds, a part-time student
  programmer, and me.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">Bob provided high-level guidance and reviewed Independent
        Submissions. While Bob was a researcher in "Div 7" (Networking) at
        ISI, ostensibly, the percentage of time he had for the RFC Editor was
        10%, but he invested much more time to keep the Series running.  He
        pitched in where he could, especially when processing times were
        getting longer; at one point, he even NROFFed a couple of RFCs-to-be.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<p id="section-3.5-3"> Joyce was a full-time ISI employee.  However, while continuing to
    ensure RFCs were published, she was also serving as a User Services Area
    Director and a keynote speaker about the Internet, and she was also
    temporarily on loan to IANA for 50% of her time while IANA was getting
    established after separating from ISI.  The student programmer performed
    programming tasks as requested and was, at the time, responsible for
    parsing MIBs.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<p id="section-3.5-4"> 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).<a href="#section-3.5-4" class="pilcrow">¶</a></p>
<p id="section-3.5-5">The workload increased significantly over the next few years.  As the
  workload increased, the RFC Editor reacted and slowly grew their staff over
  time.  To understand the team growth, let's first take a look at the
  publication rates throughout history.  The table below shows average annual
  publication rates during 5-year periods.<a href="#section-3.5-5" class="pilcrow">¶</a></p>
<span id="name-annual-publication-rates"></span><div id="AvgPubs">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-annual-publication-rates" class="selfRef">Annual Publication Rates</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Years</th>
              <th class="text-center" rowspan="1" colspan="1">Avg. Pubs per Year</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1969 - 1972</td>
              <td class="text-center" rowspan="1" colspan="1">80</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1973 - 1977</td>
              <td class="text-center" rowspan="1" colspan="1">55</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1978 - 1982</td>
              <td class="text-center" rowspan="1" colspan="1">20</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1983 - 1987</td>
              <td class="text-center" rowspan="1" colspan="1">39</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1988 - 1992</td>
              <td class="text-center" rowspan="1" colspan="1">69</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1993 - 1997</td>
              <td class="text-center" rowspan="1" colspan="1">171</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1998 - 2002</td>
              <td class="text-center" rowspan="1" colspan="1">237</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2003 - 2007</td>
              <td class="text-center" rowspan="1" colspan="1">325</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2008 - 2012</td>
              <td class="text-center" rowspan="1" colspan="1">333</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2013 - 2017</td>
              <td class="text-center" rowspan="1" colspan="1">295</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.5-7">There were significant jumps in the publication rates in the '90s and onward,
  with the number of publications almost doubling between 1993 and 2007.  The
  annual submission count surpassed the 300 mark for the first time in 2004 and
  reached an all-time high of 385 in 2011.  The submission rate did not drop
  below 300 until 2016 (284).<a href="#section-3.5-7" class="pilcrow">¶</a></p>
<p id="section-3.5-8">As the submissions grew, the RFC Editor experienced growing pains. Processing
  times began to increase as the existing staff was unable to keep up with the
  expanding queue size.  In an attempt to reduce the training hump and to avoid
  permanently hiring staff in case the submission burst was a fluke, ISI brought
  on temporary copy editors; this way, the staff could easily be resized as
  needed.  However, as Leslie noted, this didn't work very well. The effects of
  the experiment would be lasting, as this led to a form of the process we have
  now, where the RFC Editor asks more questions during AUTH/AUTH48 and technical
  changes require approval from the relevant Area Directors or stream managers,
  depending on the document stream. These changes added
  to the workload and extended publication times; many often now jokingly refer
  to AUTH48 as the authors' "48 days", "48 weeks", etc.<a href="#section-3.5-8" class="pilcrow">¶</a></p>
<p id="section-3.5-9">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.<a href="#section-3.5-9" class="pilcrow">¶</a></p>
<p id="section-3.5-10">With the understanding that the record-breaking number of submissions was not an
  anomaly, we made significant upgrades to the infrastructure of the RFC Editor
  function to facilitate document tracking and reporting.  For example, the
  illustrious "black binder" (an actual 3-ring binder used to track
  RFC number
  assignment), a manually edited HTML file for the queue page, and a
  Rube Goldberg
  set of text files and scripts that created queue statistics, all were eventually
  replaced; an errata system was proposed and implemented; and XML became a newly
  accepted source file.<a href="#section-3.5-10" class="pilcrow">¶</a></p>
<p id="section-3.5-11">In 2009, <span>[<a href="#RFC5620" class="xref">RFC5620</a>]</span> was published, introducing the initial version of the RFC
  Editor model we have now.  While it was published in 2009, it did not go into
  effect until 2010, when the RFC Editor project as I knew it was disbanded and
  divvied up into four pieces: RFC Series Editor (RSE), Independent Submissions
  Editor (ISE), RFC Production Center (RPC), and the Publisher function.  In addition, the
  RFC Series Advisory Group (RSAG) was created to "provide expert, informed
  guidance (chiefly, to the RSE) in matters affecting the RFC Series operation
  and development" <span>[<a href="#RSAG" class="xref">RSAG</a>]</span>.<a href="#section-3.5-11" class="pilcrow">¶</a></p>
<p id="section-3.5-12">In 2010, the RPC and Publisher contracts were awarded to
        Association Management Solutions (AMS).  There, we started with three existing
        team members (Alice Russo, Megan Ferguson, and me), and we were pleased
        to be joined by Lynne Bartholomew and Rebecca VanRheenen, new colleagues to anchor us in the
        AMS office.<a href="#section-3.5-12" class="pilcrow">¶</a></p>
<p id="section-3.5-13">I was wary of this model and was especially worried about the hole Bob
  Braden's departure would create.  Luckily for us, Bob Braden provided wise
  counsel and insight during the transition (and beyond). He gave the staff
  transitioning to AMS particularly helpful parting words, "keep the RFCs
  coming", and that is what we did.<a href="#section-3.5-13" class="pilcrow">¶</a></p>
<p id="section-3.5-14">AMS embraced the RFC Series and helped us quickly get set up on new servers.
  The RFC Production Center and Publisher were now part of the AMS family and
  it was all hands on deck to make sure the transition went smoothly to minimize
  the impact on document processing.<a href="#section-3.5-14" class="pilcrow">¶</a></p>
<p id="section-3.5-15">Our focus during transition was to 1) keep the trains running; that
        is, we wanted to get ourselves up and running with minimal down time,
        and 2) work with the Transitional RSE (a role that concluded before
        the transition ended), the ISE (Nevil Brownlee), RSAG, and the IETF
        Administrative Director (IAD) to better understand and implement the
        newly defined RFC Editor model.<a href="#section-3.5-15" class="pilcrow">¶</a></p>
<p id="section-3.5-16">Though some portions of the transition were challenging and lasted
        longer than expected, the Acting RSE (Olaf Kolkman) officially handed
        the reins over to the new RSE (Heather Flanagan) in 2012.  She had to
        jump in, learn the RFC Editor and IETF culture, and work through a
        backlog of issues that had been left unattended.<a href="#section-3.5-16" class="pilcrow">¶</a></p>
<p id="section-3.5-17">Two of the backlogged issues were so old that they were ones someone
        had asked me about at my first IETF meeting: When was the RFC Editor going to
        allow non-ASCII characters in RFCs? When would the RFC Editor adopt
        a more modern publication format?<a href="#section-3.5-17" class="pilcrow">¶</a></p>
<p id="section-3.5-18">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 <span>&lt;<a href="https://www.rfc-editor.org">https://www.rfc-editor.org</a>&gt;</span>
         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.<a href="#section-3.5-18" class="pilcrow">¶</a></p>
<p id="section-3.5-19">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.<a href="#section-3.5-19" class="pilcrow">¶</a></p>
<p id="section-3.5-20">Interestingly enough, I find that the RFC Editor has been in an almost
  constant state of change since I joined the team, even though the goal of the
  RFC Editor remains the same: to produce archival quality RFCs in a timely
  manner that are easily accessible for future generations.<a href="#section-3.5-20" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="the-next-fifty-years-of-rfcs">
<section id="section-4">
      <h2 id="name-the-next-fifty-years-of-rfc">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-the-next-fifty-years-of-rfc" class="section-name selfRef">The Next Fifty Years of   RFCs</a>
      </h2>
<p id="section-4-1">As Steve Crocker mentioned, the Series began with goals of communication
    over formality and openness over structure. As the Internet has grown and become a
    pervasive, global construct, we still aim for openness and communication, but
    recognize that for protocols and other information to support interoperability,
    there must be points of stability to build from. Everyone, from small-time app developers to
    multi-billion dollar companies, is on the same footing. Anyone should be able to look back
    at a point in time and understand what was done and why.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">While the informality has given way to increased structure, the openness and
    solid foundation that the Series provides must continue. With that in mind,
    what does the future hold for the next fifty years of RFCs?<a href="#section-4-2" class="pilcrow">¶</a></p>
<div id="preservation">
<section id="section-4.1">
        <h3 id="name-preservation">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-preservation" class="section-name selfRef">Preservation</a>
        </h3>
<p id="section-4.1-1">The RFC Editor exists to edit, publish, and maintain an archive of documents
    published in the RFC Series. A proper digital archive, however, is more than
    just saving RFCs to disk and making sure the disks are backed up; the field
    of digital preservation has grown and transformed into an industry in and of
    itself. "Digital Preservation Considerations for the RFC Series" <span>[<a href="#RFC8153" class="xref">RFC8153</a>]</span>
    reviews what a digital archive means today and describes ways to support the
    archive into the future. It also recommends ways for the RFC Editor to take
    advantage of those organizations that specialize in this field.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">The future of digital preservation, as far as the RFC Series is concerned,
    will mean both finding new partners that can absorb and archive RFCs into
    a public, maintained digital archive and reviewing the RFC format to ensure
    that the published documents are archivable according to whatever the
    industry best practice is over time.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="futureformat">
<section id="section-4.2">
        <h3 id="name-evolution-of-the-rfc-format">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-evolution-of-the-rfc-format" class="section-name selfRef">Evolution of the RFC Format</a>
        </h3>
<p id="section-4.2-1">RFCs have been digital documents since very early in the days of the
    Series. While not always published in US-ASCII, that format has been the
    canonical format for decades. The fact that this format has lasted through
    so much evolution and change is remarkable.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">Unfortunately, the US-ASCII format does not extend enough to meet
        the expectations and requirements of many users today.

 The entire field of online document presentation, consumption, and
 preservation has, in some cases, only been invented years after the
 first RFC was published. While it can be (and has been) argued that
 those newer fields and their tools have not had a chance to stand the
 test of time, the RFC Series Editor (in consultation with the
 community) started a concerted effort in 2012 to bring the RFC Series
 into alignment with a new array of possibilities for preservation and
 display.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">Information on the RFC format project and the initial reasoning and
        requirements for the changes underway can be found in <span>[<a href="#RFC7990" class="xref">RFC7990</a>]</span>.  With the advent of these
        changes, the door has been opened to consider further changes in the
        future as the specifications for archiving digital material evolves,
        and as the expectation of web development advances.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="streamstructure">
<section id="section-4.3">
        <h3 id="name-stream-structure">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-stream-structure" class="section-name selfRef">Stream Structure</a>
        </h3>
<p id="section-4.3-1">In the eyes of many, particularly within the IETF, the
  RFC Series is synonymous with the IETF. While the Series itself predates the
  IETF by eighteen years, over time, the IETF has become the source of the
  majority of documents submitted for publication to the RFC Editor. The
  policies developed for IETF Stream drafts tend to apply across all four
  document streams, and publication-related tools tend to focus on the IETF as
  the primary audience for their use. It is difficult for people to see how, or
  even why, there is a distinction between the Series and the IETF.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">We are in the midst of that question now more than ever. What is the future
  of the Series? If people cannot tell where the IETF ends and the Series
  starts, should we consider this an artificial distinction and declare them to
  be the same entity?<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">Ultimately, this will be something the community decides, and conversations
  are underway to consider the ramifications of possible changes.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="conclusion">
<section id="section-5">
      <h2 id="name-conclusion">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-conclusion" class="section-name selfRef">Conclusion</a>
      </h2>
<p id="section-5-1">As the Internet evolves, expectations and possibilities evolve, too. Over
    the next fifty years, the Series will continue to demonstrate a balance between
    the need to stay true to the original mission of publication and
    preservation, while also staying relevant to the needs of the authors and
    consumers of RFCs. The tension in balancing those needs rests on the RFC
    Editor and the community to resolve. We will not run short of challenges.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">This document has no security considerations.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-informative-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="APPRENTICE">[APPRENTICE]</dt>
<dd>
<span class="refAuthor">Wikipedia</span>, <span class="refTitle">"The Sorcerer's Apprentice"</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://en.wikipedia.org/w/index.php?title=The_Sorcerer%27s_Apprentice&amp;oldid=925824658">https://en.wikipedia.org/w/index.php?title=The_Sorcerer%27s_Apprentice&amp;oldid=925824658</a>&gt;</span>. </dd>
<dt id="DATATRACKER">[DATATRACKER]</dt>
<dd>
<span class="refAuthor">Internet Engineering Task Force</span>, <span class="refTitle">"IETF Datatracker"</span>, <span>&lt;<a href="https://datatracker.ietf.org">https://datatracker.ietf.org</a>&gt;</span>. </dd>
<dt id="IAB-19880712">[IAB-19880712]</dt>
<dd>
<span class="refAuthor">IAB</span>, <span class="refTitle">"IAB Minutes 1988-07-12"</span>, <time datetime="1988-07">July 1988</time>, <span>&lt;<a href="https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-07-12/">https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-07-12/</a>&gt;</span>. </dd>
<dt id="IETF1">[IETF1]</dt>
<dd>
<span class="refAuthor">The MITRE Corporation</span>, <span class="refTitle">"Proceedings of the 16-17 January 1986 DARPA Gateway Algorithms and Data Structures Task Force"</span>, <span class="refContent">IETF 1
</span>, <time datetime="1986-01">January 1986</time>, <span>&lt;<a href="https://www.ietf.org/old/2009/proceedings/prior29/IETF01.pdf">https://www.ietf.org/old/2009/proceedings/prior29/IETF01.pdf</a>&gt;</span>. </dd>
<dt id="ISI-to-AMS">[ISI-to-AMS]</dt>
<dd>
<span class="refAuthor">IETF Administrative Support Activity (IASA)</span>, <span class="refTitle">"RFC Production Center Agreement between Association Management Solutions, LLC and The Internet Society"</span>, <time datetime="2009-10">October 2009</time>, <span>&lt;<a href="https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-2009.pdf">https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-2009.pdf</a>&gt;</span>. </dd>
<dt id="RFC-ONLINE">[RFC-ONLINE]</dt>
<dd>
<span class="refAuthor">RFC Editor</span>, <span class="refTitle">"History of RFC Online Project"</span>, <time datetime="2000">2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc-online-2000.html">https://www.rfc-editor.org/rfc-online-2000.html</a>&gt;</span>. </dd>
<dt id="RFC0001">[RFC0001]</dt>
<dd>
<span class="refAuthor">Crocker, S.</span>, <span class="refTitle">"Host Software"</span>, <span class="seriesInfo">RFC 1</span>, <span class="seriesInfo">DOI 10.17487/RFC0001</span>, <time datetime="1969-04">April 1969</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1">https://www.rfc-editor.org/info/rfc1</a>&gt;</span>. </dd>
<dt id="RFC0003">[RFC0003]</dt>
<dd>
<span class="refAuthor">Crocker, S.</span>, <span class="refTitle">"Documentation conventions"</span>, <span class="seriesInfo">RFC 3</span>, <span class="seriesInfo">DOI 10.17487/RFC0003</span>, <time datetime="1969-04">April 1969</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3">https://www.rfc-editor.org/info/rfc3</a>&gt;</span>. </dd>
<dt id="RFC0114">[RFC0114]</dt>
<dd>
<span class="refAuthor">Bhushan, A.</span>, <span class="refTitle">"File Transfer Protocol"</span>, <span class="seriesInfo">RFC 114</span>, <span class="seriesInfo">DOI 10.17487/RFC0114</span>, <time datetime="1971-04">April 1971</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc114">https://www.rfc-editor.org/info/rfc114</a>&gt;</span>. </dd>
<dt id="RFC0433">[RFC0433]</dt>
<dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Socket number list"</span>, <span class="seriesInfo">RFC 433</span>, <span class="seriesInfo">DOI 10.17487/RFC0433</span>, <time datetime="1972-12">December 1972</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc433">https://www.rfc-editor.org/info/rfc433</a>&gt;</span>. </dd>
<dt id="RFC0690">[RFC0690]</dt>
<dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Comments on the proposed Host/IMP Protocol changes"</span>, <span class="seriesInfo">RFC 690</span>, <span class="seriesInfo">DOI 10.17487/RFC0690</span>, <time datetime="1975-06">June 1975</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc690">https://www.rfc-editor.org/info/rfc690</a>&gt;</span>. </dd>
<dt id="RFC0748">[RFC0748]</dt>
<dd>
<span class="refAuthor">Crispin, M.</span>, <span class="refTitle">"Telnet randomly-lose option"</span>, <span class="seriesInfo">RFC 748</span>, <span class="seriesInfo">DOI 10.17487/RFC0748</span>, <time datetime="1978-04">April 1978</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc748">https://www.rfc-editor.org/info/rfc748</a>&gt;</span>. </dd>
<dt id="RFC0902">[RFC0902]</dt>
<dd>
<span class="refAuthor">Reynolds, J.</span><span class="refAuthor"> and J. Postel</span>, <span class="refTitle">"ARPA Internet Protocol policy"</span>, <span class="seriesInfo">RFC 902</span>, <span class="seriesInfo">DOI 10.17487/RFC0902</span>, <time datetime="1984-07">July 1984</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc902">https://www.rfc-editor.org/info/rfc902</a>&gt;</span>. </dd>
<dt id="RFC1000">[RFC1000]</dt>
<dd>
<span class="refAuthor">Reynolds, J.</span><span class="refAuthor"> and J. Postel</span>, <span class="refTitle">"Request For Comments reference guide"</span>, <span class="seriesInfo">RFC 1000</span>, <span class="seriesInfo">DOI 10.17487/RFC1000</span>, <time datetime="1987-08">August 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1000">https://www.rfc-editor.org/info/rfc1000</a>&gt;</span>. </dd>
<dt id="RFC1083">[RFC1083]</dt>
<dd>
<span class="refAuthor">Defense Advanced Research Projects Agency</span><span class="refAuthor"> and Internet Activities Board</span>, <span class="refTitle">"IAB official protocol standards"</span>, <span class="seriesInfo">RFC 1083</span>, <span class="seriesInfo">DOI 10.17487/RFC1083</span>, <time datetime="1988-12">December 1988</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1083">https://www.rfc-editor.org/info/rfc1083</a>&gt;</span>. </dd>
<dt id="RFC1122">[RFC1122]</dt>
<dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refTitle">"Requirements for Internet Hosts - Communication Layers"</span>, <span class="seriesInfo">STD 3</span>, <span class="seriesInfo">RFC 1122</span>, <span class="seriesInfo">DOI 10.17487/RFC1122</span>, <time datetime="1989-10">October 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1122">https://www.rfc-editor.org/info/rfc1122</a>&gt;</span>. </dd>
<dt id="RFC1123">[RFC1123]</dt>
<dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refTitle">"Requirements for Internet Hosts - Application and Support"</span>, <span class="seriesInfo">STD 3</span>, <span class="seriesInfo">RFC 1123</span>, <span class="seriesInfo">DOI 10.17487/RFC1123</span>, <time datetime="1989-10">October 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1123">https://www.rfc-editor.org/info/rfc1123</a>&gt;</span>. </dd>
<dt id="RFC1150">[RFC1150]</dt>
<dd>
<span class="refAuthor">Malkin, G.</span><span class="refAuthor"> and J. Reynolds</span>, <span class="refTitle">"FYI on FYI: Introduction to the FYI Notes"</span>, <span class="seriesInfo">RFC 1150</span>, <span class="seriesInfo">DOI 10.17487/RFC1150</span>, <time datetime="1990-03">March 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1150">https://www.rfc-editor.org/info/rfc1150</a>&gt;</span>. </dd>
<dt id="RFC1311">[RFC1311]</dt>
<dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Introduction to the STD Notes"</span>, <span class="seriesInfo">RFC 1311</span>, <span class="seriesInfo">DOI 10.17487/RFC1311</span>, <time datetime="1992-03">March 1992</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1311">https://www.rfc-editor.org/info/rfc1311</a>&gt;</span>. </dd>
<dt id="RFC1818">[RFC1818]</dt>
<dd>
<span class="refAuthor">Postel, J.</span><span class="refAuthor">, Li, T.</span><span class="refAuthor">, and Y. Rekhter</span>, <span class="refTitle">"Best Current Practices"</span>, <span class="seriesInfo">RFC 1818</span>, <span class="seriesInfo">DOI 10.17487/RFC1818</span>, <time datetime="1995-08">August 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1818">https://www.rfc-editor.org/info/rfc1818</a>&gt;</span>. </dd>
<dt id="RFC2441">[RFC2441]</dt>
<dd>
<span class="refAuthor">Cohen, D.</span>, <span class="refTitle">"Working with Jon, Tribute delivered at UCLA, October 30, 1998"</span>, <span class="seriesInfo">RFC 2441</span>, <span class="seriesInfo">DOI 10.17487/RFC2441</span>, <time datetime="1998-11">November 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2441">https://www.rfc-editor.org/info/rfc2441</a>&gt;</span>. </dd>
<dt id="RFC2468">[RFC2468]</dt>
<dd>
<span class="refAuthor">Cerf, V.</span>, <span class="refTitle">"I REMEMBER IANA"</span>, <span class="seriesInfo">RFC 2468</span>, <span class="seriesInfo">DOI 10.17487/RFC2468</span>, <time datetime="1998-10">October 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2468">https://www.rfc-editor.org/info/rfc2468</a>&gt;</span>. </dd>
<dt id="RFC2555">[RFC2555]</dt>
<dd>
<span class="refAuthor">Editor, RFC.</span><span class="refAuthor"> and et. al.</span>, <span class="refTitle">"30 Years of RFCs"</span>, <span class="seriesInfo">RFC 2555</span>, <span class="seriesInfo">DOI 10.17487/RFC2555</span>, <time datetime="1999-04">April 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2555">https://www.rfc-editor.org/info/rfc2555</a>&gt;</span>. </dd>
<dt id="RFC4714">[RFC4714]</dt>
<dd>
<span class="refAuthor">Mankin, A.</span><span class="refAuthor"> and S. Hayes</span>, <span class="refTitle">"Requirements for IETF Technical Publication Service"</span>, <span class="seriesInfo">RFC 4714</span>, <span class="seriesInfo">DOI 10.17487/RFC4714</span>, <time datetime="2006-10">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4714">https://www.rfc-editor.org/info/rfc4714</a>&gt;</span>. </dd>
<dt id="RFC4844">[RFC4844]</dt>
<dd>
<span class="refAuthor">Daigle, L., Ed.</span><span class="refAuthor"> and Internet Architecture Board</span>, <span class="refTitle">"The RFC Series and RFC Editor"</span>, <span class="seriesInfo">RFC 4844</span>, <span class="seriesInfo">DOI 10.17487/RFC4844</span>, <time datetime="2007-07">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4844">https://www.rfc-editor.org/info/rfc4844</a>&gt;</span>. </dd>
<dt id="RFC4845">[RFC4845]</dt>
<dd>
<span class="refAuthor">Daigle, L., Ed.</span><span class="refAuthor"> and Internet Architecture Board</span>, <span class="refTitle">"Process for Publication of IAB RFCs"</span>, <span class="seriesInfo">RFC 4845</span>, <span class="seriesInfo">DOI 10.17487/RFC4845</span>, <time datetime="2007-07">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4845">https://www.rfc-editor.org/info/rfc4845</a>&gt;</span>. </dd>
<dt id="RFC4846">[RFC4846]</dt>
<dd>
<span class="refAuthor">Klensin, J., Ed.</span><span class="refAuthor"> and D. Thaler, Ed.</span>, <span class="refTitle">"Independent Submissions to the RFC Editor"</span>, <span class="seriesInfo">RFC 4846</span>, <span class="seriesInfo">DOI 10.17487/RFC4846</span>, <time datetime="2007-07">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4846">https://www.rfc-editor.org/info/rfc4846</a>&gt;</span>. </dd>
<dt id="RFC5540">[RFC5540]</dt>
<dd>
<span class="refAuthor">Editor, RFC.</span>, <span class="refTitle">"40 Years of RFCs"</span>, <span class="seriesInfo">RFC 5540</span>, <span class="seriesInfo">DOI 10.17487/RFC5540</span>, <time datetime="2009-04">April 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5540">https://www.rfc-editor.org/info/rfc5540</a>&gt;</span>. </dd>
<dt id="RFC5620">[RFC5620]</dt>
<dd>
<span class="refAuthor">Kolkman, O., Ed.</span><span class="refAuthor"> and IAB</span>, <span class="refTitle">"RFC Editor Model (Version 1)"</span>, <span class="seriesInfo">RFC 5620</span>, <span class="seriesInfo">DOI 10.17487/RFC5620</span>, <time datetime="2009-08">August 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5620">https://www.rfc-editor.org/info/rfc5620</a>&gt;</span>. </dd>
<dt id="RFC5742">[RFC5742]</dt>
<dd>
<span class="refAuthor">Alvestrand, H.</span><span class="refAuthor"> and R. Housley</span>, <span class="refTitle">"IESG Procedures for Handling of Independent and IRTF Stream Submissions"</span>, <span class="seriesInfo">BCP 92</span>, <span class="seriesInfo">RFC 5742</span>, <span class="seriesInfo">DOI 10.17487/RFC5742</span>, <time datetime="2009-12">December 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5742">https://www.rfc-editor.org/info/rfc5742</a>&gt;</span>. </dd>
<dt id="RFC5743">[RFC5743]</dt>
<dd>
<span class="refAuthor">Falk, A.</span>, <span class="refTitle">"Definition of an Internet Research Task Force (IRTF) Document Stream"</span>, <span class="seriesInfo">RFC 5743</span>, <span class="seriesInfo">DOI 10.17487/RFC5743</span>, <time datetime="2009-12">December 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5743">https://www.rfc-editor.org/info/rfc5743</a>&gt;</span>. </dd>
<dt id="RFC6360">[RFC6360]</dt>
<dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Conclusion of FYI RFC Sub-Series"</span>, <span class="seriesInfo">RFC 6360</span>, <span class="seriesInfo">DOI 10.17487/RFC6360</span>, <time datetime="2011-08">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6360">https://www.rfc-editor.org/info/rfc6360</a>&gt;</span>. </dd>
<dt id="RFC6410">[RFC6410]</dt>
<dd>
<span class="refAuthor">Housley, R.</span><span class="refAuthor">, Crocker, D.</span><span class="refAuthor">, and E. Burger</span>, <span class="refTitle">"Reducing the Standards Track to Two Maturity Levels"</span>, <span class="seriesInfo">BCP 9</span>, <span class="seriesInfo">RFC 6410</span>, <span class="seriesInfo">DOI 10.17487/RFC6410</span>, <time datetime="2011-10">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6410">https://www.rfc-editor.org/info/rfc6410</a>&gt;</span>. </dd>
<dt id="RFC6548">[RFC6548]</dt>
<dd>
<span class="refAuthor">Brownlee, N., Ed.</span><span class="refAuthor"> and IAB</span>, <span class="refTitle">"Independent Submission Editor Model"</span>, <span class="seriesInfo">RFC 6548</span>, <span class="seriesInfo">DOI 10.17487/RFC6548</span>, <time datetime="2012-06">June 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6548">https://www.rfc-editor.org/info/rfc6548</a>&gt;</span>. </dd>
<dt id="RFC6635">[RFC6635]</dt>
<dd>
<span class="refAuthor">Kolkman, O., Ed.</span><span class="refAuthor">, Halpern, J., Ed.</span><span class="refAuthor">, and IAB</span>, <span class="refTitle">"RFC Editor Model (Version 2)"</span>, <span class="seriesInfo">RFC 6635</span>, <span class="seriesInfo">DOI 10.17487/RFC6635</span>, <time datetime="2012-06">June 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6635">https://www.rfc-editor.org/info/rfc6635</a>&gt;</span>. </dd>
<dt id="RFC6949">[RFC6949]</dt>
<dd>
<span class="refAuthor">Flanagan, H.</span><span class="refAuthor"> and N. Brownlee</span>, <span class="refTitle">"RFC Series Format Requirements and Future Development"</span>, <span class="seriesInfo">RFC 6949</span>, <span class="seriesInfo">DOI 10.17487/RFC6949</span>, <time datetime="2013-05">May 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6949">https://www.rfc-editor.org/info/rfc6949</a>&gt;</span>. </dd>
<dt id="RFC7990">[RFC7990]</dt>
<dd>
<span class="refAuthor">Flanagan, H.</span>, <span class="refTitle">"RFC Format Framework"</span>, <span class="seriesInfo">RFC 7990</span>, <span class="seriesInfo">DOI 10.17487/RFC7990</span>, <time datetime="2016-12">December 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7990">https://www.rfc-editor.org/info/rfc7990</a>&gt;</span>. </dd>
<dt id="RFC8126">[RFC8126]</dt>
<dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dt id="RFC8153">[RFC8153]</dt>
<dd>
<span class="refAuthor">Flanagan, H.</span>, <span class="refTitle">"Digital Preservation Considerations for the RFC Series"</span>, <span class="seriesInfo">RFC 8153</span>, <span class="seriesInfo">DOI 10.17487/RFC8153</span>, <time datetime="2017-04">April 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8153">https://www.rfc-editor.org/info/rfc8153</a>&gt;</span>. </dd>
<dt id="RSAG">[RSAG]</dt>
<dd>
<span class="refAuthor">RFC Editor</span>, <span class="refTitle">"RFC Series Advisory Group"</span>, <span>&lt;<a href="https://www.rfc-editor.org/about/rsag/">https://www.rfc-editor.org/about/rsag/</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-appendix.a">
      <h2 id="name-iab-members-at-the-time-of-">
<a href="#name-iab-members-at-the-time-of-" class="section-name selfRef">IAB Members at the Time of Approval</a>
      </h2>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-appendix.a-1.1">Jari Arkko<a href="#section-appendix.a-1.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.2">Alissa Cooper<a href="#section-appendix.a-1.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.3">Stephen Farrell<a href="#section-appendix.a-1.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.4">Wes Hardaker<a href="#section-appendix.a-1.4" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.5">Ted Hardie<a href="#section-appendix.a-1.5" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.6">Christian Huitema<a href="#section-appendix.a-1.6" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.7">Zhenbin Li<a href="#section-appendix.a-1.7" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.8">Erik Nordmark<a href="#section-appendix.a-1.8" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.9">Mark Nottingham<a href="#section-appendix.a-1.9" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.10">Melinda Shore<a href="#section-appendix.a-1.10" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.11">Jeff Tantsura<a href="#section-appendix.a-1.11" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.12">Martin Thomson<a href="#section-appendix.a-1.12" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-appendix.a-1.13">Brian Trammell<a href="#section-appendix.a-1.13" class="pilcrow">¶</a>
</li>
</ul>
</section>
<div id="Acknowledgements">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">Many thanks to John Klensin for his feedback and insights on the
      history of the Series, as someone who directly engaged and influenced
      many of the key individuals involved in developing the RFC Series.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">Additional thanks to members of the RFC Series Advisory group and the
      Independent Submissions Editorial Board, in particular, Scott Bradner,
      Brian Carpenter, and Adrian Farrel, for their early reviews and input
      into the sequence of key moments in the history of the Series.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contributors">
<section id="section-appendix.c">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.c-1">Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil Brownlee, and
       Sandy Ginoza for their perspectives on the Series and their ongoing support.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Heather Flanagan (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">RFC Editor</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rse@rfc-editor.org" class="email">rse@rfc-editor.org</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://orcid.org/0000-0002-2647-2220" class="url">https://orcid.org/0000-0002-2647-2220</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>