idnits 2.17.1 draft-lozano-tmch-func-spec-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (May 8, 2014) is 3638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1350, but not defined == Unused Reference: 'RFC1918' is defined on line 2665, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 2669, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 2685, 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 May 8, 2014 5 Expires: November 9, 2014 7 TMCH functional specifications 8 draft-lozano-tmch-func-spec-09 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 November 9, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 128 11. Security Considerations . . . . . . . . . . . . . . . . . . . 70 129 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 130 12.1. Normative References . . . . . . . . . . . . . . . . . . . 70 131 12.2. Informative References . . . . . . . . . . . . . . . . . . 70 132 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 72 133 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72 135 1. Introduction 137 Domain Name Registries may operate in special modes within certain 138 periods of time to facilitate registration of domain names. 140 Along with the upcoming introduction of new generic Top Level Domains 141 (gTLD), two special modes will come into effect: 143 o Sunrise Period 145 o Trademark Claims Period 147 The Sunrise and Trademark Claims Periods are defined in the gTLD 148 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 150 This document describes the requirements, the architecture and the 151 interfaces between the Trademark Clearing House (TMCH) and Domain 152 Name Registries (called Registries in the rest of the document) as 153 well as between the TMCH and Domain Name Registrars (called 154 Registrars in the rest of the document) for the provisioning and 155 management of domain names during the Sunrise and Trademark Claims 156 Periods. 158 For any date and/or time indications, Coordinated Universal Time 159 (UTC) applies. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 XML is case sensitive. Unless stated otherwise, XML specifications 168 and examples provided in this document MUST be interpreted in the 169 character case presented in order to develop a conforming 170 implementation. 172 "tmNotice-1.0" is used as an abbreviation for 173 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 174 "tmNotice" is used, but implementations MUST NOT depend on it and 175 instead employ a proper namespace-aware XML parser and serializer to 176 interpret and output the XML documents. 178 3. Glossary 180 In the following section, the most common terms are briefly 181 explained: 183 o Effective allocation: A DN is considered effectively allocated 184 when the DN object for the DN has been created in the SRS of the 185 Registry and has been assigned to the effective user. A DN object 186 in status "pendingCreate" or any other status that precedes the 187 first time a DN is assigned to an end-user is not considered an 188 effective allocation. A DN object created internally by the 189 Registry for subsequent delegation to another Registrant is not 190 considered an effective allocation. 192 o Backend Registry Operator: Entity that manages (a part of) the 193 technical infrastructure for a Registry Operator. The Registry 194 Operator may also be the Backend Registry Operator. 196 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 198 o CSV: Comma-Separated Values, see [RFC4180] 200 o CNIS, Claims Notice Information Service: This service provides 201 TCNs to Registrars. 203 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 204 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 206 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 208 o Date and time, datetime: Date and time are specified following the 209 standard "Date and Time on the Internet specification", see 210 [RFC3339]. 212 o DN: Domain Name, domain name, see [RFC1034] 214 o DN Repository Object IDentifier, DNROID: an identifier assigned by 215 the Registry to each DN object that unequivocally identifies said 216 DN object. For example, if a new DN object is created for a name 217 that existed in the past, the DN objects will have different 218 DNROIDs. 220 o DNS: Domain Name System, see [RFC1034] 222 o DNL, Domain Name Label: A label as specified in [RFC1035]. For 223 IDNs the A-Label is used [RFC5890]. 225 o DNL List: A list of DNLs that are covered by a PRM. 227 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 229 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 231 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 233 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246]. 235 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 236 SMD PKI model. 238 o IDN: Internationalized Domain Name, see [RFC5890] 240 o LORDN, List of Registered Domain Names: This is the list of 241 effectively allocated DNs matching a DNL of a PRM. Registries 242 will upload this list to the TMDB (during the NORDN process). 244 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 245 Z0-9/] to be used as the lookup Key by Registrars to obtain the 246 TCN using the CNIS. Lookup Keys are unique and are related to one 247 DNL only. 249 o NORDN, Notification of Registered Domain Names: The process by 250 which Registries upload their recent LORDN to the TMDB. 252 o PGP: Pretty Good Privacy, see [RFC4880] 254 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 256 o PRM, Pre-registered mark: Mark that has been pre-registered with 257 the TMCH. 259 o Registrant: Person or Organization registering a DN via a 260 Registrar. 262 o Registrar, Domain Name Registrar: Entity that registers DNs with 263 the Registry on behalf of the Registrant. 265 o Registry, Registry Operator, Domain Name Registry: Entity that 266 accepts DN registrations from Registrars, maintains the central 267 Database of Registered DNs. A Registry Operator is the 268 contracting party with ICANN for the TLD. 270 o Qualified Launch Program period, QLP period: During this OPTIONAL 271 period, a special process applies to DNs matching the Sunrise List 272 and/or the DNL List, to ensure a TMH gets informed of a DN 273 matching his PRM. 275 o SMD, Signed Mark Data: A cryptographically signed token issued by 276 the TMV to the TMH to be used in the Sunrise Period to apply for a 277 DN that matches a DNL of a PRM; see also [I-D.lozano-tmch-smd] 279 o SMD File: A file containing the SMD (see above) and some human 280 readable data. The latter is usually ignored in the processing of 281 the SMD File. See also Section 6.4. 283 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 284 lists of revoked SMDs (SMD Revocation List); see also 285 [I-D.lozano-tmch-smd] 287 o SMD Revocation List: The SMD Revocation List is used by Registries 288 (and optionally by Registrars) during the Sunrise Period to ensure 289 that an SMD is still valid (i.e. not revoked). The SMD Revocation 290 List has a similar function as CRLs used in PKI. 292 o SRS: Shared Registration System, see also 293 [ICANN-GTLD-AGB-20120604]. 295 o Sunrise Period: During this period DNs matching a DNL of a PRM can 296 be exclusively obtained by the respective TMHs. For DNs matching 297 a PRM, a special process applies to ensure a TMH gets informed on 298 the effective allocation of a DN matching his/her PRM. 300 o Sunrise List, SURL: The list of DNLs that are covered by a PRM and 301 eligible for Sunrise. 303 o TLD: Top Level Domain Name, see [RFC1591] 305 o Trademark, mark: Marks are used to claim exclusive properties of 306 products or services. A mark is typically a name, word, phrase, 307 logo, symbol, design, image, or a combination of these elements. 308 For the scope of this document only textual marks are relevant. 310 o Trademark Claims, Claims: Provides information to enhance the 311 understanding of the Trademark rights being claimed by the TMH. 313 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 314 Trademark Claims Notice consist of one or more Trademark Claims 315 and are provided to prospective Registrants of DNs. 317 o Trademark Claims Notice Identifier, TCNID: An element of the 318 Trademark Claims Notice (see above), identifying said TCN. The 319 Trademark Claims Notice Identifier is specified in the element 320 . 322 o Trademark Claims Period: During this period, a special process 323 applies to DNs matching the DNL List, to ensure a TMH gets 324 informed of a DN matching his PRM. For DNs matching the DNL List, 325 Registrars show a TCN to prospective Registrants that has to be 326 acknowledged before effective allocation of the DN. 328 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 329 ICANN central repository for information to be authenticated, 330 stored, and disseminated, pertaining to the rights of TMHs. The 331 Trademark Clearinghouse is split into two functions TMV and TMDB 332 (see below). There could be several entities performing the TMV 333 function, but only one entity performing the TMDB function. 335 o TMDB, Trademark Clearinghouse Database: Serves as a database of 336 the TMCH to provide information to the new gTLD Registries and 337 Registrars to support Sunrise or Claims services. There is only 338 one TMDB in the TMCH that concentrates the information about the 339 "verified" Trademark records from the TMVs. 341 o TMH, Trademark Holder: The person or organization owning rights on 342 a mark. 344 o TMV, Trademark Validator, Trademark validation organization: An 345 entity authorized by ICANN to authenticate and validate 346 registrations in the TMDB ensuring the marks qualify as registered 347 or are court-validated marks or marks that are protected by 348 statute or treaty. This entity would also be asked to ensure that 349 proof of use of marks is provided, which can be demonstrated by 350 furnishing a signed declaration and one specimen of current use. 352 o UTC: Coordinated Universal Time, as maintained by the Bureau 353 International des Poids et Mesures (BIPM); see also [RFC3339]. 355 4. Architecture 357 4.1. Sunrise Period 359 Architecture Sunrise Period 361 SMD hand over (out of band; 362 trivial if Registrant == TMH) 363 ........................................... 364 : : 365 : .'''''''''''''''''''. : 366 : . TMCH . : 367 : ..................... : 368 v . . : 369 .------------. . .-------------. . hv .-----. 370 | Registrant | . | TMV |<------->| TMH | 371 '------------' . '-------------' . vh '-----' 372 | . | ^ \ . 373 | . | | \. 374 tr | . vs | | \ 375 | . | | dv .\ 376 v . v | . \ 377 .-----------. sr . .---. | . \ 378 .->| Registrar |<.........| S | vd | . \ 379 : '-----------' . | M | | . \ 380 : | sy . | D | v . \ 381 : ry | .-----------| M | .---. . vc \ 382 : | | . '---' | T | . \ 383 : v v . | M | . v 384 : .-----------. . | D | . .----------. 385 : | Registry |----------------->| B | . | ICANN-CA | 386 : '-----------' . yd '---' . '----------' 387 : ^ . . | : 388 : | ''''''''''''''''''' | : 389 : | cy | : 390 : cr '---------------------------------------' : 391 :.....................................................: 393 Figure 1 395 4.2. Trademark Claims Period 397 Architecture Trademark Claims Period 399 .'''''''''''''. 400 . TMCH . 401 ............... 402 . . 403 .------------. . .-------. . hv .-----. 404 | Registrant | . | TMV |<------->| TMH | 405 '------------' . '-------' . vh '-----' 406 | . ^ . 407 tr | . | dv . 408 | . vd | . 409 v . v . 410 .-----------. dr . .-------. . 411 | Registrar |<--------| T | . 412 '-----------' . | | . 413 | . | M | . 414 ry | . | | . 415 v . | D | . 416 .----------. dy . | | . 417 | Registry |<------->| B | . 418 '----------' yd . '-------' . 419 . . 420 ''''''''''''' 422 Figure 2 424 4.3. Interfaces 426 In the sub-sections below follows a short description of each 427 interface to provide an overview of the architecture. More detailed 428 descriptions of the relevant interfaces follow further below 429 (Section 5). 431 4.3.1. hv 433 The TMH registers a mark with a TMV via the hv interface. 435 After the successful registration of the mark, the TMV makes 436 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 437 TMH to be used during the Sunrise Period. 439 The specifics of the hv interface are beyond the scope of this 440 document. 442 4.3.2. vd 444 After successful mark registration, the TMV ensures the TMDB inserts 445 the corresponding DNLs and mark information into the database via the 446 vd interface. 448 The specifics of the vd interface are beyond the scope of this 449 document. 451 4.3.3. dy 453 Not used during the Sunrise Period. 455 During the Trademark Claims Period the Registry fetches the latest 456 DNL List from the TMDB via the dy interface in regular intervals. 457 The protocol used on the dy interface is HTTPS. 459 4.3.4. tr 461 The Registrant communicates with the Registrar via the tr interface. 463 The specifics of the tr interface are beyond the scope of this 464 document. 466 4.3.5. ry 468 The Registrar communicate with the Registry via the ry interface. 469 The ry interfaces is typically implemented in EPP [RFC5730]. 471 4.3.6. dr 473 Not used during the Sunrise Period. 475 During the Trademark Claims Period, the Registrar fetches the TCN 476 from the TMDB (to be displayed to the Registrant via the tr 477 interface) via the dr interface. The protocol used for fetching the 478 TCN is HTTPS [RFC2818]. 480 4.3.7. yd 482 During the Sunrise period the Registry notifies the TMDB via the yd 483 interface of all DNs effectively allocated. 485 During the Trademark Claims period, the Registry notifies the TMDB 486 via the yd interface of all DNs effectively allocated that matched an 487 entry in the Registry previously downloaded DNL List during the 488 creation of the DN. 490 The protocol used on the yd interface is HTTPS. 492 4.3.8. dv 494 The TMDB notifies via the dv interface to the TMV of all DNs 495 effectively allocated that match a mark registered by that TMV. 497 The specifics of the dv interface are beyond the scope of this 498 document. 500 4.3.9. vh 502 The TMV notifies the TMH via the vh interface after a DN has been 503 effectively allocated that matches a PRM of this TMH. 505 The specifics of the vh interface are beyond the scope of this 506 document. 508 4.3.10. vs 510 The TMV requests to add a revoked SMD to the SMD Revocation List at 511 the SMDM. 513 The specifics of the vs interface are beyond the scope of this 514 document. 516 Not relevant during the Trademark Claims Period. 518 4.3.11. sy 520 During the Sunrise Period the Registry fetches the most recent SMD 521 Revocation List from the SMDM via the sy interface in regular 522 intervals. The protocol used on the sy interface is HTTPS. 524 Not relevant during the Trademark Claims Period. 526 4.3.12. sr 528 During the Sunrise Period the Registrar may fetch the most recent SMD 529 Revocation List from the SMDM via the sr interface. The protocol 530 used on the sr interface is the same as on the sy interface (s. 531 above), i.e. HTTPS. 533 Not relevant during the Trademark Claims Period. 535 4.3.13. vc 537 The TMV requests to add a revoked TMV certificate to the CRL at the 538 ICANN-CA via the vc interface. 540 The specifics of the vc interface are beyond the scope of this 541 document. 543 Not relevant during the Trademark Claims Period. 545 4.3.14. cy 547 During the Sunrise Period the Registry fetches the most recent CRL 548 from the ICANN-CA via the cy interface in regular intervals. The CRL 549 is mainly used for validation of TMV certificates. The protocol used 550 on the cy interface is HTTPS [RFC2818]. 552 Not relevant during the Trademark Claims Period. 554 4.3.15. cr 556 During the Sunrise Period the Registrar may fetch the most recent CRL 557 from the ICANN-CA via the cr interface. The protocol used on the cr 558 interface is the same as on the cy interface. 560 Not relevant during the Trademark Claims Period. 562 5. Process Descriptions 564 5.1. Bootstrapping 566 5.1.1. Bootstrapping for Registries 568 5.1.1.1. Credentials 570 Each Registry Operator will receive authentication credentials from 571 the TMDB/SMDM to be used: 573 o During the Sunrise Period to fetch the SMD Revocation List from 574 the SMDM via the sy interface (Section 4.3.11). 576 o During Trademark Claims Period to fetch the DNL List from the TMDB 577 via the dy interface (Section 4.3.3). 579 o During the NORDN process to notify the LORDN to the TMDB via the 580 yd interface (Section 4.3.7). 582 Note: credentials are created per TLD and provided to the Registry 583 Operator. 585 5.1.1.2. IP Addresses for Access Control 587 Each Registry Operator MUST provide to the TMDB all IP addresses that 588 will be used to: 590 o Fetch the SMD Revocation List via the sy interface 591 (Section 4.3.11). 593 o Fetch the DNL List from the TMDB via the dy interface 594 (Section 4.3.3). 596 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 598 This access restriction MAY be applied by the TMDB/SMDM in addition 599 to HTTP Basic access authentication (for credentials to be used, see 600 Section 5.1.1.1). 602 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 603 Registry Operator. 605 5.1.1.3. TMCH Trust Anchor 607 Each Registry Operator MUST fetch the X.509 certificate ([RFC5280] / 608 [RFC6818]) of the ICANN-CA (Trust Anchor) from 609 < https://ca.icann.org/tmch.crt > to be used: 611 o During the Sunrise Period to validate the TMV certificates and the 612 CRL of TMV certificates. 614 5.1.1.4. TMDB/SMDM PGP Key 616 The TMDB MUST provide each Registry Operator with the public portion 617 of the PGP Key used by TMDB and SMDM, to be used: 619 o During the Sunrise Period to perform integrity checking of the SMD 620 Revocation List fetched from the SMDM via the sy interface 621 (Section 4.3.11). 623 o During Trademark Claims Period to perform integrity checking of 624 the DNL List fetched from the TMDB via the dy interface 625 (Section 4.3.3). 627 5.1.2. Bootstrapping for Registrars 629 5.1.2.1. Credentials 631 Each ICANN-accredited Registrar will receive authentication 632 credentials from the TMDB to be used: 634 o During the Sunrise Period to (optionally) fetch the SMD Revocation 635 List from the SMDM via the sr interface (Section 4.3.12). 637 o During Trademark Claims Period to fetch TCNs from the TMDB via the 638 dr interface (Section 4.3.6). 640 5.1.2.2. IP Addresses for Access Control 642 Each Registrar MUST provide to the TMDB all IP addresses, which will 643 be used to: 645 o Fetch the SMD Revocation List via the sr interface 646 (Section 4.3.12). 648 o Fetch TCNs via the dr interface (Section 4.3.6). 650 This access restriction MAY be applied by the TMDB/SMDM in addition 651 to HTTP Basic access authentication (for credentials to be used, see 652 Section 5.1.2.1). 654 The TMDB MAY limit the number of IP addresses to be accepted per 655 Registrar. 657 5.1.2.3. TMCH Trust Anchor 659 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 660 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 661 be used: 663 o During the Sunrise Period to (optionally) validate the TMV 664 certificates and the CRL of TMV certificates. 666 5.1.2.4. TMDB PGP Key 668 Registrars MUST receive the public portion of the PGP Key used by 669 TMDB and SMDM from the TMDB administrator to be used: 671 o During the Sunrise Period to (optionally) perform integrity 672 checking of the SMD Revocation List fetched from the SMDM via the 673 sr interface (Section 4.3.12). 675 5.2. Sunrise Period 677 5.2.1. Domain Name Registration 679 Registration during Sunrise Period 681 .------------. .-----------. .----------. 682 | Registrant | | Registrar | | Registry | 683 '------------' '-----------' '----------' 684 ^ | | | 685 | | Request DN | | 686 | | Registration | | 687 | | (with SMD) | | 688 | |------------->| Check DN availability | 689 | | |---------------------------->| 690 | | | | 691 | | DN unava. | DN unavailable .-------------. 692 '---|<-------------|<--------------------( DN available? ) 693 | | no '-------------' 694 | | | yes 695 | | DN available | 696 | |<----------------------------| 697 | | | 698 | | Request DN registration | 699 | | (with SMD) | 700 | |---------------------------->| 701 | | | 702 | | .------------------------------. 703 | | | DN registration validation / | 704 | | | SMD validation | 705 | | '------------------------------' 706 | Registration | | 707 | Error |.-----------. Error .----------------------. 708 |<-------------|| TRY AGAIN |<------( Validation successful? ) 709 | || / ABORT | no '----------------------' 710 | |'-----------' | yes 711 | | | 712 | | DN registered | 713 | DN regist. |<----------------------------| 714 |<-------------| | 715 | | | 717 Figure 3 719 Note: the figure depicted above represents a synchronous DN 720 registration workflow (usually called first come first served). 722 5.2.2. Sunrise DN Registration by Registries 724 Registries MUST perform a minimum set of checks for verifying each DN 725 registration during the Sunrise Period upon reception of a 726 registration request over the ry interface (Section 4.3.5). If any 727 of these checks fails the Registry MUST abort the registration. Each 728 of these checks MUST be performed before the DN is effectively 729 allocated. 731 In case of asynchronous registrations (e.g. auctions), the minimum 732 set of checks MAY be performed when creating the intermediate object 733 (e.g. a DN application) used for DN registration. If the minimum set 734 of checks is performed when creating the intermediate object (e.g. a 735 DN application) a Registry MAY effective allocate the DN without 736 performing the minimum set of checks again. 738 Performing the minimum set of checks Registries MUST verify that: 740 1. A SMD has been received from the Registrar along with the DN 741 registration. 743 2. The certificate of the TMV has been correctly signed by the 744 ICANN-CA. (The certificate of the TMV is contained within the 745 SMD.) 747 3. The time when the validation is done is within the validity 748 period of the TMV certificate. 750 4. The certificate of the TMV is not be listed in the CRL file 751 specified in the CRL distribution point of the TMV certificate. 753 5. The signature of the SMD (signed with the TMV certificate) is 754 valid. 756 6. The time when the validation is done is within the validity 757 period of the SMD based on and 758 elements. 760 7. The SMD has not been revoked, i.e., is not contained in the SMD 761 Revocation List. 763 8. The leftmost DNL (A-label in case of IDNs) of the DN being 764 effectively allocated matches one of the labels () 765 elements in the SMD. 767 These procedure apply to all DN effective allocations at the second 768 level as well as to all other levels subordinate to the TLD that the 769 Registry accepts registrations for. 771 5.2.3. TMDB Sunrise Services for Registries 773 5.2.3.1. SMD Revocation List 775 A new SMD Revocation List MUST be published by the SMDM twice a day, 776 by 00:00:00 and 12:00:00 UTC. 778 Registries MUST refresh the latest version of the SMD Revocation List 779 at least once every 24 hours. 781 Note: the SMD Revocation List will be the same regardless of the TLD. 782 If a Backend Registry Operator manages the infrastructure of several 783 TLDs, the Backend Registry Operator could refresh the SMD Revocation 784 List once every 24 hours, the SMD Revocation List could be used for 785 all the TLDs managed by the Backend Registry Operator. 787 Update SMD Revocation List 789 .----------. .------. 790 | Registry | | SMDM | 791 '----------' '------' 792 | | 793 .----------------. | 794 | Periodically, | | 795 | at least | | 796 | every 24 hours | | 797 '----------------' | 798 | | 799 |----------------------------------------------------->| 800 | Download latest revocation list for SMD certificates | 801 |<-----------------------------------------------------| 802 | | 803 | | 805 Figure 4 807 5.2.3.2. Certificate Revocation List 809 Registries MUST refresh their local copy of the CRL at least every 24 810 hours using the CRL distribution point specified in the TMV 811 certificate. 813 Operationally, the CRL file and CRL distribution point is the same 814 for all TMVs and (at publication of this document) located at 815 < http://crl.icann.org/tmch.crl >. 817 Note: the CRL file will be the same regardless of the TLD. If a 818 Backend Registry Operator manages the infrastructure of several TLDs, 819 the Backend Registry Operator could refresh the CRL file once every 820 24 hours, the CRL file could be used for all the TLDs managed by the 821 Backend Registry Operator. 823 Update CRL for TMV certificates 825 .----------. .----------. 826 | Registry | | ICANN-CA | 827 '----------' '----------' 828 | | 829 .----------------. | 830 | Periodically, | | 831 | at least | | 832 | every 24 hours | | 833 '----------------' | 834 | | 835 |------------------------------------------->| 836 | Download latest CRL for TMV certificates | 837 |<-------------------------------------------| 838 | | 839 | | 841 Figure 5 843 5.2.3.3. Notice of Registered Domain Names 845 The Registry MUST send a LORDN file containing DNs effectively 846 allocated to the TMDB (over the yd interface, Section 4.3.7). 848 The effective allocation of a DN MUST be reported by the Registry to 849 the TMDB within 26 hours of the effective allocation of such DN. 851 The Registry MUST create and upload a LORDN file in case there are 852 effective allocations in the SRS, that have not been successfully 853 reported to the TMDB in a previous LORDN file. 855 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 856 maximum frequency to upload LORDN files from the Registries to the 857 TMDB is every 3 hours. 859 It is RECOMMENDED that Registries try to upload at least two LORDN 860 files per day to the TMDB with enough time in between, in order to 861 have time to fix problems reported in the LORDN file. 863 The Registry SHOULD upload a LORDN file only when the previous LORDN 864 file has been processed by the TMDB and the related LORDN Log file 865 has been downloaded and processed by the Registry. 867 The Registry MUST upload LORDN files for DNs effectively allocated 868 during the Sunrise or Claims period (same applies to DNs effectively 869 allocated using applications created during the Sunrise or Claims 870 period in case of using asynchronous registrations). 872 The yd interface (Section 4.3.7) MUST support at least 1 and MAY 873 support up to 10 concurrent connections from each IP address 874 registered by a Registry Operator to access the service. 876 The TMDB MUST process each uploaded LORDN file and make the related 877 log file available for Registry download within 30 minutes of the 878 finalization of the upload. 880 NORDN 882 .----------. .------. .-----. .-----. 883 | Registry | | TMDB | | TMV | | TMH | 884 '----------' '------' '-----' '-----' 885 | | | | 886 .------------------. | | | 887 | Periodically | | | | 888 | upload LORDN | | | | 889 | file | | | | 890 '------------------' | | | 891 | | | | 892 .--------->| Upload LORDN | | | 893 | |-------------------->| | | 894 | | | | | 895 | | .-------------------------. | | 896 | | | Verify each domain name | | | 897 | | | in the uploaded file | | | 898 | | | (within 30') | | | 899 | | '-------------------------' | | 900 | | | ._____. | | 901 | | Download Log file | | END | | | 902 | |<--------------------| '-----' | | 903 | | | ^ | | 904 | .-----------------. .---------------. | | | 905 | | Check whether | / everything fine \ no | | | 906 | | Log file | ( (i.e. no errors )---' | | 907 | | contains errors | \ in Log file )? / | | 908 | '-----------------' '---------------' | | 909 | | | yes | | 910 | .---------------. | | | 911 | / everything fine \ yes | | | 912 |( (i.e. no errors )-----. | Notify TMVs | | 913 | \ in Log file )? / | | on the LORDN | | 914 | '---------------' | | pre-registered | | 915 | | no v | with said TMV | | 916 | .----------------. .------. |--------------->| | 917 '-| Correct Errors | | DONE | | | | 918 '----------------' '------' | | Notify each | 919 | | | affected TMH | 920 | | |------------->| 921 | | | | 923 Figure 6 925 The format used for the LORDN is described in Section 6.3 927 5.2.4. Sunrise DN registration by Registrars 929 Registrars MAY choose to perform the checks for verifying DN 930 registrations as performed by the Registries (see Section 5.2.2) 931 before sending the command to register a DN. 933 5.2.5. TMDB Sunrise Services for Registrars 935 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 936 also available for Registrars to optionally validate the SMDs 937 received. 939 5.3. Trademark Claims Period 941 5.3.1. Domain Registration 943 Registration during Trademark Claims Period 945 .------------. .-----------. .----------. .------. 946 | Registrant | | Registrar | | Registry | | TMDB | 947 '------------' '-----------' '----------' '------' 948 ^ | Request DN | | | 949 | | Registration | Check DN availability | | 950 | |------------->|---------------------------->| | 951 | | DN unava. | DN unavailable .-------------. | 952 '---|<-------------|<--------------------( DN available? ) | 953 | | no '-------------' | 954 | | | yes | 955 | | DN available | | 956 | |<----------------------------| | 957 | | Request Lookup key | | 958 | |---------------------------->| | 959 | | .---------. | 960 | |.----------. / Does DN \ | 961 | || CONTINUE |<---------( match DNL ) | 962 | || NORMALLY | no \ of PRM? / | 963 | |'----------' '---------' | 964 | | | yes | 965 | | Lookup key | | 966 | |<----------------------------| | 967 | | Request Claims Notice | 968 | Display |----------------------------------------->| 969 | Claims | | 970 | Notice | Return Claims Notice | 971 |<-------------|<-----------------------------------------| 972 | | | 973 .------. yes | Register DN (TCNID included) | 974 ( Ack? )--------->|---------------------------->| | 975 '------' | | | 976 ||no | Error .----------------------. | 977 || .-------. |<--------------( Validation successful? ) | 978 |'->| ABORT | | no '----------------------' | 979 | '-------' | | yes | 980 | DN regist. | DN registered | | 981 |<-------------|<----------------------------| | 982 | | | | 984 Figure 7 986 Note: the figure depicted above represents a synchronous DN 987 registration workflow (usually called first come first served). 989 5.3.2. Trademark Claims DN registration by Registries 991 During Trademark Claim Periods, Registries perform two main 992 functions: 994 o Registries MUST provide Registrars (over the ry interface, 995 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 996 that match the DNL List. 998 o Registries MUST provide the Lookup Key only when queried about a 999 specific DN. 1001 o For each DN matching a DNL of a PRM, Registries MUST perform a 1002 minimum set of checks for verifying DN registrations during 1003 Trademark Claims Period upon reception of a registration request 1004 over the ry interface (Section 4.3.5). If any of these checks 1005 fails the Registry MUST abort the registration. Each of these 1006 checks MUST be performed before the DN is effectively allocated. 1008 o In case of asynchronous registrations (e.g. auctions), the minimum 1009 set of checks MAY be performed when creating the intermediate 1010 object (e.g. a DN application) used for DN effective allocation. 1011 If the minimum set of checks is performed when creating the 1012 intermediate object (e.g. a DN application) a Registry MAY 1013 effective allocate the DN without performing the minimum set of 1014 checks again. 1016 o Performing the minimum set of checks Registries MUST verify that: 1018 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been 1020 received from the Registrar along with the DN registration. 1022 If the three elements mentioned above are not provided by 1023 the Registrar for a DN matching a DNL of a PRM, but the DNL 1024 was inserted (or re-inserted) for the first time into DNL 1025 List less than 24 hours ago, the registration MAY continue 1026 without this data and the tests listed below are not 1027 required to be performed. 1029 2. The TCN has not expired (according to the expiration datetime 1030 sent by the Registrar). 1032 3. The acceptance datetime is no more than 48 hours in the past. 1034 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1035 being registered, the expiration datetime provided by the 1036 registrar, and the TMDB Notice Identifier extracted from the 1037 TCNID provided by the registrar compute the TCN Checksum. 1038 Verify that the computed TCN Checksum match the TCN Checksum 1039 present in the TCNID. 1041 These procedures apply to all DN registrations at the second level as 1042 well as to all other levels subordinate to the TLD that the Registry 1043 accepts registrations for. 1045 5.3.3. TMBD Claims Services for Registries 1047 5.3.3.1. Domain Name Label (DNL) List 1049 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1050 and 12:00:00 UTC. 1052 Registries MUST refresh the latest version of the DNL List at least 1053 once every 24 hours. 1055 Update DNL List 1057 .----------. .------. 1058 | Registry | | TMDB | 1059 '----------' '------' 1060 | | 1061 .----------------. | 1062 | Periodically, | | 1063 | at least | | 1064 | every 24 hours | | 1065 '----------------' | 1066 | | 1067 |-------------------------------->| 1068 | Download latest list of DNLs | 1069 |<--------------------------------| 1070 | | 1071 | | 1073 Figure 8 1075 Note: the DNL List will be the same regardless of the TLD. If a 1076 Backend Registry Operator manages the infrastructure of several TLDs, 1077 the Backend Registry Operator could refresh the DNL List once every 1078 24 hours, the DNL List could be used for all the TLDs managed by the 1079 Backend Registry Operator. 1081 5.3.3.2. Notice of Registered Domain Names 1083 The NORDN process during the Trademark Claims Period is almost the 1084 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1085 difference that only registrations subject to a Trademark Claim 1086 (i.e., at registration time the name appeared in the current DNL List 1087 downloaded by the Registry Operator) are included in the LORDN. 1089 5.3.4. Trademark Claims DN Registration by Registrars 1091 For each DN matching a DNL of a PRM, Registrars MUST perform the 1092 following steps: 1094 1. Use the Lookup Key received from the Registry to obtain the TCN 1095 from the TMDB using the dr interface (Section 4.3.6) Registrars 1096 MUST only query for the Lookup Key of a DN that is available for 1097 registration. 1099 2. Present the TCN to the Registrant as described in 1100 [ICANN-GTLD-AGB-20120604]. 1102 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1103 consent with the TCN, before any further processing. (The 1104 transmission of a TCNID to the Registry over the ry interface, 1105 Section 4.3.5 implies that the Registrant has expressed his 1106 consent with the TCN.) 1108 4. Perform the minimum set of checks for verifying DN registrations. 1109 If any of these checks fails the Registrar MUST abort the DN 1110 registration. Each of these checks MUST be performed before the 1111 registration is sent to the Registry. Performing the minimum set 1112 of checks Registrars MUST verify that: 1114 1. The time when the validation is done is within the TCN 1115 validity based on the and elements. 1118 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1119 effectively allocated matches the label () 1120 element in the TCN. 1122 3. The Registrant has acknowledged (expressed his consent with) 1123 the TCN. 1125 5. Record the date and time when the registrant acknowledged the 1126 TCN. 1128 6. Send the registration to the Registry (ry interface, 1129 Section 4.3.5) and include the following information: 1131 * TCNID () 1133 * Expiration date of the TCN () 1135 * Acceptance datetime of the TCN. 1137 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the 1139 TMDB, allowing the implementation of a cache by Registrars and enough 1140 time for acknowledging the TCN. Registrars SHOULD implement a cache 1141 of TCNs to minimize the number of queries sent to the TMDB. A cached 1142 TCN MUST be removed from the cache after the expiration date of the 1143 TCN as defined by . The TMDB MAY implement rate- 1144 limiting as one of the protection mechanisms to mitigate the risk of 1145 performance degradation. 1147 5.3.5. TMBD Claims Services for Registrars 1149 5.3.5.1. Claims Notice Information Service 1151 The TCNs are provided by the TMDB online and are fetched by the 1152 Registrar via the dr interface (Section 4.3.6). 1154 To get access to the TCNs, the Registrar needs the credentials 1155 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1156 from the Registry via the ry interface (Section 4.3.5). The dr 1157 interface (Section 4.3.6) uses HTTPS with Basic access 1158 authentication. 1160 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1161 connections from each Registrar. 1163 The URL of the dr interface (Section 4.3.6) is: 1165 < https:///cnis/.xml > 1167 Note that the "lookupkey" may contain SLASH characters ("/"). The 1168 SLASH character is part of the URL path and MUST NOT be escaped when 1169 requesting the TCN. 1171 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1172 MUST be signed by a well-know public CA. Registrars MUST perform the 1173 Certification Path Validation described in Section 6 of [RFC5280]. 1174 Registrars will be authenticated in the dr interface using HTTP Basic 1175 access authentication. The dr (Section 4.3.6) interface MUST support 1176 HTTPS keep-alive and MUST maintain the connection for up to 30 1177 minutes. 1179 5.4. Qualified Launch Program Period 1181 5.4.1. Domain Registration 1183 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1184 (QLP) period effective allocations of DNs to third parties could 1185 require that Registries and Registrars provide Sunrise and/or Claims 1186 services. If required, Registries and Registrars MUST provide 1187 Sunrise and/or Claims services as described in: Section 5.2 and 1188 Section 5.3. 1190 The effective allocation scenarios are: 1192 o If the leftmost DNL (A-label in case of IDNs) of the DN being 1193 effectively allocated (QLP Name in this section) matches a DNL in 1194 the SURL, and an SMD is provided, then Registries MUST provide 1195 Sunrise Services (see Section 5.2) and the DN MUST be reported in 1196 a Sunrise LORDN file during the QLP period. 1198 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1199 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1200 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1201 file using the special SMD-id "99999-99999" during the QLP period. 1203 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1204 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1205 [QLP-Addendum]), then Registries MUST provide Claims services (see 1206 Section 5.3) and the DN MUST be reported in a Claims LORDN file 1207 during the QLP period. 1209 o If the QLP Name matches a DNL in the DNL List but does not match a 1210 DNL in the SURL, then Registries MUST provide Claims services (see 1211 Section 5.2) and the DN MUST be reported in a Claims LORDN file 1212 during the QLP period. 1214 The following table lists all the effective allocation scenarios 1215 during a QLP Period: 1217 +--------+---------+-----------------+-------------+----------------+ 1218 | QLP | QLP | SMD was | Registry | Registry MUST | 1219 | Name | Name | provided by the | MUST | report DN | 1220 | match | match | potential | provide | registration | 1221 | in the | in the | Registrant | Sunrise or | in | 1222 | SURL | DNL | | Claims | LORDN file | 1223 | | List | | Services | | 1224 +--------+---------+-----------------+-------------+----------------+ 1225 | Y | Y | Y | Sunrise | Sunrise | 1226 | | | | | | 1227 | Y | N | Y | Sunrise | Sunrise | 1228 | | | | | | 1229 | N | Y | -- | Claims | Claims | 1230 | | | | | | 1231 | N | N | -- | -- | -- | 1232 | | | | | | 1233 | Y | Y | N (see section | Claims | Claims | 1234 | | | 2.2 of | | | 1235 | | | [QLP-Addendum]) | | | 1236 | | | | | | 1237 | Y | N | N (see section | -- | Sunrise (using | 1238 | | | 2.2 of | | special | 1239 | | | [QLP-Addendum]) | | SMD-id) | 1240 +--------+---------+-----------------+-------------+----------------+ 1242 QLP Effective Allocation Scenarios 1244 The TMDB MUST provide the following services to Registries during a 1245 QLP period: 1247 o SMD Revocation List (see Section 5.2.3.1) 1249 o Notice of Registered Domain Names (see Section 5.2.3.3) 1251 o Domain Name Label List (see Section 5.3.3.1) 1253 o Sunrise List (see Section 5.4.2.1 1255 The TMDB MUST provide the following services to Registrars during a 1256 QLP period: 1258 o SMD Revocation List (see Section 5.2.3.1) 1260 o Claims Notice Information Service (see Section 5.3.5.1) 1262 5.4.2. TMBD QLP Services for Registries 1264 5.4.2.1. Sunrise List (SURL) 1266 A new Sunrise List MUST be published by the TMDB twice a day, by 00: 1267 00:00 and 12:00:00 UTC. 1269 Registries offering the OPTIONAL QLP period MUST refresh the latest 1270 version of the Sunrise List at least once every 24 hours. 1272 Update Sunrise List 1274 .----------. .------. 1275 | Registry | | TMDB | 1276 '----------' '------' 1277 | | 1278 .----------------. | 1279 | Periodically, | | 1280 | at least | | 1281 | every 24 hours | | 1282 '----------------' | 1283 | | 1284 |-------------------------------->| 1285 | Download latest list of DNLs | 1286 |<--------------------------------| 1287 | | 1288 | | 1290 Figure 9 1292 Note: the Sunrise List will be the same regardless of the TLD. If a 1293 Backend Registry Operator manages the infrastructure of several TLDs, 1294 the Backend Registry Operator could refresh the Sunrise List once 1295 every 24 hours, the Sunrise List could be used for all the TLDs 1296 managed by the Backend Registry Operator. 1298 6. Data Format Descriptions 1300 6.1. DNL List file 1302 This section defines the format of the list containing every Domain 1303 Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list 1304 is maintained by the TMDB and downloaded by Registries in regular 1305 intervals (see Section 5.3.3.1). The Registries use the DNL List 1306 during the Trademark Claims period to check whether a requested DN 1307 matches a DNL of a PRM. 1309 The DNL List contains all the DNLs covered by a PRM present in the 1310 TMDB at the time it is generated. 1312 The DNL List is contained in a CSV-like formatted file that has the 1313 following structure: 1315 o first line: , 1317 Where: 1319 + , version of the file, this field MUST be 1. 1321 + , date and time in UTC that the 1322 DNL List was created. 1324 o second line: a header line as specified in [RFC4180] 1326 With the header names as follows: 1328 DNL,lookup-key,insertion-datetime 1330 o One or more lines with: ,, 1333 Where: 1335 + , a Domain Name Label covered by a PRM. 1337 + , lookup key that the Registry MUST provide to 1338 the Registrar. The lookup key has the following format: 1339
////, where: 1342 - YYYY: year that the TCN was generated. 1344 - MM: zero-padded month that the TCN was generated. 1346 - DD: zero-padded day that the TCN was generated. 1348 - vv: version of the TCN, possible values are 00 and 01. 1350 - X: one hexadecimal digit [0-9A-F]. This is the first, 1351 second and third hexadecimal digit of encoding the 1352 in base16 as specified in [RFC4648]. 1354 - Random bits: 144 random bits encoded in base64url as 1355 specified in [RFC4648]. 1357 - Sequential number: zero-padded natural number in the 1358 range 0000000001 to 2147483647. 1360 + , datetime in UTC that the DNL was 1361 first inserted into the DNL List. The possible two values 1362 of time for inserting a DNL to the DNL List are 00:00:00 and 1363 12:00:00 UTC. 1365 Example for DNL List 1367 1,2012-08-16T00:00:00.0Z 1368 DNL,lookup-key,insertion-datetime 1369 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1370 2010-07-14T00:00:00.0Z 1371 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1372 2012-08-16T00:00:00.0Z 1373 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1374 2011-08-16T12:00:00.0Z 1376 Figure 10 1378 To provide authentication and integrity protection, the DNL List will 1379 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1380 (see also Section 5.1.1.4). The PGP signature of the DNL List can be 1381 found in the similar URI but with extension .sig as shown below. 1383 The URL of the dy interface (Section 4.3.3) is: 1385 o < https:///dnl/dnl-latest.csv > 1387 o < https:///dnl/dnl-latest.sig > 1389 6.2. SMD Revocation List 1391 This section defines the format of the list of SMDs that have been 1392 revoked. The list is maintained by the SMDM and downloaded by 1393 Registries (and optionally by Registrars) in regular intervals (see 1394 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1395 Period to validate SMDs received. The SMD Revocation List has a 1396 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1398 The SMD Revocation List contains all the revoked SMDs present in the 1399 TMDB at the time it is generated. 1401 The SMD Revocation List is contained in a CSV-like formatted file 1402 that has the following structure: 1404 o first line: , 1406 Where: 1408 + , version of the file, this field MUST be 1. 1410 + , datetime in UTC 1411 that the SMD Revocation List was created. 1413 o second line: a header line as specified in [RFC4180] 1415 With the header names as follows: 1417 smd-id,insertion-datetime 1419 o One or more lines with: , 1421 Where: 1423 + , identifier of the SMD that was revoked. 1425 + , revocation datetime in UTC of the 1426 SMD. The possible two values of time for inserting an SMD 1427 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1429 To provide integrity protection, the SMD Revocation List is PGP 1430 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1431 also Section 5.1.1.4). The SMD Revocation List is provided by the 1432 TMDB with extension .csv. The PGP signature of the SMD Revocation 1433 List can be found in the similar URI but with extension .sig as shown 1434 below. 1436 The URL of the sr interface (Section 4.3.12) and sy interface 1437 (Section 4.3.11) is: 1439 o < https:///smdrl/smdrl-latest.csv > 1441 o < https:///smdrl/smdrl-latest.sig > 1443 Example for SMD Revocation list 1445 1,2012-08-16T00:00:00.0Z 1446 smd-id,insertion-datetime 1447 2-2,2012-08-15T00:00:00.0Z 1448 3-2,2012-08-15T00:00:00.0Z 1449 1-2,2012-08-15T00:00:00.0Z 1451 Figure 11 1453 6.3. LORDN File 1455 This section defines the format of the List of Registered Domain 1456 Names (LORDN), which is maintained by each Registry and uploaded at 1457 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1458 said DN is added to the LORDN along with further information related 1459 to its registration. 1461 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1462 file is: 1464 o Sunrise LORDN file: 1466 < https:///LORDN//sunrise > 1468 o Claims LORDN file: 1470 < https:///LORDN//claims > 1472 During a QLP period, Registries MAY be required to upload Sunrise or 1473 Claims LORDN files. The URIs of the yd interface used to upload 1474 LORDN files during a QLP period is: 1476 o Sunrise LORDN file (during QLP period): 1478 < https:///LORDN//sunrise/qlp > 1480 o Claims LORDN file (during a QLP period): 1482 < https:///LORDN//claims/qlp > 1484 The yd interface (Section 4.3.7) returns the following HTTP status 1485 codes after a HTTP POST request method is received: 1487 o The interface provides a HTTP/202 status code if the interface was 1488 able to receive the LORDN file and the syntax of the LORDN file is 1489 correct. 1491 The interface provides the LORDN Transaction Identifier in the 1492 HTTP Entity-body that would be used by the Registry to download 1493 the LORDN Log file. The LORDN Transaction Identifier is a 1494 natural number zero-padded in the range 0000000000000000001 to 1495 9223372036854775807. 1497 The TMDB uses the element of the 1498 LORDN file as a unique client-side identifier. If a LORDN file 1499 with the same of a previously sent 1500 LORDN file is received by the TMDB, the LORDN Transaction 1501 Identifier of the previously sent LORDN file MUST be provided 1502 to the Registry. The TMDB MUST ignore the DN Lines present in 1503 the LORDN file if a LORDN file with the same was previously sent. 1506 The HTTP Location header field contains the URI where the LORDN 1507 Log file could be retrieved later, for example: 1509 202 Accepted 1511 Location: https:///LORDN/example/sunrise/ 1512 0000000000000000001/result 1514 o The interface provides a HTTP/400 if the request is incorrect or 1515 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1516 human readable message in the HTTP Entity-body regarding the 1517 incorrect syntax of the LORDN file. 1519 o The interface provides a HTTP/401 status code if the credentials 1520 provided does not authorize the Registry Operator to upload a 1521 LORDN file. 1523 o The TMDB MUST return a HTTP/404 status code when trying to upload 1524 a LORDN file using the 1525 https:///LORDN//sunrise/qlp or 1526 https:///LORDN//claims/qlp interface 1527 outside of a QLP period plus 26 hours. 1529 o The interface provides a HTTP/500 status code if the system is 1530 experiencing a general failure. 1532 For example, to upload the Sunrise LORDN file for TLD "example", the 1533 URI would be: 1535 < https:///LORDN/example/sunrise > 1537 The LORDN is contained in a CSV-like formatted file that has the 1538 following structure: 1540 o For Sunrise Period: 1542 * first line: ,, 1545 Where: 1547 - , version of the file, this field MUST be 1. 1549 - , date and time in UTC that the 1550 LORDN was created. 1552 - , number of DN Lines present in the 1553 LORDN file. 1555 * second line: a header line as specified in [RFC4180] 1557 With the header names as follows: 1559 roid,domain-name,SMD-id,registrar-id,registration- 1560 datetime,application-datetime 1562 * One or more lines with: ,,,,, 1566 Where: 1568 - , DN Repository Object IDentifier (DNROID) in the 1569 SRS. 1571 - , DN that was effectively allocated. For 1572 IDNs the A-Label is used [RFC5890] 1574 - , SMD ID used for registration. 1576 - , IANA Registrar ID. 1578 - , date and time in UTC that the 1579 domain was effectively allocated. 1581 - OPTIONAL , date and 1582 time in UTC that the application was created. The 1583 MUST be provided in 1584 case of a DN effective allocation based on an 1585 asynchronous registration (e.g., when using auctions). 1587 Example for LORDN during Sunrise 1589 1,2012-08-16T00:00:00.0Z,3 1590 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1591 application-datetime 1592 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1593 2012-07-15T00:50:00.0Z 1594 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1595 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1597 Figure 12 1599 o For Trademark Claims Period: 1601 * first line: ,, 1604 Where: 1606 - , version of the file, this field MUST be 1. 1608 - , date and time in UTC that the 1609 LORDN was created. 1611 - , number of DN Lines present in the 1612 LORDN file. 1614 * second line: a header line as specified in [RFC4180] 1616 With the header names as follows: 1618 roid,domain-name,notice-id,registrar-id,registration- 1619 datetime,ack-datetime,application-datetime 1621 * One or more lines with: ,,,,,, 1625 Where: 1627 - , DN Repository Object IDentifier (DNROID) in the 1628 SRS. 1630 - , DN that was effectively allocated. For 1631 IDNs the A-Label is used [RFC5890]. 1633 - , Trademark Claims Notice Identifier as specified 1634 in . 1636 - , IANA Registrar ID. 1638 - , date and time in UTC that the 1639 domain was effectively allocated. 1641 - , date and time in UTC 1642 that the TCN was acknowledged. 1644 - OPTIONAL , date and 1645 time in UTC that the application was created. The 1646 MUST be provided in 1647 case of a DN effective allocation based on an 1648 asynchronous registration (e.g., when using auctions). 1650 For a DN matching a DNL of a PRM at the moment of 1651 registration, created without the TCNID, expiration datetime 1652 and acceptance datetime, because DNL was inserted (or re- 1653 inserted) for the first time into DNL List less than 24 1654 hours ago, the string "recent-dnl-insertion" MAY be 1655 specified in and . 1658 Example for LORDN during Claims 1660 1,2012-08-16T00:00:00.0Z,3 1661 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1662 ack-datetime,application-datetime 1663 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1664 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1665 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1666 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1667 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1668 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1670 Figure 13 1672 6.3.1. LORDN Log File 1674 After reception of the LORDN file, the TMDB verifies its content for 1675 syntactical and semantical correctness. The output of the LORDN file 1676 verification is retrieved using the yd interface (Section 4.3.7). 1678 The URI of the yd interface (Section 4.3.7) used to retrieve the 1679 LORDN Log File is: 1681 o Sunrise LORDN Log file: 1683 < https:///LORDN//sunrise/ 1684 /result > 1686 o Claims LORDN Log file: 1688 < https:///LORDN//claims/ 1689 /result > 1691 A Registry Operator MUST NOT send more than one request per minute 1692 per TLD to download a LORDN Log file. 1694 The yd interface (Section 4.3.7) returns the following HTTP status 1695 codes after a HTTP GET request method is received: 1697 o The interface provides a HTTP/200 status code if the interface was 1698 able to provide the LORDN Log file. The LORDN Log file is 1699 contained in the HTTP Entity-body. 1701 o The interface provides a HTTP/204 status code if the LORDN 1702 Transaction Identifier is correct, but the server has not 1703 finalized processing the LORDN file. 1705 o The interface provides a HTTP/400 status code if the request is 1706 incorrect. 1708 o The interface provides a HTTP/401 status code if the credentials 1709 provided does not authorize the Registry Operator to download the 1710 LORDN Log file. 1712 o The interface provides a HTTP/404 status code if the LORDN 1713 Transaction Identifier is incorrect. 1715 o The interface provides a HTTP/500 status code if the system is 1716 experiencing a general failure. 1718 For example, to obtain the LORDN Log File in case of a Sunrise LORDN 1719 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1720 "example" the URI would be: 1722 < https:///LORDN/example/sunrise/ 1723 0000000000000000001/result > 1725 The LORDN Log file is contained in a CSV-like formatted file that has 1726 the following structure: 1728 o first line: ,,,,,, 1732 Where: 1734 + , version of the file, this field MUST be 1. 1736 + , date and time in UTC that the 1737 LORDN Log was created. 1739 + , date and time in UTC of 1740 creation for the LORDN file that this log file is referring 1741 to. 1743 + , unique identifier of the LORDN Log 1744 provided by the TMDB. This identifier could be used by the 1745 Registry Operator to unequivocally identify the LORDN Log. 1746 The identified will be a string of a maximum LENGTH of 60 1747 characters from the Base 64 alphabet. 1749 + , whether the LORDN file has been accepted for 1750 processing by the TMDB. Possible values are "accepted" or 1751 "rejected". 1753 + , whether the LORDN Log has any warning result 1754 codes. Possible values are "no-warnings" or "warnings- 1755 present". 1757 + , number of DNs effective allocations 1758 processed in the LORDN file. 1760 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1761 a ="accepted" and ="no-warnings". 1763 o second line: a header line as specified in [RFC4180] 1765 With the header names as follows: 1767 roid,result-code 1769 o One or more lines with: , 1771 Where: 1773 + , DN Repository Object IDentifier (DNROID) in the SRS. 1775 + , result code as described in Section 6.3.1.1. 1777 Example for LORDN Log file 1779 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1780 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1781 accepted,no-warnings,1 1782 roid,result-code 1783 SH8013-REP,2000 1785 Figure 14 1787 6.3.1.1. LORDN Log Result Codes 1789 In Figure 15 the classes of result codes (rc) are listed. Those 1790 classes in square brackets are not used at this time, but may come 1791 into use at some later stage. The first two digits of a result code 1792 denote the result code class, which defines the outcome at the TMDB: 1794 o ok: Success, DN Line accepted by the TMDB. 1796 o warn: a warning is issued, DN Line accepted by the TMDB. 1798 o err: an error is issued, LORDN file rejected by the TMDB. 1800 In case that after processing a DN Line, the error result code is 1801 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1802 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1803 valid will be reported with a 2001 result code. A 2001 result code 1804 means that the DN Line is syntactically valid, however the DN Line 1805 was not processed because the LORDN file was rejected. All DNs 1806 reported in a rejected LORDN file MUST be reported again by the 1807 Registry because none of the DN Lines present in the LORDN file have 1808 been processed by the TMDB. 1810 LORDN Log Result Code Classes 1812 code Class outcome 1813 ---- ----- ------- 1815 20xx Success ok 1817 35xx [ DN Line syntax warning ] warn 1818 36xx DN Line semantic warning warn 1820 45xx DN Line syntax error err 1821 46xx DN Line semantic error err 1823 Figure 15 1825 In the following, the LORDN Log result codes used by the TMDB are 1826 described: 1828 LORDN Log result Codes 1830 rc Short Description 1831 Long Description 1833 ---- ------------------------------------------------------------- 1835 2000 OK 1836 DN Line successfully processed. 1838 2001 OK but not processed 1839 DN Line is syntactically correct but was not processed 1840 because the LORDN file was rejected. 1842 3601 TCN Acceptance Date after Registration Date 1843 TCN Acceptance Date in DN Line is newer than the Registration 1844 Date. 1846 3602 Duplicate DN Line 1847 This DN Line is an exact duplicate of another DN Line in same 1848 file, DN Line ignored. 1850 3603 DNROID Notified Earlier 1851 Same DNROID has been notified earlier, DN Line ignored. 1853 3604 TCN Checksum invalid 1854 Based on the DN effectively allocated, the TCNID and the 1855 expiration date of the linked TCN, the TCN Checksum is 1856 invalid. 1858 3605 TCN Expired 1859 The TCN was already expired (based on the field of the TCN) 1860 at the time of acknowledgement. 1862 3606 Wrong TCNID used 1863 The TCNID used for the registration does not match 1864 the related DN. 1866 3609 Invalid SMD used 1867 The SMD used for registration was not valid at the moment of 1868 registration based on the and 1869 elements. 1870 In case of an asynchronous registration, this refer to the 1871 . 1873 3610 DN reported outside of the time window 1874 The DN was reported outside of the required 26 hours 1875 reporting window. 1877 3611 DN does not match the labels in SMD 1878 The DN does not match the labels included in the SMD. 1880 3612 SMDID does not exist 1881 The SMDID has never existed in the central repository. 1883 3613 SMD was revoked when used 1884 The SMD used for registration was revoked more than 1885 24 hours ago of the . 1886 In case of an asynchronous registration, 1887 the is used when 1888 validating the DN Line. 1890 3614 TCNID does not exist 1891 The TCNID has never existed in the central repository. 1893 3615 Recent-dnl-insertion outside of the time window 1894 The DN registration is reported as a recent-dnl-insertion, 1895 but the (re) insertion into the DNL ocurred more than 1896 24 hours ago. 1898 3616 Registration Date of DN in claims before the end of Sunrise 1899 The registration date of the DN is before the end of Sunrise 1900 and the DN was reported in a claims LORDN file. 1902 3617 Registrar has not been approved by the TMDB 1903 Registrar ID in DN Line has not completed Claims integration 1904 testing with the TMDB. 1906 3618 Registration Date of DN in a QLP LORDN file outside of the QLP period 1907 The registration date of the DN in a QLP LORDN file is outside 1908 of the QLP period. 1910 3619 TCN was not valid 1911 The TCN was not valid (based on the field of the TCN) 1912 at the time of acknowledgement. 1914 4501 Syntax Error in DN Line 1915 Syntax Error in DN Line. 1917 4601 Invalid TLD used 1918 The TLD in the DN Line does not match what is expected for 1919 this LORDN. 1921 4602 Registrar ID Invalid 1922 Registrar ID in DN Line is not a valid ICANN-Accredited 1923 Registrar. 1925 4603 Registration Date in the future 1926 The in the DN Line is in the 1927 future. 1929 4606 TLD not in Sunrise or Claims 1930 The was reported when the TLD was 1931 not in Sunrise or Claims. 1932 In case of an asynchronous registration, 1933 the is used when 1934 validating the DN Line. 1936 4607 Application Date in the future 1937 The in the DN Line is in the 1938 future. 1940 4608 Application Date is later than Registration Date 1941 The in the DN Line is later 1942 than the . 1944 4609 TCNID wrong syntax 1945 The syntax of the TCNID is invalid. 1947 4610 TCN Acceptance Date is in the future 1948 The is in the future. 1950 4611 Label has never existed in the TMDB 1951 The label in the registered DN has never existed in the TMDB. 1953 Figure 16 1955 6.4. SMD File 1957 This section defines the format of the SMD File. After a successful 1958 registration of a mark, the TMV returns an SMD File to the TMH. The 1959 SMD File can then be used for registration of one or more DNs covered 1960 by the PRM during the Sunrise Period of a TLD. 1962 Two encapsulation boundaries are defined for delimiting the 1963 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1964 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1965 boundaries MUST be used by Registries and Registrars for validation 1966 purposes, i.e. any data outside these boundaries as well as the 1967 boundaries themselves MUST be ignored for validation purposes. 1969 The structure of the SMD File is as follows: 1971 o Marks: 1973 o smdID: 1975 o U-labels: 1978 o notBefore: 1980 o notAfter: 1982 o -----BEGIN ENCODED SMD----- 1984 o 1986 o -----END ENCODED SMD----- 1987 Example for SMD File (shortened at [...]): 1989 Marks: Example One 1990 smdID: 1-2 1991 U-labels: example-one, exampleone 1992 notBefore: 2011-08-16 09:00 1993 notAfter: 2012-08-16 09:00 1994 -----BEGIN ENCODED SMD----- 1995 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1996 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1997 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1998 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 1999 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 2000 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 2001 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 2002 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 2003 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 2004 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 2005 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 2006 [...] 2007 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 2008 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 2009 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 2010 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 2011 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 2012 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 2013 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 2014 -----END ENCODED SMD----- 2016 Figure 17 2018 6.5. Trademark Claims Notice 2020 The TMDB MUST provide the TCN to Registrars in XML format as 2021 specified below. 2023 An enclosing element that describes the Trademark 2024 Notice to a given label. 2026 The child elements of the element include: 2028 o A element that contains the unique identifier of the 2029 Trademark Notice. This element contains the the TCNID. 2031 The TCNID is a string concatenation of a TCN Checksum and the 2032 TMDB Notice Identifier. The first 8 characters of the TCNID is 2033 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2034 is a zero-padded natural number in the range of 2035 0000000000000000001 to 9223372036854775807. 2037 Example of a TCNID: 2039 370d0b7c9223372036854775807. 2041 Where: 2043 + TCN Checksum=370d0b7c 2045 + TMDB Notice Identifier=9223372036854775807 2047 The TCN Checksum is a 8 characters long Base16 encoded output 2048 of computing the CRC32 of the string concatenation of: label + 2049 unix_timestamp() + TMDB Notice Identifier 2051 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is 2053 defined as the number of seconds that have elapsed since 1970- 2054 01-01T00:00:00Z not counting leap seconds. For example, the 2055 conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: 2057 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2059 The TMDB uses the and 2060 elements from the TCN along with the TMDB Notice Identifier to 2061 compute the TCN Checksum. 2063 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 2064 of the DN being registered, the expiration datetime of the TCN 2065 (provided by the Registrar) and the TMDB Notice Identifier 2066 extracted from the TCNID (provided by the Registrar) to compute 2067 the TCN Checksum. For example the DN "foo.bar.example" being 2068 effectively allocated, the left most label would be "foo". 2070 Example of computation of the TCN Checksum: 2072 CRC32(example-one12819492009223372036854775807)=370d0b7c 2074 o A element that contains the start of the 2075 validity date and time of the TCN. 2077 o A element that contains the expiration date 2078 and time of the TCN. 2080 o A elements that contain the DNL (A-label in case 2081 of IDNs) form of the label that correspond to the DN covered by a 2082 PRM. 2084 o One or more elements that contain the Trademark 2085 Claim. The element contains the following child 2086 elements: 2088 * A element that contains the mark text 2089 string. 2091 * One or more elements that contains the 2092 information of the holder of the mark. An "entitlement" 2093 attribute is used to identify the entitlement of the holder, 2094 possible values are: owner, assignee or licensee. The child 2095 elements of include: 2097 + An OPTIONAL element that contains the name 2098 of the holder. A MUST be specified if 2099 is not specified. 2101 + An OPTIONAL element that contains the name of 2102 the organization holder of the mark. A MUST 2103 be specified if is not specified. 2105 + A element that contains the address 2106 information of the holder of a mark. A 2107 contains the following child elements: 2109 - One, two or three OPTIONAL elements 2110 that contains the organization's street address. 2112 - A element that contains the 2113 organization's city. 2115 - An OPTIONAL element that contains the 2116 organization's state or province. 2118 - An OPTIONAL element that contains the 2119 organization's postal code. 2121 - A element that contains the organization's 2122 country code. This a two-character code from 2123 [ISO3166-2]. 2125 + An OPTIONAL element that contains the 2126 organization's voice telephone number. 2128 + An OPTIONAL element that contains the 2129 organization's facsimile telephone number. 2131 + An OPTIONAL element that contains the email 2132 address of the holder. 2134 * Zero or more OPTIONAL elements that contains 2135 the information of the representative of the mark registration. 2136 A "type" attribute is used to identify the type of contact, 2137 possible values are: owner, agent or thirdparty. The child 2138 elements of include: 2140 + A element that contains name of the 2141 responsible person. 2143 + An OPTIONAL element that contains the name of 2144 the organization of the contact. 2146 + A element that contains the address 2147 information of the contact. A contains the 2148 following child elements: 2150 - One, two or three OPTIONAL elements 2151 that contains the contact's street address. 2153 - A element that contains the contact's 2154 city. 2156 - An OPTIONAL element that contains the 2157 contact's state or province. 2159 - An OPTIONAL element that contains the 2160 contact's postal code. 2162 - A element that contains the contact's 2163 country code. This a two-character code from 2164 [ISO3166-2]. 2166 + A element that contains the contact's voice 2167 telephone number. 2169 + An OPTIONAL element that contains the 2170 contact's facsimile telephone number. 2172 + A element that contains the contact's email 2173 address. 2175 * A element that contains the name (in 2176 English) of the jurisdiction where the mark is protected. A 2177 jurCC attribute contains the two-character code of the 2178 jurisdiction where the mark was registered. This is a two- 2179 character code from [WIPO.ST3]. 2181 * Zero or more OPTIONAL element that 2182 contains the description (in English) of the Nice 2183 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2184 attribute contains the class number. 2186 * A element that contains the full 2187 description of the goods and services mentioned in the mark 2188 registration document. 2190 * An OPTIONAL element signals that the 2191 claim notice was added to the TCN based on other rule than 2192 exact match as defined in [ICANN-GTLD-AGB-20120604]. The 2193 contains one or more: 2195 + An OPTIONAL element that signals that the 2196 claim notice was added because of a previously abused name 2197 included in an UDRP case. The contains: 2199 - A element that contains the UDRP case 2200 number used to validate the previously abused name. 2202 - A element that contains the name 2203 of the UDRP provider. 2205 + An OPTIONAL element that signals that the 2206 claim notice was added because of a previously abused name 2207 included in a court's resolution. The 2208 contains: 2210 - A element that contains the reference 2211 number of the court's resolution used to validate the 2212 previously abused name. 2214 - A element that contains the two-character 2215 code from [ISO3166-2] of the jurisdiction of the court. 2217 - A element that contains the name of 2218 the court. 2220 Example of object: 2222 2223 2224 370d0b7c9223372036854775807 2225 2010-08-14T09:00:00.0Z 2226 2010-08-16T09:00:00.0Z 2227 example-one 2228 2229 Example One 2230 2231 Example Inc. 2232 2233 123 Example Dr. 2234 Suite 100 2235 Reston 2236 VA 2237 20190 2238 US 2239 2240 2241 2242 Joe Doe 2243 Example Inc. 2244 2245 123 Example Dr. 2246 Suite 100 2247 Reston 2248 VA 2249 20190 2250 US 2251 2252 +1.7035555555 2253 jdoe@example.com 2254 2255 UNITED STATES OF AMERICA 2256 2257 Advertising; business management; business administration. 2258 2259 2260 Insurance; financial affairs; monetary affairs; real estate. 2261 2262 2263 Bardus populorum circumdabit se cum captiosus populum. 2264 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2265 2266 2267 2268 Example-One 2269 2270 Example S.A. de C.V. 2271 2272 Calle conocida #343 2273 Conocida 2274 SP 2275 82140 2276 BR 2277 2278 2279 BRAZIL 2280 2281 Bardus populorum circumdabit se cum captiosus populum. 2282 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2283 2284 2285 2286 One 2287 2288 One Corporation 2289 2290 Otra calle 2291 Otra ciudad 2292 OT 2293 383742 2294 CR 2295 2296 2297 COSTA RICA 2298 2299 Bardus populorum circumdabit se cum captiosus populum. 2300 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2301 2302 2303 2304 234235 2305 CR 2306 Supreme Court of Justice of Costa Rica 2307 2308 2309 2310 2311 One Inc 2312 2313 One SA de CV 2314 2315 La calle 2316 La ciudad 2317 CD 2318 34323 2319 AR 2320 2321 2322 ARGENTINA 2323 2324 Bardus populorum circumdabit se cum captiosus populum. 2325 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2326 2327 2328 2329 D2003-0499 2330 WIPO 2331 2332 2333 2334 2336 For formal syntax of the TCN please refer to Section 7.1. 2338 6.6. Sunrise List File 2340 This section defines the format of the list containing every Domain 2341 Name Label (DNL) that matches a Pre-Registered Mark (PRM) eligible 2342 for Sunrise. The list is maintained by the TMDB and downloaded by 2343 Registries in regular intervals (see Section 5.4.2.1). The 2344 Registries use the Sunrise List during the Qualified Launch Program 2345 period to check whether a requested DN matches a DNL of a PRM 2346 eligible for Sunrise. 2348 The Sunrise List contains all the DNLs covered by a PRM eligible for 2349 Sunrise present in the TMDB at the time it is generated. 2351 The Sunrise List is contained in a CSV-like formatted file that has 2352 the following structure: 2354 o first line: , 2356 Where: 2358 + , version of the file, this field MUST be 1. 2360 + , date and time in UTC that 2361 the Sunrise List was created. 2363 o second line: a header line as specified in [RFC4180] 2365 With the header names as follows: 2367 DNL,insertion-datetime 2369 o One or more lines with: , 2371 Where: 2373 + , a Domain Name Label covered by a PRM eligible for 2374 Sunrise. 2376 + , datetime in UTC that the DNL was 2377 first inserted into the Sunrise List. The possible two 2378 values of time for inserting a DNL to the Sunrise List are 2379 00:00:00 and 12:00:00 UTC. 2381 Example for Sunrise List 2383 1,2012-08-16T00:00:00.0Z 2384 DNL,insertion-datetime 2385 example,2010-07-14T00:00:00.0Z 2386 another-example,2012-08-16T00:00:00.0Z 2387 anotherexample,2011-08-16T12:00:00.0Z 2389 Figure 18 2391 To provide authentication and integrity protection, the Sunrise List 2392 will be PGP [RFC4880] signed by the TMDB with the private key of the 2393 TMDB (see also Section 5.1.1.4). The PGP signature of the Sunrise 2394 List can be found in the similar URI but with extension .sig as shown 2395 below. 2397 The URL of the dy interface (Section 4.3.3) is: 2399 o < https:///dnl/surl-latest.csv > 2401 o < https:///dnl/surl-latest.sig > 2403 7. Formal Syntax 2405 7.1. Trademark Claims Notice 2407 The schema presented here is for a Trademark Claims Notice. 2409 Copyright (c) 2012 IETF Trust and the persons identified as authors 2410 of the code. All rights reserved. 2412 Redistribution and use in source and binary forms, with or without 2413 modification, are permitted provided that the following conditions 2414 are met: 2416 o Redistributions of source code must retain the above copyright 2417 notice, this list of conditions and the following disclaimer. 2419 o Redistributions in binary form must reproduce the above copyright 2420 notice, this list of conditions and the following disclaimer in 2421 the documentation and/or other materials provided with the 2422 distribution. 2424 o Neither the name of Internet Society, IETF or IETF Trust, nor the 2425 names of specific contributors, may be used to endorse or promote 2426 products derived from this software without specific prior written 2427 permission. 2429 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2430 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2431 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2432 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2433 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2434 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2435 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2436 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2437 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2438 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2439 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2441 BEGIN 2442 2443 2448 2449 2450 Schema for representing a Trademark Notice. 2451 2452 2453 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2475 2476 2477 2478 2479 2480 2482 2484 2485 2487 2488 2490 2491 2492 2493 2494 2495 2496 2497 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2548 2549 2550 2551 2552 2553 2554 2555 END 2556 8. Acknowledgements 2558 This specification is a collaborative effort from several 2559 participants in the ICANN community. Bernie Hoeneisen participated 2560 as co-author until version 02 providing invaluable support for this 2561 document. This specification is based on a model spearheaded by: 2562 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2563 would also like to thank the thoughful feedbak provided by many in 2564 the tmch-tech mailing list, but particularly the extensive help 2565 provided by James Gould, James Mitchell and Francisco Arias. 2567 9. Change History 2569 [[RFC Editor: Please remove this section.]] 2571 9.1. Changes from draft-lozano-tmch-func-spec-06 to 2572 draft-lozano-tmch-func-spec-07 2574 1. Added result codes: 3611, 3612, 3613, 3614, 4607, 4608, 4609 and 2575 4610. 2577 2. Added mechanism to retrieve the LORDN Transaction Identifier 2578 based on a previously sent element. 2580 9.2. Changes from draft-lozano-tmch-func-spec-07 to 2581 draft-lozano-tmch-func-spec-08 2583 1. Updated result codes: 3613. 2585 2. Added result codes: 3615, 3616, 3617 and 4611. 2587 3. Removed result codes: 4605 and 4606 to support Limited 2588 Registration Periods as defined in the latest RPM Requirements 2589 document. 2591 4. Minor editorial fixes. 2593 9.3. Changes from draft-lozano-tmch-func-spec-08 to 2594 draft-lozano-tmch-func-spec-09 2596 1. Added support for QLP. 2598 2. Updated result codes: 3605. 2600 3. Added result codes: 3618 (QLP) and 3619. 2602 4. XML Schema fix. 2604 5. Minor editorial fixes. 2606 10. IANA Considerations 2608 This document uses URNs to describe XML namespaces and XML schemas 2609 conforming to a registry mechanism described in [RFC3688]. One URI 2610 assigment have been registered by the IANA. 2612 Registration request for the Trademark Claims Notice: 2614 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2616 Registrant Contact: See the "Author's Address" section of this 2617 document. 2619 XML: None. Namespace URIs do not represent an XML specification. 2621 11. Security Considerations 2623 TBD 2625 12. References 2627 12.1. Normative References 2629 [I-D.lozano-tmch-smd] 2630 Lozano, G., "Mark and Signed Mark Objects Mapping", 2631 draft-lozano-tmch-smd-03 (work in progress), 2632 September 2013. 2634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2635 Requirement Levels", BCP 14, RFC 2119, March 1997. 2637 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2638 January 2004. 2640 12.2. Informative References 2642 [ICANN-GTLD-AGB-20120604] 2643 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2644 June 2012, . 2647 [ISO3166-2] 2648 ISO, "International Standard for country codes and codes 2649 for their subdivisions", 2006. 2651 [QLP-Addendum] 2652 ICANN, "Qualified Launch Program Addendum", April 2014, . 2656 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2657 STD 13, RFC 1034, November 1987. 2659 [RFC1035] Mockapetris, P., "Domain names - implementation and 2660 specification", STD 13, RFC 1035, November 1987. 2662 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 2663 RFC 1591, March 1994. 2665 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2666 E. Lear, "Address Allocation for Private Internets", 2667 BCP 5, RFC 1918, February 1996. 2669 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2670 Randers-Pehrson, "GZIP file format specification version 2671 4.3", RFC 1952, May 1996. 2673 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2674 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2675 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2677 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2679 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2680 Internet: Timestamps", RFC 3339, July 2002. 2682 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2683 Separated Values (CSV) Files", RFC 4180, October 2005. 2685 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2686 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2688 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2689 Encodings", RFC 4648, October 2006. 2691 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2692 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2694 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2695 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2697 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2698 Housley, R., and W. Polk, "Internet X.509 Public Key 2699 Infrastructure Certificate and Certificate Revocation List 2700 (CRL) Profile", RFC 5280, May 2008. 2702 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2703 STD 69, RFC 5730, August 2009. 2705 [RFC5890] Klensin, J., "Internationalized Domain Names for 2706 Applications (IDNA): Definitions and Document Framework", 2707 RFC 5890, August 2010. 2709 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2710 Infrastructure Certificate and Certificate Revocation List 2711 (CRL) Profile", RFC 6818, January 2013. 2713 [WIPO-NICE-CLASSES] 2714 WIPO, "Nice List of Classes", . 2717 [WIPO.ST3] 2718 WIPO, "Recommended standard on two-letter codes for the 2719 representation of states, other entities and 2720 intergovernmental organizations", March 2007. 2722 Appendix A. Document Changelog 2724 [RFC Editor: This section is to be removed before publication] 2726 Author's Address 2728 Gustavo Lozano 2729 ICANN 2730 12025 Waterfront Drive, Suite 300 2731 Los Angeles 90292 2732 US 2734 Phone: +1.3103015800 2735 Email: gustavo.lozano@icann.org