<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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" prepTime="2025-11-30T16:09:17" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-ecc-gost-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9906" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="MUST NOT DNSSEC with ECC-GOST">Deprecate Usage of ECC-GOST within DNSSEC</title>
    <seriesInfo name="RFC" value="9906" stream="IETF"/>
    <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization showOnFrontPage="true">USC/ISI</organization>
      <address>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization showOnFrontPage="true">Google</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date month="11" year="2025"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document retires the use of GOST R 34.10-2001 (mnemonic
      "ECC-GOST") and GOST R 34.11-94 within DNSSEC.</t>
      <t indent="0" pn="section-abstract-2">RFC 5933 (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 RFC 5933
by deprecating the use of ECC-GOST.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9906" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation">Requirements Notation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deprecating-ecc-gost-algori">Deprecating ECC-GOST Algorithms in DNSSEC</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The GOST R 34.10-2001 and GOST R 34.11-94 algorithms are documented in <xref target="RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/> and their use with DNS Security Extensions (DNSSEC) is further described in <xref target="RFC9364" format="default" sectionFormat="of" derivedContent="RFC9364"/>. These two algorithms were deprecated by the Orders of the
Federal Agency for Technical Regulation and Metrology of Russia
(Rosstandart) in August 2012 and were superseded by GOST 34.10-2012
and GOST 34.11-2012, respectively. The use of these two newer
algorithms in DNSSEC is documented in <xref target="RFC9558" format="default" sectionFormat="of" derivedContent="RFC9558"/>, and their associated
requirement levels are not changed by this document.</t>
      <t indent="0" pn="section-1-2">Thus, the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.11-94
is no longer recommended for use in DNSSEC <xref target="RFC9364" format="default" sectionFormat="of" derivedContent="RFC9364"/>.</t>
      <section anchor="requirements-notation" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-notation">Requirements Notation</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="deprecating-ecc-gost-algorithms-in-dnssec" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-deprecating-ecc-gost-algori">Deprecating ECC-GOST Algorithms in DNSSEC</name>
      <t indent="0" pn="section-2-1">The GOST R 34.11-94 algorithm <xref target="RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/> <bcp14>MUST NOT</bcp14> be used when
creating Delegation Signer (DS) records.  Validating resolvers <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 <bcp14>MUST</bcp14> be treated as insecure.</t>
      <t indent="0" pn="section-2-2">The GOST R 34.10-2001 algorithm <xref target="RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/> (mnemonic "ECC-GOST") <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 <bcp14>MUST</bcp14> consider the
associated resource records as insecure.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-3-1">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" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-4-1">This document removes support for ECC-GOST. Zone operators currently making use
of ECC-GOST-based algorithms should switch to algorithms that remain supported.
DNS registries should prohibit their clients from uploading and publishing
ECC-GOST-based DS records to ensure that they are using algorithms that are
supported by DNSSEC validators and thus can be DNSSEC validated.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">  IANA has updated the GOST R 34.10-2001 (12) entry in the "DNS
   Security Algorithm Numbers" registry <xref target="DNSKEY-IANA" format="default" sectionFormat="of" derivedContent="DNSKEY-IANA"/> <xref target="RFC9904" format="default" sectionFormat="of" derivedContent="RFC9904"/> as
   follows: </t>
      <dl spacing="compact" indent="3" newline="false" pn="section-5-2">
        <dt pn="section-5-2.1">Number:</dt>
        <dd pn="section-5-2.2"> 12</dd>
        <dt pn="section-5-2.3">Description:</dt>
        <dd pn="section-5-2.4"> GOST R 34.10-2001 (DEPRECATED)</dd>
        <dt pn="section-5-2.5">Mnemonic:</dt>
        <dd pn="section-5-2.6"> ECC-GOST </dd>
        <dt pn="section-5-2.7">Zone Signing:</dt>
        <dd pn="section-5-2.8"> Y 	</dd>
        <dt pn="section-5-2.9">Trans. Sec.:</dt>
        <dd pn="section-5-2.10"> * </dd>
        <dt pn="section-5-2.11">Use for DNSSEC Signing:</dt>
        <dd pn="section-5-2.12">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-2.13">Use for DNSSEC Validation:</dt>
        <dd pn="section-5-2.14">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-2.15">Implement for DNSSEC Signing:</dt>
        <dd pn="section-5-2.16">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-2.17">Implement for DNSSEC Validation:</dt>
        <dd pn="section-5-2.18">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-2.19">Reference:</dt>
        <dd pn="section-5-2.20">
          <xref target="RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/>, <eref target="https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/" brackets="none">Change the status of GOST
       Signature Algorithms in DNSSEC in the IETF stream to 
       Historic</eref>, and RFC 9906</dd>
      </dl>
      <t indent="0" pn="section-5-3">
   Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC 
   Delegation" columns were already set to <bcp14>MUST NOT</bcp14>.
</t>
      <t indent="0" pn="section-5-4">
   IANA has updated the GOST R 34.11-94 (3) entry in the "Digest Algorithms"
   registry <xref target="DS-IANA" format="default" sectionFormat="of" derivedContent="DS-IANA"/> as follows:
</t>
      <dl spacing="compact" indent="3" newline="false" pn="section-5-5">
        <dt pn="section-5-5.1">Value:</dt>
        <dd pn="section-5-5.2"> 3</dd>
        <dt pn="section-5-5.3">Description:</dt>
        <dd pn="section-5-5.4"> GOST R 34.11-94 (DEPRECATED)</dd>
        <dt pn="section-5-5.5">Use for DNSSEC Delegation:</dt>
        <dd pn="section-5-5.6">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-5.7">Use for DNSSEC Validation:</dt>
        <dd pn="section-5-5.8">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-5.9">Implement for DNSSEC Delegation:</dt>
        <dd pn="section-5-5.10">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-5.11">Implement for DNSSEC Validation:</dt>
        <dd pn="section-5-5.12">
          <bcp14>MUST NOT</bcp14></dd>
        <dt pn="section-5-5.13">Reference:</dt>
        <dd pn="section-5-5.14">
          <xref target="RFC5933" format="default" sectionFormat="of" derivedContent="RFC5933"/>, <eref target="https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/" brackets="none">Change the status of GOST
       Signature Algorithms in DNSSEC in the IETF stream to 
       Historic</eref>, and RFC 9906</dd>
      </dl>
      <t indent="0" pn="section-5-6">
   Note: The "Use for DNSSEC Signing" and "Implement for DNSSEC Delegation" 
   columns were already set to <bcp14>MUST NOT</bcp14>.
</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers" quoteTitle="true" derivedAnchor="DNSKEY-IANA">
          <front>
            <title>DNS Security Algorithm Numbers</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types" quoteTitle="true" derivedAnchor="DS-IANA">
          <front>
            <title>Digest Algorithms</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC5933" target="https://www.rfc-editor.org/info/rfc5933" quoteTitle="true" derivedAnchor="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 indent="0">This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in 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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity 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 indent="0">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="RFC9364" target="https://www.rfc-editor.org/info/rfc9364" quoteTitle="true" derivedAnchor="RFC9364">
          <front>
            <title>DNS Security Extensions (DNSSEC)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="February" year="2023"/>
            <abstract>
              <t indent="0">This document describes the DNS Security Extensions (commonly called "DNSSEC") 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 reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide 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="RFC9904" target="https://www.rfc-editor.org/info/rfc9904" quoteTitle="true" derivedAnchor="RFC9904">
          <front>
            <title>DNSSEC Cryptographic Algorithm Recommendation Update Process</title>
            <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
              <organization showOnFrontPage="true">USC/ISI</organization>
            </author>
            <author initials="W." surname="Kumari" fullname="Warren Kumari">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <date month="November" year="2025"/>
          </front>
          <seriesInfo name="RFC" value="9904"/>
          <seriesInfo name="DOI" value="10.17487/RFC9904"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC9558" target="https://www.rfc-editor.org/info/rfc9558" quoteTitle="true" derivedAnchor="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"/>
            <date month="April" year="2024"/>
            <abstract>
              <t indent="0">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>
          </front>
          <seriesInfo name="RFC" value="9558"/>
          <seriesInfo name="DOI" value="10.17487/RFC9558"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The 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 the many members of the DNSOP
      Working Group that discussed this specification.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
        <organization showOnFrontPage="true">USC/ISI</organization>
        <address>
          <email>ietf@hardakers.net</email>
        </address>
      </author>
      <author initials="W." surname="Kumari" fullname="Warren Kumari">
        <organization showOnFrontPage="true">Google</organization>
        <address>
          <email>warren@kumari.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
