idnits 2.17.1 draft-ietf-regext-tmch-func-spec-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 04, 2022) is 842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational Jan 04, 2022 5 Expires: July 8, 2022 7 ICANN TMCH functional specifications 8 draft-ietf-regext-tmch-func-spec-11 10 Abstract 12 This document describes the requirements, the architecture and the 13 interfaces between the ICANN Trademark Clearinghouse (TMCH) and 14 Domain Name Registries as well as between the ICANN TMCH and Domain 15 Name Registrars for the provisioning and management of domain names 16 during Sunrise and Trademark Claims Periods. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 8, 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 9 57 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 58 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . 13 77 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 78 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 79 5.1.1.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 14 80 5.1.1.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 14 81 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15 82 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 83 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 84 5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15 85 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 15 86 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.1. Domain Name registration . . . . . . . . . . . . . . 16 88 5.2.2. Sunrise Domain Name registration by Registries . . . 17 89 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 18 90 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18 91 5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 19 92 5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 19 93 5.2.4. Sunrise Domain Name registration by Registrars . . . 22 94 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 22 95 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23 96 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23 97 5.3.2. Trademark Claims Domain Name registration by 98 Registries . . . . . . . . . . . . . . . . . . . . . 24 99 5.3.3. TMBD Trademark Claims Services for Registries . . . . 25 100 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 25 101 5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 26 102 5.3.4. Trademark Claims Domain Name registration by 103 Registrars . . . . . . . . . . . . . . . . . . . . . 26 104 5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28 105 5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28 106 5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 28 107 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 28 108 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31 109 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31 110 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 31 111 6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 32 112 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 33 113 6.3. List of Registered Domain Names (LORDN) file . . . . . . 35 114 6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39 115 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 116 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 45 117 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 46 118 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 53 119 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54 120 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 54 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 122 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 57 123 9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 57 124 9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 57 125 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 57 126 9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58 127 9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 58 128 9.6. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 58 129 9.7. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 58 130 9.8. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 58 131 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 132 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 133 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 59 134 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 135 13.1. Normative References . . . . . . . . . . . . . . . . . . 59 136 13.2. Informative References . . . . . . . . . . . . . . . . . 61 137 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 139 1. Introduction 141 Domain Name Registries (DNRs) may operate in special modes for 142 certain periods of time enabling trademark holders to protect their 143 rights during the introduction of a Top Level Domain (TLD). 145 Along with the introduction of new generic TLDs (gTLD), two special 146 modes came into effect: 148 o Sunrise Period, the Sunrise Period allows trademark holders an 149 advance opportunity to register domain names corresponding to 150 their marks before names are generally available to the public. 152 o Trademark Claims Period, the Trademark Claims Period follows the 153 Sunrise Period and runs for at least the first 90 days of an 154 initial operating period of general registration. During the 155 Trademark Claims Period, anyone attempting to register a domain 156 name matching a mark that is recorded in the ICANN Trademark 157 Clearinghouse (TMCH) will receive a notification displaying the 158 relevant mark information. 160 This document describes the requirements, the architecture and the 161 interfaces between the ICANN TMCH and Domain Name Registries (called 162 Registries in the rest of the document) as well as between the ICANN 163 TMCH and Domain Name Registrars (called Registrars in the rest of the 164 document) for the provisioning and management of domain names during 165 the Sunrise and Trademark Claims Periods. 167 For any date and/or time indications, Coordinated Universal Time 168 (UTC) applies. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 XML is case sensitive. Unless stated otherwise, XML specifications 179 and examples provided in this document MUST be interpreted in the 180 character case presented in order to develop a conforming 181 implementation. 183 "tmNotice-1.0" is used as an abbreviation for 184 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 185 "tmNotice" is used, but implementations MUST NOT depend on it and 186 instead employ a proper namespace-aware XML parser and serializer to 187 interpret and output the XML documents. 189 Extensible Markup Language (XML) 1.0 as described in 190 [W3C.REC-xml-20081126] and XML Schema notation as described in 191 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are 192 used in this specification. 194 3. Glossary 196 In the following section, the most common terms are briefly 197 explained: 199 o Backend Registry Operator: Entity that manages (a part of) the 200 technical infrastructure for a Registry Operator. The Registry 201 Operator may also be the Backend Registry Operator. 203 o CA: Certificate Authority, see [RFC5280]. 205 o CNIS, Claims Notice Information Service: This service provides 206 Trademark Claims Notices (TCN) to Registrars. 208 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 209 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 211 o CRL: Certificate Revocation List, see [RFC5280]. 213 o CSV: Comma-Separated Values, see [RFC4180] 215 o Date and time, datetime: Date and time are specified following the 216 standard "Date and Time on the Internet specification", see 217 [RFC3339]. 219 o DN, Domain Name, domain name: see definition of Domain name in 220 [RFC8499]. 222 o DNROID, DN Repository Object IDentifier: an identifier assigned by 223 the Registry to each DN object that unequivocally identifies said 224 DN object. For example, if a new DN object is created for a name 225 that existed in the past, the DN objects will have different 226 DNROIDs. 228 o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see 229 [RFC5890]). 231 o DNL List: A list of DNLs that are covered by a PRM. 233 o DNS: Domain Name System, see [RFC8499]. 235 o Effective allocation: A DN is considered effectively allocated 236 when the DN object for the DN has been created in the SRS of the 237 Registry and has been assigned to the effective user. A DN object 238 in status "pendingCreate" or any other status that precedes the 239 first time a DN is assigned to an end-user is not considered an 240 effective allocation. A DN object created internally by the 241 Registry for subsequent delegation to another Registrant is not 242 considered an effective allocation. 244 o EPP: The Extensible Provisioning Protocol, see definition of EPP 245 in [RFC8499]. 247 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 248 [RFC8499]. 250 o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. 252 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 254 o IDN: Internationalized Domain Name, see definition of IDN in 255 [RFC8499]. 257 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 258 Z0-9/] to be used as the lookup key by Registrars to obtain the 259 TCN using the CNIS. Lookup Keys are unique and are related to one 260 DNL only. 262 o LORDN, List of Registered Domain Names: This is the list of 263 effectively allocated DNs matching a DNL of a PRM. Registries 264 will upload this list to the TMDB (during the NORDN process). 266 o Matching Rules: Some trademarks entitled to inclusion in the TMDB 267 include characters that are impermissible in the domain name 268 system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH 269 Matching Rules [MatchingRules]) certain DNS-impermissible 270 characters in a trademark into DNS-permissible equivalent 271 characters 273 o NORDN, Notification of Registered Domain Names: The process by 274 which Registries upload their recent LORDN to the TMDB. 276 o PGP: Pretty Good Privacy, see [RFC4880] 278 o PKI: Public Key Infrastructure, see [RFC5280]. 280 o PRM, Pre-registered mark: Mark that has been pre-registered with 281 the ICANN TMCH. 283 o QLP Period, Qualified Launch Program Period: During this optional 284 period, a special process applies to DNs matching the Sunrise List 285 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 286 DN matching their PRM. 288 o Registrant: see definition of Registrant in [RFC8499]. 290 o Registrar, Domain Name Registrar: see definition of Registrar in 291 [RFC8499]. 293 o Registry, Domain Name Registry, Registry Operator: see definition 294 of Registry in [RFC8499]. A Registry Operator is the contracting 295 party with ICANN for the TLD. 297 o SMD, Signed Mark Data: A cryptographically signed token issued by 298 the TMV to the TMH to be used in the Sunrise Period to apply for a 299 DN that matches a DNL of a PRM; see also [RFC7848]. An SMD 300 generated by an ICANN-approved trademark validator (TMV) contains 301 both the signed token and the TMV's PKIX certificate. 303 o SMD File: A file containing the SMD (see above) and some human 304 readable data. The latter is usually ignored in the processing of 305 the SMD File. See also Section 6.4. 307 o SMD Revocation List: The SMD Revocation List is used by Registries 308 (and optionally by Registrars) during the Sunrise Period to ensure 309 that an SMD is still valid (i.e. not revoked). The SMD Revocation 310 List has a similar function as CRLs used in PKI. 312 o SRS: Shared Registration System, see also 313 [ICANN-GTLD-AGB-20120604]. 315 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 316 eligible for Sunrise. 318 o Sunrise Period: During this period DNs matching a DNL of a PRM can 319 be exclusively obtained by the respective TMHs. For DNs matching 320 a PRM, a special process applies to ensure that TMHs are informed 321 on the effective allocation of a DN matching their PRM. 323 o TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. 325 o ICANN TMCH: a central repository for information to be 326 authenticated, stored, and disseminated, pertaining to the rights 327 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 328 (see below). There could be several entities performing the TMV 329 function, but only one entity performing the TMDB function. 331 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 332 This CA is operated by ICANN. The public key for this CA is the 333 trust anchor used to validate the identity of each TMV. 335 o TMDB, Trademark Clearinghouse Database: Serves as a database of 336 the ICANN TMCH to provide information to the gTLD Registries and 337 Registrars to support Sunrise or Trademark Claims services. There 338 is only one TMDB in the ICANN TMCH that concentrates the 339 information about the "verified" Trademark records from the TMVs. 341 o TMH, Trademark Holder: The person or organization owning rights on 342 a mark. 344 o TMV, Trademark Validator, Trademark validation organization: An 345 entity authorized by ICANN to authenticate and validate 346 registrations in the TMDB ensuring the marks qualify as registered 347 or are court-validated marks or marks that are protected by 348 statute or treaty. This entity would also be asked to ensure that 349 proof of use of marks is provided, which can be demonstrated by 350 furnishing a signed declaration and one specimen of current use. 352 o Trademark, mark: Marks are used to claim exclusive properties of 353 products or services. A mark is typically a name, word, phrase, 354 logo, symbol, design, image, or a combination of these elements. 355 For the scope of this document only textual marks are relevant. 357 o Trademark Claims, Claims: Provides information to enhance the 358 understanding of the Trademark rights being claimed by the TMH. 360 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 361 Trademark Claims Notice consist of one or more Trademark Claims 362 and are provided to prospective Registrants of DNs. 364 o TCNID, Trademark Claims Notice Identifier: An element of the 365 Trademark Claims Notice (see above), identifying said TCN. The 366 Trademark Claims Notice Identifier is specified in the element 367 . 369 o Trademark Claims Period: During this period, a special process 370 applies to DNs matching the DNL List, to ensure that TMHs are 371 informed of a DN matching their PRM. For DNs matching the DNL 372 List, Registrars show a TCN to prospective Registrants that has to 373 be acknowledged before effective allocation of the DN. 375 o UTC: Coordinated Universal Time, as maintained by the Bureau 376 International des Poids et Mesures (BIPM); see also [RFC3339]. 378 4. Architecture 380 4.1. Sunrise Period 382 Architecture of the Sunrise Period 384 SMD hand over (out-of-band) 385 .............................................. 386 : : 387 : .'''''''''''''''''''. : 388 : . ICANN TMCH . : 389 : ..................... : 390 v . . : 391 .------------. . .-------------. . hv .-----. 392 | Registrant | . | TMV |<---------->| TMH | 393 '------------' . '-------------' . vh '-----' 394 | . | ^ \ . 395 | . | | \. 396 tr | . vs | | dv \ 397 | . | vd | .\ 398 v . v v . \ 399 .-----------. sr . .---------. . \ 400 .->| Registrar |<..........| | . \ 401 : '-----------' . | | . \ 402 : | sy . | T | . \ 403 : ry | .------------| M | . vc \ 404 : | | . | D | . \ 405 : v v . | B | . v 406 : .-----------. . yd | | . .---------------. 407 : | Registry |---------->| | . | ICANN TMCH-CA | 408 : '-----------' . '---------' . '---------------' 409 : ^ . . | : 410 : | ''''''''''''''''''' | : 411 : | cy | : 412 : cr '-----------------------------------------' : 413 :......................................................: 415 Figure 1 417 Figure 1 depicts the architecture of the Sunrise Period, including 418 all the actors and interfaces. 420 4.2. Trademark Claims Period 422 Architecture of the Trademark Claims Period 424 .''''''''''''''. 425 . ICANN TMCH . 426 ................ 427 . . 428 .------------. . .-------. . hv .-----. 429 | Registrant | . | TMV |<----------->| TMH | 430 '------------' . '-------' . vh '-----' 431 | . ^ . 432 | . | dv . 433 tr | . vd | . 434 v . v . 435 .-----------. dr . .-------. . 436 | Registrar |<--------| | . 437 '-----------' . | T | . 438 ry | . | M | . 439 v . | D | . 440 .----------. dy . | B | . 441 | Registry |<------->| | . 442 '----------' yd . '-------' . 443 . . 444 '''''''''''''' 446 Figure 2 448 Figure 2 depicts the architecture of the Trademark Claims Period, 449 including all the actors and interfaces. 451 4.3. Interfaces 453 In the sub-sections below follows a short description of each 454 interface to provide an overview of the architecture. More detailed 455 descriptions of the relevant interfaces follow further below 456 (Section 5). 458 4.3.1. hv 460 The TMH registers a mark with a TMV via the hv interface. 462 After the successful registration of the mark, the TMV makes 463 available a SMD File (see also Section 6.4) to the TMH to be used 464 during the Sunrise Period. 466 The specifics of the hv interface are beyond the scope of this 467 document. 469 4.3.2. vd 471 After successful mark registration, the TMV ensures the TMDB inserts 472 the corresponding DNLs and mark information into the database via the 473 vd interface. 475 The specifics of the vd interface are beyond the scope of this 476 document. 478 4.3.3. dy 480 During the Trademark Claims Period the Registry fetches the latest 481 DNL List from the TMDB via the dy interface at regular intervals. 482 The protocol used on the dy interface is HTTPS. 484 Not relevant during the Sunrise Period. 486 4.3.4. tr 488 The Registrant communicates with the Registrar via the tr interface. 490 The specifics of the tr interface are beyond the scope of this 491 document. 493 4.3.5. ry 495 The Registrar communicate with the Registry via the ry interface. 496 The ry interfaces is typically implemented in EPP. 498 4.3.6. dr 500 During the Trademark Claims Period, the Registrar fetches the TCN 501 from the TMDB (to be displayed to the Registrant via the tr 502 interface) via the dr interface. The protocol used for fetching the 503 TCN is HTTPS. 505 Not relevant during the Sunrise Period. 507 4.3.7. yd 509 During the Sunrise Period the Registry notifies the TMDB via the yd 510 interface of all DNs effectively allocated. 512 During the Trademark Claims Period, the Registry notifies the TMDB 513 via the yd interface of all DNs effectively allocated that matched an 514 entry in the Registry previously downloaded DNL List during the 515 creation of the DN. 517 The protocol used on the yd interface is HTTPS. 519 4.3.8. dv 521 The TMDB notifies via the dv interface to the TMV of all DNs 522 effectively allocated that match a mark registered by that TMV. 524 The specifics of the dv interface are beyond the scope of this 525 document. 527 4.3.9. vh 529 The TMV notifies the TMH via the vh interface after a DN has been 530 effectively allocated that matches a PRM of this TMH. 532 The specifics of the vh interface are beyond the scope of this 533 document. 535 4.3.10. vs 537 The TMV requests to add a revoked SMD to the SMD Revocation List at 538 the TMDB. 540 The specifics of the vs interface are beyond the scope of this 541 document. 543 Not relevant during the Trademark Claims Period. 545 4.3.11. sy 547 During the Sunrise Period the Registry fetches the most recent SMD 548 Revocation List from the TMDB via the sy interface in regular 549 intervals. The protocol used on the sy interface is HTTPS. 551 Not relevant during the Trademark Claims Period. 553 4.3.12. sr 555 During the Sunrise Period the Registrar may fetch the most recent SMD 556 Revocation List from the TMDB via the sr interface. The protocol 557 used on the sr interface is the same as on the sy interface (s. 558 above), i.e. HTTPS. 560 Not relevant during the Trademark Claims Period. 562 4.3.13. vc 564 The TMV registers its public key, and requests to revoke an existing 565 key, with the ICANN TMCH-CA over the vc interface. 567 The specifics of the vc interface are beyond the scope of this 568 document, but it involves personal communication between the 569 operators of the TMV and the operators of the ICANN TMCH-CA. 571 Not relevant during the Trademark Claims Period. 573 4.3.14. cy 575 During the Sunrise Period the Registry fetches the most recent TMV 576 CRL file from the ICANN TMCH-CA via the cy interface at regular 577 intervals. The TMV CRL is used for validation of TMV certificates. 578 The protocol used on the cy interface is HTTPS. 580 Not relevant during the Trademark Claims Period. 582 4.3.15. cr 584 During the Sunrise Period the Registrar optionally fetches the most 585 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 586 regular intervals. The TMV CRL is used for validation of TMV 587 certificates. The protocol used on the cr interface is HTTPS. 589 Not relevant during the Trademark Claims Period. 591 5. Process Descriptions 593 5.1. Bootstrapping 595 5.1.1. Bootstrapping for Registries 597 5.1.1.1. Credentials 599 Each Registry Operator will receive authentication credentials from 600 the TMDB to be used: 602 o During the Sunrise Period to fetch the SMD Revocation List from 603 the TMBD via the sy interface (Section 4.3.11). 605 o During the Trademark Claims Period to fetch the DNL List from the 606 TMDB via the dy interface (Section 4.3.3). 608 o During the NORDN process to notify the LORDN to the TMDB via the 609 yd interface (Section 4.3.7). 611 Note: credentials are created per TLD and provided to the Registry 612 Operator. 614 5.1.1.2. IP Addresses for Access Control 616 Each Registry Operator MUST provide to the TMDB all IP addresses that 617 will be used to: 619 o Fetch the SMD Revocation List via the sy interface 620 (Section 4.3.11). 622 o Fetch the DNL List from the TMDB via the dy interface 623 (Section 4.3.3). 625 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 627 This access restriction MAY be applied by the TMDB in addition to 628 HTTP Basic access authentication (see [RFC7235]). For credentials to 629 be used, see Section 5.1.1.1. 631 The TMDB MAY limit the number of IP addresses to be accepted per 632 Registry Operator. 634 5.1.1.3. ICANN TMCH Trust Anchor 636 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 637 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 638 tmch.crt > to be used: 640 o During the Sunrise Period to validate the TMV certificates and the 641 TMV CRL. 643 5.1.1.4. TMDB PGP Key 645 The TMDB MUST provide each Registry Operator with the public portion 646 of the PGP Key used by TMDB, to be used: 648 o During the Sunrise Period to perform integrity checking of the SMD 649 Revocation List fetched from the TMDB via the sy interface 650 (Section 4.3.11). 652 o During the Trademark Claims Period to perform integrity checking 653 of the DNL List fetched from the TMDB via the dy interface 654 (Section 4.3.3). 656 5.1.2. Bootstrapping for Registrars 658 5.1.2.1. Credentials 660 Each ICANN-accredited Registrar will receive authentication 661 credentials from the TMDB to be used: 663 o During the Sunrise Period to (optionally) fetch the SMD Revocation 664 List from the TMDB via the sr interface (Section 4.3.12). 666 o During the Trademark Claims Period to fetch TCNs from the TMDB via 667 the dr interface (Section 4.3.6). 669 5.1.2.2. IP Addresses for Access Control 671 Each Registrar MUST provide to the TMDB all IP addresses, which will 672 be used to: 674 o Fetch the SMD Revocation List via the sr interface 675 (Section 4.3.12). 677 o Fetch TCNs via the dr interface (Section 4.3.6). 679 This access restriction MAY be applied by the TMDB in addition to 680 HTTP Basic access authentication (for credentials to be used, see 681 Section 5.1.2.1). 683 The TMDB MAY limit the number of IP addresses to be accepted per 684 Registrar. 686 5.1.2.3. ICANN TMCH Trust Anchor 688 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 689 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 691 o During the Sunrise Period to (optionally) validate the TMV 692 certificates and TMV CRL. 694 5.1.2.4. TMDB PGP Key 696 Registrars MUST receive the public portion of the PGP Key used by 697 TMDB from the TMDB administrator to be used: 699 o During the Sunrise Period to (optionally) perform integrity 700 checking of the SMD Revocation List fetched from the TMDB via the 701 sr interface (Section 4.3.12). 703 5.2. Sunrise Period 705 5.2.1. Domain Name registration 707 Domain Name registration during the Sunrise Period 709 .------------. .-----------. .----------. 710 | Registrant | | Registrar | | Registry | 711 '------------' '-----------' '----------' 712 | | | 713 | Request DN | | 714 | registration | | 715 | (with SMD) | | 716 |---------------->| Check DN availability | 717 | |---------------------------->| 718 | | | 719 | | DN unavailable .-------------. 720 | DN unavailable |<--------------------( DN available? ) 721 |<----------------| no '-------------' 722 | | | yes 723 | | DN available | 724 | |<----------------------------| 725 | | | 726 | | Request DN registration | 727 | | (with SMD) | 728 | |---------------------------->| 729 | | | 730 | | .------------------------------. 731 | | | DN registration validation / | 732 | | | SMD validation | 733 | | '------------------------------' 734 | | | 735 | Registration |.-----------. Error .----------------------. 736 | error || TRY AGAIN |<-----( Validation successful? ) 737 |<----------------|| / ABORT | no '----------------------' 738 | |'-----------' | yes 739 | | | 740 | | DN registered | 741 | DN registered |<----------------------------| 742 |<----------------| | 743 | | | 745 Figure 3 747 Figure 3 represents a synchronous DN registration workflow (usually 748 called first come first served). 750 5.2.2. Sunrise Domain Name registration by Registries 752 Registries MUST perform a minimum set of checks for verifying each DN 753 registration during the Sunrise Period upon reception of a 754 registration request over the ry interface (Section 4.3.5). If any 755 of these checks fails the Registry MUST abort the registration. Each 756 of these checks MUST be performed before the DN is effectively 757 allocated. 759 In case of asynchronous registrations (e.g. auctions), the minimum 760 set of checks MAY be performed when creating the intermediate object 761 (e.g. a DN application) used for DN registration. If the minimum set 762 of checks is performed when creating the intermediate object (e.g. a 763 DN application) a Registry MAY effectively allocate the DN without 764 performing the minimum set of checks again. 766 Performing the minimum set of checks Registries MUST verify that: 768 1. An SMD has been received from the Registrar along with the DN 769 registration. 771 2. The certificate of the TMV has been correctly signed by the ICANN 772 TMCH-CA. (The certificate of the TMV is contained within the 773 SMD.) 775 3. The datetime when the validation is done is within the validity 776 period of the TMV certificate. 778 4. The certificate of the TMV is not listed in the TMV CRL file 779 specified in the CRL distribution point of the TMV certificate. 781 5. The signature of the SMD (signed with the TMV certificate) is 782 valid. 784 6. The datetime when the validation is done is within the validity 785 period of the SMD based on and 786 elements. 788 7. The SMD has not been revoked, i.e., is not contained in the SMD 789 Revocation List. 791 8. The leftmost DNL of the DN being effectively allocated matches 792 one of the labels () elements in the SMD. For 793 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 794 effectively allocated, the leftmost DNL would be "xn--mgbachtv". 796 These procedure apply to all DN effective allocations at the second 797 level as well as to all other levels subordinate to the TLD that the 798 Registry accepts registrations for. 800 5.2.3. TMDB Sunrise Services for Registries 802 5.2.3.1. SMD Revocation List 804 A new SMD Revocation List MUST be published by the TMDB twice a day, 805 by 00:00:00 and 12:00:00 UTC. 807 Registries MUST refresh the latest version of the SMD Revocation List 808 at least once every 24 hours. 810 Note: the SMD Revocation List will be the same regardless of the TLD. 811 If a Backend Registry Operator manages the infrastructure of several 812 TLDs, the Backend Registry Operator could refresh the SMD Revocation 813 List once every 24 hours, the SMD Revocation List could be used for 814 all the TLDs managed by the Backend Registry Operator. 816 Update of the SMD Revocation List 818 .----------. .------. 819 | Registry | | TMDB | 820 '----------' '------' 821 | | 822 .----------------. | 823 | Periodically, | | 824 | at least | | 825 | every 24 hours | | 826 '----------------' | 827 | | 828 |----------------------------------------------------->| 829 | Download the latest SMD Revocation List | 830 |<-----------------------------------------------------| 831 | | 832 | | 834 Figure 4 836 Figure 4 depicts the process of downloading the latest SMD Revocation 837 List initiated by the Registry. 839 5.2.3.2. TMV Certificate Revocation List (CRL) 841 Registries MUST refresh their local copy of the TMV CRL file at least 842 every 24 hours using the CRL distribution point specified in the TMV 843 certificate. 845 Operationally, the TMV CRL file and CRL distribution point is the 846 same for all TMVs and (at publication of this document) located at < 847 http://crl.icann.org/tmch.crl >. 849 Note: the TMV CRL file will be the same regardless of the TLD. If a 850 Backend Registry Operator manages the infrastructure of several TLDs, 851 the Backend Registry Operator could refresh the TMV CRL file once 852 every 24 hours, the TMV CRL file could be used for all the TLDs 853 managed by the Backend Registry Operator. 855 Update of the TMV CRL file 857 .----------. .---------------. 858 | Registry | | ICANN TMCH-CA | 859 '----------' '---------------' 860 | | 861 .----------------. | 862 | Periodically, | | 863 | at least | | 864 | every 24 hours | | 865 '----------------' | 866 | | 867 |-------------------------------------------->| 868 | Download the latest TMV CRL file | 869 |<--------------------------------------------| 870 | | 871 | | 873 Figure 5 875 Figure 5 depicts the process of downloading the latest TMV CRL file 876 initiated by the Registry. 878 5.2.3.3. Notice of Registered Domain Names (NORN) 880 The Registry MUST send a LORDN file containing DNs effectively 881 allocated to the TMDB (over the yd interface, Section 4.3.7). 883 The effective allocation of a DN MUST be reported by the Registry to 884 the TMDB within 26 hours of the effective allocation of such DN. 886 The Registry MUST create and upload a LORDN file in case there are 887 effective allocations in the SRS, that have not been successfully 888 reported to the TMDB in a previous LORDN file. 890 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 891 maximum frequency to upload LORDN files from the Registries to the 892 TMDB is every 3 hours. 894 It is RECOMMENDED that Registries try to upload at least two LORDN 895 files per day to the TMDB with enough time in between, in order to 896 have time to fix problems reported in the LORDN file. 898 The Registry SHOULD upload a LORDN file only when the previous LORDN 899 file has been processed by the TMDB and the related LORDN Log file 900 has been downloaded and processed by the Registry. 902 The Registry MUST upload LORDN files for DNs effectively allocated 903 during the Sunrise or Trademark Claims Period (same applies to DNs 904 effectively allocated using applications created during the Sunrise 905 or Trademark Claims Period in case of using asynchronous 906 registrations). 908 The yd interface (Section 4.3.7) MUST support at least one (1) and 909 MAY support up to ten (10) concurrent connections from each IP 910 address registered by a Registry Operator to access the service. 912 The TMDB MUST process each uploaded LORDN file and make the related 913 log file available for Registry download within 30 minutes of the 914 finalization of the upload. 916 Notification of Registered Domain Name 918 .----------. .------. .-----. .-----. 919 | Registry | | TMDB | | TMV | | TMH | 920 '----------' '------' '-----' '-----' 921 | | | | 922 .------------------. | | | 923 | Periodically | | | | 924 | upload LORDN | | | | 925 | file | | | | 926 '------------------' | | | 927 | | | | 928 .--------->| Upload LORDN | | | 929 | |-------------------->| | | 930 | | | | | 931 | | .-------------------------. | | 932 | | | Verify each domain name | | | 933 | | | in the uploaded file | | | 934 | | | (within 30') | | | 935 | | '-------------------------' | | 936 | | | ._____.| | 937 | | Download Log file | | END || | 938 | |<--------------------| '-----'| | 939 | | | ^ | | 940 | .-----------------. .---------------. | | | 941 | | Check whether | / everything fine \ no | | | 942 | | Log file | ( (i.e. no errors )---' | | 943 | | contains errors | \ in Log file )? / | | 944 | '-----------------' '---------------' | | 945 | | | yes | | 946 | .---------------. | | | 947 | / everything fine \ yes | | | 948 |( (i.e. no errors )-----. | Notify TMVs | | 949 | \ in Log file )? / | | on the LORDN | | 950 | '---------------' | | pre-registered | | 951 | | no v | with said TMV | | 952 | .----------------. .------. |--------------->| | 953 '-| Correct Errors | | DONE | | | | 954 '----------------' '------' | | Notify each | 955 | | | affected TMH | 956 | | |-------------->| 957 | | | | 959 Figure 6 961 Figure 6 depicts the process to notify the TMH of Registered Domain 962 Names. 964 The format used for the LORDN is described in Section 6.3 966 5.2.4. Sunrise Domain Name registration by Registrars 968 Registrars MAY choose to perform the checks for verifying DN 969 registrations as performed by the Registries (see Section 5.2.2) 970 before sending the command to register a DN. 972 5.2.5. TMDB Sunrise Services for Registrars 974 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 975 also available for Registrars to optionally validate the SMDs 976 received. 978 5.3. Trademark Claims Period 980 5.3.1. Domain Registration 982 Domain Name registration during the Trademark Claims Period 984 .------------. .-----------. .----------. .------. 985 | Registrant | | Registrar | | Registry | | TMDB | 986 '------------' '-----------' '----------' '------' 987 | Request DN | | | 988 | registration | | | 989 |--------------->| Check DN availability | | 990 | |--------------------------->| | 991 | | DN unavailable .-------------. | 992 | DN unavailable |<-------------------( DN available? ) | 993 |<---------------| no '-------------' | 994 | | DN available | yes | 995 | |<---------------------------| | 996 | | Request Lookup key | | 997 | |--------------------------->| | 998 | |.__________. .---------. | 999 | || CONTINUE | / Does DN \ | 1000 | || NORMALLY |<--------( match DNL ) | 1001 | |'----------' no \ of PRM? / | 1002 | | '---------' | 1003 | | Lookup key | yes | 1004 | |<----------------------------' | 1005 | | | 1006 .-----. | | Request TCN | 1007 |ABORT| | Display |---------------------------------------->| 1008 '-----' | Claims | Return TCN | 1009 ^ | Notice |<----------------------------------------| 1010 | no |<---------------| | 1011 | .------. yes | | 1012 '-( Ack? )----------->| Register DN (with TCNID) | | 1013 '------' |--------------------------->| | 1014 | Registration | Error .----------------------. | 1015 | error |<-------------( Validation successful? ) | 1016 |<---------------| no '----------------------' | 1017 | | | yes | 1018 | | DN registered | | 1019 | DN registered |<---------------------------| | 1020 |<---------------| | | 1022 Figure 7 1024 Figure 7 represents a synchronous DN registration workflow (usually 1025 called first come first served). 1027 5.3.2. Trademark Claims Domain Name registration by Registries 1029 During the Trademark Claims Period, Registries perform two main 1030 functions: 1032 o Registries MUST provide Registrars (over the ry interface, 1033 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1034 that match the DNL List. 1036 o Registries MUST provide the Lookup Key only when queried about a 1037 specific DN. 1039 o For each DN matching a DNL of a PRM, Registries MUST perform a 1040 minimum set of checks for verifying DN registrations during the 1041 Trademark Claims Period upon reception of a registration request 1042 over the ry interface (Section 4.3.5). If any of these checks 1043 fails the Registry MUST abort the registration. Each of these 1044 checks MUST be performed before the DN is effectively allocated. 1046 o In case of asynchronous registrations (e.g. auctions), the minimum 1047 set of checks MAY be performed when creating the intermediate 1048 object (e.g. a DN application) used for DN effective allocation. 1049 If the minimum set of checks is performed when creating the 1050 intermediate object (e.g. a DN application) a Registry MAY 1051 effectively allocate the DN without performing the minimum set of 1052 checks again. 1054 o Performing the minimum set of checks Registries MUST verify that: 1056 1. The TCNID (), expiration datetime 1057 () and acceptance datetime of the TCN, have 1058 been received from the Registrar along with the DN 1059 registration. 1061 If the three elements mentioned above are not provided by 1062 the Registrar for a DN matching a DNL of a PRM, but the DNL 1063 was inserted (or re-inserted) for the first time into DNL 1064 List less than 24 hours ago, the registration MAY continue 1065 without this data and the tests listed below are not 1066 required to be performed. 1068 2. The TCN has not expired (according to the expiration datetime 1069 sent by the Registrar). 1071 3. The acceptance datetime is within the window of time defined 1072 by ICANN policy. In the gTLD round of 2012, Registrars 1073 verified that the acceptance datetime was less than or equal 1074 to 48 hours in the past, as there were no defined ICANN 1075 policies at that time. Implementers should be aware that 1076 ICANN policy may define this value in the future. 1078 4. Using the leftmost DNL of the DN being effectively allocated, 1079 the expiration datetime provided by the Registrar, and the 1080 TMDB Notice Identifier extracted from the TCNID provided by 1081 the Registrar compute the TCN Checksum. Verify that the 1082 computed TCN Checksum match the TCN Checksum present in the 1083 TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is 1084 being effectively allocated, the leftmost DNL would be "xn-- 1085 mgbachtv". 1087 These procedures apply to all DN registrations at the second level as 1088 well as to all other levels subordinate to the TLD that the Registry 1089 accepts registrations for. 1091 5.3.3. TMBD Trademark Claims Services for Registries 1093 5.3.3.1. Domain Name Label (DNL) List 1095 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1096 and 12:00:00 UTC. 1098 Registries MUST refresh the latest version of the DNL List at least 1099 once every 24 hours. 1101 Update of the DNL List 1103 .----------. .------. 1104 | Registry | | TMDB | 1105 '----------' '------' 1106 | | 1107 .----------------. | 1108 | Periodically, | | 1109 | at least | | 1110 | every 24 hours | | 1111 '----------------' | 1112 | | 1113 |-------------------------------->| 1114 | Download the latest DNL List | 1115 |<--------------------------------| 1116 | | 1117 | | 1119 Figure 8 1121 Figure 8 depicts the process of downloading the latest DNL list 1122 initiated by the Registry. 1124 Note: the DNL List will be the same regardless of the TLD. If a 1125 Backend Registry Operator manages the infrastructure of several TLDs, 1126 the Backend Registry Operator could refresh the DNL List once every 1127 24 hours, the DNL List could be used for all the TLDs managed by the 1128 Backend Registry Operator. 1130 5.3.3.2. Notice of Registered Domain Names (NORN) 1132 The NORDN process during the Trademark Claims Period is almost the 1133 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1134 difference that only registrations subject to a Trademark Claim 1135 (i.e., at registration time the name appeared in the current DNL List 1136 downloaded by the Registry Operator) are included in the LORDN. 1138 5.3.4. Trademark Claims Domain Name registration by Registrars 1140 For each DN matching a DNL of a PRM, Registrars MUST perform the 1141 following steps: 1143 1. Use the Lookup Key received from the Registry to obtain the TCN 1144 from the TMDB using the dr interface (Section 4.3.6) Registrars 1145 MUST only query for the Lookup Key of a DN that is available for 1146 registration. 1148 2. Present the TCN to the Registrant as described in Exhibit A, 1149 [RPM-Requirements]. 1151 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1152 consent with the TCN, before any further processing. (The 1153 transmission of a TCNID to the Registry over the ry interface, 1154 Section 4.3.5 implies that the Registrant has expressed his/her 1155 consent with the TCN.) 1157 4. Perform the minimum set of checks for verifying DN registrations. 1158 If any of these checks fails the Registrar MUST abort the DN 1159 registration. Each of these checks MUST be performed before the 1160 registration is sent to the Registry. Performing the minimum set 1161 of checks Registrars MUST verify that: 1163 1. The datetime when the validation is done is within the TCN 1164 validity based on the and 1165 elements. 1167 2. The leftmost DNL of the DN being effectively allocated 1168 matches the label () element in the TCN. For 1169 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 1170 effectively allocated, the leftmost DNL would be "xn-- 1171 mgbachtv". 1173 3. The Registrant has acknowledged (expressed his/her consent 1174 with) the TCN. 1176 5. Record the date and time when the registrant acknowledged the 1177 TCN. 1179 6. Send the registration to the Registry (ry interface, 1180 Section 4.3.5) and include the following information: 1182 * TCNID () 1184 * Expiration date of the TCN () 1186 * Acceptance datetime of the TCN. 1188 Currently TCNs are generated twice a day by the TMDB. The expiration 1189 date () of each TCN MUST be set to a value defined 1190 by ICANN policy. In the gTLD round of 2012, the TMDB set the 1191 expiration value to 48 hours in to the future as there were no 1192 defined ICANN policies at that time. Implementers should be aware 1193 that ICANN policy may define this value in the future. 1195 Registrars SHOULD implement a cache of TCNs to minimize the number of 1196 queries sent to the TMDB. A cached TCN MUST be removed from the 1197 cache after the expiration date of the TCN as defined by 1198 . 1200 The TMDB MAY implement rate-limiting as one of the protection 1201 mechanisms to mitigate the risk of performance degradation. 1203 5.3.5. TMBD Trademark Claims Services for Registrars 1205 5.3.5.1. Claims Notice Information Service (CNIS) 1207 The TCNs are provided by the TMDB online and are fetched by the 1208 Registrar via the dr interface (Section 4.3.6). 1210 To get access to the TCNs, the Registrar needs the credentials 1211 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1212 from the Registry via the ry interface (Section 4.3.5). The dr 1213 interface (Section 4.3.6) uses HTTPS with Basic access 1214 authentication. 1216 The dr interface (Section 4.3.6) MAY support up to ten (10) 1217 concurrent connections from each Registrar. 1219 The URL of the dr interface (Section 4.3.6) is: 1221 < https:///cnis/.xml > 1223 Note that the "lookupkey" may contain SLASH characters ("/"). The 1224 SLASH character is part of the URL path and MUST NOT be escaped when 1225 requesting the TCN. 1227 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1228 MUST be signed by a well-know public CA. Registrars MUST perform the 1229 Certification Path Validation described in Section 6 of [RFC5280]. 1230 Registrars will be authenticated in the dr interface using HTTP Basic 1231 access authentication. The dr (Section 4.3.6) interface MUST support 1232 HTTPS keep-alive and MUST maintain the connection for up to 30 1233 minutes. 1235 5.4. Qualified Launch Program (QLP) Period 1237 5.4.1. Domain Registration 1239 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1240 (QLP) Period effective allocations of DNs to third parties could 1241 require that Registries and Registrars provide Sunrise and/or 1242 Trademark Claims services. If required, Registries and Registrars 1243 MUST provide Sunrise and/or Trademark Claims services as described in 1244 Section 5.2 and Section 5.3. 1246 The effective allocation scenarios are: 1248 o If the leftmost DNL of the DN being effectively allocated (QLP 1249 Name in this section) matches a DNL in the SURL, and an SMD is 1250 provided, then Registries MUST provide Sunrise Services (see 1251 Section 5.2) and the DN MUST be reported in a Sunrise LORDN file 1252 during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- 1253 mgbh0fb" is being effectively allocated, the leftmost DNL would be 1254 "xn--mgbachtv". 1256 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1257 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1258 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1259 file using the special SMD-id "99999-99999" during the QLP Period. 1261 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1262 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1263 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1264 services (see Section 5.3) and the DN MUST be reported in a 1265 Trademark Claims LORDN file during the QLP Period. 1267 o If the QLP Name matches a DNL in the DNL List but does not match a 1268 DNL in the SURL, then Registries MUST provide Trademark Claims 1269 services (see Section 5.2) and the DN MUST be reported in a 1270 Trademark Claims LORDN file during the QLP Period. 1272 The following table lists all the effective allocation scenarios 1273 during a QLP Period: 1275 +--------+---------+-----------------+--------------+---------------+ 1276 | QLP | QLP | SMD was | Registry | Registry MUST | 1277 | Name | Name | provided by the | MUST provide | report DN | 1278 | match | match | potential | Sunrise or | registration | 1279 | in the | in the | Registrant | Trademark | in | 1280 | SURL | DNL | | Claims | LORDN file | 1281 | | List | | Services | | 1282 +--------+---------+-----------------+--------------+---------------+ 1283 | Y | Y | Y | Sunrise | Sunrise | 1284 | | | | | | 1285 | Y | N | Y | Sunrise | Sunrise | 1286 | | | | | | 1287 | N | Y | -- | Trademark | Trademark | 1288 | | | | Claims | Claims | 1289 | | | | | | 1290 | N | N | -- | -- | -- | 1291 | | | | | | 1292 | Y | Y | N (see section | Trademark | Trademark | 1293 | | | 2.2 of | Claims | Claims | 1294 | | | [QLP-Addendum]) | | | 1295 | | | | | | 1296 | Y | N | N (see section | -- | Sunrise | 1297 | | | 2.2 of | | (using | 1298 | | | [QLP-Addendum]) | | special SMD- | 1299 | | | | | id) | 1300 +--------+---------+-----------------+--------------+---------------+ 1302 QLP Effective Allocation Scenarios 1304 The TMDB MUST provide the following services to Registries during a 1305 QLP Period: 1307 o SMD Revocation List (see Section 5.2.3.1) 1309 o NORN (see Section 5.2.3.3) 1311 o DNL List (see Section 5.3.3.1) 1313 o Sunrise List (SURL) (see Section 5.4.2.1 1315 The TMDB MUST provide the following services to Registrars during a 1316 QLP Period: 1318 o SMD Revocation List (see Section 5.2.3.1) 1319 o CNIS (see Section 5.3.5.1) 1321 5.4.2. TMBD QLP Services for Registries 1323 5.4.2.1. Sunrise List (SURL) 1325 A new Sunrise List (SURL) MUST be published by the TMDB twice a day, 1326 by 00:00:00 and 12:00:00 UTC. 1328 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1329 version of the SURL at least once every 24 hours. 1331 Update of the SURL 1333 .----------. .------. 1334 | Registry | | TMDB | 1335 '----------' '------' 1336 | | 1337 .----------------. | 1338 | Periodically, | | 1339 | at least | | 1340 | every 24 hours | | 1341 '----------------' | 1342 | | 1343 |------------------------------->| 1344 | Download the latest SURL | 1345 |<-------------------------------| 1346 | | 1347 | | 1349 Figure 9 1351 Figure 9 depicts the process of downloading the latest SURL initiated 1352 by the Registry. 1354 Note: the SURL will be the same regardless of the TLD. If a Backend 1355 Registry Operator manages the infrastructure of several TLDs, the 1356 Backend Registry Operator could refresh the SURL once every 24 hours, 1357 the SURL could be used for all the TLDs managed by the Backend 1358 Registry Operator. 1360 6. Data Format Descriptions 1361 6.1. Domain Name Label (DNL) List 1363 This section defines the format of the list containing every Domain 1364 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1365 is maintained by the TMDB and downloaded by Registries in regular 1366 intervals (see Section 5.3.3.1). The Registries use the DNL List 1367 during the Trademark Claims Period to check whether a requested DN 1368 matches a DNL of a PRM. 1370 The DNL List contains all the DNLs covered by a PRM present in the 1371 TMDB at the datetime it is generated. 1373 The DNL List is contained in a CSV formatted file that has the 1374 following structure: 1376 o first line: , 1378 Where: 1380 + , version of the file, this field MUST be 1. 1382 + , date and time in UTC that the 1383 DNL List was created. 1385 o second line: a header line as specified in [RFC4180] 1387 With the header names as follows: 1389 DNL,lookup-key,insertion-datetime 1391 o One or more lines with: ,, 1394 Where: 1396 + , a Domain Name Label covered by a PRM. 1398 + , lookup key that the Registry MUST provide to 1399 the Registrar. The lookup key has the following format: 1400
////, where: 1403 - YYYY: year that the TCN was generated. 1405 - MM: zero-padded month that the TCN was generated. 1407 - DD: zero-padded day that the TCN was generated. 1409 - vv: version of the TCN, possible values are 00 and 01. 1411 - X: one hex character. This is the first, second and 1412 third hex character of encoding the in 1413 base16 as specified in [RFC4648]. 1415 - Random bits: 144 random bits encoded in base64url as 1416 specified in [RFC4648]. 1418 - Sequential number: zero-padded natural number in the 1419 range 0000000001 to 2147483647. 1421 + , datetime in UTC that the DNL was 1422 first inserted into the DNL List. The possible two values 1423 of time for inserting a DNL to the DNL List are 00:00:00 and 1424 12:00:00 UTC. 1426 Example of a DNL List: 1428 1,2012-08-16T00:00:00.0Z 1429 DNL,lookup-key,insertion-datetime 1430 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1431 2010-07-14T00:00:00.0Z 1432 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1433 2012-08-16T00:00:00.0Z 1434 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1435 2011-08-16T12:00:00.0Z 1437 To provide authentication and integrity protection, the DNL List will 1438 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1439 PGP signature of the DNL List can be found in the similar URI but 1440 with extension .sig as shown below. 1442 The URL of the dy interface (Section 4.3.3) is: 1444 o < https:///dnl/dnl-latest.csv > 1446 o < https:///dnl/dnl-latest.sig > 1448 6.2. SMD Revocation List 1450 This section defines the format of the list of SMDs that have been 1451 revoked. The list is maintained by the TMDB and downloaded by 1452 Registries (and optionally by Registrars) in regular intervals (see 1453 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1454 Period to validate SMDs received. The SMD Revocation List has a 1455 similar function as CRLs used in PKI [RFC5280]. 1457 The SMD Revocation List contains all the revoked SMDs present in the 1458 TMDB at the datetime it is generated. 1460 The SMD Revocation List is contained in a CSV formatted file that has 1461 the following structure: 1463 o first line: , 1465 Where: 1467 + , version of the file, this field MUST be 1. 1469 + , datetime in UTC 1470 that the SMD Revocation List was created. 1472 o second line: a header line as specified in [RFC4180] 1474 With the header names as follows: 1476 smd-id,insertion-datetime 1478 o One or more lines with: , 1480 Where: 1482 + , identifier of the SMD that was revoked. 1484 + , revocation datetime in UTC of the 1485 SMD. The possible two values of time for inserting an SMD 1486 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1488 To provide integrity protection, the SMD Revocation List is PGP 1489 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1490 List is provided by the TMDB with extension .csv. The PGP signature 1491 of the SMD Revocation List can be found in the similar URI but with 1492 extension .sig as shown below. 1494 The URL of the sr interface (Section 4.3.12) and sy interface 1495 (Section 4.3.11) is: 1497 o < https:///smdrl/smdrl-latest.csv > 1499 o < https:///smdrl/smdrl-latest.sig > 1500 Example of an SMD Revocation List: 1502 1,2012-08-16T00:00:00.0Z 1503 smd-id,insertion-datetime 1504 2-2,2012-08-15T00:00:00.0Z 1505 3-2,2012-08-15T00:00:00.0Z 1506 1-2,2012-08-15T00:00:00.0Z 1508 6.3. List of Registered Domain Names (LORDN) file 1510 This section defines the format of the List of Registered Domain 1511 Names (LORDN), which is maintained by each Registry and uploaded at 1512 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1513 said DN is added to the LORDN along with further information related 1514 to its registration. 1516 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1517 file is: 1519 o Sunrise LORDN file: 1521 < https:///LORDN//sunrise > 1523 o Trademark Claims LORDN file: 1525 < https:///LORDN//claims > 1527 During a QLP Period, Registries MAY be required to upload Sunrise or 1528 Trademark Claims LORDN files. The URIs of the yd interface used to 1529 upload LORDN files during a QLP Period is: 1531 o Sunrise LORDN file (during QLP Period): 1533 < https:///LORDN//sunrise/qlp > 1535 o Trademark Claims LORDN file (during a QLP Period): 1537 < https:///LORDN//claims/qlp > 1539 The yd interface (Section 4.3.7) returns the following HTTP status 1540 codes after a HTTP POST request method is received: 1542 o The interface provides a HTTP/202 status code if the interface was 1543 able to receive the LORDN file and the syntax of the LORDN file is 1544 correct. 1546 The interface provides the LORDN Transaction Identifier in the 1547 HTTP Entity-body that would be used by the Registry to download 1548 the LORDN Log file. The LORDN Transaction Identifier is a 1549 natural number zero-padded in the range 0000000000000000001 to 1550 9223372036854775807. 1552 The TMDB uses the element of the 1553 LORDN file as a unique client-side identifier. If a LORDN file 1554 with the same of a previously sent 1555 LORDN file is received by the TMDB, the LORDN Transaction 1556 Identifier of the previously sent LORDN file MUST be provided 1557 to the Registry. The TMDB MUST ignore the DN Lines present in 1558 the LORDN file if a LORDN file with the same was previously sent. 1561 The HTTP Location header field contains the URI where the LORDN 1562 Log file could be retrieved later, for example: 1564 202 Accepted 1566 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1569 o The interface provides a HTTP/400 if the request is incorrect or 1570 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1571 human readable message in the HTTP Entity-body regarding the 1572 incorrect syntax of the LORDN file. 1574 o The interface provides a HTTP/401 status code if the credentials 1575 provided does not authorize the Registry Operator to upload a 1576 LORDN file. 1578 o The TMDB MUST return a HTTP/404 status code when trying to upload 1579 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1582 plus 26 hours. 1584 o The interface provides a HTTP/500 status code if the system is 1585 experiencing a general failure. 1587 For example, to upload the Sunrise LORDN file for TLD "example", the 1588 URI would be: 1590 < https:///LORDN/example/sunrise > 1592 The LORDN is contained in a CSV formatted file that has the following 1593 structure: 1595 o For Sunrise Period: 1597 * first line: ,, 1600 Where: 1602 - , version of the file, this field MUST be 1. 1604 - , date and time in UTC that the 1605 LORDN was created. 1607 - , number of DN Lines present in the 1608 LORDN file. 1610 * second line: a header line as specified in [RFC4180] 1612 With the header names as follows: 1614 roid,domain-name,SMD-id,registrar-id,registration- 1615 datetime,application-datetime 1617 * One or more lines with: ,,,,, 1621 Where: 1623 - , DN Repository Object IDentifier (DNROID) in the 1624 SRS. 1626 - , DN that was effectively allocated. For 1627 IDNs, the A-label form is used. 1629 - , SMD ID used for registration. 1631 - , IANA Registrar ID. 1633 - , date and time in UTC that the 1634 domain was effectively allocated. 1636 - OPTIONAL , date and 1637 time in UTC that the application was created. The 1638 MUST be provided in 1639 case of a DN effective allocation based on an 1640 asynchronous registration (e.g., when using auctions). 1642 Example of a Sunrise LORDN file: 1644 1,2012-08-16T00:00:00.0Z,3 1645 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1646 application-datetime 1647 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1648 2012-07-15T00:50:00.0Z 1649 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1650 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1652 o For Trademark Claims Period: 1654 * first line: ,, 1657 Where: 1659 - , version of the file, this field MUST be 1. 1661 - , date and time in UTC that the 1662 LORDN was created. 1664 - , number of DN Lines present in the 1665 LORDN file. 1667 * second line: a header line as specified in [RFC4180] 1669 With the header names as follows: 1671 roid,domain-name,notice-id,registrar-id,registration- 1672 datetime,ack-datetime,application-datetime 1674 * One or more lines with: ,,,,,, 1678 Where: 1680 - , DN Repository Object IDentifier (DNROID) in the 1681 SRS. 1683 - , DN that was effectively allocated. For 1684 IDNs, the A-label form is used. 1686 - , Trademark Claims Notice Identifier as specified 1687 in . 1689 - , IANA Registrar ID. 1691 - , date and time in UTC that the 1692 domain was effectively allocated. 1694 - , date and time in UTC 1695 that the TCN was acknowledged. 1697 - OPTIONAL , date and 1698 time in UTC that the application was created. The 1699 MUST be provided in 1700 case of a DN effective allocation based on an 1701 asynchronous registration (e.g., when using auctions). 1703 For a DN matching a DNL of a PRM at the moment of 1704 registration, created without the TCNID, expiration datetime 1705 and acceptance datetime, because DNL was inserted (or re- 1706 inserted) for the first time into DNL List less than 24 1707 hours ago, the string "recent-dnl-insertion" MAY be 1708 specified in and . 1711 Example of a Trademark Claims LORDN file: 1713 1,2012-08-16T00:00:00.0Z,3 1714 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1715 ack-datetime,application-datetime 1716 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1717 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1718 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1719 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1720 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1721 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1723 6.3.1. LORDN Log file 1725 After reception of the LORDN file, the TMDB verifies its content for 1726 syntactical and semantical correctness. The output of the LORDN file 1727 verification is retrieved using the yd interface (Section 4.3.7). 1729 The URI of the yd interface (Section 4.3.7) used to retrieve the 1730 LORDN Log file is: 1732 o Sunrise LORDN Log file: 1734 < https:///LORDN//sunrise//result > 1737 o Trademark Claims LORDN Log file: 1739 < https:///LORDN//claims//result > 1742 A Registry Operator MUST NOT send more than one request per minute 1743 per TLD to download a LORDN Log file. 1745 The yd interface (Section 4.3.7) returns the following HTTP status 1746 codes after a HTTP GET request method is received: 1748 o The interface provides a HTTP/200 status code if the interface was 1749 able to provide the LORDN Log file. The LORDN Log file is 1750 contained in the HTTP Entity-body. 1752 o The interface provides a HTTP/204 status code if the LORDN 1753 Transaction Identifier is correct, but the server has not 1754 finalized processing the LORDN file. 1756 o The interface provides a HTTP/400 status code if the request is 1757 incorrect. 1759 o The interface provides a HTTP/401 status code if the credentials 1760 provided does not authorize the Registry Operator to download the 1761 LORDN Log file. 1763 o The interface provides a HTTP/404 status code if the LORDN 1764 Transaction Identifier is incorrect. 1766 o The interface provides a HTTP/500 status code if the system is 1767 experiencing a general failure. 1769 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1770 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1771 "example" the URI would be: 1773 < https:///LORDN/example/sunrise/0000000000000000001/result > 1776 The LORDN Log file is contained in a CSV formatted file that has the 1777 following structure: 1779 o first line: ,,,,,, 1782 Where: 1784 + , version of the file, this field MUST be 1. 1786 + , date and time in UTC that the 1787 LORDN Log was created. 1789 + , date and time in UTC of 1790 creation for the LORDN file that this log file is referring 1791 to. 1793 + , unique identifier of the LORDN Log 1794 provided by the TMDB. This identifier could be used by the 1795 Registry Operator to unequivocally identify the LORDN Log. 1796 The identified will be a string of a maximum LENGTH of 60 1797 characters from the Base 64 alphabet. 1799 + , whether the LORDN file has been accepted for 1800 processing by the TMDB. Possible values are "accepted" or 1801 "rejected". 1803 + , whether the LORDN Log has any warning result 1804 codes. Possible values are "no-warnings" or "warnings- 1805 present". 1807 + , number of DNs effective allocations 1808 processed in the LORDN file. 1810 A Registry Operator is not required to process a LORDN Log with 1811 a ="accepted" and ="no-warnings". 1813 o second line: a header line as specified in [RFC4180] 1815 With the header names as follows: 1817 roid,result-code 1819 o One or more lines with: , 1821 Where: 1823 + , DN Repository Object IDentifier (DNROID) in the SRS. 1825 + , result code as described in Section 6.3.1.1. 1827 Example of a LORDN Log file: 1829 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1830 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1831 accepted,no-warnings,1 1832 roid,result-code 1833 SH8013-REP,2000 1835 6.3.1.1. LORDN Log Result Codes 1837 The classes of result codes (rc) are listed below. Those classes in 1838 square brackets are not used at this time, but may come into use at 1839 some later stage. The first two digits of a result code denote the 1840 result code class, which defines the outcome at the TMDB: 1842 o ok: Success, DN Line accepted by the TMDB. 1844 o warn: a warning is issued, DN Line accepted by the TMDB. 1846 o err: an error is issued, LORDN file rejected by the TMDB. 1848 In case that after processing a DN Line, the error result code is 1849 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1850 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1851 valid will be reported with a 2001 result code. A 2001 result code 1852 means that the DN Line is syntactically valid, however the DN Line 1853 was not processed because the LORDN file was rejected. All DNs 1854 reported in a rejected LORDN file MUST be reported again by the 1855 Registry because none of the DN Lines present in the LORDN file have 1856 been processed by the TMDB. 1858 LORDN Log Result Code Classes: 1860 code Class outcome 1861 ---- ----- ------- 1863 20xx Success ok 1865 35xx [ DN Line syntax warning ] warn 1866 36xx DN Line semantic warning warn 1868 45xx DN Line syntax error err 1869 46xx DN Line semantic error err 1870 In the following, the LORDN Log result codes used by the TMDB are 1871 described: 1873 LORDN Log Result Codes: 1875 rc Short Description 1876 Long Description 1877 ---- ------------------------------------------------------------- 1879 2000 OK 1880 DN Line successfully processed. 1882 2001 OK but not processed 1883 DN Line is syntactically correct but was not processed 1884 because the LORDN file was rejected. 1886 3601 TCN Acceptance Date after Registration Date 1887 TCN Acceptance Date in DN Line is newer than the Registration 1888 Date. 1890 3602 Duplicate DN Line 1891 This DN Line is an exact duplicate of another DN Line in same 1892 file, DN Line ignored. 1894 3603 DNROID Notified Earlier 1895 Same DNROID has been notified earlier, DN Line ignored. 1897 3604 TCN Checksum invalid 1898 Based on the DN effectively allocated, the TCNID and the 1899 expiration date of the linked TCN, the TCN Checksum is 1900 invalid. 1902 3605 TCN Expired 1903 The TCN was already expired (based on the 1904 field of the TCN) at the datetime of acknowledgement. 1906 3606 Wrong TCNID used 1907 The TCNID used for the registration does not match 1908 the related DN. 1910 3609 Invalid SMD used 1911 The SMD used for registration was not valid at the moment of 1912 registration based on the and 1913 elements. 1914 In case of an asynchronous registration, this refer to the 1915 . 1917 3610 DN reported outside of the time window 1918 The DN was reported outside of the required 26 hours 1919 reporting window. 1921 3611 DN does not match the labels in SMD 1922 The DN does not match the labels included in the SMD. 1924 3612 SMDID does not exist 1925 The SMDID has never existed in the central repository. 1927 3613 SMD was revoked when used 1928 The SMD used for registration was revoked more than 1929 24 hours ago of the . 1930 In case of an asynchronous registration, 1931 the is used when 1932 validating the DN Line. 1934 3614 TCNID does not exist 1935 The TCNID has never existed in the central repository. 1937 3615 Recent-dnl-insertion outside of the time window 1938 The DN registration is reported as a recent-dnl-insertion, 1939 but the (re) insertion into the DNL occurred more than 1940 24 hours ago. 1942 3616 Registration Date of DN in Claims before the end of Sunrise Period 1943 The registration date of the DN is before the end of 1944 the Sunrise Period and the DN was reported in a 1945 Trademark Claims LORDN file. 1947 3617 Registrar has not been approved by the TMDB 1948 Registrar ID in DN Line has not completed Trademark Claims 1949 integration testing with the TMDB. 1951 3618 Registration Date of DN in QLP LORDN file out of the QLP Period 1952 The registration date of the DN in a QLP LORDN file is outside 1953 of the QLP Period. 1955 3619 TCN was not valid 1956 The TCN was not valid (based on the 1957 field of the TCN) at the datetime of acknowledgement. 1959 4501 Syntax Error in DN Line 1960 Syntax Error in DN Line. 1962 4601 Invalid TLD used 1963 The TLD in the DN Line does not match what is expected for 1964 this LORDN. 1966 4602 Registrar ID Invalid 1967 Registrar ID in DN Line is not a valid ICANN-Accredited 1968 Registrar. 1970 4603 Registration Date in the future 1971 The in the DN Line is in the 1972 future. 1974 4606 TLD not in Sunrise or Trademark Claims Period 1975 The was reported when the TLD was 1976 not in Sunrise or Trademark Claims Periods. 1977 In case of an asynchronous registration, 1978 the is used when 1979 validating the DN Line. 1981 4607 Application Date in the future 1982 The in the DN Line is in the 1983 future. 1985 4608 Application Date is later than Registration Date 1986 The in the DN Line is later 1987 than the . 1989 4609 TCNID wrong syntax 1990 The syntax of the TCNID is invalid. 1992 4610 TCN Acceptance Date is in the future 1993 The is in the future. 1995 4611 Label has never existed in the TMDB 1996 The label in the registered DN has never existed in the TMDB. 1998 6.4. Signed Mark Data (SMD) File 2000 This section defines the format of the Signed Mark Data (SMD) File. 2001 After a successful registration of a mark, the TMV returns an SMD 2002 File to the TMH. The SMD File can then be used for registration of 2003 one or more DNs covered by the PRM during the Sunrise Period of a 2004 TLD. 2006 Two encapsulation boundaries are defined for delimiting the 2007 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 2008 and "-----END ENCODED SMD-----". Only data inside the encapsulation 2009 boundaries MUST be used by Registries and Registrars for validation 2010 purposes, i.e. any data outside these boundaries as well as the 2011 boundaries themselves MUST be ignored for validation purposes. 2013 The structure of the SMD File is as follows, all the elements are 2014 REQUIRED, and MUST appear in the specified order. 2016 1. Marks: 2018 2. smdID: 2020 3. U-labels: 2023 4. notBefore: 2025 5. notAfter: 2027 6. -----BEGIN ENCODED SMD----- 2029 7. 2031 8. -----END ENCODED SMD----- 2033 Example of an SMD File: 2035 Marks: Example One 2036 smdID: 1-2 2037 U-labels: example-one, exampleone 2038 notBefore: 2011-08-16 09:00 2039 notAfter: 2012-08-16 09:00 2040 -----BEGIN ENCODED SMD----- 2041 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2042 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2043 ... (base64 data elided for brevity) ... 2044 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2045 -----END ENCODED SMD----- 2047 6.5. Trademark Claims Notice (TCN) 2049 The TMDB MUST provide the TCN to Registrars in XML format as 2050 specified below. 2052 An enclosing element that describes the Trademark 2053 Notice to a given label. 2055 The child elements of the element include: 2057 o A element that contains the unique identifier of the 2058 Trademark Notice. This element contains the the TCNID. 2060 The TCNID is a string concatenation of a TCN Checksum and the 2061 TMDB Notice Identifier. The first 8 characters of the TCNID is 2062 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2063 is a zero-padded natural number in the range of 2064 0000000000000000001 to 9223372036854775807. 2066 Example of a TCNID: 2068 370d0b7c9223372036854775807. 2070 Where: 2072 + TCN Checksum=370d0b7c 2074 + TMDB Notice Identifier=9223372036854775807 2076 The TCN Checksum is a 8 characters long Base16 encoded output 2077 of computing the CRC32 of the string concatenation of: label + 2078 unix_timestamp() + TMDB Notice Identifier 2080 TMDB MUST use the Unix time conversion of the 2081 in UTC to calculate the TCN Checksum. Unix 2082 time is defined as the number of seconds that have elapsed 2083 since 1970-01-01T00:00:00Z not counting leap seconds. For 2084 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2085 is shown: 2087 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2089 The TMDB uses the and 2090 elements from the TCN along with the TMDB Notice Identifier to 2091 compute the TCN Checksum. 2093 A Registry MUST use the leftmost DNL of the DN being 2094 effectively allocated, the expiration datetime of the TCN 2095 (provided by the Registrar) and the TMDB Notice Identifier 2096 extracted from the TCNID (provided by the Registrar) to compute 2097 the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- 2098 mgbh0fb" is being effectively allocated, the leftmost DNL would 2099 be "xn--mgbachtv". 2101 Example of computation of the TCN Checksum: 2103 CRC32(example-one12819492009223372036854775807)=370d0b7c 2105 o A element that contains the start of the 2106 validity date and time of the TCN. 2108 o A element that contains the expiration date 2109 and time of the TCN. 2111 o A element that contains the DNL covered by a PRM. 2113 o One or more elements that contain the Trademark 2114 Claim. The element contains the following child 2115 elements: 2117 * A element that contains the mark text 2118 string. 2120 * One or more elements that contains the 2121 information of the holder of the mark. An "entitlement" 2122 attribute is used to identify the entitlement of the holder, 2123 possible values are: owner, assignee or licensee. The child 2124 elements of include: 2126 + An OPTIONAL element that contains the name 2127 of the holder. A MUST be specified if 2128 is not specified. 2130 + An OPTIONAL element that contains the name of 2131 the organization holder of the mark. A MUST 2132 be specified if is not specified. 2134 + A element that contains the address 2135 information of the holder of a mark. A 2136 contains the following child elements: 2138 - One, two or three OPTIONAL elements 2139 that contains the organization's street address. 2141 - A element that contains the 2142 organization's city. 2144 - An OPTIONAL element that contains the 2145 organization's state or province. 2147 - An OPTIONAL element that contains the 2148 organization's postal code. 2150 - A element that contains the organization's 2151 country code. This a two-character code from 2152 [ISO3166-2]. 2154 + An OPTIONAL element that contains the 2155 organization's voice telephone number. 2157 + An OPTIONAL element that contains the 2158 organization's facsimile telephone number. 2160 + An OPTIONAL element that contains the email 2161 address of the holder. 2163 * Zero or more OPTIONAL elements that contains 2164 the information of the representative of the mark registration. 2165 A "type" attribute is used to identify the type of contact, 2166 possible values are: owner, agent or thirdparty. The child 2167 elements of include: 2169 + A element that contains name of the 2170 responsible person. 2172 + An OPTIONAL element that contains the name of 2173 the organization of the contact. 2175 + A element that contains the address 2176 information of the contact. A contains the 2177 following child elements: 2179 - One, two or three OPTIONAL elements 2180 that contains the contact's street address. 2182 - A element that contains the contact's 2183 city. 2185 - An OPTIONAL element that contains the 2186 contact's state or province. 2188 - An OPTIONAL element that contains the 2189 contact's postal code. 2191 - A element that contains the contact's 2192 country code. This a two-character code from 2193 [ISO3166-2]. 2195 + A element that contains the contact's voice 2196 telephone number. 2198 + An OPTIONAL element that contains the 2199 contact's facsimile telephone number. 2201 + A element that contains the contact's email 2202 address. 2204 * A element that contains the name (in 2205 English) of the jurisdiction where the mark is protected. A 2206 jurCC attribute contains the two-character code of the 2207 jurisdiction where the mark was registered. This is a two- 2208 character code from [WIPO.ST3]. 2210 * Zero or more OPTIONAL element that 2211 contains the description (in English) of the Nice 2212 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2213 attribute contains the class number. 2215 * A element that contains the full 2216 description of the goods and services mentioned in the mark 2217 registration document. 2219 * An OPTIONAL element signals that the 2220 claim notice was added to the TCN based on other rule (e.g. 2221 [Claims50] ) than exact match (defined in [MatchingRules]). 2222 The contains one or more: 2224 + An OPTIONAL element that signals that the 2225 claim notice was added because of a previously abused name 2226 included in an UDRP case. The contains: 2228 - A element that contains the UDRP case 2229 number used to validate the previously abused name. 2231 - A element that contains the name 2232 of the UDRP provider. 2234 + An OPTIONAL element that signals that the 2235 claim notice was added because of a previously abused name 2236 included in a court's resolution. The 2237 contains: 2239 - A element that contains the reference 2240 number of the court's resolution used to validate the 2241 previously abused name. 2243 - A element that contains the two-character 2244 code from [ISO3166-2] of the jurisdiction of the court. 2246 - A element that contains the name of 2247 the court. 2249 Example of a object: 2251 2252 2253 370d0b7c9223372036854775807 2254 2010-08-14T09:00:00.0Z 2255 2010-08-16T09:00:00.0Z 2256 example-one 2257 2258 Example One 2259 2260 Example Inc. 2261 2262 123 Example Dr. 2263 Suite 100 2264 Reston 2265 VA 2266 20190 2267 US 2268 2269 2270 2271 Joe Doe 2272 Example Inc. 2273 2274 123 Example Dr. 2275 Suite 100 2276 Reston 2277 VA 2278 20190 2279 US 2280 2281 +1.7035555555 2282 jdoe@example.com 2283 2284 USA 2285 2286 Advertising; business management; business administration. 2287 2288 2289 Insurance; financial affairs; monetary affairs; real estate. 2290 2291 2292 Bardus populorum circumdabit se cum captiosus populum. 2293 Smert populorum circumdabit se cum captiosus populum. 2294 2295 2296 2297 Example-One 2298 2299 Example S.A. de C.V. 2300 2301 Calle conocida #343 2302 Conocida 2303 SP 2304 82140 2305 BR 2306 2307 2308 BRAZIL 2309 2310 Bardus populorum circumdabit se cum captiosus populum. 2311 Smert populorum circumdabit se cum captiosus populum. 2312 2313 2314 2315 One 2316 2317 One Corporation 2318 2319 Otra calle 2320 Otra ciudad 2321 OT 2322 383742 2323 CR 2324 2325 2326 COSTA RICA 2327 2328 Bardus populorum circumdabit se cum captiosus populum. 2329 Smert populorum circumdabit se cum captiosus populum. 2330 2331 2332 2333 234235 2334 CR 2335 Supreme Court of Spain 2336 2337 2338 2339 2340 One Inc 2341 2342 One SA de CV 2343 2344 La calle 2345 La ciudad 2346 CD 2347 34323 2348 AR 2349 2350 2351 ARGENTINA 2352 2353 Bardus populorum circumdabit se cum captiosus populum. 2354 Smert populorum circumdabit se cum captiosus populum. 2355 2356 2357 2358 D2003-0499 2359 WIPO 2360 2361 2362 2363 2365 For the formal syntax of the TCN please refer to Section 7.1. 2367 6.6. Sunrise List (SURL) 2369 This section defines the format of the list containing every Domain 2370 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2371 is maintained by the TMDB and downloaded by Registries in regular 2372 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2373 during the Qualified Launch Program Period to check whether a 2374 requested DN matches a DNL of a PRM eligible for Sunrise. 2376 The Sunrise List contains all the DNLs covered by a PRM eligible for 2377 Sunrise present in the TMDB at the datetime it is generated. 2379 The Sunrise List is contained in a CSV formatted file that has the 2380 following structure: 2382 o first line: , 2384 Where: 2386 + , version of the file, this field MUST be 1. 2388 + , date and time in UTC that 2389 the Sunrise List was created. 2391 o second line: a header line as specified in [RFC4180] 2393 With the header names as follows: 2395 DNL,insertion-datetime 2397 o One or more lines with: , 2399 Where: 2401 + , a Domain Name Label covered by a PRM eligible for 2402 Sunrise. 2404 + , datetime in UTC that the DNL was 2405 first inserted into the Sunrise List. The possible two 2406 values of time for inserting a DNL to the Sunrise List are 2407 00:00:00 and 12:00:00 UTC. 2409 Example of a Sunrise List: 2411 1,2012-08-16T00:00:00.0Z 2412 DNL,insertion-datetime 2413 example,2010-07-14T00:00:00.0Z 2414 another-example,2012-08-16T00:00:00.0Z 2415 anotherexample,2011-08-16T12:00:00.0Z 2417 To provide authentication and integrity protection, the Sunrise List 2418 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2419 signature of the Sunrise List can be found in the similar URI but 2420 with extension .sig as shown below. 2422 The URL of the dy interface (Section 4.3.3) is: 2424 o < https:///dnl/surl-latest.csv > 2426 o < https:///dnl/surl-latest.sig > 2428 7. Formal Syntax 2430 7.1. Trademark Claims Notice (TCN) 2432 The schema presented here is for a Trademark Claims Notice. 2434 The CODE BEGINS and CODE ENDS tags are not part of the schema; they 2435 are used to note the beginning and ending of the schema for URI 2436 registration purposes. 2438 2439 2440 2446 2447 2448 Schema for representing a Trademark Claim Notice. 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2472 2473 2474 2475 2476 2477 2479 2481 2482 2484 2485 2487 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2553 8. Acknowledgements 2555 This specification is a collaborative effort from several 2556 participants in the ICANN community. Bernie Hoeneisen participated 2557 as co-author until version 02 providing invaluable support for this 2558 document. This specification is based on a model spearheaded by: 2559 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2560 would also like to thank the thoughtful feedbak provided by many in 2561 the tmch-tech mailing list, but particularly the extensive help 2562 provided by James Gould, James Mitchell and Francisco Arias. This 2563 document includes feedback received from the following individuals: 2564 Paul Hoffman. 2566 9. Change History 2568 [[RFC Editor: Please remove this section.]] 2570 9.1. Version 04 2572 1. Ping update. 2574 9.2. Version 05 2576 1. Ping update. 2578 9.3. Version 06 2580 1. Updated the terminology text to reflect the text in RFC8174. 2582 2. Updated the reference of RFC7719 to RFC8499. 2584 3. Updated the matching rules document reference to link to the 2585 latest version. 2587 9.4. Version 07 2589 1. Changes based on the feedback provided here: 2590 https://mailarchive.ietf.org/arch/msg/regext/ 2591 xcZPOAajlUJzgPgZBuqlIWRcFZg/ 2593 2. Changes based on the feedback provided here: 2594 https://mailarchive.ietf.org/arch/msg/regext/ 2595 MdOhSomd6_djLcthfw5mxWZkbWY 2597 9.5. Version 08 2599 1. Fixed issues detected by idnits tool. 2601 9.6. Version 09 2603 1. Ping update. 2605 9.7. Version 10 2607 1. Ping update. 2609 9.8. Version 11 2611 1. Editorial updates. 2613 2. Added Privacy section. 2615 10. IANA Considerations 2617 This document uses URNs to describe XML namespaces and XML schemas 2618 conforming to a registry mechanism described in [RFC3688]. IANA is 2619 requested to register two URI assignments. 2621 Registration request for the Trademark Claims Notice namespace: 2623 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2625 Registrant Contact: IETF 2627 XML: None. Namespace URIs do not represent an XML specification. 2629 Registration request for the Trademark Claims Notice XML schema: 2631 URI: urn:ietf:params:xml:schema:tmNotice-1.0 2632 Registrant Contact: IETF 2634 XML: See Section 7.1 of this document. 2636 11. Security Considerations 2638 This specification uses HTTP Basic Authentication to provide a simple 2639 application-layer authentication service. HTTPS is used in all 2640 interfaces in order to protect against most common attacks. In 2641 addition, the client identifier is tied to a set of IP addresses that 2642 are allowed to connect to the interfaces described in this document, 2643 providing an extra security measure. 2645 The TMDB MUST provide credentials to the appropriate Registries and 2646 Registrars. 2648 The TMDB MUST require the use of strong passwords by Registries and 2649 Registrars. 2651 The TMDB, Registries and Registrars MUST use the best practices 2652 described in [RFC7525] or its successors. 2654 12. Privacy Considerations 2656 This specification defines the interfaces to support the 2657 [RPM-Requirements]. Legal documents govern the interactions between 2658 the different parties, and such legal documents must ensure that 2659 privacy-sensitive and/or personal data receives the required 2660 protection. 2662 13. References 2664 13.1. Normative References 2666 [Claims50] 2667 ICANN, "Implementation Notes: Trademark Claims Protection 2668 for Previously Abused Names", July 2013, 2669 . 2672 [MatchingRules] 2673 ICANN, "Memorandum on Implementing Matching Rules", July 2674 2016, . 2677 [QLP-Addendum] 2678 ICANN, "Qualified Launch Program Addendum", April 2014, 2679 . 2683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2684 Requirement Levels", BCP 14, RFC 2119, 2685 DOI 10.17487/RFC2119, March 1997, 2686 . 2688 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2689 DOI 10.17487/RFC3688, January 2004, 2690 . 2692 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2693 "Recommendations for Secure Use of Transport Layer 2694 Security (TLS) and Datagram Transport Layer Security 2695 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2696 2015, . 2698 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2699 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2700 . 2702 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2703 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2704 May 2017, . 2706 [RPM-Requirements] 2707 ICANN, "Rights Protection Mechanism Requirements", 2708 September 2013, . 2711 [W3C.REC-xml-20081126] 2712 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 2713 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 2714 Edition) REC-xml-20081126", November 2008, 2715 . 2717 [W3C.REC-xmlschema-1-20041028] 2718 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 2719 "XML Schema Part 1: Structures Second Edition REC- 2720 xmlschema-1-20041028", October 2004, 2721 . 2723 [W3C.REC-xmlschema-2-20041028] 2724 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2725 Second Edition REC-xmlschema-2-20041028", October 2004, 2726 . 2728 13.2. Informative References 2730 [ICANN-GTLD-AGB-20120604] 2731 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2732 2012, . 2735 [ISO3166-2] 2736 ISO, "International Standard for country codes and codes 2737 for their subdivisions", 2006, 2738 . 2740 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2741 DOI 10.17487/RFC2818, May 2000, 2742 . 2744 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2745 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2746 . 2748 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2749 Separated Values (CSV) Files", RFC 4180, 2750 DOI 10.17487/RFC4180, October 2005, 2751 . 2753 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2754 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2755 . 2757 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2758 Thayer, "OpenPGP Message Format", RFC 4880, 2759 DOI 10.17487/RFC4880, November 2007, 2760 . 2762 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2763 Housley, R., and W. Polk, "Internet X.509 Public Key 2764 Infrastructure Certificate and Certificate Revocation List 2765 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2766 . 2768 [RFC5890] Klensin, J., "Internationalized Domain Names for 2769 Applications (IDNA): Definitions and Document Framework", 2770 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2771 . 2773 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2774 Protocol (HTTP/1.1): Message Syntax and Routing", 2775 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2776 . 2778 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2779 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2780 DOI 10.17487/RFC7231, June 2014, 2781 . 2783 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2784 Protocol (HTTP/1.1): Authentication", RFC 7235, 2785 DOI 10.17487/RFC7235, June 2014, 2786 . 2788 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2789 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2790 January 2019, . 2792 [WIPO-NICE-CLASSES] 2793 WIPO, "WIPO Nice Classification", 2015, 2794 . 2796 [WIPO.ST3] 2797 WIPO, "Recommended standard on two-letter codes for the 2798 representation of states, other entities and 2799 intergovernmental organizations", March 2007, 2800 . 2802 Author's Address 2804 Gustavo Lozano 2805 ICANN 2806 12025 Waterfront Drive, Suite 300 2807 Los Angeles 90292 2808 US 2810 Phone: +1.3103015800 2811 Email: gustavo.lozano@icann.org