rfc9361xml2.original.xml   rfc9361.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
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">
<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3688.xml">
<!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3339.xml">
<!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">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" cat
<?rfc strict="yes"?> egory="info"
<?rfc tocompact="yes"?> ipr="trust200902" docName="draft-ietf-regext-tmch-func-spec-15" number="9361" ob
<?rfc compact="yes"?> soletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="9" symRefs="true
<?rfc subcompact="no"?> " sortRefs="true" version="3">
<?rfc tocdepth="9"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-regext-tmch-func-spec -15"> <!-- xml2rfc v2v3 conversion 3.15.0 -->
<front> <front>
<title abbrev="ICANN-TMCH">ICANN TMCH functional specifications</title> <title abbrev="ICANN TMCH">ICANN Trademark Clearinghouse (TMCH) Functional S
pecifications</title>
<seriesInfo name="RFC" value="9361"/>
<author fullname="Gustavo Lozano" initials="G." surname="Lozano"> <author fullname="Gustavo Lozano" initials="G." surname="Lozano">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<postal> <postal>
<street>12025 Waterfront Drive, Suite 300</street> <street>12025 Waterfront Drive</street>
<street>Suite 300</street>
<city>Los Angeles</city> <city>Los Angeles</city>
<code>90292</code> <code>90292</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<phone>+1.310.301.5800</phone>
<phone>+1.3103015800</phone>
<email>gustavo.lozano@icann.org</email> <email>gustavo.lozano@icann.org</email>
</address> </address>
</author> </author>
<date month="March" year="2023"/>
<date day="23" month="Aug" year="2022"/> <keyword>Trademark Clearinghouse</keyword>
<keyword>TMDB</keyword>
<area>Applications</area> <keyword>ICANN</keyword>
<keyword>TMCH</keyword>
<workgroup>Internet Engineering Task Force</workgroup> <keyword>gTLD</keyword>
<keyword>new gTLD</keyword>
<keyword>Trademark Clearinghouse, TMDB, ICANN, TMCH, gTLD, new gTLD, mark</k <keyword>mark</keyword>
eyword>
<abstract> <abstract>
<t> <t>
This document describes the requirements, the architecture and This document describes the requirements, the architecture, and
the interfaces between the ICANN Trademark Clearinghouse (TMCH) and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and
Domain Name Registries as well as between the ICANN TMCH and Domain Name Domain Name Registries, as well as between the ICANN TMCH and Domain Nam e
Registrars for the provisioning and management of domain names Registrars for the provisioning and management of domain names
during Sunrise and Trademark Claims Periods. during Sunrise and Trademark Claims Periods.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t> <t>
Domain Name Registries (DNRs) may operate in special modes for certain p Domain Name Registries may operate in special modes for certain periods
eriods of time enabling trademark holders to protect their rights of time, enabling Trademark Holders to protect their rights
during the introduction of a Top Level Domain (TLD). during the introduction of a Top-Level Domain (TLD).
</t> </t>
<t> <t>
Along with the introduction of new generic TLDs (gTLD), two special mode Along with the introduction of new generic TLDs (gTLDs), two special mod
s came into effect: es came into effect:
</t>
<list style='symbols'> <ul spacing="normal">
<li>
<t> Sunrise Period: The Sunrise Period allows Trademark Holders an advan
Sunrise Period, the Sunrise Period allows trademark holders an advan ce opportunity to
ce opportunity to
register domain names corresponding to their marks before names register domain names corresponding to their marks before names
are generally available to the public. are generally available to the public.
</t> </li>
<li>
<t> Trademark Claims Period: The Trademark Claims Period follows the Sun
Trademark Claims Period, the Trademark Claims Period follows the Sun rise Period and
rise Period and
runs for at least the first 90 days of an initial operating runs for at least the first 90 days of an initial operating
period of general registration. During the Trademark Claims period of general registration. During the Trademark Claims
Period, anyone attempting to register a domain name matching Period, anyone attempting to register a domain name matching
a mark that is recorded in the ICANN Trademark Clearinghouse (TMCH) will a mark that is recorded in the ICANN Trademark Clearinghouse (TMCH) will
receive a notification displaying the relevant mark information. receive a notification displaying the relevant mark information.
</t> </li>
</ul>
</list>
</t>
<t> <t>
This document describes the requirements, the architecture and This document describes the requirements, the architecture, and
the interfaces between the ICANN TMCH and the interfaces between the ICANN TMCH and
Domain Name Registries (called Registries in the rest of the document) Domain Name Registries (called "Registries" in the rest of the document) ,
as well as between the ICANN TMCH and Domain Name as well as between the ICANN TMCH and Domain Name
Registrars (called Registrars in the rest of the document) Registrars (called "Registrars" in the rest of the document)
for the provisioning and management of domain names for the provisioning and management of domain names
during the Sunrise and Trademark Claims Periods. during Sunrise and Trademark Claims Periods.
</t> </t>
<t> <t>
For any date and/or time indications, Coordinated Universal For any date and/or time indications, Coordinated Universal
Time (UTC) applies. Time (UTC) applies.
</t> </t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>RE
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", QUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp1
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when 4>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
, and only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are t
o be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target
="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
</t> </t>
<t> <t>
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document <bcp14>MUST</bcp14> be interprete d in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
implementation. implementation.
</t> </t>
<t> <t>
"tmNotice-1.0" is used as an abbreviation for "tmNotice-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "tmNotic e" "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "tmNotic e"
is used, but implementations MUST NOT depend on it and instead employ is used, but implementations <bcp14>MUST NOT</bcp14> depend on it and in stead employ
a proper namespace-aware XML parser and serializer to interpret and a proper namespace-aware XML parser and serializer to interpret and
output the XML documents. output the XML documents.
</t> </t>
<t>Extensible Markup Language (XML) 1.0, as described in <xref target="W3C
<t>Extensible Markup Language (XML) 1.0 as described in <xref target='W3C .REC-xml-20081126" format="default"/>, and XML Schema notation, as described in
.REC-xml-20081126' /> and XML Schema notation as described in <xref target='W3C. <xref target="W3C.REC-xmlschema-1-20041028" format="default"/> and <xref target=
REC-xmlschema-1-20041028' /> and <xref target='W3C.REC-xmlschema-2-20041028' /> "W3C.REC-xmlschema-2-20041028" format="default"/>, are used in this specificatio
are used in this specification. </t> n. </t>
</section> </section>
<section anchor="glossary" numbered="true" toc="default">
<section anchor="glossary" title="Glossary"> <name>Glossary</name>
<t> <t>
In the following section, the most common terms are briefly explained: In the following section, the most common terms are briefly explained:
<list style='symbols'>
<t>
Backend Registry Operator: Entity that manages (a part of) the techn
ical infrastructure
for a Registry Operator. The Registry Operator may also be the Backe
nd Registry Operator.
</t>
<t>
CA: Certificate Authority, see <xref target='RFC5280'/>.
</t>
<t>
CNIS, Claims Notice Information Service: This service
provides Trademark Claims
Notices (TCN) to Registrars.
</t>
<t>
CRC32, Cyclic Redundancy Check: algorithm
used in the ISO 3309 standard and in section 8.1.1.6.2 of
ITU-T recommendation V.42.
</t>
<t>
CRL: Certificate Revocation List, see <xref target='RFC5280' />.
</t>
<t>
CSV: Comma-Separated Values, see <xref target='RFC4180' />
</t>
<t>
Date and time, datetime: Date and time are specified following
the standard "Date and Time on the Internet specification", see
<xref target='RFC3339' />.
</t>
<t>
DN, Domain Name, domain name: see definition of Domain name in <xref
target='RFC8499' />.
</t>
<t>
DNROID, DN Repository Object IDentifier: an identifier assigned by t
he Registry to each DN object that unequivocally identifies
said DN object. For example, if a new DN object is created for a nam
e 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 Name System, see <xref target='RFC8499' />.
</t>
<t>
Effective allocation: 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 assi
gned to the effective user. A DN object
in status "pendingCreate" or any other status that precedes the
first time a DN is assigned to an end-user is not considered an effe
ctive allocation.
A DN object created internally by the Registry for subsequent
delegation to another Registrant is not considered an effective allo
cation.
</t>
<t>
EPP: The Extensible Provisioning Protocol, see definition of EPP in
<xref target='RFC8499' />.
</t>
<t>
FQDN: Fully-Qualified Domain Name, see definition of FQDN in <xref t
arget='RFC8499' />.
</t>
<t>
HTTP: Hypertext Transfer Protocol, see <xref target='RFC7230' /> an
d <xref target='RFC7231' />.
</t>
<t>
HTTPS: HTTP over TLS (Transport Layer Security), <xref target='RFC28
18' />.
</t>
<t>
IDN: Internationalized Domain Name, see definition of IDN in <xref t
arget='RFC8499' />.
</t>
<t>
Lookup Key: A random string of up to 51 chars from the set
[a-zA-Z0-9/] to be used as the lookup key by Registrars
to obtain the TCN using the CNIS.
Lookup Keys are unique and are related to one DNL only.
</t>
<t>
LORDN, List of Registered Domain Names: This is the list
of effectively allocated DNs matching a DNL of a PRM.
Registries will upload this list to the TMDB (during the NORDN
process).
</t>
<t>
Matching Rules: Some trademarks entitled to inclusion
in the TMDB include characters that are impermissible
in the domain name system (DNS) as a DNL. The TMV changes (
using the ICANN TMCH Matching Rules <xref target='MatchingRules' />)
certain DNS-impermissible characters in a trademark into
DNS-permissible equivalent characters
</t>
<t>
NORDN, Notification of Registered Domain Names: The
process by which Registries upload their recent LORDN to
the TMDB.
</t>
<t>
PGP: Pretty Good Privacy, see <xref target='RFC4880' />
</t>
<t>
PKI: Public Key Infrastructure, see <xref
target='RFC5280' />.
</t>
<t>
PRM, Pre-registered mark: Mark that has been
pre-registered with the ICANN TMCH.
</t>
<t>
QLP Period, Qualified Launch Program Period: During this optional pe
riod, a special
process applies to DNs matching the Sunrise List (SURL) and/or the D
NL List, to ensure that
TMHs are informed of a DN matching their PRM.
</t>
<t>
Registrant: see definition of Registrant in <xref target='RFC8499' /
>.
</t>
<t>
Registrar, Domain Name Registrar: see definition of Registrar in <xr
ef target='RFC8499' />.
</t>
<t>
Registry, Domain Name Registry, Registry Operator: see definition o
f Registry
in <xref target='RFC8499' />. A Registry Operator is the contracting
party
with ICANN for the TLD.
</t>
<t>
SMD, Signed Mark Data: A cryptographically signed token issued by
the TMV to the TMH to be used in the Sunrise Period to apply for a
DN that matches a DNL of a PRM; see also <xref target='RFC7848' />.
An SMD generated by an ICANN-approved trademark validator (TMV) cont
ains
both the signed token and the TMV's PKIX certificate.
</t>
<t>
SMD File: A file containing the SMD (see above) and some
human readable data. The latter is usually ignored in the
processing of the SMD File. See also <xref
target='SmdFileFormat' />.
</t>
<t>
SMD Revocation List: The SMD Revocation List is used by
Registries (and optionally by Registrars) during the
Sunrise Period to ensure that an SMD is still valid
(i.e. not revoked). The SMD Revocation List has a similar
function as CRLs used in PKI.
</t>
<t>
SRS: Shared Registration System, see also <xref
target='ICANN-GTLD-AGB-20120604' />.
</t>
<t>
SURL, Sunrise List: The list of DNLs that are covered by a PRM and e
ligible for Sunrise.
</t>
<t>
Sunrise Period: During this period DNs matching a
DNL of a PRM can be exclusively obtained by the respective
TMHs. For DNs matching a PRM, a special
process applies to ensure that TMHs are informed on the
effective allocation of a DN matching their PRM.
</t>
<t>
TLD: Top-Level Domain Name, see definition of TLD in <xref target='R
FC8499' />.
</t>
<t>
ICANN TMCH: a central repository for
information to be authenticated, stored, and disseminated,
pertaining to the rights of TMHs. The ICANN TMCH is split into two f
unctions 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. T
his CA is
operated by ICANN. The public key for this CA is the trust anchor
used to validate the identity of each TMV.
</t>
<t>
TMDB, Trademark Clearinghouse Database: Serves as a
database of the ICANN TMCH to provide information to the
gTLD Registries and Registrars to support Sunrise or
Trademark Claims services. There is only one TMDB in the
ICANN TMCH that concentrates the information about
the “verified” Trademark records from the TMVs.
</t>
<t>
TMH, Trademark Holder: The person or organization owning
rights on a mark.
</t>
<t>
TMV, Trademark Validator, Trademark validation
organization: An entity authorized by ICANN to authenticate
and validate registrations in the TMDB ensuring the marks qualify as
registered or are court-validated 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: Marks are used to claim exclusive
properties of products or services. A mark is
typically a name, word, phrase, logo, symbol, design,
image, or a combination of these elements. For the scope of
this document only textual marks are relevant.
</t>
<t>
Trademark Claims, Claims: Provides information to enhance the
understanding of the Trademark rights being claimed by the
TMH.
</t>
<t>
TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A Tra
demark 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 Tradema
rk 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: During this period, a special
process applies to DNs matching the DNL List, to ensure that
TMHs are informed of a DN
matching their PRM. For DNs matching the DNL List,
Registrars show a TCN to prospective
Registrants that has to be acknowledged before effective allocation
of
the DN.
</t>
<t>
UTC: Coordinated Universal Time, as maintained by the
Bureau International des Poids et Mesures (BIPM); see
also <xref target='RFC3339' />.
</t>
</list>
</t> </t>
<dl spacing="normal" newline="false">
<t><vspace blankLines='99' /> </t> <dt>Backend Registry 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
.</dd>
<dt>CA:</dt>
<dd>Certification Authority. See <xref target="RFC5280" format="default"/
>.</dd>
<dt>CNIS:</dt>
<dd>Claims Notice Information Service. This service provides Trademark Cl
aims
Notices (TCNs) to Registrars.</dd>
<dt>CRC32:</dt>
<dd>Cyclic Redundancy Check. This algorithm is used in the ISO 3309 stand
ard and in Section
8.1.1.6.2 of
ITU-T recommendation V.42.</dd>
<dt>CRL:</dt>
<dd>Certificate Revocation List. See <xref target="RFC5280" format="defau
lt"/>.</dd>
<dt>CSV:</dt>
<dd>Comma-Separated Values. See <xref target="RFC4180" format="default"/>
.</dd>
<dt>datetime:</dt>
<dd>Date and time. The date and time are specified following
the standard specification "Date and Time on the Internet: Timestamps".
See
<xref target="RFC3339" format="default"/>.</dd>
<dt>DN:</dt>
<dd>Domain Name. See <xref target="RFC8499"
format="default"/>.</dd>
<dt>DNL:</dt>
<dd>Domain Name Label. The DNL is an A-label or a Non-Reserved LDH (NR-LD
H) 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. This identifier is assigned by the R
egistry to each DN
object that unequivocally
identifies said DN object. For example, if a new DN object is created for
a name that
existed in the past, the DN objects will have different DNROIDs.</dd>
<dt>DNS:</dt>
<dd>Domain Name System. See <xref target="RFC8499" format="default"/>.</d
d>
<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 pre
cedes the
first time a DN is assigned to an end user is not considered an effectiv
e allocation.
A DN object created internally by the Registry for subsequent
delegation to another Registrant is not considered an effective allocati
on.</dd>
<dt>EPP:</dt>
<dd>Extensible Provisioning Protocol. See <xref
target="RFC8499" format="default"/>.</dd>
<dt>FQDN:</dt>
<dd>Fully Qualified Domain Name. See <xref target="RFC8499"
format="default"/>.</dd>
<dt>HTTP:</dt>
<dd>Hypertext Transfer Protocol. See <xref target="RFC9110"
format="default"/>.</dd>
<dt>HTTPS:</dt>
<dd>HTTP over TLS (Transport Layer Security). See <xref
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 TMHs. The ICANN TMCH is split into two funct
ions: 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"
format="default"/>.</dd>
<dt>Lookup Key:</dt>
<dd>A random string of up to 51 characters from the set
[a-zA-Z0-9/] to be used as the lookup key by Registrars
to obtain the TCN using the CNIS.
Lookup keys are unique and are related to one DNL only.</dd>
<dt>LORDN:</dt>
<dd>List of Registered Domain Names. This is the list
of effectively allocated DNs matching a DNL of a PRM.
Registries will upload this list to the TMDB (during the NORDN
process).</dd>
<dt>Matching Rules:</dt>
<dd>Some trademarks entitled to inclusion
in the TMDB include characters that are impermissible
in the DNS as a DNL. The TMV changes (using the ICANN TMCH Matching Rule
s <xref target="MatchingRules" format="default"/>)
certain DNS-impermissible characters in a trademark into
DNS-permissible equivalent characters.</dd>
<dt>NORDN:</dt>
<dd>Notification of Registered Domain Names. This is the
process by which Registries upload their recent LORDN to
the TMDB.</dd>
<dt>PGP:</dt>
<dd>Pretty Good Privacy. See <xref target="RFC4880" format="default"/>.</
dd>
<dt>PKI:</dt>
<dd>Public Key Infrastructure. See <xref target="RFC5280" format="default
"/>.</dd>
<dt>PRM:</dt>
<dd>Pre-Registered Mark. A mark that has been
pre-registered with the ICANN TMCH.</dd>
<dt>QLP Period:</dt>
<dd>Qualified Launch Program Period. During this optional period, a speci
al
process applies to DNs matching the Sunrise List (SURL) and/or the DNL L
ist to ensure
that TMHs are informed of a DN matching their PRM. </dd>
<dt>Registrant:</dt>
<dd>See the definition of Registrant in <xref target="RFC8499" format="de
fault"/>.</dd>
<dt>Registrar:</dt>
<dd>Domain Name Registrar. See <xref target="RFC8499" format="default"/>.
</dd>
<dt>Registry:</dt>
<dd>Domain Name Registry, Registry Operator. See <xref target="RFC8499" f
ormat="default"/>.
A Registry Operator is the contracting party with ICANN for the TLD.</dd>
<dt>SMD:</dt>
<dd>Signed Mark Data. A cryptographically signed token issued by
the TMV to the TMH to be used in the Sunrise Period to apply for a
DN that matches a DNL of a PRM. See <xref target="RFC7848" format="defau
lt"/>.
An SMD generated by an ICANN-approved Trademark Validator (TMV) contains
both the signed token and the TMV's PKIX certificate.</dd>
<dt>SMD File:</dt>
<dd>A file containing the SMD (see above) and some
human-readable data. The latter is usually ignored in the
processing of the SMD File. See <xref target="SmdFileFormat" format="def
ault"/>.</dd>
<dt>SMD Revocation 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., not revoked). The SMD Revocation List has a similar
function as CRLs used in PKI.</dd>
<dt>SRS:</dt>
<dd>Shared Registration System. See <xref target="ICANN-GTLD-AGB-20120604
"
format="default"/>.</dd>
<dt>Sunrise Period:</dt>
<dd>During this period, DNs matching a
DNL of a PRM can be exclusively obtained by the respective
TMHs. For DNs matching a PRM, a special
process applies to ensure that TMHs are informed on the
effective allocation of a DN matching their PRM. </dd>
<dt>SURL:</dt>
<dd>Sunrise List. The list of DNLs that are covered by a PRM and are elig
ible for
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 is provided to
prospective Registrants of DNs. </dd>
<dt>TCNID:</dt>
<dd>Trademark Claims Notice Identifier. An element of the Trademark Claim
s
Notice (see above), identifying said TCN.
The Trademark Claims Notice Identifier is specified in the
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. This serves as a
database of the ICANN TMCH to provide information to the
gTLD Registries and Registrars to support Sunrise or
Trademark Claims services. There is only one TMDB in the
ICANN TMCH that concentrates the information about
the "verified" trademark records from the TMVs.</dd>
<dt>TMH:</dt>
<dd>Trademark Holder. The person or organization owning
rights on a mark.</dd>
<dt>TMV:</dt>
<dd>Trademark Validator, Trademark Validation
organization. An entity authorized by ICANN to authenticate
and validate registrations in the TMDB, ensuring the marks qualify as
registered, are court-validated marks, or are protected by statute or tr
eaty. This entity would
also be asked to ensure that proof of use of marks is
provided, which can be demonstrated by furnishing a signed
declaration and one specimen of current use. </dd>
<dt>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, only textual marks are relevant.</dd>
<dt>Trademark Claims, Claims:</dt>
<dd>Provides information to enhance the
understanding of the trademark rights being claimed by the
TMH.</dd>
<dt>Trademark Claims Period:</dt>
<dd> During this period, a special
process applies to DNs matching the DNL List to ensure that
TMHs are informed of a DN
matching their PRM. For DNs matching the DNL List,
Registrars show a TCN to prospective
Registrants that has to be acknowledged before effective allocation of
the DN.</dd>
<dt>UTC:</dt>
<dd> Coordinated Universal Time. This is maintained by the
Bureau International des Poids et Mesures (BIPM). See
<xref target="RFC3339" format="default"/>.</dd>
</dl>
<t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> --> <section anchor="architecture" numbered="true" toc="default">
<name>Architecture</name>
<section anchor="architecture" title="Architecture"> <section anchor="archSunrise" numbered="true" toc="default">
<name>Sunrise Period</name>
<section anchor="archSunrise" title="Sunrise Period"> <figure anchor="figArchSunrise">
<name>Architecture of the Sunrise Period</name>
<t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor='figArchSunrise'>
<preamble>Architecture of the Sunrise Period</preamble>
<artwork>
<![CDATA[
SMD hand over (out-of-band) SMD hand over (out-of-band)
.............................................. ..............................................
: : : :
: .'''''''''''''''''''. : : .'''''''''''''''''''. :
: . ICANN TMCH . : : . ICANN TMCH . :
: ..................... : : ..................... :
v . . : v . . :
.------------. . .-------------. . hv .-----. .------------. . .-------------. . hv .-----.
| Registrant | . | TMV |<---------->| TMH | | Registrant | . | TMV |<---------->| TMH |
'------------' . '-------------' . vh '-----' '------------' . '-------------' . vh '-----'
skipping to change at line 443 skipping to change at line 344
: | | . | D | . \ : | | . | D | . \
: v v . | B | . v : v v . | B | . v
: .-----------. . yd | | . .---------------. : .-----------. . yd | | . .---------------.
: | Registry |---------->| | . | ICANN TMCH-CA | : | Registry |---------->| | . | ICANN TMCH-CA |
: '-----------' . '---------' . '---------------' : '-----------' . '---------' . '---------------'
: ^ . . | : : ^ . . | :
: | ''''''''''''''''''' | : : | ''''''''''''''''''' | :
: | cy | : : | cy | :
: cr '-----------------------------------------' : : cr '-----------------------------------------' :
:......................................................: :......................................................:
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="figArchSunrise" format="default"/> depicts the architec
ture of the Sunrise Period, including all the actors and interfaces.</t>
</t> <t> </t>
<t><xref target="figArchSunrise"/> depicts the architecture of the Sunrise Pe
riod, including all the actors and interfaces.</t>
<t><vspace blankLines='99' /> </t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="archTrCl" title="Trademark Claims Period">
<t>
<figure anchor='figArchTrCl'> <section anchor="archTrCl" numbered="true" toc="default">
<preamble>Architecture of the Trademark Claims Period</preamble> <name>Trademark Claims Period</name>
<artwork> <figure anchor="figArchTrCl">
<![CDATA[ <name>Architecture of the Trademark Claims Period</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
.''''''''''''''. .''''''''''''''.
. ICANN TMCH . . ICANN TMCH .
................ ................
. . . .
.------------. . .-------. . hv .-----. .------------. . .-------. . hv .-----.
| Registrant | . | TMV |<----------->| TMH | | Registrant | . | TMV |<----------->| TMH |
'------------' . '-------' . vh '-----' '------------' . '-------' . vh '-----'
| . ^ . | . ^ .
| . | dv . | . | dv .
tr | . vd | . tr | . vd | .
skipping to change at line 483 skipping to change at line 376
.-----------. dr . .-------. . .-----------. dr . .-------. .
| Registrar |<--------| | . | Registrar |<--------| | .
'-----------' . | T | . '-----------' . | T | .
ry | . | M | . ry | . | M | .
v . | D | . v . | D | .
.----------. dy . | B | . .----------. dy . | B | .
| Registry |<------->| | . | Registry |<------->| | .
'----------' yd . '-------' . '----------' yd . '-------' .
. . . .
'''''''''''''' ''''''''''''''
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="figArchTrCl" format="default"/> depicts the architectur
e of the Trademark Claims Period, including all the actors and interfaces.</t>
</t>
<t><xref target="figArchTrCl"/> depicts the architecture of the Trademark Claims
Period, including all the actors and interfaces.</t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="archInterfaces" title="Interfaces">
<section anchor="archInterfaces" numbered="true" toc="default">
<name>Interfaces</name>
<t> <t>
In the sub-sections below follows a short description of each interfac e to The subsections below contain short descriptions of each interface to
provide an overview of the architecture. More detailed provide an overview of the architecture. More detailed
descriptions of the relevant interfaces follow further descriptions of the relevant interfaces are in <xref target="processDe
below (<xref target='processDescriptions' />). scriptions" format="default"/>.
</t> </t>
<section anchor="hv" numbered="true" toc="default">
<section anchor="hv" title="hv"> <name>hv</name>
<t> <t>
The TMH registers a mark with a TMV via the hv interface. The TMH registers a mark with a TMV via the hv interface.
</t> </t>
<t> <t>
After the successful registration of the mark, the TMV After successful registration of the mark, the TMV
makes available a SMD File (see also makes a Signed Mark Data (SMD) File available (see
<xref target='SmdFileFormat' />) to the TMH to be used <xref target="SmdFileFormat" format="default"/>) to the TMH to be us
ed
during the Sunrise Period. during the Sunrise Period.
</t> </t>
<t> <t>
The specifics of the hv interface are beyond the scope The specifics of the hv interface are beyond the scope
of this document. of this document.
</t> </t>
</section> </section>
<section anchor="vd" numbered="true" toc="default">
<section anchor="vd" title="vd"> <name>vd</name>
<t> <t>
After successful mark registration, the TMV ensures the After successful registration of the mark, the TMV ensures the
TMDB inserts the corresponding DNLs and mark information TMDB inserts the corresponding DNLs and marks information
into the database via the vd interface. into the database via the vd interface.
</t> </t>
<t> <t>
The specifics of The specifics of
the vd interface are beyond the scope of this document. the vd interface are beyond the scope of this document.
</t> </t>
</section> </section>
<section anchor="dy" numbered="true" toc="default">
<section anchor="dy" title="dy"> <name>dy</name>
<t> <t>
During the Trademark Claims Period the Registry fetches During the Trademark Claims Period, the Registry fetches
the latest DNL List from the TMDB via the dy interface the latest DNL List from the TMDB via the dy interface
at regular intervals. The protocol used on the dy at regular intervals. The protocol used on the dy
interface is HTTPS. interface is HTTPS.
</t> </t>
<t> <t>
Not relevant during the Sunrise Period. This interface is not relevant during the Sunrise Period.
</t> </t>
</section> </section>
<section anchor="tr" numbered="true" toc="default">
<section anchor="tr" title="tr"> <name>tr</name>
<t> <t>
The Registrant communicates with the Registrar via the The Registrant communicates with the Registrar via the
tr interface. tr interface.
</t> </t>
<t> <t>
The specifics of the tr interface are beyond the scope The specifics of the tr interface are beyond the scope
of this document. of this document.
</t> </t>
</section> </section>
<section anchor="ry" numbered="true" toc="default">
<section anchor="ry" title="ry"> <name>ry</name>
<t> <t>
The Registrar communicate with the Registry via the ry interface. The Registrar communicates with the Registry via the ry interface.
The ry interfaces is typically implemented in The ry interfaces are typically implemented in
EPP. EPP.
</t> </t>
</section> </section>
<section anchor="dr" numbered="true" toc="default">
<section anchor="dr" title="dr"> <name>dr</name>
<t> <t>
During the Trademark Claims Period, the Registrar fetches During the Trademark Claims Period, the Registrar fetches
the TCN from the TMDB (to be the TCN from the TMDB (to be
displayed to the Registrant via the tr interface) via displayed to the Registrant via the tr interface) via
the dr interface. The protocol used for fetching the the dr interface. The protocol used for fetching the
TCN is HTTPS. TCN is HTTPS.
</t> </t>
<t> <t>
Not relevant during the Sunrise Period. This interface is not relevant during the Sunrise Period.
</t> </t>
</section> </section>
<section anchor="yd" numbered="true" toc="default">
<section anchor="yd" title="yd"> <name>yd</name>
<t> <t>
During the Sunrise Period the Registry notifies the TMDB During the Sunrise Period, the Registry notifies the TMDB
via the yd interface of all DNs via the yd interface of all DNs
effectively allocated. effectively allocated.
</t> </t>
<t> <t>
During the Trademark Claims Period, the Registry notifies During the Trademark Claims Period, the Registry notifies
the TMDB via the yd interface of all DNs the TMDB via the yd interface of all DNs
effectively allocated that matched an entry in the Registry previous effectively allocated that matched an entry in the DNL List that the
ly Registry
downloaded DNL List during the creation of the DN. previously downloaded during the creation of the DN.
</t> </t>
<t> <t>
The protocol used on the yd interface is HTTPS. The protocol used on the yd interface is HTTPS.
</t> </t>
</section> </section>
<section anchor="dv" numbered="true" toc="default">
<section anchor="dv" title="dv"> <name>dv</name>
<t> <t>
The TMDB notifies via the dv interface to the TMV The TMDB notifies the TMV via the dv interface of all effectively
of all DNs effectively allocated allocated DNs that match a mark registered by that TMV.
that match a mark registered by that TMV.
</t> </t>
<t> <t>
The specifics of the dv interface are beyond the scope The specifics of the dv interface are beyond the scope
of this document. of this document.
</t> </t>
</section> </section>
<section anchor="vh" numbered="true" toc="default">
<section anchor="vh" title="vh"> <name>vh</name>
<t> <t>
The TMV notifies the TMH via the vh interface after a The TMV notifies the TMH via the vh interface after an effectively
DN has been effectively allocated that matches a PRM of this allocated DN matches a PRM of this THM.
TMH.
</t> </t>
<t> <t>
The specifics of the vh interface are beyond the scope of The specifics of the vh interface are beyond the scope of
this document. this document.
</t> </t>
</section> </section>
<section anchor="vs" numbered="true" toc="default">
<section anchor="vs" title="vs"> <name>vs</name>
<t> <t>
The TMV requests to add a revoked The TMV requests to add revoked
SMD to the SMD Revocation List at the TMDB. SMDs to the SMD Revocation List at the TMDB.
</t> </t>
<t> <t>
The specifics of the vs interface are beyond the scope of The specifics of the vs interface are beyond the scope of
this document. this document.
</t> </t>
<t> <t>
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
</t> </t>
</section> </section>
<section anchor="sy" numbered="true" toc="default">
<section anchor="sy" title="sy"> <name>sy</name>
<t> <t>
During the Sunrise Period the Registry fetches the most During the Sunrise Period, the Registry fetches the most
recent SMD Revocation List from the TMDB via the sy recent SMD Revocation List from the TMDB via the sy
interface in regular intervals. The protocol used on interface in regular intervals. The protocol used on
the sy interface is HTTPS. the sy interface is HTTPS.
</t> </t>
<t> <t>
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
</t> </t>
</section> </section>
<section anchor="sr" numbered="true" toc="default">
<section anchor="sr" title="sr"> <name>sr</name>
<t> <t>
During the Sunrise Period the Registrar may fetch the During the Sunrise Period, the Registrar may fetch the
most recent SMD Revocation List from the TMDB via the most recent SMD Revocation List from the TMDB via the
sr interface. The protocol used on the sr interface is sr interface. The protocol used on the sr interface is
the same as on the sy interface (s. above), the same as on the sy interface (see above),
i.e. HTTPS. i.e., HTTPS.
</t> </t>
<t> <t>
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
</t> </t>
</section> </section>
<section anchor="vc" numbered="true" toc="default">
<section anchor="vc" title="vc"> <name>vc</name>
<t> <t>
The TMV registers its public key, and requests to revoke an existing The TMV registers its public key and requests to revoke an existing
key, with the ICANN TMCH-CA over the vc interface. key with the ICANN TMCH-CA over the vc interface.
</t> </t>
<t> <t>
The specifics of the vc interface are beyond the scope of this The specifics of the vc interface are beyond the scope of this
document, but it involves personal communication between the document, but it involves personal communication between the
operators of the TMV and the operators of the ICANN TMCH-CA. operators of the TMV and the operators of the ICANN TMCH-CA.
</t> </t>
<t> <t>
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
</t> </t>
</section> </section>
<section anchor="cy" numbered="true" toc="default">
<section anchor="cy" title="cy"> <name>cy</name>
<t> <t>
During the Sunrise Period the Registry fetches the most During the Sunrise Period, the Registry fetches the most
recent TMV CRL file from the ICANN TMCH-CA via the cy interface at recent TMV CRL file from the ICANN TMCH-CA via the cy interface at
regular intervals. The TMV CRL is used for validation regular intervals. The TMV CRL is used for validation
of TMV certificates. The protocol used on the cy of TMV certificates. The protocol used on the cy
interface is HTTPS. interface is HTTPS.
</t> </t>
<t> <t>
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
</t> </t>
</section> </section>
<section anchor="cr" numbered="true" toc="default">
<section anchor="cr" title="cr"> <name>cr</name>
<t> <t>
During the Sunrise Period the Registrar optionally fetches the During the Sunrise Period, the Registrar optionally fetches the
most recent TMV CRL file from the ICANN TMCH-CA via the cr interface at most recent TMV CRL file from the ICANN TMCH-CA via the cr interface at
regular intervals. The TMV CRL is used for validation regular intervals. The TMV CRL is used for validation
of TMV certificates. of TMV certificates.
The protocol used on the cr The protocol used on the cr
interface is HTTPS. interface is HTTPS.
</t> </t>
<t> <t>
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="processDescriptions" title="Process Descriptions">
<section anchor="bootstraping" title="Bootstrapping">
<section anchor="procDescBootstrapRy" title="Bootstrapping for Registries"
>
<section anchor="procDescBootstrapCredentialsRy" title="Credentials"> <section anchor="processDescriptions" numbered="true" toc="default">
<name>Process Descriptions</name>
<section anchor="bootstraping" numbered="true" toc="default">
<name>Bootstrapping</name>
<section anchor="procDescBootstrapRy" numbered="true" toc="default">
<name>Bootstrapping for Registries</name>
<section anchor="procDescBootstrapCredentialsRy" numbered="true" toc="
default">
<name>Credentials</name>
<t>Each Registry Operator will receive authentication credentials fr
om the TMDB to be used:</t>
<ul spacing="normal">
<li>during the Sunrise Period to fetch the SMD Revocation List
from the TMDB via the sy interface
(<xref target="sy" format="default"/>),</li>
<li>during the Trademark Claims Period to fetch the DNL List from
the TMDB via the dy interface (<xref target="dy" format="default"/>), and</li>
<li>during the NORDN process to notify the LORDN to the
TMDB via the yd interface (<xref target="yd" format="default"/>).<
/li>
</ul>
<t>Note: Credentials are created per TLD and provided to the
Registry Operator.</t>
</section>
<section anchor="procDescBootstrapIpAclRy" numbered="true" toc="defaul
t">
<name>IP Addresses for Access Control</name>
<t> <t>
Each Registry Operator will receive authentication credentials fro Each Registry Operator <bcp14>MUST</bcp14> provide the TMDB with
m the TMDB to be used: all IP addresses, which will be used to:
<list style='symbols'>
<t>
During the Sunrise Period to fetch the SMD Revocation List
from the TMBD via the sy interface
(<xref target="sy" />).
</t>
<t>
During the Trademark Claims Period to fetch the DNL List from
the TMDB via the dy interface (<xref
target="dy" />).
</t>
<t>
During the NORDN process to notify the LORDN to the
TMDB via the yd interface (<xref target="yd" />).
</t>
</list>
Note: credentials are created per TLD and provided to the
Registry Operator.
</t> </t>
<ul spacing="normal">
</section> <li>fetch the SMD Revocation List
via the sy interface (<xref target="sy" format="default"/>),</li>
<section anchor="procDescBootstrapIpAclRy" title="IP Addresses for Acc <li>fetch the DNL List from the TMDB via the dy interface (<xref t
ess Control"> arget="dy" format="default"/>), and</li>
<li>upload the LORDN to the
TMDB via the yd interface (<xref target="yd" format="default"/
>).</li>
</ul>
<t> <t>
Each Registry Operator MUST provide to the TMDB This access restriction <bcp14>MAY</bcp14> be applied by the TMD
all IP addresses that will be used to: B in addition to
<list style='symbols'> HTTP Basic access authentication (see <xref target="RFC7617" for
<t> mat="default"/>). For credentials to be
Fetch the SMD Revocation List used, see <xref target="procDescBootstrapCredentialsRy" format="
via the sy interface (<xref target="sy" />). default"/>.
</t>
<t>
Fetch the DNL List from the TMDB via the dy interface (<xref t
arget="dy" />).
</t>
<t>
Upload the LORDN to the
TMDB via the yd interface (<xref target="yd" />).
</t>
</list>
</t> </t>
<t> <t>
This access restriction MAY be applied by the TMDB in addition t The TMDB <bcp14>MAY</bcp14> limit the number of IP addresses to
o be
HTTP Basic access authentication (see <xref target="RFC7235"/>).
For credentials to be
used, see <xref target="procDescBootstrapCredentialsRy"
/>.
</t>
<t>
The TMDB MAY limit the number of IP addresses to be
accepted per Registry Operator. accepted per Registry Operator.
</t> </t>
</section> </section>
<section anchor="procDescBootstrapTmchTaRy" numbered="true" toc="defau
<section anchor="procDescBootstrapTmchTaRy" title="ICANN TMCH Trust An lt">
chor"> <name>ICANN TMCH Trust Anchor</name>
<t>
<t> Each Registry Operator <bcp14>MUST</bcp14> fetch the PKIX certific
Each Registry Operator MUST fetch the PKIX certificate (<xref ate <xref target="RFC5280" format="default"/> of
target='RFC5280' />) of
the ICANN TMCH-CA (Trust Anchor) from the ICANN TMCH-CA (Trust Anchor) from
&lt;&nbsp;https://ca.icann.org/tmch.crt&nbsp;&gt; to be used: <eref target="https://ca.icann.org/tmch.crt" brackets="angle"/> to
<list style='symbols'> be used:
<t>
During the Sunrise Period to validate the TMV
certificates and the TMV CRL.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>during the Sunrise Period to validate the TMV
certificates and the TMV CRL.</li>
</ul>
</section> </section>
<section anchor="procDescBootstrapPgpKeyRy" numbered="true" toc="defau
<section anchor="procDescBootstrapPgpKeyRy" title="TMDB PGP Key"> lt">
<name>TMDB PGP Key</name>
<t> <t>
The TMDB MUST provide each Registry Operator with the public porti The TMDB <bcp14>MUST</bcp14> provide each Registry Operator with t
on of he public portion of
the PGP Key used by TMDB, to be used: the PGP Key used by the TMDB, which is to be used:
<list style='symbols'>
<t>
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 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> </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" 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" format="default"/>).</li>
</ul>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescBootstrapRr" title="Bootstrapping for Registrars"
>
<section anchor="procDescBootstrapCredentialsRr" title="Credentials"> <section anchor="procDescBootstrapRr" numbered="true" toc="default">
<name>Bootstrapping for Registrars</name>
<section anchor="procDescBootstrapCredentialsRr" numbered="true" toc="
default">
<name>Credentials</name>
<t> <t>
Each ICANN-accredited Registrar will receive authentication Each ICANN-Accredited Registrar will receive authentication
credentials from the TMDB to be used: credentials from the TMDB to be used:</t>
<ul spacing="normal">
<list style='symbols'> <li>during the Sunrise Period to (optionally) fetch the
SMD Revocation List from the TMDB via the sr
<t> interface (<xref target="sr" format="default"/>) and</li>
During the Sunrise Period to (optionally) fetch the <li>during the Trademark Claims Period to fetch TCNs
SMD Revocation List from the TMDB via the sr from the TMDB via the dr interface (<xref target="dr" format="defa
interface (<xref target="sr" />). ult"/>).</li>
</t> </ul>
<t>
During the Trademark Claims Period to fetch TCNs
from the TMDB via the dr interface (<xref
target="dr" />).
</t>
</list>
</t>
</section> </section>
<section anchor="procDescBootstrapIpAclRr" numbered="true" toc="defaul
<section anchor="procDescBootstrapIpAclRr" title="IP Addresses for Acc t">
ess Control"> <name>IP Addresses for Access Control</name>
<t> <t>
Each Registrar MUST provide to the TMDB Each Registrar <bcp14>MUST</bcp14> provide the TMDB
all IP addresses, which will be used to: with all IP addresses, which will be used to:
<list style='symbols'>
<t>
Fetch the SMD Revocation List
via the sr interface (<xref target="sr" />).
</t>
<t>
Fetch TCNs via the dr interface (<xref target="dr" />).
</t>
</list>
</t> </t>
<t> <ul spacing="normal">
This access restriction MAY be applied by the TMDB in addition t <li>fetch the SMD Revocation List
o via the sr interface (<xref target="sr" format="default"/>) and</l
i>
<li>fetch TCNs via the dr interface (<xref target="dr" format="def
ault"/>).</li>
</ul>
<t>
This access restriction <bcp14>MAY</bcp14> be applied by the TMD
B in addition to
HTTP Basic access authentication (for credentials to be HTTP Basic access authentication (for credentials to be
used, see <xref target="procDescBootstrapCredentialsRr" used, see <xref target="procDescBootstrapCredentialsRr" format="
/>). default"/>).
</t> </t>
<t> <t>
The TMDB MAY limit the number of IP addresses to be The TMDB <bcp14>MAY</bcp14> limit the number of IP addresses to
be
accepted per Registrar. accepted per Registrar.
</t> </t>
</section> </section>
<section anchor="procDescBootstrapTmchTaRr" numbered="true" toc="defau
<section anchor="procDescBootstrapTmchTaRr" title="ICANN TMCH Trust An lt">
chor"> <name>ICANN TMCH Trust Anchor</name>
<t> <t>
Registrars MAY fetch the PKIX certificate of Registrars <bcp14>MAY</bcp14> fetch the PKIX certificate of
the ICANN TMCH-CA (Trust Anchor) from the ICANN TMCH-CA (Trust Anchor) from
<&nbsp;https://ca.icann.org/tmch.crt&nbsp;&gt; to be <eref target="https://ca.icann.org/tmch.crt" brackets="angle"/> to be
used: used:
<list style='symbols'>
<t>
During the Sunrise Period to (optionally) validate
the TMV certificates and TMV CRL.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>during the Sunrise Period to (optionally) validate
the TMV certificates and TMV CRL.</li>
</ul>
</section> </section>
<section anchor="procDescBootstrapPgpKeyRr" numbered="true" toc="defau
<section anchor="procDescBootstrapPgpKeyRr" title="TMDB PGP Key"> lt">
<name>TMDB PGP Key</name>
<t> <t>
Registrars MUST receive the public portion of the PGP Key Registrars <bcp14>MUST</bcp14> receive the public portion of the P GP Key
used by TMDB from the TMDB administrator to be used: used by TMDB from the TMDB administrator to be used:
<list style='symbols'>
<t>
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> </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"
format="default"/>).</li>
</ul>
</section> </section>
</section>
</section>
<!-- <vspace blankLines='99' /> -->
</section> </section>
<section anchor="procDescSunrise" numbered="true" toc="default">
<section anchor="procDescSunrise" title="Sunrise Period"> <name>Sunrise Period</name>
<section anchor="procDescSunriseReg" numbered="true" toc="default">
<section anchor="procDescSunriseReg" title="Domain Name registration"> <name>Domain Name Registration</name>
<figure anchor="figIntSunrisePeriod">
<t> <name>Domain Name Registration during the Sunrise Period</name>
<figure anchor='figIntSunrisePeriod'> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble>Domain Name registration during the Sunrise Period</prea .------------. .-----------. .----------.
mble> | Registrant | | Registrar | | Registry |
<artwork> '------------' '-----------' '----------'
<![CDATA[ | | |
.------------. .-----------. .----------. | Request DN | |
| Registrant | | Registrar | | Registry | | registration | |
'------------' '-----------' '----------' | (with SMD) | |
| | | |---------------->| Check DN availability |
| Request DN | | | |---------------------------->|
| registration | | | | |
| (with SMD) | | | | DN unavailable .-------------.
|---------------->| Check DN availability | | DN unavailable |<--------------------( DN available? )
| |---------------------------->| |<----------------| no '-------------'
| | | | | | yes
| | DN unavailable .-------------. | | DN available |
| DN unavailable |<--------------------( DN available? ) | |<----------------------------|
|<----------------| no '-------------' | | |
| | | yes | | Request DN registration |
| | DN available | | | (with SMD) |
| |<----------------------------| | |---------------------------->|
| | | | | |
| | Request DN registration | | | .------------------------------.
| | (with SMD) | | | | DN registration validation / |
| |---------------------------->| | | | SMD validation |
| | | | | '------------------------------'
| | .------------------------------. | | |
| | | DN registration validation / | | Registration |.-----------. Error .----------------------.
| | | SMD validation | | error || TRY AGAIN |<-----( Validation successful? )
| | '------------------------------' |<----------------|| / ABORT | no '----------------------'
| | | | |'-----------' | yes
| Registration |.-----------. Error .----------------------. | | |
| error || TRY AGAIN |<-----( Validation successful? ) | | DN registered |
|<----------------|| / ABORT | no '----------------------' | DN registered |<----------------------------|
| |'-----------' | yes |<----------------| |
| | | | | |
| | DN registered | ]]></artwork>
| DN registered |<----------------------------| </figure>
|<----------------| | <t><xref target="figIntSunrisePeriod" format="default"/> represents a
| | | synchronous DN registration
]]>
</artwork>
</figure>
</t>
<t><xref target="figIntSunrisePeriod"/> represents a synchronous D
N registration
workflow (usually called first come first served).</t> workflow (usually called first come first served).</t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescSunriseResRy" title="Sunrise Domain Name regist
ration by Registries">
<section anchor="procDescSunriseResRy" numbered="true" toc="default">
<name>Sunrise Domain Name Registration by Registries</name>
<t> <t>
Registries MUST perform a minimum set of checks for Registries <bcp14>MUST</bcp14> perform a minimum set of checks for
verifying each DN registration during the Sunrise Period upon verifying each DN registration during the Sunrise Period upon
reception of a registration request over the ry interface reception of a registration request over the ry interface
(<xref target="ry" />). If any of these checks fails the (<xref target="ry" format="default"/>). If any of these checks fail
Registry MUST abort the registration. Each of these , the
checks MUST be performed before the DN is effectively allocated. Registry <bcp14>MUST</bcp14> abort the registration. Each of these
checks <bcp14>MUST</bcp14> be performed before the DN is effectively
allocated.
</t> </t>
<t> <t>
In case of asynchronous registrations (e.g. auctions), In case of asynchronous registrations (e.g., auctions),
the minimum set of checks MAY be performed when creating the minimum set of checks <bcp14>MAY</bcp14> be performed when creat
the intermediate object (e.g. a DN application) ing
the intermediate object (e.g., a DN application)
used for DN registration. used for DN registration.
If the minimum set of checks is performed when creating If the minimum set of checks is performed when creating
the intermediate object (e.g. a DN application) a the intermediate object (e.g., a DN application), a
Registry MAY effectively allocate the DN without performing Registry <bcp14>MAY</bcp14> effectively allocate the DN without perf
orming
the minimum set of checks again. the minimum set of checks again.
</t> </t>
<t> <t>
Performing the minimum set of checks Registries MUST Performing the minimum set of checks, Registries <bcp14>MUST</bcp14>
verify that: verify that:
<list style='numbers'>
<t>
An SMD has been received from the Registrar along with
the DN registration.
</t>
<t>
The certificate of the TMV has been correctly signed
by the ICANN TMCH-CA. (The certificate of the TMV is
contained within the SMD.)
</t>
<t>
The datetime when the validation is done is within the validity
period of the TMV certificate.
</t>
<t>
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 signature of the SMD (signed with the TMV certificate)
is valid.
</t>
<t>
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 SMD has not been revoked, i.e., is not contained in
the SMD Revocation List.
</t>
<t>
The leftmost DNL of the DN being
effectively allocated matches one of the
labels (&lt;mark:label&gt;) elements in the SMD.
For example, if the DN &quot;xn--mgbachtv.xn--mgbh0fb&quot; is
being effectively allocated, the leftmost DNL would be &quot;xn-
-mgbachtv&quot;.
</t>
</list>
</t> </t>
<ol spacing="normal" type="1">
<li>an SMD has been received from the Registrar, along with
the DN registration,</li>
<li>the certificate of the TMV has been correctly signed
by the ICANN TMCH-CA (the certificate of the TMV is
contained within the SMD),</li>
<li>the datetime when the validation is done is within the validity
period of the TMV
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,</li>
<li>the signature of the SMD (signed with the TMV certificate)
is 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,</li
>
<li>the SMD has not been revoked, i.e., is not contained in
the SMD Revocation List, and</li>
<li>the leftmost DNL of the DN being
effectively allocated matches one of the
label (&lt;mark:label&gt;) elements in the SMD.
For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
being effectively allocated, the leftmost DNL would be "xn--mgbachtv
".</li>
</ol>
<t> <t>
These procedure apply to all DN effective allocations at These procedures apply to all DN effective allocations at
the second level as well as to all other levels the second level, as well as to all other levels
subordinate to the TLD that the Registry accepts subordinate to the TLD that the Registry accepts
registrations for. registrations for.
</t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="SunriseRy" title="TMDB Sunrise Services for Registries"
>
<section anchor="procDescSunriseSmdRevocList" title="SMD Revocation Li
st">
<section anchor="SunriseRy" numbered="true" toc="default">
<name>TMDB Sunrise Services for Registries</name>
<section anchor="procDescSunriseSmdRevocList" numbered="true" toc="def
ault">
<name>SMD Revocation List</name>
<t> <t>
A new SMD Revocation List MUST be published by the TMDB A new SMD Revocation List <bcp14>MUST</bcp14> be published by the TMDB
twice a day, by 00:00:00 and 12:00:00 UTC. twice a day, by 00:00:00 and 12:00:00 UTC.
</t> </t>
<t> <t>
Registries MUST refresh the latest version of the SMD Registries <bcp14>MUST</bcp14> refresh the latest version of the S MD
Revocation List at least once every 24 hours. Revocation List at least once every 24 hours.
</t> </t>
<t> <t>
Note: the SMD Revocation List will be the same regardless of the T LD. Note: The SMD Revocation List will be the same regardless of the T LD.
If a Backend Registry Operator manages the infrastructure If a Backend Registry Operator manages the infrastructure
of several TLDs, the Backend Registry Operator could of several TLDs, the Backend Registry Operator could
refresh the SMD Revocation List once every 24 hours, the refresh the SMD Revocation List once every 24 hours, and the
SMD Revocation List could be used for all the TLDs managed SMD Revocation List could be used for all the TLDs managed
by the Backend Registry Operator. by the Backend Registry Operator.
</t> </t>
<figure anchor="figIntSmdRevocList">
<t> <name>Update of the SMD Revocation List</name>
<figure anchor='figIntSmdRevocList'> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble>Update of the SMD Revocation List</preamble>
<artwork>
<![CDATA[
.----------. .------. .----------. .------.
| Registry | | TMDB | | Registry | | TMDB |
'----------' '------' '----------' '------'
| | | |
.----------------. | .----------------. |
| Periodically, | | | Periodically, | |
| at least | | | at least | |
| every 24 hours | | | every 24 hours | |
'----------------' | '----------------' |
| | | |
|----------------------------------------------------->| |----------------------------------------------------->|
| Download the latest SMD Revocation List | | Download the latest SMD Revocation List |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="figIntSmdRevocList" format="default"/> depicts the
process of downloading the latest SMD Revocation List initiated by the Registry.
</t> </t>
<t><xref target="figIntSmdRevocList"/> depicts the process of do
wnloading the latest SMD Revocation List initiated by the Registry.</t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescSunriseCrl" title="TMV Certificate Revocation
List (CRL)">
<section anchor="procDescSunriseCrl" numbered="true" toc="default">
<name>TMV Certificate Revocation List (CRL)</name>
<t> <t>
Registries MUST refresh their local copy of the TMV CRL file at Registries <bcp14>MUST</bcp14> refresh their local copy of the TMV
least every 24 hours using the CRL distribution point CRL file at
least once every 24 hours using the CRL distribution point
specified in the TMV certificate. specified in the TMV certificate.
</t> </t>
<t> <t>
Operationally, the TMV CRL file and CRL distribution point Operationally, the TMV CRL file and CRL distribution point
is the same for all TMVs and (at publication of this are the same for all TMVs and (at publication of this
document) located at 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>
<t> <t>
Note: the TMV CRL file will be the same regardless of the TLD. Note: The TMV CRL file will be the same regardless of the TLD.
If a Backend Registry Operator manages the infrastructure If a Backend Registry Operator manages the infrastructure
of several TLDs, the Backend Registry Operator could of several TLDs, the Backend Registry Operator could
refresh the TMV CRL file once every 24 hours, the refresh the TMV CRL file once every 24 hours, and the
TMV CRL file could be used for all the TLDs managed TMV CRL file could be used for all the TLDs managed
by the Backend Registry Operator. by the Backend Registry Operator.
</t> </t>
<figure anchor="figIntCRL">
<t> <name>Update of the TMV CRL File</name>
<figure anchor='figIntCRL'> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble>Update of the TMV CRL file</preamble>
<artwork>
<![CDATA[
.----------. .---------------. .----------. .---------------.
| Registry | | ICANN TMCH-CA | | Registry | | ICANN TMCH-CA |
'----------' '---------------' '----------' '---------------'
| | | |
.----------------. | .----------------. |
| Periodically, | | | Periodically, | |
| at least | | | at least | |
| every 24 hours | | | every 24 hours | |
'----------------' | '----------------' |
| | | |
|-------------------------------------------->| |-------------------------------------------->|
| Download the latest TMV CRL file | | Download the latest TMV CRL file |
|<--------------------------------------------| |<--------------------------------------------|
| | | |
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="figIntCRL" format="default"/> depicts the process o
f downloading the latest TMV CRL file initiated by the Registry.</t>
</t>
<t><xref target="figIntCRL"/> depicts the process of downloading
the latest TMV CRL file initiated by the Registry.</t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescSunriseNordn" title="Notice of Registered Dom <section anchor="procDescSunriseNordn" numbered="true" toc="default">
ain Names (NORN)"> <name>Notice of Registered Domain Names (NORDN)</name>
<t> <t>
The Registry MUST send a LORDN file containing The Registry <bcp14>MUST</bcp14> send a LORDN file containing
DNs effectively allocated to the DNs effectively allocated to the
TMDB (over the yd interface, <xref target="yd" />). TMDB (over the yd interface; see <xref target="yd" format="default "/>).
</t> </t>
<t> <t>
The effective allocation of a DN MUST be reported by the Registry to the TMDB The effective allocation of a DN <bcp14>MUST</bcp14> be reported b y the Registry to the TMDB
within 26 hours of the effective allocation of such DN. within 26 hours of the effective allocation of such DN.
</t> </t>
<t> <t>
The Registry MUST create and upload a LORDN file in case there are effective allocations in the SRS, The Registry <bcp14>MUST</bcp14> create and upload a LORDN file in case there are effective allocations in the SRS
that have not been successfully reported to the TMDB in a previous LORDN file. that have not been successfully reported to the TMDB in a previous LORDN file.
</t> </t>
<t> <t>
Based on the timers used by TMVs and the TMDB, the RECOMMENDED max imum frequency Based on the timers used by TMVs and the TMDB, the <bcp14>RECOMMEN DED</bcp14> maximum frequency
to upload LORDN files from the Registries to the TMDB is every 3 h ours. to upload LORDN files from the Registries to the TMDB is every 3 h ours.
</t> </t>
<t> <t>
It is RECOMMENDED that Registries try to upload at least two LORDN files per day to the TMDB It is <bcp14>RECOMMENDED</bcp14> that Registries try to upload at least two LORDN files per day to the TMDB,
with enough time in between, in order to have time to fix problems reported in the LORDN file. with enough time in between, in order to have time to fix problems reported in the LORDN file.
</t> </t>
<t> <t>
The Registry SHOULD upload a LORDN file only when the previous LOR DN file has been processed The Registry <bcp14>SHOULD</bcp14> upload a LORDN file only when t he previous LORDN file has been processed
by the TMDB and the related LORDN Log file has been downloaded and processed by the Registry. by the TMDB and the related LORDN Log file has been downloaded and processed by the Registry.
</t> </t>
<t> <t>
The Registry MUST upload LORDN files for DNs effectively allocated The Registry <bcp14>MUST</bcp14> upload LORDN files for DNs that a
during the Sunrise or re effectively allocated during the Sunrise or
Trademark Claims Period (same applies to DNs effectively allocated Trademark Claims Periods (same applies to DNs that are effectively
using applications created during the Sunrise or Trademark Claims allocated
Period in case of using using applications created during the Sunrise or Trademark Claims
Periods in case of using
asynchronous registrations). asynchronous registrations).
</t> </t>
<t> <t>
The yd interface (<xref target="yd" />) MUST support at least one (1) and MAY support up to ten (10) The yd interface (<xref target="yd" format="default"/>) <bcp14>MUS T</bcp14> support at least one (1) and <bcp14>MAY</bcp14> support up to ten (10)
concurrent connections from each IP address registered by a Regist ry Operator concurrent connections from each IP address registered by a Regist ry Operator
to access the service. to access the service.
</t> </t>
<t> <t>
The TMDB MUST process each uploaded LORDN file and make the relate d log file available The TMDB <bcp14>MUST</bcp14> process each uploaded LORDN file and make the related log file available
for Registry download within 30 minutes of the finalization of the upload. for Registry download within 30 minutes of the finalization of the upload.
</t> </t>
<figure anchor="figIntNordn">
<name>Notification of the Registered Domain 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., no errors )---' | |
| | contains errors | \ in Log file )? / | |
| '-----------------' '---------------' | |
| | | yes | |
| .---------------. | | |
| / everything fine \ yes | | |
|( (i.e., no errors )-----. | Notify TMVs | |
| \ in Log file )? / | | on the LORDN | |
| '---------------' | | pre-registered | |
| | no v | with said TMV | |
| .----------------. .------. |--------------->| |
'-| Correct Errors | | DONE | | | |
'----------------' '------' | | Notify each |
| | | affected TMH |
| | |-------------->|
| | | |
]]></artwork>
</figure>
<t><xref target="figIntNordn" format="default"/> depicts the process
to notify the TMH of Registered Domain Names.</t>
<t> <t>
The format used for the LORDN is described in <xref target="lordnF
<figure anchor='figIntNordn'> ormat" format="default"/>.
<preamble>Notification of Registered Domain Name</preamble>
<artwork>
<![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. no errors )---' | |
| | contains errors | \ in Log file )? / | |
| '-----------------' '---------------' | |
| | | yes | |
| .---------------. | | |
| / everything fine \ yes | | |
|( (i.e. no errors )-----. | Notify TMVs | |
| \ in Log file )? / | | on the LORDN | |
| '---------------' | | pre-registered | |
| | no v | with said TMV | |
| .----------------. .------. |--------------->| |
'-| Correct Errors | | DONE | | | |
'----------------' '------' | | Notify each |
| | | affected TMH |
| | |-------------->|
| | | |
]]>
</artwork>
</figure>
</t>
<t><xref target="figIntNordn"/> depicts the process to notify th
e TMH of Registered Domain Names.</t>
<t>
The format used for the LORDN is described in <xref target='lordnF
ormat' />
</t> </t>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> --> <section anchor="procDescSunriseResRr" numbered="true" toc="default">
<section anchor="procDescSunriseResRr" title="Sunrise Domain Name regist <name>Sunrise Domain Name Registration by Registrars</name>
ration by Registrars">
<t> <t>
Registrars MAY choose to perform the checks for verifying Registrars <bcp14>MAY</bcp14> choose to perform the checks for verif
DN registrations as performed by the Registries (see <xref ying
target="procDescSunriseResRy" />) before sending the DN registrations, as performed by the Registries (see <xref target="
procDescSunriseResRy" format="default"/>) before sending the
command to register a DN. command to register a DN.
</t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> --> <section anchor="SunriseRr" numbered="true" toc="default">
<section anchor="SunriseRr" title="TMDB Sunrise Services for Registrars" <name>TMDB Sunrise Services for Registrars</name>
>
<t> <t>
The processes described in <xref The processes described in Sections <xref target="procDescSunriseSm
target="procDescSunriseSmdRevocList" /> and <xref dRevocList" format="counter"/> and <xref target="procDescSunriseCrl" format="cou
target="procDescSunriseCrl" /> are also available for nter"/> are also available for
Registrars to optionally validate the SMDs received. Registrars to optionally validate the SMDs received.
</t> </t>
<t><vspace blankLines='99' /></t> <t/>
</section> </section>
</section>
</section> <!-- End procSunrise --> <section anchor="procDescTrCl" numbered="true" toc="default">
<!-- <vspace blankLines='99' /> --> <name>Trademark Claims Period</name>
<section anchor="procDescTrCl" title="Trademark Claims Period"> <section anchor="procDescTrClReg" numbered="true" toc="default">
<name>Domain Registration</name>
<section anchor="procDescTrClReg" title="Domain Registration"> <figure anchor="figIntTmcPeriod">
<name>Domain Name Registration during the Trademark Claims Period</na
<t> me>
<figure anchor='figIntTmcPeriod'> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble>Domain Name registration during the Trademark Claims Per
iod</preamble>
<artwork>
<![CDATA[
.------------. .-----------. .----------. .------. .------------. .-----------. .----------. .------.
| Registrant | | Registrar | | Registry | | TMDB | | Registrant | | Registrar | | Registry | | TMDB |
'------------' '-----------' '----------' '------' '------------' '-----------' '----------' '------'
| Request DN | | | | Request DN | | |
| registration | | | | registration | | |
|--------------->| Check DN availability | | |--------------->| Check DN availability | |
| |--------------------------->| | | |--------------------------->| |
| | DN unavailable .-------------. | | | DN unavailable .-------------. |
| DN unavailable |<-------------------( DN available? ) | | DN unavailable |<-------------------( DN available? ) |
|<---------------| no '-------------' | |<---------------| no '-------------' |
| | DN available | yes | | | DN available | yes |
| |<---------------------------| | | |<---------------------------| |
| | Request Lookup key | | | | Request lookup key | |
| |--------------------------->| | | |--------------------------->| |
| |.__________. .---------. | | |.__________. .---------. |
| || CONTINUE | / Does DN \ | | || CONTINUE | / Does DN \ |
| || NORMALLY |<--------( match DNL ) | | || NORMALLY |<--------( match DNL ) |
| |'----------' no \ of PRM? / | | |'----------' no \ of PRM? / |
| | '---------' | | | '---------' |
| | Lookup key | yes | | | Lookup key | yes |
| |<----------------------------' | | |<----------------------------' |
| | | | | |
.-----. | | Request TCN | .-----. | | Request TCN |
skipping to change at line 1361 skipping to change at line 1066
| .------. yes | | | .------. yes | |
'-( Ack? )----------->| Register DN (with TCNID) | | '-( Ack? )----------->| Register DN (with TCNID) | |
'------' |--------------------------->| | '------' |--------------------------->| |
| Registration | Error .----------------------. | | Registration | Error .----------------------. |
| error |<-------------( Validation successful? ) | | error |<-------------( Validation successful? ) |
|<---------------| no '----------------------' | |<---------------| no '----------------------' |
| | | yes | | | | yes |
| | DN registered | | | | DN registered | |
| DN registered |<---------------------------| | | DN registered |<---------------------------| |
|<---------------| | | |<---------------| | |
]]> ]]></artwork>
</artwork> </figure>
<t><xref target="figIntTmcPeriod" format="default"/> represents a sync
</figure> hronous DN registration
</t>
<t><xref target="figIntTmcPeriod"/> represents a synchronous DN re
gistration
workflow (usually called first come first served).</t> workflow (usually called first come first served).</t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescTrClResRr" title="Trademark Claims Domain Name <section anchor="procDescTrClResRr" numbered="true" toc="default">
registration by Registries"> <name>Trademark Claims Domain Name Registration by Registries</name>
<t> <t>
During the Trademark Claims Period, Registries perform two main func tions: During the Trademark Claims Period, Registries perform two main func tions:
<list style="symbols">
<t>
Registries MUST provide Registrars (over the ry interface,
<xref target="ry" />) the Lookup Key used
to retrieve the TCNs for DNs that
match the DNL List.
</t>
<t>
Registries MUST provide the Lookup Key only when queried
about a specific DN.
</t>
<t>
For each DN matching a DNL of a PRM, Registries MUST
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" />). If any of these
checks fails the Registry MUST abort the registration.
Each of these checks MUST be performed
before the DN is effectively allocated.
</t>
<t>
In case of asynchronous registrations (e.g. auctions),
the minimum set of checks MAY be performed when creating
the intermediate object (e.g. a DN application)
used for DN effective allocation.
If the minimum set of checks is performed when creating
the intermediate object (e.g. a DN application) a
Registry MAY effectively allocate the DN without performing
the minimum set of checks again.
</t>
<t>
Performing the minimum set of checks Registries MUST
verify that:
<list style='numbers'>
<t>
The TCNID (&lt;tmNotice:id&gt;), expiration datetime (&lt;tm
Notice:notAfter&gt;)
and acceptance datetime of the TCN,
have been received from the Registrar along with the DN
registration.
<list style="empty">
<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) for the first time
into DNL List less than 24 hours ago, the registration MAY
continue without this data and the tests listed
below are not required to be performed.
</t>
</list>
</t>
<t>
The TCN has not expired (according to the
expiration datetime sent by the Registrar).
</t>
<t>
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 i
n the past,
as there were no defined ICANN policies at that time. Implem
enters
should be aware that ICANN policy may define this value in t
he future.
</t>
<t>
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.
Verify that the computed TCN Checksum match the TCN Checksum
present in the TCNID. For example, if the DN &quot;xn--mgbac
htv.xn--mgbh0fb&quot; is
being effectively allocated, the leftmost DNL would be &quot
;xn--mgbachtv&quot;.
</t>
</list>
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>Registries <bcp14>MUST</bcp14> provide Registrars (over the ry i
nterface; see
<xref target="ry" format="default"/>) the lookup key used
to retrieve the TCNs for DNs that
match the DNL List.</li>
<li>Registries <bcp14>MUST</bcp14> provide the lookup key only when
queried
about a specific 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 <bcp14>MUST</bcp
14>
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 fail, the Registry <bcp14>MUST</bcp14> abort the registration
.
Each of these checks <bcp14>MUST</bcp14> be performed
before the DN is effectively allocated.</li>
<li>In case of asynchronous registrations (e.g., auctions),
the minimum set of checks <bcp14>MAY</bcp14> be performed when creat
ing
the intermediate object (e.g., a DN application)
used for DN effective allocation.
If the minimum set of checks is performed when creating
the intermediate object (e.g., a DN application), a
Registry <bcp14>MAY</bcp14> effectively allocate the DN without perf
orming
the minimum set of checks again.</li>
<li>
<t>Performing the minimum set of checks, Registries <bcp14>MUST</b
cp14>
verify that:</t>
<ol spacing="normal" type="1">
<li>
<t>The TCNID (&lt;tmNotice:id&gt;), expiration datetime
(&lt;tmNotice:notAfter&gt;), and acceptance datetime of the TCN
have been received from the Registrar, along with the DN
registration.</t>
<t>If the three elements mentioned above are not provided
by the Registrar for a DN matching a DNL of a PRM, but
the DNL was inserted (or reinserted) for the first time
into the DNL List less than 24 hours ago, the registration <bc
p14>MAY</bcp14>
continue without this data, and the tests listed
below are not required to be performed.</t>
</li>
<li>The TCN has not expired (according to the
expiration datetime sent by 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 tha
t
the acceptance datetime was less than or equal to 48 hours in th
e past,
as there were no defined ICANN policies at that time. Implemente
rs
should be aware that ICANN policy may define this value in the f
uture.</li>
<li>The TCN Checksum is computed using the leftmost DNL of the D
N being
effectively allocated,
the expiration datetime provided by the Registrar, and
the TMDB Notice Identifier extracted from the TCNID
provided by the Registrar. Verify that the computed TCN Cheksum
matches the
TCN Checksum present in the TCNID. For example, if the
DN "xn--mgbachtv.xn--mgbh0fb" is
being effectively allocated, the leftmost DNL would be "xn--mgba
chtv".</li>
</ol>
</li>
</ul>
<t> <t>
These procedures apply to all DN registrations at These procedures apply to all DN registrations at
the second level as well as to all other levels the second level, as well as to all other levels
subordinate to the TLD that the Registry accepts subordinate to the TLD that the Registry accepts
registrations for. registrations for.
</t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="claimsServicesRy" title="TMBD Trademark Claims Services
for Registries">
<section anchor="procDescUpdateDnlList" title="Domain Name Label (DNL) <section anchor="claimsServicesRy" numbered="true" toc="default">
List"> <name>TMDB Trademark Claims Services for Registries</name>
<section anchor="procDescUpdateDnlList" numbered="true" toc="default">
<name>Domain Name Label (DNL) List</name>
<t> <t>
A new DNL List MUST be published by the TMDB twice a day, A new DNL List <bcp14>MUST</bcp14> be published by the TMDB twice a day,
by 00:00:00 and 12:00:00 UTC. by 00:00:00 and 12:00:00 UTC.
</t> </t>
<t> <t>
Registries MUST refresh the latest version of the DNL Registries <bcp14>MUST</bcp14> refresh the latest version of the D NL
List at least once every 24 hours. List at least once every 24 hours.
</t> </t>
<t> <figure anchor="figIntDnlList">
<figure anchor='figIntDnlList'> <name>Update of the DNL List</name>
<preamble>Update of the DNL List</preamble> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
.----------. .------. .----------. .------.
| Registry | | TMDB | | Registry | | TMDB |
'----------' '------' '----------' '------'
| | | |
.----------------. | .----------------. |
| Periodically, | | | Periodically, | |
| at least | | | at least | |
| every 24 hours | | | every 24 hours | |
'----------------' | '----------------' |
| | | |
|-------------------------------->| |-------------------------------->|
| Download the latest DNL List | | Download the latest DNL List |
|<--------------------------------| |<--------------------------------|
| | | |
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="figIntDnlList" format="default"/> depicts the proce
</t> ss of downloading the latest DNL List initiated by the Registry.</t>
<t><xref target="figIntDnlList"/> depicts the process of downloading
the latest DNL list initiated by the Registry.</t>
<t> <t>
Note: the DNL List will be the same regardless of the TLD. Note: The DNL List will be the same regardless of the TLD.
If a Backend Registry Operator manages the infrastructure If a Backend Registry Operator manages the infrastructure
of several TLDs, the Backend Registry Operator could of several TLDs, the Backend Registry Operator could
refresh the DNL List once every 24 hours, the refresh the DNL List once every 24 hours, and the
DNL List could be used for all the TLDs managed DNL List could be used for all the TLDs managed
by the Backend Registry Operator. by the Backend Registry Operator.
</t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescTrClNordn" title="Notice of Registered Domain
Names (NORN)">
<section anchor="procDescTrClNordn" numbered="true" toc="default">
<name>Notice of Registered Domain Names (NORDN)</name>
<t> <t>
The NORDN process during the Trademark Claims Period is The NORDN process during the Trademark Claims Period is
almost the same as during Sunrise Period as defined in almost the same as during the Sunrise Period, as defined in
<xref target="procDescSunriseNordn" /> with the <xref target="procDescSunriseNordn" format="default"/>;
difference that only registrations subject to a the difference is that only registrations subject to a
Trademark Claim (i.e., at registration time the name Trademark Claim (i.e., at registration time, the name
appeared in the current DNL List downloaded by the Registry Operat or) are appeared in the current DNL List downloaded by the Registry Operat or) are
included in the LORDN. included in the LORDN.
</t> </t>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section title="Trademark Claims Domain Name registration by Registrars"
>
<section numbered="true" toc="default">
<name>Trademark Claims Domain Name Registration by Registrars</name>
<t> <t>
For each DN matching a DNL of a PRM, Registrars MUST For each DN matching a DNL of a PRM, Registrars <bcp14>MUST</bcp14>
perform the following steps: perform the following steps:
<list style='numbers'>
<t>
Use the Lookup Key received from the Registry
to obtain the TCN from the TMDB
using the dr interface (<xref
target="dr" />)
Registrars MUST only query for the Lookup Key of a DN
that is available for registration.
</t>
<t>
Present the TCN to the Registrant as
described in Exhibit A, <xref target='RPM-Requirements'/>.
</t>
<t>
Ask Registrant for acknowledgement, i.e. the Registrant
MUST consent with the TCN, before any
further processing. (The transmission of a TCNID
to the Registry over the ry
interface, <xref target="ry" /> implies that the
Registrant has expressed his/her consent with the TCN.)
</t>
<t>
Perform the minimum set of checks for verifying DN
registrations. If any of these checks fails the
Registrar MUST abort the DN registration. Each of
these checks MUST be performed before the registration
is sent to the Registry.
Performing the minimum set of checks Registrars MUST verify
that:
<list style='numbers'>
<t>
The datetime when the validation is done is within the TCN v
alidity based on the
&lt;tmNotice:notBefore&gt; and &lt;tmNotice:notAfter&gt; ele
ments.
</t>
<t>
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;
is
being effectively allocated, the leftmost DNL would be &quot
;xn--mgbachtv&quot;.
</t>
<t>
The Registrant has acknowledged (expressed his/her consent
with) the TCN.
</t>
</list>
</t>
<t>
Record the date and time when the registrant
acknowledged the TCN.
</t>
<t>
Send the registration to the Registry (ry interface,
<xref target="ry" />) and include the following information:
<list style='symbols'>
<t>
TCNID (&lt;tmNotice:id&gt;)
</t>
<t>
Expiration date of the TCN
(&lt;tmNotice:notAfter&gt;)
</t>
<t>
Acceptance datetime of the TCN.
</t>
</list>
</t>
</list>
</t> </t>
<ol spacing="normal" type="1">
<t> <li>Use the lookup key received from the Registry
to obtain the TCN from the TMDB
Currently TCNs are generated twice a day by the TMDB. using the dr interface (<xref target="dr" format="default"/>).
The expiration date (&lt;tmNotice:notAfter&gt;) of each TCN MUST Registrars <bcp14>MUST</bcp14> only query for the lookup key of a DN
that is available for registration.</li>
<li>Present the TCN to the Registrant, as
described in Exhibit A of <xref target="RPM-Requirements" format="de
fault"/>.</li>
<li>Ask the Registrant for acknowledgement, i.e., the Registrant
<bcp14>MUST</bcp14> consent with the TCN, before any
further processing. (The transmission of a TCNID
to the Registry over the ry
interface (<xref target="ry" format="default"/>) implies that the
Registrant has expressed their consent with the TCN.)</li>
<li>
<t>Perform the minimum set of checks for verifying DN
registrations. If any of these checks fail, the
Registrar <bcp14>MUST</bcp14> abort the DN registration. Each of
these checks <bcp14>MUST</bcp14> be performed before the registrat
ion
is sent to the Registry.
Performing the minimum set of checks, Registrars <bcp14>MUST</bcp1
4> verify
the following:</t>
<ol spacing="normal" type="a">
<li>The datetime when the validation is done is within the TCN va
lidity based on
the &lt;tmNotice:notBefore&gt; and &lt;tmNotice:notAfter&gt; elem
ents.</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 "xn--mgbachtv.xn--mgbh0fb" is
being effectively allocated, the leftmost DNL would be "xn--mgba
chtv".</li>
<li>The Registrant has acknowledged (expressed their consent
with) the TCN.</li>
</ol>
</li>
<li>Record the date and time when the registrant
acknowledged the TCN.</li>
<li>
<t>Send the registration to the Registry (via the ry interface; se
e
<xref target="ry" format="default"/>) and include the following in
formation:</t>
<ul spacing="normal">
<li>TCNID (&lt;tmNotice:id&gt;)</li>
<li>Expiration date of the TCN
(&lt;tmNotice:notAfter&gt;)</li>
<li>Acceptance datetime of the 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 <bcp14>
MUST</bcp14>
be set to a value defined by ICANN policy. In the gTLD round 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 of 2012, the TMDB set the expiration value to 48 hours into
the future as there were no defined ICANN policies at that time. the future, as there were no defined ICANN policies at that time.
Implementers should be aware that ICANN policy may define Implementers should be aware that ICANN policy may define
this value in the future. this value in the future.</t>
</t> <t>Registrars <bcp14>SHOULD</bcp14> implement a cache of TCNs to
<t>
Registrars SHOULD implement a cache of TCNs to
minimize the number of queries sent to the TMDB. minimize the number of queries sent to the TMDB.
A cached TCN MUST be removed from the cache after A cached TCN <bcp14>MUST</bcp14> be removed from the cache after
the expiration date of the TCN as defined by the expiration date of the TCN, as defined by
&lt;tmNotice:notAfter&gt;. &lt;tmNotice:notAfter&gt;.
</t> </t>
<t> <t>
The TMDB MAY implement rate-limiting as one of the protection The TMDB <bcp14>MAY</bcp14> implement rate limiting as one of the pr otection
mechanisms to mitigate the risk of performance degradation. mechanisms to mitigate the risk of performance degradation.
</t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="claimsServicesRr" title="TMBD Trademark Claims Services
for Registrars">
<section anchor="cnisService" title="Claims Notice Information Service
(CNIS)">
<section anchor="claimsServicesRr" numbered="true" toc="default">
<name>TMDB Trademark Claims Services for Registrars</name>
<section anchor="cnisService" numbered="true" toc="default">
<name>Claims Notice Information Service (CNIS)</name>
<t> <t>
The TCNs are provided by the TMDB The TCNs are provided by the TMDB
online and are fetched by the Registrar via the dr online and are fetched by the Registrar via the dr
interface (<xref target="dr" />). interface (<xref target="dr" format="default"/>).
</t> </t>
<t> <t>
To get access to the To get access to the
TCNs, the Registrar needs the TCNs, the Registrar needs the
credentials provided by the TMDB (<xref credentials provided by the TMDB (<xref target="procDescBootstrapC
target="procDescBootstrapCredentialsRr" />) and the Lookup redentialsRr" format="default"/>) and the lookup
Key received from the Registry via the ry interface (<xref key received from the Registry via the ry interface (<xref target=
target="ry" />). The dr interface (<xref target="dr" />) "ry" format="default"/>). The dr interface (<xref target="dr" format="default"/>
)
uses HTTPS with Basic access authentication. uses HTTPS with Basic access authentication.
</t> </t>
<t> <t>
The dr interface (<xref target="dr" />) MAY support up to The dr interface (<xref target="dr" format="default"/>) <bcp14>MAY </bcp14> support up to
ten (10) concurrent connections from each Registrar. ten (10) concurrent connections from each Registrar.
</t> </t>
<t> <t>
The URL of the dr interface (<xref target="dr" />) is: The URL of the dr interface (<xref target="dr" format="default"/>)
<list style="empty"> is:
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/cnis/&lt;lookupkey&
gt;.xml&nbsp;&gt;
</t>
</list>
</t> </t>
<t indent="3">https://&lt;tmdb-domain-name&gt;/cnis/&lt;lookupkey&
gt;.xml
</t>
<t> <t>
Note that the "lookupkey" may contain SLASH characters ("/"). Note that the "lookupkey" may contain slash characters ("/").
The SLASH character is part of the URL path and MUST NOT The slash character is part of the URL path and <bcp14>MUST NOT</b
cp14>
be escaped when requesting the TCN. be escaped when requesting the TCN.
</t> </t>
<t> <t>
The TLS certificate (HTTPS) used on the dr interface The TLS certificate (HTTPS) used on the dr interface
(<xref target="dr" />) MUST be signed by a well-know (<xref target="dr" format="default"/>) <bcp14>MUST</bcp14> be sign
public CA. Registrars MUST perform the Certification Path Validati ed by a well-know
on public CA. Registrars <bcp14>MUST</bcp14> perform the certificatio
described in Section 6 of <xref target='RFC5280' n path validation
/>. described in <xref target="RFC5280" section="6" sectionFormat="of"
/>.
Registrars will be authenticated Registrars will be authenticated
in the dr interface using HTTP Basic access authentication. in the dr interface using HTTP Basic access authentication.
The dr (<xref target="dr" />) interface MUST support HTTPS The dr interface (<xref target="dr" format="default"/>) <bcp14>MUS
keep-alive and MUST maintain the connection for up to 30 minutes. T</bcp14> support HTTPS
keep-alive and <bcp14>MUST</bcp14> maintain the connection for up
to 30 minutes.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="procDescQLP" title="Qualified Launch Program (QLP) Period
">
<section title="Domain Registration">
<section anchor="procDescQLP" numbered="true" toc="default">
<name>Qualified Launch Program (QLP) Period</name>
<section numbered="true" toc="default">
<name>Domain Registration</name>
<t> <t>
During the OPTIONAL (see <xref target='QLP-Addendum' />) Qualified L aunch Program (QLP) Period effective allocations During the <bcp14>OPTIONAL</bcp14> Qualified Launch Program (QLP) Pe riod (see <xref target="QLP-Addendum" format="default"/>), effective allocations
of DNs to third parties could require that Registries and Registrars provide Sunrise of DNs to third parties could require that Registries and Registrars provide Sunrise
and/or Trademark Claims services. and/or Trademark Claims services.
If required, Registries and Registrars MUST provide Sunrise and/or T If required, Registries and Registrars <bcp14>MUST</bcp14> provide S
rademark Claims services as described in unrise and/or Trademark Claims services, as described in Sections
<xref target="procDescSunrise" /> and <xref target="procDescTrCl" /> <xref target="procDescSunrise" format="counter"/> and <xref target="
. procDescTrCl" format="counter"/>.
</t> </t>
<t> <t>
The effective allocation scenarios are: The effective allocation scenarios are as follows:
<list style="symbols">
<t>
If the leftmost DNL of the DN being
effectively allocated (QLP Name in this section) matches a DNL in th
e SURL, and an SMD is provided, then
Registries MUST provide Sunrise Services (see <xref target="procDesc
Sunrise" />) and
the DN MUST be reported in a Sunrise LORDN file during the QLP Per
iod. For example, if the DN &quot;xn--mgbachtv.xn--mgbh0fb&quot; is
being effectively allocated, the leftmost DNL would be &quot;xn--m
gbachtv&quot;.
</t>
<t>
If the QLP Name matches a DNL in the SURL but does not match a D
NL in the DNL List, and an SMD is NOT provided (see section
2.2 of <xref target='QLP-Addendum' />), then
the DN MUST be reported in a Sunrise LORDN file using the specia
l SMD-id "99999-99999" during the QLP Period.
</t>
<t>
If the QLP Name matches a DNL in the SURL and also matches a DNL in
the DNL List, and an SMD is NOT provided (see section
2.2 of <xref target='QLP-Addendum' />), then
Registries MUST provide Trademark Claims services (see <xref tar
get="procDescTrCl" />) and
the DN MUST be reported in a Trademark Claims LORDN file during the
QLP Period.
</t>
<t>
If the QLP Name matches a DNL in the DNL List but does not match a D
NL in the SURL, then
Registries MUST provide Trademark Claims services (see <xref target=
"procDescSunrise" />) and
the DN MUST be reported in a Trademark Claims LORDN file during the
QLP Period.
</t>
</list>
<vspace blankLines='99' />
</t> </t>
<!-- <vspace blankLines='99' /> --> <ul spacing="normal">
<li>If the leftmost DNL of the DN being
effectively allocated (QLP Name in this section) matches a DNL in th
e SURL and an SMD is provided, then
Registries <bcp14>MUST</bcp14> provide Sunrise Services (see <xref t
arget="procDescSunrise" format="default"/>), and
the DN <bcp14>MUST</bcp14> be reported in a Sunrise LORDN file dur
ing the QLP Period. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
being effectively allocated, the leftmost DNL would be "xn--mgbach
tv".</li>
<li>If the QLP Name matches a DNL in the SURL but does not match a D
NL in the DNL List and an SMD is NOT provided (see Section
2.2 of <xref target="QLP-Addendum" format="default"/>), then
the DN <bcp14>MUST</bcp14> be reported in a Sunrise LORDN file u
sing the special SMD-id "99999-99999" during the QLP Period.</li>
<li>If the QLP Name matches a DNL in the SURL and also matches a DNL
in the DNL List and an SMD is NOT provided (see Section
2.2 of <xref target="QLP-Addendum" format="default"/>), then
Registries <bcp14>MUST</bcp14> provide Trademark Claims services
(see <xref target="procDescTrCl" format="default"/>), and
the DN <bcp14>MUST</bcp14> be reported in a Trademark Claims LORDN f
ile during the QLP 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 <bcp14>MUST</bcp14> provide Trademark Claims services (se
e <xref target="procDescTrCl" format="default"/>), and
the DN <bcp14>MUST</bcp14> be reported in a Trademark Claims LORDN f
ile during the QLP Period.</li>
</ul>
<t> <t>
The following table lists all the effective allocation scenarios dur ing a QLP Period: The following table lists all the effective allocation scenarios dur ing a QLP Period:
</t> </t>
<texttable title="QLP Effective Allocation Scenarios"> <table align="center">
<ttcol align='left'> <name>QLP Effective Allocation Scenarios</name>
QLP Name match in the SURL <thead>
</ttcol> <tr>
<ttcol align='left'> <th align="left">QLP Name Match in the SURL</th>
QLP Name match in the DNL List <th align="left">QLP Name Match in the DNL List</th>
</ttcol> <th align="left">SMD Was Provided by the Potential Registrant</t
<ttcol align='left'> h>
SMD was provided by the potential Registrant <th align="left">Registry <bcp14>MUST</bcp14> Provide Sunrise or
</ttcol> Trademark Claims Services</th>
<ttcol align='left'> <th align="left">Registry <bcp14>MUST</bcp14> Report DN Registra
Registry MUST provide Sunrise or Trademark Claims Services tion in &lt;type&gt; LORDN File</th>
</ttcol> </tr>
<ttcol align='left'> </thead>
Registry MUST report DN registration in &lt;type&gt; LORDN file <tbody>
</ttcol> <tr>
<c> <td align="left">Y</td>
Y <td align="left">Y</td>
</c> <td align="left">Y</td>
<c> <td align="left">Sunrise</td>
Y <td align="left">Sunrise</td>
</c> </tr>
<c> <tr>
Y <td align="left">Y</td>
</c> <td align="left">N</td>
<c> <td align="left">Y</td>
Sunrise <td align="left">Sunrise</td>
</c> <td align="left">Sunrise</td>
<c> </tr>
Sunrise <tr>
</c> <td align="left">N</td>
<c> <td align="left">Y</td>
Y <td align="left">--</td>
</c> <td align="left">Trademark Claims</td>
<c> <td align="left">Trademark Claims</td>
N </tr>
</c> <tr>
<c> <td align="left">N</td>
Y <td align="left">N</td>
</c> <td align="left">--</td>
<c> <td align="left">--</td>
Sunrise <td align="left">--</td>
</c> </tr>
<c> <tr>
Sunrise <td align="left">Y</td>
</c> <td align="left">Y</td>
<c> <td align="left">N (see Section
N 2.2 of <xref target="QLP-Addendum" format="default"/>)</td>
</c> <td align="left">Trademark Claims</td>
<c> <td align="left">Trademark Claims</td>
Y </tr>
</c> <tr>
<c> <td align="left">Y</td>
-- <td align="left">N</td>
</c> <td align="left">N (see Section
<c> 2.2 of <xref target="QLP-Addendum" format="default"/>)</td>
Trademark Claims <td align="left">--</td>
</c> <td align="left">Sunrise (using special SMD-id)</td>
<c> </tr>
Trademark Claims </tbody>
</c> </table>
<c>
N
</c>
<c>
N
</c>
<c>
--
</c>
<c>
--
</c>
<c>
--
</c>
<c>
Y
</c>
<c>
Y
</c>
<c>
N (see 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 (see section
2.2 of <xref target='QLP-Addendum' />)
</c>
<c>
--
</c>
<c>
Sunrise (using special SMD-id)
</c>
</texttable>
<t> <t>
The TMDB MUST provide the following services to Registries during a The TMDB <bcp14>MUST</bcp14> provide the following services to Regis
QLP Period: tries during a QLP Period:
<list style="symbols">
<t> SMD Revocation List (see <xref target="procDescSunriseSmdRevoc
List"/>) </t>
<t> NORN (see <xref target="procDescSunriseNordn"/>) </t>
<t> DNL List (see <xref target="procDescUpdateDnlList"/>) </t>
<t> Sunrise List (SURL) (see <xref target="procDescUpdatesurlList"
/></t>
</list>
</t> </t>
<ul spacing="normal">
<li> SMD Revocation List (see <xref target="procDescSunriseSmdRevocL
ist" format="default"/>) </li>
<li> NORDN (see <xref target="procDescSunriseNordn" format="default"
/>) </li>
<li> DNL List (see <xref target="procDescUpdateDnlList" format="defa
ult"/>) </li>
<li> Sunrise List (SURL) (see <xref target="procDescUpdatesurlList"
format="default"/>)</li>
</ul>
<t> <t>
The TMDB MUST provide the following services to Registrars during a The TMDB <bcp14>MUST</bcp14> provide the following services to Regis
QLP Period: trars during a QLP Period:
<list style="symbols">
<t> SMD Revocation List (see <xref target="procDescSunriseSmdRevoc
List"/>) </t>
<t> CNIS (see <xref target="cnisService"/>) </t>
</list>
</t> </t>
<ul spacing="normal">
<li> SMD Revocation List (see <xref target="procDescSunriseSmdRevocL
ist" format="default"/>) </li>
<li> CNIS (see <xref target="cnisService" format="default"/>) </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="TMBD QLP Services for Registries"> <name>TMDB QLP Services for Registries</name>
<section anchor="procDescUpdatesurlList" numbered="true" toc="default"
<section anchor="procDescUpdatesurlList" title="Sunrise List (SURL)"> >
<t> A new Sunrise List (SURL) MUST be published by the TMDB twice a <name>Sunrise List (SURL)</name>
day, by 00:00:00 and 12:00:00 <t> A new SURL <bcp14>MUST</bcp14> be published by the TMDB twice a
day, by 00:00:00 and 12:00:00
UTC. </t> UTC. </t>
<t> Registries offering the OPTIONAL QLP Period MUST refresh the lat <t> Registries offering the <bcp14>OPTIONAL</bcp14> QLP Period <bcp1
est version of the SURL at least once every 24 4>MUST</bcp14> refresh the latest version of the SURL at least once every 24
hours. </t> hours. </t>
<t> <figure anchor="figIntsurlList">
<figure anchor="figIntsurlList"> <name>Update of the SURL</name>
<preamble>Update of the SURL</preamble> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
.----------. .------. .----------. .------.
| Registry | | TMDB | | Registry | | TMDB |
'----------' '------' '----------' '------'
| | | |
.----------------. | .----------------. |
| Periodically, | | | Periodically, | |
| at least | | | at least | |
| every 24 hours | | | every 24 hours | |
'----------------' | '----------------' |
| | | |
|------------------------------->| |------------------------------->|
| Download the latest SURL | | Download the latest SURL |
|<-------------------------------| |<-------------------------------|
| | | |
| | | |
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="figIntsurlList" format="default"/> depicts the proc
ess of downloading the latest SURL initiated by the Registry.</t>
</t> <t> Note: The SURL will be the same regardless of the TLD. If a Back
end Registry
<t><xref target="figIntsurlList"/> depicts the process of downloading
the latest SURL initiated by the Registry.</t>
<t> Note: the SURL will be the same regardless of the TLD. If a Back
end Registry
Operator manages the infrastructure of several TLDs, the Backend R egistry Operator could Operator manages the infrastructure of several TLDs, the Backend R egistry Operator could
refresh the SURL once every 24 hours, the SURL could be used for a ll the refresh the SURL once every 24 hours, and the SURL could be used f or all the
TLDs managed by the Backend Registry Operator. </t> TLDs managed by the Backend Registry Operator. </t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="dataFormat" title="Data Format Descriptions">
<section anchor="dnlListFormat" title="Domain Name Label (DNL) List">
<section anchor="dataFormat" numbered="true" toc="default">
<name>Data Format Descriptions</name>
<section anchor="dnlListFormat" numbered="true" toc="default">
<name>Domain Name Label (DNL) List</name>
<t> <t>
This section defines the format of the list containing every This section defines the format of the list containing every
Domain Name Label (DNL) that matches a Pre-Registered Mark DNL that matches a Pre-Registered Mark
(PRM). The list is maintained by the TMDB and downloaded by (PRM). The list is maintained by the TMDB and downloaded by
Registries in regular intervals (see <xref Registries in regular intervals (see <xref target="procDescUpdateDnlLi
target="procDescUpdateDnlList" />). The Registries use the st" format="default"/>). The Registries use the
DNL List during the Trademark Claims Period to check whether DNL List during the Trademark Claims Period to check whether
a requested DN matches a DNL of a PRM. a requested DN matches a DNL of a PRM.
</t> </t>
<t> <t>
The DNL List contains all the DNLs covered by a PRM present in the TMD The DNL List contains all the DNLs covered by a PRM present in the TMDB
B at the datetime it is generated. at the
datetime that the DNL List is generated.
</t> </t>
<t> <t>
The DNL List is contained in a CSV formatted file that has the The DNL List is contained in a CSV-formatted file that has the
following structure: following structure:
<list style='symbols'>
<t>
first line: &lt;version&gt;,&lt;DNL List creation datetime&gt;
<list style='empty'>
<t>Where:
<list style='symbols'>
<t>
&lt;version&gt;, version of the file, this field MUST be 1
.
</t>
<t>
&lt;DNL List creation datetime&gt;, date and time in UTC t
hat the DNL List was created.
</t>
</list>
</t>
</list>
</t>
<t>
second line: a header line as specified in <xref target="RFC4180"/
>
<list style='empty'>
<t>With the header names as follows:</t>
<t>DNL,lookup-key,insertion-datetime</t>
</list>
</t>
<t>
One or more lines with: &lt;DNL&gt;,&lt;lookup key&gt;,&lt;DNL ins
ertion datetime&gt;
<list style='empty'>
<t>Where:
<list style='symbols'>
<t>
&lt;DNL&gt;, a Domain Name Label covered by a PRM.
</t>
<t>
&lt;lookup key&gt;, lookup key that the Registry MUST prov
ide 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: year that the TCN was generated.
</t>
<t>
MM: zero-padded month that the TCN was generated.
</t>
<t>
DD: zero-padded day that the TCN was generated.
</t>
<t>
vv: version of the TCN, possible values are 00 and 01.
</t>
<t>
X: one hex character. This is the first, second and th
ird hex character of encoding the
&lt;Random bits&gt; in base16 as specified in <xref ta
rget="RFC4648"/>.
</t>
<t>
Random bits: 144 random bits encoded in base64url as s
pecified in <xref target="RFC4648"/>.
</t>
<t>
Sequential number: zero-padded natural number in the r
ange 0000000001 to 2147483647.
</t>
</list>
</t>
<t>
&lt;DNL insertion datetime&gt;, datetime in UTC that the D
NL 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> </t>
<ul spacing="normal">
<figure> <li>
<preamble>Example of a DNL List:</preamble> <t>first line: &lt;version&gt;,&lt;DNL List creation datetime&gt;</t
<artwork> >
<![CDATA[ <ul empty="true" spacing="normal">
<li>
<t>Where:</t>
<ul spacing="normal">
<li>&lt;version&gt;: version of the file. This field <bcp14>MU
ST</bcp14> be 1.</li>
<li>&lt;DNL List creation datetime&gt;: date and time in UTC t
hat the DNL List was created.</li>
</ul>
</li>
</ul>
</li>
<li>
<t>second line: a header line, as specified in <xref target="RFC4180
" format="default"/></t>
<ul empty="true" spacing="normal">
<li>With the header names as 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 in
sertion 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.</li>
<li>
<t>&lt;lookup key&gt;: lookup key that the Registry <bcp14>M
UST</bcp14> provide to the Registrar. The lookup key has
the following format: &lt;YYYY&gt;&lt;MM&gt;&lt;DD&gt;&lt;
vv&gt;/&lt;X&gt;/&lt;X&gt;/&lt;X&gt;/&lt;Random bits&gt;&lt;Sequential number&gt
;, where:</t>
<ul spacing="normal">
<li>YYYY: year that the TCN was generated.</li>
<li>MM: zero-padded month that the TCN was generated.</li>
<li>DD: zero-padded day that the TCN was generated.</li>
<li>vv: version of the TCN; possible values are 00 and 01.
</li>
<li>X: one hex character. This is the first, second, and t
hird hex character of encoding the
&lt;Random bits&gt; in base16, as specified in <xref t
arget="RFC4648" format="default"/>.</li>
<li>Random bits: 144 random bits encoded in base64url, as
specified in <xref target="RFC4648" format="default"/>.</li>
<li>Sequential number: zero-padded natural number in the r
ange 0000000001 to 2147483647.</li>
</ul>
</li>
<li>
&lt;DNL insertion datetime&gt;: datetime in UTC that the D
NL was first inserted into the DNL List.
The possible two values of time for inserting a DNL to the
DNL List are 00:00:00 and 12:00:00 UTC.
</li>
</ul>
</li>
</ul>
</li>
</ul>
<t>Example of a DNL list:</t>
<figure>
<name>Example DNL List</name>
<sourcecode type=""><![CDATA[
1,2012-08-16T00:00:00.0Z 1,2012-08-16T00:00:00.0Z
DNL,lookup-key,insertion-datetime DNL,lookup-key,insertion-datetime
example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\
2010-07-14T00:00:00.0Z 2010-07-14T00:00:00.0Z
another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\
2012-08-16T00:00:00.0Z 2012-08-16T00:00:00.0Z
anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\
2011-08-16T12:00:00.0Z 2011-08-16T12:00:00.0Z
]]> ]]></sourcecode>
</artwork> </figure>
</figure>
<t> <t>
To provide authentication and integrity protection, the DNL To provide authentication and integrity protection, the DNL
List will be PGP <xref target="RFC4880" /> signed by the TMDB (see als List will be PGP <xref target="RFC4880" format="default"/> signed by t
o <xref he TMDB (see <xref target="procDescBootstrapPgpKeyRy" format="default"/>). The
target="procDescBootstrapPgpKeyRy" />). The PGP signature of the PGP signature of the
DNL List can be found in the similar URI but with extension .sig as sh DNL List can be found in the similar URI but with extension .sig, as s
own below. hown below.
</t> </t>
<t> <t>
The URL of the dy interface (<xref target="dy" />) is: The URLs of the dy interface (<xref target="dy" format="default"/>) ar
<list style="symbols"> e:
<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>
</t> </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> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="revocationlistFormat" title="SMD Revocation List">
<section anchor="revocationlistFormat" numbered="true" toc="default">
<name>SMD Revocation List</name>
<t> <t>
This section defines the format of the list of SMDs that have This section defines the format of the list of SMDs that have
been revoked. The list is maintained by the TMDB and been revoked. The list is maintained by the TMDB and
downloaded by Registries (and optionally by Registrars) in downloaded by Registries (and optionally by Registrars) in
regular intervals (see <xref regular intervals (see <xref target="procDescSunriseSmdRevocList" form
target="procDescSunriseSmdRevocList" />). The SMD Revocation at="default"/>). The SMD Revocation
List is used during the Sunrise Period to validate SMDs List is used during the Sunrise Period to validate SMDs
received. The SMD Revocation List has a similar function as received. The SMD Revocation List has a similar function as
CRLs used in PKI <xref target='RFC5280' />. CRLs used in PKI <xref target="RFC5280" format="default"/>.
</t> </t>
<t> <t>
The SMD Revocation List contains all the revoked SMDs present in The SMD Revocation List contains all the revoked SMDs present in
the TMDB at the datetime it is generated. the TMDB at the datetime it is generated.
</t> </t>
<t> <t>
The SMD Revocation List is contained in a CSV formatted file that has The SMD Revocation List is contained in a CSV-formatted file that has
the following structure: the following structure:
<list style='symbols'> </t>
<ul spacing="normal">
<li>
<t> <t>
first line: &lt;version&gt;,&lt;SMD Revocation List creation datet ime&gt; first line: &lt;version&gt;,&lt;SMD Revocation List creation datet ime&gt;
<list style='empty'>
<t>Where:
<list style='symbols'>
<t>
&lt;version&gt;, version of the file, this field MUST be 1.
</t>
<t>
&lt;SMD Revocation List creation datetime&gt;, datetime in UTC
that the SMD Revocation List was created.
</t>
</list>
</t>
</list>
</t> </t>
<ul empty="true" spacing="normal">
<t> <li>
second line: a header line as specified in <xref target="RFC4180"/ <t>Where:</t>
> <ul spacing="normal">
<list style='empty'> <li>&lt;version&gt;: version of the file. This field <bcp14>MU
<t>With the header names as follows:</t> ST</bcp14> be 1.</li>
<t>smd-id,insertion-datetime</t> <li>&lt;SMD Revocation List creation datetime&gt;: datetime in
</list> UTC that the SMD Revocation List was created.</li>
</t> </ul>
</li>
<t> </ul>
One or more lines with: &lt;smd-id&gt;,&lt;revoked SMD datetime&gt </li>
; <li>
<list style='empty'> <t>second line: a header line, as specified in <xref target="RFC4180
<t>Where: " format="default"/></t>
<list style='symbols'> <ul empty="true" spacing="normal">
<t> <li>With the header names as follows:</li>
&lt;smd-id&gt;, identifier of the SMD that was revoked. <li>smd-id,insertion-datetime</li>
</t> </ul>
<t> </li>
&lt;revoked SMD datetime&gt;, revocation datetime in UTC of th <li>
e SMD. <t>One or more lines with: &lt;smd-id&gt;,&lt;revoked SMD datetime&g
t;</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.</l
i>
<li>&lt;revoked SMD datetime&gt;: revocation datetime in UTC o
f the SMD.
The possible two values of time for inserting an SMD to the SM D Revocation List The possible two values of time for inserting an SMD to the SM D Revocation List
are 00:00:00 and 12:00:00 UTC. are 00:00:00 and 12:00:00 UTC.</li>
</t> </ul>
</list> </li>
</t> </ul>
</list> </li>
</t> </ul>
</list>
</t>
<t> <t>
To provide integrity protection, the SMD Revocation List is To provide integrity protection, the SMD Revocation List is
PGP signed by the TMDB (see also <xref PGP signed by the TMDB (see <xref target="procDescBootstrapPgpKeyRy" f
target="procDescBootstrapPgpKeyRy" />). The SMD Revocation ormat="default"/>). The SMD Revocation
List is provided by the TMDB with extension .csv. The PGP signature o f the List is provided by the TMDB with extension .csv. The PGP signature o f the
SMD Revocation List can be found in the similar URI but with extension .sig as shown below. SMD Revocation List can be found in the similar URI but with extension .sig, as shown below.
</t> </t>
<t> <t>
The URL of the sr interface (<xref target="sr" />) and The URLs of the sr interface (<xref target="sr" format="default"/>) an
sy interface (<xref target="sy" />) is: d
<list style='symbols'> sy interface (<xref target="sy" format="default"/>) are:
<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>
</t> </t>
<ul spacing="normal">
<figure> <li>https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.csv</li>
<preamble>Example of an SMD Revocation List:</preamble> <li>https://&lt;tmdb-domain-name&gt;/smdrl/smdrl-latest.sig</li>
<artwork> </ul>
<![CDATA[ <t>Example of an SMD Revocation List:</t>
<figure>
<name>Example SMD Revocation List</name>
<sourcecode type=""><![CDATA[
1,2012-08-16T00:00:00.0Z 1,2012-08-16T00:00:00.0Z
smd-id,insertion-datetime smd-id,insertion-datetime
2-2,2012-08-15T00:00:00.0Z 2-2,2012-08-15T00:00:00.0Z
3-2,2012-08-15T00:00:00.0Z 3-2,2012-08-15T00:00:00.0Z
1-2,2012-08-15T00:00:00.0Z 1-2,2012-08-15T00:00:00.0Z
]]> ]]></sourcecode>
</artwork> </figure>
</figure>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="lordnFormat" title="List of Registered Domain Names (LORD <section anchor="lordnFormat" numbered="true" toc="default">
N) file"> <name>List of Registered Domain Names (LORDN) File</name>
<t> <t>
This section defines the format of the List of Registered This section defines the format of the List of Registered Domain Names
Domain Names (LORDN), which is maintained by each Registry (LORDN),
and uploaded at least daily to the TMDB. Every time a DN matching a which is maintained by each Registry
DNL of a PRM said DN is added to the LORDN along with and uploaded at least daily to the TMDB. Every time there is a DN matc
hing a
DNL of a PRM, said DN is added to the LORDN, along with
further information related to its registration. further information related to its registration.
</t> </t>
<t> <t>
The URIs of the yd interface (<xref target="yd" />) used to The URIs of the yd interface (<xref target="yd" format="default"/>) us
upload the LORDN file is: ed to
<list style="symbols"> upload the LORDN file are:
<t>
Sunrise LORDN file:
<list style="empty">
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/s
unrise&nbsp;&gt;
</t>
</list>
</t>
<t>
Trademark Claims LORDN file:
<list style="empty">
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/c
laims&nbsp;&gt;
</t>
</list>
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>Sunrise LORDN file: </t>
<t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise</t>
</li>
<li>
<t>Trademark Claims LORDN file: </t>
<t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims</t>
</li>
</ul>
<t> <t>
During a QLP Period, Registries MAY be required to upload Sunrise or T During a QLP Period, Registries <bcp14>MAY</bcp14> be required to uplo
rademark Claims LORDN files. ad Sunrise or Trademark Claims LORDN files.
The URIs of the yd interface used to upload LORDN files during a QLP P The URIs of the yd interface used to upload LORDN files during a QLP P
eriod is: eriod are:
<list style="symbols">
<t>
Sunrise LORDN file (during QLP Period):
<list style="empty">
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/s
unrise/qlp&nbsp;&gt;
</t>
</list>
</t>
<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;/c
laims/qlp&nbsp;&gt;
</t>
</list>
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>Sunrise LORDN file (during QLP Period): </t>
<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):</t>
<t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp</t>
</li>
</ul>
<t> <t>
The yd interface (<xref target="yd" />) returns the following HTTP sta tus codes after a HTTP POST request method is The yd interface (<xref target="yd" format="default"/>) returns the fo llowing HTTP status codes after an HTTP POST request method is
received: received:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The interface provides a HTTP/202 status code if the interface was <li>
able to receive the LORDN file and the syntax of the LORDN file is c <t>The interface provides an HTTP/202 status code if the interface w
orrect. as
<list style="empty"> able to receive the LORDN file and the syntax of the LORDN file is c
<t> orrect.</t>
The interface provides the LORDN Transaction Identifier in the H <t>The interface provides the LORDN Transaction Identifier in the
TTP Entity-body that would be used HTTP Entity-body that would be used
by the Registry to download the LORDN Log file. The LORDN Transa by the Registry to download the LORDN Log file. The LORDN Transa
ction Identifier is a natural number ction Identifier is a zero-padded natural number
zero-padded in the range 0000000000000000001 to 9223372036854775 in the range 0000000000000000001 to 9223372036854775807.
807.
</t> </t>
<t> <t>The TMDB uses the &lt;LORDN creation datetime&gt; element of th
The TMDB uses the &lt;LORDN creation datetime&gt; element of the e LORDN file
LORDN file
as a unique client-side identifier. If a LORDN file with the sam e &lt;LORDN creation datetime&gt; of as a unique client-side identifier. If a LORDN file with the sam e &lt;LORDN creation datetime&gt; of
a previously sent LORDN file is received by the TMDB, the LORDN Transaction Identifier a previously sent LORDN file is received by the TMDB, the LORDN Transaction Identifier
of the previously sent LORDN file MUST be provided to the Regist ry. The TMDB MUST ignore the DN Lines present in the of the previously sent LORDN file <bcp14>MUST</bcp14> be provide d to the Registry. The TMDB <bcp14>MUST</bcp14> ignore the DN Lines present in t he
LORDN file if a LORDN file with the same &lt;LORDN creation date time&gt; was previously sent. LORDN file if a LORDN file with the same &lt;LORDN creation date time&gt; was previously sent.
</t> </t>
<t> <t>The HTTP Location header field contains
The HTTP Location header field contains the URI where the LORDN Log file could be retrieved later, for exa
the URI where the LORDN Log file could be retrieved later, for e mple:</t>
xample: <ul spacing="normal" empty="true">
<list style="empty"> <li>
<t> <t>202 Accepted</t>
202 Accepted <t>Location: https://&lt;tmdb-domain-name&gt;/LORDN/example/sunris
</t> e/0000000000000000001/result</t>
<t> </li>
Location: https://&lt;tmdb-domain-name&gt;/LORDN/example/sun </ul></li></ul>
rise/0000000000000000001/result
</t> <ul spacing="normal">
</list> <li> The interface provides an HTTP/400 if the request is incorrect or
</t> the syntax of the LORDN file is incorrect.
</list> The TMDB <bcp14>MUST</bcp14> return a human-readable message in the HT
</t> TP Entity-body
<t> regarding the incorrect syntax of the LORDN file.</li>
The interface provides a HTTP/400 if the request is incorrect or <li>The interface provides an HTTP/401 status code if the credentials
the syntax of the LORDN file is incorrect. provided do not authorize the Registry Operator to upload a LORDN file
The TMDB MUST return a human readable message in the HTTP Entity-bod .</li>
y <li>The TMDB <bcp14>MUST</bcp14> return an HTTP/404 status code when t
regarding the incorrect syntax of the LORDN file. rying to upload a LORDN file using
</t>
<t>
The interface provides a HTTP/401 status code if the credentials
provided does not authorize the Registry Operator to upload a LORDN
file.
</t>
<t>
The TMDB MUST return a 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 o r the https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/qlp o r
https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp interf ace outside of a QLP Period plus 26 hours. https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/qlp interf ace outside of a QLP Period plus 26 hours.
</t> </li>
<t> <li> The interface provides an HTTP/500 status code if the system is
The interface provides a HTTP/500 status code if the system is experiencing a general failure.</li>
experiencing a general failure. </ul>
</t>
</list>
</t>
<t>
For example, to upload the Sunrise LORDN file for TLD &quot;example&qu
ot;, the URI would be:
<list style="empty">
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise&n
bsp;&gt;
</t>
</list>
</t>
<t> <t>
The LORDN is contained in a CSV formatted file that has the For example, to upload the Sunrise LORDN file for TLD "example", the U
following structure: RI would be:
<list style='symbols'> </t>
<t indent="3">https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise<
<t> /t>
For Sunrise Period:
<list style='symbols'>
<t> <t>The LORDN is contained in a CSV-formatted file that has the
first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&l following structure:</t>
t;Number of DN Lines&gt;
<list style='empty'>
<t>Where:
<list style='symbols'>
<t>
&lt;version&gt;, version of the file, this field MUST be 1
.
</t>
<t>
&lt;LORDN creation datetime&gt;, date and time in UTC that
the LORDN was created.
</t>
<t>
&lt;Number of DN Lines&gt;, number of DN Lines present in
the LORDN file.
</t>
</list>
</t>
</list>
</t>
<t> <ul spacing="normal">
second line: a header line as specified in <xref target="RFC41 <li>
80"/> <t>For Sunrise Period: </t>
<list style='empty'> <ul spacing="normal">
<t>With the header names as follows:</t> <li>
<t>roid,domain-name,SMD-id,registrar-id,registration-datetime, <t>first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&
application-datetime</t> lt;Number of DN Lines&gt;</t>
</list> <ul empty="true" spacing="normal">
<li>
<t>Where:</t>
<ul spacing="normal">
<li>&lt;version&gt;: version of the file. This field <bcp1
4>MUST</bcp14> be 1.</li>
<li>&lt;LORDN creation datetime&gt;: date and time in UTC
that the LORDN was created.</li>
<li>&lt;Number of DN Lines&gt;: number of DN Lines present
in the LORDN file.</li>
</ul>
</li>
</ul>
</li>
<li>
<t>second line: a header line, as specified in <xref target="RFC
4180" format="default"/></t>
<ul empty="true" spacing="normal">
<li>With the header names as follows:</li>
<li>roid,domain-name,SMD-id,registrar-id,registration-datetime,applic
ation-datetime</li>
</ul>
</li>
<li>
<t>One or more lines with: &lt;roid&gt;,&lt;DN registered&gt;,&l
t;SMD-id&gt;,&lt;IANA Registrar id&gt;,&lt;datetime of registration&gt;,&lt;date
time of application creation&gt;
</t> </t>
<ul empty="true" spacing="normal">
<t> <li>
One or more lines with: &lt;roid&gt;,&lt;DN registered&gt;,&lt <t>Where:</t>
;SMD-id&gt;,&lt;IANA Registrar id&gt;,&lt;datetime of registration&gt;,&lt;datet <ul spacing="normal">
ime of application creation&gt; <li>&lt;roid&gt;: DN Repository Object IDentifier (DNROID)
<list style='empty'> in the SRS.</li>
<t>Where: <li>&lt;DN registered&gt;: DN that was effectively allocat
<list style='symbols'> ed. For IDNs, the A-label form
<t> is used.</li>
&lt;roid&gt;, DN Repository Object IDentifier (DNROID) in <li>&lt;SMD-id&gt;: SMD ID used for registration.</li>
the SRS. <li>&lt;IANA Registrar ID&gt;: IANA Registrar ID.</li>
</t> <li>&lt;datetime of registration&gt;: date and time in UTC
<t> that the domain was effectively allocated.</li>
&lt;DN registered&gt;, DN that was effectively allocated. <li><bcp14>OPTIONAL</bcp14> &lt;datetime of application cr
For IDNs, the A-label form eation&gt;: date and time in UTC that
is used. the application was created. The &lt;datetime of applicati
</t> on creation&gt; <bcp14>MUST</bcp14> be provided
<t>
&lt;SMD-id&gt;, SMD ID used for registration.
</t>
<t>
&lt;IANA Registrar ID&gt;, IANA Registrar ID.
</t>
<t>
&lt;datetime of registration&gt;, date and time in UTC tha
t the domain was effectively allocated.
</t>
<t>
OPTIONAL &lt;datetime of application creation&gt;, date an
d time in UTC that
the application was created. The &lt;datetime of applicati
on creation&gt; MUST be provided
in case of a DN effective allocation based on an asynchron ous registration in case of a DN effective allocation based on an asynchron ous registration
(e.g., when using auctions). (e.g., when using auctions).</li>
</t> </ul>
</list> </li>
</t> </ul>
</list> </li>
</t> </ul>
</list> <t>Example of a Sunrise LORDN file:</t>
<figure>
<figure> <name>Example Sunrise LORDN File</name>
<preamble>Example of a Sunrise LORDN file:</pream <sourcecode type=""><![CDATA[
ble>
<artwork>
<![CDATA[
1,2012-08-16T00:00:00.0Z,3 1,2012-08-16T00:00:00.0Z,3
roid,domain-name,SMD-id,registrar-id,registration-datetime,\ roid,domain-name,SMD-id,registrar-id,registration-datetime,\
application-datetime application-datetime
SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\
2012-07-15T00:50:00.0Z 2012-07-15T00:50:00.0Z
EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.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 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z
]]> ]]></sourcecode>
</artwork> </figure>
</figure> </li>
</t> <li>
<t>For the Trademark Claims Period:</t>
<t> <ul spacing="normal">
For Trademark Claims Period: <li>
<list style='symbols'> <t>first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&
lt;Number of DN Lines&gt;</t>
<t> <ul empty="true" spacing="normal">
first line: &lt;version&gt;,&lt;LORDN creation datetime&gt;,&l <li>
t;Number of DN Lines&gt; <t>Where:</t>
<ul spacing="normal">
<list style='empty'> <li>&lt;version&gt;: version of the file. This field <bcp1
<t>Where: 4>MUST</bcp14> be 1.</li>
<list style='symbols'> <li>&lt;LORDN creation datetime&gt;: date and time in UTC
<t> that the LORDN was created.</li>
&lt;version&gt;, version of the file, this field MUST be 1 <li>&lt;Number of DN Lines&gt;: number of DN Lines present
. in the LORDN file.</li>
</t> </ul>
<t> </li>
&lt;LORDN creation datetime&gt;, date and time in UTC that </ul>
the LORDN was created. </li>
</t> <li>
<t> <t>second line: a header line, as specified in <xref target="RFC
&lt;Number of DN Lines&gt;, number of DN Lines present in 4180" format="default"/></t>
the LORDN file. <ul empty="true" spacing="normal">
</t> <li>With the header names as follows:</li>
</list> <li>roid,domain-name,notice-id,registrar-id,registration-datetime
</t> ,ack-datetime,application-datetime</li>
</list> </ul>
</t> </li>
<li>
<t> <t>One or more lines with: &lt;roid&gt;,&lt;DN registered&gt;,&l
second line: a header line as specified in <xref target="RFC41 t;TCNID&gt;,&lt;IANA Registrar id&gt;,&lt;datetime of registration&gt;,&lt;datet
80"/> ime of acceptance of the TCN&gt;,&lt;datetime of application creation&gt;</t>
<list style='empty'> <ul empty="true" spacing="normal">
<t>With the header names as follows:</t> <li>
<t>roid,domain-name,notice-id,registrar-id,registration-dateti <t>Where:</t>
me,ack-datetime,application-datetime</t> <ul spacing="normal">
</list> <li>&lt;roid&gt;: DNROID in the SRS.</li>
</t> <li>&lt;DN registered&gt;: DN that was effectively allocat
ed. For IDNs, the A-label form
<t> is used.</li>
One or more lines with: &lt;roid&gt;,&lt;DN registered&gt;,&lt <li>&lt;TCNID&gt;: Trademark Claims Notice Identifier, as
;TCNID&gt;,&lt;IANA Registrar id&gt;,&lt;datetime of registration&gt;,&lt;dateti specified in &lt;tmNotice:id&gt;.</li>
me of acceptance of the TCN&gt;,&lt;datetime of application creation&gt; <li>&lt;IANA Registrar ID&gt;: IANA Registrar ID.</li>
<list style='empty'> <li>&lt;datetime of registration&gt;: date and time in UTC
<t>Where: that the domain was effectively allocated.</li>
<list style='symbols'> <li>&lt;datetime of acceptance of the TCN&gt;: date and ti
<t> me in UTC that the TCN was acknowledged.</li>
&lt;roid&gt;, DN Repository Object IDentifier (DNROID) in <li><bcp14>OPTIONAL</bcp14> &lt;datetime of application cr
the SRS. eation&gt;: date and time in UTC that
</t> the application was created. The &lt;datetime of applicati
<t> on creation&gt; <bcp14>MUST</bcp14> be provided
&lt;DN registered&gt;, DN that was effectively allocated.
For IDNs, the A-label form
is used.
</t>
<t>
&lt;TCNID&gt;, Trademark Claims Notice Identifier as speci
fied in &lt;tmNotice:id&gt;.
</t>
<t>
&lt;IANA Registrar ID&gt;, IANA Registrar ID.
</t>
<t>
&lt;datetime of registration&gt;, date and time in UTC tha
t the domain was effectively allocated.
</t>
<t>
&lt;datetime of acceptance of the TCN&gt;, date and time i
n UTC that the TCN was acknowledged.
</t>
<t>
OPTIONAL &lt;datetime of application creation&gt;, date an
d time in UTC that
the application was created. The &lt;datetime of applicati
on creation&gt; MUST be provided
in case of a DN effective allocation based on an asynchron ous registration in case of a DN effective allocation based on an asynchron ous registration
(e.g., when using auctions). (e.g., when using auctions).</li>
</t> </ul>
</list> </li>
</t> <li> For a DN matching a DNL of a PRM at the moment of registr
<t> ation, created
For a DN matching a DNL of a PRM at the moment of registrati without the TCNID, expiration datetime,
on, created and acceptance datetime because DNL was inserted (or reinser
without the TCNID, expiration datetime ted) for the first time
and acceptance datetime, because DNL was inserted (or re-ins into a DNL List less than 24 hours ago, the string "recent-d
erted) for the first time nl-insertion" <bcp14>MAY</bcp14> be
into DNL List less than 24 hours ago, the string "recent-dnl specified in &lt;TCNID&gt; and &lt;datetime of acceptance of
-insertion" MAY be the TCN&gt;.</li>
specified in &lt;TCNID&gt; and &lt;datetime of acceptance of </ul>
the TCN&gt;. </li>
</t> </ul>
</list> <t>Example of a Trademark Claims LORDN file:</t>
</t> <figure>
</list> <name>Example Trademark Claims LORDN File</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<preamble>Example of a Trademark Claims LORDN file:</pream
ble>
<artwork>
<![CDATA[
1,2012-08-16T00:00:00.0Z,3 1,2012-08-16T00:00:00.0Z,3
roid,domain-name,notice-id,registrar-id,registration-datetime,\ roid,domain-name,notice-id,registrar-id,registration-datetime,\
ack-datetime,application-datetime ack-datetime,application-datetime
SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ SH8013-REP,example1.gtld,a76716ed9223352036854775808,\
9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z
EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ EK77-REP,example2.gtld,a7b786ed9223372036856775808,\
9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z
HB800-REP,example3.gtld,recent-dnl-insertion,\ HB800-REP,example3.gtld,recent-dnl-insertion,\
9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion
]]> ]]></artwork>
</artwork> </figure>
</figure> </li>
</ul>
</t>
</list>
</t>
<!-- <vspace blankLines='99' /> -->
<section anchor="lordnLogFormat" title="LORDN Log file">
<section anchor="lordnLogFormat" numbered="true" toc="default">
<name>LORDN Log File</name>
<t> <t>
After reception of the LORDN file, the TMDB verifies its After reception of the LORDN file, the TMDB verifies its
content for syntactical and semantical correctness. content for syntactical and semantic correctness.
The output of the LORDN file verification is retrieved using the The output of the LORDN file verification is retrieved using the
yd interface (<xref target="yd" />). yd interface (<xref target="yd" format="default"/>).
</t> </t>
<t> <t>
The URI of the yd interface (<xref target="yd" />) used to The URIs of the yd interface (<xref target="yd" format="default"/>)
retrieve the LORDN Log file is: used to
<list style="symbols"> retrieve the LORDN Log file are:
<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 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>
<ul spacing="normal">
<li>
<t>Sunrise LORDN Log file:</t>
<t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/sunrise/&l
t;lordn-transaction-identifier&gt;/result</t>
</li>
<li>
<t>Trademark Claims LORDN Log file: </t>
<t>https://&lt;tmdb-domain-name&gt;/LORDN/&lt;TLD&gt;/claims/&lt;l
ordn-transaction-identifier&gt;/result</t>
</li>
</ul>
<t> <t>
A Registry Operator MUST NOT send more than one request per minute p er TLD to download A Registry Operator <bcp14>MUST NOT</bcp14> send more than one reque st per minute per TLD to download
a LORDN Log file. a LORDN Log file.
</t> </t>
<t> <t>
The yd interface (<xref target="yd" />) returns the following HTTP s tatus codes after a HTTP GET request method is The yd interface (<xref target="yd" format="default"/>) returns the following HTTP status codes after an HTTP GET request method is
received: received:
<list style="symbols">
<t>
The interface provides a HTTP/200 status code if the interface w
as
able to provide the LORDN Log file.
The LORDN Log file is contained in the HTTP Entity-body.
</t>
<t>
The interface provides a HTTP/204 status code if the LORDN Trans
action
Identifier is correct, but the server has not finalized processi
ng the LORDN
file.
</t>
<t>
The interface provides a HTTP/400 status code if the request is
incorrect.
</t>
<t>
The interface provides a HTTP/401 status code if the credentials
provided does not authorize the Registry Operator to download th
e LORDN Log file.
</t>
<t>
The interface provides a HTTP/404 status code if the LORDN Trans
action
Identifier is incorrect.
</t>
<t>
The interface provides a HTTP/500 status code if the system is
experiencing a general failure.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>The interface provides an HTTP/200 status code if the interface
was
able to provide the LORDN Log file.
The LORDN Log file is contained in the HTTP Entity-body.</li>
<li>The interface provides an HTTP/204 status code if the LORDN Tran
saction
Identifier is correct but the server has not finalized processin
g the LORDN
file.</li>
<li>The interface provides an HTTP/400 status code if the request is
incorrect.</li>
<li> The interface provides an HTTP/401 status code if the credentia
ls
provided do not authorize the Registry Operator to download the
LORDN Log file.</li>
<li>The interface provides an HTTP/404 status code if the LORDN Tran
saction
Identifier is incorrect.</li>
<li>The interface provides an HTTP/500 status code if the system is
experiencing a general failure.</li>
</ul>
<t> <t>
For example, to obtain the LORDN Log file in case of a Sunrise LORDN file with LORDN Transaction Identifier 0000000000000000001 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; the URI would be: and TLD "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> </t>
<t>
The LORDN Log file is contained in a CSV formatted file that has the
following structure:
<list style='symbols'> <t indent ="3">https://&lt;tmdb-domain-name&gt;/LORDN/example/sunrise/
<t> 0000000000000000001/result
first line: &lt;version&gt;,&lt;LORDN Log creation datetime&gt;,
&lt;LORDN file creation datetime&gt;,&lt;LORDN Log Identifier&gt;,&lt;Status fla
g&gt;,&lt;Warning flag&gt;,&lt;Number of DN Lines&gt;
<list style='empty'>
<t>Where:
<list style='symbols'>
<t>
&lt;version&gt;, version of the file, this field MUST be 1.
</t>
<t>
&lt;LORDN Log creation datetime&gt;, date and time in UTC th
at the LORDN Log was created.
</t>
<t>
&lt;LORDN file creation datetime&gt;, date and time in UTC o
f creation for the LORDN file that
this log file is referring to.
</t>
<t>
&lt;LORDN Log Identifier&gt;, unique identifier of the LORDN
Log provided by the TMDB. This identifier
could be used by the Registry Operator to unequivocally iden
tify the LORDN Log. The identified will be
a string of a maximum LENGTH of 60 characters from the Base
64 alphabet.
</t>
<t>
&lt;Status flag&gt;, whether the LORDN file has been accepte
d for processing by the TMDB.
Possible values are &quot;accepted&quot; or &quot;rejected&q
uot;.
</t>
<t>
&lt;Warning flag&gt;, whether the LORDN Log has any warning
result codes. Possible values are
&quot;no-warnings&quot; or &quot;warnings-present&quot;.
</t>
<t>
&lt;Number of DN Lines&gt;, number of DNs effective allocati
ons processed in the LORDN file.
</t>
</list>
</t>
<t>
A Registry Operator is not required to process a LORDN Log wit
h a &lt;Status flag&gt;=&quot;accepted&quot;
and &lt;Warning flag&gt;=&quot;no-warnings&quot;.
</t>
</list>
</t>
<t>
second line: a header line as specified in <xref target="RFC4180
"/>
<list style='empty'>
<t>With the header names as follows:</t>
<t>roid,result-code</t>
</list>
</t> </t>
<t> <t>
One or more lines with: &lt;roid&gt;,&lt;result code&gt; The LORDN Log file is contained in a CSV-formatted file that has the
<list style='empty'> following structure:
<t>Where:
<list style='symbols'>
<t>
&lt;roid&gt;, DN Repository Object IDentifier (DNROID) in th
e SRS.
</t>
<t>
&lt;result code&gt;, result code as described in <xref targe
t="lordnRetCodes" />.
</t>
</list>
</t>
</list>
</t>
</list>
</t> </t>
<figure> <ul spacing="normal">
<preamble>Example of a LORDN Log file:</preamble> <li>
<artwork> <t>first line: &lt;version&gt;,&lt;LORDN Log creation datetime&gt;
<![CDATA[ ,&lt;LORDN file creation datetime&gt;,&lt;LORDN Log Identifier&gt;,&lt;Status fl
ag&gt;,&lt;Warning flag&gt;,&lt;Number of DN Lines&gt;</t>
<ul empty="true" spacing="normal">
<li>
<t>Where:</t>
<ul spacing="normal">
<li>&lt;version&gt;: version of the file. This field <bcp14>
MUST</bcp14> be 1.
</li>
<li>&lt;LORDN Log creation datetime&gt;: date and time in UT
C that the LORDN Log was created.</li>
<li>&lt;LORDN file creation datetime&gt;: date and time in U
TC of creation for the LORDN file that
this log file is referring to.</li>
<li>&lt;LORDN Log Identifier&gt;: unique identifier of the L
ORDN Log provided by the TMDB. This identifier
could be used by the Registry Operator to unequivocally iden
tify the LORDN Log. The identified will be
a string of a maximum length of 60 characters from the base6
4 alphabet.</li>
<li>&lt;Status flag&gt;: whether the LORDN file has been acc
epted for processing by the TMDB.
Possible values are "accepted" or "rejected".</li>
<li>&lt;Warning flag&gt;: whether the LORDN Log has any warn
ing result codes. Possible values are
"no-warnings" or "warnings-present".</li>
<li>&lt;Number of DN Lines&gt;: number of DN effective alloc
ations processed in the LORDN file.</li>
</ul>
</li>
<li>A Registry Operator is not required to process a LORDN Log w
ith &lt;Status flag&gt;="accepted"
and &lt;Warning flag&gt;="no-warnings".</li>
</ul>
</li>
<li>
<t>second line: a header line, as specified in <xref target="RFC41
80" format="default"/> </t>
<ul empty="true" spacing="normal">
<li>With the header names as follows:</li>
<li>roid,result-code</li>
</ul>
</li>
<li>
<t>One or more lines with: &lt;roid&gt;,&lt;result code&gt; </t>
<ul empty="true" spacing="normal">
<li>
<t>Where:</t>
<ul spacing="normal">
<li>&lt;roid&gt;: DNROID in the SRS.</li>
<li>&lt;result code&gt;: result code, as described in <xref
target="lordnRetCodes" format="default"/>.</li>
</ul>
</li>
</ul>
</li>
</ul>
<t>Example of a LORDN Log 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,\ 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\
0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\
accepted,no-warnings,1 accepted,no-warnings,1
roid,result-code roid,result-code
SH8013-REP,2000 SH8013-REP,2000
]]> ]]></sourcecode>
</artwork> </figure>
</figure>
<!-- <vspace blankLines='99' /> -->
<section anchor="lordnRetCodes" title="LORDN Log Result Codes">
<t> <section anchor="lordnRetCodes" numbered="true" toc="default">
<name>LORDN Log Result Codes</name>
<t>
The classes The classes
of result codes (rc) are listed below. Those classes in square of result codes (rc) are listed below. The classes in square
brackets are not used at this time, but may come into use brackets are not used at this time but may come into use
at some later stage. The at some later stage. The
first two digits of a result code denote the result code first two digits of a result code denote the result code
class, which defines the outcome at the TMDB: class, which defines the outcome at the TMDB:
<list style='symbols'> </t>
<ul spacing="normal">
<t> <li>ok: Success. The DN Line is accepted by the TMDB.</li>
ok: Success, DN Line accepted by the TMDB. <li>warn: A warning is issued. The DN Line is accepted by the TMD
</t> B.</li>
<li>err: An error is issued. The LORDN file is rejected by the TMD
<t> B.</li>
warn: a warning is issued, DN Line accepted by the TMDB. </ul>
</t> <t>
In cases where a DN line is processed and the error result code is
<t> 45xx or
err: an error is issued, LORDN file rejected by the TMDB. 46xx, the LORDN file <bcp14>MUST</bcp14> be rejected by the
</t> TMDB. If the LORDN file is rejected, DN Lines that are syntacticall
</list> y
</t>
<t>
In case that after processing a DN Line, the error result code i
s 45xx or 46xx for that DN Line,
the LORDN file MUST be rejected by the TMDB. If the LORDN file i
s rejected, DN Lines that are syntactically
valid will be reported with a 2001 result code. A 2001 result co de means that the DN Line is valid will be reported with a 2001 result code. A 2001 result co de means that the DN Line is
syntactically valid, however the DN Line was not processed becau syntactically valid; however, the DN Line was not processed beca
se the LORDN file was rejected. use the LORDN file was rejected.
All DNs reported in a rejected LORDN file MUST be reported again All DNs reported in a rejected LORDN file <bcp14>MUST</bcp14> be
by the Registry because none of the DN Lines present reported again by the Registry because none of the DN Lines present
in the LORDN file have been processed by the TMDB. in the LORDN file have been processed by the TMDB.
</t> </t>
<t> <t>LORDN Log Result Code Classes:</t>
<table>
</t> <name>LORDN Log Result Code Classes</name>
<figure> <thead>
<preamble>LORDN Log Result Code Classes:</preamble> <tr>
<artwork>
<![CDATA[
code Class outcome
20xx Success ok
35xx [ DN Line syntax warning ] warn
36xx DN Line semantic warning warn
45xx DN Line syntax error err
46xx DN Line semantic error err
]]>
</artwork>
</figure>
<t>
In the following, the LORDN Log result codes used by the TMDB
are described:
</t>
<figure>
<preamble>LORDN Log Result Codes:</preamble>
<artwork>
<![CDATA[
rc Short Description
Long Description
2000 OK
DN Line successfully processed.
2001 OK but not processed
DN Line is syntactically correct but was not processed
because the LORDN file was rejected.
3601 TCN Acceptance Date after Registration Date
TCN Acceptance Date in DN Line is newer than the Registration
Date.
3602 Duplicate DN Line
This DN Line is an exact duplicate of another DN Line in same
file, DN Line ignored.
3603 DNROID Notified Earlier
Same DNROID has been notified earlier, DN Line ignored.
3604 TCN Checksum invalid
Based on the DN effectively allocated, the TCNID and the
expiration date of the linked TCN, the TCN Checksum is
invalid.
3605 TCN Expired
The TCN was already expired (based on the <tmNotice:notAfter>
field of the TCN) at the datetime of acknowledgement.
3606 Wrong TCNID used
The TCNID used for the registration does not match
the related DN.
3609 Invalid SMD used
The SMD used for registration was not valid at the moment of
registration based on the <smd:notBefore> and <smd:notAfter>
elements.
In case of an asynchronous registration, this refer to the
<datetime of application creation>.
3610 DN reported outside of the time window
The DN was reported outside of the required 26 hours
reporting window.
3611 DN does not match the labels in SMD
The DN does not match the labels included in the SMD.
3612 SMDID does not exist
The SMDID has never existed in the central repository.
3613 SMD was revoked when used
The SMD used for registration was revoked more than
24 hours ago of the <datetime of registration>.
In case of an asynchronous registration,
the <datetime of application creation> is used when
validating the DN Line.
3614 TCNID does not exist
The TCNID has never existed in the central repository.
3615 Recent-dnl-insertion outside of the time window
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 Date of DN in Claims before the end of Sunrise Period
The registration date of the DN is before the end of
the Sunrise Period and the DN was reported in a
Trademark Claims LORDN file.
3617 Registrar has not been approved by the TMDB
Registrar ID in DN Line has not completed Trademark Claims
integration testing with the TMDB.
3618 Registration Date of DN in QLP LORDN file out of the QLP Period
The registration date of the DN in a QLP LORDN file is outside
of the QLP Period.
3619 TCN was not valid
The TCN was not valid (based on the <tmNotice:notBefore>
field of the TCN) at the datetime of acknowledgement.
4501 Syntax Error in DN Line
Syntax Error in DN Line.
4601 Invalid TLD used
The TLD in the DN Line does not match what is expected for
this LORDN.
4602 Registrar ID Invalid
Registrar ID in DN Line is not a valid ICANN-Accredited
Registrar.
4603 Registration Date in the future
The <datetime of registration> in the DN Line is in the
future.
4606 TLD not in Sunrise or Trademark Claims Period
The <datetime of registration> was reported when the TLD was
not in Sunrise or Trademark Claims Periods.
In case of an asynchronous registration,
the <datetime of application creation> is used when
validating the DN Line.
4607 Application Date in the future
The <datetime of application creation> in the DN Line is in the
future.
4608 Application Date is later than Registration Date
The <datetime of application creation> in the DN Line is later
than the <datetime of registration>.
4609 TCNID wrong syntax
The syntax of the TCNID is invalid.
4610 TCN Acceptance Date is in the future
The <datetime of acceptance of the TCN> is in the future.
4611 Label has never existed in the TMDB
The label in the registered DN has never existed in the TMDB.
]]>
</artwork>
</figure>
</section>
</section> <th>Code</th>
<th>Class</th>
<th>Outcome</th>
</tr>
</thead>
<tbody>
<tr>
</section> <td>20xx</td>
<td>Success</td>
<td>ok</td>
</tr>
<tr>
<!-- <td>35xx</td>
<td>[ DN Line syntax warning ]</td>
<td>warn</td>
</tr>
<tr>
4604 Sunrise DN / application reported for TLD in Claims <td>36xx</td>
The <datetime of registration> was reported in Sunrise LORDN <td>DN Line semantic warning</td>
when the TLD was in Claims. <td>warn</td>
In case of an asynchronous registration, </tr>
the <datetime of application creation> is used when <tr>
validating the DN Line.
4605 Claims DN / application reported for TLD in Sunrise <td>45xx</td>
The <datetime of registration> was reported in Claims LORDN <td>DN Line syntax error</td>
when the TLD was in Sunrise. <td>err</td>
In case of an asynchronous registration, </tr>
the <datetime of application creation> is used when <tr>
validating the DN Line.
<!-- <vspace blankLines='99' /> --> <td>46xx</td>
<section anchor="SmdFileFormat" title="Signed Mark Data (SMD) File"> <td>DN Line semantic error</td>
<td>err</td>
</tr>
</tbody>
</table>
<t>
In <xref target="LORDN-codes"/>, the LORDN Log result codes used
by the TMDB
are described.
</t>
<table anchor="LORDN-codes">
<name>LORDN Log Result Codes</name>
<thead>
<tr>
<th>rc</th>
<th>Short Description / Long Description</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="2">2000</td>
<td>OK</td>
</tr>
<tr>
<td>The DN Line is successfully processed.</td>
</tr>
<tr>
<td rowspan="2">2001</td>
<td>OK but not processed</td>
</tr>
<tr>
<td>The DN Line is syntactically correct but was not processed
because the LORDN file was rejected.</td>
</tr>
<tr>
<td rowspan="2">3601</td>
<td>TCN Acceptance Date after Registration Date</td>
</tr>
<tr>
<td>The TCN Acceptance Date in the DN Line is newer than the 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; the DN Line is ignored.</td>
</tr>
<tr>
<td rowspan="2">3603</td>
<td>DNROID Notified Earlier</td>
</tr>
<tr>
<td>The same DNROID has been notified earlier; the DN Line is ignored.</t
d>
</tr>
<tr>
<td rowspan="2">3604</td>
<td>TCN Checksum invalid</td>
</tr>
<tr>
<td>Based on the DN effective allocation, the TCNID, and the
expiration date of the linked TCN, the TCN Checksum is
invalid.</td>
</tr>
<tr>
<td rowspan="2">3605</td>
<td>TCN Expired</td>
</tr>
<tr>
<td>The TCN was already expired (based on the &lt;tmNotice:notAfter&gt;
field of the TCN) at the datetime of acknowledgement.</td>
</tr>
<tr>
<td rowspan="2">3606</td>
<td>Wrong TCNID used</td>
</tr>
<tr>
<td>The TCNID used for the registration does not match
the related 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 &lt;smd:notBefore&gt; and &lt;smd:notAfter&gt;
elements.
In case of an asynchronous registration, this refers to the
&lt;datetime of application creation>.</td>
</tr>
<tr>
<td rowspan="2">3610</td>
<td>DN reported outside of the time window</td>
</tr>
<tr>
<td>The DN was reported outside of the required 26-hour
reporting window.</td>
</tr>
<tr>
<td rowspan="2">3611</td>
<td>DN does not match the labels in SMD</td>
</tr>
<tr>
<td>The DN does not match the labels included in the SMD.</td>
</tr>
<tr>
<td rowspan="2">3612</td>
<td>SMDID does not exist</td>
</tr>
<tr>
<td>The Signed Mark Data Identifier (SMDID) has never existed
in the central repository.</td>
</tr>
<tr>
<td rowspan="2">3613</td>
<td>SMD was revoked when used</td>
</tr>
<tr>
<td>The SMD used for registration was revoked more than
24 hours ago of the &lt;datetime of registration&gt;.
In case of an asynchronous registration,
the &lt;datetime of application creation&gt; is used when
validating the DN Line.</td>
</tr>
<tr>
<td rowspan="2">3614</td>
<td>TCNID does not exist</td>
</tr>
<tr>
<td>The Trademark Claims Notice Identifier (TCNID) has never existed
in the central repository.</td>
</tr>
<tr>
<td rowspan="2">3615</td>
<td>Recent-dnl-insertion outside of the time 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.</td>
</tr>
<tr>
<td rowspan="2">3616</td>
<td>Registration Date of DN in Claims before the end of the Sunrise Perio
d</td>
</tr>
<tr>
<td>The registration date of the DN is before the end of
the Sunrise Period, and the DN was reported in a
Trademark Claims LORDN file.</td>
</tr>
<tr>
<td rowspan="2">3617</td>
<td>Registrar has not been approved by the TMDB</td>
</tr>
<tr>
<td>The Registrar ID in the DN Line has not completed Trademark Claims
integration testing with the TMDB.</td>
</tr>
<tr>
<td rowspan="2">3618</td>
<td>Registration Date of DN in QLP LORDN file out of the QLP Period</td>
</tr>
<tr>
<td>The registration date of the DN in a QLP LORDN file is outside
of the QLP Period.</td>
</tr>
<tr>
<td rowspan="2">3619</td>
<td>TCN was not valid</td>
</tr>
<tr>
<td>The TCN was not valid (based on the &lt;tmNotice:notBefore&gt;
field of the TCN) at the datetime of acknowledgement.</td>
</tr>
<tr>
<td rowspan="2">4501</td>
<td>Syntax Error in DN Line</td>
</tr>
<tr>
<td>There is a syntax error in the DN Line.</td>
</tr>
<tr>
<td rowspan="2">4601</td>
<td>Invalid TLD used</td>
</tr>
<tr>
<td>The TLD in the DN Line does not match what is expected for
this LORDN.</td>
</tr>
<tr>
<td rowspan="2">4602</td>
<td>Registrar ID Invalid</td>
</tr>
<tr>
<td>The Registrar ID in the DN Line is not a valid ICANN-Accredited
Registrar.</td>
</tr>
<tr>
<td rowspan="2">4603</td>
<td>Registration Date in the future</td>
</tr>
<tr>
<td>The &lt;datetime of registration&gt; in the DN Line is in the
future.</td>
</tr>
<tr>
<td rowspan="2">4606</td>
<td>TLD not in Sunrise or Trademark Claims Periods</td>
</tr>
<tr>
<td>The &lt;datetime of registration&gt; was reported when the TLD was
not in Sunrise or Trademark Claims Periods.
In case of an asynchronous registration,
the &lt;datetime of application creation&gt; is used when
validating the DN Line.</td>
</tr>
<tr>
<td rowspan="2">4607</td>
<td>Application Date in the future</td>
</tr>
<tr>
<td>The &lt;datetime of application creation&gt; in the DN Line is in the
future.</td>
</tr>
<tr>
<td rowspan="2">4608</td>
<td>Application Date is later than Registration Date</td>
</tr>
<tr>
<td>The &lt;datetime of application creation&gt; in the DN Line is later
than the &lt;datetime of registration&gt;.</td>
</tr>
<tr>
<td rowspan="2">4609</td>
<td>TCNID wrong syntax</td>
</tr>
<tr>
<td>The syntax of the TCNID is invalid.</td>
</tr>
<tr>
<td rowspan="2">4610</td>
<td>TCN Acceptance Date is in the future</td>
</tr>
<tr>
<td>The &lt;datetime of acceptance of the TCN&gt; is in the future.</td>
</tr>
<tr>
<td rowspan="2">4611</td>
<td>Label has never existed in the TMDB</td>
</tr>
<tr>
<td>The label in the registered DN has never existed in the TMDB.</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<section anchor="SmdFileFormat" numbered="true" toc="default">
<name>Signed Mark Data (SMD) File</name>
<t> <t>
This section defines the format of the Signed Mark Data (SMD) This section defines the format of the SMD
File. After a successful registration of a mark, the TMV returns 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 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 registration of one or more DNs covered by the PRM during the
Sunrise Period of a TLD. Sunrise Period of a TLD.
</t> </t>
<t> <t>
Two encapsulation boundaries are defined for delimiting the Two encapsulation boundaries are defined for delimiting the
encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED encapsulated base64-encoded SMD: "-----BEGIN ENCODED
SMD-----" and "-----END ENCODED SMD-----". Only data inside SMD-----" and "-----END ENCODED SMD-----". Only data inside
the encapsulation boundaries MUST be used by Registries and the encapsulation boundaries <bcp14>MUST</bcp14> be used by Registries
Registrars for validation purposes, i.e. any data outside and
these boundaries as well as the boundaries themselves MUST Registrars for validation purposes, i.e., any data outside
these boundaries as well as the boundaries themselves <bcp14>MUST</bcp
14>
be ignored for validation purposes. be ignored for validation purposes.
</t> </t>
<t> <t>
The structure of the SMD File is as follows, all the elements are REQU The structure of the SMD File is as follows. All the elements are <bcp
IRED, and MUST appear in the specified order. 14>REQUIRED</bcp14> and <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: &lt;comma separated list of U-label or NR-LDH labels (se
e <xref target='RFC5890' />)&gt;
</t>
<t>
notBefore: &lt;begin validity&gt;
</t>
<t>
notAfter: &lt;end validity&gt;
</t>
<t>
-----BEGIN ENCODED SMD-----
</t>
<t>
&lt;encoded SMD (see <xref target='RFC7848' />)&gt;
</t>
<t>
-----END ENCODED SMD-----
</t>
</list>
</t> </t>
<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 (se
e <xref target="RFC5890" format="default"/>)&gt;</li>
<li>notBefore: &lt;begin validity&gt;</li>
<li>notAfter: &lt;end validity&gt; </li>
<li>-----BEGIN ENCODED SMD-----</li>
<li>&lt;encoded SMD (see <xref target="RFC7848" format="default"/>)&gt
;</li>
<li>-----END ENCODED SMD-----</li>
</ol>
<!-- <vspace blankLines='99' /> --> <t>Example of an SMD file:</t>
<figure> <figure>
<preamble>Example of an SMD File:</preamble> <name>Example SMD File</name>
<sourcecode type=""><![CDATA[
<artwork>
<![CDATA[
Marks: Example One Marks: Example One
smdID: 1-2 smdID: 1-2
U-labels: example-one, exampleone U-labels: example-one, exampleone
notBefore: 2011-08-16 09:00 notBefore: 2011-08-16 09:00
notAfter: 2012-08-16 09:00 notAfter: 2012-08-16 09:00
-----BEGIN ENCODED SMD----- -----BEGIN ENCODED SMD-----
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu
ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN
... (base64 data elided for brevity) ... ... (base64 data elided for brevity) ...
dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
-----END ENCODED SMD----- -----END ENCODED SMD-----
]]> ]]></sourcecode>
</artwork> </figure>
</figure>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="TCN" title="Trademark Claims Notice (TCN)">
<section anchor="TCN" numbered="true" toc="default">
<name>Trademark Claims Notice (TCN)</name>
<t> <t>
The TMDB MUST provide the TCN to Registrars in XML format The TMDB <bcp14>MUST</bcp14> provide the TCN to Registrars in XML form at,
as specified below. as specified below.
</t> </t>
<t> <t>
An enclosing element &lt;tmNotice:notice&gt; that describes the Tradem ark Notice The enclosing element &lt;tmNotice:notice&gt; describes the Trademark Notice
to a given label. to a given label.
</t> </t>
<t> <t>
The child elements of the &lt;tmNotice:notice&gt; element include: The child elements of the &lt;tmNotice:notice&gt; element include:</t
>
<list style="symbols"> <ul spacing="normal">
<t> <li>
A &lt;tmNotice:id&gt; element that contains the unique identifier of <t>A &lt;tmNotice:id&gt; element that contains the unique identifier
the Trademark Notice. This element contains the the TCNID. of
<list style="empty"> the Trademark Notice. This element contains the TCNID.</t>
<t> <ul empty="true" spacing="normal">
The TCNID is a string concatenation of a TCN Checksum <li>The TCNID is a string concatenation of a TCN Checksum
and the TMDB Notice Identifier. and the TMDB Notice Identifier.
The first 8 characters of the TCNID is a 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 TCN Checksum. The rest is the TMDB Notice Identifier, which is a zero-padded natural number
in the range of 0000000000000000001 to 9223372036854775807. in the range of 0000000000000000001 to 9223372036854775807.</li>
</t> <li>
<t> <t>Example of a TCNID:</t>
Example of a TCNID: <ul empty="true" spacing="normal">
<list style="empty"> <li>370d0b7c9223372036854775807.</li>
<t> </ul>
370d0b7c9223372036854775807. </li>
</t> <li>
</list> <t>Where:</t>
</t> <ul spacing="normal">
<t> <li>TCN Checksum=370d0b7c</li>
Where: <li>TMDB Notice Identifier=9223372036854775807</li>
<list style="symbols"> </ul>
<t> </li>
TCN Checksum=370d0b7c <li>The TCN Checksum is an 8-character-long base16-encoded output
</t>
<t>
TMDB Notice Identifier=9223372036854775807
</t>
</list>
</t>
<t>
The TCN Checksum is a 8 characters long Base16 encoded output
of computing the CRC32 of the string concatenation of: of computing the CRC32 of the string concatenation of:
label + unix_timestamp(&lt;tmNotice:notAfter&gt;) + TMDB Notice label + unix_timestamp(&lt;tmNotice:notAfter&gt;) + TMDB Notice
Identifier Identifier.</li>
</t> <li>
<t> <t>The TMDB <bcp14>MUST</bcp14> use the Unix time conversion of
TMDB MUST use the Unix time conversion of the &lt;tmNotice:notAf the &lt;tmNotice:notAfter&gt; in UTC
ter&gt; in UTC
to calculate the TCN Checksum. to calculate the TCN Checksum.
Unix time is defined as the number of seconds that have elapsed since Unix time is defined as the number of seconds that have elapsed since
1970-01-01T00:00:00Z not counting leap seconds. 1970-01-01T00:00:00Z, not counting leap seconds.
For example, the conversion to Unix time of 2010-08-16T09:00:00. For example, the conversion of 2010-08-16T09:00:00.0Z to Unix ti
0Z is shown: me is:</t>
<list style="empty"> <ul empty="true" spacing="normal">
<t> <li>unix_time(2010-08-16T09:00:00.0Z)=1281949200</li>
unix_time(2010-08-16T09:00:00.0Z)=1281949200 </ul>
</t> </li>
</list> <li>The TMDB uses the &lt;tmNotice:label&gt; and &lt;tmNotice:notA
</t> fter&gt;
<t>
The TMDB uses the &lt;tmNotice:label&gt; and &lt;tmNotice:notAft
er&gt;
elements from the TCN along with the TMDB Notice Identifier elements from the TCN along with the TMDB Notice Identifier
to compute the TCN Checksum. to compute the TCN Checksum.</li>
</t> <li>A Registry <bcp14>MUST</bcp14> use the leftmost DNL of the DN
<t> being
A Registry MUST use the leftmost DNL of the DN being effectively allocated, the expiration datetime of the TCN (provi
effectively allocated, the expiration datetime of the TCN (provi ded by the Registrar),
ded by the Registrar)
and the TMDB Notice Identifier extracted from the TCNID (provide d by the Registrar) and the TMDB Notice Identifier extracted from the TCNID (provide d by the Registrar)
to compute the TCN Checksum. For example, if the DN &quot;xn--mg to compute the TCN Checksum. For example, if the DN "xn--mgbacht
bachtv.xn--mgbh0fb&quot; is v.xn--mgbh0fb" is
being effectively allocated, the leftmost DNL would be &quot;xn- being effectively allocated, the leftmost DNL would be "xn--mgba
-mgbachtv&quot;. chtv".</li>
</t> <li>
<t>An example computation of the TCN Checksum is:</t>
<t> <ul empty="true" spacing="normal">
Example of computation of the TCN Checksum: <li>
<list style="empty">
<t>
CRC32(example-one12819492009223372036854775807)=370d0b7c CRC32(example-one12819492009223372036854775807)=370d0b7c
</t> </li>
</list> </ul>
</t> </li>
</list> </ul>
</t> </li>
<t> <li>A &lt;tmNotice:notBefore&gt; element that contains the start of th
A &lt;tmNotice:notBefore&gt; element that contains the start of the e valid date and time of the TCN. </li>
validity date and time of the TCN. <li>A &lt;tmNotice:notAfter&gt; element that contains the expiration d
</t> ate and time of the TCN.</li>
<li>A &lt;tmNotice:label&gt; element that contains the DNL covered by
<t> a PRM.</li>
A &lt;tmNotice:notAfter&gt; element that contains the expiration dat <li>
e and time of the TCN. <t>One or more &lt;tmNotice:claim&gt; elements that contain the Trad
</t> emark Claims.
<t>
A &lt;tmNotice:label&gt; element that contains the DNL covered by a
PRM.
</t>
<t>
One or more &lt;tmNotice:claim&gt; elements that contain the Tradema
rk Claim.
The &lt;tmNotice:claim&gt; element contains the following The &lt;tmNotice:claim&gt; element contains the following
child elements: child elements:</t>
<ul spacing="normal">
<list style="symbols"> <li>A &lt;tmNotice:markName&gt; element that contains the mark tex
<t> t string.</li>
A &lt;tmNotice:markName&gt; element that contains the mark text <li>
string. <t>One or more &lt;tmNotice:holder&gt; elements that contain the
</t> information of the holder of the mark. An "entitlement" attribute
<t> is used to identify the entitlement of the holder; possible valu
One or more &lt;tmNotice:holder&gt; elements that contains the i es are: owner, assignee, or licensee.
nformation of the holder of the mark. An "entitlement" attribute The child elements of &lt;tmNotice:holder&gt; include:</t>
is used to identify the entitlement of the holder, possible valu <ul spacing="normal">
es are: owner, assignee or licensee. <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:name&gt; element t
The child elements of &lt;tmNotice:holder&gt; include: hat contains the name of the holder. &lt;tmNotice:name&gt; <bcp14>MUST</bcp14> b
<list style="symbols"> e specified if
&lt;tmNotice:org&gt; is not specified.</li>
<t> <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:org&gt; element th
An OPTIONAL &lt;tmNotice:name&gt; element that contains the at contains the name of the organization holder of the mark. &lt;tmNotice:org&gt
name of the holder. A &lt;tmNotice:name&gt; MUST be specified if ; <bcp14>MUST</bcp14> be specified if
&lt;tmNotice:org&gt; is not specified. &lt;tmNotice:name&gt; is not specified.</li>
</t> <li>
<t>A &lt;tmNotice:addr&gt; element that contains the address
<t> information of the holder
An OPTIONAL &lt;tmNotice:org&gt; element that contains the n of a mark. &lt;tmNotice:addr&gt; contains the following chil
ame of the organization holder of the mark. A &lt;tmNotice:org&gt; MUST be speci d elements:</t>
fied if <ul spacing="normal">
&lt;tmNotice:name&gt; is not specified. <li>One, two, or three <bcp14>OPTIONAL</bcp14> &lt;tmNotic
</t> e:street&gt; elements that contain the organization's street address.</li>
<li>A &lt;tmNotice:city&gt; element that contains the orga
<t> nization's city.</li>
A &lt;tmNotice:addr&gt; element that contains the address in <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:sp&gt; element
formation of the holder that contains the organization's state or province.</li>
of a mark. A &lt;tmNotice:addr&gt; contains the following ch <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:pc&gt; element
ild elements: that contains the organization's postal code.</li>
<li>A &lt;tmNotice:cc&gt; element that contains the organi
<list style="symbols"> zation's country code.
<t> This a two-character code from <xref target="ISO3166-2"
One, two or three OPTIONAL &lt;tmNotice:street&gt; eleme format="default"/>.</li>
nts that contains the organization's street address. </ul>
</t> </li>
<li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:voice&gt; element
<t> that contains the organization's voice telephone number.</li>
A &lt;tmNotice:city&gt; element that contains the organi <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:fax&gt; element th
zation's city. at contains the organization's facsimile telephone number.</li>
</t> <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:email&gt; element
that contains the email address of the holder.</li>
<t> </ul>
An OPTIONAL &lt;tmNotice:sp&gt; element that contains th </li>
e organization's state or province. <li>
</t> <t>Zero or more <bcp14>OPTIONAL</bcp14> &lt;tmNotice:contact&gt;
elements that contain the information of the representative of the mark registr
<t> ation.
An OPTIONAL &lt;tmNotice:pc&gt; element that contains th A "type" attribute is used to identify the type of contact; poss
e organization's postal code. ible values are: owner, agent, or third party.
</t> The child elements of &lt;tmNotice:contact&gt; include:</t>
<ul spacing="normal">
<t> <li>A &lt;tmNotice:name&gt; element that contains the name of
A &lt;tmNotice:cc&gt; element that contains the organiza the responsible person.</li>
tion's country code. <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:org&gt; element th
This a two-character code from <xref target="ISO3166-2" at contains the name of the organization of the contact.</li>
/>. <li>
</t> <t>A &lt;tmNotice:addr&gt; element that contains the address
</list> information of the contact.
</t> &lt;tmNotice:addr&gt; contains the following child elements:
</t>
<t> <ul spacing="normal">
An OPTIONAL &lt;tmNotice:voice&gt; element that contains the <li>One, two, or three <bcp14>OPTIONAL</bcp14> &lt;tmNotic
organization's voice telephone number. e:street&gt; elements that contain the contact's street address.</li>
</t> <li>A &lt;tmNotice:city&gt; element that contains the cont
act's city.</li>
<t> <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:sp&gt; element
An OPTIONAL &lt;tmNotice:fax&gt; element that contains the o that contains the contact's state or province.</li>
rganization's facsimile telephone number. <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:pc&gt; element
</t> that contains the contact's postal code.</li>
<li>A &lt;tmNotice:cc&gt; element that contains the contac
<t> t's country code.
An OPTIONAL &lt;tmNotice:email&gt; element that contains the This a two-character code from <xref target="ISO3166-2"
email address of the holder. format="default"/>.</li>
</t> </ul>
</list> </li>
</t> <li>A &lt;tmNotice:voice&gt; element that contains the contact
<t> 's voice telephone number.</li>
Zero or more OPTIONAL &lt;tmNotice:contact&gt; elements that con <li>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:fax&gt; element th
tains the information of the representative of the mark registration. at contains the contact's facsimile telephone number.</li>
A "type" attribute is used to identify the type of contact, poss <li>A &lt;tmNotice:email&gt; element that contains the contact
ible values are: owner, agent or thirdparty. 's email address.</li>
The child elements of &lt;tmNotice:contact&gt; include: </ul>
</li>
<list style="symbols"> <li>A &lt;tmNotice:jurDesc&gt; element that contains the name (in
English) of the jurisdiction where the mark is protected.
<t>
A &lt;tmNotice:name&gt; element that contains name of the re
sponsible person.
</t>
<t>
An OPTIONAL &lt;tmNotice:org&gt; element that contains the n
ame of the organization of the contact.
</t>
<t>
A &lt;tmNotice:addr&gt; element that contains the address in
formation of the contact.
A &lt;tmNotice:addr&gt; contains the following child element
s:
<list style="symbols">
<t>
One, two or three OPTIONAL &lt;tmNotice:street&gt; eleme
nts that contains the contact's street address.
</t>
<t>
A &lt;tmNotice:city&gt; element that contains the contac
t's city.
</t>
<t>
An OPTIONAL &lt;tmNotice:sp&gt; element that contains th
e contact's state or province.
</t>
<t>
An OPTIONAL &lt;tmNotice:pc&gt; element that contains th
e contact's postal code.
</t>
<t>
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 &lt;tmNotice:voice&gt; element that contains the contact's
voice telephone number.
</t>
<t>
An OPTIONAL &lt;tmNotice:fax&gt; element that contains the c
ontact's facsimile telephone number.
</t>
<t>
A &lt;tmNotice:email&gt; element that contains the contact's
email address.
</t>
</list>
</t>
<t>
A &lt;tmNotice:jurDesc&gt; element that contains the name (in En
glish) of the jurisdiction where the mark is protected.
A jurCC attribute contains the two-character code of the jurisdi ction where the mark was registered. A jurCC attribute contains the two-character code of the jurisdi ction where the mark was registered.
This is a two-character code from <xref target="WIPO.ST3" />. This is a two-character code from <xref target="WIPO.ST3" format
</t> ="default"/>.</li>
<t> <li>Zero or more <bcp14>OPTIONAL</bcp14> &lt;tmNotice:classDesc&gt
Zero or more OPTIONAL &lt;tmNotice:classDesc&gt; element that co ; elements that contain the description (in English) of
ntains the description (in English) of the Nice Classification, as defined in <xref target="WIPO-NICE-C
the Nice Classification as defined in <xref target="WIPO-NICE-CL LASSES" format="default"/>.
ASSES"/>. A classNum attribute contains the class number.</li>
A classNum attribute contains the class number. <li>A &lt;tmNotice:goodsAndServices&gt; element that contains the
</t> full description of the goods and services mentioned
<t> in the mark registration document.</li>
A &lt;tmNotice:goodsAndServices&gt; element that contains the fu <li>
ll description of the goods and services mentioned <t>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:notExactMatch&gt; ele
in the mark registration document. ment signals that the claim notice was added to the TCN
</t> based on rules (e.g., <xref target="Claims50" format="default"/>
<t> ) other than exact match (defined in <xref target="MatchingRules" format="defaul
An OPTIONAL &lt;tmNotice:notExactMatch&gt; element signals that t"/>).
the claim notice was added to the TCN &lt;tmNotice:notExactMatch&gt; contains one or more of the follo
based on other rule (e.g. <xref target="Claims50"/> ) than exact wing:</t>
match (defined in <xref target="MatchingRules"/>). <ul spacing="normal">
The &lt;tmNotice:notExactMatch&gt; contains one or more: <li>
<list style="symbols"> <t>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:udrp&gt; element
<t> that signals that the claim notice was added because
An OPTIONAL &lt;tmNotice:udrp&gt; element that signals that of a previously abused name included in a Uniform Domain-Nam
the claim notice was added because e Dispute-Resolution Policy (UDRP) case. &lt;tmNotice:udrp&gt; contains: </t>
of a previously abused name included in an UDRP case. The &l <ul spacing="normal">
t;tmNotice:udrp&gt; contains: <li>A &lt;tmNotice:caseNo&gt; element that contains the UD
<list style="symbols"> RP case number used to validate
<t> the previously abused name.</li>
A &lt;tmNotice:caseNo&gt; element that contains the UDRP <li>A &lt;tmNotice:udrpProvider&gt; element that contains
case number used to validate the name of the UDRP provider.</li>
the previously abused name. </ul>
</t> </li>
<t> <li>
A &lt;tmNotice:udrpProvider&gt; element that contains th <t>An <bcp14>OPTIONAL</bcp14> &lt;tmNotice:court&gt; element
e name of the UDRP provider. that signals that the claim notice was added because
</t> of a previously abused name included in a court's resolution
</list> . &lt;tmNotice:court&gt; contains: </t>
</t> <ul spacing="normal">
<t> <li>A &lt;tmNotice:refNum&gt; element that contains the re
An OPTIONAL &lt;tmNotice:court&gt; element that signals that ference number of the court's resolution
the claim notice was added because used to validate the previously abused name.</li>
of a previously abused name included in a court's resolution <li>A &lt;tmNotice:cc&gt; element that contains the two-ch
. The &lt;tmNotice:court&gt; contains: aracter code from <xref target="ISO3166-2" format="default"/>
<list style="symbols"> of the jurisdiction of the court.</li>
<t> <li>A &lt;tmNotice:courtName&gt; element that contains the
A &lt;tmNotice:refNum&gt; element that contains the refe name of the court.</li>
rence number of the court's resolution </ul>
used to validate the previously abused name. </li>
</t> </ul>
<t> </li>
A &lt;tmNotice:cc&gt; element that contains the two-char </ul>
acter code from <xref target="ISO3166-2"/> </li>
of the jurisdiction of the court. </ul>
</t>
<t>
A &lt;tmNotice:courtName&gt; element that contains the n
ame of the court.
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</list> <t>Example of a &lt;tmNotice:notice&gt; object:</t>
</t> <figure>
<!-- <vspace blankLines='99' /> --> <name>Example &lt;tmNotice:notice&gt; Object</name>
<figure> <sourcecode type="xml"><![CDATA[
<preamble>Example of a &lt;tmNotice:notice&gt; object:</preamble>
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<tmNotice:notice xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0"> <tmNotice:notice
<tmNotice:id>370d0b7c9223372036854775807</tmNotice:id> xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0">
<tmNotice:notBefore>2010-08-14T09:00:00.0Z</tmNotice:notBefore> <tmNotice:id>370d0b7c9223372036854775807</tmNotice:id>
<tmNotice:notAfter>2010-08-16T09:00:00.0Z</tmNotice:notAfter> <tmNotice:notBefore>2010-08-14T09:00:00.0Z</tmNotice:notBefore>
<tmNotice:label>example-one</tmNotice:label> <tmNotice:notAfter>2010-08-16T09:00:00.0Z</tmNotice:notAfter>
<tmNotice:claim> <tmNotice:label>example-one</tmNotice:label>
<tmNotice:markName>Example One</tmNotice:markName> <tmNotice:claim>
<tmNotice:holder entitlement="owner"> <tmNotice:markName>Example One</tmNotice:markName>
<tmNotice:org>Example Inc.</tmNotice:org> <tmNotice:holder entitlement="owner">
<tmNotice:addr> <tmNotice:org>Example Inc.</tmNotice:org>
<tmNotice:street>123 Example Dr.</tmNotice:street> <tmNotice:addr>
<tmNotice:street>Suite 100</tmNotice:street> <tmNotice:street>123 Example Dr.</tmNotice:street>
<tmNotice:city>Reston</tmNotice:city> <tmNotice:street>Suite 100</tmNotice:street>
<tmNotice:sp>VA</tmNotice:sp> <tmNotice:city>Reston</tmNotice:city>
<tmNotice:pc>20190</tmNotice:pc> <tmNotice:sp>VA</tmNotice:sp>
<tmNotice:cc>US</tmNotice:cc> <tmNotice:pc>20190</tmNotice:pc>
</tmNotice:addr> <tmNotice:cc>US</tmNotice:cc>
</tmNotice:holder> </tmNotice:addr>
<tmNotice:contact type="owner"> </tmNotice:holder>
<tmNotice:name>Joe Doe</tmNotice:name> <tmNotice:contact type="owner">
<tmNotice:org>Example Inc.</tmNotice:org> <tmNotice:name>Joe Doe</tmNotice:name>
<tmNotice:addr> <tmNotice:org>Example Inc.</tmNotice:org>
<tmNotice:street>123 Example Dr.</tmNotice:street> <tmNotice:addr>
<tmNotice:street>Suite 100</tmNotice:street> <tmNotice:street>123 Example Dr.</tmNotice:street>
<tmNotice:city>Reston</tmNotice:city> <tmNotice:street>Suite 100</tmNotice:street>
<tmNotice:sp>VA</tmNotice:sp> <tmNotice:city>Reston</tmNotice:city>
<tmNotice:pc>20190</tmNotice:pc> <tmNotice:sp>VA</tmNotice:sp>
<tmNotice:cc>US</tmNotice:cc> <tmNotice:pc>20190</tmNotice:pc>
</tmNotice:addr> <tmNotice:cc>US</tmNotice:cc>
<tmNotice:voice x="4321">+1.7035555555</tmNotice:voice> </tmNotice:addr>
<tmNotice:email>jdoe@example.com</tmNotice:email> <tmNotice:voice x="4321">+1.7035555555</tmNotice:voice>
</tmNotice:contact> <tmNotice:email>jdoe@example.com</tmNotice:email>
<tmNotice:jurDesc jurCC="US">USA</tmNotice:jurDesc> </tmNotice:contact>
<tmNotice:classDesc classNum="35"> <tmNotice:jurDesc jurCC="US">USA</tmNotice:jurDesc>
Advertising; business management; business administration. <tmNotice:classDesc classNum="35">
</tmNotice:classDesc> Advertising; business management; business administration.
<tmNotice:classDesc classNum="36"> </tmNotice:classDesc>
Insurance; financial affairs; monetary affairs; real estate. <tmNotice:classDesc classNum="36">
</tmNotice:classDesc> Insurance; financial affairs; monetary affairs; real estate.
<tmNotice:goodsAndServices> </tmNotice:classDesc>
Bardus populorum circumdabit se cum captiosus populum. <tmNotice:goodsAndServices>
Smert populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> Smert populorum circumdabit se cum captiosus populum.
</tmNotice:claim> </tmNotice:goodsAndServices>
<tmNotice:claim> </tmNotice:claim>
<tmNotice:markName>Example-One</tmNotice:markName> <tmNotice:claim>
<tmNotice:holder entitlement="owner"> <tmNotice:markName>Example-One</tmNotice:markName>
<tmNotice:org>Example S.A. de C.V.</tmNotice:org> <tmNotice:holder entitlement="owner">
<tmNotice:addr> <tmNotice:org>Example S.A. de C.V.</tmNotice:org>
<tmNotice:street>Calle conocida #343</tmNotice:street> <tmNotice:addr>
<tmNotice:city>Conocida</tmNotice:city> <tmNotice:street>Calle conocida #343</tmNotice:street>
<tmNotice:sp>SP</tmNotice:sp> <tmNotice:city>Conocida</tmNotice:city>
<tmNotice:pc>82140</tmNotice:pc> <tmNotice:sp>SP</tmNotice:sp>
<tmNotice:cc>BR</tmNotice:cc> <tmNotice:pc>82140</tmNotice:pc>
</tmNotice:addr> <tmNotice:cc>BR</tmNotice:cc>
</tmNotice:holder> </tmNotice:addr>
<tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc> </tmNotice:holder>
<tmNotice:goodsAndServices> <tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc>
Bardus populorum circumdabit se cum captiosus populum. <tmNotice:goodsAndServices>
Smert populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> Smert populorum circumdabit se cum captiosus populum.
</tmNotice:claim> </tmNotice:goodsAndServices>
<tmNotice:claim> </tmNotice:claim>
<tmNotice:markName>One</tmNotice:markName> <tmNotice:claim>
<tmNotice:holder entitlement="owner"> <tmNotice:markName>One</tmNotice:markName>
<tmNotice:org>One Corporation</tmNotice:org> <tmNotice:holder entitlement="owner">
<tmNotice:addr> <tmNotice:org>One Corporation</tmNotice:org>
<tmNotice:street>Otra calle</tmNotice:street> <tmNotice:addr>
<tmNotice:city>Otra ciudad</tmNotice:city> <tmNotice:street>Otra calle</tmNotice:street>
<tmNotice:sp>OT</tmNotice:sp> <tmNotice:city>Otra ciudad</tmNotice:city>
<tmNotice:pc>383742</tmNotice:pc> <tmNotice:sp>OT</tmNotice:sp>
<tmNotice:cc>CR</tmNotice:cc> <tmNotice:pc>383742</tmNotice:pc>
</tmNotice:addr> <tmNotice:cc>CR</tmNotice:cc>
</tmNotice:holder> </tmNotice:addr>
<tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc> </tmNotice:holder>
<tmNotice:goodsAndServices> <tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc>
Bardus populorum circumdabit se cum captiosus populum. <tmNotice:goodsAndServices>
Smert populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> Smert populorum circumdabit se cum captiosus populum.
<tmNotice:notExactMatch> </tmNotice:goodsAndServices>
<tmNotice:court> <tmNotice:notExactMatch>
<tmNotice:refNum>234235</tmNotice:refNum> <tmNotice:court>
<tmNotice:cc>CR</tmNotice:cc> <tmNotice:refNum>234235</tmNotice:refNum>
<tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName> <tmNotice:cc>CR</tmNotice:cc>
</tmNotice:court> <tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName>
</tmNotice:notExactMatch> </tmNotice:court>
</tmNotice:claim> </tmNotice:notExactMatch>
<tmNotice:claim> </tmNotice:claim>
<tmNotice:markName>One Inc</tmNotice:markName> <tmNotice:claim>
<tmNotice:holder entitlement="owner"> <tmNotice:markName>One Inc</tmNotice:markName>
<tmNotice:org>One SA de CV</tmNotice:org> <tmNotice:holder entitlement="owner">
<tmNotice:addr> <tmNotice:org>One SA de CV</tmNotice:org>
<tmNotice:street>La calle</tmNotice:street> <tmNotice:addr>
<tmNotice:city>La ciudad</tmNotice:city> <tmNotice:street>La calle</tmNotice:street>
<tmNotice:sp>CD</tmNotice:sp> <tmNotice:city>La ciudad</tmNotice:city>
<tmNotice:pc>34323</tmNotice:pc> <tmNotice:sp>CD</tmNotice:sp>
<tmNotice:cc>AR</tmNotice:cc> <tmNotice:pc>34323</tmNotice:pc>
</tmNotice:addr> <tmNotice:cc>AR</tmNotice:cc>
</tmNotice:holder> </tmNotice:addr>
<tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc> </tmNotice:holder>
<tmNotice:goodsAndServices> <tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc>
Bardus populorum circumdabit se cum captiosus populum. <tmNotice:goodsAndServices>
Smert populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> Smert populorum circumdabit se cum captiosus populum.
<tmNotice:notExactMatch> </tmNotice:goodsAndServices>
<tmNotice:udrp> <tmNotice:notExactMatch>
<tmNotice:caseNo>D2003-0499</tmNotice:caseNo> <tmNotice:udrp>
<tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider> <tmNotice:caseNo>D2003-0499</tmNotice:caseNo>
</tmNotice:udrp> <tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider>
</tmNotice:notExactMatch> </tmNotice:udrp>
</tmNotice:claim> </tmNotice:notExactMatch>
</tmNotice:claim>
</tmNotice:notice> </tmNotice:notice>
]]> ]]></sourcecode>
</artwork> </figure>
</figure>
<t> <t>
For the formal syntax of the TCN please For the formal syntax of the TCN, please
refer to <xref target="FormalSyntaxClaimsNotice" />. refer to <xref target="FormalSyntaxClaimsNotice" format="default"/>.
</t> </t>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="surlListFormat" title="Sunrise List (SURL)">
<section anchor="surlListFormat" numbered="true" toc="default">
<name>Sunrise List (SURL)</name>
<t> <t>
This section defines the format of the list containing every This section defines the format of the list containing every
Domain Name Label (DNL) that matches a PRM eligible for Sunrise. DNL that matches a PRM eligible for Sunrise.
The list is maintained by the TMDB and downloaded by The list is maintained by the TMDB and downloaded by
Registries in regular intervals (see <xref Registries in regular intervals (see <xref target="procDescUpdatesurlL
target="procDescUpdatesurlList" />). The Registries use the ist" format="default"/>). The Registries use the
Sunrise List during the Qualified Launch Program Period to check wheth Sunrise List during the QLP Period to check whether
er
a requested DN matches a DNL of a PRM eligible for Sunrise. a requested DN matches a DNL of a PRM eligible for Sunrise.
</t> </t>
<t> <t>
The Sunrise List contains all the DNLs covered by a PRM eligible for S unrise present in the TMDB at the datetime it is generated. The Sunrise List contains all the DNLs covered by a PRM eligible for S unrise that are present in the TMDB at the datetime it is generated.
</t> </t>
<t> <t>
The Sunrise List is contained in a CSV formatted file that has the The Sunrise List is contained in a CSV-formatted file that has the
following structure: following structure:
<list style='symbols'>
<t>
first line: &lt;version&gt;,&lt;Sunrise List creation datetime&gt;
<list style='empty'>
<t>Where:
<list style='symbols'>
<t>
&lt;version&gt;, version of the file, this field MUST be 1.
</t>
<t>
&lt;Sunrise List creation datetime&gt;, date and time in UTC t
hat the Sunrise List was created.
</t>
</list>
</t>
</list>
</t>
<t>
second line: a header line as specified in <xref target="RFC4180"/
>
<list style='empty'>
<t>With the header names as follows:</t>
<t>DNL,insertion-datetime</t>
</list>
</t>
<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;, a Domain Name Label covered by a PRM eligible for
Sunrise.
</t>
<t>
&lt;DNL insertion datetime&gt;, datetime in UTC that the DNL w
as first inserted into the Sunrise List.
The possible two values of time for inserting a DNL to the Sun
rise List are 00:00:00 and 12:00:00 UTC.
</t>
</list>
</t>
</list>
</t>
</list>
</t> </t>
<ul spacing="normal">
<figure> <li>
<preamble>Example of a Sunrise List:</preamble> <t>first line: &lt;version&gt;,&lt;Sunrise List creation datetime&gt
<artwork> ;</t>
<![CDATA[ <ul empty="true" spacing="normal">
<li>
<t>Where:</t>
<ul spacing="normal">
<li>&lt;version&gt;: version of the file. This field <bcp14>MU
ST</bcp14> be 1.</li>
<li>&lt;Sunrise List creation datetime&gt;: date and time in U
TC that the Sunrise List was created.</li>
</ul>
</li>
</ul>
</li>
<li>
<t>second line: a header line, as specified in <xref target="RFC4180
" format="default"/></t>
<ul empty="true" spacing="normal">
<li>With the header names as follows:</li>
<li>DNL,insertion-datetime</li>
</ul>
</li>
<li>
<t>One or more lines with: &lt;DNL&gt;,&lt;DNL insertion 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.</li>
<li>&lt;DNL insertion datetime&gt;: datetime in UTC that the D
NL was first inserted into the Sunrise List.
The possible two values of time for inserting a DNL to the Sun
rise List are 00:00:00 and 12:00:00 UTC.</li>
</ul>
</li>
</ul>
</li>
</ul>
<t>Example of a Sunrise List:</t>
<figure>
<name>Example Sunrise List</name>
<sourcecode type=""><![CDATA[
1,2012-08-16T00:00:00.0Z 1,2012-08-16T00:00:00.0Z
DNL,insertion-datetime DNL,insertion-datetime
example,2010-07-14T00:00:00.0Z example,2010-07-14T00:00:00.0Z
another-example,2012-08-16T00:00:00.0Z another-example,2012-08-16T00:00:00.0Z
anotherexample,2011-08-16T12:00:00.0Z anotherexample,2011-08-16T12:00:00.0Z
]]> ]]></sourcecode>
</artwork> </figure>
</figure>
<t> <t>
To provide authentication and integrity protection, the Sunrise To provide authentication and integrity protection, the Sunrise
List will be PGP signed by the TMDB (see also <xref List will be PGP signed by the TMDB (see <xref target="procDescBootstr
target="procDescBootstrapPgpKeyRy" />). The PGP signature of the apPgpKeyRy" format="default"/>). The PGP signature of the
Sunrise List can be found in the similar URI but with extension .sig a Sunrise List can be found in the similar URI but with extension .sig,
s shown below. as shown below.
</t> </t>
<t> <t>
The URL of the dy interface (<xref target="dy" />) is: The URLs of the dy interface (<xref target="dy" format="default"/>) ar
<list style="symbols"> e:
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.csv&nbs
p;&gt;
</t>
<t>
&lt;&nbsp;https://&lt;tmdb-domain-name&gt;/dnl/surl-latest.sig&nbs
p;&gt;
</t>
</list>
</t> </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>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="formalSyntax" title="Formal Syntax">
<section anchor="FormalSyntaxClaimsNotice" title="Trademark Claims Notice
(TCN)">
<section anchor="formalSyntax" numbered="true" toc="default">
<name>Formal Syntax</name>
<section anchor="FormalSyntaxClaimsNotice" numbered="true" toc="default">
<name>Trademark Claims Notice (TCN)</name>
<t> <t>
The schema presented here is for a Trademark Claims Notice. The schema presented here is for a Trademark Claims Notice.
</t> </t>
<t> <t>
The CODE BEGINS and CODE ENDS tags are not part of the schema; they ar e used to note the beginning and ending of the schema The CODE BEGINS and CODE ENDS tags are not part of the schema; they ar e used to note the beginning and ending of the schema
for URI registration purposes. for URI registration purposes.
</t> </t>
<sourcecode name="" type="xml" markers="true"><![CDATA[
<figure>
<artwork>
<![CDATA[
<CODE BEGINS>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:tmNotice-1.0" <schema targetNamespace="urn:ietf:params:xml:ns:tmNotice-1.0"
xmlns:tmNotice="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:mark="urn:ietf:params:xml:ns:mark-1.0"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<annotation> <annotation>
<documentation> <documentation>
Schema for representing a Trademark Claim Notice. Schema for representing a Trademark Claim Notice.
skipping to change at line 3478 skipping to change at line 2784
<element name="label" type="mark:labelType"/> <element name="label" type="mark:labelType"/>
<element name="claim" type="tmNotice:claimType" minOccurs="0" <element name="claim" type="tmNotice:claimType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="claimType"> <complexType name="claimType">
<sequence> <sequence>
<element name="markName" type="token"/> <element name="markName" type="token"/>
<element name="holder" type="tmNotice:holderType" <element name="holder" type="tmNotice:holderType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element name="contact" type="tmNotice:contactType" minOccurs="0" <element name="contact" type="tmNotice:contactType"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="jurDesc" type="tmNotice:jurDescType"/> <element name="jurDesc" type="tmNotice:jurDescType"/>
<element name="classDesc" type="tmNotice:classDescType" <element name="classDesc" type="tmNotice:classDescType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="goodsAndServices" type="token"/> <element name="goodsAndServices" type="token"/>
<element name="notExactMatch" type="tmNotice:noExactMatchType" <element name="notExactMatch" type="tmNotice:noExactMatchType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="jurDescType"> <complexType name="jurDescType">
<simpleContent> <simpleContent>
skipping to change at line 3525 skipping to change at line 2831
<sequence> <sequence>
<element name="refNum" type="token"/> <element name="refNum" type="token"/>
<element name="cc" type="mark:ccType"/> <element name="cc" type="mark:ccType"/>
<element name="region" type="token" minOccurs="0" <element name="region" type="token" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element name="courtName" type="token"/> <element name="courtName" type="token"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="addrType"> <complexType name="addrType">
<sequence> <sequence>
<element name="street" type="token" minOccurs="1" maxOccurs="3"/> <element name="street" type="token" minOccurs="1"
maxOccurs="3"/>
<element name="city" type="token"/> <element name="city" type="token"/>
<element name="sp" type="token" minOccurs="0"/> <element name="sp" type="token" minOccurs="0"/>
<element name="pc" type="mark:pcType" minOccurs="0"/> <element name="pc" type="mark:pcType" minOccurs="0"/>
<element name="cc" type="mark:ccType"/> <element name="cc" type="mark:ccType"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="contactType"> <complexType name="contactType">
<sequence> <sequence>
<element name="name" type="token"/> <element name="name" type="token"/>
<element name="org" type="token" minOccurs="0"/> <element name="org" type="token" minOccurs="0"/>
skipping to change at line 3549 skipping to change at line 2856
<element name="email" type="mark:minTokenType"/> <element name="email" type="mark:minTokenType"/>
</sequence> </sequence>
<attribute name="type" type="mark:contactTypeType"/> <attribute name="type" type="mark:contactTypeType"/>
</complexType> </complexType>
<simpleType name="idType"> <simpleType name="idType">
<restriction base="token"> <restriction base="token">
<pattern value="[a-fA-F0-9]{8}\d{1,19}"/> <pattern value="[a-fA-F0-9]{8}\d{1,19}"/>
</restriction> </restriction>
</simpleType> </simpleType>
</schema> </schema>
<CODE ENDS> ]]></sourcecode>
]]>
</artwork>
</figure>
</section> </section>
</section> </section>
<!-- <vspace blankLines='99' /> -->
<section anchor="Acknowledgements" title="Acknowledgements">
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t> <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 m
any 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 late
st 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: h
ttps://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>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
The code point assigned in support of this document is taken from The code point assigned in support of this document is taken from
the wrong point in the registration tree. Unfortunately, the code the wrong point in the registration tree. Unfortunately, the code
point has already been deployed in the field without following the point has already been deployed in the field without following the
proper registration review process. The Designated Experts for the proper registration review process. The designated experts for the
registry have considered the issues that correcting this action registry have considered the issues that correcting this action
would cause for deployed implementations and have consented to the would cause for deployed implementations and have consented to the
continued use of the code point. 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"/>
.
IANA is requested to register two URI assignments.
</t> </t>
<t>Registration request for the Trademark Claims Notice namespace:</t>
<t> <t>
<list> This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in <xref target="RFC3688" f
<t> ormat="default"/>. IANA has registered two URI assignments as follows.
URI: urn:ietf:params:xml:ns:tmNotice-1.0
</t>
<t>Registrant Contact: IETF &lt;iesg@ietf.org&gt; ICANN &lt;globalsupp
ort@icann.org&gt;</t>
<t>
XML: None. Namespace URIs do not represent an XML specification.
</t>
<t>Note: Note that this assignment is made from the wrong point i
n
the tree in order to be consistent with deployed
implementations.</t>
</list>
</t> </t>
<t>Registration request for the Trademark Claims Notice XML schema:</t> <t>Trademark Claims Notice namespace:</t>
<t> <dl newline="false" spacing="compact">
<list> <dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:tmNotice-1.0</dd>
<t> <dt>Registrant Contact:</dt>
URI: urn:ietf:params:xml:schema:tmNotice-1.0 <dd>IETF &lt;iesg@ietf.org&gt; and ICANN &lt;globalsupport@icann.org&gt;<
</t> /dd>
<dt>XML:</dt>
<t>Registrant Contact: IETF &lt;iesg@ietf.org&gt; ICANN &lt;globalsupp <dd>None. Namespace URIs do not represent an XML specification.</dd>
ort@icann.org&gt;</t> <dt>Note:</dt>
<dd>Note that this assignment is made from the wrong point in
<t>
XML: See <xref target="FormalSyntaxClaimsNotice"/> of this document.
</t>
<t>Note: Note that this assignment is made from the wrong point i
n
the tree in order to be consistent with deployed the tree in order to be consistent with deployed
implementations.</t> implementations.</dd>
</dl>
</list> <t>Trademark Claims Notice XML schema:</t>
</t> <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;<
/dd>
<dt>XML:</dt>
<dd>See <xref target="FormalSyntaxClaimsNotice" format="default"/> of 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.</dd>
</dl>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
This specification uses HTTP Basic Authentication to provide a simple ap plication-layer authentication service. This specification uses HTTP Basic Authentication to provide a simple ap plication-layer authentication service.
HTTPS is used in all interfaces in order to protect against most common attacks. In addition, 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, 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. providing an extra security measure.
</t> </t>
<t> <t>
The TMDB MUST provide credentials to the appropriate Registries and Regi strars. The TMDB <bcp14>MUST</bcp14> provide credentials to the appropriate Regi stries and Registrars.
</t> </t>
<t> <t>
The TMDB MUST require the use of strong passwords by Registries and Regi strars. The TMDB <bcp14>MUST</bcp14> require the use of strong passwords by Regi stries and Registrars.
</t> </t>
<t> <t>
The TMDB, Registries and Registrars MUST use the best practices describe The TMDB, Registries, and Registrars <bcp14>MUST</bcp14> use the best pr
d in <xref target="RFC7525"/> or its successors. actices described in <xref target="RFC9325" format="default"/> or its successors
.
</t>
</section>
<section numbered="true" toc="default">
<name>Privacy Considerations</name>
<t>This specification defines the interfaces to support the <xref target="
RPM-Requirements" format="default"/>. Legal documents govern the interactions be
tween the different parties, and such legal documents must ensure that privacy-s
ensitive and/or personal data receives the required protection.
</t> </t>
</section> </section>
<section title="Privacy Considerations">
<t>
This specification defines the interfaces to support the
<xref target='RPM-Requirements'/>.
Legal documents govern the interactions between the diffe
rent parties, and such legal documents must ensure that privacy-sensitive and/or
personal data receives the required protection.
</t>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <references>
<name>References</name>
&RFC2119; <references>
&RFC3688; <name>Normative References</name>
&RFC7525; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC7848; 119.xml"/>
&RFC8174; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
688.xml"/>
<reference anchor="MatchingRules" target="https://newgtlds.icann.org/en/ab <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
out/trademark-clearinghouse/matching-rules-14jul16-en.pdf"> 848.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>Memorandum on Implementing Matching Rules</title> 174.xml"/>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<organization>ICANN</organization> 325.xml"/>
</author>
<date day="14" month="July" year="2016" />
</front>
</reference>
<reference anchor="QLP-Addendum" target="https://newgtlds.icann.org/en/abo
ut/trademark-clearinghouse/rpm-requirements-qlp-addendum-10apr14-en.pdf">
<front>
<title>Qualified Launch Program Addendum</title>
<author>
<organization>ICANN</organization>
</author>
<date day="10" month="April" 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 Protection Mechanism Requirements</tit
le>
<author>
<organization>ICANN</organization>
</author>
<date day="30" month="September" year="2013" />
</front>
</reference>
<reference anchor="Claims50" target="https://newgtlds.icann.org/en/about/t
rademark-clearinghouse/previously-abused-16jul13-en.pdf">
<front>
<title>Implementation Notes: Trademark Claims Protection for Previousl
y Abused Names</title>
<author>
<organization>ICANN</organization>
</author>
<date day="16" month="July" year="2013" />
</front>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/ <reference anchor="MatchingRules" target="https://newgtlds.icann.org/en/
TR/2008/REC-xml-20081126/"> about/trademark-clearinghouse/matching-rules-14jul16-en.pdf">
<front> <front>
<title abbrev='Extensible Markup Language (XML) 1.0 (Fifth Edition) RE <title>Explanatory Memorandum: Implementing the Matching Rules</titl
C-xml-20081126'>Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-200 e>
81126</title> <author>
<author initials="T." surname="Bray" fullname="Tim Bray" /> <organization>ICANN</organization>
<author initials="J." surname="Paoli" fullname="Jean Paoli" /> </author>
<author initials="C. M." surname="Sperberg-McQueen" fullname="C. M. <date month="July" year="2016"/>
Sperberg-McQueen" /> </front>
<author initials="E." surname="Maler" fullname="Eve Maler" /> </reference>
<author initials="F." surname="Yergeau" fullname="François Yergeau"
/>
<date year='2008' month='November' />
<keyword>W3C.xml</keyword>
</front>
</reference>
<reference anchor="W3C.REC-xmlschema-1-20041028" target="https://www.w3.or <reference anchor="QLP-Addendum" target="https://newgtlds.icann.org/en/a
g/TR/2004/REC-xmlschema-1-20041028/"> bout/trademark-clearinghouse/rpm-requirements-qlp-addendum-10apr14-en.pdf">
<front> <front>
<title abbrev='XML Schema Part 1: Structures Second Edition REC-xmlsch <title>Trademark Clearinghouse Rights Protection Mechanism Requireme
ema-1-20041028'>XML Schema Part 1: Structures Second Edition REC-xmlschema-1-200 nts:
41028</title> Qualified Launch Program Addendum</title>
<author initials="H. S." surname="Thompson" fullname="Henry S. Thompson <author>
" /> <organization>ICANN</organization>
<author initials="D." surname="Beech" fullname="David Beech" /> </author>
<author initials="M." surname="Maloney" fullname="Murray Maloney" / <date month="April" year="2014"/>
> </front>
<author initials="N." surname="Mendelsohn" fullname="Noah Mendelsoh </reference>
n" />
<date year='2004' month='October' />
<keyword>W3C.xmlschema-1</keyword>
</front>
</reference>
<reference anchor="W3C.REC-xmlschema-2-20041028" target="https://www.w3.or <reference anchor="RPM-Requirements" target="https://newgtlds.icann.org/
g/TR/2004/REC-xmlschema-2-20041028/"> en/about/trademark-clearinghouse/rpm-requirements-30sep13-en.pdf">
<front> <front>
<title abbrev='XML Schema Part 2: Datatypes Second Edition REC-xmlsche <title>Trademark Clearinghouse Rights Protection Mechanism Requireme
ma-2-20041028'>XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041 nts</title>
028</title> <author>
<author initials="P. V." surname="Biron" fullname="Paul V. Biron" /> <organization>ICANN</organization>
<author initials="A." surname="Malhotra" fullname="Ashok Malhotra" </author>
/> <date month="September" year="2013"/>
<date year='2004' month='October' /> </front>
<keyword>W3C.xmlschema-2</keyword> </reference>
</front>
</reference>
</references> <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 Previou
sly Abused Names</title>
<author>
<organization>ICANN</organization>
</author>
<date month="July" year="2013"/>
</front>
</reference>
<references title='Informative References'> <reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
008/REC-xml-20081126/">
<front>
<title abbrev="Extensible Markup Language (XML) 1.0 (Fifth Edition)"
>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"/>
<author initials="J." surname="Paoli" fullname="Jean Paoli"/>
<author initials="C. M." surname="Sperberg-McQueen" fullname="C. M.
Sperberg-McQueen"/>
<author initials="E." surname="Maler" fullname="Eve Maler"/>
<author initials="F." surname="Yergeau" fullname="François Yergeau"/
>
<date year="2008" month="November"/>
<keyword>W3C.xml</keyword>
</front>
<refcontent>W3C Recommendation REC-xml-20081126</refcontent>
</reference>
&RFC7230; <reference anchor="W3C.REC-xmlschema-1-20041028" target="https://www.w3.
&RFC7231; org/TR/2004/REC-xmlschema-1-20041028/">
&RFC7235; <front>
&RFC2818; <title abbrev="XML Schema Part 1: Structures Second Edition">XML Sch
&RFC3339; ema Part 1: Structures Second Edition</title>
&RFC4180; <author initials="H." surname="Thompson" fullname="Henry S. Thompson
&RFC4648; "/>
&RFC4880; <author initials="D." surname="Beech" fullname="David Beech"/>
&RFC5280; <author initials="M." surname="Maloney" fullname="Murray Maloney"/>
&RFC5890; <author initials="N." surname="Mendelsohn" fullname="Noah Mendelsohn
&RFC8499; "/>
<date year="2004" month="October"/>
<keyword>W3C.xmlschema-1</keyword>
</front>
<refcontent>W3C Recommendation REC-xmlschema-1-20041028</refcontent>
</reference>
<reference anchor="WIPO-NICE-CLASSES" target="http://www.wipo.int/classifi <reference anchor="W3C.REC-xmlschema-2-20041028" target="https://www.w3.
cations/nice/en"> org/TR/2004/REC-xmlschema-2-20041028/">
<front> <front>
<title abbrev='WIPO Nice Classification'>WIPO Nice Classification</tit <title abbrev="XML Schema Part 2: Datatypes Second Edition ">XML Sch
le> ema Part 2: Datatypes Second Edition</title>
<author><organization>WIPO</organization></author> <author initials="P." surname="Biron" fullname="Paul V. Biron"/>
<date year='2015' /> <author initials="A." surname="Malhotra" fullname="Ashok Malhotra"/>
<keyword>WIPO</keyword> <date year="2004" month="October"/>
</front> <keyword>W3C.xmlschema-2</keyword>
</reference> </front>
<refcontent>W3C Recommendation REC-xmlschema-2-20041028</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
617.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
339.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
110.xml"/>
<reference anchor="WIPO.ST3" target="http://www.iso.org/iso/home/standards <reference anchor="WIPO-NICE-CLASSES" target="http://www.wipo.int/classi
/country_codes.htm"> fications/nice/en">
<front> <front>
<title abbrev='Two-Letter Codes for the Representation of States, Othe <title abbrev="Nice Classification">Nice Classification</title>
r Entities and Organizations'>Recommended standard on two-letter codes for the r <author>
epresentation of states, other entities and intergovernmental organizations</tit <organization>WIPO</organization>
le> </author>
<author> <keyword>WIPO</keyword>
<organization>WIPO</organization> </front>
</author> </reference>
<date year='2007' month='March' />
<keyword>WIPO</keyword>
</front>
</reference>
<reference anchor="ICANN-GTLD-AGB-20120604" target="http://newgtlds.icann. <reference anchor="WIPO.ST3" target="https://www.wipo.int/export/sites/w
org/en/applicants/agb/guidebook-full-04jun12-en.pdf"> ww/standards/en/pdf/03-03-01.pdf">
<front> <front>
<title>gTLD Applicant Guidebook Version 2012-06-04</title> <title abbrev="Two-Letter Codes for the Representation of States, Ot
<author> her Entities and Organizations">Recommended standard on two-letter codes for the
<organization>ICANN</organization> representation of states, other entities and intergovernmental organizations</t
</author> itle>
<date day="4" month="June" year="2012" /> <author>
</front> <organization>WIPO</organization>
</reference> </author>
<date year="2022" month="November"/>
<keyword>WIPO</keyword>
</front>
</reference>
<reference anchor="ISO3166-2" target="http://www.iso.org/iso/home/standard <reference anchor="ICANN-GTLD-AGB-20120604" target="http://newgtlds.ican
s/country_codes.htm"> n.org/en/applicants/agb/guidebook-full-04jun12-en.pdf">
<front> <front>
<title abbrev='International Standard for country codes and codes for <title>gTLD Applicant Guidebook Version 2012-06-04</title>
their subdivisions'>International Standard for country codes and codes for their <author>
subdivisions</title> <organization>ICANN</organization>
<author> </author>
<organization>ISO</organization> <date month="June" year="2012"/>
</author> </front>
<date year='2006' /> </reference>
<keyword>ISO</keyword>
</front>
</reference>
<reference anchor="ISO3166-2" target="http://www.iso.org/iso/home/standa
rds/country_codes.htm">
<front>
<title abbrev="International Standard for country codes and codes fo
r their subdivisions">International Standard for country codes and codes for the
ir subdivisions</title>
<author>
<organization>ISO</organization>
</author>
<keyword>ISO</keyword>
</front>
</reference>
</references>
</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 th
e 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"/>, <c
ontact 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 rece
ived from <contact fullname="Paul Hoffman"/>.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 421 change blocks. 
3318 lines changed or deleted 2571 lines changed or added

This html diff was produced by rfcdiff 1.48.