rfc8963xml2.original.xml   rfc8963.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docN
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.4 --> ame="draft-huitema-rfc-eval-project-07" indexInclude="true" ipr="trust200902" nu
mber="8963" prepTime="2021-01-12T22:14:50" scripts="Common,Latin" sortRefs="true
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ " submissionType="independent" symRefs="true" tocDepth="3" tocInclude="true" xml
]> :lang="en">
<link href="https://datatracker.ietf.org/doc/draft-huitema-rfc-eval-project-07
<?rfc toc="yes"?> " rel="prev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8963" rel="alternate"/>
<?rfc symrefs="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc comments="yes"?>
<rfc ipr="trust200902" docName="draft-huitema-rfc-eval-project-07" category="inf
o">
<front> <front>
<title abbrev="RFC-Eval-2018">Evaluation of a Sample of RFC Produced in 2018 <title abbrev="RFC Evaluation 2018">Evaluation of a Sample of RFCs Produced
</title> in 2018</title>
<seriesInfo name="RFC" value="8963" stream="independent"/>
<author initials="C." surname="Huitema" fullname="Christian Huitema"> <author initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus Inc.</organization> <organization showOnFrontPage="true">Private Octopus Inc.</organization>
<address> <address>
<postal> <postal>
<street>427 Golfcourse Rd</street> <street>427 Golfcourse Rd</street>
<city>Friday Harbor</city> <city>Friday Harbor</city>
<code>WA 98250</code> <region>WA</region>
<country>U.S.A</country> <code>98250</code>
<country>United States of America</country>
</postal> </postal>
<email>huitema@huitema.net</email> <email>huitema@huitema.net</email>
</address> </address>
</author> </author>
<date month="01" year="2021"/>
<date year="2020"/> <keyword>RFC Series</keyword>
<keyword>Independent Submissions Editor</keyword>
<area>General</area> <keyword>documents</keyword>
<keyword>publications</keyword>
<keyword>Internet-Draft</keyword> <keyword>publication delays</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">This document presents the author's
effort to understand the delays involved
<t>This document presents the author's effort to understand the delays involved
in publishing an idea in the IETF or through the Independent Stream, from the in publishing an idea in the IETF or through the Independent Stream, from the
first individual draft to the publication of the RFC. first individual draft to the publication of the RFC.
We analyze a set of randomly chosen RFC approved in 2018, looking for history We analyze a set of randomly chosen RFCs approved in 2018, looking for history
and delays. We also use two randomly chosen sets of RFC published in 2008 and 19 and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1
98 998
for comparing delays seen in 2018 to those observed 10 or 20 years ago. for comparing delays seen in 2018 to those observed 10 or 20 years ago.
The average RFC in the 2018 sample was produced in 3 years and 4 months, The average RFC in the 2018 sample was produced in 3 years and 4 months,
of which 2 years and 10 months were spent in the Working Group, of which 2 years and 10 months were spent in the working group,
3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC
production. The main variation in RFC production delays comes from production. The main variation in RFC production delays comes from
the AUTH-48 phase.</t> the AUTH48 phase.</t>
<t indent="0" pn="section-abstract-2">We also measure the number of citati
<t>We also measure the number of citations of the chosen RFC using Semantic ons of the chosen RFC using Semantic
Scholar, and compare citation counts with what we know about deployment. Scholar, and compare citation counts with what we know about deployment.
We show that citation counts indicate academic interest, but We show that citation counts indicate academic interest, but
correlate only loosely with deployment or usage of the specifications. correlate only loosely with deployment or usage of the specifications.
Counting web references could complement that.</t> Counting web references could complement that.</t>
<t>The RFCs selected for this survey were chosen at random and represent
a small sample of all RFCs produced, and only approximately 10% of
the RFCs produced in each of 1998, 2008, and 2018. It is possible
that different samples would produce different results. Furthermore,
the conclusions drawn from the observations made in this document
represent the author's opinions and do not have consensus of the
IETF.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for informational purposes.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
</t>
<t indent="0" pn="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
<eref target="https://www.rfc-editor.org/info/rfc8963" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-methodology">Methodology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-de
fining-the-important-mile">Defining the Important Milestones</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-se
lecting-a-random-sample-o">Selecting a Random Sample of RFCs</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-conventions-used-in-th
is-do">Conventions Used in This Document</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-analysis-of-20-selected-rfc">Analy
sis of 20 Selected RFCs</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8411">RFC 8411</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8456">RFC 8456</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8446">RFC 8446</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8355">RFC 8355</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.5">
<t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent=
"3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8441">RFC 8441</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.6">
<t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent=
"3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8324">RFC 8324</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.7">
<t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent=
"3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8377">RFC 8377</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.8">
<t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent=
"3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8498">RFC 8498</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.9">
<t indent="0" pn="section-toc.1-1.3.2.9.1"><xref derivedContent=
"3.9" format="counter" sectionFormat="of" target="section-3.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rfc-8479">RFC 8479</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.10">
<t indent="0" pn="section-toc.1-1.3.2.10.1"><xref derivedContent
="3.10" format="counter" sectionFormat="of" target="section-3.10"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8453">RFC 8453</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.11">
<t indent="0" pn="section-toc.1-1.3.2.11.1"><xref derivedContent
="3.11" format="counter" sectionFormat="of" target="section-3.11"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8429">RFC 8429</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.12">
<t indent="0" pn="section-toc.1-1.3.2.12.1"><xref derivedContent
="3.12" format="counter" sectionFormat="of" target="section-3.12"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8312">RFC 8312</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.13">
<t indent="0" pn="section-toc.1-1.3.2.13.1"><xref derivedContent
="3.13" format="counter" sectionFormat="of" target="section-3.13"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8492">RFC 8492</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.14">
<t indent="0" pn="section-toc.1-1.3.2.14.1"><xref derivedContent
="3.14" format="counter" sectionFormat="of" target="section-3.14"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8378">RFC 8378</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.15">
<t indent="0" pn="section-toc.1-1.3.2.15.1"><xref derivedContent
="3.15" format="counter" sectionFormat="of" target="section-3.15"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8361">RFC 8361</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.16">
<t indent="0" pn="section-toc.1-1.3.2.16.1"><xref derivedContent
="3.16" format="counter" sectionFormat="of" target="section-3.16"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8472">RFC 8472</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.17">
<t indent="0" pn="section-toc.1-1.3.2.17.1"><xref derivedContent
="3.17" format="counter" sectionFormat="of" target="section-3.17"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8471">RFC 8471</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.18">
<t indent="0" pn="section-toc.1-1.3.2.18.1"><xref derivedContent
="3.18" format="counter" sectionFormat="of" target="section-3.18"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8466">RFC 8466</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.19">
<t indent="0" pn="section-toc.1-1.3.2.19.1"><xref derivedContent
="3.19" format="counter" sectionFormat="of" target="section-3.19"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8362">RFC 8362</
xref></t>
</li>
<li pn="section-toc.1-1.3.2.20">
<t indent="0" pn="section-toc.1-1.3.2.20.1"><xref derivedContent
="3.20" format="counter" sectionFormat="of" target="section-3.20"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-rfc-8468">RFC 8468</
xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-analysis-of-process-and-del">Analy
sis of Process and Delays</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-delays-from-first-draf
t-to-">Delays from First Draft to RFC</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-working-group-processi
ng-ti">Working Group Processing Time</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-preparation-and-public
ation">Preparation and Publication Delays</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-copy-editing">Copy Edi
ting</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
"4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-independent-stream">In
dependent Stream</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-citation-counts">Citation Counts</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-citation-numbers">Cita
tion Numbers</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-comparison-to-1998-and
-2008">Comparison to 1998 and 2008</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-citations-versus-deplo
yment">Citations versus Deployments</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-citations-versus-web-r
efere">Citations versus Web References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-observations-and-next-steps">Obser
vations and Next Steps</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-informative-references">Informativ
e References</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<section anchor="introduction" title="Introduction"> lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t>As stated on the organization's web site, "The IETF is a large open internati <t indent="0" pn="section-1-1">As stated on the organization's web site, "
onal The IETF is a large open international
community of network designers, operators, vendors, and researchers concerned wi th community of network designers, operators, vendors, and researchers concerned wi th
the evolution of the Internet architecture and the smooth operation of the Inter net." the evolution of the Internet architecture and the smooth operation of the Inter net."
The specifications produced by the IETF are published in the RFC series, along w The specifications
ith produced by the IETF are published in the RFC series, along with
independent submissions, research papers and IAB documents. documents from the IAB, IRTF, and Independent streams (as per RFC 8729).
In this memo, the author attempts to understand the delays involved In this memo, the author attempts to understand the delays involved
in publishing an idea in the IETF or through the Independent Stream, from the fi rst in publishing an idea in the IETF or through the Independent Stream, from the fi rst
individual draft to the publication of the RFC. This is individual draft to the publication of the RFC. This is
an individual effort, and the author's conclusions presented here are personal. an individual effort, and the author's conclusions presented here are personal.
There was no attempt to seek IETF consensus.</t> There was no attempt to seek IETF consensus.</t>
<t indent="0" pn="section-1-2">The IETF keeps records of documents and pro
<t>The IETF keeps records of documents and process actions cess actions
in the IETF datatracker <xref target="TRKR"/>. in the IETF Datatracker <xref target="TRKR" format="default" sectionFormat="of"
The IETF datatracker provides information about RFCs and drafts, from which we c derivedContent="TRKR"/>.
an The IETF Datatracker provides information about RFCs and drafts, from which we c
an
infer statistics about the production system. We can measure how infer statistics about the production system. We can measure how
long it takes to drive a proposition from initial draft to final publication, long it takes to drive a proposition from initial draft to final publication,
and how these delays can be split between Working Group discussions, IETF review and how these delays can be split between working group discussions, IETF review
s, s,
IESG assessment, RFC Editor delays and final reviews by the authors &#8211; or, IESG assessment, RFC Editor delays and final reviews by the authors -- or, for
for Independent Stream RFCs, draft production, reviews by the Independent Submission
Independent Stream RFCs, draft production, reviews by the Independent Stream Edi s Editor,
tor,
conflict reviews, RFC Editor delays and final reviews. conflict reviews, RFC Editor delays and final reviews.
Tracker data is available for all RFCs, not just IETF stream RFCs.</t> Tracker data is available for all RFCs, not just IETF Stream RFCs.</t>
<t indent="0" pn="section-1-3">Just measuring production delays may be mis
<t>Just measuring production delays may be misleading. If the IETF or the editor leading. If the IETF or the other streams simply rubber-stamped
s of
the other series simply rubber-stamped
draft proposals and published them, the delays would be short but the quality an d draft proposals and published them, the delays would be short but the quality an d
impact might suffer. We hope that most of the RFC that are published are useful, impact might suffer. We hope that most of the RFCs that are published are useful ,
but we need a way to measure that usefulness. We try to do that by measuring the but we need a way to measure that usefulness. We try to do that by measuring the
number of references of the published RFCs in Semantic Scholar <xref target="SSC H"/>, and number of references of the published RFCs in Semantic Scholar <xref target="SSC H" format="default" sectionFormat="of" derivedContent="SSCH"/>, and
also by asking the authors of each RFC in the sample also by asking the authors of each RFC in the sample
whether the protocols and technologies defined in the RFCs were implemented and used on whether the protocols and technologies defined in the RFCs were implemented and used on
the Internet. The citations measured by the Semantic Scholar include citations i n the Internet. The citations measured by the Semantic Scholar include citations i n
other RFCs and in Internet drafts. We also measure the number of other RFCs and in Internet-Drafts. We also measure the number of
references on the web, which provides some results but would be hard to automate .</t> references on the web, which provides some results but would be hard to automate .</t>
<t indent="0" pn="section-1-4">In order to limit the resources required fo
<t>In order to limit the resource required for this study, we selected at random r this study, we selected at random 20
20 RFCs published in 2018, as explained in <xref target="sample-selection" format="
RFCs published in 2018, as explained in <xref target="sample-selection"/>. The s default" sectionFormat="of" derivedContent="Section 2.2"/>. The statistical
tatistical sampling picked both IETF Stream and Independent Stream documents.
sampling picked both IETF stream and Independent Stream documents.
For comparison purposes, For comparison purposes,
we also selected at random 20 RFC published in 1998 and 20 published in 2008. we also selected at random 20 RFCs published in 1998 and 20 published in 2008.
Limiting the sample to 20 out of 209 RFCs published in 2018 allows for in depth Limiting the sample to 20 out of 209 RFCs published in 2018 allows for in-depth
analysis of each RFC, but readers should be reminded that the this is a small sa mple. analysis of each RFC, but readers should be reminded that the this is a small sa mple.
The sample is too small to apply general statistical techniques and The sample is too small to apply general statistical techniques and
quantify specific ratios, and discussions of correlation techniques would be ina ppropriate. quantify specific ratios, and discussions of correlation techniques would be ina ppropriate.
Instead, the purpose is to identify trends, spot issues and document future Instead, the purpose is to identify trends, spot issues, and document future
work.</t> work.</t>
<t indent="0" pn="section-1-5">The information gathered for every RFC in t
<t>The information gathered for every RFC in the sample is presented in he sample is presented in
<xref target="sample-rfc-analysis"/>. In <xref target="process-analysis"/> we an <xref target="sample-rfc-analysis" format="default" sectionFormat="of" derivedCo
alyze the production process ntent="Section 3"/>. In <xref target="process-analysis" format="default" section
Format="of" derivedContent="Section 4"/>, we analyze the production process
and the sources of delays, comparing the 2018 sample to the selected samples for 1998 and the sources of delays, comparing the 2018 sample to the selected samples for 1998
and 2018. In <xref target="citation-numbers"/> we present citation counts for th e RFCs in the samples, and 2018. In <xref target="citation-numbers" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, we present citation counts for the RFCs in the samples,
and analyze whether citation counts could be used to evaluate the quality of RFC s.</t> and analyze whether citation counts could be used to evaluate the quality of RFC s.</t>
<t indent="0" pn="section-1-6">The measurement of delays could be automate
<t>The measurement of delays could be automated by processing dates and d by processing dates and
events recorded in the datatracker. The measurement of published events recorded in the Datatracker. The measurement of published
RFCs could be complemented by statistics on abandoned drafts, which RFCs could be complemented by statistics on abandoned drafts, which
would measure the efficiency of the IETF triaging process. More instrumentation would would measure the efficiency of the IETF triaging process. More instrumentation would
help understanding how large delays happen during Working Group processes. help understanding how large delays happen during working group processes.
These potential next steps are developed in <xref target="conclusion"/>.</t> These potential next steps are developed in <xref target="conclusion" format="de
fault" sectionFormat="of" derivedContent="Section 6"/>.</t>
</section> </section>
<section anchor="methodology" title="Methodology"> <section anchor="methodology" numbered="true" toc="include" removeInRFC="fal
se" pn="section-2">
<t>The study reported here started with a simple idea: take a sample of RFCs, an <name slugifiedName="name-methodology">Methodology</name>
d <t indent="0" pn="section-2-1">The study reported here started with a simp
le idea: take a sample of RFCs, and
perform an in-depth analysis of the path from the first presentation of the idea perform an in-depth analysis of the path from the first presentation of the idea
to its publication, while also trying to access the success of the resulting to its publication, while also trying to access the success of the resulting
specification. This requires defining the key milestones that we want to track, specification. This requires defining the key milestones that we want to track,
and drawing a random sample using an unbiased process.</t> and drawing a random sample using an unbiased process.</t>
<section anchor="milestones" numbered="true" toc="include" removeInRFC="fa
<section anchor="milestones" title="Defining the Important Milestones"> lse" pn="section-2.1">
<name slugifiedName="name-defining-the-important-mile">Defining the Impo
<t>The IETF datatracker records a list of events for each document processed by rtant Milestones</name>
IETF <t indent="0" pn="section-2.1-1">The IETF Datatracker records a list of
Working Groups. This has a high granularity, and also a high variability. Most d events for each document processed by IETF
ocuments working groups. This has a high granularity, and also a high variability. Most d
start life as an individual draft, are adopted by a Working Group, undergo a ocuments
Working Group last call, are submitted to the IESG, undergo an IETF last call start life as an individual draft, are adopted by a working group, undergo a
Working Group Last Call, are submitted to the IESG, undergo an IETF Last Call
and an IESG review, get eventually approved by the IESG, and are processed and an IESG review, get eventually approved by the IESG, and are processed
for publication by the RFC Editor, but there are exceptions. Some documents for publication by the RFC Editor, but there are exceptions. Some documents
are first submitted to one Working Group and then moved to another. Some documen ts are first submitted to one working group and then moved to another. Some documen ts
are published through the Independent Stream, and are submitted to the are published through the Independent Stream, and are submitted to the
Independent Stream Editor instead of the IESG.</t> Independent Submissions Editor instead of the IESG.</t>
<t indent="0" pn="section-2.1-2">In order to simplify tabulation,
<t>In order to simplify tabulation, we break the period from the submission of the first
we break the delay from between the submission of the first draft to the publication of the RFC into three big components:</t>
draft and the publication of the RFC in three big components:</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
.1-3">
<t><list style="symbols"> <li pn="section-2.1-3.1">The working group processing time, from the f
<t>The Working Group processing time, from the first draft to the start of the irst draft to the start of the IETF
IETF last call;</li>
last call;</t> <li pn="section-2.1-3.2">The IETF processing time, which lasts from th
<t>The IETF processing time, which lasts from the beginning of the IETF last c e beginning of the IETF last call to
all to
the approval by the IESG, including the reviews by the approval by the IESG, including the reviews by
various directorates;</t> various directorates;</li>
<t>The RFC production, from approval by the IESG to publication, including <li pn="section-2.1-3.3">The RFC production, from approval by the IESG
the AUTH-48 reviews.</t> to publication, including
</list></t> the AUTH48 reviews.</li>
</ul>
<t>For submissions to the Independent Stream, we don't have a Working Group. <t indent="0" pn="section-2.1-4">For submissions to the Independent Stre
am, we don't have a working group.
We consider instead the progression of the individual draft until the We consider instead the progression of the individual draft until the
adoption by the ISE as the equivalent of the "Working Group" period, adoption by the Independent Submissions Editor (ISE) as the equivalent of the "W orking Group" period,
and the delay from adoption by the ISE until submission to the RFC Editor and the delay from adoption by the ISE until submission to the RFC Editor
as the equivalent of the IETF delay.</t> as the equivalent of the IETF processing time.</t>
<t indent="0" pn="section-2.1-5">We measure the starting point of the pr
<t>We measure the staring point of the process using the date of submission ocess using the date of submission
of the first draft listed on that RFC page in the IETF datatracker. In most of the first draft listed on that RFC page in the IETF Datatracker. In most
case, this first draft is an individual draft that then resubmitted as a cases, this first draft is an individual draft that then resubmitted as a
Working Group draft, or maybe resubmitted with a new name as the draft was working group draft, or maybe resubmitted with a new name as the draft was
searching for a home in an IETF Working Group, or before deciding for searching for a home in an IETF working group, or before deciding for
submission on the Independent Stream.</t> submission on the Independent Stream.</t>
<t indent="0" pn="section-2.1-6">The IETF Datatracker entries for RFCs a nd drafts do not <em>always</em> list working group events like Working Group La st Call.
<t>The IETF datatracker entries for RFCs and drafts do not list Working Group The only intermediate event that we list
events like Working Group Last Call. The only intermediate event that we list between the first draft and the submission to the IESG is the working group
between the first draft and the submission to the IESG is the Working Group adoption, for which we use the date of submission of version 00 of the
Adoption. For that, we use the date of submission of the version 00 of the draft eventually published as RFC. We also use that date (of submission of versi
draft eventually published as RFC. We use the same definition for drafts on 00) for drafts
submitted to the Independent Stream.</t> submitted to the Independent Stream.</t>
</section>
</section> <section anchor="sample-selection" numbered="true" toc="include" removeInR
<section anchor="sample-selection" title="Selecting a Random Sample of RFCs"> FC="false" pn="section-2.2">
<name slugifiedName="name-selecting-a-random-sample-o">Selecting a Rando
<t>Basic production mechanisms could be evaluated by processing data from m Sample of RFCs</name>
the IETF datatracker, but subjective data requires manual assessment of results, <t indent="0" pn="section-2.2-1">Basic production mechanisms could be ev
which can be time consuming. Since our resources are limited, we will only aluated by processing data from
the IETF Datatracker, but subjective data requires manual assessment of results,
which can be time-consuming. Since our resources are limited, we will only
perform this analysis for a small sample of RFCs, selected at random perform this analysis for a small sample of RFCs, selected at random
from the list of RFCs approved in 2018. Specifically, we will pick from the list of RFCs approved in 2018. Specifically, we will pick
20 RFC numbers at random between:</t> 20 RFC numbers at random between:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
<t><list style="symbols"> .2-2">
<t>RFC 8307, published in January 2018, and</t> <li pn="section-2.2-2.1">RFC 8307, published in January 2018, and</li>
<t>RFC 8511, published December 2018.</t> <li pn="section-2.2-2.2">RFC 8511, published December 2018.</li>
</list></t> </ul>
<t indent="0" pn="section-2.2-3">
<t>The list of 20 selected RFCs is: RFC 8411, RFC 8456, RFC 8446, RFC 8355, RFC The list of 20 selected RFCs is: RFC 8411, RFC 8456, RFC 8446, RFC
8441, RFC 8324, 8355, RFC 8441, RFC 8324, RFC 8377, RFC 8498, RFC 8479, RFC 8453, RFC
RFC 8377, RFC 8498, RFC 8479, RFC 8453, RFC 8429, RFC 8312, RFC 8492 , RFC 8378, 8429, RFC 8312, RFC 8492 , RFC 8378, RFC 8361, RFC 8472, RFC 8471,
RFC 8361, RFC 8466, RFC 8362, and RFC 8468.</t>
RFC 8472, RFC 8471, RFC 8466, RFC 8362, and RFC 8468.</t> <t indent="0" pn="section-2.2-4">When evaluating delays and impact, we w
ill compare the year 2018 to 2008 and
<t>When evaluating delays and impact, we will compare the year 2018 to 2008 and
1998, 10 and 20 years ago. To drive this comparison, we pick 20 RFCs at random 1998, 10 and 20 years ago. To drive this comparison, we pick 20 RFCs at random
among those published in 2008, and another 20 among those published in 1998.</t> among those published in 2008, and another 20 among those published in 1998.</t>
<t indent="0" pn="section-2.2-5">The list of the 20 randomly selected RF
<t>The list of the 20 randomly selected RFCs from 2008 is: RFC 5227, RFC 5174, R Cs from 2008 is: RFC 5227, RFC 5174, RFC 5172, RFC 5354,
FC 5172, RFC 5354,
RFC 5195, RFC 5236, RFC 5348, RFC 5281, RFC 5186, RFC 5326, RFC 5277, RFC 5373, RFC 5404, RFC 5195, RFC 5236, RFC 5348, RFC 5281, RFC 5186, RFC 5326, RFC 5277, RFC 5373, RFC 5404,
RFC 5329, RFC 5283, RFC 5358, RFC 5142, RFC 5271, RFC 5349, and RFC 5301.</t> RFC 5329, RFC 5283, RFC 5358, RFC 5142, RFC 5271, RFC 5349, and RFC 5301.</t>
<t indent="0" pn="section-2.2-6">The list of the 20 randomly selected RF
<t>The list of the 20 randomly selected RFCs from 2008 is: RFC 2431, RFC 2381, R Cs from 1998 is: RFC 2431, RFC 2381, RFC 2387, RFC 2348,
FC 2387, RFC 2348,
RFC 2391, RFC 2267, RFC 2312, RFC 2448, RFC 2374, RFC 2398, RFC 2283, RFC 2382, RFC 2289, RFC 2391, RFC 2267, RFC 2312, RFC 2448, RFC 2374, RFC 2398, RFC 2283, RFC 2382, RFC 2289,
RFC 2282, RFC 2404, RFC 2449, RFC 2317, RFC 2394, RFC 2297, and RFC 2323.</t> RFC 2282, RFC 2404, RFC 2449, RFC 2317, RFC 2394, RFC 2297, and RFC 2323.</t>
</section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-2.3
</section> ">
<section anchor="sample-rfc-analysis" title="Analysis of 20 Selected RFCs"> <name slugifiedName="name-conventions-used-in-this-do">Conventions Used
in This Document</name>
<t>We review each of the RFCs listed in <xref target="sample-selection"/> for th <t indent="0" pn="section-2.3-1">The following abbreviations are used in
e year 2018, trying the tables:</t>
both to answer the known questions and to gather insight for further analyzes. <dl spacing="compact" indent="6" newline="false" pn="section-2.3-2">
<dt pn="section-2.3-2.1">BCP</dt>
<dd pn="section-2.3-2.2">Best Current Practice</dd>
<dt pn="section-2.3-2.3">Exp</dt>
<dd pn="section-2.3-2.4">Experimental</dd>
<dt pn="section-2.3-2.5">Info</dt>
<dd pn="section-2.3-2.6">Informational</dd>
<dt pn="section-2.3-2.7">PS</dt>
<dd pn="section-2.3-2.8">Proposed Standard</dd>
<dt pn="section-2.3-2.9">DS</dt>
<dd pn="section-2.3-2.10">Draft Standard [This maturity level was reti
red by RFC 6410.]</dd>
</dl>
<t indent="0" pn="section-2.3-3">In addition, Status is as defined in RF
C 2026, and
Stream is as defined in RFC 8729.</t>
</section>
</section>
<section anchor="sample-rfc-analysis" numbered="true" toc="include" removeIn
RFC="false" pn="section-3">
<name slugifiedName="name-analysis-of-20-selected-rfc">Analysis of 20 Sele
cted RFCs</name>
<t indent="0" pn="section-3-1">We review each of the RFCs listed in <xref
target="sample-selection" format="default" sectionFormat="of" derivedContent="Se
ction 2.2"/> for the year 2018, trying
both to answer the known questions and to gather insight for further analyses.
In many cases, the analysis of the data is complemented by direct feedback In many cases, the analysis of the data is complemented by direct feedback
from the RFC authors.</t> from the RFC authors.</t>
<section anchor="section" numbered="true" toc="include" removeInRFC="false
<section anchor="section" title="8411"> " pn="section-3.1">
<t>IANA Registration for the Cryptographic Algorithm Object Identifier Range <xr <name slugifiedName="name-rfc-8411">RFC 8411</name>
ef target="RFC8411"/>:</t> <t indent="0" pn="section-3.1-1">"IANA Registration for the Cryptographi
c Algorithm Object Identifier Range" <xref target="RFC8411" format="default" sec
<figure><artwork><![CDATA[ tionFormat="of" derivedContent="RFC8411"/>:</t>
Informational, 5 pages <dl indent="20" spacing="compact" newline="false" pn="section-3.1-2">
4 drafts (personal), first 2017-05-08. <dt pn="section-3.1-2.1">Status (Length):</dt>
Last call announced 2017-10-09 <dd pn="section-3.1-2.2">Informational (5 pages)</dd>
IESG evaluation starts 2017-12-28 <dt pn="section-3.1-2.3">Overview:</dt>
Approved 2018-02-26, draft 03 <dd pn="section-3.1-2.4">4 individual drafts</dd>
AUTH-48 2018-04-20 <dt pn="section-3.1-2.5">First draft:</dt>
AUTH-48 complete 2018-07-17 <dd pn="section-3.1-2.6">2017-05-08</dd>
Published 2018-08-06 <dt pn="section-3.1-2.7">Last Call start:</dt>
IANA action: create table <dd pn="section-3.1-2.8">2017-10-09</dd>
]]></artwork></figure> <dt pn="section-3.1-2.9">IESG eval. start:</dt>
<dd pn="section-3.1-2.10">2017-12-28</dd>
<t>This RFC was published from the individual draft, which was not resubmitted <dt pn="section-3.1-2.11">IESG approved:</dt>
as a Working Group draft.</t> <dd pn="section-3.1-2.12">2018-02-26 (draft 03)</dd>
<dt pn="section-3.1-2.13">AUTH48 start:</dt>
<t>The draft underwent minor copy edit before publication.</t> <dd pn="section-3.1-2.14">2018-04-20</dd>
<dt pn="section-3.1-2.15">AUTH48 complete:</dt>
<t>Some but not all of the long delay in AUTH-48 is due to clustering with <xref <dd pn="section-3.1-2.16">2018-07-17</dd>
target="RFC8410"/>. <dt pn="section-3.1-2.17">Published:</dt>
MISSREF was cleared on 2018-05-09 and the document re-entered AUTH-48 at <dd pn="section-3.1-2.18">2018-08-06</dd>
once. AUTH-48 lasted over two months after that.</t> <dt pn="section-3.1-2.19">IANA action:</dt>
<dd pn="section-3.1-2.20">create table</dd>
<t>The time after AUTH-48 and before publication (3 weeks) partly </dl>
overlaps with travel for IETF-102 and is partly due to coordinating the <t indent="0" pn="section-3.1-3">This RFC was published from the individ
ual draft, which was not resubmitted
as a working group draft.</t>
<t indent="0" pn="section-3.1-4">The draft underwent minor copy editing
before publication.</t>
<t indent="0" pn="section-3.1-5">Some but not all of the long delay in A
UTH48 is due to clustering with <xref target="RFC8410" format="default" sectionF
ormat="of" derivedContent="RFC8410"/>.
MISSREF state concluded on 2018-05-09 and the document re-entered AUTH48 at
once. AUTH48 lasted over two months after that. (For state definitions, see
<eref brackets="angle" target="https://www.rfc-editor.org/about/queue/#state_def
"/>.)</t>
<t indent="0" pn="section-3.1-6">The time after AUTH48 and before public
ation (3 weeks) partly
overlaps with travel for IETF 102 and is partly due to coordinating the
cluster.</t> cluster.</t>
</section>
</section> <section anchor="sec-1" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-1" title="8456"> pn="section-3.2">
<t>Benchmarking Methodology for Software-Defined Networking (SDN) <name slugifiedName="name-rfc-8456">RFC 8456</name>
Controller Performance <xref target="RFC8456"/>:</t> <t indent="0" pn="section-3.2-1">"Benchmarking Methodology for Software-
Defined Networking (SDN)
<figure><artwork><![CDATA[ Controller Performance" <xref target="RFC8456" format="default" sectionFormat="o
Informational, 64 pages f" derivedContent="RFC8456"/>:</t>
2 personal drafts, 9 WG drafts, first 2015-03-23 <dl indent="20" spacing="compact" newline="false" pn="section-3.2-2">
WG adoption on 2015-10-18 <dt pn="section-3.2-2.1">Status (Length):</dt>
Last call announced 2018-01-19 <dd pn="section-3.2-2.2">Informational (64 pages)</dd>
IESG evaluation starts 2018-02-27 <dt pn="section-3.2-2.3">Overview:</dt>
IESG approved 2018-05-25 <dd pn="section-3.2-2.4">2 individual drafts; 9 WG drafts</dd>
AUTH-48 2018-08-31 <dt pn="section-3.2-2.5">First draft:</dt>
AUTH-48 complete 2018-10-16 <dd pn="section-3.2-2.6">2015-03-23</dd>
Published 2018-10-30 <dt pn="section-3.2-2.7">WG adoption:</dt>
]]></artwork></figure> <dd pn="section-3.2-2.8">2015-10-18</dd>
<dt pn="section-3.2-2.9">Last Call start:</dt>
<t>The draft underwent very extensive copy editing, covering use of articles, tu <dd pn="section-3.2-2.10">2018-01-19</dd>
rn of phrases, choice <dt pn="section-3.2-2.11">IESG eval. start:</dt>
of vocabulary. The changes are enough to cause pagination differences. The "diff <dd pn="section-3.2-2.12">2018-02-27</dd>
" tool marks pretty <dt pn="section-3.2-2.13">IESG approved:</dt>
<dd pn="section-3.2-2.14">2018-05-25</dd>
<dt pn="section-3.2-2.15">AUTH48 start:</dt>
<dd pn="section-3.2-2.16">2018-08-31</dd>
<dt pn="section-3.2-2.17">AUTH48 complete:</dt>
<dd pn="section-3.2-2.18">2018-10-16</dd>
<dt pn="section-3.2-2.19">Published:</dt>
<dd pn="section-3.2-2.20">2018-10-30</dd>
</dl>
<t indent="0" pn="section-3.2-3">
The draft underwent extensive copy editing, covering use of
articles, syntax, and word choice. The changes are enough to cause pagination
differences. The "diff" tool marks pretty
much every page as changed. Some diagrams see change in protocol elements like m essage names.</t> much every page as changed. Some diagrams see change in protocol elements like m essage names.</t>
<t indent="0" pn="section-3.2-4">According to the author, the experience
<t>According to the author, the experience of producing this draft mirrors a typ of producing this document mirrors a typical one in the
ical one in the
Benchmarking Methodologies Working Group (BMWG). There were multiple authors in multiple time Benchmarking Methodologies Working Group (BMWG). There were multiple authors in multiple time
zones, which slowed down the AUTH-48 process somewhat, although the AUTH-48 dela y of 46 days is only zones, which slowed down the AUTH48 process somewhat, although the AUTH48 delay of 46 days is only
a bit longer than the average draft.</t> a bit longer than the average draft.</t>
<t indent="0" pn="section-3.2-5">The RFC was part of cluster with <xref
<t>The RFC was part of cluster with <xref target="RFC8455"/>.</t> target="RFC8455" format="default" sectionFormat="of" derivedContent="RFC8455"/>.
</t>
<t>BMWG publishes informational RFCs centered around benchmarking, <t indent="0" pn="section-3.2-6">BMWG publishes Informational RFCs cente
red around benchmarking,
and the methodologies in RFC 8456 have been implemented in benchmarking products .</t> and the methodologies in RFC 8456 have been implemented in benchmarking products .</t>
</section>
</section> <section anchor="sec-2" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-2" title="8446"> pn="section-3.3">
<t>The Transport Layer Security (TLS) Protocol Version 1.3 <xref target="RFC8446 <name slugifiedName="name-rfc-8446">RFC 8446</name>
"/>, as the title <t indent="0" pn="section-3.3-1">"The Transport Layer Security (TLS) Pro
indicates, defines the new version of the TLS protocol. From the IETF datatracke tocol Version 1.3" <xref target="RFC8446" format="default" sectionFormat="of" de
r, we extract rivedContent="RFC8446"/>, as the title
indicates, defines the new version of the TLS protocol. From the IETF Datatracke
r, we extract
the following:</t> the following:</t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.3-2">
<figure><artwork><![CDATA[ <dt pn="section-3.3-2.1">Status (Length):</dt>
Proposed standard <dd pn="section-3.3-2.2">Proposed Standard (160 pages)</dd>
160 pages <dt pn="section-3.3-2.3">Overview:</dt>
29 WG drafts first 2014-04-17. <dd pn="section-3.3-2.4">29 WG drafts</dd>
Last call announced 2018-02-15 <dt pn="section-3.3-2.5">First draft:</dt>
IESG evaluation starts 2018-03-02 <dd pn="section-3.3-2.6">2014-04-17</dd>
Approved 2018-03-21, draft 28 <dt pn="section-3.3-2.7">Last Call start:</dt>
AUTH-48 2018-06-14 <dd pn="section-3.3-2.8">2018-02-15</dd>
AUTH-48 complete 2018-08-10 <dt pn="section-3.3-2.9">IESG eval. start:</dt>
Published 2018-08-10 <dd pn="section-3.3-2.10">2018-03-02</dd>
]]></artwork></figure> <dt pn="section-3.3-2.11">IESG approved:</dt>
<t>This draft started as a WG effort.</t> <dd pn="section-3.3-2.12">2018-03-21 (draft 28)</dd>
<dt pn="section-3.3-2.13">AUTH48 start:</dt>
<t>The RFC was a major effort in the IETF. Working Group members developed and t <dd pn="section-3.3-2.14">2018-06-14</dd>
ested <dt pn="section-3.3-2.15">AUTH48 complete:</dt>
<dd pn="section-3.3-2.16">2018-08-10</dd>
<dt pn="section-3.3-2.17">Published:</dt>
<dd pn="section-3.3-2.18">2018-08-10</dd>
</dl>
<t indent="0" pn="section-3.3-3">This draft started as a WG effort.</t>
<t indent="0" pn="section-3.3-4">The RFC was a major effort in the IETF.
Working group participants developed and tested
several implementations. Researchers analyzed the specifications and performed several implementations. Researchers analyzed the specifications and performed
formal verifications. Deployment tests outlined issues that caused extra work formal verifications. Deployment tests outlined issues that caused extra work
when the specification was almost ready. These complexity largely explains the when the specification was almost ready. This complexity largely explains the
time spent in the Working Group.</t> time spent in the working group.</t>
<t indent="0" pn="section-3.3-5">Comparing the final draft to the publis
<t>Comparing the final draft to the published version, we find relatively light hed version, we find relatively light copy
copy
editing. It includes explaining acronyms on first use, clarifying some definitio ns editing. It includes explaining acronyms on first use, clarifying some definitio ns
standardizing punctiation and capitalization, and spelling out some numbers in t ext. standardizing punctuation and capitalization, and spelling out some numbers in t ext.
This generally fall in the category of "style", although some of the clarificati ons This generally fall in the category of "style", although some of the clarificati ons
go into message definitions. However, that simple analysis does not explain why go into message definitions. However, that simple analysis does not explain why
the AUTH-48 phase took almost two months.</t> the AUTH48 phase took almost two months.</t>
<t indent="0" pn="section-3.3-6">This document's AUTH48 process was part
<t>This document's AUTH-48 process was part of the "Github experiment", which tr of the "GitHub experiment", which tried to
ied to use GitHub pull requests to track the AUTH48 changes and review comments. The
use github pull requests to track the AUTH-48 changes and review comments. The RFC Production Center (RPC) staff had to learn using GitHub for that process, an
RPC staff had to learn using Github for that process, and this required more wor d this required more work
k than the usual RFC. The author and AD thoroughly reviewed each proposed
than the usual RFC. Author and AD thoroughly reviewed each proposed
edit, accepting some and rejecting some. The concern there was that edit, accepting some and rejecting some. The concern there was that
any change in a complex specification might affect a protocol that was extensive ly any change in a complex specification might affect a protocol that was extensive ly
reviewed in the Working Group, but of course these reviews added time to the reviewed in the working group, but of course these reviews added time to the
AUTH-48 delays.</t> AUTH48 delays.</t>
<t indent="0" pn="section-3.3-7">There are 21 implementations listed
<t>There are 21 implementations listed in the Wiki of the TLS 1.3 project <xref target="TLS13IMP" format="default" sect
in the Wiki of the TLS 1.3 project <xref target="TLS13IMP"/>. It has been deploy ionFormat="of" derivedContent="TLS13IMP"/>. It has been deployed on major browse
ed on major browsers, and rs, and
is already used in a large fraction of TLS connections.</t> is already used in a large fraction of TLS connections.</t>
</section>
</section> <section anchor="sec-3" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-3" title="8355"> pn="section-3.4">
<t>Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks <name slugifiedName="name-rfc-8355">RFC 8355</name>
<xref target="RFC8355"/> is an informational RFC. <t indent="0" pn="section-3.4-1">"Resiliency Use Cases in Source Packet
It originated from a use case informational draft that was mostly used for the B Routing in Networking (SPRING) Networks" <xref target="RFC8355" format="default"
OF creating the WG, and then to sectionFormat="of" derivedContent="RFC8355"/> is an Informational RFC.
drive initial work/evolutions from the WG.</t> It originated from an informational use-case draft; it was mostly used for the B
OF creating the WG, and then to
<figure><artwork><![CDATA[ drive initial work and evolutions from the WG.</t>
Informational, 13 pages. <dl indent="20" spacing="compact" newline="false" pn="section-3.4-2">
2 personal drafts (personal), first 2014-01-31. 13 WG drafts. <dt pn="section-3.4-2.1">Status (Length):</dt>
WG adoption on 2014-05-13 <dd pn="section-3.4-2.2">Informational (13 pages)</dd>
Last call announced 2017-04-20 <dt pn="section-3.4-2.3">Overview:</dt>
IESG evaluation starts 2017-05-04, draft 09 <dd pn="section-3.4-2.4">2 individual drafts; 13 WG drafts</dd>
Approved 2017-12-19, draft 12 <dt pn="section-3.4-2.5">First draft:</dt>
AUTH-48 2018-03-12 <dd pn="section-3.4-2.6">2014-01-31</dd>
AUTH-48 complete 2018-03-27 <dt pn="section-3.4-2.7">WG adoption:</dt>
Published 2018-03-28 <dd pn="section-3.4-2.8">2014-05-13</dd>
]]></artwork></figure> <dt pn="section-3.4-2.9">Last Call start:</dt>
<dd pn="section-3.4-2.10">2017-04-20</dd>
<t>Minor set of copy edits, mostly for style.</t> <dt pn="section-3.4-2.11">IESG eval. start:</dt>
<dd pn="section-3.4-2.12">2017-05-04 (draft 09)</dd>
<t>No implementation of the RFC itself, but the technology behind it such as <dt pn="section-3.4-2.13">IESG approved:</dt>
Segment Routing (architecture RFC 8402, TI-LFA draft-ietf-rtgwg-segment-routing- <dd pn="section-3.4-2.14">2017-12-19 (draft 12)</dd>
ti-lfa) is widely implemented <dt pn="section-3.4-2.15">AUTH48 start:</dt>
<dd pn="section-3.4-2.16">2018-03-12</dd>
<dt pn="section-3.4-2.17">AUTH48 complete:</dt>
<dd pn="section-3.4-2.18">2018-03-27</dd>
<dt pn="section-3.4-2.19">Published:</dt>
<dd pn="section-3.4-2.20">2018-03-28</dd>
</dl>
<t indent="0" pn="section-3.4-3">Minor set of copy edits, mostly for sty
le.</t>
<t indent="0" pn="section-3.4-4">No implementation of the RFC itself, bu
t the technology behind it (such as
Segment Routing Architecture <xref target="RFC8402" format="default" sectionForm
at="of" derivedContent="RFC8402"/> and TI-LFA <xref target="I-D.ietf-rtgwg-segme
nt-routing-ti-lfa" format="default" sectionFormat="of" derivedContent="TI-LFA"/>
) is widely implemented
and deployment is ongoing.</t> and deployment is ongoing.</t>
<t indent="0" pn="section-3.4-5">According to participants in the discus
<t>According to participants in the discussion, the process of adoption of the s sion, the process of adoption of the source packet routing
ource packet routing standards was very contentious. The establishment of consensus at both the worki
standards was very contentious. The establishment of consensus at both the Worki ng group level
ng Group level and the IETF level was difficult and time-consuming.</t>
and the IETF level was difficult and time consuming.</t> </section>
<section anchor="sec-4" numbered="true" toc="include" removeInRFC="false"
</section> pn="section-3.5">
<section anchor="section-4" title="8441"> <name slugifiedName="name-rfc-8441">RFC 8441</name>
<t>Bootstrapping WebSockets with HTTP/2 <xref target="RFC8441"/></t> <t indent="0" pn="section-3.5-1">"Bootstrapping WebSockets with HTTP/2"
<xref target="RFC8441" format="default" sectionFormat="of" derivedContent="RFC84
<figure><artwork><![CDATA[ 41"/></t>
Proposed standard, 8 pages. Updates RFC 6455. <dl indent="20" spacing="compact" newline="false" pn="section-3.5-2">
3 personal drafts (personal), first 2017-10-15. 8 WG drafts. <dt pn="section-3.5-2.1">Status (Length):</dt>
WG adoption on 2017-12-19 <dd pn="section-3.5-2.2">Proposed Standard (8 pages)</dd>
Last call announced 2018-05-07, draft 05 <dt pn="section-3.5-2.3">Overview:</dt>
IESG evaluation starts 2018-05-29, draft 06 <dd pn="section-3.5-2.4">3 individual drafts; 8 WG drafts; Updates RFC
Approved 2018-06-07, draft 07 6455</dd>
AUTH-48 2018-08-13 <dt pn="section-3.5-2.5">First draft:</dt>
AUTH-48 complete 2018-09-15 <dd pn="section-3.5-2.6">2017-10-15</dd>
Published 2018-09-21 <dt pn="section-3.5-2.7">WG adoption:</dt>
IANA Action: table entries <dd pn="section-3.5-2.8">2017-12-19</dd>
]]></artwork></figure> <dt pn="section-3.5-2.9">Last Call start:</dt>
<dd pn="section-3.5-2.10">2018-05-07 (draft 05)</dd>
<t>This RFC defines the support of WebSockets in HTTP/2, which is different <dt pn="section-3.5-2.11">IESG eval. start:</dt>
from the mechanism defined for HTTP/1.1 in <xref target="RFC6455"/>. The process <dd pn="section-3.5-2.12">2018-05-29 (draft 06)</dd>
was <dt pn="section-3.5-2.13">IESG approved:</dt>
<dd pn="section-3.5-2.14">2018-06-18 (draft 07)</dd>
<dt pn="section-3.5-2.15">AUTH48 start:</dt>
<dd pn="section-3.5-2.16">2018-08-13</dd>
<dt pn="section-3.5-2.17">AUTH48 complete:</dt>
<dd pn="section-3.5-2.18">2018-09-15</dd>
<dt pn="section-3.5-2.19">Published:</dt>
<dd pn="section-3.5-2.20">2018-09-18</dd>
<dt pn="section-3.5-2.21">IANA action:</dt>
<dd pn="section-3.5-2.22">table entries</dd>
</dl>
<t indent="0" pn="section-3.5-3">This RFC defines the support of WebSock
ets in HTTP/2, which is different
from the mechanism defined for HTTP/1.1 in <xref target="RFC6455" format="defaul
t" sectionFormat="of" derivedContent="RFC6455"/>. The process was
relatively straightforward, involving the usual type of discussions, some relatively straightforward, involving the usual type of discussions, some
on details and some on important points.</t> on details and some on important points.</t>
<t indent="0" pn="section-3.5-4">Comparing the final draft and published
<t>Comparing final draft and published RFC shows a minor set of copy edit, RFC shows a minor set of copy edits,
mostly for style. However, the author recalls a painful process. The RFC mostly for style. However, the author recalls a painful process. The RFC
includes many charts and graphs that were very difficult to format includes many charts and graphs that were very difficult to format
correctly in the author's production process that involve conversions correctly in the author's production process that involved conversions
from markdown to XML, and then from XML to text. The author had to from markdown to XML, and then from XML to text. The author had to
get substantial help from the RFC editor.</t> get substantial help from the RFC Editor.</t>
<t indent="0" pn="section-3.5-5">There are several implementations, incl
<t>There are several implementations, including Firefox and Chrome, uding Firefox and Chrome,
making RFC 8441 a very successful specification.</t> making RFC 8441 a very successful specification.</t>
</section>
</section> <section anchor="analyse-8324" numbered="true" toc="include" removeInRFC="
<section anchor="analyse-8324" title="8324"> false" pn="section-3.6">
<t>DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and <name slugifiedName="name-rfc-8324">RFC 8324</name>
Root Structure: <t indent="0" pn="section-3.6-1">"DNS Privacy, Authorization, Special Us
Time for Another Look? <xref target="RFC8324"/>. This is an opinion piece on DNS es, Encoding, Characters, Matching, and Root Structure:
development, Time for Another Look?" <xref target="RFC8324" format="default" sectionFormat="o
f" derivedContent="RFC8324"/>. This is an opinion piece on DNS development,
published on the Independent Stream.</t> published on the Independent Stream.</t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.6-2">
<figure><artwork><![CDATA[ <dt pn="section-3.6-2.1">Status (Length):</dt>
Informational, 29 pages. Independent Stream. <dd pn="section-3.6-2.2">Informational (29 pages)</dd>
5 personal drafts (personal), first 2017-06-02. <dt pn="section-3.6-2.3">Overview:</dt>
ISE review started 2017-07-10, draft 03 <dd pn="section-3.6-2.4">5 individual drafts; Independent Stream</dd>
IETF conflict review and IESG review started 2017-10-29 <dt pn="section-3.6-2.5">First draft:</dt>
Approved 2017-12-18, draft 04 <dd pn="section-3.6-2.6">2017-06-02</dd>
AUTH-48 2018-01-29, draft 05 <dt pn="section-3.6-2.7">ISE review start:</dt>
AUTH-48 complete 2018-02-26 <dd pn="section-3.6-2.8">2017-07-10 (draft 03)</dd>
Published 2018-02-27 <dt pn="section-3.6-2.9">IETF conflict review start:</dt>
]]></artwork></figure> <dd pn="section-3.6-2.10">2017-10-29</dd>
<dt pn="section-3.6-2.11">Approved:</dt>
<t>This RFC took only 9 months from first draft to publication, which is the sho <dd pn="section-3.6-2.12">2017-12-18 (draft 04)</dd>
rtest in <dt pn="section-3.6-2.13">AUTH48 start:</dt>
<dd pn="section-3.6-2.14">2018-01-29 (draft 05)</dd>
<dt pn="section-3.6-2.15">AUTH48 complete:</dt>
<dd pn="section-3.6-2.16">2018-02-26</dd>
<dt pn="section-3.6-2.17">Published:</dt>
<dd pn="section-3.6-2.18">2018-02-27</dd>
</dl>
<t indent="0" pn="section-3.6-3">This RFC took only 9 months from first
draft to publication, which is the shortest in
the 2018 sample set. In part, this is because the text was privately circulated the 2018 sample set. In part, this is because the text was privately circulated
and reviewed by ISE designated experts before the first draft was published. and reviewed by the ISE's selected experts before the first draft was published.
The nature of the document is The nature of the document is
another reason for the short delay. It is an opinion piece, and does not require another reason for the short delay. It is an opinion piece and does not require
the same type of consensus building and reviews than a protocol specification.</ the same type of consensus building and reviews as a protocol specification.</t>
t> <t indent="0" pn="section-3.6-4">Comparing the final draft and the publi
shed version shows only minor copy edits, mostly
<t>Comparing the final draft and the published version shows only minor copy edi for style. According to the author, this is because he knows how to write in RFC
t, mostly style with the result that his documents often need a minimum of editing. He als
for style. According to the author, because this is because he knows how to writ o
e in RFC
Style with the result that his documents often need a minimum of editing. He als
o
makes sure that the document on which the makes sure that the document on which the
Production Center starts working already has changes discussed RFC Production Center starts working already has changes discussed
and approved during Last Call and IESG review incorporated and approved during Last Call and IESG review incorporated,
rather than expecting the Production Center to operate off of rather than expecting the Production Center to operate off of
notes about changed to be made.</t> notes about changes to be made.</t>
</section>
</section> <section anchor="sec-5" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-5" title="8377"> pn="section-3.7">
<t>Transparent Interconnection of Lots of Links (TRILL): Multi-Topology <xref ta <name slugifiedName="name-rfc-8377">RFC 8377</name>
rget="RFC8377"/></t> <t indent="0" pn="section-3.7-1">"Transparent Interconnection of Lots of
Links (TRILL): Multi-Topology" <xref target="RFC8377" format="default" sectionF
<figure><artwork><![CDATA[ ormat="of" derivedContent="RFC8377"/></t>
Proposed standard, 20 pages. Updates RFC 6325, 7177. <dl indent="20" spacing="compact" newline="false" pn="section-3.7-2">
3 personal drafts (personal), first 2013-09-03. 7 WG drafts. <dt pn="section-3.7-2.1">Status (Length):</dt>
WG adoption on 2015-09-01 <dd pn="section-3.7-2.2">Proposed Standard (20 pages)</dd>
Last call announced 2018-02-19, draft 05 <dt pn="section-3.7-2.3">Overview:</dt>
IESG evaluation starts 2018-03-02, draft 06 <dd pn="section-3.7-2.4">3 individual drafts; 7 WG drafts; Updates RFC
Approved 2018-03-12, draft 05 s 6325 and 7177</dd>
AUTH-48 2018-04-20, draft 06 <dt pn="section-3.7-2.5">First draft:</dt>
AUTH-48 complete 2018-07-31 <dd pn="section-3.7-2.6">2013-09-03</dd>
Published 2018-07-31 <dt pn="section-3.7-2.7">WG adoption:</dt>
IANA Table, table entries <dd pn="section-3.7-2.8">2015-09-01</dd>
]]></artwork></figure> <dt pn="section-3.7-2.9">Last Call start:</dt>
<dd pn="section-3.7-2.10">2018-02-19 (draft 05)</dd>
<t>Minor set of copy edits, mostly for style, also clarity.</t> <dt pn="section-3.7-2.11">IESG eval. start:</dt>
<dd pn="section-3.7-2.12">2018-03-06 (draft 05)</dd>
</section> <dt pn="section-3.7-2.13">IESG approved:</dt>
<section anchor="section-6" title="8498"> <dd pn="section-3.7-2.14">2018-03-12 (draft 06)</dd>
<t>A P-Served-User Header Field Parameter for an Originating Call Diversion (CDI <dt pn="section-3.7-2.15">AUTH48 start:</dt>
V) <dd pn="section-3.7-2.16">2018-04-20 (draft 06)</dd>
Session Case in the Session Initiation Protocol (SIP) <xref target="RFC8498"/>.< <dt pn="section-3.7-2.17">AUTH48 complete:</dt>
/t> <dd pn="section-3.7-2.18">2018-07-31</dd>
<dt pn="section-3.7-2.19">Published:</dt>
<figure><artwork><![CDATA[ <dd pn="section-3.7-2.20">2018-07-31</dd>
Informational, 15 pages. <dt pn="section-3.7-2.21">IANA action:</dt>
5 personal drafts (personal), first 2016-03-21. 9 WG drafts. <dd pn="section-3.7-2.22">table entries</dd>
WG adoption on 2017-05-15 </dl>
Last call announced 2018-10-12, draft 05 <t indent="0" pn="section-3.7-3">Minor set of copy edits, mostly for sty
IESG evaluation starts 2018-11-28, draft 07 le, also clarity.</t>
Approved 2018-12-10, draft 08 </section>
AUTH-48 2019-01-28 <section anchor="sec-6" numbered="true" toc="include" removeInRFC="false"
AUTH-48 complete 2019-02-13 pn="section-3.8">
Published 2019-02-15 <name slugifiedName="name-rfc-8498">RFC 8498</name>
IANA Action, table rows added. <t indent="0" pn="section-3.8-1">"A P-Served-User Header Field Parameter
]]></artwork></figure> for an Originating Call Diversion (CDIV)
Session Case in the Session Initiation Protocol (SIP)" <xref target="RFC8498" fo
<t>Copy edit for style, but also clarification of ambiguous sentences.</t> rmat="default" sectionFormat="of" derivedContent="RFC8498"/>.</t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.8-2">
</section> <dt pn="section-3.8-2.1">Status (Length):</dt>
<section anchor="section-7" title="8479"> <dd pn="section-3.8-2.2">Informational (15 pages)</dd>
<t>Storing Validation Parameters in PKCS#8 <xref target="RFC8479"/></t> <dt pn="section-3.8-2.3">Overview:</dt>
<dd pn="section-3.8-2.4">5 individual drafts; 9 WG drafts</dd>
<figure><artwork><![CDATA[ <dt pn="section-3.8-2.5">First draft:</dt>
Informational, 8 pages. Independent Stream. <dd pn="section-3.8-2.6">2016-03-21</dd>
5 personal drafts (personal), first 2017-08-08. <dt pn="section-3.8-2.7">WG adoption:</dt>
ISE review started 2018-12-10, draft 00 <dd pn="section-3.8-2.8">2017-05-15</dd>
IETF conflict review and IESG review started 2018-03-29 <dt pn="section-3.8-2.9">Last Call start:</dt>
Approved 2018-08-20, draft 03 <dd pn="section-3.8-2.10">2018-10-12 (draft 05)</dd>
AUTH-48 2018-09-20, draft 04 <dt pn="section-3.8-2.11">IESG eval. start:</dt>
AUTH-48 complete 2018-09-25 <dd pn="section-3.8-2.12">2018-11-28 (draft 07)</dd>
Published 2018-09-26 <dt pn="section-3.8-2.13">IESG approved:</dt>
]]></artwork></figure> <dd pn="section-3.8-2.14">2018-12-11 (draft 08)</dd>
<dt pn="section-3.8-2.15">AUTH48 start:</dt>
<t>The goal of the draft was to document what the <dd pn="section-3.8-2.16">2019-01-28</dd>
<dt pn="section-3.8-2.17">AUTH48 complete:</dt>
<dd pn="section-3.8-2.18">2019-02-13</dd>
<dt pn="section-3.8-2.19">Published:</dt>
<dd pn="section-3.8-2.20">2019-02-14</dd>
<dt pn="section-3.8-2.21">IANA action:</dt>
<dd pn="section-3.8-2.22">table rows added.</dd>
</dl>
<t indent="0" pn="section-3.8-3">Copy edits for style, but also clarific
ation of ambiguous sentences.</t>
</section>
<section anchor="sec-7" numbered="true" toc="include" removeInRFC="false"
pn="section-3.9">
<name slugifiedName="name-rfc-8479">RFC 8479</name>
<t indent="0" pn="section-3.9-1">"Storing Validation Parameters in PKCS#
8" <xref target="RFC8479" format="default" sectionFormat="of" derivedContent="RF
C8479"/></t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.9-2">
<dt pn="section-3.9-2.1">Status (Length):</dt>
<dd pn="section-3.9-2.2">Informational (8 pages)</dd>
<dt pn="section-3.9-2.3">Overview:</dt>
<dd pn="section-3.9-2.4">5 individual drafts; Independent Stream</dd>
<dt pn="section-3.9-2.5">First draft:</dt>
<dd pn="section-3.9-2.6">2017-08-08</dd>
<dt pn="section-3.9-2.7">ISE review start:</dt>
<dd pn="section-3.9-2.8">2018-12-10 (draft 00)</dd>
<dt pn="section-3.9-2.9">IETF conflict review start:</dt>
<dd pn="section-3.9-2.10">2018-03-29</dd>
<dt pn="section-3.9-2.11">Approved:</dt>
<dd pn="section-3.9-2.12">2018-08-20 (draft 03)</dd>
<dt pn="section-3.9-2.13">AUTH48 start:</dt>
<dd pn="section-3.9-2.14">2018-09-20 (draft 04)</dd>
<dt pn="section-3.9-2.15">AUTH48 complete:</dt>
<dd pn="section-3.9-2.16">2018-09-25</dd>
<dt pn="section-3.9-2.17">Published:</dt>
<dd pn="section-3.9-2.18">2018-09-26</dd>
</dl>
<t indent="0" pn="section-3.9-3">The goal of the draft was to document w
hat the
gnutls implementation was using for storing provably generated RSA keys. gnutls implementation was using for storing provably generated RSA keys.
This is a short RFC that was published relatively quickly, although This is a short RFC that was published relatively quickly, although
discussion between the author, the Independent Series Editor and the discussion between the author, the Independent Submissions Editor, and the
IESG lasted several months. In the initial conflict review, The IESG asked IESG lasted several months. In the initial conflict review, the IESG asked
the ISE to not publish this document before IETF Working Groups had the ISE to not publish this document before IETF working groups had
an opportunity to pick up the work. The author met that requirement by an opportunity to pick up the work. The author met that requirement by
a presentation to the SECDISPATCH WG in IETF 102. Since no WG was a presentation to the SECDISPATCH WG during IETF 102. Since no WG was
interested in pickup the work, the document progressed on the interested in picking up the work, the document progressed on the
Independent Stream.</t> Independent Stream.</t>
<t indent="0" pn="section-3.9-4">Very minor set of copy edits, moving so
<t>Very minor set of copy edit, moving some references from normative to informa me references from normative to informative.</t>
tive.</t> <t indent="0" pn="section-3.9-5">The author is not aware of other implem
entations than gnutls relying on this RFC.</t>
<t>The author is not aware of other implementations than gnutls relying on this </section>
RFC.</t> <section anchor="sec-8" numbered="true" toc="include" removeInRFC="false"
pn="section-3.10">
</section> <name slugifiedName="name-rfc-8453">RFC 8453</name>
<section anchor="section-8" title="8453"> <t indent="0" pn="section-3.10-1">"Framework for Abstraction and Control
<t>Framework for Abstraction and Control of TE Networks (ACTN) <xref target="RFC of TE Networks (ACTN)" <xref target="RFC8453" format="default" sectionFormat="o
8453"/></t> f" derivedContent="RFC8453"/></t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.10-2">
<figure><artwork><![CDATA[ <dt pn="section-3.10-2.1">Status (Length):</dt>
Informational, 42 pages. <dd pn="section-3.10-2.2">Informational (42 pages)</dd>
3 personal drafts, first 2015-06-15. 16 WG drafts. <dt pn="section-3.10-2.3">Overview:</dt>
WG adoption on 2016-07-15 <dd pn="section-3.10-2.4">3 individual drafts; 16 WG drafts</dd>
Out of WG 2018-01-26, draft 11 <dt pn="section-3.10-2.5">First draft:</dt>
Expert review requested, 2018-02-13 <dd pn="section-3.10-2.6">2015-06-15</dd>
Last call announced 2018-04-16, draft 13 <dt pn="section-3.10-2.7">WG adoption:</dt>
IESG evaluation starts 2018-05-16, draft 14 <dd pn="section-3.10-2.8">2016-07-15</dd>
Approved 2018-06-01, draft 15 <dt pn="section-3.10-2.9">Out of WG:</dt>
AUTH-48 2018-08-13 <dd pn="section-3.10-2.10">2018-01-26 (draft 11)</dd>
AUTH-48 complete 2018-08-20 <dt pn="section-3.10-2.11">Expert review requested:</dt>
Published 2018-08-20 <dd pn="section-3.10-2.12">2018-02-13</dd>
IANA Action, table rows added. <dt pn="section-3.10-2.13">Last Call start:</dt>
]]></artwork></figure> <dd pn="section-3.10-2.14">2018-04-16 (draft 13)</dd>
<dt pn="section-3.10-2.15">IESG eval. start:</dt>
<t>Minor copy editing.</t> <dd pn="section-3.10-2.16">2018-05-16 (draft 14)</dd>
<dt pn="section-3.10-2.17">IESG approved:</dt>
</section> <dd pn="section-3.10-2.18">2018-06-01 (draft 15)</dd>
<section anchor="section-9" title="8429"> <dt pn="section-3.10-2.19">AUTH48 start:</dt>
<t>Deprecate Triple-DES (3DES) and RC4 in Kerberos <xref target="RFC8429"/></t> <dd pn="section-3.10-2.20">2018-08-13</dd>
<dt pn="section-3.10-2.21">AUTH48 complete:</dt>
<figure><artwork><![CDATA[ <dd pn="section-3.10-2.22">2018-08-20</dd>
BCP, 10 pages. <dt pn="section-3.10-2.23">Published:</dt>
6 WG drafts, first 2017-05-01. <dd pn="section-3.10-2.24">2018-08-23</dd>
Last call announced 2017-07-16, draft 03 <dt pn="section-3.10-2.25">IANA action:</dt>
IESG evaluation starts 2017-08-18, draft 04 <dd pn="section-3.10-2.26">table rows added.</dd>
Approved 2018-05-25, draft 05 </dl>
AUTH-48 2018-07-24 <t indent="0" pn="section-3.10-3">Minor copy editing.</t>
AUTH-48 complete 2018-10-31 </section>
Published 2018-10-31 <section anchor="sec-9" numbered="true" toc="include" removeInRFC="false"
IANA Action, table rows added. pn="section-3.11">
]]></artwork></figure> <name slugifiedName="name-rfc-8429">RFC 8429</name>
<t indent="0" pn="section-3.11-1">"Deprecate Triple-DES (3DES) and RC4 i
<t>This draft started as a Working Group effort.</t> n Kerberos" <xref target="RFC8429" format="default" sectionFormat="of" derivedCo
ntent="RFC8429"/></t>
<t>This RFC recommends to deprecate two encryption algorithms that are now consi <dl indent="20" spacing="compact" newline="false" pn="section-3.11-2">
dered <dt pn="section-3.11-2.1">Status (Length):</dt>
obsolete and possibly broken. The document was sent back to the WG after the fir <dd pn="section-3.11-2.2">BCP (10 pages)</dd>
st last call, <dt pn="section-3.11-2.3">Overview:</dt>
edited, and then there was a second last call. The delay from first draft to Wor <dd pn="section-3.11-2.4">6 WG drafts</dd>
king Group <dt pn="section-3.11-2.5">First draft:</dt>
last call was relatively short, but the number may be misleading. The initial dr <dd pn="section-3.11-2.6">2017-05-01</dd>
aft was a <dt pn="section-3.11-2.7">Last Call start:</dt>
<dd pn="section-3.11-2.8">2017-07-16 (draft 03)</dd>
<dt pn="section-3.11-2.9">IESG eval. start:</dt>
<dd pn="section-3.11-2.10">2017-08-18 (draft 04)</dd>
<dt pn="section-3.11-2.11">IESG approved:</dt>
<dd pn="section-3.11-2.12">2018-05-25 (draft 05)</dd>
<dt pn="section-3.11-2.13">AUTH48 start:</dt>
<dd pn="section-3.11-2.14">2018-07-24</dd>
<dt pn="section-3.11-2.15">AUTH48 complete:</dt>
<dd pn="section-3.11-2.16">2018-10-31</dd>
<dt pn="section-3.11-2.17">Published:</dt>
<dd pn="section-3.11-2.18">2018-10-31</dd>
<dt pn="section-3.11-2.19">IANA action:</dt>
<dd pn="section-3.11-2.20">table rows added.</dd>
</dl>
<t indent="0" pn="section-3.11-3">This draft started as a working group
effort.</t>
<t indent="0" pn="section-3.11-4">This RFC recommends deprecating two en
cryption algorithms that are now considered
obsolete and possibly broken. The document was sent back to the WG after the fir
st Last Call,
edited, and then there was a second Last Call. The delay from first draft to Wor
king Group
Last Call was relatively short, but the number may be misleading. The initial dr
aft was a
replacement of a similar draft in the KITTEN Working Group, which stagnated for some time replacement of a similar draft in the KITTEN Working Group, which stagnated for some time
before the CURDLE Working Group took up the work. before the CURDLE Working Group took up the work.
The deprecation of RC4 was somewhat contentious, but the WG had already debated this The deprecation of RC4 was somewhat contentious, but the WG had already debated this
prior to the production of this draft, and the draft was not delayed by this deb ate.</t> prior to the production of this draft, and the draft was not delayed by this deb ate.</t>
<t indent="0" pn="section-3.11-5">Most of the 280 days between IETF LC a
<t>Most of the 280 days between IETF LC and IESG approval was nd IESG approval were
because the IESG had to talk about whether this document should obsolete or because the IESG had to talk about whether this document should obsolete RFC 475
move to historic RFC 4757, and no one was really actively pushing that 7 or
move it to Historic status, and no one was really actively pushing that
discussion for a while.</t> discussion for a while.</t>
<t indent="0" pn="section-3.11-6">The 99 days in AUTH48 are mostly becau
<t>The 99 days in AUTH-48 are mostly because one of the authors was a sitting AD se one of the authors was a sitting AD, and those
, and those
duties ended up taking precedence over reviewing this document.</t> duties ended up taking precedence over reviewing this document.</t>
<t indent="0" pn="section-3.11-7">Minor copy editing, for style.</t>
<t>Minor copy editing, for style.</t> <t indent="0" pn="section-3.11-8">The implementation of the draft would
be the actual removal of support for 3DES and RC4
<t>The implementation of the draft would be the actual removal of support for 3D
ES and RC4
in major implementations. This is happening, but very slowly.</t> in major implementations. This is happening, but very slowly.</t>
</section>
</section> <section anchor="sec-10" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-10" title="8312"> pn="section-3.12">
<t>CUBIC for Fast Long-Distance Networks <xref target="RFC8312"/></t> <name slugifiedName="name-rfc-8312">RFC 8312</name>
<t indent="0" pn="section-3.12-1">"CUBIC for Fast Long-Distance Networks
<figure><artwork><![CDATA[ " <xref target="RFC8312" format="default" sectionFormat="of" derivedContent="RFC
Informational, 18 pages. 8312"/></t>
2 personal drafts, first 2014-09-01. 8 WG drafts <dl indent="20" spacing="compact" newline="false" pn="section-3.12-2">
WG adoption on 2015-06-08 <dt pn="section-3.12-2.1">Status (Length):</dt>
Last call announced 2017-09-18, draft 06 <dd pn="section-3.12-2.2">Informational (18 pages)</dd>
IESG evaluation starts 2017-11-14 <dt pn="section-3.12-2.3">Overview:</dt>
Approved 2017-10-04, draft 07 <dd pn="section-3.12-2.4">2 individual drafts; 8 WG drafts</dd>
AUTH-48 2018-01-08 <dt pn="section-3.12-2.5">First draft:</dt>
AUTH-48 complete 2018-02-07 <dd pn="section-3.12-2.6">2014-09-01</dd>
Published 2018-02-07 <dt pn="section-3.12-2.7">WG adoption:</dt>
IANA Action, table rows added. <dd pn="section-3.12-2.8">2015-06-08</dd>
]]></artwork></figure> <dt pn="section-3.12-2.9">Last Call start:</dt>
<dd pn="section-3.12-2.10">2017-09-18 (draft 06)</dd>
<t>Minor copy editing, for style.</t> <dt pn="section-3.12-2.11">IESG eval. start:</dt>
<dd pn="section-3.12-2.12">2017-10-04</dd>
<t>The TCP congestion control algorithm Cubic was defined first in 2005, was imp <dt pn="section-3.12-2.13">IESG approved:</dt>
lemented <dd pn="section-3.12-2.14">2017-11-14 (draft 07)</dd>
<dt pn="section-3.12-2.15">AUTH48 start:</dt>
<dd pn="section-3.12-2.16">2018-01-08</dd>
<dt pn="section-3.12-2.17">AUTH48 complete:</dt>
<dd pn="section-3.12-2.18">2018-02-07</dd>
<dt pn="section-3.12-2.19">Published:</dt>
<dd pn="section-3.12-2.20">2018-02-07</dd>
<dt pn="section-3.12-2.21">IANA action:</dt>
<dd pn="section-3.12-2.22">table rows added.</dd>
</dl>
<t indent="0" pn="section-3.12-3">Minor copy editing, for style.</t>
<t indent="0" pn="section-3.12-4">The TCP congestion control algorithm C
ubic was first defined in 2005, was implemented
in Linux soon after, and was implemented in major OSes after that. After some de bates in Linux soon after, and was implemented in major OSes after that. After some de bates
from 2015 to 2015, the TCPM Working Group adopted the draft, with a goal of from 2015 to 2015, the TCPM Working Group adopted the draft, with a goal of
documenting Cubic in the RFc series. According to the authors, this was not documenting Cubic in the RFC Series. According to the authors, this was not
a high priority effort, as Cubic was already implemented in multiple OSes a high-priority effort, as Cubic was already implemented in multiple OSes
and documented in research papers. At some point, only one of the authors and documented in research papers. At some point, only one of the authors
was actively working on the draft. Ths may explain why another two years was spe nt was actively working on the draft. This may explain why another two years was sp ent
progressing the draft after adoption by the WG.</t> progressing the draft after adoption by the WG.</t>
<t indent="0" pn="section-3.12-5">The RFC publication may or may not hav
<t>The RFC publication may or may not have triggered further implementations. On e triggered further implementations. On
the other hand, several OSes picked up bug fixes from the draft and the RFC.</t> the other hand, several OSes picked up bug fixes from the draft and the RFC.</t>
</section>
</section> <section anchor="sec-11" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-11" title="8492"> pn="section-3.13">
<t>Secure Password Ciphersuites for Transport Layer Security (TLS) <xref target= <name slugifiedName="name-rfc-8492">RFC 8492</name>
"RFC8492"/></t> <t indent="0" pn="section-3.13-1">"Secure Password Ciphersuites for Tran
sport Layer Security (TLS)" <xref target="RFC8492" format="default" sectionForma
<figure><artwork><![CDATA[ t="of" derivedContent="RFC8492"/></t>
Informational, 40 pages. (Independent Stream) <dl indent="20" spacing="compact" newline="false" pn="section-3.13-2">
10 personal drafts, first 2012-09-07. 8 WG drafts <dt pn="section-3.13-2.1">Status (Length):</dt>
Targeted to ISE stream 2016-08-05 <dd pn="section-3.13-2.2">Informational (40 pages)</dd>
ISE review started 2017-05-10, draft 01 <dt pn="section-3.13-2.3">Overview:</dt>
IETF conflict review and IESG review started 2017-09-04 <dd pn="section-3.13-2.4">10 individual drafts; 8 WG drafts; Independe
Approved 2017-10-29, draft 04 nt Stream</dd>
AUTH-48 2018-10-19, draft 05 <dt pn="section-3.13-2.5">First draft:</dt>
AUTH-48 complete 2019-02-19 <dd pn="section-3.13-2.6">2012-09-07</dd>
Published 2019-02-21 <dt pn="section-3.13-2.7">Targeted to ISE:</dt>
IANA Action, table rows added. <dd pn="section-3.13-2.8">2016-08-05</dd>
]]></artwork></figure> <dt pn="section-3.13-2.9">ISE review start:</dt>
<dd pn="section-3.13-2.10">2017-05-10 (draft 01)</dd>
<t>This RFC has a complex history. The first individual draft was submitted to t <dt pn="section-3.13-2.11">IETF conflict review start:</dt>
he <dd pn="section-3.13-2.12">2017-09-04</dd>
<dt pn="section-3.13-2.13">Approved:</dt>
<dd pn="section-3.13-2.14">2017-10-29 (draft 02)</dd>
<dt pn="section-3.13-2.15">AUTH48 start:</dt>
<dd pn="section-3.13-2.16">2018-10-19 (draft 05)</dd>
<dt pn="section-3.13-2.17">AUTH48 complete:</dt>
<dd pn="section-3.13-2.18">2019-02-19</dd>
<dt pn="section-3.13-2.19">Published:</dt>
<dd pn="section-3.13-2.20">2019-02-21</dd>
<dt pn="section-3.13-2.21">IANA action:</dt>
<dd pn="section-3.13-2.22">table rows added.</dd>
</dl>
<t indent="0" pn="section-3.13-3">This RFC has a complex history. The fi
rst individual draft was submitted to the
TLS Working Group on September 7, 2012. It progressed there, and was adopted TLS Working Group on September 7, 2012. It progressed there, and was adopted
by the WG after 3 revisions. There were then 8 revisions in the TLS WG, by the WG after 3 revisions. There were then 8 revisions in the TLS WG,
until the WG decided to not progress it. The draft was parked in 2013 by until the WG decided to not progress it.
the WG chairs after failing to get consensus in WG last call. The AD finally
pulled the plug in 2016, and the draft was then resubmitted to the ISE.</t>
<t>At that point, the author was busy and was treating this RFC with a The draft was parked in 2013 by
the WG chairs after failing to get consensus in WG Last Call. The AD finally
pulled the plug in 2016, and the draft was then resubmitted to the ISE.</t>
<t indent="0" pn="section-3.13-4">At that point, the author was busy and
was treating this RFC with a
low priority because, in his words, it would not be a "real RFC". low priority because, in his words, it would not be a "real RFC".
There were problems with the draft that only came up late. In particular, There were problems with the draft that only came up late. In particular,
it had to wait for a change in registry policy that only came about with it had to wait for a change in registry policy that only came about with
the publication of TLS 1.3, which caused the draft to only be published the publication of TLS 1.3, which caused the draft to be published
after RFC 8446, and also required adding references to TLS 1.3. after RFC 8446, and also required adding references to TLS 1.3.
The author also got a very late comment while in AUTH-48 that The author also got a very late comment while in AUTH48 that
caused some rewrite. Finally, there was some IANA issue with the extension caused some rewriting. Finally, there was some IANA issue with the extension
registry where a similar extension was added by someone else. The draft registry where a similar extension was added by someone else. The draft
was changed to just use it.</t> was changed to just use it.</t>
<t indent="0" pn="section-3.13-5">Changes in AUTH48 include adding a ref
<t>Changes in AUTH-48 include added reference to TLS 1.3, copy-editing for style erence to TLS 1.3, copy editing for style,
,
some added requirements, added paragraphs, and changes in algorithms specificati on.</t> some added requirements, added paragraphs, and changes in algorithms specificati on.</t>
</section>
</section> <section anchor="sec-12" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-12" title="8378"> pn="section-3.14">
<t>Signal-Free Locator/ID Separation Protocol (LISP) Multicast <xref target="RFC <name slugifiedName="name-rfc-8378">RFC 8378</name>
8378"/> is <t indent="0" pn="section-3.14-1">"Signal-Free Locator/ID Separation Pro
an experimental RFC, defining how to implement Multicast in the LISP tocol (LISP) Multicast" <xref target="RFC8378" format="default" sectionFormat="o
f" derivedContent="RFC8378"/> is
an Experimental RFC, defining how to implement Multicast in the LISP
architecture.</t> architecture.</t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.14-2">
<figure><artwork><![CDATA[ <dt pn="section-3.14-2.1">Status (Length):</dt>
Experimental, 21 pages. <dd pn="section-3.14-2.2">Experimental (21 pages)</dd>
5 personal drafts, first 2014-02-28. 10 WG drafts <dt pn="section-3.14-2.3">Overview:</dt>
WG adoption on 2015-12-21 <dd pn="section-3.14-2.4">5 individual drafts; 10 WG drafts</dd>
Last call announced 2018-02-13, draft 07 <dt pn="section-3.14-2.5">First draft:</dt>
IESG evaluation starts 2018-02-28, draft 08 <dd pn="section-3.14-2.6">2014-02-28</dd>
Approved 2018-03-12, draft 09 <dt pn="section-3.14-2.7">WG adoption:</dt>
AUTH-48 2018-04-23 <dd pn="section-3.14-2.8">2015-12-21</dd>
AUTH-48 complete 2018-05-02 <dt pn="section-3.14-2.9">Last Call start:</dt>
Published 2018-05-02 <dd pn="section-3.14-2.10">2018-02-13 (draft 07)</dd>
]]></artwork></figure> <dt pn="section-3.14-2.11">IESG eval. start:</dt>
<dd pn="section-3.14-2.12">2018-02-28 (draft 08)</dd>
<t>Preparing the RFC took more than 4 years. According to the authors, they were <dt pn="section-3.14-2.13">IESG approved:</dt>
not aggressive pushing it and just let the Working Group process decide to pace <dd pn="section-3.14-2.14">2018-03-12 (draft 09)</dd>
<dt pn="section-3.14-2.15">AUTH48 start:</dt>
<dd pn="section-3.14-2.16">2018-04-23</dd>
<dt pn="section-3.14-2.17">AUTH48 complete:</dt>
<dd pn="section-3.14-2.18">2018-05-02</dd>
<dt pn="section-3.14-2.19">Published:</dt>
<dd pn="section-3.14-2.20">2018-05-02</dd>
</dl>
<t indent="0" pn="section-3.14-3">Preparing the RFC took more than 4 yea
rs. According to the authors, they were
not aggressively pushing it and just let the working group process decide to pac
e
it. They also did implementations during that time.</t> it. They also did implementations during that time.</t>
<t indent="0" pn="section-3.14-4">Minor copy editing, for style.</t>
<t>Minor copy editing, for style.</t> <t indent="0" pn="section-3.14-5">The RFC was implemented by lispers.net
and Cisco,
<t>The RFC was implemented by lispers.net and cisco, and it was used in doing IPv6 multicast over IPv4 unicast/multicast at the Olymp
and was used in doing IPv6 multicast over IPv4 unicast/multicast at the Olympics ics
in PyeungChang. The plan is to work on a proposedstandard once the in PyeungChang. The plan is to work on a Proposed Standard once the
experiment concludes.</t> experiment concludes.</t>
</section>
</section> <section anchor="sec-13" numbered="true" toc="include" removeInRFC="false"
<section anchor="section-13" title="8361"> pn="section-3.15">
<t>Transparent Interconnection of Lots of Links (TRILL): <name slugifiedName="name-rfc-8361">RFC 8361</name>
<t indent="0" pn="section-3.15-1">"Transparent Interconnection of Lots o
f Links (TRILL):
Centralized Replication for Active-Active Broadcast, Centralized Replication for Active-Active Broadcast,
Unknown Unicast, and Multicast (BUM) Traffic <xref target="RFC8361"/></t> Unknown Unicast, and Multicast (BUM) Traffic" <xref target="RFC8361" format="def
ault" sectionFormat="of" derivedContent="RFC8361"/></t>
<figure><artwork><![CDATA[ <dl indent="20" spacing="compact" newline="false" pn="section-3.15-2">
Proposed Standard, 17 pages. <dt pn="section-3.15-2.1">Status (Length):</dt>
3 personal drafts, first 2013-11-12. 14 WG drafts <dd pn="section-3.15-2.2">Proposed Standard (17 pages)</dd>
WG adoption on 2014-12-16 <dt pn="section-3.15-2.3">Overview:</dt>
Last call announced 2017-11-28, draft 10 <dd pn="section-3.15-2.4">3 individual drafts; 14 WG drafts</dd>
IESG evaluation starts 2017-12-18, draft 11 <dt pn="section-3.15-2.5">First draft:</dt>
Approved 2018-01-29, draft 13 <dd pn="section-3.15-2.6">2013-11-12</dd>
AUTH-48 2018-03-09 <dt pn="section-3.15-2.7">WG adoption:</dt>
AUTH-48 complete 2018-04-09 <dd pn="section-3.15-2.8">2014-12-16</dd>
Published 2018-04-12 <dt pn="section-3.15-2.9">Last Call start:</dt>
]]></artwork></figure> <dd pn="section-3.15-2.10">2017-11-28 (draft 10)</dd>
<dt pn="section-3.15-2.11">IESG eval. start:</dt>
<t>According to the authors, the long delays in producing this RFC was <dd pn="section-3.15-2.12">2017-12-18 (draft 11)</dd>
<dt pn="section-3.15-2.13">IESG approved:</dt>
<dd pn="section-3.15-2.14">2018-01-29 (draft 13)</dd>
<dt pn="section-3.15-2.15">AUTH48 start:</dt>
<dd pn="section-3.15-2.16">2018-03-09</dd>
<dt pn="section-3.15-2.17">AUTH48 complete:</dt>
<dd pn="section-3.15-2.18">2018-04-09</dd>
<dt pn="section-3.15-2.19">Published:</dt>
<dd pn="section-3.15-2.20">2018-04-12</dd>
</dl>
<t indent="0" pn="section-3.15-3">According to the authors, the long del
ays in producing this RFC were
due to a slow uptake of the technology in the industry.</t> due to a slow uptake of the technology in the industry.</t>
<t indent="0" pn="section-3.15-4">Minor copy editing, for style.</t>
<t>Minor copy editing, for style.</t> <t indent="0" pn="section-3.15-5">There was at least one partial impleme
ntation.</t>
<t>There was at least 1 partial implementation.</t> </section>
<section anchor="sec-14" numbered="true" toc="include" removeInRFC="false"
</section> pn="section-3.16">
<section anchor="section-14" title="8472"> <name slugifiedName="name-rfc-8472">RFC 8472</name>
<t>Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiati <t indent="0" pn="section-3.16-1">"Transport Layer Security (TLS) Extens
on <xref target="RFC8472"/></t> ion for Token Binding Protocol Negotiation" <xref target="RFC8472" format="defau
lt" sectionFormat="of" derivedContent="RFC8472"/></t>
<figure><artwork><![CDATA[ <dl indent="20" spacing="compact" newline="false" pn="section-3.16-2">
Proposed Standard, 8 pages. <dt pn="section-3.16-2.1">Status (Length):</dt>
1 personal drafts, 2015-05-29. 15 WG drafts <dd pn="section-3.16-2.2">Proposed Standard (8 pages)</dd>
WG adoption on 2015-09-11 <dt pn="section-3.16-2.3">Overview:</dt>
Last call announced 2017-11-13, draft 10 <dd pn="section-3.16-2.4">1 individual draft; 15 WG drafts</dd>
IESG evaluation starts 2018-03-19 <dt pn="section-3.16-2.5">First draft:</dt>
Approved 2018-07-20, draft 14 <dd pn="section-3.16-2.6">2015-05-29</dd>
AUTH-48 2018-09-17 <dt pn="section-3.16-2.7">WG adoption:</dt>
AUTH-48 complete 2018-09-25 <dd pn="section-3.16-2.8">2015-09-11</dd>
Published 2018-10-08 <dt pn="section-3.16-2.9">Last Call start:</dt>
]]></artwork></figure> <dd pn="section-3.16-2.10">2017-11-13 (draft 10)</dd>
<dt pn="section-3.16-2.11">IESG eval. start:</dt>
<t>This is a pretty simple document, but it took over 3 years from individual dr <dd pn="section-3.16-2.12">2018-03-19</dd>
aft to RFC. According to <dt pn="section-3.16-2.13">IESG approved:</dt>
<dd pn="section-3.16-2.14">2018-07-20 (draft 14)</dd>
<dt pn="section-3.16-2.15">AUTH48 start:</dt>
<dd pn="section-3.16-2.16">2018-09-17</dd>
<dt pn="section-3.16-2.17">AUTH48 complete:</dt>
<dd pn="section-3.16-2.18">2018-09-25</dd>
<dt pn="section-3.16-2.19">Published:</dt>
<dd pn="section-3.16-2.20">2018-10-08</dd>
</dl>
<t indent="0" pn="section-3.16-3">This is a pretty simple document, but
it took over 3 years from individual draft to RFC. According to
the authors,the biggest setbacks occurred at the start: it took a while to find a home for this draft. the authors,the biggest setbacks occurred at the start: it took a while to find a home for this draft.
It was presented in the TLS WG (because it's a TLS extension) and UTA WG (becaus e it has to do with It was presented in the TLS WG (because it's a TLS extension) and UTA WG (becaus e it has to do with
applications using TLS). Then the ADs determined that a new WG was needed, so th e authors had to work applications using TLS). Then the ADs determined that a new WG was needed, so th e authors had to work
through the WG creation process, including running a BOF.</t> through the WG creation process, including running a BOF.</t>
<t indent="0" pn="section-3.16-4">Minor copy editing, for style, with th
<t>Minor copy editing, for style, with the addition of a reference to TLS 1.3.</ e addition of a reference to TLS 1.3.</t>
t> <t indent="0" pn="section-3.16-5">Perhaps partially due to the delays, s
ome of the implementers lost interest in supporting this RFC.</t>
<t>Perhaps partially due to the delays, some of the implementers lost interest i </section>
n supporting this RFC.</t> <section anchor="sec-15" numbered="true" toc="include" removeInRFC="false"
pn="section-3.17">
</section> <name slugifiedName="name-rfc-8471">RFC 8471</name>
<section anchor="section-15" title="8471"> <t indent="0" pn="section-3.17-1">"The Token Binding Protocol Version 1.
<t>The Token Binding Protocol Version 1.0 <xref target="RFC8471"/></t> 0" <xref target="RFC8471" format="default" sectionFormat="of" derivedContent="RF
C8471"/></t>
<figure><artwork><![CDATA[ <dl indent="20" spacing="compact" newline="false" pn="section-3.17-2">
Proposed Standard, 18 pages. <dt pn="section-3.17-2.1">Status (Length):</dt>
1 personal drafts, 2014-10-13. 19 WG drafts <dd pn="section-3.17-2.2">Proposed Standard (18 pages)</dd>
WG adoption on 2015-03-15 <dt pn="section-3.17-2.3">Overview:</dt>
Last call announced 2017-11-13, draft 16 <dd pn="section-3.17-2.4">1 individual draft; 19 WG drafts</dd>
IESG evaluation starts 2018-03-19 <dt pn="section-3.17-2.5">First draft:</dt>
Approved 2018-07-20, draft 19 <dd pn="section-3.17-2.6">2014-10-13</dd>
AUTH-48 2018-09-17 <dt pn="section-3.17-2.7">WG adoption:</dt>
AUTH-48 complete 2018-09-25 <dd pn="section-3.17-2.8">2015-03-15</dd>
Published 2018-10-08 <dt pn="section-3.17-2.9">Last Call start:</dt>
]]></artwork></figure> <dd pn="section-3.17-2.10">2017-11-13 (draft 16)</dd>
<t>Presentation of a Token Binding Protocol for TLS. We can notice a delay of 5 <dt pn="section-3.17-2.11">IESG eval. start:</dt>
months before adoption of <dd pn="section-3.17-2.12">2018-03-19</dd>
the draft by the WG. That explains in part the overall delay of almost 4 years f <dt pn="section-3.17-2.13">IESG approved:</dt>
rom first draft to <dd pn="section-3.17-2.14">2018-07-20 (draft 19)</dd>
publication.</t> <dt pn="section-3.17-2.15">AUTH48 start:</dt>
<dd pn="section-3.17-2.16">2018-09-17</dd>
<t>Minor copy editing, for style.</t> <dt pn="section-3.17-2.17">AUTH48 complete:</dt>
<dd pn="section-3.17-2.18">2018-09-25</dd>
<t>The web references indicates adoption in multiple development projects.</t> <dt pn="section-3.17-2.19">Published:</dt>
<dd pn="section-3.17-2.20">2018-10-08</dd>
</section> </dl>
<section anchor="section-16" title="8466"> <t indent="0" pn="section-3.17-3">This document presents a Token Binding
<t>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Deliver Protocol for TLS.
y <xref target="RFC8466"/></t> We can notice a
period of 5 months before adoption of the draft by the WG. That
<figure><artwork><![CDATA[ explains in part the overall time of almost 4 years from first draft
Proposed Standard, 158 pages. to publication.
5 personal drafts, first 2016-09-01. 11 WG drafts </t>
WG adoption on 2017-02-26 <t indent="0" pn="section-3.17-4">Minor copy editing, for style.</t>
Last call announced 2018-02-21, draft 07 <t indent="0" pn="section-3.17-5">The web references indicate adoption i
IESG evaluation starts 2018-03-14, draft 08 n multiple development projects.</t>
Approved 2018-06-25, draft 10 </section>
AUTH-48 2018-09-17 <section anchor="sec-16" numbered="true" toc="include" removeInRFC="false"
AUTH-48 complete 2018-10-09 pn="section-3.18">
Published 2018-10-12 <name slugifiedName="name-rfc-8466">RFC 8466</name>
]]></artwork></figure> <t indent="0" pn="section-3.18-1">"A YANG Data Model for Layer 2 Virtual
Private Network (L2VPN) Service Delivery" <xref target="RFC8466" format="defaul
<t>Copy editing for style and clarity, with also corrections to the yang model.< t" sectionFormat="of" derivedContent="RFC8466"/></t>
/t> <dl indent="20" spacing="compact" newline="false" pn="section-3.18-2">
<dt pn="section-3.18-2.1">Status (Length):</dt>
</section> <dd pn="section-3.18-2.2">Proposed Standard (158 pages)</dd>
<section anchor="section-17" title="8362"> <dt pn="section-3.18-2.3">Overview:</dt>
<t>OSPFv3 Link State Advertisement (LSA) Extensibility <xref target="RFC8362"/> <dd pn="section-3.18-2.4">5 individual drafts; 11 WG drafts</dd>
is a major extension to the <dt pn="section-3.18-2.5">First draft:</dt>
<dd pn="section-3.18-2.6">2016-09-01</dd>
<dt pn="section-3.18-2.7">WG adoption:</dt>
<dd pn="section-3.18-2.8">2017-02-26</dd>
<dt pn="section-3.18-2.9">Last Call start:</dt>
<dd pn="section-3.18-2.10">2018-02-21 (draft 07)</dd>
<dt pn="section-3.18-2.11">IESG eval. start:</dt>
<dd pn="section-3.18-2.12">2018-03-14 (draft 08)</dd>
<dt pn="section-3.18-2.13">IESG approved:</dt>
<dd pn="section-3.18-2.14">2018-06-25 (draft 10)</dd>
<dt pn="section-3.18-2.15">AUTH48 start:</dt>
<dd pn="section-3.18-2.16">2018-09-17</dd>
<dt pn="section-3.18-2.17">AUTH48 complete:</dt>
<dd pn="section-3.18-2.18">2018-10-09</dd>
<dt pn="section-3.18-2.19">Published:</dt>
<dd pn="section-3.18-2.20">2018-10-12</dd>
</dl>
<t indent="0" pn="section-3.18-3">Copy editing for style and clarity, wi
th also corrections to the YANG model.</t>
</section>
<section anchor="sec-17" numbered="true" toc="include" removeInRFC="false"
pn="section-3.19">
<name slugifiedName="name-rfc-8362">RFC 8362</name>
<t indent="0" pn="section-3.19-1">"OSPFv3 Link State Advertisement (LSA)
Extensibility" <xref target="RFC8362" format="default" sectionFormat="of" deriv
edContent="RFC8362"/> is a major extension to the
OSPF protocol. It makes OSPFv3 fully extensible.</t> OSPF protocol. It makes OSPFv3 fully extensible.</t>
<dl indent="20" spacing="compact" newline="false" pn="section-3.19-2">
<figure><artwork><![CDATA[ <dt pn="section-3.19-2.1">Status (Length):</dt>
Proposed Standard, 33 pages. <dd pn="section-3.19-2.2">Proposed Standard (33 pages)</dd>
4 personal drafts, first 2013-02-17. 24 WG drafts <dt pn="section-3.19-2.3">Overview:</dt>
WG adoption on 2013-10-15 <dd pn="section-3.19-2.4">4 individual drafts; 24 WG drafts</dd>
Last call announced 2017-12-19, draft 19 <dt pn="section-3.19-2.5">First draft:</dt>
IESG evaluation starts 2018-01-18, draft 20 <dd pn="section-3.19-2.6">2013-02-17</dd>
Approved 2018-01-29, draft 23 <dt pn="section-3.19-2.7">WG adoption:</dt>
AUTH-48 2018-03-19 <dd pn="section-3.19-2.8">2013-10-15</dd>
AUTH-48 complete 2018-03-30 <dt pn="section-3.19-2.9">Last Call start:</dt>
Published 2018-04-03 <dd pn="section-3.19-2.10">2017-12-19 (draft 19)</dd>
]]></artwork></figure> <dt pn="section-3.19-2.11">IESG eval. start:</dt>
<dd pn="section-3.19-2.12">2018-01-18 (draft 20)</dd>
<t>The specification was first submitted as a personal draft in the IPv6 WG, the <dt pn="section-3.19-2.13">IESG approved:</dt>
n moved to the OSPF WG. <dd pn="section-3.19-2.14">2018-01-29 (draft 23)</dd>
<dt pn="section-3.19-2.15">AUTH48 start:</dt>
<dd pn="section-3.19-2.16">2018-03-19</dd>
<dt pn="section-3.19-2.17">AUTH48 complete:</dt>
<dd pn="section-3.19-2.18">2018-03-30</dd>
<dt pn="section-3.19-2.19">Published:</dt>
<dd pn="section-3.19-2.20">2018-04-03</dd>
</dl>
<t indent="0" pn="section-3.19-3">The specification was first submitted
as an individual draft in the IPv6 WG, then moved to the OSPF WG.
The long delay of producing this RFC is due to the complexity of the problem, The long delay of producing this RFC is due to the complexity of the problem,
and the need to wait for implementations. It is a very important change to OSPF and the need to wait for implementations. It is a very important change to OSPF
that makes OSPFv3 fully extensible. Since it was a non-backward compatible chang e, that makes OSPFv3 fully extensible. Since it was a non-backward compatible chang e,
the developers started out with some very complex migration scenarios but ended up the developers started out with some very complex migration scenarios but ended up
with either legacy or extended OSPFv3 LSAs within an OSPFv3 routing domain. The initial attempts with either legacy or extended OSPFv3 LSAs within an OSPFv3 routing domain. The initial attempts
to have a hybrid mode of operation with both legacy and extended LSAs also delay ed implementation to have a hybrid mode of operation with both legacy and extended LSAs also delay ed implementation
due to the complexity.</t> due to the complexity.</t>
<t indent="0" pn="section-3.19-4">Copy editing for style and clarity.</t
<t>Copy editing for style and clarity.</t> >
<t indent="0" pn="section-3.19-5">This specification either was or will
<t>This specification either was or will be implemented by all the router vendor be implemented by all the router vendors.</t>
s.</t> </section>
<section anchor="sec-18" numbered="true" toc="include" removeInRFC="false"
</section> pn="section-3.20">
<section anchor="section-18" title="8468"> <name slugifiedName="name-rfc-8468">RFC 8468</name>
<t>IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP <t indent="0" pn="section-3.20-1">"IPv4, IPv6, and IPv4-IPv6 Coexistence
Performance Metrics (IPPM) Framework <xref target="RFC8468"/>.</t> : Updates for the IP
Performance Metrics (IPPM) Framework" <xref target="RFC8468" format="default" se
<figure><artwork><![CDATA[ ctionFormat="of" derivedContent="RFC8468"/>.</t>
Informational, 15 pages. <dl indent="20" spacing="compact" newline="false" pn="section-3.20-2">
3 personal drafts, first 2015-08-06. 7 WG drafts <dt pn="section-3.20-2.1">Status (Length):</dt>
WG adoption on 2016-07-04 <dd pn="section-3.20-2.2">Informational (15 pages)</dd>
Last call announced 2018-04-11, draft 04 <dt pn="section-3.20-2.3">Overview:</dt>
IESG evaluation starts 2018-05-24, draft 05 <dd pn="section-3.20-2.4">3 individual drafts; 7 WG drafts</dd>
Approved 2018-07-10, draft 06 <dt pn="section-3.20-2.5">First draft:</dt>
AUTH-48 2018-09-13 <dd pn="section-3.20-2.6">2015-08-06</dd>
AUTH-48 complete 2018-11-05 <dt pn="section-3.20-2.7">WG adoption:</dt>
Published 2018-11-14 <dd pn="section-3.20-2.8">2016-07-04</dd>
]]></artwork></figure> <dt pn="section-3.20-2.9">Last Call start:</dt>
<dd pn="section-3.20-2.10">2018-04-11 (draft 04)</dd>
<t>RFC8468 was somehow special in that <dt pn="section-3.20-2.11">IESG eval. start:</dt>
there was not a technical reason/interest that triggered it, but <dd pn="section-3.20-2.12">2018-05-24 (draft 05)</dd>
<dt pn="section-3.20-2.13">IESG approved:</dt>
<dd pn="section-3.20-2.14">2018-07-10 (draft 06)</dd>
<dt pn="section-3.20-2.15">AUTH48 start:</dt>
<dd pn="section-3.20-2.16">2018-09-13</dd>
<dt pn="section-3.20-2.17">AUTH48 complete:</dt>
<dd pn="section-3.20-2.18">2018-11-05</dd>
<dt pn="section-3.20-2.19">Published:</dt>
<dd pn="section-3.20-2.20">2018-11-14</dd>
</dl>
<t indent="0" pn="section-3.20-3">RFC 8468 was somehow special in that
there was not a technical reason or interest that triggered it, but
rather a formal requirement. rather a formal requirement.
While writing RFC7312 the IP Performance While writing RFC 7312, the IP Performance
Metrics Working Group (IPPM) realized that RFC 2330, the IP Performance Metrics (IPPM) Working Group realized that RFC 2330, the IP Performance
Metrics Framework supported IPv4 only Metrics Framework supported IPv4 only
and explicitly excluded support for IPv6. Nevertheless, people used and explicitly excluded support for IPv6. Nevertheless, people used
the metrics that were defined on top of RFC 2330 (and, therefore, IPv4 the metrics that were defined on top of RFC 2330 (and, therefore, IPv4
only) for IPv6, too. Although the IPPM WG agreed that the work was needed, the only) for IPv6, too. Although the IPPM WG agreed that the work was needed, the
interest of IPPM attendees in progressing (and reading/reviewing) the interest of IPPM attendees in progressing (and reading/reviewing) the
IPv6 draft was limited. Resolving the IPv6 technical part was IPv6 draft was limited. Resolving the IPv6 technical part was
straight-forward, but subsequently some people asked for a broader scope straightforward, but subsequently some people asked for a broader scope
(topics like header compression, 6lo, etc.) and it took some time to (topics like header compression, 6LoWPAN, etc.), and it took some time to
figure out and later on convince people that these topics are out of scope. figure out and later on convince people that these topics are out of scope.
The group also had to resolve contentious topics, for example how to The group also had to resolve contentious topics, for example, how to
measure the processing of IPv6 extension headers, which is sometimes non-standar measure the processing of IPv6 extension headers, which is sometimes nonstandard
d.</t> .</t>
<t indent="0" pn="section-3.20-4">The time in AUTH48 state for this docu
<t>The AUTH-48 delay for this draft was longer than average. According to the au ment was longer than average. According to the authors,
thors,
the main reasons include:</t> the main reasons include:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<t><list style="symbols"> .20-5">
<t>Work-load and travel caused by busy-work-periods of all co-authors</t> <li pn="section-3.20-5.1">Workload and travel caused by busy work peri
<t>Time zone difference between co-authors and editor (at least US, ods of all coauthors</li>
Europe, India, not considering travel)</t> <li pn="section-3.20-5.2">Time zone difference between coauthors and e
<t>Editor proposing and committing some unacceptable modifications that ditor (at least US,
needed to be reverted</t> Europe, and India, not considering travel)</li>
<t>Lengthy discussions on a new document title (required high effort and <li pn="section-3.20-5.3">
took a long time, in particular reaching consensus between co-authors RFC Production Center proposed and committed some unacceptable
and editor was time-consuming and involved the AD)</t> modifications that needed to be reverted
<t>Editor correctly identifying some nits (obsoleted personal websites of </li>
co-authors) and co-authors attempting to fix them.</t> <li pn="section-3.20-5.4">Lengthy discussions on a new document title
</list></t> (required high effort and
took a long time, in particular reaching consensus between coauthors
<t>The differences between the final draft and the publish RFC show copy editing and editor was time-consuming and involved the AD)</li>
for style <li pn="section-3.20-5.5">RFC Production Center correctly identified s
ome nits (obsoleted personal websites of
coauthors) and coauthors attempting to fix them.</li>
</ul>
<t indent="0" pn="section-3.20-6">The differences between the final draf
t and the published RFC show copy editing for style
and clarity, but do not account for the back and forth between authors and edito rs and clarity, but do not account for the back and forth between authors and edito rs
mentioned by the authors.</t> mentioned by the authors.</t>
</section>
</section> </section>
</section> <section anchor="process-analysis" numbered="true" toc="include" removeInRFC
<section anchor="process-analysis" title="Analysis of Process and Delays"> ="false" pn="section-4">
<name slugifiedName="name-analysis-of-process-and-del">Analysis of Process
<t>We examine the 20 RFCs in the sample, measuring various characteristics such and Delays</name>
<t indent="0" pn="section-4-1">We examine the 20 RFCs in the sample, measu
ring various characteristics such
as delay and citation counts, in an attempt to identify patterns in the as delay and citation counts, in an attempt to identify patterns in the
IETF processes.</t> IETF processes.</t>
<section anchor="first-draft-to-rfc-delays" numbered="true" toc="include"
<section anchor="first-draft-to-rfc-delays" title="First Draft to RFC Delays"> removeInRFC="false" pn="section-4.1">
<name slugifiedName="name-delays-from-first-draft-to-">Delays from First
<t>We look at the distribution of delays between the submission of the first Draft to RFC</name>
draft and the publication of the RFC, using the three big milestones defined <t indent="0" pn="section-4.1-1">We look at the distribution of delays b
in <xref target="milestones"/>: processing time in the Working Group, IETF proce etween the submission of the first
ssing time, draft and the publication of the RFC, using the three milestones defined
and publication delay. The following table in <xref target="milestones" format="default" sectionFormat="of" derivedContent=
shows the delays for the 20 RFCs in the sample:</t> "Section 2.1"/>: processing time in the working group, IETF processing time,
and RFC production time. The following table
<texttable> shows the number of days in each phase for the 20 RFCs in the sample:</t>
<ttcol align='right'>RFC</ttcol> <table align="center" pn="table-1">
<ttcol align='left'>Status</ttcol> <thead>
<ttcol align='right'>Pages</ttcol> <tr>
<ttcol align='right'>Overall</ttcol> <th align="right" colspan="1" rowspan="1">RFC</th>
<ttcol align='right'>WG</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>IETF</ttcol> <th align="right" colspan="1" rowspan="1">Pages</th>
<ttcol align='right'>Edit</ttcol> <th align="right" colspan="1" rowspan="1">Overall</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">WG</th>
<c>Info</c> <th align="right" colspan="1" rowspan="1">IETF</th>
<c>5</c> <th align="right" colspan="1" rowspan="1">Edit</th>
<c>455</c> </tr>
<c>154</c> </thead>
<c>140</c> <tbody>
<c>161</c> <tr>
<c>8456</c> <td align="right" colspan="1" rowspan="1">8411</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>64</c> <td align="right" colspan="1" rowspan="1">5</td>
<c>1317</c> <td align="right" colspan="1" rowspan="1">455</td>
<c>1033</c> <td align="right" colspan="1" rowspan="1">154</td>
<c>126</c> <td align="right" colspan="1" rowspan="1">140</td>
<c>158</c> <td align="right" colspan="1" rowspan="1">161</td>
<c>8446</c> </tr>
<c>PS</c> <tr>
<c>160</c> <td align="right" colspan="1" rowspan="1">8456</td>
<c>1576</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>1400</c> <td align="right" colspan="1" rowspan="1">64</td>
<c>34</c> <td align="right" colspan="1" rowspan="1">1317</td>
<c>142</c> <td align="right" colspan="1" rowspan="1">1033</td>
<c>8355</c> <td align="right" colspan="1" rowspan="1">126</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">158</td>
<c>13</c> </tr>
<c>1517</c> <tr>
<c>1175</c> <td align="right" colspan="1" rowspan="1">8446</td>
<c>243</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>99</c> <td align="right" colspan="1" rowspan="1">160</td>
<c>8441</c> <td align="right" colspan="1" rowspan="1">1576</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">1400</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">34</td>
<c>341</c> <td align="right" colspan="1" rowspan="1">142</td>
<c>204</c> </tr>
<c>31</c> <tr>
<c>106</c> <td align="right" colspan="1" rowspan="1">8355</td>
<c>8324</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">13</td>
<c>29</c> <td align="right" colspan="1" rowspan="1">1517</td>
<c>270</c> <td align="right" colspan="1" rowspan="1">1175</td>
<c>38</c> <td align="right" colspan="1" rowspan="1">243</td>
<c>161</c> <td align="right" colspan="1" rowspan="1">99</td>
<c>71</c> </tr>
<c>8377</c> <tr>
<c>PS</c> <td align="right" colspan="1" rowspan="1">8441</td>
<c>8</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>1792</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>1630</c> <td align="right" colspan="1" rowspan="1">327</td>
<c>21</c> <td align="right" colspan="1" rowspan="1">204</td>
<c>141</c> <td align="right" colspan="1" rowspan="1">31</td>
<c>8498</c> <td align="right" colspan="1" rowspan="1">92</td>
<c>Info</c> </tr>
<c>15</c> <tr>
<c>1061</c> <td align="right" colspan="1" rowspan="1">8324</td>
<c>935</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>59</c> <td align="right" colspan="1" rowspan="1">29</td>
<c>67</c> <td align="right" colspan="1" rowspan="1">270</td>
<c>8479</c> <td align="right" colspan="1" rowspan="1">38</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">161</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">71</td>
<c>414</c> </tr>
<c>233</c> <tr>
<c>144</c> <td align="right" colspan="1" rowspan="1">8377</td>
<c>37</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>8453</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">1792</td>
<c>42</c> <td align="right" colspan="1" rowspan="1">1630</td>
<c>1162</c> <td align="right" colspan="1" rowspan="1">21</td>
<c>1036</c> <td align="right" colspan="1" rowspan="1">141</td>
<c>46</c> </tr>
<c>80</c> <tr>
<c>8429</c> <td align="right" colspan="1" rowspan="1">8498</td>
<c>BCP</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>10</c> <td align="right" colspan="1" rowspan="1">15</td>
<c>548</c> <td align="right" colspan="1" rowspan="1">1059</td>
<c>76</c> <td align="right" colspan="1" rowspan="1">935</td>
<c>313</c> <td align="right" colspan="1" rowspan="1">59</td>
<c>159</c> <td align="right" colspan="1" rowspan="1">65</td>
<c>8312</c> </tr>
<c>Info</c> <tr>
<c>18</c> <td align="right" colspan="1" rowspan="1">8479</td>
<c>1255</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>1113</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>16</c> <td align="right" colspan="1" rowspan="1">414</td>
<c>126</c> <td align="right" colspan="1" rowspan="1">233</td>
<c>8492</c> <td align="right" colspan="1" rowspan="1">144</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">37</td>
<c>40</c> </tr>
<c>2358</c> <tr>
<c>1706</c> <td align="right" colspan="1" rowspan="1">8453</td>
<c>172</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>480</c> <td align="right" colspan="1" rowspan="1">42</td>
<c>8378</c> <td align="right" colspan="1" rowspan="1">1165</td>
<c>Exp</c> <td align="right" colspan="1" rowspan="1">1036</td>
<c>21</c> <td align="right" colspan="1" rowspan="1">46</td>
<c>1524</c> <td align="right" colspan="1" rowspan="1">83</td>
<c>1446</c> </tr>
<c>27</c> <tr>
<c>51</c> <td align="right" colspan="1" rowspan="1">8429</td>
<c>8361</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">10</td>
<c>17</c> <td align="right" colspan="1" rowspan="1">548</td>
<c>1612</c> <td align="right" colspan="1" rowspan="1">76</td>
<c>1477</c> <td align="right" colspan="1" rowspan="1">313</td>
<c>62</c> <td align="right" colspan="1" rowspan="1">159</td>
<c>73</c> </tr>
<c>8472</c> <tr>
<c>PS</c> <td align="right" colspan="1" rowspan="1">8312</td>
<c>8</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>1228</c> <td align="right" colspan="1" rowspan="1">18</td>
<c>899</c> <td align="right" colspan="1" rowspan="1">1214</td>
<c>249</c> <td align="right" colspan="1" rowspan="1">1113</td>
<c>80</c> <td align="right" colspan="1" rowspan="1">16</td>
<c>8471</c> <td align="right" colspan="1" rowspan="1">85</td>
<c>PS</c> </tr>
<c>18</c> <tr>
<c>1228</c> <td align="right" colspan="1" rowspan="1">8492</td>
<c>899</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>249</c> <td align="right" colspan="1" rowspan="1">40</td>
<c>80</c> <td align="right" colspan="1" rowspan="1">2358</td>
<c>8466</c> <td align="right" colspan="1" rowspan="1">1706</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">172</td>
<c>158</c> <td align="right" colspan="1" rowspan="1">480</td>
<c>771</c> </tr>
<c>538</c> <tr>
<c>124</c> <td align="right" colspan="1" rowspan="1">8378</td>
<c>109</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>8362</c> <td align="right" colspan="1" rowspan="1">21</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">1524</td>
<c>33</c> <td align="right" colspan="1" rowspan="1">1446</td>
<c>1871</c> <td align="right" colspan="1" rowspan="1">27</td>
<c>1766</c> <td align="right" colspan="1" rowspan="1">51</td>
<c>41</c> </tr>
<c>64</c> <tr>
<c>8468</c> <td align="right" colspan="1" rowspan="1">8361</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>15</c> <td align="right" colspan="1" rowspan="1">17</td>
<c>1196</c> <td align="right" colspan="1" rowspan="1">1612</td>
<c>979</c> <td align="right" colspan="1" rowspan="1">1477</td>
<c>90</c> <td align="right" colspan="1" rowspan="1">62</td>
<c>127</c> <td align="right" colspan="1" rowspan="1">73</td>
<c>&#160;</c> </tr>
<c>average</c> <tr>
<c>35</c> <td align="right" colspan="1" rowspan="1">8472</td>
<c>1186</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>948</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>117</c> <td align="right" colspan="1" rowspan="1">1228</td>
<c>121</c> <td align="right" colspan="1" rowspan="1">899</td>
<c>&#160;</c> <td align="right" colspan="1" rowspan="1">249</td>
<c>average(not ISE)</c> <td align="right" colspan="1" rowspan="1">80</td>
<c>36</c> </tr>
<c>1217</c> <tr>
<c>999</c> <td align="right" colspan="1" rowspan="1">8471</td>
<c>110</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>107</c> <td align="right" colspan="1" rowspan="1">18</td>
</texttable> <td align="right" colspan="1" rowspan="1">1228</td>
<td align="right" colspan="1" rowspan="1">899</td>
<t>The average delay from first draft to publication is about 3 years and 3 mont <td align="right" colspan="1" rowspan="1">249</td>
hs, but this <td align="right" colspan="1" rowspan="1">80</td>
varies widely. Excluding the Independent Stream submissions, the average </tr>
<tr>
<td align="right" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">158</td>
<td align="right" colspan="1" rowspan="1">771</td>
<td align="right" colspan="1" rowspan="1">538</td>
<td align="right" colspan="1" rowspan="1">124</td>
<td align="right" colspan="1" rowspan="1">109</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">33</td>
<td align="right" colspan="1" rowspan="1">1871</td>
<td align="right" colspan="1" rowspan="1">1766</td>
<td align="right" colspan="1" rowspan="1">41</td>
<td align="right" colspan="1" rowspan="1">64</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">15</td>
<td align="right" colspan="1" rowspan="1">1196</td>
<td align="right" colspan="1" rowspan="1">979</td>
<td align="right" colspan="1" rowspan="1">90</td>
<td align="right" colspan="1" rowspan="1">127</td>
</tr>
<tr>
<td colspan="2" align="left" rowspan="1">average</td>
<td align="right" colspan="1" rowspan="1">35</td>
<td align="right" colspan="1" rowspan="1">1172</td>
<td align="right" colspan="1" rowspan="1">948</td>
<td align="right" colspan="1" rowspan="1">117</td>
<td align="right" colspan="1" rowspan="1">118</td>
</tr>
<tr>
<td colspan="2" align="left" rowspan="1">average (not ISE)</td>
<td align="right" colspan="1" rowspan="1">36</td>
<td align="right" colspan="1" rowspan="1">1200</td>
<td align="right" colspan="1" rowspan="1">999</td>
<td align="right" colspan="1" rowspan="1">110</td>
<td align="right" colspan="1" rowspan="1">104</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.1-3">The average delay from first draft to p
ublication is about 3 years and 3 months, but this
varies widely. Excluding the RFCs from the Independent Stream, the average
delay from start to finish is 3 years and 4 months, of which on average delay from start to finish is 3 years and 4 months, of which on average
2 years and 9 months are spent getting consensus in the Working Group, 2 years and 9 months are spent getting consensus in the working group,
and 3 to 4 months each for IETF consensus and for RFC production.</t> and 3 to 4 months each for IETF consensus and for RFC production.</t>
<t indent="0" pn="section-4.1-4">The longest delay is found for <xref ta
<t>The longest delay is found for <xref target="RFC8492"/>, 6.5 years from start rget="RFC8492" format="default" sectionFormat="of" derivedContent="RFC8492"/>, 6
to finish. .5 years from start to finish.
This is however a very special case, a draft that was prepared for This is however a very special case -- a draft that was prepared for
the TLS Working Group and failed to reach consensus. After that, it was the TLS Working Group and failed to reach consensus. After that, it was
resubmitted to the ISE, and incurred atypical production delays.</t> resubmitted to the ISE, and incurred atypical production delays.</t>
<t indent="0" pn="section-4.1-5">On average, we see that 80% of the dela
<t>On average, we see that 80% of the delay is incurred in WG processing, y is incurred in WG processing,
10% in IETF review, and 10% for edition and publication.</t> 10% in IETF review, and 10% for edition and publication.</t>
<t indent="0" pn="section-4.1-6">For IETF Stream RFCs, it appears that t
<t>For IETF stream RFCs, it appears that the delays for informational documents he delays for Informational documents
are slightly shorter than those for protocol specifications, maybe six months are slightly shorter than those for protocol specifications, maybe six months
shorter on average. However, there are lots of differences between shorter on average. However, there are lots of differences between
individual documents. The delays range from less than a year to more than 5 year s for individual documents. The delays range from less than a year to more than 5 year s for
protocol specifications, and from a year and 3 months to a bit more than 4 years for protocol specifications, and from a year and 3 months to a bit more than 4 years for
informational documents.</t> Informational documents.</t>
<t indent="0" pn="section-4.1-7">We can compare the delays in the 2018 s
<t>We can compare the delays in the 2018 samples to those observed 10 years ago amples to those observed 10 years ago and 20 years
and 20 years
before:</t> before:</t>
<table align="center" pn="table-2">
<texttable> <thead>
<ttcol align='left'>RFC (2008)</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="left" colspan="1" rowspan="1">RFC (2008)</th>
<ttcol align='right'>Pages</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>Delay</ttcol> <th align="right" colspan="1" rowspan="1">Pages</th>
<c>5326</c> <th align="right" colspan="1" rowspan="1">Delay</th>
<c>Exp</c> </tr>
<c>54</c> </thead>
<c>1584</c> <tbody>
<c>5348</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5326</td>
<c>58</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>823</c> <td align="right" colspan="1" rowspan="1">54</td>
<c>5281</c> <td align="right" colspan="1" rowspan="1">1584</td>
<c>Info</c> </tr>
<c>51</c> <tr>
<c>1308</c> <td align="left" colspan="1" rowspan="1">5348</td>
<c>5354</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>Exp</c> <td align="right" colspan="1" rowspan="1">58</td>
<c>23</c> <td align="right" colspan="1" rowspan="1">823</td>
<c>2315</c> </tr>
<c>5227</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5281</td>
<c>21</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>2434</c> <td align="right" colspan="1" rowspan="1">51</td>
<c>5329</c> <td align="right" colspan="1" rowspan="1">1308</td>
<c>PS</c> </tr>
<c>12</c> <tr>
<c>1980</c> <td align="left" colspan="1" rowspan="1">5354</td>
<c>5277</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">23</td>
<c>35</c> <td align="right" colspan="1" rowspan="1">2315</td>
<c>912</c> </tr>
<c>5236</c> <tr>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">5227</td>
<c>26</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>1947</c> <td align="right" colspan="1" rowspan="1">21</td>
<c>5358</c> <td align="right" colspan="1" rowspan="1">2434</td>
<c>BCP</c> </tr>
<c>7</c> <tr>
<c>884</c> <td align="left" colspan="1" rowspan="1">5329</td>
<c>5271</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">12</td>
<c>22</c> <td align="right" colspan="1" rowspan="1">1980</td>
<c>1066</c> </tr>
<c>5195</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5277</td>
<c>10</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>974</c> <td align="right" colspan="1" rowspan="1">35</td>
<c>5283</c> <td align="right" colspan="1" rowspan="1">912</td>
<c>PS</c> </tr>
<c>12</c> <tr>
<c>1096</c> <td align="left" colspan="1" rowspan="1">5236</td>
<c>5186</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">26</td>
<c>6</c> <td align="right" colspan="1" rowspan="1">1947</td>
<c>2253</c> </tr>
<c>5142</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5358</td>
<c>13</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>1005</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>5373</c> <td align="right" colspan="1" rowspan="1">884</td>
<c>PS</c> </tr>
<c>24</c> <tr>
<c>1249</c> <td align="left" colspan="1" rowspan="1">5271</td>
<c>5404</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">22</td>
<c>27</c> <td align="right" colspan="1" rowspan="1">1066</td>
<c>214</c> </tr>
<c>5172</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5195</td>
<c>7</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>305</c> <td align="right" colspan="1" rowspan="1">10</td>
<c>5349</c> <td align="right" colspan="1" rowspan="1">974</td>
<c>Info</c> </tr>
<c>10</c> <tr>
<c>1096</c> <td align="left" colspan="1" rowspan="1">5283</td>
<c>5301</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">12</td>
<c>6</c> <td align="right" colspan="1" rowspan="1">1096</td>
<c>396</c> </tr>
<c>5174</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">5186</td>
<c>8</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>427</c> <td align="right" colspan="1" rowspan="1">6</td>
</texttable> <td align="right" colspan="1" rowspan="1">2253</td>
</tr>
<texttable> <tr>
<ttcol align='left'>RFC (1998)</ttcol> <td align="left" colspan="1" rowspan="1">5142</td>
<ttcol align='left'>Status</ttcol> <td align="left" colspan="1" rowspan="1">PS</td>
<ttcol align='right'>Pages</ttcol> <td align="right" colspan="1" rowspan="1">13</td>
<ttcol align='right'>Delay</ttcol> <td align="right" colspan="1" rowspan="1">1005</td>
<c>2289</c> </tr>
<c>PS</c> <tr>
<c>25</c> <td align="left" colspan="1" rowspan="1">5373</td>
<c>396</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2267</c> <td align="right" colspan="1" rowspan="1">24</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">1249</td>
<c>10</c> </tr>
<c>unknown</c> <tr>
<c>2317</c> <td align="left" colspan="1" rowspan="1">5404</td>
<c>BCP</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>10</c> <td align="right" colspan="1" rowspan="1">27</td>
<c>485</c> <td align="right" colspan="1" rowspan="1">214</td>
<c>2404</c> </tr>
<c>PS</c> <tr>
<c>7</c> <td align="left" colspan="1" rowspan="1">5172</td>
<c>488</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2374</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">305</td>
<c>12</c> </tr>
<c>289</c> <tr>
<c>2449</c> <td align="left" colspan="1" rowspan="1">5349</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>19</c> <td align="right" colspan="1" rowspan="1">10</td>
<c>273</c> <td align="right" colspan="1" rowspan="1">1096</td>
<c>2283</c> </tr>
<c>PS</c> <tr>
<c>9</c> <td align="left" colspan="1" rowspan="1">5301</td>
<c>153</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2394</c> <td align="right" colspan="1" rowspan="1">6</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">396</td>
<c>6</c> </tr>
<c>365</c> <tr>
<c>2348</c> <td align="left" colspan="1" rowspan="1">5174</td>
<c>DS</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>5</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>699</c> <td align="right" colspan="1" rowspan="1">427</td>
<c>2382</c> </tr>
<c>Info</c> </tbody>
<c>30</c> </table>
<c>396</c> <table align="center" pn="table-3">
<c>2297</c> <thead>
<c>ISE</c> <tr>
<c>109</c> <th align="left" colspan="1" rowspan="1">RFC (1998)</th>
<c>28</c> <th align="left" colspan="1" rowspan="1">Status</th>
<c>2381</c> <th align="right" colspan="1" rowspan="1">Pages</th>
<c>PS</c> <th align="right" colspan="1" rowspan="1">Delay</th>
<c>43</c> </tr>
<c>699</c> </thead>
<c>2312</c> <tbody>
<c>Info</c> <tr>
<c>20</c> <td align="left" colspan="1" rowspan="1">2289</td>
<c>365</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2387</c> <td align="right" colspan="1" rowspan="1">25</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">396</td>
<c>10</c> </tr>
<c>122</c> <tr>
<c>2398</c> <td align="left" colspan="1" rowspan="1">2267</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>15</c> <td align="right" colspan="1" rowspan="1">10</td>
<c>396</c> <td align="right" colspan="1" rowspan="1">unknown</td>
<c>2391</c> </tr>
<c>PS</c> <tr>
<c>10</c> <td align="left" colspan="1" rowspan="1">2317</td>
<c>122</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>2431</c> <td align="right" colspan="1" rowspan="1">10</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">485</td>
<c>10</c> </tr>
<c>457</c> <tr>
<c>2282</c> <td align="left" colspan="1" rowspan="1">2404</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>14</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>215</c> <td align="right" colspan="1" rowspan="1">488</td>
<c>2323</c> </tr>
<c>ISE</c> <tr>
<c>5</c> <td align="left" colspan="1" rowspan="1">2374</td>
<c>unknown</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2448</c> <td align="right" colspan="1" rowspan="1">12</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">289</td>
<c>7</c> </tr>
<c>92</c> <tr>
</texttable> <td align="left" colspan="1" rowspan="1">2449</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<t>We can compare the median delay, and the delays observed by the fastest and <td align="right" colspan="1" rowspan="1">19</td>
<td align="right" colspan="1" rowspan="1">273</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2283</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">9</td>
<td align="right" colspan="1" rowspan="1">153</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2394</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">6</td>
<td align="right" colspan="1" rowspan="1">365</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2348</td>
<td align="left" colspan="1" rowspan="1">DS</td>
<td align="right" colspan="1" rowspan="1">5</td>
<td align="right" colspan="1" rowspan="1">699</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2382</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">30</td>
<td align="right" colspan="1" rowspan="1">396</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2297</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">109</td>
<td align="right" colspan="1" rowspan="1">28</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2381</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">43</td>
<td align="right" colspan="1" rowspan="1">699</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2312</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">20</td>
<td align="right" colspan="1" rowspan="1">365</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2387</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">10</td>
<td align="right" colspan="1" rowspan="1">122</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2398</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">15</td>
<td align="right" colspan="1" rowspan="1">396</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2391</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">10</td>
<td align="right" colspan="1" rowspan="1">122</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2431</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">10</td>
<td align="right" colspan="1" rowspan="1">457</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2282</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">14</td>
<td align="right" colspan="1" rowspan="1">215</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2323</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">5</td>
<td align="right" colspan="1" rowspan="1">unknown</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2448</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">7</td>
<td align="right" colspan="1" rowspan="1">92</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.1-10">We can compare the median delay, and t
he delays observed by the fastest and
slowest quartiles in the three years:</t> slowest quartiles in the three years:</t>
<table align="center" pn="table-4">
<texttable> <thead>
<ttcol align='left'>Year</ttcol> <tr>
<ttcol align='right'>Fastest 25%</ttcol> <th align="left" colspan="1" rowspan="1">Year</th>
<ttcol align='right'>Median</ttcol> <th align="right" colspan="1" rowspan="1">Fastest 25%</th>
<ttcol align='right'>Slowest 25%</ttcol> <th align="right" colspan="1" rowspan="1">Median</th>
<c>2018</c> <th align="right" colspan="1" rowspan="1">Slowest 25%</th>
<c>604</c> </tr>
<c>1179</c> </thead>
<c>1522</c> <tbody>
<c>2008</c> <tr>
<c>869</c> <td align="left" colspan="1" rowspan="1">2018</td>
<c>1081</c> <td align="right" colspan="1" rowspan="1">715</td>
<c>1675</c> <td align="right" colspan="1" rowspan="1">1221</td>
<c>1998</c> <td align="right" colspan="1" rowspan="1">1537</td>
<c>169</c> </tr>
<c>365</c> <tr>
<c>442</c> <td align="left" colspan="1" rowspan="1">2008</td>
</texttable> <td align="right" colspan="1" rowspan="1">869</td>
<td align="right" colspan="1" rowspan="1">1081</td>
<t>The IETF takes three to four times more times to produce an RFC in 2018 <td align="right" colspan="1" rowspan="1">1675</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">1998</td>
<td align="right" colspan="1" rowspan="1">169</td>
<td align="right" colspan="1" rowspan="1">365</td>
<td align="right" colspan="1" rowspan="1">442</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.1-12">The IETF takes three to four times mor
e to produce an RFC in 2018
than it did in 1998, but about the same time as it did in 2008. than it did in 1998, but about the same time as it did in 2008.
We can get a rough estimate of how this translates in term of We can get a rough estimate of how this translates in terms of
"level of attention" per RFC by comparing the number of participants "level of attention" per RFC by comparing the number of participants
in the IETF meetings of 2018, 2008 and 1998 <xref target="IETFCOUNT"/> to the nu in the IETF meetings of 2018, 2008, and 1998 <xref target="IETFCOUNT" format="de
mber of RFC fault" sectionFormat="of" derivedContent="IETFCOUNT"/> to the number of RFCs
published these years <xref target="RFCYEAR"/>.</t> published these years <xref target="RFCYEAR" format="default" sectionFormat="of"
derivedContent="RFCYEAR"/>.</t>
<texttable> <table align="center" pn="table-5">
<ttcol align='left'>Year</ttcol> <thead>
<ttcol align='right'>Nb RFC</ttcol> <tr>
<ttcol align='right'>Spring P.</ttcol> <th align="left" colspan="1" rowspan="1">Year</th>
<ttcol align='right'>Summer P.</ttcol> <th align="left" colspan="1" rowspan="1">Number of RFCs</th>
<ttcol align='right'>Fall</ttcol> <th align="right" colspan="1" rowspan="1">Spring P.</th>
<ttcol align='right'>Average P.</ttcol> <th align="right" colspan="1" rowspan="1">Summer P.</th>
<ttcol align='left'>Attendees/RFC</ttcol> <th align="right" colspan="1" rowspan="1">Fall P.</th>
<c>2018</c> <th align="right" colspan="1" rowspan="1">Average P.</th>
<c>208</c> <th align="left" colspan="1" rowspan="1">Attendees/RFC</th>
<c>1235</c> </tr>
<c>1078</c> </thead>
<c>879</c> <tbody>
<c>1064</c> <tr>
<c>5.1</c> <td align="left" colspan="1" rowspan="1">2018</td>
<c>2008</c> <td align="right" colspan="1" rowspan="1">208</td>
<c>290</c> <td align="right" colspan="1" rowspan="1">1235</td>
<c>1128</c> <td align="right" colspan="1" rowspan="1">1078</td>
<c>1181</c> <td align="right" colspan="1" rowspan="1">879</td>
<c>962</c> <td align="right" colspan="1" rowspan="1">1064</td>
<c>1090</c> <td align="left" colspan="1" rowspan="1">5.1</td>
<c>3.8</c> </tr>
<c>1998</c> <tr>
<c>234</c> <td align="left" colspan="1" rowspan="1">2008</td>
<c>1775</c> <td align="right" colspan="1" rowspan="1">290</td>
<c>2106</c> <td align="right" colspan="1" rowspan="1">1128</td>
<c>1705</c> <td align="right" colspan="1" rowspan="1">1181</td>
<c>1862</c> <td align="right" colspan="1" rowspan="1">962</td>
<c>9.0</c> <td align="right" colspan="1" rowspan="1">1090</td>
</texttable> <td align="left" colspan="1" rowspan="1">3.8</td>
</tr>
<t>The last column in the table provides the ratio of average number <tr>
of participants by number of RFC produced. If the IETF was a centralized <td align="left" colspan="1" rowspan="1">1998</td>
organization, if all participants and documents were equivalent, this <td align="right" colspan="1" rowspan="1">234</td>
<td align="right" colspan="1" rowspan="1">1775</td>
<td align="right" colspan="1" rowspan="1">2106</td>
<td align="right" colspan="1" rowspan="1">1705</td>
<td align="right" colspan="1" rowspan="1">1862</td>
<td align="left" colspan="1" rowspan="1">8.0</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.1-14">The last column in the table provides
the ratio of average number
of participants to the number of RFCs published. If the IETF were a centralized
organization, and if all participants and documents were equivalent, this
ratio would be the number of participants dedicated to produce an RFC ratio would be the number of participants dedicated to produce an RFC
on a given year. This is of course a completely abstract figure because on a given year. This is of course a completely abstract figure because
none of the hypotheses above is true, but it still gives a vague none of the hypotheses above are true, but it still gives a vague
indication of the "level of attention" applied to documents. We see indication of the "level of attention" applied to documents. We see
that this ratio has increased from 2008 to 2018, as the number of that this ratio has increased from 2008 to 2018, as the number of
participants was about the same for these two years but the number of participants was about the same for these two years but the number of
published RFCs decreased. However, that ratio was much higher in 1998. published RFCs decreased. However, this ratio was much higher in 1998.
The IETF had many more participants, and there were probably The IETF had many more participants, and there were probably
many more eyes available to review any given draft. If we applied the many more eyes available to review any given draft. If we applied the
ratios of 1998, the IETF would be producing 119 documents in 2018 ratios of 1998, the IETF would be producing 119 documents in 2018
instead of 208.</t> instead of 208.</t>
</section>
</section> <section anchor="working-group-processing-time" numbered="true" toc="inclu
<section anchor="working-group-processing-time" title="Working Group Processing de" removeInRFC="false" pn="section-4.2">
Time"> <name slugifiedName="name-working-group-processing-ti">Working Group Pro
cessing Time</name>
<t>The largest part of the delays is spent in the Working Groups, before <t indent="0" pn="section-4.2-1">The largest part of the delays is spent
in the working groups, before
the draft is submitted to the IESG for IETF review. As mentioned in the draft is submitted to the IESG for IETF review. As mentioned in
<xref target="milestones"/>, the only intermediate milestone that we can extract <xref target="milestones" format="default" sectionFormat="of" derivedContent="Se
from the IETF datatracker is the date at which the document was ction 2.1"/>, the only intermediate milestone that we can extract
adopted by the Working Group, or targeted for independent submission. from the IETF Datatracker is the date at which the document was
adopted by the working group, or targeted for independent submission.
The breakdown of the delays for the documents in our sample is:</t> The breakdown of the delays for the documents in our sample is:</t>
<table align="center" pn="table-6">
<texttable> <thead>
<ttcol align='left'>RFC</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="left" colspan="1" rowspan="1">RFC</th>
<ttcol align='right'>WG</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>Until adoption</ttcol> <th align="right" colspan="1" rowspan="1">WG</th>
<ttcol align='right'>After adoption</ttcol> <th align="right" colspan="1" rowspan="1">Until adoption</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">After adoption</th>
<c>Info</c> </tr>
<c>154</c> </thead>
<c>0</c> <tbody>
<c>154</c> <tr>
<c>8456</c> <td align="left" colspan="1" rowspan="1">8411</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>1033</c> <td align="right" colspan="1" rowspan="1">154</td>
<c>209</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>824</c> <td align="right" colspan="1" rowspan="1">154</td>
<c>8446</c> </tr>
<c>PS</c> <tr>
<c>1400</c> <td align="left" colspan="1" rowspan="1">8456</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>1400</c> <td align="right" colspan="1" rowspan="1">1033</td>
<c>8355</c> <td align="right" colspan="1" rowspan="1">209</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">824</td>
<c>1175</c> </tr>
<c>102</c> <tr>
<c>1073</c> <td align="left" colspan="1" rowspan="1">8446</td>
<c>8441</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">1400</td>
<c>204</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>65</c> <td align="right" colspan="1" rowspan="1">1400</td>
<c>139</c> </tr>
<c>8324</c> <tr>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">8355</td>
<c>38</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">1175</td>
<c>38</c> <td align="right" colspan="1" rowspan="1">102</td>
<c>8377</c> <td align="right" colspan="1" rowspan="1">1073</td>
<c>PS</c> </tr>
<c>1630</c> <tr>
<c>728</c> <td align="left" colspan="1" rowspan="1">8441</td>
<c>902</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>8498</c> <td align="right" colspan="1" rowspan="1">204</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">65</td>
<c>935</c> <td align="right" colspan="1" rowspan="1">139</td>
<c>420</c> </tr>
<c>515</c> <tr>
<c>8479</c> <td align="left" colspan="1" rowspan="1">8324</td>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>233</c> <td align="right" colspan="1" rowspan="1">38</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>233</c> <td align="right" colspan="1" rowspan="1">38</td>
<c>8453</c> </tr>
<c>Info</c> <tr>
<c>1036</c> <td align="left" colspan="1" rowspan="1">8377</td>
<c>396</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>640</c> <td align="right" colspan="1" rowspan="1">1630</td>
<c>8429</c> <td align="right" colspan="1" rowspan="1">728</td>
<c>BCP</c> <td align="right" colspan="1" rowspan="1">902</td>
<c>76</c> </tr>
<c>0</c> <tr>
<c>76</c> <td align="left" colspan="1" rowspan="1">8498</td>
<c>8312</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">935</td>
<c>1113</c> <td align="right" colspan="1" rowspan="1">420</td>
<c>280</c> <td align="right" colspan="1" rowspan="1">515</td>
<c>833</c> </tr>
<c>8492</c> <tr>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">8479</td>
<c>1706</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>1428</c> <td align="right" colspan="1" rowspan="1">233</td>
<c>278</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8378</c> <td align="right" colspan="1" rowspan="1">233</td>
<c>Exp</c> </tr>
<c>1446</c> <tr>
<c>661</c> <td align="left" colspan="1" rowspan="1">8453</td>
<c>785</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>8361</c> <td align="right" colspan="1" rowspan="1">1036</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">396</td>
<c>1477</c> <td align="right" colspan="1" rowspan="1">640</td>
<c>399</c> </tr>
<c>1078</c> <tr>
<c>8472</c> <td align="left" colspan="1" rowspan="1">8429</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>899</c> <td align="right" colspan="1" rowspan="1">76</td>
<c>105</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>794</c> <td align="right" colspan="1" rowspan="1">76</td>
<c>8471</c> </tr>
<c>PS</c> <tr>
<c>1127</c> <td align="left" colspan="1" rowspan="1">8312</td>
<c>153</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>794</c> <td align="right" colspan="1" rowspan="1">1113</td>
<c>8466</c> <td align="right" colspan="1" rowspan="1">280</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">833</td>
<c>538</c> </tr>
<c>178</c> <tr>
<c>360</c> <td align="left" colspan="1" rowspan="1">8492</td>
<c>8362</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">1706</td>
<c>1766</c> <td align="right" colspan="1" rowspan="1">1428</td>
<c>240</c> <td align="right" colspan="1" rowspan="1">278</td>
<c>1526</c> </tr>
<c>8468</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8378</td>
<c>979</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>333</c> <td align="right" colspan="1" rowspan="1">1446</td>
<c>646</c> <td align="right" colspan="1" rowspan="1">661</td>
<c>&#160;</c> <td align="right" colspan="1" rowspan="1">785</td>
<c>Average</c> </tr>
<c>948</c> <tr>
<c>285</c> <td align="left" colspan="1" rowspan="1">8361</td>
<c>663</c> <td align="left" colspan="1" rowspan="1">PS</td>
</texttable> <td align="right" colspan="1" rowspan="1">1477</td>
<td align="right" colspan="1" rowspan="1">399</td>
<t>The time before Working Group adoption average to a bit more than 9 months, <td align="right" colspan="1" rowspan="1">1078</td>
compared to 1 years and almost 10 months for processing time after adoption. </tr>
<tr>
<td align="left" colspan="1" rowspan="1">8472</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">899</td>
<td align="right" colspan="1" rowspan="1">105</td>
<td align="right" colspan="1" rowspan="1">794</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8471</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1127</td>
<td align="right" colspan="1" rowspan="1">153</td>
<td align="right" colspan="1" rowspan="1">794</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">538</td>
<td align="right" colspan="1" rowspan="1">178</td>
<td align="right" colspan="1" rowspan="1">360</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1766</td>
<td align="right" colspan="1" rowspan="1">240</td>
<td align="right" colspan="1" rowspan="1">1526</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">979</td>
<td align="right" colspan="1" rowspan="1">333</td>
<td align="right" colspan="1" rowspan="1">646</td>
</tr>
<tr>
<td align="left" colspan="2" rowspan="1">Average</td>
<td align="right" colspan="1" rowspan="1">948</td>
<td align="right" colspan="1" rowspan="1">285</td>
<td align="right" colspan="1" rowspan="1">663</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.2-3">The time before working group adoption
averages to a bit more than 9 months,
compared to 1 year and almost 10 months for processing time after adoption.
We see that RFC 8492 stands out, with long delays spent attempting publication t hrough We see that RFC 8492 stands out, with long delays spent attempting publication t hrough
a Working Group before submission to the Independent Stream Editor. If we remove d RFC a working group before submission to the Independent Submissions Editor. If we r emove RFC
8492 from the list, the average time until adoption drops to just over 7 months, 8492 from the list, the average time until adoption drops to just over 7 months,
and becomes just 25% of the total processing time in the WG.</t> and becomes just 25% of the total processing time in the WG.</t>
<t indent="0" pn="section-4.2-4">There are a few
<t>There are a few documents that started immediately as working group efforts, or were immediately
documents that started immediately as Working Group efforts, or were immediately targeted
targeted
for publication in the Independent Stream. Those documents tend to see short pro cessing times, for publication in the Independent Stream. Those documents tend to see short pro cessing times,
with the exception of RFC 8446 on which the TLS Working Group spent a long time working.</t> with the exception of RFC 8446 on which the TLS Working Group spent a long time working.</t>
</section>
</section> <section anchor="preparation-and-publication-delays" numbered="true" toc="
<section anchor="preparation-and-publication-delays" title="Preparation and Publ include" removeInRFC="false" pn="section-4.3">
ication Delays"> <name slugifiedName="name-preparation-and-publication">Preparation and P
ublication Delays</name>
<t>The preparation and publication delays include three components:</t> <t indent="0" pn="section-4.3-1">The preparation and publication delays
include three components:</t>
<t><list style="symbols"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
<t>the delay from submission to the RFC Editor to beginning of AUTH-48, during .3-2">
which the document is prepared;</t> <li pn="section-4.3-2.1">the delay from submission to the RFC Editor t
<t>the AUTH-48 delay, during which authors review and eventually approve the o beginning of AUTH48, during
changes proposed by the editors;</t> which the document is prepared (referred to as "RFC edit" below);</li>
<t>the publication delay, from final agreement by authors and editors to <li pn="section-4.3-2.2">the AUTH48 delay, during which authors review
actual publication.</t> and eventually approve the
</list></t> changes proposed by the editors (referred to as "AUTH48" below);</li>
<li pn="section-4.3-2.3">the publication delay, from final agreement b
<t>The breakdown of the publication delays for each RFC is shown in the y authors and editors to
actual publication (referred to as "RFC Pub" below).</li>
</ul>
<t indent="0" pn="section-4.3-3">The breakdown of the publication delays
for each RFC is shown in the
following table.</t> following table.</t>
<table align="center" pn="table-7">
<texttable> <thead>
<ttcol align='right'>RFC</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="right" colspan="1" rowspan="1">RFC</th>
<ttcol align='right'>Pages</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>RFC edit</ttcol> <th align="right" colspan="1" rowspan="1">Pages</th>
<ttcol align='right'>AUTH-48</ttcol> <th align="right" colspan="1" rowspan="1">RFC edit</th>
<ttcol align='right'>RFC Pub</ttcol> <th align="right" colspan="1" rowspan="1">AUTH48</th>
<ttcol align='right'>Edit(total)</ttcol> <th align="right" colspan="1" rowspan="1">RFC Pub</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">Edit (total)</th>
<c>Info</c> </tr>
<c>5</c> </thead>
<c>53</c> <tbody>
<c>88</c> <tr>
<c>20</c> <td align="right" colspan="1" rowspan="1">8411</td>
<c>161</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>8456</c> <td align="right" colspan="1" rowspan="1">5</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">53</td>
<c>64</c> <td align="right" colspan="1" rowspan="1">88</td>
<c>98</c> <td align="right" colspan="1" rowspan="1">20</td>
<c>46</c> <td align="right" colspan="1" rowspan="1">161</td>
<c>14</c> </tr>
<c>158</c> <tr>
<c>8446</c> <td align="right" colspan="1" rowspan="1">8456</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>160</c> <td align="right" colspan="1" rowspan="1">64</td>
<c>85</c> <td align="right" colspan="1" rowspan="1">98</td>
<c>57</c> <td align="right" colspan="1" rowspan="1">46</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">14</td>
<c>142</c> <td align="right" colspan="1" rowspan="1">158</td>
<c>8355</c> </tr>
<c>Info</c> <tr>
<c>13</c> <td align="right" colspan="1" rowspan="1">8446</td>
<c>83</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>15</c> <td align="right" colspan="1" rowspan="1">160</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">85</td>
<c>99</c> <td align="right" colspan="1" rowspan="1">57</td>
<c>8441</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">142</td>
<c>8</c> </tr>
<c>67</c> <tr>
<c>33</c> <td align="right" colspan="1" rowspan="1">8355</td>
<c>6</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>106</c> <td align="right" colspan="1" rowspan="1">13</td>
<c>8324</c> <td align="right" colspan="1" rowspan="1">83</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">15</td>
<c>29</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>42</c> <td align="right" colspan="1" rowspan="1">99</td>
<c>28</c> </tr>
<c>1</c> <tr>
<c>71</c> <td align="right" colspan="1" rowspan="1">8441</td>
<c>8377</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">56</td>
<c>39</c> <td align="right" colspan="1" rowspan="1">33</td>
<c>102</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">92</td>
<c>141</c> </tr>
<c>8498</c> <tr>
<c>Info</c> <td align="right" colspan="1" rowspan="1">8324</td>
<c>15</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>49</c> <td align="right" colspan="1" rowspan="1">29</td>
<c>16</c> <td align="right" colspan="1" rowspan="1">42</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">28</td>
<c>67</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8479</c> <td align="right" colspan="1" rowspan="1">71</td>
<c>ISE</c> </tr>
<c>8</c> <tr>
<c>31</c> <td align="right" colspan="1" rowspan="1">8377</td>
<c>5</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>37</c> <td align="right" colspan="1" rowspan="1">39</td>
<c>8453</c> <td align="right" colspan="1" rowspan="1">102</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>42</c> <td align="right" colspan="1" rowspan="1">141</td>
<c>73</c> </tr>
<c>7</c> <tr>
<c>0</c> <td align="right" colspan="1" rowspan="1">8498</td>
<c>80</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>8429</c> <td align="right" colspan="1" rowspan="1">15</td>
<c>BCP</c> <td align="right" colspan="1" rowspan="1">48</td>
<c>10</c> <td align="right" colspan="1" rowspan="1">16</td>
<c>60</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>99</c> <td align="right" colspan="1" rowspan="1">65</td>
<c>0</c> </tr>
<c>159</c> <tr>
<c>8312</c> <td align="right" colspan="1" rowspan="1">8479</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>18</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>96</c> <td align="right" colspan="1" rowspan="1">31</td>
<c>30</c> <td align="right" colspan="1" rowspan="1">5</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>126</c> <td align="right" colspan="1" rowspan="1">37</td>
<c>8492</c> </tr>
<c>ISE</c> <tr>
<c>40</c> <td align="right" colspan="1" rowspan="1">8453</td>
<c>355</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>123</c> <td align="right" colspan="1" rowspan="1">42</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">73</td>
<c>480</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>8378</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>Exp</c> <td align="right" colspan="1" rowspan="1">83</td>
<c>21</c> </tr>
<c>42</c> <tr>
<c>9</c> <td align="right" colspan="1" rowspan="1">8429</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>51</c> <td align="right" colspan="1" rowspan="1">10</td>
<c>8361</c> <td align="right" colspan="1" rowspan="1">60</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">99</td>
<c>17</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>39</c> <td align="right" colspan="1" rowspan="1">159</td>
<c>31</c> </tr>
<c>3</c> <tr>
<c>73</c> <td align="right" colspan="1" rowspan="1">8312</td>
<c>8472</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">18</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">55</td>
<c>59</c> <td align="right" colspan="1" rowspan="1">28</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>13</c> <td align="right" colspan="1" rowspan="1">85</td>
<c>80</c> </tr>
<c>8471</c> <tr>
<c>PS</c> <td align="right" colspan="1" rowspan="1">8492</td>
<c>18</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>59</c> <td align="right" colspan="1" rowspan="1">40</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">355</td>
<c>13</c> <td align="right" colspan="1" rowspan="1">123</td>
<c>80</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>8466</c> <td align="right" colspan="1" rowspan="1">480</td>
<c>PS</c> </tr>
<c>158</c> <tr>
<c>84</c> <td align="right" colspan="1" rowspan="1">8378</td>
<c>22</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">21</td>
<c>109</c> <td align="right" colspan="1" rowspan="1">42</td>
<c>8362</c> <td align="right" colspan="1" rowspan="1">9</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>33</c> <td align="right" colspan="1" rowspan="1">51</td>
<c>49</c> </tr>
<c>11</c> <tr>
<c>4</c> <td align="right" colspan="1" rowspan="1">8361</td>
<c>64</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>8468</c> <td align="right" colspan="1" rowspan="1">17</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">39</td>
<c>15</c> <td align="right" colspan="1" rowspan="1">31</td>
<c>65</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>53</c> <td align="right" colspan="1" rowspan="1">73</td>
<c>9</c> </tr>
<c>127</c> <tr>
<c>&#160;</c> <td align="right" colspan="1" rowspan="1">8472</td>
<c>Average</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>&#160;</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>76</c> <td align="right" colspan="1" rowspan="1">59</td>
<c>40</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>5</c> <td align="right" colspan="1" rowspan="1">13</td>
<c>121</c> <td align="right" colspan="1" rowspan="1">80</td>
<c>-8492</c> </tr>
<c>Average</c> <tr>
<c>&#160;</c> <td align="right" colspan="1" rowspan="1">8471</td>
<c>62</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>35</c> <td align="right" colspan="1" rowspan="1">18</td>
<c>5</c> <td align="right" colspan="1" rowspan="1">59</td>
<c>102</c> <td align="right" colspan="1" rowspan="1">8</td>
</texttable> <td align="right" colspan="1" rowspan="1">13</td>
<td align="right" colspan="1" rowspan="1">80</td>
<t>On average, the total delay appears to be about four months, but the </tr>
average is skewed by the extreme values encountered for <xref target="RFC8492"/> <tr>
. If we <td align="right" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">158</td>
<td align="right" colspan="1" rowspan="1">84</td>
<td align="right" colspan="1" rowspan="1">22</td>
<td align="right" colspan="1" rowspan="1">3</td>
<td align="right" colspan="1" rowspan="1">109</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">33</td>
<td align="right" colspan="1" rowspan="1">49</td>
<td align="right" colspan="1" rowspan="1">11</td>
<td align="right" colspan="1" rowspan="1">4</td>
<td align="right" colspan="1" rowspan="1">64</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">15</td>
<td align="right" colspan="1" rowspan="1">65</td>
<td align="right" colspan="1" rowspan="1">53</td>
<td align="right" colspan="1" rowspan="1">9</td>
<td align="right" colspan="1" rowspan="1">127</td>
</tr>
<tr>
<td colspan="2" align="left" rowspan="1">Average</td>
<td align="right" colspan="1" rowspan="1"/>
<td align="right" colspan="1" rowspan="1">74</td>
<td align="right" colspan="1" rowspan="1">39</td>
<td align="right" colspan="1" rowspan="1">5</td>
<td align="right" colspan="1" rowspan="1">118</td>
</tr>
<tr>
<td colspan="2" align="left" rowspan="1">Average (without 8492)</t
d>
<td align="right" colspan="1" rowspan="1"/>
<td align="right" colspan="1" rowspan="1">59</td>
<td align="right" colspan="1" rowspan="1">35</td>
<td align="right" colspan="1" rowspan="1">5</td>
<td align="right" colspan="1" rowspan="1">99</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.3-5">On average, the total delay appears to
be about four months, but the
average is skewed by the extreme values encountered for <xref target="RFC8492" f
ormat="default" sectionFormat="of" derivedContent="RFC8492"/>. If we
exclude that RFC from the computations, the average delay drops to a just a bit exclude that RFC from the computations, the average delay drops to a just a bit
more than 3 months: about 2 months for the preparation, a bit more than one more than 3 months: about 2 months for the preparation, a bit more than one
month for the AUTH-48 phase, and 5 days for the publishing.</t> month for the AUTH48 phase, and 5 days for the publishing.</t>
<t indent="0" pn="section-4.3-6">Of course, these delays vary from RFC t
<t>Of course, these delays vary from RFC to RFC. To try explain the causes of th o RFC. To try explain the causes of the
e
delay, we compute the correlation factor between the observed delays and several delay, we compute the correlation factor between the observed delays and several
plausible explanation factors:</t> plausible explanation factors:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
<t><list style="symbols"> .3-7">
<t>The number of pages in the document,</t> <li pn="section-4.3-7.1">the number of pages in the document,</li>
<t>The amount of copy edit, as discussed in <xref target="copy-editing"/>,</t> <li pn="section-4.3-7.2">the amount of copy editing, as discussed in <
<t>Whether or not an IANA action was required,</t> xref target="copy-editing" format="default" sectionFormat="of" derivedContent="S
<t>The number of authors,</t> ection 4.4"/>,</li>
<t>The number of drafts revisions,</t> <li pn="section-4.3-7.3">whether or not IANA actions were required,</l
<t>The Working Group delay.</t> i>
</list></t> <li pn="section-4.3-7.4">the number of authors,</li>
<li pn="section-4.3-7.5">the number of draft revisions,</li>
<t>We find the following values:</t> <li pn="section-4.3-7.6">the working group delay.</li>
</ul>
<texttable> <t indent="0" pn="section-4.3-8">We find the following values:</t>
<ttcol align='left'>Correlation</ttcol> <table align="center" pn="table-8">
<ttcol align='right'>RFC edit</ttcol> <thead>
<ttcol align='right'>AUTH-48</ttcol> <tr>
<ttcol align='right'>Edit(total)</ttcol> <th align="left" colspan="1" rowspan="1">Correlation</th>
<c>Nb pages</c> <th align="right" colspan="1" rowspan="1">RFC edit</th>
<c>0.50</c> <th align="right" colspan="1" rowspan="1">AUTH48</th>
<c>-0.04</c> <th align="right" colspan="1" rowspan="1">Edit(total)</th>
<c>0.21</c> </tr>
<c>Copy-Edit</c> </thead>
<c>0.42</c> <tbody>
<c>0.24</c> <tr>
<c>0.45</c> <td align="left" colspan="1" rowspan="1">Number of pages</td>
<c>IANA</c> <td align="right" colspan="1" rowspan="1">0.50</td>
<c>-0.14</c> <td align="right" colspan="1" rowspan="1">-0.04</td>
<c>-0.21</c> <td align="right" colspan="1" rowspan="1">0.21</td>
<c>0.12</c> </tr>
<c>Nb Authors</c> <tr>
<c>0.39</c> <td align="left" colspan="1" rowspan="1">Copy-Edit</td>
<c>-0.07</c> <td align="right" colspan="1" rowspan="1">0.42</td>
<c>0.18</c> <td align="right" colspan="1" rowspan="1">0.24</td>
<c>Nb drafts</c> <td align="right" colspan="1" rowspan="1">0.45</td>
<c>0.18</c> </tr>
<c>-0.33</c> <tr>
<c>-0.19</c> <td align="left" colspan="1" rowspan="1">IANA</td>
<c>WG delay</c> <td align="right" colspan="1" rowspan="1">-0.14</td>
<c>0.03</c> <td align="right" colspan="1" rowspan="1">-0.21</td>
<c>-0.16</c> <td align="right" colspan="1" rowspan="1">0.12</td>
<c>-0.15</c> </tr>
</texttable> <tr>
<td align="left" colspan="1" rowspan="1">Number of authors</td>
<t>We see some plausible explanations for the production delay. It will be somew <td align="right" colspan="1" rowspan="1">0.39</td>
hat longer for <td align="right" colspan="1" rowspan="1">-0.07</td>
longer documents, or for documents that require a lot of copy editing (see <xref <td align="right" colspan="1" rowspan="1">0.18</td>
target="copy-editing"/>). </tr>
Somewhat surprisingly, it also tend to increase with the number of authors. It d <tr>
oes <td align="left" colspan="1" rowspan="1">Number of drafts</td>
<td align="right" colspan="1" rowspan="1">0.18</td>
<td align="right" colspan="1" rowspan="1">-0.33</td>
<td align="right" colspan="1" rowspan="1">-0.19</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">WG delay</td>
<td align="right" colspan="1" rowspan="1">0.03</td>
<td align="right" colspan="1" rowspan="1">-0.16</td>
<td align="right" colspan="1" rowspan="1">-0.15</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.3-10">We see some plausible explanations for
the production delay. It will be somewhat longer for
longer documents or for documents that require a lot of copy editing (see <xref
target="copy-editing" format="default" sectionFormat="of" derivedContent="Sectio
n 4.4"/>).
Somewhat surprisingly, it also tends to increase with the number of authors. It
does
not appear significantly correlated with the presence or absence of IANA action. </t> not appear significantly correlated with the presence or absence of IANA action. </t>
<t indent="0" pn="section-4.3-11">The analysis of RFC 8324 in <xref targ
<t>The analysis of RFC 8324 in <xref target="analyse-8324"/> explains its short et="analyse-8324" format="default" sectionFormat="of" derivedContent="Section 3.
6"/> explains its short
editing delays by the experience of the author. This makes sense: if a document editing delays by the experience of the author. This makes sense: if a document
needs less editing, the editing delays would be shorter. This is partially needs less editing, the editing delays would be shorter. This is partially
confirmed by the relation between the amount of copy editing and the confirmed by the relation between the amount of copy editing and the
publication delay.</t> publication delay.</t>
<t indent="0" pn="section-4.3-12">We see fewer plausible explanations fo
<t>We see fewer plausible explanations for the AUTH48 delays. These delays r the AUTH48 delays. These delays
vary much more than the preparation vary much more than the preparation
delay, with a standard deviation of 20 days for AUTH-48 versus 10 days for delay, with a standard deviation of 20 days for AUTH48 versus 10 days for
the preparation delay. In theory, AUTH-48 is just a final the preparation delay. In theory, AUTH48 is just a final
verification: the authors receive the document prepared by the RFC production ce nter, verification: the authors receive the document prepared by the RFC production ce nter,
and just have to give their approval, or maybe request a last minute and just have to give their approval, or maybe request a last minute
correction. The name indicates that this is expected to last just two days, but correction. The name indicates that this is expected to last just two days, but
in average it lasts more than a month.</t> in average it lasts more than a month.</t>
<t indent="0" pn="section-4.3-13">We often hypothesize that the
<t>We often hypothesize that the number of authors influences the AUTH48 delay, or that authors who have spent
number of authors influences the AUTH-48 delay, or that authors who have spent a long time working on the document in the working group somehow get demotivated
a long time working on the document in the Working Group somehow get demotivated and spend even longer to answer questions during AUTH48. This may happen
and spend even longer to answer questions during AUTH-48. This may happen sometimes, but our statistics don't show that - if anything, the numerical
sometimes, but our statistics don't show that &#8211; if anything, the numerica
l
results point in the opposite direction.</t> results point in the opposite direction.</t>
<t indent="0" pn="section-4.3-14">After asking the authors of the RFCs i
<t>After asking the authors of the RFCs in the sample why the AUTH-48 phase took n the sample why the AUTH48 phase took
a long time, we got three explanations:</t> a long time, we got three explanations:</t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.
<t>1- Some RFCs have multiple authors in multiple time zones. This slows down 3-15">
the coordination required for approving changes.</t> <li pn="section-4.3-15.1" derivedCounter="1.">Some RFCs have multiple authors
in multiple time zones. This slows down
<t>2- Some authors found some of the proposed changes unnecessary or the coordination required for approving changes.</li>
<li pn="section-4.3-15.2" derivedCounter="2.">Some authors found some
of the proposed changes unnecessary or
undesirable, and asked that they be reversed. This required long undesirable, and asked that they be reversed. This required long
exchanges between authors and editors.</t> exchanges between authors and editors.</li>
<li pn="section-4.3-15.3" derivedCounter="3.">Some authors were not gi
<t>3- Some authors were not giving high priority to AUTH-48 responses.</t> ving high priority to AUTH48 responses.</li>
</ol>
<t>As mentioned above, we were not able to verify these hypotheses by looking at <t indent="0" pn="section-4.3-16">As mentioned above, we were not able t
o verify these hypotheses by looking at
the data. The author's experience with this document suggests another potential the data. The author's experience with this document suggests another potential
delay for the Independent Stream RFC: processing delay by the Independent delay for the Independent Stream RFC: processing delay by the Independent
Stream Editor, discussed in <xref target="independent-stream"/>.</t> Submissions Editor, discussed in <xref target="independent-stream" format="defau
lt" sectionFormat="of" derivedContent="Section 4.5"/>.</t>
</section> </section>
<section anchor="copy-editing" title="Copy Editing"> <section anchor="copy-editing" numbered="true" toc="include" removeInRFC="
false" pn="section-4.4">
<t>We can assess the amount of copy editing applied to each published RFC by <name slugifiedName="name-copy-editing">Copy Editing</name>
<t indent="0" pn="section-4.4-1">We can assess the amount of copy editin
g applied to each published RFC by
comparing the text of the draft approved for publication and the text of the comparing the text of the draft approved for publication and the text of the
RFC. We do expect differences in the "boilerplate" and in the IANA section, RFC. We do expect differences in the "boilerplate" and in the IANA section,
but we will also see differences due to copy editing. Assessing the amount but we will also see differences due to copy editing. Assessing the amount
of copy editing is subjective, and we do it using a scale of 1 to 4:</t> of copy editing is subjective, and we do it using a scale of 1 to 4:</t>
<dl indent="4" newline="false" spacing="normal" pn="section-4.4-2">
<t>1- Minor editing</t> <dt pn="section-4.4-2.1">1:</dt>
<dd pn="section-4.4-2.2">Minor editing</dd>
<t>2- Editing for style, such as capitalization, hyphens, that versus which, <dt pn="section-4.4-2.3">2:</dt>
and expending all acronyms at least one.</t> <dd pn="section-4.4-2.4">Editing for style, such as capitalization, hy
phens, "that" versus "which",
<t>3- Editing for clarity in addition to style, such as rewriting ambiguous and expanding all acronyms at least once.</dd>
sentences and clarifying use of internal references. For Yang models, <dt pn="section-4.4-2.5">3:</dt>
that may include model corrections suggested by the verifier.</t> <dd pn="section-4.4-2.6">Editing for clarity in addition to style, suc
h as rewriting ambiguous
<t>4- Extensive editing.</t> sentences and clarifying use of internal references. For YANG models,
that may include model corrections suggested by the verifier.</dd>
<t>The following table shows that about half of the RFCs required <dt pn="section-4.4-2.7">4:</dt>
<dd pn="section-4.4-2.8">Extensive editing.</dd>
</dl>
<t indent="0" pn="section-4.4-3">The following table shows that about ha
lf of the RFCs required
editing for style, and the other half at least some editing for clarity.</t> editing for style, and the other half at least some editing for clarity.</t>
<table align="center" pn="table-9">
<texttable> <thead>
<ttcol align='right'>RFC</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="right" colspan="1" rowspan="1">RFC</th>
<ttcol align='right'>Copy Edit</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">Copy Edit</th>
<c>Info</c> </tr>
<c>2</c> </thead>
<c>8456</c> <tbody>
<c>Info</c> <tr>
<c>4</c> <td align="right" colspan="1" rowspan="1">8411</td>
<c>8446</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>3</c> </tr>
<c>8355</c> <tr>
<c>Info</c> <td align="right" colspan="1" rowspan="1">8456</td>
<c>2</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>8441</c> <td align="right" colspan="1" rowspan="1">4</td>
<c>PS</c> </tr>
<c>2</c> <tr>
<c>8324</c> <td align="right" colspan="1" rowspan="1">8446</td>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>8377</c> </tr>
<c>PS</c> <tr>
<c>3</c> <td align="right" colspan="1" rowspan="1">8355</td>
<c>8498</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>3</c> </tr>
<c>8479</c> <tr>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">8441</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>8453</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>Info</c> </tr>
<c>2</c> <tr>
<c>8429</c> <td align="right" colspan="1" rowspan="1">8324</td>
<c>BCP</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>8312</c> </tr>
<c>Info</c> <tr>
<c>2</c> <td align="right" colspan="1" rowspan="1">8377</td>
<c>8492</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>3</c> </tr>
<c>8378</c> <tr>
<c>Exp</c> <td align="right" colspan="1" rowspan="1">8498</td>
<c>2</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>8361</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>PS</c> </tr>
<c>2</c> <tr>
<c>8472</c> <td align="right" colspan="1" rowspan="1">8479</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8471</c> </tr>
<c>PS</c> <tr>
<c>2</c> <td align="right" colspan="1" rowspan="1">8453</td>
<c>8466</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>3</c> </tr>
<c>8362</c> <tr>
<c>PS</c> <td align="right" colspan="1" rowspan="1">8429</td>
<c>3</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>8468</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>Info</c> </tr>
<c>3</c> <tr>
</texttable> <td align="right" colspan="1" rowspan="1">8312</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<t>This method of assessment does not take into account <td align="right" colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8492</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">3</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8378</td>
<td align="left" colspan="1" rowspan="1">Exp</td>
<td align="right" colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8361</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8472</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8471</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">3</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">3</td>
</tr>
<tr>
<td align="right" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">3</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-4.4-5">This method of assessment does not take
into account
the number of changes proposed by the editors and eventually rejected the number of changes proposed by the editors and eventually rejected
by the authors, since these changes are not present in either the by the authors, since these changes are not present in either the
final draft or the published RFC. It might be possible to get final draft or the published RFC. It might be possible to get
an evaluation of these "phantom changes" from the RFC Production Center.</t> an evaluation of these "phantom changes" from the RFC Production Center.</t>
</section>
</section> <section anchor="independent-stream" numbered="true" toc="include" removeI
<section anchor="independent-stream" title="Independent Stream"> nRFC="false" pn="section-4.5">
<name slugifiedName="name-independent-stream">Independent Stream</name>
<t>Out of 20 randomly selected RFCs, 3 were published through the Independent St <t indent="0" pn="section-4.5-1">Out of 20 randomly selected RFCs, 3 wer
ream. e published through the Independent Stream.
One is an independent opinion, another a description of a non-IETF protocol One is an independent opinion, another a description of a non-IETF protocol
format, and the third was <xref target="RFC8492"/>, which is a special case. Apa rt from format, and the third was <xref target="RFC8492" format="default" sectionFormat= "of" derivedContent="RFC8492"/>, which is a special case. Apart from
this special case, the publication delays were significantly shorter this special case, the publication delays were significantly shorter
for the Independent Stream than for the IETF stream.</t> for the Independent Stream than for the IETF Stream.</t>
<t indent="0" pn="section-4.5-2">The authors of these 3 RFCs are regular
<t>The authors of these 3 RFCs are regular IETF contributors. This IETF contributors. This
observation motivated a secondary analysis of all the RFCs observation motivated a secondary analysis of all the RFCs
published in the Independent Stream in 2018. There are 14 such RFCs: published in the Independent Stream in 2018. There are 14 such RFCs:
8507, 8494, 8493, 8492, 8483, 8479, 8433, 8409, 8374, 8369, 8367, 8351, 8507, 8494, 8493, 8492, 8483, 8479, 8433, 8409, 8374, 8369, 8367, 8351,
8328 and 8324. (RFC 8367 and 8369 were 8328, and 8324. (RFCs 8367 and 8369 were
published on 1 April 2018.) The majority of published on 1 April 2018.) The majority of
the documents were published by regular IETF participants, but the documents were published by regular IETF participants, but
two of them were not. One describes "The BagIt File Packaging Format (V1.0)" two of them were not. One describes "The BagIt File Packaging Format (V1.0)"
<xref target="RFC8493"/>, and the other the "Yeti DNS Testbed" <xref target="RFC <xref target="RFC8493" format="default" sectionFormat="of" derivedContent="RFC84
8483"/>. They 93"/>, and the other the "Yeti DNS Testbed" <xref target="RFC8483" format="defau
document a data format and a system developed outside the IETF, and illustrate lt" sectionFormat="of" derivedContent="RFC8483"/>. They
document a data format and a system developed outside the IETF and illustrate
the outreach function of the Independent Stream. In both cases, the the outreach function of the Independent Stream. In both cases, the
authors include one experienced IETF participant, who presumably helped authors include one experienced IETF participant, who presumably helped
outsiders navigate the publication process.</t> outsiders navigate the publication process.</t>
<t indent="0" pn="section-4.5-3">Th present document experienced some pu
<t>Th present document experienced some publication delays due to the Independen blication delays due to the Independent Submissions Editor.
t Stream Editor.
The ISE is a bottleneck and is a volunteer resource. Although the ISE as a lone person The ISE is a bottleneck and is a volunteer resource. Although the ISE as a lone person
operating as a volunteer is still roughly adequate resource for the operating as a volunteer is still roughly adequate resource for the
job, the delivery will necessarily be best effort with delays caused job, the delivery will necessarily be best effort with delays caused
by spikes in ISE load, work commitments, and other life events. These by spikes in ISE load, work commitments, and other life events. These
delays may not be fundamentally critical to RFC delivery, but they delays may not be fundamentally critical to RFC delivery, but they
are capable of introducing a significant percentage delay into what are capable of introducing a significant percentage delay into what
might otherwise be a smooth process.</t> might otherwise be a smooth process.</t>
</section>
</section> </section>
</section> <section anchor="citations" numbered="true" toc="include" removeInRFC="false
<section anchor="citations" title="Citation Counts"> " pn="section-5">
<name slugifiedName="name-citation-counts">Citation Counts</name>
<t>In this exploration, we want to assess whether citation counts provide a <t indent="0" pn="section-5-1">In this exploration, we want to examine whe
ther citation counts provide a
meaningful assessment of the popularity of RFCs. We obtain the citation meaningful assessment of the popularity of RFCs. We obtain the citation
counts through the Semantic Scholar API, using queries of the form:</t> counts through the Semantic Scholar API, using queries of the form:
<eref brackets="angle" target="https://api.semanticscholar.org/v1/paper/10.
<figure><artwork><![CDATA[ 17487/rfc8446?include_unknown_references=true"/>
http://api.semanticscholar.org/ </t>
v1/paper/10.17487/rfc8446?include_unknown_references=true <t indent="0" pn="section-5-2">In these queries, the RFC is uniquely ident
]]></artwork></figure> ified by its DOI reference,
<t>In these queries, the RFC is uniquely identified by its DOI reference,
which is composed of the RFC Series prefix 10.17487 and the RFC identifier. which is composed of the RFC Series prefix 10.17487 and the RFC identifier.
The queries return a series of properties, including a list of citations The queries return a series of properties, including a list of citations
for the RFC. Based on that list of citations, we compute three numbers:</t> for the RFC. Based on that list of citations, we compute three numbers:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-3
<t><list style="symbols"> ">
<t>The total number of citations</t> <li pn="section-5-3.1">The total number of citations</li>
<t>The number of citations in the year of publication and the year after <li pn="section-5-3.2">The number of citations in the year of publicatio
that</t> n and the year after
<t>For the RFC published in 1998 or 2008 that we use for comparison, the that</li>
number of citations in the years 2018 and 2019.</t> <li pn="section-5-3.3">For the RFC published in 1998 or 2008 that we use
</list></t> for comparison, the
number of citations in the years 2018 and 2019.</li>
<t>All the numbers were retrieved on October 6, 2019.</t> </ul>
<t indent="0" pn="section-5-4">All the numbers were retrieved on October 6
<section anchor="citation-numbers" title="Citation Numbers"> , 2019.</t>
<section anchor="citation-numbers" numbered="true" toc="include" removeInR
<t>As measured on October 6, 2019, the citation counts for the RFC in FC="false" pn="section-5.1">
<name slugifiedName="name-citation-numbers">Citation Numbers</name>
<t indent="0" pn="section-5.1-1">As measured on October 6, 2019, the cit
ation counts for the RFC in
our sample set were:</t> our sample set were:</t>
<table align="center" pn="table-10">
<texttable> <thead>
<ttcol align='left'>RFC(2018)</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="left" colspan="1" rowspan="1">RFC (2018)</th>
<ttcol align='right'>Total</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>2018-2019</ttcol> <th align="right" colspan="1" rowspan="1">Total</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">2018-2019</th>
<c>Info</c> </tr>
<c>1</c> </thead>
<c>0</c> <tbody>
<c>8456</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8411</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8446</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>PS</c> </tr>
<c>418</c> <tr>
<c>204</c> <td align="left" colspan="1" rowspan="1">8456</td>
<c>8355</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>3</c> </tr>
<c>8441</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">8446</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">418</td>
<c>8324</c> <td align="right" colspan="1" rowspan="1">204</td>
<c>ISE</c> </tr>
<c>0</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">8355</td>
<c>8377</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>0</c> </tr>
<c>8498</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8441</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8479</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>ISE</c> </tr>
<c>0</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">8324</td>
<c>8453</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>3</c> </tr>
<c>8429</c> <tr>
<c>BCP</c> <td align="left" colspan="1" rowspan="1">8377</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8312</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>Info</c> </tr>
<c>25</c> <tr>
<c>16</c> <td align="left" colspan="1" rowspan="1">8498</td>
<c>8492</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>4</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>4</c> </tr>
<c>8378</c> <tr>
<c>Exp</c> <td align="left" colspan="1" rowspan="1">8479</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8361</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>PS</c> </tr>
<c>0</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">8453</td>
<c>8472</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>1</c> </tr>
<c>8471</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">8429</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8466</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>PS</c> </tr>
<c>0</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">8312</td>
<c>8362</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">25</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">16</td>
<c>1</c> </tr>
<c>8468</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8492</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">4</td>
</texttable> <td align="right" colspan="1" rowspan="1">4</td>
</tr>
<t>The results indicate that <xref target="RFC8446"/> is by far the most cited o <tr>
f the 20 <td align="left" colspan="1" rowspan="1">8378</td>
<td align="left" colspan="1" rowspan="1">Exp</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8361</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8472</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8471</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.1-3">The results indicate that <xref target=
"RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> is by f
ar the most cited of the 20
RFC in our sample. This is not surprising, since TLS is a key Internet Protocol. RFC in our sample. This is not surprising, since TLS is a key Internet Protocol.
The TLS 1.3 protocol was also the subject of extensive studies by researchers, The TLS 1.3 protocol was also the subject of extensive studies by researchers,
and thus was mentioned in a number of published papers. and thus was mentioned in a number of published papers.
Surprisingly, the Semantic Scholar mentions a number of citations that predate Surprisingly, the Semantic Scholar mentions a number of citations that predate
the publication date. These are probably citations of the various draft the publication date. These are probably citations of the various draft
versions of the protocol.</t> versions of the protocol.</t>
<t indent="0" pn="section-5.1-4">The next most cited RFC in the sample i
<t>The next most cited RFC in the sample is <xref target="RFC8312"/> which descr s <xref target="RFC8312" format="default" sectionFormat="of" derivedContent="RFC
ibes the 8312"/> which describes the
Cubic congestion control algorithm for TCP. That protocol was also the Cubic congestion control algorithm for TCP. That protocol was also the
target of a large number of academic publications.The other RFC in the target of a large number of academic publications. The other RFCs in the
sample only have a small number of citations.</t> sample only have a small number of citations.</t>
<t indent="0" pn="section-5.1-5">There is probably a small bias when mea
<t>There is probably a small bias when measuring citations at a fixed date. suring citations at a fixed date.
An RFC published in January 2018 would have more time to accrue citations than An RFC published in January 2018 would have more time to accrue citations than
one published in December. That may be true to some extent, as the second most one published in December. That may be true to some extent, as the second most
cited RFC in the set was published in January. However, the effect has to be cited RFC in the set was published in January. However, the effect has to be
limited. The most cited RFC was published in August, and the second most cited limited. The most cited RFC was published in August, and the second most cited
was published in 2019. (That RFC got an RFC number in 2018, but publication was published in 2019. (That RFC got an RFC number in 2018, but publication
was slowed by long AUTH-48 delays.)</t> was slowed by long AUTH48 delays.)</t>
</section>
</section> <section anchor="comparison-to-1998-and-2008" numbered="true" toc="include
<section anchor="comparison-to-1998-and-2008" title="Comparison to 1998 and 2008 " removeInRFC="false" pn="section-5.2">
"> <name slugifiedName="name-comparison-to-1998-and-2008">Comparison to 199
8 and 2008</name>
<t>In order to get a baseline, we can look at the number of references for the <t indent="0" pn="section-5.2-1">In order to get a baseline, we can look
RFCs published in 2008 and 1998. However, we need totake time into account. at the number of references for the
RFCs published in 2008 and 1998. However, we need to take time into account.
Documents published a long time ago are expected to have accrued more references . Documents published a long time ago are expected to have accrued more references .
We try to address this by looking at three counts for each document: the We try to address this by looking at three counts for each document: the
overall number of references over the document's lifetime, the number of overall number of references over the document's lifetime, the number of
references obtained in the year following publication, and the number of references obtained in the year following publication, and the number of
references observed since 2018:</t> references observed since 2018:</t>
<table align="center" pn="table-11">
<texttable> <thead>
<ttcol align='left'>RFC(2008)</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="left" colspan="1" rowspan="1">RFC(2008)</th>
<ttcol align='right'>Total</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>2008-2009</ttcol> <th align="right" colspan="1" rowspan="1">Total</th>
<ttcol align='right'>2018-2019</ttcol> <th align="right" colspan="1" rowspan="1">2008-2009</th>
<c>5326</c> <th align="right" colspan="1" rowspan="1">2018-2019</th>
<c>Exp</c> </tr>
<c>138</c> </thead>
<c>14</c> <tbody>
<c>15</c> <tr>
<c>5348</c> <td align="left" colspan="1" rowspan="1">5326</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>14</c> <td align="right" colspan="1" rowspan="1">138</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">14</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">15</td>
<c>5281</c> </tr>
<c>Info</c> <tr>
<c>69</c> <td align="left" colspan="1" rowspan="1">5348</td>
<c>15</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>7</c> <td align="right" colspan="1" rowspan="1">14</td>
<c>5354</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>Exp</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>17</c> </tr>
<c>13</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">5281</td>
<c>5227</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">69</td>
<c>19</c> <td align="right" colspan="1" rowspan="1">15</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>2</c> </tr>
<c>5329</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5354</td>
<c>24</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>6</c> <td align="right" colspan="1" rowspan="1">17</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">13</td>
<c>5277</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>PS</c> </tr>
<c>32</c> <tr>
<c>3</c> <td align="left" colspan="1" rowspan="1">5227</td>
<c>2</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>5236</c> <td align="right" colspan="1" rowspan="1">19</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>25</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>5</c> </tr>
<c>4</c> <tr>
<c>5358</c> <td align="left" colspan="1" rowspan="1">5329</td>
<c>BCP</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>21</c> <td align="right" colspan="1" rowspan="1">24</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">6</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>5271</c> </tr>
<c>Info</c> <tr>
<c>7</c> <td align="left" colspan="1" rowspan="1">5277</td>
<c>2</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">32</td>
<c>5195</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>7</c> </tr>
<c>4</c> <tr>
<c>2</c> <td align="left" colspan="1" rowspan="1">5236</td>
<c>5283</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">25</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">5</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">4</td>
<c>0</c> </tr>
<c>5186</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">5358</td>
<c>14</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>4</c> <td align="right" colspan="1" rowspan="1">21</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>5142</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>PS</c> </tr>
<c>8</c> <tr>
<c>4</c> <td align="left" colspan="1" rowspan="1">5271</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>5373</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>5</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2</c> </tr>
<c>0</c> <tr>
<c>5404</c> <td align="left" colspan="1" rowspan="1">5195</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">4</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>5172</c> </tr>
<c>PS</c> <tr>
<c>2</c> <td align="left" colspan="1" rowspan="1">5283</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>5349</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8</c> </tr>
<c>0</c> <tr>
<c>2</c> <td align="left" colspan="1" rowspan="1">5186</td>
<c>5301</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">14</td>
<c>5</c> <td align="right" colspan="1" rowspan="1">4</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>0</c> </tr>
<c>5174</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">5142</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">4</td>
</texttable> <td align="right" colspan="1" rowspan="1">0</td>
</tr>
<texttable> <tr>
<ttcol align='left'>RFC(1998)</ttcol> <td align="left" colspan="1" rowspan="1">5373</td>
<ttcol align='left'>Status</ttcol> <td align="left" colspan="1" rowspan="1">PS</td>
<ttcol align='right'>Total</ttcol> <td align="right" colspan="1" rowspan="1">5</td>
<ttcol align='right'>1998-1999</ttcol> <td align="right" colspan="1" rowspan="1">2</td>
<ttcol align='right'>2018-2019</ttcol> <td align="right" colspan="1" rowspan="1">0</td>
<c>2289</c> </tr>
<c>PS</c> <tr>
<c>2</c> <td align="left" colspan="1" rowspan="1">5404</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>2267</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>982</c> </tr>
<c>5</c> <tr>
<c>61</c> <td align="left" colspan="1" rowspan="1">5172</td>
<c>2317</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>BCP</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>9</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2</c> </tr>
<c>2404</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">5349</td>
<c>137</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>6</c> <td align="right" colspan="1" rowspan="1">8</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2374</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>PS</c> </tr>
<c>42</c> <tr>
<c>4</c> <td align="left" colspan="1" rowspan="1">5301</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2449</c> <td align="right" colspan="1" rowspan="1">5</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>7</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2</c> </tr>
<c>0</c> <tr>
<c>2283</c> <td align="left" colspan="1" rowspan="1">5174</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>17</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2394</c> </tr>
<c>Info</c> </tbody>
<c>13</c> </table>
<c>2</c> <table align="center" pn="table-12">
<c>1</c> <thead>
<c>2348</c> <tr>
<c>DS</c> <th align="left" colspan="1" rowspan="1">RFC (1998)</th>
<c>5</c> <th align="left" colspan="1" rowspan="1">Status</th>
<c>0</c> <th align="right" colspan="1" rowspan="1">Total</th>
<c>0</c> <th align="right" colspan="1" rowspan="1">1998-1999</th>
<c>2382</c> <th align="right" colspan="1" rowspan="1">2018-2019</th>
<c>Info</c> </tr>
<c>17</c> </thead>
<c>12</c> <tbody>
<c>0</c> <tr>
<c>2297</c> <td align="left" colspan="1" rowspan="1">2289</td>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>36</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>11</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>2381</c> </tr>
<c>PS</c> <tr>
<c>39</c> <td align="left" colspan="1" rowspan="1">2267</td>
<c>12</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">982</td>
<c>2312</c> <td align="right" colspan="1" rowspan="1">5</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">61</td>
<c>14</c> </tr>
<c>3</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">2317</td>
<c>2387</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">9</td>
<c>4</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>0</c> </tr>
<c>2398</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">2404</td>
<c>17</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">137</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">6</td>
<c>2391</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>PS</c> </tr>
<c>31</c> <tr>
<c>3</c> <td align="left" colspan="1" rowspan="1">2374</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>2431</c> <td align="right" colspan="1" rowspan="1">42</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">4</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>0</c> </tr>
<c>0</c> <tr>
<c>2282</c> <td align="left" colspan="1" rowspan="1">2449</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>8</c> <td align="right" colspan="1" rowspan="1">7</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>2323</c> </tr>
<c>ISE</c> <tr>
<c>1</c> <td align="left" colspan="1" rowspan="1">2283</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">17</td>
<c>2448</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">2</td>
<c>0</c> </tr>
<c>0</c> <tr>
<c>0</c> <td align="left" colspan="1" rowspan="1">2394</td>
</texttable> <td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">13</td>
<t>We can compare the median number of citations and the numbers of citations <td align="right" colspan="1" rowspan="1">2</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2348</td>
<td align="left" colspan="1" rowspan="1">DS</td>
<td align="right" colspan="1" rowspan="1">5</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2382</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">17</td>
<td align="right" colspan="1" rowspan="1">12</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2297</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">36</td>
<td align="right" colspan="1" rowspan="1">11</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2381</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">39</td>
<td align="right" colspan="1" rowspan="1">12</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2312</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">14</td>
<td align="right" colspan="1" rowspan="1">3</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2387</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">4</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2398</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">17</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2391</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">31</td>
<td align="right" colspan="1" rowspan="1">3</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2431</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">3</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2282</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">8</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2323</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2448</td>
<td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.2-4">We can compare the median number of cit
ations and the numbers of citations
for the least and most popular quartiles in the three years:</t> for the least and most popular quartiles in the three years:</t>
<table align="center" pn="table-13">
<texttable> <thead>
<ttcol align='left'>References</ttcol> <tr>
<ttcol align='right'>Lower 25%</ttcol> <th align="left" colspan="1" rowspan="1">References</th>
<ttcol align='right'>Median</ttcol> <th align="right" colspan="1" rowspan="1">Lower 25%</th>
<ttcol align='right'>Higher 25%</ttcol> <th align="right" colspan="1" rowspan="1">Median</th>
<c>RFC (2018)</c> <th align="right" colspan="1" rowspan="1">Higher 25%</th>
<c>0</c> </tr>
<c>1</c> </thead>
<c>3</c> <tbody>
<c>RFC (2008)</c> <tr>
<c>6.5</c> <td align="left" colspan="1" rowspan="1">RFC (2018)</td>
<c>11</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>21.75</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>RFC (2008), until 2009</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>1</c> </tr>
<c>2.5</c> <tr>
<c>4.5</c> <td align="left" colspan="1" rowspan="1">RFC (2008)</td>
<c>RFC (2008), 2018 and after</c> <td align="right" colspan="1" rowspan="1">6.5</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">11</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">21.75</td>
<c>2</c> </tr>
<c>RFC (1998)</c> <tr>
<c>4.75</c> <td align="left" colspan="1" rowspan="1">RFC (2008), until 2009</t
<c>13.5</c> d>
<c>32.25</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>RFC (1998), until 1999</c> <td align="right" colspan="1" rowspan="1">2.5</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">4.5</td>
<c>2</c> </tr>
<c>4.25</c> <tr>
<c>RFC (1998), 2018 and after</c> <td align="left" colspan="1" rowspan="1">RFC (2008), 2018 and afte
<c>0</c> r</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">0</td>
</texttable> <td align="right" colspan="1" rowspan="1">2</td>
</tr>
<t>The total numbers show new documents with fewer citations than the older ones <tr>
. <td align="left" colspan="1" rowspan="1">RFC (1998)</td>
<td align="right" colspan="1" rowspan="1">4.75</td>
<td align="right" colspan="1" rowspan="1">13.5</td>
<td align="right" colspan="1" rowspan="1">32.25</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">RFC (1998), until 1999</t
d>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">2</td>
<td align="right" colspan="1" rowspan="1">4.25</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">RFC (1998), 2018 and afte
r</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">1</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.2-6">The total numbers show new documents wi
th fewer citations than the older ones.
This can be explained to some degree by the passage of time. If we This can be explained to some degree by the passage of time. If we
restrict the analysis to the number of citations accrued in the year of restrict the analysis to the number of citations accrued in the year of
publishing and the year after that, we still see about the same distribution publishing and the year after that, we still see about the same distribution
for the three samples.</t> for the three samples.</t>
<t indent="0" pn="section-5.2-7">We also see that the number of referenc
<t>We also see that the number of references to RFC fades over time. Only the es to RFCs fades over time. Only the
most popular of the RFC produced in 1998 are still cited in 2019.</t> most popular of the RFC produced in 1998 are still cited in 2019.</t>
</section>
</section> <section anchor="citations-versus-deployments" numbered="true" toc="includ
<section anchor="citations-versus-deployments" title="Citations Versus Deploymen e" removeInRFC="false" pn="section-5.3">
ts"> <name slugifiedName="name-citations-versus-deployment">Citations versus
Deployments</name>
<t>The following table shows <t indent="0" pn="section-5.3-1">The following table shows
side by side the number of citations as measured in <xref target="citation-numbe side by side the number of citations as measured in <xref target="citation-numbe
rs"/> and rs" format="default" sectionFormat="of" derivedContent="Section 5.1"/> and
the estimation of deployment as indicated in <xref target="sample-rfc-analysis"/ the estimation of deployment as indicated in <xref target="sample-rfc-analysis"
>.</t> format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
<table align="center" pn="table-14">
<texttable> <thead>
<ttcol align='left'>RFC(2018)</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="left" colspan="1" rowspan="1">RFC (2018)</th>
<ttcol align='right'>Citations</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>Deployment</ttcol> <th align="right" colspan="1" rowspan="1">Citations</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">Deployment</th>
<c>Info</c> </tr>
<c>1</c> </thead>
<c>medium</c> <tbody>
<c>8456</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8411</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>medium</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8446</c> <td align="right" colspan="1" rowspan="1">medium</td>
<c>PS</c> </tr>
<c>418</c> <tr>
<c>high</c> <td align="left" colspan="1" rowspan="1">8456</td>
<c>8355</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">medium</td>
<c>medium</c> </tr>
<c>8441</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">8446</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>high</c> <td align="right" colspan="1" rowspan="1">418</td>
<c>8324</c> <td align="right" colspan="1" rowspan="1">high</td>
<c>ISE</c> </tr>
<c>0</c> <tr>
<c>N/A</c> <td align="left" colspan="1" rowspan="1">8355</td>
<c>8377</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">medium</td>
<c>unknown</c> </tr>
<c>8498</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8441</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>unknown</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8479</c> <td align="right" colspan="1" rowspan="1">high</td>
<c>ISE</c> </tr>
<c>0</c> <tr>
<c>one</c> <td align="left" colspan="1" rowspan="1">8324</td>
<c>8453</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>3</c> <td align="right" colspan="1" rowspan="1">N/A</td>
<c>unknown</c> </tr>
<c>8429</c> <tr>
<c>BCP</c> <td align="left" colspan="1" rowspan="1">8377</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>some</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8312</c> <td align="right" colspan="1" rowspan="1">unknown</td>
<c>Info</c> </tr>
<c>25</c> <tr>
<c>high</c> <td align="left" colspan="1" rowspan="1">8498</td>
<c>8492</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>ISE</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>4</c> <td align="right" colspan="1" rowspan="1">unknown</td>
<c>one</c> </tr>
<c>8378</c> <tr>
<c>Exp</c> <td align="left" colspan="1" rowspan="1">8479</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>some</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8361</c> <td align="right" colspan="1" rowspan="1">one</td>
<c>PS</c> </tr>
<c>0</c> <tr>
<c>one</c> <td align="left" colspan="1" rowspan="1">8453</td>
<c>8472</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">unknown</td>
<c>medium</c> </tr>
<c>8471</c> <tr>
<c>PS</c> <td align="left" colspan="1" rowspan="1">8429</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>medium</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8466</c> <td align="right" colspan="1" rowspan="1">some</td>
<c>PS</c> </tr>
<c>0</c> <tr>
<c>unknown</c> <td align="left" colspan="1" rowspan="1">8312</td>
<c>8362</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">25</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">high</td>
<c>medium</c> </tr>
<c>8468</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8492</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>some</c> <td align="right" colspan="1" rowspan="1">4</td>
</texttable> <td align="right" colspan="1" rowspan="1">one</td>
</tr>
<t>From looking at these results, it is fairly obvious that citation counts <tr>
<td align="left" colspan="1" rowspan="1">8378</td>
<td align="left" colspan="1" rowspan="1">Exp</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">some</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8361</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">one</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8472</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">medium</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8471</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">medium</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">unknown</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">medium</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">some</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.3-3">From looking at these results, it is fa
irly obvious that citation counts
cannot be used as proxies for the "value" of an RFC. In our sample, the two cannot be used as proxies for the "value" of an RFC. In our sample, the two
RFCs that have high citation counts were both widely deployed, and can certainly be RFCs that have high citation counts were both widely deployed, and can certainly be
described as successful, but we also see many RFCs that saw significant deployme nt described as successful, but we also see many RFCs that saw significant deployme nt
without garnering a high level of citations.</t> without garnering a high level of citations.</t>
<t indent="0" pn="section-5.3-4">Citation counts are driven by academic
<t>Citation counts are driven by academic interest, interest,
but are only loosely correlated with actual deployment. We saw that <xref target but are only loosely correlated with actual deployment. We saw that <xref target
="RFC8446"/> ="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>
was widely cited in part because the standardization process involved many was widely cited in part because the standardization process involved many
researchers, and that the high citation count of <xref target="RFC8312"/> is researchers, and that the high citation count of <xref target="RFC8312" format=" default" sectionFormat="of" derivedContent="RFC8312"/> is
largely due to the academic interest in evaluating congestion control protocols. largely due to the academic interest in evaluating congestion control protocols.
If we look at previous years, the most cited RFC in the 2008 sample is <xref tar get="RFC5326"/>, an If we look at previous years, the most cited RFC in the 2008 sample is <xref tar get="RFC5326" format="default" sectionFormat="of" derivedContent="RFC5326"/>, an
experimental RFC defining security extensions to an experimental RFC defining security extensions to an
experimental delay tolerant transport protocol. This protocol does not experimental delay tolerant transport protocol. This protocol does not
carry a significant proportion of Internet traffic, but has been the object carry a significant proportion of Internet traffic, but has been the object
of a fair number of academic studies.</t> of a fair number of academic studies.</t>
<t indent="0" pn="section-5.3-5">The citation process tends to privilege
<t>The citation process tends to privilege the first expression of a concept. the first expression of a concept.
We see that with the most cited RFC in the 1998 set is <xref target="RFC2267"/>, We see that with the most cited RFC in the 1998 set is <xref target="RFC2267" fo
an informational rmat="default" sectionFormat="of" derivedContent="RFC2267"/>, an informational
RFC defining Network Ingress Filtering that was obsoleted in May RFC defining Network Ingress Filtering that was obsoleted in May
2000 by <xref target="RFC2827"/>. It is still cited frequently in 2018 and 2000 by <xref target="RFC2827" format="default" sectionFormat="of" derivedConten t="RFC2827"/>. It is still cited frequently in 2018 and
2019, regardless of its formal status in 2019, regardless of its formal status in
the RFC series. We see the same effect at work with <xref target="RFC8441"/>, wh the RFC Series. We see the same effect at work with <xref target="RFC8441" forma
ich t="default" sectionFormat="of" derivedContent="RFC8441"/>, which
garners very few citations although it obsoletes <xref target="RFC6455"/> that h garners very few citations although it updates <xref target="RFC6455" format="de
as fault" sectionFormat="of" derivedContent="RFC6455"/> that has
a large number of citations. The same goes for <xref target="RFC8468"/>, which i a large number of citations. The same goes for <xref target="RFC8468" format="de
s fault" sectionFormat="of" derivedContent="RFC8468"/>, which is
sparsely cited while the <xref target="RFC2330"/> is widely cited. Just counting sparsely cited while the <xref target="RFC2330" format="default" sectionFormat="
citations of" derivedContent="RFC2330"/> is widely cited. Just counting citations
will not indicate whether developers still use an old specification or will not indicate whether developers still use an old specification or
have adopted the revised RFC.</t> have adopted the revised RFC.</t>
</section>
</section> <section anchor="citations-versus-web-references" numbered="true" toc="inc
<section anchor="citations-versus-web-references" title="Citations Versus Web Re lude" removeInRFC="false" pn="section-5.4">
ferences"> <name slugifiedName="name-citations-versus-web-refere">Citations versus
Web References</name>
<t>Web references might be another indicator of the popularity of an RFC. <t indent="0" pn="section-5.4-1">Web references might be another indicat
or of the popularity of an RFC.
In order to evaluate these references, we list here the number of results In order to evaluate these references, we list here the number of results
returned by searches on Google and Bing, looking for the search term "RFCnnnn" returned by searches on Google and Bing, looking for the search term "RFCnnnn"
(e.g., RFC8411), and copying the number of results returned by the (e.g., "RFC8411"), and copying the number of results returned by the
search engines. The table below presents the results of these searches, search engines. The table below presents the results of these searches,
performed on April 4, 2020.</t> performed on April 4, 2020.</t>
<table align="center" pn="table-15">
<texttable> <thead>
<ttcol align='left'>RFC(2018)</ttcol> <tr>
<ttcol align='left'>Status</ttcol> <th align="left" colspan="1" rowspan="1">RFC(2018)</th>
<ttcol align='right'>Citations</ttcol> <th align="left" colspan="1" rowspan="1">Status</th>
<ttcol align='right'>Google</ttcol> <th align="right" colspan="1" rowspan="1">Citations</th>
<ttcol align='right'>Bing</ttcol> <th align="right" colspan="1" rowspan="1">Google</th>
<c>8411</c> <th align="right" colspan="1" rowspan="1">Bing</th>
<c>Info</c> </tr>
<c>1</c> </thead>
<c>301</c> <tbody>
<c>94</c> <tr>
<c>8456</c> <td align="left" colspan="1" rowspan="1">8411</td>
<c>Info</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>266</c> <td align="right" colspan="1" rowspan="1">301</td>
<c>8456</c> <td align="right" colspan="1" rowspan="1">94</td>
<c>8446</c> </tr>
<c>PS</c> <tr>
<c>418</c> <td align="left" colspan="1" rowspan="1">8456</td>
<c>25900</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>47800</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>8355</c> <td align="right" colspan="1" rowspan="1">266</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">8456</td>
<c>3</c> </tr>
<c>521</c> <tr>
<c>114</c> <td align="left" colspan="1" rowspan="1">8446</td>
<c>8441</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">418</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">25900</td>
<c>2430</c> <td align="right" colspan="1" rowspan="1">47800</td>
<c>59500</c> </tr>
<c>8324</c> <tr>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">8355</td>
<c>0</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>393</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>138</c> <td align="right" colspan="1" rowspan="1">521</td>
<c>8377</c> <td align="right" colspan="1" rowspan="1">114</td>
<c>PS</c> </tr>
<c>0</c> <tr>
<c>264</c> <td align="left" colspan="1" rowspan="1">8441</td>
<c>10900</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>8498</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">2430</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">59500</td>
<c>335</c> </tr>
<c>10100</c> <tr>
<c>8479</c> <td align="left" colspan="1" rowspan="1">8324</td>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>564</c> <td align="right" colspan="1" rowspan="1">393</td>
<c>11000</c> <td align="right" colspan="1" rowspan="1">138</td>
<c>8453</c> </tr>
<c>Info</c> <tr>
<c>3</c> <td align="left" colspan="1" rowspan="1">8377</td>
<c>817</c> <td align="left" colspan="1" rowspan="1">PS</td>
<c>11400</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>8429</c> <td align="right" colspan="1" rowspan="1">264</td>
<c>BCP</c> <td align="right" colspan="1" rowspan="1">10900</td>
<c>0</c> </tr>
<c>391</c> <tr>
<c>41600</c> <td align="left" colspan="1" rowspan="1">8498</td>
<c>8312</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>Info</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>25</c> <td align="right" colspan="1" rowspan="1">335</td>
<c>1620</c> <td align="right" colspan="1" rowspan="1">10100</td>
<c>2820</c> </tr>
<c>8492</c> <tr>
<c>ISE</c> <td align="left" colspan="1" rowspan="1">8479</td>
<c>4</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>323</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>9400</c> <td align="right" colspan="1" rowspan="1">564</td>
<c>8378</c> <td align="right" colspan="1" rowspan="1">11000</td>
<c>Exp</c> </tr>
<c>1</c> <tr>
<c>418</c> <td align="left" colspan="1" rowspan="1">8453</td>
<c>11600</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>8361</c> <td align="right" colspan="1" rowspan="1">3</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">817</td>
<c>0</c> <td align="right" colspan="1" rowspan="1">11400</td>
<c>499</c> </tr>
<c>92</c> <tr>
<c>8472</c> <td align="left" colspan="1" rowspan="1">8429</td>
<c>PS</c> <td align="left" colspan="1" rowspan="1">BCP</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">0</td>
<c>496</c> <td align="right" colspan="1" rowspan="1">391</td>
<c>169</c> <td align="right" colspan="1" rowspan="1">41600</td>
<c>8471</c> </tr>
<c>PS</c> <tr>
<c>1</c> <td align="left" colspan="1" rowspan="1">8312</td>
<c>1510</c> <td align="left" colspan="1" rowspan="1">Info</td>
<c>11600</c> <td align="right" colspan="1" rowspan="1">25</td>
<c>8466</c> <td align="right" colspan="1" rowspan="1">1620</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">2820</td>
<c>0</c> </tr>
<c>766</c> <tr>
<c>173</c> <td align="left" colspan="1" rowspan="1">8492</td>
<c>8362</c> <td align="left" colspan="1" rowspan="1">Info (ISE)</td>
<c>PS</c> <td align="right" colspan="1" rowspan="1">4</td>
<c>1</c> <td align="right" colspan="1" rowspan="1">323</td>
<c>67</c> <td align="right" colspan="1" rowspan="1">9400</td>
<c>147</c> </tr>
<c>8468</c> <tr>
<c>Info</c> <td align="left" colspan="1" rowspan="1">8378</td>
<c>1</c> <td align="left" colspan="1" rowspan="1">Exp</td>
<c>453</c> <td align="right" colspan="1" rowspan="1">1</td>
<c>127</c> <td align="right" colspan="1" rowspan="1">418</td>
</texttable> <td align="right" colspan="1" rowspan="1">11600</td>
</tr>
<t>The results counts from Bing are sometimes surprising. Why would RFC 8441 gat <tr>
her <td align="left" colspan="1" rowspan="1">8361</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">499</td>
<td align="right" colspan="1" rowspan="1">92</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8472</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">496</td>
<td align="right" colspan="1" rowspan="1">169</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8471</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">1510</td>
<td align="right" colspan="1" rowspan="1">11600</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8466</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">0</td>
<td align="right" colspan="1" rowspan="1">766</td>
<td align="right" colspan="1" rowspan="1">173</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8362</td>
<td align="left" colspan="1" rowspan="1">PS</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">67</td>
<td align="right" colspan="1" rowspan="1">147</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8468</td>
<td align="left" colspan="1" rowspan="1">Info</td>
<td align="right" colspan="1" rowspan="1">1</td>
<td align="right" colspan="1" rowspan="1">453</td>
<td align="right" colspan="1" rowspan="1">127</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.4-3">The result counts from Bing are sometim
es surprising. Why would RFC 8441 gather
59,500 web references? Looking at the results in detail, we find a mix of data. 59,500 web references? Looking at the results in detail, we find a mix of data.
Some of them are logs of development projects implementing Web Sockets, which Some of them are logs of development projects implementing Web Sockets, which
is exactly what we are looking for, but others appear spurious. For example, is exactly what we are looking for, but others appear spurious. For example,
a shop selling rugby jerseys is listed because its phone number ends with "8441" . a shop selling rugby jerseys is listed because its phone number ends with "8441" .
Other pages were listed because street numbers or product numbers matched the Other pages were listed because street numbers or product numbers matched the
RFC number. RFC number.
The same type of collision may explain the large reference counts on Bing for The same type of collision may explain the large reference counts on Bing for
RFC 8377, 8498, 8479, 8453, 8429, 8378, and 8471. The result counts on Bing RFCs 8377, 8498, 8479, 8453, 8429, 8378, and 8471. The result counts on Bing
do not appear to provide a good metric.</t> do not appear to provide a good metric.</t>
<t indent="0" pn="section-5.4-4">On Google, all RFCs garner at least a 2
<t>On Google, all RFC garner at least a 250 references, largely because the whol 50 references, largely because the whole
e
RFC catalog is replicated on a large number of web servers. Deviations from that RFC catalog is replicated on a large number of web servers. Deviations from that
base line are largely correlated with the number of citations in the Semantic baseline are largely correlated with the number of citations in the Semantic
Scholar, with a couple of exception: RFC 8441, and 8471 garner more Scholar, with a couple of exception: RFC 8441 and RFC 8471 garner more
references than the low citation counts would predict. Looking at the references than the low citation counts would predict. Looking at the
results, we find many references in development databases explaining results, we find many references in development databases explaining
how these protocols are implemented in various code bases and open source how these protocols are implemented in various code bases and open source
projects. This means that counting Google results would give some indication projects. This means that counting Google results would give some indication
about an RFC's popularity, complementing the citation counts.</t> about an RFC's popularity, complementing the citation counts.</t>
<t indent="0" pn="section-5.4-5">There are some practical problems in us
<t>There are some practical problems in using the counts of Google ing the counts of Google
results. Google searches are personalized, the results depend results. Google searches are personalized, the results depend
on the source of the queries, and the counts may vary as well. The on the source of the queries, and the counts may vary as well. The
search result depend on the search algorithm, and there is no guarantee search results depend on the search algorithm, and there is no guarantee
that counts will not change when the algorithm changes. On the other that counts will not change when the algorithm changes. On the other
hand, the results do indicate that some of the RFC in our sample hand, the results do indicate that some of the RFCs in our sample
are beeing used by developers or in deployments.</t> are being used by developers or in deployments.</t>
</section>
</section> </section>
</section> <section anchor="conclusion" numbered="true" toc="include" removeInRFC="fals
<section anchor="conclusion" title="Observations and Next Steps"> e" pn="section-6">
<name slugifiedName="name-observations-and-next-steps">Observations and Ne
<t>The author's goal was to get a personal understanding of the "chain xt Steps</name>
<t indent="0" pn="section-6-1">The author's goal was to get a personal und
erstanding of the "chain
of production" of the RFCs, and in particular to look at the various of production" of the RFCs, and in particular to look at the various
causes of delays in the process. As shown in causes of delays in the process. As shown in
<xref target="process-analysis"/>, the average RFC was produced in 3 years and 4 months, <xref target="process-analysis" format="default" sectionFormat="of" derivedConte nt="Section 4"/>, the average RFC was produced in 3 years and 4 months,
which is similar to what was found in the which is similar to what was found in the
2008 sample, but more than three times larger than the delays for the 2008 sample, but more than three times larger than the delays for the
1998 sample.</t> 1998 sample.</t>
<t indent="0" pn="section-6-2">The working group process appears to be the
<t>The Working Group process appears to be the main source of delays. Efforts main source of delays.
to diminish delays should probably focus there, instead of on the Efforts to diminish delays should probably focus there, instead of on the
IETF and IESG reviews of the RFC production. For the RFC production IETF and IESG reviews or the RFC production. For the RFC production
phase, most of the variability originates in the AUTH-48 process, phase, most of the variability originates in the AUTH48 process,
which is influenced by a variety of factors such as number of which is influenced by a variety of factors such as number of
authors or level of engagement of these authors.</t> authors or level of engagement of these authors.</t>
<t indent="0" pn="section-6-3">Most of the delay is spent in the working g
<t>Most of the delay is spent in the Working Group, but the IETF roup, but the IETF
datatracker does not hold much information about what happens inside Datatracker does not hold much information about what happens inside
the Working Groups. For example, events like Working Group Last Calls the working groups. For example, events like Working Group Last Calls
were not recorded in the history of the selected drafts available in the were not recorded in the history of the selected drafts available in the
datatracker. Such information would have been interesting. Of course, Datatracker. Such information would have been interesting. Of course,
requiring that information would create an administrative burden, so requiring that information would create an administrative burden, so
there is clearly a trade-off between requiring more work from working there is clearly a trade-off between requiring more work from working
group chairs and providing better data for process analysis. (It appears group chairs and providing better data for process analysis. (It appears
that this information can be available in the datatracker for more recent that this information can be available in the Datatracker for more recent
drafts, if the WG chairs use the datatracker properly.)</t> drafts, if the WG chairs use the Datatracker properly.)</t>
<t indent="0" pn="section-6-4">The Independent Stream operates as expected
<t>The Independent Stream operates as expected. The majority . The majority
of the authors of the Independent Stream RFCs appear to be in IETF insiders, of the authors of the Independent Stream RFCs appear to be in IETF insiders,
but there is significant amount of engagement by outside parties.</t> but there is significant amount of engagement by outside parties.</t>
<t indent="0" pn="section-6-5">The analysis of citations in <xref target="
<t>The analysis of citations in <xref target="citation-numbers"/> shows that cit citation-numbers" format="default" sectionFormat="of" derivedContent="Section 5.
ation 1"/> shows that citation
numbers are a very poor indication of the "value" of an RFC. Citation numbers are a very poor indication of the "value" of an RFC. Citation
numbers measure the engagement of academic researchers with specific numbers measure the engagement of academic researchers with specific
topics, but have little correlation with the level of adoption and topics, but have little correlation with the level of adoption and
deployment of a specific RFC. The result counts of Google searches deployment of a specific RFC. The result counts of Google searches
do capture references outside academia, such as logs of development do capture references outside academia, such as logs of development
projects. This might be informative, but it is not clear that the counts projects. This might be informative, but it is not clear that the counts
would not change over time due to algorithm changes or personaliztion.</t> would not change over time due to algorithm changes or personalization.</t>
<t indent="0" pn="section-6-6">This document analyses a small sample of RF
<t>This document analyses a small sample of RFCs "in depth". This allowed Cs "in depth". This allowed
gathering of detailed feedback on the process and the deployments. On gathering of detailed feedback on the process and the deployments. On
the other hand, much of the data on delays is available from the the other hand, much of the data on delays is available from the
IETF datatracker. It may be worth considering adding an automated IETF Datatracker. It may be worth considering adding an automated
reporting of delay metrics in the IETF datatracker.</t> reporting of delay metrics in the IETF Datatracker.</t>
<t indent="0" pn="section-6-7">This document only considers the RFCs that
<t>This document only considers the RFCs that were published in a given were published in a given
year. This approach can be criticized as introducing a form of year. This approach can be criticized as introducing a form of
"survivor bias". There are many drafts proposed to the IETF, and only "survivor bias". There are many drafts proposed to the IETF, and only
a fraction of them end up being published as RFCs. a fraction of them end up being published as RFCs.
On one hand this is expected, On one hand, this is expected,
because part of the process is to triage between ideas that can gather because part of the process is to triage between ideas that can gather
consensus and those that don't. On the other hand, we don't know consensus and those that don't. On the other hand, we don't know
whether that triage is too drastic and discouraged progress on good whether that triage is too drastic and has discouraged progress on good
ideas.</t> ideas.</t>
<t indent="0" pn="section-6-8">One way to evaluate the triage process woul
<t>One way to evaluate the triage process would be to d be to
look at publication attempts that were abandoned, for look at publication attempts that were abandoned -- for
example drafts that expired without progressing or being replaced. The sampling example, drafts that expired without progressing or being replaced. The sampling
methodology could also be used for that purpose. Pick maybe 20 drafts at random, methodology could also be used for that purpose. Pick maybe 20 drafts at random,
among those abandoned in a target year, and investigate why they were abandoned. among those abandoned in a target year, and investigate why they were abandoned.
Was it because better solutions emerged in the Working Group? Or maybe because Was it because better solutions emerged in the working group? Or maybe because
the authors discovered a flaw in their proposal? Or was it because some factiona l the authors discovered a flaw in their proposal? Or was it because some factiona l
struggle blocked a good idea? Was the idea pursued in a different venue? struggle blocked a good idea? Was the idea pursued in a different venue?
Hopefully, someone will try this kind of investigation.</t> Hopefully, someone will try this kind of investigation.</t>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="include" remo
<section anchor="security-considerations" title="Security Considerations"> veInRFC="false" pn="section-7">
<name slugifiedName="name-security-considerations">Security Considerations
<t>This draft does not specify any protocol.</t> </name>
<t indent="0" pn="section-7-1">This document does not specify any protocol
<t>We might want to analyze whether security issues were discovered after .</t>
<t indent="0" pn="section-7-2">We might want to analyze whether security i
ssues were discovered after
publication of specific standards.</t> publication of specific standards.</t>
</section>
</section> <section anchor="iana-considerations" numbered="true" toc="include" removeIn
<section anchor="iana-considerations" title="IANA Considerations"> RFC="false" pn="section-8">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This draft does not require any IANA action.</t> <t indent="0" pn="section-8-1">This document has no IANA actions.</t>
<t indent="0" pn="section-8-2">Preliminary analysis does not indicate that
<t>Peliminary analysis does not indicate that IANA is causing any particular IANA is causing any particular
delay in the RFC publication process.</t> delay in the RFC publication process.</t>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Many thanks to the authors of the selected RFCs who were willing to
provide feedback on the process:
Michael Ackermann,
Zafar Ali,
Sarah Banks,
Bruno Decraene,
Lars Eggert,
Nalini Elkins,
Joachim Fabini,
Dino Farinacci,
Clarence Filsfils,
Sujay Gupta,
Dan Harkins,
Vinayak Hegde,
Benjamin Kaduk,
John Klensin,
Acee Lindem,
Nikos Mavrogiannopoulos,
Patrick McManus,
Victor Moreno,
Al Morton,
Andrei Popov,
Eric Rescorla,
Michiko Short,
Bhuvaneswaran Vengainathan,
Lao Weiguo, and
Li Yizhou.
Many thanks to Adrian Farrel for his useful advice, to Stephen Farrell and Colin
Perkins
for their guidance on the use of citations, and to Dave Crocker for a comprehens
ive
review.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="TI-LFA"
/>
<references pn="section-9">
<name slugifiedName="name-informative-references">Informative References</
name>
<reference anchor="IETFCOUNT" target="https://www.ietf.org/how/meetings/pa
st/" quoteTitle="true" derivedAnchor="IETFCOUNT">
<front>
<title>Past IETF Meetings</title>
<author>
<organization showOnFrontPage="true">IETF</organization>
</author>
</front>
</reference>
<reference anchor="RFC2267" target="https://www.rfc-editor.org/info/rfc226
7" quoteTitle="true" derivedAnchor="RFC2267">
<front>
<title>Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing</title>
<author initials="P." surname="Ferguson" fullname="P. Ferguson">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Senie" fullname="D. Senie">
<organization showOnFrontPage="true"/>
</author>
<date year="1998" month="January"/>
<abstract>
<t indent="0">This paper discusses a simple, effective, and straight
forward method for using ingress traffic filtering to prohibit DoS attacks which
use forged IP addresses to be propagated from 'behind' an Internet Service Prov
ider's (ISP) aggregation point. This memo provides information for the Internet
community. It does not specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2267"/>
<seriesInfo name="DOI" value="10.17487/RFC2267"/>
</reference>
<reference anchor="RFC2330" target="https://www.rfc-editor.org/info/rfc233
0" quoteTitle="true" derivedAnchor="RFC2330">
<front>
<title>Framework for IP Performance Metrics</title>
<author initials="V." surname="Paxson" fullname="V. Paxson">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Almes" fullname="G. Almes">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Mahdavi" fullname="J. Mahdavi">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Mathis" fullname="M. Mathis">
<organization showOnFrontPage="true"/>
</author>
<date year="1998" month="May"/>
<abstract>
<t indent="0">The purpose of this memo is to define a general framew
ork for particular metrics to be developed by the IETF's IP Performance Metrics
effort. This memo provides information for the Internet community. It does not
specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2330"/>
<seriesInfo name="DOI" value="10.17487/RFC2330"/>
</reference>
<reference anchor="RFC2827" target="https://www.rfc-editor.org/info/rfc282
7" quoteTitle="true" derivedAnchor="RFC2827">
<front>
<title>Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing</title>
<author initials="P." surname="Ferguson" fullname="P. Ferguson">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Senie" fullname="D. Senie">
<organization showOnFrontPage="true"/>
</author>
<date year="2000" month="May"/>
<abstract>
<t indent="0">This paper discusses a simple, effective, and straight
forward method for using ingress traffic filtering to prohibit DoS (Denial of Se
rvice) attacks which use forged IP addresses to be propagated from 'behind' an I
nternet Service Provider's (ISP) aggregation point. This document specifies an
Internet Best Current Practices for the Internet Community, and requests discuss
ion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="38"/>
<seriesInfo name="RFC" value="2827"/>
<seriesInfo name="DOI" value="10.17487/RFC2827"/>
</reference>
<reference anchor="RFC5326" target="https://www.rfc-editor.org/info/rfc532
6" quoteTitle="true" derivedAnchor="RFC5326">
<front>
<title>Licklider Transmission Protocol - Specification</title>
<author initials="M." surname="Ramadas" fullname="M. Ramadas">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Burleigh" fullname="S. Burleigh">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="September"/>
<abstract>
<t indent="0">This document describes the Licklider Transmission Pro
tocol (LTP), designed to provide retransmission-based reliability over links cha
racterized by extremely long message round-trip times (RTTs) and/or frequent int
erruptions in connectivity. Since communication across interplanetary space is
the most prominent example of this sort of environment, LTP is principally aimed
at supporting "long-haul" reliable transmission in interplanetary space, but it
has applications in other environments as well.</t>
<t indent="0">This document is a product of the Delay Tolerant Netwo
rking Research Group and has been reviewed by that group. No objections to its
publication as an RFC were raised. This memo defines an Experimental Protocol
for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5326"/>
<seriesInfo name="DOI" value="10.17487/RFC5326"/>
</reference>
<reference anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc645
5" quoteTitle="true" derivedAnchor="RFC6455">
<front>
<title>The WebSocket Protocol</title>
<author initials="I." surname="Fette" fullname="I. Fette">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Melnikov" fullname="A. Melnikov">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="December"/>
<abstract>
<t indent="0">The WebSocket Protocol enables two-way communication b
etween a client running untrusted code in a controlled environment to a remote h
ost that has opted-in to communications from that code. The security model used
for this is the origin-based security model commonly used by web browsers. The
protocol consists of an opening handshake followed by basic message framing, la
yered over TCP. The goal of this technology is to provide a mechanism for brows
er-based applications that need two-way communication with servers that does not
rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;if
rame&gt;s and long polling). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6455"/>
<seriesInfo name="DOI" value="10.17487/RFC6455"/>
</reference>
<reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc831
2" quoteTitle="true" derivedAnchor="RFC8312">
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author initials="I." surname="Rhee" fullname="I. Rhee">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Xu" fullname="L. Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Ha" fullname="S. Ha">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Zimmermann" fullname="A. Zimmermann">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Scheffenegger" fullname="R. Scheffenegg
er">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">CUBIC is an extension to the current TCP standards. I
t differs from the current TCP standards only in the congestion control algorith
m on the sender side. In particular, it uses a cubic function instead of a line
ar window increase function of the current TCP standards to improve scalability
and stability under fast and long-distance networks. CUBIC and its predecessor
algorithm have been adopted as defaults by Linux and have been used for many yea
rs. This document provides a specification of CUBIC to enable third-party imple
mentations and to solicit community feedback through experimentation on the perf
ormance of CUBIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8312"/>
<seriesInfo name="DOI" value="10.17487/RFC8312"/>
</reference>
<reference anchor="RFC8324" target="https://www.rfc-editor.org/info/rfc832
4" quoteTitle="true" derivedAnchor="RFC8324">
<front>
<title>DNS Privacy, Authorization, Special Uses, Encoding, Characters,
Matching, and Root Structure: Time for Another Look?</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">The basic design of the Domain Name System was complet
ed almost 30 years ago. The last half of that period has been characterized by
significant changes in requirements and expectations, some of which either requi
re changes to how the DNS is used or can be accommodated only poorly or not at a
ll. This document asks the question of whether it is time to either redesign an
d replace the DNS to match contemporary requirements and expectations (rather th
an continuing to try to design and implement incremental patches that are not fu
lly satisfactory) or draw some clear lines about functionality that is not reall
y needed or that should be performed in some other way.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8324"/>
<seriesInfo name="DOI" value="10.17487/RFC8324"/>
</reference>
<reference anchor="RFC8355" target="https://www.rfc-editor.org/info/rfc835
5" quoteTitle="true" derivedAnchor="RFC8355">
<front>
<title>Resiliency Use Cases in Source Packet Routing in Networking (SP
RING) Networks</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document identifies and describes the requirement
s for a set of use cases related to Segment Routing network resiliency on Source
Packet Routing in Networking (SPRING) networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8355"/>
<seriesInfo name="DOI" value="10.17487/RFC8355"/>
</reference>
<reference anchor="RFC8361" target="https://www.rfc-editor.org/info/rfc836
1" quoteTitle="true" derivedAnchor="RFC8361">
<front>
<title>Transparent Interconnection of Lots of Links (TRILL): Centraliz
ed Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM)
Traffic</title>
<author initials="W." surname="Hao" fullname="W. Hao">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Li" fullname="Y. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Durrani" fullname="M. Durrani">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Gupta" fullname="S. Gupta">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Qu" fullname="A. Qu">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="April"/>
<abstract>
<t indent="0">In Transparent Interconnection of Lots of Links (TRILL
) active-active access, a Reverse Path Forwarding (RPF) check failure issue may
occur when using the pseudo-nickname mechanism specified in RFC 7781. This docu
ment describes a solution to resolve this RPF check failure issue through centra
lized replication. All ingress Routing Bridges (RBridges) send Broadcast, Unkno
wn Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL
encapsulation. When the centralized node receives the BUM traffic, it decapsul
ates the packets and forwards them to their destination RBridges using a distrib
ution tree established per the TRILL base protocol (RFC 6325). To avoid RPF chec
k failure on an RBridge sitting between the ingress RBridge and the centralized
replication node, some change in the RPF calculation algorithm is required. RPF
checks on each RBridge MUST be calculated as if the centralized node was the in
gress RBridge, instead of being calculated using the actual ingress RBridge. Th
is document updates RFC 6325.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8361"/>
<seriesInfo name="DOI" value="10.17487/RFC8361"/>
</reference>
<reference anchor="RFC8362" target="https://www.rfc-editor.org/info/rfc836
2" quoteTitle="true" derivedAnchor="RFC8362">
<front>
<title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Roy" fullname="A. Roy">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Goethals" fullname="D. Goethals">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Reddy Vallem" fullname="V. Reddy Vallem
">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="April"/>
<abstract>
<t indent="0">OSPFv3 requires functional extension beyond what can r
eadily be done with the fixed-format Link State Advertisement (LSA) as described
in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links an
d advertised IPv6 prefixes must be advertised in separate LSAs and correlated to
the fixed-format LSAs. This document extends the LSA format by encoding the ex
isting OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing adv
ertisement of additional information with additional TLVs. Backward-compatibili
ty mechanisms are also described.</t>
<t indent="0">This document updates RFC 5340, "OSPF for IPv6", and R
FC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodin
gs for the base OSPFv3 unicast support and OSPFv3 address family support.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8362"/>
<seriesInfo name="DOI" value="10.17487/RFC8362"/>
</reference>
<reference anchor="RFC8377" target="https://www.rfc-editor.org/info/rfc837
7" quoteTitle="true" derivedAnchor="RFC8377">
<front>
<title>Transparent Interconnection of Lots of Links (TRILL): Multi-Top
ology</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Zhang" fullname="M. Zhang">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Banerjee" fullname="A. Banerjee">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t indent="0">This document specifies extensions to the IETF TRILL (
Transparent Interconnection of Lots of Links) protocol to support multi-topology
routing of unicast and multi-destination traffic based on IS-IS (Intermediate S
ystem to Intermediate System) multi-topology specified in RFC 5120. This docume
nt updates RFCs 6325 and 7177.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8377"/>
<seriesInfo name="DOI" value="10.17487/RFC8377"/>
</reference>
<reference anchor="RFC8378" target="https://www.rfc-editor.org/info/rfc837
8" quoteTitle="true" derivedAnchor="RFC8378">
<front>
<title>Signal-Free Locator/ID Separation Protocol (LISP) Multicast</ti
tle>
<author initials="V." surname="Moreno" fullname="V. Moreno">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Farinacci" fullname="D. Farinacci">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="May"/>
<abstract>
<t indent="0">When multicast sources and receivers are active at Loc
ator/ID Separation Protocol (LISP) sites, the core network is required to use na
tive multicast so packets can be delivered from sources to group members. When
multicast is not available to connect the multicast sites together, a signal-fre
e mechanism can be used to allow traffic to flow between sites. The mechanism d
escribed in this document uses unicast replication and encapsulation over the co
re network for the data plane and uses the LISP mapping database system so encap
sulators at the source LISP multicast site can find decapsulators at the receive
r LISP multicast sites.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8378"/>
<seriesInfo name="DOI" value="10.17487/RFC8378"/>
</reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc840
2" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t indent="0">Segment Routing (SR) leverages the source routing para
digm. A node steers a packet through an ordered list of instructions, called "s
egments". A segment can represent any instruction, topological or service based
. A segment can have a semantic local to an SR node or global within an SR doma
in. SR provides a mechanism that allows a flow to be restricted to a specific t
opological path, while maintaining per-flow state only at the ingress node(s) to
the SR domain.</t>
<t indent="0">SR can be directly applied to the MPLS architecture wi
th no change to the forwarding plane. A segment is encoded as an MPLS label. A
n ordered list of segments is encoded as a stack of labels. The segment to proc
ess is on the top of the stack. Upon completion of a segment, the related label
is popped from the stack.</t>
<t indent="0">SR can be applied to the IPv6 architecture, with a new
type of routing header. A segment is encoded as an IPv6 address. An ordered l
ist of segments is encoded as an ordered list of IPv6 addresses in the routing h
eader. The active segment is indicated by the Destination Address (DA) of the p
acket. The next active segment is indicated by a pointer in the new routing hea
der.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC8410" target="https://www.rfc-editor.org/info/rfc841
0" quoteTitle="true" derivedAnchor="RFC8410">
<front>
<title>Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for
Use in the Internet X.509 Public Key Infrastructure</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies algorithm identifiers and ASN.
1 encoding formats for elliptic curve constructs using the curve25519 and curve4
48 curves. The signature algorithms covered are Ed25519 and Ed448. The key agr
eement algorithms covered are X25519 and X448. The encoding for public key, priv
ate key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is pro
vided.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8410"/>
<seriesInfo name="DOI" value="10.17487/RFC8410"/>
</reference>
<reference anchor="RFC8411" target="https://www.rfc-editor.org/info/rfc841
1" quoteTitle="true" derivedAnchor="RFC8411">
<front>
<title>IANA Registration for the Cryptographic Algorithm Object Identi
fier Range</title>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Andrews" fullname="R. Andrews">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">When the Curdle Security Working Group was chartered,
a range of object identifiers was donated by DigiCert, Inc. for the purpose of r
egistering the Edwards Elliptic Curve key agreement and signature algorithms. T
his donated set of OIDs allowed for shorter values than would be possible using
the existing S/MIME or PKIX arcs. This document describes the donated range and
the identifiers that were assigned from that range, transfers control of that r
ange to IANA, and establishes IANA allocation policies for any future assignment
s within that range.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8411"/>
<seriesInfo name="DOI" value="10.17487/RFC8411"/>
</reference>
<reference anchor="RFC8429" target="https://www.rfc-editor.org/info/rfc842
9" quoteTitle="true" derivedAnchor="RFC8429">
<front>
<title>Deprecate Triple-DES (3DES) and RC4 in Kerberos</title>
<author initials="B." surname="Kaduk" fullname="B. Kaduk">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Short" fullname="M. Short">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">The triple-DES (3DES) and RC4 encryption types are ste
adily weakening in cryptographic strength, and the deprecation process should be
gin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic
status, as none of the encryption types it specifies should be used, and RFC 39
61 has been updated to note the deprecation of the triple-DES encryption types.
RFC 4120 is likewise updated to remove the recommendation to implement triple-D
ES encryption and checksum types.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="218"/>
<seriesInfo name="RFC" value="8429"/>
<seriesInfo name="DOI" value="10.17487/RFC8429"/>
</reference>
<reference anchor="RFC8441" target="https://www.rfc-editor.org/info/rfc844
1" quoteTitle="true" derivedAnchor="RFC8441">
<front>
<title>Bootstrapping WebSockets with HTTP/2</title>
<author initials="P." surname="McManus" fullname="P. McManus">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="September"/>
<abstract>
<t indent="0">This document defines a mechanism for running the WebS
ocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8441"/>
<seriesInfo name="DOI" value="10.17487/RFC8441"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc844
6" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport L
ayer Security (TLS) protocol. TLS allows client/server applications to communic
ate over the Internet in a way that is designed to prevent eavesdropping, tamper
ing, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsolete
s RFCs 5077, 5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8453" target="https://www.rfc-editor.org/info/rfc845
3" quoteTitle="true" derivedAnchor="RFC8453">
<front>
<title>Framework for Abstraction and Control of TE Networks (ACTN)</ti
tle>
<author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">Traffic Engineered (TE) networks have a variety of mec
hanisms to facilitate the separation of the data plane and control plane. They
also have a range of management and provisioning protocols to configure and acti
vate network resources. These mechanisms represent key technologies for enablin
g flexible and dynamic networking. The term "Traffic Engineered network" refers
to a network that uses any connection-oriented technology under the control of
a distributed or centralized control plane to support dynamic provisioning of en
d-to- end connectivity.</t>
<t indent="0">Abstraction of network resources is a technique that c
an be applied to a single network domain or across multiple domains to create a
single virtualized network that is under the control of a network operator or th
e customer of the operator that actually owns the network resources.</t>
<t indent="0">This document provides a framework for Abstraction and
Control of TE Networks (ACTN) to support virtual network services and connectiv
ity services.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8453"/>
<seriesInfo name="DOI" value="10.17487/RFC8453"/>
</reference>
<reference anchor="RFC8455" target="https://www.rfc-editor.org/info/rfc845
5" quoteTitle="true" derivedAnchor="RFC8455">
<front>
<title>Terminology for Benchmarking Software-Defined Networking (SDN)
Controller Performance</title>
<author initials="V." surname="Bhuvaneswaran" fullname="V. Bhuvaneswar
an">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Basil" fullname="A. Basil">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Tassinari" fullname="M. Tassinari">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Banks" fullname="S. Banks">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document defines terminology for benchmarking a S
oftware-Defined Networking (SDN) controller's control-plane performance. It ext
ends the terminology already defined in RFC 7426 for the purpose of benchmarking
SDN Controllers. The terms provided in this document help to benchmark an SDN
Controller's performance independently of the controller's supported protocols a
nd/or network services.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8455"/>
<seriesInfo name="DOI" value="10.17487/RFC8455"/>
</reference>
<reference anchor="RFC8456" target="https://www.rfc-editor.org/info/rfc845
6" quoteTitle="true" derivedAnchor="RFC8456">
<front>
<title>Benchmarking Methodology for Software-Defined Networking (SDN)
Controller Performance</title>
<author initials="V." surname="Bhuvaneswaran" fullname="V. Bhuvaneswar
an">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Basil" fullname="A. Basil">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Tassinari" fullname="M. Tassinari">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Banks" fullname="S. Banks">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document defines methodologies for benchmarking t
he control-plane performance of Software-Defined Networking (SDN) Controllers.
The SDN Controller is a core component in the SDN architecture that controls the
behavior of the network. SDN Controllers have been implemented with many varyi
ng designs in order to achieve their intended network functionality. Hence, the
authors of this document have taken the approach of considering an SDN Controll
er to be a black box, defining the methodology in a manner that is agnostic to p
rotocols and network services supported by controllers. This document provides
a method for measuring the performance of all controller implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8456"/>
<seriesInfo name="DOI" value="10.17487/RFC8456"/>
</reference>
<reference anchor="RFC8466" target="https://www.rfc-editor.org/info/rfc846
6" quoteTitle="true" derivedAnchor="RFC8466">
<front>
<title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) S
ervice Delivery</title>
<author initials="B." surname="Wen" fullname="B. Wen">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fioccola" fullname="G. Fioccola" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Xie" fullname="C. Xie">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Jalil" fullname="L. Jalil">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document defines a YANG data model that can be us
ed to configure a Layer 2 provider-provisioned VPN service. It is up to a manag
ement system to take this as an input and generate specific configuration models
to configure the different network elements to deliver the service. How this c
onfiguration of network elements is done is out of scope for this document.</t>
<t indent="0">The YANG data model defined in this document includes
support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint
Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Lab
el Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as describe
d in RFCs 4761 and 6624.</t>
<t indent="0">The YANG data model defined in this document conforms
to the Network Management Datastore Architecture defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8466"/>
<seriesInfo name="DOI" value="10.17487/RFC8466"/>
</reference>
<reference anchor="RFC8468" target="https://www.rfc-editor.org/info/rfc846
8" quoteTitle="true" derivedAnchor="RFC8468">
<front>
<title>IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Perfo
rmance Metrics (IPPM) Framework</title>
<author initials="A." surname="Morton" fullname="A. Morton">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Fabini" fullname="J. Fabini">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Elkins" fullname="N. Elkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Ackermann" fullname="M. Ackermann">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Hegde" fullname="V. Hegde">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This memo updates the IP Performance Metrics (IPPM) fr
amework defined by RFC 2330 with new considerations for measurement methodology
and testing. It updates the definition of standard-formed packets to include IP
v6 packets, deprecates the definition of minimal IP packet, and augments disting
uishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo
identifies that IPv4-IPv6 coexistence can challenge measurements within the sco
pe of the IPPM framework. Example use cases include, but are not limited to, IPv
4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression an
d use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and
excluded from the standard-formed packet evaluation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8468"/>
<seriesInfo name="DOI" value="10.17487/RFC8468"/>
</reference>
<reference anchor="RFC8471" target="https://www.rfc-editor.org/info/rfc847
1" quoteTitle="true" derivedAnchor="RFC8471">
<front>
<title>The Token Binding Protocol Version 1.0</title>
<author initials="A." surname="Popov" fullname="A. Popov" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Nystroem" fullname="M. Nystroem">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Balfanz" fullname="D. Balfanz">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hodges" fullname="J. Hodges">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document specifies version 1.0 of the Token Bindi
ng protocol. The Token Binding protocol allows client/server applications to cre
ate long-lived, uniquely identifiable TLS bindings spanning multiple TLS session
s and connections. Applications are then enabled to cryptographically bind secu
rity tokens to the TLS layer, preventing token export and replay attacks. To pr
otect privacy, the Token Binding identifiers are only conveyed over TLS and can
be reset by the user at any time.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8471"/>
<seriesInfo name="DOI" value="10.17487/RFC8471"/>
</reference>
<reference anchor="RFC8472" target="https://www.rfc-editor.org/info/rfc847
2" quoteTitle="true" derivedAnchor="RFC8472">
<front>
<title>Transport Layer Security (TLS) Extension for Token Binding Prot
ocol Negotiation</title>
<author initials="A." surname="Popov" fullname="A. Popov" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Nystroem" fullname="M. Nystroem">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Balfanz" fullname="D. Balfanz">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document specifies a Transport Layer Security (TL
S) extension for the negotiation of Token Binding protocol version and key param
eters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the
scope of this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8472"/>
<seriesInfo name="DOI" value="10.17487/RFC8472"/>
</reference>
<reference anchor="RFC8479" target="https://www.rfc-editor.org/info/rfc847
9" quoteTitle="true" derivedAnchor="RFC8479">
<front>
<title>Storing Validation Parameters in PKCS#8</title>
<author initials="N." surname="Mavrogiannopoulos" fullname="N. Mavrogi
annopoulos">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="September"/>
<abstract>
<t indent="0">This memo describes a method of storing parameters nee
ded for private-key validation in the Private-Key Information Syntax Specificati
on as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alte
rnative implementation of the Private-Key Information Syntax Specification as de
fined in RFC 5958.</t>
<t indent="0">The approach described in this document encodes the pa
rameters under a private enterprise extension and does not form part of a formal
standard.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8479"/>
<seriesInfo name="DOI" value="10.17487/RFC8479"/>
</reference>
<reference anchor="RFC8483" target="https://www.rfc-editor.org/info/rfc848
3" quoteTitle="true" derivedAnchor="RFC8483">
<front>
<title>Yeti DNS Testbed</title>
<author initials="L." surname="Song" fullname="L. Song" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Liu" fullname="D. Liu">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Vixie" fullname="P. Vixie">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Kato" fullname="A. Kato">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Kerr" fullname="S. Kerr">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">Yeti DNS is an experimental, non-production root serve
r testbed that provides an environment where technical and operational experimen
ts can safely be performed without risk to production root server infrastructure
. This document aims solely to document the technical and operational experienc
e of deploying a system that is similar to but different from the Root Server sy
stem (on which the Internet's Domain Name System is designed and built).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8483"/>
<seriesInfo name="DOI" value="10.17487/RFC8483"/>
</reference>
<reference anchor="RFC8492" target="https://www.rfc-editor.org/info/rfc849
2" quoteTitle="true" derivedAnchor="RFC8492">
<front>
<title>Secure Password Ciphersuites for Transport Layer Security (TLS)
</title>
<author initials="D." surname="Harkins" fullname="D. Harkins" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="February"/>
<abstract>
<t indent="0">This memo defines several new ciphersuites for the Tra
nsport Layer Security (TLS) protocol to support certificateless, secure authenti
cation using only a simple, low-entropy password. The exchange is called "TLS-P
WD". The ciphersuites are all based on an authentication and key exchange proto
col, named "dragonfly", that is resistant to offline dictionary attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8492"/>
<seriesInfo name="DOI" value="10.17487/RFC8492"/>
</reference>
<reference anchor="RFC8493" target="https://www.rfc-editor.org/info/rfc849
3" quoteTitle="true" derivedAnchor="RFC8493">
<front>
<title>The BagIt File Packaging Format (V1.0)</title>
<author initials="J." surname="Kunze" fullname="J. Kunze">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Littman" fullname="J. Littman">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Madden" fullname="E. Madden">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Scancella" fullname="J. Scancella">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Adams" fullname="C. Adams">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document describes BagIt, a set of hierarchical f
ile layout conventions for storage and transfer of arbitrary digital content. A
"bag" has just enough structure to enclose descriptive metadata "tags" and a fi
le "payload" but does not require knowledge of the payload's internal semantics.
This BagIt format is suitable for reliable storage and transfer.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8493"/>
<seriesInfo name="DOI" value="10.17487/RFC8493"/>
</reference>
<reference anchor="RFC8498" target="https://www.rfc-editor.org/info/rfc849
8" quoteTitle="true" derivedAnchor="RFC8498">
<front>
<title>A P-Served-User Header Field Parameter for an Originating Call
Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)</title>
<author initials="M." surname="Mohali" fullname="M. Mohali">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="February"/>
<abstract>
<t indent="0">The P-Served-User header field was defined based on a
requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedi
a Subsystem) in order to convey the identity of the served user, his/ her regist
ration state, and the session case that applies to that particular communication
session and application invocation. A session case is metadata that captures t
he status of the session of a served user regardless of whether or not the serve
d user is registered or the session originates or terminates with the served use
r. This document updates RFC 5502 by defining a new P-Served-User header field
parameter, "orig-cdiv". The parameter conveys the session case used by a proxy
when handling an originating session after Call Diversion (CDIV) services have b
een invoked for the served user. This document also fixes the ABNF in RFC 5502
and provides more guidance for using the P-Served-User header field in IP networ
ks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8498"/>
<seriesInfo name="DOI" value="10.17487/RFC8498"/>
</reference>
<reference anchor="RFCYEAR" target="https://www.rfc-editor.org/rfcs-per-ye
ar/" quoteTitle="true" derivedAnchor="RFCYEAR">
<front>
<title>Number of RFC Published per YEAR</title>
<author>
<organization showOnFrontPage="true">RFC Editor</organization>
</author>
</front>
</reference>
<reference anchor="SSCH" target="https://www.semanticscholar.org/" quoteTi
tle="true" derivedAnchor="SSCH">
<front>
<title>Semantic Scholar | AI-Powered Research Tool</title>
<author>
<organization showOnFrontPage="true">Allen Institute for AI</organiz
ation>
</author>
</front>
</reference>
<reference anchor="I-D.ietf-rtgwg-segment-routing-ti-lfa" quoteTitle="true
" target="https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-05
" derivedAnchor="TI-LFA">
<front>
<title>Topology Independent Fast Reroute using Segment Routing</title>
<author fullname="Stephane Litkowski">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Ahmed Bashandy">
<organization showOnFrontPage="true">Individual</organization>
</author>
<author fullname="Clarence Filsfils">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Bruno Decraene">
<organization showOnFrontPage="true">Orange</organization>
</author>
<author fullname="Daniel Voyer">
<organization showOnFrontPage="true">Bell Canada</organization>
</author>
<date month="November" day="15" year="2020"/>
<abstract>
<t indent="0"> This document presents Topology Independent Loop-fr
ee Alternate Fast
Re-route (TI-LFA), aimed at providing protection of node and
adjacency segments within the Segment Routing (SR) framework. This
Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
(DLFA). It extends these concepts to provide guaranteed coverage in
any IGP network. A key aspect of TI-LFA is the FRR path selection
approach establishing protection over the expected post-convergence
paths from the point of local repair, dramatically reducing the
operational need to control the tie-breaks among various FRR options.
<references title='Informative References'> </t>
</abstract>
<reference anchor="TRKR" target="https://datatracker.ietf.org/"> </front>
<front> <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-segment-routin
<title>IETF Data Tracker</title> g-ti-lfa-05"/>
<author > <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ie
<organization>IETF</organization> tf-rtgwg-segment-routing-ti-lfa-05.txt"/>
</author> <refcontent>Work in Progress</refcontent>
<date year="2020"/> </reference>
</front> <reference anchor="TLS13IMP" target="https://github.com/tlswg/tlswg-wiki/b
</reference> lob/master/IMPLEMENTATIONS.md" quoteTitle="true" derivedAnchor="TLS13IMP">
<reference anchor="SSCH" target="https://www.semanticscholar.org/"> <front>
<front> <title>TLS 1.3 Implementations</title>
<title>Semantic Scholar</title> <author>
<author > <organization showOnFrontPage="true">TLS WG</organization>
<organization>Allen Institute for AI</organization> </author>
</author> <date day="14" month="October" year="2019"/>
<date year="2020"/> </front>
</front> <seriesInfo name="commit" value="dcb7890"/>
</reference> </reference>
<reference anchor="TLS13IMP" target="https://github.com/tlswg/tlswg-wiki/blob/ma <reference anchor="TRKR" target="https://datatracker.ietf.org/" quoteTitle
ster/IMPLEMENTATIONS.md"> ="true" derivedAnchor="TRKR">
<front> <front>
<title>TLS 1.3 Implementations</title> <title>IETF Datatracker</title>
<author > <author>
<organization>TLS WG</organization> <organization showOnFrontPage="true">IETF</organization>
</author> </author>
<date year="2020"/> </front>
</front> </reference>
</reference>
<reference anchor="RFCYEAR" target="https://www.rfc-editor.org/rfcs-per-year/">
<front>
<title>Number of RFC Published per YEAR</title>
<author >
<organization>RFC Editor</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="IETFCOUNT" target="https://www.ietf.org/how/meetings/past/">
<front>
<title>Past IETF Meetings</title>
<author >
<organization>IETF</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="RFC8411" target='https://www.rfc-editor.org/info/rfc8411'>
<front>
<title>IANA Registration for the Cryptographic Algorithm Object Identifier Range
</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<author initials='R.' surname='Andrews' fullname='R. Andrews'><organization /></
author>
<date year='2018' month='August' />
<abstract><t>When the Curdle Security Working Group was chartered, a range of ob
ject identifiers was donated by DigiCert, Inc. for the purpose of registering th
e Edwards Elliptic Curve key agreement and signature algorithms. This donated s
et of OIDs allowed for shorter values than would be possible using the existing
S/MIME or PKIX arcs. This document describes the donated range and the identifi
ers that were assigned from that range, transfers control of that range to IANA,
and establishes IANA allocation policies for any future assignments within that
range.</t></abstract>
</front>
<seriesInfo name='RFC' value='8411'/>
<seriesInfo name='DOI' value='10.17487/RFC8411'/>
</reference>
<reference anchor="RFC8410" target='https://www.rfc-editor.org/info/rfc8410'>
<front>
<title>Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the
Internet X.509 Public Key Infrastructure</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization
/></author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<date year='2018' month='August' />
<abstract><t>This document specifies algorithm identifiers and ASN.1 encoding fo
rmats for elliptic curve constructs using the curve25519 and curve448 curves. T
he signature algorithms covered are Ed25519 and Ed448. The key agreement algori
thms covered are X25519 and X448. The encoding for public key, private key, and
Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.</t></a
bstract>
</front>
<seriesInfo name='RFC' value='8410'/>
<seriesInfo name='DOI' value='10.17487/RFC8410'/>
</reference>
<reference anchor="RFC8456" target='https://www.rfc-editor.org/info/rfc8456'>
<front>
<title>Benchmarking Methodology for Software-Defined Networking (SDN) Controller
Performance</title>
<author initials='V.' surname='Bhuvaneswaran' fullname='V. Bhuvaneswaran'><organ
ization /></author>
<author initials='A.' surname='Basil' fullname='A. Basil'><organization /></auth
or>
<author initials='M.' surname='Tassinari' fullname='M. Tassinari'><organization
/></author>
<author initials='V.' surname='Manral' fullname='V. Manral'><organization /></au
thor>
<author initials='S.' surname='Banks' fullname='S. Banks'><organization /></auth
or>
<date year='2018' month='October' />
<abstract><t>This document defines methodologies for benchmarking the control-pl
ane performance of Software-Defined Networking (SDN) Controllers. The SDN Contr
oller is a core component in the SDN architecture that controls the behavior of
the network. SDN Controllers have been implemented with many varying designs in
order to achieve their intended network functionality. Hence, the authors of t
his document have taken the approach of considering an SDN Controller to be a bl
ack box, defining the methodology in a manner that is agnostic to protocols and
network services supported by controllers. This document provides a method for
measuring the performance of all controller implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8456'/>
<seriesInfo name='DOI' value='10.17487/RFC8456'/>
</reference>
<reference anchor="RFC8455" target='https://www.rfc-editor.org/info/rfc8455'>
<front>
<title>Terminology for Benchmarking Software-Defined Networking (SDN) Controller
Performance</title>
<author initials='V.' surname='Bhuvaneswaran' fullname='V. Bhuvaneswaran'><organ
ization /></author>
<author initials='A.' surname='Basil' fullname='A. Basil'><organization /></auth
or>
<author initials='M.' surname='Tassinari' fullname='M. Tassinari'><organization
/></author>
<author initials='V.' surname='Manral' fullname='V. Manral'><organization /></au
thor>
<author initials='S.' surname='Banks' fullname='S. Banks'><organization /></auth
or>
<date year='2018' month='October' />
<abstract><t>This document defines terminology for benchmarking a Software-Defin
ed Networking (SDN) controller's control-plane performance. It extends the term
inology already defined in RFC 7426 for the purpose of benchmarking SDN Controll
ers. The terms provided in this document help to benchmark an SDN Controller's
performance independently of the controller's supported protocols and/or network
services.</t></abstract>
</front>
<seriesInfo name='RFC' value='8455'/>
<seriesInfo name='DOI' value='10.17487/RFC8455'/>
</reference>
<reference anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
</author>
<date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and mess
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2
implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>
<reference anchor="RFC8355" target='https://www.rfc-editor.org/info/rfc8355'>
<front>
<title>Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Netw
orks</title>
<author initials='C.' surname='Filsfils' fullname='C. Filsfils' role='editor'><o
rganization /></author>
<author initials='S.' surname='Previdi' fullname='S. Previdi' role='editor'><org
anization /></author>
<author initials='B.' surname='Decraene' fullname='B. Decraene'><organization />
</author>
<author initials='R.' surname='Shakir' fullname='R. Shakir'><organization /></au
thor>
<date year='2018' month='March' />
<abstract><t>This document identifies and describes the requirements for a set o
f use cases related to Segment Routing network resiliency on Source Packet Routi
ng in Networking (SPRING) networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='8355'/>
<seriesInfo name='DOI' value='10.17487/RFC8355'/>
</reference>
<reference anchor="RFC8441" target='https://www.rfc-editor.org/info/rfc8441'>
<front>
<title>Bootstrapping WebSockets with HTTP/2</title>
<author initials='P.' surname='McManus' fullname='P. McManus'><organization /></
author>
<date year='2018' month='September' />
<abstract><t>This document defines a mechanism for running the WebSocket Protoco
l (RFC 6455) over a single stream of an HTTP/2 connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='8441'/>
<seriesInfo name='DOI' value='10.17487/RFC8441'/>
</reference>
<reference anchor="RFC6455" target='https://www.rfc-editor.org/info/rfc6455'>
<front>
<title>The WebSocket Protocol</title>
<author initials='I.' surname='Fette' fullname='I. Fette'><organization /></auth
or>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'><organization />
</author>
<date year='2011' month='December' />
<abstract><t>The WebSocket Protocol enables two-way communication between a clie
nt running untrusted code in a controlled environment to a remote host that has
opted-in to communications from that code. The security model used for this is
the origin-based security model commonly used by web browsers. The protocol con
sists of an opening handshake followed by basic message framing, layered over TC
P. The goal of this technology is to provide a mechanism for browser-based appl
ications that need two-way communication with servers that does not rely on open
ing multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s and
long polling). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6455'/>
<seriesInfo name='DOI' value='10.17487/RFC6455'/>
</reference>
<reference anchor="RFC8324" target='https://www.rfc-editor.org/info/rfc8324'>
<front>
<title>DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching,
and Root Structure: Time for Another Look?</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></
author>
<date year='2018' month='February' />
<abstract><t>The basic design of the Domain Name System was completed almost 30
years ago. The last half of that period has been characterized by significant c
hanges in requirements and expectations, some of which either require changes to
how the DNS is used or can be accommodated only poorly or not at all. This doc
ument asks the question of whether it is time to either redesign and replace the
DNS to match contemporary requirements and expectations (rather than continuing
to try to design and implement incremental patches that are not fully satisfact
ory) or draw some clear lines about functionality that is not really needed or t
hat should be performed in some other way.</t></abstract>
</front>
<seriesInfo name='RFC' value='8324'/>
<seriesInfo name='DOI' value='10.17487/RFC8324'/>
</reference>
<reference anchor="RFC8377" target='https://www.rfc-editor.org/info/rfc8377'>
<front>
<title>Transparent Interconnection of Lots of Links (TRILL): Multi-Topology</tit
le>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz
ation /></author>
<author initials='M.' surname='Zhang' fullname='M. Zhang'><organization /></auth
or>
<author initials='A.' surname='Banerjee' fullname='A. Banerjee'><organization />
</author>
<date year='2018' month='July' />
<abstract><t>This document specifies extensions to the IETF TRILL (Transparent I
nterconnection of Lots of Links) protocol to support multi-topology routing of u
nicast and multi-destination traffic based on IS-IS (Intermediate System to Inte
rmediate System) multi-topology specified in RFC 5120. This document updates RF
Cs 6325 and 7177.</t></abstract>
</front>
<seriesInfo name='RFC' value='8377'/>
<seriesInfo name='DOI' value='10.17487/RFC8377'/>
</reference>
<reference anchor="RFC8498" target='https://www.rfc-editor.org/info/rfc8498'>
<front>
<title>A P-Served-User Header Field Parameter for an Originating Call Diversion
(CDIV) Session Case in the Session Initiation Protocol (SIP)</title>
<author initials='M.' surname='Mohali' fullname='M. Mohali'><organization /></au
thor>
<date year='2019' month='February' />
<abstract><t>The P-Served-User header field was defined based on a requirement f
rom the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem)
in order to convey the identity of the served user, his/ her registration state,
and the session case that applies to that particular communication session and
application invocation. A session case is metadata that captures the status of
the session of a served user regardless of whether or not the served user is reg
istered or the session originates or terminates with the served user. This docu
ment updates RFC 5502 by defining a new P-Served-User header field parameter, &q
uot;orig-cdiv&quot;. The parameter conveys the session case used by a proxy whe
n handling an originating session after Call Diversion (CDIV) services have been
invoked for the served user. This document also fixes the ABNF in RFC 5502 and
provides more guidance for using the P-Served-User header field in IP networks.
</t></abstract>
</front>
<seriesInfo name='RFC' value='8498'/>
<seriesInfo name='DOI' value='10.17487/RFC8498'/>
</reference>
<reference anchor="RFC8479" target='https://www.rfc-editor.org/info/rfc8479'>
<front>
<title>Storing Validation Parameters in PKCS#8</title>
<author initials='N.' surname='Mavrogiannopoulos' fullname='N. Mavrogiannopoulos
'><organization /></author>
<date year='2018' month='September' />
<abstract><t>This memo describes a method of storing parameters needed for priva
te-key validation in the Private-Key Information Syntax Specification as defined
in PKCS#8 format (RFC 5208). It is equally applicable to the alternative imple
mentation of the Private-Key Information Syntax Specification as defined in RFC
5958.</t><t>The approach described in this document encodes the parameters under
a private enterprise extension and does not form part of a formal standard.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8479'/>
<seriesInfo name='DOI' value='10.17487/RFC8479'/>
</reference>
<reference anchor="RFC8453" target='https://www.rfc-editor.org/info/rfc8453'>
<front>
<title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
<author initials='D.' surname='Ceccarelli' fullname='D. Ceccarelli' role='editor
'><organization /></author>
<author initials='Y.' surname='Lee' fullname='Y. Lee' role='editor'><organizatio
n /></author>
<date year='2018' month='August' />
<abstract><t>Traffic Engineered (TE) networks have a variety of mechanisms to fa
cilitate the separation of the data plane and control plane. They also have a r
ange of management and provisioning protocols to configure and activate network
resources. These mechanisms represent key technologies for enabling flexible an
d dynamic networking. The term &quot;Traffic Engineered network&quot; refers to
a network that uses any connection-oriented technology under the control of a d
istributed or centralized control plane to support dynamic provisioning of end-t
o- end connectivity.</t><t>Abstraction of network resources is a technique that
can be applied to a single network domain or across multiple domains to create a
single virtualized network that is under the control of a network operator or t
he customer of the operator that actually owns the network resources.</t><t>This
document provides a framework for Abstraction and Control of TE Networks (ACTN)
to support virtual network services and connectivity services.</t></abstract>
</front>
<seriesInfo name='RFC' value='8453'/>
<seriesInfo name='DOI' value='10.17487/RFC8453'/>
</reference>
<reference anchor="RFC8429" target='https://www.rfc-editor.org/info/rfc8429'>
<front>
<title>Deprecate Triple-DES (3DES) and RC4 in Kerberos</title>
<author initials='B.' surname='Kaduk' fullname='B. Kaduk'><organization /></auth
or>
<author initials='M.' surname='Short' fullname='M. Short'><organization /></auth
or>
<date year='2018' month='October' />
<abstract><t>The triple-DES (3DES) and RC4 encryption types are steadily weakeni
ng in cryptographic strength, and the deprecation process should begin for their
use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as n
one of the encryption types it specifies should be used, and RFC 3961 has been u
pdated to note the deprecation of the triple-DES encryption types. RFC 4120 is
likewise updated to remove the recommendation to implement triple-DES encryption
and checksum types.</t></abstract>
</front>
<seriesInfo name='BCP' value='218'/>
<seriesInfo name='RFC' value='8429'/>
<seriesInfo name='DOI' value='10.17487/RFC8429'/>
</reference>
<reference anchor="RFC8312" target='https://www.rfc-editor.org/info/rfc8312'>
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author initials='I.' surname='Rhee' fullname='I. Rhee'><organization /></author
>
<author initials='L.' surname='Xu' fullname='L. Xu'><organization /></author>
<author initials='S.' surname='Ha' fullname='S. Ha'><organization /></author>
<author initials='A.' surname='Zimmermann' fullname='A. Zimmermann'><organizatio
n /></author>
<author initials='L.' surname='Eggert' fullname='L. Eggert'><organization /></au
thor>
<author initials='R.' surname='Scheffenegger' fullname='R. Scheffenegger'><organ
ization /></author>
<date year='2018' month='February' />
<abstract><t>CUBIC is an extension to the current TCP standards. It differs fro
m the current TCP standards only in the congestion control algorithm on the send
er side. In particular, it uses a cubic function instead of a linear window inc
rease function of the current TCP standards to improve scalability and stability
under fast and long-distance networks. CUBIC and its predecessor algorithm hav
e been adopted as defaults by Linux and have been used for many years. This doc
ument provides a specification of CUBIC to enable third-party implementations an
d to solicit community feedback through experimentation on the performance of CU
BIC.</t></abstract>
</front>
<seriesInfo name='RFC' value='8312'/>
<seriesInfo name='DOI' value='10.17487/RFC8312'/>
</reference>
<reference anchor="RFC8492" target='https://www.rfc-editor.org/info/rfc8492'>
<front>
<title>Secure Password Ciphersuites for Transport Layer Security (TLS)</title>
<author initials='D.' surname='Harkins' fullname='D. Harkins' role='editor'><org
anization /></author>
<date year='2019' month='February' />
<abstract><t>This memo defines several new ciphersuites for the Transport Layer
Security (TLS) protocol to support certificateless, secure authentication using
only a simple, low-entropy password. The exchange is called &quot;TLS-PWD&quot;
. The ciphersuites are all based on an authentication and key exchange protocol
, named &quot;dragonfly&quot;, that is resistant to offline dictionary attacks.<
/t></abstract>
</front>
<seriesInfo name='RFC' value='8492'/>
<seriesInfo name='DOI' value='10.17487/RFC8492'/>
</reference>
<reference anchor="RFC8378" target='https://www.rfc-editor.org/info/rfc8378'>
<front>
<title>Signal-Free Locator/ID Separation Protocol (LISP) Multicast</title>
<author initials='V.' surname='Moreno' fullname='V. Moreno'><organization /></au
thor>
<author initials='D.' surname='Farinacci' fullname='D. Farinacci'><organization
/></author>
<date year='2018' month='May' />
<abstract><t>When multicast sources and receivers are active at Locator/ID Separ
ation Protocol (LISP) sites, the core network is required to use native multicas
t so packets can be delivered from sources to group members. When multicast is
not available to connect the multicast sites together, a signal-free mechanism c
an be used to allow traffic to flow between sites. The mechanism described in t
his document uses unicast replication and encapsulation over the core network fo
r the data plane and uses the LISP mapping database system so encapsulators at t
he source LISP multicast site can find decapsulators at the receiver LISP multic
ast sites.</t></abstract>
</front>
<seriesInfo name='RFC' value='8378'/>
<seriesInfo name='DOI' value='10.17487/RFC8378'/>
</reference>
<reference anchor="RFC8361" target='https://www.rfc-editor.org/info/rfc8361'>
<front>
<title>Transparent Interconnection of Lots of Links (TRILL): Centralized Replica
tion for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic</
title>
<author initials='W.' surname='Hao' fullname='W. Hao'><organization /></author>
<author initials='Y.' surname='Li' fullname='Y. Li'><organization /></author>
<author initials='M.' surname='Durrani' fullname='M. Durrani'><organization /></
author>
<author initials='S.' surname='Gupta' fullname='S. Gupta'><organization /></auth
or>
<author initials='A.' surname='Qu' fullname='A. Qu'><organization /></author>
<date year='2018' month='April' />
<abstract><t>In Transparent Interconnection of Lots of Links (TRILL) active-acti
ve access, a Reverse Path Forwarding (RPF) check failure issue may occur when us
ing the pseudo-nickname mechanism specified in RFC 7781. This document describe
s a solution to resolve this RPF check failure issue through centralized replica
tion. All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, a
nd Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulatio
n. When the centralized node receives the BUM traffic, it decapsulates the pack
ets and forwards them to their destination RBridges using a distribution tree es
tablished per the TRILL base protocol (RFC 6325). To avoid RPF check failure on
an RBridge sitting between the ingress RBridge and the centralized replication n
ode, some change in the RPF calculation algorithm is required. RPF checks on ea
ch RBridge MUST be calculated as if the centralized node was the ingress RBridge
, instead of being calculated using the actual ingress RBridge. This document u
pdates RFC 6325.</t></abstract>
</front>
<seriesInfo name='RFC' value='8361'/>
<seriesInfo name='DOI' value='10.17487/RFC8361'/>
</reference>
<reference anchor="RFC8472" target='https://www.rfc-editor.org/info/rfc8472'>
<front>
<title>Transport Layer Security (TLS) Extension for Token Binding Protocol Negot
iation</title>
<author initials='A.' surname='Popov' fullname='A. Popov' role='editor'><organiz
ation /></author>
<author initials='M.' surname='Nystroem' fullname='M. Nystroem'><organization />
</author>
<author initials='D.' surname='Balfanz' fullname='D. Balfanz'><organization /></
author>
<date year='2018' month='October' />
<abstract><t>This document specifies a Transport Layer Security (TLS) extension
for the negotiation of Token Binding protocol version and key parameters. Negot
iation of Token Binding in TLS 1.3 and later versions is beyond the scope of thi
s document.</t></abstract>
</front>
<seriesInfo name='RFC' value='8472'/>
<seriesInfo name='DOI' value='10.17487/RFC8472'/>
</reference>
<reference anchor="RFC8471" target='https://www.rfc-editor.org/info/rfc8471'>
<front>
<title>The Token Binding Protocol Version 1.0</title>
<author initials='A.' surname='Popov' fullname='A. Popov' role='editor'><organiz
ation /></author>
<author initials='M.' surname='Nystroem' fullname='M. Nystroem'><organization />
</author>
<author initials='D.' surname='Balfanz' fullname='D. Balfanz'><organization /></
author>
<author initials='J.' surname='Hodges' fullname='J. Hodges'><organization /></au
thor>
<date year='2018' month='October' />
<abstract><t>This document specifies version 1.0 of the Token Binding protocol.
The Token Binding protocol allows client/server applications to create long-live
d, uniquely identifiable TLS bindings spanning multiple TLS sessions and connect
ions. Applications are then enabled to cryptographically bind security tokens t
o the TLS layer, preventing token export and replay attacks. To protect privacy
, the Token Binding identifiers are only conveyed over TLS and can be reset by t
he user at any time.</t></abstract>
</front>
<seriesInfo name='RFC' value='8471'/>
<seriesInfo name='DOI' value='10.17487/RFC8471'/>
</reference>
<reference anchor="RFC8466" target='https://www.rfc-editor.org/info/rfc8466'>
<front>
<title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Del
ivery</title>
<author initials='B.' surname='Wen' fullname='B. Wen'><organization /></author>
<author initials='G.' surname='Fioccola' fullname='G. Fioccola' role='editor'><o
rganization /></author>
<author initials='C.' surname='Xie' fullname='C. Xie'><organization /></author>
<author initials='L.' surname='Jalil' fullname='L. Jalil'><organization /></auth
or>
<date year='2018' month='October' />
<abstract><t>This document defines a YANG data model that can be used to configu
re a Layer 2 provider-provisioned VPN service. It is up to a management system
to take this as an input and generate specific configuration models to configure
the different network elements to deliver the service. How this configuration
of network elements is done is out of scope for this document.</t><t>The YANG da
ta model defined in this document includes support for point-to-point Virtual Pr
ivate Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs)
that use Pseudowires signaled using the Label Distribution Protocol (LDP) and th
e Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.</t><t>The YA
NG data model defined in this document conforms to the Network Management Datast
ore Architecture defined in RFC 8342.</t></abstract>
</front>
<seriesInfo name='RFC' value='8466'/>
<seriesInfo name='DOI' value='10.17487/RFC8466'/>
</reference>
<reference anchor="RFC8362" target='https://www.rfc-editor.org/info/rfc8362'>
<front>
<title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></au
thor>
<author initials='A.' surname='Roy' fullname='A. Roy'><organization /></author>
<author initials='D.' surname='Goethals' fullname='D. Goethals'><organization />
</author>
<author initials='V.' surname='Reddy Vallem' fullname='V. Reddy Vallem'><organiz
ation /></author>
<author initials='F.' surname='Baker' fullname='F. Baker'><organization /></auth
or>
<date year='2018' month='April' />
<abstract><t>OSPFv3 requires functional extension beyond what can readily be don
e with the fixed-format Link State Advertisement (LSA) as described in RFC 5340.
Without LSA extension, attributes associated with OSPFv3 links and advertised
IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-fo
rmat LSAs. This document extends the LSA format by encoding the existing OSPFv3
LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of
additional information with additional TLVs. Backward-compatibility mechanisms
are also described.</t><t>This document updates RFC 5340, &quot;OSPF for IPv6&q
uot;, and RFC 5838, &quot;Support of Address Families in OSPFv3&quot;, by provid
ing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address f
amily support.</t></abstract>
</front>
<seriesInfo name='RFC' value='8362'/>
<seriesInfo name='DOI' value='10.17487/RFC8362'/>
</reference>
<reference anchor="RFC8468" target='https://www.rfc-editor.org/info/rfc8468'>
<front>
<title>IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Met
rics (IPPM) Framework</title>
<author initials='A.' surname='Morton' fullname='A. Morton'><organization /></au
thor>
<author initials='J.' surname='Fabini' fullname='J. Fabini'><organization /></au
thor>
<author initials='N.' surname='Elkins' fullname='N. Elkins'><organization /></au
thor>
<author initials='M.' surname='Ackermann' fullname='M. Ackermann'><organization
/></author>
<author initials='V.' surname='Hegde' fullname='V. Hegde'><organization /></auth
or>
<date year='2018' month='November' />
<abstract><t>This memo updates the IP Performance Metrics (IPPM) framework defin
ed by RFC 2330 with new considerations for measurement methodology and testing.
It updates the definition of standard-formed packets to include IPv6 packets, d
eprecates the definition of minimal IP packet, and augments distinguishing aspec
ts, referred to as Type-P, for test packets in RFC 2330. This memo identifies t
hat IPv4-IPv6 coexistence can challenge measurements within the scope of the IPP
M framework. Example use cases include, but are not limited to, IPv4-IPv6 transl
ation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6
over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded fro
m the standard-formed packet evaluation.</t></abstract>
</front>
<seriesInfo name='RFC' value='8468'/>
<seriesInfo name='DOI' value='10.17487/RFC8468'/>
</reference>
<reference anchor="RFC8493" target='https://www.rfc-editor.org/info/rfc8493'>
<front>
<title>The BagIt File Packaging Format (V1.0)</title>
<author initials='J.' surname='Kunze' fullname='J. Kunze'><organization /></auth
or>
<author initials='J.' surname='Littman' fullname='J. Littman'><organization /></
author>
<author initials='E.' surname='Madden' fullname='E. Madden'><organization /></au
thor>
<author initials='J.' surname='Scancella' fullname='J. Scancella'><organization
/></author>
<author initials='C.' surname='Adams' fullname='C. Adams'><organization /></auth
or>
<date year='2018' month='October' />
<abstract><t>This document describes BagIt, a set of hierarchical file layout co
nventions for storage and transfer of arbitrary digital content. A &quot;bag&qu
ot; has just enough structure to enclose descriptive metadata &quot;tags&quot; a
nd a file &quot;payload&quot; but does not require knowledge of the payload's in
ternal semantics. This BagIt format is suitable for reliable storage and transf
er.</t></abstract>
</front>
<seriesInfo name='RFC' value='8493'/>
<seriesInfo name='DOI' value='10.17487/RFC8493'/>
</reference>
<reference anchor="RFC8483" target='https://www.rfc-editor.org/info/rfc8483'>
<front>
<title>Yeti DNS Testbed</title>
<author initials='L.' surname='Song' fullname='L. Song' role='editor'><organizat
ion /></author>
<author initials='D.' surname='Liu' fullname='D. Liu'><organization /></author>
<author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></auth
or>
<author initials='A.' surname='Kato' fullname='A. Kato'><organization /></author
>
<author initials='S.' surname='Kerr' fullname='S. Kerr'><organization /></author
>
<date year='2018' month='October' />
<abstract><t>Yeti DNS is an experimental, non-production root server testbed tha
t provides an environment where technical and operational experiments can safely
be performed without risk to production root server infrastructure. This docum
ent aims solely to document the technical and operational experience of deployin
g a system that is similar to but different from the Root Server system (on whic
h the Internet's Domain Name System is designed and built).</t></abstract>
</front>
<seriesInfo name='RFC' value='8483'/>
<seriesInfo name='DOI' value='10.17487/RFC8483'/>
</reference>
<reference anchor="RFC5326" target='https://www.rfc-editor.org/info/rfc5326'>
<front>
<title>Licklider Transmission Protocol - Specification</title>
<author initials='M.' surname='Ramadas' fullname='M. Ramadas'><organization /></
author>
<author initials='S.' surname='Burleigh' fullname='S. Burleigh'><organization />
</author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></
author>
<date year='2008' month='September' />
<abstract><t>This document describes the Licklider Transmission Protocol (LTP),
designed to provide retransmission-based reliability over links characterized by
extremely long message round-trip times (RTTs) and/or frequent interruptions in
connectivity. Since communication across interplanetary space is the most prom
inent example of this sort of environment, LTP is principally aimed at supportin
g &quot;long-haul&quot; reliable transmission in interplanetary space, but it ha
s applications in other environments as well.</t><t>This document is a product o
f the Delay Tolerant Networking Research Group and has been reviewed by that gro
up. No objections to its publication as an RFC were raised. This memo defines
an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='5326'/>
<seriesInfo name='DOI' value='10.17487/RFC5326'/>
</reference>
<reference anchor="RFC2267" target='https://www.rfc-editor.org/info/rfc2267'>
<front>
<title>Network Ingress Filtering: Defeating Denial of Service Attacks which empl
oy IP Source Address Spoofing</title>
<author initials='P.' surname='Ferguson' fullname='P. Ferguson'><organization />
</author>
<author initials='D.' surname='Senie' fullname='D. Senie'><organization /></auth
or>
<date year='1998' month='January' />
<abstract><t>This paper discusses a simple, effective, and straightforward metho
d for using ingress traffic filtering to prohibit DoS attacks which use forged I
P addresses to be propagated from 'behind' an Internet Service Provider's (ISP)
aggregation point. This memo provides information for the Internet community.
It does not specify an Internet standard of any kind.</t></abstract>
</front>
<seriesInfo name='RFC' value='2267'/>
<seriesInfo name='DOI' value='10.17487/RFC2267'/>
</reference>
<reference anchor="RFC2827" target='https://www.rfc-editor.org/info/rfc2827'>
<front>
<title>Network Ingress Filtering: Defeating Denial of Service Attacks which empl
oy IP Source Address Spoofing</title>
<author initials='P.' surname='Ferguson' fullname='P. Ferguson'><organization />
</author>
<author initials='D.' surname='Senie' fullname='D. Senie'><organization /></auth
or>
<date year='2000' month='May' />
<abstract><t>This paper discusses a simple, effective, and straightforward metho
d for using ingress traffic filtering to prohibit DoS (Denial of Service) attack
s which use forged IP addresses to be propagated from 'behind' an Internet Servi
ce Provider's (ISP) aggregation point. This document specifies an Internet Best
Current Practices for the Internet Community, and requests discussion and sugge
stions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='38'/>
<seriesInfo name='RFC' value='2827'/>
<seriesInfo name='DOI' value='10.17487/RFC2827'/>
</reference>
<reference anchor="RFC2330" target='https://www.rfc-editor.org/info/rfc2330'>
<front>
<title>Framework for IP Performance Metrics</title>
<author initials='V.' surname='Paxson' fullname='V. Paxson'><organization /></au
thor>
<author initials='G.' surname='Almes' fullname='G. Almes'><organization /></auth
or>
<author initials='J.' surname='Mahdavi' fullname='J. Mahdavi'><organization /></
author>
<author initials='M.' surname='Mathis' fullname='M. Mathis'><organization /></au
thor>
<date year='1998' month='May' />
<abstract><t>The purpose of this memo is to define a general framework for parti
cular metrics to be developed by the IETF's IP Performance Metrics effort. This
memo provides information for the Internet community. It does not specify an In
ternet standard of any kind.</t></abstract>
</front>
<seriesInfo name='RFC' value='2330'/>
<seriesInfo name='DOI' value='10.17487/RFC2330'/>
</reference>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">Many thanks to the authors of the
selected RFCs who were willing to
provide feedback on the process:
<contact fullname="Michael Ackermann"/>,
<contact fullname="Zafar Ali"/>,
<contact fullname="Sarah Banks"/>,
<contact fullname="Bruno Decraene"/>,
<contact fullname="Lars Eggert"/>,
<contact fullname="Nalini Elkins"/>,
<contact fullname="Joachim Fabini"/>,
<contact fullname="Dino Farinacci"/>,
<contact fullname="Clarence Filsfils"/>,
<contact fullname="Sujay Gupta"/>,
<contact fullname="Dan Harkins"/>,
<contact fullname="Vinayak Hegde"/>,
<contact fullname="Benjamin Kaduk"/>,
<contact fullname="John Klensin"/>,
<contact fullname="Acee Lindem"/>,
<contact fullname="Nikos Mavrogiannopoulos"/>,
<contact fullname="Patrick McManus"/>,
<contact fullname="Victor Moreno"/>,
<contact fullname="Al Morton"/>,
<contact fullname="Andrei Popov"/>,
<contact fullname="Eric Rescorla"/>,
<contact fullname="Michiko Short"/>,
<contact fullname="Bhuvaneswaran Vengainathan"/>,
<contact fullname="Lao Weiguo"/>, and
<contact fullname="Li Yizhou"/>.
Many thanks to <contact fullname="Adrian Farrel"/> for his useful advice, to <co
ntact fullname="Stephen Farrell"/> and <contact fullname="Colin Perkins"/> for t
heir guidance on the use of citations, and to <contact fullname="Dave Crocker"/>
for a comprehensive
review. Thanks also to <contact fullname="Alice Russo"/> and the RFC Editor team
for their work improving this document and checking the accuracy of the data.</
t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="C." surname="Huitema" fullname="Christian Huitema">
<organization showOnFrontPage="true">Private Octopus Inc.</organization>
<address>
<postal>
<street>427 Golfcourse Rd</street>
<city>Friday Harbor</city>
<region>WA</region>
<code>98250</code>
<country>United States of America</country>
</postal>
<email>huitema@huitema.net</email>
</address>
</author>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAJIHll8AC729e3PbSLIv+H99CoQ7Tox9gqQJ8O0bG7Oy/GjN+KFoqcc7
e2PjBERCFNokwQFAqTktn8+++cvMegAkZc/cG7djRpZIoFCoysr85bvb7Zo6
r1fZq+jtfbrapXVebKLiNkqjq3S9XWX4/Zd359FlWSx282wR5Zso6cdTk97c
lNn9K3zZxa1d/nRRzDfpmkZblOlt3b3b5XW2Trvl7byb4aJtWfyWzetuf2Lm
aZ0ti3L/ioa8LcyC/nxFQyd9Y6o63Sz+K10VG/pon1XG5NvyVVSXu6pO+v1Z
PzFpmaWvovfZJivTlfn68Cq62NRZucnq7hs82ph5scg3y1fRruqm1TzPzTZ/
Ff3Puph3oqgqyrrMbqtOVO3X8su8WK+zTV39f8aku/quKF+ZiP/r6r8RzbN6
FZ33op/lrdzn8sbnd2Ve1Xm6Ofi+KGkal2V+T68YfZ7XxXZX0XTnPXdFRbPJ
6lfRMJlE74vV7bzYlVUW/bJwV8zzmlbqXZkv0n30c1reFKX/rljQ87+cRbNp
MuoHH+82Ndb3195V78x9TDPLV68i3Zr/W//t0crRMtNOlGsigvtMXv/6l7/+
8srdWqflEtO8q+tt9erlS9qztC7T+des7OVZfdujN33prxa6unh7/S56Q1dG
13Kpu6C5zsFa4Rb3aUgY+Pvq6vzn01N6eHjoVfQ+mzqfV/O7YpWWR2d1pddE
V3LR9yd1tlplG9o22uN6RxtJKxWdXZyc5vWHq3hw8fHy9FSXeX23u+kR4b2s
V9XDUn52H/Kv+cubVXHzcp1WRNIvaZAPbz++/XR9dn3x+dNVb71ovww9K4p7
g+gCJxZUzMe4+v474cYv70++A53tv789e4IAsNp8thd5XchC059Vd5uV3X2W
lgfL/mm3vslKx1R2N6u8uiOuQjdEeNT3p4z73vLjTk4b5HP++ddP109P3FHs
XfHwck3nj9hF9XJLi34w7Uv6UAj5o173v0DE3W43Sm8qHBw6ctd3eRUR29xh
36JtmVXgQlF9l+nQf6qi7JaIrY7qItptFlnJ7JGvWGSrdF8RY7ovVvfZgs5v
tJU1pTlGxIryRZaCZeNinj8RbX1XFrvlnXxG420z+kHPviImlK470W1ZrPGl
uc3pUXT3Ir/PF7t0JUwd08Ct/KC5Exj4iPamZ77QxDfpav9P+jeqshpfljTh
Yr3aR3TY6P14E9MtCYN7L1E60aoovmLeOFm0KrTFe4M3lbfsRRh5VdEiEGus
H4qDUelhlSWtrSMtHr4/jTBSPJtNDYanQ7dNSzxMl7DKaACdibwhDRkVN1VW
Yo5xHyuX9CNQdRWly6IX0dbRhO5JAC351e068xCVSM+HtKI99aJzYAegyQyj
dbGp76qOoTk/3OXzuygJvqZHyvfRQ1ZmUbXFHukjvhQlr9R72sltxwwwYzsc
Lx/v9Zx4QLapdjLexdur9xGJ7Dx76PAHzbty3hUjk8Wm9iK8HwmLTXRPSyUb
LVdF/iq7frSgWcWkYzDBs1+vf+4Op9H2Lq2ynjF269ZZWu3obXDNxvECEm7C
sSwhBWSyq/Cill0bZdfyBrKLmbtfRB4tGHFWWtG0pqWLvm6KBzpvxa6muW5X
xR4Hjcm0ooNPj6PL2gOA5oFPonSeLrI1iYkc6CKr6k50s6sJW5QlvTddUGyI
/ohwq4z+5ef6h4BkdhWoQ1+L9nCe3+qhqXrmHE/D6z1kN7Q1t/SEzTzDYu5W
8nbCznmSPcMER2sCal0RiiKSuuXzTByEVvU+2wup6OrRe8kJ4bUqM+Uthk7l
Ol2tLIkC7NFfPK4lVVlefjc+pr/nBArwhnH/P+gGU9uJhLSdpUTBNBoOWYfP
nAyD89AjrkzUSzcUVZXfrDLD677Ib/mla50MbR2/ug4bfE9z361qYgLRu11J
jy/XRZl1eCJE5vMVkQnohzjUw8ZxMD2/Sltr2ko5QAHHNW5dmiw3Krb5hm9j
DlREm6KO7ui0B6dKdtXgrPWEra/zxYLezfwENOrOiDFntEFEYRnWVCZWLtNN
/k+e2Z8q3v+KcFgnenZtOTVNMo1WkFs0F2ZOwLd8ByFewNXdhkAhZkHY7YE4
ApFelS8JEROcpVvKlDgo/XpP/J1/ETKoiMPMaQErXjhA5gUTLq9lRoJkF7J0
i6oj3EQznNc4vlb+VOuiIJKXhx25q/eMabZJ955obvZeMOEcN5i20hjRepln
mD2pA0uZaR5IrWp3s84r3v2Oe7tom24z5aMXZ6/dbtOZu1ACWGfrohPsOR0X
wsFbiN7/s2I2YjFr/kUxGzFuyCuDp/tbBSl03AY5eg4PiRI8LfMd2AWvPL0u
6KqH/SpFbm0KuyaYCwnIry2xohyJP/yaZduK1p8444JPhltyngttOTE2+n0u
yDRcq0CLiP74AxrHt28qXQ++B2Sgxa4ip6nQsghzZ37EhxXLV+kCi1wlMTBP
N1BvaAycRGhq80rv5GX2Eq3aE+xeM9ygm5zIImFhmARzuiP9mjGhLEirA86h
24mz5Xw/P5eYB+mCwV7e5rS84W52GNuICKL9cIKUHnmDI7Oi59zQwQYwach7
4orVfGdJnpdIxDohCRbyaVXRWmPxOwFctg/AU2Uyepc9hkIrVUR8rCABS+tr
DumWl7mjr+UXrdMe7MidMo0Osa7NLS1C7Wb9I5MEQSgNgB6YO96TIpuSLGEp
aGVYhzn1bzsL2Cs/bRrD/AVfyJZiQQ+BzJr0a1p/4imrLIUFoRdd3LYONvFJ
nm1lZWEBiaScihg5ibJ9VO5uCN50idrWW+IZbsWITggKyalw/I7uX3dCXiNy
8IZBCkH/GyXTf9AhB9Onuw09ho4TzXR5BzYISclEe0fsWGDNuqjqgGnIh01G
i78IT9/uVh2Dh9BJ2WT4nFjAHnTrERvdK1duiLr4SXXJlywK+Za23q8sJKNH
eAG40fn4KfDBJYbQVsmJGUDX//aN2Zlh/EiPSKuvOr6jWBqSwUcAwgVPmIe7
jLdGj3hdzAtdexJld5tiVSyxZYuMiK0hdhR15xaCYUnoLloAyHDTEHIMlD2G
1RVz4u3gvXKw4kV4S74xQkKOieUbL3qFoXn95yiINuESy2sQqugoA3R8syKc
bsEUU5UjtLu0XGA3aVELoD3i7iQriZ1j+Ypola9zoUG6u9iVc/zyj11eNlBo
vVvsOyAih1A9CiXdVzBjUzWD5kfSJvt9u0rtJvzxh+xfV4ahNYJIYChhmTdh
IL6GT3FOjIFeAlgkPPQs/g8ZUYAG3nldkOQfTa2k40lowzzoWh99j0MNE5hX
we6h6tkzH7B4lmoVd9Oa0sWQP0S+SX8WHV8cMLbiQbS6HFxqSwCIFewqb1A+
aya0JymgC9iG7mtJ+gu9/kLOKCZQC3SImopAT6CaTC6HdCv0exDFFixtKebW
cBPkHOX/2GVMt4YYFNH67d5hvoiRoaLPQHKx3qdqFNhvMI4jSRIA0D620D4z
QDcSzOmio/yDt0pmCgAmj6Ud3ixg190W0DcqnZe3sNzugGAN8DLkAd45xBLL
FOdQaToj5X5/yFVYj3EYis6uI1fYwuzegGIvQMqKfYIvcECsjaQFPvRi4xA2
HzVBVCwZOoHtom1tUMjoaNYqVXgXNn14dYxnZhlQV7iIzszqQ22l+FZln+XX
fkEqwTL2lSzTbQ8wt/vKXJQmm4nLIWuINjHgWHCpvE7U6VtvbdCRLLNiZqtr
x1Yd+kwIkvYQzxZk6ll8aLqOjjzInUPhWe6BXimXZwZgkpEoWASYmAWhzH6N
UHTItwmo5/Oc2PXe6UxgXDWR+lKByZzF7McCYogov9w5y66cEHOXrbaBqoLb
ACdFZ9SVuqMTRAByIUK5iSP1GVnFR5/OEp0ZHCM61Zvsd8IUNTA9EMKCVnFF
sEKZs1cmiMih7X6kDS8WkKZ72TYWBLA5EHixegZNkv9gK0kqMClj1ekVA2p8
FvqchGcYUk1wPFnN2nSZ/0Uh/+MDRKe2pVBZMm5oTniYAbuoqwYUxzatlOMT
qOGzRUxvzjoL0/lOftdxRIDSZaah2qpWpnJRYYU9qF8zgkf0lKomAqmEGz9A
09qIrgdilHMEIwYrllbi6LKIKYzWYbe5yVOcIUsltAc/RW/Cp12ssfQY+6N/
5h8/+Ql8M8c1LKvCpSTxBT3qCWKGCFkTGKuFfvggsLm7QV+VLsdditHuCKZG
S3qhHdEnnXMRCLzi+iVbGW9yMAGQPT3cCWrDtEMzus2AFZo6Lx+1DtNpuii2
ejDTlpFUDsqSntacJR0XehJJspUMwfaEuhYGJefy6n1w90aWzN2lnK9pXl0S
auNlo/lZG9p9aPDAkHxjmfllZMt0qO/r5V496lhFQNX27Pc5nQc2JkZXQHZ+
xfC1HITGG9HWt7iAShpSdHmKoPsNg9GjQ4Yqy9P2Dft67QU9plSq8peLgPcc
8eo9ZHQIQ5lrsKBPb3YrPb1Aazc00FevQQk3sPqzHGFrKLLji+FFFDMrb4+b
W0RqlBk9Jl+yDKB1pCV5Zcx/svQ4ylj5LObrrG3raRp4hLQDIWAiT13/wz6A
ie5gXAH3uLryz7jJSIIwIwglixuSnktPYPWJyZJOUIMsRTuxfMSr9XQTTmix
I75G3G1OGwYh62bY9AvoOx97BF68wXzdE3Ve1nlgVX/DMD0w9LmjeYTsHkCx
mz+psbbFBdjsD/tVDnKy5KYQbFlmDfI4sMjBWL9iEmY+E5zQi6u34Ess2In3
0wsrjMAnzxpTeAZbW14QinUYLyDYYwPLYwPy1bcPPKEnny3sHePjIH3JGhgE
lMdYo8j9HdZSJ8JGoRKLZD8DEx4gXRxIC2vfTmuhBrg+Tlj6GIHCPmHmJMk6
opOE4+VH2bxTYjYsgy1ngUxosXWVCkQ463R/kzUuVwSyyR44dsNunTzhISVx
w1Zk64sk+QRGSG9iuX9LtNA1N9ltwUBpni/0PhNynM0Jgu2dEMN0BRuT8PyW
ZdN6I1g+N2Ziwe4q/9pmSR9w/M/p+AvaZdcOexTW2QLalYgrh0owtgm5Z7g1
Tjc5IEk+3rmsZnNmZ0rYvegdqxFpzUeVXblHaczSI6lg/Ge/b/0tMolAvAbW
rEqM41/8yBU2WICYWGdhZOR1NIei/tj2ELK6EisEQ7JfBJI1oqOArA4MFsa8
TivSfwPlbk06brrJq3WgUFgd6IgGk3p/aps+BAjQCyCaCiZovtwBzzXBLDoy
3hAsNji2+nSMSA01NEOQMEvcrdnYeUXcmN5rVzo7j6gAbP+BZxCYNScxAhJy
4JyPr0PlcmjaXkaB9IcGFeMkl0WcQvCt+ACamsXatOl+HjD+GLXJqB4bGGuU
hllQ44rpoD/pNK0sf8FikZ6vpihSOey1ozgOr32TzTO2tvF05ODaKdME3JuJ
glxJrMp0iEHkt9HY/ja0vw1GI/eZvW6QDDtGfptM7Lfwqcpvk5kbb2B/S+xn
gzhxdySR/XBibx6MYx16OHEXTtwEx25a40QQnH6O1/0CrqvkGkROsLWSTdF+
T6xjHpuKiAYXVmEjMYw4ieO+NZoFcRXX1q3CROWtczw8dlstcME2m3RdsLSC
RejA/qZYVFAtbj55NWbV2lixsfhYk+YuM+nyS9n9HiWJ7tkongzdb7rYo8FI
93YUz3TnR8lgbL8dTu1n09jeO3XfJva3xNLFaDBRGhgN+3bkgaUGGmXgnmtH
joeJGyV2z5357R4N+vH/4iIkw4EOnQym/reJ/Y1e08hvM/ttMnbfWhJOhnY5
koFdSrrDfuZejkZO3GczHTlxn2Fh7Hgz9wz3tJn9NplN/CIkg2TApo2zwNRA
S3DVeHPH9huGPwZaAl5dUIQznClOOmHkdkY2d2o61iBh2LzN6ln1oC4NxLZs
IhhNaxerQFeIERP4ln1DGPNWoiasjU4c4SQm9hHwV6We8JZZxXra2kYvwf/R
bZYtbkgceQbOcV3ilBHJCe5nLs4+nUW/kFaCmDcnhHH9ebnf1gS80y2JpOhs
tSxKgmbr6DPLtehCrLo5HCPphsDkH3/8mR6BQb99I5b+3//93xG9h7PepqTD
jxh2VmZo0dJz69t+0VEUQ8s66fZHXbbMO7Uo3WyK3QZhCfx93O/2Z+JPzXxk
NCtrlV6RdJOpObNiCpvV7dNnY+se7Q+MVWXky2E36buPZFHrTL+j8SbGB0TK
h/S/sSyfOM5fRXNCJTCYwu+J99cAQiw8x5q5AdyeHFpK1CfOLv46BMaGLTVH
cLSyA6sGkfL0AFBBiIH9J9s9O0QtCA6UO2gdbEUAXMHTsNJKXexMF92HToNd
FsTm7NiUDRMjAdRcoz785vdhdfx4cXX1y9t3/BrzFZ0WUT5k3WhvZw6mOntV
mXUzDuNauKeltUEQTM99ADUZI93jhD0UNjqO3jsT2KpLwbBJPnVjbRZHViB6
PiC5lX2tXhBhljVhJoy9SrcapkZH4j5buaA9ortERGql17vlKIqSVIvU+pGM
rg+WmE/aaGxeZ5v53TqV/QuMsjz8VXFbP9A6dd+ot/OThA3h2udXbz69iMx5
gbCl1Yre6lKQXQo0aFd+NLbHrn3qxkM9dokLJXEm8Fn05b0PyrAnkLZo0E0G
hr5zSq/s3whnL56eOpq0vXE3fupoyjGcaDBE83yOusmodSqn3UF84lRiIuP2
qaQPB3179g4PBfuMst/rjLgvh4vp6aBlhu/mXiga6gki78o6n6+Y/+5K1nm2
d6Uw5Pldkc8zqNr3xZyNXeVeXc13YIYCy7ONGOGIPlKMuYX7QBbEBs8Rgpf7
nuGTZ3DsrSIQCXux6npv1jviB+LsYp0dR4qfsbA2wDwlJr3mMFn9CmfWetSj
TKSDap5rUjowDHRryIGz+ZxJd2n1LBERInOy32EPyVjpuFVlSSg8r3Rt13lZ
ws2fRvV+y05HWDHFsHCK5KE7NxnZ89cfv7x/wSuBACf8WMOID+3EBhLQmO4z
nHDzT5jKLcesVsUDXDuQuaGdyppM4Ft/YM02XdF41jhqLxNWRy85HJNk3bML
lpWoNLoh5gl2KDxGRreRxSEDdmxeTYbKApr8cTRirwxe18mDRsBUqtGec8sN
U1ogZl5+KTvOOrVurKkGAIMXiIXthgOnA3yQbxoDWf3XAYLhmF/lmsBkBR9F
9CHd0ytcZfMd/ALR8+sPVy+QbySk9TfV/5HfYN9wOOagELEzcIi+sRG7iE1i
9iZfwsRjLQgqdpDzYAm3F72zYvJQw34AcUqUPltACjjikVIkHPCSQ3ngZYXz
LS1Jpxn3LRcMeJ5neUMggHhyEnQw34pHT3O2AV3UBh3ESGMLOgBJGuxt3I2H
p0AHmNkR0BELe7v2R9D67gQgvNc4wxZVpsRVfoOXSNIVAstfr3UW15no6d6v
KCE5kL2mAiciGnVEpeHSBCF97KriWDVENeNLObRKxBddYJjuVyCDIPaalHkX
po3nVojEWEn8iUQNSGB4yr5qpoMIwhIRRZvDh8r7rzjgCiEYwqkr6y/+HYTN
ftnV3ka6MIEaxhGnY/tphc8b7n4JijuMEOX9U0pn0qULEe274mQuxKizKgBp
ZFQa9TgkW2KRXPwNG7nmZbHZr9mjLcS7g4l2DsfdLesiHEXkjWpVZOwhyP/J
Z55outaUAQ7UT7d5na404Fm0LHrpFUfvIASGB7TWGywErXhPCFCDTugVbnFi
dJVs9iBO9bOq3q+yZwHb5eFsLgFP2268WRawexZOSAVv0Yt+JgZ/n7Fkos1X
D7XTihZFJpBZ14rEwv4w2wHy9aulBQ8he61Unz9VB/Ij5OzsOHjPGWIqInHT
MyuKYByGqmcg8yWRjBZ9tWITIJOzdSk3RJBDDkwbrKDavEcmWPPL5TnO+u0t
MXdWJYGsN+oM0OncqgHXzttGG3vP9yJCdL6cFyfPdtVOBA+BbY24ptvO3sAO
w55ExEzynHDgUglaEw7LFNthf/y2dvQnL/GbWmbxkcIjCWtXN+lDKkfZsK7r
oEtqT2brHEs0JS0A9M/UIxwxjHOcmiI7EtxuukfTcljn4SgnTuasmR9Yf1q6
4JAsnH51izZgQqWxSernTeI2N1Q7gg2k/pJ/zUMBB2mpubaIqdZcRA5Jqtkh
z2JbUlVEcRLWfVMWD1WmyQIGNt0VszMJ2eF1k/CS21I0UjwUD6RF34gRwwr6
wWhkiGPnK4ly+ZVe/hzIlkM9JYDwEpK2jn4hDoBloy8aKsnlLxef3r+wn1VW
/A8AcJx/qIVqeuYCeTc5o2CrBqcMt2HoaN0Q+JSwtziyK31Xa6J4/fmdKN2W
A39578Lr4fcwYqu08d6Y6UuXRRF4Zb+87x3VnOKBYIbeoep03HQxhP4ziHu4
04GM3hE9aghtJx6cNnGIPeIpEwcU6aEzZ8wauIMNIPHMfhsnLdwx6AYftXDH
AOpZG3cMYE5hteoj2xU0d9ApUESUukHYG+b5tKSfitbRaLjt6ypb3bqoCR/0
ixjvO0jIHF4U4jVpZa6yJcMBS47PGykvgnr7SSe6vuh+eHemGe5IIu2W9fJh
2a3k/m4p93frvLu6TV+AUh/yBWRwAJM1sdFhENYFlgXEckth2rKOmG9TSUwT
k4aLo+w0nLbQKB0RaM6ZHLWtHDWdmxPXInRY86MTzNFfxU7VRRIjKe+QdSAF
+YS1BNseMD2SF8QZne4gkQf4iJ8D/TOfk4IlB6jpebLqQWxeF0UNU+F2yzFr
2c1VgcmrweTn6+vLl4nXBeJv304A8k401bMV/bqViEDs4pg0pJ4Z/NhpY0Ng
POrRUE8eNj0NT0B7OkoTd5S+A/JH3cQdrP64DffH4UiTA2tGPDh17GbQLtrH
bkbKg9gYz9TGyMZF64FuGRlD5arabVmBI9IINolIVLbIYpW88nl83lTsfKEu
+B6nmu+Me7HYx7HDY9FnmSIDoGQCaAtagdimAR542yVRyzJsAR71fsuQsJE8
A9BgOPejTnNNDBDsyDqtRtBxfETVgOIhDG9mcnDK2h0itlO1j7b5WMccsLEQ
eLqEtDIDHWGcLYHN293KB4Wq1mUcel8ruik134pN6i7IsMzkiPvzh4QklkKS
yjqvORwgePqfqiNRyTKepsHh6KrCUcm2QuMX40gR/T8fPwRikr+mjxjrANrz
G+h7CtI0iJmrdjc4vCxJObq14VnQKgMhMDqhK4ZRTO8IkN4Wv/Nkzu9ovIw2
IGWWZf2utMS8PhrliaVuxnUqokmG0R8/iTqQdfHnN/Pm05WU9pjvO4prnZbD
/mqa3K9sz3u7kYokHZpFCvTEMOtjWnOgiXqeiPMh8mDHMueVuQaL5EIT6rz8
QLrFnx0Qogl8c5mAgEOatBpt82zORIzpqZLN+WDGE+pTISlHcEoys7z02B2j
H+WmYF4JgbSrt1YBsaYF+Rr8NvCf2ITDMGGsnc3eHIHYNU31CFKZumGHLZYZ
h9x2dIp5wrNzwDzZztzkkKz+cXzNzGXkg4pboX/t8GNhlMxWkfGVceUFI45X
H+FfId3oYsOgQIOmcoB5Mf4KxPm91rIDXHAG5RHyco5YSUUdTmtB1C7tg2QN
M1pmTROJQeLGaAf+NDxMki9C9wEdWYehdbVwYqqQLBFIFbj8JJ9NQ9Iu6mOE
q7kiVttWpdK4aB7Lyj0eudnlq4UERy+cisWaZ6DCtY/0acNKIxg0tKwoZ+fd
bTm/LDg1AVc/afj2G9bcQHXpVpIWWkQPJeFPW5rhCoOq0+jOxqALSw4NC0CB
BORsGh9NM1/v1hzIbe0+P0uoO9hgxqUDMhdX57cQRi2xNZByeullwTlbjS1e
sdqa1RPvnO+gsqJWyc45YjQXwUWkHZxn4t1FueXw0oUpxZfNmwnynDtF7HBO
iG/mVHSQxy2S4oh+Mpvmqy4NXIUEz3SRWb4+mRgxR6dca4AT77xCi6X7UEhp
kQ/5hhTR59e/XHz48OJV9BHOgu414U7WKSxfnkyewKRJ/ygoHSSjTjSJJ5Mf
hqYDYLf+oBdNnoamI74uftrqPPtRaAr782loCqXvCCv17u/w1lOO8EF8wGf5
Qwap1wCnnWMY9Ye1xo6kHcwlEYGIQDSP2dScRZfdK6740iWhTXCUs+kIQmSr
RXRJUnudgc44vm0TfVYzAwiSCflNbvnE8/M3F397QSqlxDKei+mBydZ+dsEW
A15g5+x4fnVx+cKpNrMpO3KOGQ1G1mjwg4J3LE6CXuiMPa7GwGYwOk0r0IaS
H6SVmATrNFRUGrQCmezJoeG1mLFMnh6lkBmT66BJITPrOfFqjCWRsrDWtp6Q
ybkLVwgIAgYCTxS3QQZAur7JlztEvXO+H3tTlWAmM+LJBTOzv6WrfKGbacmE
VaHLv55f/TR1WzqZWc7Q2tHp/x50NeWgluPoqr3k/X8ZXYmRZtY+9NPwXLdj
XmbhlycdUTO45Y9opmPvZ18WqQsd8XCE089VYj2oDDPLza4mxallF8LlYsiW
jS9sBYB7IhSb3MqhXVdnyNaq1AEhmbIMW1wSfTPWJtBFCarMvyI81foijFc4
G+kooQ+8sedSREAzYhSJyDHT2BSr86hfIbrYaJyPWCBb+9nR9BGuC/GVBGqt
aQW1RJHrW0SNqjgWAB4GuyOdC/KcBC3UYylBAziLuMzdlmciubWBhkfHQZZN
oZw8Ao7vRpKegqSrt8Q8ry7Prs9/BrPKNeY+Jr1Bo5M3Bb6AFcCWZRLjNCYR
zKHTBDQ2xcPpPkcykeho/w2a4AnNHTlSzv8QJNwzwN/Y0omckOwrKaqXVNci
F1CbIhIHgwtIblv3Ge4oGRN1sdOt0Mo1bOXWkJ+BeQduw9V/WE/UunLW8aYB
PWylf+st6c/Pzq8/eUEzGpzgSsPEypkDTNIM5RmzjSwePy1dxqzfjcxncYzQ
BU4Bc0FzcWzeshZi+Y96tDKGTopWThq1GWXEfrDB9+xswbXDI3Y251aPD6OG
TtvZwBCPuNVhbP8BAfWxqVgEtlFivW9QropLk12XCFPpvnl7FT0f0M8XYkE4
H+Ik/DUrb7KycD4TutVu8evzSw681o0dH43OEtN//ER8JHZy3NDUn3AjTFvq
92FM1knQOOkmp6QGArEOoKJ8+CPrfDK8oWHQDiIdVMFHhix8pguRPm5D4Osl
doCQVj5+NppVzWY47yhFZ9PPiBUXN1XBr8MmRKmMtocP7mum5fe8bEsFgEQ3
7NMt1KfkAhOtou6zWdlpaku51Rq1oA5RFGakeSz85fo4n4nWMlc0s3l8MiFG
C02xd1x+yvpbtDrJkZo614HE8tI8RTm2VTp3aficJp6jaIpmhYms++vF9fXb
T21/q0Zp1alaM1jMg1NzKFdg0zj/9Zc3H962NprtNg0JJuF9ur8KB3G+eC80
1it0m/j3po2BVdMqxYvshicE9m22ZV6ULnbD67AMbSxF+gpefnEgNniDbCIx
LuaRiTo/BqV+kmlfAsws3mD5+eHcQzuXlgkZGlqP+Ft1/dfp6quqzr6MTggS
tMaIo+KiNMghxr1SvjOf84EZTkYaWb+RBGQhGkmNnivlbHdSTY199QFmklwi
zs9XQTqbaficDxrG2VItz74NnqPrYaP7lPLzmjW2szd2kUlBN4tdDdiVcaUU
UEGqwWsZcTyJTrxnYxZkko9P1KXoHePanYafkgn+qKNSd9gmhPGM50htQ+kW
3iVOjBNfC4YEt7fMHgEA4ro/CJey4FVKQPCEQJ9i6V4VD6u9tX/EiTn/9fXF
OY/+Dmf7Q7FZdt/ksFrQqx944OPkBGCIpye92U0XNlS8hlPtuOGCRPDJQOAJ
O7SmgUXhyWj9uNuS8BLjPzzpSYu7/eMqKGOQ/qEDmz/89yT8Ia1cn1+Ctywl
tYPZDICckyrR+e6Gzhe7Va0DTev1IheHBCq+Cj3O9MWHfLP7nXgXxBMEh5yA
1oWRI6nPV1kj9D064981+gucRz0/2CxJ74pHgrpp+h/bhQa0OIOj+Y5NxFXV
ztjjxAYVfj1XkGuu1dVOGlUrNYcrpzRaVIK5LXQUVxmxClbOMuj229sYYCyA
CcsHyfetMpM0J41gY09hR+zDhwzI8CMtw7OWU/XDSJgvHVopQReEmLnMNQAM
yZNjCYSgQePy1m2ythiweZ/ayeQcgmIDNsMUBTxQEqV9mdO6zJdLqYSkqUMH
DObzJih+RwrLouN0U6YcLctFW3+zg8v09yyIh2la2gOdZpYYjgVGeFBV0SqR
FpNvEfSJSvWSXPqd4GFnQDvFpobOBvv8UAd8YYCOTzKvhJnXpMm8rrm+uBiX
oVxrATLReQBxT3u8RqFNJv43PF6YzhHOFvi0Wg4v2PC+5/ASi9rsiJkt+RfQ
NQhNyr/YaDut6y0A8ESBcabudtUQLlXf4CcFSgYSR2GIOWHtMGGXUqDoM+T1
XE5ZkHEHQk/KgBe2snLTJQgwbJ76Ly0/krr5HeMqQjApIPdfJsyGFZ1FlKu7
O/ChpeVXl9g8gCVEh5jfpXlpWe5tmq+UzcE37r1ddN+X923ofvZGXFhIyt6t
Vspnt6vdUp8zPoYp63YlBZsJf/UWcUhqtlG2FsQm4N6bXbV3K1v7EDmbjia8
3RDS8FxY0Rn88+y0wvGGt97iHywcynpFz4APMc4zV5I2k1o5RG3ryrvBghA+
ZrtzeAi5rA/hYusqRdBDWnZMXltw+5CqATgNgkJLyVEkMFrQ6du3R1UsbGsl
t0rFaNilVUM0cjyYYiFD3QR+RSM77XPCXU0kF0lLZwrLGhibaCB9Vi80LPFt
S5iWBOJxeXKN7tX6VgFi5lczOkk1Z7G3sRe9EzLqBPoiX8CnnoPj/eprNGyx
MW7tHiQ4wylu7hI9gQtRXzAkRGS2qrLgfLCMDDx1XMgVeB6nyJhzdS2GCYNa
TVNGdusULFOHoVZXoVZg9jcSR6w3OtMkol/5MyKdVCJptN68f3qg3R8NFZlM
zRW86qvuO5QN+lDMUY375cUb8Ky0bPt9PlxcXb4Qd+Ic59p5Eqcc6mrU+SlR
4HIwOr68mHqLnYAOBlKGhfFNGM+ofqW3waAdhBmfcis10TsyX3swIj0N32OW
Fk/6HQcB/P5eRt809BY94XecHfodT5rqRkinaQN5/pCl2GWZBTECLrxjLZYE
2pWhILKnYakW5jds+F0KXrvPnMqbCw5iUl9l9ZGoSht/JSJGokLnmVHJspez
v8gXB3bkhS3GC88I7fMPKqo2oyfExTfIIakY73I9eJwHUtMLyRQT54oItQXC
WKOLy/uxIGkmRFaf6bNhtNvwJy/9dxp68Hm1XxNm5Orgl/tst1nycdfYvxXC
vZn7sbW72Liy29nCetejgk8+wQV/WrT0+cL57Qbj+N9z9xuEGZRIY4GTKNs6
7s+Wd8b1Xfknel0W6QLv1jG/biRL/1d5beEk/oA+f/3rxxcAtAjNc+d+fBjV
euUiCOLJj1jlB6zyEiKKh08e0yG7BcdPZMKHbtz46YDxRqBVHLePaRhpFbc9
hYhnOHVMYTE4OKaYuRzTJw9fkGheadZqmGOqtG40zTpl2wghCC5JqQpcEDee
W2/bYgdx92MHyppdcb6xzLGgkoPARedZTsx3VJy3TqqyPgSLcfQ6lyKgTqx8
yggPaIyB80AnT1CWs97Eh4QlBhlEJvcQf/Adw82MyOZJkvKc/0mSEt5+4HKe
BF7luB3PN0MphX/B0Qwz0DTQWtjhK6nRNgfM6v9iQkMhbI7yu2fdQXRyLft/
2MVBUp4CCjUhheL3G6jaqNSY1TDvE+uZ02Yz+hPOyOvxyj1X7aHaVmBhC5S5
MtyaMnxhAwF9qeJAe4meW1NpjmS0lD92YE28Sb9en7WuZHVOar4zEEZhaJd4
Kd510CfzbM2SfgO5hUpjbKQSXwgn5ooPlwPV4KeoGkfXAXVJIvO1JqEmsbLh
45LDcN9yJ7UPU2TufO90djySBc52MR9HYSQNdpmVd6jcoKfXF2eorfNEg8pd
DUEnQOmNVgUDMvFYYzPUqBuyIscBYrECHj/YPim6H/mT/aTM+M7RHrJVYEBH
e/a9oz14IkCofbSfssn+yNFuQ7l//2hftsoBp6fWlvnphyvX/4NAWz6HQuPy
90c2rlddSkHKjfH6nje60VlIa5/2m4tOyt8WbC5b+bE1b3QYMpWmK86E5VV+
DM612ku5XHk/89DoGcSL2xxCF/I0Hpuz6O9nn95LR8ePxUJrl4iQSqK/5SW7
Lmy7S3UdkIaT/O3y0wuEt9xjOd9kq5zVVEu94/FT1Dua/ohmMrZ+hTh+kogn
Gs39lGbiM+q/p5kQEQ9PaybjwLkd93+cnKX+0CE5W8hzHuy433CB5bbCsphg
OKxNsjzyoHjqnqA1ETJtoMPFifl8dfnufsC4F8tPkzlb0DbVeSWK5fMPV2cO
fEitZo9ZE03LtGUAHERREx4GD0ovkHiSAGR96O1utXKVU25WVkU9Qg4DlzM5
fBIAQ8Gc9KLkaQA8kBSvJ1haI8/xO5Vn4gAAo9rTaQCcHALg+CQAHqDmzCEA
7g98gNxhQYJ2/We2xDYXzFVpgLaG1Na6UQqa1TJsG3wH1w0sfaRcC6dcVqFM
DMof+PqysOD5+iIcpx5a5A78DJolIGYtn5aldju6FTOUhnJPE5SGj+UabECs
fdMF4ELWmBQarHGdjizd5WyJirJyVndrBRRJr8mTYt5e50u17VTzbINyydJl
xfqVDd+X5ewyWWXLdM6eF54jrrDn7+pMTJxSc1Y/1eRNwl7oytiMobDdy1Dd
Xisf3+1vynzBR5wDzVyTNp4D52/qDLAVbgr8bDEoaLBBc0PM0e3t/QhHslE0
TUrV1cCWwLKM+pE3Wdv0wIWrkfVAa0AXa087J5amBqaFDpOxaNj4u8tUfV7Q
DCsO3X3lYu5tOsrFpQkrXX3M6hK9HJ5fXF6SWu6D65yY+oGY7O/EykEoNIL2
T0XK9YdPh7nFgYPne+mkw9Df0wZc8bGwfCehTtnOCOn1DwEXu9mZJ+l6OQMy
rJSVpsTlUibaeBMz28a0C8ycYx+QNvTSwWUxYTmnZK6dODU9JI20yktgxu2Z
L6wlwayt2X6TQZzotocFzozd9lbFKCECeCLyf1rVRYpDDvqdp8bxdKMQPxOC
1HpPfNygN+U1Myg2Ty0aMR6g3B6hJwjfu2zFSs42K6QNhEbxrvVpPsvTRgKw
zN3aXriYbvSc/bO83gCtfFSGBvN54R7YgXpJumpYvQprwI6yZZnZNbAhUg31
DRLe7RY9mW8EWyKuklnDi/NVP5dMLY4Ge+mial5IWC5OrfdRaeVhrv8TpPXy
VZ5eGFJz7W7NBu66dGAtlVwhkHSDFRdfvawmB0WrJ+gGVjsEOBCczsxzWkIs
L9c0u5NMEJwALRPficarohNl9bwnyrLVzl3IGcD6bb7k/LidWEzhlCkjiee4
Z2Gk07DryvVj+LGp3obgH8xH5O9SQinAnlVBLnlVsjAQTYcQRSD7XVIHxUlg
wgLwQblp3jBaUA/a5I2rIDkRL4b3qlhwWpur6hjNKmdNU4RsY1DfTGubPWE1
FwJP2SkHRlBZP88rY7p8TrurItW6UVJCUZ1ZJCzgmeyCQLtSa7+yTW7nRdfG
YtAonF2LCm9BqTwXM+cvFfEo8fjPnQnv16uOebsjbIqjRApVKo0HbXQnvxLP
6wUepeH82iZSExXhnNNgNKaZ3UYq3LBDncR2UNKKmaWcNM1fK5k1ECeg0T9k
m2V9t2+219qolcWF63GhtOi58yxyfIzW6kK1FzUtMcKT9hJ56D3FRkhN/CDv
8mCxTLBY7BemgbquyIO2tpM2qmodCtcnSEbXhl5ucTbo2fPcxhouvIgl5bbi
wBDSvv08XugK+00UgKSkdpv/jsfb8vtBqcSoWfX+ZFKoS/Rv6N4e95iGJgYW
pGX7aY/RDsshEA7oxcXYiDv3+EPiqwzHRnF7qWbLzoNCxZe23eoGVcvZ8P3H
Twd9yLhOMdgDyQwJHO0fae7VCZo62gYgc5vBrq2vUELFcCQaDr+4hhq9vzra
PSFoKOtatm3xYemCK0zY6sQ6bd4xfnoTmFT1vfgdVky5mr8KL3R+45oYq93/
f1cnmE7QGMN3hAn6OqkINlzAImi39O1Vu33LiapRRzu9GFdkQmekCdQcRWML
E2pVYMlR9hZJR2lHt5f46SOv5yMr/LS5j9ElcCz9+1mtU48AAI8ys0c+q9Ej
3dXtdl/xz24Uyb/6p/7b/Ek3oHAzxiHgTP+M6P/DEX7GoyF+Dvv4OY4juXY0
9teO+YJBPME/fdL/6Z9kzLdO9fIh/ry84iF4oNFkLKPir4E8IZGLB/xYHTvm
0UYydjzBN8kQn81mdujYDj3lofBn0seIg5gnNNZhE3yGSK9H1EugHxN+9tS+
VzTRlxtMJuGQ8WSW8DUDXJ/woEO7DrNpMNeRPA9XzAb4Y4TnjCd67WTmJoC7
hjEmlMh6DXnC9srRwI865IfH40RWF8vGqznt68X8Mq/PL/l7PHSI0Xl9B7p8
ulYA2H62/G6J7HEsF47t1sm7JW6+vPvJYCTr0efrJvh6aKcxmOC7t79v3RqN
EtlWnm2CJR3ZBR67PZONHfPE4iEvPL/pZGAXLWnsRZLgn+mMN3A4C9dh4gf9
3qVjT478ShO+dyS0INPu2zUbuwnITk352njCYzC1gf5l2ANiiGe4asY7P2PC
Tyb/3vF8dDVnaSIy9pTH5t2OZR0TWWB37XPINNrBF7hJNpcvnPGixEwucR8z
0jQ4W9b2ZKpJyOZym7xvvWzggwO1v9t8i7wyEEyZrbPVIxoJe1gdaTjW6Bpf
+2mZYFrSmEt8bBD4NJdwFkM3C5IOgpELh2xNElzp6oBwxRqu9bnMBPc1gvoO
hYGR16U52KdJZURbLTwsySUIotWGy/ZxkEByW20dImGn14exsqTS9Eah56G1
BD4h9k7qFbnCOarWSy+ntF1Xb8tRNKJmGeeBPOhCh4DHTHUavKVvNK+B59I2
SMx35njUYkchpvOfasXog0bftDKf3XZpy2JVw6b9/3C5GXbB3IgSfOnlc8fE
dLlNUrU5t5gEPmcFTB2LLRGubc3aTcr5/ZCxgU3wVTm8JG9VMGx056u4yqvN
w/LVpNHo5Fb0jyO1UFAigXtkVYSKhcyMHaAIlLWwSJXWX1ppoMwRAG1CX7jr
uOzTzCq0E+FKkkRoK60uBaWFW1+gQqsLsnI0SeRz8hWYgqTaI48QcgoJ7ECV
7YPILR70xJpqzzR4AcOONj6URFCVK8+jvhWsNikqXEcC8tL1tmk0u9GEtFds
KIueo38KeOgBCGOcGxnh3MrI3b+Ooxt0h3HSUfDUaDqMDHrKWOnCgmiaDOjT
ZBoiMRY3g/4Ul/O9KmQH/IPkjEFbGzsMy16CSDw6QwORcyxgZyQBDRrUOJEG
STKjLw0a3ThxL+htNpzwM6cOX+C+KU88mQRTTASbkEQ06Jzjntln2ceXTwfN
mfRnfPE0hJE80ggLwFhQL2eh2+/jNQcTN4oIaYh1g+Y67uMJLwEeGXvkgA8H
MgLjACui+34mg75DDwycZHqTob+aIRuNrySBbkSnSUIpok0QnjIMt8Nx0x7J
Mw232mnNcCcxaoYb40QNqDecjgz30AnfdDidGm7K01hxeprhJjvuU8HAA56J
W1fGBSN8OJgFL89rMsbDhGLfMMXiixmGHUwDYMkwWV9mNnE0xYgKFdC57ZB9
HmN5HSREp0nfP3HqyFV2LEl4em2wJY8czOIjVw8HzU+Howm/d4iHGY3H/EQ+
WzLtUWMHhvz28g0DqeQoE+K+fSrMgsh+YU2O+6id4BaVIyox83AXA/r9HzuY
dlaZY2SizjJvIqb0d/DQR84GxNXJ6D/or4/yUCJJHYQ+NgH5vbL/CE9i1khr
z8RD+FF2nlaLm0URvY/5kz7vVTyejLgtGP8+k73BOg6ToEdizQ4+mSoXMdyV
kdgkhbPzrwCRLO/hfbL9WzEZqUZNYoBjZaXflxZ/YZSparFt71IFl2LKPbsR
yMdII4lJQoLeWtsXso0VEKlG9N6KPU1czbxEAS7zTEqhwhhZi612w+1AeYo3
+1Znd02ehps1KAFrKz7zaqyzDDBSm1PB8WwbrPGrEbjDZeeff/10/e2bRUl+
XFQVCxv6wvoswuqPP+i7v789+wUFBh0xfLqxloItz/Kyh9936zX6xfSYWtha
cKYYnz87sy6Al3jcSWI5SjlJX9Ql0Ub6rP9NhYz6bBIY9WJLTIkoP3EiygrT
1ExVWv5q0Jta+krEHDARZT9WZbPPT5nyPbNeX6Eze+CK1W69cQeFDbTwoeUL
LYXKnlXeWH11WWTT2jxscmP5LZ0uetFF0LFV3NNzH25sinKZblxlyVzM2Y2h
wzTFStxBvh+sJEcamWYj1fg4lREjkRihxeFhMmxaXub32YapxWca+2LnqfMV
Isdbi5JE6gzRaEKzCVIk7/bbggmQFT4U1MYh2mUu4JJOGb0xnsqhAOly55p+
BBa6oyeMYxTlTQJo94URv1GIjeL1vDiIbySwD69Dtgha20l269S1HXHrZhrr
xjvX5CVqfquyIIGzVSABo4QVZDnSX6bQbkqgW4hq5ahbDSM+t3rT3oWOUcI7
xFVhmS+Gc3TSIkyqQgkk46/P9ljme1LImNZZJdNMxL1uvSasEtk+ZH6J7zIh
MiYGYa+eqi3d+bCRmCCCJ1rLpYM+4Am4LizATXXx0ttH4cWxR7VkLTfsoWCx
evVEkw0YEhiLB9F7+WEKomRgOtVbFoRUU9oJZ5fPN6Zp9ZXXP2y3666x3luW
K7bfzO2prjS2Rij3y01rX6GxUSnE2FRrG4N40K64tvmqolF6+4g3jAgtcVt1
LurbXFBrU25sHoSxFirNK1VsAvjKRuRfOWXShTs8qmpvPzBOPsjPV61/TNOG
LJZjMfcOTdNmrHbihEHhNMHXgY1YzMJ9/dW0TMJiBkYvNpY7AxMagcX0y+Ak
HsxMw+zL9j0x+prQyqum3QlLp1k/MU27rthyhwxJRwQQG5Zcsd+KeRQzCU23
aq4dsBFwPKQXCY21bKHl545NyzQr5liUCoEFEsMGtlhrfx3ydJMJv4s3vqrB
dSwmbVIQGuZWMbEOxP7Xx72hhVU/xutOZtiTwKbKlkvoBu5Lb0VVyynPYjDG
hnmrqVpKE3EgjJKxaRpKxTg64GUcD8ffpbEAwljrZzJlVWQ8CNr/afjvkSoH
uTebHDM9WINgxyiiZxYTByZDDQMmRcKWEBbrTcN/1MzyZ3DqbFi/2BbA7Kbn
7kYaDxpmwwhPDFyjoe1Vg+5NuyKSvvaR7t+Hdlbx61opwfVMRMIJvTU6PzcM
sfKGuyazWJTFtnJZoZx9MXFLKe0XaUFJcvH3UFls/k5Rp6uT/rf3jZLiaXSb
PRjP16QVkIb+5Wtl4IA17Xgh8aVXzGBZsIZXW47L9YEbJu6TdbgJV8GUFEwl
k/6u2GUpSNh6JTT39qm53C1HyxZphnGjqu8RM6wShA8CsGUqRAhLOqTv63QZ
vIf1x15zYEnzugPPpQvnUFUO54CEIb0kHT/zn4HtVezQB7SGF9KgAY6HWOaS
9kHvqpEoHZv8aKJjYjL3Zun/YZ/YiGFx98vN1h8fVGQIWtBrcWPGP5HLE3YN
jFQOqx/fPe9gWTrWIQIzJEdcaanEY+EAiOaJbKmgpmH5qOQ+sglsnoapXSN3
4Tq2FGlafuXeE45iW50fjFPXUD4kAonEY/ycz+CLlmfq0JB58t+j/mMWFVNR
FaMnnccsbYci1aKn/MbM6EcTBw5Ouoyn4vjEj+iks5hNbSJ4oqc8xUMxoOlg
J9zEg5kDJTK3ky5itsGxrzWJTruH2WJlX+C0Z5hNonZBTvqEefFYuosUPukQ
ZqgycOjrpC9YVjwWI3T0lB+YZ2mffMoDzIvHbzyITjp/2Zs+dTt8wu974qq2
y3fK5r5En3jS3St7xe8RPeXpHTuC5xvUyxuFWCVSyMfrJ6vHq9Hl1W1fyvOQ
IAJLV02nmBedGthj3VIcgSZqLlvgmv7YzFghDpby1fYaEKFUIzg3QqAyl1vj
8KBMfYMNZ6SCBqPhsR7WONAAobFzHT9C8CDTdXAhFUDAMMx4GGa9Q6/0VZIQ
bNVNMdY5AHEkrgxf7y5vtAEULXskpercgKLkcwVEWmprLumofUC58n1aqtyT
ggOSQXqNhn6+MBQvAMwotlu7UQnyYBcm00UqpT4jUoVJWKDJWxAL5SzF+mzu
gCNFnAw9aMeJE/LQTTgI1Lv/ZGdeaEBaemuyy5jVy9I1R701y+mmQZMAafkT
Vuog7Zlu/qK1B2niHD63iYKG6FpKUCIaOwczctGk7S+0jLYr7GOvaPU+5yAr
Nr9znm3diLYSGub4qfNgkU9IwyMy8Eekn2Gr61blbL83wsnu9nusgvZ7Go2B
1IuuxGXRh8wO6Tu5ZDjiS3jR+FaWf125l76PRcDRU84UY+BT5pZ4zkQumsol
um7ykVzBPAzDzsyjlEHC2cMVffvNWP8dGaujSAT2MfoKT1/TZc+JQDY9xNXf
1LBieHH1V4eXGYhjtBaYV3phmNukSI5Mx/zahPiix23s+YnVrtyWOTA3iuTk
WjjeYnNrO/SZxQfkyC+C9iZSEISZaoQeLOzO5gh1e2rpWLhxJI8blShLmFRt
y+zgNNhK00EkKAN/oA0+XY3eRd+ClNS6EoXC9oZ1YZOWbYdNun3kqZp+tY9I
tqmyV2ybdivOMcuVuPddeqqFwsFznGlQ4w68TdmlWhsURcu5pa/Oyh25Rl31
Qz5jA4/BJA9jKB1NktpH2/QdosSBDpp0Xgd82zDfZquslxItMeKYtBTHcnVL
FsSInCE76XupYRkIGksQ5I79V6Y1tDsk/NCiRD8qWyKpsgKQNQsTtkJ+FQYS
o7Zxlt9nTVXJhe/oujdDjLSNuCjg/BipH1iwnRg35KUrONvROoMcwM51vbmj
aIUm7xsSWcYnqkqoCHrIBwnL3lqfV9oORownPAY/HUb2BSfiIz8o94aYXKoj
V8HupCLxhQakbY51ROT/9EkZ5uAIIwqHuL/U4zrUHG2HXFd59k6z8qRo4xH9
2pWBdPrpEUO1S6OC/3GRrYuak6ylvw6GFp3UpVog4KQCUfNKhwWBdL7u/O61
SqxxOR7avnbHnX5qjfNeFJs/1RL1zu9HUorP+2Zf37mjTYtF9DUnOpMWRZXU
j7NvhMYBCNgnyW932hg1AldfrfPTrpyPvG7FLXNlzAPUxRk4ppHE8JBxVTSx
M4RnmiR33I3A1mV43iCXBe832n9W24QRW10XvnSsChz3kcItzmeRE+lSLTi9
iI8AB/2JeYBeO9Hn24dJWF5YQMKZEKxNYYc6Rehdjd7XJR5LtxC5ltIXh42H
nNJkiXfvskXYm3Td6NOMdcIYBLJ1/CfyD2jCg9aE2cwFKUZnnSuRNWquEgHa
3SFS2CKcD4M0PCbs7eNdcmNZlxOzqb1i48BBiEpUtM3M1muj7pA07DjxpyoU
WSpBG6Wrd1xxpXK1VWnwjPsO2ghQmx96aNMkYmnE8ssNyhuD603DBtppI93A
69KV+D/OLP3pJ0ZzfBeN7mI/UiRDVE+KOO/mlPbZjZ6UN3vTDC/gRnGNEtSu
Q1fbRGmjS4JbDOskX8CwlA83YgD1qD67KfJVVm6BZJ5pZKYsE0BLJce/Y8Bp
QADAdgymII7D4TTluNETITrjFXEMgxfFtBdF/HjcJPzeFgLlSee1ZnKQFCZe
xQcu5khb4QtSVyOzu5B07Y6E1WO0dfBBf3si1rtMlNK0trKb7YgdnDZNAM2k
8ghn987LYrNfByWi6HDIeQsfq/lEnExj69XAHtycjVRy5KFt8yI81fUv8inZ
kl/F5dJvxT+54Rxau/C9CCGqf3eVIqqO8DnOtN87Gy5/16gxoefLYwaBHBm6
dw67toDEfRZ0uLg+TGWJbCpLagN07tLVbUMmWE7mgGvY5UvJ1hYoXt365WUe
mx0u7TErpzuPp42XB8bJ5IgdcnhgcRwcsS0mB3bE5IjN8MA+ODhiChwcmv3i
I0a+5NCilxwx3iWHdrrBEYPcgfUtObC0JQdmteTAhDY4NJYdMYzhMwlKJ9hy
V3DIgHBKZvOuhyQXcyMCL2z6nWlqZt+x2LfN/WX2GyNP08zDoyOYawHCKnNj
pirWtA4XDq+WPGAre5Bi2LQSCeOWOikI6+bICWkSkmlRYK4L6pP+5WDQo58R
GKKXXds5PGs20j3onChy51DWGduqh1SSktagWCO2PFsJ7JZw9YEGkQRxZL5Y
17EOS583mXb9DAMPtANox0lkFFyq5mXufFhSr8Omx3EQuJGwbX/UScqXUoyy
mdfgcpjTRq4CCREOFsHqmNqVpnCZDCfcJvzCTYXdxsubJ4ADqxzuex/332gQ
VfldHAiLA/2U2ZJzcG3Sh6Q4si0B1G/EjKfV3K1a4Nq8ACuGRgFbTAPDB4FH
Jz2RNjDH1sbGjOKhyBuM8cpMR2hJTqs95J8D/png55R/n8zwc8C/9/H7YIIr
B2P+fYx7B6O4g1gKCV8Et+tFz8V8MZ7oZ+OZFFJtdDGOaRPLfCUzfMEokAsQ
SdEZ04xSadHqzb65tM04KSiQUCdlR9YOoaL0fabkeUMn/Bme+Tpd0kl9h4oT
l+n8a7qEZHnH9Bk9/1vc6794ZhxRDkCUTfnEeOnvpHxx0+Zrkp432eKZo+Pp
QLug751vGkcEVbjkEAj0j6o9id21K1vD1WoqLhqrRKcZMqsV6lcSmUgN/10t
OTe3u03Qjua4W/piI9VjcEbE8G68tiSIgCs7OwS+OFjcDqvE4Ii7NXffQ7dv
hDnKZGmkTXqfL1M1Yodn0DZBx6FxPNUtSfhQMTIeHt+ggM3pkAWJpCMpx0yD
3rdeZaR5Saq2lCMqVvBdcFeYihTledYunUF3cyDnCsshCetGy/AAnDUHAfPh
GEfmnvApLwjbYAXs8JZ3mN+Km451kUsVNYbOVjHMpcr4Dawrmt/PKpC+vtRJ
gOiqtvlXAeuYKuopdKSuh1QmsLWw6YWFRFf5bSZi0Jq+jI5pW0fQY4mCFqlU
lIYhE0gUCViatW1n7HxFe05cIgDNgE9gqAsPTEMuixWErck7eFigwyZrREDy
LB/yKpMa8tW6AJl6giHVyqaln3NaevTHTzZRHenwF9phD1aCwvp9oJjg6cAO
ooPZbkitHHcbERylKLKBaAQ0kg/QiFXpi+1OcbwYaCUYtbipnV9HBzY6cChR
r7I1zSafR1fzuwJ86+zywial/2MnzSNtVjvxhVdSq+iurrevXr4kNaVX6QCV
3N8ryuVLoPoouo9fckOTl3G/F0+G08nL8nYOuPpnPdb/pVkK/+U1hP8LQbpS
70cMj7T4Oo2Owxs5zBY5fewLO+TCfGF4fvP5wqscHeNENceEcLdGh/dtd0w6
9qjgYOcZthHxD9AzbBelzOpduWGZaBcJaA/F7bJGBdGUo5EYFVracFKdAdnr
1PWQhD7RvrjlgoPZSYCm95mJUzWAn+5BbUeV+8ZKZ85tw9yP6OeS9wZTmhEt
jYZ752ceNUQ9h8LTlxLdrEGoO00UVFNBxQ0+OKblO1OSUlOa4BbPYOVRkKHv
LsKzRMmi7F6W7/O8LjDmuGPv+Sk4oZ/0Pn9EuzrUNzUhcSGbYyN1GqfIHs9g
DxGnGwSros8npichq8/xJo28q2verkepcIUHhGkMUTObgQNUH6GePMaPfQ5J
tX/FHIH6eHn1OIynj0l/yFGn8u3gUWJM8S1d+chRpY/Elh/7GIUUPXzDv5OK
J/fIX5OZv4zUunC4ZPZI6pyOECfyVTJ6jMccfsf3DR+HHNz5SOqbzJFUN/+s
SaIz4khN//t47K4hFS34fOrflo+ftQFbG76QmkU1w7HUjCRWcJvK9nDg4zyv
/cFP+kZzePyeeQcRxI53yVkVDKFtLKW/Znup8I6i9bbIq3AGrevrs2KlJZTW
IVazESaROXNFVROPEBOkbQKFGklazHAn8f9hODi0Fu8gd+fPNo4yVw1n4lEG
r8NVjaH8IZQOLXQQLJZrIB7ugiJeqjQI9Q/u10W2pV2kC4f2MXffuqqdsqkb
GAKDjdLtCazzebNZnCpgHjKDqUgfriebnHEx3vNLLaF7dKOMRFaKhsgpAKHH
dU4oak1PCRal6l070O0nbnTiHKqvFRSrNTSlI4vuAkY5ilCX1F5/k6eMETZB
4Ry/3Km44X5HyAW3bjzbHPLmv6SbHZQ25qniGxXvhM1xi8SSQbK3SQnE1jZZ
c6w3hArxArqG2osTYptNh2wHA33XLrVFe4Nif83h/mbt7td+vs0UcWBPHCCt
GH6TGVfJ7bp5zm27icaYZ7vlrgpU+2BWcps5uIWlSPT82kYKLSVeBL/qJqoi
K+gzoAkeizMjpdFF4X1k1tf7Qm3zVjByyDZkqMi8/pQRUFEuxPMmKYI3BBVW
+UYcHDDjh6WKPGGFraQV47Pq33q7ILUvWOoHV0OVrVwa2uxNXT3zxqm/fsDQ
B8mp6WXWcKjKEWASWwjdBWZhOCUQjISHLBalOCbylmcmsqG9TvqyhmlVNXY8
G1sA++hacIR3qL//qWIdRBx7jSU04W2MpL1Bg2GRNy0H2+6p68RAGhwlMgWU
g/BkBQn9UyCBWz1LKvIPAAaLG5DAL0J4MH2Mh4/xiHP3WbQOSaD3OWlfpOt4
Rl8/TjhbX+6Z0G18ScJAIaYLHhNOz8efBCXGJJCRlo8/BwmNl3A+PmMAggQj
ggHIw2fAkNC9PNhEnzeRv+PZCLdPCDQknHCPv6aMc5Bnr5J/KF/Hw0S+HuLr
wYQvHslAw/7QAp0+p9HzJBlOIH9eBprS3wmnzcudeu3QgR/6m7fiIE/ebgW+
6MZSieZf2QrkzdsZxQb58vLM2TSheYzpowEtOFZKljmx7zOY8DojM55hXsIv
j5R4WTe8fKLrRiNgE5AErwtHf/LNtOlv8MJ4QeS969e0xXL/bMK7RpsXx3IJ
r9Bgphc4qKd0g/R2ns6jXG7xI43I7zeYyf2xXD0cyJ/y/MQ+f6rzSQb89Fj+
HNJkFX5iO04nqh+DLs3DVx1XucRfk1rWr9rz99LXf/Gn+DH6UCAIopXC/rNk
TtoM9oAYwkRkrc0hCkE/0lDpZskOFM3RCN4k7k1GwbcdTWFRfsCX8NXDXvMy
pz1JUo88i1O+mrUghj3JTBvwKIOkl4yCC+zjlOb7kUZOt686+TQF7aF+KlkB
jVKS2n5PAqaa+EMMmqsFl46BpGCYDpq4yWy8mQgY7SK75Bp64kbZplUF6w5A
J5pVaQQwKsqW6IZZh8FtB9nsAV2p2GqqzMZH3x7RmCMpLoQ6QGyFgwu6lcgb
lhZ05Clkp/VfJJDIubBd+Z6j0k0tYrfpwok6funPQKCQjQ16D4wgNmfcafFc
+odnLXjKQqGGQl1x1xDij2+y7arYS9Gg015Xw0ZjGAmt8fjoSgd6uMTvtnX1
b1JbFHBQCiW4uox2FlxnYWPTzXkUWc5ueTv31Sq5EMFR9dy/4WPwcj+qo4M/
7dYNRd195LV1BLY01HV/jWrFeoXT2j+9PAv0dlfgI1Tf/WdOiUdUeajG+0uc
Mo+D09Tn5dFeo+fY9ECp1zusXi/PsJq9exGr3rsPrI7v5uA0fX+JU/f5GeYd
F3MKISA0T7UBcLAsio+leYkGyTf3UqwYp6RlrDFz1DtnezIX9eUiYsXveVC5
/RnHXz9jLW+jntLQQqDpCw+FQGl+CoNajlFqG4fYOsVeDakhp/SJwtYcLQGh
lpXAlWJcN1aV5blVuzlMzLe7lWgWDwET4KR6P4UqfWgYtf054NQ9MJxlWm6k
grA2sXZFDUIF9Lz1BmACi5JT85EvZhVfW5Jbomy4qDRegfaoyo4EGms6mZ+V
FEpIHw7tNqwz6Wo5vsPuVNsuijmnhrhqbIxrZeiqAGN9TGhMUeasrPPIbmEl
GsaFvDKs+Df7MR0sAXve1VsutffahgdrYKD1lYxVq65tkSkAYmV80WkbqgL9
mLW0thEE2F48fqbdxtN38axshzdXg1uSV1r3iOujLlakOMEt4frE+c4qLHOd
scQGQdCZKst926eCgIfSMmVnKKulH6FQMxT4G58wAquYYWsLDvIxY4taydRY
5DbPbj1C5bVIT35PEG4plCJlIOldtcC6WHTQvTHb1s3sZhcTf3wPWCjCUOE2
ABheNqBZP880dsA2K7rYSOfmd/mqznwDTe5Q4QpQ07M+pntUn+njwOlzpsmE
U5dq78+T6d2Wrvy8GiFYMIq5uszozC84Sh4eMFGX0c6gEhmXS6d1LjnN3gtb
vsSDEzW2YJpcmR8r5E5r7GIgjDCXSuo2EoILhbl1XhKbtu9pF3A8HI1QQki4
aGUOTW2eN7F5hye1LJRhh+0zfDSGQQvOyvMP7Wp3l9nVHAz6Yh8O2Uwv+suO
a/IA64a2NSNe0KL2xmbrqmt0ccFVYE9I4lotWt1IitKI6UNLaNRsw77PKw3H
OY6pvmQ3kVc5gAIbHbdc/I4NbtEJFg7XNZ2CKtAaBiXlXJmTqXZ0Bq3shbrT
nuUNvMmi14j3S6xbymq5Rvz7olhqk5bXbD63wtuKWblYSlg9o0lt6L9n5nnW
W/Y6Ee9pHL9QIVls94fFq6wDIJwB21tl4GyzzDWg2lZWusmkZzi79rW+kg7i
YmPsO3TMVvpviCNIIkGG0HCSfu8H8KK+/yO//Q+YBkLkCMvEbNhAjglhJvzd
9PSMZv3+43Ay1TojFtuNkpg0+GGAIUn37j+OZiO+0CHJwWwAo1CAJpMx6fL9
Wb/pDRoMRvRp3G94hUa4lD5reoemsCZI4RMPLGEHGMbj/oG3KKEnTpN+CDFh
BphJ4RQHM/Gusd5vseZwNnucJQHcHM7GNOIsdCeN4r69z2HOCf0So+6Kw5xj
mvFw0sCceKE4mTQdTdbeCCT6mkFUmQWtK7yriHjo3V6t61ofISbshfNpRrMO
bUKrcd6fow8NZBv4ttDhMs1XfBS1Jec6/531HISmc/KYCyOSwqlSte1Ysz3f
+wjPAiu5KuZfs9r24jAcopByn4QHddzKmO7oavYG3qVyGWbbHbt4JKhX24J0
iJOTvrdFVN9K+mcu6YD+hmwBqZsEzpItIt8ClKDFHbwMesRZmLO4eYYVfNYz
n5nFSc4i4+rWEIh6I+HsrD6lzSZyH5F4nmtJOuOt9+K1k/p8+20mAfA0awYL
8GuEubEinnwfTyWLYiNEgQQqCS6bSODa1IepjThMLZEwtanwNpCr8CjZ9NZ4
xjZ3kKWWmmkSDEJCsFhorx4pOiw8p8NheOymYJHsY5PTKBn1GwzeotsQWD/c
kYDmdyBBkhI9RZzYIe1YhRseCmkQNNu04Xx8Y5POKhsemtYGHosILgshKX3w
sXzEJyICrA/TqA/TJbzRqm0lzMeVJ3nlDp9fabsk8DuEBnlnYYKAOFDh+CTD
E5rPSW1pnlXjdFB7Qlkva3TFbBxGnFusRWWpCrssiU+QP05T4GUKm5XROK5N
BlqvySAcRLUlDC2hXMY11tQMrCy1rlyHa1Q0WSYjr8c5dWw688XvjNipBDT8
qQqwREfL8FleciQsolH7RiLmUILMFs1Grz5eG9/2wlL+rc7QLm3PztjhC/Y4
a58WVDHsNLimRN4ZTXzTEDeFQy6EyBrq9KE45ZxmCdWTOBYfSQsl9GTKuDah
Tr9zLuWw+h1HD0TLXQpNytYCtNRksaS2GXyw/Yy9c9rmcUWfVTVi0XFnG235
Fy1a0Q9hgtdBZAPHw5G6pZkZjJcC+Mr12gL9XOLaPvv4X6G1T/DQX9XZlgNo
CgQ3gU1+C0ONiVSWRSredOexdH11kFZWsvaudXXY6ELvjNgZ2/pRCiwGCRm2
/nrYOAjpmYHbU0+H8dULmgW1bbweKuvZgjTmjz8O2td8a9Z8cE7kwDp6vF6/
DzGr8nWuM3ywGp7k4GlQQKDNi0gNM3u5Bi2DCmaTpWdPzSJ5UnVU41ZkA5pp
nVYxbtbXYP0W4swfDZt2/FYqTaHZ44JegdsT2JJed8oGNSrhtpizjS0ruaGT
K6xYBM12uF8iihtKcaPq0NgsCbmNWDL3udF6F6yLB9EkqfaHpdOyREakd9W4
lE1t3+03xKXVStNHHicTnUjrTrgsJ++xdYHzpbeUkVpBRBGEXVa+W1JkzMdg
rq7G/+kKkS5alQOZTViQ0aWY3EGX5OzvwMKgLoQHUZuRYYt3hEndHDykBcw0
0FbazzXphbtCnhN8IJXXJk2WGTqpeacHSRVaLtd21SVtaAUHX9tTKT14p150
1X6NIAaFLUHWpMYw2tcxMZKO5Swmh0Nw63ZWvdMFEy5i0CHTbnY0+w26pxvH
nOeEh0qOrKGrFlm3uL11+an+SXwk2ejBKEYTqo10ygO/UgYgiAx30Bjw+Njg
eX/+lLX0oucXrglDUCE2fB11abXXsVGsE2Nr6AQCl43tBprLnqCTvUzPYrrw
ZglOXe0ReHJ9PFRdYskzdsPY2I1eIwHCNMo1uIN9PKu1CuDrTeZ6Wgi9IspN
D4FsTmhF9BmpwbmjA2xzD1gYOINgmIrSgI5H3UdBDqCLi7Z6gtTrY1PWtijK
6EhB4EMvwXl7lLAlYpNvOItmYJ/W1r9qNDK21aIYSu+BnZEq0Ki74yCzr07s
qkQSAgpcYWzytGNr3Z9DneO2jbSgfszTbb1rhOm45dfXSH2K6BH18wCSWpuV
o/p7X41Z4y75gHpbvfpu5KQH2Mk5N615/gBDsRLokKKrZRKmbGvtksrF2dmA
PYmhj54JLKrvnukLpCuO5zKi0iuIET0d9tgsW3DrvaKBOoJK+h5hEcAzDuBF
AvCY01sJAkYSlDYM2atNvDPtUr7aAJ29SQ/c+i/sHYn0XvZT4+gWa67yQMod
TPX2RSC1bAvYsCh8+Iz2IrLvxz6ncqgt8i1kGyFnWubbBGW+OUmcu/MIA5QE
D+6Py37cMHkDdAMB/YyO131+j9JTeVo9C9PIWAtTmeSSL129ZZutJG1zaS3T
MDlpDdtDxBVJXVyXxLZVmlYBbRumijvZ1WbZEOJnqk6HBaOdf0oiDAjGLH1T
UFq11PIitAEQY1GzCZP0f+FruFxGUz1Q6uEcdNTSgGfVWCu17XGspdPqosDS
oPSGVHfPK8hZ+nbheumC7GBgMDw1ti8gX2XfthjbYe3r+RrwRWSclyvMKdCG
4gFpkD68WSCumRvLGttYVnePr6O15boS1pUZtvzlymNsYqKjlc6tqOJjDIEt
GbwFsSaQKKbHPlTrAr61RVW2uxJk0osuczq+UkwGJXMU2NSaqdoxJJUYiGA/
3NyFrDVmGHRtNZZ7wJmlOA3YQr1vvXXPfJGOEJZsFEZUxWonIozkRrn0EKwB
2v4cfbaVb2z9+1Aw897ecyE8ovNV+qCD5LZpbLriER6aU2BN8lZORbpC7+Pd
EoLhZgWL4cJan0Acf46+aHwv/sIqVju7HLbWAmoVbHbZn83PBC1udyvEpOMR
OEOsEHPQJ87RV5hQOFvLrpvw7J+iK+vGPFc2o84Z5USc6OxAs4i6PZeVD2LM
v2QqflzmFZj/P70/x/lK86raWTNjuIacBNNq4enkqvVJi+7MtSh+ZLKubhhN
tll16zJDaPOmkWfrbmvq/nxjLll4wuH3ga5sbGKb17OOpj7+FJ3NwTpIkgla
oSl/xFBQQb+64KgW7GtkbnMGJq8bdpYhe2Gs1fKEdHxlPpKilhKGOYN4Iea9
6Zj/N0Xqxtkq75irtEzvoteYQse8LnebAuHnZZptSDf4ANX2Lfq31x3zieT8
Jo/eroiQ6Nq/QKTk6+gdKY0bGuhNTre+Q7GSdD6nv89pbdiM+y5fVbc5ClFc
7X6jlXq/29YpXU/c+Oe0lMH+Rnft06/Rz9lyQc99nW1+Q4/b6K/pYvcVz7qj
31dwsdPsz+akxX9AJjpxjE/516KKPqb3xLZyRKBsiQ8VNORlCjn7Nfo4p1Xe
8TO4lOJHQvebgkZZ4dcaxUzONosyy6NLuve+Y96WwHEZEWa5onli+egZ0RXS
xWlqd7v7dJNVD7BARX8D+ISmTHuI5SqiLxnKdzCHMh/y6O/5P4mrklhrbfXZ
okRMI60XQU5mlKBe4g+cgLi4z+eIhinYHgQzlly4YsZ3XtBGoIk91s5GtRHX
We7yRcoF34QCtEhIkOWWSsG7NwC952XhNJ5Uu6TfSc6M0UYJBv/BsQa6Mv6/
/x+YZQ0Qg/wAAA==
</rfc> </rfc>
 End of changes. 175 change blocks. 
3636 lines changed or deleted 4570 lines changed or added

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