idnits 2.17.1 draft-ietf-regext-tmch-func-spec-06.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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (Nov 19, 2019) is 1620 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1380, but not defined -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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 Nov 19, 2019 5 Expires: May 22, 2020 7 ICANN TMCH functional specifications 8 draft-ietf-regext-tmch-func-spec-06 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 May 22, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 127 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 129 12.1. Normative References . . . . . . . . . . . . . . . . . . 60 130 12.2. Informative References . . . . . . . . . . . . . . . . . 60 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 133 1. Introduction 135 Domain Name Registries (DNRs) may operate in special modes for 136 certain periods of time enabling trademark holders to protect their 137 rights during the introduction of a Top Level Domain (TLD). 139 Along with the introduction of new generic TLDs (gTLD), two special 140 modes came into effect: 142 o Sunrise Period, the Sunrise Period allows trademark holders an 143 advance opportunity to register domain names corresponding to 144 their marks before names are generally available to the public. 146 o Trademark Claims Period, the Trademark Claims Period follows the 147 Sunrise Period and runs for at least the first 90 days of an 148 initial operating period of general registration. During the 149 Trademark Claims Period, anyone attempting to register a domain 150 name matching a mark that is recorded in the ICANN Trademark 151 Clearinghouse (TMCH) will receive a notification displaying the 152 relevant mark information. 154 This document describes the requirements, the architecture and the 155 interfaces between the ICANN TMCH and Domain Name Registries (called 156 Registries in the rest of the document) as well as between the ICANN 157 TMCH and Domain Name Registrars (called Registrars in the rest of the 158 document) for the provisioning and management of domain names during 159 the Sunrise and Trademark Claims Periods. 161 For any date and/or time indications, Coordinated Universal Time 162 (UTC) applies. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 XML is case sensitive. Unless stated otherwise, XML specifications 173 and examples provided in this document MUST be interpreted in the 174 character case presented in order to develop a conforming 175 implementation. 177 "tmNotice-1.0" is used as an abbreviation for 178 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 179 "tmNotice" is used, but implementations MUST NOT depend on it and 180 instead employ a proper namespace-aware XML parser and serializer to 181 interpret and output the XML documents. 183 3. Glossary 185 In the following section, the most common terms are briefly 186 explained: 188 o Backend Registry Operator: Entity that manages (a part of) the 189 technical infrastructure for a Registry Operator. The Registry 190 Operator may also be the Backend Registry Operator. 192 o CA: Certificate Authority, see [RFC5280]. 194 o CNIS, Claims Notice Information Service: This service provides 195 Trademark Claims Notices (TCN) to Registrars. 197 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 198 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 200 o CRL: Certificate Revocation List, see [RFC5280]. 202 o CSV: Comma-Separated Values, see [RFC4180] 204 o Date and time, datetime: Date and time are specified following the 205 standard "Date and Time on the Internet specification", see 206 [RFC3339]. 208 o DN, Domain Name, domain name: see definition of Domain name in 209 [RFC8499]. 211 o DNROID, DN Repository Object IDentifier: an identifier assigned by 212 the Registry to each DN object that unequivocally identifies said 213 DN object. For example, if a new DN object is created for a name 214 that existed in the past, the DN objects will have different 215 DNROIDs. 217 o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see 218 [RFC5890]). 220 o DNL List: A list of DNLs that are covered by a PRM. 222 o DNS: Domain Name System, see [RFC8499]. 224 o Effective allocation: A DN is considered effectively allocated 225 when the DN object for the DN has been created in the SRS of the 226 Registry and has been assigned to the effective user. A DN object 227 in status "pendingCreate" or any other status that precedes the 228 first time a DN is assigned to an end-user is not considered an 229 effective allocation. A DN object created internally by the 230 Registry for subsequent delegation to another Registrant is not 231 considered an effective allocation. 233 o EPP: The Extensible Provisioning Protocol, see definition of EPP 234 in [RFC8499]. 236 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 237 [RFC8499]. 239 o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. 241 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 243 o IDN: Internationalized Domain Name, see definition of IDN in 244 [RFC8499]. 246 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 247 Z0-9/] to be used as the lookup key by Registrars to obtain the 248 TCN using the CNIS. Lookup Keys are unique and are related to one 249 DNL only. 251 o LORDN, List of Registered Domain Names: This is the list of 252 effectively allocated DNs matching a DNL of a PRM. Registries 253 will upload this list to the TMDB (during the NORDN process). 255 o Matching Rules: Some trademarks entitled to inclusion in the TMDB 256 include characters that are impermissible in the domain name 257 system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH 258 Matching Rules [MatchingRules]) certain DNS-impermissible 259 characters in a trademark into DNS-permissible equivalent 260 characters 262 o NORDN, Notification of Registered Domain Names: The process by 263 which Registries upload their recent LORDN to the TMDB. 265 o PGP: Pretty Good Privacy, see [RFC4880] 267 o PKI: Public Key Infrastructure, see [RFC5280]. 269 o PRM, Pre-registered mark: Mark that has been pre-registered with 270 the ICANN TMCH. 272 o QLP Period, Qualified Launch Program Period: During this optional 273 period, a special process applies to DNs matching the Sunrise List 274 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 275 DN matching their PRM. 277 o Registrant: see definition of Registrant in [RFC8499]. 279 o Registrar, Domain Name Registrar: see definition of Registrar in 280 [RFC8499]. 282 o Registry, Domain Name Registry, Registry Operator: see definition 283 of Registry in [RFC8499]. A Registry Operator is the contracting 284 party with ICANN for the TLD. 286 o SMD, Signed Mark Data: A cryptographically signed token issued by 287 the TMV to the TMH to be used in the Sunrise Period to apply for a 288 DN that matches a DNL of a PRM; see also [RFC7848]. An SMD 289 generated by an ICANN-approved trademark validator (TMV) contains 290 both the signed token and the TMV's PKIX certificate. 292 o SMD File: A file containing the SMD (see above) and some human 293 readable data. The latter is usually ignored in the processing of 294 the SMD File. See also Section 6.4. 296 o SMD Revocation List: The SMD Revocation List is used by Registries 297 (and optionally by Registrars) during the Sunrise Period to ensure 298 that an SMD is still valid (i.e. not revoked). The SMD Revocation 299 List has a similar function as CRLs used in PKI. 301 o SRS: Shared Registration System, see also 302 [ICANN-GTLD-AGB-20120604]. 304 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 305 eligible for Sunrise. 307 o Sunrise Period: During this period DNs matching a DNL of a PRM can 308 be exclusively obtained by the respective TMHs. For DNs matching 309 a PRM, a special process applies to ensure that TMHs are informed 310 on the effective allocation of a DN matching their PRM. 312 o TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. 314 o ICANN TMCH: a central repository for information to be 315 authenticated, stored, and disseminated, pertaining to the rights 316 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 317 (see below). There could be several entities performing the TMV 318 function, but only one entity performing the TMDB function. 320 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 321 This CA is operated by ICANN. The public key for this CA is the 322 trust anchor used to validate the identity of each TMV. 324 o TMDB, Trademark Clearinghouse Database: Serves as a database of 325 the ICANN TMCH to provide information to the gTLD Registries and 326 Registrars to support Sunrise or Trademark Claims services. There 327 is only one TMDB in the ICANN TMCH that concentrates the 328 information about the "verified" Trademark records from the TMVs. 330 o TMH, Trademark Holder: The person or organization owning rights on 331 a mark. 333 o TMV, Trademark Validator, Trademark validation organization: An 334 entity authorized by ICANN to authenticate and validate 335 registrations in the TMDB ensuring the marks qualify as registered 336 or are court-validated marks or marks that are protected by 337 statute or treaty. This entity would also be asked to ensure that 338 proof of use of marks is provided, which can be demonstrated by 339 furnishing a signed declaration and one specimen of current use. 341 o Trademark, mark: Marks are used to claim exclusive properties of 342 products or services. A mark is typically a name, word, phrase, 343 logo, symbol, design, image, or a combination of these elements. 344 For the scope of this document only textual marks are relevant. 346 o Trademark Claims, Claims: Provides information to enhance the 347 understanding of the Trademark rights being claimed by the TMH. 349 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 350 Trademark Claims Notice consist of one or more Trademark Claims 351 and are provided to prospective Registrants of DNs. 353 o TCNID, Trademark Claims Notice Identifier: An element of the 354 Trademark Claims Notice (see above), identifying said TCN. The 355 Trademark Claims Notice Identifier is specified in the element 356 . 358 o Trademark Claims Period: During this period, a special process 359 applies to DNs matching the DNL List, to ensure that TMHs are 360 informed of a DN matching their PRM. For DNs matching the DNL 361 List, Registrars show a TCN to prospective Registrants that has to 362 be acknowledged before effective allocation of the DN. 364 o UTC: Coordinated Universal Time, as maintained by the Bureau 365 International des Poids et Mesures (BIPM); see also [RFC3339]. 367 4. Architecture 369 4.1. Sunrise Period 371 Architecture of the Sunrise Period 373 SMD hand over (out-of-band) 374 .............................................. 375 : : 376 : .'''''''''''''''''''. : 377 : . ICANN TMCH . : 378 : ..................... : 379 v . . : 380 .------------. . .-------------. . hv .-----. 381 | Registrant | . | TMV |<---------->| TMH | 382 '------------' . '-------------' . vh '-----' 383 | . | ^ \ . 384 | . | | \. 385 tr | . vs | | dv \ 386 | . | vd | .\ 387 v . v v . \ 388 .-----------. sr . .---------. . \ 389 .->| Registrar |<..........| | . \ 390 : '-----------' . | | . \ 391 : | sy . | T | . \ 392 : ry | .------------| M | . vc \ 393 : | | . | D | . \ 394 : v v . | B | . v 395 : .-----------. . yd | | . .---------------. 396 : | Registry |---------->| | . | ICANN TMCH-CA | 397 : '-----------' . '---------' . '---------------' 398 : ^ . . | : 399 : | ''''''''''''''''''' | : 400 : | cy | : 401 : cr '-----------------------------------------' : 402 :......................................................: 404 Figure 1 406 4.2. Trademark Claims Period 408 Architecture of the Trademark Claims Period 410 .''''''''''''''. 411 . ICANN TMCH . 412 ................ 413 . . 414 .------------. . .-------. . hv .-----. 415 | Registrant | . | TMV |<----------->| TMH | 416 '------------' . '-------' . vh '-----' 417 | . ^ . 418 | . | dv . 419 tr | . vd | . 420 v . v . 421 .-----------. dr . .-------. . 422 | Registrar |<--------| | . 423 '-----------' . | T | . 424 ry | . | M | . 425 v . | D | . 426 .----------. dy . | B | . 427 | Registry |<------->| | . 428 '----------' yd . '-------' . 429 . . 430 '''''''''''''' 432 Figure 2 434 4.3. Interfaces 436 In the sub-sections below follows a short description of each 437 interface to provide an overview of the architecture. More detailed 438 descriptions of the relevant interfaces follow further below 439 (Section 5). 441 4.3.1. hv 443 The TMH registers a mark with a TMV via the hv interface. 445 After the successful registration of the mark, the TMV makes 446 available a SMD File (see also Section 6.4) to the TMH to be used 447 during the Sunrise Period. 449 The specifics of the hv interface are beyond the scope of this 450 document. 452 4.3.2. vd 454 After successful mark registration, the TMV ensures the TMDB inserts 455 the corresponding DNLs and mark information into the database via the 456 vd interface. 458 The specifics of the vd interface are beyond the scope of this 459 document. 461 4.3.3. dy 463 During the Trademark Claims Period the Registry fetches the latest 464 DNL List from the TMDB via the dy interface at regular intervals. 465 The protocol used on the dy interface is HTTPS. 467 Not relevant during the Sunrise Period. 469 4.3.4. tr 471 The Registrant communicates with the Registrar via the tr interface. 473 The specifics of the tr interface are beyond the scope of this 474 document. 476 4.3.5. ry 478 The Registrar communicate with the Registry via the ry interface. 479 The ry interfaces is typically implemented in EPP. 481 4.3.6. dr 483 During the Trademark Claims Period, the Registrar fetches the TCN 484 from the TMDB (to be displayed to the Registrant via the tr 485 interface) via the dr interface. The protocol used for fetching the 486 TCN is HTTPS. 488 Not relevant during the Sunrise Period. 490 4.3.7. yd 492 During the Sunrise Period the Registry notifies the TMDB via the yd 493 interface of all DNs effectively allocated. 495 During the Trademark Claims Period, the Registry notifies the TMDB 496 via the yd interface of all DNs effectively allocated that matched an 497 entry in the Registry previously downloaded DNL List during the 498 creation of the DN. 500 The protocol used on the yd interface is HTTPS. 502 4.3.8. dv 504 The TMDB notifies via the dv interface to the TMV of all DNs 505 effectively allocated that match a mark registered by that TMV. 507 The specifics of the dv interface are beyond the scope of this 508 document. 510 4.3.9. vh 512 The TMV notifies the TMH via the vh interface after a DN has been 513 effectively allocated that matches a PRM of this TMH. 515 The specifics of the vh interface are beyond the scope of this 516 document. 518 4.3.10. vs 520 The TMV requests to add a revoked SMD to the SMD Revocation List at 521 the TMDB. 523 The specifics of the vs interface are beyond the scope of this 524 document. 526 Not relevant during the Trademark Claims Period. 528 4.3.11. sy 530 During the Sunrise Period the Registry fetches the most recent SMD 531 Revocation List from the TMDB via the sy interface in regular 532 intervals. The protocol used on the sy interface is HTTPS. 534 Not relevant during the Trademark Claims Period. 536 4.3.12. sr 538 During the Sunrise Period the Registrar may fetch the most recent SMD 539 Revocation List from the TMDB via the sr interface. The protocol 540 used on the sr interface is the same as on the sy interface (s. 541 above), i.e. HTTPS. 543 Not relevant during the Trademark Claims Period. 545 4.3.13. vc 547 The TMV registers its public key, and requests to revoke an existing 548 key, with the ICANN TMCH-CA over the vc interface. 550 The specifics of the vc interface are beyond the scope of this 551 document, but it involves personal communication between the 552 operators of the TMV and the operators of the ICANN TMCH-CA. 554 Not relevant during the Trademark Claims Period. 556 4.3.14. cy 558 During the Sunrise Period the Registry fetches the most recent TMV 559 CRL file from the ICANN TMCH-CA via the cy interface at regular 560 intervals. The TMV CRL is used for validation of TMV certificates. 561 The protocol used on the cy interface is HTTPS. 563 Not relevant during the Trademark Claims Period. 565 4.3.15. cr 567 During the Sunrise Period the Registrar optionally fetches the most 568 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 569 regular intervals. The TMV CRL is used for validation of TMV 570 certificates. The protocol used on the cr interface is HTTPS. 572 Not relevant during the Trademark Claims Period. 574 5. Process Descriptions 576 5.1. Bootstrapping 578 5.1.1. Bootstrapping for Registries 580 5.1.1.1. Credentials 582 Each Registry Operator will receive authentication credentials from 583 the TMDB to be used: 585 o During the Sunrise Period to fetch the SMD Revocation List from 586 the TMBD via the sy interface (Section 4.3.11). 588 o During the Trademark Claims Period to fetch the DNL List from the 589 TMDB via the dy interface (Section 4.3.3). 591 o During the NORDN process to notify the LORDN to the TMDB via the 592 yd interface (Section 4.3.7). 594 Note: credentials are created per TLD and provided to the Registry 595 Operator. 597 5.1.1.2. IP Addresses for Access Control 599 Each Registry Operator MUST provide to the TMDB all IP addresses that 600 will be used to: 602 o Fetch the SMD Revocation List via the sy interface 603 (Section 4.3.11). 605 o Fetch the DNL List from the TMDB via the dy interface 606 (Section 4.3.3). 608 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 610 This access restriction MAY be applied by the TMDB in addition to 611 HTTP Basic access authentication (see [RFC7235]). For credentials to 612 be used, see Section 5.1.1.1. 614 The TMDB MAY limit the number of IP addresses to be accepted per 615 Registry Operator. 617 5.1.1.3. ICANN TMCH Trust Anchor 619 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 620 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 621 tmch.crt > to be used: 623 o During the Sunrise Period to validate the TMV certificates and the 624 TMV CRL. 626 5.1.1.4. TMDB PGP Key 628 The TMDB MUST provide each Registry Operator with the public portion 629 of the PGP Key used by TMDB, to be used: 631 o During the Sunrise Period to perform integrity checking of the SMD 632 Revocation List fetched from the TMDB via the sy interface 633 (Section 4.3.11). 635 o During the Trademark Claims Period to perform integrity checking 636 of the DNL List fetched from the TMDB via the dy interface 637 (Section 4.3.3). 639 5.1.2. Bootstrapping for Registrars 641 5.1.2.1. Credentials 643 Each ICANN-accredited Registrar will receive authentication 644 credentials from the TMDB to be used: 646 o During the Sunrise Period to (optionally) fetch the SMD Revocation 647 List from the TMDB via the sr interface (Section 4.3.12). 649 o During the Trademark Claims Period to fetch TCNs from the TMDB via 650 the dr interface (Section 4.3.6). 652 5.1.2.2. IP Addresses for Access Control 654 Each Registrar MUST provide to the TMDB all IP addresses, which will 655 be used to: 657 o Fetch the SMD Revocation List via the sr interface 658 (Section 4.3.12). 660 o Fetch TCNs via the dr interface (Section 4.3.6). 662 This access restriction MAY be applied by the TMDB in addition to 663 HTTP Basic access authentication (for credentials to be used, see 664 Section 5.1.2.1). 666 The TMDB MAY limit the number of IP addresses to be accepted per 667 Registrar. 669 5.1.2.3. ICANN TMCH Trust Anchor 671 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 672 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 674 o During the Sunrise Period to (optionally) validate the TMV 675 certificates and TMV CRL. 677 5.1.2.4. TMDB PGP Key 679 Registrars MUST receive the public portion of the PGP Key used by 680 TMDB from the TMDB administrator to be used: 682 o During the Sunrise Period to (optionally) perform integrity 683 checking of the SMD Revocation List fetched from the TMDB via the 684 sr interface (Section 4.3.12). 686 5.2. Sunrise Period 688 5.2.1. Domain Name registration 690 Domain Name registration during the Sunrise Period 692 .------------. .-----------. .----------. 693 | Registrant | | Registrar | | Registry | 694 '------------' '-----------' '----------' 695 | | | 696 | Request DN | | 697 | registration | | 698 | (with SMD) | | 699 |---------------->| Check DN availability | 700 | |---------------------------->| 701 | | | 702 | | DN unavailable .-------------. 703 | DN unavailable |<--------------------( DN available? ) 704 |<----------------| no '-------------' 705 | | | yes 706 | | DN available | 707 | |<----------------------------| 708 | | | 709 | | Request DN registration | 710 | | (with SMD) | 711 | |---------------------------->| 712 | | | 713 | | .------------------------------. 714 | | | DN registration validation / | 715 | | | SMD validation | 716 | | '------------------------------' 717 | | | 718 | Registration |.-----------. Error .----------------------. 719 | error || TRY AGAIN |<-----( Validation successful? ) 720 |<----------------|| / ABORT | no '----------------------' 721 | |'-----------' | yes 722 | | | 723 | | DN registered | 724 | DN registered |<----------------------------| 725 |<----------------| | 726 | | | 728 Figure 3 730 Note: the figure depicted above represents a synchronous DN 731 registration workflow (usually called first come first served). 733 5.2.2. Sunrise Domain Name registration by Registries 735 Registries MUST perform a minimum set of checks for verifying each DN 736 registration during the Sunrise Period upon reception of a 737 registration request over the ry interface (Section 4.3.5). If any 738 of these checks fails the Registry MUST abort the registration. Each 739 of these checks MUST be performed before the DN is effectively 740 allocated. 742 In case of asynchronous registrations (e.g. auctions), the minimum 743 set of checks MAY be performed when creating the intermediate object 744 (e.g. a DN application) used for DN registration. If the minimum set 745 of checks is performed when creating the intermediate object (e.g. a 746 DN application) a Registry MAY effective allocate the DN without 747 performing the minimum set of checks again. 749 Performing the minimum set of checks Registries MUST verify that: 751 1. An SMD has been received from the Registrar along with the DN 752 registration. 754 2. The certificate of the TMV has been correctly signed by the ICANN 755 TMCH-CA. (The certificate of the TMV is contained within the 756 SMD.) 758 3. The datetime when the validation is done is within the validity 759 period of the TMV certificate. 761 4. The certificate of the TMV is not listed in the TMV CRL file 762 specified in the CRL distribution point of the TMV certificate. 764 5. The signature of the SMD (signed with the TMV certificate) is 765 valid. 767 6. The datetime when the validation is done is within the validity 768 period of the SMD based on and 769 elements. 771 7. The SMD has not been revoked, i.e., is not contained in the SMD 772 Revocation List. 774 8. The leftmost DNL of the DN being effectively allocated matches 775 one of the labels () elements in the SMD. For 776 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 777 effectively allocated, the leftmost DNL would be "xn--mgbachtv". 779 These procedure apply to all DN effective allocations at the second 780 level as well as to all other levels subordinate to the TLD that the 781 Registry accepts registrations for. 783 5.2.3. TMDB Sunrise Services for Registries 785 5.2.3.1. SMD Revocation List 787 A new SMD Revocation List MUST be published by the TMDB twice a day, 788 by 00:00:00 and 12:00:00 UTC. 790 Registries MUST refresh the latest version of the SMD Revocation List 791 at least once every 24 hours. 793 Note: the SMD Revocation List will be the same regardless of the TLD. 794 If a Backend Registry Operator manages the infrastructure of several 795 TLDs, the Backend Registry Operator could refresh the SMD Revocation 796 List once every 24 hours, the SMD Revocation List could be used for 797 all the TLDs managed by the Backend Registry Operator. 799 Update of the SMD Revocation List 801 .----------. .------. 802 | Registry | | TMDB | 803 '----------' '------' 804 | | 805 .----------------. | 806 | Periodically, | | 807 | at least | | 808 | every 24 hours | | 809 '----------------' | 810 | | 811 |----------------------------------------------------->| 812 | Download the latest SMD Revocation List | 813 |<-----------------------------------------------------| 814 | | 815 | | 817 Figure 4 819 5.2.3.2. TMV Certificate Revocation List (CRL) 821 Registries MUST refresh their local copy of the TMV CRL file at least 822 every 24 hours using the CRL distribution point specified in the TMV 823 certificate. 825 Operationally, the TMV CRL file and CRL distribution point is the 826 same for all TMVs and (at publication of this document) located at < 827 http://crl.icann.org/tmch.crl >. 829 Note: the TMV CRL file will be the same regardless of the TLD. If a 830 Backend Registry Operator manages the infrastructure of several TLDs, 831 the Backend Registry Operator could refresh the TMV CRL file once 832 every 24 hours, the TMV CRL file could be used for all the TLDs 833 managed by the Backend Registry Operator. 835 Update of the TMV CRL file 837 .----------. .---------------. 838 | Registry | | ICANN TMCH-CA | 839 '----------' '---------------' 840 | | 841 .----------------. | 842 | Periodically, | | 843 | at least | | 844 | every 24 hours | | 845 '----------------' | 846 | | 847 |-------------------------------------------->| 848 | Download the latest TMV CRL file | 849 |<--------------------------------------------| 850 | | 851 | | 853 Figure 5 855 5.2.3.3. Notice of Registered Domain Names (NORN) 857 The Registry MUST send a LORDN file containing DNs effectively 858 allocated to the TMDB (over the yd interface, Section 4.3.7). 860 The effective allocation of a DN MUST be reported by the Registry to 861 the TMDB within 26 hours of the effective allocation of such DN. 863 The Registry MUST create and upload a LORDN file in case there are 864 effective allocations in the SRS, that have not been successfully 865 reported to the TMDB in a previous LORDN file. 867 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 868 maximum frequency to upload LORDN files from the Registries to the 869 TMDB is every 3 hours. 871 It is RECOMMENDED that Registries try to upload at least two LORDN 872 files per day to the TMDB with enough time in between, in order to 873 have time to fix problems reported in the LORDN file. 875 The Registry SHOULD upload a LORDN file only when the previous LORDN 876 file has been processed by the TMDB and the related LORDN Log file 877 has been downloaded and processed by the Registry. 879 The Registry MUST upload LORDN files for DNs effectively allocated 880 during the Sunrise or Trademark Claims Period (same applies to DNs 881 effectively allocated using applications created during the Sunrise 882 or Trademark Claims Period in case of using asynchronous 883 registrations). 885 The yd interface (Section 4.3.7) MUST support at least one (1) and 886 MAY support up to ten (10) concurrent connections from each IP 887 address registered by a Registry Operator to access the service. 889 The TMDB MUST process each uploaded LORDN file and make the related 890 log file available for Registry download within 30 minutes of the 891 finalization of the upload. 893 Notification of Registered Domain Name 895 .----------. .------. .-----. .-----. 896 | Registry | | TMDB | | TMV | | TMH | 897 '----------' '------' '-----' '-----' 898 | | | | 899 .------------------. | | | 900 | Periodically | | | | 901 | upload LORDN | | | | 902 | file | | | | 903 '------------------' | | | 904 | | | | 905 .--------->| Upload LORDN | | | 906 | |-------------------->| | | 907 | | | | | 908 | | .-------------------------. | | 909 | | | Verify each domain name | | | 910 | | | in the uploaded file | | | 911 | | | (within 30') | | | 912 | | '-------------------------' | | 913 | | | ._____.| | 914 | | Download Log file | | END || | 915 | |<--------------------| '-----'| | 916 | | | ^ | | 917 | .-----------------. .---------------. | | | 918 | | Check whether | / everything fine \ no | | | 919 | | Log file | ( (i.e. no errors )---' | | 920 | | contains errors | \ in Log file )? / | | 921 | '-----------------' '---------------' | | 922 | | | yes | | 923 | .---------------. | | | 924 | / everything fine \ yes | | | 925 |( (i.e. no errors )-----. | Notify TMVs | | 926 | \ in Log file )? / | | on the LORDN | | 927 | '---------------' | | pre-registered | | 928 | | no v | with said TMV | | 929 | .----------------. .------. |--------------->| | 930 '-| Correct Errors | | DONE | | | | 931 '----------------' '------' | | Notify each | 932 | | | affected TMH | 933 | | |-------------->| 934 | | | | 936 Figure 6 938 The format used for the LORDN is described in Section 6.3 940 5.2.4. Sunrise Domain Name registration by Registrars 942 Registrars MAY choose to perform the checks for verifying DN 943 registrations as performed by the Registries (see Section 5.2.2) 944 before sending the command to register a DN. 946 5.2.5. TMDB Sunrise Services for Registrars 948 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 949 also available for Registrars to optionally validate the SMDs 950 received. 952 5.3. Trademark Claims Period 954 5.3.1. Domain Registration 956 Domain Name registration during the Trademark Claims Period 958 .------------. .-----------. .----------. .------. 959 | Registrant | | Registrar | | Registry | | TMDB | 960 '------------' '-----------' '----------' '------' 961 | Request DN | | | 962 | registration | | | 963 |--------------->| Check DN availability | | 964 | |--------------------------->| | 965 | | DN unavailable .-------------. | 966 | DN unavailable |<-------------------( DN available? ) | 967 |<---------------| no '-------------' | 968 | | DN available | yes | 969 | |<---------------------------| | 970 | | Request Lookup key | | 971 | |--------------------------->| | 972 | |.__________. .---------. | 973 | || CONTINUE | / Does DN \ | 974 | || NORMALLY |<--------( match DNL ) | 975 | |'----------' no \ of PRM? / | 976 | | '---------' | 977 | | Lookup key | yes | 978 | |<----------------------------' | 979 | | | 980 .-----. | | Request TCN | 981 |ABORT| | Display |---------------------------------------->| 982 '-----' | Claims | Return TCN | 983 ^ | Notice |<----------------------------------------| 984 | no |<---------------| | 985 | .------. yes | | 986 '-( Ack? )----------->| Register DN (with TCNID) | | 987 '------' |--------------------------->| | 988 | Registration | Error .----------------------. | 989 | error |<-------------( Validation successful? ) | 990 |<---------------| no '----------------------' | 991 | | | yes | 992 | | DN registered | | 993 | DN registered |<---------------------------| | 994 |<---------------| | | 996 Figure 7 998 Note: the figure depicted above represents a synchronous DN 999 registration workflow (usually called first come first served). 1001 5.3.2. Trademark Claims Domain Name registration by Registries 1003 During the Trademark Claims Period, Registries perform two main 1004 functions: 1006 o Registries MUST provide Registrars (over the ry interface, 1007 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1008 that match the DNL List. 1010 o Registries MUST provide the Lookup Key only when queried about a 1011 specific DN. 1013 o For each DN matching a DNL of a PRM, Registries MUST perform a 1014 minimum set of checks for verifying DN registrations during the 1015 Trademark Claims Period upon reception of a registration request 1016 over the ry interface (Section 4.3.5). If any of these checks 1017 fails the Registry MUST abort the registration. Each of these 1018 checks MUST be performed before the DN is effectively allocated. 1020 o In case of asynchronous registrations (e.g. auctions), the minimum 1021 set of checks MAY be performed when creating the intermediate 1022 object (e.g. a DN application) used for DN effective allocation. 1023 If the minimum set of checks is performed when creating the 1024 intermediate object (e.g. a DN application) a Registry MAY 1025 effective allocate the DN without performing the minimum set of 1026 checks again. 1028 o Performing the minimum set of checks Registries MUST verify that: 1030 1. The TCNID (), expiration datetime 1031 () and acceptance datetime of the TCN, have 1032 been received from the Registrar along with the DN 1033 registration. 1035 If the three elements mentioned above are not provided by 1036 the Registrar for a DN matching a DNL of a PRM, but the DNL 1037 was inserted (or re-inserted) for the first time into DNL 1038 List less than 24 hours ago, the registration MAY continue 1039 without this data and the tests listed below are not 1040 required to be performed. 1042 2. The TCN has not expired (according to the expiration datetime 1043 sent by the Registrar). 1045 3. The acceptance datetime is within the window of time defined 1046 by ICANN policy. In the gTLD round of 2012, Registrars 1047 verified that the acceptance datetime was less than or equal 1048 to 48 hours in the past, as there were no defined ICANN 1049 policies at that time. Implementers should be aware that 1050 ICANN policy may define this value in the future. 1052 4. Using the leftmost DNL of the DN being effectively allocated, 1053 the expiration datetime provided by the Registrar, and the 1054 TMDB Notice Identifier extracted from the TCNID provided by 1055 the Registrar compute the TCN Checksum. Verify that the 1056 computed TCN Checksum match the TCN Checksum present in the 1057 TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is 1058 being effectively allocated, the leftmost DNL would be "xn-- 1059 mgbachtv". 1061 These procedures apply to all DN registrations at the second level as 1062 well as to all other levels subordinate to the TLD that the Registry 1063 accepts registrations for. 1065 5.3.3. TMBD Trademark Claims Services for Registries 1067 5.3.3.1. Domain Name Label (DNL) List 1069 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1070 and 12:00:00 UTC. 1072 Registries MUST refresh the latest version of the DNL List at least 1073 once every 24 hours. 1075 Update of the DNL List 1077 .----------. .------. 1078 | Registry | | TMDB | 1079 '----------' '------' 1080 | | 1081 .----------------. | 1082 | Periodically, | | 1083 | at least | | 1084 | every 24 hours | | 1085 '----------------' | 1086 | | 1087 |-------------------------------->| 1088 | Download the latest DNL List | 1089 |<--------------------------------| 1090 | | 1091 | | 1093 Figure 8 1095 Note: the DNL List will be the same regardless of the TLD. If a 1096 Backend Registry Operator manages the infrastructure of several TLDs, 1097 the Backend Registry Operator could refresh the DNL List once every 1098 24 hours, the DNL List could be used for all the TLDs managed by the 1099 Backend Registry Operator. 1101 5.3.3.2. Notice of Registered Domain Names (NORN) 1103 The NORDN process during the Trademark Claims Period is almost the 1104 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1105 difference that only registrations subject to a Trademark Claim 1106 (i.e., at registration time the name appeared in the current DNL List 1107 downloaded by the Registry Operator) are included in the LORDN. 1109 5.3.4. Trademark Claims Domain Name registration by Registrars 1111 For each DN matching a DNL of a PRM, Registrars MUST perform the 1112 following steps: 1114 1. Use the Lookup Key received from the Registry to obtain the TCN 1115 from the TMDB using the dr interface (Section 4.3.6) Registrars 1116 MUST only query for the Lookup Key of a DN that is available for 1117 registration. 1119 2. Present the TCN to the Registrant as described in Exhibit A, 1120 [RPM-Requirements]. 1122 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1123 consent with the TCN, before any further processing. (The 1124 transmission of a TCNID to the Registry over the ry interface, 1125 Section 4.3.5 implies that the Registrant has expressed his/her 1126 consent with the TCN.) 1128 4. Perform the minimum set of checks for verifying DN registrations. 1129 If any of these checks fails the Registrar MUST abort the DN 1130 registration. Each of these checks MUST be performed before the 1131 registration is sent to the Registry. Performing the minimum set 1132 of checks Registrars MUST verify that: 1134 1. The datetime when the validation is done is within the TCN 1135 validity based on the and 1136 elements. 1138 2. The leftmost DNL of the DN being effectively allocated 1139 matches the label () element in the TCN. For 1140 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 1141 effectively allocated, the leftmost DNL would be "xn-- 1142 mgbachtv". 1144 3. The Registrant has acknowledged (expressed his/her consent 1145 with) the TCN. 1147 5. Record the date and time when the registrant acknowledged the 1148 TCN. 1150 6. Send the registration to the Registry (ry interface, 1151 Section 4.3.5) and include the following information: 1153 * TCNID () 1155 * Expiration date of the TCN () 1157 * Acceptance datetime of the TCN. 1159 Currently TCNs are generated twice a day by the TMDB. The expiration 1160 date () of each TCN MUST be set to a value defined 1161 by ICANN policy. In the gTLD round of 2012, the TMDB set the 1162 expiration value to 48 hours in to the future as there were no 1163 defined ICANN policies at that time. Implementers should be aware 1164 that ICANN policy may define this value in the future. 1166 Registrars SHOULD implement a cache of TCNs to minimize the number of 1167 queries sent to the TMDB. A cached TCN MUST be removed from the 1168 cache after the expiration date of the TCN as defined by 1169 . 1171 The TMDB MAY implement rate-limiting as one of the protection 1172 mechanisms to mitigate the risk of performance degradation. 1174 5.3.5. TMBD Trademark Claims Services for Registrars 1176 5.3.5.1. Claims Notice Information Service (CNIS) 1178 The TCNs are provided by the TMDB online and are fetched by the 1179 Registrar via the dr interface (Section 4.3.6). 1181 To get access to the TCNs, the Registrar needs the credentials 1182 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1183 from the Registry via the ry interface (Section 4.3.5). The dr 1184 interface (Section 4.3.6) uses HTTPS with Basic access 1185 authentication. 1187 The dr interface (Section 4.3.6) MAY support up to ten (10) 1188 concurrent connections from each Registrar. 1190 The URL of the dr interface (Section 4.3.6) is: 1192 < https:///cnis/.xml > 1194 Note that the "lookupkey" may contain SLASH characters ("/"). The 1195 SLASH character is part of the URL path and MUST NOT be escaped when 1196 requesting the TCN. 1198 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1199 MUST be signed by a well-know public CA. Registrars MUST perform the 1200 Certification Path Validation described in Section 6 of [RFC5280]. 1201 Registrars will be authenticated in the dr interface using HTTP Basic 1202 access authentication. The dr (Section 4.3.6) interface MUST support 1203 HTTPS keep-alive and MUST maintain the connection for up to 30 1204 minutes. 1206 5.4. Qualified Launch Program (QLP) Period 1208 5.4.1. Domain Registration 1210 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1211 (QLP) Period effective allocations of DNs to third parties could 1212 require that Registries and Registrars provide Sunrise and/or 1213 Trademark Claims services. If required, Registries and Registrars 1214 MUST provide Sunrise and/or Trademark Claims services as described in 1215 Section 5.2 and Section 5.3. 1217 The effective allocation scenarios are: 1219 o If the leftmost DNL of the DN being effectively allocated (QLP 1220 Name in this section) matches a DNL in the SURL, and an SMD is 1221 provided, then Registries MUST provide Sunrise Services (see 1222 Section 5.2) and the DN MUST be reported in a Sunrise LORDN file 1223 during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- 1224 mgbh0fb" is being effectively allocated, the leftmost DNL would be 1225 "xn--mgbachtv". 1227 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1228 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1229 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1230 file using the special SMD-id "99999-99999" during the QLP Period. 1232 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1233 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1234 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1235 services (see Section 5.3) and the DN MUST be reported in a 1236 Trademark Claims LORDN file during the QLP Period. 1238 o If the QLP Name matches a DNL in the DNL List but does not match a 1239 DNL in the SURL, then Registries MUST provide Trademark Claims 1240 services (see Section 5.2) and the DN MUST be reported in a 1241 Trademark Claims LORDN file during the QLP Period. 1243 The following table lists all the effective allocation scenarios 1244 during a QLP Period: 1246 +--------+---------+-----------------+--------------+---------------+ 1247 | QLP | QLP | SMD was | Registry | Registry MUST | 1248 | Name | Name | provided by the | MUST provide | report DN | 1249 | match | match | potential | Sunrise or | registration | 1250 | in the | in the | Registrant | Trademark | in | 1251 | SURL | DNL | | Claims | LORDN file | 1252 | | List | | Services | | 1253 +--------+---------+-----------------+--------------+---------------+ 1254 | Y | Y | Y | Sunrise | Sunrise | 1255 | | | | | | 1256 | Y | N | Y | Sunrise | Sunrise | 1257 | | | | | | 1258 | N | Y | -- | Trademark | Trademark | 1259 | | | | Claims | Claims | 1260 | | | | | | 1261 | N | N | -- | -- | -- | 1262 | | | | | | 1263 | Y | Y | N (see section | Trademark | Trademark | 1264 | | | 2.2 of | Claims | Claims | 1265 | | | [QLP-Addendum]) | | | 1266 | | | | | | 1267 | Y | N | N (see section | -- | Sunrise | 1268 | | | 2.2 of | | (using | 1269 | | | [QLP-Addendum]) | | special SMD- | 1270 | | | | | id) | 1271 +--------+---------+-----------------+--------------+---------------+ 1273 QLP Effective Allocation Scenarios 1275 The TMDB MUST provide the following services to Registries during a 1276 QLP Period: 1278 o SMD Revocation List (see Section 5.2.3.1) 1280 o NORN (see Section 5.2.3.3) 1282 o DNL List (see Section 5.3.3.1) 1284 o Sunrise List (SURL) (see Section 5.4.2.1 1286 The TMDB MUST provide the following services to Registrars during a 1287 QLP Period: 1289 o SMD Revocation List (see Section 5.2.3.1) 1290 o CNIS (see Section 5.3.5.1) 1292 5.4.2. TMBD QLP Services for Registries 1294 5.4.2.1. Sunrise List (SURL) 1296 A new Sunrise List (SURL) MUST be published by the TMDB twice a day, 1297 by 00:00:00 and 12:00:00 UTC. 1299 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1300 version of the SURL at least once every 24 hours. 1302 Update of the SURL 1304 .----------. .------. 1305 | Registry | | TMDB | 1306 '----------' '------' 1307 | | 1308 .----------------. | 1309 | Periodically, | | 1310 | at least | | 1311 | every 24 hours | | 1312 '----------------' | 1313 | | 1314 |------------------------------->| 1315 | Download the latest SURL | 1316 |<-------------------------------| 1317 | | 1318 | | 1320 Figure 9 1322 Note: the SURL will be the same regardless of the TLD. If a Backend 1323 Registry Operator manages the infrastructure of several TLDs, the 1324 Backend Registry Operator could refresh the SURL once every 24 hours, 1325 the SURL could be used for all the TLDs managed by the Backend 1326 Registry Operator. 1328 6. Data Format Descriptions 1330 6.1. Domain Name Label (DNL) List 1332 This section defines the format of the list containing every Domain 1333 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1334 is maintained by the TMDB and downloaded by Registries in regular 1335 intervals (see Section 5.3.3.1). The Registries use the DNL List 1336 during the Trademark Claims Period to check whether a requested DN 1337 matches a DNL of a PRM. 1339 The DNL List contains all the DNLs covered by a PRM present in the 1340 TMDB at the datetime it is generated. 1342 The DNL List is contained in a CSV formatted file that has the 1343 following structure: 1345 o first line: , 1347 Where: 1349 + , version of the file, this field MUST be 1. 1351 + , date and time in UTC that the 1352 DNL List was created. 1354 o second line: a header line as specified in [RFC4180] 1356 With the header names as follows: 1358 DNL,lookup-key,insertion-datetime 1360 o One or more lines with: ,, 1363 Where: 1365 + , a Domain Name Label covered by a PRM. 1367 + , lookup key that the Registry MUST provide to 1368 the Registrar. The lookup key has the following format: 1369
////, where: 1372 - YYYY: year that the TCN was generated. 1374 - MM: zero-padded month that the TCN was generated. 1376 - DD: zero-padded day that the TCN was generated. 1378 - vv: version of the TCN, possible values are 00 and 01. 1380 - X: one hexadecimal digit [0-9A-F]. This is the first, 1381 second and third hexadecimal digit of encoding the 1382 in base16 as specified in [RFC4648]. 1384 - Random bits: 144 random bits encoded in base64url as 1385 specified in [RFC4648]. 1387 - Sequential number: zero-padded natural number in the 1388 range 0000000001 to 2147483647. 1390 + , datetime in UTC that the DNL was 1391 first inserted into the DNL List. The possible two values 1392 of time for inserting a DNL to the DNL List are 00:00:00 and 1393 12:00:00 UTC. 1395 Example of a DNL List 1397 1,2012-08-16T00:00:00.0Z 1398 DNL,lookup-key,insertion-datetime 1399 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1400 2010-07-14T00:00:00.0Z 1401 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1402 2012-08-16T00:00:00.0Z 1403 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1404 2011-08-16T12:00:00.0Z 1406 Figure 10 1408 To provide authentication and integrity protection, the DNL List will 1409 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1410 PGP signature of the DNL List can be found in the similar URI but 1411 with extension .sig as shown below. 1413 The URL of the dy interface (Section 4.3.3) is: 1415 o < https:///dnl/dnl-latest.csv > 1417 o < https:///dnl/dnl-latest.sig > 1419 6.2. SMD Revocation List 1421 This section defines the format of the list of SMDs that have been 1422 revoked. The list is maintained by the TMDB and downloaded by 1423 Registries (and optionally by Registrars) in regular intervals (see 1424 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1425 Period to validate SMDs received. The SMD Revocation List has a 1426 similar function as CRLs used in PKI [RFC5280]. 1428 The SMD Revocation List contains all the revoked SMDs present in the 1429 TMDB at the datetime it is generated. 1431 The SMD Revocation List is contained in a CSV formatted file that has 1432 the following structure: 1434 o first line: , 1436 Where: 1438 + , version of the file, this field MUST be 1. 1440 + , datetime in UTC 1441 that the SMD Revocation List was created. 1443 o second line: a header line as specified in [RFC4180] 1445 With the header names as follows: 1447 smd-id,insertion-datetime 1449 o One or more lines with: , 1451 Where: 1453 + , identifier of the SMD that was revoked. 1455 + , revocation datetime in UTC of the 1456 SMD. The possible two values of time for inserting an SMD 1457 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1459 To provide integrity protection, the SMD Revocation List is PGP 1460 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1461 List is provided by the TMDB with extension .csv. The PGP signature 1462 of the SMD Revocation List can be found in the similar URI but with 1463 extension .sig as shown below. 1465 The URL of the sr interface (Section 4.3.12) and sy interface 1466 (Section 4.3.11) is: 1468 o < https:///smdrl/smdrl-latest.csv > 1470 o < https:///smdrl/smdrl-latest.sig > 1471 Example of an SMD Revocation List 1473 1,2012-08-16T00:00:00.0Z 1474 smd-id,insertion-datetime 1475 2-2,2012-08-15T00:00:00.0Z 1476 3-2,2012-08-15T00:00:00.0Z 1477 1-2,2012-08-15T00:00:00.0Z 1479 Figure 11 1481 6.3. List of Registered Domain Names (LORDN) file 1483 This section defines the format of the List of Registered Domain 1484 Names (LORDN), which is maintained by each Registry and uploaded at 1485 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1486 said DN is added to the LORDN along with further information related 1487 to its registration. 1489 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1490 file is: 1492 o Sunrise LORDN file: 1494 < https:///LORDN//sunrise > 1496 o Trademark Claims LORDN file: 1498 < https:///LORDN//claims > 1500 During a QLP Period, Registries MAY be required to upload Sunrise or 1501 Trademark Claims LORDN files. The URIs of the yd interface used to 1502 upload LORDN files during a QLP Period is: 1504 o Sunrise LORDN file (during QLP Period): 1506 < https:///LORDN//sunrise/qlp > 1508 o Trademark Claims LORDN file (during a QLP Period): 1510 < https:///LORDN//claims/qlp > 1512 The yd interface (Section 4.3.7) returns the following HTTP status 1513 codes after a HTTP POST request method is received: 1515 o The interface provides a HTTP/202 status code if the interface was 1516 able to receive the LORDN file and the syntax of the LORDN file is 1517 correct. 1519 The interface provides the LORDN Transaction Identifier in the 1520 HTTP Entity-body that would be used by the Registry to download 1521 the LORDN Log file. The LORDN Transaction Identifier is a 1522 natural number zero-padded in the range 0000000000000000001 to 1523 9223372036854775807. 1525 The TMDB uses the element of the 1526 LORDN file as a unique client-side identifier. If a LORDN file 1527 with the same of a previously sent 1528 LORDN file is received by the TMDB, the LORDN Transaction 1529 Identifier of the previously sent LORDN file MUST be provided 1530 to the Registry. The TMDB MUST ignore the DN Lines present in 1531 the LORDN file if a LORDN file with the same was previously sent. 1534 The HTTP Location header field contains the URI where the LORDN 1535 Log file could be retrieved later, for example: 1537 202 Accepted 1539 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1542 o The interface provides a HTTP/400 if the request is incorrect or 1543 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1544 human readable message in the HTTP Entity-body regarding the 1545 incorrect syntax of the LORDN file. 1547 o The interface provides a HTTP/401 status code if the credentials 1548 provided does not authorize the Registry Operator to upload a 1549 LORDN file. 1551 o The TMDB MUST return a HTTP/404 status code when trying to upload 1552 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1555 plus 26 hours. 1557 o The interface provides a HTTP/500 status code if the system is 1558 experiencing a general failure. 1560 For example, to upload the Sunrise LORDN file for TLD "example", the 1561 URI would be: 1563 < https:///LORDN/example/sunrise > 1565 The LORDN is contained in a CSV formatted file that has the following 1566 structure: 1568 o For Sunrise Period: 1570 * first line: ,, 1573 Where: 1575 - , version of the file, this field MUST be 1. 1577 - , date and time in UTC that the 1578 LORDN was created. 1580 - , number of DN Lines present in the 1581 LORDN file. 1583 * second line: a header line as specified in [RFC4180] 1585 With the header names as follows: 1587 roid,domain-name,SMD-id,registrar-id,registration- 1588 datetime,application-datetime 1590 * One or more lines with: ,,,,, 1594 Where: 1596 - , DN Repository Object IDentifier (DNROID) in the 1597 SRS. 1599 - , DN that was effectively allocated. For 1600 IDNs, the A-label form is used. 1602 - , SMD ID used for registration. 1604 - , IANA Registrar ID. 1606 - , date and time in UTC that the 1607 domain was effectively allocated. 1609 - OPTIONAL , date and 1610 time in UTC that the application was created. The 1611 MUST be provided in 1612 case of a DN effective allocation based on an 1613 asynchronous registration (e.g., when using auctions). 1615 Example of a Sunrise LORDN file 1617 1,2012-08-16T00:00:00.0Z,3 1618 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1619 application-datetime 1620 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1621 2012-07-15T00:50:00.0Z 1622 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1623 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1625 Figure 12 1627 o For Trademark Claims Period: 1629 * first line: ,, 1632 Where: 1634 - , version of the file, this field MUST be 1. 1636 - , date and time in UTC that the 1637 LORDN was created. 1639 - , number of DN Lines present in the 1640 LORDN file. 1642 * second line: a header line as specified in [RFC4180] 1644 With the header names as follows: 1646 roid,domain-name,notice-id,registrar-id,registration- 1647 datetime,ack-datetime,application-datetime 1649 * One or more lines with: ,,,,,, 1653 Where: 1655 - , DN Repository Object IDentifier (DNROID) in the 1656 SRS. 1658 - , DN that was effectively allocated. For 1659 IDNs, the A-label form is used. 1661 - , Trademark Claims Notice Identifier as specified 1662 in . 1664 - , IANA Registrar ID. 1666 - , date and time in UTC that the 1667 domain was effectively allocated. 1669 - , date and time in UTC 1670 that the TCN was acknowledged. 1672 - OPTIONAL , date and 1673 time in UTC that the application was created. The 1674 MUST be provided in 1675 case of a DN effective allocation based on an 1676 asynchronous registration (e.g., when using auctions). 1678 For a DN matching a DNL of a PRM at the moment of 1679 registration, created without the TCNID, expiration datetime 1680 and acceptance datetime, because DNL was inserted (or re- 1681 inserted) for the first time into DNL List less than 24 1682 hours ago, the string "recent-dnl-insertion" MAY be 1683 specified in and . 1686 Example of a Trademark Claims LORDN file 1688 1,2012-08-16T00:00:00.0Z,3 1689 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1690 ack-datetime,application-datetime 1691 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1692 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1693 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1694 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1695 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1696 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1698 Figure 13 1700 6.3.1. LORDN Log file 1702 After reception of the LORDN file, the TMDB verifies its content for 1703 syntactical and semantical correctness. The output of the LORDN file 1704 verification is retrieved using the yd interface (Section 4.3.7). 1706 The URI of the yd interface (Section 4.3.7) used to retrieve the 1707 LORDN Log file is: 1709 o Sunrise LORDN Log file: 1711 < https:///LORDN//sunrise//result > 1714 o Trademark Claims LORDN Log file: 1716 < https:///LORDN//claims//result > 1719 A Registry Operator MUST NOT send more than one request per minute 1720 per TLD to download a LORDN Log file. 1722 The yd interface (Section 4.3.7) returns the following HTTP status 1723 codes after a HTTP GET request method is received: 1725 o The interface provides a HTTP/200 status code if the interface was 1726 able to provide the LORDN Log file. The LORDN Log file is 1727 contained in the HTTP Entity-body. 1729 o The interface provides a HTTP/204 status code if the LORDN 1730 Transaction Identifier is correct, but the server has not 1731 finalized processing the LORDN file. 1733 o The interface provides a HTTP/400 status code if the request is 1734 incorrect. 1736 o The interface provides a HTTP/401 status code if the credentials 1737 provided does not authorize the Registry Operator to download the 1738 LORDN Log file. 1740 o The interface provides a HTTP/404 status code if the LORDN 1741 Transaction Identifier is incorrect. 1743 o The interface provides a HTTP/500 status code if the system is 1744 experiencing a general failure. 1746 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1747 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1748 "example" the URI would be: 1750 < https:///LORDN/example/sunrise/0000000000000000001/result > 1753 The LORDN Log file is contained in a CSV formatted file that has the 1754 following structure: 1756 o first line: ,,,,,, 1760 Where: 1762 + , version of the file, this field MUST be 1. 1764 + , date and time in UTC that the 1765 LORDN Log was created. 1767 + , date and time in UTC of 1768 creation for the LORDN file that this log file is referring 1769 to. 1771 + , unique identifier of the LORDN Log 1772 provided by the TMDB. This identifier could be used by the 1773 Registry Operator to unequivocally identify the LORDN Log. 1774 The identified will be a string of a maximum LENGTH of 60 1775 characters from the Base 64 alphabet. 1777 + , whether the LORDN file has been accepted for 1778 processing by the TMDB. Possible values are "accepted" or 1779 "rejected". 1781 + , whether the LORDN Log has any warning result 1782 codes. Possible values are "no-warnings" or "warnings- 1783 present". 1785 + , number of DNs effective allocations 1786 processed in the LORDN file. 1788 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1789 a ="accepted" and ="no-warnings". 1791 o second line: a header line as specified in [RFC4180] 1793 With the header names as follows: 1795 roid,result-code 1797 o One or more lines with: , 1799 Where: 1801 + , DN Repository Object IDentifier (DNROID) in the SRS. 1803 + , result code as described in Section 6.3.1.1. 1805 Example of a LORDN Log file 1807 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1808 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1809 accepted,no-warnings,1 1810 roid,result-code 1811 SH8013-REP,2000 1813 Figure 14 1815 6.3.1.1. LORDN Log Result Codes 1817 In Figure 15 the classes of result codes (rc) are listed. Those 1818 classes in square brackets are not used at this time, but may come 1819 into use at some later stage. The first two digits of a result code 1820 denote the result code class, which defines the outcome at the TMDB: 1822 o ok: Success, DN Line accepted by the TMDB. 1824 o warn: a warning is issued, DN Line accepted by the TMDB. 1826 o err: an error is issued, LORDN file rejected by the TMDB. 1828 In case that after processing a DN Line, the error result code is 1829 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1830 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1831 valid will be reported with a 2001 result code. A 2001 result code 1832 means that the DN Line is syntactically valid, however the DN Line 1833 was not processed because the LORDN file was rejected. All DNs 1834 reported in a rejected LORDN file MUST be reported again by the 1835 Registry because none of the DN Lines present in the LORDN file have 1836 been processed by the TMDB. 1838 LORDN Log Result Code Classes 1840 code Class outcome 1841 ---- ----- ------- 1843 20xx Success ok 1845 35xx [ DN Line syntax warning ] warn 1846 36xx DN Line semantic warning warn 1848 45xx DN Line syntax error err 1849 46xx DN Line semantic error err 1851 Figure 15 1853 In the following, the LORDN Log result codes used by the TMDB are 1854 described: 1856 LORDN Log result Codes 1858 rc Short Description 1859 Long Description 1860 ---- ------------------------------------------------------------- 1862 2000 OK 1863 DN Line successfully processed. 1865 2001 OK but not processed 1866 DN Line is syntactically correct but was not processed 1867 because the LORDN file was rejected. 1869 3601 TCN Acceptance Date after Registration Date 1870 TCN Acceptance Date in DN Line is newer than the Registration 1871 Date. 1873 3602 Duplicate DN Line 1874 This DN Line is an exact duplicate of another DN Line in same 1875 file, DN Line ignored. 1877 3603 DNROID Notified Earlier 1878 Same DNROID has been notified earlier, DN Line ignored. 1880 3604 TCN Checksum invalid 1881 Based on the DN effectively allocated, the TCNID and the 1882 expiration date of the linked TCN, the TCN Checksum is 1883 invalid. 1885 3605 TCN Expired 1886 The TCN was already expired (based on the 1887 field of the TCN) at the datetime of acknowledgement. 1889 3606 Wrong TCNID used 1890 The TCNID used for the registration does not match 1891 the related DN. 1893 3609 Invalid SMD used 1894 The SMD used for registration was not valid at the moment of 1895 registration based on the and 1896 elements. 1897 In case of an asynchronous registration, this refer to the 1898 . 1900 3610 DN reported outside of the time window 1901 The DN was reported outside of the required 26 hours 1902 reporting window. 1904 3611 DN does not match the labels in SMD 1905 The DN does not match the labels included in the SMD. 1907 3612 SMDID does not exist 1908 The SMDID has never existed in the central repository. 1910 3613 SMD was revoked when used 1911 The SMD used for registration was revoked more than 1912 24 hours ago of the . 1913 In case of an asynchronous registration, 1914 the is used when 1915 validating the DN Line. 1917 3614 TCNID does not exist 1918 The TCNID has never existed in the central repository. 1920 3615 Recent-dnl-insertion outside of the time window 1921 The DN registration is reported as a recent-dnl-insertion, 1922 but the (re) insertion into the DNL occurred more than 1923 24 hours ago. 1925 3616 Registration Date of DN in Claims before the end of Sunrise Period 1926 The registration date of the DN is before the end of Sunrise Period 1927 and the DN was reported in a Trademark Claims LORDN file. 1929 3617 Registrar has not been approved by the TMDB 1930 Registrar ID in DN Line has not completed Trademark Claims integration 1931 testing with the TMDB. 1933 3618 Registration Date of DN in a QLP LORDN file outside of the QLP Period 1934 The registration date of the DN in a QLP LORDN file is outside 1935 of the QLP Period. 1937 3619 TCN was not valid 1938 The TCN was not valid (based on the 1939 field of the TCN) at the datetime of acknowledgement. 1941 4501 Syntax Error in DN Line 1942 Syntax Error in DN Line. 1944 4601 Invalid TLD used 1945 The TLD in the DN Line does not match what is expected for 1946 this LORDN. 1948 4602 Registrar ID Invalid 1949 Registrar ID in DN Line is not a valid ICANN-Accredited 1950 Registrar. 1952 4603 Registration Date in the future 1953 The in the DN Line is in the 1954 future. 1956 4606 TLD not in Sunrise or Trademark Claims Period 1957 The was reported when the TLD was 1958 not in Sunrise or Trademark Claims Periods. 1959 In case of an asynchronous registration, 1960 the is used when 1961 validating the DN Line. 1963 4607 Application Date in the future 1964 The in the DN Line is in the 1965 future. 1967 4608 Application Date is later than Registration Date 1968 The in the DN Line is later 1969 than the . 1971 4609 TCNID wrong syntax 1972 The syntax of the TCNID is invalid. 1974 4610 TCN Acceptance Date is in the future 1975 The is in the future. 1977 4611 Label has never existed in the TMDB 1978 The label in the registered DN has never existed in the TMDB. 1980 Figure 16 1982 6.4. Signed Mark Data (SMD) File 1984 This section defines the format of the Signed Mark Data (SMD) File. 1985 After a successful registration of a mark, the TMV returns an SMD 1986 File to the TMH. The SMD File can then be used for registration of 1987 one or more DNs covered by the PRM during the Sunrise Period of a 1988 TLD. 1990 Two encapsulation boundaries are defined for delimiting the 1991 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1992 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1993 boundaries MUST be used by Registries and Registrars for validation 1994 purposes, i.e. any data outside these boundaries as well as the 1995 boundaries themselves MUST be ignored for validation purposes. 1997 The structure of the SMD File is as follows, all the elements are 1998 REQUIRED, and MUST appear in the specified order. 2000 1. Marks: 2002 2. smdID: 2004 3. U-labels: 2007 4. notBefore: 2009 5. notAfter: 2011 6. -----BEGIN ENCODED SMD----- 2013 7. 2015 8. -----END ENCODED SMD----- 2016 Example of an SMD File: 2018 Marks: Example One 2019 smdID: 1-2 2020 U-labels: example-one, exampleone 2021 notBefore: 2011-08-16 09:00 2022 notAfter: 2012-08-16 09:00 2023 -----BEGIN ENCODED SMD----- 2024 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2025 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2026 ... (base64 data elided for brevity) ... 2027 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2028 -----END ENCODED SMD----- 2030 Figure 17 2032 6.5. Trademark Claims Notice (TCN) 2034 The TMDB MUST provide the TCN to Registrars in XML format as 2035 specified below. 2037 An enclosing element that describes the Trademark 2038 Notice to a given label. 2040 The child elements of the element include: 2042 o A element that contains the unique identifier of the 2043 Trademark Notice. This element contains the the TCNID. 2045 The TCNID is a string concatenation of a TCN Checksum and the 2046 TMDB Notice Identifier. The first 8 characters of the TCNID is 2047 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2048 is a zero-padded natural number in the range of 2049 0000000000000000001 to 9223372036854775807. 2051 Example of a TCNID: 2053 370d0b7c9223372036854775807. 2055 Where: 2057 + TCN Checksum=370d0b7c 2059 + TMDB Notice Identifier=9223372036854775807 2060 The TCN Checksum is a 8 characters long Base16 encoded output 2061 of computing the CRC32 of the string concatenation of: label + 2062 unix_timestamp() + TMDB Notice Identifier 2064 TMDB MUST use the Unix time conversion of the 2065 in UTC to calculate the TCN Checksum. Unix 2066 time is defined as the number of seconds that have elapsed 2067 since 1970-01-01T00:00:00Z not counting leap seconds. For 2068 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2069 is shown: 2071 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2073 The TMDB uses the and 2074 elements from the TCN along with the TMDB Notice Identifier to 2075 compute the TCN Checksum. 2077 A Registry MUST use the leftmost DNL of the DN being 2078 effectively allocated, the expiration datetime of the TCN 2079 (provided by the Registrar) and the TMDB Notice Identifier 2080 extracted from the TCNID (provided by the Registrar) to compute 2081 the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- 2082 mgbh0fb" is being effectively allocated, the leftmost DNL would 2083 be "xn--mgbachtv". 2085 Example of computation of the TCN Checksum: 2087 CRC32(example-one12819492009223372036854775807)=370d0b7c 2089 o A element that contains the start of the 2090 validity date and time of the TCN. 2092 o A element that contains the expiration date 2093 and time of the TCN. 2095 o A element that contains the DNL covered by a PRM. 2097 o One or more elements that contain the Trademark 2098 Claim. The element contains the following child 2099 elements: 2101 * A element that contains the mark text 2102 string. 2104 * One or more elements that contains the 2105 information of the holder of the mark. An "entitlement" 2106 attribute is used to identify the entitlement of the holder, 2107 possible values are: owner, assignee or licensee. The child 2108 elements of include: 2110 + An OPTIONAL element that contains the name 2111 of the holder. A MUST be specified if 2112 is not specified. 2114 + An OPTIONAL element that contains the name of 2115 the organization holder of the mark. A MUST 2116 be specified if is not specified. 2118 + A element that contains the address 2119 information of the holder of a mark. A 2120 contains the following child elements: 2122 - One, two or three OPTIONAL elements 2123 that contains the organization's street address. 2125 - A element that contains the 2126 organization's city. 2128 - An OPTIONAL element that contains the 2129 organization's state or province. 2131 - An OPTIONAL element that contains the 2132 organization's postal code. 2134 - A element that contains the organization's 2135 country code. This a two-character code from 2136 [ISO3166-2]. 2138 + An OPTIONAL element that contains the 2139 organization's voice telephone number. 2141 + An OPTIONAL element that contains the 2142 organization's facsimile telephone number. 2144 + An OPTIONAL element that contains the email 2145 address of the holder. 2147 * Zero or more OPTIONAL elements that contains 2148 the information of the representative of the mark registration. 2149 A "type" attribute is used to identify the type of contact, 2150 possible values are: owner, agent or thirdparty. The child 2151 elements of include: 2153 + A element that contains name of the 2154 responsible person. 2156 + An OPTIONAL element that contains the name of 2157 the organization of the contact. 2159 + A element that contains the address 2160 information of the contact. A contains the 2161 following child elements: 2163 - One, two or three OPTIONAL elements 2164 that contains the contact's street address. 2166 - A element that contains the contact's 2167 city. 2169 - An OPTIONAL element that contains the 2170 contact's state or province. 2172 - An OPTIONAL element that contains the 2173 contact's postal code. 2175 - A element that contains the contact's 2176 country code. This a two-character code from 2177 [ISO3166-2]. 2179 + A element that contains the contact's voice 2180 telephone number. 2182 + An OPTIONAL element that contains the 2183 contact's facsimile telephone number. 2185 + A element that contains the contact's email 2186 address. 2188 * A element that contains the name (in 2189 English) of the jurisdiction where the mark is protected. A 2190 jurCC attribute contains the two-character code of the 2191 jurisdiction where the mark was registered. This is a two- 2192 character code from [WIPO.ST3]. 2194 * Zero or more OPTIONAL element that 2195 contains the description (in English) of the Nice 2196 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2197 attribute contains the class number. 2199 * A element that contains the full 2200 description of the goods and services mentioned in the mark 2201 registration document. 2203 * An OPTIONAL element signals that the 2204 claim notice was added to the TCN based on other rule (e.g. 2205 [Claims50] ) than exact match (defined in [MatchingRules]). 2206 The contains one or more: 2208 + An OPTIONAL element that signals that the 2209 claim notice was added because of a previously abused name 2210 included in an UDRP case. The contains: 2212 - A element that contains the UDRP case 2213 number used to validate the previously abused name. 2215 - A element that contains the name 2216 of the UDRP provider. 2218 + An OPTIONAL element that signals that the 2219 claim notice was added because of a previously abused name 2220 included in a court's resolution. The 2221 contains: 2223 - A element that contains the reference 2224 number of the court's resolution used to validate the 2225 previously abused name. 2227 - A element that contains the two-character 2228 code from [ISO3166-2] of the jurisdiction of the court. 2230 - A element that contains the name of 2231 the court. 2233 Example of a object: 2235 2236 2237 370d0b7c9223372036854775807 2238 2010-08-14T09:00:00.0Z 2239 2010-08-16T09:00:00.0Z 2240 example-one 2241 2242 Example One 2243 2244 Example Inc. 2245 2246 123 Example Dr. 2247 Suite 100 2248 Reston 2249 VA 2250 20190 2251 US 2252 2253 2254 2255 Joe Doe 2256 Example Inc. 2257 2258 123 Example Dr. 2259 Suite 100 2260 Reston 2261 VA 2262 20190 2263 US 2264 2265 +1.7035555555 2266 jdoe@example.com 2267 2268 UNITED STATES OF AMERICA 2269 2270 Advertising; business management; business administration. 2271 2272 2273 Insurance; financial affairs; monetary affairs; real estate. 2274 2275 2276 Bardus populorum circumdabit se cum captiosus populum. 2277 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2278 2279 2280 2281 Example-One 2282 2283 Example S.A. de C.V. 2284 2285 Calle conocida #343 2286 Conocida 2287 SP 2288 82140 2289 BR 2290 2291 2292 BRAZIL 2293 2294 Bardus populorum circumdabit se cum captiosus populum. 2295 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2296 2297 2298 2299 One 2300 2301 One Corporation 2302 2303 Otra calle 2304 Otra ciudad 2305 OT 2306 383742 2307 CR 2308 2309 2310 COSTA RICA 2311 2312 Bardus populorum circumdabit se cum captiosus populum. 2313 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2314 2315 2316 2317 234235 2318 CR 2319 Supreme Court of Justice of Costa Rica 2320 2321 2322 2323 2324 One Inc 2325 2326 One SA de CV 2327 2328 La calle 2329 La ciudad 2330 CD 2331 34323 2332 AR 2333 2334 2335 ARGENTINA 2336 2337 Bardus populorum circumdabit se cum captiosus populum. 2338 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2339 2340 2341 2342 D2003-0499 2343 WIPO 2344 2345 2347 2348 2350 For the formal syntax of the TCN please refer to Section 7.1. 2352 6.6. Sunrise List (SURL) 2354 This section defines the format of the list containing every Domain 2355 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2356 is maintained by the TMDB and downloaded by Registries in regular 2357 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2358 during the Qualified Launch Program Period to check whether a 2359 requested DN matches a DNL of a PRM eligible for Sunrise. 2361 The Sunrise List contains all the DNLs covered by a PRM eligible for 2362 Sunrise present in the TMDB at the datetime it is generated. 2364 The Sunrise List is contained in a CSV formatted file that has the 2365 following structure: 2367 o first line: , 2369 Where: 2371 + , version of the file, this field MUST be 1. 2373 + , date and time in UTC that 2374 the Sunrise List was created. 2376 o second line: a header line as specified in [RFC4180] 2378 With the header names as follows: 2380 DNL,insertion-datetime 2382 o One or more lines with: , 2384 Where: 2386 + , a Domain Name Label covered by a PRM eligible for 2387 Sunrise. 2389 + , datetime in UTC that the DNL was 2390 first inserted into the Sunrise List. The possible two 2391 values of time for inserting a DNL to the Sunrise List are 2392 00:00:00 and 12:00:00 UTC. 2394 Example of a SURL 2396 1,2012-08-16T00:00:00.0Z 2397 DNL,insertion-datetime 2398 example,2010-07-14T00:00:00.0Z 2399 another-example,2012-08-16T00:00:00.0Z 2400 anotherexample,2011-08-16T12:00:00.0Z 2402 Figure 18 2404 To provide authentication and integrity protection, the Sunrise List 2405 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2406 signature of the Sunrise List can be found in the similar URI but 2407 with extension .sig as shown below. 2409 The URL of the dy interface (Section 4.3.3) is: 2411 o < https:///dnl/surl-latest.csv > 2413 o < https:///dnl/surl-latest.sig > 2415 7. Formal Syntax 2417 7.1. Trademark Claims Notice (TCN) 2419 The schema presented here is for a Trademark Claims Notice. 2421 The BEGIN and END tags are not part of the schema; they are used to 2422 note the beginning and ending of the schema for URI registration 2423 purposes. 2425 Copyright (c) 2016 IETF Trust and the persons identified as authors 2426 of the code. All rights reserved. 2428 Redistribution and use in source and binary forms, with or without 2429 modification, is permitted pursuant to, and subject to the license 2430 terms contained in, the Simplified BSD License set forth in 2431 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 2432 Documents (http://trustee.ietf.org/license-info). 2434 BEGIN 2435 2436 2441 2442 2443 Schema for representing a Trademark Claim Notice. 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2467 2468 2469 2470 2471 2472 2474 2476 2477 2479 2480 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 END 2547 8. Acknowledgements 2549 This specification is a collaborative effort from several 2550 participants in the ICANN community. Bernie Hoeneisen participated 2551 as co-author until version 02 providing invaluable support for this 2552 document. This specification is based on a model spearheaded by: 2553 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2554 would also like to thank the thoughtful feedbak provided by many in 2555 the tmch-tech mailing list, but particularly the extensive help 2556 provided by James Gould, James Mitchell and Francisco Arias. This 2557 document includes feedback received from the following individuals: 2558 Paul Hoffman. 2560 9. Change History 2562 [[RFC Editor: Please remove this section.]] 2564 9.1. Version 04 2566 1. Ping update. 2568 9.2. Version 05 2570 1. Ping update. 2572 9.3. Version 06 2574 1. Updated the terminology text to reflect the text in RFC8174. 2576 2. Updated the reference of RFC7719 to RFC8499. 2578 3. Updated the matching rules document reference to link to the 2579 latest version. 2581 10. IANA Considerations 2583 This document uses URNs to describe XML namespaces and XML schemas 2584 conforming to a registry mechanism described in [RFC3688]. One URI 2585 assignment have been registered by the IANA. 2587 Registration request for the Trademark Claims Notice namespace: 2589 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2591 Registrant Contact: See the "Author's Address" section of this 2592 document. 2594 XML: None. Namespace URIs do not represent an XML specification. 2596 Registration request for the Trademark Claims Notice XML schema: 2598 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2600 Registrant Contact: See the "Author's Address" section of this 2601 document. 2603 XML: See Section 7.1 of this document. 2605 11. Security Considerations 2607 This specification uses HTTP Basic Authentication to provide a simple 2608 application-layer authentication service. HTTPS is used in all 2609 interfaces in order to protect against most common attacks. In 2610 addition, the client identifier is tied to a set of IP addresses that 2611 are allowed to connect to the interfaces described in this document, 2612 providing an extra security measure. 2614 The TMDB MUST provide credentials to the appropriate Registries and 2615 Registrars. 2617 The TMDB MUST require the use of strong passwords by Registries and 2618 Registrars. 2620 The TMDB, Registries and Registrars MUST use the best practices 2621 described in RFC 7525 or its successors. 2623 12. References 2624 12.1. Normative References 2626 [Claims50] 2627 ICANN, "Implementation Notes: Trademark Claims Protection 2628 for Previously Abused Names", July 2013, 2629 . 2632 [MatchingRules] 2633 ICANN, "Memorandum on Implementing Matching Rules", July 2634 2016, . 2637 [QLP-Addendum] 2638 ICANN, "Qualified Launch Program Addendum", April 2014, 2639 . 2643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2644 Requirement Levels", BCP 14, RFC 2119, 2645 DOI 10.17487/RFC2119, March 1997, 2646 . 2648 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2649 DOI 10.17487/RFC3688, January 2004, 2650 . 2652 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2653 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2654 . 2656 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2657 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2658 May 2017, . 2660 [RPM-Requirements] 2661 ICANN, "Rights Protection Mechanism Requirements", 2662 September 2013, . 2665 12.2. Informative References 2667 [ICANN-GTLD-AGB-20120604] 2668 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2669 2012, . 2672 [ISO3166-2] 2673 ISO, "International Standard for country codes and codes 2674 for their subdivisions", 2006, 2675 . 2677 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2678 DOI 10.17487/RFC2818, May 2000, 2679 . 2681 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2682 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2683 . 2685 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2686 Separated Values (CSV) Files", RFC 4180, 2687 DOI 10.17487/RFC4180, October 2005, 2688 . 2690 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2691 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2692 . 2694 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2695 Thayer, "OpenPGP Message Format", RFC 4880, 2696 DOI 10.17487/RFC4880, November 2007, 2697 . 2699 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2700 Housley, R., and W. Polk, "Internet X.509 Public Key 2701 Infrastructure Certificate and Certificate Revocation List 2702 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2703 . 2705 [RFC5890] Klensin, J., "Internationalized Domain Names for 2706 Applications (IDNA): Definitions and Document Framework", 2707 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2708 . 2710 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2711 Protocol (HTTP/1.1): Message Syntax and Routing", 2712 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2713 . 2715 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2716 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2717 DOI 10.17487/RFC7231, June 2014, 2718 . 2720 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2721 Protocol (HTTP/1.1): Authentication", RFC 7235, 2722 DOI 10.17487/RFC7235, June 2014, 2723 . 2725 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2726 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2727 January 2019, . 2729 [WIPO-NICE-CLASSES] 2730 WIPO, "WIPO Nice Classification", 2015, 2731 . 2733 [WIPO.ST3] 2734 WIPO, "Recommended standard on two-letter codes for the 2735 representation of states, other entities and 2736 intergovernmental organizations", March 2007, 2737 . 2739 Author's Address 2741 Gustavo Lozano 2742 ICANN 2743 12025 Waterfront Drive, Suite 300 2744 Los Angeles 90292 2745 US 2747 Phone: +1.3103015800 2748 Email: gustavo.lozano@icann.org