idnits 2.17.1 draft-lozano-tmch-func-spec-10.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 is 1 instance 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 (Jul 23, 2015) is 3162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1352, but not defined == Unused Reference: 'RFC1918' is defined on line 2678, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 2683, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 2707, but no explicit reference was found in the text -- 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 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational Jul 23, 2015 5 Expires: January 24, 2016 7 TMCH functional specifications 8 draft-lozano-tmch-func-spec-10 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 January 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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. Change History . . . . . . . . . . . . . . . . . . . . . . . . 69 121 9.1. Changes from draft-lozano-tmch-func-spec-06 to 122 draft-lozano-tmch-func-spec-07 . . . . . . . . . . . . . . 69 123 9.2. Changes from draft-lozano-tmch-func-spec-07 to 124 draft-lozano-tmch-func-spec-08 . . . . . . . . . . . . . . 69 125 9.3. Changes from draft-lozano-tmch-func-spec-08 to 126 draft-lozano-tmch-func-spec-09 . . . . . . . . . . . . . . 69 127 9.4. Changes from draft-lozano-tmch-func-spec-09 to 128 draft-lozano-tmch-func-spec-10 . . . . . . . . . . . . . . 70 129 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 130 11. Security Considerations . . . . . . . . . . . . . . . . . . . 70 131 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 132 12.1. Normative References . . . . . . . . . . . . . . . . . . . 70 133 12.2. Informative References . . . . . . . . . . . . . . . . . . 71 134 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 73 135 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 137 1. Introduction 139 Domain Name Registries may operate in special modes within certain 140 periods of time to facilitate registration of domain names. 142 Along with the upcoming introduction of new generic Top Level Domains 143 (gTLD), two special modes will come into effect: 145 o Sunrise Period 147 o Trademark Claims Period 149 The Sunrise and Trademark Claims Periods are defined in the gTLD 150 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 152 This document describes the requirements, the architecture and the 153 interfaces between the Trademark Clearing House (TMCH) and Domain 154 Name Registries (called Registries in the rest of the document) as 155 well as between the TMCH and Domain Name Registrars (called 156 Registrars in the rest of the document) for the provisioning and 157 management of domain names during the Sunrise and Trademark Claims 158 Periods. 160 For any date and/or time indications, Coordinated Universal Time 161 (UTC) applies. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 XML is case sensitive. Unless stated otherwise, XML specifications 170 and examples provided in this document MUST be interpreted in the 171 character case presented in order to develop a conforming 172 implementation. 174 "tmNotice-1.0" is used as an abbreviation for 175 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 176 "tmNotice" is used, but implementations MUST NOT depend on it and 177 instead employ a proper namespace-aware XML parser and serializer to 178 interpret and output the XML documents. 180 3. Glossary 182 In the following section, the most common terms are briefly 183 explained: 185 o Effective allocation: A DN is considered effectively allocated 186 when the DN object for the DN has been created in the SRS of the 187 Registry and has been assigned to the effective user. A DN object 188 in status "pendingCreate" or any other status that precedes the 189 first time a DN is assigned to an end-user is not considered an 190 effective allocation. A DN object created internally by the 191 Registry for subsequent delegation to another Registrant is not 192 considered an effective allocation. 194 o Backend Registry Operator: Entity that manages (a part of) the 195 technical infrastructure for a Registry Operator. The Registry 196 Operator may also be the Backend Registry Operator. 198 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 200 o CSV: Comma-Separated Values, see [RFC4180] 202 o CNIS, Claims Notice Information Service: This service provides 203 TCNs to Registrars. 205 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 206 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 208 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 210 o Date and time, datetime: Date and time are specified following the 211 standard "Date and Time on the Internet specification", see 212 [RFC3339]. 214 o DN: Domain Name, domain name, see [RFC1034] 216 o DN Repository Object IDentifier, DNROID: an identifier assigned by 217 the Registry to each DN object that unequivocally identifies said 218 DN object. For example, if a new DN object is created for a name 219 that existed in the past, the DN objects will have different 220 DNROIDs. 222 o DNS: Domain Name System, see [RFC1034] 224 o DNL, Domain Name Label: A label as specified in [RFC1035]. For 225 IDNs the A-Label is used [RFC5890]. 227 o DNL List: A list of DNLs that are covered by a PRM. 229 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 231 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 233 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 235 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246]. 237 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 238 SMD PKI model. 240 o IDN: Internationalized Domain Name, see [RFC5890] 242 o LORDN, List of Registered Domain Names: This is the list of 243 effectively allocated DNs matching a DNL of a PRM. Registries 244 will upload this list to the TMDB (during the NORDN process). 246 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 247 Z0-9/] to be used as the lookup Key by Registrars to obtain the 248 TCN using the CNIS. Lookup Keys are unique and are related to one 249 DNL only. 251 o NORDN, Notification of Registered Domain Names: The process by 252 which Registries upload their recent LORDN to the TMDB. 254 o PGP: Pretty Good Privacy, see [RFC4880] 256 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 258 o PRM, Pre-registered mark: Mark that has been pre-registered with 259 the TMCH. 261 o Registrant: Person or Organization registering a DN via a 262 Registrar. 264 o Registrar, Domain Name Registrar: Entity that registers DNs with 265 the Registry on behalf of the Registrant. 267 o Registry, Registry Operator, Domain Name Registry: Entity that 268 accepts DN registrations from Registrars, maintains the central 269 Database of Registered DNs. A Registry Operator is the 270 contracting party with ICANN for the TLD. 272 o Qualified Launch Program period, QLP period: During this OPTIONAL 273 period, a special process applies to DNs matching the Sunrise List 274 and/or the DNL List, to ensure a TMH gets informed of a DN 275 matching his PRM. 277 o SMD, Signed Mark Data: A cryptographically signed token issued by 278 the TMV to the TMH to be used in the Sunrise Period to apply for a 279 DN that matches a DNL of a PRM; see also [I-D.lozano-tmch-smd] 281 o SMD File: A file containing the SMD (see above) and some human 282 readable data. The latter is usually ignored in the processing of 283 the SMD File. See also Section 6.4. 285 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 286 lists of revoked SMDs (SMD Revocation List); see also 287 [I-D.lozano-tmch-smd] 289 o SMD Revocation List: The SMD Revocation List is used by Registries 290 (and optionally by Registrars) during the Sunrise Period to ensure 291 that an SMD is still valid (i.e. not revoked). The SMD Revocation 292 List has a similar function as CRLs used in PKI. 294 o SRS: Shared Registration System, see also 295 [ICANN-GTLD-AGB-20120604]. 297 o Sunrise Period: During this period DNs matching a DNL of a PRM can 298 be exclusively obtained by the respective TMHs. For DNs matching 299 a PRM, a special process applies to ensure a TMH gets informed on 300 the effective allocation of a DN matching his/her PRM. 302 o Sunrise List, SURL: The list of DNLs that are covered by a PRM and 303 eligible for Sunrise. 305 o TLD: Top Level Domain Name, see [RFC1591] 307 o Trademark, mark: Marks are used to claim exclusive properties of 308 products or services. A mark is typically a name, word, phrase, 309 logo, symbol, design, image, or a combination of these elements. 310 For the scope of this document only textual marks are relevant. 312 o Trademark Claims, Claims: Provides information to enhance the 313 understanding of the Trademark rights being claimed by the TMH. 315 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 316 Trademark Claims Notice consist of one or more Trademark Claims 317 and are provided to prospective Registrants of DNs. 319 o Trademark Claims Notice Identifier, TCNID: An element of the 320 Trademark Claims Notice (see above), identifying said TCN. The 321 Trademark Claims Notice Identifier is specified in the element 322 . 324 o Trademark Claims Period: During this period, a special process 325 applies to DNs matching the DNL List, to ensure a TMH gets 326 informed of a DN matching his PRM. For DNs matching the DNL List, 327 Registrars show a TCN to prospective Registrants that has to be 328 acknowledged before effective allocation of the DN. 330 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 331 ICANN central repository for information to be authenticated, 332 stored, and disseminated, pertaining to the rights of TMHs. The 333 Trademark Clearinghouse is split into two functions TMV and TMDB 334 (see below). There could be several entities performing the TMV 335 function, but only one entity performing the TMDB function. 337 o TMDB, Trademark Clearinghouse Database: Serves as a database of 338 the TMCH to provide information to the new gTLD Registries and 339 Registrars to support Sunrise or Claims services. There is only 340 one TMDB in the TMCH that concentrates the information about the 341 "verified" Trademark records from the TMVs. 343 o TMH, Trademark Holder: The person or organization owning rights on 344 a mark. 346 o TMV, Trademark Validator, Trademark validation organization: An 347 entity authorized by ICANN to authenticate and validate 348 registrations in the TMDB ensuring the marks qualify as registered 349 or are court-validated marks or marks that are protected by 350 statute or treaty. This entity would also be asked to ensure that 351 proof of use of marks is provided, which can be demonstrated by 352 furnishing a signed declaration and one specimen of current use. 354 o UTC: Coordinated Universal Time, as maintained by the Bureau 355 International des Poids et Mesures (BIPM); see also [RFC3339]. 357 4. Architecture 359 4.1. Sunrise Period 361 Architecture Sunrise Period 363 SMD hand over (out of band; 364 trivial if Registrant == TMH) 365 ........................................... 366 : : 367 : .'''''''''''''''''''. : 368 : . TMCH . : 369 : ..................... : 370 v . . : 371 .------------. . .-------------. . hv .-----. 372 | Registrant | . | TMV |<------->| TMH | 373 '------------' . '-------------' . vh '-----' 374 | . | ^ \ . 375 | . | | \. 376 tr | . vs | | \ 377 | . | | dv .\ 378 v . v | . \ 379 .-----------. sr . .---. | . \ 380 .->| Registrar |<.........| S | vd | . \ 381 : '-----------' . | M | | . \ 382 : | sy . | D | v . \ 383 : ry | .-----------| M | .---. . vc \ 384 : | | . '---' | T | . \ 385 : v v . | M | . v 386 : .-----------. . | D | . .----------. 387 : | Registry |----------------->| B | . | ICANN-CA | 388 : '-----------' . yd '---' . '----------' 389 : ^ . . | : 390 : | ''''''''''''''''''' | : 391 : | cy | : 392 : cr '---------------------------------------' : 393 :.....................................................: 395 Figure 1 397 4.2. Trademark Claims Period 399 Architecture Trademark Claims Period 401 .'''''''''''''. 402 . TMCH . 403 ............... 404 . . 405 .------------. . .-------. . hv .-----. 406 | Registrant | . | TMV |<------->| TMH | 407 '------------' . '-------' . vh '-----' 408 | . ^ . 409 tr | . | dv . 410 | . vd | . 411 v . v . 412 .-----------. dr . .-------. . 413 | Registrar |<--------| T | . 414 '-----------' . | | . 415 | . | M | . 416 ry | . | | . 417 v . | D | . 418 .----------. dy . | | . 419 | Registry |<------->| B | . 420 '----------' yd . '-------' . 421 . . 422 ''''''''''''' 424 Figure 2 426 4.3. Interfaces 428 In the sub-sections below follows a short description of each 429 interface to provide an overview of the architecture. More detailed 430 descriptions of the relevant interfaces follow further below 431 (Section 5). 433 4.3.1. hv 435 The TMH registers a mark with a TMV via the hv interface. 437 After the successful registration of the mark, the TMV makes 438 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 439 TMH to be used during the Sunrise Period. 441 The specifics of the hv interface are beyond the scope of this 442 document. 444 4.3.2. vd 446 After successful mark registration, the TMV ensures the TMDB inserts 447 the corresponding DNLs and mark information into the database via the 448 vd interface. 450 The specifics of the vd interface are beyond the scope of this 451 document. 453 4.3.3. dy 455 Not used during the Sunrise Period. 457 During the Trademark Claims Period the Registry fetches the latest 458 DNL List from the TMDB via the dy interface in regular intervals. 459 The protocol used on the dy interface is HTTPS. 461 4.3.4. tr 463 The Registrant communicates with the Registrar via the tr interface. 465 The specifics of the tr interface are beyond the scope of this 466 document. 468 4.3.5. ry 470 The Registrar communicate with the Registry via the ry interface. 471 The ry interfaces is typically implemented in EPP [RFC5730]. 473 4.3.6. dr 475 Not used during the Sunrise Period. 477 During the Trademark Claims Period, the Registrar fetches the TCN 478 from the TMDB (to be displayed to the Registrant via the tr 479 interface) via the dr interface. The protocol used for fetching the 480 TCN is HTTPS [RFC2818]. 482 4.3.7. yd 484 During the Sunrise period the Registry notifies the TMDB via the yd 485 interface of all DNs effectively allocated. 487 During the Trademark Claims period, the Registry notifies the TMDB 488 via the yd interface of all DNs effectively allocated that matched an 489 entry in the Registry previously downloaded DNL List during the 490 creation of the DN. 492 The protocol used on the yd interface is HTTPS. 494 4.3.8. dv 496 The TMDB notifies via the dv interface to the TMV of all DNs 497 effectively allocated that match a mark registered by that TMV. 499 The specifics of the dv interface are beyond the scope of this 500 document. 502 4.3.9. vh 504 The TMV notifies the TMH via the vh interface after a DN has been 505 effectively allocated that matches a PRM of this TMH. 507 The specifics of the vh interface are beyond the scope of this 508 document. 510 4.3.10. vs 512 The TMV requests to add a revoked SMD to the SMD Revocation List at 513 the SMDM. 515 The specifics of the vs interface are beyond the scope of this 516 document. 518 Not relevant during the Trademark Claims Period. 520 4.3.11. sy 522 During the Sunrise Period the Registry fetches the most recent SMD 523 Revocation List from the SMDM via the sy interface in regular 524 intervals. The protocol used on the sy interface is HTTPS. 526 Not relevant during the Trademark Claims Period. 528 4.3.12. sr 530 During the Sunrise Period the Registrar may fetch the most recent SMD 531 Revocation List from the SMDM via the sr interface. The protocol 532 used on the sr interface is the same as on the sy interface (s. 533 above), i.e. HTTPS. 535 Not relevant during the Trademark Claims Period. 537 4.3.13. vc 539 The TMV requests to add a revoked TMV certificate to the CRL at the 540 ICANN-CA via the vc interface. 542 The specifics of the vc interface are beyond the scope of this 543 document. 545 Not relevant during the Trademark Claims Period. 547 4.3.14. cy 549 During the Sunrise Period the Registry fetches the most recent CRL 550 from the ICANN-CA via the cy interface in regular intervals. The CRL 551 is mainly used for validation of TMV certificates. The protocol used 552 on the cy interface is HTTPS [RFC2818]. 554 Not relevant during the Trademark Claims Period. 556 4.3.15. cr 558 During the Sunrise Period the Registrar may fetch the most recent CRL 559 from the ICANN-CA via the cr interface. The protocol used on the cr 560 interface is the same as on the cy interface. 562 Not relevant during the Trademark Claims Period. 564 5. Process Descriptions 566 5.1. Bootstrapping 568 5.1.1. Bootstrapping for Registries 570 5.1.1.1. Credentials 572 Each Registry Operator will receive authentication credentials from 573 the TMDB/SMDM to be used: 575 o During the Sunrise Period to fetch the SMD Revocation List from 576 the SMDM via the sy interface (Section 4.3.11). 578 o During Trademark Claims Period to fetch the DNL List from the TMDB 579 via the dy interface (Section 4.3.3). 581 o During the NORDN process to notify the LORDN to the TMDB via the 582 yd interface (Section 4.3.7). 584 Note: credentials are created per TLD and provided to the Registry 585 Operator. 587 5.1.1.2. IP Addresses for Access Control 589 Each Registry Operator MUST provide to the TMDB all IP addresses that 590 will be used to: 592 o Fetch the SMD Revocation List via the sy interface 593 (Section 4.3.11). 595 o Fetch the DNL List from the TMDB via the dy interface 596 (Section 4.3.3). 598 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 600 This access restriction MAY be applied by the TMDB/SMDM in addition 601 to HTTP Basic access authentication (for credentials to be used, see 602 Section 5.1.1.1). 604 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 605 Registry Operator. 607 5.1.1.3. TMCH Trust Anchor 609 Each Registry Operator MUST fetch the X.509 certificate ([RFC5280] / 610 [RFC6818]) of the ICANN-CA (Trust Anchor) from 611 < https://ca.icann.org/tmch.crt > to be used: 613 o During the Sunrise Period to validate the TMV certificates and the 614 CRL of TMV certificates. 616 5.1.1.4. TMDB/SMDM PGP Key 618 The TMDB MUST provide each Registry Operator with the public portion 619 of the PGP Key used by TMDB and SMDM, to be used: 621 o During the Sunrise Period to perform integrity checking of the SMD 622 Revocation List fetched from the SMDM via the sy interface 623 (Section 4.3.11). 625 o During Trademark Claims Period to perform integrity checking of 626 the DNL List fetched from the TMDB via the dy interface 627 (Section 4.3.3). 629 5.1.2. Bootstrapping for Registrars 631 5.1.2.1. Credentials 633 Each ICANN-accredited Registrar will receive authentication 634 credentials from the TMDB to be used: 636 o During the Sunrise Period to (optionally) fetch the SMD Revocation 637 List from the SMDM via the sr interface (Section 4.3.12). 639 o During Trademark Claims Period to fetch TCNs from the TMDB via the 640 dr interface (Section 4.3.6). 642 5.1.2.2. IP Addresses for Access Control 644 Each Registrar MUST provide to the TMDB all IP addresses, which will 645 be used to: 647 o Fetch the SMD Revocation List via the sr interface 648 (Section 4.3.12). 650 o Fetch TCNs via the dr interface (Section 4.3.6). 652 This access restriction MAY be applied by the TMDB/SMDM in addition 653 to HTTP Basic access authentication (for credentials to be used, see 654 Section 5.1.2.1). 656 The TMDB MAY limit the number of IP addresses to be accepted per 657 Registrar. 659 5.1.2.3. TMCH Trust Anchor 661 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 662 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 663 be used: 665 o During the Sunrise Period to (optionally) validate the TMV 666 certificates and the CRL of TMV certificates. 668 5.1.2.4. TMDB PGP Key 670 Registrars MUST receive the public portion of the PGP Key used by 671 TMDB and SMDM from the TMDB administrator to be used: 673 o During the Sunrise Period to (optionally) perform integrity 674 checking of the SMD Revocation List fetched from the SMDM via the 675 sr interface (Section 4.3.12). 677 5.2. Sunrise Period 679 5.2.1. Domain Name Registration 681 Registration during Sunrise Period 683 .------------. .-----------. .----------. 684 | Registrant | | Registrar | | Registry | 685 '------------' '-----------' '----------' 686 ^ | | | 687 | | Request DN | | 688 | | Registration | | 689 | | (with SMD) | | 690 | |------------->| Check DN availability | 691 | | |---------------------------->| 692 | | | | 693 | | DN unava. | DN unavailable .-------------. 694 '---|<-------------|<--------------------( DN available? ) 695 | | no '-------------' 696 | | | yes 697 | | DN available | 698 | |<----------------------------| 699 | | | 700 | | Request DN registration | 701 | | (with SMD) | 702 | |---------------------------->| 703 | | | 704 | | .------------------------------. 705 | | | DN registration validation / | 706 | | | SMD validation | 707 | | '------------------------------' 708 | Registration | | 709 | Error |.-----------. Error .----------------------. 710 |<-------------|| TRY AGAIN |<------( Validation successful? ) 711 | || / ABORT | no '----------------------' 712 | |'-----------' | yes 713 | | | 714 | | DN registered | 715 | DN regist. |<----------------------------| 716 |<-------------| | 717 | | | 719 Figure 3 721 Note: the figure depicted above represents a synchronous DN 722 registration workflow (usually called first come first served). 724 5.2.2. Sunrise DN Registration by Registries 726 Registries MUST perform a minimum set of checks for verifying each DN 727 registration during the Sunrise Period upon reception of a 728 registration request over the ry interface (Section 4.3.5). If any 729 of these checks fails the Registry MUST abort the registration. Each 730 of these checks MUST be performed before the DN is effectively 731 allocated. 733 In case of asynchronous registrations (e.g. auctions), the minimum 734 set of checks MAY be performed when creating the intermediate object 735 (e.g. a DN application) used for DN registration. If the minimum set 736 of checks is performed when creating the intermediate object (e.g. a 737 DN application) a Registry MAY effective allocate the DN without 738 performing the minimum set of checks again. 740 Performing the minimum set of checks Registries MUST verify that: 742 1. A SMD has been received from the Registrar along with the DN 743 registration. 745 2. The certificate of the TMV has been correctly signed by the 746 ICANN-CA. (The certificate of the TMV is contained within the 747 SMD.) 749 3. The time when the validation is done is within the validity 750 period of the TMV certificate. 752 4. The certificate of the TMV is not be listed in the CRL file 753 specified in the CRL distribution point of the TMV certificate. 755 5. The signature of the SMD (signed with the TMV certificate) is 756 valid. 758 6. The time when the validation is done is within the validity 759 period of the SMD based on and 760 elements. 762 7. The SMD has not been revoked, i.e., is not contained in the SMD 763 Revocation List. 765 8. The leftmost DNL (A-label in case of IDNs) of the DN being 766 effectively allocated matches one of the labels () 767 elements in the SMD. 769 These procedure apply to all DN effective allocations at the second 770 level as well as to all other levels subordinate to the TLD that the 771 Registry accepts registrations for. 773 5.2.3. TMDB Sunrise Services for Registries 775 5.2.3.1. SMD Revocation List 777 A new SMD Revocation List MUST be published by the SMDM twice a day, 778 by 00:00:00 and 12:00:00 UTC. 780 Registries MUST refresh the latest version of the SMD Revocation List 781 at least once every 24 hours. 783 Note: the SMD Revocation List will be the same regardless of the TLD. 784 If a Backend Registry Operator manages the infrastructure of several 785 TLDs, the Backend Registry Operator could refresh the SMD Revocation 786 List once every 24 hours, the SMD Revocation List could be used for 787 all the TLDs managed by the Backend Registry Operator. 789 Update SMD Revocation List 791 .----------. .------. 792 | Registry | | SMDM | 793 '----------' '------' 794 | | 795 .----------------. | 796 | Periodically, | | 797 | at least | | 798 | every 24 hours | | 799 '----------------' | 800 | | 801 |----------------------------------------------------->| 802 | Download latest revocation list for SMD certificates | 803 |<-----------------------------------------------------| 804 | | 805 | | 807 Figure 4 809 5.2.3.2. Certificate Revocation List 811 Registries MUST refresh their local copy of the CRL at least every 24 812 hours using the CRL distribution point specified in the TMV 813 certificate. 815 Operationally, the CRL file and CRL distribution point is the same 816 for all TMVs and (at publication of this document) located at 817 < http://crl.icann.org/tmch.crl >. 819 Note: the CRL file will be the same regardless of the TLD. If a 820 Backend Registry Operator manages the infrastructure of several TLDs, 821 the Backend Registry Operator could refresh the CRL file once every 822 24 hours, the CRL file could be used for all the TLDs managed by the 823 Backend Registry Operator. 825 Update CRL for TMV certificates 827 .----------. .----------. 828 | Registry | | ICANN-CA | 829 '----------' '----------' 830 | | 831 .----------------. | 832 | Periodically, | | 833 | at least | | 834 | every 24 hours | | 835 '----------------' | 836 | | 837 |------------------------------------------->| 838 | Download latest CRL for TMV certificates | 839 |<-------------------------------------------| 840 | | 841 | | 843 Figure 5 845 5.2.3.3. Notice of Registered Domain Names 847 The Registry MUST send a LORDN file containing DNs effectively 848 allocated to the TMDB (over the yd interface, Section 4.3.7). 850 The effective allocation of a DN MUST be reported by the Registry to 851 the TMDB within 26 hours of the effective allocation of such DN. 853 The Registry MUST create and upload a LORDN file in case there are 854 effective allocations in the SRS, that have not been successfully 855 reported to the TMDB in a previous LORDN file. 857 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 858 maximum frequency to upload LORDN files from the Registries to the 859 TMDB is every 3 hours. 861 It is RECOMMENDED that Registries try to upload at least two LORDN 862 files per day to the TMDB with enough time in between, in order to 863 have time to fix problems reported in the LORDN file. 865 The Registry SHOULD upload a LORDN file only when the previous LORDN 866 file has been processed by the TMDB and the related LORDN Log file 867 has been downloaded and processed by the Registry. 869 The Registry MUST upload LORDN files for DNs effectively allocated 870 during the Sunrise or Claims period (same applies to DNs effectively 871 allocated using applications created during the Sunrise or Claims 872 period in case of using asynchronous registrations). 874 The yd interface (Section 4.3.7) MUST support at least 1 and MAY 875 support up to 10 concurrent connections from each IP address 876 registered by a Registry Operator to access the service. 878 The TMDB MUST process each uploaded LORDN file and make the related 879 log file available for Registry download within 30 minutes of the 880 finalization of the upload. 882 NORDN 884 .----------. .------. .-----. .-----. 885 | Registry | | TMDB | | TMV | | TMH | 886 '----------' '------' '-----' '-----' 887 | | | | 888 .------------------. | | | 889 | Periodically | | | | 890 | upload LORDN | | | | 891 | file | | | | 892 '------------------' | | | 893 | | | | 894 .--------->| Upload LORDN | | | 895 | |-------------------->| | | 896 | | | | | 897 | | .-------------------------. | | 898 | | | Verify each domain name | | | 899 | | | in the uploaded file | | | 900 | | | (within 30') | | | 901 | | '-------------------------' | | 902 | | | ._____. | | 903 | | Download Log file | | END | | | 904 | |<--------------------| '-----' | | 905 | | | ^ | | 906 | .-----------------. .---------------. | | | 907 | | Check whether | / everything fine \ no | | | 908 | | Log file | ( (i.e. no errors )---' | | 909 | | contains errors | \ in Log file )? / | | 910 | '-----------------' '---------------' | | 911 | | | yes | | 912 | .---------------. | | | 913 | / everything fine \ yes | | | 914 |( (i.e. no errors )-----. | Notify TMVs | | 915 | \ in Log file )? / | | on the LORDN | | 916 | '---------------' | | pre-registered | | 917 | | no v | with said TMV | | 918 | .----------------. .------. |--------------->| | 919 '-| Correct Errors | | DONE | | | | 920 '----------------' '------' | | Notify each | 921 | | | affected TMH | 922 | | |------------->| 923 | | | | 925 Figure 6 927 The format used for the LORDN is described in Section 6.3 929 5.2.4. Sunrise DN registration by Registrars 931 Registrars MAY choose to perform the checks for verifying DN 932 registrations as performed by the Registries (see Section 5.2.2) 933 before sending the command to register a DN. 935 5.2.5. TMDB Sunrise Services for Registrars 937 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 938 also available for Registrars to optionally validate the SMDs 939 received. 941 5.3. Trademark Claims Period 943 5.3.1. Domain Registration 945 Registration during Trademark Claims Period 947 .------------. .-----------. .----------. .------. 948 | Registrant | | Registrar | | Registry | | TMDB | 949 '------------' '-----------' '----------' '------' 950 ^ | Request DN | | | 951 | | Registration | Check DN availability | | 952 | |------------->|---------------------------->| | 953 | | DN unava. | DN unavailable .-------------. | 954 '---|<-------------|<--------------------( DN available? ) | 955 | | no '-------------' | 956 | | | yes | 957 | | DN available | | 958 | |<----------------------------| | 959 | | Request Lookup key | | 960 | |---------------------------->| | 961 | | .---------. | 962 | |.----------. / Does DN \ | 963 | || CONTINUE |<---------( match DNL ) | 964 | || NORMALLY | no \ of PRM? / | 965 | |'----------' '---------' | 966 | | | yes | 967 | | Lookup key | | 968 | |<----------------------------| | 969 | | Request Claims Notice | 970 | Display |----------------------------------------->| 971 | Claims | | 972 | Notice | Return Claims Notice | 973 |<-------------|<-----------------------------------------| 974 | | | 975 .------. yes | Register DN (TCNID included) | 976 ( Ack? )--------->|---------------------------->| | 977 '------' | | | 978 ||no | Error .----------------------. | 979 || .-------. |<--------------( Validation successful? ) | 980 |'->| ABORT | | no '----------------------' | 981 | '-------' | | yes | 982 | DN regist. | DN registered | | 983 |<-------------|<----------------------------| | 984 | | | | 986 Figure 7 988 Note: the figure depicted above represents a synchronous DN 989 registration workflow (usually called first come first served). 991 5.3.2. Trademark Claims DN registration by Registries 993 During Trademark Claim Periods, Registries perform two main 994 functions: 996 o Registries MUST provide Registrars (over the ry interface, 997 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 998 that match the DNL List. 1000 o Registries MUST provide the Lookup Key only when queried about a 1001 specific DN. 1003 o For each DN matching a DNL of a PRM, Registries MUST perform a 1004 minimum set of checks for verifying DN registrations during 1005 Trademark Claims Period upon reception of a registration request 1006 over the ry interface (Section 4.3.5). If any of these checks 1007 fails the Registry MUST abort the registration. Each of these 1008 checks MUST be performed before the DN is effectively allocated. 1010 o In case of asynchronous registrations (e.g. auctions), the minimum 1011 set of checks MAY be performed when creating the intermediate 1012 object (e.g. a DN application) used for DN effective allocation. 1013 If the minimum set of checks is performed when creating the 1014 intermediate object (e.g. a DN application) a Registry MAY 1015 effective allocate the DN without performing the minimum set of 1016 checks again. 1018 o Performing the minimum set of checks Registries MUST verify that: 1020 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been 1022 received from the Registrar along with the DN registration. 1024 If the three elements mentioned above are not provided by 1025 the Registrar for a DN matching a DNL of a PRM, but the DNL 1026 was inserted (or re-inserted) for the first time into DNL 1027 List less than 24 hours ago, the registration MAY continue 1028 without this data and the tests listed below are not 1029 required to be performed. 1031 2. The TCN has not expired (according to the expiration datetime 1032 sent by the Registrar). 1034 3. The acceptance datetime is no more than 48 hours in the past. 1036 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1037 being registered, the expiration datetime provided by the 1038 registrar, and the TMDB Notice Identifier extracted from the 1039 TCNID provided by the registrar compute the TCN Checksum. 1040 Verify that the computed TCN Checksum match the TCN Checksum 1041 present in the TCNID. 1043 These procedures apply to all DN registrations at the second level as 1044 well as to all other levels subordinate to the TLD that the Registry 1045 accepts registrations for. 1047 5.3.3. TMBD Claims Services for Registries 1049 5.3.3.1. Domain Name Label (DNL) List 1051 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1052 and 12:00:00 UTC. 1054 Registries MUST refresh the latest version of the DNL List at least 1055 once every 24 hours. 1057 Update DNL List 1059 .----------. .------. 1060 | Registry | | TMDB | 1061 '----------' '------' 1062 | | 1063 .----------------. | 1064 | Periodically, | | 1065 | at least | | 1066 | every 24 hours | | 1067 '----------------' | 1068 | | 1069 |-------------------------------->| 1070 | Download latest list of DNLs | 1071 |<--------------------------------| 1072 | | 1073 | | 1075 Figure 8 1077 Note: the DNL List will be the same regardless of the TLD. If a 1078 Backend Registry Operator manages the infrastructure of several TLDs, 1079 the Backend Registry Operator could refresh the DNL List once every 1080 24 hours, the DNL List could be used for all the TLDs managed by the 1081 Backend Registry Operator. 1083 5.3.3.2. Notice of Registered Domain Names 1085 The NORDN process during the Trademark Claims Period is almost the 1086 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1087 difference that only registrations subject to a Trademark Claim 1088 (i.e., at registration time the name appeared in the current DNL List 1089 downloaded by the Registry Operator) are included in the LORDN. 1091 5.3.4. Trademark Claims DN Registration by Registrars 1093 For each DN matching a DNL of a PRM, Registrars MUST perform the 1094 following steps: 1096 1. Use the Lookup Key received from the Registry to obtain the TCN 1097 from the TMDB using the dr interface (Section 4.3.6) Registrars 1098 MUST only query for the Lookup Key of a DN that is available for 1099 registration. 1101 2. Present the TCN to the Registrant as described in 1102 [ICANN-GTLD-AGB-20120604]. 1104 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1105 consent with the TCN, before any further processing. (The 1106 transmission of a TCNID to the Registry over the ry interface, 1107 Section 4.3.5 implies that the Registrant has expressed his 1108 consent with the TCN.) 1110 4. Perform the minimum set of checks for verifying DN registrations. 1111 If any of these checks fails the Registrar MUST abort the DN 1112 registration. Each of these checks MUST be performed before the 1113 registration is sent to the Registry. Performing the minimum set 1114 of checks Registrars MUST verify that: 1116 1. The time when the validation is done is within the TCN 1117 validity based on the and elements. 1120 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1121 effectively allocated matches the label () 1122 element in the TCN. 1124 3. The Registrant has acknowledged (expressed his consent with) 1125 the TCN. 1127 5. Record the date and time when the registrant acknowledged the 1128 TCN. 1130 6. Send the registration to the Registry (ry interface, 1131 Section 4.3.5) and include the following information: 1133 * TCNID () 1135 * Expiration date of the TCN () 1137 * Acceptance datetime of the TCN. 1139 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the 1141 TMDB, allowing the implementation of a cache by Registrars and enough 1142 time for acknowledging the TCN. Registrars SHOULD implement a cache 1143 of TCNs to minimize the number of queries sent to the TMDB. A cached 1144 TCN MUST be removed from the cache after the expiration date of the 1145 TCN as defined by . The TMDB MAY implement rate- 1146 limiting as one of the protection mechanisms to mitigate the risk of 1147 performance degradation. 1149 5.3.5. TMBD Claims Services for Registrars 1151 5.3.5.1. Claims Notice Information Service 1153 The TCNs are provided by the TMDB online and are fetched by the 1154 Registrar via the dr interface (Section 4.3.6). 1156 To get access to the TCNs, the Registrar needs the credentials 1157 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1158 from the Registry via the ry interface (Section 4.3.5). The dr 1159 interface (Section 4.3.6) uses HTTPS with Basic access 1160 authentication. 1162 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1163 connections from each Registrar. 1165 The URL of the dr interface (Section 4.3.6) is: 1167 < https:///cnis/.xml > 1169 Note that the "lookupkey" may contain SLASH characters ("/"). The 1170 SLASH character is part of the URL path and MUST NOT be escaped when 1171 requesting the TCN. 1173 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1174 MUST be signed by a well-know public CA. Registrars MUST perform the 1175 Certification Path Validation described in Section 6 of [RFC5280]. 1176 Registrars will be authenticated in the dr interface using HTTP Basic 1177 access authentication. The dr (Section 4.3.6) interface MUST support 1178 HTTPS keep-alive and MUST maintain the connection for up to 30 1179 minutes. 1181 5.4. Qualified Launch Program Period 1183 5.4.1. Domain Registration 1185 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1186 (QLP) period effective allocations of DNs to third parties could 1187 require that Registries and Registrars provide Sunrise and/or Claims 1188 services. If required, Registries and Registrars MUST provide 1189 Sunrise and/or Claims services as described in: Section 5.2 and 1190 Section 5.3. 1192 The effective allocation scenarios are: 1194 o If the leftmost DNL (A-label in case of IDNs) of the DN being 1195 effectively allocated (QLP Name in this section) matches a DNL in 1196 the SURL, and an SMD is provided, then Registries MUST provide 1197 Sunrise Services (see Section 5.2) and the DN MUST be reported in 1198 a Sunrise LORDN file during the QLP period. 1200 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1201 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1202 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1203 file using the special SMD-id "99999-99999" during the QLP period. 1205 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1206 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1207 [QLP-Addendum]), then Registries MUST provide Claims services (see 1208 Section 5.3) and the DN MUST be reported in a Claims LORDN file 1209 during the QLP period. 1211 o If the QLP Name matches a DNL in the DNL List but does not match a 1212 DNL in the SURL, then Registries MUST provide Claims services (see 1213 Section 5.2) and the DN MUST be reported in a Claims LORDN file 1214 during the QLP period. 1216 The following table lists all the effective allocation scenarios 1217 during a QLP Period: 1219 +--------+---------+-----------------+-------------+----------------+ 1220 | QLP | QLP | SMD was | Registry | Registry MUST | 1221 | Name | Name | provided by the | MUST | report DN | 1222 | match | match | potential | provide | registration | 1223 | in the | in the | Registrant | Sunrise or | in | 1224 | SURL | DNL | | Claims | LORDN file | 1225 | | List | | Services | | 1226 +--------+---------+-----------------+-------------+----------------+ 1227 | Y | Y | Y | Sunrise | Sunrise | 1228 | | | | | | 1229 | Y | N | Y | Sunrise | Sunrise | 1230 | | | | | | 1231 | N | Y | -- | Claims | Claims | 1232 | | | | | | 1233 | N | N | -- | -- | -- | 1234 | | | | | | 1235 | Y | Y | N (see section | Claims | Claims | 1236 | | | 2.2 of | | | 1237 | | | [QLP-Addendum]) | | | 1238 | | | | | | 1239 | Y | N | N (see section | -- | Sunrise (using | 1240 | | | 2.2 of | | special | 1241 | | | [QLP-Addendum]) | | SMD-id) | 1242 +--------+---------+-----------------+-------------+----------------+ 1244 QLP Effective Allocation Scenarios 1246 The TMDB MUST provide the following services to Registries during a 1247 QLP period: 1249 o SMD Revocation List (see Section 5.2.3.1) 1251 o Notice of Registered Domain Names (see Section 5.2.3.3) 1253 o Domain Name Label List (see Section 5.3.3.1) 1255 o Sunrise List (see Section 5.4.2.1 1257 The TMDB MUST provide the following services to Registrars during a 1258 QLP period: 1260 o SMD Revocation List (see Section 5.2.3.1) 1262 o Claims Notice Information Service (see Section 5.3.5.1) 1264 5.4.2. TMBD QLP Services for Registries 1266 5.4.2.1. Sunrise List (SURL) 1268 A new Sunrise List MUST be published by the TMDB twice a day, by 00: 1269 00:00 and 12:00:00 UTC. 1271 Registries offering the OPTIONAL QLP period MUST refresh the latest 1272 version of the Sunrise List at least once every 24 hours. 1274 Update Sunrise List 1276 .----------. .------. 1277 | Registry | | TMDB | 1278 '----------' '------' 1279 | | 1280 .----------------. | 1281 | Periodically, | | 1282 | at least | | 1283 | every 24 hours | | 1284 '----------------' | 1285 | | 1286 |-------------------------------->| 1287 | Download latest list of DNLs | 1288 |<--------------------------------| 1289 | | 1290 | | 1292 Figure 9 1294 Note: the Sunrise List will be the same regardless of the TLD. If a 1295 Backend Registry Operator manages the infrastructure of several TLDs, 1296 the Backend Registry Operator could refresh the Sunrise List once 1297 every 24 hours, the Sunrise List could be used for all the TLDs 1298 managed by the Backend Registry Operator. 1300 6. Data Format Descriptions 1302 6.1. DNL List file 1304 This section defines the format of the list containing every Domain 1305 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1306 is maintained by the TMDB and downloaded by Registries in regular 1307 intervals (see Section 5.3.3.1). The Registries use the DNL List 1308 during the Trademark Claims period to check whether a requested DN 1309 matches a DNL of a PRM. 1311 The DNL List contains all the DNLs covered by a PRM present in the 1312 TMDB at the time it is generated. 1314 The DNL List is contained in a CSV-like formatted file that has the 1315 following structure: 1317 o first line: , 1319 Where: 1321 + , version of the file, this field MUST be 1. 1323 + , date and time in UTC that the 1324 DNL List was created. 1326 o second line: a header line as specified in [RFC4180] 1328 With the header names as follows: 1330 DNL,lookup-key,insertion-datetime 1332 o One or more lines with: ,, 1335 Where: 1337 + , a Domain Name Label covered by a PRM. 1339 + , lookup key that the Registry MUST provide to 1340 the Registrar. The lookup key has the following format: 1341
////, where: 1344 - YYYY: year that the TCN was generated. 1346 - MM: zero-padded month that the TCN was generated. 1348 - DD: zero-padded day that the TCN was generated. 1350 - vv: version of the TCN, possible values are 00 and 01. 1352 - X: one hexadecimal digit [0-9A-F]. This is the first, 1353 second and third hexadecimal digit of encoding the 1354 in base16 as specified in [RFC4648]. 1356 - Random bits: 144 random bits encoded in base64url as 1357 specified in [RFC4648]. 1359 - Sequential number: zero-padded natural number in the 1360 range 0000000001 to 2147483647. 1362 + , datetime in UTC that the DNL was 1363 first inserted into the DNL List. The possible two values 1364 of time for inserting a DNL to the DNL List are 00:00:00 and 1365 12:00:00 UTC. 1367 Example for DNL List 1369 1,2012-08-16T00:00:00.0Z 1370 DNL,lookup-key,insertion-datetime 1371 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1372 2010-07-14T00:00:00.0Z 1373 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1374 2012-08-16T00:00:00.0Z 1375 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1376 2011-08-16T12:00:00.0Z 1378 Figure 10 1380 To provide authentication and integrity protection, the DNL List will 1381 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1382 (see also Section 5.1.1.4). The PGP signature of the DNL List can be 1383 found in the similar URI but with extension .sig as shown below. 1385 The URL of the dy interface (Section 4.3.3) is: 1387 o < https:///dnl/dnl-latest.csv > 1389 o < https:///dnl/dnl-latest.sig > 1391 6.2. SMD Revocation List 1393 This section defines the format of the list of SMDs that have been 1394 revoked. The list is maintained by the SMDM and downloaded by 1395 Registries (and optionally by Registrars) in regular intervals (see 1396 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1397 Period to validate SMDs received. The SMD Revocation List has a 1398 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1400 The SMD Revocation List contains all the revoked SMDs present in the 1401 TMDB at the time it is generated. 1403 The SMD Revocation List is contained in a CSV-like formatted file 1404 that has the following structure: 1406 o first line: , 1408 Where: 1410 + , version of the file, this field MUST be 1. 1412 + , datetime in UTC 1413 that the SMD Revocation List was created. 1415 o second line: a header line as specified in [RFC4180] 1417 With the header names as follows: 1419 smd-id,insertion-datetime 1421 o One or more lines with: , 1423 Where: 1425 + , identifier of the SMD that was revoked. 1427 + , revocation datetime in UTC of the 1428 SMD. The possible two values of time for inserting an SMD 1429 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1431 To provide integrity protection, the SMD Revocation List is PGP 1432 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1433 also Section 5.1.1.4). The SMD Revocation List is provided by the 1434 TMDB with extension .csv. The PGP signature of the SMD Revocation 1435 List can be found in the similar URI but with extension .sig as shown 1436 below. 1438 The URL of the sr interface (Section 4.3.12) and sy interface 1439 (Section 4.3.11) is: 1441 o < https:///smdrl/smdrl-latest.csv > 1443 o < https:///smdrl/smdrl-latest.sig > 1445 Example for SMD Revocation list 1447 1,2012-08-16T00:00:00.0Z 1448 smd-id,insertion-datetime 1449 2-2,2012-08-15T00:00:00.0Z 1450 3-2,2012-08-15T00:00:00.0Z 1451 1-2,2012-08-15T00:00:00.0Z 1453 Figure 11 1455 6.3. LORDN File 1457 This section defines the format of the List of Registered Domain 1458 Names (LORDN), which is maintained by each Registry and uploaded at 1459 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1460 said DN is added to the LORDN along with further information related 1461 to its registration. 1463 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1464 file is: 1466 o Sunrise LORDN file: 1468 < https:///LORDN//sunrise > 1470 o Claims LORDN file: 1472 < https:///LORDN//claims > 1474 During a QLP period, Registries MAY be required to upload Sunrise or 1475 Claims LORDN files. The URIs of the yd interface used to upload 1476 LORDN files during a QLP period is: 1478 o Sunrise LORDN file (during QLP period): 1480 < https:///LORDN//sunrise/qlp > 1482 o Claims LORDN file (during a QLP period): 1484 < https:///LORDN//claims/qlp > 1486 The yd interface (Section 4.3.7) returns the following HTTP status 1487 codes after a HTTP POST request method is received: 1489 o The interface provides a HTTP/202 status code if the interface was 1490 able to receive the LORDN file and the syntax of the LORDN file is 1491 correct. 1493 The interface provides the LORDN Transaction Identifier in the 1494 HTTP Entity-body that would be used by the Registry to download 1495 the LORDN Log file. The LORDN Transaction Identifier is a 1496 natural number zero-padded in the range 0000000000000000001 to 1497 9223372036854775807. 1499 The TMDB uses the element of the 1500 LORDN file as a unique client-side identifier. If a LORDN file 1501 with the same of a previously sent 1502 LORDN file is received by the TMDB, the LORDN Transaction 1503 Identifier of the previously sent LORDN file MUST be provided 1504 to the Registry. The TMDB MUST ignore the DN Lines present in 1505 the LORDN file if a LORDN file with the same was previously sent. 1508 The HTTP Location header field contains the URI where the LORDN 1509 Log file could be retrieved later, for example: 1511 202 Accepted 1513 Location: https:///LORDN/example/sunrise/ 1514 0000000000000000001/result 1516 o The interface provides a HTTP/400 if the request is incorrect or 1517 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1518 human readable message in the HTTP Entity-body regarding the 1519 incorrect syntax of the LORDN file. 1521 o The interface provides a HTTP/401 status code if the credentials 1522 provided does not authorize the Registry Operator to upload a 1523 LORDN file. 1525 o The TMDB MUST return a HTTP/404 status code when trying to upload 1526 a LORDN file using the 1527 https:///LORDN//sunrise/qlp or 1528 https:///LORDN//claims/qlp interface 1529 outside of a QLP period plus 26 hours. 1531 o The interface provides a HTTP/500 status code if the system is 1532 experiencing a general failure. 1534 For example, to upload the Sunrise LORDN file for TLD "example", the 1535 URI would be: 1537 < https:///LORDN/example/sunrise > 1539 The LORDN is contained in a CSV-like formatted file that has the 1540 following structure: 1542 o For Sunrise Period: 1544 * first line: ,, 1547 Where: 1549 - , version of the file, this field MUST be 1. 1551 - , date and time in UTC that the 1552 LORDN was created. 1554 - , number of DN Lines present in the 1555 LORDN file. 1557 * second line: a header line as specified in [RFC4180] 1559 With the header names as follows: 1561 roid,domain-name,SMD-id,registrar-id,registration- 1562 datetime,application-datetime 1564 * One or more lines with: ,,,,, 1568 Where: 1570 - , DN Repository Object IDentifier (DNROID) in the 1571 SRS. 1573 - , DN that was effectively allocated. For 1574 IDNs the A-Label is used [RFC5890] 1576 - , SMD ID used for registration. 1578 - , IANA Registrar ID. 1580 - , date and time in UTC that the 1581 domain was effectively allocated. 1583 - OPTIONAL , date and 1584 time in UTC that the application was created. The 1585 MUST be provided in 1586 case of a DN effective allocation based on an 1587 asynchronous registration (e.g., when using auctions). 1589 Example for LORDN during Sunrise 1591 1,2012-08-16T00:00:00.0Z,3 1592 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1593 application-datetime 1594 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1595 2012-07-15T00:50:00.0Z 1596 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1597 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1599 Figure 12 1601 o For Trademark Claims Period: 1603 * first line: ,, 1606 Where: 1608 - , version of the file, this field MUST be 1. 1610 - , date and time in UTC that the 1611 LORDN was created. 1613 - , number of DN Lines present in the 1614 LORDN file. 1616 * second line: a header line as specified in [RFC4180] 1618 With the header names as follows: 1620 roid,domain-name,notice-id,registrar-id,registration- 1621 datetime,ack-datetime,application-datetime 1623 * One or more lines with: ,,,,,, 1627 Where: 1629 - , DN Repository Object IDentifier (DNROID) in the 1630 SRS. 1632 - , DN that was effectively allocated. For 1633 IDNs the A-Label is used [RFC5890]. 1635 - , Trademark Claims Notice Identifier as specified 1636 in . 1638 - , IANA Registrar ID. 1640 - , date and time in UTC that the 1641 domain was effectively allocated. 1643 - , date and time in UTC 1644 that the TCN was acknowledged. 1646 - OPTIONAL , date and 1647 time in UTC that the application was created. The 1648 MUST be provided in 1649 case of a DN effective allocation based on an 1650 asynchronous registration (e.g., when using auctions). 1652 For a DN matching a DNL of a PRM at the moment of 1653 registration, created without the TCNID, expiration datetime 1654 and acceptance datetime, because DNL was inserted (or re- 1655 inserted) for the first time into DNL List less than 24 1656 hours ago, the string "recent-dnl-insertion" MAY be 1657 specified in and . 1660 Example for LORDN during Claims 1662 1,2012-08-16T00:00:00.0Z,3 1663 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1664 ack-datetime,application-datetime 1665 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1666 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1667 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1668 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1669 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1670 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1672 Figure 13 1674 6.3.1. LORDN Log File 1676 After reception of the LORDN file, the TMDB verifies its content for 1677 syntactical and semantical correctness. The output of the LORDN file 1678 verification is retrieved using the yd interface (Section 4.3.7). 1680 The URI of the yd interface (Section 4.3.7) used to retrieve the 1681 LORDN Log File is: 1683 o Sunrise LORDN Log file: 1685 < https:///LORDN//sunrise/ 1686 /result > 1688 o Claims LORDN Log file: 1690 < https:///LORDN//claims/ 1691 /result > 1693 A Registry Operator MUST NOT send more than one request per minute 1694 per TLD to download a LORDN Log file. 1696 The yd interface (Section 4.3.7) returns the following HTTP status 1697 codes after a HTTP GET request method is received: 1699 o The interface provides a HTTP/200 status code if the interface was 1700 able to provide the LORDN Log file. The LORDN Log file is 1701 contained in the HTTP Entity-body. 1703 o The interface provides a HTTP/204 status code if the LORDN 1704 Transaction Identifier is correct, but the server has not 1705 finalized processing the LORDN file. 1707 o The interface provides a HTTP/400 status code if the request is 1708 incorrect. 1710 o The interface provides a HTTP/401 status code if the credentials 1711 provided does not authorize the Registry Operator to download the 1712 LORDN Log file. 1714 o The interface provides a HTTP/404 status code if the LORDN 1715 Transaction Identifier is incorrect. 1717 o The interface provides a HTTP/500 status code if the system is 1718 experiencing a general failure. 1720 For example, to obtain the LORDN Log File in case of a Sunrise LORDN 1721 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1722 "example" the URI would be: 1724 < https:///LORDN/example/sunrise/ 1725 0000000000000000001/result > 1727 The LORDN Log file is contained in a CSV-like formatted file that has 1728 the following structure: 1730 o first line: ,,,,,, 1734 Where: 1736 + , version of the file, this field MUST be 1. 1738 + , date and time in UTC that the 1739 LORDN Log was created. 1741 + , date and time in UTC of 1742 creation for the LORDN file that this log file is referring 1743 to. 1745 + , unique identifier of the LORDN Log 1746 provided by the TMDB. This identifier could be used by the 1747 Registry Operator to unequivocally identify the LORDN Log. 1748 The identified will be a string of a maximum LENGTH of 60 1749 characters from the Base 64 alphabet. 1751 + , whether the LORDN file has been accepted for 1752 processing by the TMDB. Possible values are "accepted" or 1753 "rejected". 1755 + , whether the LORDN Log has any warning result 1756 codes. Possible values are "no-warnings" or "warnings- 1757 present". 1759 + , number of DNs effective allocations 1760 processed in the LORDN file. 1762 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1763 a ="accepted" and ="no-warnings". 1765 o second line: a header line as specified in [RFC4180] 1767 With the header names as follows: 1769 roid,result-code 1771 o One or more lines with: , 1773 Where: 1775 + , DN Repository Object IDentifier (DNROID) in the SRS. 1777 + , result code as described in Section 6.3.1.1. 1779 Example for LORDN Log file 1781 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1782 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1783 accepted,no-warnings,1 1784 roid,result-code 1785 SH8013-REP,2000 1787 Figure 14 1789 6.3.1.1. LORDN Log Result Codes 1791 In Figure 15 the classes of result codes (rc) are listed. Those 1792 classes in square brackets are not used at this time, but may come 1793 into use at some later stage. The first two digits of a result code 1794 denote the result code class, which defines the outcome at the TMDB: 1796 o ok: Success, DN Line accepted by the TMDB. 1798 o warn: a warning is issued, DN Line accepted by the TMDB. 1800 o err: an error is issued, LORDN file rejected by the TMDB. 1802 In case that after processing a DN Line, the error result code is 1803 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1804 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1805 valid will be reported with a 2001 result code. A 2001 result code 1806 means that the DN Line is syntactically valid, however the DN Line 1807 was not processed because the LORDN file was rejected. All DNs 1808 reported in a rejected LORDN file MUST be reported again by the 1809 Registry because none of the DN Lines present in the LORDN file have 1810 been processed by the TMDB. 1812 LORDN Log Result Code Classes 1814 code Class outcome 1815 ---- ----- ------- 1817 20xx Success ok 1819 35xx [ DN Line syntax warning ] warn 1820 36xx DN Line semantic warning warn 1822 45xx DN Line syntax error err 1823 46xx DN Line semantic error err 1825 Figure 15 1827 In the following, the LORDN Log result codes used by the TMDB are 1828 described: 1830 LORDN Log result Codes 1832 rc Short Description 1833 Long Description 1835 ---- ------------------------------------------------------------- 1837 2000 OK 1838 DN Line successfully processed. 1840 2001 OK but not processed 1841 DN Line is syntactically correct but was not processed 1842 because the LORDN file was rejected. 1844 3601 TCN Acceptance Date after Registration Date 1845 TCN Acceptance Date in DN Line is newer than the Registration 1846 Date. 1848 3602 Duplicate DN Line 1849 This DN Line is an exact duplicate of another DN Line in same 1850 file, DN Line ignored. 1852 3603 DNROID Notified Earlier 1853 Same DNROID has been notified earlier, DN Line ignored. 1855 3604 TCN Checksum invalid 1856 Based on the DN effectively allocated, the TCNID and the 1857 expiration date of the linked TCN, the TCN Checksum is 1858 invalid. 1860 3605 TCN Expired 1861 The TCN was already expired (based on the field of the TCN) 1862 at the time of acknowledgement. 1864 3606 Wrong TCNID used 1865 The TCNID used for the registration does not match 1866 the related DN. 1868 3609 Invalid SMD used 1869 The SMD used for registration was not valid at the moment of 1870 registration based on the and 1871 elements. 1872 In case of an asynchronous registration, this refer to the 1873 . 1875 3610 DN reported outside of the time window 1876 The DN was reported outside of the required 26 hours 1877 reporting window. 1879 3611 DN does not match the labels in SMD 1880 The DN does not match the labels included in the SMD. 1882 3612 SMDID does not exist 1883 The SMDID has never existed in the central repository. 1885 3613 SMD was revoked when used 1886 The SMD used for registration was revoked more than 1887 24 hours ago of the . 1888 In case of an asynchronous registration, 1889 the is used when 1890 validating the DN Line. 1892 3614 TCNID does not exist 1893 The TCNID has never existed in the central repository. 1895 3615 Recent-dnl-insertion outside of the time window 1896 The DN registration is reported as a recent-dnl-insertion, 1897 but the (re) insertion into the DNL ocurred more than 1898 24 hours ago. 1900 3616 Registration Date of DN in claims before the end of Sunrise 1901 The registration date of the DN is before the end of Sunrise 1902 and the DN was reported in a claims LORDN file. 1904 3617 Registrar has not been approved by the TMDB 1905 Registrar ID in DN Line has not completed Claims integration 1906 testing with the TMDB. 1908 3618 Registration Date of DN in a QLP LORDN file outside of the QLP period 1909 The registration date of the DN in a QLP LORDN file is outside 1910 of the QLP period. 1912 3619 TCN was not valid 1913 The TCN was not valid (based on the field of the TCN) 1914 at the time of acknowledgement. 1916 4501 Syntax Error in DN Line 1917 Syntax Error in DN Line. 1919 4601 Invalid TLD used 1920 The TLD in the DN Line does not match what is expected for 1921 this LORDN. 1923 4602 Registrar ID Invalid 1924 Registrar ID in DN Line is not a valid ICANN-Accredited 1925 Registrar. 1927 4603 Registration Date in the future 1928 The in the DN Line is in the 1929 future. 1931 4606 TLD not in Sunrise or Claims 1932 The was reported when the TLD was 1933 not in Sunrise or Claims. 1934 In case of an asynchronous registration, 1935 the is used when 1936 validating the DN Line. 1938 4607 Application Date in the future 1939 The in the DN Line is in the 1940 future. 1942 4608 Application Date is later than Registration Date 1943 The in the DN Line is later 1944 than the . 1946 4609 TCNID wrong syntax 1947 The syntax of the TCNID is invalid. 1949 4610 TCN Acceptance Date is in the future 1950 The is in the future. 1952 4611 Label has never existed in the TMDB 1953 The label in the registered DN has never existed in the TMDB. 1955 Figure 16 1957 6.4. SMD File 1959 This section defines the format of the SMD File. After a successful 1960 registration of a mark, the TMV returns an SMD File to the TMH. The 1961 SMD File can then be used for registration of one or more DNs covered 1962 by the PRM during the Sunrise Period of a TLD. 1964 Two encapsulation boundaries are defined for delimiting the 1965 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1966 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1967 boundaries MUST be used by Registries and Registrars for validation 1968 purposes, i.e. any data outside these boundaries as well as the 1969 boundaries themselves MUST be ignored for validation purposes. 1971 The structure of the SMD File is as follows: 1973 o Marks: 1975 o smdID: 1977 o U-labels: 1980 o notBefore: 1982 o notAfter: 1984 o -----BEGIN ENCODED SMD----- 1986 o 1988 o -----END ENCODED SMD----- 1989 Example for SMD File (shortened at [...]): 1991 Marks: Example One 1992 smdID: 1-2 1993 U-labels: example-one, exampleone 1994 notBefore: 2011-08-16 09:00 1995 notAfter: 2012-08-16 09:00 1996 -----BEGIN ENCODED SMD----- 1997 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1998 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1999 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 2000 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 2001 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 2002 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 2003 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 2004 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 2005 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 2006 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 2007 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 2008 [...] 2009 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 2010 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 2011 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 2012 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 2013 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 2014 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 2015 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2016 -----END ENCODED SMD----- 2018 Figure 17 2020 6.5. Trademark Claims Notice 2022 The TMDB MUST provide the TCN to Registrars in XML format as 2023 specified below. 2025 An enclosing element that describes the Trademark 2026 Notice to a given label. 2028 The child elements of the element include: 2030 o A element that contains the unique identifier of the 2031 Trademark Notice. This element contains the the TCNID. 2033 The TCNID is a string concatenation of a TCN Checksum and the 2034 TMDB Notice Identifier. The first 8 characters of the TCNID is 2035 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2036 is a zero-padded natural number in the range of 2037 0000000000000000001 to 9223372036854775807. 2039 Example of a TCNID: 2041 370d0b7c9223372036854775807. 2043 Where: 2045 + TCN Checksum=370d0b7c 2047 + TMDB Notice Identifier=9223372036854775807 2049 The TCN Checksum is a 8 characters long Base16 encoded output 2050 of computing the CRC32 of the string concatenation of: label + 2051 unix_timestamp() + TMDB Notice Identifier 2053 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is 2055 defined as the number of seconds that have elapsed since 1970- 2056 01-01T00:00:00Z not counting leap seconds. For example, the 2057 conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: 2059 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2061 The TMDB uses the and 2062 elements from the TCN along with the TMDB Notice Identifier to 2063 compute the TCN Checksum. 2065 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 2066 of the DN being registered, the expiration datetime of the TCN 2067 (provided by the Registrar) and the TMDB Notice Identifier 2068 extracted from the TCNID (provided by the Registrar) to compute 2069 the TCN Checksum. For example the DN "foo.bar.example" being 2070 effectively allocated, the left most label would be "foo". 2072 Example of computation of the TCN Checksum: 2074 CRC32(example-one12819492009223372036854775807)=370d0b7c 2076 o A element that contains the start of the 2077 validity date and time of the TCN. 2079 o A element that contains the expiration date 2080 and time of the TCN. 2082 o A elements that contain the DNL (A-label in case 2083 of IDNs) form of the label that correspond to the DN covered by a 2084 PRM. 2086 o One or more elements that contain the Trademark 2087 Claim. The element contains the following child 2088 elements: 2090 * A element that contains the mark text 2091 string. 2093 * One or more elements that contains the 2094 information of the holder of the mark. An "entitlement" 2095 attribute is used to identify the entitlement of the holder, 2096 possible values are: owner, assignee or licensee. The child 2097 elements of include: 2099 + An OPTIONAL element that contains the name 2100 of the holder. A MUST be specified if 2101 is not specified. 2103 + An OPTIONAL element that contains the name of 2104 the organization holder of the mark. A MUST 2105 be specified if is not specified. 2107 + A element that contains the address 2108 information of the holder of a mark. A 2109 contains the following child elements: 2111 - One, two or three OPTIONAL elements 2112 that contains the organization's street address. 2114 - A element that contains the 2115 organization's city. 2117 - An OPTIONAL element that contains the 2118 organization's state or province. 2120 - An OPTIONAL element that contains the 2121 organization's postal code. 2123 - A element that contains the organization's 2124 country code. This a two-character code from 2125 [ISO3166-2]. 2127 + An OPTIONAL element that contains the 2128 organization's voice telephone number. 2130 + An OPTIONAL element that contains the 2131 organization's facsimile telephone number. 2133 + An OPTIONAL element that contains the email 2134 address of the holder. 2136 * Zero or more OPTIONAL elements that contains 2137 the information of the representative of the mark registration. 2138 A "type" attribute is used to identify the type of contact, 2139 possible values are: owner, agent or thirdparty. The child 2140 elements of include: 2142 + A element that contains name of the 2143 responsible person. 2145 + An OPTIONAL element that contains the name of 2146 the organization of the contact. 2148 + A element that contains the address 2149 information of the contact. A contains the 2150 following child elements: 2152 - One, two or three OPTIONAL elements 2153 that contains the contact's street address. 2155 - A element that contains the contact's 2156 city. 2158 - An OPTIONAL element that contains the 2159 contact's state or province. 2161 - An OPTIONAL element that contains the 2162 contact's postal code. 2164 - A element that contains the contact's 2165 country code. This a two-character code from 2166 [ISO3166-2]. 2168 + A element that contains the contact's voice 2169 telephone number. 2171 + An OPTIONAL element that contains the 2172 contact's facsimile telephone number. 2174 + A element that contains the contact's email 2175 address. 2177 * A element that contains the name (in 2178 English) of the jurisdiction where the mark is protected. A 2179 jurCC attribute contains the two-character code of the 2180 jurisdiction where the mark was registered. This is a two- 2181 character code from [WIPO.ST3]. 2183 * Zero or more OPTIONAL element that 2184 contains the description (in English) of the Nice 2185 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2186 attribute contains the class number. 2188 * A element that contains the full 2189 description of the goods and services mentioned in the mark 2190 registration document. 2192 * An OPTIONAL element signals that the 2193 claim notice was added to the TCN based on other rule than 2194 exact match as defined in [ICANN-GTLD-AGB-20120604]. The 2195 contains one or more: 2197 + An OPTIONAL element that signals that the 2198 claim notice was added because of a previously abused name 2199 included in an UDRP case. The contains: 2201 - A element that contains the UDRP case 2202 number used to validate the previously abused name. 2204 - A element that contains the name 2205 of the UDRP provider. 2207 + An OPTIONAL element that signals that the 2208 claim notice was added because of a previously abused name 2209 included in a court's resolution. The 2210 contains: 2212 - A element that contains the reference 2213 number of the court's resolution used to validate the 2214 previously abused name. 2216 - A element that contains the two-character 2217 code from [ISO3166-2] of the jurisdiction of the court. 2219 - A element that contains the name of 2220 the court. 2222 Example of object: 2224 2225 2226 370d0b7c9223372036854775807 2227 2010-08-14T09:00:00.0Z 2228 2010-08-16T09:00:00.0Z 2229 example-one 2230 2231 Example One 2232 2233 Example Inc. 2234 2235 123 Example Dr. 2236 Suite 100 2237 Reston 2238 VA 2239 20190 2240 US 2241 2242 2243 2244 Joe Doe 2245 Example Inc. 2246 2247 123 Example Dr. 2248 Suite 100 2249 Reston 2250 VA 2251 20190 2252 US 2253 2254 +1.7035555555 2255 jdoe@example.com 2256 2257 UNITED STATES OF AMERICA 2258 2259 Advertising; business management; business administration. 2260 2261 2262 Insurance; financial affairs; monetary affairs; real estate. 2263 2264 2265 Bardus populorum circumdabit se cum captiosus populum. 2266 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2267 2268 2269 2270 Example-One 2271 2272 Example S.A. de C.V. 2273 2274 Calle conocida #343 2275 Conocida 2276 SP 2277 82140 2278 BR 2279 2280 2281 BRAZIL 2282 2283 Bardus populorum circumdabit se cum captiosus populum. 2284 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2285 2286 2287 2288 One 2289 2290 One Corporation 2291 2292 Otra calle 2293 Otra ciudad 2294 OT 2295 383742 2296 CR 2297 2298 2299 COSTA RICA 2300 2301 Bardus populorum circumdabit se cum captiosus populum. 2302 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2303 2304 2305 2306 234235 2307 CR 2308 Supreme Court of Justice of Costa Rica 2309 2310 2311 2312 2313 One Inc 2314 2315 One SA de CV 2316 2317 La calle 2318 La ciudad 2319 CD 2320 34323 2321 AR 2322 2323 2324 ARGENTINA 2325 2326 Bardus populorum circumdabit se cum captiosus populum. 2327 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2328 2329 2330 2331 D2003-0499 2332 WIPO 2333 2334 2335 2336 2338 For formal syntax of the TCN please refer to Section 7.1. 2340 6.6. Sunrise List File 2342 This section defines the format of the list containing every Domain 2343 Name Label (DNL) that matches a Pre-Registered Mark (PRM) eligible 2344 for Sunrise. The list is maintained by the TMDB and downloaded by 2345 Registries in regular intervals (see Section 5.4.2.1). The 2346 Registries use the Sunrise List during the Qualified Launch Program 2347 period to check whether a requested DN matches a DNL of a PRM 2348 eligible for Sunrise. 2350 The Sunrise List contains all the DNLs covered by a PRM eligible for 2351 Sunrise present in the TMDB at the time it is generated. 2353 The Sunrise List is contained in a CSV-like formatted file that has 2354 the following structure: 2356 o first line: , 2358 Where: 2360 + , version of the file, this field MUST be 1. 2362 + , date and time in UTC that 2363 the Sunrise List was created. 2365 o second line: a header line as specified in [RFC4180] 2367 With the header names as follows: 2369 DNL,insertion-datetime 2371 o One or more lines with: , 2373 Where: 2375 + , a Domain Name Label covered by a PRM eligible for 2376 Sunrise. 2378 + , datetime in UTC that the DNL was 2379 first inserted into the Sunrise List. The possible two 2380 values of time for inserting a DNL to the Sunrise List are 2381 00:00:00 and 12:00:00 UTC. 2383 Example for Sunrise List 2385 1,2012-08-16T00:00:00.0Z 2386 DNL,insertion-datetime 2387 example,2010-07-14T00:00:00.0Z 2388 another-example,2012-08-16T00:00:00.0Z 2389 anotherexample,2011-08-16T12:00:00.0Z 2391 Figure 18 2393 To provide authentication and integrity protection, the Sunrise List 2394 will be PGP [RFC4880] signed by the TMDB with the private key of the 2395 TMDB (see also Section 5.1.1.4). The PGP signature of the Sunrise 2396 List can be found in the similar URI but with extension .sig as shown 2397 below. 2399 The URL of the dy interface (Section 4.3.3) is: 2401 o < https:///dnl/surl-latest.csv > 2403 o < https:///dnl/surl-latest.sig > 2405 7. Formal Syntax 2407 7.1. Trademark Claims Notice 2409 The schema presented here is for a Trademark Claims Notice. 2411 Copyright (c) 2012 IETF Trust and the persons identified as authors 2412 of the code. All rights reserved. 2414 Redistribution and use in source and binary forms, with or without 2415 modification, are permitted provided that the following conditions 2416 are met: 2418 o Redistributions of source code must retain the above copyright 2419 notice, this list of conditions and the following disclaimer. 2421 o Redistributions in binary form must reproduce the above copyright 2422 notice, this list of conditions and the following disclaimer in 2423 the documentation and/or other materials provided with the 2424 distribution. 2426 o Neither the name of Internet Society, IETF or IETF Trust, nor the 2427 names of specific contributors, may be used to endorse or promote 2428 products derived from this software without specific prior written 2429 permission. 2431 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2432 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2433 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2434 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2435 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2436 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2437 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2438 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2439 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2440 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2441 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2443 BEGIN 2444 2445 2450 2451 2452 Schema for representing a Trademark Notice. 2453 2454 2455 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2477 2478 2479 2480 2481 2482 2484 2486 2487 2489 2490 2492 2493 2494 2495 2496 2497 2498 2499 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2550 2551 2552 2553 2554 2555 2556 2557 END 2558 8. Acknowledgements 2560 This specification is a collaborative effort from several 2561 participants in the ICANN community. Bernie Hoeneisen participated 2562 as co-author until version 02 providing invaluable support for this 2563 document. This specification is based on a model spearheaded by: 2564 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2565 would also like to thank the thoughful feedbak provided by many in 2566 the tmch-tech mailing list, but particularly the extensive help 2567 provided by James Gould, James Mitchell and Francisco Arias. 2569 9. Change History 2571 [[RFC Editor: Please remove this section.]] 2573 9.1. Changes from draft-lozano-tmch-func-spec-06 to 2574 draft-lozano-tmch-func-spec-07 2576 1. Added result codes: 3611, 3612, 3613, 3614, 4607, 4608, 4609 and 2577 4610. 2579 2. Added mechanism to retrieve the LORDN Transaction Identifier 2580 based on a previously sent element. 2582 9.2. Changes from draft-lozano-tmch-func-spec-07 to 2583 draft-lozano-tmch-func-spec-08 2585 1. Updated result codes: 3613. 2587 2. Added result codes: 3615, 3616, 3617 and 4611. 2589 3. Removed result codes: 4605 and 4606 to support Limited 2590 Registration Periods as defined in the latest RPM Requirements 2591 document. 2593 4. Minor editorial fixes. 2595 9.3. Changes from draft-lozano-tmch-func-spec-08 to 2596 draft-lozano-tmch-func-spec-09 2598 1. Added support for QLP. 2600 2. Updated result codes: 3605. 2602 3. Added result codes: 3618 (QLP) and 3619. 2604 4. XML Schema fix. 2606 5. Minor editorial fixes. 2608 9.4. Changes from draft-lozano-tmch-func-spec-09 to 2609 draft-lozano-tmch-func-spec-10 2611 Draft expired. 2613 10. IANA Considerations 2615 This document uses URNs to describe XML namespaces and XML schemas 2616 conforming to a registry mechanism described in [RFC3688]. One URI 2617 assigment have been registered by the IANA. 2619 Registration request for the Trademark Claims Notice: 2621 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2623 Registrant Contact: See the "Author's Address" section of this 2624 document. 2626 XML: None. Namespace URIs do not represent an XML specification. 2628 11. Security Considerations 2630 TBD 2632 12. References 2634 12.1. Normative References 2636 [I-D.lozano-tmch-smd] 2637 Lozano, G., "Mark and Signed Mark Objects Mapping", 2638 draft-lozano-tmch-smd-03 (work in progress), 2639 September 2013. 2641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2642 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2643 RFC2119, March 1997, 2644 . 2646 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2647 DOI 10.17487/RFC3688, January 2004, 2648 . 2650 12.2. Informative References 2652 [ICANN-GTLD-AGB-20120604] 2653 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2654 June 2012, . 2657 [ISO3166-2] 2658 ISO, "International Standard for country codes and codes 2659 for their subdivisions", 2006. 2661 [QLP-Addendum] 2662 ICANN, "Qualified Launch Program Addendum", April 2014, . 2666 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2667 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 2668 . 2670 [RFC1035] Mockapetris, P., "Domain names - implementation and 2671 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2672 November 1987, . 2674 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 2675 RFC 1591, DOI 10.17487/RFC1591, March 1994, 2676 . 2678 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2679 and E. Lear, "Address Allocation for Private Internets", 2680 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2681 . 2683 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 2684 RFC 1952, DOI 10.17487/RFC1952, May 1996, 2685 . 2687 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2688 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2689 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 2690 RFC2616, June 1999, 2691 . 2693 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 2694 RFC2818, May 2000, 2695 . 2697 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2699 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2700 . 2702 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2703 Separated Values (CSV) Files", RFC 4180, DOI 10.17487/ 2704 RFC4180, October 2005, 2705 . 2707 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2708 (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/ 2709 RFC4346, April 2006, 2710 . 2712 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2713 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2714 . 2716 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2717 Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/ 2718 RFC4880, November 2007, 2719 . 2721 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2722 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2723 RFC5246, August 2008, 2724 . 2726 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2727 Housley, R., and W. Polk, "Internet X.509 Public Key 2728 Infrastructure Certificate and Certificate Revocation List 2729 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2730 . 2732 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2733 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 2734 . 2736 [RFC5890] Klensin, J., "Internationalized Domain Names for 2737 Applications (IDNA): Definitions and Document Framework", 2738 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2739 . 2741 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2742 Infrastructure Certificate and Certificate Revocation List 2743 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, 2744 January 2013, . 2746 [WIPO-NICE-CLASSES] 2747 WIPO, "Nice List of Classes", . 2750 [WIPO.ST3] 2751 WIPO, "Recommended standard on two-letter codes for the 2752 representation of states, other entities and 2753 intergovernmental organizations", March 2007. 2755 Appendix A. Document Changelog 2757 [RFC Editor: This section is to be removed before publication] 2759 Author's Address 2761 Gustavo Lozano 2762 ICANN 2763 12025 Waterfront Drive, Suite 300 2764 Los Angeles 90292 2765 US 2767 Phone: +1.3103015800 2768 Email: gustavo.lozano@icann.org