idnits 2.17.1 draft-lozano-tmch-func-spec-08.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 7 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 (Oct 02, 2013) is 3856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1210, but not defined == Unused Reference: 'RFC1918' is defined on line 2416, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 2420, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 2436, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational Oct 02, 2013 5 Expires: April 5, 2014 7 TMCH functional specifications 8 draft-lozano-tmch-func-spec-08 10 Abstract 12 This document describes the requirements, the architecture and the 13 interfaces between the Trademark Clearing House (TMCH) and Domain 14 Name Registries as well as between the TMCH and Domain Name 15 Registrars for the provisioning and management of domain names during 16 Sunrise and Trademark Claims Periods. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 5, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9 57 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 58 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 59 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . . 14 75 5.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.1.1. Registries . . . . . . . . . . . . . . . . . . . . . . 14 77 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 14 78 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 79 5.1.1.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 80 5.1.1.4. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 15 81 5.1.2. 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. TMCH Trust Anchor . . . . . . . . . . . . . . . . 16 85 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 16 86 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 17 87 5.2.1. Domain Name Registration . . . . . . . . . . . . . . . 17 88 5.2.2. DN Registration by Registries . . . . . . . . . . . . 18 89 5.2.3. TMCH Sunrise Services for Registries . . . . . . . . . 19 90 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 19 91 5.2.3.2. Certificate Revocation List . . . . . . . . . . . 20 92 5.2.3.3. Notice of Registered Domain Names . . . . . . . . 21 93 5.2.4. DN registration by Registrars . . . . . . . . . . . . 23 94 5.2.5. TMCH Sunrise Services for Registrars . . . . . . . . . 23 95 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 24 96 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 24 97 5.3.2. DN registration by Registries . . . . . . . . . . . . 25 98 5.3.3. Trademark Claims Services for Registries . . . . . . . 27 99 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 27 100 5.3.3.2. Notice of Registered Domain Names . . . . . . . . 27 101 5.3.4. DN Registration by Registrars . . . . . . . . . . . . 28 102 5.3.5. Trademark Claims Services for Registrars . . . . . . . 29 103 5.3.5.1. Claims Notice Information Service . . . . . . . . 29 104 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 30 105 6.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 30 106 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 32 107 6.3. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 34 108 6.3.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 38 109 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . . 41 110 6.4. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 45 111 6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 47 112 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 113 7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 55 114 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 115 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 58 116 9.1. Changes from draft-lozano-tmch-func-spec-06 to 117 draft-lozano-tmch-func-spec-07 . . . . . . . . . . . . . . 58 118 9.2. Changes from draft-lozano-tmch-func-spec-07 to 119 draft-lozano-tmch-func-spec-08 . . . . . . . . . . . . . . 58 120 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 122 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 123 12.1. Normative References . . . . . . . . . . . . . . . . . . . 59 124 12.2. Informative References . . . . . . . . . . . . . . . . . . 59 125 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 61 126 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 61 128 1. Introduction 130 Domain Name Registries may operate in special modes within certain 131 periods of time to facilitate registration of domain names. 133 Along with the upcoming introduction of new generic Top Level Domains 134 (gTLD), two special modes will come into effect: 136 o Sunrise Period 138 o Trademark Claims Period 140 The Sunrise and Trademark Claims Periods are defined in the gTLD 141 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 143 This document describes the requirements, the architecture and the 144 interfaces between the Trademark Clearing House (TMCH) and Domain 145 Name Registries (called Registries in the rest of the document) as 146 well as between the TMCH and Domain Name Registrars (called 147 Registrars in the rest of the document) for the provisioning and 148 management of domain names during the Sunrise and Trademark Claims 149 Periods. 151 For any date and/or time indications, Coordinated Universal Time 152 (UTC) applies. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 XML is case sensitive. Unless stated otherwise, XML specifications 161 and examples provided in this document MUST be interpreted in the 162 character case presented in order to develop a conforming 163 implementation. 165 "tmNotice-1.0" is used as an abbreviation for 166 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 167 "tmNotice" is used, but implementations MUST NOT depend on it and 168 instead employ a proper namespace-aware XML parser and serializer to 169 interpret and output the XML documents. 171 3. Glossary 173 In the following section, the most common terms are briefly 174 explained: 176 o Effective allocation: A DN is considered effectively allocated 177 when the DN object for the DN has been created in the SRS of the 178 Registry and has been assigned to the effective user. A DN object 179 in status "pendingCreate" or any other status that precedes the 180 first time a DN is assigned to an end-user is not considered an 181 effective allocation. A DN object created internally by the 182 Registry for subsequent delegation to another Registrant is not 183 considered an effective allocation. 185 o Backend Registry Operator: Entity that manages (a part of) the 186 technical infrastructure for a Registry Operator. The Registry 187 Operator may also be the Backend Registry Operator. 189 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 191 o CSV: Comma-Separated Values, see [RFC4180] 193 o CNIS, Claims Notice Information Service: This service provides 194 TCNs to Registrars. 196 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 197 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 199 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 201 o Date and time, datetime: Date and time are specified following the 202 standard "Date and Time on the Internet specification", see 203 [RFC3339]. 205 o DN: Domain Name, domain name, see [RFC1034] 207 o DN Repository Object IDentifier, DNROID: an identifier assigned by 208 the Registry to each DN object that unequivocally identifies said 209 DN object. For example, if a new DN object is created for a name 210 that existed in the past, the DN objects will have different 211 DNROIDs. 213 o DNS: Domain Name System, see [RFC1034] 215 o DNL, Domain Name Label: A label as specified in [RFC1035]. For 216 IDNs the A-Label is used [RFC5890]. 218 o DNL List: A list of DNLs that are covered by a PRM. 220 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 222 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 224 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 226 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246]. 228 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 229 SMD PKI model. 231 o IDN: Internationalized Domain Name, see [RFC5890] 233 o LORDN, List of Registered Domain Names: This is the list of 234 effectively allocated DNs matching a DNL of a PRM. Registries 235 will upload this list to the TMDB (during the NORDN process). 237 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 238 Z0-9/] to be used as the lookup Key by Registrars to obtain the 239 TCN using the CNIS. Lookup Keys are unique and are related to one 240 DNL only. 242 o NORDN, Notification of Registered Domain Names: The process by 243 which Registries upload their recent LORDN to the TMDB. 245 o PGP: Pretty Good Privacy, see [RFC4880] 247 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 249 o PRM, Pre-registered mark: Mark that has been pre-registered with 250 the TMCH. 252 o Registrant: Person or Organization registering a DN via a 253 Registrar. 255 o Registrar, Domain Name Registrar: Entity that registers DNs with 256 the Registry on behalf of the Registrant. 258 o Registry, Registry Operator, Domain Name Registry: Entity that 259 accepts DN registrations from Registrars, maintains the central 260 Database of Registered DNs. A Registry Operator is the 261 contracting party with ICANN for the TLD. 263 o SMD, Signed Mark Data: A cryptographically signed token issued by 264 the TMV to the TMH to be used in the Sunrise Period to apply for a 265 DN that matches a DNL of a PRM; see also [I-D.lozano-tmch-smd] 267 o SMD File: A file containing the SMD (see above) and some human 268 readable data. The latter is usually ignored in the processing of 269 the SMD File. See also Section 6.4. 271 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 272 lists of revoked SMDs (SMD Revocation List); see also 273 [I-D.lozano-tmch-smd] 275 o SMD Revocation List: The SMD Revocation List is used by Registries 276 (and optionally by Registrars) during the Sunrise Period to ensure 277 that an SMD is still valid (i.e. not revoked). The SMD Revocation 278 List has a similar function as CRLs used in PKI. 280 o SRS: Shared Registration System, see also 281 [ICANN-GTLD-AGB-20120604]. 283 o Sunrise Period: During this period DNs matching a DNL of a PRM can 284 be exclusively obtained by the respective TMHs. For DNs matching 285 a PRM, a special process applies to ensure a TMH gets informed on 286 the effective allocation of a DN matching his/her PRM. 288 o TLD: Top Level Domain Name, see [RFC1591] 290 o Trademark, mark: Marks are used to claim exclusive properties of 291 products or services. A mark is typically a name, word, phrase, 292 logo, symbol, design, image, or a combination of these elements. 293 For the scope of this document only textual marks are relevant. 295 o Trademark Claims, Claims: Provides information to enhance the 296 understanding of the Trademark rights being claimed by the TMH. 298 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 299 Trademark Claims Notice consist of one or more Trademark Claims 300 and are provided to prospective Registrants of DNs. 302 o Trademark Claims Notice Identifier, TCNID: An element of the 303 Trademark Claims Notice (see above), identifying said TCN. The 304 Trademark Claims Notice Identifier is specified in the element 305 . 307 o Trademark Claims Period: During this period, a special process 308 applies to DNs matching the DNL List, to ensure a TMH gets 309 informed of a DN matching his PRM. For DNs matching the DNL List, 310 Registrars show a TCN to prospective Registrants that has to be 311 acknowledged before effective allocation of the DN. 313 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 314 ICANN central repository for information to be authenticated, 315 stored, and disseminated, pertaining to the rights of TMHs. The 316 Trademark Clearinghouse is split into two functions TMV and TMDB 317 (see below). There could be several entities performing the TMV 318 function, but only one entity performing the TMDB function. 320 o TMDB, Trademark Clearinghouse Database: Serves as a database of 321 the TMCH to provide information to the new gTLD Registries and 322 Registrars to support Sunrise or Trademark Claims Services. There 323 is only one TMDB in the TMCH that concentrates the information 324 about the "verified" Trademark records from the TMVs. 326 o TMH, Trademark Holder: The person or organization owning rights on 327 a mark. 329 o TMV, Trademark Validator, Trademark validation organization: An 330 entity authorized by ICANN to authenticate and validate 331 registrations in the TMDB ensuring the marks qualify as registered 332 or are court-validated marks or marks that are protected by 333 statute or treaty. This entity would also be asked to ensure that 334 proof of use of marks is provided, which can be demonstrated by 335 furnishing a signed declaration and one specimen of current use. 337 o UTC: Coordinated Universal Time, as maintained by the Bureau 338 International des Poids et Mesures (BIPM); see also [RFC3339]. 340 4. Architecture 342 4.1. Sunrise Period 344 Architecture Sunrise Period 346 SMD hand over (out of band; 347 trivial if Registrant == TMH) 348 ........................................... 349 : : 350 : .'''''''''''''''''''. : 351 : . TMCH . : 352 : ..................... : 353 v . . : 354 .------------. . .-------------. . hv .-----. 355 | Registrant | . | TMV |<------->| TMH | 356 '------------' . '-------------' . vh '-----' 357 | . | ^ \ . 358 | . | | \. 359 tr | . vs | | \ 360 | . | | dv .\ 361 v . v | . \ 362 .-----------. sr . .---. | . \ 363 .->| Registrar |<.........| S | vd | . \ 364 : '-----------' . | M | | . \ 365 : | sy . | D | v . \ 366 : ry | .-----------| M | .---. . vc \ 367 : | | . '---' | T | . \ 368 : v v . | M | . v 369 : .-----------. . | D | . .----------. 370 : | Registry |----------------->| B | . | ICANN-CA | 371 : '-----------' . yd '---' . '----------' 372 : ^ . . | : 373 : | ''''''''''''''''''' | : 374 : | cy | : 375 : cr '---------------------------------------' : 376 :.....................................................: 378 Figure 1 380 4.2. Trademark Claims Period 382 Architecture Trademark Claims Period 384 .'''''''''''''. 385 . TMCH . 386 ............... 387 . . 388 .------------. . .-------. . hv .-----. 389 | Registrant | . | TMV |<------->| TMH | 390 '------------' . '-------' . vh '-----' 391 | . ^ . 392 tr | . | dv . 393 | . vd | . 394 v . v . 395 .-----------. dr . .-------. . 396 | Registrar |<--------| T | . 397 '-----------' . | | . 398 | . | M | . 399 ry | . | | . 400 v . | D | . 401 .----------. dy . | | . 402 | Registry |<------->| B | . 403 '----------' yd . '-------' . 404 . . 405 ''''''''''''' 407 Figure 2 409 4.3. Interfaces 411 In the sub-sections below follows a short description of each 412 interface to provide an overview of the architecture. More detailed 413 descriptions of the relevant interfaces follow further below 414 (Section 5). 416 4.3.1. hv 418 The TMH registers a mark with a TMV via the hv interface. 420 After the successful registration of the mark, the TMV makes 421 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 422 TMH to be used during the Sunrise Period. 424 The specifics of the hv interface are beyond the scope of this 425 document. 427 4.3.2. vd 429 After successful mark registration, the TMV ensures the TMDB inserts 430 the corresponding DNLs and mark information into the database via the 431 vd interface. 433 The specifics of the vd interface are beyond the scope of this 434 document. 436 4.3.3. dy 438 Not used during the Sunrise Period. 440 During the Trademark Claims Period the Registry fetches the latest 441 DNL List from the TMDB via the dy interface in regular intervals. 442 The protocol used on the dy interface is HTTPS. 444 4.3.4. tr 446 The Registrant communicates with the Registrar via the tr interface. 448 The specifics of the tr interface are beyond the scope of this 449 document. 451 4.3.5. ry 453 The Registrar communicate with the Registry via the ry interface. 454 The ry interfaces is typically implemented in EPP [RFC5730]. 456 4.3.6. dr 458 Not used during the Sunrise Period. 460 During the Trademark Claims Period, the Registrar fetches the TCN 461 from the TMDB (to be displayed to the Registrant via the tr 462 interface) via the dr interface. The protocol used for fetching the 463 TCN is HTTPS [RFC2818]. 465 4.3.7. yd 467 During the Sunrise period the Registry notifies the TMDB via the yd 468 interface of all DNs effectively allocated. 470 During the Trademark Claims period, the Registry notifies the TMDB 471 via the yd interface of all DNs effectively allocated that matched an 472 entry in the Registry previously downloaded DNL List during the 473 creation of the DN. 475 The protocol used on the yd interface is HTTPS. 477 4.3.8. dv 479 The TMDB notifies via the dv interface to the TMV of all DNs 480 effectively allocated that match a mark registered by that TMV. 482 The specifics of the dv interface are beyond the scope of this 483 document. 485 4.3.9. vh 487 The TMV notifies the TMH via the vh interface after a DN has been 488 effectively allocated that matches a PRM of this TMH. 490 The specifics of the vh interface are beyond the scope of this 491 document. 493 4.3.10. vs 495 The TMV requests to add a revoked SMD to the SMD Revocation List at 496 the SMDM. 498 The specifics of the vs interface are beyond the scope of this 499 document. 501 Not relevant during the Trademark Claims Period. 503 4.3.11. sy 505 During the Sunrise Period the Registry fetches the most recent SMD 506 Revocation List from the SMDM via the sy interface in regular 507 intervals. The protocol used on the sy interface is HTTPS. 509 Not relevant during the Trademark Claims Period. 511 4.3.12. sr 513 During the Sunrise Period the Registrar may fetch the most recent SMD 514 Revocation List from the SMDM via the sr interface. The protocol 515 used on the sr interface is the same as on the sy interface (s. 516 above), i.e. HTTPS. 518 Not relevant during the Trademark Claims Period. 520 4.3.13. vc 522 The TMV requests to add a revoked TMV certificate to the CRL at the 523 ICANN-CA via the vc interface. 525 The specifics of the vc interface are beyond the scope of this 526 document. 528 Not relevant during the Trademark Claims Period. 530 4.3.14. cy 532 During the Sunrise Period the Registry fetches the most recent CRL 533 from the ICANN-CA via the cy interface in regular intervals. The CRL 534 is mainly used for validation of TMV certificates. The protocol used 535 on the cy interface is HTTPS [RFC2818]. 537 Not relevant during the Trademark Claims Period. 539 4.3.15. cr 541 During the Sunrise Period the Registrar may fetch the most recent CRL 542 from the ICANN-CA via the cr interface. The protocol used on the cr 543 interface is the same as on the cy interface. 545 Not relevant during the Trademark Claims Period. 547 5. Process Descriptions 549 5.1. Bootstrap 551 5.1.1. Registries 553 5.1.1.1. Credentials 555 Each Registry Operator will receive authentication credentials from 556 the TMDB/SMDM to be used: 558 o During the Sunrise Period to fetch the SMD Revocation List from 559 the SMDM via the sy interface (Section 4.3.11). 561 o During Trademark Claims Period to fetch the DNL List from the TMDB 562 via the dy interface (Section 4.3.3). 564 o During the NORDN process to notify the LORDN to the TMDB via the 565 yd interface (Section 4.3.7). 567 Note: credentials are created per TLD and provided to the Registry 568 Operator. 570 5.1.1.2. IP Addresses for Access Control 572 Each Registry Operator MUST provide to the TMDB all IP addresses that 573 will be used to: 575 o Fetch the SMD Revocation List via the sy interface 576 (Section 4.3.11). 578 o Fetch the DNL List from the TMDB via the dy interface 579 (Section 4.3.3). 581 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 583 This access restriction MAY be applied by the TMDB/SMDM in addition 584 to HTTP Basic access authentication (for credentials to be used, see 585 Section 5.1.1.1). 587 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 588 Registry Operator. 590 5.1.1.3. TMCH Trust Anchor 592 Each Registry Operator MUST fetch the X.509 certificate ([RFC5280] / 593 [RFC6818]) of the ICANN-CA (Trust Anchor) from 594 < https://ca.icann.org/tmch.crt > to be used: 596 o During the Sunrise Period to validate the TMV certificates and the 597 CRL of TMV certificates. 599 5.1.1.4. TMDB/SMDM PGP Key 601 The TMDB MUST provide each Registry Operator with the public portion 602 of the PGP Key used by TMDB and SMDM, to be used: 604 o During the Sunrise Period to perform integrity checking of the SMD 605 Revocation List fetched from the SMDM via the sy interface 606 (Section 4.3.11). 608 o During Trademark Claims Period to perform integrity checking of 609 the DNL List fetched from the TMDB via the dy interface 610 (Section 4.3.3). 612 5.1.2. Registrars 614 5.1.2.1. Credentials 616 Each ICANN-accredited Registrar will receive authentication 617 credentials from the TMDB to be used: 619 o During the Sunrise Period to (optionally) fetch the SMD Revocation 620 List from the SMDM via the sr interface (Section 4.3.12). 622 o During Trademark Claims Period to fetch TCNs from the TMDB via the 623 dr interface (Section 4.3.6). 625 5.1.2.2. IP Addresses for Access Control 627 Each Registrar MUST provide to the TMDB all IP addresses, which will 628 be used to: 630 o Fetch the SMD Revocation List via the sr interface 631 (Section 4.3.12). 633 o Fetch TCNs via the dr interface (Section 4.3.6). 635 This access restriction MAY be applied by the TMDB/SMDM in addition 636 to HTTP Basic access authentication (for credentials to be used, see 637 Section 5.1.2.1). 639 The TMDB MAY limit the number of IP addresses to be accepted per 640 Registrar. 642 5.1.2.3. TMCH Trust Anchor 644 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 645 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 646 be used: 648 o During the Sunrise Period to (optionally) validate the TMV 649 certificates and the CRL of TMV certificates. 651 5.1.2.4. TMDB PGP Key 653 Registrars MUST receive the public portion of the PGP Key used by 654 TMDB and SMDM from the TMDB administrator to be used: 656 o During the Sunrise Period to (optionally) perform integrity 657 checking of the SMD Revocation List fetched from the SMDM via the 658 sr interface (Section 4.3.12). 660 5.2. Sunrise Period 662 5.2.1. Domain Name Registration 664 Registration during Sunrise Period 666 .------------. .-----------. .----------. 667 | Registrant | | Registrar | | Registry | 668 '------------' '-----------' '----------' 669 ^ | | | 670 | | Request DN | | 671 | | Registration | | 672 | | (with SMD) | | 673 | |------------->| Check DN availability | 674 | | |---------------------------->| 675 | | | | 676 | | DN unava. | DN unavailable .-------------. 677 '---|<-------------|<--------------------( DN available? ) 678 | | no '-------------' 679 | | | yes 680 | | DN available | 681 | |<----------------------------| 682 | | | 683 | | Request DN registration | 684 | | (with SMD) | 685 | |---------------------------->| 686 | | | 687 | | .------------------------------. 688 | | | DN registration validation / | 689 | | | SMD validation | 690 | | '------------------------------' 691 | Registration | | 692 | Error |.-----------. Error .----------------------. 693 |<-------------|| TRY AGAIN |<------( Validation successful? ) 694 | || / ABORT | no '----------------------' 695 | |'-----------' | yes 696 | | | 697 | | DN registered | 698 | DN regist. |<----------------------------| 699 |<-------------| | 700 | | | 702 Figure 3 704 5.2.2. DN Registration by Registries 706 Registries MUST perform a minimum set of checks for verifying each DN 707 registration during the Sunrise Period upon reception of a 708 registration request over the ry interface (Section 4.3.5). If any 709 of these checks fails the Registry MUST abort the registration. Each 710 of these checks MUST be performed before the DN is effectively 711 allocated. 713 In case of asynchronous registrations (e.g. auctions), the minimum 714 set of checks MAY be performed when creating the intermediate object 715 (e.g. a DN application) used for DN registration. If the minimum set 716 of checks is performed when creating the intermediate object (e.g. a 717 DN application) a Registry MAY effective allocate the DN without 718 performing the minimum set of checks again. 720 Performing the minimum set of checks Registries MUST verify that: 722 1. A SMD has been received from the Registrar along with the DN 723 registration. 725 2. The certificate of the TMV has been correctly signed by the 726 ICANN-CA. (The certificate of the TMV is contained within the 727 SMD.) 729 3. The time when the validation is done is within the validity 730 period of the TMV certificate. 732 4. The certificate of the TMV is not be listed in the CRL file 733 specified in the CRL distribution point of the TMV certificate. 735 5. The signature of the SMD (signed with the TMV certificate) is 736 valid. 738 6. The time when the validation is done is within the validity 739 period of the SMD based on and 740 elements. 742 7. The SMD has not been revoked, i.e., is not contained in the SMD 743 Revocation List. 745 8. The leftmost DNL (A-label in case of IDNs) of the DN being 746 effectively allocated matches one of the labels () 747 elements in the SMD. 749 These procedure apply to all DN effective allocations at the second 750 level as well as to all other levels subordinate to the TLD that the 751 Registry accepts registrations for. 753 5.2.3. TMCH Sunrise Services for Registries 755 5.2.3.1. SMD Revocation List 757 A new SMD Revocation List MUST be published by the SMDM twice a day, 758 by 00:00:00 and 12:00:00 UTC. 760 Registries MUST refresh the latest version of the SMD Revocation List 761 at least once every 24 hours. 763 Note: the SMD Revocation List will be the same regardless of the TLD. 764 If a Backend Registry Operator manages the infrastructure of several 765 TLDs, the Backend Registry Operator could refresh the SMD Revocation 766 List once every 24 hours, the SMD Revocation List could be used for 767 all the TLDs managed by the Backend Registry Operator. 769 Update SMD Revocation List 771 .----------. .------. 772 | Registry | | SMDM | 773 '----------' '------' 774 | | 775 .----------------. | 776 | Periodically, | | 777 | at least | | 778 | every 24 hours | | 779 '----------------' | 780 | | 781 |----------------------------------------------------->| 782 | Download latest revocation list for SMD certificates | 783 |<-----------------------------------------------------| 784 | | 785 | | 787 Figure 4 789 5.2.3.2. Certificate Revocation List 791 Registries MUST refresh their local copy of the CRL at least every 24 792 hours using the CRL distribution point specified in the TMV 793 certificate. 795 Operationally, the CRL file and CRL distribution point is the same 796 for all TMVs and (at publication of this document) located at 797 < http://crl.icann.org/tmch.crl >. 799 Note: the CRL file will be the same regardless of the TLD. If a 800 Backend Registry Operator manages the infrastructure of several TLDs, 801 the Backend Registry Operator could refresh the CRL file once every 802 24 hours, the CRL file could be used for all the TLDs managed by the 803 Backend Registry Operator. 805 Update CRL for TMV certificates 807 .----------. .----------. 808 | Registry | | ICANN-CA | 809 '----------' '----------' 810 | | 811 .----------------. | 812 | Periodically, | | 813 | at least | | 814 | every 24 hours | | 815 '----------------' | 816 | | 817 |------------------------------------------->| 818 | Download latest CRL for TMV certificates | 819 |<-------------------------------------------| 820 | | 821 | | 823 Figure 5 825 5.2.3.3. Notice of Registered Domain Names 827 The Registry MUST send a LORDN file containing DNs effectively 828 allocated to the TMDB (over the yd interface, Section 4.3.7). 830 The effective allocation of a DN MUST be reported by the Registry to 831 the TMDB within 26 hours of the effective allocation of such DN. 833 The Registry MUST create and upload a LORDN file in case there are 834 effective allocations in the SRS, that have not been successfully 835 reported to the TMDB in a previous LORDN file. 837 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 838 maximum frequency to upload LORDN files from the Registries to the 839 TMDB is every 3 hours. 841 It is RECOMMENDED that Registries try to upload at least two LORDN 842 files per day to the TMDB with enough time in between, in order to 843 have time to fix problems reported in the LORDN file. 845 The Registry SHOULD upload a LORDN file only when the previous LORDN 846 file has been processed by the TMDB and the related LORDN Log file 847 has been downloaded and processed by the Registry. 849 The Registry MUST upload LORDN files for DNs effectively allocated 850 during the Sunrise or Claims period (same applies to DNs effectively 851 allocated using applications created during the Sunrise or Claims 852 period in case of using asynchronous registrations). 854 The yd interface (Section 4.3.7) MUST support at least 1 and MAY 855 support up to 10 concurrent connections from each IP address 856 registered by a Registry Operator to access the service. 858 The TMDB MUST process each uploaded LORDN file and make the related 859 log file available for Registry download within 30 minutes of the 860 finalization of the upload. 862 NORDN 864 .----------. .------. .-----. .-----. 865 | Registry | | TMDB | | TMV | | TMH | 866 '----------' '------' '-----' '-----' 867 | | | | 868 .------------------. | | | 869 | Periodically | | | | 870 | upload LORDN | | | | 871 | file | | | | 872 '------------------' | | | 873 | | | | 874 .--------->| Upload LORDN | | | 875 | |-------------------->| | | 876 | | | | | 877 | | .-------------------------. | | 878 | | | Verify each domain name | | | 879 | | | in the uploaded file | | | 880 | | | (within 30') | | | 881 | | '-------------------------' | | 882 | | | ._____. | | 883 | | Download Log file | | END | | | 884 | |<--------------------| '-----' | | 885 | | | ^ | | 886 | .-----------------. .---------------. | | | 887 | | Check whether | / everything fine \ no | | | 888 | | Log file | ( (i.e. no errors )---' | | 889 | | contains errors | \ in Log file )? / | | 890 | '-----------------' '---------------' | | 891 | | | yes | | 892 | .---------------. | | | 893 | / everything fine \ yes | | | 894 |( (i.e. no errors )-----. | Notify TMVs | | 895 | \ in Log file )? / | | on the LORDN | | 896 | '---------------' | | pre-registered | | 897 | | no v | with said TMV | | 898 | .----------------. .------. |--------------->| | 899 '-| Correct Errors | | DONE | | | | 900 '----------------' '------' | | Notify each | 901 | | | affected TMH | 902 | | |------------->| 903 | | | | 905 Figure 6 907 The format used for the LORDN is described in Section 6.3 909 5.2.4. DN registration by Registrars 911 Registrars MAY choose to perform the checks for verifying DN 912 registrations as performed by the Registries (see Section 5.2.2) 913 before sending the command to register a DN. 915 5.2.5. TMCH Sunrise Services for Registrars 917 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 918 also available for Registrars to optionally validate the SMDs 919 received. 921 5.3. Trademark Claims Period 923 5.3.1. Domain Registration 925 Registration during Trademark Claims Period 927 .------------. .-----------. .----------. .------. 928 | Registrant | | Registrar | | Registry | | TMDB | 929 '------------' '-----------' '----------' '------' 930 ^ | Request DN | | | 931 | | Registration | Check DN availability | | 932 | |------------->|---------------------------->| | 933 | | DN unava. | DN unavailable .-------------. | 934 '---|<-------------|<--------------------( DN available? ) | 935 | | no '-------------' | 936 | | | yes | 937 | | DN available | | 938 | |<----------------------------| | 939 | | Request Lookup key | | 940 | |---------------------------->| | 941 | | .---------. | 942 | |.----------. / Does DN \ | 943 | || CONTINUE |<---------( match DNL ) | 944 | || NORMALLY | no \ of PRM? / | 945 | |'----------' '---------' | 946 | | | yes | 947 | | Lookup key | | 948 | |<----------------------------| | 949 | | Request Claims Notice | 950 | Display |----------------------------------------->| 951 | Claims | | 952 | Notice | Return Claims Notice | 953 |<-------------|<-----------------------------------------| 954 | | | 955 .------. yes | Register DN (TCNID included) | 956 ( Ack? )--------->|---------------------------->| | 957 '------' | | | 958 ||no | Error .----------------------. | 959 || .-------. |<--------------( Validation successful? ) | 960 |'->| ABORT | | no '----------------------' | 961 | '-------' | | yes | 962 | DN regist. | DN registered | | 963 |<-------------|<----------------------------| | 964 | | | | 966 Figure 7 968 5.3.2. DN registration by Registries 970 During Trademark Claim Periods, Registries perform two main 971 functions: 973 o Registries MUST provide Registrars (over the ry interface, 974 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 975 that match the DNL List. 977 o Registries MUST provide the Lookup Key only when queried about a 978 specific DN. 980 o For each DN matching a DNL of a PRM, Registries MUST perform a 981 minimum set of checks for verifying DN registrations during 982 Trademark Claims Period upon reception of a registration request 983 over the ry interface (Section 4.3.5). If any of these checks 984 fails the Registry MUST abort the registration. Each of these 985 checks MUST be performed before the DN is effectively allocated. 987 o In case of asynchronous registrations (e.g. auctions), the minimum 988 set of checks MAY be performed when creating the intermediate 989 object (e.g. a DN application) used for DN effective allocation. 990 If the minimum set of checks is performed when creating the 991 intermediate object (e.g. a DN application) a Registry MAY 992 effective allocate the DN without performing the minimum set of 993 checks again. 995 o Performing the minimum set of checks Registries MUST verify that: 997 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been 999 received from the Registrar along with the DN registration. 1001 If the three elements mentioned above are not provided by 1002 the Registrar for a DN matching a DNL of a PRM, but the DNL 1003 was inserted (or re-inserted) for the first time into DNL 1004 List less than 24 hours ago, the registration MAY continue 1005 without this data and the tests listed below are not 1006 required to be performed. 1008 2. The TCN has not expired (according to the expiration datetime 1009 sent by the Registrar). 1011 3. The acceptance datetime is no more than 48 hours in the past. 1013 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1014 being registered, the expiration datetime provided by the 1015 registrar, and the TMDB Notice Identifier extracted from the 1016 TCNID provided by the registrar compute the TCN Checksum. 1017 Verify that the computed TCN Checksum match the TCN Checksum 1018 present in the TCNID. 1020 These procedures apply to all DN registrations at the second level as 1021 well as to all other levels subordinate to the TLD that the Registry 1022 accepts registrations for. 1024 5.3.3. Trademark Claims Services for Registries 1026 5.3.3.1. Domain Name Label (DNL) List 1028 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1029 and 12:00:00 UTC. 1031 Registries MUST refresh the latest version of the DNL List at least 1032 once every 24 hours. 1034 Update DNL List 1036 .----------. .------. 1037 | Registry | | TMDB | 1038 '----------' '------' 1039 | | 1040 .----------------. | 1041 | Periodically, | | 1042 | at least | | 1043 | every 24 hours | | 1044 '----------------' | 1045 | | 1046 |-------------------------------->| 1047 | Download latest list of DNLs | 1048 |<--------------------------------| 1049 | | 1050 | | 1052 Figure 8 1054 Note: the DNL List will be the same regardless of the TLD. If a 1055 Backend Registry Operator manages the infrastructure of several TLDs, 1056 the Backend Registry Operator could refresh the DNL List once every 1057 24 hours, the DNL List could be used for all the TLDs managed by the 1058 Backend Registry Operator. 1060 5.3.3.2. Notice of Registered Domain Names 1062 The NORDN process during the Trademark Claims Period is almost the 1063 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1064 difference that only registrations subject to a Trademark Claim 1065 (i.e., at registration time the name appeared in the current DNL List 1066 downloaded by the Registry Operator) are included in the LORDN. 1068 5.3.4. DN Registration by Registrars 1070 For each DN matching a DNL of a PRM, Registrars MUST perform the 1071 following steps: 1073 1. Use the Lookup Key received from the Registry to obtain the TCN 1074 from the TMDB using the dr interface (Section 4.3.6) Registrars 1075 MUST only query for the Lookup Key of a DN that is available for 1076 registration. 1078 2. Present the TCN to the Registrant as described in 1079 [ICANN-GTLD-AGB-20120604]. 1081 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1082 consent with the TCN, before any further processing. (The 1083 transmission of a TCNID to the Registry over the ry interface, 1084 Section 4.3.5 implies that the Registrant has expressed his 1085 consent with the TCN.) 1087 4. Perform the minimum set of checks for verifying DN registrations. 1088 If any of these checks fails the Registrar MUST abort the DN 1089 registration. Each of these checks MUST be performed before the 1090 registration is sent to the Registry. Performing the minimum set 1091 of checks Registrars MUST verify that: 1093 1. The time when the validation is done is within the TCN 1094 validity based on the and elements. 1097 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1098 effectively allocated matches the label () 1099 element in the TCN. 1101 3. The Registrant has acknowledged (expressed his consent with) 1102 the TCN. 1104 5. Record the date and time when the registrant acknowledged the 1105 TCN. 1107 6. Send the registration to the Registry (ry interface, 1108 Section 4.3.5) and include the following information: 1110 * TCNID () 1112 * Expiration date of the TCN () 1114 * Acceptance datetime of the TCN. 1116 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the 1118 TMDB, allowing the implementation of a cache by Registrars and enough 1119 time for acknowledging the TCN. Registrars SHOULD implement a cache 1120 of TCNs to minimize the number of queries sent to the TMDB. A cached 1121 TCN MUST be removed from the cache after the expiration date of the 1122 TCN as defined by . The TMDB MAY implement rate- 1123 limiting as one of the protection mechanisms to mitigate the risk of 1124 performance degradation. 1126 5.3.5. Trademark Claims Services for Registrars 1128 5.3.5.1. Claims Notice Information Service 1130 The TCNs are provided by the TMDB online and are fetched by the 1131 Registrar via the dr interface (Section 4.3.6). 1133 To get access to the TCNs, the Registrar needs the credentials 1134 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1135 from the Registry via the ry interface (Section 4.3.5). The dr 1136 interface (Section 4.3.6) uses HTTPS with Basic access 1137 authentication. 1139 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1140 connections from each Registrar. 1142 The URL of the dr interface (Section 4.3.6) is: 1144 < https:///cnis/.xml > 1146 Note that the "lookupkey" may contain SLASH characters ("/"). The 1147 SLASH character is part of the URL path and MUST NOT be escaped when 1148 requesting the TCN. 1150 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1151 MUST be signed by a well-know public CA. Registrars MUST perform the 1152 Certification Path Validation described in Section 6 of [RFC5280]. 1153 Registrars will be authenticated in the dr interface using HTTP Basic 1154 access authentication. The dr (Section 4.3.6) interface MUST support 1155 HTTPS keep-alive and MUST maintain the connection for up to 30 1156 minutes. 1158 6. Data Format Descriptions 1160 6.1. DNL List file 1162 This section defines format of the list containing every Domain Name 1163 Label (DNL) that matches a Pre-Registered Mark (PRM). The list is 1164 maintained by the TMDB and downloaded by Registries in regular 1165 intervals (see Section 5.3.3.1). The Registries use the DNL List 1166 during the Trademark Claims period to check whether a requested DN 1167 matched a DNL of a PRM. 1169 The DNL List contains all the DNLs covered by a PRM present in the 1170 TMDB at the time it is generated. 1172 The DNL List is contained in a CSV-like formatted file that has the 1173 following structure: 1175 o first line: , 1177 Where: 1179 + , version of the file, this field MUST be 1. 1181 + , date and time in UTC that the 1182 DNL List was created. 1184 o second line: a header line as specified in [RFC4180] 1186 With the header names as follows: 1188 DNL,lookup-key,insertion-datetime 1190 o One or more lines with: ,, 1193 Where: 1195 + , a Domain Name Label covered by a PRM. 1197 + , lookup key that the Registry MUST provide to 1198 the Registrar. The lookup key has the following format: 1199
////, where: 1202 - YYYY: year that the TCN was generated. 1204 - MM: zero-padded month that the TCN was generated. 1206 - DD: zero-padded day that the TCN was generated. 1208 - vv: version of the TCN, possible values are 00 and 01. 1210 - X: one hexadecimal digit [0-9A-F]. This is the first, 1211 second and third hexadecimal digit of encoding the 1212 in base16 as specified in [RFC4648]. 1214 - Random bits: 144 random bits encoded in base64url as 1215 specified in [RFC4648]. 1217 - Sequential number: zero-padded natural number in the 1218 range 0000000001 to 2147483647. 1220 + , datetime in UTC that the DNL was 1221 first inserted into the DNL List. The possible two values 1222 of time for inserting a DNL to the DNL List are 00:00:00 and 1223 12:00:00 UTC. 1225 Example for DNL List 1227 1,2012-08-16T00:00:00.0Z 1228 DNL,lookup-key,insertion-datetime 1229 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1230 2010-07-14T00:00:00.0Z 1231 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1232 2012-08-16T00:00:00.0Z 1233 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1234 2011-08-16T12:00:00.0Z 1236 Figure 9 1238 To provide authentication and integrity protection, the DNL List will 1239 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1240 (see also Section 5.1.1.4). The PGP signature of the DNL List can be 1241 found in the similar URI but with extension .sig as shown below. 1243 The URL of the dy interface (Section 4.3.3) is: 1245 o < https:///dnl/dnl-latest.csv > 1247 o < https:///dnl/dnl-latest.sig > 1249 6.2. SMD Revocation List 1251 This section defines the format of the list of SMDs that have been 1252 revoked. The list is maintained by the SMDM and downloaded by 1253 Registries (and optionally by Registrars) in regular intervals (see 1254 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1255 Period to validate SMDs received. The SMD Revocation List has a 1256 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1258 The SMD Revocation List contains all the revoked SMDs present in the 1259 TMDB at the time it is generated. 1261 The SMD Revocation List is contained in a CSV-like formatted file 1262 that has the following structure: 1264 o first line: , 1266 Where: 1268 + , version of the file, this field MUST be 1. 1270 + , datetime in UTC 1271 that the SMD Revocation List was created. 1273 o second line: a header line as specified in [RFC4180] 1275 With the header names as follows: 1277 smd-id,insertion-datetime 1279 o One or more lines with: , 1281 Where: 1283 + , identifier of the SMD that was revoked. 1285 + , revocation datetime in UTC of the 1286 SMD. The possible two values of time for inserting an SMD 1287 to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. 1289 To provide integrity protection, the SMD Revocation List is PGP 1290 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1291 also Section 5.1.1.4). The SMD Revocation List is provided by the 1292 TMDB with extension .csv. The PGP signature of the SMD Revocation 1293 List can be found in the similar URI but with extension .sig as shown 1294 below. 1296 The URL of the sr interface (Section 4.3.12) and sy interface 1297 (Section 4.3.11) is: 1299 o < https:///smdrl/smdrl-latest.csv > 1301 o < https:///smdrl/smdrl-latest.sig > 1303 Example for SMD Revocation list 1305 1,2012-08-16T00:00:00.0Z 1306 smd-id,insertion-datetime 1307 2-2,2012-08-15T00:00:00.0Z 1308 3-2,2012-08-15T00:00:00.0Z 1309 1-2,2012-08-15T00:00:00.0Z 1311 Figure 10 1313 6.3. LORDN File 1315 This section defines the format of the List of Registered Domain 1316 Names (LORDN), which is maintained by each Registry and uploaded at 1317 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1318 said DN is added to the LORDN along with further information related 1319 to its registration. 1321 The URI of the yd interface (Section 4.3.7) used to upload the LORDN 1322 file is: 1324 o Sunrise LORDN file: 1326 < https:///LORDN//sunrise > 1328 o Claims LORDN file: 1330 < https:///LORDN//claims > 1332 The yd interface (Section 4.3.7) returns the following HTTP status 1333 codes after a HTTP POST request method is received: 1335 o The interface provides a HTTP/202 status code if the interface was 1336 able to receive the LORDN file and the syntax of the LORDN file is 1337 correct. 1339 The interface provides the LORDN Transaction Identifier in the 1340 HTTP Entity-body that would be used by the Registry to download 1341 the LORDN Log file. The LORDN Transaction Identifier is a 1342 natural number zero-padded in the range 0000000000000000001 to 1343 9223372036854775807. 1345 The TMDB uses the element of the 1346 LORDN file as a unique client-side identifier. If a LORDN file 1347 with the same of a previously sent 1348 LORDN file is received by the TMDB, the LORDN Transaction 1349 Identifier of the previously sent LORDN file MUST be provided 1350 to the Registry. The TMDB MUST ignore the DN Lines present in 1351 the LORDN file if a LORDN file with the same was previously sent. 1354 The HTTP Location header field contains the URI where the LORDN 1355 Log file could be retrieved later, for example: 1357 202 Accepted 1359 Location: https:///LORDN/example/sunrise/ 1360 0000000000000000001/result 1362 o The interface provides a HTTP/400 if the request is incorrect or 1363 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1364 human readable message in the HTTP Entity-body regarding the 1365 incorrect syntax of the LORDN file. 1367 o The interface provides a HTTP/401 status code if the credentials 1368 provided does not authorize the Registry Operator to upload a 1369 LORDN file. 1371 o The interface provides a HTTP/500 status code if the system is 1372 experiencing a general failure. 1374 For example, to upload the Sunrise LORDN file for TLD "example", the 1375 URI would be: 1377 < https:///LORDN/example/sunrise > 1379 The LORDN is contained in a CSV-like formatted file that has the 1380 following structure: 1382 o For Sunrise Period: 1384 * first line: ,, 1387 Where: 1389 - , version of the file, this field MUST be 1. 1391 - , date and time in UTC that the 1392 LORDN was created. 1394 - , number of DN Lines present in the 1395 LORDN file. 1397 * second line: a header line as specified in [RFC4180] 1399 With the header names as follows: 1401 roid,domain-name,SMD-id,registrar-id,registration- 1402 datetime,application-datetime 1404 * One or more lines with: ,,,,, 1408 Where: 1410 - , DN Repository Object IDentifier (DNROID) in the 1411 SRS. 1413 - , DN that was effectively allocated. For 1414 IDNs the A-Label is used [RFC5890] 1416 - , SMD ID used for registration. 1418 - , IANA Registrar ID. 1420 - , date and time in UTC that the 1421 domain was effectively allocated. 1423 - OPTIONAL , date and 1424 time in UTC that the application was created. The 1425 MUST be provided in 1426 case of a DN effective allocation based on an 1427 asynchronous registration (e.g., when using auctions). 1429 Example for LORDN during Sunrise 1431 1,2012-08-16T00:00:00.0Z,3 1432 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1433 application-datetime 1434 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1435 2012-07-15T00:50:00.0Z 1436 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1437 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1439 Figure 11 1441 o For Trademark Claims Period: 1443 * first line: ,, 1446 Where: 1448 - , version of the file, this field MUST be 1. 1450 - , date and time in UTC that the 1451 LORDN was created. 1453 - , number of DN Lines present in the 1454 LORDN file. 1456 * second line: a header line as specified in [RFC4180] 1458 With the header names as follows: 1460 roid,domain-name,notice-id,registrar-id,registration- 1461 datetime,ack-datetime,application-datetime 1463 * One or more lines with: ,,,,,, 1467 Where: 1469 - , DN Repository Object IDentifier (DNROID) in the 1470 SRS. 1472 - , DN that was effectively allocated. For 1473 IDNs the A-Label is used [RFC5890]. 1475 - , Trademark Claims Notice Identifier as specified 1476 in . 1478 - , IANA Registrar ID. 1480 - , date and time in UTC that the 1481 domain was effectively allocated. 1483 - , date and time in UTC 1484 that the TCN was acknowledged. 1486 - OPTIONAL , date and 1487 time in UTC that the application was created. The 1488 MUST be provided in 1489 case of a DN effective allocation based on an 1490 asynchronous registration (e.g., when using auctions). 1492 For a DN matching a DNL of a PRM at the moment of 1493 registration, created without the TCNID, expiration datetime 1494 and acceptance datetime, because DNL was inserted (or re- 1495 inserted) for the first time into DNL List less than 24 1496 hours ago, the string "recent-dnl-insertion" MAY be 1497 specified in and . 1500 Example for LORDN during Claims 1502 1,2012-08-16T00:00:00.0Z,3 1503 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1504 ack-datetime,application-datetime 1505 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1506 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1507 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1508 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1509 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1510 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1512 Figure 12 1514 6.3.1. LORDN Log File 1516 After reception of the LORDN file, the TMDB verifies its content for 1517 syntactical and semantical correctness. The output of the LORDN file 1518 verification is retrieved using the yd interface (Section 4.3.7). 1520 The URI of the yd interface (Section 4.3.7) used to retrieve the 1521 LORDN Log File is: 1523 o Sunrise LORDN Log file: 1525 < https:///LORDN//sunrise/ 1526 /result > 1528 o Claims LORDN Log file: 1530 < https:///LORDN//claims/ 1531 /result > 1533 A Registry Operator MUST NOT send more than one request per minute 1534 per TLD to download a LORDN Log file. 1536 The yd interface (Section 4.3.7) returns the following HTTP status 1537 codes after a HTTP GET request method is received: 1539 o The interface provides a HTTP/200 status code if the interface was 1540 able to provide the LORDN Log file. The LORDN Log file is 1541 contained in the HTTP Entity-body. 1543 o The interface provides a HTTP/204 status code if the LORDN 1544 Transaction Identifier is correct, but the server has not 1545 finalized processing the LORDN file. 1547 o The interface provides a HTTP/400 status code if the request is 1548 incorrect. 1550 o The interface provides a HTTP/401 status code if the credentials 1551 provided does not authorize the Registry Operator to download the 1552 LORDN Log file. 1554 o The interface provides a HTTP/404 status code if the LORDN 1555 Transaction Identifier is incorrect. 1557 o The interface provides a HTTP/500 status code if the system is 1558 experiencing a general failure. 1560 For example, to obtain the LORDN Log File in case of a Sunrise LORDN 1561 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1562 "example" the URI would be: 1564 < https:///LORDN/example/sunrise/ 1565 0000000000000000001/result > 1567 The LORDN Log file is contained in a CSV-like formatted file that has 1568 the following structure: 1570 o first line: ,,,,,, 1574 Where: 1576 + , version of the file, this field MUST be 1. 1578 + , date and time in UTC that the 1579 LORDN Log was created. 1581 + , date and time in UTC of 1582 creation for the LORDN file that this log file is referring 1583 to. 1585 + , unique identifier of the LORDN Log 1586 provided by the TMDB. This identifier could be used by the 1587 Registry Operator to unequivocally identify the LORDN Log. 1588 The identified will be a string of a maximum LENGTH of 60 1589 characters from the Base 64 alphabet. 1591 + , whether the LORDN file has been accepted for 1592 processing by the TMDB. Possible values are "accepted" or 1593 "rejected". 1595 + , whether the LORDN Log has any warning result 1596 codes. Possible values are "no-warnings" or "warnings- 1597 present". 1599 + , number of DNs effective allocations 1600 processed in the LORDN file. 1602 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1603 a ="accepted" and ="no-warnings". 1605 o second line: a header line as specified in [RFC4180] 1607 With the header names as follows: 1609 roid,result-code 1611 o One or more lines with: , 1613 Where: 1615 + , DN Repository Object IDentifier (DNROID) in the SRS. 1617 + , result code as described in Section 6.3.1.1. 1619 Example for LORDN Log file 1621 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1622 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1623 accepted,no-warnings,1 1624 roid,result-code 1625 SH8013-REP,2000 1627 Figure 13 1629 6.3.1.1. LORDN Log Result Codes 1631 In Figure 14 the classes of result codes (rc) are listed. Those 1632 classes in square brackets are not used at this time, but may come 1633 into use at some later stage. The first two digits of a result code 1634 denote the result code class, which defines the outcome at the TMDB: 1636 o ok: Success, DN Line accepted by the TMDB. 1638 o warn: a warning is issued, DN Line accepted by the TMDB. 1640 o err: an error is issued, LORDN file rejected by the TMDB. 1642 In case that after processing a DN Line, the error result code is 1643 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1644 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1645 valid will be reported with a 2001 result code. A 2001 result code 1646 means that the DN Line is syntactically valid, however the DN Line 1647 was not processed because the LORDN file was rejected. All DNs 1648 reported in a rejected LORDN file MUST be reported again by the 1649 Registry because none of the DN Lines present in the LORDN file have 1650 been processed by the TMDB. 1652 LORDN Log Result Code Classes 1654 code Class outcome 1655 ---- ----- ------- 1657 20xx Success ok 1659 35xx [ DN Line syntax warning ] warn 1660 36xx DN Line semantic warning warn 1662 45xx DN Line syntax error err 1663 46xx DN Line semantic error err 1665 Figure 14 1667 In the following, the LORDN Log result codes used by the TMDB are 1668 described: 1670 LORDN Log result Codes 1672 rc Short Description 1673 Long Description 1675 ---- ------------------------------------------------------------- 1677 2000 OK 1678 DN Line successfully processed. 1680 2001 OK but not processed 1681 DN Line is syntactically correct but was not processed 1682 because the LORDN file was rejected. 1684 3601 TCN Acceptance Date after Registration Date 1685 TCN Acceptance Date in DN Line is newer than the Registration 1686 Date. 1688 3602 Duplicate DN Line 1689 This DN Line is an exact duplicate of another DN Line in same 1690 file, DN Line ignored. 1692 3603 DNROID Notified Earlier 1693 Same DNROID has been notified earlier, DN Line ignored. 1695 3604 TCN Checksum invalid 1696 Based on the DN effectively allocated, the TCNID and the 1697 expiration date of the linked TCN, the TCN Checksum is 1698 invalid. 1700 3605 TCN Expired 1701 The TCN was already expired at the time of acknowledgement. 1703 3606 Wrong TCNID used 1704 The TCNID used for the registration does not match 1705 the related DN. 1707 3609 Invalid SMD used 1708 The SMD used for registration was not valid at the moment of 1709 registration based on the and 1710 elements. 1711 In case of an asynchronous registration, this refer to the 1712 . 1714 3610 DN reported outside of the time window 1715 The DN was reported outside of the required 26 hours 1716 reporting window. 1718 3611 DN does not match the labels in SMD 1719 The DN does not match the labels included in the SMD. 1721 3612 SMDID does not exist 1722 The SMDID has never existed in the central repository. 1724 3613 SMD was revoked when used 1725 The SMD used for registration was revoked more than 1726 24 hours ago of the . 1727 In case of an asynchronous registration, 1728 the is used when 1729 validating the DN Line. 1731 3614 TCNID does not exist 1732 The TCNID has never existed in the central repository. 1734 3615 Recent-dnl-insertion outside of the time window 1735 The DN registration is reported as a recent-dnl-insertion, 1736 but the (re) insertion into the DNL ocurred more than 1737 24 hours ago. 1739 3616 Registration Date of DN in claims before the end of Sunrise 1740 The registration date of the DN is before the end of Sunrise 1741 and the DN was reported in a claims LORDN file. 1743 3617 Registrar has not been approved by the TMDB 1744 Registrar ID in DN Line has not completed Claims integration 1745 testing with the TMDB. 1747 4501 Syntax Error in DN Line 1748 Syntax Error in DN Line. 1750 4601 Invalid TLD used 1751 The TLD in the DN Line does not match what is expected for 1752 this LORDN. 1754 4602 Registrar ID Invalid 1755 Registrar ID in DN Line is not a valid ICANN-Accredited 1756 Registrar. 1758 4603 Registration Date in the future 1759 The in the DN Line is in the 1760 future. 1762 4606 TLD not in Sunrise or Claims 1763 The was reported when the TLD was 1764 not in Sunrise or Claims. 1765 In case of an asynchronous registration, 1766 the is used when 1767 validating the DN Line. 1769 4607 Application Date in the future 1770 The in the DN Line is in the 1771 future. 1773 4608 Application Date is later than Registration Date 1774 The in the DN Line is later 1775 than the . 1777 4609 TCNID wrong syntax 1778 The syntax of the TCNID is invalid. 1780 4610 TCN Acceptance Date is in the future 1781 The is in the future. 1783 4611 Label has never existed in the TMDB 1784 The label in the registered DN has never existed in the TMDB. 1786 Figure 15 1788 6.4. SMD File 1790 This section defines the format of the SMD File. After a successful 1791 registration of a mark, the TMV returns an SMD File to the TMH. The 1792 SMD File can then be used for registration of one or more DNs covered 1793 by the PRM during the Sunrise Period of a TLD. 1795 Two encapsulation boundaries are defined for delimiting the 1796 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1797 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1798 boundaries MUST be used by Registries and Registrars for validation 1799 purposes, i.e. any data outside these boundaries as well as the 1800 boundaries themselves MUST be ignored for validation purposes. 1802 The structure of the SMD File is as follows: 1804 o Marks: 1806 o smdID: 1808 o U-labels: 1811 o notBefore: 1813 o notAfter: 1815 o -----BEGIN ENCODED SMD----- 1817 o 1819 o -----END ENCODED SMD----- 1820 Example for SMD File (shortened at [...]): 1822 Marks: Example One 1823 smdID: 1-2 1824 U-labels: example-one, exampleone 1825 notBefore: 2011-08-16 09:00 1826 notAfter: 2012-08-16 09:00 1827 -----BEGIN ENCODED SMD----- 1828 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1829 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1830 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1831 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 1832 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 1833 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 1834 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 1835 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 1836 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 1837 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 1838 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 1839 [...] 1840 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 1841 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 1842 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 1843 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 1844 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 1845 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 1846 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1847 -----END ENCODED SMD----- 1849 Figure 16 1851 6.5. Trademark Claims Notice 1853 The TMDB MUST provide the TCN to Registrars in XML format as 1854 specified below. 1856 An enclosing element that describes the Trademark 1857 Notice to a given label. 1859 The child elements of the element include: 1861 o A element that contains the unique identifier of the 1862 Trademark Notice. This element contains the the TCNID. 1864 The TCNID is a string concatenation of a TCN Checksum and the 1865 TMDB Notice Identifier. The first 8 characters of the TCNID is 1866 a TCN Checksum. The rest is the TMDB Notice Identifier, which 1867 is a zero-padded natural number in the range of 1868 0000000000000000001 to 9223372036854775807. 1870 Example of a TCNID: 1872 370d0b7c9223372036854775807. 1874 Where: 1876 + TCN Checksum=370d0b7c 1878 + TMDB Notice Identifier=9223372036854775807 1880 The TCN Checksum is a 8 characters long Base16 encoded output 1881 of computing the CRC32 of the string concatenation of: label + 1882 unix_timestamp() + TMDB Notice Identifier 1884 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is 1886 defined as the number of seconds that have elapsed since 1970- 1887 01-01T00:00:00Z not counting leap seconds. For example, the 1888 conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: 1890 unix_time(2010-08-16T09:00:00.0Z)=1281949200 1892 The TMDB uses the and 1893 elements from the TCN along with the TMDB Notice Identifier to 1894 compute the TCN Checksum. 1896 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 1897 of the DN being registered, the expiration datetime of the TCN 1898 (provided by the Registrar) and the TMDB Notice Identifier 1899 extracted from the TCNID (provided by the Registrar) to compute 1900 the TCN Checksum. For example the DN "foo.bar.example" being 1901 effectively allocated, the left most label would be "foo". 1903 Example of computation of the TCN Checksum: 1905 CRC32(example-one12819492009223372036854775807)=370d0b7c 1907 o A element that contains the start of the 1908 validity date and time of the TCN. 1910 o A element that contains the expiration date 1911 and time of the TCN. 1913 o A elements that contain the DNL (A-label in case 1914 of IDNs) form of the label that correspond to the DN covered by a 1915 PRM. 1917 o One or more elements that contain the Trademark 1918 Claim. The element contains the following child 1919 elements: 1921 * A element that contains the mark text 1922 string. 1924 * One or more elements that contains the 1925 information of the holder of the mark. An "entitlement" 1926 attribute is used to identify the entitlement of the holder, 1927 possible values are: owner, assignee or licensee. The child 1928 elements of include: 1930 + An OPTIONAL element that contains the name 1931 of the holder. A MUST be specified if 1932 is not specified. 1934 + An OPTIONAL element that contains the name of 1935 the organization holder of the mark. A MUST 1936 be specified if is not specified. 1938 + A element that contains the address 1939 information of the holder of a mark. A 1940 contains the following child elements: 1942 - One, two or three OPTIONAL elements 1943 that contains the organization's street address. 1945 - A element that contains the 1946 organization's city. 1948 - An OPTIONAL element that contains the 1949 organization's state or province. 1951 - An OPTIONAL element that contains the 1952 organization's postal code. 1954 - A element that contains the organization's 1955 country code. This a two-character code from 1956 [ISO3166-2]. 1958 + An OPTIONAL element that contains the 1959 organization's voice telephone number. 1961 + An OPTIONAL element that contains the 1962 organization's facsimile telephone number. 1964 + An OPTIONAL element that contains the email 1965 address of the holder. 1967 * Zero or more OPTIONAL elements that contains 1968 the information of the representative of the mark registration. 1969 A "type" attribute is used to identify the type of contact, 1970 possible values are: owner, agent or thirdparty. The child 1971 elements of include: 1973 + A element that contains name of the 1974 responsible person. 1976 + An OPTIONAL element that contains the name of 1977 the organization of the contact. 1979 + A element that contains the address 1980 information of the contact. A contains the 1981 following child elements: 1983 - One, two or three OPTIONAL elements 1984 that contains the contact's street address. 1986 - A element that contains the contact's 1987 city. 1989 - An OPTIONAL element that contains the 1990 contact's state or province. 1992 - An OPTIONAL element that contains the 1993 contact's postal code. 1995 - A element that contains the contact's 1996 country code. This a two-character code from 1997 [ISO3166-2]. 1999 + A element that contains the contact's voice 2000 telephone number. 2002 + An OPTIONAL element that contains the 2003 contact's facsimile telephone number. 2005 + A element that contains the contact's email 2006 address. 2008 * A element that contains the name (in 2009 English) of the jurisdiction where the mark is protected. A 2010 jurCC attribute contains the two-character code of the 2011 jurisdiction where the mark was registered. This is a two- 2012 character code from [WIPO.ST3]. 2014 * Zero or more OPTIONAL element that 2015 contains the description (in English) of the Nice 2016 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2017 attribute contains the class number. 2019 * A element that contains the full 2020 description of the goods and services mentioned in the mark 2021 registration document. 2023 * An OPTIONAL element signals that the 2024 claim notice was added to the TCN based on other rule than 2025 exact match as defined in [ICANN-GTLD-AGB-20120604]. The 2026 contains one or more: 2028 + An OPTIONAL element that signals that the 2029 claim notice was added because of a previously abused name 2030 included in an UDRP case. The contains: 2032 - A element that contains the UDRP case 2033 number used to validate the previously abused name. 2035 - A element that contains the name 2036 of the UDRP provider. 2038 + An OPTIONAL element that signals that the 2039 claim notice was added because of a previously abused name 2040 included in an court's resolution. The 2041 contains: 2043 - A element that contains the reference 2044 number of the court's resolution used to validate the 2045 previously abused name. 2047 - A element that contains the two-character 2048 code from [ISO3166-2] of the jurisdiction of the court. 2050 - A element that contains the name of 2051 the court. 2053 Example of object: 2055 2056 2057 370d0b7c9223372036854775807 2058 2010-08-14T09:00:00.0Z 2059 2010-08-16T09:00:00.0Z 2060 example-one 2061 2062 Example One 2063 2064 Example Inc. 2065 2066 123 Example Dr. 2067 Suite 100 2068 Reston 2069 VA 2070 20190 2071 US 2072 2073 2074 2075 Joe Doe 2076 Example Inc. 2077 2078 123 Example Dr. 2079 Suite 100 2080 Reston 2081 VA 2082 20190 2083 US 2084 2085 +1.7035555555 2086 jdoe@example.com 2087 2088 UNITED STATES OF AMERICA 2089 2090 Advertising; business management; business administration. 2091 2092 2093 Insurance; financial affairs; monetary affairs; real estate. 2094 2095 2096 Bardus populorum circumdabit se cum captiosus populum. 2097 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2098 2099 2100 2101 Example-One 2102 2103 Example S.A. de C.V. 2104 2105 Calle conocida #343 2106 Conocida 2107 SP 2108 82140 2109 BR 2110 2111 2112 BRAZIL 2113 2114 Bardus populorum circumdabit se cum captiosus populum. 2115 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2116 2117 2118 2119 One 2120 2121 One Corporation 2122 2123 Otra calle 2124 Otra ciudad 2125 OT 2126 383742 2127 CR 2128 2129 2130 COSTA RICA 2131 2132 Bardus populorum circumdabit se cum captiosus populum. 2133 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2134 2135 2136 2137 234235 2138 CR 2139 Supreme Court of Justice of Costa Rica 2140 2141 2142 2143 2144 One Inc 2145 2146 One SA de CV 2147 2148 La calle 2149 La ciudad 2150 CD 2151 34323 2152 AR 2153 2154 2155 ARGENTINA 2156 2157 Bardus populorum circumdabit se cum captiosus populum. 2158 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2159 2160 2161 2162 D2003-0499 2163 WIPO 2164 2165 2166 2167 2169 For formal syntax of the TCN please refer to Section 7.1. 2171 7. Formal Syntax 2173 7.1. Trademark Claims Notice 2175 The schema presented here is for a Trademark Claims Notice. 2177 Copyright (c) 2012 IETF Trust and the persons identified as authors 2178 of the code. All rights reserved. 2180 Redistribution and use in source and binary forms, with or without 2181 modification, are permitted provided that the following conditions 2182 are met: 2184 o Redistributions of source code must retain the above copyright 2185 notice, this list of conditions and the following disclaimer. 2187 o Redistributions in binary form must reproduce the above copyright 2188 notice, this list of conditions and the following disclaimer in 2189 the documentation and/or other materials provided with the 2190 distribution. 2192 o Neither the name of Internet Society, IETF or IETF Trust, nor the 2193 names of specific contributors, may be used to endorse or promote 2194 products derived from this software without specific prior written 2195 permission. 2197 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2198 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2199 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2200 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2201 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2202 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2203 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2204 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2205 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2206 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2207 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2209 BEGIN 2210 2211 2216 2217 2218 Schema for representing a Trademark Notice. 2219 2220 2221 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2243 2244 2245 2246 2247 2248 2250 2252 2253 2255 2256 2258 2259 2260 2261 2262 2263 2264 2265 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2316 2317 2318 2319 2320 2321 2322 2323 END 2325 8. Acknowledgements 2327 This specification is a collaborative effort from several 2328 participants in the ICANN community. Bernie Hoeneisen participated 2329 as co-author until version 02 providing invaluable support for this 2330 document. This specification is based on a model spearheaded by: 2331 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2332 would also like to thank the thoughful feedbak provided by many in 2333 the tmch-tech mailing list, but particularly the extensive help 2334 provided by James Gould, James Mitchell and Francisco Arias. 2336 9. Change History 2338 [[RFC Editor: Please remove this section.]] 2340 9.1. Changes from draft-lozano-tmch-func-spec-06 to 2341 draft-lozano-tmch-func-spec-07 2343 1. Added result codes: 3611, 3612, 3613, 3614, 4607, 4608, 4609 and 2344 4610. 2346 2. Added mechanism to retrieve the LORDN Transaction Identifier 2347 based on a previously sent element. 2349 9.2. Changes from draft-lozano-tmch-func-spec-07 to 2350 draft-lozano-tmch-func-spec-08 2352 1. Updated result codes: 3613. 2354 2. Added result codes: 3615, 3616, 3617 and 4611. 2356 3. Removed result codes: 4605 and 4606 to support Limited 2357 Registration Periods as defined in the latest RPM Requirements 2358 document. 2360 4. Minor editorial fixes. 2362 10. IANA Considerations 2364 This document uses URNs to describe XML namespaces and XML schemas 2365 conforming to a registry mechanism described in [RFC3688]. One URI 2366 assigment have been registered by the IANA. 2368 Registration request for the Trademark Claims Notice: 2370 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2372 Registrant Contact: See the "Author's Address" section of this 2373 document. 2375 XML: None. Namespace URIs do not represent an XML specification. 2377 11. Security Considerations 2379 TBD 2381 12. References 2383 12.1. Normative References 2385 [I-D.lozano-tmch-smd] 2386 Lozano, G., "Mark and Signed Mark Objects Mapping", 2387 draft-lozano-tmch-smd-03 (work in progress), 2388 September 2013. 2390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2391 Requirement Levels", BCP 14, RFC 2119, March 1997. 2393 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2394 January 2004. 2396 12.2. Informative References 2398 [ICANN-GTLD-AGB-20120604] 2399 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2400 June 2012, . 2403 [ISO3166-2] 2404 ISO, "International Standard for country codes and codes 2405 for their subdivisions", 2006. 2407 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2408 STD 13, RFC 1034, November 1987. 2410 [RFC1035] Mockapetris, P., "Domain names - implementation and 2411 specification", STD 13, RFC 1035, November 1987. 2413 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 2414 RFC 1591, March 1994. 2416 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2417 E. Lear, "Address Allocation for Private Internets", 2418 BCP 5, RFC 1918, February 1996. 2420 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2421 Randers-Pehrson, "GZIP file format specification version 2422 4.3", RFC 1952, May 1996. 2424 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2425 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2426 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2428 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2430 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2431 Internet: Timestamps", RFC 3339, July 2002. 2433 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2434 Separated Values (CSV) Files", RFC 4180, October 2005. 2436 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2437 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2439 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2440 Encodings", RFC 4648, October 2006. 2442 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2443 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2445 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2446 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2448 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2449 Housley, R., and W. Polk, "Internet X.509 Public Key 2450 Infrastructure Certificate and Certificate Revocation List 2451 (CRL) Profile", RFC 5280, May 2008. 2453 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2454 STD 69, RFC 5730, August 2009. 2456 [RFC5890] Klensin, J., "Internationalized Domain Names for 2457 Applications (IDNA): Definitions and Document Framework", 2458 RFC 5890, August 2010. 2460 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2461 Infrastructure Certificate and Certificate Revocation List 2462 (CRL) Profile", RFC 6818, January 2013. 2464 [WIPO-NICE-CLASSES] 2465 WIPO, "Nice List of Classes", . 2468 [WIPO.ST3] 2469 WIPO, "Recommended standard on two-letter codes for the 2470 representation of states, other entities and 2471 intergovernmental organizations", March 2007. 2473 Appendix A. Document Changelog 2475 [RFC Editor: This section is to be removed before publication] 2477 Author's Address 2479 Gustavo Lozano 2480 ICANN 2481 12025 Waterfront Drive, Suite 300 2482 Los Angeles 90292 2483 US 2485 Phone: +1.3103015800 2486 Email: gustavo.lozano@icann.org