<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.27 (Ruby 2.6.10) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-tls12-frozen-08" number="9851" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->

  <front>
    <title abbrev="tls1.2-frozen">TLS abbrev="TLS 1.2 Frozen">TLS 1.2 is in Feature Freeze</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tls-tls12-frozen-08"/> name="RFC" value="9851"/>
    <author fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <author fullname="Nimrod Aviram">
      <organization/>
      <address>
        <email>nimrod.aviram@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="April" day="03"/>
    <area>Security</area>
    <workgroup>Transport Layer Security</workgroup> year="2026" month="January"/>
    <area>SEC</area>
    <workgroup>tls</workgroup>
    <keyword>TLS</keyword>
    <keyword>features</keyword>
    <abstract>
      <?line 70?>

<t>Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is
   growing.  This document specifies that no changes will be approved
   for TLS 1.2 outside of urgent security fixes (as determine determined by
   TLS WG Working Group consensus), new TLS Exporter Labels, or and
   new Application-Layer Protocol Negotiation (ALPN) Protocol IDs,
no changes will be approved for TLS 1.2. IDs.
   This prescription applies to TLS only; it does not pertain apply to DTLS (in
   any DTLS version); it pertains to
TLS only.</t> version).</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Transport Layer Security Working Group mailing list (<eref target="mailto:tls@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/tls/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/tls/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/tlswg/tls12-frozen"/>.</t>
    </note>
  </front>
  <middle>
    <?line 80?>

<section anchor="sec-reasons">
      <name>Introduction</name>
      <t>Use of TLS
      <t>TLS 1.3 <xref target="TLS13"/> is growing, and it target="RFC9846"/> fixes most known deficiencies with TLS 1.2 <xref target="TLS12"/>.
Examples target="RFC5246"/> and its use is growing.  Some examples of this the fixes include
encrypting more of the traffic so that it is not readable by outsiders and
removing most cryptographic primitives that are now considered weak. Importantly, TLS
1.3 enjoys robust security proofs.</t>
      <t>Both versions have several extension points. Items like new cryptographic
algorithms, new supported groups (formerly "named curves"), etc., can be
added without defining a new protocol. This document specifies that no changes will be approved for TLS 1.2 outside of
urgent security fixes (as determine determined by TLS WG consensus), Working Group consensus) and the exceptions listed in <xref target="iana"/>,
no changes will be approved for TLS 1.2.</t> target="iana"/>.</t>

      <t>This prescription pertains applies to TLS only. As such, it does not pertain apply to
DTLS, in any DTLS version.</t>
    </section>
    <section anchor="implications-for-post-quantum-cryptography-pqc">
      <name>Implications for Post-Quantum Cryptography (PQC)</name>
      <t>Cryptographically relevant quantum computers, once available, are likely to
greatly lessen the time and effort needed to break
RSA, finite-field-based Diffie-Hellman (FFDH), or Elliptic Curve Cryptography (ECC) which are currently used in TLS.
In 2016, the US National Institute of Standards and Technology (NIST) started a
multi-year effort to standardize algorithms that will be "safe"
once quantum computers are feasible <xref target="PQC"/>. First Initial discussions in
the IETF community happened
around the same time <xref target="CFRGSLIDES"/>.</t>
      <t>In 2024 2024, NIST released standards for <xref target="ML-KEM"/>, <xref target="ML-DSA"/>, and <xref target="SLH-DSA"/>.
Many other countries and organizations are publishing their roadmaps,
including the multi-national standards organization ETSI, ETSI <xref target="ETSI"/>.</t>
      <t>While the industry was waiting for NIST to finish standardization, the
IETF has had several efforts underway.
A working group was formed in early 2023 to work on the use of Post-Quantum Cryptography (PQC) in IETF protocols
<xref target="PQUIPWG"/>.
Several other working groups, including TLS <xref target="TLSWG"/>,
are working on
specifications to support hybrid algorithms and identifiers, for use during a
transition from classic to a post-quantum world.</t>
      <t>It is important to note that the focus of efforts effort within the TLS Working Group is  focused exclusively on TLS 1.3 or later.
Put bluntly, PQC for
TLS 1.2 will not be specified (see <xref target="iana"/>) at any time and time; anyone wishing
to deploy PQC should expect to be using use TLS 1.3.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This entire document is about security, security and provides post-quantum security concerns
as an additional reason to upgrade to TLS 1.3.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>No TLS registries <xref target="TLS13REG"/> target="RFC9847"/> are being closed by this document.
Rather, this document modifies the instructions to IANA and the TLS
Designed
Designated Experts to constrain what the type of entries that can be added to existing
registries.</t>
      <t>This document does not introduce any new limits limitations on the registrations for either of
the following two registries:</t>
      <ul spacing="normal">
        <li>
          <t>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</t>
        </li>
        <li>
          <t>TLS Exporter Labels</t>
        </li>
      </ul>
      <dl>
        <dt>All other TLS registries should have this Note

      <t>The following note has been added to them:</dt>
        <dd>
          <t>Any the other TLS registries:</t>

      <blockquote><t>Any TLS entry added after the IESG approves publication of {THIS RFC} RFC 9851
      is intended for TLS 1.3 or later, and makes no similar requirement on
      DTLS.  Such entries should have an informal indication like "For TLS 1.3
      or later" in that entry, such as the "Comment" column.</t>
        </dd>
      </dl> column.</t></blockquote>

      <t>At the time of publication, the list of other note has been added to the following TLS registries is as follows:</t> registries:</t>
      <ul spacing="normal">
        <li>
          <t>TLS Alerts</t>
        </li>
        <li>
          <t>TLS Authorization Data Formats</t>
        </li>
        <li>
          <t>TLS CachedInformationType Values</t>
        </li>
        <li>
          <t>TLS Certificate Compression Algorithm IDs</t>
        </li>
        <li>
          <t>TLS Certificate Status Types</t>
        </li>
        <li>
          <t>TLS Certificate Types</t>
        </li>
        <li>
          <t>TLS Cipher Suites</t>
        </li>
        <li>
          <t>TLS ClientCertificateType Identifiers</t>
        </li>
        <li>
          <t>TLS ContentType</t>
        </li>
        <li>
          <t>TLS EC Curve Types</t>
        </li>
        <li>
          <t>TLS EC Point Formats</t>
        </li>
        <li>
          <t>TLS ExtensionType Values</t>
        </li>
        <li>
          <t>TLS HandshakeType</t>
        </li>
        <li>
          <t>TLS HashAlgorithm</t>
        </li>
        <li>
          <t>TLS Heartbeat Message Types</t>
        </li>
        <li>
          <t>TLS Heartbeat Modes</t>
        </li>
        <li>
          <t>TLS KDF Identifiers</t>
        </li>
        <li>
          <t>TLS PskKeyExchangeMode</t>
        </li>
        <li>
          <t>TLS SignatureAlgorithm</t>
        </li>
        <li>
          <t>TLS SignatureScheme</t>
        </li>
        <li>
          <t>TLS Supplemental Data Formats (SupplementalDataType)</t>
        </li>
        <li>
          <t>TLS Supported Groups</t>
        </li>
        <li>
          <t>TLS UserMappingType Values</t>
        </li>
      </ul>
<!-- [rfced] We see that the following TLS registries have been added to
<https://www.iana.org/assignments/tls-parameters>, but there are no comments for the entries.  Please review.

TLS SSLKEYLOGFILE Labels [draft-ietf-tls-keylogfile-05][RFC9847]
TLS RRC Message Types [draft-ietf-tls-dtls-rrc-20]

While any updates would be needed for draft-ietf-tls-keylogfile and draft-ietf-tls-dtls-rrc, it would help us understand whether comments or Notes are expected for these registries.
-->

<!-- RPC note: As noted in the document, these registries are untouched by this document:
TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
TLS Exporter Labels
-->

      <t>Any TLS registry created after this document is approved for publication
should indicate whether the actions defined here are applicable.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC5246" to="TLS12"/>
    <displayreference target="RFC9846" to="TLS13"/>
    <displayreference target="RFC9847" to="TLS13REG"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>

<!-- [RFC9846 / TLS13]
draft-ietf-tls-rfc8446bis-14
-->
        <reference anchor="TLS12">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author fullname="T. Dierks" initials="T." surname="Dierks"/>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="TLS13"> anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="Eric Rescorla" initials="E." surname="Rescorla"> surname="Rescorla" fullname="Eric Rescorla">
              <organization>Independent</organization>
            </author>
            <date day="17" month="February" year="2025"/>
            <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 message forgery.

   This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
   RFCs 5077, 5246, 6961, 8422, and 8446.  This document also specifies
   new requirements for TLS 1.2 implementations.

              </t>
            </abstract> month='January' year='2026'/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-12"/>
        </reference>
        <reference anchor="TLS13REG">
          <front>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
              <organization>Venafi</organization>
            </author>
            <author fullname="Sean Turner" initials="S." surname="Turner">
              <organization>sn3rd</organization>
            </author>
            <date day="11" month="March" year="2025"/>
            <abstract>
              <t>   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   Recommended column of the selected TLS registries and adds a
   "Comments" column to all active registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

              </t>
            </abstract>
          </front> name="RFC" value="9846"/>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8447bis-11"/> name="DOI" value="10.17487/RFC9846"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9847.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard -->

<reference anchor="ML-KEM" target="https://csrc.nist.gov/pubs/fips/203/final">
  <front>
    <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
    <author>
              <organization/>
      <organization abbrev="NIST">National Institute of Standards and Technology</organization>
    </author>
    <date year="2024" month="August"/> month="August" year="2024"/>
  </front>
  <seriesInfo name="NIST FIPS" value="203"/>
  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.203"/>
</reference>

<reference anchor="ML-DSA" target="https://csrc.nist.gov/pubs/fips/204/final">
  <front>
    <title>Module-Lattice-Based Key Digital Signature Standard</title>
    <author>
              <organization/>
      <organization abbrev="NIST">National Institute of Standards and Technology</organization>
    </author>
    <date year="2024" month="August"/> month="August" year="2024"/>
  </front>
  <seriesInfo name="NIST FIPS" value="204"/>
  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.204"/>
</reference>

<reference anchor="SLH-DSA" target="https://csrc.nist.gov/pubs/fips/205/final">
  <front>
    <title>Stateless Hash-Based Key-Digital Digital Signature Standard</title>
    <author>
              <organization/>
      <organization abbrev="NIST">National Institute of Standards and Technology</organization>
    </author>
    <date year="2024" month="August"/> month="August" year="2024"/>
  </front>
  <seriesInfo name="NIST FIPS" value="205"/>
  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.205"/>
</reference>

        <reference anchor="PQC" target="https://csrc.nist.gov/projects/post-quantum-cryptography">
          <front>
            <title>Post-Quantum Cryptography</title> Cryptography (PQC)</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date year="2017" month="January"/>
          </front>
        </reference>
        <reference anchor="CFRGSLIDES" target="https://www.ietf.org/proceedings/95/slides/slides-95-cfrg-4.pdf">
          <front>
            <title>Post Quantum Secure Cryptography Discussion</title>
            <author initials="D." surname="McGrew" fullname="David McGrew">
              <organization/>
            </author>
            <date>n.d.</date>
            <date month="April" year="2016"/>
          </front>
          <refcontent>IETF 95 Proceedings</refcontent>
        </reference>
        <reference anchor="PQUIPWG" target="https://datatracker.ietf.org/wg/pquip/about/">
          <front>
            <title>Post-Quantum Use in Protocols</title>
            <author>
              <organization/>
              <organization>IETF</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="TLSWG" target="https://datatracker.ietf.org/wg/tls/about/">
          <front>
            <title>Transport Layer Security</title>
            <author>
              <organization/>
              <organization>IETF</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="ETSI" target="https://www.etsi.org/deliver/etsi_tr/103600_103699/103619/01.01.01_60/tr_103619v010101p.pdf">
          <front>
            <title>CYBER; Migration strategies and recommendations to Quantum Safe schemes</title>
            <author>
              <organization/>
              <organization abbrev="ETSI">European Telecommunications Standards Institute</organization>
            </author>
            <date>n.d.</date>
            <date month="July" year="2020"/>
          </front>
          <seriesInfo name="ETSI TR" value="103 619"/>
          <refcontent>Version 1.1.1</refcontent>
        </reference>
      </references>
    </references>
    <?line 186?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We gratefully acknowledge Amanda Baber, David Dong, <contact fullname="Amanda Baber"/>, <contact fullname="David Dong"/>, and Sabrina Tanamal <contact fullname="Sabrina Tanamal"/>
of IANA for their help in revising and clarifying <xref target="iana"/>.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIADqb7mcAA7VZa28bNxb9zl9xoX6xAY1kO066cbFAFct2tLEN13I32E8B
NUNJrDmPkhzLiuD/vueSM9LYdbZNgW0aSOLwcR/nnns4SZJEeO2NOqHe3eWU
DgdHpB3pgs6V9LVVdG6V+qp6Qs5mVj1gmjcOs5K5Lb+qoidS6dWitOsTcj4T
IivTQubYLrNy7hOt/DzBCv572C5KDNY4L1w9y7Vzuiz8usKSydnduSjqfKbs
icgw50SkZeFU4Wp3Qt7WSsCAN0JaJWHIVKW11X7dE6vS3i9sWVfshZWFq0rr
6VKulaXdrHu1xsTsRFBC8JU/5tFJJx5UUeM4oj/fhiha2/uMU3WxoAtewuO5
1CYG6Gf2e1DaBQ8vtF/Ws/hgtRh2I9ETQtZ+WcLfBDPntTExerc6XdJUmq8Y
xTay0F+lR6BOaHQvcQ7dqXRZlKZcaFhPpOLZ1mHJzzJMGaRl/mLXa53bMqPR
g7Yy360qwvBAhuGfFzwYFouitDmOfQiRQcgOj2DZ+enbo+N3zcAbZC0ZD14k
287Tfxwfv5tp1067Pbv4HzN/5JlCF/PueVeXyaezK/6GiEu7UP6Elt5X7mQ4
TJ1NB4V2frAoH4ZVPXPDua7c8OjgDb4U0sRVDbCvyqw2KrmU3utUJR+kUxl9
UuvkrEhl5WoTQktXCCkC7XKaellk0ma9sE1AIvVG9aJ2ng7f9Ono4Oi4F00c
T0ffa+Lxd5hIYw34SENTvShiQf5V46aXH/+OdW9fsQ5HemWUc/RRumUngH/f
uptfTv+SZbb8TaXeDavS+eT3Wha+zpPUritfLqysluvOOf+SRS3tmg85/LHr
wA0v/iUuptPni0/Pby+ml5Px2fR1e1ar1aCtZjYnVSpD1bvh+7dDZ3SmXPOR
vH+bpHO7SI4HVTZ/eTy1xwciUc+sQJJdWgciDMtaSqDwny5AfuMBXaUXVq2a
wVjPY5Rstntw88uvk5vPF6/7gRBJb2V6r+zOH9BR9Xutq6GclbUffjNmvzrF
PeHGlr5MS9OU9fcehYJ/5aBvMS3mnN1NJ9/OivJOh60zZcAZdsgDX7wdHh68
eXdw8IU/3r8Pvw7fDw8OB+H/L+8Oht5+iaMPB4f8p3qZsdP/fDi7/YmuNBIU
uMHBH/Q5kC0B32QV+DFXQDo/deTLXX7lXJFLlyoHMYskSUjOeHXqheAwlnOK
jRbFsFoyzdNcP2JfV+aK7otyVVCm5jrVqkj5PMS96cx9bs1oUCvgbyDulviF
dlvDDk+uUqme83y/lJ4QZAdQ4jRRI3I8oQlrc9qexGLllc11oWi2Dmd8vqBt
w93vU6FWYfjskdOD1FzKmTKuj47Ez8SoqoxOQwiSmLsWIHQNTeB1jN3e6PLm
en/3bDJ2fbQWYrZdwJSVNoZmimSF8noAs6ANtC43blbo0anVVdgvK7GoKD1V
ynqJ8CD6Y56/h++yWMcfAAQX1P5PpLczOVGCH5aFWQ9idnKdZUYJ8QNNCo82
WKfhkM0PCFgCoeEQkKeXqaPNJrS1p6dOSvoBGtqLGOGcq/6VfK4gB1r3mn2O
np4G4uxR5hVIlo/xyyDCUlNnSmAdkwVLjby0Kj5X0ENyjm2Bm5hyuKljXGB1
JmcmpLUBgg24FVbl5UPcCMZ1aBT7VFbnmpsvb7IKQOCFyMdKyfsBTXJGAUBu
wLCsnzgOqvitXDuy5YwJfosxJLKcO0T4Qwlnm1Q4WsoH1IbCb/QM9egBNI51
VerCO5zgVe7I6HsVoPfMPCENVCZCl7sITFdXAZVZlGxANKsHZc2aesyOGcEW
ONMDkEn5dNCnVBbAmZBZxk5hLwQn5KbgkMiwbdWgdED///piuHAm1WOqqkgk
Bo0PxgHIm42WhXx6+o5SeaVWOsCnLfBpBLap02WfMfNKNQkuoD69Uk2DUCf5
tuxdMOCb7ZX20Ob3hTjtZlIapMhCTjxgATUtHXHJqxrhYnYpUnj4ABXKIEaY
gHkGBZbBtgXQDQgSyxFVxErQYE4OpprPuY8UaNGIDVzGlUXei9vpqE+cZa8S
pNBkySwomLFGAankozImBzT2zs/HH/cDu50ZwwFM6ZQx9MKns9PT/Ya62TSk
3SquCqpdTB0CNhCTgmXIu36w8NcpXYeAAfeTwqHLwFcu5FYuxbayFfU45Xoy
vdtH35EB41LktfE6WStpWzfhn2uW668IwLZAIkRbrPQcOlJPhKj+IdrBA9yC
nGa+2GyQL3ARnWuLcs62soTJSLAjfEXj1XldMNaXAKIqVIYrWVk3aHYovpiS
zWYnrpjhYkyOjol9CxAIaXDbGDCYNpso/IH8+B0alr9zfDabRtTyblcMTtAL
2k6Kw71tm3P3vhQdhL5FYS25yjFfW/CVzHJI/76IJNs8oRjkok3VzrLunkGW
sHH8Gfz6vNSIHm+giwxEaNe0Qv2vpA6szW4Fl5ExhqFbdhIXtgwoESG4S8k8
me1oMiTbEcKr7EqibY1o1dw8A/OFowL3BfABIIAiwvyGj+OZKCiGJsPtTyqV
1wcjqq3QY0gEVcmOThubYtSfWeH6tAslM0bobLysz/f17WRI3IZK0512aric
luuZhaDtIDl01AzlxdzL5MCxZGcykC2TtvAsH3XIC+7UgLaRgGzK20rq3hrY
BJMxCkOj1G0745ngPxWrhpM4B+mHNtzGnnuFjlwTaLx78RfYCwRuaofWadZb
hQA7+TWHHYgbdJmZqWPjRJjZB9EKgFClTL+o1LbHZLTnlNp2gH2CXQz2Lc/h
R4musoqYFnAgU5Up12F3h7ZmwIWP2C04h51hXJMWmBZIvFXZdNr0+ZiNpodw
wJG0bffDUBDu2y4X65GbEF99nsc5Zaqx2Ety/gjtVjf1FOUU21RXwB36Z9OW
Wqsmo+vRC4ugxEIYhLiOcy1kuIvV3qiw2zPALBT6TLGfqSmZV9B0fbeHD8St
ZOD2nw9DC2VtZ+cCxt5RAwZoBovaRs2qZ6wcLrvYHqpYMTgwiZs6cAiIrAKG
1lWoNtWQUtQdFHUHpqtHOMCJ27nSNu+tUdu2rBtVqgIEWKIY1mmOq5ptavbo
tGOlQ3lCmkQwGxPkKflV2QneCeRviOffV/HNBi+uB0KMTEsRL/LVQDPIwJCD
a667bVywJIdZJzQqYh1xANfxuZBzPiL2oOlFq4Bc5PZoPsd8c/dxMuWXVE/x
PSY0ZvZMJ3FlilCZEcO5vA+RJoewGnRXq3AjhlDmLGDPcejmU8ilbT67biC1
zXsrw+TfWCKCiO2dPzs18kGPApMAJsG7flBiJAP6RO80XCt9D5Aydc56a+R3
Ggf+ddyN0oIVIz94NeBct66BQCfjhoHb/ggvG9rWNsbVnc7Da7h2wqnEZTab
tC/nyuKO4f1vaWq1nYL9IqNDK0FaQIEGYT9qibyDlu5cfq8EpuUNX3v8bFxX
7N+0hojbjhncqXxnRbBssmsX7bySYeD5aQvZ00bZdY/A4A3fRF74f9beU/7o
90cAyC0BoM7W/IZs63c7hqbsZ9CtdIXIyMXzcztPy2w7+ml8/oorN+7+k1qf
PcYLAc9vHmzfwL08e/tgGt5JtKPouCZgHLjtJp32uo/4CZu631kWL12h97VW
4XJsr1CRYJlukERbxw0i17jSwU2Ws00xdxmPsdq91nSQLpqKawoMnW+pAty5
AGRD1uEih7UYV6EZyEhsELbNVX8m03vuMqOUr+VGZQs+GBrnJP6jg8r+2ZtL
41QP3eazIn75o/jtOThou0TRKGftRh/AduCQ+A5uXLb3/6mEhikk3aFpgRQE
SjP0EHYpis+lMhWTgFUPOvRlXgbZYvV8zT/bvj8Q/wWdevXPnhkAAA== [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>

</rfc>