rfc9361.original   rfc9361.txt 
Internet Engineering Task Force G. Lozano Independent Submission G. Lozano
Internet-Draft ICANN Request for Comments: 9361 ICANN
Intended status: Informational 23 August 2022 Category: Informational March 2023
Expires: 24 February 2023 ISSN: 2070-1721
ICANN TMCH functional specifications ICANN Trademark Clearinghouse (TMCH) Functional Specifications
draft-ietf-regext-tmch-func-spec-15
Abstract Abstract
This document describes the requirements, the architecture and the This document describes the requirements, the architecture, and the
interfaces between the ICANN Trademark Clearinghouse (TMCH) and interfaces between the ICANN Trademark Clearinghouse (TMCH) and
Domain Name Registries as well as between the ICANN TMCH and Domain Domain Name Registries, as well as between the ICANN TMCH and Domain
Name Registrars for the provisioning and management of domain names Name Registrars for the provisioning and management of domain names
during Sunrise and Trademark Claims Periods. during Sunrise and Trademark Claims Periods.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on 24 February 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9361.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Glossary
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Architecture
4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 9 4.1. Sunrise Period
4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 4.2. Trademark Claims Period
4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Interfaces
4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. hv
4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. vd
4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.3. dy
4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.4. tr
4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.5. ry
4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.6. dr
4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.7. yd
4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.8. dv
4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.9. vh
4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.10. vs
4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.11. sy
4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.12. sr
4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.13. vc
4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.14. cy
4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.15. cr
5. Process Descriptions . . . . . . . . . . . . . . . . . . . . 13 5. Process Descriptions
5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Bootstrapping
5.1.1. Bootstrapping for Registries . . . . . . . . . . . . 13 5.1.1. Bootstrapping for Registries
5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 5.1.1.1. Credentials
5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 5.1.1.2. IP Addresses for Access Control
5.1.1.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 14 5.1.1.3. ICANN TMCH Trust Anchor
5.1.1.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 14 5.1.1.4. TMDB PGP Key
5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15 5.1.2. Bootstrapping for Registrars
5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 5.1.2.1. Credentials
5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 5.1.2.2. IP Addresses for Access Control
5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15 5.1.2.3. ICANN TMCH Trust Anchor
5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 16 5.1.2.4. TMDB PGP Key
5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16 5.2. Sunrise Period
5.2.1. Domain Name registration . . . . . . . . . . . . . . 16 5.2.1. Domain Name Registration
5.2.2. Sunrise Domain Name registration by Registries . . . 18 5.2.2. Sunrise Domain Name Registration by Registries
5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 19 5.2.3. TMDB Sunrise Services for Registries
5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 19 5.2.3.1. SMD Revocation List
5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 20 5.2.3.2. TMV Certificate Revocation List (CRL)
5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 20 5.2.3.3. Notice of Registered Domain Names (NORDN)
5.2.4. Sunrise Domain Name registration by Registrars . . . 23 5.2.4. Sunrise Domain Name Registration by Registrars
5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 23 5.2.5. TMDB Sunrise Services for Registrars
5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23 5.3. Trademark Claims Period
5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23 5.3.1. Domain Registration
5.3.2. Trademark Claims Domain Name registration by 5.3.2. Trademark Claims Domain Name Registration by Registries
Registries . . . . . . . . . . . . . . . . . . . . . 24 5.3.3. TMDB Trademark Claims Services for Registries
5.3.3. TMBD Trademark Claims Services for Registries . . . . 26 5.3.3.1. Domain Name Label (DNL) List
5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 26 5.3.3.2. Notice of Registered Domain Names (NORDN)
5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 27 5.3.4. Trademark Claims Domain Name Registration by Registrars
5.3.4. Trademark Claims Domain Name registration by 5.3.5. TMDB Trademark Claims Services for Registrars
Registrars . . . . . . . . . . . . . . . . . . . . . 27 5.3.5.1. Claims Notice Information Service (CNIS)
5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28 5.4. Qualified Launch Program (QLP) Period
5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28 5.4.1. Domain Registration
5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 29 5.4.2. TMDB QLP Services for Registries
5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 29 5.4.2.1. Sunrise List (SURL)
5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31 6. Data Format Descriptions
5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31 6.1. Domain Name Label (DNL) List
6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 32 6.2. SMD Revocation List
6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 32 6.3. List of Registered Domain Names (LORDN) File
6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 34 6.3.1. LORDN Log File
6.3. List of Registered Domain Names (LORDN) file . . . . . . 35 6.3.1.1. LORDN Log Result Codes
6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39 6.4. Signed Mark Data (SMD) File
6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 6.5. Trademark Claims Notice (TCN)
6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46 6.6. Sunrise List (SURL)
6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47 7. Formal Syntax
6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54 7.1. Trademark Claims Notice (TCN)
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 8. IANA Considerations
7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55 9. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 10. Privacy Considerations
9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58 11. References
9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58 11.1. Normative References
9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58 11.2. Informative References
9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58 Acknowledgements
9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58 Author's Address
9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 58
9.6. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 59
9.7. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 59
9.8. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 59
9.9. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 59
9.10. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 59
9.11. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 59
9.12. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 59
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . . . 60
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
13.1. Normative References . . . . . . . . . . . . . . . . . . 61
13.2. Informative References . . . . . . . . . . . . . . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
Domain Name Registries (DNRs) may operate in special modes for Domain Name Registries may operate in special modes for certain
certain periods of time enabling trademark holders to protect their periods of time, enabling Trademark Holders to protect their rights
rights during the introduction of a Top Level Domain (TLD). during the introduction of a Top-Level Domain (TLD).
Along with the introduction of new generic TLDs (gTLD), two special Along with the introduction of new generic TLDs (gTLDs), two special
modes came into effect: modes came into effect:
* Sunrise Period, the Sunrise Period allows trademark holders an * Sunrise Period: The Sunrise Period allows Trademark Holders an
advance opportunity to register domain names corresponding to advance opportunity to register domain names corresponding to
their marks before names are generally available to the public. their marks before names are generally available to the public.
* Trademark Claims Period, the Trademark Claims Period follows the * Trademark Claims Period: The Trademark Claims Period follows the
Sunrise Period and runs for at least the first 90 days of an Sunrise Period and runs for at least the first 90 days of an
initial operating period of general registration. During the initial operating period of general registration. During the
Trademark Claims Period, anyone attempting to register a domain Trademark Claims Period, anyone attempting to register a domain
name matching a mark that is recorded in the ICANN Trademark name matching a mark that is recorded in the ICANN Trademark
Clearinghouse (TMCH) will receive a notification displaying the Clearinghouse (TMCH) will receive a notification displaying the
relevant mark information. relevant mark information.
This document describes the requirements, the architecture and the This document describes the requirements, the architecture, and the
interfaces between the ICANN TMCH and Domain Name Registries (called interfaces between the ICANN TMCH and Domain Name Registries (called
Registries in the rest of the document) as well as between the ICANN "Registries" in the rest of the document), as well as between the
TMCH and Domain Name Registrars (called Registrars in the rest of the ICANN TMCH and Domain Name Registrars (called "Registrars" in the
document) for the provisioning and management of domain names during rest of the document) for the provisioning and management of domain
the Sunrise and Trademark Claims Periods. names during Sunrise and Trademark Claims Periods.
For any date and/or time indications, Coordinated Universal Time For any date and/or time indications, Coordinated Universal Time
(UTC) applies. (UTC) applies.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 5, line 11 skipping to change at line 173
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
implementation. implementation.
"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 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix
"tmNotice" is used, but implementations MUST NOT depend on it and "tmNotice" is used, but implementations MUST NOT depend on it and
instead employ a proper namespace-aware XML parser and serializer to instead employ a proper namespace-aware XML parser and serializer to
interpret and output the XML documents. interpret and output the XML documents.
Extensible Markup Language (XML) 1.0 as described in Extensible Markup Language (XML) 1.0, as described in
[W3C.REC-xml-20081126] and XML Schema notation as described in [W3C.REC-xml-20081126], and XML Schema notation, as described in
[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028],
used in this specification. are used in this specification.
3. Glossary 3. Glossary
In the following section, the most common terms are briefly In the following section, the most common terms are briefly
explained: explained:
* Backend Registry Operator: Entity that manages (a part of) the Backend Registry Operator: An entity that manages (a part of) the
technical infrastructure for a Registry Operator. The Registry technical infrastructure for a Registry Operator. The Registry
Operator may also be the Backend Registry Operator. Operator may also be the Backend Registry Operator.
* CA: Certificate Authority, see [RFC5280]. CA: Certification Authority. See [RFC5280].
* CNIS, Claims Notice Information Service: This service provides CNIS: Claims Notice Information Service. This service provides
Trademark Claims Notices (TCN) to Registrars. Trademark Claims Notices (TCNs) to Registrars.
* CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 CRC32: Cyclic Redundancy Check. This algorithm is used in the ISO
standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 3309 standard and in Section 8.1.1.6.2 of ITU-T recommendation
V.42.
* CRL: Certificate Revocation List, see [RFC5280]. CRL: Certificate Revocation List. See [RFC5280].
* CSV: Comma-Separated Values, see [RFC4180] CSV: Comma-Separated Values. See [RFC4180].
* Date and time, datetime: Date and time are specified following the datetime: Date and time. The date and time are specified following
standard "Date and Time on the Internet specification", see the standard specification "Date and Time on the Internet:
[RFC3339]. Timestamps". See [RFC3339].
* DN, Domain Name, domain name: see definition of Domain name in DN: Domain Name. See [RFC8499].
[RFC8499].
* DNROID, DN Repository Object IDentifier: an identifier assigned by DNL: Domain Name Label. The DNL is an A-label or a Non-Reserved LDH
the Registry to each DN object that unequivocally identifies said (NR-LDH) label. See [RFC5890].
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.
* DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see DNL List: A list of DNLs that are covered by a PRM.
[RFC5890]).
* DNL List: A list of DNLs that are covered by a PRM. DNROID: DN Repository Object IDentifier. This identifier is
assigned by the Registry to each DN object that unequivocally
identifies said DN object. For example, if a new DN object is
created for a name that existed in the past, the DN objects will
have different DNROIDs.
* DNS: Domain Name System, see [RFC8499]. DNS: Domain Name System. See [RFC8499].
* Effective allocation: A DN is considered effectively allocated Effective Allocation: A DN is considered effectively allocated when
when the DN object for the DN has been created in the SRS of the 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 Registry and has been assigned to the effective user. A DN object
in status "pendingCreate" or any other status that precedes the in status "pendingCreate" or any other status that precedes the
first time a DN is assigned to an end-user is not considered an first time a DN is assigned to an end user is not considered an
effective allocation. A DN object created internally by the effective allocation. A DN object created internally by the
Registry for subsequent delegation to another Registrant is not Registry for subsequent delegation to another Registrant is not
considered an effective allocation. considered an effective allocation.
* EPP: The Extensible Provisioning Protocol, see definition of EPP EPP: Extensible Provisioning Protocol. See [RFC8499].
in [RFC8499].
* FQDN: Fully-Qualified Domain Name, see definition of FQDN in FQDN: Fully Qualified Domain Name. See [RFC8499].
[RFC8499].
* HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. HTTP: Hypertext Transfer Protocol. See [RFC9110].
* HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. HTTPS: HTTP over TLS (Transport Layer Security). See [RFC9110].
* IDN: Internationalized Domain Name, see definition of IDN in ICANN TMCH: A central repository for information to be
[RFC8499]. authenticated, stored, and disseminated, pertaining to the rights
of TMHs. The ICANN TMCH is split into two functions: TMV and TMDB
(see below). There could be several entities performing the TMV
function but only one entity performing the TMDB function.
* Lookup Key: A random string of up to 51 chars from the set [a-zA- ICANN TMCH-CA: The Certification Authority (CA) for the ICANN TMCH.
Z0-9/] to be used as the lookup key by Registrars to obtain the This CA is operated by ICANN. The public key for this CA is the
TCN using the CNIS. Lookup Keys are unique and are related to one trust anchor used to validate the identity of each TMV.
IDN: Internationalized Domain Name. See [RFC8499].
Lookup Key: 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. DNL only.
* LORDN, List of Registered Domain Names: This is the list of LORDN: List of Registered Domain Names. This is the list of
effectively allocated DNs matching a DNL of a PRM. Registries effectively allocated DNs matching a DNL of a PRM. Registries
will upload this list to the TMDB (during the NORDN process). will upload this list to the TMDB (during the NORDN process).
* Matching Rules: Some trademarks entitled to inclusion in the TMDB Matching Rules: Some trademarks entitled to inclusion in the TMDB
include characters that are impermissible in the domain name include characters that are impermissible in the DNS as a DNL.
system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH The TMV changes (using the ICANN TMCH Matching Rules
Matching Rules [MatchingRules]) certain DNS-impermissible [MatchingRules]) certain DNS-impermissible characters in a
characters in a trademark into DNS-permissible equivalent trademark into DNS-permissible equivalent characters.
characters
* NORDN, Notification of Registered Domain Names: The process by NORDN: Notification of Registered Domain Names. This is the process
which Registries upload their recent LORDN to the TMDB. by which Registries upload their recent LORDN to the TMDB.
* PGP: Pretty Good Privacy, see [RFC4880] PGP: Pretty Good Privacy. See [RFC4880].
* PKI: Public Key Infrastructure, see [RFC5280]. PKI: Public Key Infrastructure. See [RFC5280].
* PRM, Pre-registered mark: Mark that has been pre-registered with PRM: Pre-Registered Mark. A mark that has been pre-registered with
the ICANN TMCH. the ICANN TMCH.
* QLP Period, Qualified Launch Program Period: During this optional QLP Period: Qualified Launch Program Period. During this optional
period, a special process applies to DNs matching the Sunrise List period, a special process applies to DNs matching the Sunrise List
(SURL) and/or the DNL List, to ensure that TMHs are informed of a (SURL) and/or the DNL List to ensure that TMHs are informed of a
DN matching their PRM. DN matching their PRM.
* Registrant: see definition of Registrant in [RFC8499]. Registrant: See the definition of Registrant in [RFC8499].
* Registrar, Domain Name Registrar: see definition of Registrar in Registrar: Domain Name Registrar. See [RFC8499].
[RFC8499].
* Registry, Domain Name Registry, Registry Operator: see definition Registry: Domain Name Registry, Registry Operator. See [RFC8499].
of Registry in [RFC8499]. A Registry Operator is the contracting A Registry Operator is the contracting party with ICANN for the
party with ICANN for the TLD. TLD.
* SMD, Signed Mark Data: A cryptographically signed token issued by 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 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 [RFC7848]. An SMD DN that matches a DNL of a PRM. See [RFC7848]. An SMD generated
generated by an ICANN-approved trademark validator (TMV) contains by an ICANN-approved Trademark Validator (TMV) contains both the
both the signed token and the TMV's PKIX certificate. signed token and the TMV's PKIX certificate.
* SMD File: A file containing the SMD (see above) and some human SMD File: A file containing the SMD (see above) and some human-
readable data. The latter is usually ignored in the processing of readable data. The latter is usually ignored in the processing of
the SMD File. See also Section 6.4. the SMD File. See Section 6.4.
* SMD Revocation List: The SMD Revocation List is used by Registries SMD Revocation List: The SMD Revocation List is used by Registries
(and optionally by Registrars) during the Sunrise Period to ensure (and optionally by Registrars) during the Sunrise Period to ensure
that an SMD is still valid (i.e. not revoked). The SMD Revocation that an SMD is still valid (i.e., not revoked). The SMD
List has a similar function as CRLs used in PKI. Revocation List has a similar function as CRLs used in PKI.
* SRS: Shared Registration System, see also
[ICANN-GTLD-AGB-20120604].
* SURL, Sunrise List: The list of DNLs that are covered by a PRM and SRS: Shared Registration System. See [ICANN-GTLD-AGB-20120604].
eligible for Sunrise.
* Sunrise Period: During this period DNs matching a DNL of a PRM can Sunrise Period: During this period, DNs matching a DNL of a PRM can
be exclusively obtained by the respective TMHs. For DNs matching be exclusively obtained by the respective TMHs. For DNs matching
a PRM, a special process applies to ensure that TMHs are informed a PRM, a special process applies to ensure that TMHs are informed
on the effective allocation of a DN matching their PRM. on the effective allocation of a DN matching their PRM.
* TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. SURL: Sunrise List. The list of DNLs that are covered by a PRM and
are eligible for Sunrise.
* ICANN TMCH: a central repository for information to be TCN: Trademark Claims Notice, Claims Notice, Trademark Notice. A
authenticated, stored, and disseminated, pertaining to the rights Trademark Claims Notice consists of one or more Trademark Claims
of TMHs. The ICANN TMCH is split into two functions TMV and TMDB and is provided to prospective Registrants of DNs.
(see below). There could be several entities performing the TMV
function, but only one entity performing the TMDB function.
* ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. TCNID: Trademark Claims Notice Identifier. An element of the
This CA is operated by ICANN. The public key for this CA is the Trademark Claims Notice (see above), identifying said TCN. The
trust anchor used to validate the identity of each TMV. Trademark Claims Notice Identifier is specified in the element
<tmNotice:id>.
* TMDB, Trademark Clearinghouse Database: Serves as a database of TLD: Top-Level Domain Name. See [RFC8499].
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.
* TMH, Trademark Holder: The person or organization owning rights on TMDB: 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.
TMH: Trademark Holder. The person or organization owning rights on
a mark. a mark.
* TMV, Trademark Validator, Trademark validation organization: An TMV: Trademark Validator, Trademark Validation organization. An
entity authorized by ICANN to authenticate and validate entity authorized by ICANN to authenticate and validate
registrations in the TMDB ensuring the marks qualify as registered registrations in the TMDB, ensuring the marks qualify as
or are court-validated marks or marks that are protected by registered, are court-validated marks, or are protected by statute
statute or treaty. This entity would also be asked to ensure that or treaty. This entity would also be asked to ensure that proof
proof of use of marks is provided, which can be demonstrated by of use of marks is provided, which can be demonstrated by
furnishing a signed declaration and one specimen of current use. furnishing a signed declaration and one specimen of current use.
* Trademark, mark: Marks are used to claim exclusive properties of Trademark, Mark: Marks are used to claim exclusive properties of
products or services. A mark is typically a name, word, phrase, products or services. A mark is typically a name, word, phrase,
logo, symbol, design, image, or a combination of these elements. logo, symbol, design, image, or a combination of these elements.
For the scope of this document only textual marks are relevant. For the scope of this document, only textual marks are relevant.
* Trademark Claims, Claims: Provides information to enhance the
understanding of the Trademark rights being claimed by the TMH.
* TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A
Trademark Claims Notice consist of one or more Trademark Claims
and are provided to prospective Registrants of DNs.
* TCNID, Trademark Claims Notice Identifier: An element of the Trademark Claims, Claims: Provides information to enhance the
Trademark Claims Notice (see above), identifying said TCN. The understanding of the trademark rights being claimed by the TMH.
Trademark Claims Notice Identifier is specified in the element
<tmNotice:id>.
* Trademark Claims Period: During this period, a special process Trademark Claims Period: During this period, a special process
applies to DNs matching the DNL List, to ensure that TMHs are applies to DNs matching the DNL List to ensure that TMHs are
informed of a DN matching their PRM. For DNs matching the DNL informed of a DN matching their PRM. For DNs matching the DNL
List, Registrars show a TCN to prospective Registrants that has to List, Registrars show a TCN to prospective Registrants that has to
be acknowledged before effective allocation of the DN. be acknowledged before effective allocation of the DN.
* UTC: Coordinated Universal Time, as maintained by the Bureau UTC: Coordinated Universal Time. This is maintained by the Bureau
International des Poids et Mesures (BIPM); see also [RFC3339]. International des Poids et Mesures (BIPM). See [RFC3339].
4. Architecture 4. Architecture
4.1. Sunrise Period 4.1. Sunrise Period
Architecture of the Sunrise Period
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 page 10, line 5 skipping to change at line 391
: v v . | B | . v : v v . | B | . v
: .-----------. . yd | | . .---------------. : .-----------. . yd | | . .---------------.
: | Registry |---------->| | . | ICANN TMCH-CA | : | Registry |---------->| | . | ICANN TMCH-CA |
: '-----------' . '---------' . '---------------' : '-----------' . '---------' . '---------------'
: ^ . . | : : ^ . . | :
: | ''''''''''''''''''' | : : | ''''''''''''''''''' | :
: | cy | : : | cy | :
: cr '-----------------------------------------' : : cr '-----------------------------------------' :
:......................................................: :......................................................:
Figure 1 Figure 1: Architecture of the Sunrise Period
Figure 1 depicts the architecture of the Sunrise Period, including Figure 1 depicts the architecture of the Sunrise Period, including
all the actors and interfaces. all the actors and interfaces.
4.2. Trademark Claims Period 4.2. Trademark Claims Period
Architecture of the Trademark Claims Period
.''''''''''''''. .''''''''''''''.
. ICANN TMCH . . ICANN TMCH .
................ ................
. . . .
.------------. . .-------. . hv .-----. .------------. . .-------. . hv .-----.
| Registrant | . | TMV |<----------->| TMH | | Registrant | . | TMV |<----------->| TMH |
'------------' . '-------' . vh '-----' '------------' . '-------' . vh '-----'
| . ^ . | . ^ .
| . | dv . | . | dv .
tr | . vd | . tr | . vd | .
skipping to change at page 10, line 36 skipping to change at line 420
| Registrar |<--------| | . | Registrar |<--------| | .
'-----------' . | T | . '-----------' . | T | .
ry | . | M | . ry | . | M | .
v . | D | . v . | D | .
.----------. dy . | B | . .----------. dy . | B | .
| Registry |<------->| | . | Registry |<------->| | .
'----------' yd . '-------' . '----------' yd . '-------' .
. . . .
'''''''''''''' ''''''''''''''
Figure 2 Figure 2: Architecture of the Trademark Claims Period
Figure 2 depicts the architecture of the Trademark Claims Period, Figure 2 depicts the architecture of the Trademark Claims Period,
including all the actors and interfaces. including all the actors and interfaces.
4.3. Interfaces 4.3. Interfaces
In the sub-sections below follows a short description of each The subsections below contain short descriptions of each interface to
interface to provide an overview of the architecture. More detailed provide an overview of the architecture. More detailed descriptions
descriptions of the relevant interfaces follow further below of the relevant interfaces are in Section 5.
(Section 5).
4.3.1. hv 4.3.1. hv
The TMH registers a mark with a TMV via the hv interface. The TMH registers a mark with a TMV via the hv interface.
After the successful registration of the mark, the TMV makes After successful registration of the mark, the TMV makes a Signed
available a SMD File (see also Section 6.4) to the TMH to be used Mark Data (SMD) File available (see Section 6.4) to the TMH to be
during the Sunrise Period. used during the Sunrise Period.
The specifics of the hv interface are beyond the scope of this The specifics of the hv interface are beyond the scope of this
document. document.
4.3.2. vd 4.3.2. vd
After successful mark registration, the TMV ensures the TMDB inserts After successful registration of the mark, the TMV ensures the TMDB
the corresponding DNLs and mark information into the database via the inserts the corresponding DNLs and marks information into the
vd interface. database via the vd interface.
The specifics of the vd interface are beyond the scope of this The specifics of the vd interface are beyond the scope of this
document. document.
4.3.3. dy 4.3.3. dy
During the Trademark Claims Period the Registry fetches the latest During the Trademark Claims Period, the Registry fetches the latest
DNL List from the TMDB via the dy interface at regular intervals. DNL List from the TMDB via the dy interface at regular intervals.
The protocol used on the dy interface is HTTPS. The protocol used on the dy interface is HTTPS.
Not relevant during the Sunrise Period. This interface is not relevant during the Sunrise Period.
4.3.4. tr 4.3.4. tr
The Registrant communicates with the Registrar via the tr interface. The Registrant communicates with the Registrar via the tr interface.
The specifics of the tr interface are beyond the scope of this The specifics of the tr interface are beyond the scope of this
document. document.
4.3.5. ry 4.3.5. ry
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 EPP. The ry interfaces are typically implemented in EPP.
4.3.6. dr 4.3.6. dr
During the Trademark Claims Period, the Registrar fetches the TCN During the Trademark Claims Period, the Registrar fetches the TCN
from the TMDB (to be displayed to the Registrant via the tr from the TMDB (to be displayed to the Registrant via the tr
interface) via the dr interface. The protocol used for fetching the interface) via the dr interface. The protocol used for fetching the
TCN is HTTPS. TCN is HTTPS.
Not relevant during the Sunrise Period. This interface is not relevant during the Sunrise Period.
4.3.7. yd 4.3.7. yd
During the Sunrise Period the Registry notifies the TMDB via the yd During the Sunrise Period, the Registry notifies the TMDB via the yd
interface of all DNs effectively allocated. interface of all DNs effectively allocated.
During the Trademark Claims Period, the Registry notifies the TMDB During the Trademark Claims Period, the Registry notifies the TMDB
via the yd interface of all DNs effectively allocated that matched an via the yd interface of all DNs effectively allocated that matched an
entry in the Registry previously downloaded DNL List during the entry in the DNL List that the Registry previously downloaded during
creation of the DN. the creation of the DN.
The protocol used on the yd interface is HTTPS. The protocol used on the yd interface is HTTPS.
4.3.8. dv 4.3.8. dv
The TMDB notifies via the dv interface to the TMV of all DNs The TMDB notifies the TMV via the dv interface of all effectively
effectively allocated that match a mark registered by that TMV. allocated DNs that match a mark registered by that TMV.
The specifics of the dv interface are beyond the scope of this The specifics of the dv interface are beyond the scope of this
document. document.
4.3.9. vh 4.3.9. vh
The TMV notifies the TMH via the vh interface after a DN has been The TMV notifies the TMH via the vh interface after an effectively
effectively allocated that matches a PRM of this TMH. allocated DN matches a PRM of this THM.
The specifics of the vh interface are beyond the scope of this The specifics of the vh interface are beyond the scope of this
document. document.
4.3.10. vs 4.3.10. vs
The TMV requests to add a revoked SMD to the SMD Revocation List at The TMV requests to add revoked SMDs to the SMD Revocation List at
the TMDB. the TMDB.
The specifics of the vs interface are beyond the scope of this The specifics of the vs interface are beyond the scope of this
document. document.
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
4.3.11. sy 4.3.11. sy
During the Sunrise Period the Registry fetches the most recent SMD During the Sunrise Period, the Registry fetches the most recent SMD
Revocation List from the TMDB via the sy interface in regular Revocation List from the TMDB via the sy interface in regular
intervals. The protocol used on the sy interface is HTTPS. intervals. The protocol used on the sy interface is HTTPS.
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
4.3.12. sr 4.3.12. sr
During the Sunrise Period the Registrar may fetch the most recent SMD During the Sunrise Period, the Registrar may fetch the most recent
Revocation List from the TMDB via the sr interface. The protocol SMD Revocation List from the TMDB via the sr interface. The protocol
used on the sr interface is the same as on the sy interface (s. used on the sr interface is the same as on the sy interface (see
above), i.e. HTTPS. above), i.e., HTTPS.
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
4.3.13. vc 4.3.13. vc
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.
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.
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
4.3.14. cy 4.3.14. cy
During the Sunrise Period the Registry fetches the most recent TMV During the Sunrise Period, the Registry fetches the most recent TMV
CRL file from the ICANN TMCH-CA via the cy interface at regular CRL file from the ICANN TMCH-CA via the cy interface at regular
intervals. The TMV CRL is used for validation of TMV certificates. intervals. The TMV CRL is used for validation of TMV certificates.
The protocol used on the cy interface is HTTPS. The protocol used on the cy interface is HTTPS.
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
4.3.15. cr 4.3.15. cr
During the Sunrise Period the Registrar optionally fetches the most During the Sunrise Period, the Registrar optionally fetches the most
recent TMV CRL file from the ICANN TMCH-CA via the cr interface at recent TMV CRL file from the ICANN TMCH-CA via the cr interface at
regular intervals. The TMV CRL is used for validation of TMV regular intervals. The TMV CRL is used for validation of TMV
certificates. The protocol used on the cr interface is HTTPS. certificates. The protocol used on the cr interface is HTTPS.
Not relevant during the Trademark Claims Period. This interface is not relevant during the Trademark Claims Period.
5. Process Descriptions 5. Process Descriptions
5.1. Bootstrapping 5.1. Bootstrapping
5.1.1. Bootstrapping for Registries 5.1.1. Bootstrapping for Registries
5.1.1.1. Credentials 5.1.1.1. Credentials
Each Registry Operator will receive authentication credentials from Each Registry Operator will receive authentication credentials from
the TMDB to be used: the TMDB to be used:
* During the Sunrise Period to fetch the SMD Revocation List from * during the Sunrise Period to fetch the SMD Revocation List from
the TMBD via the sy interface (Section 4.3.11). the TMDB via the sy interface (Section 4.3.11),
* During the Trademark Claims Period to fetch the DNL List from the * during the Trademark Claims Period to fetch the DNL List from the
TMDB via the dy interface (Section 4.3.3). TMDB via the dy interface (Section 4.3.3), and
* During the NORDN process to notify the LORDN to the TMDB via the * during the NORDN process to notify the LORDN to the TMDB via the
yd interface (Section 4.3.7). yd interface (Section 4.3.7).
Note: credentials are created per TLD and provided to the Registry Note: Credentials are created per TLD and provided to the Registry
Operator. Operator.
5.1.1.2. IP Addresses for Access Control 5.1.1.2. IP Addresses for Access Control
Each Registry Operator MUST provide to the TMDB all IP addresses that Each Registry Operator MUST provide the TMDB with all IP addresses,
will be used to: which will be used to:
* Fetch the SMD Revocation List via the sy interface * fetch the SMD Revocation List via the sy interface
(Section 4.3.11). (Section 4.3.11),
* Fetch the DNL List from the TMDB via the dy interface * fetch the DNL List from the TMDB via the dy interface
(Section 4.3.3). (Section 4.3.3), and
* Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). * upload the LORDN to the TMDB via the yd interface (Section 4.3.7).
This access restriction MAY be applied by the TMDB in addition to This access restriction MAY be applied by the TMDB in addition to
HTTP Basic access authentication (see [RFC7235]). For credentials to HTTP Basic access authentication (see [RFC7617]). For credentials to
be used, see Section 5.1.1.1. be used, see Section 5.1.1.1.
The TMDB MAY limit the number of IP addresses to be accepted per The TMDB MAY limit the number of IP addresses to be accepted per
Registry Operator. Registry Operator.
5.1.1.3. ICANN TMCH Trust Anchor 5.1.1.3. ICANN TMCH Trust Anchor
Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of Each Registry Operator MUST fetch the PKIX certificate [RFC5280] of
the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ the ICANN TMCH-CA (Trust Anchor) from <https://ca.icann.org/tmch.crt>
tmch.crt > to be used: to be used:
* During the Sunrise Period to validate the TMV certificates and the * during the Sunrise Period to validate the TMV certificates and the
TMV CRL. TMV CRL.
5.1.1.4. TMDB PGP Key 5.1.1.4. TMDB PGP Key
The TMDB MUST provide each Registry Operator with the public portion The TMDB MUST provide each Registry Operator with the public portion
of the PGP Key used by TMDB, to be used: of the PGP Key used by the TMDB, which is to be used:
* During the Sunrise Period to perform integrity checking of the SMD * during the Sunrise Period to perform integrity checking of the SMD
Revocation List fetched from the TMDB via the sy interface Revocation List fetched from the TMDB via the sy interface
(Section 4.3.11). (Section 4.3.11) and
* During the Trademark Claims Period to perform integrity checking * during the Trademark Claims Period to perform integrity checking
of the DNL List fetched from the TMDB via the dy interface of the DNL List fetched from the TMDB via the dy interface
(Section 4.3.3). (Section 4.3.3).
5.1.2. Bootstrapping for Registrars 5.1.2. Bootstrapping for Registrars
5.1.2.1. Credentials 5.1.2.1. Credentials
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:
* During the Sunrise Period to (optionally) fetch the SMD Revocation * during the Sunrise Period to (optionally) fetch the SMD Revocation
List from the TMDB via the sr interface (Section 4.3.12). List from the TMDB via the sr interface (Section 4.3.12) and
* During the Trademark Claims Period to fetch TCNs from the TMDB via * during the Trademark Claims Period to fetch TCNs from the TMDB via
the dr interface (Section 4.3.6). the dr interface (Section 4.3.6).
5.1.2.2. IP Addresses for Access Control 5.1.2.2. IP Addresses for Access Control
Each Registrar MUST provide to the TMDB all IP addresses, which will Each Registrar MUST provide the TMDB with all IP addresses, which
be used to: will be used to:
* Fetch the SMD Revocation List via the sr interface * fetch the SMD Revocation List via the sr interface
(Section 4.3.12). (Section 4.3.12) and
* Fetch TCNs via the dr interface (Section 4.3.6). * fetch TCNs via the dr interface (Section 4.3.6).
This access restriction MAY be applied by the TMDB in addition to This access restriction MAY be applied by the TMDB in addition to
HTTP Basic access authentication (for credentials to be used, see HTTP Basic access authentication (for credentials to be used, see
Section 5.1.2.1). Section 5.1.2.1).
The TMDB MAY limit the number of IP addresses to be accepted per The TMDB MAY limit the number of IP addresses to be accepted per
Registrar. Registrar.
5.1.2.3. ICANN TMCH Trust Anchor 5.1.2.3. ICANN TMCH Trust Anchor
Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust
Anchor) from < https://ca.icann.org/tmch.crt > to be used: Anchor) from <https://ca.icann.org/tmch.crt> to be used:
* During the Sunrise Period to (optionally) validate the TMV * during the Sunrise Period to (optionally) validate the TMV
certificates and TMV CRL. certificates and TMV CRL.
5.1.2.4. TMDB PGP Key 5.1.2.4. TMDB PGP Key
Registrars MUST receive the public portion of the PGP Key used by Registrars MUST receive the public portion of the PGP Key used by
TMDB from the TMDB administrator to be used: TMDB from the TMDB administrator to be used:
* During the Sunrise Period to (optionally) perform integrity * during the Sunrise Period to (optionally) perform integrity
checking of the SMD Revocation List fetched from the TMDB via the checking of the SMD Revocation List fetched from the TMDB via the
sr interface (Section 4.3.12). sr interface (Section 4.3.12).
5.2. Sunrise Period 5.2. Sunrise Period
5.2.1. Domain Name registration 5.2.1. Domain Name Registration
Domain Name registration during the Sunrise Period
.------------. .-----------. .----------. .------------. .-----------. .----------.
| Registrant | | Registrar | | Registry | | Registrant | | Registrar | | Registry |
'------------' '-----------' '----------' '------------' '-----------' '----------'
| | | | | |
| Request DN | | | Request DN | |
| registration | | | registration | |
| (with SMD) | | | (with SMD) | |
|---------------->| Check DN availability | |---------------->| Check DN availability |
| |---------------------------->| | |---------------------------->|
skipping to change at page 17, line 41 skipping to change at line 716
| Registration |.-----------. Error .----------------------. | Registration |.-----------. Error .----------------------.
| error || TRY AGAIN |<-----( Validation successful? ) | error || TRY AGAIN |<-----( Validation successful? )
|<----------------|| / ABORT | no '----------------------' |<----------------|| / ABORT | no '----------------------'
| |'-----------' | yes | |'-----------' | yes
| | | | | |
| | DN registered | | | DN registered |
| DN registered |<----------------------------| | DN registered |<----------------------------|
|<----------------| | |<----------------| |
| | | | | |
Figure 3 Figure 3: Domain Name Registration during the Sunrise Period
Figure 3 represents a synchronous DN registration workflow (usually Figure 3 represents a synchronous DN registration workflow (usually
called first come first served). called first come first served).
5.2.2. Sunrise Domain Name registration by Registries 5.2.2. Sunrise Domain Name Registration by Registries
Registries MUST perform a minimum set of checks for verifying each DN Registries MUST perform a minimum set of checks for verifying each DN
registration during the Sunrise Period upon reception of a registration during the Sunrise Period upon reception of a
registration request over the ry interface (Section 4.3.5). If any registration request over the ry interface (Section 4.3.5). If any
of these checks fails the Registry MUST abort the registration. Each of these checks fail, the Registry MUST abort the registration. Each
of these checks MUST be performed before the DN is effectively of these checks MUST be performed before the DN is effectively
allocated. allocated.
In case of asynchronous registrations (e.g. auctions), the minimum In case of asynchronous registrations (e.g., auctions), the minimum
set of checks MAY be performed when creating the intermediate object set of checks MAY be performed when creating the intermediate object
(e.g. a DN application) used for DN registration. If the minimum set (e.g., a DN application) used for DN registration. If the minimum
of checks is performed when creating the intermediate object (e.g. a set of checks is performed when creating the intermediate object
DN application) a Registry MAY effectively allocate the DN without (e.g., a DN application), a Registry MAY effectively allocate the DN
performing the minimum set of checks again. without performing the minimum set of checks again.
Performing the minimum set of checks Registries MUST verify that: Performing the minimum set of checks, Registries MUST verify that:
1. An SMD has been received from the Registrar along with the DN 1. an SMD has been received from the Registrar, along with the DN
registration. registration,
2. The certificate of the TMV has been correctly signed by the ICANN 2. the certificate of the TMV has been correctly signed by the ICANN
TMCH-CA. (The certificate of the TMV is contained within the TMCH-CA (the certificate of the TMV is contained within the SMD),
SMD.)
3. The datetime when the validation is done is within the validity 3. the datetime when the validation is done is within the validity
period of the TMV certificate. period of the TMV certificate,
4. The certificate of the TMV is not listed in the TMV CRL file 4. the certificate of the TMV is not listed in the TMV CRL file
specified in the CRL distribution point of the TMV certificate. specified in the CRL distribution point of the TMV certificate,
5. The signature of the SMD (signed with the TMV certificate) is 5. the signature of the SMD (signed with the TMV certificate) is
valid. valid,
6. The datetime when the validation is done is within the validity 6. the datetime when the validation is done is within the validity
period of the SMD based on <smd:notBefore> and <smd:notAfter> period of the SMD based on <smd:notBefore> and <smd:notAfter>
elements. elements,
7. The SMD has not been revoked, i.e., is not contained in the SMD 7. the SMD has not been revoked, i.e., is not contained in the SMD
Revocation List. Revocation List, and
8. The leftmost DNL of the DN being effectively allocated matches 8. the leftmost DNL of the DN being effectively allocated matches
one of the labels (<mark:label>) elements in the SMD. For one of the label (<mark:label>) elements in the SMD. For
example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being
effectively allocated, the leftmost DNL would be "xn--mgbachtv". effectively allocated, the leftmost DNL would be "xn--mgbachtv".
These procedure apply to all DN effective allocations at the second These procedures apply to all DN effective allocations at the second
level as well as to all other levels subordinate to the TLD that the level, as well as to all other levels subordinate to the TLD that the
Registry accepts registrations for. Registry accepts registrations for.
5.2.3. TMDB Sunrise Services for Registries 5.2.3. TMDB Sunrise Services for Registries
5.2.3.1. SMD Revocation List 5.2.3.1. SMD Revocation List
A new SMD Revocation List MUST be published by the TMDB twice a day, A new SMD Revocation List MUST 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.
Registries MUST refresh the latest version of the SMD Revocation List Registries MUST refresh the latest version of the SMD Revocation List
at least once every 24 hours. at least once every 24 hours.
Note: the SMD Revocation List will be the same regardless of the TLD. Note: The SMD Revocation List will be the same regardless of the TLD.
If a Backend Registry Operator manages the infrastructure of several If a Backend Registry Operator manages the infrastructure of several
TLDs, the Backend Registry Operator could refresh the SMD Revocation TLDs, the Backend Registry Operator could refresh the SMD Revocation
List once every 24 hours, the SMD Revocation List could be used for List once every 24 hours, and the SMD Revocation List could be used
all the TLDs managed by the Backend Registry Operator. for all the TLDs managed by the Backend Registry Operator.
Update of the SMD Revocation List
.----------. .------. .----------. .------.
| 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 |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| | | |
Figure 4 Figure 4: Update of the SMD Revocation List
Figure 4 depicts the process of downloading the latest SMD Revocation Figure 4 depicts the process of downloading the latest SMD Revocation
List initiated by the Registry. List initiated by the Registry.
5.2.3.2. TMV Certificate Revocation List (CRL) 5.2.3.2. TMV Certificate Revocation List (CRL)
Registries MUST refresh their local copy of the TMV CRL file at least Registries MUST refresh their local copy of the TMV CRL file at least
every 24 hours using the CRL distribution point specified in the TMV once every 24 hours using the CRL distribution point specified in the
certificate. TMV certificate.
Operationally, the TMV CRL file and CRL distribution point is the Operationally, the TMV CRL file and CRL distribution point are the
same for all TMVs and (at publication of this document) located at < same for all TMVs and (at publication of this document) are located
http://crl.icann.org/tmch.crl >. at <http://crl.icann.org/tmch.crl>.
Note: the TMV CRL file will be the same regardless of the TLD. If a Note: The TMV CRL file will be the same regardless of the TLD. If a
Backend Registry Operator manages the infrastructure of several TLDs, Backend Registry Operator manages the infrastructure of several TLDs,
the Backend Registry Operator could refresh the TMV CRL file once the Backend Registry Operator could refresh the TMV CRL file once
every 24 hours, the TMV CRL file could be used for all the TLDs every 24 hours, and the TMV CRL file could be used for all the TLDs
managed by the Backend Registry Operator. managed by the Backend Registry Operator.
Update of the TMV CRL file
.----------. .---------------. .----------. .---------------.
| 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 |
|<--------------------------------------------| |<--------------------------------------------|
| | | |
| | | |
Figure 5 Figure 5: Update of the TMV CRL File
Figure 5 depicts the process of downloading the latest TMV CRL file Figure 5 depicts the process of downloading the latest TMV CRL file
initiated by the Registry. initiated by the Registry.
5.2.3.3. Notice of Registered Domain Names (NORN) 5.2.3.3. Notice of Registered Domain Names (NORDN)
The Registry MUST send a LORDN file containing DNs effectively The Registry MUST send a LORDN file containing DNs effectively
allocated to the TMDB (over the yd interface, Section 4.3.7). allocated to the TMDB (over the yd interface; see Section 4.3.7).
The effective allocation of a DN MUST be reported by the Registry to The effective allocation of a DN MUST be reported by the Registry to
the TMDB within 26 hours of the effective allocation of such DN. the TMDB within 26 hours of the effective allocation of such DN.
The Registry MUST create and upload a LORDN file in case there are The Registry MUST create and upload a LORDN file in case there are
effective allocations in the SRS, that have not been successfully effective allocations in the SRS that have not been successfully
reported to the TMDB in a previous LORDN file. reported to the TMDB in a previous LORDN file.
Based on the timers used by TMVs and the TMDB, the RECOMMENDED Based on the timers used by TMVs and the TMDB, the RECOMMENDED
maximum frequency to upload LORDN files from the Registries to the maximum frequency to upload LORDN files from the Registries to the
TMDB is every 3 hours. TMDB is every 3 hours.
It is RECOMMENDED that Registries try to upload at least two LORDN It is RECOMMENDED that Registries try to upload at least two LORDN
files per day to the TMDB with enough time in between, in order to files per day to the TMDB, with enough time in between, in order to
have time to fix problems reported in the LORDN file. have time to fix problems reported in the LORDN file.
The Registry SHOULD upload a LORDN file only when the previous LORDN The Registry SHOULD upload a LORDN file only when the previous LORDN
file has been processed by the TMDB and the related LORDN Log file file has been processed by the TMDB and the related LORDN Log file
has been downloaded and processed by the Registry. has been downloaded and processed by the Registry.
The Registry MUST upload LORDN files for DNs effectively allocated The Registry MUST upload LORDN files for DNs that are effectively
during the Sunrise or Trademark Claims Period (same applies to DNs allocated during the Sunrise or Trademark Claims Periods (same
effectively allocated using applications created during the Sunrise applies to DNs that are effectively allocated using applications
or Trademark Claims Period in case of using asynchronous created during the Sunrise or Trademark Claims Periods in case of
registrations). using asynchronous registrations).
The yd interface (Section 4.3.7) MUST support at least one (1) and The yd interface (Section 4.3.7) MUST support at least one (1) and
MAY support up to ten (10) concurrent connections from each IP MAY support up to ten (10) concurrent connections from each IP
address registered by a Registry Operator to access the service. address registered by a Registry Operator to access the service.
The TMDB MUST process each uploaded LORDN file and make the related The TMDB MUST process each uploaded LORDN file and make the related
log file available for Registry download within 30 minutes of the log file available for Registry download within 30 minutes of the
finalization of the upload. finalization of the upload.
Notification of Registered Domain Name
.----------. .------. .-----. .-----. .----------. .------. .-----. .-----.
| Registry | | TMDB | | TMV | | TMH | | Registry | | TMDB | | TMV | | TMH |
'----------' '------' '-----' '-----' '----------' '------' '-----' '-----'
| | | | | | | |
.------------------. | | | .------------------. | | |
| Periodically | | | | | Periodically | | | |
| upload LORDN | | | | | upload LORDN | | | |
| file | | | | | file | | | |
'------------------' | | | '------------------' | | |
| | | | | | | |
skipping to change at page 22, line 28 skipping to change at line 906
| | | Verify each domain name | | | | | | Verify each domain name | | |
| | | in the uploaded file | | | | | | in the uploaded file | | |
| | | (within 30') | | | | | | (within 30') | | |
| | '-------------------------' | | | | '-------------------------' | |
| | | ._____.| | | | | ._____.| |
| | Download Log file | | END || | | | Download Log file | | END || |
| |<--------------------| '-----'| | | |<--------------------| '-----'| |
| | | ^ | | | | | ^ | |
| .-----------------. .---------------. | | | | .-----------------. .---------------. | | |
| | Check whether | / everything fine \ no | | | | | Check whether | / everything fine \ no | | |
| | Log file | ( (i.e. no errors )---' | | | | Log file | ( (i.e., no errors )---' | |
| | contains errors | \ in Log file )? / | | | | contains errors | \ in Log file )? / | |
| '-----------------' '---------------' | | | '-----------------' '---------------' | |
| | | yes | | | | | yes | |
| .---------------. | | | | .---------------. | | |
| / everything fine \ yes | | | | / everything fine \ yes | | |
|( (i.e. no errors )-----. | Notify TMVs | | |( (i.e., no errors )-----. | Notify TMVs | |
| \ in Log file )? / | | on the LORDN | | | \ in Log file )? / | | on the LORDN | |
| '---------------' | | pre-registered | | | '---------------' | | pre-registered | |
| | no v | with said TMV | | | | no v | with said TMV | |
| .----------------. .------. |--------------->| | | .----------------. .------. |--------------->| |
'-| Correct Errors | | DONE | | | | '-| Correct Errors | | DONE | | | |
'----------------' '------' | | Notify each | '----------------' '------' | | Notify each |
| | | affected TMH | | | | affected TMH |
| | |-------------->| | | |-------------->|
| | | | | | | |
Figure 6 Figure 6: Notification of the Registered Domain Name
Figure 6 depicts the process to notify the TMH of Registered Domain Figure 6 depicts the process to notify the TMH of Registered Domain
Names. Names.
The format used for the LORDN is described in Section 6.3 The format used for the LORDN is described in Section 6.3.
5.2.4. Sunrise Domain Name registration by Registrars 5.2.4. Sunrise Domain Name Registration by Registrars
Registrars MAY choose to perform the checks for verifying DN Registrars MAY choose to perform the checks for verifying DN
registrations as performed by the Registries (see Section 5.2.2) registrations, as performed by the Registries (see Section 5.2.2)
before sending the command to register a DN. before sending the command to register a DN.
5.2.5. TMDB Sunrise Services for Registrars 5.2.5. TMDB Sunrise Services for Registrars
The processes described in Section 5.2.3.1 and Section 5.2.3.2 are The processes described in Sections 5.2.3.1 and 5.2.3.2 are also
also available for Registrars to optionally validate the SMDs available for Registrars to optionally validate the SMDs received.
received.
5.3. Trademark Claims Period 5.3. Trademark Claims Period
5.3.1. Domain Registration 5.3.1. Domain Registration
Domain Name registration during the Trademark Claims Period
.------------. .-----------. .----------. .------. .------------. .-----------. .----------. .------.
| 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 page 24, line 43 skipping to change at line 983
'-( 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 |<---------------------------| |
|<---------------| | | |<---------------| | |
Figure 7 Figure 7: Domain Name Registration during the Trademark Claims Period
Figure 7 represents a synchronous DN registration workflow (usually Figure 7 represents a synchronous DN registration workflow (usually
called first come first served). called first come first served).
5.3.2. Trademark Claims Domain Name registration by Registries 5.3.2. Trademark Claims Domain Name Registration by Registries
During the Trademark Claims Period, Registries perform two main During the Trademark Claims Period, Registries perform two main
functions: functions:
* Registries MUST provide Registrars (over the ry interface, * Registries MUST provide Registrars (over the ry interface; see
Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs Section 4.3.5) the lookup key used to retrieve the TCNs for DNs
that match the DNL List. that match the DNL List.
* Registries MUST provide the Lookup Key only when queried about a * Registries MUST provide the lookup key only when queried about a
specific DN. specific DN.
In the following instances, a minimum set of checks are described:
* For each DN matching a DNL of a PRM, Registries MUST perform a * For each DN matching a DNL of a PRM, Registries MUST perform a
minimum set of checks for verifying DN registrations during the minimum set of checks for verifying DN registrations during the
Trademark Claims Period upon reception of a registration request Trademark Claims Period upon reception of a registration request
over the ry interface (Section 4.3.5). If any of these checks over the ry interface (Section 4.3.5). If any of these checks
fails the Registry MUST abort the registration. Each of these fail, the Registry MUST abort the registration. Each of these
checks MUST be performed before the DN is effectively allocated. checks MUST be performed before the DN is effectively allocated.
* In case of asynchronous registrations (e.g. auctions), the minimum * In case of asynchronous registrations (e.g., auctions), the
set of checks MAY be performed when creating the intermediate minimum set of checks MAY be performed when creating the
object (e.g. a DN application) used for DN effective allocation. intermediate object (e.g., a DN application) used for DN effective
If the minimum set of checks is performed when creating the allocation. If the minimum set of checks is performed when
intermediate object (e.g. a DN application) a Registry MAY creating the intermediate object (e.g., a DN application), a
effectively allocate the DN without performing the minimum set of Registry MAY effectively allocate the DN without performing the
checks again. minimum set of checks again.
* Performing the minimum set of checks Registries MUST verify that: * Performing the minimum set of checks, Registries MUST verify that:
1. The TCNID (<tmNotice:id>), expiration datetime 1. The TCNID (<tmNotice:id>), expiration datetime
(<tmNotice:notAfter>) and acceptance datetime of the TCN, have (<tmNotice:notAfter>), and acceptance datetime of the TCN have
been received from the Registrar along with the DN been received from the Registrar, along with the DN
registration. registration.
If the three elements mentioned above are not provided by If the three elements mentioned above are not provided by the
the Registrar for a DN matching a DNL of a PRM, but the DNL Registrar for a DN matching a DNL of a PRM, but the DNL was
was inserted (or re-inserted) for the first time into DNL inserted (or reinserted) for the first time into the DNL List
List less than 24 hours ago, the registration MAY continue less than 24 hours ago, the registration MAY continue without
without this data and the tests listed below are not this data, and the tests listed below are not required to be
required to be performed. performed.
2. The TCN has not expired (according to the expiration datetime 2. The TCN has not expired (according to the expiration datetime
sent by the Registrar). sent by the Registrar).
3. The acceptance datetime is within the window of time defined 3. The acceptance datetime is within the window of time defined
by ICANN policy. In the gTLD round of 2012, Registrars by ICANN policy. In the gTLD round of 2012, Registrars
verified that the acceptance datetime was less than or equal verified that the acceptance datetime was less than or equal
to 48 hours in the past, as there were no defined ICANN to 48 hours in the past, as there were no defined ICANN
policies at that time. Implementers should be aware that policies at that time. Implementers should be aware that
ICANN policy may define this value in the future. ICANN policy may define this value in the future.
4. Using the leftmost DNL of the DN being effectively allocated, 4. The TCN Checksum is computed using the leftmost DNL of the DN
the expiration datetime provided by the Registrar, and the being effectively allocated, the expiration datetime provided
TMDB Notice Identifier extracted from the TCNID provided by by the Registrar, and the TMDB Notice Identifier extracted
the Registrar compute the TCN Checksum. Verify that the from the TCNID provided by the Registrar. Verify that the
computed TCN Checksum match the TCN Checksum present in the computed TCN Cheksum matches the TCN Checksum present in the
TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
being effectively allocated, the leftmost DNL would be "xn-- being effectively allocated, the leftmost DNL would be "xn--
mgbachtv". mgbachtv".
These procedures apply to all DN registrations at the second level as These procedures apply to all DN registrations at the second level,
well as to all other levels subordinate to the TLD that the Registry as well as to all other levels subordinate to the TLD that the
accepts registrations for. Registry accepts registrations for.
5.3.3. TMBD Trademark Claims Services for Registries 5.3.3. TMDB Trademark Claims Services for Registries
5.3.3.1. Domain Name Label (DNL) List 5.3.3.1. Domain Name Label (DNL) List
A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00
and 12:00:00 UTC. and 12:00:00 UTC.
Registries MUST refresh the latest version of the DNL List at least Registries MUST refresh the latest version of the DNL List at least
once every 24 hours. once every 24 hours.
Update of the DNL List
.----------. .------. .----------. .------.
| 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 |
|<--------------------------------| |<--------------------------------|
| | | |
| | | |
Figure 8 Figure 8: Update of the DNL List
Figure 8 depicts the process of downloading the latest DNL list Figure 8 depicts the process of downloading the latest DNL List
initiated by the Registry. initiated by the Registry.
Note: the DNL List will be the same regardless of the TLD. If a Note: The DNL List will be the same regardless of the TLD. If a
Backend Registry Operator manages the infrastructure of several TLDs, Backend Registry Operator manages the infrastructure of several TLDs,
the Backend Registry Operator could refresh the DNL List once every the Backend Registry Operator could refresh the DNL List once every
24 hours, the DNL List could be used for all the TLDs managed by the 24 hours, and the DNL List could be used for all the TLDs managed by
Backend Registry Operator. the Backend Registry Operator.
5.3.3.2. Notice of Registered Domain Names (NORN) 5.3.3.2. Notice of Registered Domain Names (NORDN)
The NORDN process during the Trademark Claims Period is almost the The NORDN process during the Trademark Claims Period is almost the
same as during Sunrise Period as defined in Section 5.2.3.3 with the same as during the Sunrise Period, as defined in Section 5.2.3.3; the
difference that only registrations subject to a Trademark Claim difference is that only registrations subject to a Trademark Claim
(i.e., at registration time the name appeared in the current DNL List (i.e., at registration time, the name appeared in the current DNL
downloaded by the Registry Operator) are included in the LORDN. List downloaded by the Registry Operator) are included in the LORDN.
5.3.4. Trademark Claims Domain Name registration by Registrars 5.3.4. Trademark Claims Domain Name Registration by Registrars
For each DN matching a DNL of a PRM, Registrars MUST perform the For each DN matching a DNL of a PRM, Registrars MUST perform the
following steps: following steps:
1. Use the Lookup Key received from the Registry to obtain the TCN 1. Use the lookup key received from the Registry to obtain the TCN
from the TMDB using the dr interface (Section 4.3.6) Registrars from the TMDB using the dr interface (Section 4.3.6). Registrars
MUST only query for the Lookup Key of a DN that is available for MUST only query for the lookup key of a DN that is available for
registration. registration.
2. Present the TCN to the Registrant as described in Exhibit A, 2. Present the TCN to the Registrant, as described in Exhibit A of
[RPM-Requirements]. [RPM-Requirements].
3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 3. Ask the Registrant for acknowledgement, i.e., the Registrant MUST
consent with the TCN, before any further processing. (The consent with the TCN, before any further processing. (The
transmission of a TCNID to the Registry over the ry interface, transmission of a TCNID to the Registry over the ry interface
Section 4.3.5 implies that the Registrant has expressed his/her (Section 4.3.5) implies that the Registrant has expressed their
consent with the TCN.) consent with the TCN.)
4. Perform the minimum set of checks for verifying DN registrations. 4. Perform the minimum set of checks for verifying DN registrations.
If any of these checks fails the Registrar MUST abort the DN If any of these checks fail, the Registrar MUST abort the DN
registration. Each of these checks MUST be performed before the registration. Each of these checks MUST be performed before the
registration is sent to the Registry. Performing the minimum set registration is sent to the Registry. Performing the minimum set
of checks Registrars MUST verify that: of checks, Registrars MUST verify the following:
1. The datetime when the validation is done is within the TCN a. The datetime when the validation is done is within the TCN
validity based on the <tmNotice:notBefore> and validity based on the <tmNotice:notBefore> and
<tmNotice:notAfter> elements. <tmNotice:notAfter> elements.
2. The leftmost DNL of the DN being effectively allocated b. The leftmost DNL of the DN being effectively allocated
matches the label (<tmNotice:label>) element in the TCN. For matches the label (<tmNotice:label>) element in the TCN. For
example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being
effectively allocated, the leftmost DNL would be "xn-- effectively allocated, the leftmost DNL would be "xn--
mgbachtv". mgbachtv".
3. The Registrant has acknowledged (expressed his/her consent c. The Registrant has acknowledged (expressed their consent
with) the TCN. with) the TCN.
5. Record the date and time when the registrant acknowledged the 5. Record the date and time when the registrant acknowledged the
TCN. TCN.
6. Send the registration to the Registry (ry interface, 6. Send the registration to the Registry (via the ry interface; see
Section 4.3.5) and include the following information: Section 4.3.5) and include the following information:
* TCNID (<tmNotice:id>) * TCNID (<tmNotice:id>)
* Expiration date of the TCN (<tmNotice:notAfter>) * Expiration date of the TCN (<tmNotice:notAfter>)
* Acceptance datetime of the TCN. * Acceptance datetime of the TCN
Currently TCNs are generated twice a day by the TMDB. The expiration Currently, TCNs are generated twice a day by the TMDB. The
date (<tmNotice:notAfter>) of each TCN MUST be set to a value defined expiration date (<tmNotice:notAfter>) of each TCN MUST be set to a
by ICANN policy. In the gTLD round of 2012, the TMDB set the value defined by ICANN policy. In the gTLD round of 2012, the TMDB
expiration value to 48 hours in to the future as there were no set the expiration value to 48 hours into the future, as there were
defined ICANN policies at that time. Implementers should be aware no defined ICANN policies at that time. Implementers should be aware
that ICANN policy may define this value in the future. that ICANN policy may define this value in the future.
Registrars SHOULD implement a cache of TCNs to minimize the number of Registrars SHOULD implement a cache of TCNs to minimize the number of
queries sent to the TMDB. A cached TCN MUST be removed from the queries sent to the TMDB. A cached TCN MUST be removed from the
cache after the expiration date of the TCN as defined by cache after the expiration date of the TCN, as defined by
<tmNotice:notAfter>. <tmNotice:notAfter>.
The TMDB MAY implement rate-limiting as one of the protection The TMDB MAY implement rate limiting as one of the protection
mechanisms to mitigate the risk of performance degradation. mechanisms to mitigate the risk of performance degradation.
5.3.5. TMBD Trademark Claims Services for Registrars 5.3.5. TMDB Trademark Claims Services for Registrars
5.3.5.1. Claims Notice Information Service (CNIS) 5.3.5.1. Claims Notice Information Service (CNIS)
The TCNs are provided by the TMDB online and are fetched by the The TCNs are provided by the TMDB online and are fetched by the
Registrar via the dr interface (Section 4.3.6). Registrar via the dr interface (Section 4.3.6).
To get access to the TCNs, the Registrar needs the credentials To get access to the TCNs, the Registrar needs the credentials
provided by the TMDB (Section 5.1.2.1) and the Lookup Key received provided by the TMDB (Section 5.1.2.1) and the lookup key received
from the Registry via the ry interface (Section 4.3.5). The dr from the Registry via the ry interface (Section 4.3.5). The dr
interface (Section 4.3.6) uses HTTPS with Basic access interface (Section 4.3.6) uses HTTPS with Basic access
authentication. authentication.
The dr interface (Section 4.3.6) MAY support up to ten (10) The dr interface (Section 4.3.6) MAY support up to ten (10)
concurrent connections from each Registrar. concurrent connections from each Registrar.
The URL of the dr interface (Section 4.3.6) is: The URL of the dr interface (Section 4.3.6) is:
< https://<tmdb-domain-name>/cnis/<lookupkey>.xml > https://<tmdb-domain-name>/cnis/<lookupkey>.xml
Note that the "lookupkey" may contain SLASH characters ("/"). The Note that the "lookupkey" may contain slash characters ("/"). The
SLASH character is part of the URL path and MUST NOT be escaped when slash character is part of the URL path and MUST NOT be escaped when
requesting the TCN. requesting the TCN.
The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6)
MUST be signed by a well-know public CA. Registrars MUST perform the MUST be signed by a well-know public CA. Registrars MUST perform the
Certification Path Validation described in Section 6 of [RFC5280]. certification path validation described in Section 6 of [RFC5280].
Registrars will be authenticated in the dr interface using HTTP Basic Registrars will be authenticated in the dr interface using HTTP Basic
access authentication. The dr (Section 4.3.6) interface MUST support access authentication. The dr interface (Section 4.3.6) MUST support
HTTPS keep-alive and MUST maintain the connection for up to 30 HTTPS keep-alive and MUST maintain the connection for up to 30
minutes. minutes.
5.4. Qualified Launch Program (QLP) Period 5.4. Qualified Launch Program (QLP) Period
5.4.1. Domain Registration 5.4.1. Domain Registration
During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program During the OPTIONAL Qualified Launch Program (QLP) Period (see
(QLP) Period effective allocations of DNs to third parties could [QLP-Addendum]), effective allocations of DNs to third parties could
require that Registries and Registrars provide Sunrise and/or require that Registries and Registrars provide Sunrise and/or
Trademark Claims services. If required, Registries and Registrars Trademark Claims services. If required, Registries and Registrars
MUST provide Sunrise and/or Trademark Claims services as described in MUST provide Sunrise and/or Trademark Claims services, as described
Section 5.2 and Section 5.3. in Sections 5.2 and 5.3.
The effective allocation scenarios are: The effective allocation scenarios are as follows:
* If the leftmost DNL of the DN being effectively allocated (QLP * If the leftmost DNL of the DN being effectively allocated (QLP
Name in this section) matches a DNL in the SURL, and an SMD is Name in this section) matches a DNL in the SURL and an SMD is
provided, then Registries MUST provide Sunrise Services (see provided, then Registries MUST provide Sunrise Services (see
Section 5.2) and the DN MUST be reported in a Sunrise LORDN file Section 5.2), and the DN MUST be reported in a Sunrise LORDN file
during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- during the QLP Period. For example, if the DN "xn--mgbachtv.xn--
mgbh0fb" is being effectively allocated, the leftmost DNL would be mgbh0fb" is being effectively allocated, the leftmost DNL would be
"xn--mgbachtv". "xn--mgbachtv".
* If the QLP Name matches a DNL in the SURL but does not match a DNL * If the QLP Name matches a DNL in the SURL but does not match a DNL
in the DNL List, and an SMD is NOT provided (see section 2.2 of in the DNL List and an SMD is NOT provided (see Section 2.2 of
[QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN
file using the special SMD-id "99999-99999" during the QLP Period. file using the special SMD-id "99999-99999" during the QLP Period.
* If the QLP Name matches a DNL in the SURL and also matches a DNL * 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 in the DNL List and an SMD is NOT provided (see Section 2.2 of
[QLP-Addendum]), then Registries MUST provide Trademark Claims [QLP-Addendum]), then Registries MUST provide Trademark Claims
services (see Section 5.3) and the DN MUST be reported in a services (see Section 5.3), and the DN MUST be reported in a
Trademark Claims LORDN file during the QLP Period. Trademark Claims LORDN file during the QLP Period.
* If the QLP Name matches a DNL in the DNL List but does not match a * If the QLP Name matches a DNL in the DNL List but does not match a
DNL in the SURL, then Registries MUST provide Trademark Claims DNL in the SURL, then Registries MUST provide Trademark Claims
services (see Section 5.2) and the DN MUST be reported in a services (see Section 5.3), and the DN MUST be reported in a
Trademark Claims LORDN file during the QLP Period. Trademark Claims LORDN file during the QLP Period.
The following table lists all the effective allocation scenarios The following table lists all the effective allocation scenarios
during a QLP Period: during a QLP Period:
+========+==========+=================+==============+==============+ +========+==========+=================+==============+==============+
| QLP | QLP | SMD was | Registry | Registry | | QLP | QLP | SMD Was | Registry | Registry |
| Name | Name | provided by the | MUST provide | MUST report | | Name | Name | Provided by the | MUST Provide | MUST Report |
| match | match | potential | Sunrise or | DN | | Match | Match | Potential | Sunrise or | DN |
| in the | in the | Registrant | Trademark | registration | | in the | in the | Registrant | Trademark | Registration |
| SURL | DNL | | Claims | in <type> | | SURL | DNL | | Claims | in <type> |
| | List | | Services | LORDN file | | | List | | Services | LORDN File |
+========+==========+=================+==============+==============+ +========+==========+=================+==============+==============+
| Y | Y | Y | Sunrise | Sunrise | | Y | Y | Y | Sunrise | Sunrise |
+--------+----------+-----------------+--------------+--------------+ +--------+----------+-----------------+--------------+--------------+
| Y | N | Y | Sunrise | Sunrise | | Y | N | Y | Sunrise | Sunrise |
+--------+----------+-----------------+--------------+--------------+ +--------+----------+-----------------+--------------+--------------+
| N | Y | -- | Trademark | Trademark | | N | Y | -- | Trademark | Trademark |
| | | | Claims | Claims | | | | | Claims | Claims |
+--------+----------+-----------------+--------------+--------------+ +--------+----------+-----------------+--------------+--------------+
| N | N | -- | -- | -- | | N | N | -- | -- | -- |
+--------+----------+-----------------+--------------+--------------+ +--------+----------+-----------------+--------------+--------------+
| Y | Y | N (see section | Trademark | Trademark | | Y | Y | N (see | Trademark | Trademark |
| | | 2.2 of | Claims | Claims | | | | Section 2.2 of | Claims | Claims |
| | | [QLP-Addendum]) | | | | | | [QLP-Addendum]) | | |
+--------+----------+-----------------+--------------+--------------+ +--------+----------+-----------------+--------------+--------------+
| Y | N | N (see section | -- | Sunrise | | Y | N | N (see | -- | Sunrise |
| | | 2.2 of | | (using | | | | Section 2.2 of | | (using |
| | | [QLP-Addendum]) | | special SMD- | | | | [QLP-Addendum]) | | special SMD- |
| | | | | id) | | | | | | id) |
+--------+----------+-----------------+--------------+--------------+ +--------+----------+-----------------+--------------+--------------+
Table 1: QLP Effective Allocation Scenarios Table 1: QLP Effective Allocation Scenarios
The TMDB MUST provide the following services to Registries during a The TMDB MUST provide the following services to Registries during a
QLP Period: QLP Period:
* SMD Revocation List (see Section 5.2.3.1) * SMD Revocation List (see Section 5.2.3.1)
* NORN (see Section 5.2.3.3) * NORDN (see Section 5.2.3.3)
* DNL List (see Section 5.3.3.1) * DNL List (see Section 5.3.3.1)
* Sunrise List (SURL) (see Section 5.4.2.1 * Sunrise List (SURL) (see Section 5.4.2.1)
The TMDB MUST provide the following services to Registrars during a The TMDB MUST provide the following services to Registrars during a
QLP Period: QLP Period:
* SMD Revocation List (see Section 5.2.3.1) * SMD Revocation List (see Section 5.2.3.1)
* CNIS (see Section 5.3.5.1) * CNIS (see Section 5.3.5.1)
5.4.2. TMBD QLP Services for Registries 5.4.2. TMDB QLP Services for Registries
5.4.2.1. Sunrise List (SURL) 5.4.2.1. Sunrise List (SURL)
A new Sunrise List (SURL) MUST be published by the TMDB twice a day, A new SURL MUST be published by the TMDB twice a day, by 00:00:00 and
by 00:00:00 and 12:00:00 UTC. 12:00:00 UTC.
Registries offering the OPTIONAL QLP Period MUST refresh the latest Registries offering the OPTIONAL QLP Period MUST refresh the latest
version of the SURL at least once every 24 hours. version of the SURL at least once every 24 hours.
Update of the SURL
.----------. .------. .----------. .------.
| Registry | | TMDB | | Registry | | TMDB |
'----------' '------' '----------' '------'
| | | |
.----------------. | .----------------. |
| Periodically, | | | Periodically, | |
| at least | | | at least | |
| every 24 hours | | | every 24 hours | |
'----------------' | '----------------' |
| | | |
|------------------------------->| |------------------------------->|
| Download the latest SURL | | Download the latest SURL |
|<-------------------------------| |<-------------------------------|
| | | |
| | | |
Figure 9 Figure 9: Update of the SURL
Figure 9 depicts the process of downloading the latest SURL initiated Figure 9 depicts the process of downloading the latest SURL initiated
by the Registry. by the Registry.
Note: the SURL will be the same regardless of the TLD. If a Backend Note: The SURL will be the same regardless of the TLD. If a Backend
Registry Operator manages the infrastructure of several TLDs, the Registry Operator manages the infrastructure of several TLDs, the
Backend Registry Operator could refresh the SURL once every 24 hours, Backend Registry Operator could refresh the SURL once every 24 hours,
the SURL could be used for all the TLDs managed by the Backend and the SURL could be used for all the TLDs managed by the Backend
Registry Operator. Registry Operator.
6. Data Format Descriptions 6. Data Format Descriptions
6.1. Domain Name Label (DNL) List 6.1. Domain Name Label (DNL) List
This section defines the format of the list containing every Domain This section defines the format of the list containing every DNL that
Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list matches a Pre-Registered Mark (PRM). The list is maintained by the
is maintained by the TMDB and downloaded by Registries in regular TMDB and downloaded by Registries in regular intervals (see
intervals (see Section 5.3.3.1). The Registries use the DNL List Section 5.3.3.1). The Registries use the DNL List during the
during the Trademark Claims Period to check whether a requested DN Trademark Claims Period to check whether a requested DN matches a DNL
matches a DNL of a PRM. of a PRM.
The DNL List contains all the DNLs covered by a PRM present in the The DNL List contains all the DNLs covered by a PRM present in the
TMDB at the datetime it is generated. TMDB at the datetime that the DNL List is generated.
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:
* first line: <version>,<DNL List creation datetime> * first line: <version>,<DNL List creation datetime>
Where: Where:
o <version>, version of the file, this field MUST be 1. o <version>: version of the file. This field MUST be 1.
o <DNL List creation datetime>, date and time in UTC that the o <DNL List creation datetime>: date and time in UTC that the
DNL List was created. DNL List was created.
* second line: a header line as specified in [RFC4180] * second line: a header line, as specified in [RFC4180]
With the header names as follows: With the header names as follows:
DNL,lookup-key,insertion-datetime DNL,lookup-key,insertion-datetime
* One or more lines with: <DNL>,<lookup key>,<DNL insertion * One or more lines with: <DNL>,<lookup key>,<DNL insertion
datetime> datetime>
Where: Where:
o <DNL>, a Domain Name Label covered by a PRM. o <DNL>: a Domain Name Label covered by a PRM.
o <lookup key>, lookup key that the Registry MUST provide to o <lookup key>: lookup key that the Registry MUST provide to
the Registrar. The lookup key has the following format: the Registrar. The lookup key has the following format:
<YYYY><MM><DD><vv>/<X>/<X>/<X>/<Random bits><Sequential <YYYY><MM><DD><vv>/<X>/<X>/<X>/<Random bits><Sequential
number>, where: number>, where:
+ YYYY: year that the TCN was generated. + YYYY: year that the TCN was generated.
+ MM: zero-padded month that the TCN was generated. + MM: zero-padded month that the TCN was generated.
+ DD: zero-padded day that the TCN was generated. + DD: zero-padded day that the TCN was generated.
+ vv: version of the TCN, possible values are 00 and 01. + vv: version of the TCN; possible values are 00 and 01.
+ X: one hex character. This is the first, second and + X: one hex character. This is the first, second, and
third hex character of encoding the <Random bits> in third hex character of encoding the <Random bits> in
base16 as specified in [RFC4648]. base16, as specified in [RFC4648].
+ Random bits: 144 random bits encoded in base64url as + Random bits: 144 random bits encoded in base64url, as
specified in [RFC4648]. specified in [RFC4648].
+ Sequential number: zero-padded natural number in the + Sequential number: zero-padded natural number in the
range 0000000001 to 2147483647. range 0000000001 to 2147483647.
o <DNL insertion datetime>, datetime in UTC that the DNL was o <DNL insertion datetime>: datetime in UTC that the DNL was
first inserted into the DNL List. The possible two values 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 of time for inserting a DNL to the DNL List are 00:00:00 and
12:00:00 UTC. 12:00:00 UTC.
Example of a DNL List: Example of a DNL list:
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
Figure 10: Example DNL List
To provide authentication and integrity protection, the DNL List will To provide authentication and integrity protection, the DNL List will
be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The be PGP [RFC4880] signed by the TMDB (see Section 5.1.1.4). The PGP
PGP signature of the DNL List can be found in the similar URI but signature of the DNL List can be found in the similar URI but with
with extension .sig as shown below. extension .sig, as shown below.
The URL of the dy interface (Section 4.3.3) is: The URLs of the dy interface (Section 4.3.3) are:
* < https://<tmdb-domain-name>/dnl/dnl-latest.csv > * https://<tmdb-domain-name>/dnl/dnl-latest.csv
* < https://<tmdb-domain-name>/dnl/dnl-latest.sig > * https://<tmdb-domain-name>/dnl/dnl-latest.sig
6.2. SMD Revocation List 6.2. SMD Revocation List
This section defines the format of the list of SMDs that have been This section defines the format of the list of SMDs that have been
revoked. The list is maintained by the TMDB and downloaded by revoked. The list is maintained by the TMDB and downloaded by
Registries (and optionally by Registrars) in regular intervals (see Registries (and optionally by Registrars) in regular intervals (see
Section 5.2.3.1). The SMD Revocation List is used during the Sunrise Section 5.2.3.1). The SMD Revocation List is used during the Sunrise
Period to validate SMDs received. The SMD Revocation List has a Period to validate SMDs received. The SMD Revocation List has a
similar function as CRLs used in PKI [RFC5280]. similar function as CRLs used in PKI [RFC5280].
The SMD Revocation List contains all the revoked SMDs present in the The SMD Revocation List contains all the revoked SMDs present in the
TMDB at the datetime it is generated. TMDB at the datetime it is generated.
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:
* first line: <version>,<SMD Revocation List creation datetime> * first line: <version>,<SMD Revocation List creation datetime>
Where: Where:
o <version>, version of the file, this field MUST be 1. o <version>: version of the file. This field MUST be 1.
o <SMD Revocation List creation datetime>, datetime in UTC o <SMD Revocation List creation datetime>: datetime in UTC
that the SMD Revocation List was created. that the SMD Revocation List was created.
* second line: a header line as specified in [RFC4180] * second line: a header line, as specified in [RFC4180]
With the header names as follows: With the header names as follows:
smd-id,insertion-datetime smd-id,insertion-datetime
* One or more lines with: <smd-id>,<revoked SMD datetime> * One or more lines with: <smd-id>,<revoked SMD datetime>
Where: Where:
o <smd-id>, identifier of the SMD that was revoked. o <smd-id>: identifier of the SMD that was revoked.
o <revoked SMD datetime>, revocation datetime in UTC of the o <revoked SMD datetime>: revocation datetime in UTC of the
SMD. The possible two values of time for inserting an SMD SMD. The possible two values of time for inserting an SMD
to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. to the SMD Revocation List are 00:00:00 and 12:00:00 UTC.
To provide integrity protection, the SMD Revocation List is PGP To provide integrity protection, the SMD Revocation List is PGP
signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation signed by the TMDB (see Section 5.1.1.4). The SMD Revocation List is
List is provided by the TMDB with extension .csv. The PGP signature provided by the TMDB with extension .csv. The PGP signature of the
of the SMD Revocation List can be found in the similar URI but with SMD Revocation List can be found in the similar URI but with
extension .sig as shown below. extension .sig, as shown below.
The URL of the sr interface (Section 4.3.12) and sy interface The URLs of the sr interface (Section 4.3.12) and sy interface
(Section 4.3.11) is: (Section 4.3.11) are:
* < https://<tmdb-domain-name>/smdrl/smdrl-latest.csv > * https://<tmdb-domain-name>/smdrl/smdrl-latest.csv
* < https://<tmdb-domain-name>/smdrl/smdrl-latest.sig > * https://<tmdb-domain-name>/smdrl/smdrl-latest.sig
Example of an SMD Revocation List: Example of an SMD Revocation List:
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
6.3. List of Registered Domain Names (LORDN) file Figure 11: Example SMD Revocation List
6.3. List of Registered Domain Names (LORDN) File
This section defines the format of the List of Registered Domain This section defines the format of the List of Registered Domain
Names (LORDN), which is maintained by each Registry and uploaded at Names (LORDN), which is maintained by each Registry and uploaded at
least daily to the TMDB. Every time a DN matching a DNL of a PRM least daily to the TMDB. Every time there is a DN matching a DNL of
said DN is added to the LORDN along with further information related a PRM, said DN is added to the LORDN, along with further information
to its registration. related to its registration.
The URIs of the yd interface (Section 4.3.7) used to upload the LORDN The URIs of the yd interface (Section 4.3.7) used to upload the LORDN
file is: file are:
* Sunrise LORDN file: * Sunrise LORDN file:
< https://<tmdb-domain-name>/LORDN/<TLD>/sunrise > https://<tmdb-domain-name>/LORDN/<TLD>/sunrise
* Trademark Claims LORDN file: * Trademark Claims LORDN file:
< https://<tmdb-domain-name>/LORDN/<TLD>/claims > https://<tmdb-domain-name>/LORDN/<TLD>/claims
During a QLP Period, Registries MAY be required to upload Sunrise or During a QLP Period, Registries MAY be required to upload Sunrise or
Trademark Claims LORDN files. The URIs of the yd interface used to Trademark Claims LORDN files. The URIs of the yd interface used to
upload LORDN files during a QLP Period is: upload LORDN files during a QLP Period are:
* Sunrise LORDN file (during QLP Period): * Sunrise LORDN file (during QLP Period):
< https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp > https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp
* Trademark Claims LORDN file (during a QLP Period): * Trademark Claims LORDN file (during a QLP Period):
< https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp > https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp
The yd interface (Section 4.3.7) returns the following HTTP status The yd interface (Section 4.3.7) returns the following HTTP status
codes after a HTTP POST request method is received: codes after an HTTP POST request method is received:
* The interface provides a HTTP/202 status code if the interface was * The interface provides an HTTP/202 status code if the interface
able to receive the LORDN file and the syntax of the LORDN file is was able to receive the LORDN file and the syntax of the LORDN
correct. file is correct.
The interface provides the LORDN Transaction Identifier in the The interface provides the LORDN Transaction Identifier in the
HTTP Entity-body that would be used by the Registry to download HTTP Entity-body that would be used by the Registry to download
the LORDN Log file. The LORDN Transaction Identifier is a the LORDN Log file. The LORDN Transaction Identifier is a zero-
natural number zero-padded in the range 0000000000000000001 to padded natural number in the range 0000000000000000001 to
9223372036854775807. 9223372036854775807.
The TMDB uses the <LORDN creation datetime> element of the The TMDB uses the <LORDN creation datetime> element of the LORDN
LORDN file as a unique client-side identifier. If a LORDN file file as a unique client-side identifier. If a LORDN file with the
with the same <LORDN creation datetime> of a previously sent same <LORDN creation datetime> of a previously sent LORDN file is
LORDN file is received by the TMDB, the LORDN Transaction received by the TMDB, the LORDN Transaction Identifier of the
Identifier of the previously sent LORDN file MUST be provided previously sent LORDN file MUST be provided to the Registry. The
to the Registry. The TMDB MUST ignore the DN Lines present in TMDB MUST ignore the DN Lines present in the LORDN file if a LORDN
the LORDN file if a LORDN file with the same <LORDN creation file with the same <LORDN creation datetime> was previously sent.
datetime> was previously sent.
The HTTP Location header field contains the URI where the LORDN The HTTP Location header field contains the URI where the LORDN
Log file could be retrieved later, for example: Log file could be retrieved later, for example:
202 Accepted 202 Accepted
Location: https://<tmdb-domain- Location: https://<tmdb-domain-
name>/LORDN/example/sunrise/0000000000000000001/result name>/LORDN/example/sunrise/0000000000000000001/result
* The interface provides a HTTP/400 if the request is incorrect or * The interface provides an HTTP/400 if the request is incorrect or
the syntax of the LORDN file is incorrect. The TMDB MUST return a the syntax of the LORDN file is incorrect. The TMDB MUST return a
human readable message in the HTTP Entity-body regarding the human-readable message in the HTTP Entity-body regarding the
incorrect syntax of the LORDN file. incorrect syntax of the LORDN file.
* The interface provides a HTTP/401 status code if the credentials * The interface provides an HTTP/401 status code if the credentials
provided does not authorize the Registry Operator to upload a provided do not authorize the Registry Operator to upload a LORDN
LORDN file. file.
* The TMDB MUST return a HTTP/404 status code when trying to upload * The TMDB MUST return an HTTP/404 status code when trying to upload
a LORDN file using the https://<tmdb-domain- a LORDN file using the https://<tmdb-domain-
name>/LORDN/<TLD>/sunrise/qlp or https://<tmdb-domain- name>/LORDN/<TLD>/sunrise/qlp or https://<tmdb-domain-
name>/LORDN/<TLD>/claims/qlp interface outside of a QLP Period name>/LORDN/<TLD>/claims/qlp interface outside of a QLP Period
plus 26 hours. plus 26 hours.
* The interface provides a HTTP/500 status code if the system is * The interface provides an HTTP/500 status code if the system is
experiencing a general failure. experiencing a general failure.
For example, to upload the Sunrise LORDN file for TLD "example", the For example, to upload the Sunrise LORDN file for TLD "example", the
URI would be: URI would be:
< https://<tmdb-domain-name>/LORDN/example/sunrise > https://<tmdb-domain-name>/LORDN/example/sunrise
The LORDN is contained in a CSV formatted file that has the following The LORDN is contained in a CSV-formatted file that has the following
structure: structure:
* For Sunrise Period: * For Sunrise Period:
- first line: <version>,<LORDN creation datetime>,<Number of DN - first line: <version>,<LORDN creation datetime>,<Number of DN
Lines> Lines>
Where: Where:
+ <version>, version of the file, this field MUST be 1. + <version>: version of the file. This field MUST be 1.
+ <LORDN creation datetime>, date and time in UTC that the + <LORDN creation datetime>: date and time in UTC that the
LORDN was created. LORDN was created.
+ <Number of DN Lines>, number of DN Lines present in the + <Number of DN Lines>: number of DN Lines present in the
LORDN file. LORDN file.
- second line: a header line as specified in [RFC4180] - second line: a header line, as specified in [RFC4180]
With the header names as follows: With the header names as follows:
roid,domain-name,SMD-id,registrar-id,registration- roid,domain-name,SMD-id,registrar-id,registration-
datetime,application-datetime datetime,application-datetime
- One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA - One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA
Registrar id>,<datetime of registration>,<datetime of Registrar id>,<datetime of registration>,<datetime of
application creation> application creation>
Where: Where:
+ <roid>, DN Repository Object IDentifier (DNROID) in the + <roid>: DN Repository Object IDentifier (DNROID) in the
SRS. SRS.
+ <DN registered>, DN that was effectively allocated. For + <DN registered>: DN that was effectively allocated. For
IDNs, the A-label form is used. IDNs, the A-label form is used.
+ <SMD-id>, SMD ID used for registration. + <SMD-id>: SMD ID used for registration.
+ <IANA Registrar ID>, IANA Registrar ID. + <IANA Registrar ID>: IANA Registrar ID.
+ <datetime of registration>, date and time in UTC that the + <datetime of registration>: date and time in UTC that the
domain was effectively allocated. domain was effectively allocated.
+ OPTIONAL <datetime of application creation>, date and + OPTIONAL <datetime of application creation>: date and
time in UTC that the application was created. The time in UTC that the application was created. The
<datetime of application creation> MUST be provided in <datetime of application creation> MUST be provided in
case of a DN effective allocation based on an case of a DN effective allocation based on an
asynchronous registration (e.g., when using auctions). asynchronous registration (e.g., when using auctions).
Example of a Sunrise LORDN file: Example of a Sunrise LORDN file:
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
* For Trademark Claims Period: Figure 12: Example Sunrise LORDN File
* For the Trademark Claims Period:
- first line: <version>,<LORDN creation datetime>,<Number of DN - first line: <version>,<LORDN creation datetime>,<Number of DN
Lines> Lines>
Where: Where:
+ <version>, version of the file, this field MUST be 1. + <version>: version of the file. This field MUST be 1.
+ <LORDN creation datetime>, date and time in UTC that the + <LORDN creation datetime>: date and time in UTC that the
LORDN was created. LORDN was created.
+ <Number of DN Lines>, number of DN Lines present in the + <Number of DN Lines>: number of DN Lines present in the
LORDN file. LORDN file.
- second line: a header line as specified in [RFC4180] - second line: a header line, as specified in [RFC4180]
With the header names as follows: With the header names as follows:
roid,domain-name,notice-id,registrar-id,registration- roid,domain-name,notice-id,registrar-id,registration-
datetime,ack-datetime,application-datetime datetime,ack-datetime,application-datetime
- One or more lines with: <roid>,<DN registered>,<TCNID>,<IANA - One or more lines with: <roid>,<DN registered>,<TCNID>,<IANA
Registrar id>,<datetime of registration>,<datetime of Registrar id>,<datetime of registration>,<datetime of
acceptance of the TCN>,<datetime of application creation> acceptance of the TCN>,<datetime of application creation>
Where: Where:
+ <roid>, DN Repository Object IDentifier (DNROID) in the + <roid>: DNROID in the SRS.
SRS.
+ <DN registered>, DN that was effectively allocated. For + <DN registered>: DN that was effectively allocated. For
IDNs, the A-label form is used. IDNs, the A-label form is used.
+ <TCNID>, Trademark Claims Notice Identifier as specified + <TCNID>: Trademark Claims Notice Identifier, as specified
in <tmNotice:id>. in <tmNotice:id>.
+ <IANA Registrar ID>, IANA Registrar ID. + <IANA Registrar ID>: IANA Registrar ID.
+ <datetime of registration>, date and time in UTC that the + <datetime of registration>: date and time in UTC that the
domain was effectively allocated. domain was effectively allocated.
+ <datetime of acceptance of the TCN>, date and time in UTC + <datetime of acceptance of the TCN>: date and time in UTC
that the TCN was acknowledged. that the TCN was acknowledged.
+ OPTIONAL <datetime of application creation>, date and + OPTIONAL <datetime of application creation>: date and
time in UTC that the application was created. The time in UTC that the application was created. The
<datetime of application creation> MUST be provided in <datetime of application creation> MUST be provided in
case of a DN effective allocation based on an case of a DN effective allocation based on an
asynchronous registration (e.g., when using auctions). asynchronous registration (e.g., when using auctions).
For a DN matching a DNL of a PRM at the moment of For a DN matching a DNL of a PRM at the moment of
registration, created without the TCNID, expiration datetime registration, created without the TCNID, expiration
and acceptance datetime, because DNL was inserted (or re- datetime, and acceptance datetime because DNL was inserted
inserted) for the first time into DNL List less than 24 (or reinserted) for the first time into a DNL List less than
hours ago, the string "recent-dnl-insertion" MAY be 24 hours ago, the string "recent-dnl-insertion" MAY be
specified in <TCNID> and <datetime of acceptance of the specified in <TCNID> and <datetime of acceptance of the
TCN>. TCN>.
Example of a Trademark Claims LORDN file: Example of a Trademark Claims LORDN file:
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
6.3.1. LORDN Log file Figure 13: Example Trademark Claims LORDN File
6.3.1. LORDN Log File
After reception of the LORDN file, the TMDB verifies its content for After reception of the LORDN file, the TMDB verifies its content for
syntactical and semantical correctness. The output of the LORDN file syntactical and semantic correctness. The output of the LORDN file
verification is retrieved using the yd interface (Section 4.3.7). verification is retrieved using the yd interface (Section 4.3.7).
The URI of the yd interface (Section 4.3.7) used to retrieve the The URIs of the yd interface (Section 4.3.7) used to retrieve the
LORDN Log file is: LORDN Log file are:
* Sunrise LORDN Log file: * Sunrise LORDN Log file:
< https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/<lordn- https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/<lordn-transaction-
transaction-identifier>/result > identifier>/result
* Trademark Claims LORDN Log file: * Trademark Claims LORDN Log file:
< https://<tmdb-domain-name>/LORDN/<TLD>/claims/<lordn- https://<tmdb-domain-name>/LORDN/<TLD>/claims/<lordn-transaction-
transaction-identifier>/result > identifier>/result
A Registry Operator MUST NOT send more than one request per minute A Registry Operator MUST NOT send more than one request per minute
per TLD to download a LORDN Log file. per TLD to download a LORDN Log file.
The yd interface (Section 4.3.7) returns the following HTTP status The yd interface (Section 4.3.7) returns the following HTTP status
codes after a HTTP GET request method is received: codes after an HTTP GET request method is received:
* The interface provides a HTTP/200 status code if the interface was * The interface provides an HTTP/200 status code if the interface
able to provide the LORDN Log file. The LORDN Log file is was able to provide the LORDN Log file. The LORDN Log file is
contained in the HTTP Entity-body. contained in the HTTP Entity-body.
* The interface provides a HTTP/204 status code if the LORDN * The interface provides an HTTP/204 status code if the LORDN
Transaction Identifier is correct, but the server has not Transaction Identifier is correct but the server has not finalized
finalized processing the LORDN file. processing the LORDN file.
* The interface provides a HTTP/400 status code if the request is * The interface provides an HTTP/400 status code if the request is
incorrect. incorrect.
* The interface provides a HTTP/401 status code if the credentials * The interface provides an HTTP/401 status code if the credentials
provided does not authorize the Registry Operator to download the provided do not authorize the Registry Operator to download the
LORDN Log file. LORDN Log file.
* The interface provides a HTTP/404 status code if the LORDN * The interface provides an HTTP/404 status code if the LORDN
Transaction Identifier is incorrect. Transaction Identifier is incorrect.
* The interface provides a HTTP/500 status code if the system is * The interface provides an HTTP/500 status code if the system is
experiencing a general failure. experiencing a general failure.
For example, to obtain the LORDN Log file in case of a Sunrise LORDN For example, to obtain the LORDN Log file in case of a Sunrise LORDN
file with LORDN Transaction Identifier 0000000000000000001 and TLD file with LORDN Transaction Identifier 0000000000000000001 and TLD
"example" the URI would be: "example", the URI would be:
< https://<tmdb-domain- https://<tmdb-domain-
name>/LORDN/example/sunrise/0000000000000000001/result > name>/LORDN/example/sunrise/0000000000000000001/result
The LORDN Log file is contained in a CSV formatted file that has the The LORDN Log file is contained in a CSV-formatted file that has the
following structure: following structure:
* first line: <version>,<LORDN Log creation datetime>,<LORDN file * first line: <version>,<LORDN Log creation datetime>,<LORDN file
creation datetime>,<LORDN Log Identifier>,<Status flag>,<Warning creation datetime>,<LORDN Log Identifier>,<Status flag>,<Warning
flag>,<Number of DN Lines> flag>,<Number of DN Lines>
Where: Where:
o <version>, version of the file, this field MUST be 1. o <version>: version of the file. This field MUST be 1.
o <LORDN Log creation datetime>, date and time in UTC that the o <LORDN Log creation datetime>: date and time in UTC that the
LORDN Log was created. LORDN Log was created.
o <LORDN file creation datetime>, date and time in UTC of o <LORDN file creation datetime>: date and time in UTC of
creation for the LORDN file that this log file is referring creation for the LORDN file that this log file is referring
to. to.
o <LORDN Log Identifier>, unique identifier of the LORDN Log o <LORDN Log Identifier>: unique identifier of the LORDN Log
provided by the TMDB. This identifier could be used by the provided by the TMDB. This identifier could be used by the
Registry Operator to unequivocally identify the LORDN Log. Registry Operator to unequivocally identify the LORDN Log.
The identified will be a string of a maximum LENGTH of 60 The identified will be a string of a maximum length of 60
characters from the Base 64 alphabet. characters from the base64 alphabet.
o <Status flag>, whether the LORDN file has been accepted for o <Status flag>: whether the LORDN file has been accepted for
processing by the TMDB. Possible values are "accepted" or processing by the TMDB. Possible values are "accepted" or
"rejected". "rejected".
o <Warning flag>, whether the LORDN Log has any warning result o <Warning flag>: whether the LORDN Log has any warning result
codes. Possible values are "no-warnings" or "warnings- codes. Possible values are "no-warnings" or "warnings-
present". present".
o <Number of DN Lines>, number of DNs effective allocations o <Number of DN Lines>: number of DN effective allocations
processed in the LORDN file. processed in the LORDN file.
A Registry Operator is not required to process a LORDN Log with A Registry Operator is not required to process a LORDN Log with
a <Status flag>="accepted" and <Warning flag>="no-warnings". <Status flag>="accepted" and <Warning flag>="no-warnings".
* second line: a header line as specified in [RFC4180] * second line: a header line, as specified in [RFC4180]
With the header names as follows: With the header names as follows:
roid,result-code roid,result-code
* One or more lines with: <roid>,<result code> * One or more lines with: <roid>,<result code>
Where: Where:
o <roid>, DN Repository Object IDentifier (DNROID) in the SRS. o <roid>: DNROID in the SRS.
o <result code>, result code as described in Section 6.3.1.1. o <result code>: result code, as described in Section 6.3.1.1.
Example of a LORDN Log file: Example of a LORDN Log file:
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
Figure 14: Example LORDN Log File
6.3.1.1. LORDN Log Result Codes 6.3.1.1. LORDN Log Result Codes
The classes of result codes (rc) are listed below. Those classes in The classes of result codes (rc) are listed below. The classes in
square brackets are not used at this time, but may come into use at square brackets are not used at this time but may come into use at
some later stage. The first two digits of a result code denote the some later stage. The first two digits of a result code denote the
result code class, which defines the outcome at the TMDB: result code class, which defines the outcome at the TMDB:
* ok: Success, DN Line accepted by the TMDB. * ok: Success. The DN Line is accepted by the TMDB.
* warn: a warning is issued, DN Line accepted by the TMDB. * warn: A warning is issued. The DN Line is accepted by the TMDB.
* err: an error is issued, LORDN file rejected by the TMDB. * err: An error is issued. The LORDN file is rejected by the TMDB.
In case that after processing a DN Line, the error result code is In cases where a DN line is processed and the error result code is
45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 45xx or 46xx, the LORDN file MUST be rejected by the TMDB. If the
TMDB. If the LORDN file is rejected, DN Lines that are syntactically LORDN file is rejected, DN Lines that are syntactically valid will be
valid will be reported with a 2001 result code. A 2001 result code reported with a 2001 result code. A 2001 result code means that the
means that the DN Line is syntactically valid, however the DN Line DN Line is syntactically valid; however, the DN Line was not
was not processed because the LORDN file was rejected. All DNs processed because the LORDN file was rejected. All DNs reported in a
reported in a rejected LORDN file MUST be reported again by the rejected LORDN file MUST be reported again by the Registry because
Registry because none of the DN Lines present in the LORDN file have none of the DN Lines present in the LORDN file have been processed by
been processed by the TMDB. the TMDB.
LORDN Log Result Code Classes: LORDN Log Result Code Classes:
code Class outcome +======+============================+=========+
---- ----- ------- | Code | Class | Outcome |
+======+============================+=========+
20xx Success ok | 20xx | Success | ok |
+------+----------------------------+---------+
35xx [ DN Line syntax warning ] warn | 35xx | [ DN Line syntax warning ] | warn |
36xx DN Line semantic warning warn +------+----------------------------+---------+
| 36xx | DN Line semantic warning | warn |
45xx DN Line syntax error err +------+----------------------------+---------+
46xx DN Line semantic error err | 45xx | DN Line syntax error | err |
+------+----------------------------+---------+
In the following, the LORDN Log result codes used by the TMDB are | 46xx | DN Line semantic error | err |
described: +------+----------------------------+---------+
LORDN Log Result Codes:
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 Table 2: LORDN Log Result Code Classes
The <datetime of application creation> in the DN Line is later
than the <datetime of registration>.
4609 TCNID wrong syntax In Table 3, the LORDN Log result codes used by the TMDB are
The syntax of the TCNID is invalid. described.
4610 TCN Acceptance Date is in the future +======+===================================================+
The <datetime of acceptance of the TCN> is in the future. | rc | Short Description / Long Description |
+======+===================================================+
| 2000 | OK |
| +---------------------------------------------------+
| | The DN Line is successfully processed. |
+------+---------------------------------------------------+
| 2001 | OK but not processed |
| +---------------------------------------------------+
| | The DN Line is syntactically correct but was not |
| | processed because the LORDN file was rejected. |
+------+---------------------------------------------------+
| 3601 | TCN Acceptance Date after Registration Date |
| +---------------------------------------------------+
| | The TCN Acceptance Date in the DN Line is newer |
| | than the registration date. |
+------+---------------------------------------------------+
| 3602 | Duplicate DN Line |
| +---------------------------------------------------+
| | This DN Line is an exact duplicate of another DN |
| | Line in the same file; the DN Line is ignored. |
+------+---------------------------------------------------+
| 3603 | DNROID Notified Earlier |
| +---------------------------------------------------+
| | The same DNROID has been notified earlier; the DN |
| | Line is ignored. |
+------+---------------------------------------------------+
| 3604 | TCN Checksum invalid |
| +---------------------------------------------------+
| | Based on the DN effective allocation, 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 refers |
| | to the <datetime of application creation>. |
+------+---------------------------------------------------+
| 3610 | DN reported outside of the time window |
| +---------------------------------------------------+
| | The DN was reported outside of the required |
| | 26-hour 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 Signed Mark Data Identifier (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 Trademark Claims Notice Identifier (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 the 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 |
| +---------------------------------------------------+
| | The Registrar ID in the 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 |
| +---------------------------------------------------+
| | There is a syntax error in the 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 |
| +---------------------------------------------------+
| | The Registrar ID in the 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 Periods |
| +---------------------------------------------------+
| | 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. |
+------+---------------------------------------------------+
4611 Label has never existed in the TMDB Table 3: LORDN Log Result Codes
The label in the registered DN has never existed in the TMDB.
6.4. Signed Mark Data (SMD) File 6.4. Signed Mark Data (SMD) File
This section defines the format of the Signed Mark Data (SMD) File. This section defines the format of the SMD File. After a successful
After a successful registration of a mark, the TMV returns an SMD registration of a mark, the TMV returns an SMD File to the TMH. The
File to the TMH. The SMD File can then be used for registration of SMD File can then be used for registration of one or more DNs covered
one or more DNs covered by the PRM during the Sunrise Period of a by the PRM during the Sunrise Period of a TLD.
TLD.
Two encapsulation boundaries are defined for delimiting the Two encapsulation boundaries are defined for delimiting the
encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" encapsulated base64-encoded SMD: "-----BEGIN ENCODED SMD-----" and "
and "-----END ENCODED SMD-----". Only data inside the encapsulation -----END ENCODED SMD-----". Only data inside the encapsulation
boundaries MUST be used by Registries and Registrars for validation boundaries MUST be used by Registries and Registrars for validation
purposes, i.e. any data outside these boundaries as well as the purposes, i.e., any data outside these boundaries as well as the
boundaries themselves MUST be ignored for validation purposes. boundaries themselves MUST be ignored for validation purposes.
The structure of the SMD File is as follows, all the elements are The structure of the SMD File is as follows. All the elements are
REQUIRED, and MUST appear in the specified order. REQUIRED and MUST appear in the specified order.
1. Marks: <marks> 1. Marks: <marks>
2. smdID: <SMD-ID> 2. smdID: <SMD-ID>
3. U-labels: <comma separated list of U-label or NR-LDH labels (see 3. U-labels: <comma separated list of U-label or NR-LDH labels (see
[RFC5890])> [RFC5890])>
4. notBefore: <begin validity> 4. notBefore: <begin validity>
5. notAfter: <end validity> 5. notAfter: <end validity>
6. -----BEGIN ENCODED SMD----- 6. -----BEGIN ENCODED SMD-----
7. <encoded SMD (see [RFC7848])> 7. <encoded SMD (see [RFC7848])>
8. -----END ENCODED SMD----- 8. -----END ENCODED SMD-----
Example of an SMD File: Example of an SMD file:
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-----
Figure 15: Example SMD File
6.5. Trademark Claims Notice (TCN) 6.5. Trademark Claims Notice (TCN)
The TMDB MUST provide the TCN to Registrars in XML format as The TMDB MUST provide the TCN to Registrars in XML format, as
specified below. specified below.
An enclosing element <tmNotice:notice> that describes the Trademark The enclosing element <tmNotice:notice> describes the Trademark
Notice to a given label. Notice to a given label.
The child elements of the <tmNotice:notice> element include: The child elements of the <tmNotice:notice> element include:
* A <tmNotice:id> element that contains the unique identifier of the * A <tmNotice:id> element that contains the unique identifier of the
Trademark Notice. This element contains the the TCNID. Trademark Notice. This element contains the TCNID.
The TCNID is a string concatenation of a TCN Checksum and the The TCNID is a string concatenation of a TCN Checksum and the
TMDB Notice Identifier. The first 8 characters of the TCNID is TMDB Notice Identifier. The first 8 characters of the TCNID is
a TCN Checksum. The rest is the TMDB Notice Identifier, which a TCN Checksum. The rest is the TMDB Notice Identifier, which
is a zero-padded natural number in the range of is a zero-padded natural number in the range of
0000000000000000001 to 9223372036854775807. 0000000000000000001 to 9223372036854775807.
Example of a TCNID: Example of a TCNID:
370d0b7c9223372036854775807. 370d0b7c9223372036854775807.
Where: Where:
o TCN Checksum=370d0b7c o TCN Checksum=370d0b7c
o TMDB Notice Identifier=9223372036854775807 o TMDB Notice Identifier=9223372036854775807
The TCN Checksum is a 8 characters long Base16 encoded output The TCN Checksum is an 8-character-long base16-encoded output
of computing the CRC32 of the string concatenation of: label + of computing the CRC32 of the string concatenation of: label +
unix_timestamp(<tmNotice:notAfter>) + TMDB Notice Identifier unix_timestamp(<tmNotice:notAfter>) + TMDB Notice Identifier.
TMDB MUST use the Unix time conversion of the
The TMDB MUST use the Unix time conversion of the
<tmNotice:notAfter> in UTC to calculate the TCN Checksum. Unix <tmNotice:notAfter> in UTC to calculate the TCN Checksum. Unix
time is defined as the number of seconds that have elapsed time is defined as the number of seconds that have elapsed
since 1970-01-01T00:00:00Z not counting leap seconds. For since 1970-01-01T00:00:00Z, not counting leap seconds. For
example, the conversion to Unix time of 2010-08-16T09:00:00.0Z example, the conversion of 2010-08-16T09:00:00.0Z to Unix time
is shown: is:
unix_time(2010-08-16T09:00:00.0Z)=1281949200 unix_time(2010-08-16T09:00:00.0Z)=1281949200
The TMDB uses the <tmNotice:label> and <tmNotice:notAfter> The TMDB uses the <tmNotice:label> and <tmNotice:notAfter>
elements from the TCN along with the TMDB Notice Identifier to elements from the TCN along with the TMDB Notice Identifier to
compute the TCN Checksum. compute the TCN Checksum.
A Registry MUST use the leftmost DNL of the DN being A Registry MUST use the leftmost DNL of the DN being
effectively allocated, the expiration datetime of the TCN effectively allocated, the expiration datetime of the TCN
(provided by the Registrar) and the TMDB Notice Identifier (provided by the Registrar), and the TMDB Notice Identifier
extracted from the TCNID (provided by the Registrar) to compute extracted from the TCNID (provided by the Registrar) to compute
the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- the TCN Checksum. For example, if the DN "xn--mgbachtv.xn--
mgbh0fb" is being effectively allocated, the leftmost DNL would mgbh0fb" is being effectively allocated, the leftmost DNL would
be "xn--mgbachtv". be "xn--mgbachtv".
Example of computation of the TCN Checksum: An example computation of the TCN Checksum is:
CRC32(example-one12819492009223372036854775807)=370d0b7c CRC32(example-one12819492009223372036854775807)=370d0b7c
* A <tmNotice:notBefore> element that contains the start of the * A <tmNotice:notBefore> element that contains the start of the
validity date and time of the TCN. valid date and time of the TCN.
* A <tmNotice:notAfter> element that contains the expiration date * A <tmNotice:notAfter> element that contains the expiration date
and time of the TCN. and time of the TCN.
* A <tmNotice:label> element that contains the DNL covered by a PRM. * A <tmNotice:label> element that contains the DNL covered by a PRM.
* One or more <tmNotice:claim> elements that contain the Trademark * One or more <tmNotice:claim> elements that contain the Trademark
Claim. The <tmNotice:claim> element contains the following child Claims. The <tmNotice:claim> element contains the following child
elements: elements:
- A <tmNotice:markName> element that contains the mark text - A <tmNotice:markName> element that contains the mark text
string. string.
- One or more <tmNotice:holder> elements that contains the - One or more <tmNotice:holder> elements that contain the
information of the holder of the mark. An "entitlement" information of the holder of the mark. An "entitlement"
attribute is used to identify the entitlement of the holder, attribute is used to identify the entitlement of the holder;
possible values are: owner, assignee or licensee. The child possible values are: owner, assignee, or licensee. The child
elements of <tmNotice:holder> include: elements of <tmNotice:holder> include:
o An OPTIONAL <tmNotice:name> element that contains the name o An OPTIONAL <tmNotice:name> element that contains the name
of the holder. A <tmNotice:name> MUST be specified if of the holder. <tmNotice:name> MUST be specified if
<tmNotice:org> is not specified. <tmNotice:org> is not specified.
o An OPTIONAL <tmNotice:org> element that contains the name of o An OPTIONAL <tmNotice:org> element that contains the name of
the organization holder of the mark. A <tmNotice:org> MUST the organization holder of the mark. <tmNotice:org> MUST be
be specified if <tmNotice:name> is not specified. specified if <tmNotice:name> is not specified.
o A <tmNotice:addr> element that contains the address o A <tmNotice:addr> element that contains the address
information of the holder of a mark. A <tmNotice:addr> information of the holder of a mark. <tmNotice:addr>
contains the following child elements: contains the following child elements:
+ One, two or three OPTIONAL <tmNotice:street> elements + One, two, or three OPTIONAL <tmNotice:street> elements
that contains the organization's street address. that contain the organization's street address.
+ A <tmNotice:city> element that contains the + A <tmNotice:city> element that contains the
organization's city. organization's city.
+ An OPTIONAL <tmNotice:sp> element that contains the + An OPTIONAL <tmNotice:sp> element that contains the
organization's state or province. organization's state or province.
+ An OPTIONAL <tmNotice:pc> element that contains the + An OPTIONAL <tmNotice:pc> element that contains the
organization's postal code. organization's postal code.
skipping to change at page 49, line 42 skipping to change at line 2182
o An OPTIONAL <tmNotice:voice> element that contains the o An OPTIONAL <tmNotice:voice> element that contains the
organization's voice telephone number. organization's voice telephone number.
o An OPTIONAL <tmNotice:fax> element that contains the o An OPTIONAL <tmNotice:fax> element that contains the
organization's facsimile telephone number. organization's facsimile telephone number.
o An OPTIONAL <tmNotice:email> element that contains the email o An OPTIONAL <tmNotice:email> element that contains the email
address of the holder. address of the holder.
- Zero or more OPTIONAL <tmNotice:contact> elements that contains - Zero or more OPTIONAL <tmNotice:contact> elements that contain
the information of the representative of the mark registration. the information of the representative of the mark registration.
A "type" attribute is used to identify the type of contact, A "type" attribute is used to identify the type of contact;
possible values are: owner, agent or thirdparty. The child possible values are: owner, agent, or third party. The child
elements of <tmNotice:contact> include: elements of <tmNotice:contact> include:
o A <tmNotice:name> element that contains name of the o A <tmNotice:name> element that contains the name of the
responsible person. responsible person.
o An OPTIONAL <tmNotice:org> element that contains the name of o An OPTIONAL <tmNotice:org> element that contains the name of
the organization of the contact. the organization of the contact.
o A <tmNotice:addr> element that contains the address o A <tmNotice:addr> element that contains the address
information of the contact. A <tmNotice:addr> contains the information of the contact. <tmNotice:addr> contains the
following child elements: following child elements:
+ One, two or three OPTIONAL <tmNotice:street> elements + One, two, or three OPTIONAL <tmNotice:street> elements
that contains the contact's street address. that contain the contact's street address.
+ A <tmNotice:city> element that contains the contact's + A <tmNotice:city> element that contains the contact's
city. city.
+ An OPTIONAL <tmNotice:sp> element that contains the + An OPTIONAL <tmNotice:sp> element that contains the
contact's state or province. contact's state or province.
+ An OPTIONAL <tmNotice:pc> element that contains the + An OPTIONAL <tmNotice:pc> element that contains the
contact's postal code. contact's postal code.
skipping to change at page 50, line 40 skipping to change at line 2229
o A <tmNotice:email> element that contains the contact's email o A <tmNotice:email> element that contains the contact's email
address. address.
- A <tmNotice:jurDesc> element that contains the name (in - A <tmNotice:jurDesc> element that contains the name (in
English) of the jurisdiction where the mark is protected. A English) of the jurisdiction where the mark is protected. A
jurCC attribute contains the two-character code of the jurCC attribute contains the two-character code of the
jurisdiction where the mark was registered. This is a two- jurisdiction where the mark was registered. This is a two-
character code from [WIPO.ST3]. character code from [WIPO.ST3].
- Zero or more OPTIONAL <tmNotice:classDesc> element that - Zero or more OPTIONAL <tmNotice:classDesc> elements that
contains the description (in English) of the Nice contain the description (in English) of the Nice
Classification as defined in [WIPO-NICE-CLASSES]. A classNum Classification, as defined in [WIPO-NICE-CLASSES]. A classNum
attribute contains the class number. attribute contains the class number.
- A <tmNotice:goodsAndServices> element that contains the full - A <tmNotice:goodsAndServices> element that contains the full
description of the goods and services mentioned in the mark description of the goods and services mentioned in the mark
registration document. registration document.
- An OPTIONAL <tmNotice:notExactMatch> element signals that the - An OPTIONAL <tmNotice:notExactMatch> element signals that the
claim notice was added to the TCN based on other rule (e.g. claim notice was added to the TCN based on rules (e.g.,
[Claims50] ) than exact match (defined in [MatchingRules]). [Claims50]) other than exact match (defined in
The <tmNotice:notExactMatch> contains one or more: [MatchingRules]). <tmNotice:notExactMatch> contains one or
more of the following:
o An OPTIONAL <tmNotice:udrp> element that signals that the o An OPTIONAL <tmNotice:udrp> element that signals that the
claim notice was added because of a previously abused name claim notice was added because of a previously abused name
included in an UDRP case. The <tmNotice:udrp> contains: included in a Uniform Domain-Name Dispute-Resolution Policy
(UDRP) case. <tmNotice:udrp> contains:
+ A <tmNotice:caseNo> element that contains the UDRP case + A <tmNotice:caseNo> element that contains the UDRP case
number used to validate the previously abused name. number used to validate the previously abused name.
+ A <tmNotice:udrpProvider> element that contains the name + A <tmNotice:udrpProvider> element that contains the name
of the UDRP provider. of the UDRP provider.
o An OPTIONAL <tmNotice:court> element that signals that the o An OPTIONAL <tmNotice:court> element that signals that the
claim notice was added because of a previously abused name claim notice was added because of a previously abused name
included in a court's resolution. The <tmNotice:court> included in a court's resolution. <tmNotice:court> contains:
contains:
+ A <tmNotice:refNum> element that contains the reference + A <tmNotice:refNum> element that contains the reference
number of the court's resolution used to validate the number of the court's resolution used to validate the
previously abused name. previously abused name.
+ A <tmNotice:cc> element that contains the two-character + A <tmNotice:cc> element that contains the two-character
code from [ISO3166-2] of the jurisdiction of the court. code from [ISO3166-2] of the jurisdiction of the court.
+ A <tmNotice:courtName> element that contains the name of + A <tmNotice:courtName> element that contains the name of
the court. the court.
Example of a <tmNotice:notice> object: Example of a <tmNotice:notice> object:
<?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:claim>
<tmNotice:markName>Example One</tmNotice:markName> <tmNotice:markName>Example One</tmNotice:markName>
<tmNotice:holder entitlement="owner"> <tmNotice:holder entitlement="owner">
<tmNotice:org>Example Inc.</tmNotice:org> <tmNotice:org>Example Inc.</tmNotice:org>
<tmNotice:addr> <tmNotice:addr>
<tmNotice:street>123 Example Dr.</tmNotice:street> <tmNotice:street>123 Example Dr.</tmNotice:street>
<tmNotice:street>Suite 100</tmNotice:street> <tmNotice:street>Suite 100</tmNotice:street>
<tmNotice:city>Reston</tmNotice:city> <tmNotice:city>Reston</tmNotice:city>
<tmNotice:sp>VA</tmNotice:sp> <tmNotice:sp>VA</tmNotice:sp>
<tmNotice:pc>20190</tmNotice:pc> <tmNotice:pc>20190</tmNotice:pc>
<tmNotice:cc>US</tmNotice:cc> <tmNotice:cc>US</tmNotice:cc>
</tmNotice:addr> </tmNotice:addr>
</tmNotice:holder> </tmNotice:holder>
<tmNotice:contact type="owner"> <tmNotice:contact type="owner">
<tmNotice:name>Joe Doe</tmNotice:name> <tmNotice:name>Joe Doe</tmNotice:name>
<tmNotice:org>Example Inc.</tmNotice:org> <tmNotice:org>Example Inc.</tmNotice:org>
<tmNotice:addr> <tmNotice:addr>
<tmNotice:street>123 Example Dr.</tmNotice:street> <tmNotice:street>123 Example Dr.</tmNotice:street>
<tmNotice:street>Suite 100</tmNotice:street> <tmNotice:street>Suite 100</tmNotice:street>
<tmNotice:city>Reston</tmNotice:city> <tmNotice:city>Reston</tmNotice:city>
<tmNotice:sp>VA</tmNotice:sp> <tmNotice:sp>VA</tmNotice:sp>
<tmNotice:pc>20190</tmNotice:pc> <tmNotice:pc>20190</tmNotice:pc>
<tmNotice:cc>US</tmNotice:cc> <tmNotice:cc>US</tmNotice:cc>
</tmNotice:addr> </tmNotice:addr>
<tmNotice:voice x="4321">+1.7035555555</tmNotice:voice> <tmNotice:voice x="4321">+1.7035555555</tmNotice:voice>
<tmNotice:email>jdoe@example.com</tmNotice:email> <tmNotice:email>jdoe@example.com</tmNotice:email>
</tmNotice:contact> </tmNotice:contact>
<tmNotice:jurDesc jurCC="US">USA</tmNotice:jurDesc> <tmNotice:jurDesc jurCC="US">USA</tmNotice:jurDesc>
<tmNotice:classDesc classNum="35"> <tmNotice:classDesc classNum="35">
Advertising; business management; business administration. Advertising; business management; business administration.
</tmNotice:classDesc> </tmNotice:classDesc>
<tmNotice:classDesc classNum="36"> <tmNotice:classDesc classNum="36">
Insurance; financial affairs; monetary affairs; real estate. Insurance; financial affairs; monetary affairs; real estate.
</tmNotice:classDesc> </tmNotice:classDesc>
<tmNotice:goodsAndServices> <tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> </tmNotice:goodsAndServices>
</tmNotice:claim> </tmNotice:claim>
<tmNotice:claim> <tmNotice:claim>
<tmNotice:markName>Example-One</tmNotice:markName> <tmNotice:markName>Example-One</tmNotice:markName>
<tmNotice:holder entitlement="owner"> <tmNotice:holder entitlement="owner">
<tmNotice:org>Example S.A. de C.V.</tmNotice:org> <tmNotice:org>Example S.A. de C.V.</tmNotice:org>
<tmNotice:addr> <tmNotice:addr>
<tmNotice:street>Calle conocida #343</tmNotice:street> <tmNotice:street>Calle conocida #343</tmNotice:street>
<tmNotice:city>Conocida</tmNotice:city> <tmNotice:city>Conocida</tmNotice:city>
<tmNotice:sp>SP</tmNotice:sp> <tmNotice:sp>SP</tmNotice:sp>
<tmNotice:pc>82140</tmNotice:pc> <tmNotice:pc>82140</tmNotice:pc>
<tmNotice:cc>BR</tmNotice:cc> <tmNotice:cc>BR</tmNotice:cc>
</tmNotice:addr> </tmNotice:addr>
</tmNotice:holder> </tmNotice:holder>
<tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc> <tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc>
<tmNotice:goodsAndServices> <tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> </tmNotice:goodsAndServices>
</tmNotice:claim> </tmNotice:claim>
<tmNotice:claim> <tmNotice:claim>
<tmNotice:markName>One</tmNotice:markName> <tmNotice:markName>One</tmNotice:markName>
<tmNotice:holder entitlement="owner"> <tmNotice:holder entitlement="owner">
<tmNotice:org>One Corporation</tmNotice:org> <tmNotice:org>One Corporation</tmNotice:org>
<tmNotice:addr> <tmNotice:addr>
<tmNotice:street>Otra calle</tmNotice:street> <tmNotice:street>Otra calle</tmNotice:street>
<tmNotice:city>Otra ciudad</tmNotice:city> <tmNotice:city>Otra ciudad</tmNotice:city>
<tmNotice:sp>OT</tmNotice:sp> <tmNotice:sp>OT</tmNotice:sp>
<tmNotice:pc>383742</tmNotice:pc> <tmNotice:pc>383742</tmNotice:pc>
<tmNotice:cc>CR</tmNotice:cc> <tmNotice:cc>CR</tmNotice:cc>
</tmNotice:addr> </tmNotice:addr>
</tmNotice:holder> </tmNotice:holder>
<tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc> <tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc>
<tmNotice:goodsAndServices> <tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> </tmNotice:goodsAndServices>
<tmNotice:notExactMatch> <tmNotice:notExactMatch>
<tmNotice:court> <tmNotice:court>
<tmNotice:refNum>234235</tmNotice:refNum> <tmNotice:refNum>234235</tmNotice:refNum>
<tmNotice:cc>CR</tmNotice:cc> <tmNotice:cc>CR</tmNotice:cc>
<tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName> <tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName>
</tmNotice:court> </tmNotice:court>
</tmNotice:notExactMatch> </tmNotice:notExactMatch>
</tmNotice:claim> </tmNotice:claim>
<tmNotice:claim> <tmNotice:claim>
<tmNotice:markName>One Inc</tmNotice:markName> <tmNotice:markName>One Inc</tmNotice:markName>
<tmNotice:holder entitlement="owner"> <tmNotice:holder entitlement="owner">
<tmNotice:org>One SA de CV</tmNotice:org> <tmNotice:org>One SA de CV</tmNotice:org>
<tmNotice:addr> <tmNotice:addr>
<tmNotice:street>La calle</tmNotice:street> <tmNotice:street>La calle</tmNotice:street>
<tmNotice:city>La ciudad</tmNotice:city> <tmNotice:city>La ciudad</tmNotice:city>
<tmNotice:sp>CD</tmNotice:sp> <tmNotice:sp>CD</tmNotice:sp>
<tmNotice:pc>34323</tmNotice:pc> <tmNotice:pc>34323</tmNotice:pc>
<tmNotice:cc>AR</tmNotice:cc> <tmNotice:cc>AR</tmNotice:cc>
</tmNotice:addr> </tmNotice:addr>
</tmNotice:holder> </tmNotice:holder>
<tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc> <tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc>
<tmNotice:goodsAndServices> <tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum. Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices> </tmNotice:goodsAndServices>
<tmNotice:notExactMatch> <tmNotice:notExactMatch>
<tmNotice:udrp> <tmNotice:udrp>
<tmNotice:caseNo>D2003-0499</tmNotice:caseNo> <tmNotice:caseNo>D2003-0499</tmNotice:caseNo>
<tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider> <tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider>
</tmNotice:udrp> </tmNotice:udrp>
</tmNotice:notExactMatch> </tmNotice:notExactMatch>
</tmNotice:claim> </tmNotice:claim>
</tmNotice:notice> </tmNotice:notice>
For the formal syntax of the TCN please refer to Section 7.1. Figure 16: Example <tmNotice:notice> Object
For the formal syntax of the TCN, please refer to Section 7.1.
6.6. Sunrise List (SURL) 6.6. Sunrise List (SURL)
This section defines the format of the list containing every Domain This section defines the format of the list containing every DNL that
Name Label (DNL) that matches a PRM eligible for Sunrise. The list matches a PRM eligible for Sunrise. The list is maintained by the
is maintained by the TMDB and downloaded by Registries in regular TMDB and downloaded by Registries in regular intervals (see
intervals (see Section 5.4.2.1). The Registries use the Sunrise List Section 5.4.2.1). The Registries use the Sunrise List during the QLP
during the Qualified Launch Program Period to check whether a Period to check whether a requested DN matches a DNL of a PRM
requested DN matches a DNL of a PRM eligible for Sunrise. eligible for Sunrise.
The Sunrise List contains all the DNLs covered by a PRM eligible for The Sunrise List contains all the DNLs covered by a PRM eligible for
Sunrise present in the TMDB at the datetime it is generated. Sunrise that are present in the TMDB at the datetime it is generated.
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:
* first line: <version>,<Sunrise List creation datetime> * first line: <version>,<Sunrise List creation datetime>
Where: Where:
o <version>, version of the file, this field MUST be 1. o <version>: version of the file. This field MUST be 1.
o <Sunrise List creation datetime>, date and time in UTC that o <Sunrise List creation datetime>: date and time in UTC that
the Sunrise List was created. the Sunrise List was created.
* second line: a header line as specified in [RFC4180] * second line: a header line, as specified in [RFC4180]
With the header names as follows: With the header names as follows:
DNL,insertion-datetime DNL,insertion-datetime
* One or more lines with: <DNL>,<DNL insertion datetime> * One or more lines with: <DNL>,<DNL insertion datetime>
Where: Where:
o <DNL>, a Domain Name Label covered by a PRM eligible for o <DNL>: a Domain Name Label covered by a PRM eligible for
Sunrise. Sunrise.
o <DNL insertion datetime>, datetime in UTC that the DNL was o <DNL insertion datetime>: datetime in UTC that the DNL was
first inserted into the Sunrise List. The possible two first inserted into the Sunrise List. The possible two
values of time for inserting a DNL to the Sunrise List are values of time for inserting a DNL to the Sunrise List are
00:00:00 and 12:00:00 UTC. 00:00:00 and 12:00:00 UTC.
Example of a Sunrise List: Example of a Sunrise List:
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
Figure 17: Example Sunrise List
To provide authentication and integrity protection, the Sunrise List To provide authentication and integrity protection, the Sunrise List
will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP will be PGP signed by the TMDB (see Section 5.1.1.4). The PGP
signature of the Sunrise List can be found in the similar URI but signature of the Sunrise List can be found in the similar URI but
with extension .sig as shown below. with extension .sig, as shown below.
The URL of the dy interface (Section 4.3.3) is: The URLs of the dy interface (Section 4.3.3) are:
* < https://<tmdb-domain-name>/dnl/surl-latest.csv > * https://<tmdb-domain-name>/dnl/surl-latest.csv
* < https://<tmdb-domain-name>/dnl/surl-latest.sig > * https://<tmdb-domain-name>/dnl/surl-latest.sig
7. Formal Syntax 7. Formal Syntax
7.1. Trademark Claims Notice (TCN) 7.1. Trademark Claims Notice (TCN)
The schema presented here is for a Trademark Claims Notice. The schema presented here is for a Trademark Claims Notice.
The CODE BEGINS and CODE ENDS tags are not part of the schema; they The CODE BEGINS and CODE ENDS tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI are used to note the beginning and ending of the schema for URI
registration purposes. registration purposes.
skipping to change at page 56, line 25 skipping to change at line 2504
<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 page 57, line 24 skipping to change at line 2551
<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 page 58, line 5 skipping to change at line 2578
<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> <CODE ENDS>
8. Acknowledgements 8. IANA Considerations
This specification is a collaborative effort from several
participants in the ICANN community. Bernie Hoeneisen participated
as co-author until version 02 providing invaluable support for this
document. This specification is based on a model spearheaded by:
Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author
would also like to thank the thoughtful feedbak provided by many in
the tmch-tech mailing list, but particularly the extensive help
provided by James Gould, James Mitchell and Francisco Arias. This
document includes feedback received from the following individuals:
Paul Hoffman.
9. Change History
[[RFC Editor: Please remove this section.]]
9.1. Version 04
1. Ping update.
9.2. Version 05
1. Ping update.
9.3. Version 06
1. Updated the terminology text to reflect the text in RFC8174.
2. Updated the reference of RFC7719 to RFC8499.
3. Updated the matching rules document reference to link to the
latest version.
9.4. Version 07
1. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/
xcZPOAajlUJzgPgZBuqlIWRcFZg/
2. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/
MdOhSomd6_djLcthfw5mxWZkbWY
9.5. Version 08
1. Fixed issues detected by idnits tool.
9.6. Version 09
1. Ping update.
9.7. Version 10
1. Ping update.
9.8. Version 11
1. Editorial updates.
2. Added Privacy section.
9.9. Version 12
1. Editorial updates.
9.10. Version 13
1. Editorial updates.
9.11. Version 14
1. Editorial updates.
9.12. Version 15
1. Ping update.
10. IANA Considerations
The code point assigned in support of this document is taken from the The code point assigned in support of this document is taken from the
wrong point in the registration tree. Unfortunately, the code point wrong point in the registration tree. Unfortunately, the code point
has already been deployed in the field without following the proper has already been deployed in the field without following the proper
registration review process. The Designated Experts for the registry registration review process. The designated experts for the registry
have considered the issues that correcting this action would cause have considered the issues that correcting this action would cause
for deployed implementations and have consented to the continued use for deployed implementations and have consented to the continued use
of the code point. of the code point.
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. IANA is conforming to a registry mechanism described in [RFC3688]. IANA has
requested to register two URI assignments. registered two URI assignments as follows.
Registration request for the Trademark Claims Notice namespace: Trademark Claims Notice namespace:
URI: urn:ietf:params:xml:ns:tmNotice-1.0 URI: urn:ietf:params:xml:ns:tmNotice-1.0
Registrant Contact: IETF <iesg@ietf.org> ICANN Registrant Contact: IETF <iesg@ietf.org> and ICANN
<globalsupport@icann.org> <globalsupport@icann.org>
XML: None. Namespace URIs do not represent an XML specification.
Note: Note that this assignment is made from the wrong point in the
tree in order to be consistent with deployed implementations.
XML: None. Namespace URIs do not represent an XML specification. Trademark Claims Notice XML schema:
Note: Note that this assignment is made from the wrong point in
the tree in order to be consistent with deployed implementations.
Registration request for the Trademark Claims Notice XML schema:
URI: urn:ietf:params:xml:schema:tmNotice-1.0
Registrant Contact: IETF <iesg@ietf.org> ICANN URI: urn:ietf:params:xml:schema:tmNotice-1.0
Registrant Contact: IETF <iesg@ietf.org> and ICANN
<globalsupport@icann.org> <globalsupport@icann.org>
XML: See Section 7.1 of RFC 9361.
Note: Note that this assignment is made from the wrong point in the
tree in order to be consistent with deployed implementations.
XML: See Section 7.1 of this document. 9. Security Considerations
Note: Note that this assignment is made from the wrong point in
the tree in order to be consistent with deployed implementations.
11. Security Considerations
This specification uses HTTP Basic Authentication to provide a simple This specification uses HTTP Basic Authentication to provide a simple
application-layer authentication service. HTTPS is used in all application-layer authentication service. HTTPS is used in all
interfaces in order to protect against most common attacks. In interfaces in order to protect against most common attacks. In
addition, the client identifier is tied to a set of IP addresses that addition, the client identifier is tied to a set of IP addresses that
are allowed to connect to the interfaces described in this document, are allowed to connect to the interfaces described in this document,
providing an extra security measure. providing an extra security measure.
The TMDB MUST provide credentials to the appropriate Registries and The TMDB MUST provide credentials to the appropriate Registries and
Registrars. Registrars.
The TMDB MUST require the use of strong passwords by Registries and The TMDB MUST require the use of strong passwords by Registries and
Registrars. Registrars.
The TMDB, Registries and Registrars MUST use the best practices The TMDB, Registries, and Registrars MUST use the best practices
described in [RFC7525] or its successors. described in [RFC9325] or its successors.
12. Privacy Considerations 10. Privacy Considerations
This specification defines the interfaces to support the This specification defines the interfaces to support the
[RPM-Requirements]. Legal documents govern the interactions between [RPM-Requirements]. Legal documents govern the interactions between
the different parties, and such legal documents must ensure that the different parties, and such legal documents must ensure that
privacy-sensitive and/or personal data receives the required privacy-sensitive and/or personal data receives the required
protection. protection.
13. References 11. References
13.1. Normative References
11.1. Normative References
[Claims50] ICANN, "Implementation Notes: Trademark Claims Protection [Claims50] ICANN, "Implementation Notes: Trademark Claims Protection
for Previously Abused Names", 16 July 2013, for Previously Abused Names", July 2013,
<https://newgtlds.icann.org/en/about/trademark- <https://newgtlds.icann.org/en/about/trademark-
clearinghouse/previously-abused-16jul13-en.pdf>. clearinghouse/previously-abused-16jul13-en.pdf>.
[MatchingRules] [MatchingRules]
ICANN, "Memorandum on Implementing Matching Rules", 14 ICANN, "Explanatory Memorandum: Implementing the Matching
July 2016, <https://newgtlds.icann.org/en/about/trademark- Rules", July 2016, <https://newgtlds.icann.org/en/about/
clearinghouse/matching-rules-14jul16-en.pdf>. trademark-clearinghouse/matching-rules-14jul16-en.pdf>.
[QLP-Addendum] [QLP-Addendum]
ICANN, "Qualified Launch Program Addendum", 10 April 2014, ICANN, "Trademark Clearinghouse Rights Protection
Mechanism Requirements: Qualified Launch Program
Addendum", April 2014,
<https://newgtlds.icann.org/en/about/trademark- <https://newgtlds.icann.org/en/about/trademark-
clearinghouse/rpm-requirements-qlp-addendum- clearinghouse/rpm-requirements-qlp-addendum-
10apr14-en.pdf>. 10apr14-en.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping",
RFC 7848, DOI 10.17487/RFC7848, June 2016, RFC 7848, DOI 10.17487/RFC7848, June 2016,
<https://www.rfc-editor.org/info/rfc7848>. <https://www.rfc-editor.org/info/rfc7848>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RPM-Requirements] [RPM-Requirements]
ICANN, "Rights Protection Mechanism Requirements", 30 ICANN, "Trademark Clearinghouse Rights Protection
September 2013, <https://newgtlds.icann.org/en/about/ Mechanism Requirements", September 2013,
trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>. <https://newgtlds.icann.org/en/about/trademark-
clearinghouse/rpm-requirements-30sep13-en.pdf>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0 and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition) REC-xml-20081126", November 2008, (Fifth Edition)", W3C Recommendation REC-xml-20081126,
November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>. <https://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H. S., Beech, D., Maloney, M., and N. Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
Mendelsohn, "XML Schema Part 1: Structures Second Edition "XML Schema Part 1: Structures Second Edition", W3C
REC-xmlschema-1-20041028", October 2004, Recommendation REC-xmlschema-1-20041028, October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>. <https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. V. and A. Malhotra, "XML Schema Part 2: Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Datatypes Second Edition REC-xmlschema-2-20041028", Second Edition", W3C Recommendation REC-xmlschema-
October 2004, 2-20041028, October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>. <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
13.2. Informative References 11.2. Informative References
[ICANN-GTLD-AGB-20120604] [ICANN-GTLD-AGB-20120604]
ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 4 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June
June 2012, <http://newgtlds.icann.org/en/applicants/agb/ 2012, <http://newgtlds.icann.org/en/applicants/agb/
guidebook-full-04jun12-en.pdf>. guidebook-full-04jun12-en.pdf>.
[ISO3166-2] [ISO3166-2]
ISO, "International Standard for country codes and codes ISO, "International Standard for country codes and codes
for their subdivisions", 2006, for their subdivisions",
<http://www.iso.org/iso/home/standards/country_codes.htm>. <http://www.iso.org/iso/home/standards/country_codes.htm>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180, Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005, DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>. <https://www.rfc-editor.org/info/rfc4180>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
skipping to change at page 63, line 21 skipping to change at line 2747
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7617, DOI 10.17487/RFC7617, September 2015,
RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7617>.
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[WIPO-NICE-CLASSES] [WIPO-NICE-CLASSES]
WIPO, "WIPO Nice Classification", 2015, WIPO, "Nice Classification",
<http://www.wipo.int/classifications/nice/en>. <http://www.wipo.int/classifications/nice/en>.
[WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the [WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the
representation of states, other entities and representation of states, other entities and
intergovernmental organizations", March 2007, intergovernmental organizations", November 2022,
<http://www.iso.org/iso/home/standards/country_codes.htm>. <https://www.wipo.int/export/sites/www/standards/en/
pdf/03-03-01.pdf>.
Acknowledgements
This specification is a collaborative effort from several
participants in the ICANN community. Bernie Hoeneisen participated
as a coauthor for the first draft version of this document, providing
invaluable support. This specification is based on a model
spearheaded by Chris Wright, Jeff Neuman, Jeff Eckhaus, and 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 James Gould, James Mitchell, and Francisco
Arias. This document includes feedback received from Paul Hoffman.
Author's Address Author's Address
Gustavo Lozano Gustavo Lozano
ICANN ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive
Suite 300
Los Angeles, 90292 Los Angeles, 90292
United States of America United States of America
Phone: +1.3103015800 Phone: +1.310.301.5800
Email: gustavo.lozano@icann.org Email: gustavo.lozano@icann.org
 End of changes. 431 change blocks. 
1089 lines changed or deleted 1038 lines changed or added

This html diff was produced by rfcdiff 1.48.