idnits 2.17.1 draft-ietf-eppext-tmch-func-spec-00.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. ** There are 2 instances of lines with control characters in the document. 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 (Sep 28, 2015) is 3133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1355, but not defined == Unused Reference: 'RFC2617' is defined on line 2663, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-eppext-tmch-smd-02 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 Sep 28, 2015 5 Expires: March 31, 2016 7 TMCH functional specifications 8 draft-ietf-eppext-tmch-func-spec-00 10 Abstract 12 This document describes the requirements, the architecture and the 13 interfaces between the Trademark Clearing House (TMCH) and Domain 14 Name Registries as well as between the TMCH and Domain Name 15 Registrars for the provisioning and management of domain names during 16 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 March 31, 2016. 35 Copyright Notice 37 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9 57 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 58 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 59 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . . 14 75 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 14 76 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . . 14 77 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 14 78 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 79 5.1.1.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 80 5.1.1.4. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 15 81 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . . 16 82 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 16 83 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 16 84 5.1.2.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 16 85 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 16 86 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 17 87 5.2.1. Domain Name Registration . . . . . . . . . . . . . . . 17 88 5.2.2. Sunrise DN Registration by Registries . . . . . . . . 18 89 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . . 19 90 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 19 91 5.2.3.2. Certificate Revocation List . . . . . . . . . . . 20 92 5.2.3.3. Notice of Registered Domain Names . . . . . . . . 21 93 5.2.4. Sunrise DN registration by Registrars . . . . . . . . 23 94 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . . 24 95 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 25 96 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 25 97 5.3.2. Trademark Claims DN registration by Registries . . . . 27 98 5.3.3. TMBD Claims Services for Registries . . . . . . . . . 29 99 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 29 100 5.3.3.2. Notice of Registered Domain Names . . . . . . . . 30 101 5.3.4. Trademark Claims DN Registration by Registrars . . . . 31 102 5.3.5. TMBD Claims Services for Registrars . . . . . . . . . 33 103 5.3.5.1. Claims Notice Information Service . . . . . . . . 33 104 5.4. Qualified Launch Program Period . . . . . . . . . . . . . 34 105 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 34 106 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . . 36 107 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 36 108 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 37 109 6.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 37 110 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 39 111 6.3. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 41 112 6.3.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 46 113 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . . 49 114 6.4. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 53 115 6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 55 116 6.6. Sunrise List File . . . . . . . . . . . . . . . . . . . . 63 117 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 65 118 7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 65 119 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 120 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 121 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 122 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 123 11.1. Normative References . . . . . . . . . . . . . . . . . . . 70 124 11.2. Informative References . . . . . . . . . . . . . . . . . . 70 125 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72 127 1. Introduction 129 Domain Name Registries may operate in special modes within certain 130 periods of time to facilitate registration of domain names. 132 Along with the introduction of new generic Top-Level Domains (gTLD), 133 two special modes will come into effect: 135 o Sunrise Period, the Sunrise Period allows trademark holders an 136 advance opportunity to register domain names corresponding to 137 their marks before names are generally available to the public. 139 o Trademark Claims Period, the Trademark Claims Period follows the 140 Sunrise Period and runs for at least the first 90 days of an 141 initial operating period of general registration. During the 142 Trademark Claims Period, anyone attempting to register a domain 143 name matching a mark that is recorded in the Trademark 144 Clearinghouse will receive a notification displaying the relevant 145 mark information. 147 This document describes the requirements, the architecture and the 148 interfaces between the Trademark Clearing House (TMCH) and Domain 149 Name Registries (called Registries in the rest of the document) as 150 well as between the TMCH and Domain Name Registrars (called 151 Registrars in the rest of the document) for the provisioning and 152 management of domain names during the Sunrise and Trademark Claims 153 Periods. 155 For any date and/or time indications, Coordinated Universal Time 156 (UTC) applies. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 XML is case sensitive. Unless stated otherwise, XML specifications 165 and examples provided in this document MUST be interpreted in the 166 character case presented in order to develop a conforming 167 implementation. 169 "tmNotice-1.0" is used as an abbreviation for 170 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 171 "tmNotice" is used, but implementations MUST NOT depend on it and 172 instead employ a proper namespace-aware XML parser and serializer to 173 interpret and output the XML documents. 175 3. Glossary 177 In the following section, the most common terms are briefly 178 explained: 180 o Backend Registry Operator: Entity that manages (a part of) the 181 technical infrastructure for a Registry Operator. The Registry 182 Operator may also be the Backend Registry Operator. 184 o CA: Certificate Authority, see [RFC5280]. 186 o CNIS, Claims Notice Information Service: This service provides 187 TCNs to Registrars. 189 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 190 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 192 o CRL: Certificate Revocation List, see [RFC5280]. 194 o CSV: Comma-Separated Values, see [RFC4180] 196 o Date and time, datetime: Date and time are specified following the 197 standard "Date and Time on the Internet specification", see 198 [RFC3339]. 200 o DN: Domain Name, domain name, see definition of Domain name in 201 [I-D.ietf-dnsop-dns-terminology]. 203 o DN Repository Object IDentifier, DNROID: an identifier assigned by 204 the Registry to each DN object that unequivocally identifies said 205 DN object. For example, if a new DN object is created for a name 206 that existed in the past, the DN objects will have different 207 DNROIDs. 209 o DNL, Domain Name Label, see definition of Label in 210 [I-D.ietf-dnsop-dns-terminology]. 212 o DNL List: A list of DNLs that are covered by a PRM. 214 o DNS: Domain Name System, see [I-D.ietf-dnsop-dns-terminology]. 216 o Effective allocation: A DN is considered effectively allocated 217 when the DN object for the DN has been created in the SRS of the 218 Registry and has been assigned to the effective user. A DN object 219 in status "pendingCreate" or any other status that precedes the 220 first time a DN is assigned to an end-user is not considered an 221 effective allocation. A DN object created internally by the 222 Registry for subsequent delegation to another Registrant is not 223 considered an effective allocation. 225 o EPP: The Extensible Provisioning Protocol, see definition of EPP 226 in [I-D.ietf-dnsop-dns-terminology]. 228 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 229 [I-D.ietf-dnsop-dns-terminology]. 231 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 233 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 235 o IDN: Internationalized Domain Name, see definition of IDN in 236 [I-D.ietf-dnsop-dns-terminology]. 238 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 239 Z0-9/] to be used as the lookup Key by Registrars to obtain the 240 TCN using the CNIS. Lookup Keys are unique and are related to one 241 DNL only. 243 o LORDN, List of Registered Domain Names: This is the list of 244 effectively allocated DNs matching a DNL of a PRM. Registries 245 will upload this list to the TMDB (during the NORDN process). 247 o NORDN, Notification of Registered Domain Names: The process by 248 which Registries upload their recent LORDN to the TMDB. 250 o PGP: Pretty Good Privacy, see [RFC4880] 252 o PKI: Public Key Infrastructure, see [RFC5280]. 254 o PRM, Pre-registered mark: Mark that has been pre-registered with 255 the TMCH. 257 o Qualified Launch Program period, QLP period: During this OPTIONAL 258 period, a special process applies to DNs matching the Sunrise List 259 and/or the DNL List, to ensure that TMHs are informed of a DN 260 matching their PRM. 262 o Registrant: see definition of Registrant in 263 [I-D.ietf-dnsop-dns-terminology]. 265 o Registrar, Domain Name Registrar: see definition of Registrar in 266 [I-D.ietf-dnsop-dns-terminology]. 268 o Registry, Registry Operator, Domain Name Registry: see definition 269 of Registry in [I-D.ietf-dnsop-dns-terminology]. A Registry 270 Operator is the contracting party with ICANN for the TLD. 272 o SMD, Signed Mark Data: A cryptographically signed token issued by 273 the TMV to the TMH to be used in the Sunrise Period to apply for a 274 DN that matches a DNL of a PRM; see also 275 [I-D.ietf-eppext-tmch-smd]. An SMD generated by an ICANN-approved 276 trademark validator (TMV) contains both the signed token and the 277 TMV's PKIX certificate. 279 o SMD File: A file containing the SMD (see above) and some human 280 readable data. The latter is usually ignored in the processing of 281 the SMD File. See also Section 6.4. 283 o SMD Revocation List: The SMD Revocation List is used by Registries 284 (and optionally by Registrars) during the Sunrise Period to ensure 285 that an SMD is still valid (i.e. not revoked). The SMD Revocation 286 List has a similar function as CRLs used in PKI. 288 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 289 lists of revoked SMDs (SMD Revocation List); see also 290 [I-D.ietf-eppext-tmch-smd] 292 o SRS: Shared Registration System, see also 293 [ICANN-GTLD-AGB-20120604]. 295 o Sunrise List, SURL: The list of DNLs that are covered by a PRM and 296 eligible for Sunrise. 298 o Sunrise Period: During this period DNs matching a DNL of a PRM can 299 be exclusively obtained by the respective TMHs. For DNs matching 300 a PRM, a special process applies to ensure that TMHs are informed 301 on the effective allocation of a DN matching their PRM. 303 o TLD: Top-Level Domain Name, see definition of TLD in 304 [I-D.ietf-dnsop-dns-terminology]. 306 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 307 ICANN central repository for information to be authenticated, 308 stored, and disseminated, pertaining to the rights of TMHs. The 309 Trademark Clearinghouse is split into two functions TMV and TMDB 310 (see below). There could be several entities performing the TMV 311 function, but only one entity performing the TMDB function. 313 o TMCH-CA: The Certificate Authority (CA) for the TMCH. This CA is 314 operated by ICANN. The public key for this CA is the trust anchor 315 used to validate the identity of each TMV. 317 o TMDB, Trademark Clearinghouse Database: Serves as a database of 318 the TMCH to provide information to the new gTLD Registries and 319 Registrars to support Sunrise or Claims services. There is only 320 one TMDB in the TMCH that concentrates the information about the 321 "verified" Trademark records from the TMVs. 323 o TMH, Trademark Holder: The person or organization owning rights on 324 a mark. 326 o TMV, Trademark Validator, Trademark validation organization: An 327 entity authorized by ICANN to authenticate and validate 328 registrations in the TMDB ensuring the marks qualify as registered 329 or are court-validated marks or marks that are protected by 330 statute or treaty. This entity would also be asked to ensure that 331 proof of use of marks is provided, which can be demonstrated by 332 furnishing a signed declaration and one specimen of current use. 334 o Trademark, mark: Marks are used to claim exclusive properties of 335 products or services. A mark is typically a name, word, phrase, 336 logo, symbol, design, image, or a combination of these elements. 337 For the scope of this document only textual marks are relevant. 339 o Trademark Claims, Claims: Provides information to enhance the 340 understanding of the Trademark rights being claimed by the TMH. 342 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 343 Trademark Claims Notice consist of one or more Trademark Claims 344 and are provided to prospective Registrants of DNs. 346 o Trademark Claims Notice Identifier, TCNID: An element of the 347 Trademark Claims Notice (see above), identifying said TCN. The 348 Trademark Claims Notice Identifier is specified in the element 349 . 351 o Trademark Claims Period: During this period, a special process 352 applies to DNs matching the DNL List, to ensure that TMHs are 353 informed of a DN matching their PRM. For DNs matching the DNL 354 List, Registrars show a TCN to prospective Registrants that has to 355 be acknowledged before effective allocation of the DN. 357 o UTC: Coordinated Universal Time, as maintained by the Bureau 358 International des Poids et Mesures (BIPM); see also [RFC3339]. 360 4. Architecture 362 4.1. Sunrise Period 364 Architecture Sunrise Period 366 SMD hand over (out of band; 367 trivial if Registrant == TMH) 368 .............................................. 369 : : 370 : .'''''''''''''''''''. : 371 : . TMCH . : 372 : ..................... : 373 v . . : 374 .------------. . .-------------. . hv .-----. 375 | Registrant | . | TMV |<---------->| TMH | 376 '------------' . '-------------' . vh '-----' 377 | . | ^ \ . 378 | . | | \. 379 tr | . vs | | dv \ 380 | . | | .\ 381 v . v | . \ 382 .-----------. sr . .---. | . \ 383 .->| Registrar |<.........| S | vd | . \ 384 : '-----------' . | M | | . \ 385 : | sy . | D | v . \ 386 : ry | .-----------| M | .---. . vc \ 387 : | | . '---' | T | . \ 388 : v v . | M | . v 389 : .-----------. . | D | . .---------. 390 : | Registry |----------------->| B | . | TMCH-CA | 391 : '-----------' . yd '---' . '---------' 392 : ^ . . | : 393 : | ''''''''''''''''''' | : 394 : | cy | : 395 : cr '---------------------------------------' : 396 :....................................................: 398 Figure 1 400 4.2. Trademark Claims Period 402 Architecture Trademark Claims Period 404 .'''''''''''''. 405 . TMCH . 406 ............... 407 . . 408 .------------. . .-------. . hv .-----. 409 | Registrant | . | TMV |<---------->| TMH | 410 '------------' . '-------' . vh '-----' 411 | . ^ . 412 | . | dv . 413 tr | . vd | . 414 v . v . 415 .-----------. dr . .-------. . 416 | Registrar |<--------| T | . 417 '-----------' . | | . 418 | . | M | . 419 ry | . | | . 420 v . | D | . 421 .----------. dy . | | . 422 | Registry |<------->| B | . 423 '----------' yd . '-------' . 424 . . 425 ''''''''''''' 427 Figure 2 429 4.3. Interfaces 431 In the sub-sections below follows a short description of each 432 interface to provide an overview of the architecture. More detailed 433 descriptions of the relevant interfaces follow further below 434 (Section 5). 436 4.3.1. hv 438 The TMH registers a mark with a TMV via the hv interface. 440 After the successful registration of the mark, the TMV makes 441 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 442 TMH to be used during the Sunrise Period. 444 The specifics of the hv interface are beyond the scope of this 445 document. 447 4.3.2. vd 449 After successful mark registration, the TMV ensures the TMDB inserts 450 the corresponding DNLs and mark information into the database via the 451 vd interface. 453 The specifics of the vd interface are beyond the scope of this 454 document. 456 4.3.3. dy 458 Not used during the Sunrise Period. 460 During the Trademark Claims Period the Registry fetches the latest 461 DNL List from the TMDB via the dy interface in regular intervals. 462 The protocol used on the dy interface is HTTPS. 464 4.3.4. tr 466 The Registrant communicates with the Registrar via the tr interface. 468 The specifics of the tr interface are beyond the scope of this 469 document. 471 4.3.5. ry 473 The Registrar communicate with the Registry via the ry interface. 474 The ry interfaces is typically implemented in EPP. 476 4.3.6. dr 478 Not used during the Sunrise Period. 480 During the Trademark Claims Period, the Registrar fetches the TCN 481 from the TMDB (to be displayed to the Registrant via the tr 482 interface) via the dr interface. The protocol used for fetching the 483 TCN is HTTPS. 485 4.3.7. yd 487 During the Sunrise period the Registry notifies the TMDB via the yd 488 interface of all DNs effectively allocated. 490 During the Trademark Claims period, the Registry notifies the TMDB 491 via the yd interface of all DNs effectively allocated that matched an 492 entry in the Registry previously downloaded DNL List during the 493 creation of the DN. 495 The protocol used on the yd interface is HTTPS. 497 4.3.8. dv 499 The TMDB notifies via the dv interface to the TMV of all DNs 500 effectively allocated that match a mark registered by that TMV. 502 The specifics of the dv interface are beyond the scope of this 503 document. 505 4.3.9. vh 507 The TMV notifies the TMH via the vh interface after a DN has been 508 effectively allocated that matches a PRM of this TMH. 510 The specifics of the vh interface are beyond the scope of this 511 document. 513 4.3.10. vs 515 The TMV requests to add a revoked SMD to the SMD Revocation List at 516 the SMDM. 518 The specifics of the vs interface are beyond the scope of this 519 document. 521 Not relevant during the Trademark Claims Period. 523 4.3.11. sy 525 During the Sunrise Period the Registry fetches the most recent SMD 526 Revocation List from the SMDM via the sy interface in regular 527 intervals. The protocol used on the sy interface is HTTPS. 529 Not relevant during the Trademark Claims Period. 531 4.3.12. sr 533 During the Sunrise Period the Registrar may fetch the most recent SMD 534 Revocation List from the SMDM via the sr interface. The protocol 535 used on the sr interface is the same as on the sy interface (s. 536 above), i.e. HTTPS. 538 Not relevant during the Trademark Claims Period. 540 4.3.13. vc 542 The TMV registers its public key, and requests to revoke an existing 543 key, with the TMCH-CA over the vc interface. 545 The specifics of the vc interface are beyond the scope of this 546 document, but it involves personal communication between the 547 operators of the TMV and the operators of the TMCH-CA. 549 Not relevant during the Trademark Claims Period. 551 4.3.14. cy 553 During the Sunrise Period the Registry fetches the most recent CRL 554 from the TMCH-CA via the cy interface at regular intervals. The CRL 555 is used for validation of TMV certificates. The protocol used on the 556 cy interface is HTTPS. 558 Not relevant during the Trademark Claims Period. 560 4.3.15. cr 562 During the Sunrise Period the Registrar optionally fetches the most 563 recent CRL from the TMCH-CA via the cr interface at regular 564 intervals. The CRL is used for validation of TMV certificates. The 565 protocol used on the cr interface is HTTPS. 567 Not relevant during the Trademark Claims Period. 569 5. Process Descriptions 571 5.1. Bootstrapping 573 5.1.1. Bootstrapping for Registries 575 5.1.1.1. Credentials 577 Each Registry Operator will receive authentication credentials from 578 the TMDB/SMDM to be used: 580 o During the Sunrise Period to fetch the SMD Revocation List from 581 the SMDM via the sy interface (Section 4.3.11). 583 o During Trademark Claims Period to fetch the DNL List from the TMDB 584 via the dy interface (Section 4.3.3). 586 o During the NORDN process to notify the LORDN to the TMDB via the 587 yd interface (Section 4.3.7). 589 Note: credentials are created per TLD and provided to the Registry 590 Operator. 592 5.1.1.2. IP Addresses for Access Control 594 Each Registry Operator MUST provide to the TMDB all IP addresses that 595 will be used to: 597 o Fetch the SMD Revocation List via the sy interface 598 (Section 4.3.11). 600 o Fetch the DNL List from the TMDB via the dy interface 601 (Section 4.3.3). 603 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 605 This access restriction MAY be applied by the TMDB/SMDM in addition 606 to HTTP Basic access authentication (for credentials to be used, see 607 Section 5.1.1.1). 609 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 610 Registry Operator. 612 5.1.1.3. TMCH Trust Anchor 614 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 615 the TMCH-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 616 be used: 618 o During the Sunrise Period to validate the TMV certificates and the 619 CRL of TMV certificates. 621 5.1.1.4. TMDB/SMDM PGP Key 623 The TMDB MUST provide each Registry Operator with the public portion 624 of the PGP Key used by TMDB and SMDM, to be used: 626 o During the Sunrise Period to perform integrity checking of the SMD 627 Revocation List fetched from the SMDM via the sy interface 628 (Section 4.3.11). 630 o During Trademark Claims Period to perform integrity checking of 631 the DNL List fetched from the TMDB via the dy interface 632 (Section 4.3.3). 634 5.1.2. Bootstrapping for Registrars 636 5.1.2.1. Credentials 638 Each ICANN-accredited Registrar will receive authentication 639 credentials from the TMDB to be used: 641 o During the Sunrise Period to (optionally) fetch the SMD Revocation 642 List from the SMDM via the sr interface (Section 4.3.12). 644 o During Trademark Claims Period to fetch TCNs from the TMDB via the 645 dr interface (Section 4.3.6). 647 5.1.2.2. IP Addresses for Access Control 649 Each Registrar MUST provide to the TMDB all IP addresses, which will 650 be used to: 652 o Fetch the SMD Revocation List via the sr interface 653 (Section 4.3.12). 655 o Fetch TCNs via the dr interface (Section 4.3.6). 657 This access restriction MAY be applied by the TMDB/SMDM in addition 658 to HTTP Basic access authentication (for credentials to be used, see 659 Section 5.1.2.1). 661 The TMDB MAY limit the number of IP addresses to be accepted per 662 Registrar. 664 5.1.2.3. TMCH Trust Anchor 666 Registrars MAY fetch the PKIX certificate of the TMCH-CA (Trust 667 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 669 o During the Sunrise Period to (optionally) validate the TMV 670 certificates and the CRL of TMV certificates. 672 5.1.2.4. TMDB PGP Key 674 Registrars MUST receive the public portion of the PGP Key used by 675 TMDB and SMDM from the TMDB administrator to be used: 677 o During the Sunrise Period to (optionally) perform integrity 678 checking of the SMD Revocation List fetched from the SMDM via the 679 sr interface (Section 4.3.12). 681 5.2. Sunrise Period 683 5.2.1. Domain Name Registration 685 Registration during Sunrise Period 687 .------------. .-----------. .----------. 688 | Registrant | | Registrar | | Registry | 689 '------------' '-----------' '----------' 690 | | | 691 | Request DN | | 692 | Registration | | 693 | (with SMD) | | 694 |---------------->| Check DN availability | 695 | |---------------------------->| 696 | | | 697 | | DN unavailable .-------------. 698 | DN unavailable |<--------------------( DN available? ) 699 |<----------------| no '-------------' 700 | | | yes 701 | | DN available | 702 | |<----------------------------| 703 | | | 704 | | Request DN registration | 705 | | (with SMD) | 706 | |---------------------------->| 707 | | | 708 | | .------------------------------. 709 | | | DN registration validation / | 710 | | | SMD validation | 711 | | '------------------------------' 712 | | | 713 | Registration |.-----------. Error .----------------------. 714 | Error || TRY AGAIN |<-----( Validation successful? ) 715 |<----------------|| / ABORT | no '----------------------' 716 | |'-----------' | yes 717 | | | 718 | | DN registered | 719 | DN registered |<----------------------------| 720 |<----------------| | 721 | | | 723 Figure 3 725 Note: the figure depicted above represents a synchronous DN 726 registration workflow (usually called first come first served). 728 5.2.2. Sunrise DN Registration by Registries 730 Registries MUST perform a minimum set of checks for verifying each DN 731 registration during the Sunrise Period upon reception of a 732 registration request over the ry interface (Section 4.3.5). If any 733 of these checks fails the Registry MUST abort the registration. Each 734 of these checks MUST be performed before the DN is effectively 735 allocated. 737 In case of asynchronous registrations (e.g. auctions), the minimum 738 set of checks MAY be performed when creating the intermediate object 739 (e.g. a DN application) used for DN registration. If the minimum set 740 of checks is performed when creating the intermediate object (e.g. a 741 DN application) a Registry MAY effective allocate the DN without 742 performing the minimum set of checks again. 744 Performing the minimum set of checks Registries MUST verify that: 746 1. A SMD has been received from the Registrar along with the DN 747 registration. 749 2. The certificate of the TMV has been correctly signed by the 750 TMCH-CA. (The certificate of the TMV is contained within the 751 SMD.) 753 3. The time when the validation is done is within the validity 754 period of the TMV certificate. 756 4. The certificate of the TMV is not be listed in the CRL file 757 specified in the CRL distribution point of the TMV certificate. 759 5. The signature of the SMD (signed with the TMV certificate) is 760 valid. 762 6. The time when the validation is done is within the validity 763 period of the SMD based on and 764 elements. 766 7. The SMD has not been revoked, i.e., is not contained in the SMD 767 Revocation List. 769 8. The leftmost DNL (A-label in case of IDNs) of the DN being 770 effectively allocated matches one of the labels () 771 elements in the SMD. 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 SMDM 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 SMD Revocation List 795 .----------. .------. 796 | Registry | | SMDM | 797 '----------' '------' 798 | | 799 .----------------. | 800 | Periodically, | | 801 | at least | | 802 | every 24 hours | | 803 '----------------' | 804 | | 805 |----------------------------------------------------->| 806 | Download latest revocation list for SMD certificates | 807 |<-----------------------------------------------------| 808 | | 809 | | 811 Figure 4 813 5.2.3.2. Certificate Revocation List 815 Registries MUST refresh their local copy of the CRL at least every 24 816 hours using the CRL distribution point specified in the TMV 817 certificate. 819 Operationally, the CRL file and CRL distribution point is the same 820 for all TMVs and (at publication of this document) located at 821 < http://crl.icann.org/tmch.crl >. 823 Note: the 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 CRL file once every 826 24 hours, the CRL file could be used for all the TLDs managed by the 827 Backend Registry Operator. 829 Update CRL for TMV certificates 831 .----------. .---------. 832 | Registry | | TMCH-CA | 833 '----------' '---------' 834 | | 835 .----------------. | 836 | Periodically, | | 837 | at least | | 838 | every 24 hours | | 839 '----------------' | 840 | | 841 |------------------------------------------->| 842 | Download latest CRL for TMV certificates | 843 |<-------------------------------------------| 844 | | 845 | | 847 Figure 5 849 5.2.3.3. Notice of Registered Domain Names 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 Claims period (same applies to DNs effectively 875 allocated using applications created during the Sunrise or Claims 876 period in case of using asynchronous registrations). 878 The yd interface (Section 4.3.7) MUST support at least 1 and MAY 879 support up to 10 concurrent connections from each IP address 880 registered by a Registry Operator to access the service. 882 The TMDB MUST process each uploaded LORDN file and make the related 883 log file available for Registry download within 30 minutes of the 884 finalization of the upload. 886 NORDN 888 .----------. .------. .-----. .-----. 889 | Registry | | TMDB | | TMV | | TMH | 890 '----------' '------' '-----' '-----' 891 | | | | 892 .------------------. | | | 893 | Periodically | | | | 894 | upload LORDN | | | | 895 | file | | | | 896 '------------------' | | | 897 | | | | 898 .--------->| Upload LORDN | | | 899 | |-------------------->| | | 900 | | | | | 901 | | .-------------------------. | | 902 | | | Verify each domain name | | | 903 | | | in the uploaded file | | | 904 | | | (within 30') | | | 905 | | '-------------------------' | | 906 | | | ._____.| | 907 | | Download Log file | | END || | 908 | |<--------------------| '-----'| | 909 | | | ^ | | 910 | .-----------------. .---------------. | | | 911 | | Check whether | / everything fine \ no | | | 912 | | Log file | ( (i.e. no errors )---' | | 913 | | contains errors | \ in Log file )? / | | 914 | '-----------------' '---------------' | | 915 | | | yes | | 916 | .---------------. | | | 917 | / everything fine \ yes | | | 918 |( (i.e. no errors )-----. | Notify TMVs | | 919 | \ in Log file )? / | | on the LORDN | | 920 | '---------------' | | pre-registered | | 921 | | no v | with said TMV | | 922 | .----------------. .------. |--------------->| | 923 '-| Correct Errors | | DONE | | | | 924 '----------------' '------' | | Notify each | 925 | | | affected TMH | 926 | | |-------------->| 927 | | | | 929 Figure 6 931 The format used for the LORDN is described in Section 6.3 933 5.2.4. Sunrise DN registration by Registrars 935 Registrars MAY choose to perform the checks for verifying DN 936 registrations as performed by the Registries (see Section 5.2.2) 937 before sending the command to register a DN. 939 5.2.5. TMDB Sunrise Services for Registrars 941 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 942 also available for Registrars to optionally validate the SMDs 943 received. 945 5.3. Trademark Claims Period 947 5.3.1. Domain Registration 949 Registration during Trademark Claims Period 951 .------------. .-----------. .----------. .------. 952 | Registrant | | Registrar | | Registry | | TMDB | 953 '------------' '-----------' '----------' '------' 954 | Request DN | | | 955 | Registration | | | 956 |--------------->| Check DN availability | | 957 | |--------------------------->| | 958 | | DN unavailable .-------------. | 959 | DN unavailable |<-------------------( DN available? ) | 960 |<---------------| no '-------------' | 961 | | DN available | yes | 962 | |<---------------------------| | 963 | | Request Lookup key | | 964 | |--------------------------->| | 965 | |.__________. .---------. | 966 | || CONTINUE | / Does DN \ | 967 | || NORMALLY |<--------( match DNL ) | 968 | |'----------' no \ of PRM? / | 969 | | '---------' | 970 | | Lookup key | yes | 971 | |<----------------------------' | 972 | | | 973 .-----. | | Request Claims Notice | 974 |ABORT| | Display |---------------------------------------->| 975 '-----' | Claims | Return Claims Notice | 976 ^ | Notice |<----------------------------------------| 977 | no |<---------------| | 978 | .------. yes | | 979 '-( Ack? )----------->| Register DN (with TCNID) | | 980 '------' |--------------------------->| | 981 | Registration | Error .----------------------. | 982 | Error |<-------------( Validation successful? ) | 983 |<---------------| no '----------------------' | 984 | | | yes | 985 | | DN registered | | 986 | DN registered |<---------------------------| | 987 |<---------------| | | 989 Figure 7 991 Note: the figure depicted above represents a synchronous DN 992 registration workflow (usually called first come first served). 994 5.3.2. Trademark Claims DN registration by Registries 996 During Trademark Claim Periods, Registries perform two main 997 functions: 999 o Registries MUST provide Registrars (over the ry interface, 1000 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 1001 that match the DNL List. 1003 o Registries MUST provide the Lookup Key only when queried about a 1004 specific DN. 1006 o For each DN matching a DNL of a PRM, Registries MUST perform a 1007 minimum set of checks for verifying DN registrations during 1008 Trademark Claims Period upon reception of a registration request 1009 over the ry interface (Section 4.3.5). If any of these checks 1010 fails the Registry MUST abort the registration. Each of these 1011 checks MUST be performed before the DN is effectively allocated. 1013 o In case of asynchronous registrations (e.g. auctions), the minimum 1014 set of checks MAY be performed when creating the intermediate 1015 object (e.g. a DN application) used for DN effective allocation. 1016 If the minimum set of checks is performed when creating the 1017 intermediate object (e.g. a DN application) a Registry MAY 1018 effective allocate the DN without performing the minimum set of 1019 checks again. 1021 o Performing the minimum set of checks Registries MUST verify that: 1023 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been 1025 received from the Registrar along with the DN registration. 1027 If the three elements mentioned above are not provided by 1028 the Registrar for a DN matching a DNL of a PRM, but the DNL 1029 was inserted (or re-inserted) for the first time into DNL 1030 List less than 24 hours ago, the registration MAY continue 1031 without this data and the tests listed below are not 1032 required to be performed. 1034 2. The TCN has not expired (according to the expiration datetime 1035 sent by the Registrar). 1037 3. The acceptance datetime is no more than 48 hours in the past. 1039 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1040 being registered, the expiration datetime provided by the 1041 registrar, and the TMDB Notice Identifier extracted from the 1042 TCNID provided by the registrar compute the TCN Checksum. 1043 Verify that the computed TCN Checksum match the TCN Checksum 1044 present in the TCNID. 1046 These procedures apply to all DN registrations at the second level as 1047 well as to all other levels subordinate to the TLD that the Registry 1048 accepts registrations for. 1050 5.3.3. TMBD Claims Services for Registries 1052 5.3.3.1. Domain Name Label (DNL) List 1054 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1055 and 12:00:00 UTC. 1057 Registries MUST refresh the latest version of the DNL List at least 1058 once every 24 hours. 1060 Update DNL List 1062 .----------. .------. 1063 | Registry | | TMDB | 1064 '----------' '------' 1065 | | 1066 .----------------. | 1067 | Periodically, | | 1068 | at least | | 1069 | every 24 hours | | 1070 '----------------' | 1071 | | 1072 |-------------------------------->| 1073 | Download latest list of DNLs | 1074 |<--------------------------------| 1075 | | 1076 | | 1078 Figure 8 1080 Note: the DNL List will be the same regardless of the TLD. If a 1081 Backend Registry Operator manages the infrastructure of several TLDs, 1082 the Backend Registry Operator could refresh the DNL List once every 1083 24 hours, the DNL List could be used for all the TLDs managed by the 1084 Backend Registry Operator. 1086 5.3.3.2. Notice of Registered Domain Names 1088 The NORDN process during the Trademark Claims Period is almost the 1089 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1090 difference that only registrations subject to a Trademark Claim 1091 (i.e., at registration time the name appeared in the current DNL List 1092 downloaded by the Registry Operator) are included in the LORDN. 1094 5.3.4. Trademark Claims DN Registration by Registrars 1096 For each DN matching a DNL of a PRM, Registrars MUST perform the 1097 following steps: 1099 1. Use the Lookup Key received from the Registry to obtain the TCN 1100 from the TMDB using the dr interface (Section 4.3.6) Registrars 1101 MUST only query for the Lookup Key of a DN that is available for 1102 registration. 1104 2. Present the TCN to the Registrant as described in Exhibit A, 1105 [RPM-Requirements]. 1107 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1108 consent with the TCN, before any further processing. (The 1109 transmission of a TCNID to the Registry over the ry interface, 1110 Section 4.3.5 implies that the Registrant has expressed his/her 1111 consent with the TCN.) 1113 4. Perform the minimum set of checks for verifying DN registrations. 1114 If any of these checks fails the Registrar MUST abort the DN 1115 registration. Each of these checks MUST be performed before the 1116 registration is sent to the Registry. Performing the minimum set 1117 of checks Registrars MUST verify that: 1119 1. The time when the validation is done is within the TCN 1120 validity based on the and elements. 1123 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1124 effectively allocated matches the label () 1125 element in the TCN. 1127 3. The Registrant has acknowledged (expressed his/her consent 1128 with) the TCN. 1130 5. Record the date and time when the registrant acknowledged the 1131 TCN. 1133 6. Send the registration to the Registry (ry interface, 1134 Section 4.3.5) and include the following information: 1136 * TCNID () 1138 * Expiration date of the TCN () 1140 * Acceptance datetime of the TCN. 1142 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the 1144 TMDB, allowing the implementation of a cache by Registrars and enough 1145 time for acknowledging the TCN. Registrars SHOULD implement a cache 1146 of TCNs to minimize the number of queries sent to the TMDB. A cached 1147 TCN MUST be removed from the cache after the expiration date of the 1148 TCN as defined by . The TMDB MAY implement rate- 1149 limiting as one of the protection mechanisms to mitigate the risk of 1150 performance degradation. 1152 5.3.5. TMBD Claims Services for Registrars 1154 5.3.5.1. Claims Notice Information Service 1156 The TCNs are provided by the TMDB online and are fetched by the 1157 Registrar via the dr interface (Section 4.3.6). 1159 To get access to the TCNs, the Registrar needs the credentials 1160 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1161 from the Registry via the ry interface (Section 4.3.5). The dr 1162 interface (Section 4.3.6) uses HTTPS with Basic access 1163 authentication. 1165 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1166 connections from each Registrar. 1168 The URL of the dr interface (Section 4.3.6) is: 1170 < https:///cnis/.xml > 1172 Note that the "lookupkey" may contain SLASH characters ("/"). The 1173 SLASH character is part of the URL path and MUST NOT be escaped when 1174 requesting the TCN. 1176 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1177 MUST be signed by a well-know public CA. Registrars MUST perform the 1178 Certification Path Validation described in Section 6 of [RFC5280]. 1179 Registrars will be authenticated in the dr interface using HTTP Basic 1180 access authentication. The dr (Section 4.3.6) interface MUST support 1181 HTTPS keep-alive and MUST maintain the connection for up to 30 1182 minutes. 1184 5.4. Qualified Launch Program Period 1186 5.4.1. Domain Registration 1188 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1189 (QLP) period effective allocations of DNs to third parties could 1190 require that Registries and Registrars provide Sunrise and/or Claims 1191 services. If required, Registries and Registrars MUST provide 1192 Sunrise and/or Claims services as described in: Section 5.2 and 1193 Section 5.3. 1195 The effective allocation scenarios are: 1197 o If the leftmost DNL (A-label in case of IDNs) of the DN being 1198 effectively allocated (QLP Name in this section) matches a DNL in 1199 the SURL, and an SMD is provided, then Registries MUST provide 1200 Sunrise Services (see Section 5.2) and the DN MUST be reported in 1201 a Sunrise LORDN file during the QLP period. 1203 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1204 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1205 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1206 file using the special SMD-id "99999-99999" during the QLP period. 1208 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1209 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1210 [QLP-Addendum]), then Registries MUST provide Claims services (see 1211 Section 5.3) and the DN MUST be reported in a Claims LORDN file 1212 during the QLP period. 1214 o If the QLP Name matches a DNL in the DNL List but does not match a 1215 DNL in the SURL, then Registries MUST provide Claims services (see 1216 Section 5.2) and the DN MUST be reported in a Claims LORDN file 1217 during the QLP period. 1219 The following table lists all the effective allocation scenarios 1220 during a QLP Period: 1222 +--------+---------+-----------------+-------------+----------------+ 1223 | QLP | QLP | SMD was | Registry | Registry MUST | 1224 | Name | Name | provided by the | MUST | report DN | 1225 | match | match | potential | provide | registration | 1226 | in the | in the | Registrant | Sunrise or | in | 1227 | SURL | DNL | | Claims | LORDN file | 1228 | | List | | Services | | 1229 +--------+---------+-----------------+-------------+----------------+ 1230 | Y | Y | Y | Sunrise | Sunrise | 1231 | | | | | | 1232 | Y | N | Y | Sunrise | Sunrise | 1233 | | | | | | 1234 | N | Y | -- | Claims | Claims | 1235 | | | | | | 1236 | N | N | -- | -- | -- | 1237 | | | | | | 1238 | Y | Y | N (see section | Claims | Claims | 1239 | | | 2.2 of | | | 1240 | | | [QLP-Addendum]) | | | 1241 | | | | | | 1242 | Y | N | N (see section | -- | Sunrise (using | 1243 | | | 2.2 of | | special | 1244 | | | [QLP-Addendum]) | | SMD-id) | 1245 +--------+---------+-----------------+-------------+----------------+ 1247 QLP Effective Allocation Scenarios 1249 The TMDB MUST provide the following services to Registries during a 1250 QLP period: 1252 o SMD Revocation List (see Section 5.2.3.1) 1254 o Notice of Registered Domain Names (see Section 5.2.3.3) 1256 o Domain Name Label List (see Section 5.3.3.1) 1258 o Sunrise List (see Section 5.4.2.1 1260 The TMDB MUST provide the following services to Registrars during a 1261 QLP period: 1263 o SMD Revocation List (see Section 5.2.3.1) 1265 o Claims Notice Information Service (see Section 5.3.5.1) 1267 5.4.2. TMBD QLP Services for Registries 1269 5.4.2.1. Sunrise List (SURL) 1271 A new Sunrise List MUST be published by the TMDB twice a day, by 00: 1272 00:00 and 12:00:00 UTC. 1274 Registries offering the OPTIONAL QLP period MUST refresh the latest 1275 version of the Sunrise List at least once every 24 hours. 1277 Update Sunrise List 1279 .----------. .------. 1280 | Registry | | TMDB | 1281 '----------' '------' 1282 | | 1283 .----------------. | 1284 | Periodically, | | 1285 | at least | | 1286 | every 24 hours | | 1287 '----------------' | 1288 | | 1289 |-------------------------------->| 1290 | Download latest list of DNLs | 1291 |<--------------------------------| 1292 | | 1293 | | 1295 Figure 9 1297 Note: the Sunrise List will be the same regardless of the TLD. If a 1298 Backend Registry Operator manages the infrastructure of several TLDs, 1299 the Backend Registry Operator could refresh the Sunrise List once 1300 every 24 hours, the Sunrise List could be used for all the TLDs 1301 managed by the Backend Registry Operator. 1303 6. Data Format Descriptions 1305 6.1. DNL List file 1307 This section defines the format of the list containing every Domain 1308 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1309 is maintained by the TMDB and downloaded by Registries in regular 1310 intervals (see Section 5.3.3.1). The Registries use the DNL List 1311 during the Trademark Claims period to check whether a requested DN 1312 matches a DNL of a PRM. 1314 The DNL List contains all the DNLs covered by a PRM present in the 1315 TMDB at the time it is generated. 1317 The DNL List is contained in a CSV formatted file that has the 1318 following structure: 1320 o first line: , 1322 Where: 1324 + , version of the file, this field MUST be 1. 1326 + , date and time in UTC that the 1327 DNL List was created. 1329 o second line: a header line as specified in [RFC4180] 1331 With the header names as follows: 1333 DNL,lookup-key,insertion-datetime 1335 o One or more lines with: ,, 1338 Where: 1340 + , a Domain Name Label covered by a PRM. 1342 + , lookup key that the Registry MUST provide to 1343 the Registrar. The lookup key has the following format: 1344
////, where: 1347 - YYYY: year that the TCN was generated. 1349 - MM: zero-padded month that the TCN was generated. 1351 - DD: zero-padded day that the TCN was generated. 1353 - vv: version of the TCN, possible values are 00 and 01. 1355 - X: one hexadecimal digit [0-9A-F]. This is the first, 1356 second and third hexadecimal digit of encoding the 1357 in base16 as specified in [RFC4648]. 1359 - Random bits: 144 random bits encoded in base64url as 1360 specified in [RFC4648]. 1362 - Sequential number: zero-padded natural number in the 1363 range 0000000001 to 2147483647. 1365 + , datetime in UTC that the DNL was 1366 first inserted into the DNL List. The possible two values 1367 of time for inserting a DNL to the DNL List are 00:00:00 and 1368 12:00:00 UTC. 1370 Example for DNL List 1372 1,2012-08-16T00:00:00.0Z 1373 DNL,lookup-key,insertion-datetime 1374 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1375 2010-07-14T00:00:00.0Z 1376 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1377 2012-08-16T00:00:00.0Z 1378 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1379 2011-08-16T12:00:00.0Z 1381 Figure 10 1383 To provide authentication and integrity protection, the DNL List will 1384 be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The 1385 PGP signature of the DNL List can be found in the similar URI but 1386 with extension .sig as shown below. 1388 The URL of the dy interface (Section 4.3.3) is: 1390 o < https:///dnl/dnl-latest.csv > 1392 o < https:///dnl/dnl-latest.sig > 1394 6.2. SMD Revocation List 1396 This section defines the format of the list of SMDs that have been 1397 revoked. The list is maintained by the SMDM and downloaded by 1398 Registries (and optionally by Registrars) in regular intervals (see 1399 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1400 Period to validate SMDs received. The SMD Revocation List has a 1401 similar function as CRLs used in PKI [RFC5280]. 1403 The SMD Revocation List contains all the revoked SMDs present in the 1404 TMDB at the time it is generated. 1406 The SMD Revocation List is contained in a CSV formatted file that has 1407 the following structure: 1409 o first line: , 1411 Where: 1413 + , version of the file, this field MUST be 1. 1415 + , datetime in UTC 1416 that the SMD Revocation List was created. 1418 o second line: a header line as specified in [RFC4180] 1420 With the header names as follows: 1422 smd-id,insertion-datetime 1424 o One or more lines with: , 1426 Where: 1428 + , identifier of the SMD that was revoked. 1430 + , revocation datetime in UTC of the 1431 SMD. The possible two values of time for inserting an SMD 1432 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1434 To provide integrity protection, the SMD Revocation List is PGP 1435 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1436 List is provided by the TMDB with extension .csv. The PGP signature 1437 of the SMD Revocation List can be found in the similar URI but with 1438 extension .sig as shown below. 1440 The URL of the sr interface (Section 4.3.12) and sy interface 1441 (Section 4.3.11) is: 1443 o < https:///smdrl/smdrl-latest.csv > 1445 o < https:///smdrl/smdrl-latest.sig > 1447 Example for SMD Revocation list 1449 1,2012-08-16T00:00:00.0Z 1450 smd-id,insertion-datetime 1451 2-2,2012-08-15T00:00:00.0Z 1452 3-2,2012-08-15T00:00:00.0Z 1453 1-2,2012-08-15T00:00:00.0Z 1455 Figure 11 1457 6.3. LORDN File 1459 This section defines the format of the List of Registered Domain 1460 Names (LORDN), which is maintained by each Registry and uploaded at 1461 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1462 said DN is added to the LORDN along with further information related 1463 to its registration. 1465 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1466 file is: 1468 o Sunrise LORDN file: 1470 < https:///LORDN//sunrise > 1472 o Claims LORDN file: 1474 < https:///LORDN//claims > 1476 During a QLP period, Registries MAY be required to upload Sunrise or 1477 Claims LORDN files. The URIs of the yd interface used to upload 1478 LORDN files during a QLP period is: 1480 o Sunrise LORDN file (during QLP period): 1482 < https:///LORDN//sunrise/qlp > 1484 o Claims LORDN file (during a QLP period): 1486 < https:///LORDN//claims/qlp > 1488 The yd interface (Section 4.3.7) returns the following HTTP status 1489 codes after a HTTP POST request method is received: 1491 o The interface provides a HTTP/202 status code if the interface was 1492 able to receive the LORDN file and the syntax of the LORDN file is 1493 correct. 1495 The interface provides the LORDN Transaction Identifier in the 1496 HTTP Entity-body that would be used by the Registry to download 1497 the LORDN Log file. The LORDN Transaction Identifier is a 1498 natural number zero-padded in the range 0000000000000000001 to 1499 9223372036854775807. 1501 The TMDB uses the element of the 1502 LORDN file as a unique client-side identifier. If a LORDN file 1503 with the same of a previously sent 1504 LORDN file is received by the TMDB, the LORDN Transaction 1505 Identifier of the previously sent LORDN file MUST be provided 1506 to the Registry. The TMDB MUST ignore the DN Lines present in 1507 the LORDN file if a LORDN file with the same was previously sent. 1510 The HTTP Location header field contains the URI where the LORDN 1511 Log file could be retrieved later, for example: 1513 202 Accepted 1515 Location: https:///LORDN/example/sunrise/ 1516 0000000000000000001/result 1518 o The interface provides a HTTP/400 if the request is incorrect or 1519 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1520 human readable message in the HTTP Entity-body regarding the 1521 incorrect syntax of the LORDN file. 1523 o The interface provides a HTTP/401 status code if the credentials 1524 provided does not authorize the Registry Operator to upload a 1525 LORDN file. 1527 o The TMDB MUST return a HTTP/404 status code when trying to upload 1528 a LORDN file using the 1529 https:///LORDN//sunrise/qlp or 1530 https:///LORDN//claims/qlp interface 1531 outside of a QLP period plus 26 hours. 1533 o The interface provides a HTTP/500 status code if the system is 1534 experiencing a general failure. 1536 For example, to upload the Sunrise LORDN file for TLD "example", the 1537 URI would be: 1539 < https:///LORDN/example/sunrise > 1541 The LORDN is contained in a CSV formatted file that has the following 1542 structure: 1544 o For Sunrise Period: 1546 * first line: ,, 1549 Where: 1551 - , version of the file, this field MUST be 1. 1553 - , date and time in UTC that the 1554 LORDN was created. 1556 - , number of DN Lines present in the 1557 LORDN file. 1559 * second line: a header line as specified in [RFC4180] 1561 With the header names as follows: 1563 roid,domain-name,SMD-id,registrar-id,registration- 1564 datetime,application-datetime 1566 * One or more lines with: ,,,,, 1570 Where: 1572 - , DN Repository Object IDentifier (DNROID) in the 1573 SRS. 1575 - , DN that was effectively allocated. For 1576 IDNs the A-Label (see [RFC5890]) is used. 1578 - , SMD ID used for registration. 1580 - , IANA Registrar ID. 1582 - , date and time in UTC that the 1583 domain was effectively allocated. 1585 - OPTIONAL , date and 1586 time in UTC that the application was created. The 1587 MUST be provided in 1588 case of a DN effective allocation based on an 1589 asynchronous registration (e.g., when using auctions). 1591 Example for LORDN during Sunrise 1593 1,2012-08-16T00:00:00.0Z,3 1594 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1595 application-datetime 1596 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1597 2012-07-15T00:50:00.0Z 1598 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1599 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1601 Figure 12 1603 o For Trademark Claims Period: 1605 * first line: ,, 1608 Where: 1610 - , version of the file, this field MUST be 1. 1612 - , date and time in UTC that the 1613 LORDN was created. 1615 - , number of DN Lines present in the 1616 LORDN file. 1618 * second line: a header line as specified in [RFC4180] 1620 With the header names as follows: 1622 roid,domain-name,notice-id,registrar-id,registration- 1623 datetime,ack-datetime,application-datetime 1625 * One or more lines with: ,,,,,, 1629 Where: 1631 - , DN Repository Object IDentifier (DNROID) in the 1632 SRS. 1634 - , DN that was effectively allocated. For 1635 IDNs the A-Label is used. 1637 - , Trademark Claims Notice Identifier as specified 1638 in . 1640 - , IANA Registrar ID. 1642 - , date and time in UTC that the 1643 domain was effectively allocated. 1645 - , date and time in UTC 1646 that the TCN was acknowledged. 1648 - OPTIONAL , date and 1649 time in UTC that the application was created. The 1650 MUST be provided in 1651 case of a DN effective allocation based on an 1652 asynchronous registration (e.g., when using auctions). 1654 For a DN matching a DNL of a PRM at the moment of 1655 registration, created without the TCNID, expiration datetime 1656 and acceptance datetime, because DNL was inserted (or re- 1657 inserted) for the first time into DNL List less than 24 1658 hours ago, the string "recent-dnl-insertion" MAY be 1659 specified in and . 1662 Example for LORDN during Claims 1664 1,2012-08-16T00:00:00.0Z,3 1665 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1666 ack-datetime,application-datetime 1667 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1668 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1669 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1670 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1671 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1672 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1674 Figure 13 1676 6.3.1. LORDN Log File 1678 After reception of the LORDN file, the TMDB verifies its content for 1679 syntactical and semantical correctness. The output of the LORDN file 1680 verification is retrieved using the yd interface (Section 4.3.7). 1682 The URI of the yd interface (Section 4.3.7) used to retrieve the 1683 LORDN Log File is: 1685 o Sunrise LORDN Log file: 1687 < https:///LORDN//sunrise/ 1688 /result > 1690 o Claims LORDN Log file: 1692 < https:///LORDN//claims/ 1693 /result > 1695 A Registry Operator MUST NOT send more than one request per minute 1696 per TLD to download a LORDN Log file. 1698 The yd interface (Section 4.3.7) returns the following HTTP status 1699 codes after a HTTP GET request method is received: 1701 o The interface provides a HTTP/200 status code if the interface was 1702 able to provide the LORDN Log file. The LORDN Log file is 1703 contained in the HTTP Entity-body. 1705 o The interface provides a HTTP/204 status code if the LORDN 1706 Transaction Identifier is correct, but the server has not 1707 finalized processing the LORDN file. 1709 o The interface provides a HTTP/400 status code if the request is 1710 incorrect. 1712 o The interface provides a HTTP/401 status code if the credentials 1713 provided does not authorize the Registry Operator to download the 1714 LORDN Log file. 1716 o The interface provides a HTTP/404 status code if the LORDN 1717 Transaction Identifier is incorrect. 1719 o The interface provides a HTTP/500 status code if the system is 1720 experiencing a general failure. 1722 For example, to obtain the LORDN Log File in case of a Sunrise LORDN 1723 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1724 "example" the URI would be: 1726 < https:///LORDN/example/sunrise/ 1727 0000000000000000001/result > 1729 The LORDN Log file is contained in a CSV formatted file that has the 1730 following structure: 1732 o first line: ,,,,,, 1736 Where: 1738 + , version of the file, this field MUST be 1. 1740 + , date and time in UTC that the 1741 LORDN Log was created. 1743 + , date and time in UTC of 1744 creation for the LORDN file that this log file is referring 1745 to. 1747 + , unique identifier of the LORDN Log 1748 provided by the TMDB. This identifier could be used by the 1749 Registry Operator to unequivocally identify the LORDN Log. 1750 The identified will be a string of a maximum LENGTH of 60 1751 characters from the Base 64 alphabet. 1753 + , whether the LORDN file has been accepted for 1754 processing by the TMDB. Possible values are "accepted" or 1755 "rejected". 1757 + , whether the LORDN Log has any warning result 1758 codes. Possible values are "no-warnings" or "warnings- 1759 present". 1761 + , number of DNs effective allocations 1762 processed in the LORDN file. 1764 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1765 a ="accepted" and ="no-warnings". 1767 o second line: a header line as specified in [RFC4180] 1769 With the header names as follows: 1771 roid,result-code 1773 o One or more lines with: , 1775 Where: 1777 + , DN Repository Object IDentifier (DNROID) in the SRS. 1779 + , result code as described in Section 6.3.1.1. 1781 Example for LORDN Log file 1783 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1784 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1785 accepted,no-warnings,1 1786 roid,result-code 1787 SH8013-REP,2000 1789 Figure 14 1791 6.3.1.1. LORDN Log Result Codes 1793 In Figure 15 the classes of result codes (rc) are listed. Those 1794 classes in square brackets are not used at this time, but may come 1795 into use at some later stage. The first two digits of a result code 1796 denote the result code class, which defines the outcome at the TMDB: 1798 o ok: Success, DN Line accepted by the TMDB. 1800 o warn: a warning is issued, DN Line accepted by the TMDB. 1802 o err: an error is issued, LORDN file rejected by the TMDB. 1804 In case that after processing a DN Line, the error result code is 1805 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1806 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1807 valid will be reported with a 2001 result code. A 2001 result code 1808 means that the DN Line is syntactically valid, however the DN Line 1809 was not processed because the LORDN file was rejected. All DNs 1810 reported in a rejected LORDN file MUST be reported again by the 1811 Registry because none of the DN Lines present in the LORDN file have 1812 been processed by the TMDB. 1814 LORDN Log Result Code Classes 1816 code Class outcome 1817 ---- ----- ------- 1819 20xx Success ok 1821 35xx [ DN Line syntax warning ] warn 1822 36xx DN Line semantic warning warn 1824 45xx DN Line syntax error err 1825 46xx DN Line semantic error err 1827 Figure 15 1829 In the following, the LORDN Log result codes used by the TMDB are 1830 described: 1832 LORDN Log result Codes 1834 rc Short Description 1835 Long Description 1837 ---- ------------------------------------------------------------- 1839 2000 OK 1840 DN Line successfully processed. 1842 2001 OK but not processed 1843 DN Line is syntactically correct but was not processed 1844 because the LORDN file was rejected. 1846 3601 TCN Acceptance Date after Registration Date 1847 TCN Acceptance Date in DN Line is newer than the Registration 1848 Date. 1850 3602 Duplicate DN Line 1851 This DN Line is an exact duplicate of another DN Line in same 1852 file, DN Line ignored. 1854 3603 DNROID Notified Earlier 1855 Same DNROID has been notified earlier, DN Line ignored. 1857 3604 TCN Checksum invalid 1858 Based on the DN effectively allocated, the TCNID and the 1859 expiration date of the linked TCN, the TCN Checksum is 1860 invalid. 1862 3605 TCN Expired 1863 The TCN was already expired (based on the field of the TCN) 1864 at the time of acknowledgement. 1866 3606 Wrong TCNID used 1867 The TCNID used for the registration does not match 1868 the related DN. 1870 3609 Invalid SMD used 1871 The SMD used for registration was not valid at the moment of 1872 registration based on the and 1873 elements. 1874 In case of an asynchronous registration, this refer to the 1875 . 1877 3610 DN reported outside of the time window 1878 The DN was reported outside of the required 26 hours 1879 reporting window. 1881 3611 DN does not match the labels in SMD 1882 The DN does not match the labels included in the SMD. 1884 3612 SMDID does not exist 1885 The SMDID has never existed in the central repository. 1887 3613 SMD was revoked when used 1888 The SMD used for registration was revoked more than 1889 24 hours ago of the . 1890 In case of an asynchronous registration, 1891 the is used when 1892 validating the DN Line. 1894 3614 TCNID does not exist 1895 The TCNID has never existed in the central repository. 1897 3615 Recent-dnl-insertion outside of the time window 1898 The DN registration is reported as a recent-dnl-insertion, 1899 but the (re) insertion into the DNL ocurred more than 1900 24 hours ago. 1902 3616 Registration Date of DN in claims before the end of Sunrise 1903 The registration date of the DN is before the end of Sunrise 1904 and the DN was reported in a claims LORDN file. 1906 3617 Registrar has not been approved by the TMDB 1907 Registrar ID in DN Line has not completed Claims integration 1908 testing with the TMDB. 1910 3618 Registration Date of DN in a QLP LORDN file outside of the QLP period 1911 The registration date of the DN in a QLP LORDN file is outside 1912 of the QLP period. 1914 3619 TCN was not valid 1915 The TCN was not valid (based on the field of the TCN) 1916 at the time of acknowledgement. 1918 4501 Syntax Error in DN Line 1919 Syntax Error in DN Line. 1921 4601 Invalid TLD used 1922 The TLD in the DN Line does not match what is expected for 1923 this LORDN. 1925 4602 Registrar ID Invalid 1926 Registrar ID in DN Line is not a valid ICANN-Accredited 1927 Registrar. 1929 4603 Registration Date in the future 1930 The in the DN Line is in the 1931 future. 1933 4606 TLD not in Sunrise or Claims 1934 The was reported when the TLD was 1935 not in Sunrise or Claims. 1936 In case of an asynchronous registration, 1937 the is used when 1938 validating the DN Line. 1940 4607 Application Date in the future 1941 The in the DN Line is in the 1942 future. 1944 4608 Application Date is later than Registration Date 1945 The in the DN Line is later 1946 than the . 1948 4609 TCNID wrong syntax 1949 The syntax of the TCNID is invalid. 1951 4610 TCN Acceptance Date is in the future 1952 The is in the future. 1954 4611 Label has never existed in the TMDB 1955 The label in the registered DN has never existed in the TMDB. 1957 Figure 16 1959 6.4. SMD File 1961 This section defines the format of the SMD File. After a successful 1962 registration of a mark, the TMV returns an SMD File to the TMH. The 1963 SMD File can then be used for registration of one or more DNs covered 1964 by the PRM during the Sunrise Period of a TLD. 1966 Two encapsulation boundaries are defined for delimiting the 1967 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1968 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1969 boundaries MUST be used by Registries and Registrars for validation 1970 purposes, i.e. any data outside these boundaries as well as the 1971 boundaries themselves MUST be ignored for validation purposes. 1973 The structure of the SMD File is as follows: 1975 o Marks: 1977 o smdID: 1979 o U-labels: 1982 o notBefore: 1984 o notAfter: 1986 o -----BEGIN ENCODED SMD----- 1988 o 1990 o -----END ENCODED SMD----- 1991 Example for SMD File (shortened at [...]): 1993 Marks: Example One 1994 smdID: 1-2 1995 U-labels: example-one, exampleone 1996 notBefore: 2011-08-16 09:00 1997 notAfter: 2012-08-16 09:00 1998 -----BEGIN ENCODED SMD----- 1999 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 2000 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 2001 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 2002 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 2003 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 2004 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 2005 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 2006 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 2007 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 2008 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 2009 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 2010 [...] 2011 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 2012 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 2013 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 2014 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 2015 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 2016 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 2017 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2018 -----END ENCODED SMD----- 2020 Figure 17 2022 6.5. Trademark Claims Notice 2024 The TMDB MUST provide the TCN to Registrars in XML format as 2025 specified below. 2027 An enclosing element that describes the Trademark 2028 Notice to a given label. 2030 The child elements of the element include: 2032 o A element that contains the unique identifier of the 2033 Trademark Notice. This element contains the the TCNID. 2035 The TCNID is a string concatenation of a TCN Checksum and the 2036 TMDB Notice Identifier. The first 8 characters of the TCNID is 2037 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2038 is a zero-padded natural number in the range of 2039 0000000000000000001 to 9223372036854775807. 2041 Example of a TCNID: 2043 370d0b7c9223372036854775807. 2045 Where: 2047 + TCN Checksum=370d0b7c 2049 + TMDB Notice Identifier=9223372036854775807 2051 The TCN Checksum is a 8 characters long Base16 encoded output 2052 of computing the CRC32 of the string concatenation of: label + 2053 unix_timestamp() + TMDB Notice Identifier 2055 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is 2057 defined as the number of seconds that have elapsed since 1970- 2058 01-01T00:00:00Z not counting leap seconds. For example, the 2059 conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: 2061 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2063 The TMDB uses the and 2064 elements from the TCN along with the TMDB Notice Identifier to 2065 compute the TCN Checksum. 2067 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 2068 of the DN being registered, the expiration datetime of the TCN 2069 (provided by the Registrar) and the TMDB Notice Identifier 2070 extracted from the TCNID (provided by the Registrar) to compute 2071 the TCN Checksum. For example the DN "foo.bar.example" being 2072 effectively allocated, the left most label would be "foo". 2074 Example of computation of the TCN Checksum: 2076 CRC32(example-one12819492009223372036854775807)=370d0b7c 2078 o A element that contains the start of the 2079 validity date and time of the TCN. 2081 o A element that contains the expiration date 2082 and time of the TCN. 2084 o A elements that contain the DNL (A-label in case 2085 of IDNs) form of the label that correspond to the DN covered by a 2086 PRM. 2088 o One or more elements that contain the Trademark 2089 Claim. The element contains the following child 2090 elements: 2092 * A element that contains the mark text 2093 string. 2095 * One or more elements that contains the 2096 information of the holder of the mark. An "entitlement" 2097 attribute is used to identify the entitlement of the holder, 2098 possible values are: owner, assignee or licensee. The child 2099 elements of include: 2101 + An OPTIONAL element that contains the name 2102 of the holder. A MUST be specified if 2103 is not specified. 2105 + An OPTIONAL element that contains the name of 2106 the organization holder of the mark. A MUST 2107 be specified if is not specified. 2109 + A element that contains the address 2110 information of the holder of a mark. A 2111 contains the following child elements: 2113 - One, two or three OPTIONAL elements 2114 that contains the organization's street address. 2116 - A element that contains the 2117 organization's city. 2119 - An OPTIONAL element that contains the 2120 organization's state or province. 2122 - An OPTIONAL element that contains the 2123 organization's postal code. 2125 - A element that contains the organization's 2126 country code. This a two-character code from 2127 [ISO3166-2]. 2129 + An OPTIONAL element that contains the 2130 organization's voice telephone number. 2132 + An OPTIONAL element that contains the 2133 organization's facsimile telephone number. 2135 + An OPTIONAL element that contains the email 2136 address of the holder. 2138 * Zero or more OPTIONAL elements that contains 2139 the information of the representative of the mark registration. 2140 A "type" attribute is used to identify the type of contact, 2141 possible values are: owner, agent or thirdparty. The child 2142 elements of include: 2144 + A element that contains name of the 2145 responsible person. 2147 + An OPTIONAL element that contains the name of 2148 the organization of the contact. 2150 + A element that contains the address 2151 information of the contact. A contains the 2152 following child elements: 2154 - One, two or three OPTIONAL elements 2155 that contains the contact's street address. 2157 - A element that contains the contact's 2158 city. 2160 - An OPTIONAL element that contains the 2161 contact's state or province. 2163 - An OPTIONAL element that contains the 2164 contact's postal code. 2166 - A element that contains the contact's 2167 country code. This a two-character code from 2168 [ISO3166-2]. 2170 + A element that contains the contact's voice 2171 telephone number. 2173 + An OPTIONAL element that contains the 2174 contact's facsimile telephone number. 2176 + A element that contains the contact's email 2177 address. 2179 * A element that contains the name (in 2180 English) of the jurisdiction where the mark is protected. A 2181 jurCC attribute contains the two-character code of the 2182 jurisdiction where the mark was registered. This is a two- 2183 character code from [WIPO.ST3]. 2185 * Zero or more OPTIONAL element that 2186 contains the description (in English) of the Nice 2187 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2188 attribute contains the class number. 2190 * A element that contains the full 2191 description of the goods and services mentioned in the mark 2192 registration document. 2194 * An OPTIONAL element signals that the 2195 claim notice was added to the TCN based on other rule (e.g. 2196 [Claims50] ) than exact match (defined in [MatchingRules]). 2197 The contains one or more: 2199 + An OPTIONAL element that signals that the 2200 claim notice was added because of a previously abused name 2201 included in an UDRP case. The contains: 2203 - A element that contains the UDRP case 2204 number used to validate the previously abused name. 2206 - A element that contains the name 2207 of the UDRP provider. 2209 + An OPTIONAL element that signals that the 2210 claim notice was added because of a previously abused name 2211 included in a court's resolution. The 2212 contains: 2214 - A element that contains the reference 2215 number of the court's resolution used to validate the 2216 previously abused name. 2218 - A element that contains the two-character 2219 code from [ISO3166-2] of the jurisdiction of the court. 2221 - A element that contains the name of 2222 the court. 2224 Example of object: 2226 2227 2228 370d0b7c9223372036854775807 2229 2010-08-14T09:00:00.0Z 2230 2010-08-16T09:00:00.0Z 2231 example-one 2232 2233 Example One 2234 2235 Example Inc. 2236 2237 123 Example Dr. 2238 Suite 100 2239 Reston 2240 VA 2241 20190 2242 US 2243 2244 2245 2246 Joe Doe 2247 Example Inc. 2248 2249 123 Example Dr. 2250 Suite 100 2251 Reston 2252 VA 2253 20190 2254 US 2255 2256 +1.7035555555 2257 jdoe@example.com 2258 2259 UNITED STATES OF AMERICA 2260 2261 Advertising; business management; business administration. 2262 2263 2264 Insurance; financial affairs; monetary affairs; real estate. 2265 2266 2267 Bardus populorum circumdabit se cum captiosus populum. 2268 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2269 2270 2271 2272 Example-One 2273 2274 Example S.A. de C.V. 2275 2276 Calle conocida #343 2277 Conocida 2278 SP 2279 82140 2280 BR 2281 2282 2283 BRAZIL 2284 2285 Bardus populorum circumdabit se cum captiosus populum. 2286 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2287 2288 2289 2290 One 2291 2292 One Corporation 2293 2294 Otra calle 2295 Otra ciudad 2296 OT 2297 383742 2298 CR 2299 2300 2301 COSTA RICA 2302 2303 Bardus populorum circumdabit se cum captiosus populum. 2304 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2305 2306 2307 2308 234235 2309 CR 2310 Supreme Court of Justice of Costa Rica 2311 2312 2313 2314 2315 One Inc 2316 2317 One SA de CV 2318 2319 La calle 2320 La ciudad 2321 CD 2322 34323 2323 AR 2324 2325 2326 ARGENTINA 2327 2328 Bardus populorum circumdabit se cum captiosus populum. 2329 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2330 2331 2332 2333 D2003-0499 2334 WIPO 2335 2336 2337 2338 2340 For formal syntax of the TCN please refer to Section 7.1. 2342 6.6. Sunrise List File 2344 This section defines the format of the list containing every Domain 2345 Name Label (DNL) that matches a Pre-Registered Mark (PRM) eligible 2346 for Sunrise. The list is maintained by the TMDB and downloaded by 2347 Registries in regular intervals (see Section 5.4.2.1). The 2348 Registries use the Sunrise List during the Qualified Launch Program 2349 period to check whether a requested DN matches a DNL of a PRM 2350 eligible for Sunrise. 2352 The Sunrise List contains all the DNLs covered by a PRM eligible for 2353 Sunrise present in the TMDB at the time it is generated. 2355 The Sunrise List is contained in a CSV formatted file that has the 2356 following structure: 2358 o first line: , 2360 Where: 2362 + , version of the file, this field MUST be 1. 2364 + , date and time in UTC that 2365 the Sunrise List was created. 2367 o second line: a header line as specified in [RFC4180] 2369 With the header names as follows: 2371 DNL,insertion-datetime 2373 o One or more lines with: , 2375 Where: 2377 + , a Domain Name Label covered by a PRM eligible for 2378 Sunrise. 2380 + , datetime in UTC that the DNL was 2381 first inserted into the Sunrise List. The possible two 2382 values of time for inserting a DNL to the Sunrise List are 2383 00:00:00 and 12:00:00 UTC. 2385 Example for Sunrise List 2387 1,2012-08-16T00:00:00.0Z 2388 DNL,insertion-datetime 2389 example,2010-07-14T00:00:00.0Z 2390 another-example,2012-08-16T00:00:00.0Z 2391 anotherexample,2011-08-16T12:00:00.0Z 2393 Figure 18 2395 To provide authentication and integrity protection, the Sunrise List 2396 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2397 signature of the Sunrise List can be found in the similar URI but 2398 with extension .sig as shown below. 2400 The URL of the dy interface (Section 4.3.3) is: 2402 o < https:///dnl/surl-latest.csv > 2404 o < https:///dnl/surl-latest.sig > 2406 7. Formal Syntax 2408 7.1. Trademark Claims Notice 2410 The schema presented here is for a Trademark Claims Notice. 2412 Copyright (c) 2012 IETF Trust and the persons identified as authors 2413 of the code. All rights reserved. 2415 Redistribution and use in source and binary forms, with or without 2416 modification, are permitted provided that the following conditions 2417 are met: 2419 o Redistributions of source code must retain the above copyright 2420 notice, this list of conditions and the following disclaimer. 2422 o Redistributions in binary form must reproduce the above copyright 2423 notice, this list of conditions and the following disclaimer in 2424 the documentation and/or other materials provided with the 2425 distribution. 2427 o Neither the name of Internet Society, IETF or IETF Trust, nor the 2428 names of specific contributors, may be used to endorse or promote 2429 products derived from this software without specific prior written 2430 permission. 2432 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2433 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2434 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2435 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2436 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2437 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2438 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2439 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2440 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2441 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2442 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2444 BEGIN 2445 2446 2451 2452 2453 Schema for representing a Trademark Notice. 2454 2455 2456 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2478 2479 2480 2481 2482 2483 2485 2487 2488 2490 2491 2493 2494 2495 2496 2497 2498 2499 2500 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2551 2552 2553 2554 2555 2556 2557 2558 END 2559 8. Acknowledgements 2561 This specification is a collaborative effort from several 2562 participants in the ICANN community. Bernie Hoeneisen participated 2563 as co-author until version 02 providing invaluable support for this 2564 document. This specification is based on a model spearheaded by: 2565 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2566 would also like to thank the thoughful feedbak provided by many in 2567 the tmch-tech mailing list, but particularly the extensive help 2568 provided by James Gould, James Mitchell and Francisco Arias. This 2569 document includes feedback received from the following individuals: 2570 Paul Hoffman. 2572 9. IANA Considerations 2574 This document uses URNs to describe XML namespaces and XML schemas 2575 conforming to a registry mechanism described in [RFC3688]. One URI 2576 assigment have been registered by the IANA. 2578 Registration request for the Trademark Claims Notice: 2580 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2582 Registrant Contact: See the "Author's Address" section of this 2583 document. 2585 XML: None. Namespace URIs do not represent an XML specification. 2587 10. Security Considerations 2589 This specification uses HTTP Basic Authentication to provide a simple 2590 application-layer authentication service. HTTPS is used in all 2591 interfaces in order to protect against most common attacks. In 2592 addition, the client identifier is tied to a set of IP addresses that 2593 are allowed to connect to the interfaces described in this document, 2594 providing an extra security measure. 2596 The TMDB MUST provide credentials to the appropriate Registries and 2597 Registrars. 2599 The TMDB MUST require the use of strong passwords by Registries and 2600 Registrars. 2602 The TMDB, Registries and Registrars MUST use the best practices 2603 described in RFC 7525 or its successors. 2605 11. References 2607 11.1. Normative References 2609 [I-D.ietf-eppext-tmch-smd] 2610 Lozano, G., "Mark and Signed Mark Objects Mapping", 2611 draft-ietf-eppext-tmch-smd-02 (work in progress), 2612 July 2015. 2614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2615 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2616 RFC2119, March 1997, 2617 . 2619 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2620 DOI 10.17487/RFC3688, January 2004, 2621 . 2623 11.2. Informative References 2625 [Claims50] 2626 ICANN, "Implementation Notes: Trademark Claims Protection 2627 for Previously Abused Names", July 2013, . 2631 [I-D.ietf-dnsop-dns-terminology] 2632 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2633 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 2634 progress), September 2015. 2636 [ICANN-GTLD-AGB-20120604] 2637 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2638 June 2012, . 2641 [ISO3166-2] 2642 ISO, "International Standard for country codes and codes 2643 for their subdivisions", 2006, 2644 . 2646 [MatchingRules] 2647 ICANN, "Memorandum on Implementing Matching Rules", 2648 September 2012, . 2651 [QLP-Addendum] 2652 ICANN, "Qualified Launch Program Addendum", April 2014, . 2657 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2658 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2659 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 2660 RFC2616, June 1999, 2661 . 2663 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2664 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2665 Authentication: Basic and Digest Access Authentication", 2666 RFC 2617, DOI 10.17487/RFC2617, June 1999, 2667 . 2669 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 2670 RFC2818, May 2000, 2671 . 2673 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2674 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2675 . 2677 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2678 Separated Values (CSV) Files", RFC 4180, DOI 10.17487/ 2679 RFC4180, October 2005, 2680 . 2682 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2683 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2684 . 2686 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2687 Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/ 2688 RFC4880, November 2007, 2689 . 2691 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2692 Housley, R., and W. Polk, "Internet X.509 Public Key 2693 Infrastructure Certificate and Certificate Revocation List 2694 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2695 . 2697 [RFC5890] Klensin, J., "Internationalized Domain Names for 2698 Applications (IDNA): Definitions and Document Framework", 2699 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2700 . 2702 [RPM-Requirements] 2703 ICANN, "Rights Protection Mechanism Requirements", 2704 September 2013, . 2707 [WIPO-NICE-CLASSES] 2708 WIPO, "Nice List of Classes", 2709 . 2711 [WIPO.ST3] 2712 WIPO, "Recommended standard on two-letter codes for the 2713 representation of states, other entities and 2714 intergovernmental organizations", March 2007, 2715 . 2717 Author's Address 2719 Gustavo Lozano 2720 ICANN 2721 12025 Waterfront Drive, Suite 300 2722 Los Angeles 90292 2723 US 2725 Phone: +1.3103015800 2726 Email: gustavo.lozano@icann.org