idnits 2.17.1 draft-lozano-tmch-func-spec-06.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 (May 13, 2013) is 3972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1205, but not defined == Unused Reference: 'RFC1918' is defined on line 2340, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 2344, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 2360, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-lozano-tmch-smd-02 -- 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 (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational May 13, 2013 5 Expires: November 14, 2013 7 TMCH functional specifications 8 draft-lozano-tmch-func-spec-06 10 Abstract 12 This document describes the requirements, the architecture and the 13 interfaces between the Trademark Clearing House (TMCH) and Domain 14 Name Registries as well as between the TMCH and Domain Name 15 Registrars for the provisioning and management of domain names during 16 Sunrise and Trademark Claims Periods. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 14, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 44 111 6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 46 112 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54 113 7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 54 114 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 116 10. Security Considerations . . . . . . . . . . . . . . . . . . . 57 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 58 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 58 120 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 59 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 59 123 1. Introduction 125 Domain Name Registries may operate in special modes within certain 126 periods of time to facilitate registration of domain names. 128 Along with the upcoming introduction of new generic Top Level Domains 129 (gTLD), two special modes will come into effect: 131 o Sunrise Period 133 o Trademark Claims Period 135 The Sunrise and Trademark Claims Periods are defined in the gTLD 136 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 138 This document describes the requirements, the architecture and the 139 interfaces between the Trademark Clearing House (TMCH) and Domain 140 Name Registries (called Registries in the rest of the document) as 141 well as between the TMCH and Domain Name Registrars (called 142 Registrars in the rest of the document) for the provisioning and 143 management of domain names during the Sunrise and Trademark Claims 144 Periods. 146 For any date and/or time indications, Coordinated Universal Time 147 (UTC) applies. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 XML is case sensitive. Unless stated otherwise, XML specifications 156 and examples provided in this document MUST be interpreted in the 157 character case presented in order to develop a conforming 158 implementation. 160 "tmNotice-1.0" is used as an abbreviation for 161 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 162 "tmNotice" is used, but implementations MUST NOT depend on it and 163 instead employ a proper namespace-aware XML parser and serializer to 164 interpret and output the XML documents. 166 3. Glossary 168 In the following section, the most common terms are briefly 169 explained: 171 o Effective allocation: A DN is considered effectively allocated 172 when the DN object for the DN has been created in the SRS of the 173 Registry and has been assigned to the effective user. A DN object 174 in status "pendingCreate" or any other status that precedes the 175 first time a DN is assigned to an end-user is not considered an 176 effective allocation. A DN object created internally by the 177 Registry for subsequent delegation to another Registrant is not 178 considered an effective allocation. 180 o Backend Registry Operator: Entity that manages (a part of) the 181 technical infrastructure for a Registry Operator. The Registry 182 Operator may also be the Backend Registry Operator. 184 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 186 o CSV: Comma-Separated Values, see [RFC4180] 188 o CNIS, Claims Notice Information Service: This service provides 189 TCNs to Registrars. 191 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 192 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 194 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 196 o Date and time, datetime: Date and time are specified following the 197 standard "Date and Time on the Internet specification", see 198 [RFC3339]. 200 o DN: Domain Name, domain name, see [RFC1034] 202 o DN Repository Object IDentifier, DNROID: an identifier assigned by 203 the Registry to each DN object that unequivocally identifies said 204 DN object. For example, if a new DN object is created for a name 205 that existed in the past, the DN objects will have different 206 DNROIDs. 208 o DNS: Domain Name System, see [RFC1034] 210 o DNL, Domain Name Label: A label as specified in [RFC1035]. For 211 IDNs the A-Label is used [RFC5890]. 213 o DNL List: A list of DNLs that are covered by a PRM. 215 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 217 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 219 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 221 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246]. 223 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 224 SMD PKI model. 226 o IDN: Internationalized Domain Name, see [RFC5890] 228 o LORDN, List of Registered Domain Names: This is the list of 229 effectively allocated DNs matching a DNL of a PRM. Registries 230 will upload this list to the TMDB (during the NORDN process). 232 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 233 Z0-9/] to be used as the lookup Key by Registrars to obtain the 234 TCN using the CNIS. Lookup Keys are unique and are related to one 235 DNL only. 237 o NORDN, Notification of Registered Domain Names: The process by 238 which Registries upload their recent LORDN to the TMDB. 240 o PGP: Pretty Good Privacy, see [RFC4880] 242 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 244 o PRM, Pre-registered mark: Mark that has been pre-registered with 245 the TMCH. 247 o Registrant: Person or Organization registering a DN via a 248 Registrar. 250 o Registrar, Domain Name Registrar: Entity that registers DNs with 251 the Registry on behalf of the Registrant. 253 o Registry, Registry Operator, Domain Name Registry: Entity that 254 accepts DN registrations from Registrars, maintains the central 255 Database of Registered DNs. A Registry Operator is the 256 contracting party with ICANN for the TLD. 258 o SMD, Signed Mark Data: A cryptographically signed token issued by 259 the TMV to the TMH to be used in the Sunrise Period to apply for a 260 DN that matches a DNL of a PRM; see also [I-D.lozano-tmch-smd] 262 o SMD File: A file containing the SMD (see above) and some human 263 readable data. The latter is usually ignored in the processing of 264 the SMD File. See also Section 6.4. 266 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 267 lists of revoked SMDs (SMD Revocation List); see also 268 [I-D.lozano-tmch-smd] 270 o SMD Revocation List: The SMD Revocation List is used by Registries 271 (and optionally by Registrars) during the Sunrise Period to ensure 272 that an SMD is still valid (i.e. not revoked). The SMD Revocation 273 List has a similar function as CRLs used in PKI. 275 o SRS: Shared Registration System, see also 276 [ICANN-GTLD-AGB-20120604]. 278 o Sunrise Period: During this period DNs matching a DNL of a PRM can 279 be exclusively obtained by the respective TMHs. For DNs matching 280 a PRM, a special process applies to ensure a TMH gets informed on 281 the effective allocation of a DN matching his/her PRM. 283 o TLD: Top Level Domain Name, see [RFC1591] 285 o Trademark, mark: Marks are used to claim exclusive properties of 286 products or services. A mark is typically a name, word, phrase, 287 logo, symbol, design, image, or a combination of these elements. 288 For the scope of this document only textual marks are relevant. 290 o Trademark Claims, Claims: Provides information to enhance the 291 understanding of the Trademark rights being claimed by the TMH. 293 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 294 Trademark Claims Notice consist of one or more Trademark Claims 295 and are provided to prospective Registrants of DNs. 297 o Trademark Claims Notice Identifier, TCNID: An element of the 298 Trademark Claims Notice (see above), identifying said TCN. The 299 Trademark Claims Notice Identifier is specified in the element 300 . 302 o Trademark Claims Period: During this period, a special process 303 applies to DNs matching the DNL List, to ensure a TMH gets 304 informed of a DN matching his PRM. For DNs matching the DNL List, 305 Registrars show a TCN to prospective Registrants that has to be 306 acknowledged before effective allocation of the DN. 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 TMHs. The 311 Trademark Clearinghouse is split into two functions TMV and TMDB 312 (see below). There could be several entities performing the TMV 313 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 mark. 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 during 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]. 451 4.3.6. dr 453 Not used during the Sunrise Period. 455 During the Trademark Claims Period, the Registrar fetches the TCN 456 from the TMDB (to be displayed to the Registrant via the tr 457 interface) via the dr interface. The protocol used for fetching the 458 TCN is HTTPS [RFC2818]. 460 4.3.7. yd 462 During the Sunrise period the Registry notifies the TMDB via the yd 463 interface of all DNs effectively allocated. 465 During the Trademark Claims period, the Registry notifies the TMDB 466 via the yd interface of all DNs effectively allocated that matched an 467 entry in the Registry previously downloaded DNL List during the 468 creation of the DN. 470 The protocol used on the yd interface is HTTPS. 472 4.3.8. dv 474 The TMDB notifies via the dv interface to the TMV of all DNs 475 effectively allocated that match a mark registered by that TMV. 477 The specifics of the dv interface are beyond the scope of this 478 document. 480 4.3.9. vh 482 The TMV notifies the TMH via the vh interface after a DN has been 483 effectively allocated that matches a PRM of this TMH. 485 The specifics of the vh interface are beyond the scope of this 486 document. 488 4.3.10. vs 490 The TMV requests to add a revoked SMD to the SMD Revocation List at 491 the SMDM. 493 The specifics of the vs interface are beyond the scope of this 494 document. 496 Not relevant during the Trademark Claims Period. 498 4.3.11. sy 500 During the Sunrise Period the Registry fetches the most recent SMD 501 Revocation List from the SMDM via the sy interface in regular 502 intervals. The protocol used on the sy interface is HTTPS. 504 Not relevant during the Trademark Claims Period. 506 4.3.12. sr 508 During the Sunrise Period the Registrar may fetch the most recent SMD 509 Revocation List from the SMDM via the sr interface. The protocol 510 used on the sr interface is the same as on the sy interface (s. 511 above), i.e. HTTPS. 513 Not relevant during the Trademark Claims Period. 515 4.3.13. vc 517 The TMV requests to add a revoked TMV certificate to the CRL at the 518 ICANN-CA via the vc interface. 520 The specifics of the vc interface are beyond the scope of this 521 document. 523 Not relevant during the Trademark Claims Period. 525 4.3.14. cy 527 During the Sunrise Period the Registry fetches the most recent CRL 528 from the ICANN-CA via the cy interface in regular intervals. The CRL 529 is mainly used for validation of TMV certificates. The protocol used 530 on the cy interface is HTTPS [RFC2818]. 532 Not relevant during the Trademark Claims Period. 534 4.3.15. cr 536 During the Sunrise Period the Registrar may fetch the most recent CRL 537 from the ICANN-CA via the cr interface. The protocol used on the cr 538 interface is the same as on the cy interface. 540 Not relevant during the Trademark Claims Period. 542 5. Process Descriptions 544 5.1. Bootstrap 546 5.1.1. Registries 548 5.1.1.1. Credentials 550 Each Registry Operator will receive authentication credentials from 551 the TMDB/SMDM to be used: 553 o During the Sunrise Period to fetch the SMD Revocation List from 554 the SMDM via the sy interface (Section 4.3.11). 556 o During Trademark Claims Period to fetch the DNL List from the TMDB 557 via the dy interface (Section 4.3.3). 559 o During the NORDN process to notify the LORDN to the TMDB via the 560 yd interface (Section 4.3.7). 562 Note: credentials are created per TLD and provided to the Registry 563 Operator. 565 5.1.1.2. IP Addresses for Access Control 567 Each Registry Operator MUST provide to the TMDB all IP addresses that 568 will be used to: 570 o Fetch the SMD Revocation List via the sy interface 571 (Section 4.3.11). 573 o Fetch the DNL List from the TMDB via the dy interface 574 (Section 4.3.3). 576 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 578 This access restriction MAY be applied by the TMDB/SMDM in addition 579 to HTTP Basic access authentication (for credentials to be used, see 580 Section 5.1.1.1). 582 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 583 Registry Operator. 585 5.1.1.3. TMCH Trust Anchor 587 Each Registry Operator MUST fetch the X.509 certificate ([RFC5280] / 588 [RFC6818]) of the ICANN-CA (Trust Anchor) from 589 < https://ca.icann.org/tmch.crt > to be used: 591 o During the Sunrise Period to validate the TMV certificates and the 592 CRL of TMV certificates. 594 5.1.1.4. TMDB/SMDM PGP Key 596 The TMDB MUST provide each Registry Operator with the public portion 597 of the PGP Key used by TMDB and SMDM, to be used: 599 o During the Sunrise Period to perform integrity checking of the SMD 600 Revocation List fetched from the SMDM via the sy interface 601 (Section 4.3.11). 603 o During Trademark Claims Period to perform integrity checking of 604 the DNL List fetched from the TMDB via the dy interface 605 (Section 4.3.3). 607 5.1.2. Registrars 609 5.1.2.1. Credentials 611 Each ICANN-accredited Registrar will receive authentication 612 credentials from the TMDB to be used: 614 o During the Sunrise Period to (optionally) fetch the SMD Revocation 615 List from the SMDM via the sr interface (Section 4.3.12). 617 o During Trademark Claims Period to fetch TCNs from the TMDB via the 618 dr interface (Section 4.3.6). 620 5.1.2.2. IP Addresses for Access Control 622 Each Registrar MUST provide to the TMDB all IP addresses, which will 623 be used to: 625 o Fetch the SMD Revocation List via the sr interface 626 (Section 4.3.12). 628 o Fetch TCNs via the dr interface (Section 4.3.6). 630 This access restriction MAY be applied by the TMDB/SMDM in addition 631 to HTTP Basic access authentication (for credentials to be used, see 632 Section 5.1.2.1). 634 The TMDB MAY limit the number of IP addresses to be accepted per 635 Registrar. 637 5.1.2.3. TMCH Trust Anchor 639 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 640 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 641 be used: 643 o During the Sunrise Period to (optionally) validate the TMV 644 certificates and the CRL of TMV certificates. 646 5.1.2.4. TMDB PGP Key 648 Registrars MUST receive the public portion of the PGP Key used by 649 TMDB and SMDM from the TMDB administrator to be used: 651 o During the Sunrise Period to (optionally) perform integrity 652 checking of the SMD Revocation List fetched from the SMDM via the 653 sr interface (Section 4.3.12). 655 5.2. Sunrise Period 657 5.2.1. Domain Name Registration 659 Registration during Sunrise Period 661 .------------. .-----------. .----------. 662 | Registrant | | Registrar | | Registry | 663 '------------' '-----------' '----------' 664 ^ | | | 665 | | Request DN | | 666 | | Registration | | 667 | | (with SMD) | | 668 | |------------->| Check DN availability | 669 | | |---------------------------->| 670 | | | | 671 | | DN unava. | DN unavailable .-------------. 672 '---|<-------------|<--------------------( DN available? ) 673 | | no '-------------' 674 | | | yes 675 | | DN available | 676 | |<----------------------------| 677 | | | 678 | | Request DN registration | 679 | | (with SMD) | 680 | |---------------------------->| 681 | | | 682 | | .------------------------------. 683 | | | DN registration validation / | 684 | | | SMD validation | 685 | | '------------------------------' 686 | Registration | | 687 | Error |.-----------. Error .----------------------. 688 |<-------------|| TRY AGAIN |<------( Validation successful? ) 689 | || / ABORT | no '----------------------' 690 | |'-----------' | yes 691 | | | 692 | | DN registered | 693 | DN regist. |<----------------------------| 694 |<-------------| | 695 | | | 697 Figure 3 699 5.2.2. DN Registration by Registries 701 Registries MUST perform a minimum set of checks for verifying each DN 702 registration during the Sunrise Period upon reception of a 703 registration request over the ry interface (Section 4.3.5). If any 704 of these checks fails the Registry MUST abort the registration. Each 705 of these checks MUST be performed before the DN is effectively 706 allocated. 708 In case of asynchronous registrations (e.g. auctions), the minimum 709 set of checks MAY be performed when creating the intermediate object 710 (e.g. a DN application) used for DN registration. If the minimum set 711 of checks is performed when creating the intermediate object (e.g. a 712 DN application) a Registry MAY effective allocate the DN without 713 performing the minimum set of checks again. 715 Performing the minimum set of checks Registries MUST verify that: 717 1. A SMD has been received from the Registrar along with the DN 718 registration. 720 2. The certificate of the TMV has been correctly signed by the 721 ICANN-CA. (The certificate of the TMV is contained within the 722 SMD.) 724 3. The time when the validation is done is within the validity 725 period of the TMV certificate. 727 4. The certificate of the TMV is not be listed in the CRL file 728 specified in the CRL distribution point of the TMV certificate. 730 5. The signature of the SMD (signed with the TMV certificate) is 731 valid. 733 6. The time when the validation is done is within the validity 734 period of the SMD based on and 735 elements. 737 7. The SMD has not been revoked, i.e., is not contained in the SMD 738 Revocation List. 740 8. The leftmost DNL (A-label in case of IDNs) of the DN being 741 effectively allocated matches one of the labels () 742 elements in the SMD. 744 These procedure apply to all DN effective allocations at the second 745 level as well as to all other levels subordinate to the TLD that the 746 Registry accepts registrations for. 748 5.2.3. TMCH Sunrise Services for Registries 750 5.2.3.1. SMD Revocation List 752 A new SMD Revocation List MUST be published by the SMDM twice a day, 753 by 00:00:00 and 12:00:00 UTC. 755 Registries MUST refresh the latest version of the SMD Revocation List 756 at least once every 24 hours. 758 Note: the SMD Revocation List will be the same regardless of the TLD. 759 If a Backend Registry Operator manages the infrastructure of several 760 TLDs, the Backend Registry Operator could refresh the SMD Revocation 761 List once every 24 hours, the SMD Revocation List could be used for 762 all the TLDs managed by the Backend Registry Operator. 764 Update SMD Revocation List 766 .----------. .------. 767 | Registry | | SMDM | 768 '----------' '------' 769 | | 770 .----------------. | 771 | Periodically, | | 772 | at least | | 773 | every 24 hours | | 774 '----------------' | 775 | | 776 |----------------------------------------------------->| 777 | Download latest revocation list for SMD certificates | 778 |<-----------------------------------------------------| 779 | | 780 | | 782 Figure 4 784 5.2.3.2. Certificate Revocation List 786 Registries MUST refresh their local copy of the CRL at least every 24 787 hours using the CRL distribution point specified in the TMV 788 certificate. 790 Operationally, the CRL file and CRL distribution point is the same 791 for all TMVs and (at publication of this document) located at 792 < http://crl.icann.org/tmch.crl >. 794 Note: the CRL file will be the same regardless of the TLD. If a 795 Backend Registry Operator manages the infrastructure of several TLDs, 796 the Backend Registry Operator could refresh the CRL file once every 797 24 hours, the CRL file could be used for all the TLDs managed by the 798 Backend Registry Operator. 800 Update CRL for TMV certificates 802 .----------. .----------. 803 | Registry | | ICANN-CA | 804 '----------' '----------' 805 | | 806 .----------------. | 807 | Periodically, | | 808 | at least | | 809 | every 24 hours | | 810 '----------------' | 811 | | 812 |------------------------------------------->| 813 | Download latest CRL for TMV certificates | 814 |<-------------------------------------------| 815 | | 816 | | 818 Figure 5 820 5.2.3.3. Notice of Registered Domain Names 822 The Registry MUST send a LORDN file containing DNs effectively 823 allocated to the TMDB (over the yd interface, Section 4.3.7). 825 The effective allocation of a DN MUST be reported by the Registry to 826 the TMDB within 26 hours of the effective allocation of such DN. 828 The Registry MUST create and upload a LORDN file in case there are 829 effective allocations in the SRS, that have not been successfully 830 reported to the TMDB in a previous LORDN file. 832 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 833 maximum frequency to upload LORN files from the Registries to the 834 TMDB is every 3 hours. 836 It is RECOMMENDED that Registries try to upload at least two LORDN 837 files per day to the TMDB with enough time in between, in order to 838 have time to fix problems reported in the LORDN file. 840 The Registry SHOULD upload a LORDN file only when the previous LORDN 841 file has been processed by the TMDB and the related LORDN Log file 842 has been downloaded and processed by the Registry. 844 The Registry MUST upload LORDN files for DNs effectively allocated 845 during the Sunrise or Claims period (same applies to DNs effectively 846 allocated using applications created during the Sunrise or Claims 847 period in case of using asynchronous registrations). 849 The yd interface (Section 4.3.7) MUST support at least 1 and MAY 850 support up to 10 concurrent connections from each IP address 851 registered by a Registry Operator to access the service. 853 The TMDB MUST process each uploaded LORDN file and make the related 854 log file available for Registry download within 30 minutes of the 855 finalization of the upload. 857 NORDN 859 .----------. .------. .-----. .-----. 860 | Registry | | TMDB | | TMV | | TMH | 861 '----------' '------' '-----' '-----' 862 | | | | 863 .------------------. | | | 864 | Periodically | | | | 865 | upload LORDN | | | | 866 | file | | | | 867 '------------------' | | | 868 | | | | 869 .--------->| Upload LORDN | | | 870 | |-------------------->| | | 871 | | | | | 872 | | .-------------------------. | | 873 | | | Verify each domain name | | | 874 | | | in the uploaded file | | | 875 | | | (within 30') | | | 876 | | '-------------------------' | | 877 | | | ._____. | | 878 | | Download Log file | | END | | | 879 | |<--------------------| '-----' | | 880 | | | ^ | | 881 | .-----------------. .---------------. | | | 882 | | Check whether | / everything fine \ no | | | 883 | | Log file | ( (i.e. no errors )---' | | 884 | | contains errors | \ in Log file )? / | | 885 | '-----------------' '---------------' | | 886 | | | yes | | 887 | .---------------. | | | 888 | / everything fine \ yes | | | 889 |( (i.e. no errors )-----. | Notify TMVs | | 890 | \ in Log file )? / | | on the LORDN | | 891 | '---------------' | | pre-registered | | 892 | | no v | with said TMV | | 893 | .----------------. .------. |--------------->| | 894 '-| Correct Errors | | DONE | | | | 895 '----------------' '------' | | Notify each | 896 | | | affected TMH | 897 | | |------------->| 898 | | | | 900 Figure 6 902 The format used for the LORDN is described in Section 6.3 904 5.2.4. DN registration by Registrars 906 Registrars MAY choose to perform the checks for verifying DN 907 registrations as performed by the Registries (see Section 5.2.2) 908 before sending the command to register a DN. 910 5.2.5. TMCH Sunrise Services for Registrars 912 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 913 also available for Registrars to optionally validate the SMDs 914 received. 916 5.3. Trademark Claims Period 918 5.3.1. Domain Registration 920 Registration during Trademark Claims Period 922 .------------. .-----------. .----------. .------. 923 | Registrant | | Registrar | | Registry | | TMDB | 924 '------------' '-----------' '----------' '------' 925 ^ | Request DN | | | 926 | | Registration | Check DN availability | | 927 | |------------->|---------------------------->| | 928 | | DN unava. | DN unavailable .-------------. | 929 '---|<-------------|<--------------------( DN available? ) | 930 | | no '-------------' | 931 | | | yes | 932 | | DN available | | 933 | |<----------------------------| | 934 | | Request Lookup key | | 935 | |---------------------------->| | 936 | | .---------. | 937 | |.----------. / Does DN \ | 938 | || CONTINUE |<---------( match DNL ) | 939 | || NORMALLY | no \ of PRM? / | 940 | |'----------' '---------' | 941 | | | yes | 942 | | Lookup key | | 943 | |<----------------------------| | 944 | | Request Claims Notice | 945 | Display |----------------------------------------->| 946 | Claims | | 947 | Notice | Return Claims Notice | 948 |<-------------|<-----------------------------------------| 949 | | | 950 .------. yes | Register DN (TCNID included) | 951 ( Ack? )--------->|---------------------------->| | 952 '------' | | | 953 ||no | Error .----------------------. | 954 || .-------. |<--------------( Validation successful? ) | 955 |'->| ABORT | | no '----------------------' | 956 | '-------' | | yes | 957 | DN regist. | DN registered | | 958 |<-------------|<----------------------------| | 959 | | | | 961 Figure 7 963 5.3.2. DN registration by Registries 965 During Trademark Claim Periods, Registries perform two main 966 functions: 968 o Registries MUST provide Registrars (over the ry interface, 969 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 970 that match the DNL List. 972 o Registries MUST provide the Lookup Key only when queried about a 973 specific DN. 975 o For each DN matching a DNL of a PRM, Registries MUST perform a 976 minimum set of checks for verifying DN registrations during 977 Trademark Claims Period upon reception of a registration request 978 over the ry interface (Section 4.3.5). If any of these checks 979 fails the Registry MUST abort the registration. Each of these 980 checks MUST be performed before the DN is effectively allocated. 982 o In case of asynchronous registrations (e.g. auctions), the minimum 983 set of checks MAY be performed when creating the intermediate 984 object (e.g. a DN application) used for DN effective allocation. 985 If the minimum set of checks is performed when creating the 986 intermediate object (e.g. a DN application) a Registry MAY 987 effective allocate the DN without performing the minimum set of 988 checks again. 990 o Performing the minimum set of checks Registries MUST verify that: 992 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been 994 received from the Registrar along with the DN registration. 996 If the three elements mentioned above are not provided by 997 the Registrar for a DN matching a DNL of a PRM, but the DNL 998 was inserted (or re-inserted) for the first time into DNL 999 List less than 24 hours ago, the registration MAY continue 1000 without this data and the tests listed below are not 1001 required to be performed. 1003 2. The TCN has not expired (according to the expiration datetime 1004 sent by the Registrar). 1006 3. The acceptance datetime is no more than 48 hours in the past. 1008 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1009 being registered, the expiration datetime provided by the 1010 registrar, and the TMDB Notice Identifier extracted from the 1011 TCNID provided by the registrar compute the TCN Checksum. 1012 Verify that the computed TCN Checksum match the TCN Checksum 1013 present in the TCNID. 1015 These procedures apply to all DN registrations at the second level as 1016 well as to all other levels subordinate to the TLD that the Registry 1017 accepts registrations for. 1019 5.3.3. Trademark Claims Services for Registries 1021 5.3.3.1. Domain Name Label (DNL) List 1023 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1024 and 12:00:00 UTC. 1026 Registries MUST refresh the latest version of the DNL List at least 1027 once every 24 hours. 1029 Update DNL List 1031 .----------. .------. 1032 | Registry | | TMDB | 1033 '----------' '------' 1034 | | 1035 .----------------. | 1036 | Periodically, | | 1037 | at least | | 1038 | every 24 hours | | 1039 '----------------' | 1040 | | 1041 |-------------------------------->| 1042 | Download latest list of DNLs | 1043 |<--------------------------------| 1044 | | 1045 | | 1047 Figure 8 1049 Note: the DNL List will be the same regardless of the TLD. If a 1050 Backend Registry Operator manages the infrastructure of several TLDs, 1051 the Backend Registry Operator could refresh the DNL List once every 1052 24 hours, the DNL List could be used for all the TLDs managed by the 1053 Backend Registry Operator. 1055 5.3.3.2. Notice of Registered Domain Names 1057 The NORDN process during the Trademark Claims Period is almost the 1058 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1059 difference that only registrations subject to a Trademark Claim 1060 (i.e., at registration time the name appeared in the current DNL List 1061 downloaded by the Registry Operator) are included in the LORDN. 1063 5.3.4. DN Registration by Registrars 1065 For each DN matching a DNL of a PRM, Registrars MUST perform the 1066 following steps: 1068 1. Use the Lookup Key received from the Registry to obtain the TNC 1069 from the TMDB using the dr interface (Section 4.3.6) Registrars 1070 MUST only query for the Lookup Key of a DN that is available for 1071 registration. 1073 2. Present the TCN to the Registrant as described in 1074 [ICANN-GTLD-AGB-20120604]. 1076 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1077 consent with the TCN, before any further processing. (The 1078 transmission of a TCNID to the Registry over the ry interface, 1079 Section 4.3.5 implies that the Registrant has expressed his 1080 consent with the TCN.) 1082 4. Perform the minimum set of checks for verifying DN registrations. 1083 If any of these checks fails the Registrar MUST abort the DN 1084 registration. Each of these checks MUST be performed before the 1085 registration is sent to the Registry. Performing the minimum set 1086 of checks Registrars MUST verify that: 1088 1. The time when the validation is done is within the TCN 1089 validity based on the and elements. 1092 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1093 effectively allocated matches the label () 1094 element in the TCN. 1096 3. The Registrant has acknowledged (expressed his consent with) 1097 the TCN. 1099 5. Record the date and time when the registrant acknowledged the 1100 TCN. 1102 6. Send the registration to the Registry (ry interface, 1103 Section 4.3.5) and include the following information: 1105 * TCNID () 1107 * Expiration date of the TCN () 1109 * Acceptance datetime of the TCN. 1111 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the 1113 TMDB, allowing the implementation of a cache by Registrars and enough 1114 time for acknowledging the TCN. Registrars SHOULD implement a cache 1115 of TCNs to minimize the number of queries sent to the TMDB. A cached 1116 TCN MUST be removed from the cache after the expiration date of the 1117 TCN as defined by . The TMDB MAY implement rate- 1118 limiting as one of the protection mechanisms to mitigate the risk of 1119 performance degradation. 1121 5.3.5. Trademark Claims Services for Registrars 1123 5.3.5.1. Claims Notice Information Service 1125 The TCNs are provided by the TMDB online and are fetched by the 1126 Registrar via the dr interface (Section 4.3.6). 1128 To get access to the TCNs, the Registrar needs the credentials 1129 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1130 from the Registry via the ry interface (Section 4.3.5). The dr 1131 interface (Section 4.3.6) uses HTTPS with Basic access 1132 authentication. 1134 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1135 connections from each Registrar. 1137 The URL of the dr interface (Section 4.3.6) is: 1139 < https:///cnis/.xml > 1141 Note that the "lookupkey" may contain SLASH characters ("/"). The 1142 SLASH character is part of the URL path and MUST NOT be escaped when 1143 requesting the TCN. 1145 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1146 MUST be signed by a well-know public CA. Registrars MUST perform the 1147 Certification Path Validation described in Section 6 of [RFC5280]. 1148 Registrars will be authenticated in the dr interface using HTTP Basic 1149 access authentication. The dr (Section 4.3.6) interface MUST support 1150 HTTPS keep-alive and MUST maintain the connection for up to 30 1151 minutes. 1153 6. Data Format Descriptions 1155 6.1. DNL List file 1157 This section defines format of the list containing every Domain Name 1158 Label (DNL) that matches a Pre-Registered Mark (PRM). The list is 1159 maintained by the TMDB and downloaded by Registries in regular 1160 intervals (see Section 5.3.3.1). The Registries use the DNL List 1161 during the Trademark Claims period to check whether a requested DN 1162 matched a DNL of a PRM. 1164 The DNL List contains all the DNLs covered by a PRM present in the 1165 TMDB at the time it is generated. 1167 The DNL List is contained in a CSV-like formatted file that has the 1168 following structure: 1170 o first line: , 1172 Where: 1174 + , version of the file, this field MUST be 1. 1176 + , date and time in UTC that the 1177 DNL List was created. 1179 o second line: a header line as specified in [RFC4180] 1181 With the header names as follows: 1183 DNL,lookup-key,insertion-datetime 1185 o One or more lines with: ,, 1188 Where: 1190 + , a Domain Name Label covered by a PRM. 1192 + , lookup key that the Registry MUST provide to 1193 the Registrar. The lookup key has the following format: 1194
////, where: 1197 - YYYY: year that the TCN was generated. 1199 - MM: zero-padded month that the TCN was generated. 1201 - DD: zero-padded day that the TCN was generated. 1203 - vv: version of the TCN, possible values are 00 and 01. 1205 - X: one hexadecimal digit [0-9A-F]. This is the first, 1206 second and third hexadecimal digit of encoding the 1207 in base16 as specified in [RFC4648]. 1209 - Random bits: 144 random bits encoded in base64url as 1210 specified in [RFC4648]. 1212 - Sequential number: zero-padded natural number in the 1213 range 0000000001 to 2147483647. 1215 + , datetime in UTC that the DNL was 1216 first inserted into the DNL List. The possible two values 1217 of time for inserting a DNL to the DNL List are 00:00:00 and 1218 12:00:00 UTC. 1220 Example for DNL List 1222 1,2012-08-16T00:00:00.0Z 1223 DNL,lookup-key,insertion-datetime 1224 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1225 2010-07-14T00:00:00.0Z 1226 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1227 2012-08-16T00:00:00.0Z 1228 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1229 2011-08-16T12:00:00.0Z 1231 Figure 9 1233 To provide authentication and integrity protection, the DNL List will 1234 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1235 (see also Section 5.1.1.4). The PGP signature of the DNL List can be 1236 found in the similar URI but with extension .sig as shown below. 1238 The URL of the dy interface (Section 4.3.3) is: 1240 o < https:///dnl/dnl-latest.csv > 1242 o < https:///dnl/dnl-latest.sig > 1244 6.2. SMD Revocation List 1246 This section defines the format of the list of SMDs that have been 1247 revoked. The list is maintained by the SMDM and downloaded by 1248 Registries (and optionally by Registrars) in regular intervals (see 1249 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1250 Period to validate SMDs received. The SMD Revocation List has a 1251 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1253 The SMD Revocation List contains all the revoked SMDs present in the 1254 TMDB at the time it is generated. 1256 The SMD Revocation List is contained in a CSV-like formatted file 1257 that has the following structure: 1259 o first line: , 1261 Where: 1263 + , version of the file, this field MUST be 1. 1265 + , datetime in UTC 1266 that the SMD Revocation List was created. 1268 o second line: a header line as specified in [RFC4180] 1270 With the header names as follows: 1272 smd-id,insertion-datetime 1274 o One or more lines with: , 1276 Where: 1278 + , identifier of the SMD that was revoked. 1280 + , revocation datetime in UTC of the 1281 SMD. The possible two values of time for inserting a DNL to 1282 the DNL List are 00:00:00 and 12:00:00 UTC. 1284 To provide integrity protection, the SMD Revocation List is PGP 1285 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1286 also Section 5.1.1.4). The SMD Revocation List is provided by the 1287 TMDB with extension .csv. The PGP signature of the SMD Revocation 1288 List can be found in the similar URI but with extension .sig as shown 1289 below. 1291 The URL of the sr interface (Section 4.3.12) and sy interface 1292 (Section 4.3.11) is: 1294 o < https:///smdrl/smdrl-latest.csv > 1296 o < https:///smdrl/smdrl-latest.sig > 1298 Example for SMD Revocation list 1300 1,2012-08-16T00:00:00.0Z 1301 smd-id,insertion-datetime 1302 2-2,2012-08-15T00:00:00.0Z 1303 3-2,2012-08-15T00:00:00.0Z 1304 1-2,2012-08-15T00:00:00.0Z 1306 Figure 10 1308 6.3. LORDN File 1310 This section defines the format of the List of Registered Domain 1311 Names (LORDN), which is maintained by each Registry and uploaded at 1312 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1313 said DN is added to the LORDN along with further information related 1314 to its registration. 1316 The URI of the dy interface (Section 4.3.3) used to upload the LORDN 1317 file is: 1319 o Sunrise LORDN file: 1321 < https:///LORDN//sunrise > 1323 o Claims LORDN file: 1325 < https:///LORDN//claims > 1327 The dy interface (Section 4.3.3) returns the following HTTP status 1328 codes after a HTTP POST request method is received: 1330 o The interface provides a HTTP/202 status code if the interface was 1331 able to receive the LORDN file and the syntax of the LORDN file is 1332 correct. 1334 The interface provides the LORDN Transaction Identifier in the 1335 HTTP Entity-body that would be used by the Registry to download 1336 the LORDN Log file. The LORDN Transaction Identifier is a 1337 natural number zero-padded in the range 0000000000000000001 to 1338 9223372036854775807. 1340 The HTTP Location header field contains the URI where the LORDN 1341 Log file could be retrieved later, for example: 1343 202 Accepted 1345 Location: https:///LORDN/example/sunrise/ 1346 0000000000000000001/result 1348 o The interface provides a HTTP/400 if the request is incorrect or 1349 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1350 human readable message in the HTTP Entity-body regarding the 1351 incorrect syntax of the LORDN file. 1353 o The interface provides a HTTP/401 status code if the credentials 1354 provided does not authorize the Registry Operator to upload a 1355 LORDN file. 1357 o The interface provides a HTTP/500 status code if the system is 1358 experiencing a general failure. 1360 For example, to upload the Sunrise LORDN file for TLD "example", the 1361 URI would be: 1363 < https:///LORDN/example/sunrise > 1365 The LORDN is contained in a CSV-like formatted file that has the 1366 following structure: 1368 o For Sunrise Period: 1370 * first line: ,, 1373 Where: 1375 - , version of the file, this field MUST be 1. 1377 - , date and time in UTC that the 1378 LORDN was created. 1380 - , number of DN Lines present in the 1381 LORDN file. 1383 * second line: a header line as specified in [RFC4180] 1385 With the header names as follows: 1387 roid,domain-name,SMD-id,registrar-id,registration- 1388 datetime,application-datetime 1390 * One or more lines with: ,,,,, 1394 Where: 1396 - , DN Repository Object IDentifier (DNROID) in the 1397 SRS. 1399 - , DN that was effectively allocated. For 1400 IDNs the A-Label is used [RFC5890] 1402 - , SMD ID used for registration. 1404 - , IANA Registrar ID. 1406 - , date and time in UTC that the 1407 domain was effectively allocated. 1409 - OPTIONAL , date and 1410 time in UTC that the application was created. The 1411 MUST be provided in 1412 case of a DN effective allocation based on an 1413 asynchronous registration (e.g., when using auctions). 1415 Example for LORDN during Sunrise 1417 1,2012-08-16T00:00:00.0Z,3 1418 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1419 application-datetime 1420 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1421 2012-07-15T00:50:00.0Z 1422 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1423 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1425 Figure 11 1427 o For Trademark Claims Period: 1429 * first line: ,, 1432 Where: 1434 - , version of the file, this field MUST be 1. 1436 - , date and time in UTC that the 1437 LORDN was created. 1439 - , number of DN Lines present in the 1440 LORDN file. 1442 * second line: a header line as specified in [RFC4180] 1444 With the header names as follows: 1446 roid,domain-name,notice-id,registrar-id,registration- 1447 datetime,ack-datetime,application-datetime 1449 * One or more lines with: ,,,,,, 1453 Where: 1455 - , DN Repository Object IDentifier (DNROID) in the 1456 SRS. 1458 - , DN that was effectively allocated. For 1459 IDNs the A-Label is used [RFC5890]. 1461 - , Trademark Claims Notice Identifier as specified 1462 in . 1464 - , IANA Registrar ID. 1466 - , date and time in UTC that the 1467 domain was effectively allocated. 1469 - , date and time in UTC 1470 that the TCN was acknowledged. 1472 - OPTIONAL , date and 1473 time in UTC that the application was created. The 1474 MUST be provided in 1475 case of a DN effective allocation based on an 1476 asynchronous registration (e.g., when using auctions). 1478 For a DN matching a DNL of a PRM at the moment of 1479 registration, created without the TCNID, expiration datetime 1480 and acceptance datetime, because DNL was inserted (or re- 1481 inserted) for the first time into DNL List less than 24 1482 hours ago, the string "recent-dnl-insertion" MAY be 1483 specified in and . 1486 Example for LORDN during Claims 1488 1,2012-08-16T00:00:00.0Z,3 1489 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1490 ack-datetime,application-datetime 1491 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1492 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1493 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1494 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1495 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1496 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1498 Figure 12 1500 6.3.1. LORDN Log File 1502 After reception of the LORDN file, the TMDB verifies its content for 1503 syntactical and semantical correctness. The output of the LORDN file 1504 verification is retrieved using the dy interface (Section 4.3.3). 1506 The URI of the dy interface (Section 4.3.3) used to retrieve the 1507 LORDN Log File is: 1509 o Sunrise LORDN Log file: 1511 < https:///LORDN//sunrise/ 1512 /result > 1514 o Claims LORDN Log file: 1516 < https:///LORDN//claims/ 1517 /result > 1519 A Registry Operator MUST NOT send more than one request per minute 1520 per TLD to download a LORDN Log file. 1522 The dy interface (Section 4.3.3) returns the following HTTP status 1523 codes after a HTTP GET request method is received: 1525 o The interface provides a HTTP/200 status code if the interface was 1526 able to provide the LORDN Log file. The LORDN Log file is 1527 contained in the HTTP Entity-body. 1529 o The interface provides a HTTP/204 status code if the LORDN 1530 Transaction Identifier is correct, but the server has not 1531 finalized processing the LORDN file. 1533 o The interface provides a HTTP/400 status code if the request is 1534 incorrect. 1536 o The interface provides a HTTP/401 status code if the credentials 1537 provided does not authorize the Registry Operator to download the 1538 LORDN Log file. 1540 o The interface provides a HTTP/404 status code if the LORDN 1541 Transaction Identifier is incorrect. 1543 o The interface provides a HTTP/500 status code if the system is 1544 experiencing a general failure. 1546 For example, to obtain the LORN Log File in case of a Sunrise LORDN 1547 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1548 "example" the URI would be: 1550 < https:///LORDN/example/sunrise/ 1551 0000000000000000001/result > 1553 The LORDN Log file is contained in a CSV-like formatted file that has 1554 the following structure: 1556 o first line: ,,,,,, 1560 Where: 1562 + , version of the file, this field MUST be 1. 1564 + , date and time in UTC that the 1565 LORDN Log was created. 1567 + , date and time in UTC of 1568 creation for the LORDN file that this log file is referring 1569 to. 1571 + , unique identifier of the LORDN Log 1572 provided by the TMDB. This identifier could be used by the 1573 Registry Operator to unequivocally identify the LORDN Log. 1574 The identified will be a string of a maximum LENGTH of 60 1575 characters from the Base 64 alphabet. 1577 + , whether the LORDN file has been accepted for 1578 processing by the TMDB. Possible values are "accepted" or 1579 "rejected". 1581 + , whether the LORDN Log has any warning result 1582 codes. Possible values are "no-warnings" or "warnings- 1583 present". 1585 + , number of DNs effective allocations 1586 processed in the LORDN file. 1588 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1589 a ="accepted" and ="no-warnings". 1591 o second line: a header line as specified in [RFC4180] 1593 With the header names as follows: 1595 roid,result-code 1597 o One or more lines with: , 1599 Where: 1601 + , DN Repository Object IDentifier (DNROID) in the SRS. 1603 + , result code as described in Section 6.3.1.1. 1605 Example for LORDN Log file 1607 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1608 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1609 accepted,no-warnings,1 1610 roid,result-code 1611 SH8013-REP,2000 1613 Figure 13 1615 6.3.1.1. LORDN Log Result Codes 1617 In Figure 14 the classes of result codes (rc) are listed. Those 1618 classes in square brackets are not used at this time, but may come 1619 into use at some later stage. The first two digits of a result code 1620 denote the result code class, which defines the outcome at the TMDB: 1622 o ok: Success, DN Line accepted by the TMDB. 1624 o warn: a warning is issued, DN Line accepted by the TMDB. 1626 o err: an error is issued, LORDN file rejected by the TMDB. 1628 In case that after processing a DN Line, the error result code is 1629 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1630 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1631 valid will be reported with a 2001 result code. A 2001 result code 1632 means that the DN Line is syntactically valid, however the DN Line 1633 was not processed because the LORDN file was rejected. All DNs 1634 reported in a rejected LORDN file MUST be reported again by the 1635 Registry because none of the DN Lines present in the LORDN file have 1636 been processed by the TMDB. 1638 LORDN Log Result Code Classes 1640 code Class outcome 1641 ---- ----- ------- 1643 20xx Success ok 1645 35xx [ DN Line syntax warning ] warn 1646 36xx DN Line semantic warning warn 1648 45xx DN Line syntax error err 1649 46xx DN Line semantic error err 1651 Figure 14 1653 In the following, the LORDN Log result codes used by the TMDB are 1654 described: 1656 LORDN Log result Codes 1658 rc Short Description 1659 Long Description 1661 ---- ------------------------------------------------------------- 1663 2000 OK 1664 DN Line successfully processed. 1666 2001 OK but not processed 1667 DN Line is syntactically correct but was not processed 1668 because the LORDN file was rejected. 1670 3601 TCN Acceptance Date after Registration Date 1671 TCN Acceptance Date in DN Line is newer than the Registration 1672 Date. 1674 3602 Duplicate DN Line 1675 This DN Line is an exact duplicate of another DN Line in same 1676 file, DN Line ignored. 1678 3603 DNROID Notified Earlier 1679 Same DNROID has been notified earlier, DN Line ignored. 1681 3604 TCN Checksum invalid 1682 Based on the DN effectively allocated, the TCNID and the 1683 expiration date of the linked TCN, the TCN Checksum is 1684 invalid. 1686 3605 TCN Expired 1687 The TCN was already expired at the time of acknowledgement. 1689 3606 Wrong TCNID used 1690 The TCNID used for the registration does not match 1691 the related DN. 1693 3609 Invalid SMD used 1694 The SMD used for registration was not valid. 1695 In case of an asynchronous registration, this refer to the 1696 . 1698 3610 DN reported outside of the time window 1699 The DN was reported outside of the required 26 hours 1700 reporting window. 1702 4501 Syntax Error in DN Line 1703 Syntax Error in DN Line. 1705 4601 Invalid TLD used 1706 The TLD in the DN Line does not match what is expected for 1707 this LORDN. 1709 4602 Registrar ID Invalid 1710 Registrar ID in DN Line is not a valid ICANN-Accredited 1711 Registrar. 1713 4603 Registration Date in the future 1714 The in the DN Line is in the 1715 future. 1717 4604 Sunrise DN / application reported for TLD in Claims 1718 The was reported in Sunrise LORDN 1719 when the TLD was in Claims. 1720 In case of an asynchronous registration, 1721 the is used when 1722 validating the DN Line. 1724 4605 Claims DN / application reported for TLD in Sunrise 1725 The was reported in Claims LORDN 1726 when the TLD was in Sunrise. 1727 In case of an asynchronous registration, 1728 the is used when 1729 validating the DN Line. 1731 4606 TLD not in Sunrise or Claims 1732 The was reported when the TLD was 1733 not in Sunrise or Claims. 1734 In case of an asynchronous registration, 1735 the is used when 1736 validating the DN Line. 1738 Figure 15 1740 6.4. SMD File 1742 This section defines the format of the SMD File. After a successful 1743 registration of a mark, the TMV returns an SMD File to the TMH. The 1744 SMD File can then be used for registration of one or more DNs covered 1745 by the PRM during the Sunrise Period of a TLD. 1747 Two encapsulation boundaries are defined for delimiting the 1748 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1749 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1750 boundaries MUST be used by Registries and Registrars for validation 1751 purposes, i.e. any data outside these boundaries as well as the 1752 boundaries themselves MUST be ignored for validation purposes. 1754 The structure of the SMD File is as follows: 1756 o Marks: 1758 o smdID: 1760 o U-labels: 1763 o notBefore: 1765 o notAfter: 1767 o -----BEGIN ENCODED SMD----- 1769 o 1771 o -----END ENCODED SMD----- 1772 Example for SMD File (shortened at [...]): 1774 Marks: Example One 1775 smdID: 1-2 1776 U-labels: example-one, exampleone 1777 notBefore: 2011-08-16 09:00 1778 notAfter: 2012-08-16 09:00 1779 -----BEGIN ENCODED SMD----- 1780 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1781 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1782 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1783 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 1784 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 1785 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 1786 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 1787 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 1788 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 1789 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 1790 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 1791 [...] 1792 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 1793 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 1794 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 1795 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 1796 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 1797 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 1798 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1799 -----END ENCODED SMD----- 1801 Figure 16 1803 6.5. Trademark Claims Notice 1805 The TMDB MUST provide the TCN to Registrars in XML format as 1806 specified below. 1808 An enclosing element that describes the Trademark 1809 Notice to a given label. 1811 The child elements of the element include: 1813 o A element that contains the unique identifier of the 1814 Trademark Notice. This element contains the the TCNID. 1816 The TCNID is a string concatenation of a TCN Checksum and the 1817 TMDB Notice Identifier. The first 8 characters of the TCNID is 1818 a TCN Checksum. The rest is the TMDB Notice Identifier, which 1819 is a zero-padded natural number in the range of 1820 0000000000000000001 to 9223372036854775807. 1822 Example of a TCNID: 1824 370d0b7c9223372036854775807. 1826 Where: 1828 + TCN Checksum=370d0b7c 1830 + TMDB Notice Identifier=9223372036854775807 1832 The TCN Checksum is a 8 characters long Base16 encoded output 1833 of computing the CRC32 of the string concatenation of: label + 1834 unix_timestamp() + TMDB Notice Identifier 1836 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is 1838 defined as the number of seconds that have elapsed since 1970- 1839 01-01T00:00:00Z not counting leap seconds. For example, the 1840 conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: 1842 unix_time(2010-08-16T09:00:00.0Z)=1281949200 1844 The TMDB uses the and 1845 elements from the TCN along with the TMDB Notice Identifier to 1846 compute the TCN Checksum. 1848 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 1849 of the DN being registered, the expiration datetime of the TCN 1850 (provided by the Registrar) and the TMDB Notice Identifier 1851 extracted from the TCNID (provided by the Registrar) to compute 1852 the TCN Checksum. For example the DN "foo.bar.example" being 1853 effectively allocated, the left most label would be "foo". 1855 Example of computation of the TCN Checksum: 1857 CRC32(example-one12819492009223372036854775807)=370d0b7c 1859 o A element that contains the start of the 1860 validity date and time of the TCN. 1862 o A element that contains the expiration date 1863 and time of the TCN. 1865 o A elements that contain the DNL (A-label in case 1866 of IDNs) form of the label that correspond to the DN covered by a 1867 PRM. 1869 o One or more elements that contain the Trademark 1870 Claim. The element contains the following child 1871 elements: 1873 * A element that contains the mark text 1874 string. 1876 * One or more elements that contains the 1877 information of the holder of the mark. An "entitlement" 1878 attribute is used to identify the entitlement of the holder, 1879 possible values are: owner, assignee or licensee. The child 1880 elements of include: 1882 + An OPTIONAL element that contains the name 1883 of the holder. A MUST be specified if 1884 is not specified. 1886 + An OPTIONAL element that contains the name of 1887 the organization holder of the mark. A MUST 1888 be specified if is not specified. 1890 + A element that contains the address 1891 information of the holder of a mark. A 1892 contains the following child elements: 1894 - One, two or three OPTIONAL elements 1895 that contains the organization's street address. 1897 - A element that contains the 1898 organization's city. 1900 - An OPTIONAL element that contains the 1901 organization's state or province. 1903 - An OPTIONAL element that contains the 1904 organization's postal code. 1906 - A element that contains the organization's 1907 country code. This a two-character code from 1908 [ISO3166-2]. 1910 + An OPTIONAL element that contains the 1911 organization's voice telephone number. 1913 + An OPTIONAL element that contains the 1914 organization's facsimile telephone number. 1916 + An OPTIONAL element that contains the email 1917 address of the holder. 1919 * Zero or more OPTIONAL elements that contains 1920 the information of the representative of the mark registration. 1921 A "type" attribute is used to identify the type of contact, 1922 possible values are: owner, agent or thirdparty. The child 1923 elements of include: 1925 + A element that contains name of the 1926 responsible person. 1928 + An OPTIONAL element that contains the name of 1929 the organization of the contact. 1931 + A element that contains the address 1932 information of the contact. A contains the 1933 following child elements: 1935 - One, two or three OPTIONAL elements 1936 that contains the contact's street address. 1938 - A element that contains the contact's 1939 city. 1941 - An OPTIONAL element that contains the 1942 contact's state or province. 1944 - An OPTIONAL element that contains the 1945 contact's postal code. 1947 - A element that contains the contact's 1948 country code. This a two-character code from 1949 [ISO3166-2]. 1951 + A element that contains the contact's voice 1952 telephone number. 1954 + An OPTIONAL element that contains the 1955 contact's facsimile telephone number. 1957 + A element that contains the contact's email 1958 address. 1960 * A element that contains the name (in 1961 English) of the jurisdiction where the mark is protected. A 1962 jurCC attribute contains the two-character code of the 1963 jurisdiction where the mark was registered. This is a two- 1964 character code from [WIPO.ST3]. 1966 * Zero or more OPTIONAL element that 1967 contains the description (in English) of the Nice 1968 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 1969 attribute contains the class number. 1971 * A element that contains the full 1972 description of the goods and services mentioned in the mark 1973 registration document. 1975 * An OPTIONAL element signals that the 1976 claim notice was added to the TCN based on other rule than 1977 exact match as defined in [ICANN-GTLD-AGB-20120604]. The 1978 contains one or more: 1980 + An OPTIONAL element that signals that the 1981 claim notice was added because of a previously abused name 1982 included in an UDRP case. The contains: 1984 - A element that contains the UDRP case 1985 number used to validate the previously abused name. 1987 - A element that contains the name 1988 of the UDRP provider. 1990 + An OPTIONAL element that signals that the 1991 claim notice was added because of a previously abused name 1992 included in an court's resolution. The 1993 contains: 1995 - A element that contains the reference 1996 number of the court's resolution used to validate the 1997 previously abused name. 1999 - A element that contains the two-character 2000 code from [ISO3166-2] of the jurisdiction of the court. 2002 - A element that contains the name of 2003 the court. 2005 Example of object: 2007 2008 2009 370d0b7c9223372036854775807 2010 2010-08-14T09:00:00.0Z 2011 2010-08-16T09:00:00.0Z 2012 example-one 2013 2014 Example One 2015 2016 Example Inc. 2017 2018 123 Example Dr. 2019 Suite 100 2020 Reston 2021 VA 2022 20190 2023 US 2024 2025 2026 2027 Joe Doe 2028 Example Inc. 2029 2030 123 Example Dr. 2031 Suite 100 2032 Reston 2033 VA 2034 20190 2035 US 2036 2037 +1.7035555555 2038 jdoe@example.com 2039 2040 UNITED STATES OF AMERICA 2041 2042 Advertising; business management; business administration. 2043 2044 2045 Insurance; financial affairs; monetary affairs; real estate. 2046 2047 2048 Bardus populorum circumdabit se cum captiosus populum. 2049 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2050 2051 2052 2053 Example-One 2054 2055 Example S.A. de C.V. 2056 2057 Calle conocida #343 2058 Conocida 2059 SP 2060 82140 2061 BR 2062 2063 2064 BRAZIL 2065 2066 Bardus populorum circumdabit se cum captiosus populum. 2067 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2068 2069 2070 2071 One 2072 2073 One Corporation 2074 2075 Otra calle 2076 Otra ciudad 2077 OT 2078 383742 2079 CR 2080 2081 2082 COSTA RICA 2083 2084 Bardus populorum circumdabit se cum captiosus populum. 2085 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2086 2087 2088 2089 234235 2090 CR 2091 Supreme Court of Justice of Costa Rica 2092 2093 2094 2095 2096 One Inc 2097 2098 One SA de CV 2099 2100 La calle 2101 La ciudad 2102 CD 2103 34323 2104 AR 2105 2106 2107 ARGENTINA 2108 2109 Bardus populorum circumdabit se cum captiosus populum. 2110 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2111 2112 2113 2114 D2003-0499 2115 WIPO 2116 2117 2118 2119 2121 For formal syntax of the TCN please refer to Section 7.1. 2123 7. Formal Syntax 2125 7.1. Trademark Claims Notice 2127 The schema presented here is for a Trademark Claims Notice. 2129 Copyright (c) 2012 IETF Trust and the persons identified as authors 2130 of the code. All rights reserved. 2132 Redistribution and use in source and binary forms, with or without 2133 modification, are permitted provided that the following conditions 2134 are met: 2136 o Redistributions of source code must retain the above copyright 2137 notice, this list of conditions and the following disclaimer. 2139 o Redistributions in binary form must reproduce the above copyright 2140 notice, this list of conditions and the following disclaimer in 2141 the documentation and/or other materials provided with the 2142 distribution. 2144 o Neither the name of Internet Society, IETF or IETF Trust, nor the 2145 names of specific contributors, may be used to endorse or promote 2146 products derived from this software without specific prior written 2147 permission. 2149 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2150 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2151 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2152 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2153 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2154 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2155 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2156 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2157 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2158 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2159 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2161 BEGIN 2162 2163 2168 2169 2170 Schema for representing a Trademark Notice. 2171 2172 2173 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2195 2196 2197 2198 2199 2200 2202 2204 2205 2207 2208 2210 2211 2212 2213 2214 2215 2216 2217 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2268 2269 2270 2271 2272 2273 2274 2275 END 2277 8. Acknowledgements 2279 This specification is a collaborative effort from several 2280 participants in the ICANN community. Bernie Hoeneisen participated 2281 as co-author until version 02 providing invaluable support for this 2282 document. This specification is based on a model spearheaded by: 2283 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2284 would also like to thank the thoughful feedbak provided by many in 2285 the tmch-tech mailing list, but particularly the extensive help 2286 provided by James Gould, James Mitchell and Francisco Arias. 2288 9. IANA Considerations 2290 This document uses URNs to describe XML namespaces and XML schemas 2291 conforming to a registry mechanism described in [RFC3688]. One URI 2292 assigment have been registered by the IANA. 2294 Registration request for the Trademark Claims Notice: 2296 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2298 Registrant Contact: See the "Author's Address" section of this 2299 document. 2301 XML: None. Namespace URIs do not represent an XML specification. 2303 10. Security Considerations 2305 TBD 2307 11. References 2308 11.1. Normative References 2310 [I-D.lozano-tmch-smd] 2311 Lozano, G., "Mark and Signed Mark Objects Mapping", 2312 draft-lozano-tmch-smd-02 (work in progress), March 2013. 2314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2315 Requirement Levels", BCP 14, RFC 2119, March 1997. 2317 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2318 January 2004. 2320 11.2. Informative References 2322 [ICANN-GTLD-AGB-20120604] 2323 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2324 June 2012, . 2327 [ISO3166-2] 2328 ISO, "International Standard for country codes and codes 2329 for their subdivisions", 2006. 2331 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2332 STD 13, RFC 1034, November 1987. 2334 [RFC1035] Mockapetris, P., "Domain names - implementation and 2335 specification", STD 13, RFC 1035, November 1987. 2337 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 2338 RFC 1591, March 1994. 2340 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2341 E. Lear, "Address Allocation for Private Internets", 2342 BCP 5, RFC 1918, February 1996. 2344 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2345 Randers-Pehrson, "GZIP file format specification version 2346 4.3", RFC 1952, May 1996. 2348 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2349 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2350 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2352 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2354 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2355 Internet: Timestamps", RFC 3339, July 2002. 2357 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2358 Separated Values (CSV) Files", RFC 4180, October 2005. 2360 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2361 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2363 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2364 Encodings", RFC 4648, October 2006. 2366 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2367 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2369 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2370 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2372 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2373 Housley, R., and W. Polk, "Internet X.509 Public Key 2374 Infrastructure Certificate and Certificate Revocation List 2375 (CRL) Profile", RFC 5280, May 2008. 2377 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2378 STD 69, RFC 5730, August 2009. 2380 [RFC5890] Klensin, J., "Internationalized Domain Names for 2381 Applications (IDNA): Definitions and Document Framework", 2382 RFC 5890, August 2010. 2384 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2385 Infrastructure Certificate and Certificate Revocation List 2386 (CRL) Profile", RFC 6818, January 2013. 2388 [WIPO-NICE-CLASSES] 2389 WIPO, "Nice List of Classes", . 2392 [WIPO.ST3] 2393 WIPO, "Recommended standard on two-letter codes for the 2394 representation of states, other entities and 2395 intergovernmental organizations", March 2007. 2397 Appendix A. Document Changelog 2399 [RFC Editor: This section is to be removed before publication] 2401 Author's Address 2403 Gustavo Lozano 2404 ICANN 2405 12025 Waterfront Drive, Suite 300 2406 Los Angeles 90292 2407 US 2409 Phone: +1.3103015800 2410 Email: gustavo.lozano@icann.org