<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC7235 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7235.xml">
<!ENTITY RFC7525 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7525.xml">
  <!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"> nbsp    "&#160;">
  <!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml"> zwsp   "&#8203;">
  <!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml"> nbhy   "&#8209;">
  <!ENTITY RFC4180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4180.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC4880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml">
<!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC8499 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml">
<!ENTITY RFC7848 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7848.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="9"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc sortrefs="yes" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" category="info"
ipr="trust200902" docName="draft-ietf-regext-tmch-func-spec-15"> docName="draft-ietf-regext-tmch-func-spec-15" number="9361" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="9" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <front>
    <title abbrev="ICANN-TMCH">ICANN TMCH functional specifications</title> abbrev="ICANN TMCH">ICANN Trademark Clearinghouse (TMCH) Functional Specifications</title>
    <seriesInfo name="RFC" value="9361"/>
    <author fullname="Gustavo Lozano" initials="G." surname="Lozano">
      <organization>ICANN</organization>
      <address>
        <postal>
          <street>12025 Waterfront Drive, Suite Drive</street>
	   <street>Suite 300</street>
          <city>Los Angeles</city>
          <code>90292</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>

        <phone>+1.3103015800</phone>
        <phone>+1.310.301.5800</phone>
        <email>gustavo.lozano@icann.org</email>
      </address>
    </author>
    <date day="23" month="Aug" year="2022"/>

    <area>Applications</area>

    <workgroup>Internet Engineering Task Force</workgroup> month="March" year="2023"/>
    <keyword>Trademark Clearinghouse, TMDB, ICANN, TMCH, gTLD, new gTLD, mark</keyword> Clearinghouse</keyword>
    <keyword>TMDB</keyword>
    <keyword>ICANN</keyword>
    <keyword>TMCH</keyword>
    <keyword>gTLD</keyword>
    <keyword>new gTLD</keyword>
    <keyword>mark</keyword>
    <abstract>
      <t>
        This document describes the requirements, the architecture architecture, and
        the interfaces between the ICANN Trademark Clearinghouse (TMCH) and
        Domain Name Registries 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>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        Domain Name Registries (DNRs) may operate in special modes for certain periods of time time, enabling trademark holders Trademark Holders to protect their rights
        during the introduction of a Top Level Top-Level Domain (TLD).
      </t>
      <t>
        Along with the introduction of new generic TLDs (gTLD), (gTLDs), two special modes came into effect:

        <list style='symbols'>

          <t>
      </t>
      <ul spacing="normal">
        <li>
            Sunrise Period, the Period: The Sunrise Period allows trademark holders Trademark Holders an advance opportunity to
            register domain names corresponding to their marks before names
            are generally available to the public.
          </t>

          <t>
          </li>
        <li>
            Trademark Claims Period, the 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.
          </t>

        </list>

      </t>
          </li>
      </ul>
      <t>
        This document describes the requirements, the architecture architecture, and
        the interfaces between the ICANN TMCH and
        Domain Name Registries (called Registries "Registries" in the rest of the document) document),
        as well as between the ICANN TMCH and Domain Name
        Registrars (called Registrars "Registrars" in the rest of the document)
        for the provisioning and management of domain names
        during the Sunrise and Trademark Claims Periods.
      </t>
      <t>
        For any date and/or time indications, Coordinated Universal
        Time (UTC) applies.
      </t>
    </section>
    <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
      NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only when, they
      appear in all capitals, as shown here.
      </t>
      <t>
        XML is case sensitive. Unless stated otherwise, XML specifications
        and examples provided in this document MUST <bcp14>MUST</bcp14> be interpreted in the
        character case presented in order to develop a conforming
        implementation.
      </t>
      <t>
        "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 MUST NOT <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>Extensible Markup Language (XML) 1.0 1.0, as described in <xref target='W3C.REC-xml-20081126' /> target="W3C.REC-xml-20081126" format="default"/>, and XML Schema notation notation, as described in <xref target='W3C.REC-xmlschema-1-20041028' /> target="W3C.REC-xmlschema-1-20041028" format="default"/> and <xref target='W3C.REC-xmlschema-2-20041028' /> target="W3C.REC-xmlschema-2-20041028" format="default"/>, are used in this specification. </t>
    </section>
    <section anchor="glossary" title="Glossary"> numbered="true" toc="default">
      <name>Glossary</name>
      <t>
        In the following section, the most common terms are briefly explained:
        <list style='symbols'>
          <t>
            Backend
      </t>
      <dl spacing="normal" newline="false">
        <dt>Backend Registry Operator: Entity Operator:</dt>
	<dd>An entity that manages (a part of) the technical infrastructure for a Registry
	Operator. The Registry Operator may also be the Backend Registry Operator.
          </t>
          <t>
            CA: Certificate Authority, see Operator.</dd>
        <dt>CA:</dt>
	<dd>Certification Authority. See <xref target='RFC5280'/>.
          </t>
          <t>
            CNIS, Claims target="RFC5280" format="default"/>.</dd>
        <dt>CNIS:</dt>
	<dd>Claims Notice Information Service: Service. This service provides Trademark Claims
        Notices (TCN) (TCNs) to Registrars.
          </t>
          <t>
            CRC32, Cyclic Registrars.</dd>
        <dt>CRC32:</dt>
	<dd>Cyclic Redundancy Check: Check. This algorithm is used in the ISO 3309 standard and in section Section
	8.1.1.6.2 of
        ITU-T recommendation V.42.
          </t>
          <t>
            CRL: Certificate V.42.</dd>
        <dt>CRL:</dt>
	<dd>Certificate Revocation List, see List. See <xref target='RFC5280' />.
          </t>
          <t>
            CSV: Comma-Separated Values, see target="RFC5280" format="default"/>.</dd>
        <dt>CSV:</dt>
	<dd>Comma-Separated Values. See <xref target='RFC4180' />
          </t>
          <t>
            Date target="RFC4180" format="default"/>.</dd>
        <dt>datetime:</dt>
	<dd>Date and time, datetime: Date time. The date and time are specified following
        the standard specification "Date and Time on the Internet specification", see Internet: Timestamps". See
        <xref target='RFC3339' />.
          </t>
          <t>
            DN, Domain Name, domain name: see definition of Domain name in target="RFC3339" format="default"/>.</dd>
        <dt>DN:</dt>
	<dd>Domain Name. See <xref target='RFC8499' />.
          </t>
          <t>
            DNROID, DN target="RFC8499"
	format="default"/>.</dd>
        <dt>DNL:</dt>
	<dd>Domain Name Label. The DNL is an A-label or a Non-Reserved LDH (NR-LDH) label. See <xref target="RFC5890"
	format="default"/>.</dd>
        <dt>DNL List:</dt>
	<dd>A list of DNLs that are covered by a PRM.</dd>
        <dt>DNROID:</dt>
	<dd>DN Repository Object IDentifier: an 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.
          </t>
          <t>
            DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see <xref target='RFC5890' />).
          </t>
          <t>
            DNL List: A list of DNLs that are covered by a PRM.
          </t>
          <t>
            DNS: Domain DNROIDs.</dd>
        <dt>DNS:</dt>
	<dd>Domain Name System, see System. See <xref target='RFC8499' />.
          </t>
          <t>
            Effective allocation: target="RFC8499" format="default"/>.</dd>
        <dt>Effective Allocation:</dt>
	<dd> 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 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.
          </t>
          <t>
            EPP: The Extensible allocation.</dd>
        <dt>EPP:</dt>
	<dd>Extensible Provisioning Protocol, see definition of EPP in Protocol. See <xref target='RFC8499' />.
          </t>
          <t>
            FQDN: Fully-Qualified
	target="RFC8499" format="default"/>.</dd>
        <dt>FQDN:</dt>
	<dd>Fully Qualified Domain Name, see definition of FQDN in Name. See <xref target='RFC8499' />.
          </t>
          <t>
            HTTP: Hypertext target="RFC8499"
	format="default"/>.</dd>
        <dt>HTTP:</dt>
	<dd>Hypertext Transfer Protocol, see  <xref target='RFC7230' /> and Protocol. See <xref target='RFC7231' />.
          </t>
          <t>
            HTTPS: HTTP target="RFC9110"
	format="default"/>.</dd>
        <dt>HTTPS:</dt>
	<dd>HTTP over TLS (Transport Layer Security), Security). See <xref target='RFC2818' />.
          </t>
          <t>
            IDN: Internationalized Domain Name, see definition
	target="RFC9110" format="default"/>.</dd>
        <dt>ICANN TMCH:</dt>
	<dd>A central repository for
        information to be authenticated, stored, and disseminated,
        pertaining to the rights of IDN in 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>ICANN TMCH-CA:</dt>
	<dd>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>IDN:</dt>
	<dd>Internationalized Domain Name. See <xref target='RFC8499' />.
          </t>
          <t>
            Lookup Key: A target="RFC8499"
	format="default"/>.</dd>
        <dt>Lookup Key:</dt>
	<dd>A random string of up to 51 chars 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 keys are unique and are related to one DNL only.
          </t>
          <t>
            LORDN, List only.</dd>
        <dt>LORDN:</dt>
	<dd>List of Registered Domain Names: 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).
          </t>
          <t>
            Matching Rules: Some
        process).</dd>
        <dt>Matching Rules:</dt>
	<dd>Some trademarks entitled to inclusion
        in the TMDB include characters that are impermissible
        in the domain name system (DNS) DNS as a DNL. The TMV changes (
            using (using the ICANN TMCH Matching Rules <xref target='MatchingRules' />) target="MatchingRules" format="default"/>)
        certain DNS-impermissible characters in a trademark into
        DNS-permissible equivalent characters
          </t>
          <t>
            NORDN, Notification characters.</dd>
        <dt>NORDN:</dt>
	<dd>Notification of Registered Domain Names: The Names. This is the
        process by which Registries upload their recent LORDN to
        the TMDB.
          </t>
          <t>
            PGP: Pretty TMDB.</dd>
        <dt>PGP:</dt>
	<dd>Pretty Good Privacy, see Privacy. See <xref target='RFC4880' />
          </t>
          <t>
            PKI: Public target="RFC4880" format="default"/>.</dd>
        <dt>PKI:</dt>
	<dd>Public Key Infrastructure, see Infrastructure. See <xref
              target='RFC5280' />.
          </t>
          <t>
            PRM, Pre-registered mark: Mark target="RFC5280" format="default"/>.</dd>
        <dt>PRM:</dt>
	<dd>Pre-Registered Mark. A mark that has been
        pre-registered with the ICANN TMCH.
          </t>
          <t>
            QLP Period, Qualified TMCH.</dd>
        <dt>QLP Period:</dt>
	<dd>Qualified Launch Program Period: Period. During this optional period, a special
        process applies to DNs matching the Sunrise List (SURL) and/or the DNL List, List to ensure
	that TMHs are informed of a DN matching their PRM.
          </t>
          <t>
            Registrant: see </dd>
        <dt>Registrant:</dt>
	<dd>See the definition of Registrant in <xref target='RFC8499' />.
          </t>
          <t>
            Registrar, Domain target="RFC8499" format="default"/>.</dd>
        <dt>Registrar:</dt>
	<dd>Domain Name Registrar: see definition of Registrar in Registrar. See <xref target='RFC8499' />.
          </t>
          <t>
            Registry, Domain target="RFC8499" format="default"/>.</dd>
        <dt>Registry:</dt>
	<dd>Domain Name Registry, Registry Operator:  see definition of Registry
            in Operator. See <xref target='RFC8499' />. target="RFC8499" format="default"/>.
	A Registry Operator is the contracting party with ICANN for the TLD.
          </t>
          <t>
            SMD, Signed TLD.</dd>
        <dt>SMD:</dt>
	<dd>Signed Mark Data: 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 also PRM. See <xref target='RFC7848' />. target="RFC7848" format="default"/>.
        An SMD generated by an ICANN-approved trademark validator Trademark Validator (TMV) contains
        both the signed token and the TMV's PKIX certificate.
          </t>
          <t>
            SMD File: A certificate.</dd>
        <dt>SMD File:</dt>
	<dd>A file containing the SMD (see above) and some
            human readable
        human-readable data. The latter is usually ignored in the
        processing of the SMD File. See also <xref
              target='SmdFileFormat' />.
          </t>
          <t>
            SMD target="SmdFileFormat" format="default"/>.</dd>
        <dt>SMD Revocation List: The List:</dt>
	<dd>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.
        (i.e., not revoked). The SMD Revocation List has a similar
        function as CRLs used in PKI.
          </t>
          <t>
            SRS: Shared PKI.</dd>
        <dt>SRS:</dt>
	<dd>Shared Registration System, see also System. See <xref
              target='ICANN-GTLD-AGB-20120604' />.
          </t>
          <t>
            SURL, Sunrise List: The list of DNLs that are covered by a PRM and eligible for Sunrise.
          </t>
          <t>
            Sunrise Period: During target="ICANN-GTLD-AGB-20120604"
	format="default"/>.</dd>
        <dt>Sunrise Period:</dt>
	<dd>During this period 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.
          </t>
          <t>
            TLD: Top-Level Domain Name, see definition </dd>
        <dt>SURL:</dt>
	<dd>Sunrise List. The list of TLD in <xref target='RFC8499' />.
          </t>
          <t>
            ICANN TMCH: DNLs that are covered by a central repository PRM and are eligible for
            information to be authenticated, stored,
	Sunrise.</dd>
        <dt>TCN:</dt>
	<dd>Trademark Claims Notice, Claims Notice, Trademark Notice. A Trademark Claims
        Notice consists of one or more Trademark Claims and disseminated,
            pertaining is provided to the rights
        prospective Registrants of DNs.  </dd>
        <dt>TCNID:</dt>
	<dd>Trademark Claims Notice Identifier. An element 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.
          </t>
          <t>
            ICANN TMCH-CA:  The Certificate Authority (CA) for the ICANN TMCH. This CA is
            operated by ICANN. Trademark Claims
        Notice (see above), identifying said TCN.
        The public key for this CA Trademark Claims Notice Identifier is specified in the trust anchor
            used to validate the identity of each TMV.
          </t>
          <t>
            TMDB, Trademark
        element &lt;tmNotice:id&gt;. </dd>
        <dt>TLD:</dt>
	<dd>Top-Level Domain Name. See <xref target="RFC8499"
	format="default"/>.</dd>
        <dt>TMDB:</dt>
	<dd>Trademark Clearinghouse Database: Serves 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 "verified" trademark records from the TMVs.
          </t>
          <t>
            TMH, Trademark Holder: TMVs.</dd>
        <dt>TMH:</dt>
	<dd>Trademark Holder. The person or organization owning
        rights on a mark.
          </t>
          <t>
            TMV, Trademark mark.</dd>
        <dt>TMV:</dt>
	<dd>Trademark Validator, Trademark validation
            organization: Validation
        organization. An entity authorized by ICANN to authenticate
        and validate registrations in the TMDB TMDB, ensuring the marks qualify as
            registered or
        registered, are court-validated marks marks, or marks
            that 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.
          </t>
          <t>
            Trademark, mark: </dd>
        <dt>Trademark, Mark:</dt>
	<dd> 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 document, only textual marks are relevant.
          </t>
          <t>
            Trademark relevant.</dd>
        <dt>Trademark Claims, Claims: Provides Claims:</dt>
	<dd>Provides information to enhance the
        understanding of the Trademark trademark rights being claimed by the
            TMH.
          </t>
          <t>
            TCN, Trademark
        TMH.</dd>
        <dt>Trademark Claims Notice, Claims Notice, Trademark Notice: A Trademark Claims
            Notice consist of one or more Trademark Claims and are provided to
            prospective Registrants of DNs.
          </t>
          <t>
            TCNID, 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;.
          </t>
          <t>
            Trademark Claims Period: Period:</dt>
	<dd> During this period, a special
        process applies to DNs matching the DNL List, 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.
          </t>
          <t>
            UTC: DN.</dd>
        <dt>UTC:</dt>
	<dd> Coordinated Universal Time, as Time. This is maintained by the
        Bureau International des Poids et Mesures (BIPM); see
            also (BIPM). See
        <xref target='RFC3339' />.
          </t>

        </list>

      </t>

      <t><vspace blankLines='99' /> target="RFC3339" format="default"/>.</dd>
      </dl>
      <t> </t>
    </section>

<!-- <vspace blankLines='99' /> -->

    <section anchor="architecture" title="Architecture"> numbered="true" toc="default">
      <name>Architecture</name>
      <section anchor="archSunrise" title="Sunrise Period">

        <t> numbered="true" toc="default">
        <name>Sunrise Period</name>
        <figure anchor='figArchSunrise'>
            <preamble>Architecture anchor="figArchSunrise">
	  <name>Architecture of the Sunrise Period</preamble>
            <artwork>
              <![CDATA[ Period</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
                     SMD hand over (out-of-band)
           ..............................................
           :                                            :
           :           .'''''''''''''''''''.            :
           :           .    ICANN TMCH     .            :
           :           .....................            :
           v           .                   .            :
    .------------.     .  .-------------.  . hv      .-----.
    | Registrant |     .  |     TMV     |<---------->| TMH |
    '------------'     .  '-------------'  .     vh  '-----'
          |            .     |       ^   \ .
          |            .     |       |    \.
       tr |            .  vs |       | dv  \
          |            .     |    vd |     .\
          v            .     v       v     . \
    .-----------.  sr  .    .---------.    .  \
 .->| Registrar |<..........|         |    .   \
 :  '-----------'      .    |         |    .    \
 :        |        sy  .    |    T    |    .     \
 :     ry |    .------------|    M    |    .   vc \
 :        |    |       .    |    D    |    .       \
 :        v    v       .    |    B    |    .        v
 :  .-----------.      . yd |         |    .  .---------------.
 :  | Registry  |---------->|         |    .  | ICANN TMCH-CA |
 :  '-----------'      .    '---------'    .  '---------------'
 :        ^            .                   .        |   :
 :        |             '''''''''''''''''''         |   :
 :        | cy                                      |   :
 : cr     '-----------------------------------------'   :
 :......................................................:
 ]]>
            </artwork>
]]></artwork>
        </figure>

        </t>
        <t><xref target="figArchSunrise"/> target="figArchSunrise" format="default"/> depicts the architecture of the Sunrise Period, including all the actors and interfaces.</t>

        <t><vspace blankLines='99' />
        <t> </t>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="archTrCl" title="Trademark numbered="true" toc="default">
        <name>Trademark Claims Period">

        <t> Period</name>
        <figure anchor='figArchTrCl'>
            <preamble>Architecture anchor="figArchTrCl">
	  <name>Architecture of the Trademark Claims Period</preamble>
            <artwork>
              <![CDATA[ Period</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
                    .''''''''''''''.
                    .  ICANN TMCH  .
                    ................
                    .              .
 .------------.     .  .-------.   . hv      .-----.
 | Registrant |     .  |  TMV  |<----------->| TMH |
 '------------'     .  '-------'   .     vh  '-----'
        |           .      ^       .
        |           .      | dv    .
     tr |           .   vd |       .
        v           .      v       .
 .-----------.  dr  .  .-------.   .
 | Registrar |<--------|       |   .
 '-----------'      .  |   T   |   .
     ry |           .  |   M   |   .
        v           .  |   D   |   .
  .----------.  dy  .  |   B   |   .
  | Registry |<------->|       |   .
  '----------'   yd .  '-------'   .
                    .              .
                     ''''''''''''''
 ]]>
            </artwork>
]]></artwork>
        </figure>

        </t>
        <t><xref target="figArchTrCl"/> target="figArchTrCl" format="default"/> depicts the architecture of the Trademark Claims Period, including all the actors and interfaces.</t>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="archInterfaces" title="Interfaces"> numbered="true" toc="default">
        <name>Interfaces</name>
        <t>
          In the sub-sections
          The subsections below follows a contain short description descriptions of each interface to
          provide an overview of the architecture. More detailed
          descriptions of the relevant interfaces follow further
          below (<xref target='processDescriptions' />). are in <xref target="processDescriptions" format="default"/>.
        </t>
        <section anchor="hv" title="hv"> numbered="true" toc="default">
          <name>hv</name>
          <t>
            The TMH registers a mark with a TMV via the hv interface.
          </t>
          <t>
            After the successful registration of the mark, the TMV
            makes available a SMD Signed Mark Data (SMD) File available (see also
            <xref target='SmdFileFormat' />) target="SmdFileFormat" format="default"/>) to the TMH to be used
            during the Sunrise Period.
          </t>
          <t>
            The specifics of the hv interface are beyond the scope
            of this document.
          </t>
        </section>
        <section anchor="vd" title="vd"> numbered="true" toc="default">
          <name>vd</name>
          <t>
            After successful mark registration, registration of the mark, the TMV ensures the
            TMDB inserts the corresponding DNLs and mark marks information
            into the database via the vd interface.
          </t>
          <t>
            The specifics of
            the vd interface are beyond the scope of this document.
          </t>
        </section>
        <section anchor="dy" title="dy"> numbered="true" toc="default">
          <name>dy</name>
          <t>
            During the Trademark Claims Period 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>
            Not
            This interface is not relevant during the Sunrise Period.
          </t>
        </section>
        <section anchor="tr" title="tr"> numbered="true" toc="default">
          <name>tr</name>
          <t>
            The Registrant communicates with the Registrar via the
            tr interface.
          </t>
          <t>
            The specifics of the tr interface are beyond the scope
            of this document.
          </t>
        </section>
        <section anchor="ry" title="ry"> numbered="true" toc="default">
          <name>ry</name>
          <t>
            The Registrar communicate communicates with the Registry via the ry interface.
            The ry interfaces is are typically implemented in
            EPP.
          </t>
        </section>
        <section anchor="dr" title="dr"> numbered="true" toc="default">
          <name>dr</name>
          <t>
            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>
            Not
            This interface is not relevant during the Sunrise Period.
          </t>
        </section>
        <section anchor="yd" title="yd"> numbered="true" toc="default">
          <name>yd</name>
          <t>
            During the Sunrise Period Period, the Registry notifies the TMDB
            via the yd interface of all DNs
            effectively allocated.
          </t>
          <t>
            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 DNL List during the creation of the DN.
          </t>
          <t>
            The protocol used on the yd interface is HTTPS.
          </t>
        </section>
        <section anchor="dv" title="dv"> numbered="true" toc="default">
          <name>dv</name>
          <t>
	    The TMDB notifies the TMV via the dv interface to the TMV of all DNs effectively
	    allocated DNs that match a mark registered by that TMV.
          </t>
          <t>
            The specifics of the dv interface are beyond the scope
            of this document.
          </t>
        </section>
        <section anchor="vh" title="vh"> numbered="true" toc="default">
          <name>vh</name>
          <t>
	    The TMV notifies the TMH via the vh interface after a
            DN has been an effectively
	    allocated that DN matches a PRM of this
            TMH. THM.
          </t>
          <t>
            The specifics of the vh interface are beyond the scope of
            this document.
          </t>
        </section>
        <section anchor="vs" title="vs"> numbered="true" toc="default">
          <name>vs</name>
          <t>
            The TMV requests to add a revoked
            SMD
            SMDs to the SMD Revocation List at the TMDB.
          </t>
          <t>
            The specifics of the vs interface are beyond the scope of
            this document.
          </t>
          <t>
            Not
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="sy" title="sy"> numbered="true" toc="default">
          <name>sy</name>
          <t>
            During the Sunrise Period 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>
            Not
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="sr" title="sr"> numbered="true" toc="default">
          <name>sr</name>
          <t>
            During the Sunrise Period 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 (s. (see above),
            i.e.
            i.e., HTTPS.
          </t>
          <t>
            Not
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="vc" title="vc"> numbered="true" toc="default">
          <name>vc</name>
          <t>
            The TMV registers its public key, key and requests to revoke an existing
            key,
            key with the ICANN TMCH-CA over the vc interface.
          </t>
          <t>
            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>
            Not
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="cy" title="cy"> numbered="true" toc="default">
          <name>cy</name>
          <t>
            During the Sunrise Period 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>
            Not
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
        <section anchor="cr" title="cr"> numbered="true" toc="default">
          <name>cr</name>
          <t>
            During the Sunrise Period 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>
            Not
            This interface is not relevant during the Trademark Claims Period.
          </t>
        </section>
      </section>
    </section>
    <!-- <vspace blankLines='99' /> -->

    <section anchor="processDescriptions" title="Process Descriptions"> numbered="true" toc="default">
      <name>Process Descriptions</name>
      <section anchor="bootstraping" title="Bootstrapping"> numbered="true" toc="default">
        <name>Bootstrapping</name>
        <section anchor="procDescBootstrapRy" title="Bootstrapping numbered="true" toc="default">
          <name>Bootstrapping for Registries"> Registries</name>
          <section anchor="procDescBootstrapCredentialsRy" title="Credentials">
            <t>
              Each numbered="true" toc="default">
            <name>Credentials</name>
            <t>Each Registry Operator will receive authentication credentials from the TMDB to be used:

              <list style='symbols'>

                <t>
                  During used:</t>
            <ul spacing="normal">
              <li>during the Sunrise Period to fetch the SMD Revocation List
              from the TMBD TMDB via the sy interface
              (<xref target="sy" />).
                </t>

                <t>
                  During format="default"/>),</li>
              <li>during the Trademark Claims Period to fetch the DNL List from the TMDB via the dy interface (<xref target="dy" />).
                </t>

                <t>
                  During format="default"/>), and</li>
              <li>during the NORDN process to notify the LORDN to the
              TMDB via the yd interface (<xref target="yd" />).
                </t>
              </list>

                  Note: credentials format="default"/>).</li>
            </ul>
            <t>Note: Credentials are created per TLD and provided to the
                  Registry Operator.

            </t> Operator.</t>
          </section>
          <section anchor="procDescBootstrapIpAclRy" title="IP numbered="true" toc="default">
            <name>IP Addresses for Access Control"> Control</name>
            <t>
              Each Registry Operator MUST <bcp14>MUST</bcp14> provide to the TMDB with
              all IP addresses that addresses, which will be used to:
              <list style='symbols'>
                <t>
                  Fetch
            </t>
            <ul spacing="normal">
              <li>fetch the SMD Revocation List
              via the sy interface (<xref target="sy" />).
                </t>
                <t>
                  Fetch format="default"/>),</li>
              <li>fetch the DNL List from the TMDB via the dy interface (<xref target="dy" />).
                </t>
                <t>
                  Upload format="default"/>), and</li>
              <li>upload the LORDN to the
                  TMDB via the yd interface (<xref target="yd" />).
                </t>
              </list>
            </t> format="default"/>).</li>
            </ul>
            <t>
                This access restriction MAY <bcp14>MAY</bcp14> be applied by the TMDB in addition to
                HTTP Basic access authentication (see <xref target="RFC7235"/>). target="RFC7617" format="default"/>). For credentials to be
                used, see <xref target="procDescBootstrapCredentialsRy"
                />. format="default"/>.
            </t>
            <t>
                The TMDB MAY <bcp14>MAY</bcp14> limit the number of IP addresses to be
                accepted per Registry Operator.
            </t>
          </section>
          <section anchor="procDescBootstrapTmchTaRy" title="ICANN numbered="true" toc="default">
            <name>ICANN TMCH Trust Anchor"> Anchor</name>
            <t>
              Each Registry Operator MUST <bcp14>MUST</bcp14> fetch the PKIX certificate (<xref
              target='RFC5280' />) <xref target="RFC5280" format="default"/> of
              the ICANN TMCH-CA (Trust Anchor) from
              &lt;&nbsp;https://ca.icann.org/tmch.crt&nbsp;&gt;
              <eref target="https://ca.icann.org/tmch.crt" brackets="angle"/> to be used:
              <list style='symbols'>

                <t>
                  During
            </t>
            <ul spacing="normal">
              <li>during the Sunrise Period to validate the TMV
                  certificates and the TMV CRL.
                </t>

              </list>
            </t> CRL.</li>
            </ul>
          </section>
          <section anchor="procDescBootstrapPgpKeyRy" title="TMDB numbered="true" toc="default">
            <name>TMDB PGP Key"> Key</name>
            <t>
              The TMDB MUST <bcp14>MUST</bcp14> provide each Registry Operator with the public portion of
              the PGP Key used by the TMDB, which is to be used:
              <list style='symbols'>

                <t>
                  During
            </t>
            <ul spacing="normal">
              <li>during the Sunrise Period to perform integrity
              checking of the SMD Revocation List fetched from
              the TMDB via the sy interface (<xref target="sy"
                  />).
                </t>

                <t>
                  During format="default"/>) and</li>
              <li>during the Trademark Claims Period to perform integrity
              checking of the DNL List fetched from the TMDB
              via the dy interface (<xref target="dy" />).
                </t>

              </list>
            </t> format="default"/>).</li>
            </ul>
          </section>
        </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="procDescBootstrapRr" title="Bootstrapping numbered="true" toc="default">
          <name>Bootstrapping for Registrars"> Registrars</name>
          <section anchor="procDescBootstrapCredentialsRr" title="Credentials"> numbered="true" toc="default">
            <name>Credentials</name>
            <t>
              Each ICANN-accredited ICANN-Accredited Registrar will receive authentication
              credentials from the TMDB to be used:

              <list style='symbols'>

                <t>
                  During used:</t>
            <ul spacing="normal">
              <li>during the Sunrise Period to (optionally) fetch the
              SMD Revocation List from the TMDB via the sr
              interface (<xref target="sr" />).
                </t>

                <t>
                  During format="default"/>) and</li>
              <li>during the Trademark Claims Period to fetch TCNs
              from the TMDB via the dr interface (<xref target="dr" />).
                </t>

              </list>
            </t> format="default"/>).</li>
            </ul>
          </section>
          <section anchor="procDescBootstrapIpAclRr" title="IP numbered="true" toc="default">
            <name>IP Addresses for Access Control"> Control</name>
            <t>
              Each Registrar MUST <bcp14>MUST</bcp14> provide to the TMDB
              with all IP addresses, which will be used to:
              <list style='symbols'>
                <t>
                  Fetch
            </t>
            <ul spacing="normal">
              <li>fetch the SMD Revocation List
              via the sr interface (<xref target="sr" />).
                </t>
                <t>
                  Fetch format="default"/>) and</li>
              <li>fetch TCNs via the dr interface (<xref target="dr" />).
                </t>
              </list>
            </t> format="default"/>).</li>
            </ul>
            <t>
                This access restriction MAY <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"/>).
            </t>
            <t>
                The TMDB MAY <bcp14>MAY</bcp14> limit the number of IP addresses to be
                accepted per Registrar.
            </t>
          </section>
          <section anchor="procDescBootstrapTmchTaRr" title="ICANN numbered="true" toc="default">
            <name>ICANN TMCH Trust Anchor"> Anchor</name>
            <t>
              Registrars MAY <bcp14>MAY</bcp14> fetch the PKIX certificate of
              the ICANN TMCH-CA (Trust Anchor) from
              &lt;&nbsp;https://ca.icann.org/tmch.crt&nbsp;&gt;
              <eref target="https://ca.icann.org/tmch.crt" brackets="angle"/> to be
              used:
              <list style='symbols'>
                <t>
                  During
            </t>
            <ul spacing="normal">
              <li>during the Sunrise Period to (optionally) validate
              the TMV certificates and TMV CRL.
                </t>
              </list>
            </t> CRL.</li>
            </ul>
          </section>
          <section anchor="procDescBootstrapPgpKeyRr" title="TMDB numbered="true" toc="default">
            <name>TMDB PGP Key"> Key</name>
            <t>
              Registrars MUST <bcp14>MUST</bcp14> receive the public portion of the PGP Key
              used by TMDB from the TMDB administrator to be used:
              <list style='symbols'>

                <t>
                  During
            </t>
            <ul spacing="normal">
              <li>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" />).
                </t>

              </list>
            </t>
	      format="default"/>).</li>
            </ul>
          </section>
        </section>
      <!-- <vspace blankLines='99' /> -->
    </section>
      <section anchor="procDescSunrise" title="Sunrise Period"> numbered="true" toc="default">
        <name>Sunrise Period</name>
        <section anchor="procDescSunriseReg" title="Domain numbered="true" toc="default">
          <name>Domain Name registration">

          <t> Registration</name>
          <figure anchor='figIntSunrisePeriod'>
              <preamble>Domain anchor="figIntSunrisePeriod">
	    <name>Domain Name registration Registration during the Sunrise Period</preamble>
              <artwork>
                <![CDATA[ Period</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
.------------.     .-----------.                 .----------.
| Registrant |     | Registrar |                 | Registry |
'------------'     '-----------'                 '----------'
       |                 |                             |
       |      Request DN |                             |
       |    registration |                             |
       |      (with SMD) |                             |
       |---------------->|       Check DN availability |
       |                 |---------------------------->|
       |                 |                             |
       |                 | DN unavailable       .-------------.
       | DN unavailable  |<--------------------( DN available? )
       |<----------------|                   no '-------------'
       |                 |                             | yes
       |                 | DN available                |
       |                 |<----------------------------|
       |                 |                             |
       |                 |     Request DN registration |
       |                 |                  (with SMD) |
       |                 |---------------------------->|
       |                 |                             |
       |                 |             .------------------------------.
       |                 |             | DN registration validation / |
       |                 |             |       SMD validation         |
       |                 |             '------------------------------'
       |                 |                             |
       | Registration    |.-----------. Error .----------------------.
       | error           || TRY AGAIN |<-----( Validation successful? )
       |<----------------|| / ABORT   |    no '----------------------'
       |                 |'-----------'                | yes
       |                 |                             |
       |                 | DN registered               |
       | DN registered   |<----------------------------|
       |<----------------|                             |
       |                 |                             |
]]>
              </artwork>
]]></artwork>
          </figure>

          </t>
          <t><xref target="figIntSunrisePeriod"/> target="figIntSunrisePeriod" format="default"/> represents a synchronous DN registration
              workflow (usually called first come first served).</t>
        </section>
        <!-- <vspace blankLines='99' /> -->

        <section anchor="procDescSunriseResRy" title="Sunrise numbered="true" toc="default">
          <name>Sunrise Domain Name registration Registration by Registries"> Registries</name>
          <t>
            Registries MUST <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"/>).  If any of these checks fails fail, the
            Registry MUST <bcp14>MUST</bcp14> abort the registration.  Each of these
            checks MUST <bcp14>MUST</bcp14> be performed before the DN is effectively allocated.
          </t>
          <t>
            In case of asynchronous registrations (e.g. (e.g., auctions),
            the minimum set of checks MAY <bcp14>MAY</bcp14> be performed when creating
            the intermediate object (e.g. (e.g., a DN application)
            used for DN registration.
            If the minimum set of checks is performed when creating
            the intermediate object (e.g. (e.g., a DN application) application), a
            Registry MAY <bcp14>MAY</bcp14> effectively allocate the DN without performing
            the minimum set of checks again.
          </t>
          <t>
            Performing the minimum set of checks checks, Registries MUST <bcp14>MUST</bcp14>
            verify that:
            <list style='numbers'>

             <t>
                An
          </t>
          <ol spacing="normal" type="1">
	    <li>an SMD has been received from the Registrar Registrar, along with
            the DN registration.
              </t>

              <t>
                The registration,</li>
            <li>the certificate of the TMV has been correctly signed
            by the ICANN TMCH-CA. (The TMCH-CA (the certificate of the TMV is
            contained within the SMD.)
              </t>

              <t>
                The SMD),</li>
            <li>the datetime when the validation is done is within the validity period of the TMV certificate.
              </t>

              <t>
                The
	    certificate,</li>
            <li>the certificate of the TMV is not listed in the TMV CRL file
            specified in the CRL distribution point of the TMV
                certificate.
              </t>

              <t>
                The
            certificate,</li>
            <li>the signature of the SMD (signed with the TMV certificate)
            is valid.
              </t>

              <t>
                The valid,</li>
            <li>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.
              </t>

              <t>
                The elements,</li>
            <li>the SMD has not been revoked, i.e., is not contained in
            the SMD Revocation List.
              </t>

              <t>
                The List, and</li>
            <li>the leftmost DNL of the DN being
            effectively allocated matches one of the
                labels
            label (&lt;mark:label&gt;) elements in the SMD.
            For example, if the DN &quot;xn--mgbachtv.xn--mgbh0fb&quot; "xn--mgbachtv.xn--mgbh0fb" is
            being effectively allocated, the leftmost DNL would be &quot;xn--mgbachtv&quot;.
              </t>

            </list>
          </t> "xn--mgbachtv".</li>
          </ol>
          <t>
            These procedure procedures apply to all DN effective allocations at
            the second level level, as well as to all other levels
            subordinate to the TLD that the Registry accepts
            registrations for.
          </t>
        </section>
        <!-- <vspace blankLines='99' /> -->

        <section anchor="SunriseRy" title="TMDB numbered="true" toc="default">
          <name>TMDB Sunrise Services for Registries"> Registries</name>
          <section anchor="procDescSunriseSmdRevocList" title="SMD numbered="true" toc="default">
            <name>SMD Revocation List"> List</name>
            <t>
              A new SMD Revocation List MUST <bcp14>MUST</bcp14> be published by the TMDB
              twice a day, by 00:00:00 and 12:00:00 UTC.
            </t>
            <t>
              Registries MUST <bcp14>MUST</bcp14> refresh the latest version of the SMD
              Revocation List at least once every 24 hours.
            </t>
            <t>
              Note: the 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>

            <t>
            <figure anchor='figIntSmdRevocList'>
                <preamble>Update anchor="figIntSmdRevocList">
	      <name>Update of the SMD Revocation List</preamble>
                <artwork>
                  <![CDATA[ List</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
    .----------.                                             .------.
    | Registry |                                             | TMDB |
    '----------'                                             '------'
          |                                                      |
 .----------------.                                              |
 |  Periodically, |                                              |
 |    at least    |                                              |
 | every 24 hours |                                              |
 '----------------'                                              |
          |                                                      |
          |----------------------------------------------------->|
          |      Download the latest SMD Revocation List         |
          |<-----------------------------------------------------|
          |                                                      |
          |                                                      |
]]>
                </artwork>
]]></artwork>
            </figure>

            </t>
            <t><xref target="figIntSmdRevocList"/> target="figIntSmdRevocList" format="default"/> depicts the process of downloading the latest SMD Revocation List initiated by the Registry.</t>
          </section>
          <!-- <vspace blankLines='99' /> -->

          <section anchor="procDescSunriseCrl" title="TMV numbered="true" toc="default">
            <name>TMV Certificate Revocation List (CRL)"> (CRL)</name>
            <t>
              Registries MUST <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>
              Operationally, the TMV CRL file and CRL distribution point
              is
              are the same for all TMVs and (at publication of this
              document) are located at
              &lt;&nbsp;http://crl.icann.org/tmch.crl&nbsp;&gt;.
              <eref target="http://crl.icann.org/tmch.crl" brackets="angle"/>.
            </t>
            <t>
              Note: the 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>

            <t>
            <figure anchor='figIntCRL'>
                <preamble>Update anchor="figIntCRL">
	      <name>Update of the TMV CRL file</preamble>
                <artwork>
                  <![CDATA[ File</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
   .----------.                                .---------------.
   | Registry |                                | ICANN TMCH-CA |
   '----------'                                '---------------'
         |                                             |
 .----------------.                                    |
 | Periodically,  |                                    |
 |   at least     |                                    |
 | every 24 hours |                                    |
 '----------------'                                    |
         |                                             |
         |-------------------------------------------->|
         |     Download the latest TMV CRL file        |
         |<--------------------------------------------|
         |                                             |
         |                                             |
]]>
                </artwork>
]]></artwork>
            </figure>

            </t>
            <t><xref target="figIntCRL"/> target="figIntCRL" format="default"/> depicts the process of downloading the latest TMV CRL file initiated by the Registry.</t>
          </section>
          <!-- <vspace blankLines='99' /> -->

          <section anchor="procDescSunriseNordn" title="Notice numbered="true" toc="default">
            <name>Notice of Registered Domain Names (NORN)"> (NORDN)</name>
            <t>
              The Registry MUST <bcp14>MUST</bcp14> send a LORDN file containing
              DNs effectively allocated to the
              TMDB (over the yd interface, interface; see <xref target="yd" />). format="default"/>).
            </t>
            <t>
              The effective allocation of a DN MUST <bcp14>MUST</bcp14> be reported by the Registry to the TMDB
              within 26 hours of the effective allocation of such DN.
            </t>
            <t>
              The Registry MUST <bcp14>MUST</bcp14> create and upload a LORDN file in case there are effective allocations in the SRS, SRS
              that have not been successfully reported to the TMDB in a previous LORDN file.
            </t>
            <t>
              Based on the timers used by TMVs and the TMDB, the RECOMMENDED <bcp14>RECOMMENDED</bcp14> maximum frequency
              to upload LORDN files from the Registries to the TMDB is every 3 hours.
            </t>
            <t>
              It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that Registries try to upload at least two LORDN files per day to the TMDB TMDB,
              with enough time in between, in order to have time to fix problems reported in the LORDN file.
            </t>
            <t>
              The Registry SHOULD <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>
              The Registry MUST <bcp14>MUST</bcp14> upload LORDN files for DNs that are effectively allocated during the Sunrise or
              Trademark Claims Period Periods (same applies to DNs that are effectively allocated
              using applications created during the Sunrise or Trademark Claims Period Periods in case of using
              asynchronous registrations).
            </t>
            <t>
              The yd interface (<xref target="yd" />) MUST format="default"/>) <bcp14>MUST</bcp14> support at least one (1) and MAY <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>
              The TMDB MUST <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>
            <t>
            <figure anchor='figIntNordn'>
                <preamble>Notification anchor="figIntNordn">
	      <name>Notification of the Registered Domain Name</preamble>
                <artwork>
                  <![CDATA[ Name</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
     .----------.            .------.          .-----.         .-----.
     | Registry |            | TMDB |          | TMV |         | TMH |
     '----------'            '------'          '-----'         '-----'
           |                     |                |               |
 .------------------.            |                |               |
 | Periodically     |            |                |               |
 | upload LORDN     |            |                |               |
 | file             |            |                |               |
 '------------------'            |                |               |
           |                     |                |               |
.--------->|        Upload LORDN |                |               |
|          |-------------------->|                |               |
|          |                     |                |               |
|          |        .-------------------------.   |               |
|          |        | Verify each domain name |   |               |
|          |        | in the uploaded file    |   |               |
|          |        | (within 30')            |   |               |
|          |        '-------------------------'   |               |
|          |                     |         ._____.|               |
|          | Download Log file   |         | END ||               |
|          |<--------------------|         '-----'|               |
|          |                     |             ^  |               |
| .-----------------.    .---------------.     |  |               |
| |  Check whether  |   / everything fine \ no |  |               |
| |    Log file     |  (  (i.e. (i.e., no errors  )---'  |               |
| | contains errors |   \ in Log file )?  /       |               |
| '-----------------'    '---------------'        |               |
|          |                     | yes            |               |
|  .---------------.             |                |               |
| / everything fine \ yes        |                |               |
|(  (i.e. (i.e., no errors  )-----.     |    Notify TMVs |               |
| \ in Log file )?  /      |     |   on the LORDN |               |
|  '---------------'       |     | pre-registered |               |
|          | no            v     |  with said TMV |               |
| .----------------.   .------.  |--------------->|               |
'-| Correct Errors |   | DONE |  |                |               |
  '----------------'   '------'  |                |   Notify each |
           |                     |                |  affected TMH |
           |                     |                |-------------->|
           |                     |                |               |
]]>
                </artwork>
]]></artwork>
            </figure>
            </t>
            <t><xref target="figIntNordn"/> target="figIntNordn" format="default"/> depicts the process to notify the TMH of Registered Domain Names.</t>
            <t>
              The format used for the LORDN is described in <xref target='lordnFormat' /> target="lordnFormat" format="default"/>.
            </t>
          </section>
        </section>

        <!-- <vspace blankLines='99' /> -->

        <section anchor="procDescSunriseResRr" title="Sunrise numbered="true" toc="default">
          <name>Sunrise Domain Name registration Registration by Registrars"> Registrars</name>
          <t>
            Registrars MAY <bcp14>MAY</bcp14> choose to perform the checks for verifying
            DN registrations registrations, as performed by the Registries (see <xref target="procDescSunriseResRy" />) format="default"/>) before sending the
            command to register a DN.
          </t>
        </section>

        <!-- <vspace blankLines='99' /> -->

        <section anchor="SunriseRr" title="TMDB numbered="true" toc="default">
          <name>TMDB Sunrise Services for Registrars"> Registrars</name>
          <t>
             The processes described in Sections <xref target="procDescSunriseSmdRevocList" /> format="counter"/> and <xref target="procDescSunriseCrl" /> format="counter"/> are also available for
             Registrars to optionally validate the SMDs received.
          </t>
          <t><vspace blankLines='99' /></t>
          <t/>
        </section>
      </section> <!-- End procSunrise -->
      <!-- <vspace blankLines='99' /> -->

      <section anchor="procDescTrCl" title="Trademark numbered="true" toc="default">
        <name>Trademark Claims Period"> Period</name>
        <section anchor="procDescTrClReg" title="Domain Registration">

          <t> numbered="true" toc="default">
          <name>Domain Registration</name>
          <figure anchor='figIntTmcPeriod'>
              <preamble>Domain anchor="figIntTmcPeriod">
	    <name>Domain Name registration Registration during the Trademark Claims Period</preamble>
              <artwork>
                <![CDATA[ Period</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
 .------------.   .-----------.                 .----------.   .------.
 | Registrant |   | Registrar |                 | Registry |   | TMDB |
 '------------'   '-----------'                 '----------'   '------'
        |     Request DN |                            |            |
        |   registration |                            |            |
        |--------------->|     Check DN availability  |            |
        |                |--------------------------->|            |
        |                | DN unavailable      .-------------.     |
        | DN unavailable |<-------------------( DN available? )    |
        |<---------------|                  no '-------------'     |
        |                | DN available               | yes        |
        |                |<---------------------------|            |
        |                |         Request Lookup lookup key |            |
        |                |--------------------------->|            |
        |                |.__________.           .---------.       |
        |                || CONTINUE |          /  Does DN  \      |
        |                || NORMALLY |<--------(  match DNL  )     |
        |                |'----------'       no \  of PRM?  /      |
        |                |                       '---------'       |
        |                | Lookup key                  | yes       |
        |                |<----------------------------'           |
        |                |                                         |
.-----. |                |                             Request TCN |
|ABORT| | Display        |---------------------------------------->|
'-----' | Claims         | Return TCN                              |
 ^      | Notice         |<----------------------------------------|
 | no   |<---------------|                                         |
 |  .------.  yes        |                                         |
 '-(  Ack?  )----------->|   Register DN (with TCNID) |            |
    '------'             |--------------------------->|            |
        | Registration   | Error         .----------------------.  |
        | error          |<-------------( Validation successful? ) |
        |<---------------|            no '----------------------'  |
        |                |                            | yes        |
        |                | DN registered              |            |
        | DN registered  |<---------------------------|            |
        |<---------------|                            |            |
]]>
              </artwork>
]]></artwork>
          </figure>
          </t>
          <t><xref target="figIntTmcPeriod"/> target="figIntTmcPeriod" format="default"/> represents a synchronous DN registration
            workflow (usually called first come first served).</t>
        </section>
        <!-- <vspace blankLines='99' /> -->

        <section anchor="procDescTrClResRr" title="Trademark numbered="true" toc="default">
          <name>Trademark Claims Domain Name registration Registration by Registries"> Registries</name>
          <t>
            During the Trademark Claims Period, Registries perform two main functions:
            <list style="symbols">

              <t>
                Registries MUST
          </t>
          <ul spacing="normal">
            <li>Registries <bcp14>MUST</bcp14> provide Registrars (over the ry interface, interface; see
            <xref target="ry" />) format="default"/>) the Lookup Key lookup key used
            to retrieve the TCNs for DNs that
            match the DNL List.
              </t>
              <t>
                Registries MUST List.</li>
            <li>Registries <bcp14>MUST</bcp14> provide the Lookup Key lookup key only when queried
            about a specific DN.
              </t>

              <t>
                For DN.</li>
	  </ul>
	  <t>In the following instances, a minimum set of checks are described:</t>
	  <ul spacing="normal">
            <li>For each DN matching a DNL of a PRM, Registries MUST <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"/>).  If any of these
            checks fails fail, the Registry MUST <bcp14>MUST</bcp14> abort the registration.
            Each of these checks MUST <bcp14>MUST</bcp14> be performed
            before the DN is effectively allocated.
              </t>
              <t>
                In allocated.</li>
            <li>In case of asynchronous registrations (e.g. (e.g., auctions),
            the minimum set of checks MAY <bcp14>MAY</bcp14> be performed when creating
            the intermediate object (e.g. (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. (e.g., a DN application) application), a
            Registry MAY <bcp14>MAY</bcp14> effectively allocate the DN without performing
            the minimum set of checks again.
              </t>
              <t>
                Performing again.</li>
            <li>
              <t>Performing the minimum set of checks checks, Registries MUST <bcp14>MUST</bcp14>
              verify that:
                <list style='numbers'>

                  <t>
                    The that:</t>
              <ol spacing="normal" type="1">
		<li>
                  <t>The TCNID (&lt;tmNotice:id&gt;), expiration datetime (&lt;tmNotice:notAfter&gt;)
		  (&lt;tmNotice:notAfter&gt;), and acceptance datetime of the TCN, TCN
                  have been received from the Registrar Registrar, along with the DN
                    registration.
                  <list style="empty">
                    <t>
                      If
                  registration.</t>
                  <t>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 re-inserted) reinserted) for the first time
                  into the DNL List less than 24 hours ago, the registration MAY <bcp14>MAY</bcp14>
                  continue without this data data, and the tests listed
                  below are not required to be performed.
                    </t>
                  </list>
                  </t>
                  <t>
                    The performed.</t>
                </li>
                <li>The TCN has not expired (according to the
                expiration datetime sent by the Registrar).
                  </t>

                  <t>

                    The Registrar).</li>
                <li>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.

                  </t>
                  <t>
                    Using future.</li>

                <li>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 compute the TCN Checksum. Registrar. Verify that the computed TCN Checksum match Cheksum matches the
		TCN Checksum present in the TCNID. For example, if the
		DN &quot;xn--mgbachtv.xn--mgbh0fb&quot; "xn--mgbachtv.xn--mgbh0fb" is
                being effectively allocated, the leftmost DNL would be &quot;xn--mgbachtv&quot;.
                  </t>
                </list>

              </t>
            </list>
          </t> "xn--mgbachtv".</li>
              </ol>
            </li>
          </ul>
          <t>
            These procedures apply to all DN registrations at
            the second level level, as well as to all other levels
            subordinate to the TLD that the Registry accepts
            registrations for.
          </t>
        </section>
        <!-- <vspace blankLines='99' /> -->

        <section anchor="claimsServicesRy" title="TMBD numbered="true" toc="default">
          <name>TMDB Trademark Claims Services for Registries"> Registries</name>
          <section anchor="procDescUpdateDnlList" title="Domain numbered="true" toc="default">
            <name>Domain Name Label (DNL) List"> List</name>
            <t>
              A new DNL List MUST <bcp14>MUST</bcp14> be published by the TMDB twice a day,
              by 00:00:00 and 12:00:00 UTC.
            </t>
            <t>
              Registries MUST <bcp14>MUST</bcp14> refresh the latest version of the DNL
              List at least once every 24 hours.
            </t>
            <t>
            <figure anchor='figIntDnlList'>
                <preamble>Update anchor="figIntDnlList">
	      <name>Update of the DNL List</preamble>
                <artwork>
                  <![CDATA[ List</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
    .----------.                        .------.
    | Registry |                        | TMDB |
    '----------'                        '------'
          |                                 |
 .----------------.                         |
 |  Periodically, |                         |
 |    at least    |                         |
 | every 24 hours |                         |
 '----------------'                         |
          |                                 |
          |-------------------------------->|
          |  Download the latest DNL List   |
          |<--------------------------------|
          |                                 |
          |                                 |
]]>
                </artwork>
]]></artwork>
            </figure>
            </t>
            <t><xref target="figIntDnlList"/> target="figIntDnlList" format="default"/> depicts the process of downloading the latest DNL list List initiated by the Registry.</t>
            <t>
              Note: the 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>
          <!-- <vspace blankLines='99' /> -->

          <section anchor="procDescTrClNordn" title="Notice numbered="true" toc="default">
            <name>Notice of Registered Domain Names (NORN)"> (NORDN)</name>
            <t>
              The NORDN process during the Trademark Claims Period is
              almost the same as during the Sunrise Period Period, as defined in
              <xref target="procDescSunriseNordn" /> with format="default"/>;
	      the difference is that only registrations subject to a
              Trademark Claim (i.e., at registration time time, the name
              appeared in the current DNL List downloaded by the Registry Operator) are
              included in the LORDN.
            </t>
          </section>
        </section>
        <!-- <vspace blankLines='99' /> -->

        <section title="Trademark numbered="true" toc="default">
          <name>Trademark Claims Domain Name registration Registration by Registrars"> Registrars</name>
          <t>
            For each DN matching a DNL of a PRM, Registrars MUST <bcp14>MUST</bcp14>
            perform the following steps:
            <list style='numbers'>

              <t>
                Use
          </t>
          <ol spacing="normal" type="1">
	    <li>Use the Lookup Key lookup key received from the Registry
            to obtain the TCN from the TMDB
            using the dr interface (<xref target="dr" />) format="default"/>).
            Registrars MUST <bcp14>MUST</bcp14> only query for the Lookup Key lookup key of a DN
            that is available for registration.
              </t>

              <t>
                Present registration.</li>
            <li>Present the TCN to the Registrant Registrant, as
            described in Exhibit A, A of <xref target='RPM-Requirements'/>.
              </t>

              <t>
                Ask target="RPM-Requirements" format="default"/>.</li>
            <li>Ask the Registrant for acknowledgement, i.e. i.e., the Registrant
                MUST
            <bcp14>MUST</bcp14> consent with the TCN, before any
            further processing. (The transmission of a TCNID
            to the Registry over the ry
                interface, <xref
            interface (<xref target="ry" /> format="default"/>) implies that the
            Registrant has expressed his/her their consent with the TCN.)
              </t>

              <t>
                Perform TCN.)</li>
            <li>
              <t>Perform the minimum set of checks for verifying DN
              registrations.  If any of these checks fails fail, the
              Registrar MUST <bcp14>MUST</bcp14> abort the DN registration. Each of
              these checks MUST <bcp14>MUST</bcp14> be performed before the registration
              is sent to the Registry.
              Performing the minimum set of checks checks, Registrars MUST <bcp14>MUST</bcp14> verify
                that:
                <list style='numbers'>

                  <t>
                    The
              the following:</t>
              <ol spacing="normal" type="a">
		<li>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.
                  </t>
                  <t>
                    The elements.</li>
                <li>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 &quot;xn--mgbachtv.xn--mgbh0fb&quot; "xn--mgbachtv.xn--mgbh0fb" is
                being effectively allocated, the leftmost DNL would be &quot;xn--mgbachtv&quot;.
                  </t>

                  <t>
                    The "xn--mgbachtv".</li>
                <li>The Registrant has acknowledged (expressed his/her their consent
                with) the TCN.
                  </t>

                </list>
              </t>

              <t>
                Record TCN.</li>
              </ol>
            </li>
            <li>Record the date and time when the registrant
            acknowledged the TCN.
              </t>

              <t>
                Send TCN.</li>
            <li>
              <t>Send the registration to the Registry (ry interface, (via the ry interface; see
              <xref target="ry" />) format="default"/>) and include the following information:
                <list style='symbols'>

                  <t>
                    TCNID (&lt;tmNotice:id&gt;)
                  </t>
                  <t>
                    Expiration information:</t>
              <ul spacing="normal">
                <li>TCNID (&lt;tmNotice:id&gt;)</li>
                <li>Expiration date of the TCN
                    (&lt;tmNotice:notAfter&gt;)
                </t>
                  <t>
                    Acceptance
                (&lt;tmNotice:notAfter&gt;)</li>
                <li>Acceptance datetime of the TCN.
                  </t>

                </list>
              </t>

            </list>
          </t>

         <t>

             Currently TCN</li>
              </ul>
            </li>
          </ol>
          <t>Currently, TCNs are generated twice a day by the TMDB.
             The expiration date (&lt;tmNotice:notAfter&gt;) of each TCN MUST <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 in to into
               the future 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>
            Registrars SHOULD future.</t>
          <t>Registrars <bcp14>SHOULD</bcp14> implement a cache of TCNs to
            minimize the number of queries sent to the TMDB.
            A cached TCN MUST <bcp14>MUST</bcp14> be removed from the cache after
            the expiration date of the TCN TCN, as defined by
            &lt;tmNotice:notAfter&gt;.
          </t>
          <t>
            The TMDB MAY <bcp14>MAY</bcp14> implement rate-limiting rate limiting as one of the protection
            mechanisms to mitigate the risk of performance degradation.
          </t>
        </section>
        <!-- <vspace blankLines='99' /> -->

        <section anchor="claimsServicesRr" title="TMBD numbered="true" toc="default">
          <name>TMDB Trademark Claims Services for Registrars"> Registrars</name>
          <section anchor="cnisService" title="Claims numbered="true" toc="default">
            <name>Claims Notice Information Service (CNIS)"> (CNIS)</name>
            <t>
              The TCNs are provided by the TMDB
              online and are fetched by the Registrar via the dr
              interface (<xref target="dr" />). format="default"/>).
            </t>
            <t>
              To get access to the
              TCNs, the Registrar needs the
              credentials provided by the TMDB (<xref target="procDescBootstrapCredentialsRr" />) format="default"/>) and the Lookup
              Key lookup
              key received from the Registry via the ry interface (<xref target="ry" />). format="default"/>). The dr interface (<xref target="dr" />) format="default"/>)
              uses HTTPS with Basic access authentication.
            </t>
            <t>
              The dr interface (<xref target="dr" />) MAY format="default"/>) <bcp14>MAY</bcp14> support up to
              ten (10) concurrent connections from each Registrar.
            </t>
            <t>
              The URL of the dr interface (<xref target="dr" />) format="default"/>) is:
              <list style="empty">
                <t>
                  &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/cnis/&lt;lookupkey&gt;.xml&nbsp;&gt;
            </t>
              </list>
	       <t indent="3">https://&lt;tmdb-domain-name&gt;/cnis/&lt;lookupkey&gt;.xml
	     </t>
            <t>
              Note that the "lookupkey" may contain SLASH slash characters ("/").
              The SLASH slash character is part of the URL path and MUST NOT <bcp14>MUST NOT</bcp14>
              be escaped when requesting the TCN.
            </t>
            <t>
              The TLS certificate (HTTPS) used on the dr interface
              (<xref target="dr" />) MUST format="default"/>) <bcp14>MUST</bcp14> be signed by a well-know
              public CA. Registrars MUST <bcp14>MUST</bcp14> perform the Certification Path Validation certification path validation
              described in Section 6 of <xref target='RFC5280'
              />. target="RFC5280" section="6" sectionFormat="of"/>.
              Registrars will be authenticated
              in the dr interface using HTTP Basic access authentication.

              The dr interface (<xref target="dr" />) interface MUST format="default"/>) <bcp14>MUST</bcp14> support HTTPS
              keep-alive and MUST <bcp14>MUST</bcp14> maintain the connection for up to 30 minutes.
            </t>
          </section>
        </section>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="procDescQLP" title="Qualified numbered="true" toc="default">
        <name>Qualified Launch Program (QLP) Period"> Period</name>
        <section title="Domain Registration"> numbered="true" toc="default">
          <name>Domain Registration</name>
          <t>
            During the OPTIONAL (see <xref target='QLP-Addendum' />) <bcp14>OPTIONAL</bcp14> Qualified Launch Program (QLP) Period (see <xref target="QLP-Addendum" format="default"/>), 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 MUST <bcp14>MUST</bcp14> provide Sunrise and/or Trademark Claims services services, as described in Sections
            <xref target="procDescSunrise" /> format="counter"/> and <xref target="procDescTrCl" />. format="counter"/>.
          </t>
          <t>
            The effective allocation scenarios are:
            <list style="symbols">

            <t>
            If are as follows:
          </t>
          <ul spacing="normal">
            <li>If the leftmost DNL of the DN being
            effectively allocated (QLP Name in this section) matches a DNL in the SURL, SURL and an SMD is provided, then
            Registries MUST <bcp14>MUST</bcp14> provide Sunrise Services (see <xref target="procDescSunrise" />) format="default"/>), and
              the DN MUST <bcp14>MUST</bcp14> be reported in a Sunrise LORDN file during the QLP Period. For example, if the DN &quot;xn--mgbachtv.xn--mgbh0fb&quot; "xn--mgbachtv.xn--mgbh0fb" is
              being effectively allocated, the leftmost DNL would be &quot;xn--mgbachtv&quot;.
            </t>
              <t>
                If "xn--mgbachtv".</li>
            <li>If the QLP Name matches a DNL in the SURL but does not match a DNL in the DNL List, List and an SMD is NOT provided (see section Section
                2.2 of <xref target='QLP-Addendum' />), target="QLP-Addendum" format="default"/>), then
                the DN MUST <bcp14>MUST</bcp14> be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP Period.
              </t>
              <t>
            If Period.</li>
            <li>If the QLP Name matches a DNL in the SURL and also matches a DNL in the DNL List, List and an SMD is NOT provided (see section Section
            2.2 of <xref target='QLP-Addendum' />), target="QLP-Addendum" format="default"/>), then
                Registries MUST <bcp14>MUST</bcp14> provide Trademark Claims services (see <xref target="procDescTrCl" />) format="default"/>), and
            the DN MUST <bcp14>MUST</bcp14> be reported in a Trademark Claims LORDN file during the QLP Period.
              </t>
              <t>
            If Period.</li>
            <li>If the QLP Name matches a DNL in the DNL List but does not match a DNL in the SURL, then
            Registries MUST <bcp14>MUST</bcp14> provide Trademark Claims services (see <xref target="procDescSunrise" />) target="procDescTrCl" format="default"/>), and
            the DN MUST <bcp14>MUST</bcp14> be reported in a Trademark Claims LORDN file during the QLP Period.
              </t>
            </list>
            <vspace blankLines='99' />
          </t>
          <!-- <vspace blankLines='99' /> --> Period.</li>
          </ul>

          <t>
            The following table lists all the effective allocation scenarios during a QLP Period:
          </t>
            <texttable  title="QLP
          <table align="center">
            <name>QLP Effective Allocation Scenarios">
              <ttcol align='left'>
                QLP Scenarios</name>
            <thead>
              <tr>
                <th align="left">QLP Name match Match in the SURL
              </ttcol>
              <ttcol align='left'>
                QLP SURL</th>
                <th align="left">QLP Name match Match in the DNL List
              </ttcol>
              <ttcol align='left'>
                SMD was provided List</th>
                <th align="left">SMD Was Provided by the potential Registrant
              </ttcol>
              <ttcol align='left'>
                Registry MUST provide Potential Registrant</th>
                <th align="left">Registry <bcp14>MUST</bcp14> Provide Sunrise or Trademark Claims Services
              </ttcol>
              <ttcol align='left'>
                Registry MUST report Services</th>
                <th align="left">Registry <bcp14>MUST</bcp14> Report DN registration Registration in &lt;type&gt; LORDN file
              </ttcol>
              <c>
                Y
              </c>
              <c>
                Y
              </c>
              <c>
                Y
              </c>
              <c>
                Sunrise
              </c>
              <c>
                Sunrise
              </c>
              <c>
                Y
              </c>
              <c>
                N
              </c>
              <c>
                Y
              </c>
              <c>
                Sunrise
              </c>
              <c>
                Sunrise
              </c>
              <c>
                N
              </c>
              <c>
                Y
              </c>
              <c>
                --
              </c>
              <c>
                Trademark Claims
              </c>
              <c>
                Trademark Claims
              </c>
              <c>
                N
              </c>
              <c>
                N
              </c>
              <c>
                --
              </c>
              <c>
                --
              </c>
              <c>
                --
              </c>
              <c>
                Y
              </c>
              <c>
                Y
              </c>
              <c>
                N File</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">Y</td>
                <td align="left">Y</td>
                <td align="left">Y</td>
                <td align="left">Sunrise</td>
                <td align="left">Sunrise</td>
              </tr>
              <tr>
                <td align="left">Y</td>
                <td align="left">N</td>
                <td align="left">Y</td>
                <td align="left">Sunrise</td>
                <td align="left">Sunrise</td>
              </tr>
              <tr>
                <td align="left">N</td>
                <td align="left">Y</td>
                <td align="left">--</td>
                <td align="left">Trademark Claims</td>
                <td align="left">Trademark Claims</td>
              </tr>
              <tr>
                <td align="left">N</td>
                <td align="left">N</td>
                <td align="left">--</td>
                <td align="left">--</td>
                <td align="left">--</td>
              </tr>
              <tr>
                <td align="left">Y</td>
                <td align="left">Y</td>
                <td align="left">N (see section Section
                2.2 of <xref target='QLP-Addendum' />)
              </c>
              <c>
                Trademark Claims
              </c>
              <c>
                Trademark Claims
              </c>
              <c>
                Y
              </c>
              <c>
                N
              </c>
              <c>
                N target="QLP-Addendum" format="default"/>)</td>
                <td align="left">Trademark Claims</td>
                <td align="left">Trademark Claims</td>
              </tr>
              <tr>
                <td align="left">Y</td>
                <td align="left">N</td>
                <td align="left">N (see section Section
                2.2 of <xref target='QLP-Addendum' />)
              </c>
              <c>
                --
              </c>
              <c>
                Sunrise target="QLP-Addendum" format="default"/>)</td>
                <td align="left">--</td>
                <td align="left">Sunrise (using special SMD-id)
              </c>
            </texttable> SMD-id)</td>
              </tr>
            </tbody>
          </table>
          <t>
            The TMDB MUST <bcp14>MUST</bcp14> provide the following services to Registries during a QLP Period:
            <list style="symbols">
              <t>
          </t>
          <ul spacing="normal">
            <li> SMD Revocation List (see <xref target="procDescSunriseSmdRevocList"/>) </t>
              <t> NORN target="procDescSunriseSmdRevocList" format="default"/>) </li>
            <li> NORDN (see <xref target="procDescSunriseNordn"/>) </t>
              <t> target="procDescSunriseNordn" format="default"/>) </li>
            <li> DNL List (see <xref target="procDescUpdateDnlList"/>) </t>
              <t> target="procDescUpdateDnlList" format="default"/>) </li>
            <li> Sunrise List (SURL) (see <xref target="procDescUpdatesurlList"/></t>
            </list>
          </t> target="procDescUpdatesurlList" format="default"/>)</li>
          </ul>
          <t>
            The TMDB MUST <bcp14>MUST</bcp14> provide the following services to Registrars during a QLP Period:
            <list style="symbols">
              <t>
          </t>
          <ul spacing="normal">
            <li> SMD Revocation List (see <xref target="procDescSunriseSmdRevocList"/>) </t>
              <t> target="procDescSunriseSmdRevocList" format="default"/>) </li>
            <li> CNIS (see <xref target="cnisService"/>) </t>
            </list>
          </t> target="cnisService" format="default"/>) </li>
          </ul>
        </section>
        <section title="TMBD numbered="true" toc="default">
          <name>TMDB QLP Services for Registries"> Registries</name>
          <section anchor="procDescUpdatesurlList" title="Sunrise numbered="true" toc="default">
            <name>Sunrise List (SURL)"> (SURL)</name>
            <t> A new Sunrise List (SURL) MUST SURL <bcp14>MUST</bcp14> be published by the TMDB twice a day, by 00:00:00 and 12:00:00
              UTC. </t>
            <t> Registries offering the OPTIONAL <bcp14>OPTIONAL</bcp14> QLP Period MUST <bcp14>MUST</bcp14> refresh the latest version of the SURL at least once every 24
            hours. </t>
            <t>
            <figure anchor="figIntsurlList">
                <preamble>Update
	      <name>Update of the SURL</preamble>
                <artwork>
                  <![CDATA[ SURL</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
    .----------.                       .------.
    | Registry |                       | TMDB |
    '----------'                       '------'
          |                                |
 .----------------.                        |
 |  Periodically, |                        |
 |    at least    |                        |
 | every 24 hours |                        |
 '----------------'                        |
          |                                |
          |------------------------------->|
          |    Download the latest SURL    |
          |<-------------------------------|
          |                                |
          |                                |
]]>
                </artwork>
]]></artwork>
            </figure>

            </t>
            <t><xref target="figIntsurlList"/> target="figIntsurlList" format="default"/> depicts the process of downloading the latest SURL initiated by the Registry.</t>
            <t> Note: the 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>
    <!-- <vspace blankLines='99' /> -->

    <section anchor="dataFormat" title="Data numbered="true" toc="default">
      <name>Data Format Descriptions"> Descriptions</name>
      <section anchor="dnlListFormat" title="Domain numbered="true" toc="default">
        <name>Domain Name Label (DNL) List"> List</name>
        <t>
          This section defines the format of the list containing every
          Domain Name Label (DNL)
          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"/>). 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>
	  The DNL List contains all the DNLs covered by a PRM present in the TMDB at the
	  datetime it that the DNL List is generated.
        </t>
        <t>
          The DNL List is contained in a CSV formatted CSV-formatted file that has the
          following structure:

          <list style='symbols'>

            <t>
              first

        </t>
        <ul spacing="normal">
          <li>
            <t>first line: &lt;version&gt;,&lt;DNL List creation datetime&gt;
              <list style='empty'>
                <t>Where:
                  <list style='symbols'>
                    <t>
                      &lt;version&gt;, datetime&gt;</t>
	    <ul empty="true" spacing="normal">
	      <li>
		<t>Where:</t>
                <ul spacing="normal">
                  <li>&lt;version&gt;: version of the file, this file. This field MUST <bcp14>MUST</bcp14> be 1.
                    </t>
                    <t>
                      &lt;DNL 1.</li>
                  <li>&lt;DNL List creation datetime&gt;, datetime&gt;: date and time in UTC that the DNL List was created.
                    </t>
                  </list>
                </t>
              </list>
            </t>

            <t>
              second created.</li>
                </ul>
              </li>
	    </ul>
	  </li>
              <li>
            <t>second line: a header line line, as specified in <xref target="RFC4180"/>
              <list style='empty'>
                <t>With target="RFC4180" format="default"/></t>
	    <ul empty="true" spacing="normal">
              <li>With the header names as follows:</t>
                <t>DNL,lookup-key,insertion-datetime</t>
              </list>
            </t>

            <t>
              One follows:</li>
              <li>DNL,lookup-key,insertion-datetime</li>
	    </ul>
          </li>
          <li>
            <t>One or more lines with: &lt;DNL&gt;,&lt;lookup key&gt;,&lt;DNL insertion datetime&gt;
              <list style='empty'>
                <t>Where:
                  <list style='symbols'>
                    <t>
                      &lt;DNL&gt;, datetime&gt;</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>Where:</t>
                <ul spacing="normal">
                  <li>&lt;DNL&gt;: a Domain Name Label covered by a PRM.
                    </t>

                    <t>
                      &lt;lookup key&gt;, PRM.</li>
                  <li>
                    <t>&lt;lookup key&gt;: lookup key that the Registry MUST <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:
                      <list style="symbols">
                        <t>
                          YYYY: where:</t>
                    <ul spacing="normal">
                      <li>YYYY: year that the TCN was generated.
                        </t>
                        <t>
                          MM: generated.</li>
                      <li>MM: zero-padded month that the TCN was generated.
                        </t>
                        <t>
                          DD: generated.</li>
                      <li>DD: zero-padded day that the TCN was generated.
                        </t>
                        <t>
                          vv: generated.</li>
                      <li>vv: version of the TCN, TCN; possible values are 00 and 01.
                        </t>
                        <t>
                          X: 01.</li>
                      <li>X: one hex character. This is the first, second second, and third hex character of encoding the
                          &lt;Random bits&gt; in base16 base16, as specified in <xref target="RFC4648"/>.
                        </t>
                        <t>
                          Random target="RFC4648" format="default"/>.</li>
                      <li>Random bits: 144 random bits encoded in base64url base64url, as specified in <xref target="RFC4648"/>.
                        </t>
                        <t>
                          Sequential target="RFC4648" format="default"/>.</li>
                      <li>Sequential number: zero-padded natural number in the range 0000000001 to 2147483647.
                        </t>
                      </list>
                    </t>
                    <t> 2147483647.</li>
                    </ul>
                  </li>
                  <li>
                      &lt;DNL insertion datetime&gt;, 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.
                    </t>
                  </list>
                </t>
              </list>
            </t>
          </list>

        </t>

        <figure>
          <preamble>Example
                    </li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
<t>Example of a DNL List:</preamble>
          <artwork>
              <![CDATA[ list:</t>
<figure>
  <name>Example DNL List</name>
<sourcecode type=""><![CDATA[
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
]]>
            </artwork>
]]></sourcecode>
</figure>
        <t>
          To provide authentication and integrity protection, the DNL
          List will be PGP <xref target="RFC4880" /> format="default"/> signed by the TMDB (see also <xref target="procDescBootstrapPgpKeyRy" />). format="default"/>).  The PGP signature of the
          DNL List can be found in the similar URI but with extension .sig .sig, as shown below.
        </t>
        <t>
          The URL URLs of the dy interface (<xref target="dy" />) is:
          <list style="symbols">
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/dnl/dnl-latest.csv&nbsp;&gt;
            </t>
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/dnl/dnl-latest.sig&nbsp;&gt;
            </t>
          </list> format="default"/>) are:
        </t>
        <ul spacing="normal">
          <li>
              https://&lt;tmdb-domain-name&gt;/dnl/dnl-latest.csv
            </li>
          <li>
              https://&lt;tmdb-domain-name&gt;/dnl/dnl-latest.sig
            </li>
        </ul>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="revocationlistFormat" title="SMD numbered="true" toc="default">
        <name>SMD Revocation List"> List</name>
        <t>
          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"/>). 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' />. target="RFC5280" format="default"/>.
        </t>
        <t>
          The SMD Revocation List contains all the revoked SMDs present in
          the TMDB at the datetime it is generated.
        </t>
        <t>
          The SMD Revocation List is contained in a CSV formatted CSV-formatted file that has
          the following structure:

          <list style='symbols'>

        </t>
        <ul spacing="normal">
          <li>
            <t>
              first line: &lt;version&gt;,&lt;SMD Revocation List creation datetime&gt;
            <list style='empty'>
              <t>Where:
              <list style='symbols'>
                <t>
                  &lt;version&gt;,
            </t>
            <ul empty="true" spacing="normal">
              <li>
                <t>Where:</t>
                <ul spacing="normal">
                  <li>&lt;version&gt;: version of the file, this file. This field MUST <bcp14>MUST</bcp14> be 1.
                </t>
                <t>
                  &lt;SMD 1.</li>
                  <li>&lt;SMD Revocation List creation datetime&gt;, datetime&gt;: datetime in UTC that the SMD Revocation List was created.
                </t>
              </list>
              </t>
            </list>
            </t>

            <t>
              second created.</li>
                </ul>
              </li>
            </ul>
          </li>
          <li>
            <t>second line: a header line line, as specified in <xref target="RFC4180"/>
            <list style='empty'>
              <t>With target="RFC4180" format="default"/></t>
            <ul empty="true" spacing="normal">
              <li>With the header names as follows:</t>
              <t>smd-id,insertion-datetime</t>
            </list>
            </t>

            <t>
              One follows:</li>
              <li>smd-id,insertion-datetime</li>
            </ul>
          </li>
          <li>
            <t>One or more lines with: &lt;smd-id&gt;,&lt;revoked SMD datetime&gt;
            <list style='empty'>
              <t>Where:
              <list style='symbols'>
                <t>
                  &lt;smd-id&gt;, datetime&gt;</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>Where:</t>
                <ul spacing="normal">
                  <li>&lt;smd-id&gt;: identifier of the SMD that was revoked.
                </t>
                <t>
                  &lt;revoked revoked.</li>
                  <li>&lt;revoked SMD datetime&gt;, 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.
                </t>
              </list>
              </t>
            </list>
            </t>
          </list>

        </t> UTC.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <t>
          To provide integrity protection, the SMD Revocation List is
          PGP signed by the TMDB (see also <xref target="procDescBootstrapPgpKeyRy" />). format="default"/>).  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 .sig, as shown below.
        </t>
        <t>
          The URL URLs of the sr interface (<xref target="sr" />) format="default"/>) and
          sy interface (<xref target="sy" />) is:
          <list style='symbols'>
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.csv&nbsp;&gt;
            </t>
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.sig&nbsp;&gt;
            </t>
          </list> format="default"/>) are:
        </t>

          <figure>
            <preamble>Example
        <ul spacing="normal">
          <li>https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.csv</li>
          <li>https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.sig</li>
        </ul>
	<t>Example of an SMD Revocation List:</preamble>
            <artwork>
              <![CDATA[ List:</t>
	<figure>
	  <name>Example SMD Revocation List</name>
	<sourcecode type=""><![CDATA[
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
]]>
            </artwork>
]]></sourcecode>
	</figure>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="lordnFormat" title="List numbered="true" toc="default">
        <name>List of Registered Domain Names (LORDN) file"> File</name>
        <t>
          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 PRM, said DN is added to the LORDN LORDN, along with
          further information related to its registration.
        </t>
        <t>
          The URIs of the yd interface (<xref target="yd" />) format="default"/>) used to
          upload the LORDN file is:
          <list style="symbols">
            <t>
              Sunrise are:
        </t>
        <ul spacing="normal">
          <li>
            <t>Sunrise LORDN file:
              <list style="empty">
                <t>
                  &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise&nbsp;&gt;
                </t>
              </list> </t>
            <t>
              Trademark
            <t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise</t>
          </li>
          <li>
            <t>Trademark Claims LORDN file:
              <list style="empty">
                <t>
                  &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims&nbsp;&gt;
                </t>
              </list>
            </t>
          </list> </t>
            <t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims</t>
          </li>
        </ul>
        <t>
          During a QLP Period, Registries MAY <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 is:
          <list style="symbols">
            <t>
              Sunrise are:
        </t>
        <ul spacing="normal">
          <li>
            <t>Sunrise LORDN file (during QLP Period):
              <list style="empty">
                <t>
                  &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/qlp&nbsp;&gt; </t>
              </list>
            </t>
            <t>
              Trademark
            <t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/qlp</t>
          </li>
          <li>
            <t>Trademark Claims LORDN file (during a QLP Period):
              <list style="empty">
                <t>
                  &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp&nbsp;&gt;
                </t>
              </list>
            </t>
          </list>
        </t> Period):</t>
            <t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp</t>
          </li>
        </ul>
        <t>
          The yd interface (<xref target="yd" />) format="default"/>) returns the following HTTP status codes after a an HTTP POST request method is
          received:
        <list style="symbols">
          <t>
            The
        </t>
        <ul spacing="normal">
          <li>
            <t>The interface provides a an HTTP/202 status code if the interface was
            able to receive the LORDN file and the syntax of the LORDN file is correct.
            <list style="empty">
              <t>
                The correct.</t>
              <t>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
                zero-padded
                 in the range 0000000000000000001 to 9223372036854775807.
              </t>
              <t>
                The
              <t>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 MUST <bcp14>MUST</bcp14> be provided to the Registry. The TMDB MUST <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>
                The
              <t>The HTTP Location header field contains
              the URI where the LORDN Log file could be retrieved later, for example:
                <list style="empty">
                  <t>
                    202 Accepted
                  </t>
                  <t>
                    Location: https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/0000000000000000001/result
                  </t>
                </list>
              </t>
            </list>
          </t>
          <t> example:</t>
	      <ul spacing="normal" empty="true">
              <li>
              <t>202 Accepted</t>
              <t>Location: https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/0000000000000000001/result</t>
              </li>
	      </ul></li></ul>

	   <ul spacing="normal">
          <li> The interface provides a an HTTP/400 if the request is incorrect or
          the syntax of the LORDN file is incorrect.
          The TMDB MUST <bcp14>MUST</bcp14> return a human readable human-readable message in the HTTP Entity-body
          regarding the incorrect syntax of the LORDN file.
          </t>
          <t>
            The file.</li>
          <li>The interface provides a an HTTP/401 status code if the credentials
          provided does do not authorize the Registry Operator to upload a LORDN file.
          </t>
          <t>
            The file.</li>
          <li>The TMDB MUST <bcp14>MUST</bcp14> return a 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.
          </t>
          <t>
          </li>
          <li> The interface provides a an HTTP/500 status code if the system is
            experiencing a general failure.
          </t>
        </list>
        </t> failure.</li>
           </ul>

        <t>
          For example, to upload the Sunrise LORDN file for TLD &quot;example&quot;, "example", the URI would be:
          <list style="empty">
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise&nbsp;&gt;
            </t>
          </list>
        </t>

        <t>
          The
           <t indent="3">https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise</t>

        <t>The LORDN is contained in a CSV formatted CSV-formatted file that has the
        following structure:
          <list style='symbols'>

            <t>
              For structure:</t>

        <ul spacing="normal">
          <li>
            <t>For Sunrise Period:
              <list style='symbols'>

                <t>
                  first </t>
            <ul spacing="normal">
              <li>
                <t>first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&lt;Number of DN Lines&gt;
                <list style='empty'>
                  <t>Where:
                  <list style='symbols'>
                    <t>
                      &lt;version&gt;, Lines&gt;</t>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>Where:</t>
                    <ul spacing="normal">
                      <li>&lt;version&gt;: version of the file, this file. This field MUST <bcp14>MUST</bcp14> be 1.
                    </t>
                    <t>
                      &lt;LORDN 1.</li>
                      <li>&lt;LORDN creation datetime&gt;, datetime&gt;: date and time in UTC that the LORDN was created.
                    </t>
                    <t>
                      &lt;Number created.</li>
                      <li>&lt;Number of DN Lines&gt;, Lines&gt;: number of DN Lines present in the LORDN file.
                    </t>
                  </list>
                  </t>
                </list>
                </t>

                <t>
                  second file.</li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li>
                <t>second line: a header line line, as specified in <xref target="RFC4180"/>
                <list style='empty'>
                  <t>With target="RFC4180" format="default"/></t>
            <ul empty="true" spacing="normal">
            <li>With the header names as follows:</t>
                  <t>roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime</t>
                </list>
                </t>

                <t>
                  One follows:</li>
	    <li>roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime</li>
	       </ul>
	      </li>
	      <li>
                <t>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;
                <list style='empty'>
                  <t>Where:
                  <list style='symbols'>
                    <t>
                      &lt;roid&gt;,
                </t>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>Where:</t>
                    <ul spacing="normal">
                      <li>&lt;roid&gt;: DN Repository Object IDentifier (DNROID) in the SRS.
                    </t>
                    <t>
                      &lt;DN registered&gt;, SRS.</li>
                      <li>&lt;DN registered&gt;: DN that was effectively allocated. For IDNs, the A-label form
                      is used.
                    </t>
                    <t>
                      &lt;SMD-id&gt;, used.</li>
                      <li>&lt;SMD-id&gt;: SMD ID used for registration.
                    </t>
                    <t>
                      &lt;IANA registration.</li>
                      <li>&lt;IANA Registrar ID&gt;, ID&gt;: IANA Registrar ID.
                    </t>
                    <t>
                      &lt;datetime ID.</li>
                      <li>&lt;datetime of registration&gt;, registration&gt;: date and time in UTC that the domain was effectively allocated.
                    </t>
                    <t>
                      OPTIONAL allocated.</li>
                      <li><bcp14>OPTIONAL</bcp14> &lt;datetime of application creation&gt;, creation&gt;: date and time in UTC that
                      the application was created. The &lt;datetime of application creation&gt; MUST <bcp14>MUST</bcp14> be provided
                      in case of a DN effective allocation based on an asynchronous registration
                      (e.g., when using auctions).
                    </t>
                  </list>
                  </t>
                </list>
                </t>
              </list>

              <figure>
                		<preamble>Example auctions).</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
	    <t>Example of a Sunrise LORDN file:</preamble>

                <artwork>
                  <![CDATA[ file:</t>
	    <figure>
	      <name>Example Sunrise LORDN File</name>
<sourcecode type=""><![CDATA[
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
]]>
                </artwork>
]]></sourcecode>
	    </figure>
            </t>

            <t>
              For
          </li>
          <li>
            <t>For the Trademark Claims Period:
              <list style='symbols'>

                <t>
                  first Period:</t>
            <ul spacing="normal">
              <li>
                <t>first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&lt;Number of DN Lines&gt;

                <list style='empty'>
                  <t>Where:
                  <list style='symbols'>
                    <t>
                      &lt;version&gt;, Lines&gt;</t>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>Where:</t>
                    <ul spacing="normal">
                      <li>&lt;version&gt;: version of the file, this file. This field MUST <bcp14>MUST</bcp14> be 1.
                    </t>
                    <t>
                      &lt;LORDN 1.</li>
                      <li>&lt;LORDN creation datetime&gt;, datetime&gt;: date and time in UTC that the LORDN was created.
                    </t>
                    <t>
                      &lt;Number created.</li>
                      <li>&lt;Number of DN Lines&gt;, Lines&gt;: number of DN Lines present in the LORDN file.
                    </t>
                  </list>
                  </t>
                </list>
                </t>

                <t>
                  second file.</li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li>
                <t>second line: a header line line, as specified in <xref target="RFC4180"/>
                <list style='empty'>
                  <t>With target="RFC4180" format="default"/></t>
		<ul empty="true" spacing="normal">
                <li>With the header names as follows:</t>
                  <t>roid,domain-name,notice-id,registrar-id,registration-datetime,ack-datetime,application-datetime</t>
                </list>
                </t>

                <t>
                  One follows:</li>
        	<li>roid,domain-name,notice-id,registrar-id,registration-datetime,ack-datetime,application-datetime</li>
               </ul>
              </li>
              <li>
                <t>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;
                <list style='empty'>
                  <t>Where:
                  <list style='symbols'>
                    <t>
                      &lt;roid&gt;, DN Repository Object IDentifier (DNROID) creation&gt;</t>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>Where:</t>
                    <ul spacing="normal">
                      <li>&lt;roid&gt;: DNROID in the SRS.
                    </t>
                    <t>
                      &lt;DN registered&gt;, SRS.</li>
                      <li>&lt;DN registered&gt;: DN that was effectively allocated. For IDNs, the A-label form
                      is used.
                    </t>
                    <t>
                      &lt;TCNID&gt;, used.</li>
                      <li>&lt;TCNID&gt;: Trademark Claims Notice Identifier Identifier, as specified in &lt;tmNotice:id&gt;.
                    </t>
                    <t>
                      &lt;IANA &lt;tmNotice:id&gt;.</li>
                      <li>&lt;IANA Registrar ID&gt;, ID&gt;: IANA Registrar ID.
                    </t>
                    <t>
                      &lt;datetime ID.</li>
                      <li>&lt;datetime of registration&gt;, registration&gt;: date and time in UTC that the domain was effectively allocated.
                    </t>
                    <t>
                      &lt;datetime allocated.</li>
                      <li>&lt;datetime of acceptance of the TCN&gt;, TCN&gt;: date and time in UTC that the TCN was acknowledged.
                    </t>
                    <t>
                      OPTIONAL acknowledged.</li>
                      <li><bcp14>OPTIONAL</bcp14> &lt;datetime of application creation&gt;, creation&gt;: date and time in UTC that
                      the application was created. The &lt;datetime of application creation&gt; MUST <bcp14>MUST</bcp14> be provided
                      in case of a DN effective allocation based on an asynchronous registration
                      (e.g., when using auctions).
                    </t>
                  </list>
                  </t>
                  <t> auctions).</li>
                    </ul>
                  </li>
                  <li> For a DN matching a DNL of a PRM at the moment of registration, created
                    without the TCNID, expiration datetime datetime,
                    and acceptance datetime, datetime because DNL was inserted (or re-inserted) reinserted) for the first time
                    into a DNL List less than 24 hours ago, the string "recent-dnl-insertion" MAY <bcp14>MAY</bcp14> be
                    specified in &lt;TCNID&gt; and &lt;datetime of acceptance of the TCN&gt;.
                  </t>
                </list>
                </t>
              </list>

          <figure>
                      <preamble>Example TCN&gt;.</li>
                </ul>
              </li>
            </ul>
	    <t>Example of a Trademark Claims LORDN file:</preamble>

            <artwork>
              <![CDATA[ file:</t>
	    <figure>
	      <name>Example Trademark Claims LORDN File</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
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>
]]></artwork>
	    </figure>

              </t>
          </list>
        </t>
        <!-- <vspace blankLines='99' /> -->
          </li>
        </ul>

        <section anchor="lordnLogFormat" title="LORDN numbered="true" toc="default">
          <name>LORDN Log file"> File</name>
          <t>
            After reception of the LORDN file, the TMDB verifies its
            content for syntactical and semantical semantic correctness.
            The output of the LORDN file verification is retrieved using the
            yd interface (<xref target="yd" />). format="default"/>).
          </t>
          <t>
            The URI URIs of the yd interface (<xref target="yd" />) format="default"/>) used to
            retrieve the LORDN Log file is:
            <list style="symbols">
              <t>
                Sunrise are:
          </t>
          <ul spacing="normal">
            <li>
              <t>Sunrise LORDN Log file:
                <list style="empty">
                  <t>
                    &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/&lt;lordn-transaction-identifier&gt;/result&nbsp;&gt;
                  </t>
                </list>
              </t>
              <t>
                Trademark file:</t>
                <t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/&lt;lordn-transaction-identifier&gt;/result</t>
            </li>
            <li>
              <t>Trademark Claims LORDN Log file:
                <list style="empty">
                  <t>
                    &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/&lt;lordn-transaction-identifier&gt;/result&nbsp;&gt;
                  </t>
                </list>
              </t>
            </list> </t>
              <t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/&lt;lordn-transaction-identifier&gt;/result</t>
            </li>
          </ul>
          <t>
            A Registry Operator MUST NOT <bcp14>MUST NOT</bcp14> send more than one request per minute per TLD to download
            a LORDN Log file.
          </t>
          <t>
            The yd interface (<xref target="yd" />) format="default"/>) returns the following HTTP status codes after a an HTTP GET request method is
            received:
            <list style="symbols">
              <t>
                The
          </t>

          <ul spacing="normal">
            <li>The interface provides a 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.
              </t>
              <t>
                The Entity-body.</li>
            <li>The interface provides a an HTTP/204 status code if the LORDN Transaction
                Identifier is correct, correct but the server has not finalized processing the LORDN
                file.
              </t>
              <t>
                The
                file.</li>
            <li>The interface provides a an HTTP/400 status code if the request is incorrect.
              </t>
              <t> incorrect.</li>
            <li> The interface provides a an HTTP/401 status code if the credentials
                provided does do not authorize the Registry Operator to download the LORDN Log file.
              </t>
              <t>
                The file.</li>
            <li>The interface provides a an HTTP/404 status code if the LORDN Transaction
                Identifier is incorrect.
              </t>
              <t>
                The incorrect.</li>
            <li>The interface provides a an HTTP/500 status code if the system is
                experiencing a general failure.
              </t>
            </list>
          </t> failure.</li>
          </ul>

          <t>
            For example, to obtain the LORDN Log file in case of a Sunrise LORDN file with LORDN Transaction Identifier 0000000000000000001
            and TLD &quot;example&quot; "example", the URI would be:
            <list style="empty">
              <t>
                &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/0000000000000000001/result&nbsp;&gt;
          </t>
            </list>

          <t indent ="3">https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/0000000000000000001/result
              </t>

	   <t>
            The LORDN Log file is contained in a CSV formatted CSV-formatted file that has the
            following structure:

            <list style='symbols'>
              <t>
                first
          </t>

          <ul spacing="normal">
            <li>
              <t>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;

              <list style='empty'>
                <t>Where:
                <list style='symbols'>
                  <t>
                    &lt;version&gt;, Lines&gt;</t>
              <ul empty="true" spacing="normal">
                <li>
                  <t>Where:</t>
                  <ul spacing="normal">
                    <li>&lt;version&gt;: version of the file, this file. This field MUST <bcp14>MUST</bcp14> be 1.
                  </t>
                  <t>
                    &lt;LORDN
                  </li>
                    <li>&lt;LORDN Log creation datetime&gt;, datetime&gt;: date and time in UTC that the LORDN Log was created.
                  </t>
                  <t>
                    &lt;LORDN created.</li>
                    <li>&lt;LORDN file creation datetime&gt;, datetime&gt;: date and time in UTC of creation for the LORDN file that
                    this log file is referring to.
                  </t>
                  <t>
                    &lt;LORDN to.</li>
                    <li>&lt;LORDN Log Identifier&gt;, 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 length of 60 characters from the Base 64 alphabet.
                  </t>
                  <t>
                    &lt;Status flag&gt;, base64 alphabet.</li>
                    <li>&lt;Status flag&gt;: whether the LORDN file has been accepted for processing by the TMDB.
                    Possible values are &quot;accepted&quot; "accepted" or &quot;rejected&quot;.
                  </t>
                  <t>
                    &lt;Warning flag&gt;, "rejected".</li>
                    <li>&lt;Warning flag&gt;: whether the LORDN Log has any warning result codes. Possible values are
                    &quot;no-warnings&quot;
                    "no-warnings" or &quot;warnings-present&quot;.
                  </t>
                  <t>
                    &lt;Number "warnings-present".</li>
                    <li>&lt;Number of DN Lines&gt;, Lines&gt;: number of DNs DN effective allocations processed in the LORDN file.
                  </t>
                </list>
                </t>
                <t>
                  A file.</li>
                  </ul>
                </li>
                <li>A Registry Operator is not required to process a LORDN Log with a &lt;Status flag&gt;=&quot;accepted&quot; flag&gt;="accepted"
                  and &lt;Warning flag&gt;=&quot;no-warnings&quot;.
                </t>
              </list>
              </t>

              <t>
                second flag&gt;="no-warnings".</li>
              </ul>
            </li>
            <li>
              <t>second line: a header line line, as specified in <xref target="RFC4180"/>
              <list style='empty'>
                <t>With target="RFC4180" format="default"/> </t>
	        <ul empty="true" spacing="normal">
                <li>With the header names as follows:</t>
                <t>roid,result-code</t>
              </list>
              </t>

              <t>
                One follows:</li>
                <li>roid,result-code</li>
		</ul>
            </li>
            <li>
              <t>One or more lines with: &lt;roid&gt;,&lt;result code&gt;
              <list style='empty'>
                <t>Where:
                <list style='symbols'>
                  <t>
                    &lt;roid&gt;, DN Repository Object IDentifier (DNROID) </t>
              <ul empty="true" spacing="normal">
                <li>
                  <t>Where:</t>
                  <ul spacing="normal">
                    <li>&lt;roid&gt;: DNROID in the SRS.
                  </t>
                  <t>
                    &lt;result code&gt;, SRS.</li>
                    <li>&lt;result code&gt;: result code code, as described in <xref target="lordnRetCodes" />.
                  </t>
                </list>
                </t>
              </list>
              </t>
            </list>
          </t>

            <figure>
              <preamble>Example format="default"/>.</li>
                  </ul>
                </li>
              </ul>
            </li>
          </ul>

<t>Example of a LORDN Log file:</preamble>
              <artwork>
                <![CDATA[ file:</t>
	  <figure>
	    <name>Example LORDN Log File</name>
<sourcecode type=""><![CDATA[
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
]]>
              </artwork>
]]></sourcecode>
	  </figure>

          <!-- <vspace blankLines='99' /> -->

            <section anchor="lordnRetCodes" title="LORDN numbered="true" toc="default">
            <name>LORDN Log Result Codes"> Codes</name>
            <t>
                The classes
                of result codes (rc) are listed below. Those The classes in square
                brackets are not used at this time, 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:
                <list style='symbols'>

                  <t>
                    ok: Success,
            </t>
            <ul spacing="normal">
              <li>ok: Success. The DN Line is accepted by the TMDB.
                  </t>

                  <t>
                    warn: a TMDB.</li>
              <li>warn: A warning is issued, issued. The DN Line  is accepted by the TMDB.
                  </t>

                  <t>
                    err: an TMDB.</li>
              <li>err: An error is issued, issued. The LORDN file is rejected by the TMDB.
                  </t>
                </list>
              </t> TMDB.</li>
            </ul>
            <t>
              In case that after processing cases where a DN Line, line is processed and the error result code is 45xx or 46xx for that DN Line,
	      46xx, the LORDN file MUST <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 valid; however, the DN Line was not processed because the LORDN file was rejected.
                All DNs reported in a rejected LORDN file MUST <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>

              </t>
                <figure>
                  <preamble>LORDN
<t>LORDN Log Result Code Classes:</preamble>
                  <artwork>
                <![CDATA[
code  Class                              outcome
----  -----                              -------

20xx  Success                            ok

35xx  [ Classes:</t>
	    <table>
	      <name>LORDN Log Result Code Classes</name>
<thead>
<tr>

<th>Code</th>
<th>Class</th>
<th>Outcome</th>
</tr>
</thead>
<tbody>
<tr>

<td>20xx</td>
<td>Success</td>
<td>ok</td>
</tr>
<tr>

<td>35xx</td>
<td>[ DN Line syntax warning ]         warn
36xx  DN ]</td>
<td>warn</td>
</tr>
<tr>

<td>36xx</td>
<td>DN Line semantic warning           warn

45xx  DN warning</td>
<td>warn</td>
</tr>
<tr>

<td>45xx</td>
<td>DN Line syntax error               err
46xx  DN error</td>
<td>err</td>
</tr>
<tr>

<td>46xx</td>
<td>DN Line semantic error             err
]]>
                  </artwork>
                </figure> error</td>
<td>err</td>
</tr>
</tbody>
</table>
            <t>
                In the following, <xref target="LORDN-codes"/>, the LORDN Log result codes used by the TMDB
                are described: described.
            </t>

                <figure>
                  <preamble>LORDN
	    <table anchor="LORDN-codes">
	      <name>LORDN Log Result Codes:</preamble>
                  <artwork>
                <![CDATA[
rc    Short Codes</name>
    <thead>
      <tr>
	<th>rc</th>
	<th>Short Description / Long Description
----  -------------------------------------------------------------

2000  OK Description</th>
      </tr>
    </thead>
    <tbody>
      <tr>
	<td rowspan="2">2000</td>
	<td>OK</td>
      </tr>
      <tr>
	<td>The DN Line is successfully processed.

2001  OK processed.</td>
      </tr>
      <tr>
	<td rowspan="2">2001</td>
	<td>OK but not processed processed</td>
      </tr>
      <tr>
	<td>The DN Line is syntactically correct but was not processed
	because the LORDN file was rejected.

3601  TCN rejected.</td>
      </tr>
      <tr>
	<td rowspan="2">3601</td>
	<td>TCN Acceptance Date after Registration Date Date</td>
      </tr>
      <tr>
	<td>The TCN Acceptance Date in the DN Line is newer than the Registration
      Date.

3602  Duplicate DN Line
      This registration date.</td>
      </tr>
      <tr>
	<td rowspan="2">3602</td>
	<td>Duplicate DN Line</td>
      </tr>
      <tr>
	<td>This DN Line is an exact duplicate of another DN Line in the same
      file,
	file; the DN Line ignored.

3603  DNROID is ignored.</td>
      </tr>
      <tr>
	<td rowspan="2">3603</td>
	<td>DNROID Notified Earlier
      Same Earlier</td>
      </tr>
      <tr>
	<td>The same DNROID has been notified earlier, earlier; the DN Line ignored.

3604  TCN is ignored.</td>
      </tr>
      <tr>
	<td rowspan="2">3604</td>
	<td>TCN Checksum invalid
      Based invalid</td>
      </tr>
      <tr>
	<td>Based on the DN effectively allocated, effective allocation, the TCNID TCNID, and the
	expiration date of the linked TCN, the TCN Checksum is
      invalid.

3605  TCN Expired
      The
	invalid.</td>
      </tr>
      <tr>
	<td rowspan="2">3605</td>
	<td>TCN Expired</td>
      </tr>
      <tr>
	<td>The TCN was already expired (based on the <tmNotice:notAfter> &lt;tmNotice:notAfter&gt;
	field of the TCN) at the datetime of acknowledgement.

3606  Wrong acknowledgement.</td>
      </tr>
      <tr>
	<td rowspan="2">3606</td>
	<td>Wrong TCNID used
      The used</td>
      </tr>
      <tr>
	<td>The TCNID used for the registration does not match
	the related DN.

3609  Invalid SMD used
      The DN.</td>
      </tr>
      <tr>
	<td rowspan="2">3609</td>
	<td>Invalid SMD used</td>
      </tr>
      <tr>
	<td>The SMD used for registration was not valid at the moment of
	registration based on the <smd:notBefore> &lt;smd:notBefore&gt; and <smd:notAfter> &lt;smd:notAfter&gt;
	elements.
	In case of an asynchronous registration, this refer refers to the
      <datetime
	&lt;datetime of application creation>.

3610  DN creation>.</td>
      </tr>
      <tr>
	<td rowspan="2">3610</td>
	<td>DN reported outside of the time window
      The window</td>
      </tr>
      <tr>
	<td>The DN was reported outside of the required 26 hours 26-hour
	reporting window.

3611  DN window.</td>
      </tr>
      <tr>
	<td rowspan="2">3611</td>
	<td>DN does not match the labels in SMD
      The SMD</td>
      </tr>
      <tr>
	<td>The DN does not match the labels included in the SMD.

3612  SMDID SMD.</td>
      </tr>
      <tr>
	<td rowspan="2">3612</td>
	<td>SMDID does not exist
      The SMDID exist</td>
      </tr>
      <tr>
	<td>The Signed Mark Data Identifier (SMDID) has never existed
            in the central repository.

3613  SMD repository.</td>
      </tr>
      <tr>
	<td rowspan="2">3613</td>
	<td>SMD was revoked when used
      The used</td>
      </tr>
      <tr>
	<td>The SMD used for registration was revoked more than
	24 hours ago of the <datetime &lt;datetime of registration>. registration&gt;.
	In case of an asynchronous registration,
	the <datetime &lt;datetime of application creation> creation&gt; is used when
	validating the DN Line.

3614  TCNID Line.</td>
      </tr>
      <tr>
	<td rowspan="2">3614</td>
	<td>TCNID does not exist
      The TCNID exist</td>
      </tr>
      <tr>
	<td>The Trademark Claims Notice Identifier (TCNID) has never existed
            in the central repository.

3615  Recent-dnl-insertion repository.</td>
      </tr>
      <tr>
	<td rowspan="2">3615</td>
	<td>Recent-dnl-insertion outside of the time window
      The window</td>
      </tr>
      <tr>
	<td>The DN registration is reported as a recent-dnl-insertion,
	but the (re) insertion into the DNL occurred more than
	24 hours ago.

3616  Registration ago.</td>
      </tr>
      <tr>
	<td rowspan="2">3616</td>
	<td>Registration Date of DN in Claims before the end of the Sunrise Period
      The Period</td>
      </tr>
      <tr>
	<td>The registration date of the DN is before the end of
	the Sunrise Period Period, and the DN was reported in a
	Trademark Claims LORDN file.

3617  Registrar file.</td>
      </tr>
      <tr>
	<td rowspan="2">3617</td>
	<td>Registrar has not been approved by the TMDB TMDB</td>
      </tr>
      <tr>
	<td>The Registrar ID in the DN Line has not completed Trademark Claims
	integration testing with the TMDB.

3618  Registration TMDB.</td>
      </tr>
      <tr>
	<td rowspan="2">3618</td>
	<td>Registration Date of DN in QLP LORDN file out of the QLP Period
      The Period</td>
      </tr>
      <tr>
	<td>The registration date of the DN in a QLP LORDN file is outside
	of the QLP Period.

3619  TCN Period.</td>
      </tr>
      <tr>
	<td rowspan="2">3619</td>
	<td>TCN was not valid
      The valid</td>
      </tr>
      <tr>
	<td>The TCN was not valid (based on the <tmNotice:notBefore> &lt;tmNotice:notBefore&gt;
	field of the TCN) at the datetime of acknowledgement.

4501  Syntax acknowledgement.</td>
      </tr>
      <tr>
	<td rowspan="2">4501</td>
	<td>Syntax Error in DN Line
      Syntax Error Line</td>
      </tr>
      <tr>
	<td>There is a syntax error in the DN Line.

4601  Invalid Line.</td>
      </tr>
      <tr>
	<td rowspan="2">4601</td>
	<td>Invalid TLD used
      The used</td>
      </tr>
      <tr>
	<td>The TLD in the DN Line does not match what is expected for
	this LORDN.

4602  Registrar LORDN.</td>
      </tr>
      <tr>
	<td rowspan="2">4602</td>
	<td>Registrar ID Invalid Invalid</td>
      </tr>
      <tr>
	<td>The Registrar ID in the DN Line is not a valid ICANN-Accredited
      Registrar.

4603  Registration
	Registrar.</td>
      </tr>
      <tr>
	<td rowspan="2">4603</td>
	<td>Registration Date in the future
      The <datetime future</td>
      </tr>
      <tr>
	<td>The &lt;datetime of registration> registration&gt; in the DN Line is in the
      future.

4606  TLD
	future.</td>
      </tr>
      <tr>
	<td rowspan="2">4606</td>
	<td>TLD not in Sunrise or Trademark Claims Period
      The <datetime Periods</td>
      </tr>
      <tr>
	<td>The &lt;datetime of registration> registration&gt; was reported when the TLD was
	not in Sunrise or Trademark Claims Periods.
	In case of an asynchronous registration,
	the <datetime &lt;datetime of application creation> creation&gt; is used when
	validating the DN Line.

4607  Application Line.</td>
      </tr>
      <tr>
	<td rowspan="2">4607</td>
	<td>Application Date in the future
      The <datetime future</td>
      </tr>
      <tr>
	<td>The &lt;datetime of application creation> creation&gt; in the DN Line is in the
      future.

4608  Application
	future.</td>
      </tr>
      <tr>
	<td rowspan="2">4608</td>
	<td>Application Date is later than Registration Date
      The <datetime Date</td>
      </tr>
      <tr>
	<td>The &lt;datetime of application creation> creation&gt; in the DN Line is later
	than the <datetime &lt;datetime of registration>.

4609  TCNID registration&gt;.</td>
      </tr>
      <tr>
	<td rowspan="2">4609</td>
	<td>TCNID wrong syntax
      The syntax</td>
      </tr>
      <tr>
	<td>The syntax of the TCNID is invalid.

4610  TCN invalid.</td>
      </tr>
      <tr>
	<td rowspan="2">4610</td>
	<td>TCN Acceptance Date is in the future
      The <datetime future</td>
      </tr>
      <tr>
	<td>The &lt;datetime of acceptance of the TCN> TCN&gt; is in the future.

4611  Label future.</td>
      </tr>
      <tr>
	<td rowspan="2">4611</td>
	<td>Label has never existed in the TMDB
      The TMDB</td>
      </tr>
      <tr>
	<td>The label in the registered DN has never existed in the TMDB.
]]>
                  </artwork>
                </figure> TMDB.</td>
      </tr>
    </tbody>
  </table>

</section>
</section>
</section>

      <!--

4604  Sunrise DN / application reported for TLD in Claims
The <datetime of registration> was reported in Sunrise LORDN
  when the TLD was in Claims.
  In case of an asynchronous registration,
  the <datetime of application creation> is used when
    validating the DN Line.

    4605  Claims DN / application reported for TLD in Sunrise
    The <datetime of registration> was reported in Claims LORDN
      when the TLD was in Sunrise.
      In case of an asynchronous registration,
      the <datetime of application creation> is used when
        validating the DN Line.

-->
      <!-- <vspace blankLines='99' /> -->
      <section anchor="SmdFileFormat" title="Signed numbered="true" toc="default">
        <name>Signed Mark Data (SMD) File"> File</name>
        <t>
          This section defines the format of the Signed Mark Data (SMD) 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>
          Two encapsulation boundaries are defined for delimiting the
          encapsulated base64 encoded base64-encoded SMD: i.e. "-----BEGIN ENCODED
          SMD-----" and "-----END ENCODED SMD-----". Only data inside
          the encapsulation boundaries MUST <bcp14>MUST</bcp14> be used by Registries and
          Registrars for validation purposes, i.e. i.e., any data outside
          these boundaries as well as the boundaries themselves MUST <bcp14>MUST</bcp14>
          be ignored for validation purposes.
        </t>
        <t>
          The structure of the SMD File is as follows, all follows. All the elements are REQUIRED, <bcp14>REQUIRED</bcp14> and MUST <bcp14>MUST</bcp14> appear in the specified order.
          <list style='numbers'>

            <t>
              Marks: &lt;marks&gt;
        </t>

            <t>
              smdID: &lt;SMD-ID&gt;
            </t>

            <t>
              U-labels:
        <ol spacing="normal" type="1">
	  <li>Marks: &lt;marks&gt; </li>
          <li>smdID: &lt;SMD-ID&gt;</li>
          <li>U-labels: &lt;comma separated list of U-label or NR-LDH labels (see <xref target='RFC5890' />)&gt;
            </t>

            <t>
              notBefore: target="RFC5890" format="default"/>)&gt;</li>
          <li>notBefore: &lt;begin validity&gt;
            </t>

            <t>
              notAfter: validity&gt;</li>
          <li>notAfter: &lt;end validity&gt;
            </t>

            <t>
              -----BEGIN  </li>
          <li>-----BEGIN ENCODED SMD-----
            </t>

            <t>
              &lt;encoded SMD-----</li>
          <li>&lt;encoded SMD (see <xref target='RFC7848' />)&gt;
            </t>

            <t>
              -----END target="RFC7848" format="default"/>)&gt;</li>
          <li>-----END ENCODED SMD-----
            </t>

          </list>

        </t>

        <!-- <vspace blankLines='99' /> -->
          <figure>
            <preamble>Example SMD-----</li>
        </ol>

<t>Example of an SMD File:</preamble>

            <artwork>
              <![CDATA[ file:</t>
<figure>
<name>Example SMD File</name>
<sourcecode type=""><![CDATA[
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-----
]]>
            </artwork>
]]></sourcecode>
</figure>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="TCN" title="Trademark numbered="true" toc="default">
        <name>Trademark Claims Notice (TCN)"> (TCN)</name>
        <t>
          The TMDB MUST <bcp14>MUST</bcp14> provide the TCN to Registrars in XML format format,
          as specified below.
        </t>
        <t>
          An
          The enclosing element &lt;tmNotice:notice&gt; that describes the Trademark Notice
          to a given label.
        </t>
        <t>
          The child  elements of the &lt;tmNotice:notice&gt; element include:

        <list style="symbols">
          <t>
            A include:</t>
        <ul spacing="normal">
          <li>
            <t>A &lt;tmNotice:id&gt; element that contains the unique identifier of
            the Trademark Notice. This element contains the the TCNID.
            <list style="empty">
              <t>
                The TCNID.</t>
            <ul empty="true" spacing="normal">
              <li>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.
              </t>
              <t>
                Example of a TCNID:
                <list style="empty">
                  <t>
                    370d0b7c9223372036854775807.
                  </t>
                </list>
              </t>
              <t>
                Where:
                <list style="symbols">
                  <t>
                    TCN Checksum=370d0b7c
                  </t>
                  <t>
                    TMDB 9223372036854775807.</li>
              <li>
                <t>Example of a TCNID:</t>
                <ul empty="true" spacing="normal">
                  <li>370d0b7c9223372036854775807.</li>
                </ul>
              </li>
              <li>
                <t>Where:</t>
                <ul spacing="normal">
                  <li>TCN Checksum=370d0b7c</li>
                  <li>TMDB Notice Identifier=9223372036854775807
                  </t>
                </list>
              </t>
              <t>
                The Identifier=9223372036854775807</li>
                </ul>
              </li>
              <li>The TCN Checksum is a 8 characters long Base16 encoded 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
              </t>
              <t> Identifier.</li>
              <li>
                <t>The TMDB MUST <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
                1970-01-01T00:00:00Z, not counting leap seconds.
                For example, the conversion of 2010-08-16T09:00:00.0Z to Unix time of 2010-08-16T09:00:00.0Z is shown:
                <list style="empty">
                  <t>
                    unix_time(2010-08-16T09:00:00.0Z)=1281949200
                  </t>
                </list>
              </t>
              <t>
                The is:</t>
		  <ul empty="true" spacing="normal">
                  <li>unix_time(2010-08-16T09:00:00.0Z)=1281949200</li>
		  </ul>
              </li>
              <li>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.
              </t>
              <t>
                A Checksum.</li>
              <li>A Registry MUST <bcp14>MUST</bcp14> use the leftmost DNL of the DN being
                effectively allocated, the expiration datetime of the TCN (provided by the Registrar) Registrar),
                and the TMDB Notice Identifier extracted from the TCNID (provided by the Registrar)
                to compute the TCN Checksum. For example, if the DN &quot;xn--mgbachtv.xn--mgbh0fb&quot; "xn--mgbachtv.xn--mgbh0fb" is
                being effectively allocated, the leftmost DNL would be &quot;xn--mgbachtv&quot;.
              </t>

              <t>
                Example of "xn--mgbachtv".</li>
              <li>
                <t>An example computation of the TCN Checksum:
                <list style="empty">
                  <t> Checksum is:</t>
		 <ul empty="true" spacing="normal">
                  <li>
                    CRC32(example-one12819492009223372036854775807)=370d0b7c
                  </t>
                </list>
              </t>
            </list>
          </t>
          <t>
            A
                  </li>
		 </ul>
              </li>
            </ul>
          </li>
          <li>A &lt;tmNotice:notBefore&gt; element that contains the start of the validity valid date and time of the TCN.
          </t>

          <t>
            A </li>
          <li>A &lt;tmNotice:notAfter&gt; element that contains the expiration date and time of the TCN.
          </t>
          <t>
            A TCN.</li>
          <li>A &lt;tmNotice:label&gt; element that contains the DNL covered by a PRM.
          </t>
          <t>
            One PRM.</li>
          <li>
            <t>One or more &lt;tmNotice:claim&gt; elements that contain the Trademark Claim. Claims.
            The &lt;tmNotice:claim&gt; element contains the following
            child elements:

            <list style="symbols">
              <t>
                A elements:</t>
            <ul spacing="normal">
              <li>A &lt;tmNotice:markName&gt; element that contains the mark text string.
              </t>
              <t>
                One string.</li>
              <li>
                <t>One or more &lt;tmNotice:holder&gt; elements that contains contain the information of the holder of the mark. An "entitlement" attribute
                is used to identify the entitlement of the holder, holder; possible values are: owner, assignee assignee, or licensee.
                The child elements of &lt;tmNotice:holder&gt; include:
                <list style="symbols">

                  <t>
                    An OPTIONAL include:</t>
                <ul spacing="normal">
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:name&gt; element that contains the name of the holder. A &lt;tmNotice:name&gt; MUST <bcp14>MUST</bcp14> be specified if
                    &lt;tmNotice:org&gt; is not specified.
                  </t>

                  <t>
                    An OPTIONAL specified.</li>
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:org&gt; element that contains the name of the organization holder of the mark. A &lt;tmNotice:org&gt; MUST <bcp14>MUST</bcp14> be specified if
                    &lt;tmNotice:name&gt; is not specified.
                  </t>

                  <t>
                    A specified.</li>
                  <li>
                    <t>A &lt;tmNotice:addr&gt; element that contains the address information of the holder
                    of a mark. A &lt;tmNotice:addr&gt; contains the following child elements:

                    <list style="symbols">
                      <t>
                        One, two elements:</t>
                    <ul spacing="normal">
                      <li>One, two, or three OPTIONAL <bcp14>OPTIONAL</bcp14> &lt;tmNotice:street&gt; elements that contains contain the organization's street address.
                      </t>

                      <t>
                        A address.</li>
                      <li>A &lt;tmNotice:city&gt; element that contains the organization's city.
                      </t>

                      <t>
                        An OPTIONAL city.</li>
                      <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:sp&gt; element that contains the organization's state or province.
                      </t>

                      <t>
                        An OPTIONAL province.</li>
                      <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:pc&gt; element that contains the organization's postal code.
                      </t>

                      <t>
                        A code.</li>
                      <li>A &lt;tmNotice:cc&gt; element that contains the organization's country code.
                        This a two-character code from <xref target="ISO3166-2" />.
                      </t>
                    </list>
                  </t>

                  <t>
                    An OPTIONAL format="default"/>.</li>
                    </ul>
                  </li>
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:voice&gt; element that contains the organization's voice telephone number.
                  </t>

                  <t>
                    An OPTIONAL number.</li>
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:fax&gt; element that contains the organization's facsimile telephone number.
                  </t>

                  <t>
                    An OPTIONAL number.</li>
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:email&gt; element that contains the email address of the holder.
                  </t>
                </list>
              </t>
              <t>
                Zero holder.</li>
                </ul>
              </li>
              <li>
                <t>Zero or more OPTIONAL <bcp14>OPTIONAL</bcp14> &lt;tmNotice:contact&gt; elements that contains contain the information of the representative of the mark registration.
                A "type" attribute is used to identify the type of contact, contact; possible values are: owner, agent agent, or thirdparty. third party.
                The child elements of &lt;tmNotice:contact&gt; include:

                <list style="symbols">

                  <t>
                    A include:</t>
                <ul spacing="normal">
                  <li>A &lt;tmNotice:name&gt; element that contains the name of the responsible person.
                  </t>

                  <t>
                    An OPTIONAL person.</li>
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:org&gt; element that contains the name of the organization of the contact.
                  </t>

                  <t>
                    A contact.</li>
                  <li>
                    <t>A &lt;tmNotice:addr&gt; element that contains the address information of the contact.
                    A
                    &lt;tmNotice:addr&gt; contains the following child elements:

                    <list style="symbols">
                      <t>
                        One, two elements:</t>
                    <ul spacing="normal">
                      <li>One, two, or three OPTIONAL <bcp14>OPTIONAL</bcp14> &lt;tmNotice:street&gt; elements that contains contain the contact's street address.
                      </t>

                      <t>
                        A address.</li>
                      <li>A &lt;tmNotice:city&gt; element that contains the contact's city.
                      </t>

                      <t>
                        An OPTIONAL city.</li>
                      <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:sp&gt; element that contains the contact's state or province.
                      </t>

                      <t>
                        An OPTIONAL province.</li>
                      <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:pc&gt; element that contains the contact's postal code.
                      </t>

                      <t>
                        A code.</li>
                      <li>A &lt;tmNotice:cc&gt; element that contains the contact's country code.
                        This a two-character code from <xref target="ISO3166-2" />.
                      </t>
                    </list>
                  </t>

                  <t>
                    A format="default"/>.</li>
                    </ul>
                  </li>
                  <li>A &lt;tmNotice:voice&gt; element that contains the contact's voice telephone number.
                  </t>

                  <t>
                    An OPTIONAL number.</li>
                  <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:fax&gt; element that contains the contact's facsimile telephone number.
                  </t>

                  <t>
                    A number.</li>
                  <li>A &lt;tmNotice:email&gt; element that contains the contact's email address.
                  </t>
                </list>

              </t>
              <t>
                A address.</li>
                </ul>
              </li>
              <li>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" />.
              </t>
              <t>
                Zero format="default"/>.</li>
              <li>Zero or more OPTIONAL <bcp14>OPTIONAL</bcp14> &lt;tmNotice:classDesc&gt; element elements that contains contain the description (in English) of
                the Nice Classification Classification, as defined in <xref target="WIPO-NICE-CLASSES"/>. target="WIPO-NICE-CLASSES" format="default"/>.
                A classNum attribute contains the class number.
              </t>
              <t>
                A number.</li>
              <li>A &lt;tmNotice:goodsAndServices&gt; element that contains the full description of the goods and services mentioned
                in the mark registration document.
              </t>
              <t>
                An OPTIONAL document.</li>
              <li>
                <t>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:notExactMatch&gt; element signals that the claim notice was added to the TCN
                based on other rule (e.g. rules (e.g., <xref target="Claims50"/> ) target="Claims50" format="default"/>) other than exact match (defined in <xref target="MatchingRules"/>).
                The target="MatchingRules" format="default"/>).
                &lt;tmNotice:notExactMatch&gt; contains one or more:
                <list style="symbols">
                  <t>
                    An OPTIONAL more of the following:</t>
                <ul spacing="normal">
                  <li>
                    <t>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 an UDRP a Uniform Domain-Name Dispute-Resolution Policy (UDRP) case. The &lt;tmNotice:udrp&gt; contains:
                    <list style="symbols">
                      <t>
                        A </t>
                    <ul spacing="normal">
                      <li>A &lt;tmNotice:caseNo&gt; element that contains the UDRP case number used to validate
                        the previously abused name.
                      </t>
                      <t>
                        A name.</li>
                      <li>A &lt;tmNotice:udrpProvider&gt; element that contains the name of the UDRP provider.
                      </t>
                    </list>
                  </t>
                  <t>
                    An OPTIONAL provider.</li>
                    </ul>
                  </li>
                  <li>
                    <t>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. The &lt;tmNotice:court&gt; contains:
                    <list style="symbols">
                      <t>
                        A  </t>
                    <ul spacing="normal">
                      <li>A &lt;tmNotice:refNum&gt; element that contains the reference number of the court's resolution
                        used to validate the previously abused name.
                      </t>
                      <t>
                        A name.</li>
                      <li>A &lt;tmNotice:cc&gt; element that contains the two-character code from <xref target="ISO3166-2"/> target="ISO3166-2" format="default"/>
                        of the jurisdiction of the court.
                      </t>
                      <t>
                        A court.</li>
                      <li>A &lt;tmNotice:courtName&gt; element that contains the name of the court.
                      </t>
                    </list>
                  </t>
                </list>
                </t>
            </list>
          </t>

        </list>
        </t>
        <!-- <vspace blankLines='99' /> -->
          <figure>
            <preamble>Example court.</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>

	<t>Example of a &lt;tmNotice:notice&gt; object:</preamble>
            <artwork>
<![CDATA[ object:</t>
	<figure>
	  <name>Example &lt;tmNotice:notice&gt; Object</name>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<tmNotice:notice
 xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0">
 <tmNotice:id>370d0b7c9223372036854775807</tmNotice:id>
 <tmNotice:notBefore>2010-08-14T09:00:00.0Z</tmNotice:notBefore>
 <tmNotice:notAfter>2010-08-16T09:00:00.0Z</tmNotice:notAfter>
 <tmNotice:label>example-one</tmNotice:label>
 <tmNotice:claim>
  <tmNotice:markName>Example One</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>Example Inc.</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>123 Example Dr.</tmNotice:street>
    <tmNotice:street>Suite 100</tmNotice:street>
    <tmNotice:city>Reston</tmNotice:city>
    <tmNotice:sp>VA</tmNotice:sp>
    <tmNotice:pc>20190</tmNotice:pc>
    <tmNotice:cc>US</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:contact type="owner">
   <tmNotice:name>Joe Doe</tmNotice:name>
   <tmNotice:org>Example Inc.</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>123 Example Dr.</tmNotice:street>
    <tmNotice:street>Suite 100</tmNotice:street>
    <tmNotice:city>Reston</tmNotice:city>
    <tmNotice:sp>VA</tmNotice:sp>
    <tmNotice:pc>20190</tmNotice:pc>
    <tmNotice:cc>US</tmNotice:cc>
   </tmNotice:addr>
   <tmNotice:voice x="4321">+1.7035555555</tmNotice:voice>
   <tmNotice:email>jdoe@example.com</tmNotice:email>
  </tmNotice:contact>
  <tmNotice:jurDesc jurCC="US">USA</tmNotice:jurDesc>
  <tmNotice:classDesc classNum="35">
  Advertising; business management; business administration.
 </tmNotice:classDesc>
  <tmNotice:classDesc classNum="36">
  Insurance; financial affairs; monetary affairs; real estate.
 </tmNotice:classDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
 </tmNotice:claim>
 <tmNotice:claim>
  <tmNotice:markName>Example-One</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>Example S.A. de C.V.</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>Calle conocida #343</tmNotice:street>
    <tmNotice:city>Conocida</tmNotice:city>
    <tmNotice:sp>SP</tmNotice:sp>
    <tmNotice:pc>82140</tmNotice:pc>
    <tmNotice:cc>BR</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
 </tmNotice:claim>
 <tmNotice:claim>
  <tmNotice:markName>One</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>One Corporation</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>Otra calle</tmNotice:street>
    <tmNotice:city>Otra ciudad</tmNotice:city>
    <tmNotice:sp>OT</tmNotice:sp>
    <tmNotice:pc>383742</tmNotice:pc>
    <tmNotice:cc>CR</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
  <tmNotice:notExactMatch>
   <tmNotice:court>
    <tmNotice:refNum>234235</tmNotice:refNum>
    <tmNotice:cc>CR</tmNotice:cc>
    <tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName>
   </tmNotice:court>
  </tmNotice:notExactMatch>
 </tmNotice:claim>
 <tmNotice:claim>
  <tmNotice:markName>One Inc</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>One SA de CV</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>La calle</tmNotice:street>
    <tmNotice:city>La ciudad</tmNotice:city>
    <tmNotice:sp>CD</tmNotice:sp>
    <tmNotice:pc>34323</tmNotice:pc>
    <tmNotice:cc>AR</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
  <tmNotice:notExactMatch>
   <tmNotice:udrp>
    <tmNotice:caseNo>D2003-0499</tmNotice:caseNo>
    <tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider>
   </tmNotice:udrp>
  </tmNotice:notExactMatch>
 </tmNotice:claim>
</tmNotice:notice>
]]>
            </artwork>
]]></sourcecode>
</figure>
        <t>
          For the formal syntax of the TCN TCN, please
          refer to <xref target="FormalSyntaxClaimsNotice" />. format="default"/>.
        </t>
      </section>
      <!-- <vspace blankLines='99' /> -->

      <section anchor="surlListFormat" title="Sunrise numbered="true" toc="default">
        <name>Sunrise List (SURL)"> (SURL)</name>
        <t>
          This section defines the format of the list containing every
          Domain Name Label (DNL)
          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"/>). The Registries use the
          Sunrise List during the Qualified Launch Program QLP Period to check whether
          a requested DN matches a DNL of a PRM eligible for Sunrise.
        </t>
        <t>
          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>
          The Sunrise List is contained in a CSV formatted CSV-formatted file that has the
          following structure:

          <list style='symbols'>

            <t>
              first

        </t>
        <ul spacing="normal">
          <li>
            <t>first line: &lt;version&gt;,&lt;Sunrise List creation datetime&gt;
            <list style='empty'>
              <t>Where:
              <list style='symbols'>
                <t>
                  &lt;version&gt;, datetime&gt;</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>Where:</t>
                <ul spacing="normal">
                  <li>&lt;version&gt;: version of the file, this file. This field MUST <bcp14>MUST</bcp14> be 1.
                </t>
                <t>
                  &lt;Sunrise 1.</li>
                  <li>&lt;Sunrise List creation datetime&gt;, datetime&gt;: date and time in UTC that the Sunrise List was created.
                </t>
              </list>
              </t>
            </list>
            </t>
            <t>
              second created.</li>
                </ul>
              </li>
            </ul>
          </li>
          <li>
            <t>second line: a header line line, as specified in <xref target="RFC4180"/>
            <list style='empty'>
              <t>With target="RFC4180" format="default"/></t>
	     <ul empty="true" spacing="normal">
              <li>With the header names as follows:</t>
              <t>DNL,insertion-datetime</t>
            </list>
            </t>
            <t>
              One follows:</li>
              <li>DNL,insertion-datetime</li>
	     </ul>
          </li>
          <li>
            <t>One or more lines with: &lt;DNL&gt;,&lt;DNL insertion datetime&gt;
            <list style='empty'>
              <t>Where:
              <list style='symbols'>
                <t>
                  &lt;DNL&gt;, datetime&gt;</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>Where:</t>
                <ul spacing="normal">
                  <li>&lt;DNL&gt;: a Domain Name Label covered by a PRM eligible for Sunrise.
                </t>
                <t>
                  &lt;DNL Sunrise.</li>
                  <li>&lt;DNL insertion datetime&gt;, 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.
                </t>
              </list>
              </t>
            </list>
            </t>
          </list>

        </t>

        <figure>
          <preamble>Example UTC.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
	<t>Example of a Sunrise List:</preamble>
          <artwork>
            <![CDATA[ List:</t>
	<figure>
	  <name>Example Sunrise List</name>
<sourcecode type=""><![CDATA[
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
]]>
          </artwork>
]]></sourcecode>
	</figure>
        <t>
          To provide authentication and integrity protection, the Sunrise
          List will be PGP signed by the TMDB (see also <xref target="procDescBootstrapPgpKeyRy" />). format="default"/>).  The PGP signature of the
          Sunrise List can be found in the similar URI but with extension .sig .sig, as shown below.
        </t>
        <t>
          The URL URLs of the dy interface (<xref target="dy" />) is:
          <list style="symbols">
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.csv&nbsp;&gt;
            </t>
            <t>
              &lt;&nbsp;https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.sig&nbsp;&gt;
            </t>
          </list> format="default"/>) are:
        </t>
        <ul spacing="normal">
          <li>https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.csv</li>
          <li>https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.sig</li>
        </ul>
      </section>
    </section>
    <!-- <vspace blankLines='99' /> -->

    <section anchor="formalSyntax" title="Formal Syntax"> numbered="true" toc="default">
      <name>Formal Syntax</name>
      <section anchor="FormalSyntaxClaimsNotice" title="Trademark numbered="true" toc="default">
        <name>Trademark Claims Notice (TCN)"> (TCN)</name>
        <t>
          The schema presented here is for a Trademark Claims Notice.
        </t>
        <t>
          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>

        <figure>
          <artwork>
            <![CDATA[
<CODE BEGINS>
<sourcecode name="" type="xml" markers="true"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<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">

  <annotation>
    <documentation>
      Schema for representing a Trademark Claim Notice.
    </documentation>
  </annotation>
  <import namespace="urn:ietf:params:xml:ns:mark-1.0"/>
  <element name="notice" type="tmNotice:noticeType"/>
  <complexType name="holderType">
    <sequence>
      <element name="name" type="token" minOccurs="0"/>
      <element name="org" type="token" minOccurs="0"/>
      <element name="addr" type="tmNotice:addrType"/>
      <element name="voice" type="mark:e164Type" minOccurs="0"/>
      <element name="fax" type="mark:e164Type" minOccurs="0"/>
      <element name="email" type="mark:minTokenType" minOccurs="0"/>
    </sequence>
    <attribute name="entitlement" type="mark:entitlementType"/>
  </complexType>
  <complexType name="noticeType">
    <sequence>
      <element name="id" type="tmNotice:idType"/>
      <element name="notBefore" type="dateTime"/>
      <element name="notAfter" type="dateTime"/>
      <element name="label" type="mark:labelType"/>
      <element name="claim" type="tmNotice:claimType" minOccurs="0"
        maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <complexType name="claimType">
    <sequence>
      <element name="markName" type="token"/>
      <element name="holder" type="tmNotice:holderType"
        maxOccurs="unbounded"/>
      <element name="contact" type="tmNotice:contactType"
        minOccurs="0" maxOccurs="unbounded"/>
      <element name="jurDesc" type="tmNotice:jurDescType"/>
      <element name="classDesc" type="tmNotice:classDescType"
        minOccurs="0" maxOccurs="unbounded"/>
      <element name="goodsAndServices" type="token"/>
      <element name="notExactMatch" type="tmNotice:noExactMatchType"
        minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="jurDescType">
    <simpleContent>
      <extension base="token">
        <attribute name="jurCC" type="mark:ccType" use="required"/>
      </extension>
    </simpleContent>
  </complexType>
  <complexType name="classDescType">
    <simpleContent>
      <extension base="token">
        <attribute name="classNum" type="integer" use="required"/>
      </extension>
    </simpleContent>
  </complexType>
  <complexType name="noExactMatchType">
    <choice maxOccurs="unbounded">
      <element name="udrp" type="tmNotice:udrpType"/>
      <element name="court" type="tmNotice:courtType"/>
    </choice>
  </complexType>
  <complexType name="udrpType">
    <sequence>
      <element name="caseNo" type="token"/>
      <element name="udrpProvider" type="token"/>
    </sequence>
  </complexType>
  <complexType name="courtType">
    <sequence>
      <element name="refNum" type="token"/>
      <element name="cc" type="mark:ccType"/>
      <element name="region" type="token" minOccurs="0"
        maxOccurs="unbounded"/>
      <element name="courtName" type="token"/>
    </sequence>
  </complexType>
  <complexType name="addrType">
    <sequence>
      <element name="street" type="token" minOccurs="1"
        maxOccurs="3"/>
      <element name="city" type="token"/>
      <element name="sp" type="token" minOccurs="0"/>
      <element name="pc" type="mark:pcType" minOccurs="0"/>
      <element name="cc" type="mark:ccType"/>
    </sequence>
  </complexType>
  <complexType name="contactType">
    <sequence>
      <element name="name" type="token"/>
      <element name="org" type="token" minOccurs="0"/>
      <element name="addr" type="tmNotice:addrType"/>
      <element name="voice" type="mark:e164Type"/>
      <element name="fax" type="mark:e164Type" minOccurs="0"/>
      <element name="email" type="mark:minTokenType"/>
    </sequence>
    <attribute name="type" type="mark:contactTypeType"/>
  </complexType>
  <simpleType name="idType">
    <restriction base="token">
      <pattern value="[a-fA-F0-9]{8}\d{1,19}"/>
    </restriction>
  </simpleType>
</schema>
<CODE ENDS>
]]>
          </artwork>
        </figure>

      </section>

    </section>
    <!-- <vspace blankLines='99' /> -->
    <section anchor="Acknowledgements" title="Acknowledgements">

      <t>
        This specification is a collaborative effort from several participants
        in the ICANN community.
        Bernie Hoeneisen participated as co-author until version 02
        providing invaluable support for this document.
        This specification is based on a model spearheaded by:
        Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter.
        The author would also like to thank the thoughtful feedbak provided by many in the
        tmch-tech mailing list, but particularly the extensive help provided by
        James Gould, James Mitchell and Francisco Arias. This document includes feedback received from
        the following individuals: Paul Hoffman.
      </t>

    </section>

    <section title="Change History">
      <t>
        [[RFC Editor: Please remove this section.]]
      </t>
      <section title="Version 04">
        <t>
          <list style="numbers">
            <t>Ping update.</t>
          </list>
        </t>
      </section>
      <section title="Version 05">
        <t>
          <list style="numbers">
            <t>Ping update.</t>
          </list>
        </t>
      </section>
            <section title="Version 06">
        <t>
          <list style="numbers">
            <t>Updated the terminology text to reflect the text in RFC8174.</t>
            <t>Updated the reference of RFC7719 to RFC8499.</t>
            <t>Updated the matching rules document reference to link to the latest version.</t>
          </list>
        </t>
      </section>
      <section title="Version 07">
                <t>
                    <list style="numbers">
                        <t>Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/xcZPOAajlUJzgPgZBuqlIWRcFZg/</t>
                   		<t>Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/MdOhSomd6_djLcthfw5mxWZkbWY</t>
                  </list>
                </t>
            </section>
      <section title="Version 08">
                <t>
                    <list style="numbers">
                        <t>Fixed issues detected by idnits tool.</t>
                  </list>
                </t>
            </section>
                  <section title="Version 09">
                <t>
                    <list style="numbers">
                        <t>Ping update.</t>
                  </list>
                </t>
            </section>
                 <section title="Version 10">
                <t>
                    <list style="numbers">
                        <t>Ping update.</t>
                  </list>
                </t>
            </section>
             <section title="Version 11">
                <t>
                    <list style="numbers">
                        <t>Editorial updates.</t>
                        <t>Added Privacy section.</t>
                  </list>
                </t>
            </section>
                         <section title="Version 12">
                <t>
                    <list style="numbers">
                        <t>Editorial updates.</t>
                  </list>
                </t>
            </section>
                         <section title="Version 13">
                <t>
                    <list style="numbers">
                        <t>Editorial updates.</t>
                  </list>
                </t>
            </section>
                         <section title="Version 14">
                <t>
                    <list style="numbers">
                        <t>Editorial updates.</t>
                  </list>
                </t>
            </section>
            <section title="Version 15">
                <t>
                    <list style="numbers">
                        <t>Ping update.</t>
                  </list>
                </t>
]]></sourcecode>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
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 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>
        This document uses URNs to describe XML namespaces and XML schemas
        conforming to a registry mechanism described in <xref target="RFC3688"/>. target="RFC3688" format="default"/>. IANA is requested to register has registered two URI assignments. assignments as follows.
      </t>

      <t>Registration request for the Trademark
      <t>Trademark Claims Notice namespace:</t>
      <t>
        <list>

          <t>
            URI: urn:ietf:params:xml:ns:tmNotice-1.0
          </t>

          <t>Registrant Contact: IETF
      <dl newline="false" spacing="compact">
        <dt>URI:</dt>
	<dd>urn:ietf:params:xml:ns:tmNotice-1.0</dd>
        <dt>Registrant Contact:</dt>
	<dd>IETF &lt;iesg@ietf.org&gt; and ICANN &lt;globalsupport@icann.org&gt;</t>

          <t>
            XML: None. &lt;globalsupport@icann.org&gt;</dd>
        <dt>XML:</dt>
	<dd>None.  Namespace URIs do not represent an XML specification.
          </t>

		<t>Note: Note specification.</dd>
        <dt>Note:</dt>
	<dd>Note that this assignment is made from the wrong point in
            the tree in order to be consistent with deployed
            implementations.</t>

        </list>
      </t>
        <t>Registration request for the Trademark
            implementations.</dd>
      </dl>
      <t>Trademark Claims Notice XML schema:</t>
        <t>
        <list>

          <t>
            URI: urn:ietf:params:xml:schema:tmNotice-1.0
          </t>

          <t>Registrant Contact: IETF
      <dl newline="false" spacing="compact">
        <dt>URI:</dt>
	<dd>urn:ietf:params:xml:schema:tmNotice-1.0</dd>
        <dt>Registrant Contact:</dt>
	<dd>IETF &lt;iesg@ietf.org&gt; and ICANN &lt;globalsupport@icann.org&gt;</t>

          <t>
            XML: See &lt;globalsupport@icann.org&gt;</dd>
        <dt>XML:</dt>
	<dd>See <xref target="FormalSyntaxClaimsNotice"/> target="FormalSyntaxClaimsNotice" format="default"/> of this document.
          </t>

          	<t>Note: Note RFC 9361.</dd>
        <dt>Note:</dt>
	<dd>Note that this assignment is made from the wrong point in
            the tree in order to be consistent with deployed
            implementations.</t>

        </list>
        </t>
            implementations.</dd>
      </dl>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        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>
        The TMDB MUST <bcp14>MUST</bcp14> provide credentials to the appropriate Registries and Registrars.
      </t>
      <t>
        The TMDB MUST <bcp14>MUST</bcp14> require the use of strong passwords by Registries and Registrars.
      </t>
      <t>
        The TMDB, Registries Registries, and Registrars MUST <bcp14>MUST</bcp14> use the best practices described in <xref target="RFC7525"/> target="RFC9325" format="default"/> or its successors.
      </t>
    </section>
    <section title="Privacy Considerations">
            <t>
			This numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>This specification defines the interfaces to support the <xref target='RPM-Requirements'/>. target="RPM-Requirements" format="default"/>. 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 title='Normative References'>

      &RFC2119;
      &RFC3688;
      &RFC7525;
      &RFC7848;
      &RFC8174;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7848.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

        <reference anchor="MatchingRules" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rules-14jul16-en.pdf">
          <front>
          <title>Memorandum on
            <title>Explanatory Memorandum: Implementing the Matching Rules</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date day="14" month="July" year="2016" /> year="2016"/>
          </front>
        </reference>

        <reference anchor="QLP-Addendum" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-qlp-addendum-10apr14-en.pdf">
          <front>
          <title>Qualified
            <title>Trademark Clearinghouse Rights Protection Mechanism Requirements:
Qualified Launch Program Addendum</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date day="10" month="April" year="2014" /> year="2014"/>
          </front>
        </reference>

        <reference anchor="RPM-Requirements" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-30sep13-en.pdf">
          <front>
          <title>Rights
            <title>Trademark Clearinghouse Rights Protection Mechanism Requirements</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date day="30" month="September" year="2013" /> year="2013"/>
          </front>
        </reference>

        <reference anchor="Claims50" target="https://newgtlds.icann.org/en/about/trademark-clearinghouse/previously-abused-16jul13-en.pdf">
          <front>
            <title>Implementation Notes: Trademark Claims Protection for Previously Abused Names</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date day="16" month="July" year="2013" /> year="2013"/>
          </front>
        </reference>

        <reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2008/REC-xml-20081126/">
          <front>
            <title abbrev='Extensible abbrev="Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126'>Extensible Edition)">Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126</title> Edition)</title>
            <author initials="T." surname="Bray" fullname="Tim Bray" /> Bray"/>
            <author initials="J." surname="Paoli" fullname="Jean Paoli" /> Paoli"/>
            <author initials="C. M." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen" /> Sperberg-McQueen"/>
            <author initials="E." surname="Maler" fullname="Eve Maler" /> Maler"/>
            <author initials="F." surname="Yergeau" fullname="François Yergeau" /> Yergeau"/>
            <date year='2008' month='November' /> 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/">
          <front>
            <title abbrev='XML abbrev="XML Schema Part 1: Structures Second Edition REC-xmlschema-1-20041028'>XML Edition">XML Schema Part 1: Structures Second Edition REC-xmlschema-1-20041028</title> Edition</title>
            <author initials="H. S." initials="H." surname="Thompson" fullname="Henry S. Thompson" /> Thompson"/>
            <author initials="D." surname="Beech" fullname="David Beech" /> Beech"/>
            <author initials="M." surname="Maloney" fullname="Murray Maloney" /> Maloney"/>
            <author initials="N." surname="Mendelsohn" fullname="Noah Mendelsohn" /> Mendelsohn"/>
            <date year='2004' month='October' /> 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/">
          <front>
            <title abbrev='XML abbrev="XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028'>XML ">XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028</title> Edition</title>
            <author initials="P. V." initials="P." surname="Biron" fullname="Paul V. Biron" /> Biron"/>
            <author initials="A." surname="Malhotra" fullname="Ashok Malhotra" /> Malhotra"/>
            <date year='2004' month='October' /> year="2004" month="October"/>
            <keyword>W3C.xmlschema-2</keyword>
          </front>
	  <refcontent>W3C Recommendation REC-xmlschema-2-20041028</refcontent>
        </reference>
      </references>

    <references title='Informative References'>

      &RFC7230;
      &RFC7231;
      &RFC7235;
      &RFC2818;
      &RFC3339;
      &RFC4180;
      &RFC4648;
      &RFC4880;
      &RFC5280;
      &RFC5890;
      &RFC8499;
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4180.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>

        <reference anchor="WIPO-NICE-CLASSES" target="http://www.wipo.int/classifications/nice/en">
          <front>
            <title abbrev='WIPO Nice Classification'>WIPO Nice abbrev="Nice Classification">Nice Classification</title>
          <author><organization>WIPO</organization></author>
          <date year='2015' />
            <author>
              <organization>WIPO</organization>
            </author>
            <keyword>WIPO</keyword>
          </front>
        </reference>

        <reference anchor="WIPO.ST3" target="http://www.iso.org/iso/home/standards/country_codes.htm"> target="https://www.wipo.int/export/sites/www/standards/en/pdf/03-03-01.pdf">
          <front>
            <title abbrev='Two-Letter abbrev="Two-Letter Codes for the Representation of States, Other Entities and Organizations'>Recommended Organizations">Recommended standard on two-letter codes for the representation of states, other entities and intergovernmental organizations</title>
            <author>
              <organization>WIPO</organization>
            </author>
            <date year='2007' month='March' /> year="2022" month="November"/>
            <keyword>WIPO</keyword>
          </front>
        </reference>

        <reference anchor="ICANN-GTLD-AGB-20120604" target="http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf">
          <front>
            <title>gTLD Applicant Guidebook Version 2012-06-04</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date day="4" month="June" year="2012" /> year="2012"/>
          </front>
        </reference>

        <reference anchor="ISO3166-2" target="http://www.iso.org/iso/home/standards/country_codes.htm">
          <front>
            <title abbrev='International abbrev="International Standard for country codes and codes for their subdivisions'>International subdivisions">International Standard for country codes and codes for their subdivisions</title>
            <author>
              <organization>ISO</organization>
            </author>
          <date year='2006' />
            <keyword>ISO</keyword>
          </front>
        </reference>
      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        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>
  </back>
</rfc>