idnits 2.17.1 draft-ietf-eppext-tmch-func-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9A-F' is mentioned on line 1350, but not defined == Unused Reference: 'RFC2617' is defined on line 2616, 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 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 3 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: Standards Track March 21, 2016 5 Expires: September 22, 2016 7 ICANN TMCH functional specifications 8 draft-ietf-eppext-tmch-func-spec-01 10 Abstract 12 This document describes the requirements, the architecture and the 13 interfaces between the ICANN Trademark Clearinghouse (TMCH) and 14 Domain Name Registries as well as between the ICANN TMCH and Domain 15 Name Registrars for the provisioning and management of domain names 16 during Sunrise and Trademark Claims Periods. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 22, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 9 57 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 58 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . 13 77 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 78 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 79 5.1.1.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 14 80 5.1.1.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 14 81 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15 82 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 83 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 84 5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15 85 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 15 86 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.1. Domain Name registration . . . . . . . . . . . . . . 16 88 5.2.2. Sunrise Domain Name registration by Registries . . . 17 89 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 18 90 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18 91 5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 18 92 5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 19 93 5.2.4. Sunrise Domain Name registration by Registrars . . . 22 94 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 22 95 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23 96 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23 97 5.3.2. Trademark Claims Domain Name registration by 98 Registries . . . . . . . . . . . . . . . . . . . . . 24 99 5.3.3. TMBD Trademark Claims Services for Registries . . . . 25 100 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 25 101 5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 26 102 5.3.4. Trademark Claims Domain Name registration by 103 Registrars . . . . . . . . . . . . . . . . . . . . . 26 104 5.3.5. TMBD Trademark Claims Services for Registrars . . . . 27 105 5.3.5.1. Claims Notice Information Service (CNIS) . . . . 27 106 5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 28 107 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 28 108 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 30 109 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 30 110 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 30 111 6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 30 112 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 32 113 6.3. List of Registered Domain Names (LORDN) file . . . . . . 34 114 6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39 115 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 41 116 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 45 117 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 46 118 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 53 119 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54 120 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 54 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 123 10. Security Considerations . . . . . . . . . . . . . . . . . . . 57 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 125 11.1. Normative References . . . . . . . . . . . . . . . . . . 58 126 11.2. Informative References . . . . . . . . . . . . . . . . . 58 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60 129 1. Introduction 131 Domain Name Registries (DNRs) may operate in special modes for 132 certain periods of time enabling trademark holders to protect their 133 rights during the introduction of a Top Level Domain (TLD). 135 Along with the introduction of new generic TLDs (gTLD), two special 136 modes came into effect: 138 o Sunrise Period, the Sunrise Period allows trademark holders an 139 advance opportunity to register domain names corresponding to 140 their marks before names are generally available to the public. 142 o Trademark Claims Period, the Trademark Claims Period follows the 143 Sunrise Period and runs for at least the first 90 days of an 144 initial operating period of general registration. During the 145 Trademark Claims Period, anyone attempting to register a domain 146 name matching a mark that is recorded in the ICANN Trademark 147 Clearinghouse (TMCH) will receive a notification displaying the 148 relevant mark information. 150 This document describes the requirements, the architecture and the 151 interfaces between the ICANN TMCH and Domain Name Registries (called 152 Registries in the rest of the document) as well as between the ICANN 153 TMCH and Domain Name Registrars (called Registrars in the rest of the 154 document) for the provisioning and management of domain names during 155 the Sunrise and Trademark Claims Periods. 157 For any date and/or time indications, Coordinated Universal Time 158 (UTC) applies. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 XML is case sensitive. Unless stated otherwise, XML specifications 167 and examples provided in this document MUST be interpreted in the 168 character case presented in order to develop a conforming 169 implementation. 171 "tmNotice-1.0" is used as an abbreviation for 172 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 173 "tmNotice" is used, but implementations MUST NOT depend on it and 174 instead employ a proper namespace-aware XML parser and serializer to 175 interpret and output the XML documents. 177 3. Glossary 179 In the following section, the most common terms are briefly 180 explained: 182 o Backend Registry Operator: Entity that manages (a part of) the 183 technical infrastructure for a Registry Operator. The Registry 184 Operator may also be the Backend Registry Operator. 186 o CA: Certificate Authority, see [RFC5280]. 188 o CNIS, Claims Notice Information Service: This service provides 189 Trademark Claims Notices (TCN) to Registrars. 191 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 192 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 194 o CRL: Certificate Revocation List, see [RFC5280]. 196 o CSV: Comma-Separated Values, see [RFC4180] 198 o Date and time, datetime: Date and time are specified following the 199 standard "Date and Time on the Internet specification", see 200 [RFC3339]. 202 o DN, Domain Name, domain name: see definition of Domain name in 203 [RFC7719]. 205 o DNROID, DN Repository Object IDentifier: an identifier assigned by 206 the Registry to each DN object that unequivocally identifies said 207 DN object. For example, if a new DN object is created for a name 208 that existed in the past, the DN objects will have different 209 DNROIDs. 211 o DNL, Domain Name Label, see definition of Label in [RFC7719]. 213 o DNL List: A list of DNLs that are covered by a PRM. 215 o DNS: Domain Name System, see [RFC7719]. 217 o Effective allocation: A DN is considered effectively allocated 218 when the DN object for the DN has been created in the SRS of the 219 Registry and has been assigned to the effective user. A DN object 220 in status "pendingCreate" or any other status that precedes the 221 first time a DN is assigned to an end-user is not considered an 222 effective allocation. A DN object created internally by the 223 Registry for subsequent delegation to another Registrant is not 224 considered an effective allocation. 226 o EPP: The Extensible Provisioning Protocol, see definition of EPP 227 in [RFC7719]. 229 o FQDN: Fully-Qualified Domain Name, see definition of FQDN in 230 [RFC7719]. 232 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 234 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. 236 o IDN: Internationalized Domain Name, see definition of IDN in 237 [RFC7719]. 239 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 240 Z0-9/] to be used as the lookup key by Registrars to obtain the 241 TCN using the CNIS. Lookup Keys are unique and are related to one 242 DNL only. 244 o LORDN, List of Registered Domain Names: This is the list of 245 effectively allocated DNs matching a DNL of a PRM. Registries 246 will upload this list to the TMDB (during the NORDN process). 248 o NORDN, Notification of Registered Domain Names: The process by 249 which Registries upload their recent LORDN to the TMDB. 251 o PGP: Pretty Good Privacy, see [RFC4880] 253 o PKI: Public Key Infrastructure, see [RFC5280]. 255 o PRM, Pre-registered mark: Mark that has been pre-registered with 256 the ICANN TMCH. 258 o QLP Period, Qualified Launch Program Period: During this optional 259 period, a special process applies to DNs matching the Sunrise List 260 (SURL) and/or the DNL List, to ensure that TMHs are informed of a 261 DN matching their PRM. 263 o Registrant: see definition of Registrant in [RFC7719]. 265 o Registrar, Domain Name Registrar: see definition of Registrar in 266 [RFC7719]. 268 o Registry, Domain Name Registry, Registry Operator: see definition 269 of Registry in [RFC7719]. A Registry Operator is the contracting 270 party with ICANN for the TLD. 272 o SMD, Signed Mark Data: A cryptographically signed token issued by 273 the TMV to the TMH to be used in the Sunrise Period to apply for a 274 DN that matches a DNL of a PRM; see also 275 [I-D.ietf-eppext-tmch-smd]. An SMD generated by an ICANN-approved 276 trademark validator (TMV) contains both the signed token and the 277 TMV's PKIX certificate. 279 o SMD File: A file containing the SMD (see above) and some human 280 readable data. The latter is usually ignored in the processing of 281 the SMD File. See also Section 6.4. 283 o SMD Revocation List: The SMD Revocation List is used by Registries 284 (and optionally by Registrars) during the Sunrise Period to ensure 285 that an SMD is still valid (i.e. not revoked). The SMD Revocation 286 List has a similar function as CRLs used in PKI. 288 o SRS: Shared Registration System, see also 289 [ICANN-GTLD-AGB-20120604]. 291 o SURL, Sunrise List: The list of DNLs that are covered by a PRM and 292 eligible for Sunrise. 294 o Sunrise Period: During this period DNs matching a DNL of a PRM can 295 be exclusively obtained by the respective TMHs. For DNs matching 296 a PRM, a special process applies to ensure that TMHs are informed 297 on the effective allocation of a DN matching their PRM. 299 o TLD: Top-Level Domain Name, see definition of TLD in [RFC7719]. 301 o ICANN TMCH: a central repository for information to be 302 authenticated, stored, and disseminated, pertaining to the rights 303 of TMHs. The ICANN TMCH is split into two functions TMV and TMDB 304 (see below). There could be several entities performing the TMV 305 function, but only one entity performing the TMDB function. 307 o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. 308 This CA is operated by ICANN. The public key for this CA is the 309 trust anchor used to validate the identity of each TMV. 311 o TMDB, Trademark Clearinghouse Database: Serves as a database of 312 the ICANN TMCH to provide information to the gTLD Registries and 313 Registrars to support Sunrise or Trademark Claims services. There 314 is only one TMDB in the ICANN TMCH that concentrates the 315 information about the "verified" Trademark records from the TMVs. 317 o TMH, Trademark Holder: The person or organization owning rights on 318 a mark. 320 o TMV, Trademark Validator, Trademark validation organization: An 321 entity authorized by ICANN to authenticate and validate 322 registrations in the TMDB ensuring the marks qualify as registered 323 or are court-validated marks or marks that are protected by 324 statute or treaty. This entity would also be asked to ensure that 325 proof of use of marks is provided, which can be demonstrated by 326 furnishing a signed declaration and one specimen of current use. 328 o Trademark, mark: Marks are used to claim exclusive properties of 329 products or services. A mark is typically a name, word, phrase, 330 logo, symbol, design, image, or a combination of these elements. 331 For the scope of this document only textual marks are relevant. 333 o Trademark Claims, Claims: Provides information to enhance the 334 understanding of the Trademark rights being claimed by the TMH. 336 o TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A 337 Trademark Claims Notice consist of one or more Trademark Claims 338 and are provided to prospective Registrants of DNs. 340 o TCNID, Trademark Claims Notice Identifier: An element of the 341 Trademark Claims Notice (see above), identifying said TCN. The 342 Trademark Claims Notice Identifier is specified in the element 343 . 345 o Trademark Claims Period: During this period, a special process 346 applies to DNs matching the DNL List, to ensure that TMHs are 347 informed of a DN matching their PRM. For DNs matching the DNL 348 List, Registrars show a TCN to prospective Registrants that has to 349 be acknowledged before effective allocation of the DN. 351 o UTC: Coordinated Universal Time, as maintained by the Bureau 352 International des Poids et Mesures (BIPM); see also [RFC3339]. 354 4. Architecture 356 4.1. Sunrise Period 358 Architecture of the Sunrise Period 360 SMD hand over (out-of-band) 361 .............................................. 362 : : 363 : .'''''''''''''''''''. : 364 : . ICANN TMCH . : 365 : ..................... : 366 v . . : 367 .------------. . .-------------. . hv .-----. 368 | Registrant | . | TMV |<---------->| TMH | 369 '------------' . '-------------' . vh '-----' 370 | . | ^ \ . 371 | . | | \. 372 tr | . vs | | dv \ 373 | . | vd | .\ 374 v . v v . \ 375 .-----------. sr . .---------. . \ 376 .->| Registrar |<..........| | . \ 377 : '-----------' . | | . \ 378 : | sy . | T | . \ 379 : ry | .------------| M | . vc \ 380 : | | . | D | . \ 381 : v v . | B | . v 382 : .-----------. . yd | | . .---------------. 383 : | Registry |---------->| | . | ICANN TMCH-CA | 384 : '-----------' . '---------' . '---------------' 385 : ^ . . | : 386 : | ''''''''''''''''''' | : 387 : | cy | : 388 : cr '-----------------------------------------' : 389 :......................................................: 391 Figure 1 393 4.2. Trademark Claims Period 395 Architecture of the Trademark Claims Period 397 .''''''''''''''. 398 . ICANN TMCH . 399 ................ 400 . . 401 .------------. . .-------. . hv .-----. 402 | Registrant | . | TMV |<----------->| TMH | 403 '------------' . '-------' . vh '-----' 404 | . ^ . 405 | . | dv . 406 tr | . vd | . 407 v . v . 408 .-----------. dr . .-------. . 409 | Registrar |<--------| | . 410 '-----------' . | T | . 411 ry | . | M | . 412 v . | D | . 413 .----------. dy . | B | . 414 | Registry |<------->| | . 415 '----------' yd . '-------' . 416 . . 417 '''''''''''''' 419 Figure 2 421 4.3. Interfaces 423 In the sub-sections below follows a short description of each 424 interface to provide an overview of the architecture. More detailed 425 descriptions of the relevant interfaces follow further below 426 (Section 5). 428 4.3.1. hv 430 The TMH registers a mark with a TMV via the hv interface. 432 After the successful registration of the mark, the TMV makes 433 available a SMD File (see also Section 6.4) to the TMH to be used 434 during the Sunrise Period. 436 The specifics of the hv interface are beyond the scope of this 437 document. 439 4.3.2. vd 441 After successful mark registration, the TMV ensures the TMDB inserts 442 the corresponding DNLs and mark information into the database via the 443 vd interface. 445 The specifics of the vd interface are beyond the scope of this 446 document. 448 4.3.3. dy 450 During the Trademark Claims Period the Registry fetches the latest 451 DNL List from the TMDB via the dy interface at regular intervals. 452 The protocol used on the dy interface is HTTPS. 454 Not relevant during the Sunrise Period. 456 4.3.4. tr 458 The Registrant communicates with the Registrar via the tr interface. 460 The specifics of the tr interface are beyond the scope of this 461 document. 463 4.3.5. ry 465 The Registrar communicate with the Registry via the ry interface. 466 The ry interfaces is typically implemented in EPP. 468 4.3.6. dr 470 During the Trademark Claims Period, the Registrar fetches the TCN 471 from the TMDB (to be displayed to the Registrant via the tr 472 interface) via the dr interface. The protocol used for fetching the 473 TCN is HTTPS. 475 Not relevant during the Sunrise Period. 477 4.3.7. yd 479 During the Sunrise Period the Registry notifies the TMDB via the yd 480 interface of all DNs effectively allocated. 482 During the Trademark Claims Period, the Registry notifies the TMDB 483 via the yd interface of all DNs effectively allocated that matched an 484 entry in the Registry previously downloaded DNL List during the 485 creation of the DN. 487 The protocol used on the yd interface is HTTPS. 489 4.3.8. dv 491 The TMDB notifies via the dv interface to the TMV of all DNs 492 effectively allocated that match a mark registered by that TMV. 494 The specifics of the dv interface are beyond the scope of this 495 document. 497 4.3.9. vh 499 The TMV notifies the TMH via the vh interface after a DN has been 500 effectively allocated that matches a PRM of this TMH. 502 The specifics of the vh interface are beyond the scope of this 503 document. 505 4.3.10. vs 507 The TMV requests to add a revoked SMD to the SMD Revocation List at 508 the TMDB. 510 The specifics of the vs interface are beyond the scope of this 511 document. 513 Not relevant during the Trademark Claims Period. 515 4.3.11. sy 517 During the Sunrise Period the Registry fetches the most recent SMD 518 Revocation List from the TMDB via the sy interface in regular 519 intervals. The protocol used on the sy interface is HTTPS. 521 Not relevant during the Trademark Claims Period. 523 4.3.12. sr 525 During the Sunrise Period the Registrar may fetch the most recent SMD 526 Revocation List from the TMDB via the sr interface. The protocol 527 used on the sr interface is the same as on the sy interface (s. 528 above), i.e. HTTPS. 530 Not relevant during the Trademark Claims Period. 532 4.3.13. vc 534 The TMV registers its public key, and requests to revoke an existing 535 key, with the ICANN TMCH-CA over the vc interface. 537 The specifics of the vc interface are beyond the scope of this 538 document, but it involves personal communication between the 539 operators of the TMV and the operators of the ICANN TMCH-CA. 541 Not relevant during the Trademark Claims Period. 543 4.3.14. cy 545 During the Sunrise Period the Registry fetches the most recent TMV 546 CRL file from the ICANN TMCH-CA via the cy interface at regular 547 intervals. The TMV CRL is used for validation of TMV certificates. 548 The protocol used on the cy interface is HTTPS. 550 Not relevant during the Trademark Claims Period. 552 4.3.15. cr 554 During the Sunrise Period the Registrar optionally fetches the most 555 recent TMV CRL file from the ICANN TMCH-CA via the cr interface at 556 regular intervals. The TMV CRL is used for validation of TMV 557 certificates. The protocol used on the cr interface is HTTPS. 559 Not relevant during the Trademark Claims Period. 561 5. Process Descriptions 563 5.1. Bootstrapping 565 5.1.1. Bootstrapping for Registries 567 5.1.1.1. Credentials 569 Each Registry Operator will receive authentication credentials from 570 the TMDB to be used: 572 o During the Sunrise Period to fetch the SMD Revocation List from 573 the TMBD via the sy interface (Section 4.3.11). 575 o During the Trademark Claims Period to fetch the DNL List from the 576 TMDB via the dy interface (Section 4.3.3). 578 o During the NORDN process to notify the LORDN to the TMDB via the 579 yd interface (Section 4.3.7). 581 Note: credentials are created per TLD and provided to the Registry 582 Operator. 584 5.1.1.2. IP Addresses for Access Control 586 Each Registry Operator MUST provide to the TMDB all IP addresses that 587 will be used to: 589 o Fetch the SMD Revocation List via the sy interface 590 (Section 4.3.11). 592 o Fetch the DNL List from the TMDB via the dy interface 593 (Section 4.3.3). 595 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 597 This access restriction MAY be applied by the TMDB in addition to 598 HTTP Basic access authentication (for credentials to be used, see 599 Section 5.1.1.1). 601 The TMDB MAY limit the number of IP addresses to be accepted per 602 Registry Operator. 604 5.1.1.3. ICANN TMCH Trust Anchor 606 Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of 607 the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ 608 tmch.crt > to be used: 610 o During the Sunrise Period to validate the TMV certificates and the 611 TMV CRL. 613 5.1.1.4. TMDB PGP Key 615 The TMDB MUST provide each Registry Operator with the public portion 616 of the PGP Key used by TMDB, to be used: 618 o During the Sunrise Period to perform integrity checking of the SMD 619 Revocation List fetched from the TMDB via the sy interface 620 (Section 4.3.11). 622 o During the Trademark Claims Period to perform integrity checking 623 of the DNL List fetched from the TMDB via the dy interface 624 (Section 4.3.3). 626 5.1.2. Bootstrapping for Registrars 628 5.1.2.1. Credentials 630 Each ICANN-accredited Registrar will receive authentication 631 credentials from the TMDB to be used: 633 o During the Sunrise Period to (optionally) fetch the SMD Revocation 634 List from the TMDB via the sr interface (Section 4.3.12). 636 o During the Trademark Claims Period to fetch TCNs from the TMDB via 637 the dr interface (Section 4.3.6). 639 5.1.2.2. IP Addresses for Access Control 641 Each Registrar MUST provide to the TMDB all IP addresses, which will 642 be used to: 644 o Fetch the SMD Revocation List via the sr interface 645 (Section 4.3.12). 647 o Fetch TCNs via the dr interface (Section 4.3.6). 649 This access restriction MAY be applied by the TMDB in addition to 650 HTTP Basic access authentication (for credentials to be used, see 651 Section 5.1.2.1). 653 The TMDB MAY limit the number of IP addresses to be accepted per 654 Registrar. 656 5.1.2.3. ICANN TMCH Trust Anchor 658 Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust 659 Anchor) from < https://ca.icann.org/tmch.crt > to be used: 661 o During the Sunrise Period to (optionally) validate the TMV 662 certificates and TMV CRL. 664 5.1.2.4. TMDB PGP Key 666 Registrars MUST receive the public portion of the PGP Key used by 667 TMDB from the TMDB administrator to be used: 669 o During the Sunrise Period to (optionally) perform integrity 670 checking of the SMD Revocation List fetched from the TMDB via the 671 sr interface (Section 4.3.12). 673 5.2. Sunrise Period 675 5.2.1. Domain Name registration 677 Domain Name registration during the Sunrise Period 679 .------------. .-----------. .----------. 680 | Registrant | | Registrar | | Registry | 681 '------------' '-----------' '----------' 682 | | | 683 | Request DN | | 684 | registration | | 685 | (with SMD) | | 686 |---------------->| Check DN availability | 687 | |---------------------------->| 688 | | | 689 | | DN unavailable .-------------. 690 | DN unavailable |<--------------------( DN available? ) 691 |<----------------| no '-------------' 692 | | | yes 693 | | DN available | 694 | |<----------------------------| 695 | | | 696 | | Request DN registration | 697 | | (with SMD) | 698 | |---------------------------->| 699 | | | 700 | | .------------------------------. 701 | | | DN registration validation / | 702 | | | SMD validation | 703 | | '------------------------------' 704 | | | 705 | Registration |.-----------. Error .----------------------. 706 | error || TRY AGAIN |<-----( Validation successful? ) 707 |<----------------|| / ABORT | no '----------------------' 708 | |'-----------' | yes 709 | | | 710 | | DN registered | 711 | DN registered |<----------------------------| 712 |<----------------| | 713 | | | 715 Figure 3 717 Note: the figure depicted above represents a synchronous DN 718 registration workflow (usually called first come first served). 720 5.2.2. Sunrise Domain Name registration by Registries 722 Registries MUST perform a minimum set of checks for verifying each DN 723 registration during the Sunrise Period upon reception of a 724 registration request over the ry interface (Section 4.3.5). If any 725 of these checks fails the Registry MUST abort the registration. Each 726 of these checks MUST be performed before the DN is effectively 727 allocated. 729 In case of asynchronous registrations (e.g. auctions), the minimum 730 set of checks MAY be performed when creating the intermediate object 731 (e.g. a DN application) used for DN registration. If the minimum set 732 of checks is performed when creating the intermediate object (e.g. a 733 DN application) a Registry MAY effective allocate the DN without 734 performing the minimum set of checks again. 736 Performing the minimum set of checks Registries MUST verify that: 738 1. An SMD has been received from the Registrar along with the DN 739 registration. 741 2. The certificate of the TMV has been correctly signed by the ICANN 742 TMCH-CA. (The certificate of the TMV is contained within the 743 SMD.) 745 3. The datetime when the validation is done is within the validity 746 period of the TMV certificate. 748 4. The certificate of the TMV is not listed in the TMV CRL file 749 specified in the CRL distribution point of the TMV certificate. 751 5. The signature of the SMD (signed with the TMV certificate) is 752 valid. 754 6. The datetime when the validation is done is within the validity 755 period of the SMD based on and 756 elements. 758 7. The SMD has not been revoked, i.e., is not contained in the SMD 759 Revocation List. 761 8. The leftmost DNL (A-label in case of IDNs) of the DN being 762 effectively allocated matches one of the labels () 763 elements in the SMD. 765 These procedure apply to all DN effective allocations at the second 766 level as well as to all other levels subordinate to the TLD that the 767 Registry accepts registrations for. 769 5.2.3. TMDB Sunrise Services for Registries 771 5.2.3.1. SMD Revocation List 773 A new SMD Revocation List MUST be published by the TMDB twice a day, 774 by 00:00:00 and 12:00:00 UTC. 776 Registries MUST refresh the latest version of the SMD Revocation List 777 at least once every 24 hours. 779 Note: the SMD Revocation List will be the same regardless of the TLD. 780 If a Backend Registry Operator manages the infrastructure of several 781 TLDs, the Backend Registry Operator could refresh the SMD Revocation 782 List once every 24 hours, the SMD Revocation List could be used for 783 all the TLDs managed by the Backend Registry Operator. 785 Update of the SMD Revocation List 787 .----------. .------. 788 | Registry | | TMDB | 789 '----------' '------' 790 | | 791 .----------------. | 792 | Periodically, | | 793 | at least | | 794 | every 24 hours | | 795 '----------------' | 796 | | 797 |----------------------------------------------------->| 798 | Download the latest SMD Revocation List | 799 |<-----------------------------------------------------| 800 | | 801 | | 803 Figure 4 805 5.2.3.2. TMV Certificate Revocation List (CRL) 807 Registries MUST refresh their local copy of the TMV CRL file at least 808 every 24 hours using the CRL distribution point specified in the TMV 809 certificate. 811 Operationally, the TMV CRL file and CRL distribution point is the 812 same for all TMVs and (at publication of this document) located at < 813 http://crl.icann.org/tmch.crl >. 815 Note: the TMV CRL file will be the same regardless of the TLD. If a 816 Backend Registry Operator manages the infrastructure of several TLDs, 817 the Backend Registry Operator could refresh the TMV CRL file once 818 every 24 hours, the TMV CRL file could be used for all the TLDs 819 managed by the Backend Registry Operator. 821 Update of the TMV CRL file 823 .----------. .---------------. 824 | Registry | | ICANN TMCH-CA | 825 '----------' '---------------' 826 | | 827 .----------------. | 828 | Periodically, | | 829 | at least | | 830 | every 24 hours | | 831 '----------------' | 832 | | 833 |-------------------------------------------->| 834 | Download the latest TMV CRL file | 835 |<--------------------------------------------| 836 | | 837 | | 839 Figure 5 841 5.2.3.3. Notice of Registered Domain Names (NORN) 843 The Registry MUST send a LORDN file containing DNs effectively 844 allocated to the TMDB (over the yd interface, Section 4.3.7). 846 The effective allocation of a DN MUST be reported by the Registry to 847 the TMDB within 26 hours of the effective allocation of such DN. 849 The Registry MUST create and upload a LORDN file in case there are 850 effective allocations in the SRS, that have not been successfully 851 reported to the TMDB in a previous LORDN file. 853 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 854 maximum frequency to upload LORDN files from the Registries to the 855 TMDB is every 3 hours. 857 It is RECOMMENDED that Registries try to upload at least two LORDN 858 files per day to the TMDB with enough time in between, in order to 859 have time to fix problems reported in the LORDN file. 861 The Registry SHOULD upload a LORDN file only when the previous LORDN 862 file has been processed by the TMDB and the related LORDN Log file 863 has been downloaded and processed by the Registry. 865 The Registry MUST upload LORDN files for DNs effectively allocated 866 during the Sunrise or Trademark Claims Period (same applies to DNs 867 effectively allocated using applications created during the Sunrise 868 or Trademark Claims Period in case of using asynchronous 869 registrations). 871 The yd interface (Section 4.3.7) MUST support at least one (1) and 872 MAY support up to ten (10) concurrent connections from each IP 873 address registered by a Registry Operator to access the service. 875 The TMDB MUST process each uploaded LORDN file and make the related 876 log file available for Registry download within 30 minutes of the 877 finalization of the upload. 879 Notification of Registered Domain Name 881 .----------. .------. .-----. .-----. 882 | Registry | | TMDB | | TMV | | TMH | 883 '----------' '------' '-----' '-----' 884 | | | | 885 .------------------. | | | 886 | Periodically | | | | 887 | upload LORDN | | | | 888 | file | | | | 889 '------------------' | | | 890 | | | | 891 .--------->| Upload LORDN | | | 892 | |-------------------->| | | 893 | | | | | 894 | | .-------------------------. | | 895 | | | Verify each domain name | | | 896 | | | in the uploaded file | | | 897 | | | (within 30') | | | 898 | | '-------------------------' | | 899 | | | ._____.| | 900 | | Download Log file | | END || | 901 | |<--------------------| '-----'| | 902 | | | ^ | | 903 | .-----------------. .---------------. | | | 904 | | Check whether | / everything fine \ no | | | 905 | | Log file | ( (i.e. no errors )---' | | 906 | | contains errors | \ in Log file )? / | | 907 | '-----------------' '---------------' | | 908 | | | yes | | 909 | .---------------. | | | 910 | / everything fine \ yes | | | 911 |( (i.e. no errors )-----. | Notify TMVs | | 912 | \ in Log file )? / | | on the LORDN | | 913 | '---------------' | | pre-registered | | 914 | | no v | with said TMV | | 915 | .----------------. .------. |--------------->| | 916 '-| Correct Errors | | DONE | | | | 917 '----------------' '------' | | Notify each | 918 | | | affected TMH | 919 | | |-------------->| 920 | | | | 922 Figure 6 924 The format used for the LORDN is described in Section 6.3 926 5.2.4. Sunrise Domain Name registration by Registrars 928 Registrars MAY choose to perform the checks for verifying DN 929 registrations as performed by the Registries (see Section 5.2.2) 930 before sending the command to register a DN. 932 5.2.5. TMDB Sunrise Services for Registrars 934 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 935 also available for Registrars to optionally validate the SMDs 936 received. 938 5.3. Trademark Claims Period 940 5.3.1. Domain Registration 942 Domain Name registration during the Trademark Claims Period 944 .------------. .-----------. .----------. .------. 945 | Registrant | | Registrar | | Registry | | TMDB | 946 '------------' '-----------' '----------' '------' 947 | Request DN | | | 948 | registration | | | 949 |--------------->| Check DN availability | | 950 | |--------------------------->| | 951 | | DN unavailable .-------------. | 952 | DN unavailable |<-------------------( DN available? ) | 953 |<---------------| no '-------------' | 954 | | DN available | yes | 955 | |<---------------------------| | 956 | | Request Lookup key | | 957 | |--------------------------->| | 958 | |.__________. .---------. | 959 | || CONTINUE | / Does DN \ | 960 | || NORMALLY |<--------( match DNL ) | 961 | |'----------' no \ of PRM? / | 962 | | '---------' | 963 | | Lookup key | yes | 964 | |<----------------------------' | 965 | | | 966 .-----. | | Request TCN | 967 |ABORT| | Display |---------------------------------------->| 968 '-----' | Claims | Return TCN | 969 ^ | Notice |<----------------------------------------| 970 | no |<---------------| | 971 | .------. yes | | 972 '-( Ack? )----------->| Register DN (with TCNID) | | 973 '------' |--------------------------->| | 974 | Registration | Error .----------------------. | 975 | error |<-------------( Validation successful? ) | 976 |<---------------| no '----------------------' | 977 | | | yes | 978 | | DN registered | | 979 | DN registered |<---------------------------| | 980 |<---------------| | | 982 Figure 7 984 Note: the figure depicted above represents a synchronous DN 985 registration workflow (usually called first come first served). 987 5.3.2. Trademark Claims Domain Name registration by Registries 989 During the Trademark Claims Period, Registries perform two main 990 functions: 992 o Registries MUST provide Registrars (over the ry interface, 993 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 994 that match the DNL List. 996 o Registries MUST provide the Lookup Key only when queried about a 997 specific DN. 999 o For each DN matching a DNL of a PRM, Registries MUST perform a 1000 minimum set of checks for verifying DN registrations during the 1001 Trademark Claims Period upon reception of a registration request 1002 over the ry interface (Section 4.3.5). If any of these checks 1003 fails the Registry MUST abort the registration. Each of these 1004 checks MUST be performed before the DN is effectively allocated. 1006 o In case of asynchronous registrations (e.g. auctions), the minimum 1007 set of checks MAY be performed when creating the intermediate 1008 object (e.g. a DN application) used for DN effective allocation. 1009 If the minimum set of checks is performed when creating the 1010 intermediate object (e.g. a DN application) a Registry MAY 1011 effective allocate the DN without performing the minimum set of 1012 checks again. 1014 o Performing the minimum set of checks Registries MUST verify that: 1016 1. The TCNID (), expiration datetime 1017 () and acceptance datetime of the TCN, have 1018 been received from the Registrar along with the DN 1019 registration. 1021 If the three elements mentioned above are not provided by 1022 the Registrar for a DN matching a DNL of a PRM, but the DNL 1023 was inserted (or re-inserted) for the first time into DNL 1024 List less than 24 hours ago, the registration MAY continue 1025 without this data and the tests listed below are not 1026 required to be performed. 1028 2. The TCN has not expired (according to the expiration datetime 1029 sent by the Registrar). 1031 3. The acceptance datetime is no more than 48 hours in the past. 1033 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1034 being registered, the expiration datetime provided by the 1035 Registrar, and the TMDB Notice Identifier extracted from the 1036 TCNID provided by the Registrar compute the TCN Checksum. 1037 Verify that the computed TCN Checksum match the TCN Checksum 1038 present in the TCNID. 1040 These procedures apply to all DN registrations at the second level as 1041 well as to all other levels subordinate to the TLD that the Registry 1042 accepts registrations for. 1044 5.3.3. TMBD Trademark Claims Services for Registries 1046 5.3.3.1. Domain Name Label (DNL) List 1048 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1049 and 12:00:00 UTC. 1051 Registries MUST refresh the latest version of the DNL List at least 1052 once every 24 hours. 1054 Update of the DNL List 1056 .----------. .------. 1057 | Registry | | TMDB | 1058 '----------' '------' 1059 | | 1060 .----------------. | 1061 | Periodically, | | 1062 | at least | | 1063 | every 24 hours | | 1064 '----------------' | 1065 | | 1066 |-------------------------------->| 1067 | Download the latest DNL List | 1068 |<--------------------------------| 1069 | | 1070 | | 1072 Figure 8 1074 Note: the DNL List will be the same regardless of the TLD. If a 1075 Backend Registry Operator manages the infrastructure of several TLDs, 1076 the Backend Registry Operator could refresh the DNL List once every 1077 24 hours, the DNL List could be used for all the TLDs managed by the 1078 Backend Registry Operator. 1080 5.3.3.2. Notice of Registered Domain Names (NORN) 1082 The NORDN process during the Trademark Claims Period is almost the 1083 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1084 difference that only registrations subject to a Trademark Claim 1085 (i.e., at registration time the name appeared in the current DNL List 1086 downloaded by the Registry Operator) are included in the LORDN. 1088 5.3.4. Trademark Claims Domain Name registration by Registrars 1090 For each DN matching a DNL of a PRM, Registrars MUST perform the 1091 following steps: 1093 1. Use the Lookup Key received from the Registry to obtain the TCN 1094 from the TMDB using the dr interface (Section 4.3.6) Registrars 1095 MUST only query for the Lookup Key of a DN that is available for 1096 registration. 1098 2. Present the TCN to the Registrant as described in Exhibit A, 1099 [RPM-Requirements]. 1101 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1102 consent with the TCN, before any further processing. (The 1103 transmission of a TCNID to the Registry over the ry interface, 1104 Section 4.3.5 implies that the Registrant has expressed his/her 1105 consent with the TCN.) 1107 4. Perform the minimum set of checks for verifying DN registrations. 1108 If any of these checks fails the Registrar MUST abort the DN 1109 registration. Each of these checks MUST be performed before the 1110 registration is sent to the Registry. Performing the minimum set 1111 of checks Registrars MUST verify that: 1113 1. The datetime when the validation is done is within the TCN 1114 validity based on the and 1115 elements. 1117 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1118 effectively allocated matches the label () 1119 element in the TCN. 1121 3. The Registrant has acknowledged (expressed his/her consent 1122 with) the TCN. 1124 5. Record the date and time when the registrant acknowledged the 1125 TCN. 1127 6. Send the registration to the Registry (ry interface, 1128 Section 4.3.5) and include the following information: 1130 * TCNID () 1132 * Expiration date of the TCN () 1134 * Acceptance datetime of the TCN. 1136 TCN are generated twice a day. The expiration date 1137 () of each TCN MUST be set to 48 hours in the 1138 future by the TMDB, allowing the implementation of a cache by 1139 Registrars and enough time for acknowledging the TCN. Registrars 1140 SHOULD implement a cache of TCNs to minimize the number of queries 1141 sent to the TMDB. A cached TCN MUST be removed from the cache after 1142 the expiration date of the TCN as defined by . 1143 The TMDB MAY implement rate-limiting as one of the protection 1144 mechanisms to mitigate the risk of performance degradation. 1146 5.3.5. TMBD Trademark Claims Services for Registrars 1148 5.3.5.1. Claims Notice Information Service (CNIS) 1150 The TCNs are provided by the TMDB online and are fetched by the 1151 Registrar via the dr interface (Section 4.3.6). 1153 To get access to the TCNs, the Registrar needs the credentials 1154 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1155 from the Registry via the ry interface (Section 4.3.5). The dr 1156 interface (Section 4.3.6) uses HTTPS with Basic access 1157 authentication. 1159 The dr interface (Section 4.3.6) MAY support up to ten (10) 1160 concurrent connections from each Registrar. 1162 The URL of the dr interface (Section 4.3.6) is: 1164 < https:///cnis/.xml > 1166 Note that the "lookupkey" may contain SLASH characters ("/"). The 1167 SLASH character is part of the URL path and MUST NOT be escaped when 1168 requesting the TCN. 1170 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1171 MUST be signed by a well-know public CA. Registrars MUST perform the 1172 Certification Path Validation described in Section 6 of [RFC5280]. 1173 Registrars will be authenticated in the dr interface using HTTP Basic 1174 access authentication. The dr (Section 4.3.6) interface MUST support 1175 HTTPS keep-alive and MUST maintain the connection for up to 30 1176 minutes. 1178 5.4. Qualified Launch Program (QLP) Period 1180 5.4.1. Domain Registration 1182 During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program 1183 (QLP) Period effective allocations of DNs to third parties could 1184 require that Registries and Registrars provide Sunrise and/or 1185 Trademark Claims services. If required, Registries and Registrars 1186 MUST provide Sunrise and/or Trademark Claims services as described in 1187 Section 5.2 and Section 5.3. 1189 The effective allocation scenarios are: 1191 o If the leftmost DNL (A-label in case of IDNs) of the DN being 1192 effectively allocated (QLP Name in this section) matches a DNL in 1193 the SURL, and an SMD is provided, then Registries MUST provide 1194 Sunrise Services (see Section 5.2) and the DN MUST be reported in 1195 a Sunrise LORDN file during the QLP Period. 1197 o If the QLP Name matches a DNL in the SURL but does not match a DNL 1198 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1199 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN 1200 file using the special SMD-id "99999-99999" during the QLP Period. 1202 o If the QLP Name matches a DNL in the SURL and also matches a DNL 1203 in the DNL List, and an SMD is NOT provided (see section 2.2 of 1204 [QLP-Addendum]), then Registries MUST provide Trademark Claims 1205 services (see Section 5.3) and the DN MUST be reported in a 1206 Trademark Claims LORDN file during the QLP Period. 1208 o If the QLP Name matches a DNL in the DNL List but does not match a 1209 DNL in the SURL, then Registries MUST provide Trademark Claims 1210 services (see Section 5.2) and the DN MUST be reported in a 1211 Trademark Claims LORDN file during the QLP Period. 1213 The following table lists all the effective allocation scenarios 1214 during a QLP Period: 1216 +--------+---------+-----------------+--------------+---------------+ 1217 | QLP | QLP | SMD was | Registry | Registry MUST | 1218 | Name | Name | provided by the | MUST provide | report DN | 1219 | match | match | potential | Sunrise or | registration | 1220 | in the | in the | Registrant | Trademark | in | 1221 | SURL | DNL | | Claims | LORDN file | 1222 | | List | | Services | | 1223 +--------+---------+-----------------+--------------+---------------+ 1224 | Y | Y | Y | Sunrise | Sunrise | 1225 | | | | | | 1226 | Y | N | Y | Sunrise | Sunrise | 1227 | | | | | | 1228 | N | Y | -- | Trademark | Trademark | 1229 | | | | Claims | Claims | 1230 | | | | | | 1231 | N | N | -- | -- | -- | 1232 | | | | | | 1233 | Y | Y | N (see section | Trademark | Trademark | 1234 | | | 2.2 of | Claims | Claims | 1235 | | | [QLP-Addendum]) | | | 1236 | | | | | | 1237 | Y | N | N (see section | -- | Sunrise | 1238 | | | 2.2 of | | (using | 1239 | | | [QLP-Addendum]) | | special SMD- | 1240 | | | | | id) | 1241 +--------+---------+-----------------+--------------+---------------+ 1243 QLP Effective Allocation Scenarios 1245 The TMDB MUST provide the following services to Registries during a 1246 QLP Period: 1248 o SMD Revocation List (see Section 5.2.3.1) 1250 o NORN (see Section 5.2.3.3) 1252 o DNL List (see Section 5.3.3.1) 1254 o Sunrise List (SURL) (see Section 5.4.2.1 1256 The TMDB MUST provide the following services to Registrars during a 1257 QLP Period: 1259 o SMD Revocation List (see Section 5.2.3.1) 1260 o CNIS (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 (SURL) MUST be published by the TMDB twice a day, 1267 by 00:00:00 and 12:00:00 UTC. 1269 Registries offering the OPTIONAL QLP Period MUST refresh the latest 1270 version of the SURL at least once every 24 hours. 1272 Update of the SURL 1274 .----------. .------. 1275 | Registry | | TMDB | 1276 '----------' '------' 1277 | | 1278 .----------------. | 1279 | Periodically, | | 1280 | at least | | 1281 | every 24 hours | | 1282 '----------------' | 1283 | | 1284 |------------------------------->| 1285 | Download the latest SURL | 1286 |<-------------------------------| 1287 | | 1288 | | 1290 Figure 9 1292 Note: the SURL will be the same regardless of the TLD. If a Backend 1293 Registry Operator manages the infrastructure of several TLDs, the 1294 Backend Registry Operator could refresh the SURL once every 24 hours, 1295 the SURL could be used for all the TLDs managed by the Backend 1296 Registry Operator. 1298 6. Data Format Descriptions 1300 6.1. Domain Name Label (DNL) List 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 datetime it is generated. 1312 The DNL List is contained in a CSV 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 of a 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 (see also Section 5.1.1.4). The 1380 PGP signature of the DNL List can be found in the similar URI but 1381 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 TMDB 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]. 1398 The SMD Revocation List contains all the revoked SMDs present in the 1399 TMDB at the datetime it is generated. 1401 The SMD Revocation List is contained in a CSV formatted file that has 1402 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 signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation 1431 List is provided by the TMDB with extension .csv. The PGP signature 1432 of the SMD Revocation List can be found in the similar URI but with 1433 extension .sig as shown below. 1435 The URL of the sr interface (Section 4.3.12) and sy interface 1436 (Section 4.3.11) is: 1438 o < https:///smdrl/smdrl-latest.csv > 1440 o < https:///smdrl/smdrl-latest.sig > 1441 Example of an SMD Revocation List 1443 1,2012-08-16T00:00:00.0Z 1444 smd-id,insertion-datetime 1445 2-2,2012-08-15T00:00:00.0Z 1446 3-2,2012-08-15T00:00:00.0Z 1447 1-2,2012-08-15T00:00:00.0Z 1449 Figure 11 1451 6.3. List of Registered Domain Names (LORDN) file 1453 This section defines the format of the List of Registered Domain 1454 Names (LORDN), which is maintained by each Registry and uploaded at 1455 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1456 said DN is added to the LORDN along with further information related 1457 to its registration. 1459 The URIs of the yd interface (Section 4.3.7) used to upload the LORDN 1460 file is: 1462 o Sunrise LORDN file: 1464 < https:///LORDN//sunrise > 1466 o Trademark Claims LORDN file: 1468 < https:///LORDN//claims > 1470 During a QLP Period, Registries MAY be required to upload Sunrise or 1471 Trademark Claims LORDN files. The URIs of the yd interface used to 1472 upload LORDN files during a QLP Period is: 1474 o Sunrise LORDN file (during QLP Period): 1476 < https:///LORDN//sunrise/qlp > 1478 o Trademark Claims LORDN file (during a QLP Period): 1480 < https:///LORDN//claims/qlp > 1482 The yd interface (Section 4.3.7) returns the following HTTP status 1483 codes after a HTTP POST request method is received: 1485 o The interface provides a HTTP/202 status code if the interface was 1486 able to receive the LORDN file and the syntax of the LORDN file is 1487 correct. 1489 The interface provides the LORDN Transaction Identifier in the 1490 HTTP Entity-body that would be used by the Registry to download 1491 the LORDN Log file. The LORDN Transaction Identifier is a 1492 natural number zero-padded in the range 0000000000000000001 to 1493 9223372036854775807. 1495 The TMDB uses the element of the 1496 LORDN file as a unique client-side identifier. If a LORDN file 1497 with the same of a previously sent 1498 LORDN file is received by the TMDB, the LORDN Transaction 1499 Identifier of the previously sent LORDN file MUST be provided 1500 to the Registry. The TMDB MUST ignore the DN Lines present in 1501 the LORDN file if a LORDN file with the same was previously sent. 1504 The HTTP Location header field contains the URI where the LORDN 1505 Log file could be retrieved later, for example: 1507 202 Accepted 1509 Location: https:///LORDN/example/sunrise/0000000000000000001/result 1512 o The interface provides a HTTP/400 if the request is incorrect or 1513 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1514 human readable message in the HTTP Entity-body regarding the 1515 incorrect syntax of the LORDN file. 1517 o The interface provides a HTTP/401 status code if the credentials 1518 provided does not authorize the Registry Operator to upload a 1519 LORDN file. 1521 o The TMDB MUST return a HTTP/404 status code when trying to upload 1522 a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period 1525 plus 26 hours. 1527 o The interface provides a HTTP/500 status code if the system is 1528 experiencing a general failure. 1530 For example, to upload the Sunrise LORDN file for TLD "example", the 1531 URI would be: 1533 < https:///LORDN/example/sunrise > 1535 The LORDN is contained in a CSV formatted file that has the following 1536 structure: 1538 o For Sunrise Period: 1540 * first line: ,, 1543 Where: 1545 - , version of the file, this field MUST be 1. 1547 - , date and time in UTC that the 1548 LORDN was created. 1550 - , number of DN Lines present in the 1551 LORDN file. 1553 * second line: a header line as specified in [RFC4180] 1555 With the header names as follows: 1557 roid,domain-name,SMD-id,registrar-id,registration- 1558 datetime,application-datetime 1560 * One or more lines with: ,,,,, 1564 Where: 1566 - , DN Repository Object IDentifier (DNROID) in the 1567 SRS. 1569 - , DN that was effectively allocated. For 1570 IDNs the A-Label (see [RFC5890]) is used. 1572 - , SMD ID used for registration. 1574 - , IANA Registrar ID. 1576 - , date and time in UTC that the 1577 domain was effectively allocated. 1579 - OPTIONAL , date and 1580 time in UTC that the application was created. The 1581 MUST be provided in 1582 case of a DN effective allocation based on an 1583 asynchronous registration (e.g., when using auctions). 1585 Example of a Sunrise LORDN file 1587 1,2012-08-16T00:00:00.0Z,3 1588 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1589 application-datetime 1590 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1591 2012-07-15T00:50:00.0Z 1592 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1593 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1595 Figure 12 1597 o For Trademark Claims Period: 1599 * first line: ,, 1602 Where: 1604 - , version of the file, this field MUST be 1. 1606 - , date and time in UTC that the 1607 LORDN was created. 1609 - , number of DN Lines present in the 1610 LORDN file. 1612 * second line: a header line as specified in [RFC4180] 1614 With the header names as follows: 1616 roid,domain-name,notice-id,registrar-id,registration- 1617 datetime,ack-datetime,application-datetime 1619 * One or more lines with: ,,,,,, 1623 Where: 1625 - , DN Repository Object IDentifier (DNROID) in the 1626 SRS. 1628 - , DN that was effectively allocated. For 1629 IDNs the A-Label is used. 1631 - , Trademark Claims Notice Identifier as specified 1632 in . 1634 - , IANA Registrar ID. 1636 - , date and time in UTC that the 1637 domain was effectively allocated. 1639 - , date and time in UTC 1640 that the TCN was acknowledged. 1642 - OPTIONAL , date and 1643 time in UTC that the application was created. The 1644 MUST be provided in 1645 case of a DN effective allocation based on an 1646 asynchronous registration (e.g., when using auctions). 1648 For a DN matching a DNL of a PRM at the moment of 1649 registration, created without the TCNID, expiration datetime 1650 and acceptance datetime, because DNL was inserted (or re- 1651 inserted) for the first time into DNL List less than 24 1652 hours ago, the string "recent-dnl-insertion" MAY be 1653 specified in and . 1656 Example of a Trademark Claims LORDN file 1658 1,2012-08-16T00:00:00.0Z,3 1659 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1660 ack-datetime,application-datetime 1661 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1662 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1663 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1664 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1665 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1666 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1668 Figure 13 1670 6.3.1. LORDN Log file 1672 After reception of the LORDN file, the TMDB verifies its content for 1673 syntactical and semantical correctness. The output of the LORDN file 1674 verification is retrieved using the yd interface (Section 4.3.7). 1676 The URI of the yd interface (Section 4.3.7) used to retrieve the 1677 LORDN Log file is: 1679 o Sunrise LORDN Log file: 1681 < https:///LORDN//sunrise//result > 1684 o Trademark Claims LORDN Log file: 1686 < https:///LORDN//claims//result > 1689 A Registry Operator MUST NOT send more than one request per minute 1690 per TLD to download a LORDN Log file. 1692 The yd interface (Section 4.3.7) returns the following HTTP status 1693 codes after a HTTP GET request method is received: 1695 o The interface provides a HTTP/200 status code if the interface was 1696 able to provide the LORDN Log file. The LORDN Log file is 1697 contained in the HTTP Entity-body. 1699 o The interface provides a HTTP/204 status code if the LORDN 1700 Transaction Identifier is correct, but the server has not 1701 finalized processing the LORDN file. 1703 o The interface provides a HTTP/400 status code if the request is 1704 incorrect. 1706 o The interface provides a HTTP/401 status code if the credentials 1707 provided does not authorize the Registry Operator to download the 1708 LORDN Log file. 1710 o The interface provides a HTTP/404 status code if the LORDN 1711 Transaction Identifier is incorrect. 1713 o The interface provides a HTTP/500 status code if the system is 1714 experiencing a general failure. 1716 For example, to obtain the LORDN Log file in case of a Sunrise LORDN 1717 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1718 "example" the URI would be: 1720 < https:///LORDN/example/sunrise/0000000000000000001/result > 1723 The LORDN Log file is contained in a CSV formatted file that has the 1724 following structure: 1726 o first line: ,,,,,, 1730 Where: 1732 + , version of the file, this field MUST be 1. 1734 + , date and time in UTC that the 1735 LORDN Log was created. 1737 + , date and time in UTC of 1738 creation for the LORDN file that this log file is referring 1739 to. 1741 + , unique identifier of the LORDN Log 1742 provided by the TMDB. This identifier could be used by the 1743 Registry Operator to unequivocally identify the LORDN Log. 1744 The identified will be a string of a maximum LENGTH of 60 1745 characters from the Base 64 alphabet. 1747 + , whether the LORDN file has been accepted for 1748 processing by the TMDB. Possible values are "accepted" or 1749 "rejected". 1751 + , whether the LORDN Log has any warning result 1752 codes. Possible values are "no-warnings" or "warnings- 1753 present". 1755 + , number of DNs effective allocations 1756 processed in the LORDN file. 1758 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1759 a ="accepted" and ="no-warnings". 1761 o second line: a header line as specified in [RFC4180] 1763 With the header names as follows: 1765 roid,result-code 1767 o One or more lines with: , 1769 Where: 1771 + , DN Repository Object IDentifier (DNROID) in the SRS. 1773 + , result code as described in Section 6.3.1.1. 1775 Example of a LORDN Log file 1777 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1778 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1779 accepted,no-warnings,1 1780 roid,result-code 1781 SH8013-REP,2000 1783 Figure 14 1785 6.3.1.1. LORDN Log Result Codes 1787 In Figure 15 the classes of result codes (rc) are listed. Those 1788 classes in square brackets are not used at this time, but may come 1789 into use at some later stage. The first two digits of a result code 1790 denote the result code class, which defines the outcome at the TMDB: 1792 o ok: Success, DN Line accepted by the TMDB. 1794 o warn: a warning is issued, DN Line accepted by the TMDB. 1796 o err: an error is issued, LORDN file rejected by the TMDB. 1798 In case that after processing a DN Line, the error result code is 1799 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1800 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1801 valid will be reported with a 2001 result code. A 2001 result code 1802 means that the DN Line is syntactically valid, however the DN Line 1803 was not processed because the LORDN file was rejected. All DNs 1804 reported in a rejected LORDN file MUST be reported again by the 1805 Registry because none of the DN Lines present in the LORDN file have 1806 been processed by the TMDB. 1808 LORDN Log Result Code Classes 1810 code Class outcome 1811 ---- ----- ------- 1813 20xx Success ok 1815 35xx [ DN Line syntax warning ] warn 1816 36xx DN Line semantic warning warn 1818 45xx DN Line syntax error err 1819 46xx DN Line semantic error err 1821 Figure 15 1823 In the following, the LORDN Log result codes used by the TMDB are 1824 described: 1826 LORDN Log result Codes 1828 rc Short Description 1829 Long Description 1830 ---- ------------------------------------------------------------- 1832 2000 OK 1833 DN Line successfully processed. 1835 2001 OK but not processed 1836 DN Line is syntactically correct but was not processed 1837 because the LORDN file was rejected. 1839 3601 TCN Acceptance Date after Registration Date 1840 TCN Acceptance Date in DN Line is newer than the Registration 1841 Date. 1843 3602 Duplicate DN Line 1844 This DN Line is an exact duplicate of another DN Line in same 1845 file, DN Line ignored. 1847 3603 DNROID Notified Earlier 1848 Same DNROID has been notified earlier, DN Line ignored. 1850 3604 TCN Checksum invalid 1851 Based on the DN effectively allocated, the TCNID and the 1852 expiration date of the linked TCN, the TCN Checksum is 1853 invalid. 1855 3605 TCN Expired 1856 The TCN was already expired (based on the 1857 field of the TCN) at the datetime of acknowledgement. 1859 3606 Wrong TCNID used 1860 The TCNID used for the registration does not match 1861 the related DN. 1863 3609 Invalid SMD used 1864 The SMD used for registration was not valid at the moment of 1865 registration based on the and 1866 elements. 1867 In case of an asynchronous registration, this refer to the 1868 . 1870 3610 DN reported outside of the time window 1871 The DN was reported outside of the required 26 hours 1872 reporting window. 1874 3611 DN does not match the labels in SMD 1875 The DN does not match the labels included in the SMD. 1877 3612 SMDID does not exist 1878 The SMDID has never existed in the central repository. 1880 3613 SMD was revoked when used 1881 The SMD used for registration was revoked more than 1882 24 hours ago of the . 1883 In case of an asynchronous registration, 1884 the is used when 1885 validating the DN Line. 1887 3614 TCNID does not exist 1888 The TCNID has never existed in the central repository. 1890 3615 Recent-dnl-insertion outside of the time window 1891 The DN registration is reported as a recent-dnl-insertion, 1892 but the (re) insertion into the DNL occurred more than 1893 24 hours ago. 1895 3616 Registration Date of DN in Claims before the end of Sunrise Period 1896 The registration date of the DN is before the end of Sunrise Period 1897 and the DN was reported in a Trademark Claims LORDN file. 1899 3617 Registrar has not been approved by the TMDB 1900 Registrar ID in DN Line has not completed Trademark Claims integration 1901 testing with the TMDB. 1903 3618 Registration Date of DN in a QLP LORDN file outside of the QLP Period 1904 The registration date of the DN in a QLP LORDN file is outside 1905 of the QLP Period. 1907 3619 TCN was not valid 1908 The TCN was not valid (based on the 1909 field of the TCN) at the datetime of acknowledgement. 1911 4501 Syntax Error in DN Line 1912 Syntax Error in DN Line. 1914 4601 Invalid TLD used 1915 The TLD in the DN Line does not match what is expected for 1916 this LORDN. 1918 4602 Registrar ID Invalid 1919 Registrar ID in DN Line is not a valid ICANN-Accredited 1920 Registrar. 1922 4603 Registration Date in the future 1923 The in the DN Line is in the 1924 future. 1926 4606 TLD not in Sunrise or Trademark Claims Period 1927 The was reported when the TLD was 1928 not in Sunrise or Trademark Claims Periods. 1929 In case of an asynchronous registration, 1930 the is used when 1931 validating the DN Line. 1933 4607 Application Date in the future 1934 The in the DN Line is in the 1935 future. 1937 4608 Application Date is later than Registration Date 1938 The in the DN Line is later 1939 than the . 1941 4609 TCNID wrong syntax 1942 The syntax of the TCNID is invalid. 1944 4610 TCN Acceptance Date is in the future 1945 The is in the future. 1947 4611 Label has never existed in the TMDB 1948 The label in the registered DN has never existed in the TMDB. 1950 Figure 16 1952 6.4. Signed Mark Data (SMD) File 1954 This section defines the format of the Signed Mark Data (SMD) File. 1955 After a successful registration of a mark, the TMV returns an SMD 1956 File to the TMH. The SMD File can then be used for registration of 1957 one or more DNs covered by the PRM during the Sunrise Period of a 1958 TLD. 1960 Two encapsulation boundaries are defined for delimiting the 1961 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1962 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1963 boundaries MUST be used by Registries and Registrars for validation 1964 purposes, i.e. any data outside these boundaries as well as the 1965 boundaries themselves MUST be ignored for validation purposes. 1967 The structure of the SMD File is as follows, all the elements are 1968 REQUIRED, and MUST appear in the specified order. 1970 1. Marks: 1972 2. smdID: 1974 3. U-labels: 1977 4. notBefore: 1979 5. notAfter: 1981 6. -----BEGIN ENCODED SMD----- 1983 7. 1985 8. -----END ENCODED SMD----- 1986 Example of an SMD File: 1988 Marks: Example One 1989 smdID: 1-2 1990 U-labels: example-one, exampleone 1991 notBefore: 2011-08-16 09:00 1992 notAfter: 2012-08-16 09:00 1993 -----BEGIN ENCODED SMD----- 1994 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1995 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1996 ... (base64 data elided for brevity) ... 1997 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1998 -----END ENCODED SMD----- 2000 Figure 17 2002 6.5. Trademark Claims Notice (TCN) 2004 The TMDB MUST provide the TCN to Registrars in XML format as 2005 specified below. 2007 An enclosing element that describes the Trademark 2008 Notice to a given label. 2010 The child elements of the element include: 2012 o A element that contains the unique identifier of the 2013 Trademark Notice. This element contains the the TCNID. 2015 The TCNID is a string concatenation of a TCN Checksum and the 2016 TMDB Notice Identifier. The first 8 characters of the TCNID is 2017 a TCN Checksum. The rest is the TMDB Notice Identifier, which 2018 is a zero-padded natural number in the range of 2019 0000000000000000001 to 9223372036854775807. 2021 Example of a TCNID: 2023 370d0b7c9223372036854775807. 2025 Where: 2027 + TCN Checksum=370d0b7c 2029 + TMDB Notice Identifier=9223372036854775807 2030 The TCN Checksum is a 8 characters long Base16 encoded output 2031 of computing the CRC32 of the string concatenation of: label + 2032 unix_timestamp() + TMDB Notice Identifier 2034 TMDB MUST use the Unix time conversion of the 2035 in UTC to calculate the TCN Checksum. Unix 2036 time is defined as the number of seconds that have elapsed 2037 since 1970-01-01T00:00:00Z not counting leap seconds. For 2038 example, the conversion to Unix time of 2010-08-16T09:00:00.0Z 2039 is shown: 2041 unix_time(2010-08-16T09:00:00.0Z)=1281949200 2043 The TMDB uses the and 2044 elements from the TCN along with the TMDB Notice Identifier to 2045 compute the TCN Checksum. 2047 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 2048 of the DN being registered, the expiration datetime of the TCN 2049 (provided by the Registrar) and the TMDB Notice Identifier 2050 extracted from the TCNID (provided by the Registrar) to compute 2051 the TCN Checksum. For example the DN "foo.bar.example" being 2052 effectively allocated, the left most label would be "foo". 2054 Example of computation of the TCN Checksum: 2056 CRC32(example-one12819492009223372036854775807)=370d0b7c 2058 o A element that contains the start of the 2059 validity date and time of the TCN. 2061 o A element that contains the expiration date 2062 and time of the TCN. 2064 o A elements that contain the DNL (A-label in case 2065 of IDNs) form of the label that correspond to the DN covered by a 2066 PRM. 2068 o One or more elements that contain the Trademark 2069 Claim. The element contains the following child 2070 elements: 2072 * A element that contains the mark text 2073 string. 2075 * One or more elements that contains the 2076 information of the holder of the mark. An "entitlement" 2077 attribute is used to identify the entitlement of the holder, 2078 possible values are: owner, assignee or licensee. The child 2079 elements of include: 2081 + An OPTIONAL element that contains the name 2082 of the holder. A MUST be specified if 2083 is not specified. 2085 + An OPTIONAL element that contains the name of 2086 the organization holder of the mark. A MUST 2087 be specified if is not specified. 2089 + A element that contains the address 2090 information of the holder of a mark. A 2091 contains the following child elements: 2093 - One, two or three OPTIONAL elements 2094 that contains the organization's street address. 2096 - A element that contains the 2097 organization's city. 2099 - An OPTIONAL element that contains the 2100 organization's state or province. 2102 - An OPTIONAL element that contains the 2103 organization's postal code. 2105 - A element that contains the organization's 2106 country code. This a two-character code from 2107 [ISO3166-2]. 2109 + An OPTIONAL element that contains the 2110 organization's voice telephone number. 2112 + An OPTIONAL element that contains the 2113 organization's facsimile telephone number. 2115 + An OPTIONAL element that contains the email 2116 address of the holder. 2118 * Zero or more OPTIONAL elements that contains 2119 the information of the representative of the mark registration. 2120 A "type" attribute is used to identify the type of contact, 2121 possible values are: owner, agent or thirdparty. The child 2122 elements of include: 2124 + A element that contains name of the 2125 responsible person. 2127 + An OPTIONAL element that contains the name of 2128 the organization of the contact. 2130 + A element that contains the address 2131 information of the contact. A contains the 2132 following child elements: 2134 - One, two or three OPTIONAL elements 2135 that contains the contact's street address. 2137 - A element that contains the contact's 2138 city. 2140 - An OPTIONAL element that contains the 2141 contact's state or province. 2143 - An OPTIONAL element that contains the 2144 contact's postal code. 2146 - A element that contains the contact's 2147 country code. This a two-character code from 2148 [ISO3166-2]. 2150 + A element that contains the contact's voice 2151 telephone number. 2153 + An OPTIONAL element that contains the 2154 contact's facsimile telephone number. 2156 + A element that contains the contact's email 2157 address. 2159 * A element that contains the name (in 2160 English) of the jurisdiction where the mark is protected. A 2161 jurCC attribute contains the two-character code of the 2162 jurisdiction where the mark was registered. This is a two- 2163 character code from [WIPO.ST3]. 2165 * Zero or more OPTIONAL element that 2166 contains the description (in English) of the Nice 2167 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2168 attribute contains the class number. 2170 * A element that contains the full 2171 description of the goods and services mentioned in the mark 2172 registration document. 2174 * An OPTIONAL element signals that the 2175 claim notice was added to the TCN based on other rule (e.g. 2176 [Claims50] ) than exact match (defined in [MatchingRules]). 2177 The contains one or more: 2179 + An OPTIONAL element that signals that the 2180 claim notice was added because of a previously abused name 2181 included in an UDRP case. The contains: 2183 - A element that contains the UDRP case 2184 number used to validate the previously abused name. 2186 - A element that contains the name 2187 of the UDRP provider. 2189 + An OPTIONAL element that signals that the 2190 claim notice was added because of a previously abused name 2191 included in a court's resolution. The 2192 contains: 2194 - A element that contains the reference 2195 number of the court's resolution used to validate the 2196 previously abused name. 2198 - A element that contains the two-character 2199 code from [ISO3166-2] of the jurisdiction of the court. 2201 - A element that contains the name of 2202 the court. 2204 Example of a object: 2206 2207 2208 370d0b7c9223372036854775807 2209 2010-08-14T09:00:00.0Z 2210 2010-08-16T09:00:00.0Z 2211 example-one 2212 2213 Example One 2214 2215 Example Inc. 2216 2217 123 Example Dr. 2218 Suite 100 2219 Reston 2220 VA 2221 20190 2222 US 2223 2224 2225 2226 Joe Doe 2227 Example Inc. 2228 2229 123 Example Dr. 2230 Suite 100 2231 Reston 2232 VA 2233 20190 2234 US 2235 2236 +1.7035555555 2237 jdoe@example.com 2238 2239 UNITED STATES OF AMERICA 2240 2241 Advertising; business management; business administration. 2242 2243 2244 Insurance; financial affairs; monetary affairs; real estate. 2245 2246 2247 Bardus populorum circumdabit se cum captiosus populum. 2248 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2249 2250 2251 2252 Example-One 2253 2254 Example S.A. de C.V. 2255 2256 Calle conocida #343 2257 Conocida 2258 SP 2259 82140 2260 BR 2261 2262 2263 BRAZIL 2264 2265 Bardus populorum circumdabit se cum captiosus populum. 2266 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2267 2268 2269 2270 One 2271 2272 One Corporation 2273 2274 Otra calle 2275 Otra ciudad 2276 OT 2277 383742 2278 CR 2279 2280 2281 COSTA RICA 2282 2283 Bardus populorum circumdabit se cum captiosus populum. 2284 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2285 2286 2287 2288 234235 2289 CR 2290 Supreme Court of Justice of Costa Rica 2291 2292 2293 2294 2295 One Inc 2296 2297 One SA de CV 2298 2299 La calle 2300 La ciudad 2301 CD 2302 34323 2303 AR 2304 2305 2306 ARGENTINA 2307 2308 Bardus populorum circumdabit se cum captiosus populum. 2309 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2310 2311 2312 2313 D2003-0499 2314 WIPO 2315 2316 2318 2319 2321 For the formal syntax of the TCN please refer to Section 7.1. 2323 6.6. Sunrise List (SURL) 2325 This section defines the format of the list containing every Domain 2326 Name Label (DNL) that matches a PRM eligible for Sunrise. The list 2327 is maintained by the TMDB and downloaded by Registries in regular 2328 intervals (see Section 5.4.2.1). The Registries use the Sunrise List 2329 during the Qualified Launch Program Period to check whether a 2330 requested DN matches a DNL of a PRM eligible for Sunrise. 2332 The Sunrise List contains all the DNLs covered by a PRM eligible for 2333 Sunrise present in the TMDB at the datetime it is generated. 2335 The Sunrise List is contained in a CSV formatted file that has the 2336 following structure: 2338 o first line: , 2340 Where: 2342 + , version of the file, this field MUST be 1. 2344 + , date and time in UTC that 2345 the Sunrise List was created. 2347 o second line: a header line as specified in [RFC4180] 2349 With the header names as follows: 2351 DNL,insertion-datetime 2353 o One or more lines with: , 2355 Where: 2357 + , a Domain Name Label covered by a PRM eligible for 2358 Sunrise. 2360 + , datetime in UTC that the DNL was 2361 first inserted into the Sunrise List. The possible two 2362 values of time for inserting a DNL to the Sunrise List are 2363 00:00:00 and 12:00:00 UTC. 2365 Example of a SURL 2367 1,2012-08-16T00:00:00.0Z 2368 DNL,insertion-datetime 2369 example,2010-07-14T00:00:00.0Z 2370 another-example,2012-08-16T00:00:00.0Z 2371 anotherexample,2011-08-16T12:00:00.0Z 2373 Figure 18 2375 To provide authentication and integrity protection, the Sunrise List 2376 will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP 2377 signature of the Sunrise List can be found in the similar URI but 2378 with extension .sig as shown below. 2380 The URL of the dy interface (Section 4.3.3) is: 2382 o < https:///dnl/surl-latest.csv > 2384 o < https:///dnl/surl-latest.sig > 2386 7. Formal Syntax 2388 7.1. Trademark Claims Notice (TCN) 2390 The schema presented here is for a Trademark Claims Notice. 2392 The BEGIN and END tags are not part of the schema; they are used to 2393 note the beginning and ending of the schema for URI registration 2394 purposes. 2396 Copyright (c) 2016 IETF Trust and the persons identified as authors 2397 of the code. All rights reserved. 2399 Redistribution and use in source and binary forms, with or without 2400 modification, is permitted pursuant to, and subject to the license 2401 terms contained in, the Simplified BSD License set forth in 2402 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 2403 Documents (http://trustee.ietf.org/license-info). 2405 BEGIN 2406 2407 2412 2413 2414 Schema for representing a Trademark Claim Notice. 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2438 2439 2440 2441 2442 2443 2445 2447 2448 2450 2451 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 END 2518 8. Acknowledgements 2520 This specification is a collaborative effort from several 2521 participants in the ICANN community. Bernie Hoeneisen participated 2522 as co-author until version 02 providing invaluable support for this 2523 document. This specification is based on a model spearheaded by: 2524 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2525 would also like to thank the thoughtful feedbak provided by many in 2526 the tmch-tech mailing list, but particularly the extensive help 2527 provided by James Gould, James Mitchell and Francisco Arias. This 2528 document includes feedback received from the following individuals: 2529 Paul Hoffman. 2531 9. IANA Considerations 2533 This document uses URNs to describe XML namespaces and XML schemas 2534 conforming to a registry mechanism described in [RFC3688]. One URI 2535 assignment have been registered by the IANA. 2537 Registration request for the Trademark Claims Notice: 2539 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2541 Registrant Contact: See the "Author's Address" section of this 2542 document. 2544 XML: None. Namespace URIs do not represent an XML specification. 2546 10. Security Considerations 2548 This specification uses HTTP Basic Authentication to provide a simple 2549 application-layer authentication service. HTTPS is used in all 2550 interfaces in order to protect against most common attacks. In 2551 addition, the client identifier is tied to a set of IP addresses that 2552 are allowed to connect to the interfaces described in this document, 2553 providing an extra security measure. 2555 The TMDB MUST provide credentials to the appropriate Registries and 2556 Registrars. 2558 The TMDB MUST require the use of strong passwords by Registries and 2559 Registrars. 2561 The TMDB, Registries and Registrars MUST use the best practices 2562 described in RFC 7525 or its successors. 2564 11. References 2566 11.1. Normative References 2568 [I-D.ietf-eppext-tmch-smd] 2569 Lozano, G., "Mark and Signed Mark Objects Mapping", draft- 2570 ietf-eppext-tmch-smd-06 (work in progress), March 2016. 2572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2573 Requirement Levels", BCP 14, RFC 2119, 2574 DOI 10.17487/RFC2119, March 1997, 2575 . 2577 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2578 DOI 10.17487/RFC3688, January 2004, 2579 . 2581 11.2. Informative References 2583 [Claims50] 2584 ICANN, "Implementation Notes: Trademark Claims Protection 2585 for Previously Abused Names", July 2013, 2586 . 2589 [ICANN-GTLD-AGB-20120604] 2590 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2591 2012, . 2594 [ISO3166-2] 2595 ISO, "International Standard for country codes and codes 2596 for their subdivisions", 2006, 2597 . 2599 [MatchingRules] 2600 ICANN, "Memorandum on Implementing Matching Rules", 2601 September 2012, . 2604 [QLP-Addendum] 2605 ICANN, "Qualified Launch Program Addendum", April 2014, 2606 . 2610 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2611 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2612 Transfer Protocol -- HTTP/1.1", RFC 2616, 2613 DOI 10.17487/RFC2616, June 1999, 2614 . 2616 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2617 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2618 Authentication: Basic and Digest Access Authentication", 2619 RFC 2617, DOI 10.17487/RFC2617, June 1999, 2620 . 2622 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2623 DOI 10.17487/RFC2818, May 2000, 2624 . 2626 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2627 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2628 . 2630 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2631 Separated Values (CSV) Files", RFC 4180, 2632 DOI 10.17487/RFC4180, October 2005, 2633 . 2635 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2636 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2637 . 2639 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2640 Thayer, "OpenPGP Message Format", RFC 4880, 2641 DOI 10.17487/RFC4880, November 2007, 2642 . 2644 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2645 Housley, R., and W. Polk, "Internet X.509 Public Key 2646 Infrastructure Certificate and Certificate Revocation List 2647 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2648 . 2650 [RFC5890] Klensin, J., "Internationalized Domain Names for 2651 Applications (IDNA): Definitions and Document Framework", 2652 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2653 . 2655 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2656 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2657 2015, . 2659 [RPM-Requirements] 2660 ICANN, "Rights Protection Mechanism Requirements", 2661 September 2013, . 2664 [WIPO-NICE-CLASSES] 2665 WIPO, "WIPO Nice Classification", 2015, 2666 . 2668 [WIPO.ST3] 2669 WIPO, "Recommended standard on two-letter codes for the 2670 representation of states, other entities and 2671 intergovernmental organizations", March 2007, 2672 . 2674 Author's Address 2676 Gustavo Lozano 2677 ICANN 2678 12025 Waterfront Drive, Suite 300 2679 Los Angeles 90292 2680 US 2682 Phone: +1.3103015800 2683 Email: gustavo.lozano@icann.org