<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.2) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-must-not-ecc-gost-07" number="9906" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3">

  <front>

<!--[rfced] We have updated the short title that spans the header of
the PDF file to more closely match the title. Please let us know
of any objection.

Original:
   MUST NOT DNSSEC with ECC-GOST

Current:
   Deprecate Usage of ECC-GOST
-->

    <title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate usage Usage of ECC-GOST within DNSSEC</title>
    <seriesInfo name="RFC" value="9906"/>
    <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization>USC/ISI</organization>
      <address>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization>Google</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2025" month="June" day="03"/> month="November"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<abstract>

<?line 53?>

<!--[rfced] This document discusses no longer using the GOST R 34.10-2001
and GOST R 34.11-94 algorithms but only "GOST R 34.10-2001" is
mentioned in the first sentence of the Abstract. Is that
intended, or should GOST R 34.11-94 also be included?

Original:
   This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-
   GOST") within DNSSEC.

Perhaps:
   This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-
   GOST") and GOST R 34.11-94 within DNSSEC.
-->

      <t>This document retires the use of GOST R 34.10-2001 (mnemonic
      "ECC-GOST") within DNSSEC.</t>

<t>RFC5933
      <t>RFC 5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94
      algorithms with DNS Security Extensions (DNSSEC).

<!--[rfced] We note that this document does not "update" RFC 5933 but
rather moves it to Historic status. For clarity, may we update
the Abstract to reflect this as shown below?

Current:
   RFC 5933 (now historic) defined the use of GOST R 34.10-2001 and GOST
   R 34.11-94 algorithms with DNS Security Extensions (DNSSEC).  This
   document updates RFC5933 RFC 5933 by deprecating the use of ECC-GOST.

Perhaps:
   RFC 5933 defined the use of the GOST R 34.10-2001 and GOST R 34.11-94
   algorithms with DNS Security Extensions (DNSSEC). This document
   moves RFC 5933 to Historic status by deprecating the use of ECC-GOST.
-->

      This document updates RFC 5933
by deprecating the use of ECC-GOST.</t>
    </abstract>
  </front>
  <middle>

<?line 62?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
  <name>Introduction</name>

<!--[rfced] This sentence reads oddly as it sounds like the DNS
Security Extensions were documented in RFC 5933 yet there is a
reference to RFC 9364. For clarity, may we rephrase this as shown
below?

Original:
   The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with
   the DNS Security Extensions (DNSSEC) [RFC9364] was documented in
   [RFC5933].

Perhaps:
   The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are
   documented in [RFC5933] and their use with DNS Security
   Extensions (DNSSEC) is further described in [RFC9364].
-->

      <t>The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with
the DNS Security Extensions (DNSSEC) <xref target="RFC9364"></xref> target="RFC9364"/> was documented in
<xref target="RFC5933"/>. These two algorithms were deprecated by the Orders of the
Federal Agency for Technical Regulation and Metrology of Russia
(Rosstandart) in August 2012, 2012 and were superseded by GOST 34.10-2012
and GOST 34.11-2012 34.11-2012, respectively. The use of these newer two newer
algorithms in DNSSEC is documented in <xref target="RFC9558"/> target="RFC9558"/>, and their associated
requirement levels are not changed by this document.</t>
      <t>Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) "ECC-GOST") and GOST R 34.11-94
is no longer recommended for use in DNSSEC <xref target="RFC9364"/>.</t>
      <section anchor="requirements-notation"><name>Requirements notation</name>

<t>The anchor="requirements-notation">
        <name>Requirements Notation</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="deprecating-ecc-gost-algorithms-in-dnssec"><name>Deprecating anchor="deprecating-ecc-gost-algorithms-in-dnssec">
      <name>Deprecating ECC-GOST algorithms Algorithms in DNSSEC</name>
      <t>The GOST R 34.11-94 algorithm <xref target="RFC5933"/> algorithm MUST NOT <bcp14>MUST NOT</bcp14> be used when
creating DS Delegation Signer (DS) records.  Validating resolvers MUST <bcp14>MUST</bcp14> treat GOST R 34.11-94
DS records as insecure.  If no other DS records of accepted
cryptographic algorithms are available, the DNS records below the
      delegation point MUST <bcp14>MUST</bcp14> be treated as insecure.</t>

<t>The

<!--[rfced] Would it be clearer to include the descriptive name "GOST
R 34.10-2001" (instead of the mnemonic "ECC-GOST") here for clarity?
We ask because "GOST R 34.11-94" was used in the previous paragraph.

Also, we updated "these algorithms" to "this algorithm" as we assume
it is referring to the ECC-GOST <xref target="RFC5933"/> algorithm.

Original:
   The ECC-GOST [RFC5933] algorithm MUST NOT be used when creating
   DNSKEY and RRSIG records.  Validating resolvers MUST treat RRSIG
   records created from DNSKEY records using these algorithms as an
   unsupported algorithm.

Perhaps:
   The GOST R 34.10-2001 algorithm [RFC5933] MUST NOT be used when creating
   DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records.
   Validating resolvers MUST treat RRSIG records created from DNSKEY
   records using this algorithm as an unsupported algorithm.
-->

<t>The ECC-GOST algorithm <xref target="RFC5933"/> <bcp14>MUST NOT</bcp14> be used when creating
DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records.  Validating resolvers <bcp14>MUST</bcp14> treat
RRSIG records created from DNSKEY records using these algorithms as
unsupported algorithms. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver MUST <bcp14>MUST</bcp14> consider the
associated resource records as insecure.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document potentially increases the security of the DNSSEC ecosystem by
deprecating algorithms that are no longer recommended for use.</t>
    </section>
    <section anchor="operational-considerations"><name>Operational anchor="operational-considerations">
      <name>Operational Considerations</name>
      <t>This document removes support for ECC-GOST. Zone operators currently making use
of ECC-GOST based ECC-GOST-based algorithms should switch to algorithms that remain supported.
DNS registries should prohibit their clients from uploading and publishing
ECC-GOST based
ECC-GOST-based DS records to ensure that they are using algorithms which that are
supported by DNSSEC validators, validators and so thus can be DNSSEC validated.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>[Note to IANA,

<!--[rfced] Section 5. For clarity, may we update this text to reflect
all of IANA's updates? Also, should "DEPRECATED" be removed by added to the RFC Editor:
Description column for "GOST R 34.11-94" (to match the registry fields
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t>

<t>IANA is requested to entry for
"GOST R 34.10-2001 (DEPRECATED)") as shown below?

Current:
   IANA has set the "Use for DNSSEC Signing", "Use for DNSSEC
   Validation", "Implement for DNSSEC Signing", and "Implement for
   DNSSEC Validation" columns of in the DNS "DNS Security Algorithm Numbers Numbers"
   registry
<xref target="DNSKEY-IANA"/> <xref target="draft-ietf-dnsop-rfc8624-bis"/> for ECC-GOST (12) [DNSKEY-IANA] [RFC9904] to MUST NOT. NOT for ECC-GOST (12).  Note
   that previously the "Use for DNSSEC Signing" and "Implement for DNSSEC
   Delegation" columns were already MUST NOT.</t>

<t>IANA is requested set to MUST NOT.

   IANA has set the "Use for DNSSEC Delegation", "Use for DNSSEC
   Validation", "Implement for DNSSEC Delegation", and "Implement for
   DNSSEC Validation" columns of in the "Digest Algorithms" registry <xref target="DS-IANA"/>
   [DS-IANA] to MUST NOT for GOST R 34.11-94 (3) to MUST NOT. (3).  Note that previously the "Use
   for DNSSEC Signing" and "Implement for DNSSEC Delegation" columns
   were already MUST NOT.</t>

</section>

  </middle>

  <back>

<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used set to signify MUST NOT.

Perhaps:
   IANA has updated the requirements GOST R 34.10-2001 (12) entry in the specification. These words are often capitalized. This document defines these words "DNS
   Security Algorithm Numbers" registry [DNSKEY-IANA] [RFC9904] as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices
   follows:

   Number: 12
   Description: GOST R 34.10-2001 (DEPRECATED)
   Mnemonic: ECC-GOST
   Zone Signing: Y
   Trans. Sec.: *
   Use for the Internet Community, and requests discussion and suggestions DNSSEC Signing: MUST NOT
   Use for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5933">
  <front>
    <title>Use DNSSEC Validation: MUST NOT
   Implement for DNSSEC Signing: MUST NOT
   Implement for DNSSEC Validation: MUST NOT
   Reference: [RFC5933], [Change the status of GOST Signature
     Algorithms in DNSKEY DNSSEC in the IETF stream to Historic], and RRSIG Resource Records RFC 9906

   Note that the "Use for DNSSEC</title>
    <author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov"/>
    <author fullname="A. Chuprina" initials="A." surname="Chuprina"/>
    <author fullname="I. Ustinov" initials="I." surname="Ustinov"/>
    <date month="July" year="2010"/>
    <abstract>
      <t>This document describes how to produce digital signatures DNSSEC Signing" and hash functions using "Implement for DNSSEC
   Delegation" columns were already set to MUST NOT.

   IANA has updated the GOST R 34.10-2001 and 34.11-94 (3) entry in the "Digest Algorithms"
   registry [DS-IANA] [RFC9904] as follows:

   Value: 3
   Description: GOST R 34.11-94 algorithms (DEPRECATED)
   Use for DNSKEY, RRSIG, and DS resource records, DNSSEC Delegation: MUST NOT
   Use for use in DNSSEC Validation: MUST NOT
   Implement for DNSSEC Delegation: MUST NOT
   Implement for DNSSEC Validation: MUST NOT
   Reference: [RFC5933], [Change the Domain Name System Security Extensions (DNSSEC).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5933"/>
  <seriesInfo name="DOI" value="10.17487/RFC5933"/>
</reference>
<reference anchor="RFC9364">
  <front>
    <title>DNS Security Extensions (DNSSEC)</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <date month="February" year="2023"/>
    <abstract>
      <t>This document describes status of GOST
    Signature Algorithms in DNSSEC in the DNS Security Extensions (commonly called "DNSSEC") IETF stream to
    Historic], and RFC 9906

   Note that are specified in RFCs 4033, 4034, the "Use for DNSSEC Signing" and 4035, as well as a handful of others. One purpose is "Implement for DNSSEC Delegation"
   columns were already set to introduce all of MUST NOT.
-->

      <t>IANA has set the RFCs "Use for DNSSEC Signing", "Use for DNSSEC
Validation", "Implement for DNSSEC Signing", and "Implement for DNSSEC
Validation" columns in one place so the "DNS Security Algorithm Numbers" registry
<xref target="DNSKEY-IANA"/> <xref target="RFC9904"/> to <bcp14>MUST NOT</bcp14> for ECC-GOST (12).  Note that
the reader can understand "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already set to <bcp14>MUST NOT</bcp14>.</t>
      <t>IANA has set the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is "Use for DNSSEC Delegation", "Use for DNSSEC
Validation", "Implement for DNSSEC Delegation", and "Implement for DNSSEC
Validation" columns in the "Digest Algorithms" registry <xref target="DS-IANA"/>
 to state <bcp14>MUST NOT</bcp14> for GOST R 34.11-94 (3).  Note that using
the "Use for DNSSEC Signing" and "Implement for origin authentication of DNS data is the best current practice. A third purpose is DNSSEC Delegation"
columns were already set to provide a single <bcp14>MUST NOT</bcp14>.</t>
    </section>
  </middle>
  <back>
    <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.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5933.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>

<!-- [rfced] FYI: We updated the reference entries for other documents that want the IANA
registries to refer reflect the names of the registries rather than the
registry group names to DNSSEC.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="237"/>
  <seriesInfo name="RFC" value="9364"/>
  <seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference> match the running text. Please let us
know of any objection.

Current:
   [DNSKEY-IANA]
              IANA, "DNS Security Algorithm Numbers",
              <https://www.iana.org/assignments/dns-sec-alg-numbers>.

   [DS-IANA]  IANA, "Digest Algorithms",
              <http://www.iana.org/assignments/ds-rr-types>.
-->

        <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml"> target="https://www.iana.org/assignments/dns-sec-alg-numbers">
          <front>
    <title>Domain Name System
            <title>DNS Security (DNSSEC) Algorithm Numbers</title>
    <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <author>
              <organization>IANA</organization>
            </author>
    <date year="n.d."/>
          </front>
        </reference>
        <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types">
          <front>
    <title>Delegation Signer (DS) Resource Record (RR) Type Digest
            <title>Digest Algorithms</title>
    <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <author>
              <organization>IANA</organization>
            </author>
    <date year="n.d."/>
          </front>
        </reference>

<!--
draft-ietf-dnsop-rfc8624-bis-13
companion doc RFC 9904
AUTH48 as of 10/30/25
-->
        <reference anchor="draft-ietf-dnsop-rfc8624-bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8624-bis"> anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9904">
          <front>
    <title>DNS Security
            <title>DNSSEC Cryptographic Algorithm Numbers</title> Recommendation Update Process</title>
            <author initials="K." surname="W." fullname="Kumari, W.">
      <organization></organization> initials="W." surname="Hardaker" fullname="Wes Hardaker">
              <organization>USC/ISI</organization>
            </author>
    <date year="n.d."/>
  </front>
</reference>

    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="RFC9558">
  <front>
    <title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC</title>
            <author fullname="B. Makarenko" initials="B." surname="Makarenko"/>
    <author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov"/> initials="W." surname="Kumari" fullname="Warren Kumari">
              <organization>Google</organization>
            </author>
            <date month="April" year="2024"/>
    <abstract>
      <t>This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).</t>
    </abstract> month='November' year='2025'/>
          </front>
          <seriesInfo name="RFC" value="9558"/> value="9904"/>
          <seriesInfo name="DOI" value="10.17487/RFC9558"/> value="10.17487/RFC9904"/>
        </reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9558.xml"/>
      </references>
    </references>

<section anchor="acknowledgments" numbered="false">
  <name>Acknowledgments</name>

<!--[rfced] Since most of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used the names in protocol specifications. This document aims to reduce the ambiguity by clarifying Acknowledgments were in
alphabetical order, we reordered a few names so that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>

    </references>

</references>

<?line 135?>

<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>The full
list is now in alphabetical order. If this is not desired,
please let us know.

Original:
   The authors appreciate the comments and suggestions from the
   following IETF participants in helping produce this document: Mark
   Andrews, Steve Crocker, Brian Dickson, Thomas Graf, Russ Housely,
   Shumon Huque, Paul Hoffman, S Moonesamy, Peter Dickson, Peter
   Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the many
   members of the DNSOP working group that discussed this draft.</t>

</section>
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage levels</name> draft.

Current:
   The authors appreciate the comments and suggestions from the
   following IETF participants in helping produce this document: Mark
   Andrews, Steve Crocker, Brian Dickson, Peter Dickson, Thomas Graf,
   Paul Hoffman, Russ Housely, Shumon Huque, S. Moonesamy, Peter
   Thomassen, Stefan Ubbink, Tim Wicinski, Paul Wouters, and the many
   members of the DNSOP Working Group that discussed this
   specification.
-->

      <t>The DNSSEC scanning project by Viktor Dukhovni authors appreciate the comments and suggestions from the
      following IETF participants in helping produce this document: <contact
      fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
      fullname="Brian Dickson"/>, <contact fullname="Peter Dickson"/>, <contact fullname="Thomas Graf"/>,  <contact fullname="Paul Hoffman"/>, <contact
      fullname="Russ Housely"/>, <contact fullname="Shumon Huque"/>, <contact fullname="S. Moonesamy"/>, <contact fullname="Peter Thomassen"/>,
      <contact fullname="Stefan Ubbink"/>,
      <contact fullname="Tim Wicinski"/>, <contact fullname="Paul Wouters"/>, and Wes Hardaker
highlights the current deployment many members of various algorithms on the
https://stats.dnssec-tools.org/ website.</t>

<t>&lt;RFC Editor: please delete DNSOP
      Working Group that discussed this section upon publication&gt;</t> specification.</t>
    </section>
<section anchor="github-version-of-this-document"><name>Github Version

  </back>

<!-- [rfced] FYI - To match the companion documents, we have added
expansions for the following abbreviations per Section 3.6 of this document</name>

<t>While this RFC
7322 ("RFC Style Guide"). Please review these and each expansion
in the document carefully to ensure correctness.

  DNS Public Key (DNSKEY)
  Delegation Signer (DS)
  Resource Record Signature (RRSIG)
-->

<!-- [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 under development, it can be viewed, tracked,
fill here:</t>

<t>https://github.com/hardaker/draft-hardaker-dnsop-must-not-gost</t>

<t>&lt;RFC Editor: please delete helpful for readers.

Note that our script did not flag any words in particular, but this section upon publication&gt;</t>

</section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA81YbW/jNhL+zl8xcL8kgOW8bPqyxuGuqZPdDbpJ9uxsF72i
ONDUWOKZIlUOZVcI/N+LIWVbzubSl/tynyxT5GieZx7ODJllmQg6GBzD4Apr
j0oGhIZkgeAWcD2ZZG/vZw+w1qHUFq7uZrPryUDI+dzjagy3H2cPcHf/0L2I
03aLRO6UlRWOIfdyETKNYZHlllydVQ2FzLqQoVJZ4Shkp18L/nThfDsGCrnQ
tR9D8A2F89PT16fngoJHWY3h5vrhjRCCgrT5v6VxFsfQIolaj+Gn4NQQyPng
cUFDoLZKD7lTlaxrbYufhZBNKJ0fC4BMAABoS2P4NIJ30udyiT4OJs8/IR0O
O1+M4eNscnIzu4kDWEltxsDgvi27mTSyGD4z/31TSa/7xqX3aPvj0fpb5wqD
fePrOPHbZZwYbQvrfCWDXiHDmL6ZnJ+dve4ev3z96lX3+PrVVxdjIYDj8/31
j9nN5d3lOFrec7D3h9/GgSB9gWEMgzKEmsYnJ+v1eqSllSPnixNJpAtboQ10
klvKCFUmTZHZppqjf3Zs9GsZKjNIxpPcrlwltYU7WSHMWgpYwQxV43Vo4SjJ
6RguTeG8DmUFd8kQQ5n9JRgvoqDM+yy0NdKhj2iwkEE7CzNdWPRwdDU7himS
a7xCmKJyPoej6fQYHtoa4UoXSGHvNjH3n6nfL9Q3X51fZHNNByjgAMZWdkP4
NDp4kfSyG96i3MYql0EGL9US/Yg/GtHmTp1wCE5ecuYA+t1sH4/nwgAghLaL
JzJ8/eWX34yFEFmWgZwT+xGEeCg18RZsmG7wGLRHglBypol5JuaYKby6GJ2d
Zuenp2dwVFmsnNVKDLb5ZHB8mIZGQnRqhyPr1lBqCs5rdQw5LrTF/OUvSJv3
R8+y1xdC7gKXUtkBC9e/BrSknaWdQEdwCK2pcxmQtrtQzFvIu6yqbdH3Zwtq
lLiqdJ4bFOILuLHBu7xRrDpmbreCF/8hFPAEheCVv4cEfurSxc+wlntEmIO2
4vGxA7TZMGIkhLB2B99BjzuomMO8jf7e+xw9dd6LN5ijlwYuC7SqhYXz8ICq
tFpJA1MsGpP2GmO6xeCdcUXLi6cNkZbiaOoopn3pwzFoC5dN0VCA89Oz82Fc
Fd2gpkZPmCc3Ijlbws7OxY6wRBePgUeqUbGMTRsB9jgnBItr9Iy4r4+dDEE/
oQsiXbwTNpvoVShRe5BETmlmR3j8pdEeo2QMrtAQSI9gXQBVSltsCexZHrEW
Ghr+wV0T32XXk8nxszrXBNaBcbZADx6Vqyq0TBjHhK3v0SUwr7662GxGQogv
voDp3ns2E2SSKkBkboktrJ3PCQbcHQyG6Ze7BH6eXv/z4830+oqfZ+8u37/f
PaQZbGYwe3f/8X03hZ/2iyf3t7fXd1dpPTceT4ZuL39MNhj14P7Dw8393eX7
AeM5oDPyHRzMGWpAX3vk4LHykZTXc8xFLN3w3eQDnF0kGrjIbjbw+PiP6ZvJ
N2dfX2w2sC7RJvE5a9rubyixBVnXKH1nRhoDStY6SEND/g6Vbm2hRI8j3vZX
vTSx67qek1vKCU+3fG+H7lft27N51EwevRPKY/rO1SzG3uc0AvhBGp2ncY/k
zIo3bjTAfVf4TEL7xYxGW+LkgiOAmwVry4USfe8LrFepFNasf+XbOrjCy7rU
qo+SoyJXUhs5N5i0zolra2OOxq1jKsn3lbl22obk6RyTsymSO58SZTtW/wRX
sOVKpAYqxnk6nd28/ePMiYP5ySLvNO+qri3bvWuoqxKEB6wQSCsaS01dOx/R
bV+ODug+/FKPcThgXLzM+OpzPAmOcpZ0zqmwRLFPZ3FW7IeeEwSLe1d4Jp2F
GDl62hjULqANWhrTgrZMFHVtAm0NdHWwy02oHKXWcd6KfqHtAQylDF12fSHh
RTfv684zaX7HU4+VWyFBF5FoZVfR4V/OIrhozHkC1XD3HkwLlVyydw2h6B+u
5pL6MY25oTE50FoHVXKaeorHY2yed4IYibRNCk3Ba9xZqL0r9VyHrgQpo2PS
jtprauNkHtmyOdTN3GgqWepP/Ort4eAALTWcOtmLlOU8drrttwOlViW/EnvN
zttt2DqBOU8pcZIDJS1vvMMJjIs7osu7y8/i8dOdCzGD89thl8pTWHbdx/TN
BK5zHbi15v8dPy0sNJqchNEUN9PcrRDW2hi2sd2f3Lq90CuPfhYiOqYJuJxj
NBUcEEZiYPCRMOqiw8QHCG0LLlKHb8Q2fzjLL2+q2qTO4NnFsa49N6dvBpQz
TWWpt11eaOZ3vIjHx945MRa6lyjYbA50D0dn58cggtul0hFAihKLpfa40q4h
04qX6PnvAHunsYHYAowNnzQeZd7uv/snQ9Mz/Jeic7D+LwVo8NnBcbBX6+Nj
d+TdbASbe1r7j14dw/8H63ySmUu15F17qZbWrQ3mRWwUUw1OB13i1shjrB4R
fkrHgVI2aArmIp5OYqLiGQtnjFtzlonXP7X0QStdS16kuY0yfLfD+S5vFB72
emO4lX4Jlzb3uKYhzAKuECbe8RF5KL7zWlq40mpJzg7hoXSVJHjr5WIYDx7w
zjWEph3CrGwqZ+Fd80uDQ/ggGwPv3GJRSTuEGdw6Z5Fk1Q7hAwb0Ymcy/u0M
E7eHs4ALaeHjfK7tsrP0yTUBOSM+6Ao+aaUtLfUQtgcIUUnbQoVpx+739f0H
7rZjWSm8a+oU9lyTaojiEZiZ4F0cc+kk1aJe35Pu+tIpJAWpCzwpaW1H6n9Q
Bc6IP+hlYGk0y9KtrI7OHVyRlboojS7KkOp2V/r4ZGhcG6XlFrCSnjXZLxjO
RpDbOwwKMtAot8T3SME5Q/EWA9Y4Jx24Wv+tn9xrw60CcFMYuuATxhM0NDW3
iFzcVBTx35mFtzqUzRx+QM+H4MRmTzBCfCq1eaIiziaN5e4nZ65czYND0GFb
u1Ya15gPId295EOx4IrCDf5Y7IAV8csj5aqT7WVhdyWz/fv0hpRvR/8XuL8B
elkXheIVAAA= should
still be reviewed as a best practice.
-->

</rfc>