idnits 2.17.1 draft-ietf-regext-tmch-func-spec-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Nov 19, 2020) is 1247 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational Nov 19, 2020 5 Expires: May 23, 2021 7 ICANN TMCH functional specifications 8 draft-ietf-regext-tmch-func-spec-09 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 23, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 9 57 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 58 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . 13 77 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 78 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 79 5.1.1.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 14 80 5.1.1.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 14 81 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15 82 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 83 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 84 5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15 85 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 15 86 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.1. Domain Name registration . . . . . . . . . . . . . . 16 88 5.2.2. Sunrise Domain Name registration by Registries . . . 17 89 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 18 90 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18 91 5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 18 92 5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 19 93 5.2.4. Sunrise Domain Name registration by Registrars . . . 22 94 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 22 95 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23 96 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23 97 5.3.2. Trademark Claims Domain Name registration by 98 Registries . . . . . . . . . . . . . . . . . . . . . 24 99 5.3.3. TMBD Trademark Claims Services for Registries . . . . 25 100 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 25 101 5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 26 102 5.3.4. Trademark Claims Domain Name registration by 103 Registrars . . . . . . . . . . . . . . . . . . . . . 26 104 5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28 105 5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28 106 5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 28 107 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 28 108 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31 109 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31 110 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 31 111 6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 31 112 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 33 113 6.3. List of Registered Domain Names (LORDN) file . . . . . . 35 114 6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 40 115 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 116 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46 117 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47 118 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54 119 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 120 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 122 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58 123 9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58 124 9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58 125 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58 126 9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58 127 9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 59 128 9.6. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 59 129 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 130 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 131 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 132 12.1. Normative References . . . . . . . . . . . . . . . . . . 60 133 12.2. Informative References . . . . . . . . . . . . . . . . . 61 134 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 136 1. Introduction 138 Domain Name Registries (DNRs) may operate in special modes for 139 certain periods of time enabling trademark holders to protect their 140 rights during the introduction of a Top Level Domain (TLD). 142 Along with the introduction of new generic TLDs (gTLD), two special 143 modes came into effect: 145 o Sunrise Period, the Sunrise Period allows trademark holders an 146 advance opportunity to register domain names corresponding to 147 their marks before names are generally available to the public. 149 o Trademark Claims Period, the Trademark Claims Period follows the 150 Sunrise Period and runs for at least the first 90 days of an 151 initial operating period of general registration. During the 152 Trademark Claims Period, anyone attempting to register a domain 153 name matching a mark that is recorded in the ICANN Trademark 154 Clearinghouse (TMCH) will receive a notification displaying the 155 relevant mark information. 157 This document describes the requirements, the architecture and the 158 interfaces between the ICANN TMCH and Domain Name Registries (called 159 Registries in the rest of the document) as well as between the ICANN 160 TMCH and Domain Name Registrars (called Registrars in the rest of the 161 document) for the provisioning and management of domain names during 162 the Sunrise and Trademark Claims Periods. 164 For any date and/or time indications, Coordinated Universal Time 165 (UTC) applies. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 XML is case sensitive. Unless stated otherwise, XML specifications 176 and examples provided in this document MUST be interpreted in the 177 character case presented in order to develop a conforming 178 implementation. 180 "tmNotice-1.0" is used as an abbreviation for 181 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 182 "tmNotice" is used, but implementations MUST NOT depend on it and 183 instead employ a proper namespace-aware XML parser and serializer to 184 interpret and output the XML documents. 186 Extensible Markup Language (XML) 1.0 as described in 187 [W3C.REC-xml-20081126] and XML Schema notation as described in 188 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are 189 used in this specification. 191 3. Glossary 193 In the following section, the most common terms are briefly 194 explained: 196 o Backend Registry Operator: Entity that manages (a part of) the 197 technical infrastructure for a Registry Operator. The Registry 198 Operator may also be the Backend Registry Operator. 200 o CA: Certificate Authority, see [RFC5280]. 202 o CNIS, Claims Notice Information Service: This service provides 203 Trademark Claims Notices (TCN) to Registrars. 205 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 206 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 208 o CRL: Certificate Revocation List, see [RFC5280]. 210 o CSV: Comma-Separated Values, see [RFC4180] 212 o Date and time, datetime: Date and time are specified following the 213 standard "Date and Time on the Internet specification", see 214 [RFC3339]. 216 o DN, Domain Name, domain name: see definition of Domain name in 217 [RFC8499]. 219 o DNROID, DN Repository Object IDentifier: an identifier assigned by 220 the Registry to each DN object that unequivocally identifies said 221 DN object. For example, if a new DN object is created for a name 222 that existed in the past, the DN objects will have different 223 DNROIDs. 225 o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see 226 [RFC5890]). 228 o DNL List: A list of DNLs that are covered by a PRM. 230 o DNS: Domain Name System, see [RFC8499]. 232 o Effective allocation: A DN is considered effectively allocated 233 when the DN object for the DN has been created in the SRS of the 234 Registry and has been assigned to the effective user. A DN object 235 in status "pendingCreate" or any other status that precedes the 236 first time a DN is assigned to an end-user is not considered an 237 effective allocation. A DN object created internally by the 238 Registry for subsequent delegation to another Registrant is not 239 considered an effective allocation. 241 o EPP: The Extensible Provisioning Protocol, see definition of EPP 242 in [RFC8499]. 244 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 245 [RFC8499]. 247 o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. 249 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 251 o IDN: Internationalized Domain Name, see definition of IDN in 252 [RFC8499]. 254 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 255 Z0-9/] to be used as the lookup key by Registrars to obtain the 256 TCN using the CNIS. Lookup Keys are unique and are related to one 257 DNL only. 259 o LORDN, List of Registered Domain Names: This is the list of 260 effectively allocated DNs matching a DNL of a PRM. Registries 261 will upload this list to the TMDB (during the NORDN process). 263 o Matching Rules: Some trademarks entitled to inclusion in the TMDB 264 include characters that are impermissible in the domain name 265 system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH 266 Matching Rules [MatchingRules]) certain DNS-impermissible 267 characters in a trademark into DNS-permissible equivalent 268 characters 270 o NORDN, Notification of Registered Domain Names: The process by 271 which Registries upload their recent LORDN to the TMDB. 273 o PGP: Pretty Good Privacy, see [RFC4880] 275 o PKI: Public Key Infrastructure, see [RFC5280]. 277 o PRM, Pre-registered mark: Mark that has been pre-registered with 278 the ICANN TMCH. 280 o QLP Period, Qualified Launch Program Period: During this optional 281 period, a special process applies to DNs matching the Sunrise List 282 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 283 DN matching their PRM. 285 o Registrant: see definition of Registrant in [RFC8499]. 287 o Registrar, Domain Name Registrar: see definition of Registrar in 288 [RFC8499]. 290 o Registry, Domain Name Registry, Registry Operator: see definition 291 of Registry in [RFC8499]. A Registry Operator is the contracting 292 party with ICANN for the TLD. 294 o SMD, Signed Mark Data: A cryptographically signed token issued by 295 the TMV to the TMH to be used in the Sunrise Period to apply for a 296 DN that matches a DNL of a PRM; see also [RFC7848]. An SMD 297 generated by an ICANN-approved trademark validator (TMV) contains 298 both the signed token and the TMV's PKIX certificate. 300 o SMD File: A file containing the SMD (see above) and some human 301 readable data. The latter is usually ignored in the processing of 302 the SMD File. See also Section 6.4. 304 o SMD Revocation List: The SMD Revocation List is used by Registries 305 (and optionally by Registrars) during the Sunrise Period to ensure 306 that an SMD is still valid (i.e. not revoked). The SMD Revocation 307 List has a similar function as CRLs used in PKI. 309 o SRS: Shared Registration System, see also 310 [ICANN-GTLD-AGB-20120604]. 312 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 313 eligible for Sunrise. 315 o Sunrise Period: During this period DNs matching a DNL of a PRM can 316 be exclusively obtained by the respective TMHs. For DNs matching 317 a PRM, a special process applies to ensure that TMHs are informed 318 on the effective allocation of a DN matching their PRM. 320 o TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. 322 o ICANN TMCH: a central repository for information to be 323 authenticated, stored, and disseminated, pertaining to the rights 324 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 325 (see below). There could be several entities performing the TMV 326 function, but only one entity performing the TMDB function. 328 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 329 This CA is operated by ICANN. The public key for this CA is the 330 trust anchor used to validate the identity of each TMV. 332 o TMDB, Trademark Clearinghouse Database: Serves as a database of 333 the ICANN TMCH to provide information to the gTLD Registries and 334 Registrars to support Sunrise or Trademark Claims services. There 335 is only one TMDB in the ICANN TMCH that concentrates the 336 information about the "verified" Trademark records from the TMVs. 338 o TMH, Trademark Holder: The person or organization owning rights on 339 a mark. 341 o TMV, Trademark Validator, Trademark validation organization: An 342 entity authorized by ICANN to authenticate and validate 343 registrations in the TMDB ensuring the marks qualify as registered 344 or are court-validated marks or marks that are protected by 345 statute or treaty. This entity would also be asked to ensure that 346 proof of use of marks is provided, which can be demonstrated by 347 furnishing a signed declaration and one specimen of current use. 349 o Trademark, mark: Marks are used to claim exclusive properties of 350 products or services. A mark is typically a name, word, phrase, 351 logo, symbol, design, image, or a combination of these elements. 352 For the scope of this document only textual marks are relevant. 354 o Trademark Claims, Claims: Provides information to enhance the 355 understanding of the Trademark rights being claimed by the TMH. 357 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 358 Trademark Claims Notice consist of one or more Trademark Claims 359 and are provided to prospective Registrants of DNs. 361 o TCNID, Trademark Claims Notice Identifier: An element of the 362 Trademark Claims Notice (see above), identifying said TCN. The 363 Trademark Claims Notice Identifier is specified in the element 364 . 366 o Trademark Claims Period: During this period, a special process 367 applies to DNs matching the DNL List, to ensure that TMHs are 368 informed of a DN matching their PRM. For DNs matching the DNL 369 List, Registrars show a TCN to prospective Registrants that has to 370 be acknowledged before effective allocation of the DN. 372 o UTC: Coordinated Universal Time, as maintained by the Bureau 373 International des Poids et Mesures (BIPM); see also [RFC3339]. 375 4. Architecture 377 4.1. Sunrise Period 379 Architecture of the Sunrise Period 381 SMD hand over (out-of-band) 382 .............................................. 383 : : 384 : .'''''''''''''''''''. : 385 : . ICANN TMCH . : 386 : ..................... : 387 v . . : 388 .------------. . .-------------. . hv .-----. 389 | Registrant | . | TMV |<---------->| TMH | 390 '------------' . '-------------' . vh '-----' 391 | . | ^ \ . 392 | . | | \. 393 tr | . vs | | dv \ 394 | . | vd | .\ 395 v . v v . \ 396 .-----------. sr . .---------. . \ 397 .->| Registrar |<..........| | . \ 398 : '-----------' . | | . \ 399 : | sy . | T | . \ 400 : ry | .------------| M | . vc \ 401 : | | . | D | . \ 402 : v v . | B | . v 403 : .-----------. . yd | | . .---------------. 404 : | Registry |---------->| | . | ICANN TMCH-CA | 405 : '-----------' . '---------' . '---------------' 406 : ^ . . | : 407 : | ''''''''''''''''''' | : 408 : | cy | : 409 : cr '-----------------------------------------' : 410 :......................................................: 412 Figure 1 414 4.2. Trademark Claims Period 416 Architecture of the Trademark Claims Period 418 .''''''''''''''. 419 . ICANN TMCH . 420 ................ 421 . . 422 .------------. . .-------. . hv .-----. 423 | Registrant | . | TMV |<----------->| TMH | 424 '------------' . '-------' . vh '-----' 425 | . ^ . 426 | . | dv . 427 tr | . vd | . 428 v . v . 429 .-----------. dr . .-------. . 430 | Registrar |<--------| | . 431 '-----------' . | T | . 432 ry | . | M | . 433 v . | D | . 434 .----------. dy . | B | . 435 | Registry |<------->| | . 436 '----------' yd . '-------' . 437 . . 438 '''''''''''''' 440 Figure 2 442 4.3. Interfaces 444 In the sub-sections below follows a short description of each 445 interface to provide an overview of the architecture. More detailed 446 descriptions of the relevant interfaces follow further below 447 (Section 5). 449 4.3.1. hv 451 The TMH registers a mark with a TMV via the hv interface. 453 After the successful registration of the mark, the TMV makes 454 available a SMD File (see also Section 6.4) to the TMH to be used 455 during the Sunrise Period. 457 The specifics of the hv interface are beyond the scope of this 458 document. 460 4.3.2. vd 462 After successful mark registration, the TMV ensures the TMDB inserts 463 the corresponding DNLs and mark information into the database via the 464 vd interface. 466 The specifics of the vd interface are beyond the scope of this 467 document. 469 4.3.3. dy 471 During the Trademark Claims Period the Registry fetches the latest 472 DNL List from the TMDB via the dy interface at regular intervals. 473 The protocol used on the dy interface is HTTPS. 475 Not relevant during the Sunrise Period. 477 4.3.4. tr 479 The Registrant communicates with the Registrar via the tr interface. 481 The specifics of the tr interface are beyond the scope of this 482 document. 484 4.3.5. ry 486 The Registrar communicate with the Registry via the ry interface. 487 The ry interfaces is typically implemented in EPP. 489 4.3.6. dr 491 During the Trademark Claims Period, the Registrar fetches the TCN 492 from the TMDB (to be displayed to the Registrant via the tr 493 interface) via the dr interface. The protocol used for fetching the 494 TCN is HTTPS. 496 Not relevant during the Sunrise Period. 498 4.3.7. yd 500 During the Sunrise Period the Registry notifies the TMDB via the yd 501 interface of all DNs effectively allocated. 503 During the Trademark Claims Period, the Registry notifies the TMDB 504 via the yd interface of all DNs effectively allocated that matched an 505 entry in the Registry previously downloaded DNL List during the 506 creation of the DN. 508 The protocol used on the yd interface is HTTPS. 510 4.3.8. dv 512 The TMDB notifies via the dv interface to the TMV of all DNs 513 effectively allocated that match a mark registered by that TMV. 515 The specifics of the dv interface are beyond the scope of this 516 document. 518 4.3.9. vh 520 The TMV notifies the TMH via the vh interface after a DN has been 521 effectively allocated that matches a PRM of this TMH. 523 The specifics of the vh interface are beyond the scope of this 524 document. 526 4.3.10. vs 528 The TMV requests to add a revoked SMD to the SMD Revocation List at 529 the TMDB. 531 The specifics of the vs interface are beyond the scope of this 532 document. 534 Not relevant during the Trademark Claims Period. 536 4.3.11. sy 538 During the Sunrise Period the Registry fetches the most recent SMD 539 Revocation List from the TMDB via the sy interface in regular 540 intervals. The protocol used on the sy interface is HTTPS. 542 Not relevant during the Trademark Claims Period. 544 4.3.12. sr 546 During the Sunrise Period the Registrar may fetch the most recent SMD 547 Revocation List from the TMDB via the sr interface. The protocol 548 used on the sr interface is the same as on the sy interface (s. 549 above), i.e. HTTPS. 551 Not relevant during the Trademark Claims Period. 553 4.3.13. vc 555 The TMV registers its public key, and requests to revoke an existing 556 key, with the ICANN TMCH-CA over the vc interface. 558 The specifics of the vc interface are beyond the scope of this 559 document, but it involves personal communication between the 560 operators of the TMV and the operators of the ICANN TMCH-CA. 562 Not relevant during the Trademark Claims Period. 564 4.3.14. cy 566 During the Sunrise Period the Registry fetches the most recent TMV 567 CRL file from the ICANN TMCH-CA via the cy interface at regular 568 intervals. The TMV CRL is used for validation of TMV certificates. 569 The protocol used on the cy interface is HTTPS. 571 Not relevant during the Trademark Claims Period. 573 4.3.15. cr 575 During the Sunrise Period the Registrar optionally fetches the most 576 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 577 regular intervals. The TMV CRL is used for validation of TMV 578 certificates. The protocol used on the cr interface is HTTPS. 580 Not relevant during the Trademark Claims Period. 582 5. Process Descriptions 584 5.1. Bootstrapping 586 5.1.1. Bootstrapping for Registries 588 5.1.1.1. Credentials 590 Each Registry Operator will receive authentication credentials from 591 the TMDB to be used: 593 o During the Sunrise Period to fetch the SMD Revocation List from 594 the TMBD via the sy interface (Section 4.3.11). 596 o During the Trademark Claims Period to fetch the DNL List from the 597 TMDB via the dy interface (Section 4.3.3). 599 o During the NORDN process to notify the LORDN to the TMDB via the 600 yd interface (Section 4.3.7). 602 Note: credentials are created per TLD and provided to the Registry 603 Operator. 605 5.1.1.2. IP Addresses for Access Control 607 Each Registry Operator MUST provide to the TMDB all IP addresses that 608 will be used to: 610 o Fetch the SMD Revocation List via the sy interface 611 (Section 4.3.11). 613 o Fetch the DNL List from the TMDB via the dy interface 614 (Section 4.3.3). 616 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 618 This access restriction MAY be applied by the TMDB in addition to 619 HTTP Basic access authentication (see [RFC7235]). For credentials to 620 be used, see Section 5.1.1.1. 622 The TMDB MAY limit the number of IP addresses to be accepted per 623 Registry Operator. 625 5.1.1.3. ICANN TMCH Trust Anchor 627 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 628 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 629 tmch.crt > to be used: 631 o During the Sunrise Period to validate the TMV certificates and the 632 TMV CRL. 634 5.1.1.4. TMDB PGP Key 636 The TMDB MUST provide each Registry Operator with the public portion 637 of the PGP Key used by TMDB, to be used: 639 o During the Sunrise Period to perform integrity checking of the SMD 640 Revocation List fetched from the TMDB via the sy interface 641 (Section 4.3.11). 643 o During the Trademark Claims Period to perform integrity checking 644 of the DNL List fetched from the TMDB via the dy interface 645 (Section 4.3.3). 647 5.1.2. Bootstrapping for Registrars 649 5.1.2.1. Credentials 651 Each ICANN-accredited Registrar will receive authentication 652 credentials from the TMDB to be used: 654 o During the Sunrise Period to (optionally) fetch the SMD Revocation 655 List from the TMDB via the sr interface (Section 4.3.12). 657 o During the Trademark Claims Period to fetch TCNs from the TMDB via 658 the dr interface (Section 4.3.6). 660 5.1.2.2. IP Addresses for Access Control 662 Each Registrar MUST provide to the TMDB all IP addresses, which will 663 be used to: 665 o Fetch the SMD Revocation List via the sr interface 666 (Section 4.3.12). 668 o Fetch TCNs via the dr interface (Section 4.3.6). 670 This access restriction MAY be applied by the TMDB in addition to 671 HTTP Basic access authentication (for credentials to be used, see 672 Section 5.1.2.1). 674 The TMDB MAY limit the number of IP addresses to be accepted per 675 Registrar. 677 5.1.2.3. ICANN TMCH Trust Anchor 679 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 680 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 682 o During the Sunrise Period to (optionally) validate the TMV 683 certificates and TMV CRL. 685 5.1.2.4. TMDB PGP Key 687 Registrars MUST receive the public portion of the PGP Key used by 688 TMDB from the TMDB administrator to be used: 690 o During the Sunrise Period to (optionally) perform integrity 691 checking of the SMD Revocation List fetched from the TMDB via the 692 sr interface (Section 4.3.12). 694 5.2. Sunrise Period 696 5.2.1. Domain Name registration 698 Domain Name registration during the Sunrise Period 700 .------------. .-----------. .----------. 701 | Registrant | | Registrar | | Registry | 702 '------------' '-----------' '----------' 703 | | | 704 | Request DN | | 705 | registration | | 706 | (with SMD) | | 707 |---------------->| Check DN availability | 708 | |---------------------------->| 709 | | | 710 | | DN unavailable .-------------. 711 | DN unavailable |<--------------------( DN available? ) 712 |<----------------| no '-------------' 713 | | | yes 714 | | DN available | 715 | |<----------------------------| 716 | | | 717 | | Request DN registration | 718 | | (with SMD) | 719 | |---------------------------->| 720 | | | 721 | | .------------------------------. 722 | | | DN registration validation / | 723 | | | SMD validation | 724 | | '------------------------------' 725 | | | 726 | Registration |.-----------. Error .----------------------. 727 | error || TRY AGAIN |<-----( Validation successful? ) 728 |<----------------|| / ABORT | no '----------------------' 729 | |'-----------' | yes 730 | | | 731 | | DN registered | 732 | DN registered |<----------------------------| 733 |<----------------| | 734 | | | 736 Figure 3 738 Note: the figure depicted above represents a synchronous DN 739 registration workflow (usually called first come first served). 741 5.2.2. Sunrise Domain Name registration by Registries 743 Registries MUST perform a minimum set of checks for verifying each DN 744 registration during the Sunrise Period upon reception of a 745 registration request over the ry interface (Section 4.3.5). If any 746 of these checks fails the Registry MUST abort the registration. Each 747 of these checks MUST be performed before the DN is effectively 748 allocated. 750 In case of asynchronous registrations (e.g. auctions), the minimum 751 set of checks MAY be performed when creating the intermediate object 752 (e.g. a DN application) used for DN registration. If the minimum set 753 of checks is performed when creating the intermediate object (e.g. a 754 DN application) a Registry MAY effectively allocate the DN without 755 performing the minimum set of checks again. 757 Performing the minimum set of checks Registries MUST verify that: 759 1. An SMD has been received from the Registrar along with the DN 760 registration. 762 2. The certificate of the TMV has been correctly signed by the ICANN 763 TMCH-CA. (The certificate of the TMV is contained within the 764 SMD.) 766 3. The datetime when the validation is done is within the validity 767 period of the TMV certificate. 769 4. The certificate of the TMV is not listed in the TMV CRL file 770 specified in the CRL distribution point of the TMV certificate. 772 5. The signature of the SMD (signed with the TMV certificate) is 773 valid. 775 6. The datetime when the validation is done is within the validity 776 period of the SMD based on and 777 elements. 779 7. The SMD has not been revoked, i.e., is not contained in the SMD 780 Revocation List. 782 8. The leftmost DNL of the DN being effectively allocated matches 783 one of the labels () elements in the SMD. For 784 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 785 effectively allocated, the leftmost DNL would be "xn--mgbachtv". 787 These procedure apply to all DN effective allocations at the second 788 level as well as to all other levels subordinate to the TLD that the 789 Registry accepts registrations for. 791 5.2.3. TMDB Sunrise Services for Registries 793 5.2.3.1. SMD Revocation List 795 A new SMD Revocation List MUST be published by the TMDB twice a day, 796 by 00:00:00 and 12:00:00 UTC. 798 Registries MUST refresh the latest version of the SMD Revocation List 799 at least once every 24 hours. 801 Note: the SMD Revocation List will be the same regardless of the TLD. 802 If a Backend Registry Operator manages the infrastructure of several 803 TLDs, the Backend Registry Operator could refresh the SMD Revocation 804 List once every 24 hours, the SMD Revocation List could be used for 805 all the TLDs managed by the Backend Registry Operator. 807 Update of the SMD Revocation List 809 .----------. .------. 810 | Registry | | TMDB | 811 '----------' '------' 812 | | 813 .----------------. | 814 | Periodically, | | 815 | at least | | 816 | every 24 hours | | 817 '----------------' | 818 | | 819 |----------------------------------------------------->| 820 | Download the latest SMD Revocation List | 821 |<-----------------------------------------------------| 822 | | 823 | | 825 Figure 4 827 5.2.3.2. TMV Certificate Revocation List (CRL) 829 Registries MUST refresh their local copy of the TMV CRL file at least 830 every 24 hours using the CRL distribution point specified in the TMV 831 certificate. 833 Operationally, the TMV CRL file and CRL distribution point is the 834 same for all TMVs and (at publication of this document) located at < 835 http://crl.icann.org/tmch.crl >. 837 Note: the TMV CRL file will be the same regardless of the TLD. If a 838 Backend Registry Operator manages the infrastructure of several TLDs, 839 the Backend Registry Operator could refresh the TMV CRL file once 840 every 24 hours, the TMV CRL file could be used for all the TLDs 841 managed by the Backend Registry Operator. 843 Update of the TMV CRL file 845 .----------. .---------------. 846 | Registry | | ICANN TMCH-CA | 847 '----------' '---------------' 848 | | 849 .----------------. | 850 | Periodically, | | 851 | at least | | 852 | every 24 hours | | 853 '----------------' | 854 | | 855 |-------------------------------------------->| 856 | Download the latest TMV CRL file | 857 |<--------------------------------------------| 858 | | 859 | | 861 Figure 5 863 5.2.3.3. Notice of Registered Domain Names (NORN) 865 The Registry MUST send a LORDN file containing DNs effectively 866 allocated to the TMDB (over the yd interface, Section 4.3.7). 868 The effective allocation of a DN MUST be reported by the Registry to 869 the TMDB within 26 hours of the effective allocation of such DN. 871 The Registry MUST create and upload a LORDN file in case there are 872 effective allocations in the SRS, that have not been successfully 873 reported to the TMDB in a previous LORDN file. 875 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 876 maximum frequency to upload LORDN files from the Registries to the 877 TMDB is every 3 hours. 879 It is RECOMMENDED that Registries try to upload at least two LORDN 880 files per day to the TMDB with enough time in between, in order to 881 have time to fix problems reported in the LORDN file. 883 The Registry SHOULD upload a LORDN file only when the previous LORDN 884 file has been processed by the TMDB and the related LORDN Log file 885 has been downloaded and processed by the Registry. 887 The Registry MUST upload LORDN files for DNs effectively allocated 888 during the Sunrise or Trademark Claims Period (same applies to DNs 889 effectively allocated using applications created during the Sunrise 890 or Trademark Claims Period in case of using asynchronous 891 registrations). 893 The yd interface (Section 4.3.7) MUST support at least one (1) and 894 MAY support up to ten (10) concurrent connections from each IP 895 address registered by a Registry Operator to access the service. 897 The TMDB MUST process each uploaded LORDN file and make the related 898 log file available for Registry download within 30 minutes of the 899 finalization of the upload. 901 Notification of Registered Domain Name 903 .----------. .------. .-----. .-----. 904 | Registry | | TMDB | | TMV | | TMH | 905 '----------' '------' '-----' '-----' 906 | | | | 907 .------------------. | | | 908 | Periodically | | | | 909 | upload LORDN | | | | 910 | file | | | | 911 '------------------' | | | 912 | | | | 913 .--------->| Upload LORDN | | | 914 | |-------------------->| | | 915 | | | | | 916 | | .-------------------------. | | 917 | | | Verify each domain name | | | 918 | | | in the uploaded file | | | 919 | | | (within 30') | | | 920 | | '-------------------------' | | 921 | | | ._____.| | 922 | | Download Log file | | END || | 923 | |<--------------------| '-----'| | 924 | | | ^ | | 925 | .-----------------. .---------------. | | | 926 | | Check whether | / everything fine \ no | | | 927 | | Log file | ( (i.e. no errors )---' | | 928 | | contains errors | \ in Log file )? / | | 929 | '-----------------' '---------------' | | 930 | | | yes | | 931 | .---------------. | | | 932 | / everything fine \ yes | | | 933 |( (i.e. no errors )-----. | Notify TMVs | | 934 | \ in Log file )? / | | on the LORDN | | 935 | '---------------' | | pre-registered | | 936 | | no v | with said TMV | | 937 | .----------------. .------. |--------------->| | 938 '-| Correct Errors | | DONE | | | | 939 '----------------' '------' | | Notify each | 940 | | | affected TMH | 941 | | |-------------->| 942 | | | | 944 Figure 6 946 The format used for the LORDN is described in Section 6.3 948 5.2.4. Sunrise Domain Name registration by Registrars 950 Registrars MAY choose to perform the checks for verifying DN 951 registrations as performed by the Registries (see Section 5.2.2) 952 before sending the command to register a DN. 954 5.2.5. TMDB Sunrise Services for Registrars 956 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 957 also available for Registrars to optionally validate the SMDs 958 received. 960 5.3. Trademark Claims Period 962 5.3.1. Domain Registration 964 Domain Name registration during the Trademark Claims Period 966 .------------. .-----------. .----------. .------. 967 | Registrant | | Registrar | | Registry | | TMDB | 968 '------------' '-----------' '----------' '------' 969 | Request DN | | | 970 | registration | | | 971 |--------------->| Check DN availability | | 972 | |--------------------------->| | 973 | | DN unavailable .-------------. | 974 | DN unavailable |<-------------------( DN available? ) | 975 |<---------------| no '-------------' | 976 | | DN available | yes | 977 | |<---------------------------| | 978 | | Request Lookup key | | 979 | |--------------------------->| | 980 | |.__________. .---------. | 981 | || CONTINUE | / Does DN \ | 982 | || NORMALLY |<--------( match DNL ) | 983 | |'----------' no \ of PRM? / | 984 | | '---------' | 985 | | Lookup key | yes | 986 | |<----------------------------' | 987 | | | 988 .-----. | | Request TCN | 989 |ABORT| | Display |---------------------------------------->| 990 '-----' | Claims | Return TCN | 991 ^ | Notice |<----------------------------------------| 992 | no |<---------------| | 993 | .------. yes | | 994 '-( Ack? )----------->| Register DN (with TCNID) | | 995 '------' |--------------------------->| | 996 | Registration | Error .----------------------. | 997 | error |<-------------( Validation successful? ) | 998 |<---------------| no '----------------------' | 999 | | | yes | 1000 | | DN registered | | 1001 | DN registered |<---------------------------| | 1002 |<---------------| | | 1004 Figure 7 1006 Note: the figure depicted above represents a synchronous DN 1007 registration workflow (usually called first come first served). 1009 5.3.2. Trademark Claims Domain Name registration by Registries 1011 During the Trademark Claims Period, Registries perform two main 1012 functions: 1014 o Registries MUST provide Registrars (over the ry interface, 1015 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1016 that match the DNL List. 1018 o Registries MUST provide the Lookup Key only when queried about a 1019 specific DN. 1021 o For each DN matching a DNL of a PRM, Registries MUST perform a 1022 minimum set of checks for verifying DN registrations during the 1023 Trademark Claims Period upon reception of a registration request 1024 over the ry interface (Section 4.3.5). If any of these checks 1025 fails the Registry MUST abort the registration. Each of these 1026 checks MUST be performed before the DN is effectively allocated. 1028 o In case of asynchronous registrations (e.g. auctions), the minimum 1029 set of checks MAY be performed when creating the intermediate 1030 object (e.g. a DN application) used for DN effective allocation. 1031 If the minimum set of checks is performed when creating the 1032 intermediate object (e.g. a DN application) a Registry MAY 1033 effectively allocate the DN without performing the minimum set of 1034 checks again. 1036 o Performing the minimum set of checks Registries MUST verify that: 1038 1. The TCNID (), expiration datetime 1039 () and acceptance datetime of the TCN, have 1040 been received from the Registrar along with the DN 1041 registration. 1043 If the three elements mentioned above are not provided by 1044 the Registrar for a DN matching a DNL of a PRM, but the DNL 1045 was inserted (or re-inserted) for the first time into DNL 1046 List less than 24 hours ago, the registration MAY continue 1047 without this data and the tests listed below are not 1048 required to be performed. 1050 2. The TCN has not expired (according to the expiration datetime 1051 sent by the Registrar). 1053 3. The acceptance datetime is within the window of time defined 1054 by ICANN policy. In the gTLD round of 2012, Registrars 1055 verified that the acceptance datetime was less than or equal 1056 to 48 hours in the past, as there were no defined ICANN 1057 policies at that time. Implementers should be aware that 1058 ICANN policy may define this value in the future. 1060 4. Using the leftmost DNL of the DN being effectively allocated, 1061 the expiration datetime provided by the Registrar, and the 1062 TMDB Notice Identifier extracted from the TCNID provided by 1063 the Registrar compute the TCN Checksum. Verify that the 1064 computed TCN Checksum match the TCN Checksum present in the 1065 TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is 1066 being effectively allocated, the leftmost DNL would be "xn-- 1067 mgbachtv". 1069 These procedures apply to all DN registrations at the second level as 1070 well as to all other levels subordinate to the TLD that the Registry 1071 accepts registrations for. 1073 5.3.3. TMBD Trademark Claims Services for Registries 1075 5.3.3.1. Domain Name Label (DNL) List 1077 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1078 and 12:00:00 UTC. 1080 Registries MUST refresh the latest version of the DNL List at least 1081 once every 24 hours. 1083 Update of the DNL List 1085 .----------. .------. 1086 | Registry | | TMDB | 1087 '----------' '------' 1088 | | 1089 .----------------. | 1090 | Periodically, | | 1091 | at least | | 1092 | every 24 hours | | 1093 '----------------' | 1094 | | 1095 |-------------------------------->| 1096 | Download the latest DNL List | 1097 |<--------------------------------| 1098 | | 1099 | | 1101 Figure 8 1103 Note: the DNL List will be the same regardless of the TLD. If a 1104 Backend Registry Operator manages the infrastructure of several TLDs, 1105 the Backend Registry Operator could refresh the DNL List once every 1106 24 hours, the DNL List could be used for all the TLDs managed by the 1107 Backend Registry Operator. 1109 5.3.3.2. Notice of Registered Domain Names (NORN) 1111 The NORDN process during the Trademark Claims Period is almost the 1112 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1113 difference that only registrations subject to a Trademark Claim 1114 (i.e., at registration time the name appeared in the current DNL List 1115 downloaded by the Registry Operator) are included in the LORDN. 1117 5.3.4. Trademark Claims Domain Name registration by Registrars 1119 For each DN matching a DNL of a PRM, Registrars MUST perform the 1120 following steps: 1122 1. Use the Lookup Key received from the Registry to obtain the TCN 1123 from the TMDB using the dr interface (Section 4.3.6) Registrars 1124 MUST only query for the Lookup Key of a DN that is available for 1125 registration. 1127 2. Present the TCN to the Registrant as described in Exhibit A, 1128 [RPM-Requirements]. 1130 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1131 consent with the TCN, before any further processing. (The 1132 transmission of a TCNID to the Registry over the ry interface, 1133 Section 4.3.5 implies that the Registrant has expressed his/her 1134 consent with the TCN.) 1136 4. Perform the minimum set of checks for verifying DN registrations. 1137 If any of these checks fails the Registrar MUST abort the DN 1138 registration. Each of these checks MUST be performed before the 1139 registration is sent to the Registry. Performing the minimum set 1140 of checks Registrars MUST verify that: 1142 1. The datetime when the validation is done is within the TCN 1143 validity based on the and 1144 elements. 1146 2. The leftmost DNL of the DN being effectively allocated 1147 matches the label () element in the TCN. For 1148 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 1149 effectively allocated, the leftmost DNL would be "xn-- 1150 mgbachtv". 1152 3. The Registrant has acknowledged (expressed his/her consent 1153 with) the TCN. 1155 5. Record the date and time when the registrant acknowledged the 1156 TCN. 1158 6. Send the registration to the Registry (ry interface, 1159 Section 4.3.5) and include the following information: 1161 * TCNID () 1163 * Expiration date of the TCN () 1165 * Acceptance datetime of the TCN. 1167 Currently TCNs are generated twice a day by the TMDB. The expiration 1168 date () of each TCN MUST be set to a value defined 1169 by ICANN policy. In the gTLD round of 2012, the TMDB set the 1170 expiration value to 48 hours in to the future as there were no 1171 defined ICANN policies at that time. Implementers should be aware 1172 that ICANN policy may define this value in the future. 1174 Registrars SHOULD implement a cache of TCNs to minimize the number of 1175 queries sent to the TMDB. A cached TCN MUST be removed from the 1176 cache after the expiration date of the TCN as defined by 1177 . 1179 The TMDB MAY implement rate-limiting as one of the protection 1180 mechanisms to mitigate the risk of performance degradation. 1182 5.3.5. TMBD Trademark Claims Services for Registrars 1184 5.3.5.1. Claims Notice Information Service (CNIS) 1186 The TCNs are provided by the TMDB online and are fetched by the 1187 Registrar via the dr interface (Section 4.3.6). 1189 To get access to the TCNs, the Registrar needs the credentials 1190 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1191 from the Registry via the ry interface (Section 4.3.5). The dr 1192 interface (Section 4.3.6) uses HTTPS with Basic access 1193 authentication. 1195 The dr interface (Section 4.3.6) MAY support up to ten (10) 1196 concurrent connections from each Registrar. 1198 The URL of the dr interface (Section 4.3.6) is: 1200 < https:///cnis/.xml > 1202 Note that the "lookupkey" may contain SLASH characters ("/"). The 1203 SLASH character is part of the URL path and MUST NOT be escaped when 1204 requesting the TCN. 1206 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1207 MUST be signed by a well-know public CA. Registrars MUST perform the 1208 Certification Path Validation described in Section 6 of [RFC5280]. 1209 Registrars will be authenticated in the dr interface using HTTP Basic 1210 access authentication. The dr (Section 4.3.6) interface MUST support 1211 HTTPS keep-alive and MUST maintain the connection for up to 30 1212 minutes. 1214 5.4. Qualified Launch Program (QLP) Period 1216 5.4.1. Domain Registration 1218 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1219 (QLP) Period effective allocations of DNs to third parties could 1220 require that Registries and Registrars provide Sunrise and/or 1221 Trademark Claims services. If required, Registries and Registrars 1222 MUST provide Sunrise and/or Trademark Claims services as described in 1223 Section 5.2 and Section 5.3. 1225 The effective allocation scenarios are: 1227 o If the leftmost DNL of the DN being effectively allocated (QLP 1228 Name in this section) matches a DNL in the SURL, and an SMD is 1229 provided, then Registries MUST provide Sunrise Services (see 1230 Section 5.2) and the DN MUST be reported in a Sunrise LORDN file 1231 during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- 1232 mgbh0fb" is being effectively allocated, the leftmost DNL would be 1233 "xn--mgbachtv". 1235 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1236 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1237 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1238 file using the special SMD-id "99999-99999" during the QLP Period. 1240 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1241 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1242 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1243 services (see Section 5.3) and the DN MUST be reported in a 1244 Trademark Claims LORDN file during the QLP Period. 1246 o If the QLP Name matches a DNL in the DNL List but does not match a 1247 DNL in the SURL, then Registries MUST provide Trademark Claims 1248 services (see Section 5.2) and the DN MUST be reported in a 1249 Trademark Claims LORDN file during the QLP Period. 1251 The following table lists all the effective allocation scenarios 1252 during a QLP Period: 1254 +--------+---------+-----------------+--------------+---------------+ 1255 | QLP | QLP | SMD was | Registry | Registry MUST | 1256 | Name | Name | provided by the | MUST provide | report DN | 1257 | match | match | potential | Sunrise or | registration | 1258 | in the | in the | Registrant | Trademark | in | 1259 | SURL | DNL | | Claims | LORDN file | 1260 | | List | | Services | | 1261 +--------+---------+-----------------+--------------+---------------+ 1262 | Y | Y | Y | Sunrise | Sunrise | 1263 | | | | | | 1264 | Y | N | Y | Sunrise | Sunrise | 1265 | | | | | | 1266 | N | Y | -- | Trademark | Trademark | 1267 | | | | Claims | Claims | 1268 | | | | | | 1269 | N | N | -- | -- | -- | 1270 | | | | | | 1271 | Y | Y | N (see section | Trademark | Trademark | 1272 | | | 2.2 of | Claims | Claims | 1273 | | | [QLP-Addendum]) | | | 1274 | | | | | | 1275 | Y | N | N (see section | -- | Sunrise | 1276 | | | 2.2 of | | (using | 1277 | | | [QLP-Addendum]) | | special SMD- | 1278 | | | | | id) | 1279 +--------+---------+-----------------+--------------+---------------+ 1281 QLP Effective Allocation Scenarios 1283 The TMDB MUST provide the following services to Registries during a 1284 QLP Period: 1286 o SMD Revocation List (see Section 5.2.3.1) 1288 o NORN (see Section 5.2.3.3) 1290 o DNL List (see Section 5.3.3.1) 1292 o Sunrise List (SURL) (see Section 5.4.2.1 1294 The TMDB MUST provide the following services to Registrars during a 1295 QLP Period: 1297 o SMD Revocation List (see Section 5.2.3.1) 1298 o CNIS (see Section 5.3.5.1) 1300 5.4.2. TMBD QLP Services for Registries 1302 5.4.2.1. Sunrise List (SURL) 1304 A new Sunrise List (SURL) MUST be published by the TMDB twice a day, 1305 by 00:00:00 and 12:00:00 UTC. 1307 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1308 version of the SURL at least once every 24 hours. 1310 Update of the SURL 1312 .----------. .------. 1313 | Registry | | TMDB | 1314 '----------' '------' 1315 | | 1316 .----------------. | 1317 | Periodically, | | 1318 | at least | | 1319 | every 24 hours | | 1320 '----------------' | 1321 | | 1322 |------------------------------->| 1323 | Download the latest SURL | 1324 |<-------------------------------| 1325 | | 1326 | | 1328 Figure 9 1330 Note: the SURL will be the same regardless of the TLD. If a Backend 1331 Registry Operator manages the infrastructure of several TLDs, the 1332 Backend Registry Operator could refresh the SURL once every 24 hours, 1333 the SURL could be used for all the TLDs managed by the Backend 1334 Registry Operator. 1336 6. Data Format Descriptions 1338 6.1. Domain Name Label (DNL) List 1340 This section defines the format of the list containing every Domain 1341 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1342 is maintained by the TMDB and downloaded by Registries in regular 1343 intervals (see Section 5.3.3.1). The Registries use the DNL List 1344 during the Trademark Claims Period to check whether a requested DN 1345 matches a DNL of a PRM. 1347 The DNL List contains all the DNLs covered by a PRM present in the 1348 TMDB at the datetime it is generated. 1350 The DNL List is contained in a CSV formatted file that has the 1351 following structure: 1353 o first line: , 1355 Where: 1357 + , version of the file, this field MUST be 1. 1359 + , date and time in UTC that the 1360 DNL List was created. 1362 o second line: a header line as specified in [RFC4180] 1364 With the header names as follows: 1366 DNL,lookup-key,insertion-datetime 1368 o One or more lines with: ,, 1371 Where: 1373 + , a Domain Name Label covered by a PRM. 1375 + , lookup key that the Registry MUST provide to 1376 the Registrar. The lookup key has the following format: 1377
////, where: 1380 - YYYY: year that the TCN was generated. 1382 - MM: zero-padded month that the TCN was generated. 1384 - DD: zero-padded day that the TCN was generated. 1386 - vv: version of the TCN, possible values are 00 and 01. 1388 - X: one hex character. This is the first, second and 1389 third hex character of encoding the in 1390 base16 as specified in [RFC4648]. 1392 - Random bits: 144 random bits encoded in base64url as 1393 specified in [RFC4648]. 1395 - Sequential number: zero-padded natural number in the 1396 range 0000000001 to 2147483647. 1398 + , datetime in UTC that the DNL was 1399 first inserted into the DNL List. The possible two values 1400 of time for inserting a DNL to the DNL List are 00:00:00 and 1401 12:00:00 UTC. 1403 Example of a DNL List 1405 1,2012-08-16T00:00:00.0Z 1406 DNL,lookup-key,insertion-datetime 1407 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1408 2010-07-14T00:00:00.0Z 1409 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1410 2012-08-16T00:00:00.0Z 1411 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1412 2011-08-16T12:00:00.0Z 1414 Figure 10 1416 To provide authentication and integrity protection, the DNL List will 1417 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1418 PGP signature of the DNL List can be found in the similar URI but 1419 with extension .sig as shown below. 1421 The URL of the dy interface (Section 4.3.3) is: 1423 o < https:///dnl/dnl-latest.csv > 1425 o < https:///dnl/dnl-latest.sig > 1427 6.2. SMD Revocation List 1429 This section defines the format of the list of SMDs that have been 1430 revoked. The list is maintained by the TMDB and downloaded by 1431 Registries (and optionally by Registrars) in regular intervals (see 1432 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1433 Period to validate SMDs received. The SMD Revocation List has a 1434 similar function as CRLs used in PKI [RFC5280]. 1436 The SMD Revocation List contains all the revoked SMDs present in the 1437 TMDB at the datetime it is generated. 1439 The SMD Revocation List is contained in a CSV formatted file that has 1440 the following structure: 1442 o first line: , 1444 Where: 1446 + , version of the file, this field MUST be 1. 1448 + , datetime in UTC 1449 that the SMD Revocation List was created. 1451 o second line: a header line as specified in [RFC4180] 1453 With the header names as follows: 1455 smd-id,insertion-datetime 1457 o One or more lines with: , 1459 Where: 1461 + , identifier of the SMD that was revoked. 1463 + , revocation datetime in UTC of the 1464 SMD. The possible two values of time for inserting an SMD 1465 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1467 To provide integrity protection, the SMD Revocation List is PGP 1468 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1469 List is provided by the TMDB with extension .csv. The PGP signature 1470 of the SMD Revocation List can be found in the similar URI but with 1471 extension .sig as shown below. 1473 The URL of the sr interface (Section 4.3.12) and sy interface 1474 (Section 4.3.11) is: 1476 o < https:///smdrl/smdrl-latest.csv > 1478 o < https:///smdrl/smdrl-latest.sig > 1479 Example of an SMD Revocation List 1481 1,2012-08-16T00:00:00.0Z 1482 smd-id,insertion-datetime 1483 2-2,2012-08-15T00:00:00.0Z 1484 3-2,2012-08-15T00:00:00.0Z 1485 1-2,2012-08-15T00:00:00.0Z 1487 Figure 11 1489 6.3. List of Registered Domain Names (LORDN) file 1491 This section defines the format of the List of Registered Domain 1492 Names (LORDN), which is maintained by each Registry and uploaded at 1493 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1494 said DN is added to the LORDN along with further information related 1495 to its registration. 1497 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1498 file is: 1500 o Sunrise LORDN file: 1502 < https:///LORDN//sunrise > 1504 o Trademark Claims LORDN file: 1506 < https:///LORDN//claims > 1508 During a QLP Period, Registries MAY be required to upload Sunrise or 1509 Trademark Claims LORDN files. The URIs of the yd interface used to 1510 upload LORDN files during a QLP Period is: 1512 o Sunrise LORDN file (during QLP Period): 1514 < https:///LORDN//sunrise/qlp > 1516 o Trademark Claims LORDN file (during a QLP Period): 1518 < https:///LORDN//claims/qlp > 1520 The yd interface (Section 4.3.7) returns the following HTTP status 1521 codes after a HTTP POST request method is received: 1523 o The interface provides a HTTP/202 status code if the interface was 1524 able to receive the LORDN file and the syntax of the LORDN file is 1525 correct. 1527 The interface provides the LORDN Transaction Identifier in the 1528 HTTP Entity-body that would be used by the Registry to download 1529 the LORDN Log file. The LORDN Transaction Identifier is a 1530 natural number zero-padded in the range 0000000000000000001 to 1531 9223372036854775807. 1533 The TMDB uses the element of the 1534 LORDN file as a unique client-side identifier. If a LORDN file 1535 with the same of a previously sent 1536 LORDN file is received by the TMDB, the LORDN Transaction 1537 Identifier of the previously sent LORDN file MUST be provided 1538 to the Registry. The TMDB MUST ignore the DN Lines present in 1539 the LORDN file if a LORDN file with the same was previously sent. 1542 The HTTP Location header field contains the URI where the LORDN 1543 Log file could be retrieved later, for example: 1545 202 Accepted 1547 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1550 o The interface provides a HTTP/400 if the request is incorrect or 1551 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1552 human readable message in the HTTP Entity-body regarding the 1553 incorrect syntax of the LORDN file. 1555 o The interface provides a HTTP/401 status code if the credentials 1556 provided does not authorize the Registry Operator to upload a 1557 LORDN file. 1559 o The TMDB MUST return a HTTP/404 status code when trying to upload 1560 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1563 plus 26 hours. 1565 o The interface provides a HTTP/500 status code if the system is 1566 experiencing a general failure. 1568 For example, to upload the Sunrise LORDN file for TLD "example", the 1569 URI would be: 1571 < https:///LORDN/example/sunrise > 1573 The LORDN is contained in a CSV formatted file that has the following 1574 structure: 1576 o For Sunrise Period: 1578 * first line: ,, 1581 Where: 1583 - , version of the file, this field MUST be 1. 1585 - , date and time in UTC that the 1586 LORDN was created. 1588 - , number of DN Lines present in the 1589 LORDN file. 1591 * second line: a header line as specified in [RFC4180] 1593 With the header names as follows: 1595 roid,domain-name,SMD-id,registrar-id,registration- 1596 datetime,application-datetime 1598 * One or more lines with: ,,,,, 1602 Where: 1604 - , DN Repository Object IDentifier (DNROID) in the 1605 SRS. 1607 - , DN that was effectively allocated. For 1608 IDNs, the A-label form is used. 1610 - , SMD ID used for registration. 1612 - , IANA Registrar ID. 1614 - , date and time in UTC that the 1615 domain was effectively allocated. 1617 - OPTIONAL , date and 1618 time in UTC that the application was created. The 1619 MUST be provided in 1620 case of a DN effective allocation based on an 1621 asynchronous registration (e.g., when using auctions). 1623 Example of a Sunrise LORDN file 1625 1,2012-08-16T00:00:00.0Z,3 1626 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1627 application-datetime 1628 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1629 2012-07-15T00:50:00.0Z 1630 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1631 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1633 Figure 12 1635 o For Trademark Claims Period: 1637 * first line: ,, 1640 Where: 1642 - , version of the file, this field MUST be 1. 1644 - , date and time in UTC that the 1645 LORDN was created. 1647 - , number of DN Lines present in the 1648 LORDN file. 1650 * second line: a header line as specified in [RFC4180] 1652 With the header names as follows: 1654 roid,domain-name,notice-id,registrar-id,registration- 1655 datetime,ack-datetime,application-datetime 1657 * One or more lines with: ,,,,,, 1661 Where: 1663 - , DN Repository Object IDentifier (DNROID) in the 1664 SRS. 1666 - , DN that was effectively allocated. For 1667 IDNs, the A-label form is used. 1669 - , Trademark Claims Notice Identifier as specified 1670 in . 1672 - , IANA Registrar ID. 1674 - , date and time in UTC that the 1675 domain was effectively allocated. 1677 - , date and time in UTC 1678 that the TCN was acknowledged. 1680 - OPTIONAL , date and 1681 time in UTC that the application was created. The 1682 MUST be provided in 1683 case of a DN effective allocation based on an 1684 asynchronous registration (e.g., when using auctions). 1686 For a DN matching a DNL of a PRM at the moment of 1687 registration, created without the TCNID, expiration datetime 1688 and acceptance datetime, because DNL was inserted (or re- 1689 inserted) for the first time into DNL List less than 24 1690 hours ago, the string "recent-dnl-insertion" MAY be 1691 specified in and . 1694 Example of a Trademark Claims LORDN file 1696 1,2012-08-16T00:00:00.0Z,3 1697 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1698 ack-datetime,application-datetime 1699 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1700 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1701 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1702 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1703 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1704 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1706 Figure 13 1708 6.3.1. LORDN Log file 1710 After reception of the LORDN file, the TMDB verifies its content for 1711 syntactical and semantical correctness. The output of the LORDN file 1712 verification is retrieved using the yd interface (Section 4.3.7). 1714 The URI of the yd interface (Section 4.3.7) used to retrieve the 1715 LORDN Log file is: 1717 o Sunrise LORDN Log file: 1719 < https:///LORDN//sunrise//result > 1722 o Trademark Claims LORDN Log file: 1724 < https:///LORDN//claims//result > 1727 A Registry Operator MUST NOT send more than one request per minute 1728 per TLD to download a LORDN Log file. 1730 The yd interface (Section 4.3.7) returns the following HTTP status 1731 codes after a HTTP GET request method is received: 1733 o The interface provides a HTTP/200 status code if the interface was 1734 able to provide the LORDN Log file. The LORDN Log file is 1735 contained in the HTTP Entity-body. 1737 o The interface provides a HTTP/204 status code if the LORDN 1738 Transaction Identifier is correct, but the server has not 1739 finalized processing the LORDN file. 1741 o The interface provides a HTTP/400 status code if the request is 1742 incorrect. 1744 o The interface provides a HTTP/401 status code if the credentials 1745 provided does not authorize the Registry Operator to download the 1746 LORDN Log file. 1748 o The interface provides a HTTP/404 status code if the LORDN 1749 Transaction Identifier is incorrect. 1751 o The interface provides a HTTP/500 status code if the system is 1752 experiencing a general failure. 1754 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1755 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1756 "example" the URI would be: 1758 < https:///LORDN/example/sunrise/0000000000000000001/result > 1761 The LORDN Log file is contained in a CSV formatted file that has the 1762 following structure: 1764 o first line: ,,,,,, 1768 Where: 1770 + , version of the file, this field MUST be 1. 1772 + , date and time in UTC that the 1773 LORDN Log was created. 1775 + , date and time in UTC of 1776 creation for the LORDN file that this log file is referring 1777 to. 1779 + , unique identifier of the LORDN Log 1780 provided by the TMDB. This identifier could be used by the 1781 Registry Operator to unequivocally identify the LORDN Log. 1782 The identified will be a string of a maximum LENGTH of 60 1783 characters from the Base 64 alphabet. 1785 + , whether the LORDN file has been accepted for 1786 processing by the TMDB. Possible values are "accepted" or 1787 "rejected". 1789 + , whether the LORDN Log has any warning result 1790 codes. Possible values are "no-warnings" or "warnings- 1791 present". 1793 + , number of DNs effective allocations 1794 processed in the LORDN file. 1796 A Registry Operator is not required to process a LORDN Log with 1797 a ="accepted" and ="no-warnings". 1799 o second line: a header line as specified in [RFC4180] 1801 With the header names as follows: 1803 roid,result-code 1805 o One or more lines with: , 1807 Where: 1809 + , DN Repository Object IDentifier (DNROID) in the SRS. 1811 + , result code as described in Section 6.3.1.1. 1813 Example of a LORDN Log file 1815 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1816 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1817 accepted,no-warnings,1 1818 roid,result-code 1819 SH8013-REP,2000 1821 Figure 14 1823 6.3.1.1. LORDN Log Result Codes 1825 In Figure 15 the classes of result codes (rc) are listed. Those 1826 classes in square brackets are not used at this time, but may come 1827 into use at some later stage. The first two digits of a result code 1828 denote the result code class, which defines the outcome at the TMDB: 1830 o ok: Success, DN Line accepted by the TMDB. 1832 o warn: a warning is issued, DN Line accepted by the TMDB. 1834 o err: an error is issued, LORDN file rejected by the TMDB. 1836 In case that after processing a DN Line, the error result code is 1837 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1838 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1839 valid will be reported with a 2001 result code. A 2001 result code 1840 means that the DN Line is syntactically valid, however the DN Line 1841 was not processed because the LORDN file was rejected. All DNs 1842 reported in a rejected LORDN file MUST be reported again by the 1843 Registry because none of the DN Lines present in the LORDN file have 1844 been processed by the TMDB. 1846 LORDN Log Result Code Classes 1848 code Class outcome 1849 ---- ----- ------- 1851 20xx Success ok 1853 35xx [ DN Line syntax warning ] warn 1854 36xx DN Line semantic warning warn 1856 45xx DN Line syntax error err 1857 46xx DN Line semantic error err 1859 Figure 15 1861 In the following, the LORDN Log result codes used by the TMDB are 1862 described: 1864 LORDN Log result Codes 1866 rc Short Description 1867 Long Description 1868 ---- ------------------------------------------------------------- 1870 2000 OK 1871 DN Line successfully processed. 1873 2001 OK but not processed 1874 DN Line is syntactically correct but was not processed 1875 because the LORDN file was rejected. 1877 3601 TCN Acceptance Date after Registration Date 1878 TCN Acceptance Date in DN Line is newer than the Registration 1879 Date. 1881 3602 Duplicate DN Line 1882 This DN Line is an exact duplicate of another DN Line in same 1883 file, DN Line ignored. 1885 3603 DNROID Notified Earlier 1886 Same DNROID has been notified earlier, DN Line ignored. 1888 3604 TCN Checksum invalid 1889 Based on the DN effectively allocated, the TCNID and the 1890 expiration date of the linked TCN, the TCN Checksum is 1891 invalid. 1893 3605 TCN Expired 1894 The TCN was already expired (based on the 1895 field of the TCN) at the datetime of acknowledgement. 1897 3606 Wrong TCNID used 1898 The TCNID used for the registration does not match 1899 the related DN. 1901 3609 Invalid SMD used 1902 The SMD used for registration was not valid at the moment of 1903 registration based on the and 1904 elements. 1905 In case of an asynchronous registration, this refer to the 1906 . 1908 3610 DN reported outside of the time window 1909 The DN was reported outside of the required 26 hours 1910 reporting window. 1912 3611 DN does not match the labels in SMD 1913 The DN does not match the labels included in the SMD. 1915 3612 SMDID does not exist 1916 The SMDID has never existed in the central repository. 1918 3613 SMD was revoked when used 1919 The SMD used for registration was revoked more than 1920 24 hours ago of the . 1921 In case of an asynchronous registration, 1922 the is used when 1923 validating the DN Line. 1925 3614 TCNID does not exist 1926 The TCNID has never existed in the central repository. 1928 3615 Recent-dnl-insertion outside of the time window 1929 The DN registration is reported as a recent-dnl-insertion, 1930 but the (re) insertion into the DNL occurred more than 1931 24 hours ago. 1933 3616 Registration Date of DN in Claims before the end of Sunrise Period 1934 The registration date of the DN is before the end of 1935 the Sunrise Period and the DN was reported in a 1936 Trademark Claims LORDN file. 1938 3617 Registrar has not been approved by the TMDB 1939 Registrar ID in DN Line has not completed Trademark Claims 1940 integration testing with the TMDB. 1942 3618 Registration Date of DN in QLP LORDN file out of the QLP Period 1943 The registration date of the DN in a QLP LORDN file is outside 1944 of the QLP Period. 1946 3619 TCN was not valid 1947 The TCN was not valid (based on the 1948 field of the TCN) at the datetime of acknowledgement. 1950 4501 Syntax Error in DN Line 1951 Syntax Error in DN Line. 1953 4601 Invalid TLD used 1954 The TLD in the DN Line does not match what is expected for 1955 this LORDN. 1957 4602 Registrar ID Invalid 1958 Registrar ID in DN Line is not a valid ICANN-Accredited 1959 Registrar. 1961 4603 Registration Date in the future 1962 The in the DN Line is in the 1963 future. 1965 4606 TLD not in Sunrise or Trademark Claims Period 1966 The was reported when the TLD was 1967 not in Sunrise or Trademark Claims Periods. 1968 In case of an asynchronous registration, 1969 the is used when 1970 validating the DN Line. 1972 4607 Application Date in the future 1973 The in the DN Line is in the 1974 future. 1976 4608 Application Date is later than Registration Date 1977 The in the DN Line is later 1978 than the . 1980 4609 TCNID wrong syntax 1981 The syntax of the TCNID is invalid. 1983 4610 TCN Acceptance Date is in the future 1984 The is in the future. 1986 4611 Label has never existed in the TMDB 1987 The label in the registered DN has never existed in the TMDB. 1989 Figure 16 1991 6.4. Signed Mark Data (SMD) File 1993 This section defines the format of the Signed Mark Data (SMD) File. 1994 After a successful registration of a mark, the TMV returns an SMD 1995 File to the TMH. The SMD File can then be used for registration of 1996 one or more DNs covered by the PRM during the Sunrise Period of a 1997 TLD. 1999 Two encapsulation boundaries are defined for delimiting the 2000 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 2001 and "-----END ENCODED SMD-----". Only data inside the encapsulation 2002 boundaries MUST be used by Registries and Registrars for validation 2003 purposes, i.e. any data outside these boundaries as well as the 2004 boundaries themselves MUST be ignored for validation purposes. 2006 The structure of the SMD File is as follows, all the elements are 2007 REQUIRED, and MUST appear in the specified order. 2009 1. Marks: 2011 2. smdID: 2013 3. U-labels: 2016 4. notBefore: 2018 5. notAfter: 2020 6. -----BEGIN ENCODED SMD----- 2022 7. 2024 8. -----END ENCODED SMD----- 2025 Example of an SMD File: 2027 Marks: Example One 2028 smdID: 1-2 2029 U-labels: example-one, exampleone 2030 notBefore: 2011-08-16 09:00 2031 notAfter: 2012-08-16 09:00 2032 -----BEGIN ENCODED SMD----- 2033 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2034 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2035 ... (base64 data elided for brevity) ... 2036 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2037 -----END ENCODED SMD----- 2039 Figure 17 2041 6.5. Trademark Claims Notice (TCN) 2043 The TMDB MUST provide the TCN to Registrars in XML format as 2044 specified below. 2046 An enclosing element that describes the Trademark 2047 Notice to a given label. 2049 The child elements of the element include: 2051 o A element that contains the unique identifier of the 2052 Trademark Notice. This element contains the the TCNID. 2054 The TCNID is a string concatenation of a TCN Checksum and the 2055 TMDB Notice Identifier. The first 8 characters of the TCNID is 2056 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2057 is a zero-padded natural number in the range of 2058 0000000000000000001 to 9223372036854775807. 2060 Example of a TCNID: 2062 370d0b7c9223372036854775807. 2064 Where: 2066 + TCN Checksum=370d0b7c 2068 + TMDB Notice Identifier=9223372036854775807 2069 The TCN Checksum is a 8 characters long Base16 encoded output 2070 of computing the CRC32 of the string concatenation of: label + 2071 unix_timestamp() + TMDB Notice Identifier 2073 TMDB MUST use the Unix time conversion of the 2074 in UTC to calculate the TCN Checksum. Unix 2075 time is defined as the number of seconds that have elapsed 2076 since 1970-01-01T00:00:00Z not counting leap seconds. For 2077 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2078 is shown: 2080 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2082 The TMDB uses the and 2083 elements from the TCN along with the TMDB Notice Identifier to 2084 compute the TCN Checksum. 2086 A Registry MUST use the leftmost DNL of the DN being 2087 effectively allocated, the expiration datetime of the TCN 2088 (provided by the Registrar) and the TMDB Notice Identifier 2089 extracted from the TCNID (provided by the Registrar) to compute 2090 the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- 2091 mgbh0fb" is being effectively allocated, the leftmost DNL would 2092 be "xn--mgbachtv". 2094 Example of computation of the TCN Checksum: 2096 CRC32(example-one12819492009223372036854775807)=370d0b7c 2098 o A element that contains the start of the 2099 validity date and time of the TCN. 2101 o A element that contains the expiration date 2102 and time of the TCN. 2104 o A element that contains the DNL covered by a PRM. 2106 o One or more elements that contain the Trademark 2107 Claim. The element contains the following child 2108 elements: 2110 * A element that contains the mark text 2111 string. 2113 * One or more elements that contains the 2114 information of the holder of the mark. An "entitlement" 2115 attribute is used to identify the entitlement of the holder, 2116 possible values are: owner, assignee or licensee. The child 2117 elements of include: 2119 + An OPTIONAL element that contains the name 2120 of the holder. A MUST be specified if 2121 is not specified. 2123 + An OPTIONAL element that contains the name of 2124 the organization holder of the mark. A MUST 2125 be specified if is not specified. 2127 + A element that contains the address 2128 information of the holder of a mark. A 2129 contains the following child elements: 2131 - One, two or three OPTIONAL elements 2132 that contains the organization's street address. 2134 - A element that contains the 2135 organization's city. 2137 - An OPTIONAL element that contains the 2138 organization's state or province. 2140 - An OPTIONAL element that contains the 2141 organization's postal code. 2143 - A element that contains the organization's 2144 country code. This a two-character code from 2145 [ISO3166-2]. 2147 + An OPTIONAL element that contains the 2148 organization's voice telephone number. 2150 + An OPTIONAL element that contains the 2151 organization's facsimile telephone number. 2153 + An OPTIONAL element that contains the email 2154 address of the holder. 2156 * Zero or more OPTIONAL elements that contains 2157 the information of the representative of the mark registration. 2158 A "type" attribute is used to identify the type of contact, 2159 possible values are: owner, agent or thirdparty. The child 2160 elements of include: 2162 + A element that contains name of the 2163 responsible person. 2165 + An OPTIONAL element that contains the name of 2166 the organization of the contact. 2168 + A element that contains the address 2169 information of the contact. A contains the 2170 following child elements: 2172 - One, two or three OPTIONAL elements 2173 that contains the contact's street address. 2175 - A element that contains the contact's 2176 city. 2178 - An OPTIONAL element that contains the 2179 contact's state or province. 2181 - An OPTIONAL element that contains the 2182 contact's postal code. 2184 - A element that contains the contact's 2185 country code. This a two-character code from 2186 [ISO3166-2]. 2188 + A element that contains the contact's voice 2189 telephone number. 2191 + An OPTIONAL element that contains the 2192 contact's facsimile telephone number. 2194 + A element that contains the contact's email 2195 address. 2197 * A element that contains the name (in 2198 English) of the jurisdiction where the mark is protected. A 2199 jurCC attribute contains the two-character code of the 2200 jurisdiction where the mark was registered. This is a two- 2201 character code from [WIPO.ST3]. 2203 * Zero or more OPTIONAL element that 2204 contains the description (in English) of the Nice 2205 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2206 attribute contains the class number. 2208 * A element that contains the full 2209 description of the goods and services mentioned in the mark 2210 registration document. 2212 * An OPTIONAL element signals that the 2213 claim notice was added to the TCN based on other rule (e.g. 2214 [Claims50] ) than exact match (defined in [MatchingRules]). 2215 The contains one or more: 2217 + An OPTIONAL element that signals that the 2218 claim notice was added because of a previously abused name 2219 included in an UDRP case. The contains: 2221 - A element that contains the UDRP case 2222 number used to validate the previously abused name. 2224 - A element that contains the name 2225 of the UDRP provider. 2227 + An OPTIONAL element that signals that the 2228 claim notice was added because of a previously abused name 2229 included in a court's resolution. The 2230 contains: 2232 - A element that contains the reference 2233 number of the court's resolution used to validate the 2234 previously abused name. 2236 - A element that contains the two-character 2237 code from [ISO3166-2] of the jurisdiction of the court. 2239 - A element that contains the name of 2240 the court. 2242 Example of a object: 2244 2245 2246 370d0b7c9223372036854775807 2247 2010-08-14T09:00:00.0Z 2248 2010-08-16T09:00:00.0Z 2249 example-one 2250 2251 Example One 2252 2253 Example Inc. 2254 2255 123 Example Dr. 2256 Suite 100 2257 Reston 2258 VA 2259 20190 2260 US 2261 2262 2263 2264 Joe Doe 2265 Example Inc. 2266 2267 123 Example Dr. 2268 Suite 100 2269 Reston 2270 VA 2271 20190 2272 US 2273 2274 +1.7035555555 2275 jdoe@example.com 2276 2277 USA 2278 2279 Advertising; business management; business administration. 2280 2281 2282 Insurance; financial affairs; monetary affairs; real estate. 2283 2284 2285 Bardus populorum circumdabit se cum captiosus populum. 2286 Smert populorum circumdabit se cum captiosus populum. 2287 2288 2289 2290 Example-One 2291 2292 Example S.A. de C.V. 2293 2294 Calle conocida #343 2295 Conocida 2296 SP 2297 82140 2298 BR 2299 2300 2301 BRAZIL 2302 2303 Bardus populorum circumdabit se cum captiosus populum. 2304 Smert populorum circumdabit se cum captiosus populum. 2305 2306 2307 2308 One 2309 2310 One Corporation 2311 2312 Otra calle 2313 Otra ciudad 2314 OT 2315 383742 2316 CR 2317 2318 2319 COSTA RICA 2320 2321 Bardus populorum circumdabit se cum captiosus populum. 2322 Smert populorum circumdabit se cum captiosus populum. 2323 2324 2325 2326 234235 2327 CR 2328 Supreme Court of Spain 2329 2330 2331 2332 2333 One Inc 2334 2335 One SA de CV 2336 2337 La calle 2338 La ciudad 2339 CD 2340 34323 2341 AR 2342 2343 2344 ARGENTINA 2345 2346 Bardus populorum circumdabit se cum captiosus populum. 2347 Smert populorum circumdabit se cum captiosus populum. 2348 2349 2350 2351 D2003-0499 2352 WIPO 2353 2354 2356 2357 2359 For the formal syntax of the TCN please refer to Section 7.1. 2361 6.6. Sunrise List (SURL) 2363 This section defines the format of the list containing every Domain 2364 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2365 is maintained by the TMDB and downloaded by Registries in regular 2366 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2367 during the Qualified Launch Program Period to check whether a 2368 requested DN matches a DNL of a PRM eligible for Sunrise. 2370 The Sunrise List contains all the DNLs covered by a PRM eligible for 2371 Sunrise present in the TMDB at the datetime it is generated. 2373 The Sunrise List is contained in a CSV formatted file that has the 2374 following structure: 2376 o first line: , 2378 Where: 2380 + , version of the file, this field MUST be 1. 2382 + , date and time in UTC that 2383 the Sunrise List was created. 2385 o second line: a header line as specified in [RFC4180] 2387 With the header names as follows: 2389 DNL,insertion-datetime 2391 o One or more lines with: , 2393 Where: 2395 + , a Domain Name Label covered by a PRM eligible for 2396 Sunrise. 2398 + , datetime in UTC that the DNL was 2399 first inserted into the Sunrise List. The possible two 2400 values of time for inserting a DNL to the Sunrise List are 2401 00:00:00 and 12:00:00 UTC. 2403 Example of a SURL 2405 1,2012-08-16T00:00:00.0Z 2406 DNL,insertion-datetime 2407 example,2010-07-14T00:00:00.0Z 2408 another-example,2012-08-16T00:00:00.0Z 2409 anotherexample,2011-08-16T12:00:00.0Z 2411 Figure 18 2413 To provide authentication and integrity protection, the Sunrise List 2414 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2415 signature of the Sunrise List can be found in the similar URI but 2416 with extension .sig as shown below. 2418 The URL of the dy interface (Section 4.3.3) is: 2420 o < https:///dnl/surl-latest.csv > 2422 o < https:///dnl/surl-latest.sig > 2424 7. Formal Syntax 2426 7.1. Trademark Claims Notice (TCN) 2428 The schema presented here is for a Trademark Claims Notice. 2430 The BEGIN and END tags are not part of the schema; they are used to 2431 note the beginning and ending of the schema for URI registration 2432 purposes. 2434 2435 2436 2442 2443 2444 Schema for representing a Trademark Claim Notice. 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2468 2469 2470 2471 2472 2473 2475 2477 2478 2480 2481 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 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 2546 2547 2548 2550 8. Acknowledgements 2552 This specification is a collaborative effort from several 2553 participants in the ICANN community. Bernie Hoeneisen participated 2554 as co-author until version 02 providing invaluable support for this 2555 document. This specification is based on a model spearheaded by: 2556 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2557 would also like to thank the thoughtful feedbak provided by many in 2558 the tmch-tech mailing list, but particularly the extensive help 2559 provided by James Gould, James Mitchell and Francisco Arias. This 2560 document includes feedback received from the following individuals: 2561 Paul Hoffman. 2563 9. Change History 2565 [[RFC Editor: Please remove this section.]] 2567 9.1. Version 04 2569 1. Ping update. 2571 9.2. Version 05 2573 1. Ping update. 2575 9.3. Version 06 2577 1. Updated the terminology text to reflect the text in RFC8174. 2579 2. Updated the reference of RFC7719 to RFC8499. 2581 3. Updated the matching rules document reference to link to the 2582 latest version. 2584 9.4. Version 07 2586 1. Changes based on the feedback provided here: 2587 https://mailarchive.ietf.org/arch/msg/regext/ 2588 xcZPOAajlUJzgPgZBuqlIWRcFZg/ 2590 2. Changes based on the feedback provided here: 2591 https://mailarchive.ietf.org/arch/msg/regext/ 2592 MdOhSomd6_djLcthfw5mxWZkbWY 2594 9.5. Version 08 2596 1. Fixed issues detected by idnits tool. 2598 9.6. Version 09 2600 1. Ping update. 2602 10. IANA Considerations 2604 This document uses URNs to describe XML namespaces and XML schemas 2605 conforming to a registry mechanism described in [RFC3688]. Two URI 2606 assignments have been registered by the IANA. 2608 Registration request for the Trademark Claims Notice namespace: 2610 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2612 Registrant Contact: IETF 2614 XML: None. Namespace URIs do not represent an XML specification. 2616 Registration request for the Trademark Claims Notice XML schema: 2618 URI: urn:ietf:params:xml:schema:tmNotice-1.0 2620 Registrant Contact: IETF 2622 XML: See Section 7.1 of this document. 2624 11. Security Considerations 2626 This specification uses HTTP Basic Authentication to provide a simple 2627 application-layer authentication service. HTTPS is used in all 2628 interfaces in order to protect against most common attacks. In 2629 addition, the client identifier is tied to a set of IP addresses that 2630 are allowed to connect to the interfaces described in this document, 2631 providing an extra security measure. 2633 The TMDB MUST provide credentials to the appropriate Registries and 2634 Registrars. 2636 The TMDB MUST require the use of strong passwords by Registries and 2637 Registrars. 2639 The TMDB, Registries and Registrars MUST use the best practices 2640 described in RFC 7525 or its successors. 2642 12. References 2644 12.1. Normative References 2646 [Claims50] 2647 ICANN, "Implementation Notes: Trademark Claims Protection 2648 for Previously Abused Names", July 2013, 2649 . 2652 [MatchingRules] 2653 ICANN, "Memorandum on Implementing Matching Rules", July 2654 2016, . 2657 [QLP-Addendum] 2658 ICANN, "Qualified Launch Program Addendum", April 2014, 2659 . 2663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2664 Requirement Levels", BCP 14, RFC 2119, 2665 DOI 10.17487/RFC2119, March 1997, 2666 . 2668 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2669 DOI 10.17487/RFC3688, January 2004, 2670 . 2672 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2673 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2674 . 2676 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2677 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2678 May 2017, . 2680 [RPM-Requirements] 2681 ICANN, "Rights Protection Mechanism Requirements", 2682 September 2013, . 2685 [W3C.REC-xml-20081126] 2686 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 2687 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 2688 Edition) REC-xml-20081126", November 2008, 2689 . 2691 [W3C.REC-xmlschema-1-20041028] 2692 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 2693 "XML Schema Part 1: Structures Second Edition REC- 2694 xmlschema-1-20041028", October 2004, 2695 . 2697 [W3C.REC-xmlschema-2-20041028] 2698 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2699 Second Edition REC-xmlschema-2-20041028", October 2004, 2700 . 2702 12.2. Informative References 2704 [ICANN-GTLD-AGB-20120604] 2705 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2706 2012, . 2709 [ISO3166-2] 2710 ISO, "International Standard for country codes and codes 2711 for their subdivisions", 2006, 2712 . 2714 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2715 DOI 10.17487/RFC2818, May 2000, 2716 . 2718 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2719 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2720 . 2722 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2723 Separated Values (CSV) Files", RFC 4180, 2724 DOI 10.17487/RFC4180, October 2005, 2725 . 2727 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2728 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2729 . 2731 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2732 Thayer, "OpenPGP Message Format", RFC 4880, 2733 DOI 10.17487/RFC4880, November 2007, 2734 . 2736 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2737 Housley, R., and W. Polk, "Internet X.509 Public Key 2738 Infrastructure Certificate and Certificate Revocation List 2739 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2740 . 2742 [RFC5890] Klensin, J., "Internationalized Domain Names for 2743 Applications (IDNA): Definitions and Document Framework", 2744 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2745 . 2747 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2748 Protocol (HTTP/1.1): Message Syntax and Routing", 2749 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2750 . 2752 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2753 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2754 DOI 10.17487/RFC7231, June 2014, 2755 . 2757 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2758 Protocol (HTTP/1.1): Authentication", RFC 7235, 2759 DOI 10.17487/RFC7235, June 2014, 2760 . 2762 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2763 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2764 January 2019, . 2766 [WIPO-NICE-CLASSES] 2767 WIPO, "WIPO Nice Classification", 2015, 2768 . 2770 [WIPO.ST3] 2771 WIPO, "Recommended standard on two-letter codes for the 2772 representation of states, other entities and 2773 intergovernmental organizations", March 2007, 2774 . 2776 Author's Address 2777 Gustavo Lozano 2778 ICANN 2779 12025 Waterfront Drive, Suite 300 2780 Los Angeles 90292 2781 US 2783 Phone: +1.3103015800 2784 Email: gustavo.lozano@icann.org