wdiff rfc9157xml2.original.xml rfc9157.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->

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

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-dnssec-iana-cons-05" category="std" consensus="true" number="9157" updates="5155, 6014, 8624"> 8624" obsoletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="IANA revisions Revisions for DNSSEC">Revised IANA Considerations for DNSSEC</title>
    <seriesInfo name="RFC" value="9157"/>
    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization>ICANN</organization>
      <address>
        <email>paul.hoffman@icann.org</email>
      </address>
    </author>
    <date year="2021" month="October" day="07"/>

    <keyword>Internet-Draft</keyword> month="November"/>

<abstract>

      <t>This document changes the review requirements needed to get DNSSEC algorithms
      and resource records added to IANA registries.
It updates RFC 6014 to include hash algorithms for DS (Delegation Signer) Delegation Signer (DS) records
and NSEC3 (Hashed NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence) parameters. Existence). It also updates RFC RFCs 5155 and RFC 6014, which have requirements for DNSSEC
algorithms, and updates RFC 8624 to say that clarify the implementation recommendation related to the algorithms that are described in RFCs that are not on standards track are only at the “MAY” level of implementation recommendation. standards track.
The rationale for these changes is to bring the requirements for DS records
and for the hash algorithms used in NSEC3 in line with the requirements for
all other DNSSEC algorithms.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>DNSSEC is primarily described in <xref target="RFC4033"/>, target="RFC4033" format="default"/>, <xref target="RFC4034"/>, target="RFC4034" format="default"/>, and <xref target="RFC4035"/>. target="RFC4035" format="default"/>.
DNSSEC commonly uses another resource record beyond those defined in RFC 4034: <xref target="RFC4034"/>:
NSEC3 <xref target="RFC5155"/>. target="RFC5155" format="default"/>.
DS resrouce resource records were originally defined in <xref target="RFC3658"/>, target="RFC3658" format="default"/>, and that definition
was obsoleted by RFC 4034.</t> <xref target="RFC4034"/>.</t>
      <t><xref target="RFC6014"/> updated target="RFC6014" format="default"/> updates the requirements for how DNSSEC cryptographic algorithm
identifiers in the IANA registries are assigned, reducing the requirements
from being “Standards Action” "Standards Action" to “RFC Required”. "RFC Required".
However, the IANA registry requirements for hash algorithms for DS records
<xref target="RFC3658"/> target="RFC3658" format="default"/>
and for the hash algorithms used in NSEC3 records <xref target="RFC5155"/> target="RFC5155" format="default"/> are still “Standards Action”. "Standards Action".
This document updates those IANA registry requirements.
      (For a reference on how IANA registries can be updated in general, see <xref target="RFC8126"/>.)</t>

<t>The target="RFC8126" format="default"/>.)</t>
    <section numbered="true" toc="default">
      <name>Requirements Language</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 BCP&nbsp;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="update-to-rfc-6014" title="Update numbered="true" toc="default">
      <name>Update to RFC 6014"> 6014</name>
      <t><xref target="iana"/> target="iana" format="default"/> updates RFC 6014 <xref target="RFC6014"/> to bring the requirements for DS records
and NSEC3 hash algorithms in line with the rest of the DNSSEC cryptographic algorithms
by allowing any DS hash algorithms, NSEC3 hash algorithms,
NSEC3 parameters, and NSEC3 flags that are fully described in an RFC
to have identifiers assigned in the IANA registries.
This is an addition to the IANA considerations in RFC 6014.</t> <xref target="RFC6014"/>.</t>
    </section>
    <section anchor="update-to-rfc-8624" title="Update numbered="true" toc="default">
      <name>Update to RFC 8624"> 8624</name>
      <t>This document updates <xref target="RFC8624"/> target="RFC8624" format="default"/> for all DNSKEY and DS algorithms that are not
on the standards track.</t>
      <t>The second paragraph of Section 1.2 of RFC 8624 <xref target="RFC8624" sectionFormat="of" section="1.2"/> currently says:</t>

<figure><artwork><![CDATA[
<blockquote><t>
   This document only provides recommendations with respect to
   mandatory-to-implement algorithms or algorithms so weak that they
   cannot be recommended.  Any algorithm listed in the [DNSKEY-IANA]
   and [DS-IANA] registries that are not mentioned in this document
   MAY
   <bcp14>MAY</bcp14> be implemented.  For clarification and consistency, an
   algorithm will be specified as MAY <bcp14>MAY</bcp14> in this document only when it
   has been downgraded from a MUST <bcp14>MUST</bcp14> or a RECOMMENDED <bcp14>RECOMMENDED</bcp14> to a MAY.
]]></artwork></figure> <bcp14>MAY</bcp14>.</t>
</blockquote>
      <t>That paragraph is now replaced with the following:</t>

<figure><artwork><![CDATA[
<blockquote><t>
   This document provides recommendations with respect to
   mandatory-to-implement algorithms, algorithms so weak that they
   cannot be recommended, and algorithms that are defined in RFCs
   that are not on the standards track. Any algorithm listed in the
   [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in
   this document MAY <bcp14>MAY</bcp14> be implemented. For clarification and
   consistency, an algorithm will be specified as MAY <bcp14>MAY</bcp14> in this document only when it has been downgraded from a MUST <bcp14>MUST</bcp14> or a
   RECOMMENDED
   <bcp14>RECOMMENDED</bcp14> to a MAY.
]]></artwork></figure> <bcp14>MAY</bcp14>.</t>
 </blockquote>
      <t>This update is also reflected in the IANA considerations in <xref target="iana"/>.</t> target="iana" format="default"/>.</t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>In the “Domain "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters” Parameters"
registry, the registration procedure for “DNSSEC "DNSSEC NSEC3 Flags”, “DNSSEC Flags", "DNSSEC NSEC3
Hash Algorithms”, Algorithms", and “DNSSEC "DNSSEC NSEC3PARAM Flags” are Flags" has been changed from “Standards
Action” "Standards
Action" to “RFC Required”.</t> "RFC Required", and this document has been added as a reference.</t>
      <t>In the “Delegation "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms” Algorithms" registry, the registration procedure for “Digest Algorithms” is "Digest Algorithms" has been changed from
“Standards Action” "Standards Action" to “RFC Required”.</t> "RFC Required", and this document has been added as a reference.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Changing the requirements for getting adding security algorithms added to IANA
registries as described in this document will make it easier to get add both good
algorithms added to the registries,
and will make it easier to get bad algorithms added to the registries.
It is impossible to weigh the security impact of those two changes.</t>
      <t>Administrators of DNSSEC-signed zones, zones and of validating resolvers, resolvers may have been making
security decisions based on the contents of the IANA registries.
This was a bad idea in the past, and now it is an even worse idea because there will be more
algorithms in those registries that may not have gone through IETF review.
Security decisions about which algorithms are safe and not safe should be made by
reading the security literature, not by looking in IANA registries.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions 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='RFC4033' target='https://www.rfc-editor.org/info/rfc4033'>
<front>
<title>DNS Security Introduction and Requirements</title>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></author>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></author>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></author>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.  This document introduces these extensions and describes their capabilities and limitations.  This document also discusses the services that the DNS security extensions do and do not provide.  Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4033'/>
<seriesInfo name='DOI' value='10.17487/RFC4033'/>
</reference>

<reference anchor='RFC4034' target='https://www.rfc-editor.org/info/rfc4034'>
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></author>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></author>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></author>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS.  This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records.  The purpose and format of each resource record is described in detail, and an example of each resource record is given. </t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4034'/>
<seriesInfo name='DOI' value='10.17487/RFC4034'/>
</reference>

<reference anchor='RFC4035' target='https://www.rfc-editor.org/info/rfc4035'>
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></author>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></author>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></author>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS.  This document describes the DNSSEC protocol modifications.  This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC.  These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. </t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4035'/>
<seriesInfo name='DOI' value='10.17487/RFC4035'/>
</reference>

<reference anchor='RFC5155' target='https://www.rfc-editor.org/info/rfc5155'>
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
<author fullname='B. Laurie' initials='B.' surname='Laurie'><organization/></author>
<author fullname='G. Sisson' initials='G.' surname='Sisson'><organization/></author>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='D. Blacka' initials='D.' surname='Blacka'><organization/></author>
<date month='March' year='2008'/>
<abstract><t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence.  However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5155'/>
<seriesInfo name='DOI' value='10.17487/RFC5155'/>
</reference>

<reference anchor='RFC6014' target='https://www.rfc-editor.org/info/rfc6014'>
<front>
<title>Cryptographic Algorithm Identifier Allocation for DNSSEC</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<date month='November' year='2010'/>
<abstract><t>This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated.  It changes the requirement from &quot;standard required&quot; to &quot;RFC Required&quot;.  It does not change the list of algorithms that are recommended or required for DNSSEC implementations.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6014'/>
<seriesInfo name='DOI' value='10.17487/RFC6014'/>
</reference>

<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></author>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></author>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying 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>

<reference anchor='RFC8624' target='https://www.rfc-editor.org/info/rfc8624'>
<front>
<title>Algorithm Implementation Requirements and Usage Guidance for DNSSEC</title>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></author>
<author fullname='O. Sury' initials='O.' surname='Sury'><organization/></author>
<date month='June' year='2019'/>
<abstract><t>The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence.  To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support.  This document defines the current algorithm implementation requirements and usage guidance for DNSSEC.  This document obsoletes RFC 6944.</t></abstract>
</front>
<seriesInfo name='RFC' value='8624'/>
<seriesInfo name='DOI' value='10.17487/RFC8624'/>
</reference>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6014.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8624.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3658.xml"/>
      </references>

    <references title='Informative References'>

<reference anchor='RFC3658' target='https://www.rfc-editor.org/info/rfc3658'>
<front>
<title>Delegation Signer (DS) Resource Record (RR)</title>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organization/></author>
<date month='December' year='2003'/>
<abstract><t>The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone.  The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations.  The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.  This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers.  This change is not backwards compatible with RFC 2535.  This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.</t></abstract>
</front>
<seriesInfo name='RFC' value='3658'/>
<seriesInfo name='DOI' value='10.17487/RFC3658'/>
</reference>
    </references>
    <section anchor="acknowledgements" title="Acknowledgements">

<t>Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and
Benjamin Kaduk numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t><contact fullname="Donald Eastlake"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Dan Harkins"/>, <contact fullname="Martin Duke"/>, and
<contact fullname="Benjamin Kaduk"/> contributed to this document.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAIhZX2EAA61Y3W4btxK+51MQ6k0MSILt2Gnqq6NaDmwk/qnlXBTFQUHt
UhKPd5d7SK5VNXDQB+l5uT7J+Wa4u1r9xEiK3tjkkhzOfPPNDzUYDEQwIdNn
8l4/Ga9TeTW6GclzW3iTaqeCwUjOrJPjm8nk4lyo6dTpp7O4zdGZ7R2pTQqV
Q2Lq1CwMjA6zQVp4W9Jfr5OBUYUaJDg1ODwVwgdVpL+qzBY4ElylBS3pwlf+
TK60F8KUjld8OD48/OHwWDwucX8RtCt0GIzpFpGocCZ9SEVVpipoHD09Oj3t
yzeHRyd9+fbN8YkQpTkTUgabRLk8THUZFmfyBDNvXXB65ptVv8rXU6GqsLAO
AgZYkqbA97uhvLSzWa4K+hRtvlNV1v1q3Ry6no9ubmimc2WyM1li03ARN/3L
JKoohtgnRGFdDsSfNOl5/+78+Ojoh3p4cvj69Xp4sh6e1kMytx6SzfXw7dHx
m3b4ffsVcJwJU8y27nv95vTtmcBYDAYDqaY+OJUEIR4Wxku4tcp1EWSyUMVc
exkWmgmgl/j338o4TcteFlqn4FGwcq5DTQqpsrl1JixyL+BuHPC2cgkJSKxL
vVRpfabm1dzgcqP9UFwFWfuUVGSH0j5TJFmVarlQftGRHok4ka/GOtNzpq+c
mHmh3UFzFytwA6Vey1eXOI17R3AudIcrAmZjXRiVSTuTF79BDV0k+gA+c3Aw
OBdVUpm3G3oR/pIkN0r25XJhkgUUfNKbAHWjqVW8T4dFVyJ5iSz1agWsVeha
GedOy1T7xJkptDYFnYpLgpYKGySs5/hShDF585FP2SJbSUggF/auRz/3ZKaf
NJts8jJjPSN2hFmOacrTIagAY3isMs2WQIbXLSlAFKg8daaY1wTZNnyy4Yda
wo4bKx9Nin7CIDOFlkss7hULIKE9Vtwu4YaC6ZybNM20EN9R6nA2rRKyQoh6
PxQvncmVM4BmA9VPn+r4e37ut5MTmpABzYfT5+dhI4sgY4hhBahdRMW2OC+n
emUhAGnFkx9nMLDxoowxHo3nG4hefAPB552tOrGz1ORSZ+YGTmHtW1l8lsK6
UZeJwxsMm79UXtqpt5km5k9X7e1AjQ8TlZ+fa6qn+326sMsG9sStymDnTpUg
/9oJAsUE8TUziB/Si8RsRToTU3lPwZr2sQAP7WORmDmbAzxa601aco/YnT1i
X49suI9H0t5QXNol2O36O7eu9piyP500lO3g+Q30bRzV8SRb64MBbXeNGG5l
3CYrRKp82YKhePXOEtFmYASyFoU/+WYbaVQcANj6FHrONTKkyvrSax3VpMoB
wh0IDvlHvZJLtuGvP/68/jh5+OuP//Wbsby5bef3Fz99vLq/GDfzyeXow4eN
SbNb8Ifbjx86e2m2Ke389vr64ma8FohVueczkhgLJadgenv3cHV7M6KbI926
cBL0lKQ0lpDQS8fcRyB0w178eH4nUWoYDCrE8FkNzPcUEEsUjBhSHOlxCiqs
hCpLrRxdS0kpUaUJqBZ9usDDG3AJvIPwQib6yB4gZZqqQVFH/VEbcptV7+sT
a2TeNi/3JFIfKO3T+OUQ9gLZARbZJamgihXduCW/v//afp3J1jU0Ihe/zjI1
71S0WZVtZ2DFSVHAfi6m3VzSJIwvJJU6kgxlYeoxOOkRkO3eZLPTrfMv4T3c
9VDsI/cHZyQHNsB15A9yPhB9f/Ez2wqw9tVv1AaxW6SHMoYdumUqEYQb+4M8
NdGcJOTR8JimbaeQVA5BH4AdGgaPNu7z58/Uc25qy2QtnX2CzX6ruvtIC1Ci
xB2wmY7npFiwbjUIdtA2B11b2NZ2hrZoqdVjtJDjAUKoxUU3MtXrG3U6lHJU
rNZnwUwf1p78JYI3IC/9m4QQir+MJ/FDN511wZSkHWxp5HRsJxlIExz3jR2s
BeXMJEPln1EDSNjSVUwM7v5WxFbWoFV1SYkbgggpYiKnDxK+k2za7CANa4DQ
wEFMU6QCOJXaXq5oSnIuJTS7CY6op0j0kB0KWsDYNSFwVWGpAS8zlUBUG9gz
W4fql5jwj5Kg//coENPA/r622w/Rc2zTzfti5gU20fkNQv0NNkUduhDuY9Ne
MjEAm3z6BjLR6b18+ioy0ekX+QSLYg7jNEnvGjQQGZy/lVV3M2VTqjhT7vvd
4NN3vEGIqyinN7Z4AaMtQhmQkxXQyCmfVcBhhScb158DeaN/CxhUTuOFxjXi
AO/qpnT0RNP79OsKxrOINUiNKKhcfJr06ooW68w7qjO9/uZXQS9AOWoZ2IuU
3NhzN7ofXdfHmRnxsVNDvW7fxAs96BqB7Xcp7J4cYGv9OLiPj4NX9/cH8mFV
oiqbOdXojorfAsDOYXJyV3/xdT00HNw6atPJQpyTuC/2JXMdAi365ngn3Dde
/aL7FthsxrbijgMmV4+aYkArj06g+blhbm0q9t3QQQoXRC+/IGeqvkYM/xRA
/UVeWjQi04w7haU285iEW5uxQSV1o0U9fFja5skMbEdpjvcY+9Cip8GuSL9B
3dv8jgxUq4y1J5UZytXAlJ6U2RP3U7laxe6I8wGMwrpo70+RWeIPdVNFTxMb
2YiQDuyougPc3z3RG1ERItR5qSYnlMqHqBMVoNhh4ZlV0DvB67h1qhNVkbnU
8rZ5LrdOi82mNKKynYXJJsrCbNccIOAznr4A9+ri4V3949NQTHatVFNbhfoH
mK4b6dGlZrpWO8QJuvIqS1kzZFA8gsFElTaEbjHMTCDOI7b6fBbtcGYt4UwW
7EDHPzpMUZgodkbJI1DKdDqvH7FiTL+gpPICKGZgYF9eo3+Dve+rBGCpJYJ7
DEQvlcMN8O+1cnC5HFe0l0rKj7r4jwJv5HuVVo/sSoRLFRqedgJmKP4PQlWM
JugVAAA=

-->
</rfc>