idnits 2.17.1 draft-lozano-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 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1469 has weird spacing: '... 36xx domai...' == Line 1471 has weird spacing: '... 43xx heade...' == Line 1472 has weird spacing: '... 44xx heade...' == Line 1473 has weird spacing: '... 45xx domai...' == Line 1474 has weird spacing: '... 46xx domai...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: At 03:00 UTC, the last uploaded LORDN file is considered final, given no ERRORs (i.e. only OKs and warnings) occur during the processing of the file at the TMDB. If a LORDN file is considered final, it is stored in the TMDB, and information is sent to the TMVs for informing the TMHs. Any LORDN file (for the same date) that is uploaded later than 03:00 will be ignored. The TMDB SHOULD not allow upload of LORDN files outside the 00:00 to 03:00 window. -- The document date (March 23, 2013) is 4023 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) == Unused Reference: 'RFC1918' is defined on line 1953, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 1957, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-lozano-tmch-smd-01 -- 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) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano, Ed. 3 Internet-Draft ICANN 4 Intended status: Standards Track B. Hoeneisen 5 Expires: September 24, 2013 Ucom.ch 6 March 23, 2013 8 TMCH functional specifications 9 draft-lozano-tmch-func-spec-01 11 Abstract 13 This document describes the requirements, the architecture and the 14 interfaces between the Trademark Clearing House (TMCH) and Domain 15 Name Registries as well as between the TMCH and Domain Name 16 Registrars for the provisioning and management of domain names during 17 Sunrise and Trademark Claims Period of a domain name Registry. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 24, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9 59 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 60 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Process Decriptions . . . . . . . . . . . . . . . . . . . . . 14 77 5.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.1.1. Registries . . . . . . . . . . . . . . . . . . . . . . 14 79 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 14 80 5.1.1.2. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 81 5.1.1.3. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 14 82 5.1.2. Registrars . . . . . . . . . . . . . . . . . . . . . . 15 83 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 84 5.1.2.2. TMCH Trust Anchor . . . . . . . . . . . . . . . . 15 85 5.1.2.3. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 15 86 5.1.2.4. IP Addresses for Access Control . . . . . . . . . 15 87 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 16 88 5.2.1. Domain Registration . . . . . . . . . . . . . . . . . 16 89 5.2.2. DN Registration by Registries . . . . . . . . . . . . 17 90 5.2.3. TMCH Sunrise Services for Registries . . . . . . . . . 19 91 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 19 92 5.2.3.2. Certificate Revocation List . . . . . . . . . . . 20 93 5.2.3.3. Notice of Registered Domain Names . . . . . . . . 21 94 5.2.4. DN registration by Registrars . . . . . . . . . . . . 23 95 5.2.5. TMCH Sunrise Services for Registrars . . . . . . . . . 23 97 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 24 98 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 24 99 5.3.2. DN registration by Registries . . . . . . . . . . . . 25 100 5.3.3. Trademark Claims Services for Registries . . . . . . . 27 101 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 27 102 5.3.3.2. Notice of Registered Domain Names . . . . . . . . 27 103 5.3.4. DN Registration by Registrars . . . . . . . . . . . . 27 104 5.3.5. Tradermark Claims Services for Registrars . . . . . . 29 105 5.3.5.1. Claims Notice Information Service . . . . . . . . 29 106 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 30 107 6.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 30 108 6.2. SMD revocation list . . . . . . . . . . . . . . . . . . . 32 109 6.3. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 34 110 6.3.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 37 111 6.3.1.1. LORDN Return Codes . . . . . . . . . . . . . . . . 39 112 6.4. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 44 114 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48 115 7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 48 116 8. Status of this Draft . . . . . . . . . . . . . . . . . . . . . 50 117 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 120 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 121 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 122 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 123 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 52 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 126 1. Introduction 128 Domain Name Registries may operate in special modes within certain 129 periods of time to facilitate registration of domain names. 131 Along with the upcoming introduction of new generic Top Level Domains 132 (gTLD), two special modes will come into effect: 134 o Sunrise Period 136 o Trademark Claims Period 138 The Sunrise and Trademark Claims Periods are defined in the gTLD 139 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 141 This document describes the requirements, the architecture and the 142 interfaces between the Trademark Clearing House (TMCH) and Domain 143 Name Registries as well as between the TMCH and Domain Name 144 Registrars for the provisioning and management of domain names during 145 the Sunrise and Trademark Claims Periods. 147 After the Terminology (Section 2) the Glossary (Section 3) is listed, 148 followed by the architecture (Section 4) and the different process 149 descriptions (Section 5). Afterwards, in Section 6, the necessary 150 Data Formats are defined, followed by their formal syntax 151 (Section 7). 153 For any date and/or time indications, Coordinated Universal Time 154 (UTC) applies. 156 1.1. Discussion 158 Any interested parties are invited to contribute to the discussion of 159 this draft and provide feedback. The discussion currently takes 160 place on the tmch-tech discussion list . 161 Interested parties can subscribe to this mailing list via 162 . 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 XML is case sensitive. Unless stated otherwise, XML specifications 171 and examples provided in this document MUST be interpreted in the 172 character case presented in order to develop a conforming 173 implementation. 175 "tmNotice-1.0" is used as an abbreviation for 176 "urn:ietf:params:xml:ns:tm-notice-1.0". The XML namespace prefix 177 "tmNotice" is used, but implementations MUST NOT depend on it and 178 instead employ a proper namespace-aware XML parser and serializer to 179 interpret and output the XML documents. 181 3. Glossary 183 In the following the most common terms are briefly Explained: 185 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 187 o CSV: Comma-Separated Values, see [RFC4180] 189 o CNIS, Claims Notice Information Service: This service provides 190 trademark claims notices to Registrars. 192 o CRC32, algorithm used in the ISO 3309 standard and in section 193 8.1.1.6.2 of ITU-T recommendation V.42. 195 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 197 o Date and time, dateandtime: Date and time are specified following 198 the standard "Date and Time on the Internet specification", see 199 [RFC3339]. 201 o DN: Domain Name, see [RFC1034] 203 o DNS: Domain Name System, see [RFC1034] 205 o DNL, Domain Name Label: An ASCII string used in the DNS (an FQDN 206 is composed by such labels separated by dots) as defined in 207 [RFC1034]. For IDNs the A-Label is used [RFC5890]. 209 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 211 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 213 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 215 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. Only 216 TLS 1.0, 1.1 and 1.2 are supported. 218 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 219 SMD PKI model. 221 o IDN: Internationalized Domain Names, see [RFC5890] 223 o LORDN, List of Registered Domain Names: This is the list of 224 registered domain names matching a DNL of a PRM that Registries 225 daily upload to the TMDB (during the NORDN process). 227 o Lookup Key: A random string of up to 64 chars from the set [a-zA- 228 Z0-9/] to be used as the lookup Key by Registrars to obtain the 229 claims notice using the CNIS. Lookup Keys are unique and are 230 related to one DNL only. 232 o NORDN, Notification of Registered Domain Names: The process by 233 which Registries daily upload their recent LORDN to the TMDB. 235 o PGP: Pretty Good Privacy, see [RFC4880] 237 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 239 o PRM, Pre-registered mark: Mark that has been pre-registered with 240 the TMCH. 242 o Registrant: Person or Organization registering a Domain Name via a 243 Registrar. 245 o Registrar, Domain Name Registrar: Entity that registers Domain 246 Names with the Registry on behalf of the Registrant. 248 o Registry, Domain Name Registry: Entity that accepts Domain Name 249 registrations from Registrars, maintains the central Database of 250 Registered Domains. 252 o SMD, Signed Mark Data: A cryptographically signed token issued by 253 the TMV to the TMH to be used in the Sunrise Period to apply for a 254 Domain Name that matches a DNL of a PRM; see also 255 [I-D.lozano-tmch-smd] 257 o SMD File: A file containing the SMD (see above) and some human 258 readable data. The latter is usually ignored in the processing of 259 the SMD File. See also Section 6.4. 261 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 262 lists of revoked SMDs; see also [I-D.lozano-tmch-smd] 264 o SMD revocation list: The SMD revocation list is used by Registries 265 (and optionally by Registrars) during the Sunrise Period to ensure 266 that an SMD is still valid (i.e. not revoked). The SMD revocation 267 list has a similar function as CRLs used in PKI. 269 o SRS: Shared Registration System, see also 270 [ICANN-GTLD-AGB-20120604]. 272 o Sunrise Period: During this period Domain Names matching a DNL of 273 a PRM can be exclusively obtained by the respective mark holders. 274 For domain names matching a PRM, a special process applies to 275 ensure a TMH gets informed on the registration of a domain name 276 matching his/her PRM. Every launch of a new gTLD Registry starts 277 with a Sunrise Period, followed by a Trademark Claims Period (see 278 below). 280 o TLD: Top Level Domain Name, see [RFC1591] 282 o Trademark, mark: Trademarks are used to claim exclusive properties 283 of products or services. A trademark is typically a name, word, 284 phrase, logo, symbol, design, image, or a combination of these 285 elements. For the scope of this document only textual trademarks 286 are relevant. 288 o Trademark Claims, Claims: Provides information to enhance the 289 understanding of the Trademark rights being claimed by the 290 Trademark Holder. 292 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 293 Trademark Claims Notice consist of one or more Trademark Claims 294 and are provided to prospective Registrants of Domain Names. 296 o Trademark Claims Notice Identifier, Claims Notice Identifier, 297 Claims Notice ID, TCNID: An element of the Trademark Claims Notice 298 (see above), identifying said Claims Notice. The Trademark Claims 299 Notice identifier is specified in the element . 301 o Trademark Claims Period: During this period, a special process 302 applies to DNs matching DNL derived from PRMs, to ensure a TMH 303 gets informed on the registration of a domain name matching his 304 PRM. For DNs matching DNL derived from PRMs, Registrars show a 305 Trademark Claims Notice to prospective Registrants that has to be 306 acknowledged before registration. 308 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 309 ICANN central repository for information to be authenticated, 310 stored, and disseminated, pertaining to the rights of trademark 311 holders. The Clearinghouse is split into two functions TMV and 312 TMDB (see below). There could be several entities performing the 313 TMV function, but only one entity performing the TMDB function. 315 o TMDB, Trademark Clearinghouse Database: Serves as a database of 316 the TMCH to provide information to the new gTLD Registries and 317 Registrars to support Sunrise or Trademark Claims Services. There 318 is only one TMDB in the TMCH that concentrates the information 319 about the "verified" Trademark records from the TMVs. 321 o TMH, Trademark Holder: The person or organization owning rights on 322 a Trademark. 324 o TMV, Trademark Validator, Trademark validation organization: An 325 entity authorized by ICANN to authenticate and validate 326 registrations in the TMDB ensuring the marks qualify as registered 327 or are court-validated marks or marks that are protected by 328 statute or treaty. This entity would also be asked to ensure that 329 proof of use of marks is provided, which can be demonstrated by 330 furnishing a signed declaration and one specimen of current use. 332 o UTC: Coordinated Universal Time, as maintained by the Bureau 333 International des Poids et Mesures (BIPM); see also [RFC3339]. 335 4. Architecture 337 4.1. Sunrise Period 339 Architecture Sunrise Period 341 SMD hand over (out of band; 342 trivial if Registrant == TMH) 343 ........................................... 344 : : 345 : .'''''''''''''''''''. : 346 : . TMCH . : 347 : ..................... : 348 v . . : 349 .------------. . .-------------. . hv .-----. 350 | Registrant | . | TMV |<------->| TMH | 351 '------------' . '-------------' . vh '-----' 352 | . | ^ \ . 353 | . | | \. 354 tr | . vs | | \ 355 | . | | dv .\ 356 v . v | . \ 357 .-----------. sr . .---. | . \ 358 .->| Registrar |<.........| S | vd | . \ 359 : '-----------' . | M | | . \ 360 : | sy . | D | v . \ 361 : ry | .-----------| M | .---. . vc \ 362 : | | . '---' | T | . \ 363 : v v . | M | . v 364 : .-----------. . | D | . .----------. 365 : | Registry |----------------->| B | . | ICANN-CA | 366 : '-----------' . yd '---' . '----------' 367 : ^ . . | : 368 : | ''''''''''''''''''' | : 369 : | cy | : 370 : cr '---------------------------------------' : 371 :.....................................................: 373 Figure 1 375 4.2. Trademark Claims Period 377 Architecture Trademark Claims Period 379 .'''''''''''''. 380 . TMCH . 381 ............... 382 . . 383 .------------. . .-------. . hv .-----. 384 | Registrant | . | TMV |<------->| TMH | 385 '------------' . '-------' . vh '-----' 386 | . ^ . 387 tr | . | dv . 388 | . vd | . 389 v . v . 390 .-----------. dr . .-------. . 391 | Registrar |<--------| T | . 392 '-----------' . | | . 393 | . | M | . 394 ry | . | | . 395 v . | D | . 396 .----------. dy . | | . 397 | Registry |<------->| B | . 398 '----------' yd . '-------' . 399 . . 400 ''''''''''''' 402 Figure 2 404 4.3. Interfaces 406 In the sub-sections below follows a short description of each 407 interface to provide an overview of the architecture. More detailed 408 descriptions of the relevant interfaces follow further below 409 (Section 5). 411 4.3.1. hv 413 The TMH registers a mark with a TMV via the hv interface. 415 After the successful registration of the mark, the TMV makes 416 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 417 TMH to be used duringn the Sunrise Period. 419 The specifics of the hv interface are beyond the scope of this 420 document. 422 4.3.2. vd 424 After successful mark registration, the TMV ensures the TMDB inserts 425 the corresponding DNLs and mark information into the database via the 426 vd interface. 428 The specifics of the vd interface are beyond the scope of this 429 document. 431 4.3.3. dy 433 Not used during the Sunrise Period. 435 During the Trademark Claims Period the Registry fetches the latest 436 DNL list from the TMDB via the dy interface in regular intervals. 437 The protocol used on the dy interface is HTTPS. 439 4.3.4. tr 441 The Registrant communicates with the Registrar via the tr interface. 443 The specifics of the tr interface are beyond the scope of this 444 document. 446 4.3.5. ry 448 The Registrar communicate with the Registry via the ry interface. 449 The ry interfaces is typically implemented in EPP [RFC5730]. A TMCH 450 specific EPP standard extension is yet to be developed. 452 4.3.6. dr 454 Not used during the Sunrise Period. 456 During the Trademark Claims Period the Registrar fetches the 457 Trademark Claims Notice from the TMDB (to be displayed to the 458 Registrant via the tr interface) via the dr interface. The protocol 459 used for fetching the Trademark Claims Notice is HTTPS [RFC2818]. 461 4.3.7. yd 463 During the Sunrise period the Registry notifies the TMDB daily via 464 the yd interface of all domain names registered. 466 During the Trademark Claims period, the Registry notifies daily the 467 TMDB via the yd interface of all domains registered that matched an 468 entry in the Registry's DNL during the creation of the domain name. 470 The protocol used on the yd interface is HTTPS. 472 4.3.8. dv 474 The TMDB notifies the TMV of all domains registered that match a mark 475 registered in the TMDB by that TMV as informed by Registries via the 476 dv interface. 478 The specifics of the dv interface are beyond the scope of this 479 document. 481 4.3.9. vh 483 The TMV notifies the TMH via the vh interface after a domains has 484 been registered that matches a PRM of this TMH. 486 The specifics of the vh interface are beyond the scope of this 487 document. 489 4.3.10. vs 491 The TMV requests to add a revoked SMD to the list of revoked SMDs at 492 the SMDM. 494 The specifics of the vs interface are beyond the scope of this 495 document. 497 Not relevant during the Trademark Claims Period. 499 4.3.11. sy 501 During the Sunrise Period the Registry fetches the most recent list 502 of revoked SMDs from the SMDM via the sy interface in regular 503 intervals. The protocol used on the sy interface is HTTPS. 505 Not relevant during the Trademark Claims Period. 507 4.3.12. sr 509 During the Sunrise Period the Registrar may fetch the most recent 510 list of revoked SMDs from the SMDM via the sr interface. The 511 protocol used on the sr interface is the same as on the sy interface 512 (s. above), i.e. HTTPS. 514 Not relevant during the Trademark Claims Period. 516 4.3.13. vc 518 The TMV requests to add a revoked TMV certificate to the CRL at the 519 ICANN-CA via the vc interface. 521 The specifics of the vc interface are beyond the scope of this 522 document. 524 Not relevant during the Trademark Claims Period. 526 4.3.14. cy 528 During the Sunrise Period the Registry fetches the most recent CRL 529 from the ICANN-CA via the cy interface in regular intervals. The CRL 530 is mainly used for validation of TMV certificates. The protocol used 531 on the cy interface is HTTPS [RFC2818]. 533 Not relevant during the Trademark Claims Period. 535 4.3.15. cr 537 During the Sunrise Period the Registrar may fetch the most recent CRL 538 from the ICANN-CA via the cr interface. The protocol used on the cr 539 interface is the same as on the cy interface (s. above). 541 Not relevant during the Trademark Claims Period. 543 5. Process Decriptions 545 5.1. Bootstrap 547 5.1.1. Registries 549 5.1.1.1. Credentials 551 Each Registry will receive authentication credentials from the TMDB/ 552 SMDM to be used: 554 o During the Sunrise Period to fetch the lists of revoked SMDs from 555 the SMDM via the sy interface (Section 4.3.11). 557 o During Trademark Claims Period to fetch the lists of DNLs from the 558 TMDB via the dy interface (Section 4.3.3). 560 o During the NORDN process to notify the LORDN to the TMDB via the 561 yd interface (Section 4.3.7). 563 o Credentials are created per TLD and provided to the registry 564 operator which is the contracting party for the TLD. 566 5.1.1.2. TMCH Trust Anchor 568 Each Registry MUST fetch the X.509 certificate ([RFC5280] / 569 [RFC6818]) of the ICANN-CA (Trust Anchor) from 570 < https://ca.icann.org/tmch.crt > to be used: 572 o during the Sunrise Period to validate the TMV certificates and the 573 CRL of TMV certificates. 575 5.1.1.3. TMDB/SMDM PGP Key 577 The TMDB MUST provide each Registry with the public portion of the 578 PGP Key used by TMDB and SMDM, to be used: 580 o During the Sunrise Period to perform integrity checking of the 581 list of revoked SMDs fetched from the SMDM via the sy interface 582 (Section 4.3.11). 584 o During Trademark Claims Period to perform integrity checking of 585 the list of DNL fetched from the TMDB via the dy interface 586 (Section 4.3.3). 588 5.1.2. Registrars 590 5.1.2.1. Credentials 592 Each ICANN-accredited Registrar will receive authentication 593 credentials from the TMDB to be used: 595 o During the Sunrise Period to (optionally) fetch the lists of 596 revoked SMDs from the SMDM via the sr interface (Section 4.3.12). 598 o During Trademark Claims Period to fetch Claims Notices from the 599 TMDB via the dr interface (Section 4.3.6). 601 5.1.2.2. TMCH Trust Anchor 603 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 604 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 605 be used: 607 o during the Sunrise Period to (optionally) validate the TMV's 608 certificates and the CRL of TMV certificates. 610 5.1.2.3. TMDB PGP Key 612 Registrars MUST receive the public portion of the PGP Key used by 613 TMDB and SMDM from the TMDB administrator to be used: 615 o during the Sunrise Period to (optionally) perform integrity 616 checking of the list of revoked SMDs fetched from the SMDM via the 617 sr interface (Section 4.3.12). 619 5.1.2.4. IP Addresses for Access Control 621 The Registrars MUST provide to the TMDB administrator all IP 622 addresses, which will be used by their hosts to fetch Trademark 623 Claims Notices via the dr interface (Section 4.3.6). The TMDB 624 restricts access to known IP Addresses only. This access restriction 625 is applied in addition to HTTP Basic access authentication (for 626 credentials to be used, see Section 5.1.2.1). The TMDB MAY limit the 627 number of IP addresses to be accepted per Registrar. 629 5.2. Sunrise Period 631 5.2.1. Domain Registration 633 Registration during Sunrise Period 635 .------------. .-----------. .----------. 636 | Registrant | | Registrar | | Registry | 637 '------------' '-----------' '----------' 638 | | | 639 | Request DN | | 640 | Registration | | 641 | (with SMD) | | 642 |------------->| Check DN availability | 643 | |---------------------------->| 644 | | | 645 | |.-------. DN unavail. .-------------. 646 | || ABORT |<-----------( DN available? ) 647 | |'-------' no '-------------' 648 | | | yes 649 | | | 650 | | Request DN registration | 651 | | (with SMD) | 652 | |---------------------------->| 653 | | | 654 | | .-------------------------------. 655 | | | Validate SMD and | 656 | | | corresponding TMV certificate | 657 | | '-------------------------------' 658 | | | 659 | |.-------. Error .----------------------. 660 | || TRY |<------( Validation successful? ) 661 | || AGAIN | no '----------------------' 662 | || OR | | yes 663 | || ABORT | | 664 | |'-------' | 665 | | | 666 | | DN registered | 667 | DN regist. |<----------------------------| 668 |<-------------| | 669 | | | 671 Figure 3 673 5.2.2. DN Registration by Registries 675 Registries MUST perform a minimum set of checks for verifying DN 676 registrations during Sunrise Period upon reception of a registration 677 request over the ry interface (Section 4.3.5). If any of these 678 checks fails the Registry MUST abort the DN registration. Each of 679 these checks MUST be performed before the DN is registered (see 680 Section 3). 682 In case of asynchronous registrations (e.g. auctions), the minimum 683 set of checks MAY be performed when creating the intermediate object 684 (e.g. a domain name application) used for DN registration. However, 685 the validation of the SMD compared to the moment of effective 686 registration of the DN MUST NOT be older than a period of time (i.e., 687 the SMD-validation validity period) that is defined in the PRM 688 requeriments document referenced in Specification 7 of the gTLD 689 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 691 Performing the minimum set of checks Registries MUST verify that: 693 1. A SMD has been received from the Registrar along with the DN 694 registration. 696 2. The certificate of the TMV has been correctly signed by the 697 ICANN-CA. (The certificate of the TMV is contained within the 698 SMD.) 700 3. The validity period of the TMV certificate is within the allowed 701 range. 703 4. The certificate of the TMV is not be listed in the CRL file 704 specified in the CRL distribution point of the TMV certificate. 706 5. The signature of the SMD (signed with the TMV certificate) is 707 valid. 709 6. The validity period of the SMD is within the allowed range ( and elements). 712 7. The SMD has not been revoked, i.e., is not contained in the SMD 713 revocation list. 715 8. The leftmost DNS label (A-label in case of IDNs) of the DN being 716 registered matches one of the labels () elements in 717 the SMD. 719 These procedure apply to all DN registrations at the second level as 720 well as to all other levels subordinate to the TLD that the Registry 721 accepts registrations for. 723 5.2.3. TMCH Sunrise Services for Registries 725 5.2.3.1. SMD Revocation List 727 A new SMD revocation list MUST be published by the SMDM twice a day, 728 by 00:00 and 12:00 UTC. 730 Registries MUST download the latest version of the SMD revocation 731 list at least once every 24 hours. 733 Update SMD revocation list 735 .----------. .------. 736 | Registry | | SMDM | 737 '----------' '------' 738 | | 739 .----------------. | 740 | Periodically, | | 741 | at least | | 742 | every 24 hours | | 743 '----------------' | 744 | | 745 |----------------------------------------------------->| 746 | Download latest revocation list for SMD certificates | 747 |<-----------------------------------------------------| 748 | | 749 | | 751 Figure 4 753 5.2.3.2. Certificate Revocation List 755 Registries MUST update their local copy of the CRL at least every 4 756 hours using the CRL distribution point specified in the TMV 757 certificate. 759 Operationally, the CRL file and CRL distribution point is the same 760 for all TMVs and (at publication of this document) located at 761 < https://crl.icann.org/tmch.crl >. 763 Update CRL for TMV certificates 765 .----------. .----------. 766 | Registry | | ICANN-CA | 767 '----------' '----------' 768 | | 769 .----------------. | 770 | Periodically, | | 771 | at least | | 772 | every 24 hours | | 773 '----------------' | 774 | | 775 |------------------------------------------->| 776 | Download latest CRL for TMV certificates | 777 |<-------------------------------------------| 778 | | 779 | | 781 Figure 5 783 5.2.3.3. Notice of Registered Domain Names 785 The Registry MUST send the LORDN file containing all DNs registered 786 on the previous calendar day (UTC), to the TMDB (over the yd 787 interface, Section 4.3.7) between 00:00 and 03:00 UTC each day. 789 The TMDB MUST process each uploaded LORDN file within 30 minutes of 790 the finalization of the upload and have the response indicating the 791 errors and warnings to the Registry. 793 A LORDN file with headers and no data elements is used to indicate 794 that there were no registrations the previous calendar day (UTC). 796 If a new LORDN file (containing the registered DNs for the same date) 797 is uploaded before 03:00 UTC, the previous LORDN file will be 798 discarded and the new LORDN file will be processed instead. 800 At 03:00 UTC, the last uploaded LORDN file is considered final, given 801 no ERRORs (i.e. only OKs and warnings) occur during the processing of 802 the file at the TMDB. If a LORDN file is considered final, it is 803 stored in the TMDB, and information is sent to the TMVs for informing 804 the TMHs. Any LORDN file (for the same date) that is uploaded later 805 than 03:00 will be ignored. The TMDB SHOULD not allow upload of 806 LORDN files outside the 00:00 to 03:00 window. 808 In case that a LORDN file was not received for the previous calendar 809 day or errors are encountered, a manual process between the TMDB and 810 the Registry will be performed to transmit the file. 812 NORDN 814 .----------. .------. .-----. .-----. 815 | Registry | | TMDB | | TMV | | TMH | 816 '----------' '------' '-----' '-----' 817 | | | | 818 .------------------. .-----------. | | 819 | Periodically; | | Wait for |<-------. | | 820 | every 24 hours | | LORDN | | | | 821 | (between 00:00 | '-----------' | | | 822 | and 03:00 UTC) | | | | | 823 '------------------' | | | | 824 | | | | | 825 .--------->| Upload LORDN | | | | 826 | |-------------------->| | | | 827 | | | | | | 828 | | .-------------------------. | | | 829 | | | Verify each domain name | | | | 830 | | | in the uploaded file | | | | 831 | | | and write results to a | | | | 832 | | | .err-file (within 30') | | | | 833 | | '-------------------------' | | | 834 | | | | | | 835 | | Download log file | | | | 836 | |<--------------------| | | | 837 | | | | | | 838 | .-----------------. .---------------. | | | 839 | | Check whether | / everything fine \ no | | | 840 | | log file | ( (i.e. no errors )----' | | 841 | | contains errors | \ in log file )? / | | 842 | '-----------------' '---------------' | | 843 | | | yes | | 844 | .---------------. | | | 845 | / everything fine \ yes | | | 846 |( (i.e. no errors )-----. | Notify TMVs | | 847 | \ in log fiel )? / | | on the LORDN | | 848 | '---------------' | | pre-registered | | 849 | | no v | with said TMV | | 850 | .----------------. .------. |--------------->| | 851 '-| Correct Errors | | DONE | | | | 852 '----------------' '------' | | Notify each | 853 | | | affected TMH | 854 | | |------------->| 855 | | | | 857 Figure 6 859 The format used for the LORDN is described in Section 6.3 861 5.2.4. DN registration by Registrars 863 Registrars MAY choose to perform the checks for verifying DN 864 registrations as performed by the Registries (see Section 5.2.2) 865 before sending the command to register a DN. 867 5.2.5. TMCH Sunrise Services for Registrars 869 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 870 also available for Registrars to optionally validate the SMDs 871 received. 873 5.3. Trademark Claims Period 875 5.3.1. Domain Registration 877 Registration during Trademark Claims Period 879 .------------. .-----------. .----------. .------. 880 | Registrant | | Registrar | | Registry | | TMDB | 881 '------------' '-----------' '----------' '------' 882 | | | | 883 | Request DN | | | 884 | Registration | Check DN availability | | 885 |------------->|---------------------------->| | 886 | | | | 887 | |.-------. DN unavail. .-------------. | 888 | || ABORT |<-----------( DN available? ) | 889 | |'-------' no '-------------' | 890 | | | yes | 891 | | DN available & .---------. | 892 | |.----------. no claim / Does DN \ | 893 | || CONTINUE |<---------( match DNL ) | 894 | || NORMALLY | no \ of PRM? / | 895 | |'----------' '---------' | 896 | | | yes | 897 | | DN avail (Lookup key inc.) | | 898 | |<----------------------------| | 899 | | | | 900 | | Request Claims Notice | 901 | Display |----------------------------------------->| 902 | Claims | | 903 | Notice | Return Claims Notice | 904 |<-------------|<-----------------------------------------| 905 | | | 906 .------. yes | Register DN (TCNID included) | 907 ( Ack? )--------->|---------------------------->| | 908 '------' | | | 909 ||no | Error .----------------------. | 910 || .-------. |<--------------( Validation successful? ) | 911 |'->| ABORT | | no '----------------------' | 912 | '-------' | | yes | 913 | | | | 914 | DN regist. | DN registered | | 915 |<-------------|<----------------------------| | 916 | | | | 918 Figure 7 920 5.3.2. DN registration by Registries 922 During Trademark Claim Periods, Registries perform two main 923 functions: 925 o Whenever a Registrar queries the domain availability (e.g., an EPP 926 domain Check command) that matches a DNL of a PRM (over the ry 927 interface, Section 4.3.5) for availability, the Registry MUST 928 return the corresponding Lookup Key. 930 o For any DN matching a DNL of a PRM, Registries MUST perform a 931 minimum set of checks for verifying DN registrations during 932 Trademark Claims Period upon reception of a registration request 933 over the ry interface (Section 4.3.5). If any of these checks 934 fails the Registry MUST abort the DN registration. Each of these 935 checks MUST be performed before the DN is registered (see 936 Section 3). 938 o In case of asynchronous registrations (e.g. auctions), the minimum 939 set of checks MAY be performed when creating the intermediate 940 object (e.g. a domain name application) used for DN registration. 941 However, the acknowledgement of the Trademark Notice compared to 942 the moment of effective registration of the DN MUST NOT be older 943 than a period of time (i.e., the TCN-Ack validity period) that is 944 defined in the PRM requeriments document referenced in 945 Specification 7 of the gTLD Applicant Guidebook 946 [ICANN-GTLD-AGB-20120604]. 948 o Performing the minimum set of checks Registries MUST verify that: 950 1. The Claims Notice Identifier, expiration datetime and 951 acceptance datetime of the Trademark Notice, have been 952 received from the Registrar along with the DN registration. 954 If the three elements mentioned above are not provided by 955 the Registrar for a DN matching a DNL of a PRM, but the DNL 956 was inserted (or re-inserted) for the first time into DNL 957 list less than 24 hours ago, the registration MAY continue 958 without this data and the tests listed below are not 959 required to be performed. (Note however, that such DN 960 registrations MUST be included in the LORDN.) 962 2. The claim notice has not expired (according to the expiration 963 datetime sent by the Registrar). 965 3. The acceptance datetime is no more than 48 hours in the past. 967 4. Using the leftmost DNS label (A-label in the case of IDNs) of 968 the DN being registered, the expiration datetime provided by 969 the registrar and the TMDB identifier extracted from the 970 Claims Notice identifier provided by the registrar compute the 971 checksum. Verify using that the checksum match the checksum 972 present in the Claims Notice identifier. 974 These procedures apply to all DN registrations at the second level as 975 well as to all other levels subordinate to the TLD that the Registry 976 accepts registrations for. 978 5.3.3. Trademark Claims Services for Registries 980 5.3.3.1. Domain Name Label (DNL) List 982 A new DNL list MUST be published by the TMDB twice a day, by 00:00 983 and 12:00 UTC. 985 Registries MUST download the latest version of the DNL list at least 986 once every 24 hours. 988 Update DNL list 990 .----------. .------. 991 | Registry | | TMDB | 992 '----------' '------' 993 | | 994 .----------------. | 995 | Periodically, | | 996 | at least | | 997 | every 24 hours | | 998 '----------------' | 999 | | 1000 |-------------------------------->| 1001 | Download latest list of DNLs | 1002 |<--------------------------------| 1003 | | 1004 | | 1006 Figure 8 1008 5.3.3.2. Notice of Registered Domain Names 1010 The NORDN process during the Trademark Claims Period is almost the 1011 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1012 difference that only registrations subject to a Trademark Claim 1013 (i.e., at registration time the name appeared in the current DNL list 1014 downloaded by the Registry) are included in the LORDN. 1016 5.3.4. DN Registration by Registrars 1018 For any DN matching a DNL of a PRM, Registrars MUST perform the 1019 following steps: 1021 1. Use the Lookup Key received from the Registry (while verifying DN 1022 availability) to obtain the Claims Notice from the TMDB using the 1023 dr interface (Section 4.3.6) 1025 2. Present the Claims Notice to the Registrant as described in 1026 [ICANN-GTLD-AGB-20120604]. 1028 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1029 consent with the Claims Notice, before any further processing. 1030 (The transmission of a Trademark Claims Identifier to the 1031 Registry over the ry interface, Section 4.3.5 implies that the 1032 Registrant has expressed his consent with the Claims Notice.) 1034 4. Perform the minimum set of checks for verifying DN registrations. 1035 If any of these checks fails the Registrar MUST abort the DN 1036 registration. Each of these checks MUST be performed before the 1037 registration is sent to the Registry. Performing the minimum set 1038 of checks Registrars MUST verify that: 1040 1. The claim notice has not expired (using expiration date 1041 (). 1043 2. The claim notice validity based on the (). 1046 3. The leftmost DNS label (A-label in case of IDNs) of the DN 1047 being registered matches the label () element 1048 in the Trademark Claim Notice. 1050 4. The Registrant has acknowledged (expressed his consent with) 1051 the Claims Notice. 1053 5. Record the date and time when the registrant acknowledged the 1054 trademark claims notice. 1056 6. Send the registration to the Registry (ry interface, 1057 Section 4.3.5) and include the following information: 1059 * Trademark Claims Identifier () 1061 * Expiration date of the claims notice () 1063 * Acceptance datetime of the trademark claims notice. 1065 Claims notices are generated twice a day. The expiration date of the 1066 claims notice is set to 48 hours in the future, allowing the 1067 implementation of a cache by Registrars and enough time for the 1068 registration workflow process to finalize. Registrars SHOULD 1069 implement a cache of claims notices to minimize the number of queries 1070 sent to the TMDB. The cached TM Notice must be removed from the 1071 cache after the expiration date of the TM notice as defined by 1072 . The TMDB MAY implement rate-limiting as one of 1073 the protection mechanisms to mitigate the risk of performance 1074 degradation. 1076 5.3.5. Tradermark Claims Services for Registrars 1078 5.3.5.1. Claims Notice Information Service 1080 The Trademark Claims Notices are provided by the TMDB online and are 1081 fetched by the Registrar via the dr interface (Section 4.3.6). To 1082 get access to the Trademark Claims Notices, the Registrar needs the 1083 credentials provided by the TMDB (Section 5.1.2.1) and the Lookup Key 1084 received from the Registry via the ry interface (Section 4.3.5). The 1085 dr interface (Section 4.3.6) uses HTTPS with Basic access 1086 authentication. Furthermore the Registrar has to ensure that all IP 1087 addresses used by his own systems on dr interface have been informed 1088 to the TMDB to be entered into the list known IP Addresses 1089 (Section 5.1.2.4). 1091 The URL of the dr interface (Section 4.3.6) is: 1092 /cnis/.xml> 1094 Note that the "lookupkey" may contain SLASH characters ("/"). 1096 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1097 MUST be signed by a well-know public CA. Registrars MUST perform 1098 standard validation of the TLS (HTTPS) certificate. Registrars are 1099 authenticated in the dr interface using HTTP Basic access 1100 authentication. The dr (Section 4.3.6) interface MUST support HTTPS 1101 keep-alive and MUST maintain the connection for up to 30 minutes. 1103 6. Data Format Descriptions 1105 6.1. DNL List file 1107 This section defines format of the list containing every Domain Name 1108 Label (DNL) that matches a Pre-Registered Mark (PRM). The list is 1109 maintained by the TMDB and downloaded by Registries in regular 1110 intervals (see Section 5.3.3.1). The Registries use the DNL list 1111 during the Trademark Claims period to check whether a requested DN 1112 matched a DNL of a PRM. 1114 The DNL list is contained in a CSV-like formatted file that has the 1115 following structure: 1117 o first line: , 1119 Where: 1121 + , version of the file. Version 1 MUST always be 1122 present. 1124 + , date and time that the DNL was 1125 created. 1127 o second line: a header line as specified in [RFC4180] 1129 With the header names as follows: 1131 DNL,lookup-key,insertion-datetime 1133 o One or more lines with: ,, 1136 Where: 1138 + , a domain label covered by a trademark. 1140 + , lookup key that the registry MUST provide to 1141 the registrar. 1143 + , datetime when the DNL was first 1144 inserted into the DNL. The possible two values of time for 1145 inserting a DNL to the DNL list are 00:00 and 12:00. 1147 Example for DNL list 1149 1,2012-08-16T00:00:00.0Z 1150 DNL,lookup-key,insertion-datetime 1151 example,j8f/KR6/Dex/dac5KfYddfEr,2010-07-14T00:00:00.0Z 1152 another-example,lj3/l4F/33F/f4HGgg42l5Ts,2012-08-16T00:00:00.0Z 1153 anotherexample,h7h/nm9/FEJ/iHH82mkj3d2c,2011-08-16T12:00:00.0Z 1155 Figure 9 1157 To provide authentication and integrity protection, the DNL list will 1158 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1159 (see also Section 5.1.1.3). The PGP signature of the DNL list can be 1160 found in the similar URI but with extension .sig as shown below. 1162 The URL of the dy interface (Section 4.3.3) is: 1164 o /dnl/dnl-latest.csv> 1166 o /dnl/dnl-latest.sig> 1168 6.2. SMD revocation list 1170 This section defines format of the list of SMDs that have been 1171 revoked. The list is maintained by the SMDM and downloaded by 1172 Registries (and optionally by Registrars) in regular intervals (see 1173 Section 5.2.3.1). The SMD revocation list is used during the Sunrise 1174 Period to validate SMDs received. The SMD revocation list has a 1175 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1177 The SMD revocation list is contained in a CSV-like formatted file 1178 that has the following structure: 1180 o first line: , 1182 Where: 1184 + , version of the file. Version 1 MUST always be 1185 present. 1187 + , datetime that the 1188 SMD revokation list was created. 1190 o second line: a header line as specified in [RFC4180] 1192 With the header names as follows: 1194 smd-id 1196 o One or more lines with: 1198 Where: 1200 + , identifier of the SMD that was revoked. 1202 To provide integrity protection, the SMD revocation list is PGP 1203 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1204 also Section 5.1.1.3). The SMD revocation list is provided by the 1205 TMDB with extension .csv. The PGP signature of the SMD revocation 1206 list can be found in the similar URI but with extension .sig as shown 1207 below. 1209 The URL of the sr interface (Section 4.3.12) and sy interface 1210 (Section 4.3.11) is: 1212 o /smdrl/smdrl-latest.csv> 1214 o /smdrl/smdrl-latest.sig> 1215 Example for SMD Revocation list 1217 1,2012-08-16T00:00:00.0Z 1218 smd-id 1219 2-2 1220 3-2 1221 1-2 1223 Figure 10 1225 6.3. LORDN File 1227 This section defines the format of the List of Registered Domain 1228 Names (LORDN), which is maintained by each Registry and uploaded 1229 daily to the TMDB. Every time a DN matching a DNL of a PRL said DN 1230 is added to the LORDN along with further information related to its 1231 registration. 1233 The URI of the dy interface (Section 4.3.3) used to upload the LORDN 1234 file is: 1236 o https:///LORDN// 1238 o For example, to upload the LORN file for 2012-08-15 and TLD 1239 "example", the URL would be 1240 https:///LORDN/example/2012-08-15 1242 The LORDN is contained in a CSV-like formatted file that has the 1243 following structure: 1245 o For Sunrise Period: 1247 * first line: ,,,, 1250 Where: 1252 - , version of the file. Version 1 MUST always be 1253 present. 1255 - , date and time that the LORDN 1256 was created. 1258 - , day when the domains were 1259 registered. 1261 - : Sunrise 1263 - , number of domain names registered 1265 * second line: a header line as specified in [RFC4180] 1267 With the header names as follows: 1269 roid,domain-name,SMD-id,registrar-id,application- 1270 datetime,registration-datetime 1272 * One or more lines with: ,,, ,, 1276 Where: 1278 - , Repository Object IDentifier (ROID) in the SRS. 1280 - , domain name that was registered. 1282 - , SMD ID used when the domain was registered. 1284 - , IANA registrar ID. 1286 - OPTIONAL , date and 1287 time that the application was created, in case of a 1288 domain registration based on an asynchronous registration 1289 (e.g., when using auctions). 1291 - , date and time that the domain 1292 was registered. 1294 Example for LORDN during Sunrise 1296 1,2012-08-16T00:00:00.0Z,2012-08-15,Sunrise,3 1297 roid,domain-name,SMD-id,registrar-id,application-datetime\ 1298 registration-datetime, 1299 SH8013-REP,example1.gtld,1-2,9999,2012-07-15T00:50:00.0Z,\ 1300 2012-08-15T13:20:00.0Z 1301 EK77-REP,example2.gtld,2-2,9999,,2012-08-15T14:00:03.0Z 1302 HB800-REP,example3.gtld,3-2,9999,,2012-08-15T15:40:00.0Z 1304 Figure 11 1306 o For Trademark Claims Period: 1308 * first line: ,,,, 1311 Where: 1313 - , version of the file. Version 1 MUST always be 1314 present. 1316 - , date and time that the LORDN 1317 was created. 1319 - , day when the domains were 1320 registered. 1322 - : Claims 1324 - , number of domain names registered 1326 * second line: a header line as specified in [RFC4180] 1328 With the header names as follows: 1330 roid,domain-name,notice-id,registrar-id,application- 1331 datetime,registration-datetime,ack-datetime 1333 * One or more lines with: ,,,< 1334 IANA registrar id>,,, 1337 Where: 1339 - , Repository Object IDentifier (ROID) in the SRS. 1341 - , domain name that was registered. 1343 - , trademark notice identifier as specified 1344 in . 1346 - , IANA registrar ID. 1348 - OPTIONAL , date and 1349 time that the application was created, in case of a 1350 domain registration based on an asynchronous registration 1351 (e.g., when using auctions). 1353 - , date and time that the domain 1354 was registered. 1356 - , date and time 1357 that the TM notice was acknowledged. 1359 For a DN matching a DNL of a PRM at the moment of 1360 registration, created without the Claims Notice Identifier, 1361 expiration datetime and acceptance datetime, becauste DNL 1362 was inserted (or re-inserted) for the first time into DNL 1363 list less than 24 hours ago, the string "recent-dnl- 1364 insertion" MUST be specified in and . 1367 Example for LORDN during Claims 1369 1,2012-08-16T00:00:00.0Z,2012-08-15,Claims,3 1370 roid,domain-name,notice-id,registrar-id,application-datetime,\ 1371 registration-datetime,ack-datetime 1372 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1373 9999,,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1374 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1375 9999,,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1376 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1377 9999,,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1379 Figure 12 1381 6.3.1. LORDN Log File 1383 After reception of the LORDN File, the TMDB verifies its content for 1384 syntactical and semantical correctness. The ouput of the LORDN File 1385 verification is retrieved using the dy interface (Section 4.3.3). 1387 The URI of the dy interface (Section 4.3.3) used to retrieve the 1388 LORDN Log File is: 1390 o https:///LORDN///result 1392 o For example, to obtain the LORN Log File for 2012-08-15 and TLD 1393 "example" the URI would be 1394 https:///LORDN/example/2012-08-15/result 1396 The LORDN log file is contained in a CSV-like formatted file that has 1397 the following structure: 1399 o first line: ,, ,, 1403 Where: 1405 + , version of the file. Version 1 MUST always be 1406 present. 1408 + , date and time that the LORDN 1409 Log was created. 1411 + , date and time of creationg 1412 for the LORDN file that this log file is referring to. 1414 + , day when the domains were 1415 registered as indicated in the related LORDN file. 1417 + , Sunrise or Claims. 1419 + , whether the LORDN file has been accepted for 1420 processing by the TMDB. Possible values are "accepted" or 1421 "rejected". 1423 o second line: a header line as specified in [RFC4180] 1425 With the header names as follows: 1427 roid,result-code 1429 o One or more lines with: , 1431 Where: 1433 + , Repository Object IDentifier (ROID) in the SRS. 1435 + , return code as described in Section 6.3.1.1. 1437 Example for LORDN Logfile 1439 1.0,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1440 2012-08-15,Claims,accepted 1441 roid,result-code 1442 SH8013-REP,2000 1444 Figure 13 1446 6.3.1.1. LORDN Return Codes 1448 In Figure 14 the classes of return codes (rc) are listed. Those 1449 classes in square brackets are not used at this time, but may come 1450 into use at some later stage. The first two digits of a return code 1451 denote the return code class, which defines the outcome at the TMDB: 1453 o ok: Success, domain name line accepted 1455 o warn: a warning is issued, domain name line accepted 1457 o err: an error is issued, LORDN file rejected 1459 LORDN Return Code Classes 1461 code Class outcome 1462 ---- ----- ------- 1464 20xx Success ok 1466 33xx [ header line syntax warning ] warn 1467 34xx [ header line semantic warning ] warn 1468 35xx [ domain name line syntax warning ] warn 1469 36xx domain name line semantic warning warn 1471 43xx header information syntax error err 1472 44xx header information semantic error err 1473 45xx domain name line syntax error err 1474 46xx domain name line semantic error err 1476 Figure 14 1478 In the following the LORDN return codes used by the TMDB are 1479 described: 1481 LORDN Return Codes 1483 rc Short Decription 1484 Long Description 1485 ---- ------------------------------------------------------------ 1487 2000 OK 1488 Domain Name line successfully processed 1490 3601 TCN Acknowledgement Date after Registration Date 1491 TCN Acknowledgement Date in Domain Name is newer than the 1492 Registration Date 1494 3602 Duplicate DN Line 1495 This DN Line is an exact duplicate of another line in same 1496 file, DN line ignored 1498 3603 ROID Notified Earlier 1499 Same ROID has been notified earlier, DN line ignored 1501 3604 Checksum Invalid 1502 Based on the DN registered, the TMC-ID and 1503 the expiration date of the linked TM notice, the 1504 checksum is invalid. 1506 3605 TMC-ID Expired 1507 Trademark Claim Notice Identifier was expired 1508 when accepted, but still accepted. 1509 In case of an asynchronous registration, this may refer 1510 to the date of the application creation. 1512 3606 Wrong TMC-ID used 1513 The TMC-ID used for the registration was not valid 1514 for this DN. 1516 3607 SMD-Validation too old 1517 The validation of the SMD was done outside of the SMD-validation 1518 validity period, and still was used for registration. 1520 3608 TCN-Acknowledgement too old 1521 The Acknowledgement of the TCN was done outside of the TCN-Ack 1522 validity period, and still was used for registration. 1524 3609 Invalid SMD used 1525 The SMD used for registration was not valid. In case of 1526 an asynchronous registration, this may refer to the date of 1527 the application creation. 1529 4301 Syntax Error in Header 1530 Syntac Error in Header information. 1532 4401 Domain Name Count Mismatch 1533 The number of Domain Names in Header does not match 1534 the count of DN lines 1536 4402 Creation Date in past or future 1537 Creation Date of LORDN is out of range 1539 4403 Registration Date in past or future 1540 Registration date of LORDN is out of range 1542 4404 Sunrise/Claims mismatch 1543 The LORDN is for Sunrise, but the TLD is marked in the TMDB 1544 as being in Claims or viceversa 1546 4501 Syntax Error in DN line 1547 Syntax Error in Domain Name line 1549 4601 Invalid TLD used 1550 The TLD in the DN line does not match what is expected for this LORDN 1552 4602 Registrar ID Invalid 1553 Registrar ID in DN line is not valid 1555 4603 Registration Date out of range 1556 Registration Date in the DN line is in the past or the future 1558 Figure 15 1560 6.4. SMD File 1562 This section defines the format of the SMD File. After a successful 1563 registration of a mark, the TMV returns an SMD File to the TMH. The 1564 SMD file can then be used for registration of one or more DNs covered 1565 by the PRM during the Sunrise Period of a TLD. 1567 Two encapsulation boundaries are defined for delimiting the 1568 encapsulated base64 encoded SMD, i.e. "-----BEGIN ENCODED SMD-----" 1569 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1570 boundaries MUST be used by Registries and Registrars for validation 1571 purposes, i.e. any data outside these boundaries as well as the 1572 boundaries themselves MUST be ignored for validation purposes. 1574 The structure of the SMD File is as follows: 1576 o Marks: 1578 o smdID: 1580 o U-labels: 1582 o notBefore: 1584 o notAfter: 1586 o -----BEGIN ENCODED SMD----- 1588 o 1590 o -----END ENCODED SMD----- 1591 Example for SMD File (shortened at [...]): 1593 Marks: Example One 1594 smdID: 1-2 1595 U-labels: example-one, exampleone 1596 notBefore: 2011-08-16 09:00 1597 notAfter: 2012-08-16 09:00 1598 -----BEGIN ENCODED SMD----- 1599 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1600 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1601 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1602 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 1603 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 1604 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 1605 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 1606 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 1607 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 1608 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 1609 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 1610 [...] 1611 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 1612 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 1613 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 1614 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 1615 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 1616 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 1617 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1618 -----END ENCODED SMD----- 1620 Figure 16 1622 6.5. Trademark Claims Notice 1624 The TMDB MUST provide the Trademark Claim Notice to Registrars in XML 1625 format as specified below. 1627 An enclosing element that describes the Trademark 1628 Notice to a given label. 1630 The child elements of the element include: 1632 o A element that contains the unique identifier of the 1633 Trademark Notice. 1635 The Trademark Notice identifier is a concatenation of a 1636 checksum and the TMDB identifier. The first 8 characters of 1637 the Trademark Notice identifier is a checksum. The rest is the 1638 TMDB identifier, which is a zero-padded number in the range of 1639 1 to 9223372036854775808. 1641 Example of a Trademark Notice identifier 1642 a7b216ed9223372036854775808. 1644 Where: 1646 + Checksum=a7b216ed 1648 + TMDB identifier=9223372036854775808 1650 The checksum is a 8 characters long Base16 encoded output of 1651 computing the CRC32 of the string concatenation of: label + 1652 unix_timestamp() + TMDB identifier 1654 The TMDB uses the and 1655 elements from the Trademark Notice along with the TMDB 1656 identifier to compute the checksum. 1658 A registry MUST use the leftmost DNS label (A-label in case of 1659 IDNs) of the DN being registered, the expiration datetime of 1660 the Trademark Notice and the TMDB identifier extracted from the 1661 Trademark Notice identifier provided by the Registrar to 1662 compute the checksum. For example the DN "foo.bar.example" 1663 being registered, the left most label would be "foo". 1665 Example of computation of the checksum: CRC32(example- 1666 one12819492009223372036854775808)=a7b216ed 1668 o A element that contains the start of the 1669 validity date and time of the TM notice. 1671 o A element that contains the expiration date 1672 and time of the TM notice. 1674 o A elements that contain the DNS label (A-label in 1675 case of IDNs) form of the label that correspond to the DN covered 1676 by a PRM. 1678 o One or more elements that contain the claim. The 1679 element contains the following child elements: 1681 * A element that contains the mark text 1682 string. 1684 * One or more elements that contains the 1685 information of the holder of the mark. An "entitlement" 1686 attribute is used to identify the entitlement of the holder, 1687 possible values are: owner, assignee and licensee. 1689 * Zero or more OPTIONAL elements that contains 1690 the information of the representative of the mark registration. 1691 A "type" attribute is used to identify the type of contact, 1692 possible values are: owner, agent or thirdparty. 1694 * A element that contains the name (in 1695 English) of the jurisdiciton where the trademark is protected. 1696 A jurCC attribute contains the two-character code of the 1697 jurisdiction where the trademark was registered. This is a 1698 two-character code from [WIPO.ST3]. 1700 * Zero or more OPTIONAL element that 1701 contains the description (in English) of the Nice 1702 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 1703 attribute contains the class number. 1705 * A element that contains the full 1706 description of the goods and services mentioned in the mark 1707 registration document. 1709 Example of object: 1711 1712 1713 a7b216ed9223372036854775808 1714 2010-08-14T09:00:00.0Z 1715 2010-08-16T09:00:00.0Z 1716 example-one 1717 1718 Example One 1719 1720 Example Inc. 1721 1722 123 Example Dr. 1723 Suite 100 1724 Reston 1725 VA 1726 20190 1727 US 1728 1729 1730 1731 Joe Doe 1732 Example Inc. 1733 1734 123 Example Dr. 1735 Suite 100 1736 Reston 1737 VA 1738 20190 1739 US 1740 1741 +1.7035555555 1742 jdoe@example.com 1743 1744 UNITED STATES OF AMERICA 1745 1746 Advertising; business management; business administration. 1747 1748 1749 Insurance; financial affairs; monetary affairs; real estate. 1750 1751 1752 Bardus populorum circumdabit se cum captiosus populum. 1753 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 1754 1755 1756 1757 Example-One 1758 1759 Example S.A. de C.V. 1760 1761 Calle conocida #343 1762 Conocida 1763 SP 1764 82140 1765 BR 1766 1767 1768 BRAZIL 1769 1770 Bardus populorum circumdabit se cum captiosus populum. 1771 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 1772 1773 1774 1776 This example generates a TRADEMARK NOTICE with two mark claims. 1778 For formal syntax of the Trademark Claims Notice please refer to 1779 Section 7.1. 1781 7. Formal Syntax 1783 7.1. Trademark Claims Notice 1785 The schema presented here is for the Trademark Claims Notice. 1787 Copyright (c) 2012 IETF Trust and the persons identified as authors 1788 of the code. All rights reserved. 1790 Redistribution and use in source and binary forms, with or without 1791 modification, are permitted provided that the following conditions 1792 are met: 1794 o Redistributions of source code must retain the above copyright 1795 notice, this list of conditions and the following disclaimer. 1797 o Redistributions in binary form must reproduce the above copyright 1798 notice, this list of conditions and the following disclaimer in 1799 the documentation and/or other materials provided with the 1800 distribution. 1802 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1803 names of specific contributors, may be used to endorse or promote 1804 products derived from this software without specific prior written 1805 permission. 1807 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1808 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1809 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1810 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1811 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1812 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1813 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1814 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1815 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1816 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1817 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1819 BEGIN 1820 1821 1826 1827 1828 Schema for representing a Trademark Notice. 1829 1830 1831 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1853 1854 1855 1856 1857 1858 1860 1862 1863 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 END 1910 8. Status of this Draft 1912 This draft is the product of several discussions regarding the 1913 interaction between the TMCH and Registries/Registrars. It does by 1914 no means claim to be complete and minor updates are likely to be 1915 added in future versions of this document. 1917 9. Acknowledgements 1919 TBD 1921 10. IANA Considerations 1923 TBD 1925 11. Security Considerations 1927 TBD 1929 12. References 1931 12.1. Normative References 1933 [I-D.lozano-tmch-smd] 1934 Lozano, G., "Mark and Signed Mark Objects Mapping", 1935 draft-lozano-tmch-smd-01 (work in progress), March 2013. 1937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1938 Requirement Levels", BCP 14, RFC 2119, March 1997. 1940 12.2. Informative References 1942 [ICANN-GTLD-AGB-20120604] 1943 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 1944 June 2012, . 1947 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1948 STD 13, RFC 1034, November 1987. 1950 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1951 RFC 1591, March 1994. 1953 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1954 E. Lear, "Address Allocation for Private Internets", 1955 BCP 5, RFC 1918, February 1996. 1957 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1958 Randers-Pehrson, "GZIP file format specification version 1959 4.3", RFC 1952, May 1996. 1961 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1962 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1963 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1965 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1967 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1968 Internet: Timestamps", RFC 3339, July 2002. 1970 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 1971 Separated Values (CSV) Files", RFC 4180, October 2005. 1973 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1974 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1976 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1977 Housley, R., and W. Polk, "Internet X.509 Public Key 1978 Infrastructure Certificate and Certificate Revocation List 1979 (CRL) Profile", RFC 5280, May 2008. 1981 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1982 STD 69, RFC 5730, August 2009. 1984 [RFC5890] Klensin, J., "Internationalized Domain Names for 1985 Applications (IDNA): Definitions and Document Framework", 1986 RFC 5890, August 2010. 1988 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 1989 Infrastructure Certificate and Certificate Revocation List 1990 (CRL) Profile", RFC 6818, January 2013. 1992 [WIPO-NICE-CLASSES] 1993 WIPO, "Nice List of Classes", . 1996 [WIPO.ST3] 1997 WIPO, "Recommended standard on two-letter codes for the 1998 representation of states, other entities and 1999 intergovernmental organizations", March 2007. 2001 Appendix A. Document Changelog 2003 [RFC Editor: This section is to be removed before publication] 2005 draft-lozano-tmch-functional-spec-00: 2007 o Initial version 2009 Authors' Addresses 2011 Gustavo Lozano (editor) 2012 ICANN 2013 12025 Waterfront Drive, Suite 300 2014 Los Angeles 90292 2015 US 2017 Phone: +1.3103015800 2018 Email: gustavo.lozano@icann.org 2020 Bernie Hoeneisen 2021 Ucom Standards Track Solutions GmbH 2022 CH-8000 Zuerich 2023 Switzerland 2025 Phone: +41 44 500 52 44 2026 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 2027 URI: http://www.ucom.ch/