idnits 2.17.1 draft-ietf-regext-tmch-func-spec-03.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 (July 18, 2017) is 2466 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1374, 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 7719 (Obsoleted by RFC 8499) 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 July 18, 2017 5 Expires: January 19, 2018 7 ICANN TMCH functional specifications 8 draft-ietf-regext-tmch-func-spec-03 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 http://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 January 19, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 (http://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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 123 10. Security Considerations . . . . . . . . . . . . . . . . . . . 59 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 125 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 126 11.2. Informative References . . . . . . . . . . . . . . . . . 60 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61 129 1. Introduction 131 Domain Name Registries (DNRs) may operate in special modes for 132 certain periods of time enabling trademark holders to protect their 133 rights during the introduction of a Top Level Domain (TLD). 135 Along with the introduction of new generic TLDs (gTLD), two special 136 modes came into effect: 138 o Sunrise Period, the Sunrise Period allows trademark holders an 139 advance opportunity to register domain names corresponding to 140 their marks before names are generally available to the public. 142 o Trademark Claims Period, the Trademark Claims Period follows the 143 Sunrise Period and runs for at least the first 90 days of an 144 initial operating period of general registration. During the 145 Trademark Claims Period, anyone attempting to register a domain 146 name matching a mark that is recorded in the ICANN Trademark 147 Clearinghouse (TMCH) will receive a notification displaying the 148 relevant mark information. 150 This document describes the requirements, the architecture and the 151 interfaces between the ICANN TMCH and Domain Name Registries (called 152 Registries in the rest of the document) as well as between the ICANN 153 TMCH and Domain Name Registrars (called Registrars in the rest of the 154 document) for the provisioning and management of domain names during 155 the Sunrise and Trademark Claims Periods. 157 For any date and/or time indications, Coordinated Universal Time 158 (UTC) applies. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 XML is case sensitive. Unless stated otherwise, XML specifications 167 and examples provided in this document MUST be interpreted in the 168 character case presented in order to develop a conforming 169 implementation. 171 "tmNotice-1.0" is used as an abbreviation for 172 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 173 "tmNotice" is used, but implementations MUST NOT depend on it and 174 instead employ a proper namespace-aware XML parser and serializer to 175 interpret and output the XML documents. 177 3. Glossary 179 In the following section, the most common terms are briefly 180 explained: 182 o Backend Registry Operator: Entity that manages (a part of) the 183 technical infrastructure for a Registry Operator. The Registry 184 Operator may also be the Backend Registry Operator. 186 o CA: Certificate Authority, see [RFC5280]. 188 o CNIS, Claims Notice Information Service: This service provides 189 Trademark Claims Notices (TCN) to Registrars. 191 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 192 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 194 o CRL: Certificate Revocation List, see [RFC5280]. 196 o CSV: Comma-Separated Values, see [RFC4180] 198 o Date and time, datetime: Date and time are specified following the 199 standard "Date and Time on the Internet specification", see 200 [RFC3339]. 202 o DN, Domain Name, domain name: see definition of Domain name in 203 [RFC7719]. 205 o DNROID, DN Repository Object IDentifier: an identifier assigned by 206 the Registry to each DN object that unequivocally identifies said 207 DN object. For example, if a new DN object is created for a name 208 that existed in the past, the DN objects will have different 209 DNROIDs. 211 o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see 212 [RFC5890]). 214 o DNL List: A list of DNLs that are covered by a PRM. 216 o DNS: Domain Name System, see [RFC7719]. 218 o Effective allocation: A DN is considered effectively allocated 219 when the DN object for the DN has been created in the SRS of the 220 Registry and has been assigned to the effective user. A DN object 221 in status "pendingCreate" or any other status that precedes the 222 first time a DN is assigned to an end-user is not considered an 223 effective allocation. A DN object created internally by the 224 Registry for subsequent delegation to another Registrant is not 225 considered an effective allocation. 227 o EPP: The Extensible Provisioning Protocol, see definition of EPP 228 in [RFC7719]. 230 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 231 [RFC7719]. 233 o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. 235 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 237 o IDN: Internationalized Domain Name, see definition of IDN in 238 [RFC7719]. 240 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 241 Z0-9/] to be used as the lookup key by Registrars to obtain the 242 TCN using the CNIS. Lookup Keys are unique and are related to one 243 DNL only. 245 o LORDN, List of Registered Domain Names: This is the list of 246 effectively allocated DNs matching a DNL of a PRM. Registries 247 will upload this list to the TMDB (during the NORDN process). 249 o Matching Rules: Some trademarks entitled to inclusion in the TMDB 250 include characters that are impermissible in the domain name 251 system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH 252 Matching Rules [MatchingRules]) certain DNS-impermissible 253 characters in a trademark into DNS-permissible equivalent 254 characters 256 o NORDN, Notification of Registered Domain Names: The process by 257 which Registries upload their recent LORDN to the TMDB. 259 o PGP: Pretty Good Privacy, see [RFC4880] 261 o PKI: Public Key Infrastructure, see [RFC5280]. 263 o PRM, Pre-registered mark: Mark that has been pre-registered with 264 the ICANN TMCH. 266 o QLP Period, Qualified Launch Program Period: During this optional 267 period, a special process applies to DNs matching the Sunrise List 268 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 269 DN matching their PRM. 271 o Registrant: see definition of Registrant in [RFC7719]. 273 o Registrar, Domain Name Registrar: see definition of Registrar in 274 [RFC7719]. 276 o Registry, Domain Name Registry, Registry Operator: see definition 277 of Registry in [RFC7719]. A Registry Operator is the contracting 278 party with ICANN for the TLD. 280 o SMD, Signed Mark Data: A cryptographically signed token issued by 281 the TMV to the TMH to be used in the Sunrise Period to apply for a 282 DN that matches a DNL of a PRM; see also [RFC7848]. An SMD 283 generated by an ICANN-approved trademark validator (TMV) contains 284 both the signed token and the TMV's PKIX certificate. 286 o SMD File: A file containing the SMD (see above) and some human 287 readable data. The latter is usually ignored in the processing of 288 the SMD File. See also Section 6.4. 290 o SMD Revocation List: The SMD Revocation List is used by Registries 291 (and optionally by Registrars) during the Sunrise Period to ensure 292 that an SMD is still valid (i.e. not revoked). The SMD Revocation 293 List has a similar function as CRLs used in PKI. 295 o SRS: Shared Registration System, see also 296 [ICANN-GTLD-AGB-20120604]. 298 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 299 eligible for Sunrise. 301 o Sunrise Period: During this period DNs matching a DNL of a PRM can 302 be exclusively obtained by the respective TMHs. For DNs matching 303 a PRM, a special process applies to ensure that TMHs are informed 304 on the effective allocation of a DN matching their PRM. 306 o TLD: Top-Level Domain Name, see definition of TLD in [RFC7719]. 308 o ICANN TMCH: a central repository for information to be 309 authenticated, stored, and disseminated, pertaining to the rights 310 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 311 (see below). There could be several entities performing the TMV 312 function, but only one entity performing the TMDB function. 314 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 315 This CA is operated by ICANN. The public key for this CA is the 316 trust anchor used to validate the identity of each TMV. 318 o TMDB, Trademark Clearinghouse Database: Serves as a database of 319 the ICANN TMCH to provide information to the gTLD Registries and 320 Registrars to support Sunrise or Trademark Claims services. There 321 is only one TMDB in the ICANN TMCH that concentrates the 322 information about the "verified" Trademark records from the TMVs. 324 o TMH, Trademark Holder: The person or organization owning rights on 325 a mark. 327 o TMV, Trademark Validator, Trademark validation organization: An 328 entity authorized by ICANN to authenticate and validate 329 registrations in the TMDB ensuring the marks qualify as registered 330 or are court-validated marks or marks that are protected by 331 statute or treaty. This entity would also be asked to ensure that 332 proof of use of marks is provided, which can be demonstrated by 333 furnishing a signed declaration and one specimen of current use. 335 o Trademark, mark: Marks are used to claim exclusive properties of 336 products or services. A mark is typically a name, word, phrase, 337 logo, symbol, design, image, or a combination of these elements. 338 For the scope of this document only textual marks are relevant. 340 o Trademark Claims, Claims: Provides information to enhance the 341 understanding of the Trademark rights being claimed by the TMH. 343 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 344 Trademark Claims Notice consist of one or more Trademark Claims 345 and are provided to prospective Registrants of DNs. 347 o TCNID, Trademark Claims Notice Identifier: An element of the 348 Trademark Claims Notice (see above), identifying said TCN. The 349 Trademark Claims Notice Identifier is specified in the element 350 . 352 o Trademark Claims Period: During this period, a special process 353 applies to DNs matching the DNL List, to ensure that TMHs are 354 informed of a DN matching their PRM. For DNs matching the DNL 355 List, Registrars show a TCN to prospective Registrants that has to 356 be acknowledged before effective allocation of the DN. 358 o UTC: Coordinated Universal Time, as maintained by the Bureau 359 International des Poids et Mesures (BIPM); see also [RFC3339]. 361 4. Architecture 363 4.1. Sunrise Period 365 Architecture of the Sunrise Period 367 SMD hand over (out-of-band) 368 .............................................. 369 : : 370 : .'''''''''''''''''''. : 371 : . ICANN TMCH . : 372 : ..................... : 373 v . . : 374 .------------. . .-------------. . hv .-----. 375 | Registrant | . | TMV |<---------->| TMH | 376 '------------' . '-------------' . vh '-----' 377 | . | ^ \ . 378 | . | | \. 379 tr | . vs | | dv \ 380 | . | vd | .\ 381 v . v v . \ 382 .-----------. sr . .---------. . \ 383 .->| Registrar |<..........| | . \ 384 : '-----------' . | | . \ 385 : | sy . | T | . \ 386 : ry | .------------| M | . vc \ 387 : | | . | D | . \ 388 : v v . | B | . v 389 : .-----------. . yd | | . .---------------. 390 : | Registry |---------->| | . | ICANN TMCH-CA | 391 : '-----------' . '---------' . '---------------' 392 : ^ . . | : 393 : | ''''''''''''''''''' | : 394 : | cy | : 395 : cr '-----------------------------------------' : 396 :......................................................: 398 Figure 1 400 4.2. Trademark Claims Period 402 Architecture of the Trademark Claims Period 404 .''''''''''''''. 405 . ICANN TMCH . 406 ................ 407 . . 408 .------------. . .-------. . hv .-----. 409 | Registrant | . | TMV |<----------->| TMH | 410 '------------' . '-------' . vh '-----' 411 | . ^ . 412 | . | dv . 413 tr | . vd | . 414 v . v . 415 .-----------. dr . .-------. . 416 | Registrar |<--------| | . 417 '-----------' . | T | . 418 ry | . | M | . 419 v . | D | . 420 .----------. dy . | B | . 421 | Registry |<------->| | . 422 '----------' yd . '-------' . 423 . . 424 '''''''''''''' 426 Figure 2 428 4.3. Interfaces 430 In the sub-sections below follows a short description of each 431 interface to provide an overview of the architecture. More detailed 432 descriptions of the relevant interfaces follow further below 433 (Section 5). 435 4.3.1. hv 437 The TMH registers a mark with a TMV via the hv interface. 439 After the successful registration of the mark, the TMV makes 440 available a SMD File (see also Section 6.4) to the TMH to be used 441 during the Sunrise Period. 443 The specifics of the hv interface are beyond the scope of this 444 document. 446 4.3.2. vd 448 After successful mark registration, the TMV ensures the TMDB inserts 449 the corresponding DNLs and mark information into the database via the 450 vd interface. 452 The specifics of the vd interface are beyond the scope of this 453 document. 455 4.3.3. dy 457 During the Trademark Claims Period the Registry fetches the latest 458 DNL List from the TMDB via the dy interface at regular intervals. 459 The protocol used on the dy interface is HTTPS. 461 Not relevant during the Sunrise Period. 463 4.3.4. tr 465 The Registrant communicates with the Registrar via the tr interface. 467 The specifics of the tr interface are beyond the scope of this 468 document. 470 4.3.5. ry 472 The Registrar communicate with the Registry via the ry interface. 473 The ry interfaces is typically implemented in EPP. 475 4.3.6. dr 477 During the Trademark Claims Period, the Registrar fetches the TCN 478 from the TMDB (to be displayed to the Registrant via the tr 479 interface) via the dr interface. The protocol used for fetching the 480 TCN is HTTPS. 482 Not relevant during the Sunrise Period. 484 4.3.7. yd 486 During the Sunrise Period the Registry notifies the TMDB via the yd 487 interface of all DNs effectively allocated. 489 During the Trademark Claims Period, the Registry notifies the TMDB 490 via the yd interface of all DNs effectively allocated that matched an 491 entry in the Registry previously downloaded DNL List during the 492 creation of the DN. 494 The protocol used on the yd interface is HTTPS. 496 4.3.8. dv 498 The TMDB notifies via the dv interface to the TMV of all DNs 499 effectively allocated that match a mark registered by that TMV. 501 The specifics of the dv interface are beyond the scope of this 502 document. 504 4.3.9. vh 506 The TMV notifies the TMH via the vh interface after a DN has been 507 effectively allocated that matches a PRM of this TMH. 509 The specifics of the vh interface are beyond the scope of this 510 document. 512 4.3.10. vs 514 The TMV requests to add a revoked SMD to the SMD Revocation List at 515 the TMDB. 517 The specifics of the vs interface are beyond the scope of this 518 document. 520 Not relevant during the Trademark Claims Period. 522 4.3.11. sy 524 During the Sunrise Period the Registry fetches the most recent SMD 525 Revocation List from the TMDB via the sy interface in regular 526 intervals. The protocol used on the sy interface is HTTPS. 528 Not relevant during the Trademark Claims Period. 530 4.3.12. sr 532 During the Sunrise Period the Registrar may fetch the most recent SMD 533 Revocation List from the TMDB via the sr interface. The protocol 534 used on the sr interface is the same as on the sy interface (s. 535 above), i.e. HTTPS. 537 Not relevant during the Trademark Claims Period. 539 4.3.13. vc 541 The TMV registers its public key, and requests to revoke an existing 542 key, with the ICANN TMCH-CA over the vc interface. 544 The specifics of the vc interface are beyond the scope of this 545 document, but it involves personal communication between the 546 operators of the TMV and the operators of the ICANN TMCH-CA. 548 Not relevant during the Trademark Claims Period. 550 4.3.14. cy 552 During the Sunrise Period the Registry fetches the most recent TMV 553 CRL file from the ICANN TMCH-CA via the cy interface at regular 554 intervals. The TMV CRL is used for validation of TMV certificates. 555 The protocol used on the cy interface is HTTPS. 557 Not relevant during the Trademark Claims Period. 559 4.3.15. cr 561 During the Sunrise Period the Registrar optionally fetches the most 562 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 563 regular intervals. The TMV CRL is used for validation of TMV 564 certificates. The protocol used on the cr interface is HTTPS. 566 Not relevant during the Trademark Claims Period. 568 5. Process Descriptions 570 5.1. Bootstrapping 572 5.1.1. Bootstrapping for Registries 574 5.1.1.1. Credentials 576 Each Registry Operator will receive authentication credentials from 577 the TMDB to be used: 579 o During the Sunrise Period to fetch the SMD Revocation List from 580 the TMBD via the sy interface (Section 4.3.11). 582 o During the Trademark Claims Period to fetch the DNL List from the 583 TMDB via the dy interface (Section 4.3.3). 585 o During the NORDN process to notify the LORDN to the TMDB via the 586 yd interface (Section 4.3.7). 588 Note: credentials are created per TLD and provided to the Registry 589 Operator. 591 5.1.1.2. IP Addresses for Access Control 593 Each Registry Operator MUST provide to the TMDB all IP addresses that 594 will be used to: 596 o Fetch the SMD Revocation List via the sy interface 597 (Section 4.3.11). 599 o Fetch the DNL List from the TMDB via the dy interface 600 (Section 4.3.3). 602 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 604 This access restriction MAY be applied by the TMDB in addition to 605 HTTP Basic access authentication (see [RFC7235]). For credentials to 606 be used, see Section 5.1.1.1. 608 The TMDB MAY limit the number of IP addresses to be accepted per 609 Registry Operator. 611 5.1.1.3. ICANN TMCH Trust Anchor 613 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 614 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 615 tmch.crt > to be used: 617 o During the Sunrise Period to validate the TMV certificates and the 618 TMV CRL. 620 5.1.1.4. TMDB PGP Key 622 The TMDB MUST provide each Registry Operator with the public portion 623 of the PGP Key used by TMDB, to be used: 625 o During the Sunrise Period to perform integrity checking of the SMD 626 Revocation List fetched from the TMDB via the sy interface 627 (Section 4.3.11). 629 o During the Trademark Claims Period to perform integrity checking 630 of the DNL List fetched from the TMDB via the dy interface 631 (Section 4.3.3). 633 5.1.2. Bootstrapping for Registrars 635 5.1.2.1. Credentials 637 Each ICANN-accredited Registrar will receive authentication 638 credentials from the TMDB to be used: 640 o During the Sunrise Period to (optionally) fetch the SMD Revocation 641 List from the TMDB via the sr interface (Section 4.3.12). 643 o During the Trademark Claims Period to fetch TCNs from the TMDB via 644 the dr interface (Section 4.3.6). 646 5.1.2.2. IP Addresses for Access Control 648 Each Registrar MUST provide to the TMDB all IP addresses, which will 649 be used to: 651 o Fetch the SMD Revocation List via the sr interface 652 (Section 4.3.12). 654 o Fetch TCNs via the dr interface (Section 4.3.6). 656 This access restriction MAY be applied by the TMDB in addition to 657 HTTP Basic access authentication (for credentials to be used, see 658 Section 5.1.2.1). 660 The TMDB MAY limit the number of IP addresses to be accepted per 661 Registrar. 663 5.1.2.3. ICANN TMCH Trust Anchor 665 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 666 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 668 o During the Sunrise Period to (optionally) validate the TMV 669 certificates and TMV CRL. 671 5.1.2.4. TMDB PGP Key 673 Registrars MUST receive the public portion of the PGP Key used by 674 TMDB from the TMDB administrator to be used: 676 o During the Sunrise Period to (optionally) perform integrity 677 checking of the SMD Revocation List fetched from the TMDB via the 678 sr interface (Section 4.3.12). 680 5.2. Sunrise Period 682 5.2.1. Domain Name registration 684 Domain Name registration during the Sunrise Period 686 .------------. .-----------. .----------. 687 | Registrant | | Registrar | | Registry | 688 '------------' '-----------' '----------' 689 | | | 690 | Request DN | | 691 | registration | | 692 | (with SMD) | | 693 |---------------->| Check DN availability | 694 | |---------------------------->| 695 | | | 696 | | DN unavailable .-------------. 697 | DN unavailable |<--------------------( DN available? ) 698 |<----------------| no '-------------' 699 | | | yes 700 | | DN available | 701 | |<----------------------------| 702 | | | 703 | | Request DN registration | 704 | | (with SMD) | 705 | |---------------------------->| 706 | | | 707 | | .------------------------------. 708 | | | DN registration validation / | 709 | | | SMD validation | 710 | | '------------------------------' 711 | | | 712 | Registration |.-----------. Error .----------------------. 713 | error || TRY AGAIN |<-----( Validation successful? ) 714 |<----------------|| / ABORT | no '----------------------' 715 | |'-----------' | yes 716 | | | 717 | | DN registered | 718 | DN registered |<----------------------------| 719 |<----------------| | 720 | | | 722 Figure 3 724 Note: the figure depicted above represents a synchronous DN 725 registration workflow (usually called first come first served). 727 5.2.2. Sunrise Domain Name registration by Registries 729 Registries MUST perform a minimum set of checks for verifying each DN 730 registration during the Sunrise Period upon reception of a 731 registration request over the ry interface (Section 4.3.5). If any 732 of these checks fails the Registry MUST abort the registration. Each 733 of these checks MUST be performed before the DN is effectively 734 allocated. 736 In case of asynchronous registrations (e.g. auctions), the minimum 737 set of checks MAY be performed when creating the intermediate object 738 (e.g. a DN application) used for DN registration. If the minimum set 739 of checks is performed when creating the intermediate object (e.g. a 740 DN application) a Registry MAY effective allocate the DN without 741 performing the minimum set of checks again. 743 Performing the minimum set of checks Registries MUST verify that: 745 1. An SMD has been received from the Registrar along with the DN 746 registration. 748 2. The certificate of the TMV has been correctly signed by the ICANN 749 TMCH-CA. (The certificate of the TMV is contained within the 750 SMD.) 752 3. The datetime when the validation is done is within the validity 753 period of the TMV certificate. 755 4. The certificate of the TMV is not listed in the TMV CRL file 756 specified in the CRL distribution point of the TMV certificate. 758 5. The signature of the SMD (signed with the TMV certificate) is 759 valid. 761 6. The datetime when the validation is done is within the validity 762 period of the SMD based on and 763 elements. 765 7. The SMD has not been revoked, i.e., is not contained in the SMD 766 Revocation List. 768 8. The leftmost DNL of the DN being effectively allocated matches 769 one of the labels () elements in the SMD. For 770 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 771 effectively allocated, the leftmost DNL would be "xn--mgbachtv". 773 These procedure apply to all DN effective allocations at the second 774 level as well as to all other levels subordinate to the TLD that the 775 Registry accepts registrations for. 777 5.2.3. TMDB Sunrise Services for Registries 779 5.2.3.1. SMD Revocation List 781 A new SMD Revocation List MUST be published by the TMDB twice a day, 782 by 00:00:00 and 12:00:00 UTC. 784 Registries MUST refresh the latest version of the SMD Revocation List 785 at least once every 24 hours. 787 Note: the SMD Revocation List will be the same regardless of the TLD. 788 If a Backend Registry Operator manages the infrastructure of several 789 TLDs, the Backend Registry Operator could refresh the SMD Revocation 790 List once every 24 hours, the SMD Revocation List could be used for 791 all the TLDs managed by the Backend Registry Operator. 793 Update of the SMD Revocation List 795 .----------. .------. 796 | Registry | | TMDB | 797 '----------' '------' 798 | | 799 .----------------. | 800 | Periodically, | | 801 | at least | | 802 | every 24 hours | | 803 '----------------' | 804 | | 805 |----------------------------------------------------->| 806 | Download the latest SMD Revocation List | 807 |<-----------------------------------------------------| 808 | | 809 | | 811 Figure 4 813 5.2.3.2. TMV Certificate Revocation List (CRL) 815 Registries MUST refresh their local copy of the TMV CRL file at least 816 every 24 hours using the CRL distribution point specified in the TMV 817 certificate. 819 Operationally, the TMV CRL file and CRL distribution point is the 820 same for all TMVs and (at publication of this document) located at < 821 http://crl.icann.org/tmch.crl >. 823 Note: the TMV CRL file will be the same regardless of the TLD. If a 824 Backend Registry Operator manages the infrastructure of several TLDs, 825 the Backend Registry Operator could refresh the TMV CRL file once 826 every 24 hours, the TMV CRL file could be used for all the TLDs 827 managed by the Backend Registry Operator. 829 Update of the TMV CRL file 831 .----------. .---------------. 832 | Registry | | ICANN TMCH-CA | 833 '----------' '---------------' 834 | | 835 .----------------. | 836 | Periodically, | | 837 | at least | | 838 | every 24 hours | | 839 '----------------' | 840 | | 841 |-------------------------------------------->| 842 | Download the latest TMV CRL file | 843 |<--------------------------------------------| 844 | | 845 | | 847 Figure 5 849 5.2.3.3. Notice of Registered Domain Names (NORN) 851 The Registry MUST send a LORDN file containing DNs effectively 852 allocated to the TMDB (over the yd interface, Section 4.3.7). 854 The effective allocation of a DN MUST be reported by the Registry to 855 the TMDB within 26 hours of the effective allocation of such DN. 857 The Registry MUST create and upload a LORDN file in case there are 858 effective allocations in the SRS, that have not been successfully 859 reported to the TMDB in a previous LORDN file. 861 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 862 maximum frequency to upload LORDN files from the Registries to the 863 TMDB is every 3 hours. 865 It is RECOMMENDED that Registries try to upload at least two LORDN 866 files per day to the TMDB with enough time in between, in order to 867 have time to fix problems reported in the LORDN file. 869 The Registry SHOULD upload a LORDN file only when the previous LORDN 870 file has been processed by the TMDB and the related LORDN Log file 871 has been downloaded and processed by the Registry. 873 The Registry MUST upload LORDN files for DNs effectively allocated 874 during the Sunrise or Trademark Claims Period (same applies to DNs 875 effectively allocated using applications created during the Sunrise 876 or Trademark Claims Period in case of using asynchronous 877 registrations). 879 The yd interface (Section 4.3.7) MUST support at least one (1) and 880 MAY support up to ten (10) concurrent connections from each IP 881 address registered by a Registry Operator to access the service. 883 The TMDB MUST process each uploaded LORDN file and make the related 884 log file available for Registry download within 30 minutes of the 885 finalization of the upload. 887 Notification of Registered Domain Name 889 .----------. .------. .-----. .-----. 890 | Registry | | TMDB | | TMV | | TMH | 891 '----------' '------' '-----' '-----' 892 | | | | 893 .------------------. | | | 894 | Periodically | | | | 895 | upload LORDN | | | | 896 | file | | | | 897 '------------------' | | | 898 | | | | 899 .--------->| Upload LORDN | | | 900 | |-------------------->| | | 901 | | | | | 902 | | .-------------------------. | | 903 | | | Verify each domain name | | | 904 | | | in the uploaded file | | | 905 | | | (within 30') | | | 906 | | '-------------------------' | | 907 | | | ._____.| | 908 | | Download Log file | | END || | 909 | |<--------------------| '-----'| | 910 | | | ^ | | 911 | .-----------------. .---------------. | | | 912 | | Check whether | / everything fine \ no | | | 913 | | Log file | ( (i.e. no errors )---' | | 914 | | contains errors | \ in Log file )? / | | 915 | '-----------------' '---------------' | | 916 | | | yes | | 917 | .---------------. | | | 918 | / everything fine \ yes | | | 919 |( (i.e. no errors )-----. | Notify TMVs | | 920 | \ in Log file )? / | | on the LORDN | | 921 | '---------------' | | pre-registered | | 922 | | no v | with said TMV | | 923 | .----------------. .------. |--------------->| | 924 '-| Correct Errors | | DONE | | | | 925 '----------------' '------' | | Notify each | 926 | | | affected TMH | 927 | | |-------------->| 928 | | | | 930 Figure 6 932 The format used for the LORDN is described in Section 6.3 934 5.2.4. Sunrise Domain Name registration by Registrars 936 Registrars MAY choose to perform the checks for verifying DN 937 registrations as performed by the Registries (see Section 5.2.2) 938 before sending the command to register a DN. 940 5.2.5. TMDB Sunrise Services for Registrars 942 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 943 also available for Registrars to optionally validate the SMDs 944 received. 946 5.3. Trademark Claims Period 948 5.3.1. Domain Registration 950 Domain Name registration during the Trademark Claims Period 952 .------------. .-----------. .----------. .------. 953 | Registrant | | Registrar | | Registry | | TMDB | 954 '------------' '-----------' '----------' '------' 955 | Request DN | | | 956 | registration | | | 957 |--------------->| Check DN availability | | 958 | |--------------------------->| | 959 | | DN unavailable .-------------. | 960 | DN unavailable |<-------------------( DN available? ) | 961 |<---------------| no '-------------' | 962 | | DN available | yes | 963 | |<---------------------------| | 964 | | Request Lookup key | | 965 | |--------------------------->| | 966 | |.__________. .---------. | 967 | || CONTINUE | / Does DN \ | 968 | || NORMALLY |<--------( match DNL ) | 969 | |'----------' no \ of PRM? / | 970 | | '---------' | 971 | | Lookup key | yes | 972 | |<----------------------------' | 973 | | | 974 .-----. | | Request TCN | 975 |ABORT| | Display |---------------------------------------->| 976 '-----' | Claims | Return TCN | 977 ^ | Notice |<----------------------------------------| 978 | no |<---------------| | 979 | .------. yes | | 980 '-( Ack? )----------->| Register DN (with TCNID) | | 981 '------' |--------------------------->| | 982 | Registration | Error .----------------------. | 983 | error |<-------------( Validation successful? ) | 984 |<---------------| no '----------------------' | 985 | | | yes | 986 | | DN registered | | 987 | DN registered |<---------------------------| | 988 |<---------------| | | 990 Figure 7 992 Note: the figure depicted above represents a synchronous DN 993 registration workflow (usually called first come first served). 995 5.3.2. Trademark Claims Domain Name registration by Registries 997 During the Trademark Claims Period, Registries perform two main 998 functions: 1000 o Registries MUST provide Registrars (over the ry interface, 1001 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1002 that match the DNL List. 1004 o Registries MUST provide the Lookup Key only when queried about a 1005 specific DN. 1007 o For each DN matching a DNL of a PRM, Registries MUST perform a 1008 minimum set of checks for verifying DN registrations during the 1009 Trademark Claims Period upon reception of a registration request 1010 over the ry interface (Section 4.3.5). If any of these checks 1011 fails the Registry MUST abort the registration. Each of these 1012 checks MUST be performed before the DN is effectively allocated. 1014 o In case of asynchronous registrations (e.g. auctions), the minimum 1015 set of checks MAY be performed when creating the intermediate 1016 object (e.g. a DN application) used for DN effective allocation. 1017 If the minimum set of checks is performed when creating the 1018 intermediate object (e.g. a DN application) a Registry MAY 1019 effective allocate the DN without performing the minimum set of 1020 checks again. 1022 o Performing the minimum set of checks Registries MUST verify that: 1024 1. The TCNID (), expiration datetime 1025 () and acceptance datetime of the TCN, have 1026 been received from the Registrar along with the DN 1027 registration. 1029 If the three elements mentioned above are not provided by 1030 the Registrar for a DN matching a DNL of a PRM, but the DNL 1031 was inserted (or re-inserted) for the first time into DNL 1032 List less than 24 hours ago, the registration MAY continue 1033 without this data and the tests listed below are not 1034 required to be performed. 1036 2. The TCN has not expired (according to the expiration datetime 1037 sent by the Registrar). 1039 3. The acceptance datetime is within the window of time defined 1040 by ICANN policy. In the gTLD round of 2012, Registrars 1041 verified that the acceptance datetime was less than or equal 1042 to 48 hours in the past, as there were no defined ICANN 1043 policies at that time. Implementers should be aware that 1044 ICANN policy may define this value in the future. 1046 4. Using the leftmost DNL of the DN being effectively allocated, 1047 the expiration datetime provided by the Registrar, and the 1048 TMDB Notice Identifier extracted from the TCNID provided by 1049 the Registrar compute the TCN Checksum. Verify that the 1050 computed TCN Checksum match the TCN Checksum present in the 1051 TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is 1052 being effectively allocated, the leftmost DNL would be "xn-- 1053 mgbachtv". 1055 These procedures apply to all DN registrations at the second level as 1056 well as to all other levels subordinate to the TLD that the Registry 1057 accepts registrations for. 1059 5.3.3. TMBD Trademark Claims Services for Registries 1061 5.3.3.1. Domain Name Label (DNL) List 1063 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1064 and 12:00:00 UTC. 1066 Registries MUST refresh the latest version of the DNL List at least 1067 once every 24 hours. 1069 Update of the DNL List 1071 .----------. .------. 1072 | Registry | | TMDB | 1073 '----------' '------' 1074 | | 1075 .----------------. | 1076 | Periodically, | | 1077 | at least | | 1078 | every 24 hours | | 1079 '----------------' | 1080 | | 1081 |-------------------------------->| 1082 | Download the latest DNL List | 1083 |<--------------------------------| 1084 | | 1085 | | 1087 Figure 8 1089 Note: the DNL List will be the same regardless of the TLD. If a 1090 Backend Registry Operator manages the infrastructure of several TLDs, 1091 the Backend Registry Operator could refresh the DNL List once every 1092 24 hours, the DNL List could be used for all the TLDs managed by the 1093 Backend Registry Operator. 1095 5.3.3.2. Notice of Registered Domain Names (NORN) 1097 The NORDN process during the Trademark Claims Period is almost the 1098 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1099 difference that only registrations subject to a Trademark Claim 1100 (i.e., at registration time the name appeared in the current DNL List 1101 downloaded by the Registry Operator) are included in the LORDN. 1103 5.3.4. Trademark Claims Domain Name registration by Registrars 1105 For each DN matching a DNL of a PRM, Registrars MUST perform the 1106 following steps: 1108 1. Use the Lookup Key received from the Registry to obtain the TCN 1109 from the TMDB using the dr interface (Section 4.3.6) Registrars 1110 MUST only query for the Lookup Key of a DN that is available for 1111 registration. 1113 2. Present the TCN to the Registrant as described in Exhibit A, 1114 [RPM-Requirements]. 1116 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1117 consent with the TCN, before any further processing. (The 1118 transmission of a TCNID to the Registry over the ry interface, 1119 Section 4.3.5 implies that the Registrant has expressed his/her 1120 consent with the TCN.) 1122 4. Perform the minimum set of checks for verifying DN registrations. 1123 If any of these checks fails the Registrar MUST abort the DN 1124 registration. Each of these checks MUST be performed before the 1125 registration is sent to the Registry. Performing the minimum set 1126 of checks Registrars MUST verify that: 1128 1. The datetime when the validation is done is within the TCN 1129 validity based on the and 1130 elements. 1132 2. The leftmost DNL of the DN being effectively allocated 1133 matches the label () element in the TCN. For 1134 example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being 1135 effectively allocated, the leftmost DNL would be "xn-- 1136 mgbachtv". 1138 3. The Registrant has acknowledged (expressed his/her consent 1139 with) the TCN. 1141 5. Record the date and time when the registrant acknowledged the 1142 TCN. 1144 6. Send the registration to the Registry (ry interface, 1145 Section 4.3.5) and include the following information: 1147 * TCNID () 1149 * Expiration date of the TCN () 1151 * Acceptance datetime of the TCN. 1153 Currently TCNs are generated twice a day by the TMDB. The expiration 1154 date () of each TCN MUST be set to a value defined 1155 by ICANN policy. In the gTLD round of 2012, the TMDB set the 1156 expiration value to 48 hours in to the future as there were no 1157 defined ICANN policies at that time. Implementers should be aware 1158 that ICANN policy may define this value in the future. 1160 Registrars SHOULD implement a cache of TCNs to minimize the number of 1161 queries sent to the TMDB. A cached TCN MUST be removed from the 1162 cache after the expiration date of the TCN as defined by 1163 . 1165 The TMDB MAY implement rate-limiting as one of the protection 1166 mechanisms to mitigate the risk of performance degradation. 1168 5.3.5. TMBD Trademark Claims Services for Registrars 1170 5.3.5.1. Claims Notice Information Service (CNIS) 1172 The TCNs are provided by the TMDB online and are fetched by the 1173 Registrar via the dr interface (Section 4.3.6). 1175 To get access to the TCNs, the Registrar needs the credentials 1176 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1177 from the Registry via the ry interface (Section 4.3.5). The dr 1178 interface (Section 4.3.6) uses HTTPS with Basic access 1179 authentication. 1181 The dr interface (Section 4.3.6) MAY support up to ten (10) 1182 concurrent connections from each Registrar. 1184 The URL of the dr interface (Section 4.3.6) is: 1186 < https:///cnis/.xml > 1188 Note that the "lookupkey" may contain SLASH characters ("/"). The 1189 SLASH character is part of the URL path and MUST NOT be escaped when 1190 requesting the TCN. 1192 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1193 MUST be signed by a well-know public CA. Registrars MUST perform the 1194 Certification Path Validation described in Section 6 of [RFC5280]. 1195 Registrars will be authenticated in the dr interface using HTTP Basic 1196 access authentication. The dr (Section 4.3.6) interface MUST support 1197 HTTPS keep-alive and MUST maintain the connection for up to 30 1198 minutes. 1200 5.4. Qualified Launch Program (QLP) Period 1202 5.4.1. Domain Registration 1204 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1205 (QLP) Period effective allocations of DNs to third parties could 1206 require that Registries and Registrars provide Sunrise and/or 1207 Trademark Claims services. If required, Registries and Registrars 1208 MUST provide Sunrise and/or Trademark Claims services as described in 1209 Section 5.2 and Section 5.3. 1211 The effective allocation scenarios are: 1213 o If the leftmost DNL of the DN being effectively allocated (QLP 1214 Name in this section) matches a DNL in the SURL, and an SMD is 1215 provided, then Registries MUST provide Sunrise Services (see 1216 Section 5.2) and the DN MUST be reported in a Sunrise LORDN file 1217 during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- 1218 mgbh0fb" is being effectively allocated, the leftmost DNL would be 1219 "xn--mgbachtv". 1221 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1222 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1223 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1224 file using the special SMD-id "99999-99999" during the QLP Period. 1226 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1227 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1228 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1229 services (see Section 5.3) and the DN MUST be reported in a 1230 Trademark Claims LORDN file during the QLP Period. 1232 o If the QLP Name matches a DNL in the DNL List but does not match a 1233 DNL in the SURL, then Registries MUST provide Trademark Claims 1234 services (see Section 5.2) and the DN MUST be reported in a 1235 Trademark Claims LORDN file during the QLP Period. 1237 The following table lists all the effective allocation scenarios 1238 during a QLP Period: 1240 +--------+---------+-----------------+--------------+---------------+ 1241 | QLP | QLP | SMD was | Registry | Registry MUST | 1242 | Name | Name | provided by the | MUST provide | report DN | 1243 | match | match | potential | Sunrise or | registration | 1244 | in the | in the | Registrant | Trademark | in | 1245 | SURL | DNL | | Claims | LORDN file | 1246 | | List | | Services | | 1247 +--------+---------+-----------------+--------------+---------------+ 1248 | Y | Y | Y | Sunrise | Sunrise | 1249 | | | | | | 1250 | Y | N | Y | Sunrise | Sunrise | 1251 | | | | | | 1252 | N | Y | -- | Trademark | Trademark | 1253 | | | | Claims | Claims | 1254 | | | | | | 1255 | N | N | -- | -- | -- | 1256 | | | | | | 1257 | Y | Y | N (see section | Trademark | Trademark | 1258 | | | 2.2 of | Claims | Claims | 1259 | | | [QLP-Addendum]) | | | 1260 | | | | | | 1261 | Y | N | N (see section | -- | Sunrise | 1262 | | | 2.2 of | | (using | 1263 | | | [QLP-Addendum]) | | special SMD- | 1264 | | | | | id) | 1265 +--------+---------+-----------------+--------------+---------------+ 1267 QLP Effective Allocation Scenarios 1269 The TMDB MUST provide the following services to Registries during a 1270 QLP Period: 1272 o SMD Revocation List (see Section 5.2.3.1) 1274 o NORN (see Section 5.2.3.3) 1276 o DNL List (see Section 5.3.3.1) 1278 o Sunrise List (SURL) (see Section 5.4.2.1 1280 The TMDB MUST provide the following services to Registrars during a 1281 QLP Period: 1283 o SMD Revocation List (see Section 5.2.3.1) 1284 o CNIS (see Section 5.3.5.1) 1286 5.4.2. TMBD QLP Services for Registries 1288 5.4.2.1. Sunrise List (SURL) 1290 A new Sunrise List (SURL) MUST be published by the TMDB twice a day, 1291 by 00:00:00 and 12:00:00 UTC. 1293 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1294 version of the SURL at least once every 24 hours. 1296 Update of the SURL 1298 .----------. .------. 1299 | Registry | | TMDB | 1300 '----------' '------' 1301 | | 1302 .----------------. | 1303 | Periodically, | | 1304 | at least | | 1305 | every 24 hours | | 1306 '----------------' | 1307 | | 1308 |------------------------------->| 1309 | Download the latest SURL | 1310 |<-------------------------------| 1311 | | 1312 | | 1314 Figure 9 1316 Note: the SURL will be the same regardless of the TLD. If a Backend 1317 Registry Operator manages the infrastructure of several TLDs, the 1318 Backend Registry Operator could refresh the SURL once every 24 hours, 1319 the SURL could be used for all the TLDs managed by the Backend 1320 Registry Operator. 1322 6. Data Format Descriptions 1324 6.1. Domain Name Label (DNL) List 1326 This section defines the format of the list containing every Domain 1327 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1328 is maintained by the TMDB and downloaded by Registries in regular 1329 intervals (see Section 5.3.3.1). The Registries use the DNL List 1330 during the Trademark Claims Period to check whether a requested DN 1331 matches a DNL of a PRM. 1333 The DNL List contains all the DNLs covered by a PRM present in the 1334 TMDB at the datetime it is generated. 1336 The DNL List is contained in a CSV formatted file that has the 1337 following structure: 1339 o first line: , 1341 Where: 1343 + , version of the file, this field MUST be 1. 1345 + , date and time in UTC that the 1346 DNL List was created. 1348 o second line: a header line as specified in [RFC4180] 1350 With the header names as follows: 1352 DNL,lookup-key,insertion-datetime 1354 o One or more lines with: ,, 1357 Where: 1359 + , a Domain Name Label covered by a PRM. 1361 + , lookup key that the Registry MUST provide to 1362 the Registrar. The lookup key has the following format: 1363
////, where: 1366 - YYYY: year that the TCN was generated. 1368 - MM: zero-padded month that the TCN was generated. 1370 - DD: zero-padded day that the TCN was generated. 1372 - vv: version of the TCN, possible values are 00 and 01. 1374 - X: one hexadecimal digit [0-9A-F]. This is the first, 1375 second and third hexadecimal digit of encoding the 1376 in base16 as specified in [RFC4648]. 1378 - Random bits: 144 random bits encoded in base64url as 1379 specified in [RFC4648]. 1381 - Sequential number: zero-padded natural number in the 1382 range 0000000001 to 2147483647. 1384 + , datetime in UTC that the DNL was 1385 first inserted into the DNL List. The possible two values 1386 of time for inserting a DNL to the DNL List are 00:00:00 and 1387 12:00:00 UTC. 1389 Example of a DNL List 1391 1,2012-08-16T00:00:00.0Z 1392 DNL,lookup-key,insertion-datetime 1393 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1394 2010-07-14T00:00:00.0Z 1395 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1396 2012-08-16T00:00:00.0Z 1397 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1398 2011-08-16T12:00:00.0Z 1400 Figure 10 1402 To provide authentication and integrity protection, the DNL List will 1403 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1404 PGP signature of the DNL List can be found in the similar URI but 1405 with extension .sig as shown below. 1407 The URL of the dy interface (Section 4.3.3) is: 1409 o < https:///dnl/dnl-latest.csv > 1411 o < https:///dnl/dnl-latest.sig > 1413 6.2. SMD Revocation List 1415 This section defines the format of the list of SMDs that have been 1416 revoked. The list is maintained by the TMDB and downloaded by 1417 Registries (and optionally by Registrars) in regular intervals (see 1418 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1419 Period to validate SMDs received. The SMD Revocation List has a 1420 similar function as CRLs used in PKI [RFC5280]. 1422 The SMD Revocation List contains all the revoked SMDs present in the 1423 TMDB at the datetime it is generated. 1425 The SMD Revocation List is contained in a CSV formatted file that has 1426 the following structure: 1428 o first line: , 1430 Where: 1432 + , version of the file, this field MUST be 1. 1434 + , datetime in UTC 1435 that the SMD Revocation List was created. 1437 o second line: a header line as specified in [RFC4180] 1439 With the header names as follows: 1441 smd-id,insertion-datetime 1443 o One or more lines with: , 1445 Where: 1447 + , identifier of the SMD that was revoked. 1449 + , revocation datetime in UTC of the 1450 SMD. The possible two values of time for inserting an SMD 1451 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1453 To provide integrity protection, the SMD Revocation List is PGP 1454 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1455 List is provided by the TMDB with extension .csv. The PGP signature 1456 of the SMD Revocation List can be found in the similar URI but with 1457 extension .sig as shown below. 1459 The URL of the sr interface (Section 4.3.12) and sy interface 1460 (Section 4.3.11) is: 1462 o < https:///smdrl/smdrl-latest.csv > 1464 o < https:///smdrl/smdrl-latest.sig > 1465 Example of an SMD Revocation List 1467 1,2012-08-16T00:00:00.0Z 1468 smd-id,insertion-datetime 1469 2-2,2012-08-15T00:00:00.0Z 1470 3-2,2012-08-15T00:00:00.0Z 1471 1-2,2012-08-15T00:00:00.0Z 1473 Figure 11 1475 6.3. List of Registered Domain Names (LORDN) file 1477 This section defines the format of the List of Registered Domain 1478 Names (LORDN), which is maintained by each Registry and uploaded at 1479 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1480 said DN is added to the LORDN along with further information related 1481 to its registration. 1483 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1484 file is: 1486 o Sunrise LORDN file: 1488 < https:///LORDN//sunrise > 1490 o Trademark Claims LORDN file: 1492 < https:///LORDN//claims > 1494 During a QLP Period, Registries MAY be required to upload Sunrise or 1495 Trademark Claims LORDN files. The URIs of the yd interface used to 1496 upload LORDN files during a QLP Period is: 1498 o Sunrise LORDN file (during QLP Period): 1500 < https:///LORDN//sunrise/qlp > 1502 o Trademark Claims LORDN file (during a QLP Period): 1504 < https:///LORDN//claims/qlp > 1506 The yd interface (Section 4.3.7) returns the following HTTP status 1507 codes after a HTTP POST request method is received: 1509 o The interface provides a HTTP/202 status code if the interface was 1510 able to receive the LORDN file and the syntax of the LORDN file is 1511 correct. 1513 The interface provides the LORDN Transaction Identifier in the 1514 HTTP Entity-body that would be used by the Registry to download 1515 the LORDN Log file. The LORDN Transaction Identifier is a 1516 natural number zero-padded in the range 0000000000000000001 to 1517 9223372036854775807. 1519 The TMDB uses the element of the 1520 LORDN file as a unique client-side identifier. If a LORDN file 1521 with the same of a previously sent 1522 LORDN file is received by the TMDB, the LORDN Transaction 1523 Identifier of the previously sent LORDN file MUST be provided 1524 to the Registry. The TMDB MUST ignore the DN Lines present in 1525 the LORDN file if a LORDN file with the same was previously sent. 1528 The HTTP Location header field contains the URI where the LORDN 1529 Log file could be retrieved later, for example: 1531 202 Accepted 1533 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1536 o The interface provides a HTTP/400 if the request is incorrect or 1537 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1538 human readable message in the HTTP Entity-body regarding the 1539 incorrect syntax of the LORDN file. 1541 o The interface provides a HTTP/401 status code if the credentials 1542 provided does not authorize the Registry Operator to upload a 1543 LORDN file. 1545 o The TMDB MUST return a HTTP/404 status code when trying to upload 1546 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1549 plus 26 hours. 1551 o The interface provides a HTTP/500 status code if the system is 1552 experiencing a general failure. 1554 For example, to upload the Sunrise LORDN file for TLD "example", the 1555 URI would be: 1557 < https:///LORDN/example/sunrise > 1559 The LORDN is contained in a CSV formatted file that has the following 1560 structure: 1562 o For Sunrise Period: 1564 * first line: ,, 1567 Where: 1569 - , version of the file, this field MUST be 1. 1571 - , date and time in UTC that the 1572 LORDN was created. 1574 - , number of DN Lines present in the 1575 LORDN file. 1577 * second line: a header line as specified in [RFC4180] 1579 With the header names as follows: 1581 roid,domain-name,SMD-id,registrar-id,registration- 1582 datetime,application-datetime 1584 * One or more lines with: ,,,,, 1588 Where: 1590 - , DN Repository Object IDentifier (DNROID) in the 1591 SRS. 1593 - , DN that was effectively allocated. For 1594 IDNs, the A-label form is used. 1596 - , SMD ID used for registration. 1598 - , IANA Registrar ID. 1600 - , date and time in UTC that the 1601 domain was effectively allocated. 1603 - OPTIONAL , date and 1604 time in UTC that the application was created. The 1605 MUST be provided in 1606 case of a DN effective allocation based on an 1607 asynchronous registration (e.g., when using auctions). 1609 Example of a Sunrise LORDN file 1611 1,2012-08-16T00:00:00.0Z,3 1612 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1613 application-datetime 1614 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1615 2012-07-15T00:50:00.0Z 1616 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1617 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1619 Figure 12 1621 o For Trademark Claims Period: 1623 * first line: ,, 1626 Where: 1628 - , version of the file, this field MUST be 1. 1630 - , date and time in UTC that the 1631 LORDN was created. 1633 - , number of DN Lines present in the 1634 LORDN file. 1636 * second line: a header line as specified in [RFC4180] 1638 With the header names as follows: 1640 roid,domain-name,notice-id,registrar-id,registration- 1641 datetime,ack-datetime,application-datetime 1643 * One or more lines with: ,,,,,, 1647 Where: 1649 - , DN Repository Object IDentifier (DNROID) in the 1650 SRS. 1652 - , DN that was effectively allocated. For 1653 IDNs, the A-label form is used. 1655 - , Trademark Claims Notice Identifier as specified 1656 in . 1658 - , IANA Registrar ID. 1660 - , date and time in UTC that the 1661 domain was effectively allocated. 1663 - , date and time in UTC 1664 that the TCN was acknowledged. 1666 - OPTIONAL , date and 1667 time in UTC that the application was created. The 1668 MUST be provided in 1669 case of a DN effective allocation based on an 1670 asynchronous registration (e.g., when using auctions). 1672 For a DN matching a DNL of a PRM at the moment of 1673 registration, created without the TCNID, expiration datetime 1674 and acceptance datetime, because DNL was inserted (or re- 1675 inserted) for the first time into DNL List less than 24 1676 hours ago, the string "recent-dnl-insertion" MAY be 1677 specified in and . 1680 Example of a Trademark Claims LORDN file 1682 1,2012-08-16T00:00:00.0Z,3 1683 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1684 ack-datetime,application-datetime 1685 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1686 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1687 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1688 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1689 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1690 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1692 Figure 13 1694 6.3.1. LORDN Log file 1696 After reception of the LORDN file, the TMDB verifies its content for 1697 syntactical and semantical correctness. The output of the LORDN file 1698 verification is retrieved using the yd interface (Section 4.3.7). 1700 The URI of the yd interface (Section 4.3.7) used to retrieve the 1701 LORDN Log file is: 1703 o Sunrise LORDN Log file: 1705 < https:///LORDN//sunrise//result > 1708 o Trademark Claims LORDN Log file: 1710 < https:///LORDN//claims//result > 1713 A Registry Operator MUST NOT send more than one request per minute 1714 per TLD to download a LORDN Log file. 1716 The yd interface (Section 4.3.7) returns the following HTTP status 1717 codes after a HTTP GET request method is received: 1719 o The interface provides a HTTP/200 status code if the interface was 1720 able to provide the LORDN Log file. The LORDN Log file is 1721 contained in the HTTP Entity-body. 1723 o The interface provides a HTTP/204 status code if the LORDN 1724 Transaction Identifier is correct, but the server has not 1725 finalized processing the LORDN file. 1727 o The interface provides a HTTP/400 status code if the request is 1728 incorrect. 1730 o The interface provides a HTTP/401 status code if the credentials 1731 provided does not authorize the Registry Operator to download the 1732 LORDN Log file. 1734 o The interface provides a HTTP/404 status code if the LORDN 1735 Transaction Identifier is incorrect. 1737 o The interface provides a HTTP/500 status code if the system is 1738 experiencing a general failure. 1740 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1741 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1742 "example" the URI would be: 1744 < https:///LORDN/example/sunrise/0000000000000000001/result > 1747 The LORDN Log file is contained in a CSV formatted file that has the 1748 following structure: 1750 o first line: ,,,,,, 1754 Where: 1756 + , version of the file, this field MUST be 1. 1758 + , date and time in UTC that the 1759 LORDN Log was created. 1761 + , date and time in UTC of 1762 creation for the LORDN file that this log file is referring 1763 to. 1765 + , unique identifier of the LORDN Log 1766 provided by the TMDB. This identifier could be used by the 1767 Registry Operator to unequivocally identify the LORDN Log. 1768 The identified will be a string of a maximum LENGTH of 60 1769 characters from the Base 64 alphabet. 1771 + , whether the LORDN file has been accepted for 1772 processing by the TMDB. Possible values are "accepted" or 1773 "rejected". 1775 + , whether the LORDN Log has any warning result 1776 codes. Possible values are "no-warnings" or "warnings- 1777 present". 1779 + , number of DNs effective allocations 1780 processed in the LORDN file. 1782 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1783 a ="accepted" and ="no-warnings". 1785 o second line: a header line as specified in [RFC4180] 1787 With the header names as follows: 1789 roid,result-code 1791 o One or more lines with: , 1793 Where: 1795 + , DN Repository Object IDentifier (DNROID) in the SRS. 1797 + , result code as described in Section 6.3.1.1. 1799 Example of a LORDN Log file 1801 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1802 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1803 accepted,no-warnings,1 1804 roid,result-code 1805 SH8013-REP,2000 1807 Figure 14 1809 6.3.1.1. LORDN Log Result Codes 1811 In Figure 15 the classes of result codes (rc) are listed. Those 1812 classes in square brackets are not used at this time, but may come 1813 into use at some later stage. The first two digits of a result code 1814 denote the result code class, which defines the outcome at the TMDB: 1816 o ok: Success, DN Line accepted by the TMDB. 1818 o warn: a warning is issued, DN Line accepted by the TMDB. 1820 o err: an error is issued, LORDN file rejected by the TMDB. 1822 In case that after processing a DN Line, the error result code is 1823 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1824 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1825 valid will be reported with a 2001 result code. A 2001 result code 1826 means that the DN Line is syntactically valid, however the DN Line 1827 was not processed because the LORDN file was rejected. All DNs 1828 reported in a rejected LORDN file MUST be reported again by the 1829 Registry because none of the DN Lines present in the LORDN file have 1830 been processed by the TMDB. 1832 LORDN Log Result Code Classes 1834 code Class outcome 1835 ---- ----- ------- 1837 20xx Success ok 1839 35xx [ DN Line syntax warning ] warn 1840 36xx DN Line semantic warning warn 1842 45xx DN Line syntax error err 1843 46xx DN Line semantic error err 1845 Figure 15 1847 In the following, the LORDN Log result codes used by the TMDB are 1848 described: 1850 LORDN Log result Codes 1852 rc Short Description 1853 Long Description 1854 ---- ------------------------------------------------------------- 1856 2000 OK 1857 DN Line successfully processed. 1859 2001 OK but not processed 1860 DN Line is syntactically correct but was not processed 1861 because the LORDN file was rejected. 1863 3601 TCN Acceptance Date after Registration Date 1864 TCN Acceptance Date in DN Line is newer than the Registration 1865 Date. 1867 3602 Duplicate DN Line 1868 This DN Line is an exact duplicate of another DN Line in same 1869 file, DN Line ignored. 1871 3603 DNROID Notified Earlier 1872 Same DNROID has been notified earlier, DN Line ignored. 1874 3604 TCN Checksum invalid 1875 Based on the DN effectively allocated, the TCNID and the 1876 expiration date of the linked TCN, the TCN Checksum is 1877 invalid. 1879 3605 TCN Expired 1880 The TCN was already expired (based on the 1881 field of the TCN) at the datetime of acknowledgement. 1883 3606 Wrong TCNID used 1884 The TCNID used for the registration does not match 1885 the related DN. 1887 3609 Invalid SMD used 1888 The SMD used for registration was not valid at the moment of 1889 registration based on the and 1890 elements. 1891 In case of an asynchronous registration, this refer to the 1892 . 1894 3610 DN reported outside of the time window 1895 The DN was reported outside of the required 26 hours 1896 reporting window. 1898 3611 DN does not match the labels in SMD 1899 The DN does not match the labels included in the SMD. 1901 3612 SMDID does not exist 1902 The SMDID has never existed in the central repository. 1904 3613 SMD was revoked when used 1905 The SMD used for registration was revoked more than 1906 24 hours ago of the . 1907 In case of an asynchronous registration, 1908 the is used when 1909 validating the DN Line. 1911 3614 TCNID does not exist 1912 The TCNID has never existed in the central repository. 1914 3615 Recent-dnl-insertion outside of the time window 1915 The DN registration is reported as a recent-dnl-insertion, 1916 but the (re) insertion into the DNL occurred more than 1917 24 hours ago. 1919 3616 Registration Date of DN in Claims before the end of Sunrise Period 1920 The registration date of the DN is before the end of Sunrise Period 1921 and the DN was reported in a Trademark Claims LORDN file. 1923 3617 Registrar has not been approved by the TMDB 1924 Registrar ID in DN Line has not completed Trademark Claims integration 1925 testing with the TMDB. 1927 3618 Registration Date of DN in a QLP LORDN file outside of the QLP Period 1928 The registration date of the DN in a QLP LORDN file is outside 1929 of the QLP Period. 1931 3619 TCN was not valid 1932 The TCN was not valid (based on the 1933 field of the TCN) at the datetime of acknowledgement. 1935 4501 Syntax Error in DN Line 1936 Syntax Error in DN Line. 1938 4601 Invalid TLD used 1939 The TLD in the DN Line does not match what is expected for 1940 this LORDN. 1942 4602 Registrar ID Invalid 1943 Registrar ID in DN Line is not a valid ICANN-Accredited 1944 Registrar. 1946 4603 Registration Date in the future 1947 The in the DN Line is in the 1948 future. 1950 4606 TLD not in Sunrise or Trademark Claims Period 1951 The was reported when the TLD was 1952 not in Sunrise or Trademark Claims Periods. 1953 In case of an asynchronous registration, 1954 the is used when 1955 validating the DN Line. 1957 4607 Application Date in the future 1958 The in the DN Line is in the 1959 future. 1961 4608 Application Date is later than Registration Date 1962 The in the DN Line is later 1963 than the . 1965 4609 TCNID wrong syntax 1966 The syntax of the TCNID is invalid. 1968 4610 TCN Acceptance Date is in the future 1969 The is in the future. 1971 4611 Label has never existed in the TMDB 1972 The label in the registered DN has never existed in the TMDB. 1974 Figure 16 1976 6.4. Signed Mark Data (SMD) File 1978 This section defines the format of the Signed Mark Data (SMD) File. 1979 After a successful registration of a mark, the TMV returns an SMD 1980 File to the TMH. The SMD File can then be used for registration of 1981 one or more DNs covered by the PRM during the Sunrise Period of a 1982 TLD. 1984 Two encapsulation boundaries are defined for delimiting the 1985 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1986 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1987 boundaries MUST be used by Registries and Registrars for validation 1988 purposes, i.e. any data outside these boundaries as well as the 1989 boundaries themselves MUST be ignored for validation purposes. 1991 The structure of the SMD File is as follows, all the elements are 1992 REQUIRED, and MUST appear in the specified order. 1994 1. Marks: 1996 2. smdID: 1998 3. U-labels: 2001 4. notBefore: 2003 5. notAfter: 2005 6. -----BEGIN ENCODED SMD----- 2007 7. 2009 8. -----END ENCODED SMD----- 2010 Example of an SMD File: 2012 Marks: Example One 2013 smdID: 1-2 2014 U-labels: example-one, exampleone 2015 notBefore: 2011-08-16 09:00 2016 notAfter: 2012-08-16 09:00 2017 -----BEGIN ENCODED SMD----- 2018 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2019 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2020 ... (base64 data elided for brevity) ... 2021 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2022 -----END ENCODED SMD----- 2024 Figure 17 2026 6.5. Trademark Claims Notice (TCN) 2028 The TMDB MUST provide the TCN to Registrars in XML format as 2029 specified below. 2031 An enclosing element that describes the Trademark 2032 Notice to a given label. 2034 The child elements of the element include: 2036 o A element that contains the unique identifier of the 2037 Trademark Notice. This element contains the the TCNID. 2039 The TCNID is a string concatenation of a TCN Checksum and the 2040 TMDB Notice Identifier. The first 8 characters of the TCNID is 2041 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2042 is a zero-padded natural number in the range of 2043 0000000000000000001 to 9223372036854775807. 2045 Example of a TCNID: 2047 370d0b7c9223372036854775807. 2049 Where: 2051 + TCN Checksum=370d0b7c 2053 + TMDB Notice Identifier=9223372036854775807 2054 The TCN Checksum is a 8 characters long Base16 encoded output 2055 of computing the CRC32 of the string concatenation of: label + 2056 unix_timestamp() + TMDB Notice Identifier 2058 TMDB MUST use the Unix time conversion of the 2059 in UTC to calculate the TCN Checksum. Unix 2060 time is defined as the number of seconds that have elapsed 2061 since 1970-01-01T00:00:00Z not counting leap seconds. For 2062 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2063 is shown: 2065 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2067 The TMDB uses the and 2068 elements from the TCN along with the TMDB Notice Identifier to 2069 compute the TCN Checksum. 2071 A Registry MUST use the leftmost DNL of the DN being 2072 effectively allocated, the expiration datetime of the TCN 2073 (provided by the Registrar) and the TMDB Notice Identifier 2074 extracted from the TCNID (provided by the Registrar) to compute 2075 the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- 2076 mgbh0fb" is being effectively allocated, the leftmost DNL would 2077 be "xn--mgbachtv". 2079 Example of computation of the TCN Checksum: 2081 CRC32(example-one12819492009223372036854775807)=370d0b7c 2083 o A element that contains the start of the 2084 validity date and time of the TCN. 2086 o A element that contains the expiration date 2087 and time of the TCN. 2089 o A element that contains the DNL covered by a PRM. 2091 o One or more elements that contain the Trademark 2092 Claim. The element contains the following child 2093 elements: 2095 * A element that contains the mark text 2096 string. 2098 * One or more elements that contains the 2099 information of the holder of the mark. An "entitlement" 2100 attribute is used to identify the entitlement of the holder, 2101 possible values are: owner, assignee or licensee. The child 2102 elements of include: 2104 + An OPTIONAL element that contains the name 2105 of the holder. A MUST be specified if 2106 is not specified. 2108 + An OPTIONAL element that contains the name of 2109 the organization holder of the mark. A MUST 2110 be specified if is not specified. 2112 + A element that contains the address 2113 information of the holder of a mark. A 2114 contains the following child elements: 2116 - One, two or three OPTIONAL elements 2117 that contains the organization's street address. 2119 - A element that contains the 2120 organization's city. 2122 - An OPTIONAL element that contains the 2123 organization's state or province. 2125 - An OPTIONAL element that contains the 2126 organization's postal code. 2128 - A element that contains the organization's 2129 country code. This a two-character code from 2130 [ISO3166-2]. 2132 + An OPTIONAL element that contains the 2133 organization's voice telephone number. 2135 + An OPTIONAL element that contains the 2136 organization's facsimile telephone number. 2138 + An OPTIONAL element that contains the email 2139 address of the holder. 2141 * Zero or more OPTIONAL elements that contains 2142 the information of the representative of the mark registration. 2143 A "type" attribute is used to identify the type of contact, 2144 possible values are: owner, agent or thirdparty. The child 2145 elements of include: 2147 + A element that contains name of the 2148 responsible person. 2150 + An OPTIONAL element that contains the name of 2151 the organization of the contact. 2153 + A element that contains the address 2154 information of the contact. A contains the 2155 following child elements: 2157 - One, two or three OPTIONAL elements 2158 that contains the contact's street address. 2160 - A element that contains the contact's 2161 city. 2163 - An OPTIONAL element that contains the 2164 contact's state or province. 2166 - An OPTIONAL element that contains the 2167 contact's postal code. 2169 - A element that contains the contact's 2170 country code. This a two-character code from 2171 [ISO3166-2]. 2173 + A element that contains the contact's voice 2174 telephone number. 2176 + An OPTIONAL element that contains the 2177 contact's facsimile telephone number. 2179 + A element that contains the contact's email 2180 address. 2182 * A element that contains the name (in 2183 English) of the jurisdiction where the mark is protected. A 2184 jurCC attribute contains the two-character code of the 2185 jurisdiction where the mark was registered. This is a two- 2186 character code from [WIPO.ST3]. 2188 * Zero or more OPTIONAL element that 2189 contains the description (in English) of the Nice 2190 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2191 attribute contains the class number. 2193 * A element that contains the full 2194 description of the goods and services mentioned in the mark 2195 registration document. 2197 * An OPTIONAL element signals that the 2198 claim notice was added to the TCN based on other rule (e.g. 2199 [Claims50] ) than exact match (defined in [MatchingRules]). 2200 The contains one or more: 2202 + An OPTIONAL element that signals that the 2203 claim notice was added because of a previously abused name 2204 included in an UDRP case. The contains: 2206 - A element that contains the UDRP case 2207 number used to validate the previously abused name. 2209 - A element that contains the name 2210 of the UDRP provider. 2212 + An OPTIONAL element that signals that the 2213 claim notice was added because of a previously abused name 2214 included in a court's resolution. The 2215 contains: 2217 - A element that contains the reference 2218 number of the court's resolution used to validate the 2219 previously abused name. 2221 - A element that contains the two-character 2222 code from [ISO3166-2] of the jurisdiction of the court. 2224 - A element that contains the name of 2225 the court. 2227 Example of a object: 2229 2230 2231 370d0b7c9223372036854775807 2232 2010-08-14T09:00:00.0Z 2233 2010-08-16T09:00:00.0Z 2234 example-one 2235 2236 Example One 2237 2238 Example Inc. 2239 2240 123 Example Dr. 2241 Suite 100 2242 Reston 2243 VA 2244 20190 2245 US 2246 2247 2248 2249 Joe Doe 2250 Example Inc. 2251 2252 123 Example Dr. 2253 Suite 100 2254 Reston 2255 VA 2256 20190 2257 US 2258 2259 +1.7035555555 2260 jdoe@example.com 2261 2262 UNITED STATES OF AMERICA 2263 2264 Advertising; business management; business administration. 2265 2266 2267 Insurance; financial affairs; monetary affairs; real estate. 2268 2269 2270 Bardus populorum circumdabit se cum captiosus populum. 2271 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2272 2273 2274 2275 Example-One 2276 2277 Example S.A. de C.V. 2278 2279 Calle conocida #343 2280 Conocida 2281 SP 2282 82140 2283 BR 2284 2285 2286 BRAZIL 2287 2288 Bardus populorum circumdabit se cum captiosus populum. 2289 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2290 2291 2292 2293 One 2294 2295 One Corporation 2296 2297 Otra calle 2298 Otra ciudad 2299 OT 2300 383742 2301 CR 2302 2303 2304 COSTA RICA 2305 2306 Bardus populorum circumdabit se cum captiosus populum. 2307 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2308 2309 2310 2311 234235 2312 CR 2313 Supreme Court of Justice of Costa Rica 2314 2315 2316 2317 2318 One Inc 2319 2320 One SA de CV 2321 2322 La calle 2323 La ciudad 2324 CD 2325 34323 2326 AR 2327 2328 2329 ARGENTINA 2330 2331 Bardus populorum circumdabit se cum captiosus populum. 2332 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2333 2334 2335 2336 D2003-0499 2337 WIPO 2338 2339 2341 2342 2344 For the formal syntax of the TCN please refer to Section 7.1. 2346 6.6. Sunrise List (SURL) 2348 This section defines the format of the list containing every Domain 2349 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2350 is maintained by the TMDB and downloaded by Registries in regular 2351 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2352 during the Qualified Launch Program Period to check whether a 2353 requested DN matches a DNL of a PRM eligible for Sunrise. 2355 The Sunrise List contains all the DNLs covered by a PRM eligible for 2356 Sunrise present in the TMDB at the datetime it is generated. 2358 The Sunrise List is contained in a CSV formatted file that has the 2359 following structure: 2361 o first line: , 2363 Where: 2365 + , version of the file, this field MUST be 1. 2367 + , date and time in UTC that 2368 the Sunrise List was created. 2370 o second line: a header line as specified in [RFC4180] 2372 With the header names as follows: 2374 DNL,insertion-datetime 2376 o One or more lines with: , 2378 Where: 2380 + , a Domain Name Label covered by a PRM eligible for 2381 Sunrise. 2383 + , datetime in UTC that the DNL was 2384 first inserted into the Sunrise List. The possible two 2385 values of time for inserting a DNL to the Sunrise List are 2386 00:00:00 and 12:00:00 UTC. 2388 Example of a SURL 2390 1,2012-08-16T00:00:00.0Z 2391 DNL,insertion-datetime 2392 example,2010-07-14T00:00:00.0Z 2393 another-example,2012-08-16T00:00:00.0Z 2394 anotherexample,2011-08-16T12:00:00.0Z 2396 Figure 18 2398 To provide authentication and integrity protection, the Sunrise List 2399 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2400 signature of the Sunrise List can be found in the similar URI but 2401 with extension .sig as shown below. 2403 The URL of the dy interface (Section 4.3.3) is: 2405 o < https:///dnl/surl-latest.csv > 2407 o < https:///dnl/surl-latest.sig > 2409 7. Formal Syntax 2411 7.1. Trademark Claims Notice (TCN) 2413 The schema presented here is for a Trademark Claims Notice. 2415 The BEGIN and END tags are not part of the schema; they are used to 2416 note the beginning and ending of the schema for URI registration 2417 purposes. 2419 Copyright (c) 2016 IETF Trust and the persons identified as authors 2420 of the code. All rights reserved. 2422 Redistribution and use in source and binary forms, with or without 2423 modification, is permitted pursuant to, and subject to the license 2424 terms contained in, the Simplified BSD License set forth in 2425 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 2426 Documents (http://trustee.ietf.org/license-info). 2428 BEGIN 2429 2430 2435 2436 2437 Schema for representing a Trademark Claim Notice. 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2461 2462 2463 2464 2465 2466 2468 2470 2471 2473 2474 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 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 2537 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. IANA Considerations 2556 This document uses URNs to describe XML namespaces and XML schemas 2557 conforming to a registry mechanism described in [RFC3688]. One URI 2558 assignment have been registered by the IANA. 2560 Registration request for the Trademark Claims Notice namespace: 2562 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2564 Registrant Contact: See the "Author's Address" section of this 2565 document. 2567 XML: None. Namespace URIs do not represent an XML specification. 2569 Registration request for the Trademark Claims Notice XML schema: 2571 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2573 Registrant Contact: See the "Author's Address" section of this 2574 document. 2576 XML: See Section 7.1 of this document. 2578 10. Security Considerations 2580 This specification uses HTTP Basic Authentication to provide a simple 2581 application-layer authentication service. HTTPS is used in all 2582 interfaces in order to protect against most common attacks. In 2583 addition, the client identifier is tied to a set of IP addresses that 2584 are allowed to connect to the interfaces described in this document, 2585 providing an extra security measure. 2587 The TMDB MUST provide credentials to the appropriate Registries and 2588 Registrars. 2590 The TMDB MUST require the use of strong passwords by Registries and 2591 Registrars. 2593 The TMDB, Registries and Registrars MUST use the best practices 2594 described in RFC 7525 or its successors. 2596 11. References 2598 11.1. Normative References 2600 [Claims50] 2601 ICANN, "Implementation Notes: Trademark Claims Protection 2602 for Previously Abused Names", July 2013, 2603 . 2606 [MatchingRules] 2607 ICANN, "Memorandum on Implementing Matching Rules", 2608 September 2012, . 2611 [QLP-Addendum] 2612 ICANN, "Qualified Launch Program Addendum", April 2014, 2613 . 2617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2618 Requirement Levels", BCP 14, RFC 2119, 2619 DOI 10.17487/RFC2119, March 1997, 2620 . 2622 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2623 DOI 10.17487/RFC3688, January 2004, 2624 . 2626 [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", 2627 RFC 7848, DOI 10.17487/RFC7848, June 2016, 2628 . 2630 [RPM-Requirements] 2631 ICANN, "Rights Protection Mechanism Requirements", 2632 September 2013, . 2635 11.2. Informative References 2637 [ICANN-GTLD-AGB-20120604] 2638 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2639 2012, . 2642 [ISO3166-2] 2643 ISO, "International Standard for country codes and codes 2644 for their subdivisions", 2006, 2645 . 2647 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2648 DOI 10.17487/RFC2818, May 2000, 2649 . 2651 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2652 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2653 . 2655 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2656 Separated Values (CSV) Files", RFC 4180, 2657 DOI 10.17487/RFC4180, October 2005, 2658 . 2660 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2661 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2662 . 2664 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2665 Thayer, "OpenPGP Message Format", RFC 4880, 2666 DOI 10.17487/RFC4880, November 2007, 2667 . 2669 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2670 Housley, R., and W. Polk, "Internet X.509 Public Key 2671 Infrastructure Certificate and Certificate Revocation List 2672 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2673 . 2675 [RFC5890] Klensin, J., "Internationalized Domain Names for 2676 Applications (IDNA): Definitions and Document Framework", 2677 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2678 . 2680 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2681 Protocol (HTTP/1.1): Message Syntax and Routing", 2682 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2683 . 2685 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2686 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2687 DOI 10.17487/RFC7231, June 2014, 2688 . 2690 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2691 Protocol (HTTP/1.1): Authentication", RFC 7235, 2692 DOI 10.17487/RFC7235, June 2014, 2693 . 2695 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2696 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2697 2015, . 2699 [WIPO-NICE-CLASSES] 2700 WIPO, "WIPO Nice Classification", 2015, 2701 . 2703 [WIPO.ST3] 2704 WIPO, "Recommended standard on two-letter codes for the 2705 representation of states, other entities and 2706 intergovernmental organizations", March 2007, 2707 . 2709 Author's Address 2710 Gustavo Lozano 2711 ICANN 2712 12025 Waterfront Drive, Suite 300 2713 Los Angeles 90292 2714 US 2716 Phone: +1.3103015800 2717 Email: gustavo.lozano@icann.org