idnits 2.17.1 draft-ietf-regext-tmch-func-spec-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (Apr 06, 2020) is 1481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1381, but not defined -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational Apr 06, 2020 5 Expires: October 8, 2020 7 ICANN TMCH functional specifications 8 draft-ietf-regext-tmch-func-spec-07 10 Abstract 12 This document describes the requirements, the architecture and the 13 interfaces between the ICANN Trademark Clearinghouse (TMCH) and 14 Domain Name Registries as well as between the ICANN TMCH and Domain 15 Name Registrars for the provisioning and management of domain names 16 during Sunrise and Trademark Claims Periods. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 8, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 9 57 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 58 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . 13 77 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 78 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 79 5.1.1.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 14 80 5.1.1.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 14 81 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15 82 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 83 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 84 5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15 85 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 15 86 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.1. Domain Name registration . . . . . . . . . . . . . . 16 88 5.2.2. Sunrise Domain Name registration by Registries . . . 17 89 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 18 90 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18 91 5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 18 92 5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 19 93 5.2.4. Sunrise Domain Name registration by Registrars . . . 22 94 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 22 95 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23 96 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23 97 5.3.2. Trademark Claims Domain Name registration by 98 Registries . . . . . . . . . . . . . . . . . . . . . 24 99 5.3.3. TMBD Trademark Claims Services for Registries . . . . 25 100 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 25 101 5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 26 102 5.3.4. Trademark Claims Domain Name registration by 103 Registrars . . . . . . . . . . . . . . . . . . . . . 26 104 5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28 105 5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28 106 5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 28 107 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 28 108 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31 109 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31 110 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 31 111 6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 31 112 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 33 113 6.3. List of Registered Domain Names (LORDN) file . . . . . . 35 114 6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 40 115 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 116 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46 117 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47 118 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54 119 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 120 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 122 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58 123 9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58 124 9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58 125 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58 126 9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58 127 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 128 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 129 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 130 12.1. Normative References . . . . . . . . . . . . . . . . . . 59 131 12.2. Informative References . . . . . . . . . . . . . . . . . 61 132 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 134 1. Introduction 136 Domain Name Registries (DNRs) may operate in special modes for 137 certain periods of time enabling trademark holders to protect their 138 rights during the introduction of a Top Level Domain (TLD). 140 Along with the introduction of new generic TLDs (gTLD), two special 141 modes came into effect: 143 o Sunrise Period, the Sunrise Period allows trademark holders an 144 advance opportunity to register domain names corresponding to 145 their marks before names are generally available to the public. 147 o Trademark Claims Period, the Trademark Claims Period follows the 148 Sunrise Period and runs for at least the first 90 days of an 149 initial operating period of general registration. During the 150 Trademark Claims Period, anyone attempting to register a domain 151 name matching a mark that is recorded in the ICANN Trademark 152 Clearinghouse (TMCH) will receive a notification displaying the 153 relevant mark information. 155 This document describes the requirements, the architecture and the 156 interfaces between the ICANN TMCH and Domain Name Registries (called 157 Registries in the rest of the document) as well as between the ICANN 158 TMCH and Domain Name Registrars (called Registrars in the rest of the 159 document) for the provisioning and management of domain names during 160 the Sunrise and Trademark Claims Periods. 162 For any date and/or time indications, Coordinated Universal Time 163 (UTC) applies. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 XML is case sensitive. Unless stated otherwise, XML specifications 174 and examples provided in this document MUST be interpreted in the 175 character case presented in order to develop a conforming 176 implementation. 178 "tmNotice-1.0" is used as an abbreviation for 179 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 180 "tmNotice" is used, but implementations MUST NOT depend on it and 181 instead employ a proper namespace-aware XML parser and serializer to 182 interpret and output the XML documents. 184 3. Glossary 186 In the following section, the most common terms are briefly 187 explained: 189 o Backend Registry Operator: Entity that manages (a part of) the 190 technical infrastructure for a Registry Operator. The Registry 191 Operator may also be the Backend Registry Operator. 193 o CA: Certificate Authority, see [RFC5280]. 195 o CNIS, Claims Notice Information Service: This service provides 196 Trademark Claims Notices (TCN) to Registrars. 198 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 199 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 201 o CRL: Certificate Revocation List, see [RFC5280]. 203 o CSV: Comma-Separated Values, see [RFC4180] 205 o Date and time, datetime: Date and time are specified following the 206 standard "Date and Time on the Internet specification", see 207 [RFC3339]. 209 o DN, Domain Name, domain name: see definition of Domain name in 210 [RFC8499]. 212 o DNROID, DN Repository Object IDentifier: an identifier assigned by 213 the Registry to each DN object that unequivocally identifies said 214 DN object. For example, if a new DN object is created for a name 215 that existed in the past, the DN objects will have different 216 DNROIDs. 218 o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see 219 [RFC5890]). 221 o DNL List: A list of DNLs that are covered by a PRM. 223 o DNS: Domain Name System, see [RFC8499]. 225 o Effective allocation: A DN is considered effectively allocated 226 when the DN object for the DN has been created in the SRS of the 227 Registry and has been assigned to the effective user. A DN object 228 in status "pendingCreate" or any other status that precedes the 229 first time a DN is assigned to an end-user is not considered an 230 effective allocation. A DN object created internally by the 231 Registry for subsequent delegation to another Registrant is not 232 considered an effective allocation. 234 o EPP: The Extensible Provisioning Protocol, see definition of EPP 235 in [RFC8499]. 237 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 238 [RFC8499]. 240 o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. 242 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 244 o IDN: Internationalized Domain Name, see definition of IDN in 245 [RFC8499]. 247 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 248 Z0-9/] to be used as the lookup key by Registrars to obtain the 249 TCN using the CNIS. Lookup Keys are unique and are related to one 250 DNL only. 252 o LORDN, List of Registered Domain Names: This is the list of 253 effectively allocated DNs matching a DNL of a PRM. Registries 254 will upload this list to the TMDB (during the NORDN process). 256 o Matching Rules: Some trademarks entitled to inclusion in the TMDB 257 include characters that are impermissible in the domain name 258 system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH 259 Matching Rules [MatchingRules]) certain DNS-impermissible 260 characters in a trademark into DNS-permissible equivalent 261 characters 263 o NORDN, Notification of Registered Domain Names: The process by 264 which Registries upload their recent LORDN to the TMDB. 266 o PGP: Pretty Good Privacy, see [RFC4880] 268 o PKI: Public Key Infrastructure, see [RFC5280]. 270 o PRM, Pre-registered mark: Mark that has been pre-registered with 271 the ICANN TMCH. 273 o QLP Period, Qualified Launch Program Period: During this optional 274 period, a special process applies to DNs matching the Sunrise List 275 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 276 DN matching their PRM. 278 o Registrant: see definition of Registrant in [RFC8499]. 280 o Registrar, Domain Name Registrar: see definition of Registrar in 281 [RFC8499]. 283 o Registry, Domain Name Registry, Registry Operator: see definition 284 of Registry in [RFC8499]. A Registry Operator is the contracting 285 party with ICANN for the TLD. 287 o SMD, Signed Mark Data: A cryptographically signed token issued by 288 the TMV to the TMH to be used in the Sunrise Period to apply for a 289 DN that matches a DNL of a PRM; see also [RFC7848]. An SMD 290 generated by an ICANN-approved trademark validator (TMV) contains 291 both the signed token and the TMV's PKIX certificate. 293 o SMD File: A file containing the SMD (see above) and some human 294 readable data. The latter is usually ignored in the processing of 295 the SMD File. See also Section 6.4. 297 o SMD Revocation List: The SMD Revocation List is used by Registries 298 (and optionally by Registrars) during the Sunrise Period to ensure 299 that an SMD is still valid (i.e. not revoked). The SMD Revocation 300 List has a similar function as CRLs used in PKI. 302 o SRS: Shared Registration System, see also 303 [ICANN-GTLD-AGB-20120604]. 305 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 306 eligible for Sunrise. 308 o Sunrise Period: During this period DNs matching a DNL of a PRM can 309 be exclusively obtained by the respective TMHs. For DNs matching 310 a PRM, a special process applies to ensure that TMHs are informed 311 on the effective allocation of a DN matching their PRM. 313 o TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. 315 o ICANN TMCH: a central repository for information to be 316 authenticated, stored, and disseminated, pertaining to the rights 317 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 318 (see below). There could be several entities performing the TMV 319 function, but only one entity performing the TMDB function. 321 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 322 This CA is operated by ICANN. The public key for this CA is the 323 trust anchor used to validate the identity of each TMV. 325 o TMDB, Trademark Clearinghouse Database: Serves as a database of 326 the ICANN TMCH to provide information to the gTLD Registries and 327 Registrars to support Sunrise or Trademark Claims services. There 328 is only one TMDB in the ICANN TMCH that concentrates the 329 information about the "verified" Trademark records from the TMVs. 331 o TMH, Trademark Holder: The person or organization owning rights on 332 a mark. 334 o TMV, Trademark Validator, Trademark validation organization: An 335 entity authorized by ICANN to authenticate and validate 336 registrations in the TMDB ensuring the marks qualify as registered 337 or are court-validated marks or marks that are protected by 338 statute or treaty. This entity would also be asked to ensure that 339 proof of use of marks is provided, which can be demonstrated by 340 furnishing a signed declaration and one specimen of current use. 342 o Trademark, mark: Marks are used to claim exclusive properties of 343 products or services. A mark is typically a name, word, phrase, 344 logo, symbol, design, image, or a combination of these elements. 345 For the scope of this document only textual marks are relevant. 347 o Trademark Claims, Claims: Provides information to enhance the 348 understanding of the Trademark rights being claimed by the TMH. 350 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 351 Trademark Claims Notice consist of one or more Trademark Claims 352 and are provided to prospective Registrants of DNs. 354 o TCNID, Trademark Claims Notice Identifier: An element of the 355 Trademark Claims Notice (see above), identifying said TCN. The 356 Trademark Claims Notice Identifier is specified in the element 357 . 359 o Trademark Claims Period: During this period, a special process 360 applies to DNs matching the DNL List, to ensure that TMHs are 361 informed of a DN matching their PRM. For DNs matching the DNL 362 List, Registrars show a TCN to prospective Registrants that has to 363 be acknowledged before effective allocation of the DN. 365 o UTC: Coordinated Universal Time, as maintained by the Bureau 366 International des Poids et Mesures (BIPM); see also [RFC3339]. 368 4. Architecture 370 4.1. Sunrise Period 372 Architecture of the Sunrise Period 374 SMD hand over (out-of-band) 375 .............................................. 376 : : 377 : .'''''''''''''''''''. : 378 : . ICANN TMCH . : 379 : ..................... : 380 v . . : 381 .------------. . .-------------. . hv .-----. 382 | Registrant | . | TMV |<---------->| TMH | 383 '------------' . '-------------' . vh '-----' 384 | . | ^ \ . 385 | . | | \. 386 tr | . vs | | dv \ 387 | . | vd | .\ 388 v . v v . \ 389 .-----------. sr . .---------. . \ 390 .->| Registrar |<..........| | . \ 391 : '-----------' . | | . \ 392 : | sy . | T | . \ 393 : ry | .------------| M | . vc \ 394 : | | . | D | . \ 395 : v v . | B | . v 396 : .-----------. . yd | | . .---------------. 397 : | Registry |---------->| | . | ICANN TMCH-CA | 398 : '-----------' . '---------' . '---------------' 399 : ^ . . | : 400 : | ''''''''''''''''''' | : 401 : | cy | : 402 : cr '-----------------------------------------' : 403 :......................................................: 405 Figure 1 407 4.2. Trademark Claims Period 409 Architecture of the Trademark Claims Period 411 .''''''''''''''. 412 . ICANN TMCH . 413 ................ 414 . . 415 .------------. . .-------. . hv .-----. 416 | Registrant | . | TMV |<----------->| TMH | 417 '------------' . '-------' . vh '-----' 418 | . ^ . 419 | . | dv . 420 tr | . vd | . 421 v . v . 422 .-----------. dr . .-------. . 423 | Registrar |<--------| | . 424 '-----------' . | T | . 425 ry | . | M | . 426 v . | D | . 427 .----------. dy . | B | . 428 | Registry |<------->| | . 429 '----------' yd . '-------' . 430 . . 431 '''''''''''''' 433 Figure 2 435 4.3. Interfaces 437 In the sub-sections below follows a short description of each 438 interface to provide an overview of the architecture. More detailed 439 descriptions of the relevant interfaces follow further below 440 (Section 5). 442 4.3.1. hv 444 The TMH registers a mark with a TMV via the hv interface. 446 After the successful registration of the mark, the TMV makes 447 available a SMD File (see also Section 6.4) to the TMH to be used 448 during the Sunrise Period. 450 The specifics of the hv interface are beyond the scope of this 451 document. 453 4.3.2. vd 455 After successful mark registration, the TMV ensures the TMDB inserts 456 the corresponding DNLs and mark information into the database via the 457 vd interface. 459 The specifics of the vd interface are beyond the scope of this 460 document. 462 4.3.3. dy 464 During the Trademark Claims Period the Registry fetches the latest 465 DNL List from the TMDB via the dy interface at regular intervals. 466 The protocol used on the dy interface is HTTPS. 468 Not relevant during the Sunrise Period. 470 4.3.4. tr 472 The Registrant communicates with the Registrar via the tr interface. 474 The specifics of the tr interface are beyond the scope of this 475 document. 477 4.3.5. ry 479 The Registrar communicate with the Registry via the ry interface. 480 The ry interfaces is typically implemented in EPP. 482 4.3.6. dr 484 During the Trademark Claims Period, the Registrar fetches the TCN 485 from the TMDB (to be displayed to the Registrant via the tr 486 interface) via the dr interface. The protocol used for fetching the 487 TCN is HTTPS. 489 Not relevant during the Sunrise Period. 491 4.3.7. yd 493 During the Sunrise Period the Registry notifies the TMDB via the yd 494 interface of all DNs effectively allocated. 496 During the Trademark Claims Period, the Registry notifies the TMDB 497 via the yd interface of all DNs effectively allocated that matched an 498 entry in the Registry previously downloaded DNL List during the 499 creation of the DN. 501 The protocol used on the yd interface is HTTPS. 503 4.3.8. dv 505 The TMDB notifies via the dv interface to the TMV of all DNs 506 effectively allocated that match a mark registered by that TMV. 508 The specifics of the dv interface are beyond the scope of this 509 document. 511 4.3.9. vh 513 The TMV notifies the TMH via the vh interface after a DN has been 514 effectively allocated that matches a PRM of this TMH. 516 The specifics of the vh interface are beyond the scope of this 517 document. 519 4.3.10. vs 521 The TMV requests to add a revoked SMD to the SMD Revocation List at 522 the TMDB. 524 The specifics of the vs interface are beyond the scope of this 525 document. 527 Not relevant during the Trademark Claims Period. 529 4.3.11. sy 531 During the Sunrise Period the Registry fetches the most recent SMD 532 Revocation List from the TMDB via the sy interface in regular 533 intervals. The protocol used on the sy interface is HTTPS. 535 Not relevant during the Trademark Claims Period. 537 4.3.12. sr 539 During the Sunrise Period the Registrar may fetch the most recent SMD 540 Revocation List from the TMDB via the sr interface. The protocol 541 used on the sr interface is the same as on the sy interface (s. 542 above), i.e. HTTPS. 544 Not relevant during the Trademark Claims Period. 546 4.3.13. vc 548 The TMV registers its public key, and requests to revoke an existing 549 key, with the ICANN TMCH-CA over the vc interface. 551 The specifics of the vc interface are beyond the scope of this 552 document, but it involves personal communication between the 553 operators of the TMV and the operators of the ICANN TMCH-CA. 555 Not relevant during the Trademark Claims Period. 557 4.3.14. cy 559 During the Sunrise Period the Registry fetches the most recent TMV 560 CRL file from the ICANN TMCH-CA via the cy interface at regular 561 intervals. The TMV CRL is used for validation of TMV certificates. 562 The protocol used on the cy interface is HTTPS. 564 Not relevant during the Trademark Claims Period. 566 4.3.15. cr 568 During the Sunrise Period the Registrar optionally fetches the most 569 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 570 regular intervals. The TMV CRL is used for validation of TMV 571 certificates. The protocol used on the cr interface is HTTPS. 573 Not relevant during the Trademark Claims Period. 575 5. Process Descriptions 577 5.1. Bootstrapping 579 5.1.1. Bootstrapping for Registries 581 5.1.1.1. Credentials 583 Each Registry Operator will receive authentication credentials from 584 the TMDB to be used: 586 o During the Sunrise Period to fetch the SMD Revocation List from 587 the TMBD via the sy interface (Section 4.3.11). 589 o During the Trademark Claims Period to fetch the DNL List from the 590 TMDB via the dy interface (Section 4.3.3). 592 o During the NORDN process to notify the LORDN to the TMDB via the 593 yd interface (Section 4.3.7). 595 Note: credentials are created per TLD and provided to the Registry 596 Operator. 598 5.1.1.2. IP Addresses for Access Control 600 Each Registry Operator MUST provide to the TMDB all IP addresses that 601 will be used to: 603 o Fetch the SMD Revocation List via the sy interface 604 (Section 4.3.11). 606 o Fetch the DNL List from the TMDB via the dy interface 607 (Section 4.3.3). 609 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 611 This access restriction MAY be applied by the TMDB in addition to 612 HTTP Basic access authentication (see [RFC7235]). For credentials to 613 be used, see Section 5.1.1.1. 615 The TMDB MAY limit the number of IP addresses to be accepted per 616 Registry Operator. 618 5.1.1.3. ICANN TMCH Trust Anchor 620 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 621 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 622 tmch.crt > to be used: 624 o During the Sunrise Period to validate the TMV certificates and the 625 TMV CRL. 627 5.1.1.4. TMDB PGP Key 629 The TMDB MUST provide each Registry Operator with the public portion 630 of the PGP Key used by TMDB, to be used: 632 o During the Sunrise Period to perform integrity checking of the SMD 633 Revocation List fetched from the TMDB via the sy interface 634 (Section 4.3.11). 636 o During the Trademark Claims Period to perform integrity checking 637 of the DNL List fetched from the TMDB via the dy interface 638 (Section 4.3.3). 640 5.1.2. Bootstrapping for Registrars 642 5.1.2.1. Credentials 644 Each ICANN-accredited Registrar will receive authentication 645 credentials from the TMDB to be used: 647 o During the Sunrise Period to (optionally) fetch the SMD Revocation 648 List from the TMDB via the sr interface (Section 4.3.12). 650 o During the Trademark Claims Period to fetch TCNs from the TMDB via 651 the dr interface (Section 4.3.6). 653 5.1.2.2. IP Addresses for Access Control 655 Each Registrar MUST provide to the TMDB all IP addresses, which will 656 be used to: 658 o Fetch the SMD Revocation List via the sr interface 659 (Section 4.3.12). 661 o Fetch TCNs via the dr interface (Section 4.3.6). 663 This access restriction MAY be applied by the TMDB in addition to 664 HTTP Basic access authentication (for credentials to be used, see 665 Section 5.1.2.1). 667 The TMDB MAY limit the number of IP addresses to be accepted per 668 Registrar. 670 5.1.2.3. ICANN TMCH Trust Anchor 672 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 673 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 675 o During the Sunrise Period to (optionally) validate the TMV 676 certificates and TMV CRL. 678 5.1.2.4. TMDB PGP Key 680 Registrars MUST receive the public portion of the PGP Key used by 681 TMDB from the TMDB administrator to be used: 683 o During the Sunrise Period to (optionally) perform integrity 684 checking of the SMD Revocation List fetched from the TMDB via the 685 sr interface (Section 4.3.12). 687 5.2. Sunrise Period 689 5.2.1. Domain Name registration 691 Domain Name registration during the Sunrise Period 693 .------------. .-----------. .----------. 694 | Registrant | | Registrar | | Registry | 695 '------------' '-----------' '----------' 696 | | | 697 | Request DN | | 698 | registration | | 699 | (with SMD) | | 700 |---------------->| Check DN availability | 701 | |---------------------------->| 702 | | | 703 | | DN unavailable .-------------. 704 | DN unavailable |<--------------------( DN available? ) 705 |<----------------| no '-------------' 706 | | | yes 707 | | DN available | 708 | |<----------------------------| 709 | | | 710 | | Request DN registration | 711 | | (with SMD) | 712 | |---------------------------->| 713 | | | 714 | | .------------------------------. 715 | | | DN registration validation / | 716 | | | SMD validation | 717 | | '------------------------------' 718 | | | 719 | Registration |.-----------. Error .----------------------. 720 | error || TRY AGAIN |<-----( Validation successful? ) 721 |<----------------|| / ABORT | no '----------------------' 722 | |'-----------' | yes 723 | | | 724 | | DN registered | 725 | DN registered |<----------------------------| 726 |<----------------| | 727 | | | 729 Figure 3 731 Note: the figure depicted above represents a synchronous DN 732 registration workflow (usually called first come first served). 734 5.2.2. Sunrise Domain Name registration by Registries 736 Registries MUST perform a minimum set of checks for verifying each DN 737 registration during the Sunrise Period upon reception of a 738 registration request over the ry interface (Section 4.3.5). If any 739 of these checks fails the Registry MUST abort the registration. Each 740 of these checks MUST be performed before the DN is effectively 741 allocated. 743 In case of asynchronous registrations (e.g. auctions), the minimum 744 set of checks MAY be performed when creating the intermediate object 745 (e.g. a DN application) used for DN registration. If the minimum set 746 of checks is performed when creating the intermediate object (e.g. a 747 DN application) a Registry MAY effectively allocate the DN without 748 performing the minimum set of checks again. 750 Performing the minimum set of checks Registries MUST verify that: 752 1. An SMD has been received from the Registrar along with the DN 753 registration. 755 2. The certificate of the TMV has been correctly signed by the ICANN 756 TMCH-CA. (The certificate of the TMV is contained within the 757 SMD.) 759 3. The datetime when the validation is done is within the validity 760 period of the TMV certificate. 762 4. The certificate of the TMV is not listed in the TMV CRL file 763 specified in the CRL distribution point of the TMV certificate. 765 5. The signature of the SMD (signed with the TMV certificate) is 766 valid. 768 6. The datetime when the validation is done is within the validity 769 period of the SMD based on and 770 elements. 772 7. The SMD has not been revoked, i.e., is not contained in the SMD 773 Revocation List. 775 8. The leftmost DNL of the DN being effectively allocated matches 776 one of the labels () elements in the SMD. For 777 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 778 effectively allocated, the leftmost DNL would be "xn--mgbachtv". 780 These procedure apply to all DN effective allocations at the second 781 level as well as to all other levels subordinate to the TLD that the 782 Registry accepts registrations for. 784 5.2.3. TMDB Sunrise Services for Registries 786 5.2.3.1. SMD Revocation List 788 A new SMD Revocation List MUST be published by the TMDB twice a day, 789 by 00:00:00 and 12:00:00 UTC. 791 Registries MUST refresh the latest version of the SMD Revocation List 792 at least once every 24 hours. 794 Note: the SMD Revocation List will be the same regardless of the TLD. 795 If a Backend Registry Operator manages the infrastructure of several 796 TLDs, the Backend Registry Operator could refresh the SMD Revocation 797 List once every 24 hours, the SMD Revocation List could be used for 798 all the TLDs managed by the Backend Registry Operator. 800 Update of the SMD Revocation List 802 .----------. .------. 803 | Registry | | TMDB | 804 '----------' '------' 805 | | 806 .----------------. | 807 | Periodically, | | 808 | at least | | 809 | every 24 hours | | 810 '----------------' | 811 | | 812 |----------------------------------------------------->| 813 | Download the latest SMD Revocation List | 814 |<-----------------------------------------------------| 815 | | 816 | | 818 Figure 4 820 5.2.3.2. TMV Certificate Revocation List (CRL) 822 Registries MUST refresh their local copy of the TMV CRL file at least 823 every 24 hours using the CRL distribution point specified in the TMV 824 certificate. 826 Operationally, the TMV CRL file and CRL distribution point is the 827 same for all TMVs and (at publication of this document) located at < 828 http://crl.icann.org/tmch.crl >. 830 Note: the TMV CRL file will be the same regardless of the TLD. If a 831 Backend Registry Operator manages the infrastructure of several TLDs, 832 the Backend Registry Operator could refresh the TMV CRL file once 833 every 24 hours, the TMV CRL file could be used for all the TLDs 834 managed by the Backend Registry Operator. 836 Update of the TMV CRL file 838 .----------. .---------------. 839 | Registry | | ICANN TMCH-CA | 840 '----------' '---------------' 841 | | 842 .----------------. | 843 | Periodically, | | 844 | at least | | 845 | every 24 hours | | 846 '----------------' | 847 | | 848 |-------------------------------------------->| 849 | Download the latest TMV CRL file | 850 |<--------------------------------------------| 851 | | 852 | | 854 Figure 5 856 5.2.3.3. Notice of Registered Domain Names (NORN) 858 The Registry MUST send a LORDN file containing DNs effectively 859 allocated to the TMDB (over the yd interface, Section 4.3.7). 861 The effective allocation of a DN MUST be reported by the Registry to 862 the TMDB within 26 hours of the effective allocation of such DN. 864 The Registry MUST create and upload a LORDN file in case there are 865 effective allocations in the SRS, that have not been successfully 866 reported to the TMDB in a previous LORDN file. 868 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 869 maximum frequency to upload LORDN files from the Registries to the 870 TMDB is every 3 hours. 872 It is RECOMMENDED that Registries try to upload at least two LORDN 873 files per day to the TMDB with enough time in between, in order to 874 have time to fix problems reported in the LORDN file. 876 The Registry SHOULD upload a LORDN file only when the previous LORDN 877 file has been processed by the TMDB and the related LORDN Log file 878 has been downloaded and processed by the Registry. 880 The Registry MUST upload LORDN files for DNs effectively allocated 881 during the Sunrise or Trademark Claims Period (same applies to DNs 882 effectively allocated using applications created during the Sunrise 883 or Trademark Claims Period in case of using asynchronous 884 registrations). 886 The yd interface (Section 4.3.7) MUST support at least one (1) and 887 MAY support up to ten (10) concurrent connections from each IP 888 address registered by a Registry Operator to access the service. 890 The TMDB MUST process each uploaded LORDN file and make the related 891 log file available for Registry download within 30 minutes of the 892 finalization of the upload. 894 Notification of Registered Domain Name 896 .----------. .------. .-----. .-----. 897 | Registry | | TMDB | | TMV | | TMH | 898 '----------' '------' '-----' '-----' 899 | | | | 900 .------------------. | | | 901 | Periodically | | | | 902 | upload LORDN | | | | 903 | file | | | | 904 '------------------' | | | 905 | | | | 906 .--------->| Upload LORDN | | | 907 | |-------------------->| | | 908 | | | | | 909 | | .-------------------------. | | 910 | | | Verify each domain name | | | 911 | | | in the uploaded file | | | 912 | | | (within 30') | | | 913 | | '-------------------------' | | 914 | | | ._____.| | 915 | | Download Log file | | END || | 916 | |<--------------------| '-----'| | 917 | | | ^ | | 918 | .-----------------. .---------------. | | | 919 | | Check whether | / everything fine \ no | | | 920 | | Log file | ( (i.e. no errors )---' | | 921 | | contains errors | \ in Log file )? / | | 922 | '-----------------' '---------------' | | 923 | | | yes | | 924 | .---------------. | | | 925 | / everything fine \ yes | | | 926 |( (i.e. no errors )-----. | Notify TMVs | | 927 | \ in Log file )? / | | on the LORDN | | 928 | '---------------' | | pre-registered | | 929 | | no v | with said TMV | | 930 | .----------------. .------. |--------------->| | 931 '-| Correct Errors | | DONE | | | | 932 '----------------' '------' | | Notify each | 933 | | | affected TMH | 934 | | |-------------->| 935 | | | | 937 Figure 6 939 The format used for the LORDN is described in Section 6.3 941 5.2.4. Sunrise Domain Name registration by Registrars 943 Registrars MAY choose to perform the checks for verifying DN 944 registrations as performed by the Registries (see Section 5.2.2) 945 before sending the command to register a DN. 947 5.2.5. TMDB Sunrise Services for Registrars 949 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 950 also available for Registrars to optionally validate the SMDs 951 received. 953 5.3. Trademark Claims Period 955 5.3.1. Domain Registration 957 Domain Name registration during the Trademark Claims Period 959 .------------. .-----------. .----------. .------. 960 | Registrant | | Registrar | | Registry | | TMDB | 961 '------------' '-----------' '----------' '------' 962 | Request DN | | | 963 | registration | | | 964 |--------------->| Check DN availability | | 965 | |--------------------------->| | 966 | | DN unavailable .-------------. | 967 | DN unavailable |<-------------------( DN available? ) | 968 |<---------------| no '-------------' | 969 | | DN available | yes | 970 | |<---------------------------| | 971 | | Request Lookup key | | 972 | |--------------------------->| | 973 | |.__________. .---------. | 974 | || CONTINUE | / Does DN \ | 975 | || NORMALLY |<--------( match DNL ) | 976 | |'----------' no \ of PRM? / | 977 | | '---------' | 978 | | Lookup key | yes | 979 | |<----------------------------' | 980 | | | 981 .-----. | | Request TCN | 982 |ABORT| | Display |---------------------------------------->| 983 '-----' | Claims | Return TCN | 984 ^ | Notice |<----------------------------------------| 985 | no |<---------------| | 986 | .------. yes | | 987 '-( Ack? )----------->| Register DN (with TCNID) | | 988 '------' |--------------------------->| | 989 | Registration | Error .----------------------. | 990 | error |<-------------( Validation successful? ) | 991 |<---------------| no '----------------------' | 992 | | | yes | 993 | | DN registered | | 994 | DN registered |<---------------------------| | 995 |<---------------| | | 997 Figure 7 999 Note: the figure depicted above represents a synchronous DN 1000 registration workflow (usually called first come first served). 1002 5.3.2. Trademark Claims Domain Name registration by Registries 1004 During the Trademark Claims Period, Registries perform two main 1005 functions: 1007 o Registries MUST provide Registrars (over the ry interface, 1008 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1009 that match the DNL List. 1011 o Registries MUST provide the Lookup Key only when queried about a 1012 specific DN. 1014 o For each DN matching a DNL of a PRM, Registries MUST perform a 1015 minimum set of checks for verifying DN registrations during the 1016 Trademark Claims Period upon reception of a registration request 1017 over the ry interface (Section 4.3.5). If any of these checks 1018 fails the Registry MUST abort the registration. Each of these 1019 checks MUST be performed before the DN is effectively allocated. 1021 o In case of asynchronous registrations (e.g. auctions), the minimum 1022 set of checks MAY be performed when creating the intermediate 1023 object (e.g. a DN application) used for DN effective allocation. 1024 If the minimum set of checks is performed when creating the 1025 intermediate object (e.g. a DN application) a Registry MAY 1026 effectively allocate the DN without performing the minimum set of 1027 checks again. 1029 o Performing the minimum set of checks Registries MUST verify that: 1031 1. The TCNID (), expiration datetime 1032 () and acceptance datetime of the TCN, have 1033 been received from the Registrar along with the DN 1034 registration. 1036 If the three elements mentioned above are not provided by 1037 the Registrar for a DN matching a DNL of a PRM, but the DNL 1038 was inserted (or re-inserted) for the first time into DNL 1039 List less than 24 hours ago, the registration MAY continue 1040 without this data and the tests listed below are not 1041 required to be performed. 1043 2. The TCN has not expired (according to the expiration datetime 1044 sent by the Registrar). 1046 3. The acceptance datetime is within the window of time defined 1047 by ICANN policy. In the gTLD round of 2012, Registrars 1048 verified that the acceptance datetime was less than or equal 1049 to 48 hours in the past, as there were no defined ICANN 1050 policies at that time. Implementers should be aware that 1051 ICANN policy may define this value in the future. 1053 4. Using the leftmost DNL of the DN being effectively allocated, 1054 the expiration datetime provided by the Registrar, and the 1055 TMDB Notice Identifier extracted from the TCNID provided by 1056 the Registrar compute the TCN Checksum. Verify that the 1057 computed TCN Checksum match the TCN Checksum present in the 1058 TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is 1059 being effectively allocated, the leftmost DNL would be "xn-- 1060 mgbachtv". 1062 These procedures apply to all DN registrations at the second level as 1063 well as to all other levels subordinate to the TLD that the Registry 1064 accepts registrations for. 1066 5.3.3. TMBD Trademark Claims Services for Registries 1068 5.3.3.1. Domain Name Label (DNL) List 1070 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1071 and 12:00:00 UTC. 1073 Registries MUST refresh the latest version of the DNL List at least 1074 once every 24 hours. 1076 Update of the DNL List 1078 .----------. .------. 1079 | Registry | | TMDB | 1080 '----------' '------' 1081 | | 1082 .----------------. | 1083 | Periodically, | | 1084 | at least | | 1085 | every 24 hours | | 1086 '----------------' | 1087 | | 1088 |-------------------------------->| 1089 | Download the latest DNL List | 1090 |<--------------------------------| 1091 | | 1092 | | 1094 Figure 8 1096 Note: the DNL List will be the same regardless of the TLD. If a 1097 Backend Registry Operator manages the infrastructure of several TLDs, 1098 the Backend Registry Operator could refresh the DNL List once every 1099 24 hours, the DNL List could be used for all the TLDs managed by the 1100 Backend Registry Operator. 1102 5.3.3.2. Notice of Registered Domain Names (NORN) 1104 The NORDN process during the Trademark Claims Period is almost the 1105 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1106 difference that only registrations subject to a Trademark Claim 1107 (i.e., at registration time the name appeared in the current DNL List 1108 downloaded by the Registry Operator) are included in the LORDN. 1110 5.3.4. Trademark Claims Domain Name registration by Registrars 1112 For each DN matching a DNL of a PRM, Registrars MUST perform the 1113 following steps: 1115 1. Use the Lookup Key received from the Registry to obtain the TCN 1116 from the TMDB using the dr interface (Section 4.3.6) Registrars 1117 MUST only query for the Lookup Key of a DN that is available for 1118 registration. 1120 2. Present the TCN to the Registrant as described in Exhibit A, 1121 [RPM-Requirements]. 1123 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1124 consent with the TCN, before any further processing. (The 1125 transmission of a TCNID to the Registry over the ry interface, 1126 Section 4.3.5 implies that the Registrant has expressed his/her 1127 consent with the TCN.) 1129 4. Perform the minimum set of checks for verifying DN registrations. 1130 If any of these checks fails the Registrar MUST abort the DN 1131 registration. Each of these checks MUST be performed before the 1132 registration is sent to the Registry. Performing the minimum set 1133 of checks Registrars MUST verify that: 1135 1. The datetime when the validation is done is within the TCN 1136 validity based on the and 1137 elements. 1139 2. The leftmost DNL of the DN being effectively allocated 1140 matches the label () element in the TCN. For 1141 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 1142 effectively allocated, the leftmost DNL would be "xn-- 1143 mgbachtv". 1145 3. The Registrant has acknowledged (expressed his/her consent 1146 with) the TCN. 1148 5. Record the date and time when the registrant acknowledged the 1149 TCN. 1151 6. Send the registration to the Registry (ry interface, 1152 Section 4.3.5) and include the following information: 1154 * TCNID () 1156 * Expiration date of the TCN () 1158 * Acceptance datetime of the TCN. 1160 Currently TCNs are generated twice a day by the TMDB. The expiration 1161 date () of each TCN MUST be set to a value defined 1162 by ICANN policy. In the gTLD round of 2012, the TMDB set the 1163 expiration value to 48 hours in to the future as there were no 1164 defined ICANN policies at that time. Implementers should be aware 1165 that ICANN policy may define this value in the future. 1167 Registrars SHOULD implement a cache of TCNs to minimize the number of 1168 queries sent to the TMDB. A cached TCN MUST be removed from the 1169 cache after the expiration date of the TCN as defined by 1170 . 1172 The TMDB MAY implement rate-limiting as one of the protection 1173 mechanisms to mitigate the risk of performance degradation. 1175 5.3.5. TMBD Trademark Claims Services for Registrars 1177 5.3.5.1. Claims Notice Information Service (CNIS) 1179 The TCNs are provided by the TMDB online and are fetched by the 1180 Registrar via the dr interface (Section 4.3.6). 1182 To get access to the TCNs, the Registrar needs the credentials 1183 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1184 from the Registry via the ry interface (Section 4.3.5). The dr 1185 interface (Section 4.3.6) uses HTTPS with Basic access 1186 authentication. 1188 The dr interface (Section 4.3.6) MAY support up to ten (10) 1189 concurrent connections from each Registrar. 1191 The URL of the dr interface (Section 4.3.6) is: 1193 < https:///cnis/.xml > 1195 Note that the "lookupkey" may contain SLASH characters ("/"). The 1196 SLASH character is part of the URL path and MUST NOT be escaped when 1197 requesting the TCN. 1199 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1200 MUST be signed by a well-know public CA. Registrars MUST perform the 1201 Certification Path Validation described in Section 6 of [RFC5280]. 1202 Registrars will be authenticated in the dr interface using HTTP Basic 1203 access authentication. The dr (Section 4.3.6) interface MUST support 1204 HTTPS keep-alive and MUST maintain the connection for up to 30 1205 minutes. 1207 5.4. Qualified Launch Program (QLP) Period 1209 5.4.1. Domain Registration 1211 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1212 (QLP) Period effective allocations of DNs to third parties could 1213 require that Registries and Registrars provide Sunrise and/or 1214 Trademark Claims services. If required, Registries and Registrars 1215 MUST provide Sunrise and/or Trademark Claims services as described in 1216 Section 5.2 and Section 5.3. 1218 The effective allocation scenarios are: 1220 o If the leftmost DNL of the DN being effectively allocated (QLP 1221 Name in this section) matches a DNL in the SURL, and an SMD is 1222 provided, then Registries MUST provide Sunrise Services (see 1223 Section 5.2) and the DN MUST be reported in a Sunrise LORDN file 1224 during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- 1225 mgbh0fb" is being effectively allocated, the leftmost DNL would be 1226 "xn--mgbachtv". 1228 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1229 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1230 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1231 file using the special SMD-id "99999-99999" during the QLP Period. 1233 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1234 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1235 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1236 services (see Section 5.3) and the DN MUST be reported in a 1237 Trademark Claims LORDN file during the QLP Period. 1239 o If the QLP Name matches a DNL in the DNL List but does not match a 1240 DNL in the SURL, then Registries MUST provide Trademark Claims 1241 services (see Section 5.2) and the DN MUST be reported in a 1242 Trademark Claims LORDN file during the QLP Period. 1244 The following table lists all the effective allocation scenarios 1245 during a QLP Period: 1247 +--------+---------+-----------------+--------------+---------------+ 1248 | QLP | QLP | SMD was | Registry | Registry MUST | 1249 | Name | Name | provided by the | MUST provide | report DN | 1250 | match | match | potential | Sunrise or | registration | 1251 | in the | in the | Registrant | Trademark | in | 1252 | SURL | DNL | | Claims | LORDN file | 1253 | | List | | Services | | 1254 +--------+---------+-----------------+--------------+---------------+ 1255 | Y | Y | Y | Sunrise | Sunrise | 1256 | | | | | | 1257 | Y | N | Y | Sunrise | Sunrise | 1258 | | | | | | 1259 | N | Y | -- | Trademark | Trademark | 1260 | | | | Claims | Claims | 1261 | | | | | | 1262 | N | N | -- | -- | -- | 1263 | | | | | | 1264 | Y | Y | N (see section | Trademark | Trademark | 1265 | | | 2.2 of | Claims | Claims | 1266 | | | [QLP-Addendum]) | | | 1267 | | | | | | 1268 | Y | N | N (see section | -- | Sunrise | 1269 | | | 2.2 of | | (using | 1270 | | | [QLP-Addendum]) | | special SMD- | 1271 | | | | | id) | 1272 +--------+---------+-----------------+--------------+---------------+ 1274 QLP Effective Allocation Scenarios 1276 The TMDB MUST provide the following services to Registries during a 1277 QLP Period: 1279 o SMD Revocation List (see Section 5.2.3.1) 1281 o NORN (see Section 5.2.3.3) 1283 o DNL List (see Section 5.3.3.1) 1285 o Sunrise List (SURL) (see Section 5.4.2.1 1287 The TMDB MUST provide the following services to Registrars during a 1288 QLP Period: 1290 o SMD Revocation List (see Section 5.2.3.1) 1291 o CNIS (see Section 5.3.5.1) 1293 5.4.2. TMBD QLP Services for Registries 1295 5.4.2.1. Sunrise List (SURL) 1297 A new Sunrise List (SURL) MUST be published by the TMDB twice a day, 1298 by 00:00:00 and 12:00:00 UTC. 1300 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1301 version of the SURL at least once every 24 hours. 1303 Update of the SURL 1305 .----------. .------. 1306 | Registry | | TMDB | 1307 '----------' '------' 1308 | | 1309 .----------------. | 1310 | Periodically, | | 1311 | at least | | 1312 | every 24 hours | | 1313 '----------------' | 1314 | | 1315 |------------------------------->| 1316 | Download the latest SURL | 1317 |<-------------------------------| 1318 | | 1319 | | 1321 Figure 9 1323 Note: the SURL will be the same regardless of the TLD. If a Backend 1324 Registry Operator manages the infrastructure of several TLDs, the 1325 Backend Registry Operator could refresh the SURL once every 24 hours, 1326 the SURL could be used for all the TLDs managed by the Backend 1327 Registry Operator. 1329 6. Data Format Descriptions 1331 6.1. Domain Name Label (DNL) List 1333 This section defines the format of the list containing every Domain 1334 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1335 is maintained by the TMDB and downloaded by Registries in regular 1336 intervals (see Section 5.3.3.1). The Registries use the DNL List 1337 during the Trademark Claims Period to check whether a requested DN 1338 matches a DNL of a PRM. 1340 The DNL List contains all the DNLs covered by a PRM present in the 1341 TMDB at the datetime it is generated. 1343 The DNL List is contained in a CSV formatted file that has the 1344 following structure: 1346 o first line: , 1348 Where: 1350 + , version of the file, this field MUST be 1. 1352 + , date and time in UTC that the 1353 DNL List was created. 1355 o second line: a header line as specified in [RFC4180] 1357 With the header names as follows: 1359 DNL,lookup-key,insertion-datetime 1361 o One or more lines with: ,, 1364 Where: 1366 + , a Domain Name Label covered by a PRM. 1368 + , lookup key that the Registry MUST provide to 1369 the Registrar. The lookup key has the following format: 1370
////, where: 1373 - YYYY: year that the TCN was generated. 1375 - MM: zero-padded month that the TCN was generated. 1377 - DD: zero-padded day that the TCN was generated. 1379 - vv: version of the TCN, possible values are 00 and 01. 1381 - X: one hexadecimal digit [0-9A-F]. This is the first, 1382 second and third hexadecimal digit of encoding the 1383 in base16 as specified in [RFC4648]. 1385 - Random bits: 144 random bits encoded in base64url as 1386 specified in [RFC4648]. 1388 - Sequential number: zero-padded natural number in the 1389 range 0000000001 to 2147483647. 1391 + , datetime in UTC that the DNL was 1392 first inserted into the DNL List. The possible two values 1393 of time for inserting a DNL to the DNL List are 00:00:00 and 1394 12:00:00 UTC. 1396 Example of a DNL List 1398 1,2012-08-16T00:00:00.0Z 1399 DNL,lookup-key,insertion-datetime 1400 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1401 2010-07-14T00:00:00.0Z 1402 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1403 2012-08-16T00:00:00.0Z 1404 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1405 2011-08-16T12:00:00.0Z 1407 Figure 10 1409 To provide authentication and integrity protection, the DNL List will 1410 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1411 PGP signature of the DNL List can be found in the similar URI but 1412 with extension .sig as shown below. 1414 The URL of the dy interface (Section 4.3.3) is: 1416 o < https:///dnl/dnl-latest.csv > 1418 o < https:///dnl/dnl-latest.sig > 1420 6.2. SMD Revocation List 1422 This section defines the format of the list of SMDs that have been 1423 revoked. The list is maintained by the TMDB and downloaded by 1424 Registries (and optionally by Registrars) in regular intervals (see 1425 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1426 Period to validate SMDs received. The SMD Revocation List has a 1427 similar function as CRLs used in PKI [RFC5280]. 1429 The SMD Revocation List contains all the revoked SMDs present in the 1430 TMDB at the datetime it is generated. 1432 The SMD Revocation List is contained in a CSV formatted file that has 1433 the following structure: 1435 o first line: , 1437 Where: 1439 + , version of the file, this field MUST be 1. 1441 + , datetime in UTC 1442 that the SMD Revocation List was created. 1444 o second line: a header line as specified in [RFC4180] 1446 With the header names as follows: 1448 smd-id,insertion-datetime 1450 o One or more lines with: , 1452 Where: 1454 + , identifier of the SMD that was revoked. 1456 + , revocation datetime in UTC of the 1457 SMD. The possible two values of time for inserting an SMD 1458 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1460 To provide integrity protection, the SMD Revocation List is PGP 1461 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1462 List is provided by the TMDB with extension .csv. The PGP signature 1463 of the SMD Revocation List can be found in the similar URI but with 1464 extension .sig as shown below. 1466 The URL of the sr interface (Section 4.3.12) and sy interface 1467 (Section 4.3.11) is: 1469 o < https:///smdrl/smdrl-latest.csv > 1471 o < https:///smdrl/smdrl-latest.sig > 1472 Example of an SMD Revocation List 1474 1,2012-08-16T00:00:00.0Z 1475 smd-id,insertion-datetime 1476 2-2,2012-08-15T00:00:00.0Z 1477 3-2,2012-08-15T00:00:00.0Z 1478 1-2,2012-08-15T00:00:00.0Z 1480 Figure 11 1482 6.3. List of Registered Domain Names (LORDN) file 1484 This section defines the format of the List of Registered Domain 1485 Names (LORDN), which is maintained by each Registry and uploaded at 1486 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1487 said DN is added to the LORDN along with further information related 1488 to its registration. 1490 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1491 file is: 1493 o Sunrise LORDN file: 1495 < https:///LORDN//sunrise > 1497 o Trademark Claims LORDN file: 1499 < https:///LORDN//claims > 1501 During a QLP Period, Registries MAY be required to upload Sunrise or 1502 Trademark Claims LORDN files. The URIs of the yd interface used to 1503 upload LORDN files during a QLP Period is: 1505 o Sunrise LORDN file (during QLP Period): 1507 < https:///LORDN//sunrise/qlp > 1509 o Trademark Claims LORDN file (during a QLP Period): 1511 < https:///LORDN//claims/qlp > 1513 The yd interface (Section 4.3.7) returns the following HTTP status 1514 codes after a HTTP POST request method is received: 1516 o The interface provides a HTTP/202 status code if the interface was 1517 able to receive the LORDN file and the syntax of the LORDN file is 1518 correct. 1520 The interface provides the LORDN Transaction Identifier in the 1521 HTTP Entity-body that would be used by the Registry to download 1522 the LORDN Log file. The LORDN Transaction Identifier is a 1523 natural number zero-padded in the range 0000000000000000001 to 1524 9223372036854775807. 1526 The TMDB uses the element of the 1527 LORDN file as a unique client-side identifier. If a LORDN file 1528 with the same of a previously sent 1529 LORDN file is received by the TMDB, the LORDN Transaction 1530 Identifier of the previously sent LORDN file MUST be provided 1531 to the Registry. The TMDB MUST ignore the DN Lines present in 1532 the LORDN file if a LORDN file with the same was previously sent. 1535 The HTTP Location header field contains the URI where the LORDN 1536 Log file could be retrieved later, for example: 1538 202 Accepted 1540 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1543 o The interface provides a HTTP/400 if the request is incorrect or 1544 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1545 human readable message in the HTTP Entity-body regarding the 1546 incorrect syntax of the LORDN file. 1548 o The interface provides a HTTP/401 status code if the credentials 1549 provided does not authorize the Registry Operator to upload a 1550 LORDN file. 1552 o The TMDB MUST return a HTTP/404 status code when trying to upload 1553 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1556 plus 26 hours. 1558 o The interface provides a HTTP/500 status code if the system is 1559 experiencing a general failure. 1561 For example, to upload the Sunrise LORDN file for TLD "example", the 1562 URI would be: 1564 < https:///LORDN/example/sunrise > 1566 The LORDN is contained in a CSV formatted file that has the following 1567 structure: 1569 o For Sunrise Period: 1571 * first line: ,, 1574 Where: 1576 - , version of the file, this field MUST be 1. 1578 - , date and time in UTC that the 1579 LORDN was created. 1581 - , number of DN Lines present in the 1582 LORDN file. 1584 * second line: a header line as specified in [RFC4180] 1586 With the header names as follows: 1588 roid,domain-name,SMD-id,registrar-id,registration- 1589 datetime,application-datetime 1591 * One or more lines with: ,,,,, 1595 Where: 1597 - , DN Repository Object IDentifier (DNROID) in the 1598 SRS. 1600 - , DN that was effectively allocated. For 1601 IDNs, the A-label form is used. 1603 - , SMD ID used for registration. 1605 - , IANA Registrar ID. 1607 - , date and time in UTC that the 1608 domain was effectively allocated. 1610 - OPTIONAL , date and 1611 time in UTC that the application was created. The 1612 MUST be provided in 1613 case of a DN effective allocation based on an 1614 asynchronous registration (e.g., when using auctions). 1616 Example of a Sunrise LORDN file 1618 1,2012-08-16T00:00:00.0Z,3 1619 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1620 application-datetime 1621 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1622 2012-07-15T00:50:00.0Z 1623 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1624 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1626 Figure 12 1628 o For Trademark Claims Period: 1630 * first line: ,, 1633 Where: 1635 - , version of the file, this field MUST be 1. 1637 - , date and time in UTC that the 1638 LORDN was created. 1640 - , number of DN Lines present in the 1641 LORDN file. 1643 * second line: a header line as specified in [RFC4180] 1645 With the header names as follows: 1647 roid,domain-name,notice-id,registrar-id,registration- 1648 datetime,ack-datetime,application-datetime 1650 * One or more lines with: ,,,,,, 1654 Where: 1656 - , DN Repository Object IDentifier (DNROID) in the 1657 SRS. 1659 - , DN that was effectively allocated. For 1660 IDNs, the A-label form is used. 1662 - , Trademark Claims Notice Identifier as specified 1663 in . 1665 - , IANA Registrar ID. 1667 - , date and time in UTC that the 1668 domain was effectively allocated. 1670 - , date and time in UTC 1671 that the TCN was acknowledged. 1673 - OPTIONAL , date and 1674 time in UTC that the application was created. The 1675 MUST be provided in 1676 case of a DN effective allocation based on an 1677 asynchronous registration (e.g., when using auctions). 1679 For a DN matching a DNL of a PRM at the moment of 1680 registration, created without the TCNID, expiration datetime 1681 and acceptance datetime, because DNL was inserted (or re- 1682 inserted) for the first time into DNL List less than 24 1683 hours ago, the string "recent-dnl-insertion" MAY be 1684 specified in and . 1687 Example of a Trademark Claims LORDN file 1689 1,2012-08-16T00:00:00.0Z,3 1690 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1691 ack-datetime,application-datetime 1692 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1693 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1694 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1695 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1696 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1697 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1699 Figure 13 1701 6.3.1. LORDN Log file 1703 After reception of the LORDN file, the TMDB verifies its content for 1704 syntactical and semantical correctness. The output of the LORDN file 1705 verification is retrieved using the yd interface (Section 4.3.7). 1707 The URI of the yd interface (Section 4.3.7) used to retrieve the 1708 LORDN Log file is: 1710 o Sunrise LORDN Log file: 1712 < https:///LORDN//sunrise//result > 1715 o Trademark Claims LORDN Log file: 1717 < https:///LORDN//claims//result > 1720 A Registry Operator MUST NOT send more than one request per minute 1721 per TLD to download a LORDN Log file. 1723 The yd interface (Section 4.3.7) returns the following HTTP status 1724 codes after a HTTP GET request method is received: 1726 o The interface provides a HTTP/200 status code if the interface was 1727 able to provide the LORDN Log file. The LORDN Log file is 1728 contained in the HTTP Entity-body. 1730 o The interface provides a HTTP/204 status code if the LORDN 1731 Transaction Identifier is correct, but the server has not 1732 finalized processing the LORDN file. 1734 o The interface provides a HTTP/400 status code if the request is 1735 incorrect. 1737 o The interface provides a HTTP/401 status code if the credentials 1738 provided does not authorize the Registry Operator to download the 1739 LORDN Log file. 1741 o The interface provides a HTTP/404 status code if the LORDN 1742 Transaction Identifier is incorrect. 1744 o The interface provides a HTTP/500 status code if the system is 1745 experiencing a general failure. 1747 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1748 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1749 "example" the URI would be: 1751 < https:///LORDN/example/sunrise/0000000000000000001/result > 1754 The LORDN Log file is contained in a CSV formatted file that has the 1755 following structure: 1757 o first line: ,,,,,, 1761 Where: 1763 + , version of the file, this field MUST be 1. 1765 + , date and time in UTC that the 1766 LORDN Log was created. 1768 + , date and time in UTC of 1769 creation for the LORDN file that this log file is referring 1770 to. 1772 + , unique identifier of the LORDN Log 1773 provided by the TMDB. This identifier could be used by the 1774 Registry Operator to unequivocally identify the LORDN Log. 1775 The identified will be a string of a maximum LENGTH of 60 1776 characters from the Base 64 alphabet. 1778 + , whether the LORDN file has been accepted for 1779 processing by the TMDB. Possible values are "accepted" or 1780 "rejected". 1782 + , whether the LORDN Log has any warning result 1783 codes. Possible values are "no-warnings" or "warnings- 1784 present". 1786 + , number of DNs effective allocations 1787 processed in the LORDN file. 1789 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1790 a ="accepted" and ="no-warnings". 1792 o second line: a header line as specified in [RFC4180] 1794 With the header names as follows: 1796 roid,result-code 1798 o One or more lines with: , 1800 Where: 1802 + , DN Repository Object IDentifier (DNROID) in the SRS. 1804 + , result code as described in Section 6.3.1.1. 1806 Example of a LORDN Log file 1808 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1809 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1810 accepted,no-warnings,1 1811 roid,result-code 1812 SH8013-REP,2000 1814 Figure 14 1816 6.3.1.1. LORDN Log Result Codes 1818 In Figure 15 the classes of result codes (rc) are listed. Those 1819 classes in square brackets are not used at this time, but may come 1820 into use at some later stage. The first two digits of a result code 1821 denote the result code class, which defines the outcome at the TMDB: 1823 o ok: Success, DN Line accepted by the TMDB. 1825 o warn: a warning is issued, DN Line accepted by the TMDB. 1827 o err: an error is issued, LORDN file rejected by the TMDB. 1829 In case that after processing a DN Line, the error result code is 1830 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1831 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1832 valid will be reported with a 2001 result code. A 2001 result code 1833 means that the DN Line is syntactically valid, however the DN Line 1834 was not processed because the LORDN file was rejected. All DNs 1835 reported in a rejected LORDN file MUST be reported again by the 1836 Registry because none of the DN Lines present in the LORDN file have 1837 been processed by the TMDB. 1839 LORDN Log Result Code Classes 1841 code Class outcome 1842 ---- ----- ------- 1844 20xx Success ok 1846 35xx [ DN Line syntax warning ] warn 1847 36xx DN Line semantic warning warn 1849 45xx DN Line syntax error err 1850 46xx DN Line semantic error err 1852 Figure 15 1854 In the following, the LORDN Log result codes used by the TMDB are 1855 described: 1857 LORDN Log result Codes 1859 rc Short Description 1860 Long Description 1861 ---- ------------------------------------------------------------- 1863 2000 OK 1864 DN Line successfully processed. 1866 2001 OK but not processed 1867 DN Line is syntactically correct but was not processed 1868 because the LORDN file was rejected. 1870 3601 TCN Acceptance Date after Registration Date 1871 TCN Acceptance Date in DN Line is newer than the Registration 1872 Date. 1874 3602 Duplicate DN Line 1875 This DN Line is an exact duplicate of another DN Line in same 1876 file, DN Line ignored. 1878 3603 DNROID Notified Earlier 1879 Same DNROID has been notified earlier, DN Line ignored. 1881 3604 TCN Checksum invalid 1882 Based on the DN effectively allocated, the TCNID and the 1883 expiration date of the linked TCN, the TCN Checksum is 1884 invalid. 1886 3605 TCN Expired 1887 The TCN was already expired (based on the 1888 field of the TCN) at the datetime of acknowledgement. 1890 3606 Wrong TCNID used 1891 The TCNID used for the registration does not match 1892 the related DN. 1894 3609 Invalid SMD used 1895 The SMD used for registration was not valid at the moment of 1896 registration based on the and 1897 elements. 1898 In case of an asynchronous registration, this refer to the 1899 . 1901 3610 DN reported outside of the time window 1902 The DN was reported outside of the required 26 hours 1903 reporting window. 1905 3611 DN does not match the labels in SMD 1906 The DN does not match the labels included in the SMD. 1908 3612 SMDID does not exist 1909 The SMDID has never existed in the central repository. 1911 3613 SMD was revoked when used 1912 The SMD used for registration was revoked more than 1913 24 hours ago of the . 1914 In case of an asynchronous registration, 1915 the is used when 1916 validating the DN Line. 1918 3614 TCNID does not exist 1919 The TCNID has never existed in the central repository. 1921 3615 Recent-dnl-insertion outside of the time window 1922 The DN registration is reported as a recent-dnl-insertion, 1923 but the (re) insertion into the DNL occurred more than 1924 24 hours ago. 1926 3616 Registration Date of DN in Claims before the end of Sunrise Period 1927 The registration date of the DN is before the end of Sunrise Period 1928 and the DN was reported in a Trademark Claims LORDN file. 1930 3617 Registrar has not been approved by the TMDB 1931 Registrar ID in DN Line has not completed Trademark Claims integration 1932 testing with the TMDB. 1934 3618 Registration Date of DN in a QLP LORDN file outside of the QLP Period 1935 The registration date of the DN in a QLP LORDN file is outside 1936 of the QLP Period. 1938 3619 TCN was not valid 1939 The TCN was not valid (based on the 1940 field of the TCN) at the datetime of acknowledgement. 1942 4501 Syntax Error in DN Line 1943 Syntax Error in DN Line. 1945 4601 Invalid TLD used 1946 The TLD in the DN Line does not match what is expected for 1947 this LORDN. 1949 4602 Registrar ID Invalid 1950 Registrar ID in DN Line is not a valid ICANN-Accredited 1951 Registrar. 1953 4603 Registration Date in the future 1954 The in the DN Line is in the 1955 future. 1957 4606 TLD not in Sunrise or Trademark Claims Period 1958 The was reported when the TLD was 1959 not in Sunrise or Trademark Claims Periods. 1960 In case of an asynchronous registration, 1961 the is used when 1962 validating the DN Line. 1964 4607 Application Date in the future 1965 The in the DN Line is in the 1966 future. 1968 4608 Application Date is later than Registration Date 1969 The in the DN Line is later 1970 than the . 1972 4609 TCNID wrong syntax 1973 The syntax of the TCNID is invalid. 1975 4610 TCN Acceptance Date is in the future 1976 The is in the future. 1978 4611 Label has never existed in the TMDB 1979 The label in the registered DN has never existed in the TMDB. 1981 Figure 16 1983 6.4. Signed Mark Data (SMD) File 1985 This section defines the format of the Signed Mark Data (SMD) File. 1986 After a successful registration of a mark, the TMV returns an SMD 1987 File to the TMH. The SMD File can then be used for registration of 1988 one or more DNs covered by the PRM during the Sunrise Period of a 1989 TLD. 1991 Two encapsulation boundaries are defined for delimiting the 1992 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1993 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1994 boundaries MUST be used by Registries and Registrars for validation 1995 purposes, i.e. any data outside these boundaries as well as the 1996 boundaries themselves MUST be ignored for validation purposes. 1998 The structure of the SMD File is as follows, all the elements are 1999 REQUIRED, and MUST appear in the specified order. 2001 1. Marks: 2003 2. smdID: 2005 3. U-labels: 2008 4. notBefore: 2010 5. notAfter: 2012 6. -----BEGIN ENCODED SMD----- 2014 7. 2016 8. -----END ENCODED SMD----- 2017 Example of an SMD File: 2019 Marks: Example One 2020 smdID: 1-2 2021 U-labels: example-one, exampleone 2022 notBefore: 2011-08-16 09:00 2023 notAfter: 2012-08-16 09:00 2024 -----BEGIN ENCODED SMD----- 2025 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2026 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2027 ... (base64 data elided for brevity) ... 2028 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2029 -----END ENCODED SMD----- 2031 Figure 17 2033 6.5. Trademark Claims Notice (TCN) 2035 The TMDB MUST provide the TCN to Registrars in XML format as 2036 specified below. 2038 An enclosing element that describes the Trademark 2039 Notice to a given label. 2041 The child elements of the element include: 2043 o A element that contains the unique identifier of the 2044 Trademark Notice. This element contains the the TCNID. 2046 The TCNID is a string concatenation of a TCN Checksum and the 2047 TMDB Notice Identifier. The first 8 characters of the TCNID is 2048 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2049 is a zero-padded natural number in the range of 2050 0000000000000000001 to 9223372036854775807. 2052 Example of a TCNID: 2054 370d0b7c9223372036854775807. 2056 Where: 2058 + TCN Checksum=370d0b7c 2060 + TMDB Notice Identifier=9223372036854775807 2061 The TCN Checksum is a 8 characters long Base16 encoded output 2062 of computing the CRC32 of the string concatenation of: label + 2063 unix_timestamp() + TMDB Notice Identifier 2065 TMDB MUST use the Unix time conversion of the 2066 in UTC to calculate the TCN Checksum. Unix 2067 time is defined as the number of seconds that have elapsed 2068 since 1970-01-01T00:00:00Z not counting leap seconds. For 2069 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2070 is shown: 2072 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2074 The TMDB uses the and 2075 elements from the TCN along with the TMDB Notice Identifier to 2076 compute the TCN Checksum. 2078 A Registry MUST use the leftmost DNL of the DN being 2079 effectively allocated, the expiration datetime of the TCN 2080 (provided by the Registrar) and the TMDB Notice Identifier 2081 extracted from the TCNID (provided by the Registrar) to compute 2082 the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- 2083 mgbh0fb" is being effectively allocated, the leftmost DNL would 2084 be "xn--mgbachtv". 2086 Example of computation of the TCN Checksum: 2088 CRC32(example-one12819492009223372036854775807)=370d0b7c 2090 o A element that contains the start of the 2091 validity date and time of the TCN. 2093 o A element that contains the expiration date 2094 and time of the TCN. 2096 o A element that contains the DNL covered by a PRM. 2098 o One or more elements that contain the Trademark 2099 Claim. The element contains the following child 2100 elements: 2102 * A element that contains the mark text 2103 string. 2105 * One or more elements that contains the 2106 information of the holder of the mark. An "entitlement" 2107 attribute is used to identify the entitlement of the holder, 2108 possible values are: owner, assignee or licensee. The child 2109 elements of include: 2111 + An OPTIONAL element that contains the name 2112 of the holder. A MUST be specified if 2113 is not specified. 2115 + An OPTIONAL element that contains the name of 2116 the organization holder of the mark. A MUST 2117 be specified if is not specified. 2119 + A element that contains the address 2120 information of the holder of a mark. A 2121 contains the following child elements: 2123 - One, two or three OPTIONAL elements 2124 that contains the organization's street address. 2126 - A element that contains the 2127 organization's city. 2129 - An OPTIONAL element that contains the 2130 organization's state or province. 2132 - An OPTIONAL element that contains the 2133 organization's postal code. 2135 - A element that contains the organization's 2136 country code. This a two-character code from 2137 [ISO3166-2]. 2139 + An OPTIONAL element that contains the 2140 organization's voice telephone number. 2142 + An OPTIONAL element that contains the 2143 organization's facsimile telephone number. 2145 + An OPTIONAL element that contains the email 2146 address of the holder. 2148 * Zero or more OPTIONAL elements that contains 2149 the information of the representative of the mark registration. 2150 A "type" attribute is used to identify the type of contact, 2151 possible values are: owner, agent or thirdparty. The child 2152 elements of include: 2154 + A element that contains name of the 2155 responsible person. 2157 + An OPTIONAL element that contains the name of 2158 the organization of the contact. 2160 + A element that contains the address 2161 information of the contact. A contains the 2162 following child elements: 2164 - One, two or three OPTIONAL elements 2165 that contains the contact's street address. 2167 - A element that contains the contact's 2168 city. 2170 - An OPTIONAL element that contains the 2171 contact's state or province. 2173 - An OPTIONAL element that contains the 2174 contact's postal code. 2176 - A element that contains the contact's 2177 country code. This a two-character code from 2178 [ISO3166-2]. 2180 + A element that contains the contact's voice 2181 telephone number. 2183 + An OPTIONAL element that contains the 2184 contact's facsimile telephone number. 2186 + A element that contains the contact's email 2187 address. 2189 * A element that contains the name (in 2190 English) of the jurisdiction where the mark is protected. A 2191 jurCC attribute contains the two-character code of the 2192 jurisdiction where the mark was registered. This is a two- 2193 character code from [WIPO.ST3]. 2195 * Zero or more OPTIONAL element that 2196 contains the description (in English) of the Nice 2197 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2198 attribute contains the class number. 2200 * A element that contains the full 2201 description of the goods and services mentioned in the mark 2202 registration document. 2204 * An OPTIONAL element signals that the 2205 claim notice was added to the TCN based on other rule (e.g. 2206 [Claims50] ) than exact match (defined in [MatchingRules]). 2207 The contains one or more: 2209 + An OPTIONAL element that signals that the 2210 claim notice was added because of a previously abused name 2211 included in an UDRP case. The contains: 2213 - A element that contains the UDRP case 2214 number used to validate the previously abused name. 2216 - A element that contains the name 2217 of the UDRP provider. 2219 + An OPTIONAL element that signals that the 2220 claim notice was added because of a previously abused name 2221 included in a court's resolution. The 2222 contains: 2224 - A element that contains the reference 2225 number of the court's resolution used to validate the 2226 previously abused name. 2228 - A element that contains the two-character 2229 code from [ISO3166-2] of the jurisdiction of the court. 2231 - A element that contains the name of 2232 the court. 2234 Example of a object: 2236 2237 2238 370d0b7c9223372036854775807 2239 2010-08-14T09:00:00.0Z 2240 2010-08-16T09:00:00.0Z 2241 example-one 2242 2243 Example One 2244 2245 Example Inc. 2246 2247 123 Example Dr. 2248 Suite 100 2249 Reston 2250 VA 2251 20190 2252 US 2253 2254 2255 2256 Joe Doe 2257 Example Inc. 2258 2259 123 Example Dr. 2260 Suite 100 2261 Reston 2262 VA 2263 20190 2264 US 2265 2266 +1.7035555555 2267 jdoe@example.com 2268 2269 UNITED STATES OF AMERICA 2270 2271 Advertising; business management; business administration. 2272 2273 2274 Insurance; financial affairs; monetary affairs; real estate. 2275 2276 2277 Bardus populorum circumdabit se cum captiosus populum. 2278 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2279 2280 2281 2282 Example-One 2283 2284 Example S.A. de C.V. 2285 2286 Calle conocida #343 2287 Conocida 2288 SP 2289 82140 2290 BR 2291 2292 2293 BRAZIL 2294 2295 Bardus populorum circumdabit se cum captiosus populum. 2296 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2297 2298 2299 2300 One 2301 2302 One Corporation 2303 2304 Otra calle 2305 Otra ciudad 2306 OT 2307 383742 2308 CR 2309 2310 2311 COSTA RICA 2312 2313 Bardus populorum circumdabit se cum captiosus populum. 2314 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2315 2316 2317 2318 234235 2319 CR 2320 Supreme Court of Justice of Costa Rica 2321 2322 2323 2324 2325 One Inc 2326 2327 One SA de CV 2328 2329 La calle 2330 La ciudad 2331 CD 2332 34323 2333 AR 2334 2335 2336 ARGENTINA 2337 2338 Bardus populorum circumdabit se cum captiosus populum. 2339 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2340 2341 2342 2343 D2003-0499 2344 WIPO 2345 2346 2348 2349 2351 For the formal syntax of the TCN please refer to Section 7.1. 2353 6.6. Sunrise List (SURL) 2355 This section defines the format of the list containing every Domain 2356 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2357 is maintained by the TMDB and downloaded by Registries in regular 2358 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2359 during the Qualified Launch Program Period to check whether a 2360 requested DN matches a DNL of a PRM eligible for Sunrise. 2362 The Sunrise List contains all the DNLs covered by a PRM eligible for 2363 Sunrise present in the TMDB at the datetime it is generated. 2365 The Sunrise List is contained in a CSV formatted file that has the 2366 following structure: 2368 o first line: , 2370 Where: 2372 + , version of the file, this field MUST be 1. 2374 + , date and time in UTC that 2375 the Sunrise List was created. 2377 o second line: a header line as specified in [RFC4180] 2379 With the header names as follows: 2381 DNL,insertion-datetime 2383 o One or more lines with: , 2385 Where: 2387 + , a Domain Name Label covered by a PRM eligible for 2388 Sunrise. 2390 + , datetime in UTC that the DNL was 2391 first inserted into the Sunrise List. The possible two 2392 values of time for inserting a DNL to the Sunrise List are 2393 00:00:00 and 12:00:00 UTC. 2395 Example of a SURL 2397 1,2012-08-16T00:00:00.0Z 2398 DNL,insertion-datetime 2399 example,2010-07-14T00:00:00.0Z 2400 another-example,2012-08-16T00:00:00.0Z 2401 anotherexample,2011-08-16T12:00:00.0Z 2403 Figure 18 2405 To provide authentication and integrity protection, the Sunrise List 2406 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2407 signature of the Sunrise List can be found in the similar URI but 2408 with extension .sig as shown below. 2410 The URL of the dy interface (Section 4.3.3) is: 2412 o < https:///dnl/surl-latest.csv > 2414 o < https:///dnl/surl-latest.sig > 2416 7. Formal Syntax 2418 7.1. Trademark Claims Notice (TCN) 2420 The schema presented here is for a Trademark Claims Notice. 2422 The BEGIN and END tags are not part of the schema; they are used to 2423 note the beginning and ending of the schema for URI registration 2424 purposes. 2426 BEGIN 2427 2428 2433 2434 2435 Schema for representing a Trademark Claim Notice. 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2459 2460 2461 2462 2463 2464 2466 2468 2469 2471 2472 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2538 2539 END 2541 8. Acknowledgements 2543 This specification is a collaborative effort from several 2544 participants in the ICANN community. Bernie Hoeneisen participated 2545 as co-author until version 02 providing invaluable support for this 2546 document. This specification is based on a model spearheaded by: 2547 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2548 would also like to thank the thoughtful feedbak provided by many in 2549 the tmch-tech mailing list, but particularly the extensive help 2550 provided by James Gould, James Mitchell and Francisco Arias. This 2551 document includes feedback received from the following individuals: 2552 Paul Hoffman. 2554 9. Change History 2556 [[RFC Editor: Please remove this section.]] 2558 9.1. Version 04 2560 1. Ping update. 2562 9.2. Version 05 2564 1. Ping update. 2566 9.3. Version 06 2568 1. Updated the terminology text to reflect the text in RFC8174. 2570 2. Updated the reference of RFC7719 to RFC8499. 2572 3. Updated the matching rules document reference to link to the 2573 latest version. 2575 9.4. Version 07 2577 1. Changes based on the feedback provided here: 2578 https://mailarchive.ietf.org/arch/msg/regext/ 2579 xcZPOAajlUJzgPgZBuqlIWRcFZg/ 2581 2. Changes based on the feedback provided here: 2582 https://mailarchive.ietf.org/arch/msg/regext/ 2583 MdOhSomd6_djLcthfw5mxWZkbWY 2585 10. IANA Considerations 2587 This document uses URNs to describe XML namespaces and XML schemas 2588 conforming to a registry mechanism described in [RFC3688]. Two URI 2589 assignments have been registered by the IANA. 2591 Registration request for the Trademark Claims Notice namespace: 2593 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2595 Registrant Contact: IETF 2597 XML: None. Namespace URIs do not represent an XML specification. 2599 Registration request for the Trademark Claims Notice XML schema: 2601 URI: urn:ietf:params:xml:schema:tmNotice-1.0 2603 Registrant Contact: IETF 2605 XML: See Section 7.1 of this document. 2607 11. Security Considerations 2609 This specification uses HTTP Basic Authentication to provide a simple 2610 application-layer authentication service. HTTPS is used in all 2611 interfaces in order to protect against most common attacks. In 2612 addition, the client identifier is tied to a set of IP addresses that 2613 are allowed to connect to the interfaces described in this document, 2614 providing an extra security measure. 2616 The TMDB MUST provide credentials to the appropriate Registries and 2617 Registrars. 2619 The TMDB MUST require the use of strong passwords by Registries and 2620 Registrars. 2622 The TMDB, Registries and Registrars MUST use the best practices 2623 described in RFC 7525 or its successors. 2625 12. References 2627 12.1. Normative References 2629 [Claims50] 2630 ICANN, "Implementation Notes: Trademark Claims Protection 2631 for Previously Abused Names", July 2013, 2632 . 2635 [MatchingRules] 2636 ICANN, "Memorandum on Implementing Matching Rules", July 2637 2016, . 2640 [QLP-Addendum] 2641 ICANN, "Qualified Launch Program Addendum", April 2014, 2642 . 2646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2647 Requirement Levels", BCP 14, RFC 2119, 2648 DOI 10.17487/RFC2119, March 1997, 2649 . 2651 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2652 DOI 10.17487/RFC3688, January 2004, 2653 . 2655 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2656 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2657 . 2659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2661 May 2017, . 2663 [RPM-Requirements] 2664 ICANN, "Rights Protection Mechanism Requirements", 2665 September 2013, . 2668 [W3C.REC-xml-20081126] 2669 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 2670 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 2671 Edition) REC-xml-20081126", November 2008, 2672 . 2674 [W3C.REC-xmlschema-1-20041028] 2675 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 2676 "XML Schema Part 1: Structures Second Edition REC- 2677 xmlschema-1-20041028", October 2004, 2678 . 2680 [W3C.REC-xmlschema-2-20041028] 2681 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2682 Second Edition REC-xmlschema-2-20041028", October 2004, 2683 . 2685 12.2. Informative References 2687 [ICANN-GTLD-AGB-20120604] 2688 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2689 2012, . 2692 [ISO3166-2] 2693 ISO, "International Standard for country codes and codes 2694 for their subdivisions", 2006, 2695 . 2697 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2698 DOI 10.17487/RFC2818, May 2000, 2699 . 2701 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2702 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2703 . 2705 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2706 Separated Values (CSV) Files", RFC 4180, 2707 DOI 10.17487/RFC4180, October 2005, 2708 . 2710 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2711 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2712 . 2714 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2715 Thayer, "OpenPGP Message Format", RFC 4880, 2716 DOI 10.17487/RFC4880, November 2007, 2717 . 2719 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2720 Housley, R., and W. Polk, "Internet X.509 Public Key 2721 Infrastructure Certificate and Certificate Revocation List 2722 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2723 . 2725 [RFC5890] Klensin, J., "Internationalized Domain Names for 2726 Applications (IDNA): Definitions and Document Framework", 2727 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2728 . 2730 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2731 Protocol (HTTP/1.1): Message Syntax and Routing", 2732 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2733 . 2735 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2736 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2737 DOI 10.17487/RFC7231, June 2014, 2738 . 2740 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2741 Protocol (HTTP/1.1): Authentication", RFC 7235, 2742 DOI 10.17487/RFC7235, June 2014, 2743 . 2745 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2746 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2747 January 2019, . 2749 [WIPO-NICE-CLASSES] 2750 WIPO, "WIPO Nice Classification", 2015, 2751 . 2753 [WIPO.ST3] 2754 WIPO, "Recommended standard on two-letter codes for the 2755 representation of states, other entities and 2756 intergovernmental organizations", March 2007, 2757 . 2759 Author's Address 2760 Gustavo Lozano 2761 ICANN 2762 12025 Waterfront Drive, Suite 300 2763 Los Angeles 90292 2764 US 2766 Phone: +1.3103015800 2767 Email: gustavo.lozano@icann.org