idnits 2.17.1 draft-ietf-regext-tmch-func-spec-08.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 (Apr 07, 2020) is 1479 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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: 0 errors (**), 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 Apr 07, 2020 5 Expires: October 9, 2020 7 ICANN TMCH functional specifications 8 draft-ietf-regext-tmch-func-spec-08 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 October 9, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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) . . . . . . 18 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 . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . 40 115 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 116 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46 117 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47 118 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54 119 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 120 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 122 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58 123 9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58 124 9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58 125 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58 126 9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58 127 9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 59 128 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 129 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 60 132 12.2. Informative References . . . . . . . . . . . . . . . . . 61 133 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 135 1. Introduction 137 Domain Name Registries (DNRs) may operate in special modes for 138 certain periods of time enabling trademark holders to protect their 139 rights during the introduction of a Top Level Domain (TLD). 141 Along with the introduction of new generic TLDs (gTLD), two special 142 modes came into effect: 144 o Sunrise Period, the Sunrise Period allows trademark holders an 145 advance opportunity to register domain names corresponding to 146 their marks before names are generally available to the public. 148 o Trademark Claims Period, the Trademark Claims Period follows the 149 Sunrise Period and runs for at least the first 90 days of an 150 initial operating period of general registration. During the 151 Trademark Claims Period, anyone attempting to register a domain 152 name matching a mark that is recorded in the ICANN Trademark 153 Clearinghouse (TMCH) will receive a notification displaying the 154 relevant mark information. 156 This document describes the requirements, the architecture and the 157 interfaces between the ICANN TMCH and Domain Name Registries (called 158 Registries in the rest of the document) as well as between the ICANN 159 TMCH and Domain Name Registrars (called Registrars in the rest of the 160 document) for the provisioning and management of domain names during 161 the Sunrise and Trademark Claims Periods. 163 For any date and/or time indications, Coordinated Universal Time 164 (UTC) applies. 166 2. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 XML is case sensitive. Unless stated otherwise, XML specifications 175 and examples provided in this document MUST be interpreted in the 176 character case presented in order to develop a conforming 177 implementation. 179 "tmNotice-1.0" is used as an abbreviation for 180 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 181 "tmNotice" is used, but implementations MUST NOT depend on it and 182 instead employ a proper namespace-aware XML parser and serializer to 183 interpret and output the XML documents. 185 3. Glossary 187 In the following section, the most common terms are briefly 188 explained: 190 o Backend Registry Operator: Entity that manages (a part of) the 191 technical infrastructure for a Registry Operator. The Registry 192 Operator may also be the Backend Registry Operator. 194 o CA: Certificate Authority, see [RFC5280]. 196 o CNIS, Claims Notice Information Service: This service provides 197 Trademark Claims Notices (TCN) to Registrars. 199 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 200 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 202 o CRL: Certificate Revocation List, see [RFC5280]. 204 o CSV: Comma-Separated Values, see [RFC4180] 206 o Date and time, datetime: Date and time are specified following the 207 standard "Date and Time on the Internet specification", see 208 [RFC3339]. 210 o DN, Domain Name, domain name: see definition of Domain name in 211 [RFC8499]. 213 o DNROID, DN Repository Object IDentifier: an identifier assigned by 214 the Registry to each DN object that unequivocally identifies said 215 DN object. For example, if a new DN object is created for a name 216 that existed in the past, the DN objects will have different 217 DNROIDs. 219 o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see 220 [RFC5890]). 222 o DNL List: A list of DNLs that are covered by a PRM. 224 o DNS: Domain Name System, see [RFC8499]. 226 o Effective allocation: A DN is considered effectively allocated 227 when the DN object for the DN has been created in the SRS of the 228 Registry and has been assigned to the effective user. A DN object 229 in status "pendingCreate" or any other status that precedes the 230 first time a DN is assigned to an end-user is not considered an 231 effective allocation. A DN object created internally by the 232 Registry for subsequent delegation to another Registrant is not 233 considered an effective allocation. 235 o EPP: The Extensible Provisioning Protocol, see definition of EPP 236 in [RFC8499]. 238 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 239 [RFC8499]. 241 o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. 243 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 245 o IDN: Internationalized Domain Name, see definition of IDN in 246 [RFC8499]. 248 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 249 Z0-9/] to be used as the lookup key by Registrars to obtain the 250 TCN using the CNIS. Lookup Keys are unique and are related to one 251 DNL only. 253 o LORDN, List of Registered Domain Names: This is the list of 254 effectively allocated DNs matching a DNL of a PRM. Registries 255 will upload this list to the TMDB (during the NORDN process). 257 o Matching Rules: Some trademarks entitled to inclusion in the TMDB 258 include characters that are impermissible in the domain name 259 system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH 260 Matching Rules [MatchingRules]) certain DNS-impermissible 261 characters in a trademark into DNS-permissible equivalent 262 characters 264 o NORDN, Notification of Registered Domain Names: The process by 265 which Registries upload their recent LORDN to the TMDB. 267 o PGP: Pretty Good Privacy, see [RFC4880] 269 o PKI: Public Key Infrastructure, see [RFC5280]. 271 o PRM, Pre-registered mark: Mark that has been pre-registered with 272 the ICANN TMCH. 274 o QLP Period, Qualified Launch Program Period: During this optional 275 period, a special process applies to DNs matching the Sunrise List 276 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 277 DN matching their PRM. 279 o Registrant: see definition of Registrant in [RFC8499]. 281 o Registrar, Domain Name Registrar: see definition of Registrar in 282 [RFC8499]. 284 o Registry, Domain Name Registry, Registry Operator: see definition 285 of Registry in [RFC8499]. A Registry Operator is the contracting 286 party with ICANN for the TLD. 288 o SMD, Signed Mark Data: A cryptographically signed token issued by 289 the TMV to the TMH to be used in the Sunrise Period to apply for a 290 DN that matches a DNL of a PRM; see also [RFC7848]. An SMD 291 generated by an ICANN-approved trademark validator (TMV) contains 292 both the signed token and the TMV's PKIX certificate. 294 o SMD File: A file containing the SMD (see above) and some human 295 readable data. The latter is usually ignored in the processing of 296 the SMD File. See also Section 6.4. 298 o SMD Revocation List: The SMD Revocation List is used by Registries 299 (and optionally by Registrars) during the Sunrise Period to ensure 300 that an SMD is still valid (i.e. not revoked). The SMD Revocation 301 List has a similar function as CRLs used in PKI. 303 o SRS: Shared Registration System, see also 304 [ICANN-GTLD-AGB-20120604]. 306 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 307 eligible for Sunrise. 309 o Sunrise Period: During this period DNs matching a DNL of a PRM can 310 be exclusively obtained by the respective TMHs. For DNs matching 311 a PRM, a special process applies to ensure that TMHs are informed 312 on the effective allocation of a DN matching their PRM. 314 o TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. 316 o ICANN TMCH: a central repository for information to be 317 authenticated, stored, and disseminated, pertaining to the rights 318 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 319 (see below). There could be several entities performing the TMV 320 function, but only one entity performing the TMDB function. 322 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 323 This CA is operated by ICANN. The public key for this CA is the 324 trust anchor used to validate the identity of each TMV. 326 o TMDB, Trademark Clearinghouse Database: Serves as a database of 327 the ICANN TMCH to provide information to the gTLD Registries and 328 Registrars to support Sunrise or Trademark Claims services. There 329 is only one TMDB in the ICANN TMCH that concentrates the 330 information about the "verified" Trademark records from the TMVs. 332 o TMH, Trademark Holder: The person or organization owning rights on 333 a mark. 335 o TMV, Trademark Validator, Trademark validation organization: An 336 entity authorized by ICANN to authenticate and validate 337 registrations in the TMDB ensuring the marks qualify as registered 338 or are court-validated marks or marks that are protected by 339 statute or treaty. This entity would also be asked to ensure that 340 proof of use of marks is provided, which can be demonstrated by 341 furnishing a signed declaration and one specimen of current use. 343 o Trademark, mark: Marks are used to claim exclusive properties of 344 products or services. A mark is typically a name, word, phrase, 345 logo, symbol, design, image, or a combination of these elements. 346 For the scope of this document only textual marks are relevant. 348 o Trademark Claims, Claims: Provides information to enhance the 349 understanding of the Trademark rights being claimed by the TMH. 351 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 352 Trademark Claims Notice consist of one or more Trademark Claims 353 and are provided to prospective Registrants of DNs. 355 o TCNID, Trademark Claims Notice Identifier: An element of the 356 Trademark Claims Notice (see above), identifying said TCN. The 357 Trademark Claims Notice Identifier is specified in the element 358 . 360 o Trademark Claims Period: During this period, a special process 361 applies to DNs matching the DNL List, to ensure that TMHs are 362 informed of a DN matching their PRM. For DNs matching the DNL 363 List, Registrars show a TCN to prospective Registrants that has to 364 be acknowledged before effective allocation of the DN. 366 o UTC: Coordinated Universal Time, as maintained by the Bureau 367 International des Poids et Mesures (BIPM); see also [RFC3339]. 369 4. Architecture 371 4.1. Sunrise Period 373 Architecture of the Sunrise Period 375 SMD hand over (out-of-band) 376 .............................................. 377 : : 378 : .'''''''''''''''''''. : 379 : . ICANN TMCH . : 380 : ..................... : 381 v . . : 382 .------------. . .-------------. . hv .-----. 383 | Registrant | . | TMV |<---------->| TMH | 384 '------------' . '-------------' . vh '-----' 385 | . | ^ \ . 386 | . | | \. 387 tr | . vs | | dv \ 388 | . | vd | .\ 389 v . v v . \ 390 .-----------. sr . .---------. . \ 391 .->| Registrar |<..........| | . \ 392 : '-----------' . | | . \ 393 : | sy . | T | . \ 394 : ry | .------------| M | . vc \ 395 : | | . | D | . \ 396 : v v . | B | . v 397 : .-----------. . yd | | . .---------------. 398 : | Registry |---------->| | . | ICANN TMCH-CA | 399 : '-----------' . '---------' . '---------------' 400 : ^ . . | : 401 : | ''''''''''''''''''' | : 402 : | cy | : 403 : cr '-----------------------------------------' : 404 :......................................................: 406 Figure 1 408 4.2. Trademark Claims Period 410 Architecture of the Trademark Claims Period 412 .''''''''''''''. 413 . ICANN TMCH . 414 ................ 415 . . 416 .------------. . .-------. . hv .-----. 417 | Registrant | . | TMV |<----------->| TMH | 418 '------------' . '-------' . vh '-----' 419 | . ^ . 420 | . | dv . 421 tr | . vd | . 422 v . v . 423 .-----------. dr . .-------. . 424 | Registrar |<--------| | . 425 '-----------' . | T | . 426 ry | . | M | . 427 v . | D | . 428 .----------. dy . | B | . 429 | Registry |<------->| | . 430 '----------' yd . '-------' . 431 . . 432 '''''''''''''' 434 Figure 2 436 4.3. Interfaces 438 In the sub-sections below follows a short description of each 439 interface to provide an overview of the architecture. More detailed 440 descriptions of the relevant interfaces follow further below 441 (Section 5). 443 4.3.1. hv 445 The TMH registers a mark with a TMV via the hv interface. 447 After the successful registration of the mark, the TMV makes 448 available a SMD File (see also Section 6.4) to the TMH to be used 449 during the Sunrise Period. 451 The specifics of the hv interface are beyond the scope of this 452 document. 454 4.3.2. vd 456 After successful mark registration, the TMV ensures the TMDB inserts 457 the corresponding DNLs and mark information into the database via the 458 vd interface. 460 The specifics of the vd interface are beyond the scope of this 461 document. 463 4.3.3. dy 465 During the Trademark Claims Period the Registry fetches the latest 466 DNL List from the TMDB via the dy interface at regular intervals. 467 The protocol used on the dy interface is HTTPS. 469 Not relevant during the Sunrise Period. 471 4.3.4. tr 473 The Registrant communicates with the Registrar via the tr interface. 475 The specifics of the tr interface are beyond the scope of this 476 document. 478 4.3.5. ry 480 The Registrar communicate with the Registry via the ry interface. 481 The ry interfaces is typically implemented in EPP. 483 4.3.6. dr 485 During the Trademark Claims Period, the Registrar fetches the TCN 486 from the TMDB (to be displayed to the Registrant via the tr 487 interface) via the dr interface. The protocol used for fetching the 488 TCN is HTTPS. 490 Not relevant during the Sunrise Period. 492 4.3.7. yd 494 During the Sunrise Period the Registry notifies the TMDB via the yd 495 interface of all DNs effectively allocated. 497 During the Trademark Claims Period, the Registry notifies the TMDB 498 via the yd interface of all DNs effectively allocated that matched an 499 entry in the Registry previously downloaded DNL List during the 500 creation of the DN. 502 The protocol used on the yd interface is HTTPS. 504 4.3.8. dv 506 The TMDB notifies via the dv interface to the TMV of all DNs 507 effectively allocated that match a mark registered by that TMV. 509 The specifics of the dv interface are beyond the scope of this 510 document. 512 4.3.9. vh 514 The TMV notifies the TMH via the vh interface after a DN has been 515 effectively allocated that matches a PRM of this TMH. 517 The specifics of the vh interface are beyond the scope of this 518 document. 520 4.3.10. vs 522 The TMV requests to add a revoked SMD to the SMD Revocation List at 523 the TMDB. 525 The specifics of the vs interface are beyond the scope of this 526 document. 528 Not relevant during the Trademark Claims Period. 530 4.3.11. sy 532 During the Sunrise Period the Registry fetches the most recent SMD 533 Revocation List from the TMDB via the sy interface in regular 534 intervals. The protocol used on the sy interface is HTTPS. 536 Not relevant during the Trademark Claims Period. 538 4.3.12. sr 540 During the Sunrise Period the Registrar may fetch the most recent SMD 541 Revocation List from the TMDB via the sr interface. The protocol 542 used on the sr interface is the same as on the sy interface (s. 543 above), i.e. HTTPS. 545 Not relevant during the Trademark Claims Period. 547 4.3.13. vc 549 The TMV registers its public key, and requests to revoke an existing 550 key, with the ICANN TMCH-CA over the vc interface. 552 The specifics of the vc interface are beyond the scope of this 553 document, but it involves personal communication between the 554 operators of the TMV and the operators of the ICANN TMCH-CA. 556 Not relevant during the Trademark Claims Period. 558 4.3.14. cy 560 During the Sunrise Period the Registry fetches the most recent TMV 561 CRL file from the ICANN TMCH-CA via the cy interface at regular 562 intervals. The TMV CRL is used for validation of TMV certificates. 563 The protocol used on the cy interface is HTTPS. 565 Not relevant during the Trademark Claims Period. 567 4.3.15. cr 569 During the Sunrise Period the Registrar optionally fetches the most 570 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 571 regular intervals. The TMV CRL is used for validation of TMV 572 certificates. The protocol used on the cr interface is HTTPS. 574 Not relevant during the Trademark Claims Period. 576 5. Process Descriptions 578 5.1. Bootstrapping 580 5.1.1. Bootstrapping for Registries 582 5.1.1.1. Credentials 584 Each Registry Operator will receive authentication credentials from 585 the TMDB to be used: 587 o During the Sunrise Period to fetch the SMD Revocation List from 588 the TMBD via the sy interface (Section 4.3.11). 590 o During the Trademark Claims Period to fetch the DNL List from the 591 TMDB via the dy interface (Section 4.3.3). 593 o During the NORDN process to notify the LORDN to the TMDB via the 594 yd interface (Section 4.3.7). 596 Note: credentials are created per TLD and provided to the Registry 597 Operator. 599 5.1.1.2. IP Addresses for Access Control 601 Each Registry Operator MUST provide to the TMDB all IP addresses that 602 will be used to: 604 o Fetch the SMD Revocation List via the sy interface 605 (Section 4.3.11). 607 o Fetch the DNL List from the TMDB via the dy interface 608 (Section 4.3.3). 610 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 612 This access restriction MAY be applied by the TMDB in addition to 613 HTTP Basic access authentication (see [RFC7235]). For credentials to 614 be used, see Section 5.1.1.1. 616 The TMDB MAY limit the number of IP addresses to be accepted per 617 Registry Operator. 619 5.1.1.3. ICANN TMCH Trust Anchor 621 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 622 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 623 tmch.crt > to be used: 625 o During the Sunrise Period to validate the TMV certificates and the 626 TMV CRL. 628 5.1.1.4. TMDB PGP Key 630 The TMDB MUST provide each Registry Operator with the public portion 631 of the PGP Key used by TMDB, to be used: 633 o During the Sunrise Period to perform integrity checking of the SMD 634 Revocation List fetched from the TMDB via the sy interface 635 (Section 4.3.11). 637 o During the Trademark Claims Period to perform integrity checking 638 of the DNL List fetched from the TMDB via the dy interface 639 (Section 4.3.3). 641 5.1.2. Bootstrapping for Registrars 643 5.1.2.1. Credentials 645 Each ICANN-accredited Registrar will receive authentication 646 credentials from the TMDB to be used: 648 o During the Sunrise Period to (optionally) fetch the SMD Revocation 649 List from the TMDB via the sr interface (Section 4.3.12). 651 o During the Trademark Claims Period to fetch TCNs from the TMDB via 652 the dr interface (Section 4.3.6). 654 5.1.2.2. IP Addresses for Access Control 656 Each Registrar MUST provide to the TMDB all IP addresses, which will 657 be used to: 659 o Fetch the SMD Revocation List via the sr interface 660 (Section 4.3.12). 662 o Fetch TCNs via the dr interface (Section 4.3.6). 664 This access restriction MAY be applied by the TMDB in addition to 665 HTTP Basic access authentication (for credentials to be used, see 666 Section 5.1.2.1). 668 The TMDB MAY limit the number of IP addresses to be accepted per 669 Registrar. 671 5.1.2.3. ICANN TMCH Trust Anchor 673 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 674 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 676 o During the Sunrise Period to (optionally) validate the TMV 677 certificates and TMV CRL. 679 5.1.2.4. TMDB PGP Key 681 Registrars MUST receive the public portion of the PGP Key used by 682 TMDB from the TMDB administrator to be used: 684 o During the Sunrise Period to (optionally) perform integrity 685 checking of the SMD Revocation List fetched from the TMDB via the 686 sr interface (Section 4.3.12). 688 5.2. Sunrise Period 690 5.2.1. Domain Name registration 692 Domain Name registration during the Sunrise Period 694 .------------. .-----------. .----------. 695 | Registrant | | Registrar | | Registry | 696 '------------' '-----------' '----------' 697 | | | 698 | Request DN | | 699 | registration | | 700 | (with SMD) | | 701 |---------------->| Check DN availability | 702 | |---------------------------->| 703 | | | 704 | | DN unavailable .-------------. 705 | DN unavailable |<--------------------( DN available? ) 706 |<----------------| no '-------------' 707 | | | yes 708 | | DN available | 709 | |<----------------------------| 710 | | | 711 | | Request DN registration | 712 | | (with SMD) | 713 | |---------------------------->| 714 | | | 715 | | .------------------------------. 716 | | | DN registration validation / | 717 | | | SMD validation | 718 | | '------------------------------' 719 | | | 720 | Registration |.-----------. Error .----------------------. 721 | error || TRY AGAIN |<-----( Validation successful? ) 722 |<----------------|| / ABORT | no '----------------------' 723 | |'-----------' | yes 724 | | | 725 | | DN registered | 726 | DN registered |<----------------------------| 727 |<----------------| | 728 | | | 730 Figure 3 732 Note: the figure depicted above represents a synchronous DN 733 registration workflow (usually called first come first served). 735 5.2.2. Sunrise Domain Name registration by Registries 737 Registries MUST perform a minimum set of checks for verifying each DN 738 registration during the Sunrise Period upon reception of a 739 registration request over the ry interface (Section 4.3.5). If any 740 of these checks fails the Registry MUST abort the registration. Each 741 of these checks MUST be performed before the DN is effectively 742 allocated. 744 In case of asynchronous registrations (e.g. auctions), the minimum 745 set of checks MAY be performed when creating the intermediate object 746 (e.g. a DN application) used for DN registration. If the minimum set 747 of checks is performed when creating the intermediate object (e.g. a 748 DN application) a Registry MAY effectively allocate the DN without 749 performing the minimum set of checks again. 751 Performing the minimum set of checks Registries MUST verify that: 753 1. An SMD has been received from the Registrar along with the DN 754 registration. 756 2. The certificate of the TMV has been correctly signed by the ICANN 757 TMCH-CA. (The certificate of the TMV is contained within the 758 SMD.) 760 3. The datetime when the validation is done is within the validity 761 period of the TMV certificate. 763 4. The certificate of the TMV is not listed in the TMV CRL file 764 specified in the CRL distribution point of the TMV certificate. 766 5. The signature of the SMD (signed with the TMV certificate) is 767 valid. 769 6. The datetime when the validation is done is within the validity 770 period of the SMD based on and 771 elements. 773 7. The SMD has not been revoked, i.e., is not contained in the SMD 774 Revocation List. 776 8. The leftmost DNL of the DN being effectively allocated matches 777 one of the labels () elements in the SMD. For 778 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 779 effectively allocated, the leftmost DNL would be "xn--mgbachtv". 781 These procedure apply to all DN effective allocations at the second 782 level as well as to all other levels subordinate to the TLD that the 783 Registry accepts registrations for. 785 5.2.3. TMDB Sunrise Services for Registries 787 5.2.3.1. SMD Revocation List 789 A new SMD Revocation List MUST be published by the TMDB twice a day, 790 by 00:00:00 and 12:00:00 UTC. 792 Registries MUST refresh the latest version of the SMD Revocation List 793 at least once every 24 hours. 795 Note: the SMD Revocation List will be the same regardless of the TLD. 796 If a Backend Registry Operator manages the infrastructure of several 797 TLDs, the Backend Registry Operator could refresh the SMD Revocation 798 List once every 24 hours, the SMD Revocation List could be used for 799 all the TLDs managed by the Backend Registry Operator. 801 Update of the SMD Revocation List 803 .----------. .------. 804 | Registry | | TMDB | 805 '----------' '------' 806 | | 807 .----------------. | 808 | Periodically, | | 809 | at least | | 810 | every 24 hours | | 811 '----------------' | 812 | | 813 |----------------------------------------------------->| 814 | Download the latest SMD Revocation List | 815 |<-----------------------------------------------------| 816 | | 817 | | 819 Figure 4 821 5.2.3.2. TMV Certificate Revocation List (CRL) 823 Registries MUST refresh their local copy of the TMV CRL file at least 824 every 24 hours using the CRL distribution point specified in the TMV 825 certificate. 827 Operationally, the TMV CRL file and CRL distribution point is the 828 same for all TMVs and (at publication of this document) located at < 829 http://crl.icann.org/tmch.crl >. 831 Note: the TMV CRL file will be the same regardless of the TLD. If a 832 Backend Registry Operator manages the infrastructure of several TLDs, 833 the Backend Registry Operator could refresh the TMV CRL file once 834 every 24 hours, the TMV CRL file could be used for all the TLDs 835 managed by the Backend Registry Operator. 837 Update of the TMV CRL file 839 .----------. .---------------. 840 | Registry | | ICANN TMCH-CA | 841 '----------' '---------------' 842 | | 843 .----------------. | 844 | Periodically, | | 845 | at least | | 846 | every 24 hours | | 847 '----------------' | 848 | | 849 |-------------------------------------------->| 850 | Download the latest TMV CRL file | 851 |<--------------------------------------------| 852 | | 853 | | 855 Figure 5 857 5.2.3.3. Notice of Registered Domain Names (NORN) 859 The Registry MUST send a LORDN file containing DNs effectively 860 allocated to the TMDB (over the yd interface, Section 4.3.7). 862 The effective allocation of a DN MUST be reported by the Registry to 863 the TMDB within 26 hours of the effective allocation of such DN. 865 The Registry MUST create and upload a LORDN file in case there are 866 effective allocations in the SRS, that have not been successfully 867 reported to the TMDB in a previous LORDN file. 869 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 870 maximum frequency to upload LORDN files from the Registries to the 871 TMDB is every 3 hours. 873 It is RECOMMENDED that Registries try to upload at least two LORDN 874 files per day to the TMDB with enough time in between, in order to 875 have time to fix problems reported in the LORDN file. 877 The Registry SHOULD upload a LORDN file only when the previous LORDN 878 file has been processed by the TMDB and the related LORDN Log file 879 has been downloaded and processed by the Registry. 881 The Registry MUST upload LORDN files for DNs effectively allocated 882 during the Sunrise or Trademark Claims Period (same applies to DNs 883 effectively allocated using applications created during the Sunrise 884 or Trademark Claims Period in case of using asynchronous 885 registrations). 887 The yd interface (Section 4.3.7) MUST support at least one (1) and 888 MAY support up to ten (10) concurrent connections from each IP 889 address registered by a Registry Operator to access the service. 891 The TMDB MUST process each uploaded LORDN file and make the related 892 log file available for Registry download within 30 minutes of the 893 finalization of the upload. 895 Notification of Registered Domain Name 897 .----------. .------. .-----. .-----. 898 | Registry | | TMDB | | TMV | | TMH | 899 '----------' '------' '-----' '-----' 900 | | | | 901 .------------------. | | | 902 | Periodically | | | | 903 | upload LORDN | | | | 904 | file | | | | 905 '------------------' | | | 906 | | | | 907 .--------->| Upload LORDN | | | 908 | |-------------------->| | | 909 | | | | | 910 | | .-------------------------. | | 911 | | | Verify each domain name | | | 912 | | | in the uploaded file | | | 913 | | | (within 30') | | | 914 | | '-------------------------' | | 915 | | | ._____.| | 916 | | Download Log file | | END || | 917 | |<--------------------| '-----'| | 918 | | | ^ | | 919 | .-----------------. .---------------. | | | 920 | | Check whether | / everything fine \ no | | | 921 | | Log file | ( (i.e. no errors )---' | | 922 | | contains errors | \ in Log file )? / | | 923 | '-----------------' '---------------' | | 924 | | | yes | | 925 | .---------------. | | | 926 | / everything fine \ yes | | | 927 |( (i.e. no errors )-----. | Notify TMVs | | 928 | \ in Log file )? / | | on the LORDN | | 929 | '---------------' | | pre-registered | | 930 | | no v | with said TMV | | 931 | .----------------. .------. |--------------->| | 932 '-| Correct Errors | | DONE | | | | 933 '----------------' '------' | | Notify each | 934 | | | affected TMH | 935 | | |-------------->| 936 | | | | 938 Figure 6 940 The format used for the LORDN is described in Section 6.3 942 5.2.4. Sunrise Domain Name registration by Registrars 944 Registrars MAY choose to perform the checks for verifying DN 945 registrations as performed by the Registries (see Section 5.2.2) 946 before sending the command to register a DN. 948 5.2.5. TMDB Sunrise Services for Registrars 950 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 951 also available for Registrars to optionally validate the SMDs 952 received. 954 5.3. Trademark Claims Period 956 5.3.1. Domain Registration 958 Domain Name registration during the Trademark Claims Period 960 .------------. .-----------. .----------. .------. 961 | Registrant | | Registrar | | Registry | | TMDB | 962 '------------' '-----------' '----------' '------' 963 | Request DN | | | 964 | registration | | | 965 |--------------->| Check DN availability | | 966 | |--------------------------->| | 967 | | DN unavailable .-------------. | 968 | DN unavailable |<-------------------( DN available? ) | 969 |<---------------| no '-------------' | 970 | | DN available | yes | 971 | |<---------------------------| | 972 | | Request Lookup key | | 973 | |--------------------------->| | 974 | |.__________. .---------. | 975 | || CONTINUE | / Does DN \ | 976 | || NORMALLY |<--------( match DNL ) | 977 | |'----------' no \ of PRM? / | 978 | | '---------' | 979 | | Lookup key | yes | 980 | |<----------------------------' | 981 | | | 982 .-----. | | Request TCN | 983 |ABORT| | Display |---------------------------------------->| 984 '-----' | Claims | Return TCN | 985 ^ | Notice |<----------------------------------------| 986 | no |<---------------| | 987 | .------. yes | | 988 '-( Ack? )----------->| Register DN (with TCNID) | | 989 '------' |--------------------------->| | 990 | Registration | Error .----------------------. | 991 | error |<-------------( Validation successful? ) | 992 |<---------------| no '----------------------' | 993 | | | yes | 994 | | DN registered | | 995 | DN registered |<---------------------------| | 996 |<---------------| | | 998 Figure 7 1000 Note: the figure depicted above represents a synchronous DN 1001 registration workflow (usually called first come first served). 1003 5.3.2. Trademark Claims Domain Name registration by Registries 1005 During the Trademark Claims Period, Registries perform two main 1006 functions: 1008 o Registries MUST provide Registrars (over the ry interface, 1009 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1010 that match the DNL List. 1012 o Registries MUST provide the Lookup Key only when queried about a 1013 specific DN. 1015 o For each DN matching a DNL of a PRM, Registries MUST perform a 1016 minimum set of checks for verifying DN registrations during the 1017 Trademark Claims Period upon reception of a registration request 1018 over the ry interface (Section 4.3.5). If any of these checks 1019 fails the Registry MUST abort the registration. Each of these 1020 checks MUST be performed before the DN is effectively allocated. 1022 o In case of asynchronous registrations (e.g. auctions), the minimum 1023 set of checks MAY be performed when creating the intermediate 1024 object (e.g. a DN application) used for DN effective allocation. 1025 If the minimum set of checks is performed when creating the 1026 intermediate object (e.g. a DN application) a Registry MAY 1027 effectively allocate the DN without performing the minimum set of 1028 checks again. 1030 o Performing the minimum set of checks Registries MUST verify that: 1032 1. The TCNID (), expiration datetime 1033 () and acceptance datetime of the TCN, have 1034 been received from the Registrar along with the DN 1035 registration. 1037 If the three elements mentioned above are not provided by 1038 the Registrar for a DN matching a DNL of a PRM, but the DNL 1039 was inserted (or re-inserted) for the first time into DNL 1040 List less than 24 hours ago, the registration MAY continue 1041 without this data and the tests listed below are not 1042 required to be performed. 1044 2. The TCN has not expired (according to the expiration datetime 1045 sent by the Registrar). 1047 3. The acceptance datetime is within the window of time defined 1048 by ICANN policy. In the gTLD round of 2012, Registrars 1049 verified that the acceptance datetime was less than or equal 1050 to 48 hours in the past, as there were no defined ICANN 1051 policies at that time. Implementers should be aware that 1052 ICANN policy may define this value in the future. 1054 4. Using the leftmost DNL of the DN being effectively allocated, 1055 the expiration datetime provided by the Registrar, and the 1056 TMDB Notice Identifier extracted from the TCNID provided by 1057 the Registrar compute the TCN Checksum. Verify that the 1058 computed TCN Checksum match the TCN Checksum present in the 1059 TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is 1060 being effectively allocated, the leftmost DNL would be "xn-- 1061 mgbachtv". 1063 These procedures apply to all DN registrations at the second level as 1064 well as to all other levels subordinate to the TLD that the Registry 1065 accepts registrations for. 1067 5.3.3. TMBD Trademark Claims Services for Registries 1069 5.3.3.1. Domain Name Label (DNL) List 1071 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1072 and 12:00:00 UTC. 1074 Registries MUST refresh the latest version of the DNL List at least 1075 once every 24 hours. 1077 Update of the DNL List 1079 .----------. .------. 1080 | Registry | | TMDB | 1081 '----------' '------' 1082 | | 1083 .----------------. | 1084 | Periodically, | | 1085 | at least | | 1086 | every 24 hours | | 1087 '----------------' | 1088 | | 1089 |-------------------------------->| 1090 | Download the latest DNL List | 1091 |<--------------------------------| 1092 | | 1093 | | 1095 Figure 8 1097 Note: the DNL List will be the same regardless of the TLD. If a 1098 Backend Registry Operator manages the infrastructure of several TLDs, 1099 the Backend Registry Operator could refresh the DNL List once every 1100 24 hours, the DNL List could be used for all the TLDs managed by the 1101 Backend Registry Operator. 1103 5.3.3.2. Notice of Registered Domain Names (NORN) 1105 The NORDN process during the Trademark Claims Period is almost the 1106 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1107 difference that only registrations subject to a Trademark Claim 1108 (i.e., at registration time the name appeared in the current DNL List 1109 downloaded by the Registry Operator) are included in the LORDN. 1111 5.3.4. Trademark Claims Domain Name registration by Registrars 1113 For each DN matching a DNL of a PRM, Registrars MUST perform the 1114 following steps: 1116 1. Use the Lookup Key received from the Registry to obtain the TCN 1117 from the TMDB using the dr interface (Section 4.3.6) Registrars 1118 MUST only query for the Lookup Key of a DN that is available for 1119 registration. 1121 2. Present the TCN to the Registrant as described in Exhibit A, 1122 [RPM-Requirements]. 1124 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1125 consent with the TCN, before any further processing. (The 1126 transmission of a TCNID to the Registry over the ry interface, 1127 Section 4.3.5 implies that the Registrant has expressed his/her 1128 consent with the TCN.) 1130 4. Perform the minimum set of checks for verifying DN registrations. 1131 If any of these checks fails the Registrar MUST abort the DN 1132 registration. Each of these checks MUST be performed before the 1133 registration is sent to the Registry. Performing the minimum set 1134 of checks Registrars MUST verify that: 1136 1. The datetime when the validation is done is within the TCN 1137 validity based on the and 1138 elements. 1140 2. The leftmost DNL of the DN being effectively allocated 1141 matches the label () element in the TCN. For 1142 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 1143 effectively allocated, the leftmost DNL would be "xn-- 1144 mgbachtv". 1146 3. The Registrant has acknowledged (expressed his/her consent 1147 with) the TCN. 1149 5. Record the date and time when the registrant acknowledged the 1150 TCN. 1152 6. Send the registration to the Registry (ry interface, 1153 Section 4.3.5) and include the following information: 1155 * TCNID () 1157 * Expiration date of the TCN () 1159 * Acceptance datetime of the TCN. 1161 Currently TCNs are generated twice a day by the TMDB. The expiration 1162 date () of each TCN MUST be set to a value defined 1163 by ICANN policy. In the gTLD round of 2012, the TMDB set the 1164 expiration value to 48 hours in to the future as there were no 1165 defined ICANN policies at that time. Implementers should be aware 1166 that ICANN policy may define this value in the future. 1168 Registrars SHOULD implement a cache of TCNs to minimize the number of 1169 queries sent to the TMDB. A cached TCN MUST be removed from the 1170 cache after the expiration date of the TCN as defined by 1171 . 1173 The TMDB MAY implement rate-limiting as one of the protection 1174 mechanisms to mitigate the risk of performance degradation. 1176 5.3.5. TMBD Trademark Claims Services for Registrars 1178 5.3.5.1. Claims Notice Information Service (CNIS) 1180 The TCNs are provided by the TMDB online and are fetched by the 1181 Registrar via the dr interface (Section 4.3.6). 1183 To get access to the TCNs, the Registrar needs the credentials 1184 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1185 from the Registry via the ry interface (Section 4.3.5). The dr 1186 interface (Section 4.3.6) uses HTTPS with Basic access 1187 authentication. 1189 The dr interface (Section 4.3.6) MAY support up to ten (10) 1190 concurrent connections from each Registrar. 1192 The URL of the dr interface (Section 4.3.6) is: 1194 < https:///cnis/.xml > 1196 Note that the "lookupkey" may contain SLASH characters ("/"). The 1197 SLASH character is part of the URL path and MUST NOT be escaped when 1198 requesting the TCN. 1200 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1201 MUST be signed by a well-know public CA. Registrars MUST perform the 1202 Certification Path Validation described in Section 6 of [RFC5280]. 1203 Registrars will be authenticated in the dr interface using HTTP Basic 1204 access authentication. The dr (Section 4.3.6) interface MUST support 1205 HTTPS keep-alive and MUST maintain the connection for up to 30 1206 minutes. 1208 5.4. Qualified Launch Program (QLP) Period 1210 5.4.1. Domain Registration 1212 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1213 (QLP) Period effective allocations of DNs to third parties could 1214 require that Registries and Registrars provide Sunrise and/or 1215 Trademark Claims services. If required, Registries and Registrars 1216 MUST provide Sunrise and/or Trademark Claims services as described in 1217 Section 5.2 and Section 5.3. 1219 The effective allocation scenarios are: 1221 o If the leftmost DNL of the DN being effectively allocated (QLP 1222 Name in this section) matches a DNL in the SURL, and an SMD is 1223 provided, then Registries MUST provide Sunrise Services (see 1224 Section 5.2) and the DN MUST be reported in a Sunrise LORDN file 1225 during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- 1226 mgbh0fb" is being effectively allocated, the leftmost DNL would be 1227 "xn--mgbachtv". 1229 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1230 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1231 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1232 file using the special SMD-id "99999-99999" during the QLP Period. 1234 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1235 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1236 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1237 services (see Section 5.3) and the DN MUST be reported in a 1238 Trademark Claims LORDN file during the QLP Period. 1240 o If the QLP Name matches a DNL in the DNL List but does not match a 1241 DNL in the SURL, then Registries MUST provide Trademark Claims 1242 services (see Section 5.2) and the DN MUST be reported in a 1243 Trademark Claims LORDN file during the QLP Period. 1245 The following table lists all the effective allocation scenarios 1246 during a QLP Period: 1248 +--------+---------+-----------------+--------------+---------------+ 1249 | QLP | QLP | SMD was | Registry | Registry MUST | 1250 | Name | Name | provided by the | MUST provide | report DN | 1251 | match | match | potential | Sunrise or | registration | 1252 | in the | in the | Registrant | Trademark | in | 1253 | SURL | DNL | | Claims | LORDN file | 1254 | | List | | Services | | 1255 +--------+---------+-----------------+--------------+---------------+ 1256 | Y | Y | Y | Sunrise | Sunrise | 1257 | | | | | | 1258 | Y | N | Y | Sunrise | Sunrise | 1259 | | | | | | 1260 | N | Y | -- | Trademark | Trademark | 1261 | | | | Claims | Claims | 1262 | | | | | | 1263 | N | N | -- | -- | -- | 1264 | | | | | | 1265 | Y | Y | N (see section | Trademark | Trademark | 1266 | | | 2.2 of | Claims | Claims | 1267 | | | [QLP-Addendum]) | | | 1268 | | | | | | 1269 | Y | N | N (see section | -- | Sunrise | 1270 | | | 2.2 of | | (using | 1271 | | | [QLP-Addendum]) | | special SMD- | 1272 | | | | | id) | 1273 +--------+---------+-----------------+--------------+---------------+ 1275 QLP Effective Allocation Scenarios 1277 The TMDB MUST provide the following services to Registries during a 1278 QLP Period: 1280 o SMD Revocation List (see Section 5.2.3.1) 1282 o NORN (see Section 5.2.3.3) 1284 o DNL List (see Section 5.3.3.1) 1286 o Sunrise List (SURL) (see Section 5.4.2.1 1288 The TMDB MUST provide the following services to Registrars during a 1289 QLP Period: 1291 o SMD Revocation List (see Section 5.2.3.1) 1292 o CNIS (see Section 5.3.5.1) 1294 5.4.2. TMBD QLP Services for Registries 1296 5.4.2.1. Sunrise List (SURL) 1298 A new Sunrise List (SURL) MUST be published by the TMDB twice a day, 1299 by 00:00:00 and 12:00:00 UTC. 1301 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1302 version of the SURL at least once every 24 hours. 1304 Update of the SURL 1306 .----------. .------. 1307 | Registry | | TMDB | 1308 '----------' '------' 1309 | | 1310 .----------------. | 1311 | Periodically, | | 1312 | at least | | 1313 | every 24 hours | | 1314 '----------------' | 1315 | | 1316 |------------------------------->| 1317 | Download the latest SURL | 1318 |<-------------------------------| 1319 | | 1320 | | 1322 Figure 9 1324 Note: the SURL will be the same regardless of the TLD. If a Backend 1325 Registry Operator manages the infrastructure of several TLDs, the 1326 Backend Registry Operator could refresh the SURL once every 24 hours, 1327 the SURL could be used for all the TLDs managed by the Backend 1328 Registry Operator. 1330 6. Data Format Descriptions 1332 6.1. Domain Name Label (DNL) List 1334 This section defines the format of the list containing every Domain 1335 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1336 is maintained by the TMDB and downloaded by Registries in regular 1337 intervals (see Section 5.3.3.1). The Registries use the DNL List 1338 during the Trademark Claims Period to check whether a requested DN 1339 matches a DNL of a PRM. 1341 The DNL List contains all the DNLs covered by a PRM present in the 1342 TMDB at the datetime it is generated. 1344 The DNL List is contained in a CSV formatted file that has the 1345 following structure: 1347 o first line: , 1349 Where: 1351 + , version of the file, this field MUST be 1. 1353 + , date and time in UTC that the 1354 DNL List was created. 1356 o second line: a header line as specified in [RFC4180] 1358 With the header names as follows: 1360 DNL,lookup-key,insertion-datetime 1362 o One or more lines with: ,, 1365 Where: 1367 + , a Domain Name Label covered by a PRM. 1369 + , lookup key that the Registry MUST provide to 1370 the Registrar. The lookup key has the following format: 1371
////, where: 1374 - YYYY: year that the TCN was generated. 1376 - MM: zero-padded month that the TCN was generated. 1378 - DD: zero-padded day that the TCN was generated. 1380 - vv: version of the TCN, possible values are 00 and 01. 1382 - X: one hex character. This is the first, second and 1383 third hex character of encoding the in 1384 base16 as specified in [RFC4648]. 1386 - Random bits: 144 random bits encoded in base64url as 1387 specified in [RFC4648]. 1389 - Sequential number: zero-padded natural number in the 1390 range 0000000001 to 2147483647. 1392 + , datetime in UTC that the DNL was 1393 first inserted into the DNL List. The possible two values 1394 of time for inserting a DNL to the DNL List are 00:00:00 and 1395 12:00:00 UTC. 1397 Example of a DNL List 1399 1,2012-08-16T00:00:00.0Z 1400 DNL,lookup-key,insertion-datetime 1401 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1402 2010-07-14T00:00:00.0Z 1403 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1404 2012-08-16T00:00:00.0Z 1405 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1406 2011-08-16T12:00:00.0Z 1408 Figure 10 1410 To provide authentication and integrity protection, the DNL List will 1411 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1412 PGP signature of the DNL List can be found in the similar URI but 1413 with extension .sig as shown below. 1415 The URL of the dy interface (Section 4.3.3) is: 1417 o < https:///dnl/dnl-latest.csv > 1419 o < https:///dnl/dnl-latest.sig > 1421 6.2. SMD Revocation List 1423 This section defines the format of the list of SMDs that have been 1424 revoked. The list is maintained by the TMDB and downloaded by 1425 Registries (and optionally by Registrars) in regular intervals (see 1426 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1427 Period to validate SMDs received. The SMD Revocation List has a 1428 similar function as CRLs used in PKI [RFC5280]. 1430 The SMD Revocation List contains all the revoked SMDs present in the 1431 TMDB at the datetime it is generated. 1433 The SMD Revocation List is contained in a CSV formatted file that has 1434 the following structure: 1436 o first line: , 1438 Where: 1440 + , version of the file, this field MUST be 1. 1442 + , datetime in UTC 1443 that the SMD Revocation List was created. 1445 o second line: a header line as specified in [RFC4180] 1447 With the header names as follows: 1449 smd-id,insertion-datetime 1451 o One or more lines with: , 1453 Where: 1455 + , identifier of the SMD that was revoked. 1457 + , revocation datetime in UTC of the 1458 SMD. The possible two values of time for inserting an SMD 1459 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1461 To provide integrity protection, the SMD Revocation List is PGP 1462 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1463 List is provided by the TMDB with extension .csv. The PGP signature 1464 of the SMD Revocation List can be found in the similar URI but with 1465 extension .sig as shown below. 1467 The URL of the sr interface (Section 4.3.12) and sy interface 1468 (Section 4.3.11) is: 1470 o < https:///smdrl/smdrl-latest.csv > 1472 o < https:///smdrl/smdrl-latest.sig > 1473 Example of an SMD Revocation List 1475 1,2012-08-16T00:00:00.0Z 1476 smd-id,insertion-datetime 1477 2-2,2012-08-15T00:00:00.0Z 1478 3-2,2012-08-15T00:00:00.0Z 1479 1-2,2012-08-15T00:00:00.0Z 1481 Figure 11 1483 6.3. List of Registered Domain Names (LORDN) file 1485 This section defines the format of the List of Registered Domain 1486 Names (LORDN), which is maintained by each Registry and uploaded at 1487 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1488 said DN is added to the LORDN along with further information related 1489 to its registration. 1491 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1492 file is: 1494 o Sunrise LORDN file: 1496 < https:///LORDN//sunrise > 1498 o Trademark Claims LORDN file: 1500 < https:///LORDN//claims > 1502 During a QLP Period, Registries MAY be required to upload Sunrise or 1503 Trademark Claims LORDN files. The URIs of the yd interface used to 1504 upload LORDN files during a QLP Period is: 1506 o Sunrise LORDN file (during QLP Period): 1508 < https:///LORDN//sunrise/qlp > 1510 o Trademark Claims LORDN file (during a QLP Period): 1512 < https:///LORDN//claims/qlp > 1514 The yd interface (Section 4.3.7) returns the following HTTP status 1515 codes after a HTTP POST request method is received: 1517 o The interface provides a HTTP/202 status code if the interface was 1518 able to receive the LORDN file and the syntax of the LORDN file is 1519 correct. 1521 The interface provides the LORDN Transaction Identifier in the 1522 HTTP Entity-body that would be used by the Registry to download 1523 the LORDN Log file. The LORDN Transaction Identifier is a 1524 natural number zero-padded in the range 0000000000000000001 to 1525 9223372036854775807. 1527 The TMDB uses the element of the 1528 LORDN file as a unique client-side identifier. If a LORDN file 1529 with the same of a previously sent 1530 LORDN file is received by the TMDB, the LORDN Transaction 1531 Identifier of the previously sent LORDN file MUST be provided 1532 to the Registry. The TMDB MUST ignore the DN Lines present in 1533 the LORDN file if a LORDN file with the same was previously sent. 1536 The HTTP Location header field contains the URI where the LORDN 1537 Log file could be retrieved later, for example: 1539 202 Accepted 1541 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1544 o The interface provides a HTTP/400 if the request is incorrect or 1545 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1546 human readable message in the HTTP Entity-body regarding the 1547 incorrect syntax of the LORDN file. 1549 o The interface provides a HTTP/401 status code if the credentials 1550 provided does not authorize the Registry Operator to upload a 1551 LORDN file. 1553 o The TMDB MUST return a HTTP/404 status code when trying to upload 1554 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1557 plus 26 hours. 1559 o The interface provides a HTTP/500 status code if the system is 1560 experiencing a general failure. 1562 For example, to upload the Sunrise LORDN file for TLD "example", the 1563 URI would be: 1565 < https:///LORDN/example/sunrise > 1567 The LORDN is contained in a CSV formatted file that has the following 1568 structure: 1570 o For Sunrise Period: 1572 * first line: ,, 1575 Where: 1577 - , version of the file, this field MUST be 1. 1579 - , date and time in UTC that the 1580 LORDN was created. 1582 - , number of DN Lines present in the 1583 LORDN file. 1585 * second line: a header line as specified in [RFC4180] 1587 With the header names as follows: 1589 roid,domain-name,SMD-id,registrar-id,registration- 1590 datetime,application-datetime 1592 * One or more lines with: ,,,,, 1596 Where: 1598 - , DN Repository Object IDentifier (DNROID) in the 1599 SRS. 1601 - , DN that was effectively allocated. For 1602 IDNs, the A-label form is used. 1604 - , SMD ID used for registration. 1606 - , IANA Registrar ID. 1608 - , date and time in UTC that the 1609 domain was effectively allocated. 1611 - OPTIONAL , date and 1612 time in UTC that the application was created. The 1613 MUST be provided in 1614 case of a DN effective allocation based on an 1615 asynchronous registration (e.g., when using auctions). 1617 Example of a Sunrise LORDN file 1619 1,2012-08-16T00:00:00.0Z,3 1620 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1621 application-datetime 1622 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1623 2012-07-15T00:50:00.0Z 1624 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1625 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1627 Figure 12 1629 o For Trademark Claims Period: 1631 * first line: ,, 1634 Where: 1636 - , version of the file, this field MUST be 1. 1638 - , date and time in UTC that the 1639 LORDN was created. 1641 - , number of DN Lines present in the 1642 LORDN file. 1644 * second line: a header line as specified in [RFC4180] 1646 With the header names as follows: 1648 roid,domain-name,notice-id,registrar-id,registration- 1649 datetime,ack-datetime,application-datetime 1651 * One or more lines with: ,,,,,, 1655 Where: 1657 - , DN Repository Object IDentifier (DNROID) in the 1658 SRS. 1660 - , DN that was effectively allocated. For 1661 IDNs, the A-label form is used. 1663 - , Trademark Claims Notice Identifier as specified 1664 in . 1666 - , IANA Registrar ID. 1668 - , date and time in UTC that the 1669 domain was effectively allocated. 1671 - , date and time in UTC 1672 that the TCN was acknowledged. 1674 - OPTIONAL , date and 1675 time in UTC that the application was created. The 1676 MUST be provided in 1677 case of a DN effective allocation based on an 1678 asynchronous registration (e.g., when using auctions). 1680 For a DN matching a DNL of a PRM at the moment of 1681 registration, created without the TCNID, expiration datetime 1682 and acceptance datetime, because DNL was inserted (or re- 1683 inserted) for the first time into DNL List less than 24 1684 hours ago, the string "recent-dnl-insertion" MAY be 1685 specified in and . 1688 Example of a Trademark Claims LORDN file 1690 1,2012-08-16T00:00:00.0Z,3 1691 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1692 ack-datetime,application-datetime 1693 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1694 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1695 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1696 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1697 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1698 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1700 Figure 13 1702 6.3.1. LORDN Log file 1704 After reception of the LORDN file, the TMDB verifies its content for 1705 syntactical and semantical correctness. The output of the LORDN file 1706 verification is retrieved using the yd interface (Section 4.3.7). 1708 The URI of the yd interface (Section 4.3.7) used to retrieve the 1709 LORDN Log file is: 1711 o Sunrise LORDN Log file: 1713 < https:///LORDN//sunrise//result > 1716 o Trademark Claims LORDN Log file: 1718 < https:///LORDN//claims//result > 1721 A Registry Operator MUST NOT send more than one request per minute 1722 per TLD to download a LORDN Log file. 1724 The yd interface (Section 4.3.7) returns the following HTTP status 1725 codes after a HTTP GET request method is received: 1727 o The interface provides a HTTP/200 status code if the interface was 1728 able to provide the LORDN Log file. The LORDN Log file is 1729 contained in the HTTP Entity-body. 1731 o The interface provides a HTTP/204 status code if the LORDN 1732 Transaction Identifier is correct, but the server has not 1733 finalized processing the LORDN file. 1735 o The interface provides a HTTP/400 status code if the request is 1736 incorrect. 1738 o The interface provides a HTTP/401 status code if the credentials 1739 provided does not authorize the Registry Operator to download the 1740 LORDN Log file. 1742 o The interface provides a HTTP/404 status code if the LORDN 1743 Transaction Identifier is incorrect. 1745 o The interface provides a HTTP/500 status code if the system is 1746 experiencing a general failure. 1748 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1749 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1750 "example" the URI would be: 1752 < https:///LORDN/example/sunrise/0000000000000000001/result > 1755 The LORDN Log file is contained in a CSV formatted file that has the 1756 following structure: 1758 o first line: ,,,,,, 1762 Where: 1764 + , version of the file, this field MUST be 1. 1766 + , date and time in UTC that the 1767 LORDN Log was created. 1769 + , date and time in UTC of 1770 creation for the LORDN file that this log file is referring 1771 to. 1773 + , unique identifier of the LORDN Log 1774 provided by the TMDB. This identifier could be used by the 1775 Registry Operator to unequivocally identify the LORDN Log. 1776 The identified will be a string of a maximum LENGTH of 60 1777 characters from the Base 64 alphabet. 1779 + , whether the LORDN file has been accepted for 1780 processing by the TMDB. Possible values are "accepted" or 1781 "rejected". 1783 + , whether the LORDN Log has any warning result 1784 codes. Possible values are "no-warnings" or "warnings- 1785 present". 1787 + , number of DNs effective allocations 1788 processed in the LORDN file. 1790 A Registry Operator is not required to process a LORDN Log with 1791 a ="accepted" and ="no-warnings". 1793 o second line: a header line as specified in [RFC4180] 1795 With the header names as follows: 1797 roid,result-code 1799 o One or more lines with: , 1801 Where: 1803 + , DN Repository Object IDentifier (DNROID) in the SRS. 1805 + , result code as described in Section 6.3.1.1. 1807 Example of a LORDN Log file 1809 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1810 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1811 accepted,no-warnings,1 1812 roid,result-code 1813 SH8013-REP,2000 1815 Figure 14 1817 6.3.1.1. LORDN Log Result Codes 1819 In Figure 15 the classes of result codes (rc) are listed. Those 1820 classes in square brackets are not used at this time, but may come 1821 into use at some later stage. The first two digits of a result code 1822 denote the result code class, which defines the outcome at the TMDB: 1824 o ok: Success, DN Line accepted by the TMDB. 1826 o warn: a warning is issued, DN Line accepted by the TMDB. 1828 o err: an error is issued, LORDN file rejected by the TMDB. 1830 In case that after processing a DN Line, the error result code is 1831 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1832 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1833 valid will be reported with a 2001 result code. A 2001 result code 1834 means that the DN Line is syntactically valid, however the DN Line 1835 was not processed because the LORDN file was rejected. All DNs 1836 reported in a rejected LORDN file MUST be reported again by the 1837 Registry because none of the DN Lines present in the LORDN file have 1838 been processed by the TMDB. 1840 LORDN Log Result Code Classes 1842 code Class outcome 1843 ---- ----- ------- 1845 20xx Success ok 1847 35xx [ DN Line syntax warning ] warn 1848 36xx DN Line semantic warning warn 1850 45xx DN Line syntax error err 1851 46xx DN Line semantic error err 1853 Figure 15 1855 In the following, the LORDN Log result codes used by the TMDB are 1856 described: 1858 LORDN Log result Codes 1860 rc Short Description 1861 Long Description 1862 ---- ------------------------------------------------------------- 1864 2000 OK 1865 DN Line successfully processed. 1867 2001 OK but not processed 1868 DN Line is syntactically correct but was not processed 1869 because the LORDN file was rejected. 1871 3601 TCN Acceptance Date after Registration Date 1872 TCN Acceptance Date in DN Line is newer than the Registration 1873 Date. 1875 3602 Duplicate DN Line 1876 This DN Line is an exact duplicate of another DN Line in same 1877 file, DN Line ignored. 1879 3603 DNROID Notified Earlier 1880 Same DNROID has been notified earlier, DN Line ignored. 1882 3604 TCN Checksum invalid 1883 Based on the DN effectively allocated, the TCNID and the 1884 expiration date of the linked TCN, the TCN Checksum is 1885 invalid. 1887 3605 TCN Expired 1888 The TCN was already expired (based on the 1889 field of the TCN) at the datetime of acknowledgement. 1891 3606 Wrong TCNID used 1892 The TCNID used for the registration does not match 1893 the related DN. 1895 3609 Invalid SMD used 1896 The SMD used for registration was not valid at the moment of 1897 registration based on the and 1898 elements. 1899 In case of an asynchronous registration, this refer to the 1900 . 1902 3610 DN reported outside of the time window 1903 The DN was reported outside of the required 26 hours 1904 reporting window. 1906 3611 DN does not match the labels in SMD 1907 The DN does not match the labels included in the SMD. 1909 3612 SMDID does not exist 1910 The SMDID has never existed in the central repository. 1912 3613 SMD was revoked when used 1913 The SMD used for registration was revoked more than 1914 24 hours ago of the . 1915 In case of an asynchronous registration, 1916 the is used when 1917 validating the DN Line. 1919 3614 TCNID does not exist 1920 The TCNID has never existed in the central repository. 1922 3615 Recent-dnl-insertion outside of the time window 1923 The DN registration is reported as a recent-dnl-insertion, 1924 but the (re) insertion into the DNL occurred more than 1925 24 hours ago. 1927 3616 Registration Date of DN in Claims before the end of Sunrise Period 1928 The registration date of the DN is before the end of 1929 the Sunrise Period and the DN was reported in a 1930 Trademark Claims LORDN file. 1932 3617 Registrar has not been approved by the TMDB 1933 Registrar ID in DN Line has not completed Trademark Claims 1934 integration testing with the TMDB. 1936 3618 Registration Date of DN in QLP LORDN file out of the QLP Period 1937 The registration date of the DN in a QLP LORDN file is outside 1938 of the QLP Period. 1940 3619 TCN was not valid 1941 The TCN was not valid (based on the 1942 field of the TCN) at the datetime of acknowledgement. 1944 4501 Syntax Error in DN Line 1945 Syntax Error in DN Line. 1947 4601 Invalid TLD used 1948 The TLD in the DN Line does not match what is expected for 1949 this LORDN. 1951 4602 Registrar ID Invalid 1952 Registrar ID in DN Line is not a valid ICANN-Accredited 1953 Registrar. 1955 4603 Registration Date in the future 1956 The in the DN Line is in the 1957 future. 1959 4606 TLD not in Sunrise or Trademark Claims Period 1960 The was reported when the TLD was 1961 not in Sunrise or Trademark Claims Periods. 1962 In case of an asynchronous registration, 1963 the is used when 1964 validating the DN Line. 1966 4607 Application Date in the future 1967 The in the DN Line is in the 1968 future. 1970 4608 Application Date is later than Registration Date 1971 The in the DN Line is later 1972 than the . 1974 4609 TCNID wrong syntax 1975 The syntax of the TCNID is invalid. 1977 4610 TCN Acceptance Date is in the future 1978 The is in the future. 1980 4611 Label has never existed in the TMDB 1981 The label in the registered DN has never existed in the TMDB. 1983 Figure 16 1985 6.4. Signed Mark Data (SMD) File 1987 This section defines the format of the Signed Mark Data (SMD) File. 1988 After a successful registration of a mark, the TMV returns an SMD 1989 File to the TMH. The SMD File can then be used for registration of 1990 one or more DNs covered by the PRM during the Sunrise Period of a 1991 TLD. 1993 Two encapsulation boundaries are defined for delimiting the 1994 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1995 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1996 boundaries MUST be used by Registries and Registrars for validation 1997 purposes, i.e. any data outside these boundaries as well as the 1998 boundaries themselves MUST be ignored for validation purposes. 2000 The structure of the SMD File is as follows, all the elements are 2001 REQUIRED, and MUST appear in the specified order. 2003 1. Marks: 2005 2. smdID: 2007 3. U-labels: 2010 4. notBefore: 2012 5. notAfter: 2014 6. -----BEGIN ENCODED SMD----- 2016 7. 2018 8. -----END ENCODED SMD----- 2019 Example of an SMD File: 2021 Marks: Example One 2022 smdID: 1-2 2023 U-labels: example-one, exampleone 2024 notBefore: 2011-08-16 09:00 2025 notAfter: 2012-08-16 09:00 2026 -----BEGIN ENCODED SMD----- 2027 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2028 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2029 ... (base64 data elided for brevity) ... 2030 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2031 -----END ENCODED SMD----- 2033 Figure 17 2035 6.5. Trademark Claims Notice (TCN) 2037 The TMDB MUST provide the TCN to Registrars in XML format as 2038 specified below. 2040 An enclosing element that describes the Trademark 2041 Notice to a given label. 2043 The child elements of the element include: 2045 o A element that contains the unique identifier of the 2046 Trademark Notice. This element contains the the TCNID. 2048 The TCNID is a string concatenation of a TCN Checksum and the 2049 TMDB Notice Identifier. The first 8 characters of the TCNID is 2050 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2051 is a zero-padded natural number in the range of 2052 0000000000000000001 to 9223372036854775807. 2054 Example of a TCNID: 2056 370d0b7c9223372036854775807. 2058 Where: 2060 + TCN Checksum=370d0b7c 2062 + TMDB Notice Identifier=9223372036854775807 2063 The TCN Checksum is a 8 characters long Base16 encoded output 2064 of computing the CRC32 of the string concatenation of: label + 2065 unix_timestamp() + TMDB Notice Identifier 2067 TMDB MUST use the Unix time conversion of the 2068 in UTC to calculate the TCN Checksum. Unix 2069 time is defined as the number of seconds that have elapsed 2070 since 1970-01-01T00:00:00Z not counting leap seconds. For 2071 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2072 is shown: 2074 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2076 The TMDB uses the and 2077 elements from the TCN along with the TMDB Notice Identifier to 2078 compute the TCN Checksum. 2080 A Registry MUST use the leftmost DNL of the DN being 2081 effectively allocated, the expiration datetime of the TCN 2082 (provided by the Registrar) and the TMDB Notice Identifier 2083 extracted from the TCNID (provided by the Registrar) to compute 2084 the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- 2085 mgbh0fb" is being effectively allocated, the leftmost DNL would 2086 be "xn--mgbachtv". 2088 Example of computation of the TCN Checksum: 2090 CRC32(example-one12819492009223372036854775807)=370d0b7c 2092 o A element that contains the start of the 2093 validity date and time of the TCN. 2095 o A element that contains the expiration date 2096 and time of the TCN. 2098 o A element that contains the DNL covered by a PRM. 2100 o One or more elements that contain the Trademark 2101 Claim. The element contains the following child 2102 elements: 2104 * A element that contains the mark text 2105 string. 2107 * One or more elements that contains the 2108 information of the holder of the mark. An "entitlement" 2109 attribute is used to identify the entitlement of the holder, 2110 possible values are: owner, assignee or licensee. The child 2111 elements of include: 2113 + An OPTIONAL element that contains the name 2114 of the holder. A MUST be specified if 2115 is not specified. 2117 + An OPTIONAL element that contains the name of 2118 the organization holder of the mark. A MUST 2119 be specified if is not specified. 2121 + A element that contains the address 2122 information of the holder of a mark. A 2123 contains the following child elements: 2125 - One, two or three OPTIONAL elements 2126 that contains the organization's street address. 2128 - A element that contains the 2129 organization's city. 2131 - An OPTIONAL element that contains the 2132 organization's state or province. 2134 - An OPTIONAL element that contains the 2135 organization's postal code. 2137 - A element that contains the organization's 2138 country code. This a two-character code from 2139 [ISO3166-2]. 2141 + An OPTIONAL element that contains the 2142 organization's voice telephone number. 2144 + An OPTIONAL element that contains the 2145 organization's facsimile telephone number. 2147 + An OPTIONAL element that contains the email 2148 address of the holder. 2150 * Zero or more OPTIONAL elements that contains 2151 the information of the representative of the mark registration. 2152 A "type" attribute is used to identify the type of contact, 2153 possible values are: owner, agent or thirdparty. The child 2154 elements of include: 2156 + A element that contains name of the 2157 responsible person. 2159 + An OPTIONAL element that contains the name of 2160 the organization of the contact. 2162 + A element that contains the address 2163 information of the contact. A contains the 2164 following child elements: 2166 - One, two or three OPTIONAL elements 2167 that contains the contact's street address. 2169 - A element that contains the contact's 2170 city. 2172 - An OPTIONAL element that contains the 2173 contact's state or province. 2175 - An OPTIONAL element that contains the 2176 contact's postal code. 2178 - A element that contains the contact's 2179 country code. This a two-character code from 2180 [ISO3166-2]. 2182 + A element that contains the contact's voice 2183 telephone number. 2185 + An OPTIONAL element that contains the 2186 contact's facsimile telephone number. 2188 + A element that contains the contact's email 2189 address. 2191 * A element that contains the name (in 2192 English) of the jurisdiction where the mark is protected. A 2193 jurCC attribute contains the two-character code of the 2194 jurisdiction where the mark was registered. This is a two- 2195 character code from [WIPO.ST3]. 2197 * Zero or more OPTIONAL element that 2198 contains the description (in English) of the Nice 2199 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2200 attribute contains the class number. 2202 * A element that contains the full 2203 description of the goods and services mentioned in the mark 2204 registration document. 2206 * An OPTIONAL element signals that the 2207 claim notice was added to the TCN based on other rule (e.g. 2208 [Claims50] ) than exact match (defined in [MatchingRules]). 2209 The contains one or more: 2211 + An OPTIONAL element that signals that the 2212 claim notice was added because of a previously abused name 2213 included in an UDRP case. The contains: 2215 - A element that contains the UDRP case 2216 number used to validate the previously abused name. 2218 - A element that contains the name 2219 of the UDRP provider. 2221 + An OPTIONAL element that signals that the 2222 claim notice was added because of a previously abused name 2223 included in a court's resolution. The 2224 contains: 2226 - A element that contains the reference 2227 number of the court's resolution used to validate the 2228 previously abused name. 2230 - A element that contains the two-character 2231 code from [ISO3166-2] of the jurisdiction of the court. 2233 - A element that contains the name of 2234 the court. 2236 Example of a object: 2238 2239 2240 370d0b7c9223372036854775807 2241 2010-08-14T09:00:00.0Z 2242 2010-08-16T09:00:00.0Z 2243 example-one 2244 2245 Example One 2246 2247 Example Inc. 2248 2249 123 Example Dr. 2250 Suite 100 2251 Reston 2252 VA 2253 20190 2254 US 2255 2256 2257 2258 Joe Doe 2259 Example Inc. 2260 2261 123 Example Dr. 2262 Suite 100 2263 Reston 2264 VA 2265 20190 2266 US 2267 2268 +1.7035555555 2269 jdoe@example.com 2270 2271 USA 2272 2273 Advertising; business management; business administration. 2274 2275 2276 Insurance; financial affairs; monetary affairs; real estate. 2277 2278 2279 Bardus populorum circumdabit se cum captiosus populum. 2280 Smert populorum circumdabit se cum captiosus populum. 2281 2282 2283 2284 Example-One 2285 2286 Example S.A. de C.V. 2287 2288 Calle conocida #343 2289 Conocida 2290 SP 2291 82140 2292 BR 2293 2294 2295 BRAZIL 2296 2297 Bardus populorum circumdabit se cum captiosus populum. 2298 Smert populorum circumdabit se cum captiosus populum. 2299 2300 2301 2302 One 2303 2304 One Corporation 2305 2306 Otra calle 2307 Otra ciudad 2308 OT 2309 383742 2310 CR 2311 2312 2313 COSTA RICA 2314 2315 Bardus populorum circumdabit se cum captiosus populum. 2316 Smert populorum circumdabit se cum captiosus populum. 2317 2318 2319 2320 234235 2321 CR 2322 Supreme Court of Spain 2323 2324 2325 2326 2327 One Inc 2328 2329 One SA de CV 2330 2331 La calle 2332 La ciudad 2333 CD 2334 34323 2335 AR 2336 2337 2338 ARGENTINA 2339 2340 Bardus populorum circumdabit se cum captiosus populum. 2341 Smert populorum circumdabit se cum captiosus populum. 2342 2343 2344 2345 D2003-0499 2346 WIPO 2347 2348 2350 2351 2353 For the formal syntax of the TCN please refer to Section 7.1. 2355 6.6. Sunrise List (SURL) 2357 This section defines the format of the list containing every Domain 2358 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2359 is maintained by the TMDB and downloaded by Registries in regular 2360 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2361 during the Qualified Launch Program Period to check whether a 2362 requested DN matches a DNL of a PRM eligible for Sunrise. 2364 The Sunrise List contains all the DNLs covered by a PRM eligible for 2365 Sunrise present in the TMDB at the datetime it is generated. 2367 The Sunrise List is contained in a CSV formatted file that has the 2368 following structure: 2370 o first line: , 2372 Where: 2374 + , version of the file, this field MUST be 1. 2376 + , date and time in UTC that 2377 the Sunrise List was created. 2379 o second line: a header line as specified in [RFC4180] 2381 With the header names as follows: 2383 DNL,insertion-datetime 2385 o One or more lines with: , 2387 Where: 2389 + , a Domain Name Label covered by a PRM eligible for 2390 Sunrise. 2392 + , datetime in UTC that the DNL was 2393 first inserted into the Sunrise List. The possible two 2394 values of time for inserting a DNL to the Sunrise List are 2395 00:00:00 and 12:00:00 UTC. 2397 Example of a SURL 2399 1,2012-08-16T00:00:00.0Z 2400 DNL,insertion-datetime 2401 example,2010-07-14T00:00:00.0Z 2402 another-example,2012-08-16T00:00:00.0Z 2403 anotherexample,2011-08-16T12:00:00.0Z 2405 Figure 18 2407 To provide authentication and integrity protection, the Sunrise List 2408 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2409 signature of the Sunrise List can be found in the similar URI but 2410 with extension .sig as shown below. 2412 The URL of the dy interface (Section 4.3.3) is: 2414 o < https:///dnl/surl-latest.csv > 2416 o < https:///dnl/surl-latest.sig > 2418 7. Formal Syntax 2420 7.1. Trademark Claims Notice (TCN) 2422 The schema presented here is for a Trademark Claims Notice. 2424 The BEGIN and END tags are not part of the schema; they are used to 2425 note the beginning and ending of the schema for URI registration 2426 purposes. 2428 BEGIN 2429 2430 2436 2437 2438 Schema for representing a Trademark Claim Notice. 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2462 2463 2464 2465 2466 2467 2469 2471 2472 2474 2475 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2540 2541 2542 END 2544 8. Acknowledgements 2546 This specification is a collaborative effort from several 2547 participants in the ICANN community. Bernie Hoeneisen participated 2548 as co-author until version 02 providing invaluable support for this 2549 document. This specification is based on a model spearheaded by: 2550 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2551 would also like to thank the thoughtful feedbak provided by many in 2552 the tmch-tech mailing list, but particularly the extensive help 2553 provided by James Gould, James Mitchell and Francisco Arias. This 2554 document includes feedback received from the following individuals: 2555 Paul Hoffman. 2557 9. Change History 2559 [[RFC Editor: Please remove this section.]] 2561 9.1. Version 04 2563 1. Ping update. 2565 9.2. Version 05 2567 1. Ping update. 2569 9.3. Version 06 2571 1. Updated the terminology text to reflect the text in RFC8174. 2573 2. Updated the reference of RFC7719 to RFC8499. 2575 3. Updated the matching rules document reference to link to the 2576 latest version. 2578 9.4. Version 07 2580 1. Changes based on the feedback provided here: 2581 https://mailarchive.ietf.org/arch/msg/regext/ 2582 xcZPOAajlUJzgPgZBuqlIWRcFZg/ 2584 2. Changes based on the feedback provided here: 2585 https://mailarchive.ietf.org/arch/msg/regext/ 2586 MdOhSomd6_djLcthfw5mxWZkbWY 2588 9.5. Version 08 2590 1. Fixed issues detected by idnits tool. 2592 10. IANA Considerations 2594 This document uses URNs to describe XML namespaces and XML schemas 2595 conforming to a registry mechanism described in [RFC3688]. Two URI 2596 assignments have been registered by the IANA. 2598 Registration request for the Trademark Claims Notice namespace: 2600 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2602 Registrant Contact: IETF 2604 XML: None. Namespace URIs do not represent an XML specification. 2606 Registration request for the Trademark Claims Notice XML schema: 2608 URI: urn:ietf:params:xml:schema:tmNotice-1.0 2610 Registrant Contact: IETF 2612 XML: See Section 7.1 of this document. 2614 11. Security Considerations 2616 This specification uses HTTP Basic Authentication to provide a simple 2617 application-layer authentication service. HTTPS is used in all 2618 interfaces in order to protect against most common attacks. In 2619 addition, the client identifier is tied to a set of IP addresses that 2620 are allowed to connect to the interfaces described in this document, 2621 providing an extra security measure. 2623 The TMDB MUST provide credentials to the appropriate Registries and 2624 Registrars. 2626 The TMDB MUST require the use of strong passwords by Registries and 2627 Registrars. 2629 The TMDB, Registries and Registrars MUST use the best practices 2630 described in RFC 7525 or its successors. 2632 12. References 2634 12.1. Normative References 2636 [Claims50] 2637 ICANN, "Implementation Notes: Trademark Claims Protection 2638 for Previously Abused Names", July 2013, 2639 . 2642 [MatchingRules] 2643 ICANN, "Memorandum on Implementing Matching Rules", July 2644 2016, . 2647 [QLP-Addendum] 2648 ICANN, "Qualified Launch Program Addendum", April 2014, 2649 . 2653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2654 Requirement Levels", BCP 14, RFC 2119, 2655 DOI 10.17487/RFC2119, March 1997, 2656 . 2658 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2659 DOI 10.17487/RFC3688, January 2004, 2660 . 2662 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2663 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2664 . 2666 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2667 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2668 May 2017, . 2670 [RPM-Requirements] 2671 ICANN, "Rights Protection Mechanism Requirements", 2672 September 2013, . 2675 [W3C.REC-xml-20081126] 2676 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 2677 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 2678 Edition) REC-xml-20081126", November 2008, 2679 . 2681 [W3C.REC-xmlschema-1-20041028] 2682 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 2683 "XML Schema Part 1: Structures Second Edition REC- 2684 xmlschema-1-20041028", October 2004, 2685 . 2687 [W3C.REC-xmlschema-2-20041028] 2688 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2689 Second Edition REC-xmlschema-2-20041028", October 2004, 2690 . 2692 12.2. Informative References 2694 [ICANN-GTLD-AGB-20120604] 2695 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2696 2012, . 2699 [ISO3166-2] 2700 ISO, "International Standard for country codes and codes 2701 for their subdivisions", 2006, 2702 . 2704 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2705 DOI 10.17487/RFC2818, May 2000, 2706 . 2708 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2709 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2710 . 2712 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2713 Separated Values (CSV) Files", RFC 4180, 2714 DOI 10.17487/RFC4180, October 2005, 2715 . 2717 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2718 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2719 . 2721 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2722 Thayer, "OpenPGP Message Format", RFC 4880, 2723 DOI 10.17487/RFC4880, November 2007, 2724 . 2726 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2727 Housley, R., and W. Polk, "Internet X.509 Public Key 2728 Infrastructure Certificate and Certificate Revocation List 2729 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2730 . 2732 [RFC5890] Klensin, J., "Internationalized Domain Names for 2733 Applications (IDNA): Definitions and Document Framework", 2734 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2735 . 2737 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2738 Protocol (HTTP/1.1): Message Syntax and Routing", 2739 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2740 . 2742 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2743 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2744 DOI 10.17487/RFC7231, June 2014, 2745 . 2747 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2748 Protocol (HTTP/1.1): Authentication", RFC 7235, 2749 DOI 10.17487/RFC7235, June 2014, 2750 . 2752 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2753 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2754 January 2019, . 2756 [WIPO-NICE-CLASSES] 2757 WIPO, "WIPO Nice Classification", 2015, 2758 . 2760 [WIPO.ST3] 2761 WIPO, "Recommended standard on two-letter codes for the 2762 representation of states, other entities and 2763 intergovernmental organizations", March 2007, 2764 . 2766 Author's Address 2767 Gustavo Lozano 2768 ICANN 2769 12025 Waterfront Drive, Suite 300 2770 Los Angeles 90292 2771 US 2773 Phone: +1.3103015800 2774 Email: gustavo.lozano@icann.org