<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docName="draft-ietf-regext-tmch-func-spec-15" indexInclude="true" ipr="trust200902" number="9361" prepTime="2023-03-09T20:50:37" scripts="Common,Latin" sortRefs="true" submissionType="independent" symRefs="true" tocDepth="9" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9361" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ICANN TMCH">ICANN Trademark Clearinghouse (TMCH) Functional Specifications</title>
    <seriesInfo name="RFC" value="9361" stream="independent"/>
    <author fullname="Gustavo Lozano" initials="G." surname="Lozano">
      <organization showOnFrontPage="true">ICANN</organization>
      <address>
        <postal>
          <street>12025 Waterfront Drive</street>
          <street>Suite 300</street>
          <city>Los Angeles</city>
          <code>90292</code>
          <country>United States of America</country>
        </postal>
        <phone>+1.310.301.5800</phone>
        <email>gustavo.lozano@icann.org</email>
      </address>
    </author>
    <date month="03" year="2023"/>
    <keyword>Trademark Clearinghouse</keyword>
    <keyword>TMDB</keyword>
    <keyword>ICANN</keyword>
    <keyword>TMCH</keyword>
    <keyword>gTLD</keyword>
    <keyword>new gTLD</keyword>
    <keyword>mark</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        This document describes the requirements, the architecture, and
        the interfaces between the ICANN Trademark Clearinghouse (TMCH) and
        Domain Name Registries, as well as between the ICANN TMCH and Domain Name
        Registrars for the provisioning and management of domain names
        during Sunrise and Trademark Claims Periods.
      </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 document is not an Internet Standards Track specification; it is
            published for informational purposes.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see 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/rfc9361" 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) 2023 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.
        </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>
          </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-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" 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-glossary">Glossary</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-architecture">Architecture</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sunrise-period">Sunrise Period</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trademark-claims-period">Trademark Claims Period</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interfaces">Interfaces</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hv">hv</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vd">vd</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dy">dy</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tr">tr</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.5">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.5.1"><xref derivedContent="4.3.5" format="counter" sectionFormat="of" target="section-4.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ry">ry</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.6">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.6.1"><xref derivedContent="4.3.6" format="counter" sectionFormat="of" target="section-4.3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dr">dr</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.7">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.7.1"><xref derivedContent="4.3.7" format="counter" sectionFormat="of" target="section-4.3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-yd">yd</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.8">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.8.1"><xref derivedContent="4.3.8" format="counter" sectionFormat="of" target="section-4.3.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dv">dv</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.9">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.9.1"><xref derivedContent="4.3.9" format="counter" sectionFormat="of" target="section-4.3.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vh">vh</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.10">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.10.1"><xref derivedContent="4.3.10" format="counter" sectionFormat="of" target="section-4.3.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-vs">vs</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.11">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.11.1"><xref derivedContent="4.3.11" format="counter" sectionFormat="of" target="section-4.3.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sy">sy</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.12">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.12.1"><xref derivedContent="4.3.12" format="counter" sectionFormat="of" target="section-4.3.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sr">sr</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.13">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.13.1"><xref derivedContent="4.3.13" format="counter" sectionFormat="of" target="section-4.3.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-vc">vc</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.14">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.14.1"><xref derivedContent="4.3.14" format="counter" sectionFormat="of" target="section-4.3.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-cy">cy</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.15">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.15.1"><xref derivedContent="4.3.15" format="counter" sectionFormat="of" target="section-4.3.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-cr">cr</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </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-process-descriptions">Process Descriptions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bootstrapping">Bootstrapping</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bootstrapping-for-registrie">Bootstrapping for Registries</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2.1.2">
                      <li pn="section-toc.1-1.5.2.1.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.1.2.1.1"><xref derivedContent="5.1.1.1" format="counter" sectionFormat="of" target="section-5.1.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-credentials">Credentials</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.1.2.1.2.2">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.1.2.2.1"><xref derivedContent="5.1.1.2" format="counter" sectionFormat="of" target="section-5.1.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-addresses-for-access-con">IP Addresses for Access Control</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.1.2.1.2.3">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.1.2.3.1"><xref derivedContent="5.1.1.3" format="counter" sectionFormat="of" target="section-5.1.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icann-tmch-trust-anchor">ICANN TMCH Trust Anchor</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.1.2.1.2.4">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.1.2.4.1"><xref derivedContent="5.1.1.4" format="counter" sectionFormat="of" target="section-5.1.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-pgp-key">TMDB PGP Key</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bootstrapping-for-registrar">Bootstrapping for Registrars</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2.2.2">
                      <li pn="section-toc.1-1.5.2.1.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.2.2.1.1"><xref derivedContent="5.1.2.1" format="counter" sectionFormat="of" target="section-5.1.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-credentials-2">Credentials</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.1.2.2.2.2">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.2.2.2.1"><xref derivedContent="5.1.2.2" format="counter" sectionFormat="of" target="section-5.1.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-addresses-for-access-cont">IP Addresses for Access Control</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.1.2.2.2.3">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.2.2.3.1"><xref derivedContent="5.1.2.3" format="counter" sectionFormat="of" target="section-5.1.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icann-tmch-trust-anchor-2">ICANN TMCH Trust Anchor</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.1.2.2.2.4">
                        <t indent="0" pn="section-toc.1-1.5.2.1.2.2.2.4.1"><xref derivedContent="5.1.2.4" format="counter" sectionFormat="of" target="section-5.1.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-pgp-key-2">TMDB PGP Key</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sunrise-period-2">Sunrise Period</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-domain-name-registration">Domain Name Registration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sunrise-domain-name-registr">Sunrise Domain Name Registration by Registries</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-sunrise-services-for-r">TMDB Sunrise Services for Registries</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2.3.2">
                      <li pn="section-toc.1-1.5.2.2.2.3.2.1">
                        <t indent="0" pn="section-toc.1-1.5.2.2.2.3.2.1.1"><xref derivedContent="5.2.3.1" format="counter" sectionFormat="of" target="section-5.2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-smd-revocation-list">SMD Revocation List</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.2.2.3.2.2">
                        <t indent="0" pn="section-toc.1-1.5.2.2.2.3.2.2.1"><xref derivedContent="5.2.3.2" format="counter" sectionFormat="of" target="section-5.2.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmv-certificate-revocation-">TMV Certificate Revocation List (CRL)</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.2.2.3.2.3">
                        <t indent="0" pn="section-toc.1-1.5.2.2.2.3.2.3.1"><xref derivedContent="5.2.3.3" format="counter" sectionFormat="of" target="section-5.2.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-notice-of-registered-domain">Notice of Registered Domain Names (NORDN)</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.4.1"><xref derivedContent="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sunrise-domain-name-registra">Sunrise Domain Name Registration by Registrars</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.5.1"><xref derivedContent="5.2.5" format="counter" sectionFormat="of" target="section-5.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-sunrise-services-for-re">TMDB Sunrise Services for Registrars</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trademark-claims-period-2">Trademark Claims Period</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-domain-registration">Domain Registration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trademark-claims-domain-nam">Trademark Claims Domain Name Registration by Registries</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-trademark-claims-servi">TMDB Trademark Claims Services for Registries</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2.3.2">
                      <li pn="section-toc.1-1.5.2.3.2.3.2.1">
                        <t indent="0" pn="section-toc.1-1.5.2.3.2.3.2.1.1"><xref derivedContent="5.3.3.1" format="counter" sectionFormat="of" target="section-5.3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-domain-name-label-dnl-list">Domain Name Label (DNL) List</xref></t>
                      </li>
                      <li pn="section-toc.1-1.5.2.3.2.3.2.2">
                        <t indent="0" pn="section-toc.1-1.5.2.3.2.3.2.2.1"><xref derivedContent="5.3.3.2" format="counter" sectionFormat="of" target="section-5.3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-notice-of-registered-domain-">Notice of Registered Domain Names (NORDN)</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.4.1"><xref derivedContent="5.3.4" format="counter" sectionFormat="of" target="section-5.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trademark-claims-domain-name">Trademark Claims Domain Name Registration by Registrars</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.5">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.5.1"><xref derivedContent="5.3.5" format="counter" sectionFormat="of" target="section-5.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-trademark-claims-servic">TMDB Trademark Claims Services for Registrars</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2.5.2">
                      <li pn="section-toc.1-1.5.2.3.2.5.2.1">
                        <t indent="0" pn="section-toc.1-1.5.2.3.2.5.2.1.1"><xref derivedContent="5.3.5.1" format="counter" sectionFormat="of" target="section-5.3.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-claims-notice-information-s">Claims Notice Information Service (CNIS)</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-qualified-launch-program-ql">Qualified Launch Program (QLP) Period</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.4.2">
                  <li pn="section-toc.1-1.5.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.1.1"><xref derivedContent="5.4.1" format="counter" sectionFormat="of" target="section-5.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-domain-registration-2">Domain Registration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.2.1"><xref derivedContent="5.4.2" format="counter" sectionFormat="of" target="section-5.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tmdb-qlp-services-for-regis">TMDB QLP Services for Registries</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.4.2.2.2">
                      <li pn="section-toc.1-1.5.2.4.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.5.2.4.2.2.2.1.1"><xref derivedContent="5.4.2.1" format="counter" sectionFormat="of" target="section-5.4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sunrise-list-surl">Sunrise List (SURL)</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </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-data-format-descriptions">Data Format Descriptions</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-domain-name-label-dnl-list-2">Domain Name Label (DNL) List</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-smd-revocation-list-2">SMD Revocation List</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-list-of-registered-domain-n">List of Registered Domain Names (LORDN) File</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.3.2">
                  <li pn="section-toc.1-1.6.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derivedContent="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lordn-log-file">LORDN Log File</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.3.2.1.2">
                      <li pn="section-toc.1-1.6.2.3.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.6.2.3.2.1.2.1.1"><xref derivedContent="6.3.1.1" format="counter" sectionFormat="of" target="section-6.3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lordn-log-result-codes">LORDN Log Result Codes</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signed-mark-data-smd-file">Signed Mark Data (SMD) File</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trademark-claims-notice-tcn">Trademark Claims Notice (TCN)</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sunrise-list-surl-2">Sunrise List (SURL)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-formal-syntax">Formal Syntax</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trademark-claims-notice-tcn-2">Trademark Claims Notice (TCN)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <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.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">  
        Domain Name Registries may operate in special modes for certain periods of time, enabling Trademark Holders to protect their rights
        during the introduction of a Top-Level Domain (TLD).
      </t>
      <t indent="0" pn="section-1-2">
        Along with the introduction of new generic TLDs (gTLDs), two special modes came into effect:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-3">
        <li pn="section-1-3.1">
            Sunrise Period: The Sunrise Period allows Trademark Holders an advance opportunity to
            register domain names corresponding to their marks before names
            are generally available to the public.
          </li>
        <li pn="section-1-3.2">
            Trademark Claims Period: The Trademark Claims Period follows the Sunrise Period and
            runs for at least the first 90 days of an initial operating
            period of general registration. During the Trademark Claims
            Period, anyone attempting to register a domain name matching
            a mark that is recorded in the ICANN Trademark Clearinghouse (TMCH) will
            receive a notification displaying the relevant mark information.
          </li>
      </ul>
      <t indent="0" pn="section-1-4">
        This document describes the requirements, the architecture, and
        the interfaces between the ICANN TMCH and
        Domain Name Registries (called "Registries" in the rest of the document),
        as well as between the ICANN TMCH and Domain Name
        Registrars (called "Registrars" in the rest of the document) 
        for the provisioning and management of domain names
        during Sunrise and Trademark Claims Periods.
      </t>
      <t indent="0" pn="section-1-5">
        For any date and/or time indications, Coordinated Universal
        Time (UTC) applies. 
      </t>
    </section>
    <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-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>
      <t indent="0" pn="section-2-2">
        XML is case sensitive. Unless stated otherwise, XML specifications
        and examples provided in this document <bcp14>MUST</bcp14> be interpreted in the
        character case presented in order to develop a conforming
        implementation.
      </t>
      <t indent="0" pn="section-2-3">
        "tmNotice-1.0" is used as an abbreviation for
        "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "tmNotice"
        is used, but implementations <bcp14>MUST NOT</bcp14> depend on it and instead employ
        a proper namespace-aware XML parser and serializer to interpret and
        output the XML documents. 
      </t>
      <t indent="0" pn="section-2-4">Extensible Markup Language (XML) 1.0, as described in <xref target="W3C.REC-xml-20081126" format="default" sectionFormat="of" derivedContent="W3C.REC-xml-20081126"/>, and XML Schema notation, as described in <xref target="W3C.REC-xmlschema-1-20041028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-1-20041028"/> and <xref target="W3C.REC-xmlschema-2-20041028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-2-20041028"/>, are used in this specification. </t>
    </section>
    <section anchor="glossary" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-glossary">Glossary</name>
      <t indent="0" pn="section-3-1">
        In the following section, the most common terms are briefly explained:
      </t>
      <dl spacing="normal" newline="false" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">Backend Registry Operator:</dt>
        <dd pn="section-3-2.2">An entity that manages (a part of) the technical infrastructure for a Registry
	Operator. The Registry Operator may also be the Backend Registry Operator.</dd>
        <dt pn="section-3-2.3">CA:</dt>
        <dd pn="section-3-2.4">Certification Authority. See <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</dd>
        <dt pn="section-3-2.5">CNIS:</dt>
        <dd pn="section-3-2.6">Claims Notice Information Service. This service provides Trademark Claims
        Notices (TCNs) to Registrars.</dd>
        <dt pn="section-3-2.7">CRC32:</dt>
        <dd pn="section-3-2.8">Cyclic Redundancy Check. This algorithm is used in the ISO 3309 standard and in Section
	8.1.1.6.2 of
        ITU-T recommendation V.42.</dd>
        <dt pn="section-3-2.9">CRL:</dt>
        <dd pn="section-3-2.10">Certificate Revocation List. See <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</dd>
        <dt pn="section-3-2.11">CSV:</dt>
        <dd pn="section-3-2.12">Comma-Separated Values. See <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/>.</dd>
        <dt pn="section-3-2.13">datetime:</dt>
        <dd pn="section-3-2.14">Date and time. The date and time are specified following 
        the standard specification "Date and Time on the Internet: Timestamps". See
        <xref target="RFC3339" format="default" sectionFormat="of" derivedContent="RFC3339"/>.</dd>
        <dt pn="section-3-2.15">DN:</dt>
        <dd pn="section-3-2.16">Domain Name. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.17">DNL:</dt>
        <dd pn="section-3-2.18">Domain Name Label. The DNL is an A-label or a Non-Reserved LDH (NR-LDH) label. See <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.</dd>
        <dt pn="section-3-2.19">DNL List:</dt>
        <dd pn="section-3-2.20">A list of DNLs that are covered by a PRM.</dd>
        <dt pn="section-3-2.21">DNROID:</dt>
        <dd pn="section-3-2.22">DN Repository Object IDentifier. This identifier is assigned by the Registry to each DN
	object that unequivocally
	identifies said DN object. For example, if a new DN object is created for a name that
	existed in the past, the DN objects will have different DNROIDs.</dd>
        <dt pn="section-3-2.23">DNS:</dt>
        <dd pn="section-3-2.24">Domain Name System. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.25">Effective Allocation:</dt>
        <dd pn="section-3-2.26"> A DN is considered effectively allocated when the DN object for
        the DN has been created in the SRS of the Registry and has been assigned to the effective
	user.  A DN object in status "pendingCreate" or any other status that precedes the
        first time a DN is assigned to an end user is not considered an effective allocation.
        A DN object created internally by the Registry for subsequent
        delegation to another Registrant is not considered an effective allocation.</dd>
        <dt pn="section-3-2.27">EPP:</dt>
        <dd pn="section-3-2.28">Extensible Provisioning Protocol. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.29">FQDN:</dt>
        <dd pn="section-3-2.30">Fully Qualified Domain Name. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.31">HTTP:</dt>
        <dd pn="section-3-2.32">Hypertext Transfer Protocol. See <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/>.</dd>
        <dt pn="section-3-2.33">HTTPS:</dt>
        <dd pn="section-3-2.34">HTTP over TLS (Transport Layer Security). See <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/>.</dd>
        <dt pn="section-3-2.35">ICANN TMCH:</dt>
        <dd pn="section-3-2.36">A central repository for
        information to be authenticated, stored, and disseminated,
        pertaining to the rights of TMHs. The ICANN TMCH is split into two functions: TMV and TMDB
        (see below). There could be several entities performing the
        TMV function but only one entity performing the
        TMDB function.</dd>
        <dt pn="section-3-2.37">ICANN TMCH-CA:</dt>
        <dd pn="section-3-2.38">The Certification Authority (CA) for the ICANN TMCH. This CA is
        operated by ICANN. The public key for this CA is the trust anchor
        used to validate the identity of each TMV.</dd>
        <dt pn="section-3-2.39">IDN:</dt>
        <dd pn="section-3-2.40">Internationalized Domain Name. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.41">Lookup Key:</dt>
        <dd pn="section-3-2.42">A random string of up to 51 characters from the set
        [a-zA-Z0-9/] to be used as the lookup key by Registrars 
        to obtain the TCN using the CNIS. 
        Lookup keys are unique and are related to one DNL only.</dd>
        <dt pn="section-3-2.43">LORDN:</dt>
        <dd pn="section-3-2.44">List of Registered Domain Names. This is the list
        of effectively allocated DNs matching a DNL of a PRM.
        Registries will upload this list to the TMDB (during the NORDN
        process).</dd>
        <dt pn="section-3-2.45">Matching Rules:</dt>
        <dd pn="section-3-2.46">Some trademarks entitled to inclusion 
        in the TMDB include characters that are impermissible 
        in the DNS as a DNL. The TMV changes (using the ICANN TMCH Matching Rules <xref target="MatchingRules" format="default" sectionFormat="of" derivedContent="MatchingRules"/>) 
        certain DNS-impermissible characters in a trademark into 
        DNS-permissible equivalent characters.</dd>
        <dt pn="section-3-2.47">NORDN:</dt>
        <dd pn="section-3-2.48">Notification of Registered Domain Names. This is the
        process by which Registries upload their recent LORDN to
        the TMDB.</dd>
        <dt pn="section-3-2.49">PGP:</dt>
        <dd pn="section-3-2.50">Pretty Good Privacy. See <xref target="RFC4880" format="default" sectionFormat="of" derivedContent="RFC4880"/>.</dd>
        <dt pn="section-3-2.51">PKI:</dt>
        <dd pn="section-3-2.52">Public Key Infrastructure. See <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</dd>
        <dt pn="section-3-2.53">PRM:</dt>
        <dd pn="section-3-2.54">Pre-Registered Mark. A mark that has been
        pre-registered with the ICANN TMCH.</dd>
        <dt pn="section-3-2.55">QLP Period:</dt>
        <dd pn="section-3-2.56">Qualified Launch Program Period. During this optional period, a special
        process applies to DNs matching the Sunrise List (SURL) and/or the DNL List to ensure
	that TMHs are informed of a DN matching their PRM. </dd>
        <dt pn="section-3-2.57">Registrant:</dt>
        <dd pn="section-3-2.58">See the definition of Registrant in <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.59">Registrar:</dt>
        <dd pn="section-3-2.60">Domain Name Registrar. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.61">Registry:</dt>
        <dd pn="section-3-2.62">Domain Name Registry, Registry Operator. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.
	A Registry Operator is the contracting party with ICANN for the TLD.</dd>
        <dt pn="section-3-2.63">SMD:</dt>
        <dd pn="section-3-2.64">Signed Mark Data. A cryptographically signed token issued by
        the TMV to the TMH to be used in the Sunrise Period to apply for a
        DN that matches a DNL of a PRM. See <xref target="RFC7848" format="default" sectionFormat="of" derivedContent="RFC7848"/>. 
        An SMD generated by an ICANN-approved Trademark Validator (TMV) contains 
        both the signed token and the TMV's PKIX certificate.</dd>
        <dt pn="section-3-2.65">SMD File:</dt>
        <dd pn="section-3-2.66">A file containing the SMD (see above) and some
        human-readable data. The latter is usually ignored in the
        processing of the SMD File. See <xref target="SmdFileFormat" format="default" sectionFormat="of" derivedContent="Section 6.4"/>.</dd>
        <dt pn="section-3-2.67">SMD Revocation List:</dt>
        <dd pn="section-3-2.68">The SMD Revocation List is used by
        Registries (and optionally by Registrars) during the
        Sunrise Period to ensure that an SMD is still valid
        (i.e., not revoked). The SMD Revocation List has a similar
        function as CRLs used in PKI.</dd>
        <dt pn="section-3-2.69">SRS:</dt>
        <dd pn="section-3-2.70">Shared Registration System. See <xref target="ICANN-GTLD-AGB-20120604" format="default" sectionFormat="of" derivedContent="ICANN-GTLD-AGB-20120604"/>.</dd>
        <dt pn="section-3-2.71">Sunrise Period:</dt>
        <dd pn="section-3-2.72">During this period, DNs matching a
        DNL of a PRM can be exclusively obtained by the respective
        TMHs. For DNs matching a PRM, a special
        process applies to ensure that TMHs are informed on the
        effective allocation of a DN matching their PRM. </dd>
        <dt pn="section-3-2.73">SURL:</dt>
        <dd pn="section-3-2.74">Sunrise List. The list of DNLs that are covered by a PRM and are eligible for
	Sunrise.</dd>
        <dt pn="section-3-2.75">TCN:</dt>
        <dd pn="section-3-2.76">Trademark Claims Notice, Claims Notice, Trademark Notice. A Trademark Claims
        Notice consists of one or more Trademark Claims and is provided to 
        prospective Registrants of DNs.  </dd>
        <dt pn="section-3-2.77">TCNID:</dt>
        <dd pn="section-3-2.78">Trademark Claims Notice Identifier. An element of the Trademark Claims
        Notice (see above), identifying said TCN. 
        The Trademark Claims Notice Identifier is specified in the 
        element &lt;tmNotice:id&gt;. </dd>
        <dt pn="section-3-2.79">TLD:</dt>
        <dd pn="section-3-2.80">Top-Level Domain Name. See <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-3-2.81">TMDB:</dt>
        <dd pn="section-3-2.82">Trademark Clearinghouse Database. This serves as a
        database of the ICANN TMCH to provide information to the
        gTLD Registries and Registrars to support Sunrise or
        Trademark Claims services. There is only one TMDB in the
        ICANN TMCH that concentrates the information about
        the "verified" trademark records from the TMVs.</dd>
        <dt pn="section-3-2.83">TMH:</dt>
        <dd pn="section-3-2.84">Trademark Holder. The person or organization owning
        rights on a mark.</dd>
        <dt pn="section-3-2.85">TMV:</dt>
        <dd pn="section-3-2.86">Trademark Validator, Trademark Validation
        organization. An entity authorized by ICANN to authenticate
        and validate registrations in the TMDB, ensuring the marks qualify as
        registered, are court-validated marks, or are protected by statute or treaty. This entity would
        also be asked to ensure that proof of use of marks is
        provided, which can be demonstrated by furnishing a signed
         declaration and one specimen of current use. </dd>
        <dt pn="section-3-2.87">Trademark, Mark:</dt>
        <dd pn="section-3-2.88"> Marks are used to claim exclusive
        properties of products or services. A mark is
        typically a name, word, phrase, logo, symbol, design,
        image, or a combination of these elements. For the scope of
        this document, only textual marks are relevant.</dd>
        <dt pn="section-3-2.89">Trademark Claims, Claims:</dt>
        <dd pn="section-3-2.90">Provides information to enhance the
        understanding of the trademark rights being claimed by the
        TMH.</dd>
        <dt pn="section-3-2.91">Trademark Claims Period:</dt>
        <dd pn="section-3-2.92"> During this period, a special
        process applies to DNs matching the DNL List to ensure that
        TMHs are informed of a DN
        matching their PRM. For DNs matching the DNL List,
        Registrars show a TCN to prospective
        Registrants that has to be acknowledged before effective allocation of
        the DN.</dd>
        <dt pn="section-3-2.93">UTC:</dt>
        <dd pn="section-3-2.94"> Coordinated Universal Time. This is maintained by the
        Bureau International des Poids et Mesures (BIPM). See
        <xref target="RFC3339" format="default" sectionFormat="of" derivedContent="RFC3339"/>.</dd>
      </dl>
      <t indent="0" pn="section-3-3"> </t>
    </section>
    <section anchor="architecture" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-architecture">Architecture</name>
      <section anchor="archSunrise" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-sunrise-period">Sunrise Period</name>
        <figure anchor="figArchSunrise" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-architecture-of-the-sunrise">Architecture of the Sunrise Period</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-1.1">          
                     SMD hand over (out-of-band)
           ..............................................
           :                                            :
           :           .'''''''''''''''''''.            :
           :           .    ICANN TMCH     .            :
           :           .....................            :
           v           .                   .            :
    .------------.     .  .-------------.  . hv      .-----.
    | Registrant |     .  |     TMV     |&lt;----------&gt;| TMH |
    '------------'     .  '-------------'  .     vh  '-----'
          |            .     |       ^   \ .
          |            .     |       |    \.
       tr |            .  vs |       | dv  \
          |            .     |    vd |     .\
          v            .     v       v     . \
    .-----------.  sr  .    .---------.    .  \
 .-&gt;| Registrar |&lt;..........|         |    .   \
 :  '-----------'      .    |         |    .    \
 :        |        sy  .    |    T    |    .     \
 :     ry |    .------------|    M    |    .   vc \
 :        |    |       .    |    D    |    .       \
 :        v    v       .    |    B    |    .        v
 :  .-----------.      . yd |         |    .  .---------------.
 :  | Registry  |----------&gt;|         |    .  | ICANN TMCH-CA |
 :  '-----------'      .    '---------'    .  '---------------'
 :        ^            .                   .        |   :
 :        |             '''''''''''''''''''         |   :
 :        | cy                                      |   :
 : cr     '-----------------------------------------'   :
 :......................................................:
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-2"><xref target="figArchSunrise" format="default" sectionFormat="of" derivedContent="Figure 1"/> depicts the architecture of the Sunrise Period, including all the actors and interfaces.</t>
        <t indent="0" pn="section-4.1-3"> </t>
      </section>
      <section anchor="archTrCl" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-trademark-claims-period">Trademark Claims Period</name>
        <figure anchor="figArchTrCl" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-architecture-of-the-tradema">Architecture of the Trademark Claims Period</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.2-1.1">              
                    .''''''''''''''.
                    .  ICANN TMCH  .
                    ................
                    .              .
 .------------.     .  .-------.   . hv      .-----.
 | Registrant |     .  |  TMV  |&lt;-----------&gt;| TMH |
 '------------'     .  '-------'   .     vh  '-----'
        |           .      ^       .
        |           .      | dv    .
     tr |           .   vd |       .
        v           .      v       .
 .-----------.  dr  .  .-------.   .
 | Registrar |&lt;--------|       |   .
 '-----------'      .  |   T   |   .
     ry |           .  |   M   |   .
        v           .  |   D   |   .
  .----------.  dy  .  |   B   |   .
  | Registry |&lt;-------&gt;|       |   .
  '----------'   yd .  '-------'   .
                    .              .
                     ''''''''''''''
</artwork>
        </figure>
        <t indent="0" pn="section-4.2-2"><xref target="figArchTrCl" format="default" sectionFormat="of" derivedContent="Figure 2"/> depicts the architecture of the Trademark Claims Period, including all the actors and interfaces.</t>
      </section>
      <section anchor="archInterfaces" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-interfaces">Interfaces</name>
        <t indent="0" pn="section-4.3-1">
          The subsections below contain short descriptions of each interface to
          provide an overview of the architecture. More detailed
          descriptions of the relevant interfaces are in <xref target="processDescriptions" format="default" sectionFormat="of" derivedContent="Section 5"/>.
        </t>
        <section anchor="hv" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-hv">hv</name>
          <t indent="0" pn="section-4.3.1-1">
            The TMH registers a mark with a TMV via the hv interface.
          </t>
          <t indent="0" pn="section-4.3.1-2">
            After successful registration of the mark, the TMV
            makes a Signed Mark Data (SMD) File available (see
            <xref target="SmdFileFormat" format="default" sectionFormat="of" derivedContent="Section 6.4"/>) to the TMH to be used
            during the Sunrise Period.
          </t>
          <t indent="0" pn="section-4.3.1-3">
            The specifics of the hv interface are beyond the scope
            of this document.
          </t>
        </section>
        <section anchor="vd" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-vd">vd</name>
          <t indent="0" pn="section-4.3.2-1">
            After successful registration of the mark, the TMV ensures the
            TMDB inserts the corresponding DNLs and marks information
            into the database via the vd interface. 
          </t>
          <t indent="0" pn="section-4.3.2-2">
            The specifics of
            the vd interface are beyond the scope of this document.
          </t>
        </section>
        <section anchor="dy" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.3">
          <name slugifiedName="name-dy">dy</name>
          <t indent="0" pn="section-4.3.3-1">
            During the Trademark Claims Period, the Registry fetches
            the latest DNL List from the TMDB via the dy interface
            at regular intervals.  The protocol used on the dy
            interface is HTTPS. 
          </t>
          <t indent="0" pn="section-4.3.3-2">
            This interface is not relevant during the Sunrise Period.
          </t>
        </section>
        <section anchor="tr" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.4">
          <name slugifiedName="name-tr">tr</name>
          <t indent="0" pn="section-4.3.4-1">
            The Registrant communicates with the Registrar via the 
            tr interface.
          </t>
          <t indent="0" pn="section-4.3.4-2">
            The specifics of the tr interface are beyond the scope
            of this document.
          </t>
        </section>
        <section anchor="ry" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.5">
          <name slugifiedName="name-ry">ry</name>
          <t indent="0" pn="section-4.3.5-1">
            The Registrar communicates with the Registry via the ry interface. 
            The ry interfaces are typically implemented in
            EPP.
          </t>
        </section>
        <section anchor="dr" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.6">
          <name slugifiedName="name-dr">dr</name>
          <t indent="0" pn="section-4.3.6-1">
            During the Trademark Claims Period, the Registrar fetches
            the TCN from the TMDB (to be
            displayed to the Registrant via the tr interface) via
            the dr interface. The protocol used for fetching the
            TCN is HTTPS.
          </t>
          <t indent="0" pn="section-4.3.6-2">
            This interface is not relevant during the Sunrise Period.
          </t>
        </section>
        <section anchor="yd" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.7">
          <name slugifiedName="name-yd">yd</name>
          <t indent="0" pn="section-4.3.7-1">
            During the Sunrise Period, the Registry notifies the TMDB
            via the yd interface of all DNs
            effectively allocated.
          </t>
          <t indent="0" pn="section-4.3.7-2">
            During the Trademark Claims Period, the Registry notifies
            the TMDB via the yd interface of all DNs
            effectively allocated that matched an entry in the DNL List that the Registry
	    previously downloaded during the creation of the DN.
          </t>
          <t indent="0" pn="section-4.3.7-3">
            The protocol used on the yd interface is HTTPS.
          </t>
        </section>
        <section anchor="dv" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.8">
          <name slugifiedName="name-dv">dv</name>
          <t indent="0" pn="section-4.3.8-1">
	    The TMDB notifies the TMV via the dv interface of all effectively 
	    allocated DNs that match a mark registered by that TMV.
          </t>
          <t indent="0" pn="section-4.3.8-2">
            The specifics of the dv interface are beyond the scope
            of this document.
          </t>
        </section>
        <section anchor="vh" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.9">
          <name slugifiedName="name-vh">vh</name>
          <t indent="0" pn="section-4.3.9-1">
	    The TMV notifies the TMH via the vh interface after an effectively
	    allocated DN matches a PRM of this THM.
          </t>
          <t indent="0" pn="section-4.3.9-2">
            The specifics of the vh interface are beyond the scope of
            this document.
          </t>
        </section>
        <section anchor="vs" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.10">
          <name slugifiedName="name-vs">vs</name>
          <t indent="0" pn="section-4.3.10-1">
            The TMV requests to add revoked
            SMDs to the SMD Revocation List at the TMDB.  
          </t>
          <t indent="0" pn="section-4.3.10-2">
            The specifics of the vs interface are beyond the scope of
            this document.
          </t>
          <t indent="0" pn="section-4.3.10-3">
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="sy" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.11">
          <name slugifiedName="name-sy">sy</name>
          <t indent="0" pn="section-4.3.11-1">
            During the Sunrise Period, the Registry fetches the most
            recent SMD Revocation List from the TMDB via the sy
            interface in regular intervals.  The protocol used on
            the sy interface is HTTPS. 
          </t>
          <t indent="0" pn="section-4.3.11-2">
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="sr" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.12">
          <name slugifiedName="name-sr">sr</name>
          <t indent="0" pn="section-4.3.12-1">
            During the Sunrise Period, the Registrar may fetch the
            most recent SMD Revocation List from the TMDB via the
            sr interface.  The protocol used on the sr interface is
            the same as on the sy interface (see above),
            i.e., HTTPS. 
          </t>
          <t indent="0" pn="section-4.3.12-2">
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="vc" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.13">
          <name slugifiedName="name-vc">vc</name>
          <t indent="0" pn="section-4.3.13-1">
            The TMV registers its public key and requests to revoke an existing
            key with the ICANN TMCH-CA over the vc interface.
          </t>
          <t indent="0" pn="section-4.3.13-2">
            The specifics of the vc interface are beyond the scope of this
            document, but it involves personal communication between the
            operators of the TMV and the operators of the ICANN TMCH-CA.
          </t>
          <t indent="0" pn="section-4.3.13-3">
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="cy" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.14">
          <name slugifiedName="name-cy">cy</name>
          <t indent="0" pn="section-4.3.14-1">
            During the Sunrise Period, the Registry fetches the most
            recent TMV CRL file from the ICANN TMCH-CA via the cy interface at
            regular intervals. The TMV CRL is used for validation 
            of TMV certificates. The protocol used on the cy
            interface is HTTPS.
          </t>
          <t indent="0" pn="section-4.3.14-2">
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="cr" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.15">
          <name slugifiedName="name-cr">cr</name>
          <t indent="0" pn="section-4.3.15-1">
            During the Sunrise Period, the Registrar optionally fetches the
            most recent TMV CRL file from the ICANN TMCH-CA via the cr interface at
            regular intervals. The TMV CRL is used for validation 
            of TMV certificates.
            The protocol used on the cr
            interface is HTTPS.
          </t>
          <t indent="0" pn="section-4.3.15-2">
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
      </section>
    </section>
    <section anchor="processDescriptions" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-process-descriptions">Process Descriptions</name>
      <section anchor="bootstraping" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-bootstrapping">Bootstrapping</name>
        <section anchor="procDescBootstrapRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-bootstrapping-for-registrie">Bootstrapping for Registries</name>
          <section anchor="procDescBootstrapCredentialsRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1.1">
            <name slugifiedName="name-credentials">Credentials</name>
            <t indent="0" pn="section-5.1.1.1-1">Each Registry Operator will receive authentication credentials from the TMDB to be used:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.1.1-2">
              <li pn="section-5.1.1.1-2.1">during the Sunrise Period to fetch the SMD Revocation List
              from the TMDB via the sy interface
              (<xref target="sy" format="default" sectionFormat="of" derivedContent="Section 4.3.11"/>),</li>
              <li pn="section-5.1.1.1-2.2">during the Trademark Claims Period to fetch the DNL List from the TMDB via the dy interface (<xref target="dy" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>), and</li>
              <li pn="section-5.1.1.1-2.3">during the NORDN process to notify the LORDN to the
              TMDB via the yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>).</li>
            </ul>
            <t indent="0" pn="section-5.1.1.1-3">Note: Credentials are created per TLD and provided to the 
                  Registry Operator.</t>
          </section>
          <section anchor="procDescBootstrapIpAclRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1.2">
            <name slugifiedName="name-ip-addresses-for-access-con">IP Addresses for Access Control</name>
            <t indent="0" pn="section-5.1.1.2-1">
              Each Registry Operator <bcp14>MUST</bcp14> provide the TMDB with
              all IP addresses, which will be used to:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.1.2-2">
              <li pn="section-5.1.1.2-2.1">fetch the SMD Revocation List
              via the sy interface (<xref target="sy" format="default" sectionFormat="of" derivedContent="Section 4.3.11"/>),</li>
              <li pn="section-5.1.1.2-2.2">fetch the DNL List from the TMDB via the dy interface (<xref target="dy" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>), and</li>
              <li pn="section-5.1.1.2-2.3">upload the LORDN to the
                  TMDB via the yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>).</li>
            </ul>
            <t indent="0" pn="section-5.1.1.2-3">
                This access restriction <bcp14>MAY</bcp14> be applied by the TMDB in addition to
                HTTP Basic access authentication (see <xref target="RFC7617" format="default" sectionFormat="of" derivedContent="RFC7617"/>). For credentials to be
                used, see <xref target="procDescBootstrapCredentialsRy" format="default" sectionFormat="of" derivedContent="Section 5.1.1.1"/>. 
            </t>
            <t indent="0" pn="section-5.1.1.2-4">
                The TMDB <bcp14>MAY</bcp14> limit the number of IP addresses to be
                accepted per Registry Operator.
            </t>
          </section>
          <section anchor="procDescBootstrapTmchTaRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1.3">
            <name slugifiedName="name-icann-tmch-trust-anchor">ICANN TMCH Trust Anchor</name>
            <t indent="0" pn="section-5.1.1.3-1">
              Each Registry Operator <bcp14>MUST</bcp14> fetch the PKIX certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> of
              the ICANN TMCH-CA (Trust Anchor) from
              <eref target="https://ca.icann.org/tmch.crt" brackets="angle"/> to be used:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.1.3-2">
              <li pn="section-5.1.1.3-2.1">during the Sunrise Period to validate the TMV 
                  certificates and the TMV CRL.</li>
            </ul>
          </section>
          <section anchor="procDescBootstrapPgpKeyRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1.4">
            <name slugifiedName="name-tmdb-pgp-key">TMDB PGP Key</name>
            <t indent="0" pn="section-5.1.1.4-1">
              The TMDB <bcp14>MUST</bcp14> provide each Registry Operator with the public portion of 
              the PGP Key used by the TMDB, which is to be used:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.1.4-2">
              <li pn="section-5.1.1.4-2.1">during the Sunrise Period to perform integrity
              checking of the SMD Revocation List fetched from
              the TMDB via the sy interface (<xref target="sy" format="default" sectionFormat="of" derivedContent="Section 4.3.11"/>) and</li>
              <li pn="section-5.1.1.4-2.2">during the Trademark Claims Period to perform integrity
              checking of the DNL List fetched from the TMDB
              via the dy interface (<xref target="dy" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>).</li>
            </ul>
          </section>
        </section>
        <section anchor="procDescBootstrapRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-bootstrapping-for-registrar">Bootstrapping for Registrars</name>
          <section anchor="procDescBootstrapCredentialsRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2.1">
            <name slugifiedName="name-credentials-2">Credentials</name>
            <t indent="0" pn="section-5.1.2.1-1">
              Each ICANN-Accredited Registrar will receive authentication 
              credentials from the TMDB to be used:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.2.1-2">
              <li pn="section-5.1.2.1-2.1">during the Sunrise Period to (optionally) fetch the
              SMD Revocation List from the TMDB via the sr
              interface (<xref target="sr" format="default" sectionFormat="of" derivedContent="Section 4.3.12"/>) and</li>
              <li pn="section-5.1.2.1-2.2">during the Trademark Claims Period to fetch TCNs
              from the TMDB via the dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>).</li>
            </ul>
          </section>
          <section anchor="procDescBootstrapIpAclRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2.2">
            <name slugifiedName="name-ip-addresses-for-access-cont">IP Addresses for Access Control</name>
            <t indent="0" pn="section-5.1.2.2-1">
              Each Registrar <bcp14>MUST</bcp14> provide the TMDB
              with all IP addresses, which will be used to:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.2.2-2">
              <li pn="section-5.1.2.2-2.1">fetch the SMD Revocation List
              via the sr interface (<xref target="sr" format="default" sectionFormat="of" derivedContent="Section 4.3.12"/>) and</li>
              <li pn="section-5.1.2.2-2.2">fetch TCNs via the dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>).</li>
            </ul>
            <t indent="0" pn="section-5.1.2.2-3">
                This access restriction <bcp14>MAY</bcp14> be applied by the TMDB in addition to
                HTTP Basic access authentication (for credentials to be
                used, see <xref target="procDescBootstrapCredentialsRr" format="default" sectionFormat="of" derivedContent="Section 5.1.2.1"/>). 
            </t>
            <t indent="0" pn="section-5.1.2.2-4">
                The TMDB <bcp14>MAY</bcp14> limit the number of IP addresses to be
                accepted per Registrar.
            </t>
          </section>
          <section anchor="procDescBootstrapTmchTaRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2.3">
            <name slugifiedName="name-icann-tmch-trust-anchor-2">ICANN TMCH Trust Anchor</name>
            <t indent="0" pn="section-5.1.2.3-1">
              Registrars <bcp14>MAY</bcp14> fetch the PKIX certificate of
              the ICANN TMCH-CA (Trust Anchor) from
              <eref target="https://ca.icann.org/tmch.crt" brackets="angle"/> to be
              used:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.2.3-2">
              <li pn="section-5.1.2.3-2.1">during the Sunrise Period to (optionally) validate
              the TMV certificates and TMV CRL.</li>
            </ul>
          </section>
          <section anchor="procDescBootstrapPgpKeyRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2.4">
            <name slugifiedName="name-tmdb-pgp-key-2">TMDB PGP Key</name>
            <t indent="0" pn="section-5.1.2.4-1">
              Registrars <bcp14>MUST</bcp14> receive the public portion of the PGP Key
              used by TMDB from the TMDB administrator to be used:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.2.4-2">
              <li pn="section-5.1.2.4-2.1">during the Sunrise Period to (optionally) perform
              integrity checking of the SMD Revocation List
              fetched from the TMDB via the sr interface (<xref target="sr" format="default" sectionFormat="of" derivedContent="Section 4.3.12"/>).</li>
            </ul>
          </section>
        </section>
      </section>
      <section anchor="procDescSunrise" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-sunrise-period-2">Sunrise Period</name>
        <section anchor="procDescSunriseReg" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1">
          <name slugifiedName="name-domain-name-registration">Domain Name Registration</name>
          <figure anchor="figIntSunrisePeriod" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-domain-name-registration-du">Domain Name Registration during the Sunrise Period</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.2.1-1.1">              
.------------.     .-----------.                 .----------.
| Registrant |     | Registrar |                 | Registry |
'------------'     '-----------'                 '----------'
       |                 |                             |
       |      Request DN |                             |
       |    registration |                             |
       |      (with SMD) |                             |
       |----------------&gt;|       Check DN availability |
       |                 |----------------------------&gt;|
       |                 |                             |
       |                 | DN unavailable       .-------------.
       | DN unavailable  |&lt;--------------------( DN available? )
       |&lt;----------------|                   no '-------------'
       |                 |                             | yes
       |                 | DN available                |      
       |                 |&lt;----------------------------|
       |                 |                             | 
       |                 |     Request DN registration |
       |                 |                  (with SMD) |
       |                 |----------------------------&gt;|
       |                 |                             |
       |                 |             .------------------------------.
       |                 |             | DN registration validation / |
       |                 |             |       SMD validation         |
       |                 |             '------------------------------'
       |                 |                             |
       | Registration    |.-----------. Error .----------------------.
       | error           || TRY AGAIN |&lt;-----( Validation successful? )
       |&lt;----------------|| / ABORT   |    no '----------------------'
       |                 |'-----------'                | yes
       |                 |                             |
       |                 | DN registered               |
       | DN registered   |&lt;----------------------------|
       |&lt;----------------|                             |
       |                 |                             |
</artwork>
          </figure>
          <t indent="0" pn="section-5.2.1-2"><xref target="figIntSunrisePeriod" format="default" sectionFormat="of" derivedContent="Figure 3"/> represents a synchronous DN registration
              workflow (usually called first come first served).</t>
        </section>
        <section anchor="procDescSunriseResRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2">
          <name slugifiedName="name-sunrise-domain-name-registr">Sunrise Domain Name Registration by Registries</name>
          <t indent="0" pn="section-5.2.2-1">
            Registries <bcp14>MUST</bcp14> perform a minimum set of checks for
            verifying each DN registration during the Sunrise Period upon
            reception of a registration request over the ry interface
            (<xref target="ry" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>).  If any of these checks fail, the
            Registry <bcp14>MUST</bcp14> abort the registration.  Each of these
            checks <bcp14>MUST</bcp14> be performed before the DN is effectively allocated.
          </t>
          <t indent="0" pn="section-5.2.2-2">
            In case of asynchronous registrations (e.g., auctions), 
            the minimum set of checks <bcp14>MAY</bcp14> be performed when creating 
            the intermediate object (e.g., a DN application)
            used for DN registration.
            If the minimum set of checks is performed when creating
            the intermediate object (e.g., a DN application), a 
            Registry <bcp14>MAY</bcp14> effectively allocate the DN without performing
            the minimum set of checks again.
          </t>
          <t indent="0" pn="section-5.2.2-3">
            Performing the minimum set of checks, Registries <bcp14>MUST</bcp14>
            verify that:
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.2.2-4">
	    <li pn="section-5.2.2-4.1" derivedCounter="1.">an SMD has been received from the Registrar, along with
            the DN registration,</li>
            <li pn="section-5.2.2-4.2" derivedCounter="2.">the certificate of the TMV has been correctly signed
            by the ICANN TMCH-CA (the certificate of the TMV is
            contained within the SMD),</li>
            <li pn="section-5.2.2-4.3" derivedCounter="3.">the datetime when the validation is done is within the validity period of the TMV
	    certificate,</li>
            <li pn="section-5.2.2-4.4" derivedCounter="4.">the certificate of the TMV is not listed in the TMV CRL file
            specified in the CRL distribution point of the TMV
            certificate,</li>
            <li pn="section-5.2.2-4.5" derivedCounter="5.">the signature of the SMD (signed with the TMV certificate)
            is valid,</li>
            <li pn="section-5.2.2-4.6" derivedCounter="6.">the datetime when the validation is done is within the validity period of the SMD
	    based on &lt;smd:notBefore&gt; and &lt;smd:notAfter&gt; elements,</li>
            <li pn="section-5.2.2-4.7" derivedCounter="7.">the SMD has not been revoked, i.e., is not contained in
            the SMD Revocation List, and</li>
            <li pn="section-5.2.2-4.8" derivedCounter="8.">the leftmost DNL of the DN being
            effectively allocated matches one of the
            label (&lt;mark:label&gt;) elements in the SMD.
            For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
            being effectively allocated, the leftmost DNL would be "xn--mgbachtv".</li>
          </ol>
          <t indent="0" pn="section-5.2.2-5">
            These procedures apply to all DN effective allocations at
            the second level, as well as to all other levels
            subordinate to the TLD that the Registry accepts
            registrations for.
          </t>
        </section>
        <section anchor="SunriseRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3">
          <name slugifiedName="name-tmdb-sunrise-services-for-r">TMDB Sunrise Services for Registries</name>
          <section anchor="procDescSunriseSmdRevocList" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3.1">
            <name slugifiedName="name-smd-revocation-list">SMD Revocation List</name>
            <t indent="0" pn="section-5.2.3.1-1"> 
              A new SMD Revocation List <bcp14>MUST</bcp14> be published by the TMDB 
              twice a day, by 00:00:00 and 12:00:00 UTC.
            </t>
            <t indent="0" pn="section-5.2.3.1-2">
              Registries <bcp14>MUST</bcp14> refresh the latest version of the SMD
              Revocation List at least once every 24 hours.
            </t>
            <t indent="0" pn="section-5.2.3.1-3">
              Note: The SMD Revocation List will be the same regardless of the TLD.
              If a Backend Registry Operator manages the infrastructure
              of several TLDs, the Backend Registry Operator could
              refresh the SMD Revocation List once every 24 hours, and the 
              SMD Revocation List could be used for all the TLDs managed 
              by the Backend Registry Operator.
            </t>
            <figure anchor="figIntSmdRevocList" align="left" suppress-title="false" pn="figure-4">
              <name slugifiedName="name-update-of-the-smd-revocatio">Update of the SMD Revocation List</name>
              <artwork name="" type="" align="left" alt="" pn="section-5.2.3.1-4.1">                 
    .----------.                                             .------.
    | Registry |                                             | TMDB |
    '----------'                                             '------'
          |                                                      |
 .----------------.                                              |
 |  Periodically, |                                              |
 |    at least    |                                              |
 | every 24 hours |                                              |
 '----------------'                                              |
          |                                                      |
          |-----------------------------------------------------&gt;|
          |      Download the latest SMD Revocation List         |
          |&lt;-----------------------------------------------------|
          |                                                      |
          |                                                      |
</artwork>
            </figure>
            <t indent="0" pn="section-5.2.3.1-5"><xref target="figIntSmdRevocList" format="default" sectionFormat="of" derivedContent="Figure 4"/> depicts the process of downloading the latest SMD Revocation List initiated by the Registry.</t>
          </section>
          <section anchor="procDescSunriseCrl" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3.2">
            <name slugifiedName="name-tmv-certificate-revocation-">TMV Certificate Revocation List (CRL)</name>
            <t indent="0" pn="section-5.2.3.2-1"> 
              Registries <bcp14>MUST</bcp14> refresh their local copy of the TMV CRL file at
              least once every 24 hours using the CRL distribution point
              specified in the TMV certificate.
            </t>
            <t indent="0" pn="section-5.2.3.2-2"> 
              Operationally, the TMV CRL file and CRL distribution point
              are the same for all TMVs and (at publication of this
              document) are located at
              <eref target="http://crl.icann.org/tmch.crl" brackets="angle"/>.
            </t>
            <t indent="0" pn="section-5.2.3.2-3">
              Note: The TMV CRL file will be the same regardless of the TLD.
              If a Backend Registry Operator manages the infrastructure
              of several TLDs, the Backend Registry Operator could 
              refresh the TMV CRL file once every 24 hours, and the 
              TMV CRL file could be used for all the TLDs managed 
              by the Backend Registry Operator.
            </t>
            <figure anchor="figIntCRL" align="left" suppress-title="false" pn="figure-5">
              <name slugifiedName="name-update-of-the-tmv-crl-file">Update of the TMV CRL File</name>
              <artwork name="" type="" align="left" alt="" pn="section-5.2.3.2-4.1">                 
   .----------.                                .---------------.
   | Registry |                                | ICANN TMCH-CA |
   '----------'                                '---------------'
         |                                             |
 .----------------.                                    |
 | Periodically,  |                                    |
 |   at least     |                                    |
 | every 24 hours |                                    |
 '----------------'                                    |
         |                                             |
         |--------------------------------------------&gt;|
         |     Download the latest TMV CRL file        |
         |&lt;--------------------------------------------|
         |                                             |
         |                                             |
</artwork>
            </figure>
            <t indent="0" pn="section-5.2.3.2-5"><xref target="figIntCRL" format="default" sectionFormat="of" derivedContent="Figure 5"/> depicts the process of downloading the latest TMV CRL file initiated by the Registry.</t>
          </section>
          <section anchor="procDescSunriseNordn" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3.3">
            <name slugifiedName="name-notice-of-registered-domain">Notice of Registered Domain Names (NORDN)</name>
            <t indent="0" pn="section-5.2.3.3-1">
              The Registry <bcp14>MUST</bcp14> send a LORDN file containing
              DNs effectively allocated to the
              TMDB (over the yd interface; see <xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>).
            </t>
            <t indent="0" pn="section-5.2.3.3-2">
              The effective allocation of a DN <bcp14>MUST</bcp14> be reported by the Registry to the TMDB
              within 26 hours of the effective allocation of such DN.
            </t>
            <t indent="0" pn="section-5.2.3.3-3">
              The Registry <bcp14>MUST</bcp14> create and upload a LORDN file in case there are effective allocations in the SRS
              that have not been successfully reported to the TMDB in a previous LORDN file.
            </t>
            <t indent="0" pn="section-5.2.3.3-4">
              Based on the timers used by TMVs and the TMDB, the <bcp14>RECOMMENDED</bcp14> maximum frequency
              to upload LORDN files from the Registries to the TMDB is every 3 hours.
            </t>
            <t indent="0" pn="section-5.2.3.3-5">
              It is <bcp14>RECOMMENDED</bcp14> that Registries try to upload at least two LORDN files per day to the TMDB, 
              with enough time in between, in order to have time to fix problems reported in the LORDN file.
            </t>
            <t indent="0" pn="section-5.2.3.3-6">
              The Registry <bcp14>SHOULD</bcp14> upload a LORDN file only when the previous LORDN file has been processed 
              by the TMDB and the related LORDN Log file has been downloaded and processed by the Registry.
            </t>
            <t indent="0" pn="section-5.2.3.3-7">
              The Registry <bcp14>MUST</bcp14> upload LORDN files for DNs that are effectively allocated during the Sunrise or 
              Trademark Claims Periods (same applies to DNs that are effectively allocated 
              using applications created during the Sunrise or Trademark Claims Periods in case of using
              asynchronous registrations).
            </t>
            <t indent="0" pn="section-5.2.3.3-8">
              The yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>) <bcp14>MUST</bcp14> support at least one (1) and <bcp14>MAY</bcp14> support up to ten (10)
              concurrent connections from each IP address registered by a Registry Operator
              to access the service.
            </t>
            <t indent="0" pn="section-5.2.3.3-9">
              The TMDB <bcp14>MUST</bcp14> process each uploaded LORDN file and make the related log file available 
              for Registry download within 30 minutes of the finalization of the upload.
            </t>
            <figure anchor="figIntNordn" align="left" suppress-title="false" pn="figure-6">
              <name slugifiedName="name-notification-of-the-registe">Notification of the Registered Domain Name</name>
              <artwork name="" type="" align="left" alt="" pn="section-5.2.3.3-10.1">              
     .----------.            .------.          .-----.         .-----.
     | Registry |            | TMDB |          | TMV |         | TMH |
     '----------'            '------'          '-----'         '-----'
           |                     |                |               |
 .------------------.            |                |               |
 | Periodically     |            |                |               |
 | upload LORDN     |            |                |               |
 | file             |            |                |               |
 '------------------'            |                |               |
           |                     |                |               |
.---------&gt;|        Upload LORDN |                |               |
|          |--------------------&gt;|                |               |
|          |                     |                |               |
|          |        .-------------------------.   |               |
|          |        | Verify each domain name |   |               |
|          |        | in the uploaded file    |   |               |
|          |        | (within 30')            |   |               |
|          |        '-------------------------'   |               |
|          |                     |         ._____.|               |
|          | Download Log file   |         | END ||               |
|          |&lt;--------------------|         '-----'|               |
|          |                     |             ^  |               |
| .-----------------.    .---------------.     |  |               |
| |  Check whether  |   / everything fine \ no |  |               |
| |    Log file     |  ( (i.e., no errors  )---'  |               |
| | contains errors |   \ in Log file )?  /       |               |
| '-----------------'    '---------------'        |               |
|          |                     | yes            |               |
|  .---------------.             |                |               |
| / everything fine \ yes        |                |               |
|( (i.e., no errors  )-----.     |    Notify TMVs |               |
| \ in Log file )?  /      |     |   on the LORDN |               |
|  '---------------'       |     | pre-registered |               |
|          | no            v     |  with said TMV |               |
| .----------------.   .------.  |---------------&gt;|               |
'-| Correct Errors |   | DONE |  |                |               |
  '----------------'   '------'  |                |   Notify each |
           |                     |                |  affected TMH |
           |                     |                |--------------&gt;|
           |                     |                |               |
</artwork>
            </figure>
            <t indent="0" pn="section-5.2.3.3-11"><xref target="figIntNordn" format="default" sectionFormat="of" derivedContent="Figure 6"/> depicts the process to notify the TMH of Registered Domain Names.</t>
            <t indent="0" pn="section-5.2.3.3-12">
              The format used for the LORDN is described in <xref target="lordnFormat" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.
            </t>
          </section>
        </section>
        <section anchor="procDescSunriseResRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.4">
          <name slugifiedName="name-sunrise-domain-name-registra">Sunrise Domain Name Registration by Registrars</name>
          <t indent="0" pn="section-5.2.4-1">
            Registrars <bcp14>MAY</bcp14> choose to perform the checks for verifying
            DN registrations, as performed by the Registries (see <xref target="procDescSunriseResRy" format="default" sectionFormat="of" derivedContent="Section 5.2.2"/>) before sending the
            command to register a DN.
          </t>
        </section>
        <section anchor="SunriseRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.5">
          <name slugifiedName="name-tmdb-sunrise-services-for-re">TMDB Sunrise Services for Registrars</name>
          <t indent="0" pn="section-5.2.5-1">
             The processes described in Sections <xref target="procDescSunriseSmdRevocList" format="counter" sectionFormat="of" derivedContent="5.2.3.1"/> and <xref target="procDescSunriseCrl" format="counter" sectionFormat="of" derivedContent="5.2.3.2"/> are also available for
             Registrars to optionally validate the SMDs received.
          </t>
          <t indent="0" pn="section-5.2.5-2"/>
        </section>
      </section>
      <section anchor="procDescTrCl" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-trademark-claims-period-2">Trademark Claims Period</name>
        <section anchor="procDescTrClReg" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1">
          <name slugifiedName="name-domain-registration">Domain Registration</name>
          <figure anchor="figIntTmcPeriod" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-domain-name-registration-dur">Domain Name Registration during the Trademark Claims Period</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.3.1-1.1">               
 .------------.   .-----------.                 .----------.   .------.
 | Registrant |   | Registrar |                 | Registry |   | TMDB |
 '------------'   '-----------'                 '----------'   '------'
        |     Request DN |                            |            |
        |   registration |                            |            |
        |---------------&gt;|     Check DN availability  |            |
        |                |---------------------------&gt;|            |
        |                | DN unavailable      .-------------.     |
        | DN unavailable |&lt;-------------------( DN available? )    |
        |&lt;---------------|                  no '-------------'     |
        |                | DN available               | yes        |
        |                |&lt;---------------------------|            |
        |                |         Request lookup key |            |
        |                |---------------------------&gt;|            |
        |                |.__________.           .---------.       |
        |                || CONTINUE |          /  Does DN  \      |
        |                || NORMALLY |&lt;--------(  match DNL  )     |
        |                |'----------'       no \  of PRM?  /      |
        |                |                       '---------'       |
        |                | Lookup key                  | yes       |
        |                |&lt;----------------------------'           |
        |                |                                         |
.-----. |                |                             Request TCN |
|ABORT| | Display        |----------------------------------------&gt;|
'-----' | Claims         | Return TCN                              |
 ^      | Notice         |&lt;----------------------------------------|
 | no   |&lt;---------------|                                         |
 |  .------.  yes        |                                         |
 '-(  Ack?  )-----------&gt;|   Register DN (with TCNID) |            |
    '------'             |---------------------------&gt;|            |
        | Registration   | Error         .----------------------.  |
        | error          |&lt;-------------( Validation successful? ) |
        |&lt;---------------|            no '----------------------'  |
        |                |                            | yes        |
        |                | DN registered              |            |
        | DN registered  |&lt;---------------------------|            |
        |&lt;---------------|                            |            |
</artwork>
          </figure>
          <t indent="0" pn="section-5.3.1-2"><xref target="figIntTmcPeriod" format="default" sectionFormat="of" derivedContent="Figure 7"/> represents a synchronous DN registration
            workflow (usually called first come first served).</t>
        </section>
        <section anchor="procDescTrClResRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2">
          <name slugifiedName="name-trademark-claims-domain-nam">Trademark Claims Domain Name Registration by Registries</name>
          <t indent="0" pn="section-5.3.2-1">
            During the Trademark Claims Period, Registries perform two main functions:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3.2-2">
            <li pn="section-5.3.2-2.1">Registries <bcp14>MUST</bcp14> provide Registrars (over the ry interface; see
            <xref target="ry" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>) the lookup key used
            to retrieve the TCNs for DNs that 
            match the DNL List.</li>
            <li pn="section-5.3.2-2.2">Registries <bcp14>MUST</bcp14> provide the lookup key only when queried
            about a specific DN.</li>
          </ul>
          <t indent="0" pn="section-5.3.2-3">In the following instances, a minimum set of checks are described:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3.2-4">
            <li pn="section-5.3.2-4.1">For each DN matching a DNL of a PRM, Registries <bcp14>MUST</bcp14>
            perform a minimum set of checks for verifying DN
            registrations during the Trademark Claims Period upon
            reception of a registration request over the ry
            interface (<xref target="ry" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>).  If any of these
            checks fail, the Registry <bcp14>MUST</bcp14> abort the registration.  
            Each of these checks <bcp14>MUST</bcp14> be performed
            before the DN is effectively allocated.</li>
            <li pn="section-5.3.2-4.2">In case of asynchronous registrations (e.g., auctions), 
            the minimum set of checks <bcp14>MAY</bcp14> be performed when creating 
            the intermediate object (e.g., a DN application)
            used for DN effective allocation. 
            If the minimum set of checks is performed when creating
            the intermediate object (e.g., a DN application), a 
            Registry <bcp14>MAY</bcp14> effectively allocate the DN without performing
            the minimum set of checks again.</li>
            <li pn="section-5.3.2-4.3">
              <t indent="0" pn="section-5.3.2-4.3.1">Performing the minimum set of checks, Registries <bcp14>MUST</bcp14>
              verify that:</t>
              <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.3.2-4.3.2">
		<li pn="section-5.3.2-4.3.2.1" derivedCounter="1.">
                  <t indent="0" pn="section-5.3.2-4.3.2.1.1">The TCNID (&lt;tmNotice:id&gt;), expiration datetime
		  (&lt;tmNotice:notAfter&gt;), and acceptance datetime of the TCN
                  have been received from the Registrar, along with the DN
                  registration.</t>
                  <t indent="0" pn="section-5.3.2-4.3.2.1.2">If the three elements mentioned above are not provided
                  by the Registrar for a DN matching a DNL of a PRM, but 
                  the DNL was inserted (or reinserted) for the first time
                  into the DNL List less than 24 hours ago, the registration <bcp14>MAY</bcp14>
                  continue without this data, and the tests listed
                  below are not required to be performed.</t>
                </li>
                <li pn="section-5.3.2-4.3.2.2" derivedCounter="2.">The TCN has not expired (according to the
                expiration datetime sent by the Registrar).</li>
                <li pn="section-5.3.2-4.3.2.3" derivedCounter="3.">The acceptance datetime is within the window of time defined by
                ICANN policy. In the gTLD round of 2012, Registrars verified that
                the acceptance datetime was less than or equal to 48 hours in the past,
                as there were no defined ICANN policies at that time. Implementers 
                should be aware that ICANN policy may define this value in the future.</li>
                <li pn="section-5.3.2-4.3.2.4" derivedCounter="4.">The TCN Checksum is computed using the leftmost DNL of the DN being
		effectively allocated, 
                the expiration datetime provided by the Registrar, and 
                the TMDB Notice Identifier extracted from the TCNID
                provided by the Registrar. Verify that the computed TCN Checksum matches the
		TCN Checksum present in the TCNID. For example, if the 
		DN "xn--mgbachtv.xn--mgbh0fb" is
                being effectively allocated, the leftmost DNL would be "xn--mgbachtv".</li>
              </ol>
            </li>
          </ul>
          <t indent="0" pn="section-5.3.2-5">
            These procedures apply to all DN registrations at
            the second level, as well as to all other levels
            subordinate to the TLD that the Registry accepts
            registrations for.
          </t>
        </section>
        <section anchor="claimsServicesRy" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3">
          <name slugifiedName="name-tmdb-trademark-claims-servi">TMDB Trademark Claims Services for Registries</name>
          <section anchor="procDescUpdateDnlList" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3.1">
            <name slugifiedName="name-domain-name-label-dnl-list">Domain Name Label (DNL) List</name>
            <t indent="0" pn="section-5.3.3.1-1"> 
              A new DNL List <bcp14>MUST</bcp14> be published by the TMDB twice a day,
              by 00:00:00 and 12:00:00 UTC.
            </t>
            <t indent="0" pn="section-5.3.3.1-2">
              Registries <bcp14>MUST</bcp14> refresh the latest version of the DNL
              List at least once every 24 hours.
            </t>
            <figure anchor="figIntDnlList" align="left" suppress-title="false" pn="figure-8">
              <name slugifiedName="name-update-of-the-dnl-list">Update of the DNL List</name>
              <artwork name="" type="" align="left" alt="" pn="section-5.3.3.1-3.1">                
    .----------.                        .------.
    | Registry |                        | TMDB |
    '----------'                        '------'
          |                                 |
 .----------------.                         |
 |  Periodically, |                         |
 |    at least    |                         |
 | every 24 hours |                         |
 '----------------'                         |
          |                                 |
          |--------------------------------&gt;|
          |  Download the latest DNL List   |
          |&lt;--------------------------------|
          |                                 |
          |                                 |
</artwork>
            </figure>
            <t indent="0" pn="section-5.3.3.1-4"><xref target="figIntDnlList" format="default" sectionFormat="of" derivedContent="Figure 8"/> depicts the process of downloading the latest DNL List initiated by the Registry.</t>
            <t indent="0" pn="section-5.3.3.1-5">
              Note: The DNL List will be the same regardless of the TLD.
              If a Backend Registry Operator manages the infrastructure
              of several TLDs, the Backend Registry Operator could
              refresh the DNL List once every 24 hours, and the 
              DNL List could be used for all the TLDs managed 
              by the Backend Registry Operator.
            </t>
          </section>
          <section anchor="procDescTrClNordn" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3.2">
            <name slugifiedName="name-notice-of-registered-domain-">Notice of Registered Domain Names (NORDN)</name>
            <t indent="0" pn="section-5.3.3.2-1">
              The NORDN process during the Trademark Claims Period is
              almost the same as during the Sunrise Period, as defined in
              <xref target="procDescSunriseNordn" format="default" sectionFormat="of" derivedContent="Section 5.2.3.3"/>;
	      the difference is that only registrations subject to a
              Trademark Claim (i.e., at registration time, the name
              appeared in the current DNL List downloaded by the Registry Operator) are 
              included in the LORDN.
            </t>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.4">
          <name slugifiedName="name-trademark-claims-domain-name">Trademark Claims Domain Name Registration by Registrars</name>
          <t indent="0" pn="section-5.3.4-1">
            For each DN matching a DNL of a PRM, Registrars <bcp14>MUST</bcp14>
            perform the following steps:
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.3.4-2">
	    <li pn="section-5.3.4-2.1" derivedCounter="1.">Use the lookup key received from the Registry 
            to obtain the TCN from the TMDB 
            using the dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>).
            Registrars <bcp14>MUST</bcp14> only query for the lookup key of a DN
            that is available for registration.</li>
            <li pn="section-5.3.4-2.2" derivedCounter="2.">Present the TCN to the Registrant, as
            described in Exhibit A of <xref target="RPM-Requirements" format="default" sectionFormat="of" derivedContent="RPM-Requirements"/>.</li>
            <li pn="section-5.3.4-2.3" derivedCounter="3.">Ask the Registrant for acknowledgement, i.e., the Registrant
            <bcp14>MUST</bcp14> consent with the TCN, before any
            further processing. (The transmission of a TCNID
            to the Registry over the ry
            interface (<xref target="ry" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>) implies that the
            Registrant has expressed their consent with the TCN.)</li>
            <li pn="section-5.3.4-2.4" derivedCounter="4.">
              <t indent="0" pn="section-5.3.4-2.4.1">Perform the minimum set of checks for verifying DN
              registrations.  If any of these checks fail, the
              Registrar <bcp14>MUST</bcp14> abort the DN registration. Each of
              these checks <bcp14>MUST</bcp14> be performed before the registration
              is sent to the Registry.
              Performing the minimum set of checks, Registrars <bcp14>MUST</bcp14> verify
              the following:</t>
              <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-5.3.4-2.4.2">
		<li pn="section-5.3.4-2.4.2.1" derivedCounter="a.">The datetime when the validation is done is within the TCN validity based on
		the &lt;tmNotice:notBefore&gt; and &lt;tmNotice:notAfter&gt; elements.</li>
                <li pn="section-5.3.4-2.4.2.2" derivedCounter="b.">The leftmost DNL of the DN  being
                effectively allocated matches the
                label (&lt;tmNotice:label&gt;) element in the TCN. 
                For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
                being effectively allocated, the leftmost DNL would be "xn--mgbachtv".</li>
                <li pn="section-5.3.4-2.4.2.3" derivedCounter="c.">The Registrant has acknowledged (expressed their consent
                with) the TCN.</li>
              </ol>
            </li>
            <li pn="section-5.3.4-2.5" derivedCounter="5.">Record the date and time when the registrant
            acknowledged the TCN.</li>
            <li pn="section-5.3.4-2.6" derivedCounter="6.">
              <t indent="0" pn="section-5.3.4-2.6.1">Send the registration to the Registry (via the ry interface; see
              <xref target="ry" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>) and include the following information:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3.4-2.6.2">
                <li pn="section-5.3.4-2.6.2.1">TCNID (&lt;tmNotice:id&gt;)</li>
                <li pn="section-5.3.4-2.6.2.2">Expiration date of the TCN
                (&lt;tmNotice:notAfter&gt;)</li>
                <li pn="section-5.3.4-2.6.2.3">Acceptance datetime of the TCN</li>
              </ul>
            </li>
          </ol>
          <t indent="0" pn="section-5.3.4-3">Currently, TCNs are generated twice a day by the TMDB. 
             The expiration date (&lt;tmNotice:notAfter&gt;) of each TCN <bcp14>MUST</bcp14>
               be set to a value defined by ICANN policy. In the gTLD round 
               of 2012, the TMDB set the expiration value to 48 hours into 
               the future, as there were no defined ICANN policies at that time.
               Implementers should be aware that ICANN policy may define 
               this value in the future.</t>
          <t indent="0" pn="section-5.3.4-4">Registrars <bcp14>SHOULD</bcp14> implement a cache of TCNs to
            minimize the number of queries sent to the TMDB. 
            A cached TCN <bcp14>MUST</bcp14> be removed from the cache after
            the expiration date of the TCN, as defined by 
            &lt;tmNotice:notAfter&gt;.
          </t>
          <t indent="0" pn="section-5.3.4-5">
            The TMDB <bcp14>MAY</bcp14> implement rate limiting as one of the protection
            mechanisms to mitigate the risk of performance degradation.
          </t>
        </section>
        <section anchor="claimsServicesRr" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.5">
          <name slugifiedName="name-tmdb-trademark-claims-servic">TMDB Trademark Claims Services for Registrars</name>
          <section anchor="cnisService" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.5.1">
            <name slugifiedName="name-claims-notice-information-s">Claims Notice Information Service (CNIS)</name>
            <t indent="0" pn="section-5.3.5.1-1">
              The TCNs are provided by the TMDB
              online and are fetched by the Registrar via the dr
              interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>). 
            </t>
            <t indent="0" pn="section-5.3.5.1-2">
              To get access to the
              TCNs, the Registrar needs the
              credentials provided by the TMDB (<xref target="procDescBootstrapCredentialsRr" format="default" sectionFormat="of" derivedContent="Section 5.1.2.1"/>) and the lookup
              key received from the Registry via the ry interface (<xref target="ry" format="default" sectionFormat="of" derivedContent="Section 4.3.5"/>). The dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>)
              uses HTTPS with Basic access authentication.
            </t>
            <t indent="0" pn="section-5.3.5.1-3">
              The dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>) <bcp14>MAY</bcp14> support up to 
              ten (10) concurrent connections from each Registrar.
            </t>
            <t indent="0" pn="section-5.3.5.1-4">
              The URL of the dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>) is:
            </t>
            <t indent="3" pn="section-5.3.5.1-5">https://&lt;tmdb-domain-name&gt;/cnis/&lt;lookupkey&gt;.xml
            </t>
            <t indent="0" pn="section-5.3.5.1-6">
              Note that the "lookupkey" may contain slash characters ("/"). 
              The slash character is part of the URL path and <bcp14>MUST NOT</bcp14>
              be escaped when requesting the TCN.
            </t>
            <t indent="0" pn="section-5.3.5.1-7">
              The TLS certificate (HTTPS) used on the dr interface
              (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>) <bcp14>MUST</bcp14> be signed by a well-know
              public CA. Registrars <bcp14>MUST</bcp14> perform the certification path validation
              described in <xref target="RFC5280" section="6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-6" derivedContent="RFC5280"/>. 
              Registrars will be authenticated
              in the dr interface using HTTP Basic access authentication.
              
              The dr interface (<xref target="dr" format="default" sectionFormat="of" derivedContent="Section 4.3.6"/>) <bcp14>MUST</bcp14> support HTTPS
              keep-alive and <bcp14>MUST</bcp14> maintain the connection for up to 30 minutes.
            </t>
          </section>
        </section>
      </section>
      <section anchor="procDescQLP" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-qualified-launch-program-ql">Qualified Launch Program (QLP) Period</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.4.1">
          <name slugifiedName="name-domain-registration-2">Domain Registration</name>
          <t indent="0" pn="section-5.4.1-1">
            During the <bcp14>OPTIONAL</bcp14> Qualified Launch Program (QLP) Period (see <xref target="QLP-Addendum" format="default" sectionFormat="of" derivedContent="QLP-Addendum"/>), effective allocations 
            of DNs to third parties could require that Registries and Registrars provide Sunrise 
            and/or Trademark Claims services.
            
            If required, Registries and Registrars <bcp14>MUST</bcp14> provide Sunrise and/or Trademark Claims services, as described in Sections 
            <xref target="procDescSunrise" format="counter" sectionFormat="of" derivedContent="5.2"/> and <xref target="procDescTrCl" format="counter" sectionFormat="of" derivedContent="5.3"/>.
          </t>
          <t indent="0" pn="section-5.4.1-2">
            The effective allocation scenarios are as follows:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4.1-3">
            <li pn="section-5.4.1-3.1">If the leftmost DNL of the DN being
            effectively allocated (QLP Name in this section) matches a DNL in the SURL and an SMD is provided, then
            Registries <bcp14>MUST</bcp14> provide Sunrise Services (see <xref target="procDescSunrise" format="default" sectionFormat="of" derivedContent="Section 5.2"/>), and
              the DN <bcp14>MUST</bcp14> be reported in a Sunrise LORDN file during the QLP Period. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
              being effectively allocated, the leftmost DNL would be "xn--mgbachtv".</li>
            <li pn="section-5.4.1-3.2">If the QLP Name matches a DNL in the SURL but does not match a DNL in the DNL List and an SMD is NOT provided (see Section
                2.2 of <xref target="QLP-Addendum" format="default" sectionFormat="of" derivedContent="QLP-Addendum"/>), then
                the DN <bcp14>MUST</bcp14> be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP Period.</li>
            <li pn="section-5.4.1-3.3">If the QLP Name matches a DNL in the SURL and also matches a DNL in the DNL List and an SMD is NOT provided (see Section
            2.2 of <xref target="QLP-Addendum" format="default" sectionFormat="of" derivedContent="QLP-Addendum"/>), then
                Registries <bcp14>MUST</bcp14> provide Trademark Claims services (see <xref target="procDescTrCl" format="default" sectionFormat="of" derivedContent="Section 5.3"/>), and
            the DN <bcp14>MUST</bcp14> be reported in a Trademark Claims LORDN file during the QLP Period.</li>
            <li pn="section-5.4.1-3.4">If the QLP Name matches a DNL in the DNL List but does not match a DNL in the SURL, then
            Registries <bcp14>MUST</bcp14> provide Trademark Claims services (see <xref target="procDescTrCl" format="default" sectionFormat="of" derivedContent="Section 5.3"/>), and
            the DN <bcp14>MUST</bcp14> be reported in a Trademark Claims LORDN file during the QLP Period.</li>
          </ul>
          <t indent="0" pn="section-5.4.1-4">
            The following table lists all the effective allocation scenarios during a QLP Period:
          </t>
          <table align="center" pn="table-1">
            <name slugifiedName="name-qlp-effective-allocation-sc">QLP Effective Allocation Scenarios</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">QLP Name Match in the SURL</th>
                <th align="left" colspan="1" rowspan="1">QLP Name Match in the DNL List</th>
                <th align="left" colspan="1" rowspan="1">SMD Was Provided by the Potential Registrant</th>
                <th align="left" colspan="1" rowspan="1">Registry <bcp14>MUST</bcp14> Provide Sunrise or Trademark Claims Services</th>
                <th align="left" colspan="1" rowspan="1">Registry <bcp14>MUST</bcp14> Report DN Registration in &lt;type&gt; LORDN File</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">Sunrise</td>
                <td align="left" colspan="1" rowspan="1">Sunrise</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">N</td>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">Sunrise</td>
                <td align="left" colspan="1" rowspan="1">Sunrise</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">N</td>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">--</td>
                <td align="left" colspan="1" rowspan="1">Trademark Claims</td>
                <td align="left" colspan="1" rowspan="1">Trademark Claims</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">N</td>
                <td align="left" colspan="1" rowspan="1">N</td>
                <td align="left" colspan="1" rowspan="1">--</td>
                <td align="left" colspan="1" rowspan="1">--</td>
                <td align="left" colspan="1" rowspan="1">--</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">N (see Section
                2.2 of <xref target="QLP-Addendum" format="default" sectionFormat="of" derivedContent="QLP-Addendum"/>)</td>
                <td align="left" colspan="1" rowspan="1">Trademark Claims</td>
                <td align="left" colspan="1" rowspan="1">Trademark Claims</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Y</td>
                <td align="left" colspan="1" rowspan="1">N</td>
                <td align="left" colspan="1" rowspan="1">N (see Section
                2.2 of <xref target="QLP-Addendum" format="default" sectionFormat="of" derivedContent="QLP-Addendum"/>)</td>
                <td align="left" colspan="1" rowspan="1">--</td>
                <td align="left" colspan="1" rowspan="1">Sunrise (using special SMD-id)</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-5.4.1-6">
            The TMDB <bcp14>MUST</bcp14> provide the following services to Registries during a QLP Period:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4.1-7">
            <li pn="section-5.4.1-7.1"> SMD Revocation List (see <xref target="procDescSunriseSmdRevocList" format="default" sectionFormat="of" derivedContent="Section 5.2.3.1"/>) </li>
            <li pn="section-5.4.1-7.2"> NORDN (see <xref target="procDescSunriseNordn" format="default" sectionFormat="of" derivedContent="Section 5.2.3.3"/>) </li>
            <li pn="section-5.4.1-7.3"> DNL List (see <xref target="procDescUpdateDnlList" format="default" sectionFormat="of" derivedContent="Section 5.3.3.1"/>) </li>
            <li pn="section-5.4.1-7.4"> Sunrise List (SURL) (see <xref target="procDescUpdatesurlList" format="default" sectionFormat="of" derivedContent="Section 5.4.2.1"/>)</li>
          </ul>
          <t indent="0" pn="section-5.4.1-8">
            The TMDB <bcp14>MUST</bcp14> provide the following services to Registrars during a QLP Period:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4.1-9">
            <li pn="section-5.4.1-9.1"> SMD Revocation List (see <xref target="procDescSunriseSmdRevocList" format="default" sectionFormat="of" derivedContent="Section 5.2.3.1"/>) </li>
            <li pn="section-5.4.1-9.2"> CNIS (see <xref target="cnisService" format="default" sectionFormat="of" derivedContent="Section 5.3.5.1"/>) </li>
          </ul>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.4.2">
          <name slugifiedName="name-tmdb-qlp-services-for-regis">TMDB QLP Services for Registries</name>
          <section anchor="procDescUpdatesurlList" numbered="true" toc="include" removeInRFC="false" pn="section-5.4.2.1">
            <name slugifiedName="name-sunrise-list-surl">Sunrise List (SURL)</name>
            <t indent="0" pn="section-5.4.2.1-1"> A new SURL <bcp14>MUST</bcp14> be published by the TMDB twice a day, by 00:00:00 and 12:00:00
              UTC. </t>
            <t indent="0" pn="section-5.4.2.1-2"> Registries offering the <bcp14>OPTIONAL</bcp14> QLP Period <bcp14>MUST</bcp14> refresh the latest version of the SURL at least once every 24
            hours. </t>
            <figure anchor="figIntsurlList" align="left" suppress-title="false" pn="figure-9">
              <name slugifiedName="name-update-of-the-surl">Update of the SURL</name>
              <artwork name="" type="" align="left" alt="" pn="section-5.4.2.1-3.1">                  
    .----------.                       .------.
    | Registry |                       | TMDB |
    '----------'                       '------'
          |                                |
 .----------------.                        |
 |  Periodically, |                        |
 |    at least    |                        |
 | every 24 hours |                        |
 '----------------'                        |
          |                                |
          |-------------------------------&gt;|
          |    Download the latest SURL    |
          |&lt;-------------------------------|
          |                                |
          |                                |
</artwork>
            </figure>
            <t indent="0" pn="section-5.4.2.1-4"><xref target="figIntsurlList" format="default" sectionFormat="of" derivedContent="Figure 9"/> depicts the process of downloading the latest SURL initiated by the Registry.</t>
            <t indent="0" pn="section-5.4.2.1-5"> Note: The SURL will be the same regardless of the TLD. If a Backend Registry
              Operator manages the infrastructure of several TLDs, the Backend Registry Operator could
              refresh the SURL once every 24 hours, and the SURL could be used for all the
              TLDs managed by the Backend Registry Operator. </t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="dataFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-data-format-descriptions">Data Format Descriptions</name>
      <section anchor="dnlListFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-domain-name-label-dnl-list-2">Domain Name Label (DNL) List</name>
        <t indent="0" pn="section-6.1-1">
          This section defines the format of the list containing every
          DNL that matches a Pre-Registered Mark
          (PRM). The list is maintained by the TMDB and downloaded by
          Registries in regular intervals (see <xref target="procDescUpdateDnlList" format="default" sectionFormat="of" derivedContent="Section 5.3.3.1"/>). The Registries use the
          DNL List during the Trademark Claims Period to check whether
          a requested DN matches a DNL of a PRM.
        </t>
        <t indent="0" pn="section-6.1-2">
	  The DNL List contains all the DNLs covered by a PRM present in the TMDB at the
	  datetime that the DNL List is generated.
        </t>
        <t indent="0" pn="section-6.1-3">
          The DNL List is contained in a CSV-formatted file that has the
          following structure:
          
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-4">
          <li pn="section-6.1-4.1">
            <t indent="0" pn="section-6.1-4.1.1">first line: &lt;version&gt;,&lt;DNL List creation datetime&gt;</t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.1-4.1.2">
              <li pn="section-6.1-4.1.2.1">
                <t indent="0" pn="section-6.1-4.1.2.1.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-4.1.2.1.2">
                  <li pn="section-6.1-4.1.2.1.2.1">&lt;version&gt;: version of the file. This field <bcp14>MUST</bcp14> be 1.</li>
                  <li pn="section-6.1-4.1.2.1.2.2">&lt;DNL List creation datetime&gt;: date and time in UTC that the DNL List was created.</li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-6.1-4.2">
            <t indent="0" pn="section-6.1-4.2.1">second line: a header line, as specified in <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/></t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.1-4.2.2">
              <li pn="section-6.1-4.2.2.1">With the header names as follows:</li>
              <li pn="section-6.1-4.2.2.2">DNL,lookup-key,insertion-datetime</li>
            </ul>
          </li>
          <li pn="section-6.1-4.3">
            <t indent="0" pn="section-6.1-4.3.1">One or more lines with: &lt;DNL&gt;,&lt;lookup key&gt;,&lt;DNL insertion datetime&gt;</t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.1-4.3.2">
              <li pn="section-6.1-4.3.2.1">
                <t indent="0" pn="section-6.1-4.3.2.1.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-4.3.2.1.2">
                  <li pn="section-6.1-4.3.2.1.2.1">&lt;DNL&gt;: a Domain Name Label covered by a PRM.</li>
                  <li pn="section-6.1-4.3.2.1.2.2">
                    <t indent="0" pn="section-6.1-4.3.2.1.2.2.1">&lt;lookup key&gt;: lookup key that the Registry <bcp14>MUST</bcp14> provide to the Registrar. The lookup key has
                      the following format: &lt;YYYY&gt;&lt;MM&gt;&lt;DD&gt;&lt;vv&gt;/&lt;X&gt;/&lt;X&gt;/&lt;X&gt;/&lt;Random bits&gt;&lt;Sequential number&gt;, where:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-4.3.2.1.2.2.2">
                      <li pn="section-6.1-4.3.2.1.2.2.2.1">YYYY: year that the TCN was generated.</li>
                      <li pn="section-6.1-4.3.2.1.2.2.2.2">MM: zero-padded month that the TCN was generated.</li>
                      <li pn="section-6.1-4.3.2.1.2.2.2.3">DD: zero-padded day that the TCN was generated.</li>
                      <li pn="section-6.1-4.3.2.1.2.2.2.4">vv: version of the TCN; possible values are 00 and 01.</li>
                      <li pn="section-6.1-4.3.2.1.2.2.2.5">X: one hex character. This is the first, second, and third hex character of encoding the 
                          &lt;Random bits&gt; in base16, as specified in <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/>.</li>
                      <li pn="section-6.1-4.3.2.1.2.2.2.6">Random bits: 144 random bits encoded in base64url, as specified in <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/>.</li>
                      <li pn="section-6.1-4.3.2.1.2.2.2.7">Sequential number: zero-padded natural number in the range 0000000001 to 2147483647.</li>
                    </ul>
                  </li>
                  <li pn="section-6.1-4.3.2.1.2.3">
                      &lt;DNL insertion datetime&gt;: datetime in UTC that the DNL was first inserted into the DNL List.
                      The possible two values of time for inserting a DNL to the DNL List are 00:00:00 and 12:00:00 UTC.
                    </li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-5">Example of a DNL list:</t>
        <figure align="left" suppress-title="false" pn="figure-10">
          <name slugifiedName="name-example-dnl-list">Example DNL List</name>
          <sourcecode type="" markers="false" pn="section-6.1-6.1">
1,2012-08-16T00:00:00.0Z
DNL,lookup-key,insertion-datetime
example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\
   2010-07-14T00:00:00.0Z
another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\
   2012-08-16T00:00:00.0Z
anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\
   2011-08-16T12:00:00.0Z
</sourcecode>
        </figure>
        <t indent="0" pn="section-6.1-7">
          To provide authentication and integrity protection, the DNL
          List will be PGP <xref target="RFC4880" format="default" sectionFormat="of" derivedContent="RFC4880"/> signed by the TMDB (see <xref target="procDescBootstrapPgpKeyRy" format="default" sectionFormat="of" derivedContent="Section 5.1.1.4"/>).  The PGP signature of the 
          DNL List can be found in the similar URI but with extension .sig, as shown below.
        </t>
        <t indent="0" pn="section-6.1-8">
          The URLs of the dy interface (<xref target="dy" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>) are:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-9">
          <li pn="section-6.1-9.1">
              https://&lt;tmdb-domain-name&gt;/dnl/dnl-latest.csv
            </li>
          <li pn="section-6.1-9.2">
              https://&lt;tmdb-domain-name&gt;/dnl/dnl-latest.sig
            </li>
        </ul>
      </section>
      <section anchor="revocationlistFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-smd-revocation-list-2">SMD Revocation List</name>
        <t indent="0" pn="section-6.2-1">
          This section defines the format of the list of SMDs that have
          been revoked.  The list is maintained by the TMDB and
          downloaded by Registries (and optionally by Registrars) in
          regular intervals (see <xref target="procDescSunriseSmdRevocList" format="default" sectionFormat="of" derivedContent="Section 5.2.3.1"/>). The SMD Revocation
          List is used during the Sunrise Period to validate SMDs
          received. The SMD Revocation List has a similar function as
          CRLs used in PKI <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.
        </t>
        <t indent="0" pn="section-6.2-2">
          The SMD Revocation List contains all the revoked SMDs present in
          the TMDB at the datetime it is generated.
        </t>
        <t indent="0" pn="section-6.2-3">
          The SMD Revocation List is contained in a CSV-formatted file that has
          the following structure:
          
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4">
          <li pn="section-6.2-4.1">
            <t indent="0" pn="section-6.2-4.1.1">
              first line: &lt;version&gt;,&lt;SMD Revocation List creation datetime&gt;           
            </t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.2-4.1.2">
              <li pn="section-6.2-4.1.2.1">
                <t indent="0" pn="section-6.2-4.1.2.1.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4.1.2.1.2">
                  <li pn="section-6.2-4.1.2.1.2.1">&lt;version&gt;: version of the file. This field <bcp14>MUST</bcp14> be 1.</li>
                  <li pn="section-6.2-4.1.2.1.2.2">&lt;SMD Revocation List creation datetime&gt;: datetime in UTC that the SMD Revocation List was created.</li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-6.2-4.2">
            <t indent="0" pn="section-6.2-4.2.1">second line: a header line, as specified in <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/></t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.2-4.2.2">
              <li pn="section-6.2-4.2.2.1">With the header names as follows:</li>
              <li pn="section-6.2-4.2.2.2">smd-id,insertion-datetime</li>
            </ul>
          </li>
          <li pn="section-6.2-4.3">
            <t indent="0" pn="section-6.2-4.3.1">One or more lines with: &lt;smd-id&gt;,&lt;revoked SMD datetime&gt;</t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.2-4.3.2">
              <li pn="section-6.2-4.3.2.1">
                <t indent="0" pn="section-6.2-4.3.2.1.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4.3.2.1.2">
                  <li pn="section-6.2-4.3.2.1.2.1">&lt;smd-id&gt;: identifier of the SMD that was revoked.</li>
                  <li pn="section-6.2-4.3.2.1.2.2">&lt;revoked SMD datetime&gt;: revocation datetime in UTC of the SMD. 
                  The possible two values of time for inserting an SMD to the SMD Revocation List
                  are 00:00:00 and 12:00:00 UTC.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-6.2-5">
          To provide integrity protection, the SMD Revocation List is
          PGP signed by the TMDB (see <xref target="procDescBootstrapPgpKeyRy" format="default" sectionFormat="of" derivedContent="Section 5.1.1.4"/>).  The SMD Revocation
          List  is provided by the TMDB with extension .csv. The PGP signature of the 
          SMD Revocation List can be found in the similar URI but with extension .sig, as shown below.
        </t>
        <t indent="0" pn="section-6.2-6">
          The URLs of the sr interface (<xref target="sr" format="default" sectionFormat="of" derivedContent="Section 4.3.12"/>) and
          sy interface (<xref target="sy" format="default" sectionFormat="of" derivedContent="Section 4.3.11"/>) are:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-7">
          <li pn="section-6.2-7.1">https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.csv</li>
          <li pn="section-6.2-7.2">https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.sig</li>
        </ul>
        <t indent="0" pn="section-6.2-8">Example of an SMD Revocation List:</t>
        <figure align="left" suppress-title="false" pn="figure-11">
          <name slugifiedName="name-example-smd-revocation-list">Example SMD Revocation List</name>
          <sourcecode type="" markers="false" pn="section-6.2-9.1">
1,2012-08-16T00:00:00.0Z
smd-id,insertion-datetime
2-2,2012-08-15T00:00:00.0Z
3-2,2012-08-15T00:00:00.0Z
1-2,2012-08-15T00:00:00.0Z
</sourcecode>
        </figure>
      </section>
      <section anchor="lordnFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-list-of-registered-domain-n">List of Registered Domain Names (LORDN) File</name>
        <t indent="0" pn="section-6.3-1">
          This section defines the format of the List of Registered Domain Names (LORDN),
	  which is maintained by each Registry
          and uploaded at least daily to the TMDB. Every time there is a DN matching a
          DNL of a PRM, said DN is added to the LORDN, along with
          further information related to its registration.
        </t>
        <t indent="0" pn="section-6.3-2">
          The URIs of the yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>) used to
          upload the LORDN file are:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-3">
          <li pn="section-6.3-3.1">
            <t indent="0" pn="section-6.3-3.1.1">Sunrise LORDN file: </t>
            <t indent="0" pn="section-6.3-3.1.2">https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise</t>
          </li>
          <li pn="section-6.3-3.2">
            <t indent="0" pn="section-6.3-3.2.1">Trademark Claims LORDN file: </t>
            <t indent="0" pn="section-6.3-3.2.2">https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims</t>
          </li>
        </ul>
        <t indent="0" pn="section-6.3-4">
          During a QLP Period, Registries <bcp14>MAY</bcp14> be required to upload Sunrise or Trademark Claims LORDN files.
          The URIs of the yd interface used to upload LORDN files during a QLP Period are:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-5">
          <li pn="section-6.3-5.1">
            <t indent="0" pn="section-6.3-5.1.1">Sunrise LORDN file (during QLP Period): </t>
            <t indent="0" pn="section-6.3-5.1.2">https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/qlp</t>
          </li>
          <li pn="section-6.3-5.2">
            <t indent="0" pn="section-6.3-5.2.1">Trademark Claims LORDN file (during a QLP Period):</t>
            <t indent="0" pn="section-6.3-5.2.2">https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp</t>
          </li>
        </ul>
        <t indent="0" pn="section-6.3-6">
          The yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>) returns the following HTTP status codes after an HTTP POST request method is
          received:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-7">
          <li pn="section-6.3-7.1">
            <t indent="0" pn="section-6.3-7.1.1">The interface provides an HTTP/202 status code if the interface was
            able to receive the LORDN file and the syntax of the LORDN file is correct.</t>
            <t indent="0" pn="section-6.3-7.1.2">The interface provides the LORDN Transaction Identifier in the HTTP Entity-body that would be used
                by the Registry to download the LORDN Log file. The LORDN Transaction Identifier is a zero-padded natural number
                 in the range 0000000000000000001 to 9223372036854775807.
            </t>
            <t indent="0" pn="section-6.3-7.1.3">The TMDB uses the &lt;LORDN creation datetime&gt; element of the LORDN file
                as a unique client-side identifier. If a LORDN file with the same &lt;LORDN creation datetime&gt; of
                a previously sent LORDN file is received by the TMDB, the LORDN Transaction Identifier 
                of the previously sent LORDN file <bcp14>MUST</bcp14> be provided to the Registry. The TMDB <bcp14>MUST</bcp14> ignore the DN Lines present in the
                LORDN file if a LORDN file with the same &lt;LORDN creation datetime&gt; was previously sent.
            </t>
            <t indent="0" pn="section-6.3-7.1.4">The HTTP Location header field contains
              the URI where the LORDN Log file could be retrieved later, for example:</t>
            <ul spacing="normal" empty="true" bare="false" indent="3" pn="section-6.3-7.1.5">
              <li pn="section-6.3-7.1.5.1">
                <t indent="0" pn="section-6.3-7.1.5.1.1">202 Accepted</t>
                <t indent="0" pn="section-6.3-7.1.5.1.2">Location: https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/0000000000000000001/result</t>
              </li>
            </ul>
          </li>
        </ul>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-8">
          <li pn="section-6.3-8.1"> The interface provides an HTTP/400 if the request is incorrect or 
          the syntax of the LORDN file is incorrect.
          The TMDB <bcp14>MUST</bcp14> return a human-readable message in the HTTP Entity-body
          regarding the incorrect syntax of the LORDN file.</li>
          <li pn="section-6.3-8.2">The interface provides an HTTP/401 status code if the credentials
          provided do not authorize the Registry Operator to upload a LORDN file.</li>
          <li pn="section-6.3-8.3">The TMDB <bcp14>MUST</bcp14> return an HTTP/404 status code when trying to upload a LORDN file using 
            the https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/qlp or 
            https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp interface outside of a QLP Period plus 26 hours.
          </li>
          <li pn="section-6.3-8.4"> The interface provides an HTTP/500 status code if the system is
            experiencing a general failure.</li>
        </ul>
        <t indent="0" pn="section-6.3-9">
          For example, to upload the Sunrise LORDN file for TLD "example", the URI would be:
        </t>
        <t indent="3" pn="section-6.3-10">https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise</t>
        <t indent="0" pn="section-6.3-11">The LORDN is contained in a CSV-formatted file that has the
        following structure:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12">
          <li pn="section-6.3-12.1">
            <t indent="0" pn="section-6.3-12.1.1">For Sunrise Period: </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12.1.2">
              <li pn="section-6.3-12.1.2.1">
                <t indent="0" pn="section-6.3-12.1.2.1.1">first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&lt;Number of DN Lines&gt;</t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-12.1.2.1.2">
                  <li pn="section-6.3-12.1.2.1.2.1">
                    <t indent="0" pn="section-6.3-12.1.2.1.2.1.1">Where:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12.1.2.1.2.1.2">
                      <li pn="section-6.3-12.1.2.1.2.1.2.1">&lt;version&gt;: version of the file. This field <bcp14>MUST</bcp14> be 1.</li>
                      <li pn="section-6.3-12.1.2.1.2.1.2.2">&lt;LORDN creation datetime&gt;: date and time in UTC that the LORDN was created.</li>
                      <li pn="section-6.3-12.1.2.1.2.1.2.3">&lt;Number of DN Lines&gt;: number of DN Lines present in the LORDN file.</li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-6.3-12.1.2.2">
                <t indent="0" pn="section-6.3-12.1.2.2.1">second line: a header line, as specified in <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/></t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-12.1.2.2.2">
                  <li pn="section-6.3-12.1.2.2.2.1">With the header names as follows:</li>
                  <li pn="section-6.3-12.1.2.2.2.2">roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime</li>
                </ul>
              </li>
              <li pn="section-6.3-12.1.2.3">
                <t indent="0" pn="section-6.3-12.1.2.3.1">One or more lines with: &lt;roid&gt;,&lt;DN registered&gt;,&lt;SMD-id&gt;,&lt;IANA Registrar id&gt;,&lt;datetime of registration&gt;,&lt;datetime of application creation&gt;
                </t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-12.1.2.3.2">
                  <li pn="section-6.3-12.1.2.3.2.1">
                    <t indent="0" pn="section-6.3-12.1.2.3.2.1.1">Where:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12.1.2.3.2.1.2">
                      <li pn="section-6.3-12.1.2.3.2.1.2.1">&lt;roid&gt;: DN Repository Object IDentifier (DNROID) in the SRS.</li>
                      <li pn="section-6.3-12.1.2.3.2.1.2.2">&lt;DN registered&gt;: DN that was effectively allocated. For IDNs, the A-label form
                      is used.</li>
                      <li pn="section-6.3-12.1.2.3.2.1.2.3">&lt;SMD-id&gt;: SMD ID used for registration.</li>
                      <li pn="section-6.3-12.1.2.3.2.1.2.4">&lt;IANA Registrar ID&gt;: IANA Registrar ID.</li>
                      <li pn="section-6.3-12.1.2.3.2.1.2.5">&lt;datetime of registration&gt;: date and time in UTC that the domain was effectively allocated.</li>
                      <li pn="section-6.3-12.1.2.3.2.1.2.6">
                        <bcp14>OPTIONAL</bcp14> &lt;datetime of application creation&gt;: date and time in UTC that 
                      the application was created. The &lt;datetime of application creation&gt; <bcp14>MUST</bcp14> be provided
                      in case of a DN effective allocation based on an asynchronous registration
                      (e.g., when using auctions).</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
            <t indent="0" pn="section-6.3-12.1.3">Example of a Sunrise LORDN file:</t>
            <figure align="left" suppress-title="false" pn="figure-12">
              <name slugifiedName="name-example-sunrise-lordn-file">Example Sunrise LORDN File</name>
              <sourcecode type="" markers="false" pn="section-6.3-12.1.4.1">
1,2012-08-16T00:00:00.0Z,3
roid,domain-name,SMD-id,registrar-id,registration-datetime,\
   application-datetime
SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\
   2012-07-15T00:50:00.0Z
EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z
HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z
</sourcecode>
            </figure>
          </li>
          <li pn="section-6.3-12.2">
            <t indent="0" pn="section-6.3-12.2.1">For the Trademark Claims Period:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12.2.2">
              <li pn="section-6.3-12.2.2.1">
                <t indent="0" pn="section-6.3-12.2.2.1.1">first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&lt;Number of DN Lines&gt;</t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-12.2.2.1.2">
                  <li pn="section-6.3-12.2.2.1.2.1">
                    <t indent="0" pn="section-6.3-12.2.2.1.2.1.1">Where:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12.2.2.1.2.1.2">
                      <li pn="section-6.3-12.2.2.1.2.1.2.1">&lt;version&gt;: version of the file. This field <bcp14>MUST</bcp14> be 1.</li>
                      <li pn="section-6.3-12.2.2.1.2.1.2.2">&lt;LORDN creation datetime&gt;: date and time in UTC that the LORDN was created.</li>
                      <li pn="section-6.3-12.2.2.1.2.1.2.3">&lt;Number of DN Lines&gt;: number of DN Lines present in the LORDN file.</li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-6.3-12.2.2.2">
                <t indent="0" pn="section-6.3-12.2.2.2.1">second line: a header line, as specified in <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/></t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-12.2.2.2.2">
                  <li pn="section-6.3-12.2.2.2.2.1">With the header names as follows:</li>
                  <li pn="section-6.3-12.2.2.2.2.2">roid,domain-name,notice-id,registrar-id,registration-datetime,ack-datetime,application-datetime</li>
                </ul>
              </li>
              <li pn="section-6.3-12.2.2.3">
                <t indent="0" pn="section-6.3-12.2.2.3.1">One or more lines with: &lt;roid&gt;,&lt;DN registered&gt;,&lt;TCNID&gt;,&lt;IANA Registrar id&gt;,&lt;datetime of registration&gt;,&lt;datetime of acceptance of the TCN&gt;,&lt;datetime of application creation&gt;</t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-12.2.2.3.2">
                  <li pn="section-6.3-12.2.2.3.2.1">
                    <t indent="0" pn="section-6.3-12.2.2.3.2.1.1">Where:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-12.2.2.3.2.1.2">
                      <li pn="section-6.3-12.2.2.3.2.1.2.1">&lt;roid&gt;: DNROID in the SRS.</li>
                      <li pn="section-6.3-12.2.2.3.2.1.2.2">&lt;DN registered&gt;: DN that was effectively allocated. For IDNs, the A-label form
                      is used.</li>
                      <li pn="section-6.3-12.2.2.3.2.1.2.3">&lt;TCNID&gt;: Trademark Claims Notice Identifier, as specified in &lt;tmNotice:id&gt;.</li>
                      <li pn="section-6.3-12.2.2.3.2.1.2.4">&lt;IANA Registrar ID&gt;: IANA Registrar ID.</li>
                      <li pn="section-6.3-12.2.2.3.2.1.2.5">&lt;datetime of registration&gt;: date and time in UTC that the domain was effectively allocated.</li>
                      <li pn="section-6.3-12.2.2.3.2.1.2.6">&lt;datetime of acceptance of the TCN&gt;: date and time in UTC that the TCN was acknowledged.</li>
                      <li pn="section-6.3-12.2.2.3.2.1.2.7">
                        <bcp14>OPTIONAL</bcp14> &lt;datetime of application creation&gt;: date and time in UTC that 
                      the application was created. The &lt;datetime of application creation&gt; <bcp14>MUST</bcp14> be provided
                      in case of a DN effective allocation based on an asynchronous registration
                      (e.g., when using auctions).</li>
                    </ul>
                  </li>
                  <li pn="section-6.3-12.2.2.3.2.2"> For a DN matching a DNL of a PRM at the moment of registration, created
                    without the TCNID, expiration datetime,
                    and acceptance datetime because DNL was inserted (or reinserted) for the first time
                    into a DNL List less than 24 hours ago, the string "recent-dnl-insertion" <bcp14>MAY</bcp14> be 
                    specified in &lt;TCNID&gt; and &lt;datetime of acceptance of the TCN&gt;.</li>
                </ul>
              </li>
            </ul>
            <t indent="0" pn="section-6.3-12.2.3">Example of a Trademark Claims LORDN file:</t>
            <figure align="left" suppress-title="false" pn="figure-13">
              <name slugifiedName="name-example-trademark-claims-lo">Example Trademark Claims LORDN File</name>
              <artwork name="" type="" align="left" alt="" pn="section-6.3-12.2.4.1">             
1,2012-08-16T00:00:00.0Z,3
roid,domain-name,notice-id,registrar-id,registration-datetime,\
    ack-datetime,application-datetime
SH8013-REP,example1.gtld,a76716ed9223352036854775808,\
    9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z
EK77-REP,example2.gtld,a7b786ed9223372036856775808,\
    9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z
HB800-REP,example3.gtld,recent-dnl-insertion,\ 
    9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion
</artwork>
            </figure>
          </li>
        </ul>
        <section anchor="lordnLogFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.1">
          <name slugifiedName="name-lordn-log-file">LORDN Log File</name>
          <t indent="0" pn="section-6.3.1-1">
            After reception of the LORDN file, the TMDB verifies its
            content for syntactical and semantic correctness. 
            The output of the LORDN file verification is retrieved using the 
            yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>). 
          </t>
          <t indent="0" pn="section-6.3.1-2">
            The URIs of the yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>) used to
            retrieve the LORDN Log file are:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3.1-3">
            <li pn="section-6.3.1-3.1">
              <t indent="0" pn="section-6.3.1-3.1.1">Sunrise LORDN Log file:</t>
              <t indent="0" pn="section-6.3.1-3.1.2">https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/&lt;lordn-transaction-identifier&gt;/result</t>
            </li>
            <li pn="section-6.3.1-3.2">
              <t indent="0" pn="section-6.3.1-3.2.1">Trademark Claims LORDN Log file: </t>
              <t indent="0" pn="section-6.3.1-3.2.2">https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/&lt;lordn-transaction-identifier&gt;/result</t>
            </li>
          </ul>
          <t indent="0" pn="section-6.3.1-4">
            A Registry Operator <bcp14>MUST NOT</bcp14> send more than one request per minute per TLD to download
            a LORDN Log file.
          </t>
          <t indent="0" pn="section-6.3.1-5">
            The yd interface (<xref target="yd" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>) returns the following HTTP status codes after an HTTP GET request method is
            received:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3.1-6">
            <li pn="section-6.3.1-6.1">The interface provides an HTTP/200 status code if the interface was
                able to provide the LORDN Log file.
                The LORDN Log file is contained in the HTTP Entity-body.</li>
            <li pn="section-6.3.1-6.2">The interface provides an HTTP/204 status code if the LORDN Transaction
                Identifier is correct but the server has not finalized processing the LORDN
                file.</li>
            <li pn="section-6.3.1-6.3">The interface provides an HTTP/400 status code if the request is incorrect.</li>
            <li pn="section-6.3.1-6.4"> The interface provides an HTTP/401 status code if the credentials
                provided do not authorize the Registry Operator to download the LORDN Log file.</li>
            <li pn="section-6.3.1-6.5">The interface provides an HTTP/404 status code if the LORDN Transaction
                Identifier is incorrect.</li>
            <li pn="section-6.3.1-6.6">The interface provides an HTTP/500 status code if the system is
                experiencing a general failure.</li>
          </ul>
          <t indent="0" pn="section-6.3.1-7">
            For example, to obtain the LORDN Log file in case of a Sunrise LORDN file with LORDN Transaction Identifier 0000000000000000001
            and TLD "example", the URI would be: 
          </t>
          <t indent="3" pn="section-6.3.1-8">https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/0000000000000000001/result
          </t>
          <t indent="0" pn="section-6.3.1-9">
            The LORDN Log file is contained in a CSV-formatted file that has the
            following structure:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3.1-10">
            <li pn="section-6.3.1-10.1">
              <t indent="0" pn="section-6.3.1-10.1.1">first line: &lt;version&gt;,&lt;LORDN Log creation datetime&gt;,&lt;LORDN file creation datetime&gt;,&lt;LORDN Log Identifier&gt;,&lt;Status flag&gt;,&lt;Warning flag&gt;,&lt;Number of DN Lines&gt;</t>
              <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3.1-10.1.2">
                <li pn="section-6.3.1-10.1.2.1">
                  <t indent="0" pn="section-6.3.1-10.1.2.1.1">Where:</t>
                  <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3.1-10.1.2.1.2">
                    <li pn="section-6.3.1-10.1.2.1.2.1">&lt;version&gt;: version of the file. This field <bcp14>MUST</bcp14> be 1.
                  </li>
                    <li pn="section-6.3.1-10.1.2.1.2.2">&lt;LORDN Log creation datetime&gt;: date and time in UTC that the LORDN Log was created.</li>
                    <li pn="section-6.3.1-10.1.2.1.2.3">&lt;LORDN file creation datetime&gt;: date and time in UTC of creation for the LORDN file that
                    this log file is referring to.</li>
                    <li pn="section-6.3.1-10.1.2.1.2.4">&lt;LORDN Log Identifier&gt;: unique identifier of the LORDN Log provided by the TMDB. This identifier
                    could be used by the Registry Operator to unequivocally identify the LORDN Log. The identified will be
                    a string of a maximum length of 60 characters from the base64 alphabet.</li>
                    <li pn="section-6.3.1-10.1.2.1.2.5">&lt;Status flag&gt;: whether the LORDN file has been accepted for processing by the TMDB.
                    Possible values are "accepted" or "rejected".</li>
                    <li pn="section-6.3.1-10.1.2.1.2.6">&lt;Warning flag&gt;: whether the LORDN Log has any warning result codes. Possible values are 
                    "no-warnings" or "warnings-present".</li>
                    <li pn="section-6.3.1-10.1.2.1.2.7">&lt;Number of DN Lines&gt;: number of DN effective allocations processed in the LORDN file.</li>
                  </ul>
                </li>
                <li pn="section-6.3.1-10.1.2.2">A Registry Operator is not required to process a LORDN Log with &lt;Status flag&gt;="accepted"
                  and &lt;Warning flag&gt;="no-warnings".</li>
              </ul>
            </li>
            <li pn="section-6.3.1-10.2">
              <t indent="0" pn="section-6.3.1-10.2.1">second line: a header line, as specified in <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/> </t>
              <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3.1-10.2.2">
                <li pn="section-6.3.1-10.2.2.1">With the header names as follows:</li>
                <li pn="section-6.3.1-10.2.2.2">roid,result-code</li>
              </ul>
            </li>
            <li pn="section-6.3.1-10.3">
              <t indent="0" pn="section-6.3.1-10.3.1">One or more lines with: &lt;roid&gt;,&lt;result code&gt; </t>
              <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3.1-10.3.2">
                <li pn="section-6.3.1-10.3.2.1">
                  <t indent="0" pn="section-6.3.1-10.3.2.1.1">Where:</t>
                  <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3.1-10.3.2.1.2">
                    <li pn="section-6.3.1-10.3.2.1.2.1">&lt;roid&gt;: DNROID in the SRS.</li>
                    <li pn="section-6.3.1-10.3.2.1.2.2">&lt;result code&gt;: result code, as described in <xref target="lordnRetCodes" format="default" sectionFormat="of" derivedContent="Section 6.3.1.1"/>.</li>
                  </ul>
                </li>
              </ul>
            </li>
          </ul>
          <t indent="0" pn="section-6.3.1-11">Example of a LORDN Log file:</t>
          <figure align="left" suppress-title="false" pn="figure-14">
            <name slugifiedName="name-example-lordn-log-file">Example LORDN Log File</name>
            <sourcecode type="" markers="false" pn="section-6.3.1-12.1">
1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\
   0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\
   accepted,no-warnings,1
roid,result-code
SH8013-REP,2000
</sourcecode>
          </figure>
          <section anchor="lordnRetCodes" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.1.1">
            <name slugifiedName="name-lordn-log-result-codes">LORDN Log Result Codes</name>
            <t indent="0" pn="section-6.3.1.1-1">
                The classes
                of result codes (rc) are listed below. The classes in square
                brackets are not used at this time but may come into use
                at some later stage. The
                first two digits of a result code denote the result code
                class, which defines the outcome at the TMDB:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3.1.1-2">
              <li pn="section-6.3.1.1-2.1">ok: Success. The DN Line is accepted by the TMDB.</li>
              <li pn="section-6.3.1.1-2.2">warn: A warning is issued. The DN Line  is accepted by the TMDB.</li>
              <li pn="section-6.3.1.1-2.3">err: An error is issued. The LORDN file is rejected by the TMDB.</li>
            </ul>
            <t indent="0" pn="section-6.3.1.1-3">
              In cases where a DN line is processed and the error result code is 45xx or
	      46xx, the LORDN file <bcp14>MUST</bcp14> be rejected by the
	      TMDB. If the LORDN file is rejected, DN Lines that are syntactically
                valid will be reported with a 2001 result code. A 2001 result code means that the DN Line is
                syntactically valid; however, the DN Line was not processed because the LORDN file was rejected.
                All DNs reported in a rejected LORDN file <bcp14>MUST</bcp14> be reported again by the Registry because none of the DN Lines present
                in the LORDN file have been processed by the TMDB.
            </t>
            <t indent="0" pn="section-6.3.1.1-4">LORDN Log Result Code Classes:</t>
            <table align="center" pn="table-2">
              <name slugifiedName="name-lordn-log-result-code-class">LORDN Log Result Code Classes</name>
              <thead>
                <tr>
                  <th align="left" colspan="1" rowspan="1">Code</th>
                  <th align="left" colspan="1" rowspan="1">Class</th>
                  <th align="left" colspan="1" rowspan="1">Outcome</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left" colspan="1" rowspan="1">20xx</td>
                  <td align="left" colspan="1" rowspan="1">Success</td>
                  <td align="left" colspan="1" rowspan="1">ok</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">35xx</td>
                  <td align="left" colspan="1" rowspan="1">[ DN Line syntax warning ]</td>
                  <td align="left" colspan="1" rowspan="1">warn</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">36xx</td>
                  <td align="left" colspan="1" rowspan="1">DN Line semantic warning</td>
                  <td align="left" colspan="1" rowspan="1">warn</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">45xx</td>
                  <td align="left" colspan="1" rowspan="1">DN Line syntax error</td>
                  <td align="left" colspan="1" rowspan="1">err</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">46xx</td>
                  <td align="left" colspan="1" rowspan="1">DN Line semantic error</td>
                  <td align="left" colspan="1" rowspan="1">err</td>
                </tr>
              </tbody>
            </table>
            <t indent="0" pn="section-6.3.1.1-6">
                In <xref target="LORDN-codes" format="default" sectionFormat="of" derivedContent="Table 3"/>, the LORDN Log result codes used by the TMDB
                are described.
            </t>
            <table anchor="LORDN-codes" align="center" pn="table-3">
              <name slugifiedName="name-lordn-log-result-codes-2">LORDN Log Result Codes</name>
              <thead>
                <tr>
                  <th align="left" colspan="1" rowspan="1">rc</th>
                  <th align="left" colspan="1" rowspan="1">Short Description / Long Description</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td rowspan="2" align="left" colspan="1">2000</td>
                  <td align="left" colspan="1" rowspan="1">OK</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The DN Line is successfully processed.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">2001</td>
                  <td align="left" colspan="1" rowspan="1">OK but not processed</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The DN Line is syntactically correct but was not processed 
	because the LORDN file was rejected.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3601</td>
                  <td align="left" colspan="1" rowspan="1">TCN Acceptance Date after Registration Date</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The TCN Acceptance Date in the DN Line is newer than the registration date.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3602</td>
                  <td align="left" colspan="1" rowspan="1">Duplicate DN Line</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">This DN Line is an exact duplicate of another DN Line in the same 
	file; the DN Line is ignored.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3603</td>
                  <td align="left" colspan="1" rowspan="1">DNROID Notified Earlier</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The same DNROID has been notified earlier; the DN Line is ignored.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3604</td>
                  <td align="left" colspan="1" rowspan="1">TCN Checksum invalid</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">Based on the DN effective allocation, the TCNID, and the 
	expiration date of the linked TCN, the TCN Checksum is
	invalid.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3605</td>
                  <td align="left" colspan="1" rowspan="1">TCN Expired</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The TCN was already expired (based on the &lt;tmNotice:notAfter&gt; 
	field of the TCN) at the datetime of acknowledgement.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3606</td>
                  <td align="left" colspan="1" rowspan="1">Wrong TCNID used</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The TCNID used for the registration does not match
	the related DN.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3609</td>
                  <td align="left" colspan="1" rowspan="1">Invalid SMD used</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The SMD used for registration was not valid at the moment of
	registration based on the &lt;smd:notBefore&gt; and &lt;smd:notAfter&gt;
	elements.
	In case of an asynchronous registration, this refers to the
	&lt;datetime of application creation&gt;.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3610</td>
                  <td align="left" colspan="1" rowspan="1">DN reported outside of the time window</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The DN was reported outside of the required 26-hour
	reporting window.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3611</td>
                  <td align="left" colspan="1" rowspan="1">DN does not match the labels in SMD</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The DN does not match the labels included in the SMD.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3612</td>
                  <td align="left" colspan="1" rowspan="1">SMDID does not exist</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The Signed Mark Data Identifier (SMDID) has never existed 
            in the central repository.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3613</td>
                  <td align="left" colspan="1" rowspan="1">SMD was revoked when used</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The SMD used for registration was revoked more than
	24 hours ago of the &lt;datetime of registration&gt;.
	In case of an asynchronous registration, 
	the &lt;datetime of application creation&gt; is used when
	validating the DN Line.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3614</td>
                  <td align="left" colspan="1" rowspan="1">TCNID does not exist</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The Trademark Claims Notice Identifier (TCNID) has never existed
            in the central repository.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3615</td>
                  <td align="left" colspan="1" rowspan="1">Recent-dnl-insertion outside of the time window</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The DN registration is reported as a recent-dnl-insertion,
	but the (re) insertion into the DNL occurred more than
	24 hours ago.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3616</td>
                  <td align="left" colspan="1" rowspan="1">Registration Date of DN in Claims before the end of the Sunrise Period</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The registration date of the DN is before the end of 
	the Sunrise Period, and the DN was reported in a 
	Trademark Claims LORDN file.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3617</td>
                  <td align="left" colspan="1" rowspan="1">Registrar has not been approved by the TMDB</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The Registrar ID in the DN Line has not completed Trademark Claims
	integration testing with the TMDB.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3618</td>
                  <td align="left" colspan="1" rowspan="1">Registration Date of DN in QLP LORDN file out of the QLP Period</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The registration date of the DN in a QLP LORDN file is outside 
	of the QLP Period.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">3619</td>
                  <td align="left" colspan="1" rowspan="1">TCN was not valid</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The TCN was not valid (based on the &lt;tmNotice:notBefore&gt; 
	field of the TCN) at the datetime of acknowledgement.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4501</td>
                  <td align="left" colspan="1" rowspan="1">Syntax Error in DN Line</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">There is a syntax error in the DN Line.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4601</td>
                  <td align="left" colspan="1" rowspan="1">Invalid TLD used</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The TLD in the DN Line does not match what is expected for
	this LORDN.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4602</td>
                  <td align="left" colspan="1" rowspan="1">Registrar ID Invalid</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The Registrar ID in the DN Line is not a valid ICANN-Accredited
	Registrar.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4603</td>
                  <td align="left" colspan="1" rowspan="1">Registration Date in the future</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The &lt;datetime of registration&gt; in the DN Line is in the
	future.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4606</td>
                  <td align="left" colspan="1" rowspan="1">TLD not in Sunrise or Trademark Claims Periods</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The &lt;datetime of registration&gt; was reported when the TLD was
	not in Sunrise or Trademark Claims Periods.
	In case of an asynchronous registration, 
	the &lt;datetime of application creation&gt; is used when
	validating the DN Line.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4607</td>
                  <td align="left" colspan="1" rowspan="1">Application Date in the future</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The &lt;datetime of application creation&gt; in the DN Line is in the
	future.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4608</td>
                  <td align="left" colspan="1" rowspan="1">Application Date is later than Registration Date</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The &lt;datetime of application creation&gt; in the DN Line is later
	than the &lt;datetime of registration&gt;.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4609</td>
                  <td align="left" colspan="1" rowspan="1">TCNID wrong syntax</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The syntax of the TCNID is invalid.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4610</td>
                  <td align="left" colspan="1" rowspan="1">TCN Acceptance Date is in the future</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The &lt;datetime of acceptance of the TCN&gt; is in the future.</td>
                </tr>
                <tr>
                  <td rowspan="2" align="left" colspan="1">4611</td>
                  <td align="left" colspan="1" rowspan="1">Label has never existed in the TMDB</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">The label in the registered DN has never existed in the TMDB.</td>
                </tr>
              </tbody>
            </table>
          </section>
        </section>
      </section>
      <section anchor="SmdFileFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-signed-mark-data-smd-file">Signed Mark Data (SMD) File</name>
        <t indent="0" pn="section-6.4-1">
          This section defines the format of the SMD
          File. After a successful registration of a mark, the TMV returns
          an SMD File to the TMH. The SMD File can then be used for
          registration of one or more DNs covered by the PRM during the
          Sunrise Period of a TLD.
        </t>
        <t indent="0" pn="section-6.4-2">
          Two encapsulation boundaries are defined for delimiting the
          encapsulated base64-encoded SMD: "-----BEGIN ENCODED
          SMD-----" and "-----END ENCODED SMD-----". Only data inside
          the encapsulation boundaries <bcp14>MUST</bcp14> be used by Registries and
          Registrars for validation purposes, i.e., any data outside
          these boundaries as well as the boundaries themselves <bcp14>MUST</bcp14>
          be ignored for validation purposes.
        </t>
        <t indent="0" pn="section-6.4-3">
          The structure of the SMD File is as follows. All the elements are <bcp14>REQUIRED</bcp14> and <bcp14>MUST</bcp14> appear in the specified order.
        </t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.4-4">
	  <li pn="section-6.4-4.1" derivedCounter="1.">Marks: &lt;marks&gt; </li>
          <li pn="section-6.4-4.2" derivedCounter="2.">smdID: &lt;SMD-ID&gt;</li>
          <li pn="section-6.4-4.3" derivedCounter="3.">U-labels: &lt;comma separated list of U-label or NR-LDH labels (see <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>)&gt;</li>
          <li pn="section-6.4-4.4" derivedCounter="4.">notBefore: &lt;begin validity&gt;</li>
          <li pn="section-6.4-4.5" derivedCounter="5.">notAfter: &lt;end validity&gt;  </li>
          <li pn="section-6.4-4.6" derivedCounter="6.">-----BEGIN ENCODED SMD-----</li>
          <li pn="section-6.4-4.7" derivedCounter="7.">&lt;encoded SMD (see <xref target="RFC7848" format="default" sectionFormat="of" derivedContent="RFC7848"/>)&gt;</li>
          <li pn="section-6.4-4.8" derivedCounter="8.">-----END ENCODED SMD-----</li>
        </ol>
        <t indent="0" pn="section-6.4-5">Example of an SMD file:</t>
        <figure align="left" suppress-title="false" pn="figure-15">
          <name slugifiedName="name-example-smd-file">Example SMD File</name>
          <sourcecode type="" markers="false" pn="section-6.4-6.1">
Marks: Example One
smdID: 1-2
U-labels: example-one, exampleone
notBefore: 2011-08-16 09:00
notAfter: 2012-08-16 09:00
-----BEGIN ENCODED SMD-----
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu
ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN
... (base64 data elided for brevity) ...
dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
-----END ENCODED SMD-----
</sourcecode>
        </figure>
      </section>
      <section anchor="TCN" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-trademark-claims-notice-tcn">Trademark Claims Notice (TCN)</name>
        <t indent="0" pn="section-6.5-1">
          The TMDB <bcp14>MUST</bcp14> provide the TCN to Registrars in XML format,
          as specified below.
        </t>
        <t indent="0" pn="section-6.5-2">
          The enclosing element &lt;tmNotice:notice&gt; describes the Trademark Notice 
          to a given label.
        </t>
        <t indent="0" pn="section-6.5-3">
          The child  elements of the &lt;tmNotice:notice&gt; element include:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4">
          <li pn="section-6.5-4.1">
            <t indent="0" pn="section-6.5-4.1.1">A &lt;tmNotice:id&gt; element that contains the unique identifier of
            the Trademark Notice. This element contains the TCNID.</t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.5-4.1.2">
              <li pn="section-6.5-4.1.2.1">The TCNID is a string concatenation of a TCN Checksum
                and the TMDB Notice Identifier.
                The first 8 characters of the TCNID is a
                TCN Checksum. The rest is the TMDB Notice Identifier, which is a zero-padded natural number
                in the range of 0000000000000000001 to 9223372036854775807.</li>
              <li pn="section-6.5-4.1.2.2">
                <t indent="0" pn="section-6.5-4.1.2.2.1">Example of a TCNID:</t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.5-4.1.2.2.2">
                  <li pn="section-6.5-4.1.2.2.2.1">370d0b7c9223372036854775807.</li>
                </ul>
              </li>
              <li pn="section-6.5-4.1.2.3">
                <t indent="0" pn="section-6.5-4.1.2.3.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.1.2.3.2">
                  <li pn="section-6.5-4.1.2.3.2.1">TCN Checksum=370d0b7c</li>
                  <li pn="section-6.5-4.1.2.3.2.2">TMDB Notice Identifier=9223372036854775807</li>
                </ul>
              </li>
              <li pn="section-6.5-4.1.2.4">The TCN Checksum is an 8-character-long base16-encoded output 
                of computing the CRC32 of the string concatenation of:
                label + unix_timestamp(&lt;tmNotice:notAfter&gt;) + TMDB Notice Identifier.</li>
              <li pn="section-6.5-4.1.2.5">
                <t indent="0" pn="section-6.5-4.1.2.5.1">The TMDB <bcp14>MUST</bcp14> use the Unix time conversion of the &lt;tmNotice:notAfter&gt; in UTC 
                to calculate the TCN Checksum.
                Unix time is defined as the number of seconds that have elapsed since 
                1970-01-01T00:00:00Z, not counting leap seconds.
                For example, the conversion of 2010-08-16T09:00:00.0Z to Unix time is:</t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.5-4.1.2.5.2">
                  <li pn="section-6.5-4.1.2.5.2.1">unix_time(2010-08-16T09:00:00.0Z)=1281949200</li>
                </ul>
              </li>
              <li pn="section-6.5-4.1.2.6">The TMDB uses the &lt;tmNotice:label&gt; and &lt;tmNotice:notAfter&gt; 
                elements from the TCN along with the TMDB Notice Identifier 
                to compute the TCN Checksum.</li>
              <li pn="section-6.5-4.1.2.7">A Registry <bcp14>MUST</bcp14> use the leftmost DNL of the DN being
                effectively allocated, the expiration datetime of the TCN (provided by the Registrar),
                and the TMDB Notice Identifier extracted from the TCNID (provided by the Registrar)
                to compute the TCN Checksum. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
                being effectively allocated, the leftmost DNL would be "xn--mgbachtv".</li>
              <li pn="section-6.5-4.1.2.8">
                <t indent="0" pn="section-6.5-4.1.2.8.1">An example computation of the TCN Checksum is:</t>
                <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.5-4.1.2.8.2">
                  <li pn="section-6.5-4.1.2.8.2.1">
                    CRC32(example-one12819492009223372036854775807)=370d0b7c
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-6.5-4.2">A &lt;tmNotice:notBefore&gt; element that contains the start of the valid date and time of the TCN. </li>
          <li pn="section-6.5-4.3">A &lt;tmNotice:notAfter&gt; element that contains the expiration date and time of the TCN.</li>
          <li pn="section-6.5-4.4">A &lt;tmNotice:label&gt; element that contains the DNL covered by a PRM.</li>
          <li pn="section-6.5-4.5">
            <t indent="0" pn="section-6.5-4.5.1">One or more &lt;tmNotice:claim&gt; elements that contain the Trademark Claims.
            The &lt;tmNotice:claim&gt; element contains the following 
            child elements:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2">
              <li pn="section-6.5-4.5.2.1">A &lt;tmNotice:markName&gt; element that contains the mark text string.</li>
              <li pn="section-6.5-4.5.2.2">
                <t indent="0" pn="section-6.5-4.5.2.2.1">One or more &lt;tmNotice:holder&gt; elements that contain the information of the holder of the mark. An "entitlement" attribute
                is used to identify the entitlement of the holder; possible values are: owner, assignee, or licensee. 
                The child elements of &lt;tmNotice:holder&gt; include:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.2.2">
                  <li pn="section-6.5-4.5.2.2.2.1">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:name&gt; element that contains the name of the holder. &lt;tmNotice:name&gt; <bcp14>MUST</bcp14> be specified if
                    &lt;tmNotice:org&gt; is not specified.</li>
                  <li pn="section-6.5-4.5.2.2.2.2">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:org&gt; element that contains the name of the organization holder of the mark. &lt;tmNotice:org&gt; <bcp14>MUST</bcp14> be specified if
                    &lt;tmNotice:name&gt; is not specified.</li>
                  <li pn="section-6.5-4.5.2.2.2.3">
                    <t indent="0" pn="section-6.5-4.5.2.2.2.3.1">A &lt;tmNotice:addr&gt; element that contains the address information of the holder 
                    of a mark. &lt;tmNotice:addr&gt; contains the following child elements:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.2.2.3.2">
                      <li pn="section-6.5-4.5.2.2.2.3.2.1">One, two, or three <bcp14>OPTIONAL</bcp14> &lt;tmNotice:street&gt; elements that contain the organization's street address.</li>
                      <li pn="section-6.5-4.5.2.2.2.3.2.2">A &lt;tmNotice:city&gt; element that contains the organization's city.</li>
                      <li pn="section-6.5-4.5.2.2.2.3.2.3">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:sp&gt; element that contains the organization's state or province.</li>
                      <li pn="section-6.5-4.5.2.2.2.3.2.4">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:pc&gt; element that contains the organization's postal code.</li>
                      <li pn="section-6.5-4.5.2.2.2.3.2.5">A &lt;tmNotice:cc&gt; element that contains the organization's country code.
                        This a two-character code from <xref target="ISO3166-2" format="default" sectionFormat="of" derivedContent="ISO3166-2"/>.</li>
                    </ul>
                  </li>
                  <li pn="section-6.5-4.5.2.2.2.4">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:voice&gt; element that contains the organization's voice telephone number.</li>
                  <li pn="section-6.5-4.5.2.2.2.5">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:fax&gt; element that contains the organization's facsimile telephone number.</li>
                  <li pn="section-6.5-4.5.2.2.2.6">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:email&gt; element that contains the email address of the holder.</li>
                </ul>
              </li>
              <li pn="section-6.5-4.5.2.3">
                <t indent="0" pn="section-6.5-4.5.2.3.1">Zero or more <bcp14>OPTIONAL</bcp14> &lt;tmNotice:contact&gt; elements that contain the information of the representative of the mark registration. 
                A "type" attribute is used to identify the type of contact; possible values are: owner, agent, or third party.
                The child elements of &lt;tmNotice:contact&gt; include:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.3.2">
                  <li pn="section-6.5-4.5.2.3.2.1">A &lt;tmNotice:name&gt; element that contains the name of the responsible person.</li>
                  <li pn="section-6.5-4.5.2.3.2.2">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:org&gt; element that contains the name of the organization of the contact.</li>
                  <li pn="section-6.5-4.5.2.3.2.3">
                    <t indent="0" pn="section-6.5-4.5.2.3.2.3.1">A &lt;tmNotice:addr&gt; element that contains the address information of the contact. 
                    &lt;tmNotice:addr&gt; contains the following child elements:</t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.3.2.3.2">
                      <li pn="section-6.5-4.5.2.3.2.3.2.1">One, two, or three <bcp14>OPTIONAL</bcp14> &lt;tmNotice:street&gt; elements that contain the contact's street address.</li>
                      <li pn="section-6.5-4.5.2.3.2.3.2.2">A &lt;tmNotice:city&gt; element that contains the contact's city.</li>
                      <li pn="section-6.5-4.5.2.3.2.3.2.3">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:sp&gt; element that contains the contact's state or province.</li>
                      <li pn="section-6.5-4.5.2.3.2.3.2.4">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:pc&gt; element that contains the contact's postal code.</li>
                      <li pn="section-6.5-4.5.2.3.2.3.2.5">A &lt;tmNotice:cc&gt; element that contains the contact's country code.
                        This a two-character code from <xref target="ISO3166-2" format="default" sectionFormat="of" derivedContent="ISO3166-2"/>.</li>
                    </ul>
                  </li>
                  <li pn="section-6.5-4.5.2.3.2.4">A &lt;tmNotice:voice&gt; element that contains the contact's voice telephone number.</li>
                  <li pn="section-6.5-4.5.2.3.2.5">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:fax&gt; element that contains the contact's facsimile telephone number.</li>
                  <li pn="section-6.5-4.5.2.3.2.6">A &lt;tmNotice:email&gt; element that contains the contact's email address.</li>
                </ul>
              </li>
              <li pn="section-6.5-4.5.2.4">A &lt;tmNotice:jurDesc&gt; element that contains the name (in English) of the jurisdiction where the mark is protected.
                A jurCC attribute contains the two-character code of the jurisdiction where the mark was registered.
                This is a two-character code from <xref target="WIPO.ST3" format="default" sectionFormat="of" derivedContent="WIPO.ST3"/>.</li>
              <li pn="section-6.5-4.5.2.5">Zero or more <bcp14>OPTIONAL</bcp14> &lt;tmNotice:classDesc&gt; elements that contain the description (in English) of 
                the Nice Classification, as defined in <xref target="WIPO-NICE-CLASSES" format="default" sectionFormat="of" derivedContent="WIPO-NICE-CLASSES"/>.
                A classNum attribute contains the class number.</li>
              <li pn="section-6.5-4.5.2.6">A &lt;tmNotice:goodsAndServices&gt; element that contains the full description of the goods and services mentioned 
                in the mark registration document.</li>
              <li pn="section-6.5-4.5.2.7">
                <t indent="0" pn="section-6.5-4.5.2.7.1">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:notExactMatch&gt; element signals that the claim notice was added to the TCN 
                based on rules (e.g., <xref target="Claims50" format="default" sectionFormat="of" derivedContent="Claims50"/>) other than exact match (defined in <xref target="MatchingRules" format="default" sectionFormat="of" derivedContent="MatchingRules"/>). 
                &lt;tmNotice:notExactMatch&gt; contains one or more of the following:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.7.2">
                  <li pn="section-6.5-4.5.2.7.2.1">
                    <t indent="0" pn="section-6.5-4.5.2.7.2.1.1">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:udrp&gt; element that signals that the claim notice was added because 
                    of a previously abused name included in a Uniform Domain-Name Dispute-Resolution Policy (UDRP) case. &lt;tmNotice:udrp&gt; contains: </t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.7.2.1.2">
                      <li pn="section-6.5-4.5.2.7.2.1.2.1">A &lt;tmNotice:caseNo&gt; element that contains the UDRP case number used to validate
                        the previously abused name.</li>
                      <li pn="section-6.5-4.5.2.7.2.1.2.2">A &lt;tmNotice:udrpProvider&gt; element that contains the name of the UDRP provider.</li>
                    </ul>
                  </li>
                  <li pn="section-6.5-4.5.2.7.2.2">
                    <t indent="0" pn="section-6.5-4.5.2.7.2.2.1">An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:court&gt; element that signals that the claim notice was added because 
                    of a previously abused name included in a court's resolution. &lt;tmNotice:court&gt; contains:  </t>
                    <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4.5.2.7.2.2.2">
                      <li pn="section-6.5-4.5.2.7.2.2.2.1">A &lt;tmNotice:refNum&gt; element that contains the reference number of the court's resolution
                        used to validate the previously abused name.</li>
                      <li pn="section-6.5-4.5.2.7.2.2.2.2">A &lt;tmNotice:cc&gt; element that contains the two-character code from <xref target="ISO3166-2" format="default" sectionFormat="of" derivedContent="ISO3166-2"/> 
                        of the jurisdiction of the court.</li>
                      <li pn="section-6.5-4.5.2.7.2.2.2.3">A &lt;tmNotice:courtName&gt; element that contains the name of the court.</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-6.5-5">Example of a &lt;tmNotice:notice&gt; object:</t>
        <figure align="left" suppress-title="false" pn="figure-16">
          <name slugifiedName="name-example-tmnoticenotice-obje">Example &lt;tmNotice:notice&gt; Object</name>
          <sourcecode type="xml" markers="false" pn="section-6.5-6.1">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;tmNotice:notice
 xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0"&gt;
 &lt;tmNotice:id&gt;370d0b7c9223372036854775807&lt;/tmNotice:id&gt;
 &lt;tmNotice:notBefore&gt;2010-08-14T09:00:00.0Z&lt;/tmNotice:notBefore&gt;
 &lt;tmNotice:notAfter&gt;2010-08-16T09:00:00.0Z&lt;/tmNotice:notAfter&gt;
 &lt;tmNotice:label&gt;example-one&lt;/tmNotice:label&gt;
 &lt;tmNotice:claim&gt;
  &lt;tmNotice:markName&gt;Example One&lt;/tmNotice:markName&gt;
  &lt;tmNotice:holder entitlement="owner"&gt;
   &lt;tmNotice:org&gt;Example Inc.&lt;/tmNotice:org&gt;
   &lt;tmNotice:addr&gt;
    &lt;tmNotice:street&gt;123 Example Dr.&lt;/tmNotice:street&gt;
    &lt;tmNotice:street&gt;Suite 100&lt;/tmNotice:street&gt;
    &lt;tmNotice:city&gt;Reston&lt;/tmNotice:city&gt;
    &lt;tmNotice:sp&gt;VA&lt;/tmNotice:sp&gt;
    &lt;tmNotice:pc&gt;20190&lt;/tmNotice:pc&gt;
    &lt;tmNotice:cc&gt;US&lt;/tmNotice:cc&gt;
   &lt;/tmNotice:addr&gt;
  &lt;/tmNotice:holder&gt;
  &lt;tmNotice:contact type="owner"&gt;
   &lt;tmNotice:name&gt;Joe Doe&lt;/tmNotice:name&gt;
   &lt;tmNotice:org&gt;Example Inc.&lt;/tmNotice:org&gt;
   &lt;tmNotice:addr&gt;
    &lt;tmNotice:street&gt;123 Example Dr.&lt;/tmNotice:street&gt;
    &lt;tmNotice:street&gt;Suite 100&lt;/tmNotice:street&gt;
    &lt;tmNotice:city&gt;Reston&lt;/tmNotice:city&gt;
    &lt;tmNotice:sp&gt;VA&lt;/tmNotice:sp&gt;
    &lt;tmNotice:pc&gt;20190&lt;/tmNotice:pc&gt;
    &lt;tmNotice:cc&gt;US&lt;/tmNotice:cc&gt;
   &lt;/tmNotice:addr&gt;
   &lt;tmNotice:voice x="4321"&gt;+1.7035555555&lt;/tmNotice:voice&gt;
   &lt;tmNotice:email&gt;jdoe@example.com&lt;/tmNotice:email&gt;
  &lt;/tmNotice:contact&gt;
  &lt;tmNotice:jurDesc jurCC="US"&gt;USA&lt;/tmNotice:jurDesc&gt;
  &lt;tmNotice:classDesc classNum="35"&gt;
  Advertising; business management; business administration.
 &lt;/tmNotice:classDesc&gt;
  &lt;tmNotice:classDesc classNum="36"&gt;
  Insurance; financial affairs; monetary affairs; real estate.
 &lt;/tmNotice:classDesc&gt;
  &lt;tmNotice:goodsAndServices&gt;
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 &lt;/tmNotice:goodsAndServices&gt;
 &lt;/tmNotice:claim&gt;
 &lt;tmNotice:claim&gt;
  &lt;tmNotice:markName&gt;Example-One&lt;/tmNotice:markName&gt;
  &lt;tmNotice:holder entitlement="owner"&gt;
   &lt;tmNotice:org&gt;Example S.A. de C.V.&lt;/tmNotice:org&gt;
   &lt;tmNotice:addr&gt;
    &lt;tmNotice:street&gt;Calle conocida #343&lt;/tmNotice:street&gt;
    &lt;tmNotice:city&gt;Conocida&lt;/tmNotice:city&gt;
    &lt;tmNotice:sp&gt;SP&lt;/tmNotice:sp&gt;
    &lt;tmNotice:pc&gt;82140&lt;/tmNotice:pc&gt;
    &lt;tmNotice:cc&gt;BR&lt;/tmNotice:cc&gt;
   &lt;/tmNotice:addr&gt;
  &lt;/tmNotice:holder&gt;
  &lt;tmNotice:jurDesc jurCC="BR"&gt;BRAZIL&lt;/tmNotice:jurDesc&gt;
  &lt;tmNotice:goodsAndServices&gt;
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 &lt;/tmNotice:goodsAndServices&gt;
 &lt;/tmNotice:claim&gt;
 &lt;tmNotice:claim&gt;
  &lt;tmNotice:markName&gt;One&lt;/tmNotice:markName&gt;
  &lt;tmNotice:holder entitlement="owner"&gt;
   &lt;tmNotice:org&gt;One Corporation&lt;/tmNotice:org&gt;
   &lt;tmNotice:addr&gt;
    &lt;tmNotice:street&gt;Otra calle&lt;/tmNotice:street&gt;
    &lt;tmNotice:city&gt;Otra ciudad&lt;/tmNotice:city&gt;
    &lt;tmNotice:sp&gt;OT&lt;/tmNotice:sp&gt;
    &lt;tmNotice:pc&gt;383742&lt;/tmNotice:pc&gt;
    &lt;tmNotice:cc&gt;CR&lt;/tmNotice:cc&gt;
   &lt;/tmNotice:addr&gt;
  &lt;/tmNotice:holder&gt;
  &lt;tmNotice:jurDesc jurCC="CR"&gt;COSTA RICA&lt;/tmNotice:jurDesc&gt;
  &lt;tmNotice:goodsAndServices&gt;
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 &lt;/tmNotice:goodsAndServices&gt;
  &lt;tmNotice:notExactMatch&gt;
   &lt;tmNotice:court&gt;
    &lt;tmNotice:refNum&gt;234235&lt;/tmNotice:refNum&gt;
    &lt;tmNotice:cc&gt;CR&lt;/tmNotice:cc&gt;
    &lt;tmNotice:courtName&gt;Supreme Court of Spain&lt;/tmNotice:courtName&gt;
   &lt;/tmNotice:court&gt;
  &lt;/tmNotice:notExactMatch&gt;
 &lt;/tmNotice:claim&gt;
 &lt;tmNotice:claim&gt;
  &lt;tmNotice:markName&gt;One Inc&lt;/tmNotice:markName&gt;
  &lt;tmNotice:holder entitlement="owner"&gt;
   &lt;tmNotice:org&gt;One SA de CV&lt;/tmNotice:org&gt;
   &lt;tmNotice:addr&gt;
    &lt;tmNotice:street&gt;La calle&lt;/tmNotice:street&gt;
    &lt;tmNotice:city&gt;La ciudad&lt;/tmNotice:city&gt;
    &lt;tmNotice:sp&gt;CD&lt;/tmNotice:sp&gt;
    &lt;tmNotice:pc&gt;34323&lt;/tmNotice:pc&gt;
    &lt;tmNotice:cc&gt;AR&lt;/tmNotice:cc&gt;
   &lt;/tmNotice:addr&gt;
  &lt;/tmNotice:holder&gt;
  &lt;tmNotice:jurDesc jurCC="AR"&gt;ARGENTINA&lt;/tmNotice:jurDesc&gt;
  &lt;tmNotice:goodsAndServices&gt;
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 &lt;/tmNotice:goodsAndServices&gt;
  &lt;tmNotice:notExactMatch&gt;
   &lt;tmNotice:udrp&gt;
    &lt;tmNotice:caseNo&gt;D2003-0499&lt;/tmNotice:caseNo&gt;
    &lt;tmNotice:udrpProvider&gt;WIPO&lt;/tmNotice:udrpProvider&gt;
   &lt;/tmNotice:udrp&gt;
  &lt;/tmNotice:notExactMatch&gt;
 &lt;/tmNotice:claim&gt;
&lt;/tmNotice:notice&gt;
</sourcecode>
        </figure>
        <t indent="0" pn="section-6.5-7">
          For the formal syntax of the TCN, please
          refer to <xref target="FormalSyntaxClaimsNotice" format="default" sectionFormat="of" derivedContent="Section 7.1"/>.
        </t>
      </section>
      <section anchor="surlListFormat" numbered="true" toc="include" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-sunrise-list-surl-2">Sunrise List (SURL)</name>
        <t indent="0" pn="section-6.6-1">
          This section defines the format of the list containing every
          DNL that matches a PRM eligible for Sunrise. 
          The list is maintained by the TMDB and downloaded by
          Registries in regular intervals (see <xref target="procDescUpdatesurlList" format="default" sectionFormat="of" derivedContent="Section 5.4.2.1"/>). The Registries use the
          Sunrise List during the QLP Period to check whether
          a requested DN matches a DNL of a PRM eligible for Sunrise.
        </t>
        <t indent="0" pn="section-6.6-2">
          The Sunrise List contains all the DNLs covered by a PRM eligible for Sunrise that are present in the TMDB at the datetime it is generated.
        </t>
        <t indent="0" pn="section-6.6-3">
          The Sunrise List is contained in a CSV-formatted file that has the
          following structure:
          
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6-4">
          <li pn="section-6.6-4.1">
            <t indent="0" pn="section-6.6-4.1.1">first line: &lt;version&gt;,&lt;Sunrise List creation datetime&gt;</t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.6-4.1.2">
              <li pn="section-6.6-4.1.2.1">
                <t indent="0" pn="section-6.6-4.1.2.1.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6-4.1.2.1.2">
                  <li pn="section-6.6-4.1.2.1.2.1">&lt;version&gt;: version of the file. This field <bcp14>MUST</bcp14> be 1.</li>
                  <li pn="section-6.6-4.1.2.1.2.2">&lt;Sunrise List creation datetime&gt;: date and time in UTC that the Sunrise List was created.</li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-6.6-4.2">
            <t indent="0" pn="section-6.6-4.2.1">second line: a header line, as specified in <xref target="RFC4180" format="default" sectionFormat="of" derivedContent="RFC4180"/></t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.6-4.2.2">
              <li pn="section-6.6-4.2.2.1">With the header names as follows:</li>
              <li pn="section-6.6-4.2.2.2">DNL,insertion-datetime</li>
            </ul>
          </li>
          <li pn="section-6.6-4.3">
            <t indent="0" pn="section-6.6-4.3.1">One or more lines with: &lt;DNL&gt;,&lt;DNL insertion datetime&gt;</t>
            <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.6-4.3.2">
              <li pn="section-6.6-4.3.2.1">
                <t indent="0" pn="section-6.6-4.3.2.1.1">Where:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6-4.3.2.1.2">
                  <li pn="section-6.6-4.3.2.1.2.1">&lt;DNL&gt;: a Domain Name Label covered by a PRM eligible for Sunrise.</li>
                  <li pn="section-6.6-4.3.2.1.2.2">&lt;DNL insertion datetime&gt;: datetime in UTC that the DNL was first inserted into the Sunrise List.
                  The possible two values of time for inserting a DNL to the Sunrise List are 00:00:00 and 12:00:00 UTC.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-6.6-5">Example of a Sunrise List:</t>
        <figure align="left" suppress-title="false" pn="figure-17">
          <name slugifiedName="name-example-sunrise-list">Example Sunrise List</name>
          <sourcecode type="" markers="false" pn="section-6.6-6.1">
1,2012-08-16T00:00:00.0Z
DNL,insertion-datetime
example,2010-07-14T00:00:00.0Z
another-example,2012-08-16T00:00:00.0Z
anotherexample,2011-08-16T12:00:00.0Z
</sourcecode>
        </figure>
        <t indent="0" pn="section-6.6-7">
          To provide authentication and integrity protection, the Sunrise
          List will be PGP signed by the TMDB (see <xref target="procDescBootstrapPgpKeyRy" format="default" sectionFormat="of" derivedContent="Section 5.1.1.4"/>).  The PGP signature of the 
          Sunrise List can be found in the similar URI but with extension .sig, as shown below.
        </t>
        <t indent="0" pn="section-6.6-8">
          The URLs of the dy interface (<xref target="dy" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>) are:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6-9">
          <li pn="section-6.6-9.1">https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.csv</li>
          <li pn="section-6.6-9.2">https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.sig</li>
        </ul>
      </section>
    </section>
    <section anchor="formalSyntax" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-formal-syntax">Formal Syntax</name>
      <section anchor="FormalSyntaxClaimsNotice" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-trademark-claims-notice-tcn-2">Trademark Claims Notice (TCN)</name>
        <t indent="0" pn="section-7.1-1">
          The schema presented here is for a Trademark Claims Notice.
        </t>
        <t indent="0" pn="section-7.1-2">
          The CODE BEGINS and CODE ENDS tags are not part of the schema; they are used to note the beginning and ending of the schema
          for URI registration purposes.
        </t>
        <sourcecode name="" type="xml" markers="true" pn="section-7.1-3">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;schema targetNamespace="urn:ietf:params:xml:ns:tmNotice-1.0"
  xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0"
  xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified"&gt;

  &lt;annotation&gt;
    &lt;documentation&gt;
      Schema for representing a Trademark Claim Notice.
    &lt;/documentation&gt;
  &lt;/annotation&gt;
  &lt;import namespace="urn:ietf:params:xml:ns:mark-1.0"/&gt;
  &lt;element name="notice" type="tmNotice:noticeType"/&gt;
  &lt;complexType name="holderType"&gt;
    &lt;sequence&gt;
      &lt;element name="name" type="token" minOccurs="0"/&gt;
      &lt;element name="org" type="token" minOccurs="0"/&gt;
      &lt;element name="addr" type="tmNotice:addrType"/&gt;
      &lt;element name="voice" type="mark:e164Type" minOccurs="0"/&gt;
      &lt;element name="fax" type="mark:e164Type" minOccurs="0"/&gt;
      &lt;element name="email" type="mark:minTokenType" minOccurs="0"/&gt;
    &lt;/sequence&gt;
    &lt;attribute name="entitlement" type="mark:entitlementType"/&gt;
  &lt;/complexType&gt;
  &lt;complexType name="noticeType"&gt;
    &lt;sequence&gt;
      &lt;element name="id" type="tmNotice:idType"/&gt;
      &lt;element name="notBefore" type="dateTime"/&gt;
      &lt;element name="notAfter" type="dateTime"/&gt;
      &lt;element name="label" type="mark:labelType"/&gt;
      &lt;element name="claim" type="tmNotice:claimType" minOccurs="0"
        maxOccurs="unbounded"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;
  &lt;complexType name="claimType"&gt;
    &lt;sequence&gt;
      &lt;element name="markName" type="token"/&gt;
      &lt;element name="holder" type="tmNotice:holderType"
        maxOccurs="unbounded"/&gt;
      &lt;element name="contact" type="tmNotice:contactType"
        minOccurs="0" maxOccurs="unbounded"/&gt;
      &lt;element name="jurDesc" type="tmNotice:jurDescType"/&gt;
      &lt;element name="classDesc" type="tmNotice:classDescType"
        minOccurs="0" maxOccurs="unbounded"/&gt;
      &lt;element name="goodsAndServices" type="token"/&gt;
      &lt;element name="notExactMatch" type="tmNotice:noExactMatchType"
        minOccurs="0"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;
  &lt;complexType name="jurDescType"&gt;
    &lt;simpleContent&gt;
      &lt;extension base="token"&gt;
        &lt;attribute name="jurCC" type="mark:ccType" use="required"/&gt;
      &lt;/extension&gt;
    &lt;/simpleContent&gt;
  &lt;/complexType&gt;
  &lt;complexType name="classDescType"&gt;
    &lt;simpleContent&gt;
      &lt;extension base="token"&gt;
        &lt;attribute name="classNum" type="integer" use="required"/&gt;
      &lt;/extension&gt;
    &lt;/simpleContent&gt;
  &lt;/complexType&gt;
  &lt;complexType name="noExactMatchType"&gt;
    &lt;choice maxOccurs="unbounded"&gt;
      &lt;element name="udrp" type="tmNotice:udrpType"/&gt;
      &lt;element name="court" type="tmNotice:courtType"/&gt;
    &lt;/choice&gt;
  &lt;/complexType&gt;
  &lt;complexType name="udrpType"&gt;
    &lt;sequence&gt;
      &lt;element name="caseNo" type="token"/&gt;
      &lt;element name="udrpProvider" type="token"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;
  &lt;complexType name="courtType"&gt;
    &lt;sequence&gt;
      &lt;element name="refNum" type="token"/&gt;
      &lt;element name="cc" type="mark:ccType"/&gt;
      &lt;element name="region" type="token" minOccurs="0"
        maxOccurs="unbounded"/&gt;
      &lt;element name="courtName" type="token"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;
  &lt;complexType name="addrType"&gt;
    &lt;sequence&gt;
      &lt;element name="street" type="token" minOccurs="1"
        maxOccurs="3"/&gt;
      &lt;element name="city" type="token"/&gt;
      &lt;element name="sp" type="token" minOccurs="0"/&gt;
      &lt;element name="pc" type="mark:pcType" minOccurs="0"/&gt;
      &lt;element name="cc" type="mark:ccType"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;
  &lt;complexType name="contactType"&gt;
    &lt;sequence&gt;
      &lt;element name="name" type="token"/&gt;
      &lt;element name="org" type="token" minOccurs="0"/&gt;
      &lt;element name="addr" type="tmNotice:addrType"/&gt;
      &lt;element name="voice" type="mark:e164Type"/&gt;
      &lt;element name="fax" type="mark:e164Type" minOccurs="0"/&gt;
      &lt;element name="email" type="mark:minTokenType"/&gt;
    &lt;/sequence&gt;
    &lt;attribute name="type" type="mark:contactTypeType"/&gt;
  &lt;/complexType&gt;
  &lt;simpleType name="idType"&gt;
    &lt;restriction base="token"&gt;
      &lt;pattern value="[a-fA-F0-9]{8}\d{1,19}"/&gt;
    &lt;/restriction&gt;
  &lt;/simpleType&gt;
&lt;/schema&gt;
</sourcecode>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">
The code point assigned in support of this document is taken from
the wrong point in the registration tree. Unfortunately, the code
point has already been deployed in the field without following the
proper registration review process. The designated experts for the
registry have considered the issues that correcting this action
would cause for deployed implementations and have consented to the
continued use of the code point.    
      </t>
      <t indent="0" pn="section-8-2">
        This document uses URNs to describe XML namespaces and XML schemas
        conforming to a registry mechanism described in <xref target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>. IANA has registered two URI assignments as follows.
      </t>
      <t indent="0" pn="section-8-3">Trademark Claims Notice namespace:</t>
      <dl newline="false" spacing="compact" indent="3" pn="section-8-4">
        <dt pn="section-8-4.1">URI:</dt>
        <dd pn="section-8-4.2">urn:ietf:params:xml:ns:tmNotice-1.0</dd>
        <dt pn="section-8-4.3">Registrant Contact:</dt>
        <dd pn="section-8-4.4">IETF &lt;iesg@ietf.org&gt; and ICANN &lt;globalsupport@icann.org&gt;</dd>
        <dt pn="section-8-4.5">XML:</dt>
        <dd pn="section-8-4.6">None.  Namespace URIs do not represent an XML specification.</dd>
        <dt pn="section-8-4.7">Note:</dt>
        <dd pn="section-8-4.8">Note that this assignment is made from the wrong point in
            the tree in order to be consistent with deployed
            implementations.</dd>
      </dl>
      <t indent="0" pn="section-8-5">Trademark Claims Notice XML schema:</t>
      <dl newline="false" spacing="compact" indent="3" pn="section-8-6">
        <dt pn="section-8-6.1">URI:</dt>
        <dd pn="section-8-6.2">urn:ietf:params:xml:schema:tmNotice-1.0</dd>
        <dt pn="section-8-6.3">Registrant Contact:</dt>
        <dd pn="section-8-6.4">IETF &lt;iesg@ietf.org&gt; and ICANN &lt;globalsupport@icann.org&gt;</dd>
        <dt pn="section-8-6.5">XML:</dt>
        <dd pn="section-8-6.6">See <xref target="FormalSyntaxClaimsNotice" format="default" sectionFormat="of" derivedContent="Section 7.1"/> of RFC 9361.</dd>
        <dt pn="section-8-6.7">Note:</dt>
        <dd pn="section-8-6.8">Note that this assignment is made from the wrong point in
            the tree in order to be consistent with deployed
            implementations.</dd>
      </dl>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">
        This specification uses HTTP Basic Authentication to provide a simple application-layer authentication service. 
        HTTPS is used in all interfaces in order to protect against most common attacks. In addition,
        the client identifier is tied to a set of IP addresses that are allowed to connect to the interfaces described in this document,
        providing an extra security measure.
      </t>
      <t indent="0" pn="section-9-2">
        The TMDB <bcp14>MUST</bcp14> provide credentials to the appropriate Registries and Registrars. 
      </t>
      <t indent="0" pn="section-9-3">
        The TMDB <bcp14>MUST</bcp14> require the use of strong passwords by Registries and Registrars.
      </t>
      <t indent="0" pn="section-9-4">
        The TMDB, Registries, and Registrars <bcp14>MUST</bcp14> use the best practices described in <xref target="RFC9325" format="default" sectionFormat="of" derivedContent="RFC9325"/> or its successors.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-10-1">This specification defines the interfaces to support the <xref target="RPM-Requirements" format="default" sectionFormat="of" derivedContent="RPM-Requirements"/>. Legal documents govern the interactions between the different parties, and such legal documents must ensure that privacy-sensitive and/or personal data receives the required protection.           
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="Claims50" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/previously-abused-16jul13-en.pdf" quoteTitle="true" derivedAnchor="Claims50">
          <front>
            <title>Implementation Notes: Trademark Claims Protection for Previously Abused Names</title>
            <author>
              <organization showOnFrontPage="true">ICANN</organization>
            </author>
            <date month="July" year="2013"/>
          </front>
        </reference>
        <reference anchor="MatchingRules" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rules-14jul16-en.pdf" quoteTitle="true" derivedAnchor="MatchingRules">
          <front>
            <title>Explanatory Memorandum: Implementing the Matching Rules</title>
            <author>
              <organization showOnFrontPage="true">ICANN</organization>
            </author>
            <date month="July" year="2016"/>
          </front>
        </reference>
        <reference anchor="QLP-Addendum" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-qlp-addendum-10apr14-en.pdf" quoteTitle="true" derivedAnchor="QLP-Addendum">
          <front>
            <title>Trademark Clearinghouse Rights Protection Mechanism Requirements: Qualified Launch Program Addendum</title>
            <author>
              <organization showOnFrontPage="true">ICANN</organization>
            </author>
            <date month="April" year="2014"/>
          </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="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC7848" target="https://www.rfc-editor.org/info/rfc7848" quoteTitle="true" derivedAnchor="RFC7848">
          <front>
            <title>Mark and Signed Mark Objects Mapping</title>
            <author fullname="G. Lozano" initials="G." surname="Lozano"/>
            <date month="June" year="2016"/>
            <abstract>
              <t indent="0">Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).</t>
              <t indent="0">One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.</t>
              <t indent="0">This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7848"/>
          <seriesInfo name="DOI" value="10.17487/RFC7848"/>
        </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="RFC9325" target="https://www.rfc-editor.org/info/rfc9325" quoteTitle="true" derivedAnchor="RFC9325">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="November" year="2022"/>
            <abstract>
              <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
              <t indent="0">RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="9325"/>
          <seriesInfo name="DOI" value="10.17487/RFC9325"/>
        </reference>
        <reference anchor="RPM-Requirements" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-30sep13-en.pdf" quoteTitle="true" derivedAnchor="RPM-Requirements">
          <front>
            <title>Trademark Clearinghouse Rights Protection Mechanism Requirements</title>
            <author>
              <organization showOnFrontPage="true">ICANN</organization>
            </author>
            <date month="September" year="2013"/>
          </front>
        </reference>
        <reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
          <front>
            <title abbrev="Extensible Markup Language (XML) 1.0 (Fifth Edition)">Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
            <author initials="T." surname="Bray" fullname="Tim Bray"/>
            <author initials="J." surname="Paoli" fullname="Jean Paoli"/>
            <author initials="C. M." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen"/>
            <author initials="E." surname="Maler" fullname="Eve Maler"/>
            <author initials="F." surname="Yergeau" fullname="François Yergeau"/>
            <date year="2008" month="November"/>
            <keyword>W3C.xml</keyword>
          </front>
          <refcontent>W3C Recommendation REC-xml-20081126</refcontent>
        </reference>
        <reference anchor="W3C.REC-xmlschema-1-20041028" target="https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-xmlschema-1-20041028">
          <front>
            <title abbrev="XML Schema Part 1: Structures Second Edition">XML Schema Part 1: Structures Second Edition</title>
            <author initials="H." surname="Thompson" fullname="Henry S. Thompson"/>
            <author initials="D." surname="Beech" fullname="David Beech"/>
            <author initials="M." surname="Maloney" fullname="Murray Maloney"/>
            <author initials="N." surname="Mendelsohn" fullname="Noah Mendelsohn"/>
            <date year="2004" month="October"/>
            <keyword>W3C.xmlschema-1</keyword>
          </front>
          <refcontent>W3C Recommendation REC-xmlschema-1-20041028</refcontent>
        </reference>
        <reference anchor="W3C.REC-xmlschema-2-20041028" target="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-xmlschema-2-20041028">
          <front>
            <title abbrev="XML Schema Part 2: Datatypes Second Edition">XML Schema Part 2: Datatypes Second Edition</title>
            <author initials="P." surname="Biron" fullname="Paul V. Biron"/>
            <author initials="A." surname="Malhotra" fullname="Ashok Malhotra"/>
            <date year="2004" month="October"/>
            <keyword>W3C.xmlschema-2</keyword>
          </front>
          <refcontent>W3C Recommendation REC-xmlschema-2-20041028</refcontent>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="ICANN-GTLD-AGB-20120604" target="http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf" quoteTitle="true" derivedAnchor="ICANN-GTLD-AGB-20120604">
          <front>
            <title>gTLD Applicant Guidebook Version 2012-06-04</title>
            <author>
              <organization showOnFrontPage="true">ICANN</organization>
            </author>
            <date month="June" year="2012"/>
          </front>
        </reference>
        <reference anchor="ISO3166-2" target="http://www.iso.org/iso/home/standards/country_codes.htm" quoteTitle="true" derivedAnchor="ISO3166-2">
          <front>
            <title abbrev="International Standard for country codes and codes for their subdivisions">International Standard for country codes and codes for their subdivisions</title>
            <author>
              <organization showOnFrontPage="true">ISO</organization>
            </author>
            <keyword>ISO</keyword>
          </front>
        </reference>
        <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339" quoteTitle="true" derivedAnchor="RFC3339">
          <front>
            <title>Date and Time on the Internet: Timestamps</title>
            <author fullname="G. Klyne" initials="G." surname="Klyne"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2002"/>
            <abstract>
              <t indent="0">This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3339"/>
          <seriesInfo name="DOI" value="10.17487/RFC3339"/>
        </reference>
        <reference anchor="RFC4180" target="https://www.rfc-editor.org/info/rfc4180" quoteTitle="true" derivedAnchor="RFC4180">
          <front>
            <title>Common Format and MIME Type for Comma-Separated Values (CSV) Files</title>
            <author fullname="Y. Shafranovich" initials="Y." surname="Shafranovich"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4180"/>
          <seriesInfo name="DOI" value="10.17487/RFC4180"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC4880" target="https://www.rfc-editor.org/info/rfc4880" quoteTitle="true" derivedAnchor="RFC4880">
          <front>
            <title>OpenPGP Message Format</title>
            <author fullname="J. Callas" initials="J." surname="Callas"/>
            <author fullname="L. Donnerhacke" initials="L." surname="Donnerhacke"/>
            <author fullname="H. Finney" initials="H." surname="Finney"/>
            <author fullname="D. Shaw" initials="D." surname="Shaw"/>
            <author fullname="R. Thayer" initials="R." surname="Thayer"/>
            <date month="November" year="2007"/>
            <abstract>
              <t indent="0">This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t>
              <t indent="0">OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4880"/>
          <seriesInfo name="DOI" value="10.17487/RFC4880"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890" quoteTitle="true" derivedAnchor="RFC5890">
          <front>
            <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t indent="0">This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5890"/>
          <seriesInfo name="DOI" value="10.17487/RFC5890"/>
        </reference>
        <reference anchor="RFC7617" target="https://www.rfc-editor.org/info/rfc7617" quoteTitle="true" derivedAnchor="RFC7617">
          <front>
            <title>The 'Basic' HTTP Authentication Scheme</title>
            <author fullname="J. Reschke" initials="J." surname="Reschke"/>
            <date month="September" year="2015"/>
            <abstract>
              <t indent="0">This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7617"/>
          <seriesInfo name="DOI" value="10.17487/RFC7617"/>
        </reference>
        <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="January" year="2019"/>
            <abstract>
              <t indent="0">The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t indent="0">This document obsoletes RFC 7719 and updates RFC 2308.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="WIPO-NICE-CLASSES" target="http://www.wipo.int/classifications/nice/en" quoteTitle="true" derivedAnchor="WIPO-NICE-CLASSES">
          <front>
            <title abbrev="Nice Classification">Nice Classification</title>
            <author>
              <organization showOnFrontPage="true">WIPO</organization>
            </author>
            <keyword>WIPO</keyword>
          </front>
        </reference>
        <reference anchor="WIPO.ST3" target="https://www.wipo.int/export/sites/www/standards/en/pdf/03-03-01.pdf" quoteTitle="true" derivedAnchor="WIPO.ST3">
          <front>
            <title abbrev="Two-Letter Codes for the Representation of States, Other Entities and Organizations">Recommended standard on two-letter codes for the representation of states, other entities and intergovernmental organizations</title>
            <author>
              <organization showOnFrontPage="true">WIPO</organization>
            </author>
            <date year="2022" month="November"/>
            <keyword>WIPO</keyword>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
        This specification is a collaborative effort from several participants 
        in the ICANN community.
        <contact fullname="Bernie Hoeneisen"/> participated as a coauthor for the first draft version of this document,
        providing invaluable support.
        This specification is based on a model spearheaded by
       <contact fullname="Chris Wright"/>, <contact fullname="Jeff Neuman"/>, <contact fullname="Jeff Eckhaus"/>, and <contact fullname="Will Shorter"/>.
        The author would also like to thank the thoughtful feedback provided by many in the
        tmch-tech mailing list but particularly the extensive help provided by
        <contact fullname="James Gould"/>, <contact fullname="James Mitchell"/>, and <contact fullname="Francisco Arias"/>. This document includes feedback received from  <contact fullname="Paul Hoffman"/>.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Gustavo Lozano" initials="G." surname="Lozano">
        <organization showOnFrontPage="true">ICANN</organization>
        <address>
          <postal>
            <street>12025 Waterfront Drive</street>
            <street>Suite 300</street>
            <city>Los Angeles</city>
            <code>90292</code>
            <country>United States of America</country>
          </postal>
          <phone>+1.310.301.5800</phone>
          <email>gustavo.lozano@icann.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
