rfc9906xml2.original.xml   rfc9906.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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" so rtRefs="true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-ietf-dnsop-must-not-ecc-gost-07" category= "std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" s ymRefs="true">
<front> <front>
<title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate usage of ECC-GOST wi <title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate Usage of ECC-GOST wi
thin DNSSEC</title> thin DNSSEC</title>
<seriesInfo name="RFC" value="9906"/>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker"> <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/ISI</organization> <organization>USC/ISI</organization>
<address> <address>
<email>ietf@hardakers.net</email> <email>ietf@hardakers.net</email>
</address> </address>
</author> </author>
<author initials="W." surname="Kumari" fullname="Warren Kumari"> <author initials="W." surname="Kumari" fullname="Warren Kumari">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<date year="2025" month="November"/>
<area>OPS</area>
<workgroup>dnsop</workgroup>
<date year="2025" month="June" day="03"/> <abstract>
<t>This document retires the use of GOST R 34.10-2001 (mnemonic
<abstract> "ECC-GOST") and GOST R 34.11-94 within DNSSEC.</t>
<t>RFC 5933 (Historic) defined the use of GOST R 34.10-2001 and GOST R 34.
<?line 53?> 11-94
algorithms with DNS Security Extensions (DNSSEC).
<t>This document retires the use of GOST R 34.10-2001 (mnemonic This document updates RFC 5933
"ECC-GOST") within DNSSEC.</t>
<t>RFC5933 (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
by deprecating the use of ECC-GOST.</t> by deprecating the use of ECC-GOST.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 62?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t>The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are documented in
<xref target="RFC5933"/> and their use with DNS Security Extensions (DNSSEC) is
<t>The use of the GOST R 34.10-2001 and GOST R 34.11-94 algorithms with further described in <xref target="RFC9364"/>. These two algorithms were depreca
the DNS Security Extensions (DNSSEC) <xref target="RFC9364"></xref> was document ted by the Orders of the
ed in
<xref target="RFC5933"/>. These two algorithms were deprecated by the Orders of
the
Federal Agency for Technical Regulation and Metrology of Russia Federal Agency for Technical Regulation and Metrology of Russia
(Rosstandart) in August 2012, and were superseded by GOST 34.10-2012 (Rosstandart) in August 2012 and were superseded by GOST 34.10-2012
and GOST 34.11-2012 respectively. The use of these newer two and GOST 34.11-2012, respectively. The use of these two newer
algorithms in DNSSEC is documented in <xref target="RFC9558"/> and their associa algorithms in DNSSEC is documented in <xref target="RFC9558"/>, and their associ
ted ated
requirement levels are not changed by this document.</t> requirement levels are not changed by this document.</t>
<t>Thus, the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.
<t>Thus, the use of GOST R 34.10-2001 (mnemonic GOST-ECC) and GOST R 34.11-94 11-94
is no longer recommended for use in DNSSEC <xref target="RFC9364"/>.</t> is no longer recommended for use in DNSSEC <xref target="RFC9364"/>.</t>
<section anchor="requirements-notation">
<section anchor="requirements-notation"><name>Requirements notation</name> <name>Requirements Notation</name>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and "OPTIONAL" in this document are to be interpreted as described NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
en, they appear "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
in all capitals, as shown here.</t> be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section anchor="deprecating-ecc-gost-algorithms-in-dnssec"><name>Deprecating EC </section>
C-GOST algorithms in DNSSEC</name> </section>
<section anchor="deprecating-ecc-gost-algorithms-in-dnssec">
<t>The GOST R 34.11-94 <xref target="RFC5933"/> algorithm MUST NOT be used when <name>Deprecating ECC-GOST Algorithms in DNSSEC</name>
creating DS records. Validating resolvers MUST treat GOST R 34.11-94 <t>The GOST R 34.11-94 algorithm <xref target="RFC5933"/> <bcp14>MUST NOT<
/bcp14> be used when
creating Delegation Signer (DS) records. Validating resolvers <bcp14>MUST</bcp1
4> treat GOST R 34.11-94
DS records as insecure. If no other DS records of accepted DS records as insecure. If no other DS records of accepted
cryptographic algorithms are available, the DNS records below the cryptographic algorithms are available, the DNS records below the
delegation point MUST be treated as insecure.</t> delegation point <bcp14>MUST</bcp14> be treated as insecure.</t>
<t>The ECC-GOST <xref target="RFC5933"/> algorithm MUST NOT be used when creatin <t>The GOST R 34.10-2001 algorithm <xref target="RFC5933"/> (mnemonic "ECC-GOST"
g ) <bcp14>MUST NOT</bcp14> be used when creating DNS Public Key (DNSKEY) and Reso
DNSKEY and RRSIG records. Validating resolvers MUST treat urce Record Signature (RRSIG) records. Validating resolvers <bcp14>MUST</bcp14>
RRSIG records created from DNSKEY records using these algorithms as an treat
unsupported algorithm. If no other RRSIG records of accepted cryptographic RRSIG records created from DNSKEY records using these algorithms as
algorithms are available, the validating resolver MUST consider the unsupported algorithms. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver <bcp14>MUST</bcp14> consider t
he
associated resource records as insecure.</t> associated resource records as insecure.</t>
</section>
</section> <section anchor="security-considerations">
<section anchor="security-considerations"><name>Security Considerations</name> <name>Security Considerations</name>
<t>This document potentially increases the security of the DNSSEC ecosyste
<t>This document potentially increases the security of the DNSSEC ecosystem by m by
deprecating algorithms that are no longer recommended for use.</t> deprecating algorithms that are no longer recommended for use.</t>
</section>
</section> <section anchor="operational-considerations">
<section anchor="operational-considerations"><name>Operational Considerations</n <name>Operational Considerations</name>
ame> <t>This document removes support for ECC-GOST. Zone operators currently ma
king use
<t>This document removes support for ECC-GOST. Zone operators currently making u of ECC-GOST-based algorithms should switch to algorithms that remain supported.
se
of ECC-GOST based algorithms should switch to algorithms that remain supported.
DNS registries should prohibit their clients from uploading and publishing DNS registries should prohibit their clients from uploading and publishing
ECC-GOST based DS records to ensure that they are using algorithms which are ECC-GOST-based DS records to ensure that they are using algorithms that are
supported by DNSSEC validators, and so can be DNSSEC validated.</t> supported by DNSSEC validators and thus can be DNSSEC validated.</t>
</section>
</section> <section anchor="iana-considerations">
<section anchor="iana-considerations"><name>IANA Considerations</name> <name>IANA Considerations</name>
<t>[Note to IANA, to be removed by the RFC Editor: the registry fields
listed above will be created by draft-ietf-dnsop-rfc8624-bis.]</t>
<t>IANA is requested to set the "Use for DNSSEC Signing", "Use for DNSSEC
Validation", "Implement for DNSSEC Signing", and "Implement for DNSSEC
Validation" columns of the DNS Security Algorithm Numbers registry
<xref target="DNSKEY-IANA"/> <xref target="draft-ietf-dnsop-rfc8624-bis"/> for E
CC-GOST (12)
to MUST NOT. Note that previously
the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already MUST NOT.</t>
<t>IANA is requested to set the "Use for DNSSEC Delegation", "Use for DNSSEC <!--IANA Action: add "DEPRECATED" to "GOST R 34.11-94" -->
Validation", "Implement for DNSSEC Delegation", and "Implement for DNSSEC
Validation" columns of the "Digest Algorithms" registry <xref target="DS-IANA"/>
for GOST R 34.11-94 (3) to MUST NOT. Note that previously
the "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already MUST NOT.</t>
</section> <t> IANA has updated the GOST R 34.10-2001 (12) entry in the "DNS
Security Algorithm Numbers" registry <xref target="DNSKEY-IANA"/> <xref targe
t="RFC9904"/> as
follows: </t>
<dl spacing="compact">
<dt>Number:</dt><dd> 12</dd>
<dt>Description:</dt><dd> GOST R 34.10-2001 (DEPRECATED)</dd>
<dt>Mnemonic:</dt><dd> ECC-GOST </dd>
<dt>Zone Signing:</dt><dd> Y </dd>
<dt>Trans. Sec.:</dt><dd> * </dd>
<dt>Use for DNSSEC Signing:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Use for DNSSEC Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Implement for DNSSEC Signing:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Implement for DNSSEC Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Reference:</dt><dd><xref target="RFC5933"/>, <eref target="https://datatra
cker.ietf.org/doc/status-change-gost-dnssec-to-historic/">Change the status of G
OST
Signature Algorithms in DNSSEC in the IETF stream to
Historic</eref>, and RFC 9906</dd>
</dl>
<t>
Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC
Delegation" columns were already set to <bcp14>MUST NOT</bcp14>.
</t>
<t>
IANA has updated the GOST R 34.11-94 (3) entry in the "Digest Algorithms"
registry <xref target="DS-IANA"/> as follows:
</t>
<dl spacing="compact">
<dt>Value:</dt><dd> 3</dd>
<dt>Description:</dt><dd> GOST R 34.11-94 (DEPRECATED)</dd>
<dt>Use for DNSSEC Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Use for DNSSEC Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Implement for DNSSEC Delegation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Implement for DNSSEC Validation:</dt><dd><bcp14>MUST NOT</bcp14></dd>
<dt>Reference:</dt><dd><xref target="RFC5933"/>, <eref target="https://datatra
cker.ietf.org/doc/status-change-gost-dnssec-to-historic/">Change the status of G
OST
Signature Algorithms in DNSSEC in the IETF stream to
Historic</eref>, and RFC 9906</dd>
</dl>
<t>
Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation"
columns were already set to <bcp14>MUST NOT</bcp14>.
</t>
</section>
</middle> </middle>
<back> <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.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
933.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
364.xml"/>
<references title='References' anchor="sec-combined-references"> <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments
/dns-sec-alg-numbers">
<references title='Normative References' anchor="sec-normative-references"> <front>
<title>DNS Security Algorithm Numbers</title>
<reference anchor="RFC2119"> <author>
<front> <organization>IANA</organization>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> </author>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> </front>
<date month="March" year="1997"/> </reference>
<abstract> <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-r
<t>In many standards track documents several words are used to signify the r-types">
requirements in the specification. These words are often capitalized. This docu <front>
ment defines these words as they should be interpreted in IETF documents. This d <title>Digest Algorithms</title>
ocument specifies an Internet Best Current Practices for the Internet Community, <author>
and requests discussion and suggestions for improvements.</t> <organization>IANA</organization>
</abstract> </author>
</front> </front>
<seriesInfo name="BCP" value="14"/> </reference>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5933">
<front>
<title>Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records
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 and hash func
tions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRS
IG, and DS resource records, for use in the Domain Name System Security Extensio
ns (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 the DNS Security Extensions (commonly called "D
NSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of
others. One purpose is to introduce all of the RFCs in one place so that the re
ader can understand the many aspects of DNSSEC. This document does not update an
y of those RFCs. A second purpose is to state that using DNSSEC for origin authe
ntication of DNS data is the best current practice. A third purpose is to provid
e a single reference for other documents that want to refer to DNSSEC.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="237"/>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
<reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec
-alg-numbers/dns-sec-alg-numbers.xhtml">
<front>
<title>Domain Name System Security (DNSSEC) Algorithm Numbers</title>
<author initials="" surname="IANA" fullname="IANA">
<organization></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 Algorithms</t
itle>
<author initials="" surname="IANA" fullname="IANA">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="draft-ietf-dnsop-rfc8624-bis" target="https://datatracker.iet
f.org/doc/html/draft-ietf-dnsop-rfc8624-bis">
<front>
<title>DNS Security Algorithm Numbers</title>
<author initials="K." surname="W." fullname="Kumari, W.">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-reference
s">
<reference anchor="RFC9558"> <!--
<front> draft-ietf-dnsop-rfc8624-bis-13
<title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Re companion doc RFC 9904
cords for DNSSEC</title> AUTH48 as of 10/30/25
<author fullname="B. Makarenko" initials="B." surname="Makarenko"/> -->
<author fullname="V. Dolmatov" initials="V." role="editor" surname="Dolmatov <reference anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9
"/> 904">
<date month="April" year="2024"/> <front>
<abstract> <title>DNSSEC Cryptographic Algorithm Recommendation Update Process<
<t>This document describes how to produce digital signatures and hash func /title>
tions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, R <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
RSIG, and DS resource records, for use in the Domain Name System Security Extens <organization>USC/ISI</organization>
ions (DNSSEC).</t> </author>
</abstract> <author initials="W." surname="Kumari" fullname="Warren Kumari">
</front> <organization>Google</organization>
<seriesInfo name="RFC" value="9558"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC9558"/> <date month='November' year='2025'/>
</reference> </front>
<reference anchor="RFC8174"> <seriesInfo name="RFC" value="9904"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC9904"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> </reference>
<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 in protocol specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE 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 anchor="sec-informative-references">
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
558.xml"/>
</references>
</references> </references>
</references> <section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<?line 135?> <t>The authors appreciate the comments and suggestions from the
following IETF participants in helping produce this document: <contact
<section anchor="acknowledgments"><name>Acknowledgments</name> fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
fullname="Brian Dickson"/>, <contact fullname="Peter Dickson"/>, <contact
<t>The authors appreciate the comments and suggestions from the following IETF fullname="Thomas Graf"/>, <contact fullname="Paul Hoffman"/>, <contact
participants in helping produce this document: Mark Andrews, Steve Crocker, fullname="Russ Housely"/>, <contact fullname="Shumon Huque"/>, <contact fu
Brian Dickson, Thomas Graf, Russ Housely, Shumon Huque, Paul Hoffman, S Moonesam llname="S. Moonesamy"/>, <contact fullname="Peter Thomassen"/>,
y, Peter <contact fullname="Stefan Ubbink"/>,
Dickson, Peter Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, and the <contact fullname="Tim Wicinski"/>, <contact fullname="Paul Wouters"/>, an
many members of the DNSOP working group that discussed this draft.</t> d the many members of the DNSOP
Working Group that discussed this specification.</t>
</section> </section>
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage l
evels</name>
<t>The DNSSEC scanning project by Viktor Dukhovni and Wes Hardaker
highlights the current deployment of various algorithms on the
https://stats.dnssec-tools.org/ website.</t>
<t>&lt;RFC Editor: please delete this section upon publication&gt;</t>
</section>
<section anchor="github-version-of-this-document"><name>Github Version of this d
ocument</name>
<t>While this document 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 this section upon publication&gt;</t>
</section>
</back> </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=
</rfc> </rfc>
 End of changes. 30 change blocks. 
322 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.48.