idnits 2.17.1 draft-lozano-tmch-func-spec-07.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 (Aug 09, 2013) is 3903 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9A-F' is mentioned on line 1208, but not defined == Unused Reference: 'RFC1918' is defined on line 2396, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 2400, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 2416, 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 Aug 09, 2013 5 Expires: February 10, 2014 7 TMCH functional specifications 8 draft-lozano-tmch-func-spec-07 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 February 10, 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 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 120 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 121 12.1. Normative References . . . . . . . . . . . . . . . . . . . 59 122 12.2. Informative References . . . . . . . . . . . . . . . . . . 59 123 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 61 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 61 126 1. Introduction 128 Domain Name Registries may operate in special modes within certain 129 periods of time to facilitate registration of domain names. 131 Along with the upcoming introduction of new generic Top Level Domains 132 (gTLD), two special modes will come into effect: 134 o Sunrise Period 136 o Trademark Claims Period 138 The Sunrise and Trademark Claims Periods are defined in the gTLD 139 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 141 This document describes the requirements, the architecture and the 142 interfaces between the Trademark Clearing House (TMCH) and Domain 143 Name Registries (called Registries in the rest of the document) as 144 well as between the TMCH and Domain Name Registrars (called 145 Registrars in the rest of the document) for the provisioning and 146 management of domain names during the Sunrise and Trademark Claims 147 Periods. 149 For any date and/or time indications, Coordinated Universal Time 150 (UTC) applies. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 XML is case sensitive. Unless stated otherwise, XML specifications 159 and examples provided in this document MUST be interpreted in the 160 character case presented in order to develop a conforming 161 implementation. 163 "tmNotice-1.0" is used as an abbreviation for 164 "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix 165 "tmNotice" is used, but implementations MUST NOT depend on it and 166 instead employ a proper namespace-aware XML parser and serializer to 167 interpret and output the XML documents. 169 3. Glossary 171 In the following section, the most common terms are briefly 172 explained: 174 o Effective allocation: A DN is considered effectively allocated 175 when the DN object for the DN has been created in the SRS of the 176 Registry and has been assigned to the effective user. A DN object 177 in status "pendingCreate" or any other status that precedes the 178 first time a DN is assigned to an end-user is not considered an 179 effective allocation. A DN object created internally by the 180 Registry for subsequent delegation to another Registrant is not 181 considered an effective allocation. 183 o Backend Registry Operator: Entity that manages (a part of) the 184 technical infrastructure for a Registry Operator. The Registry 185 Operator may also be the Backend Registry Operator. 187 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 189 o CSV: Comma-Separated Values, see [RFC4180] 191 o CNIS, Claims Notice Information Service: This service provides 192 TCNs to Registrars. 194 o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 195 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 197 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 199 o Date and time, datetime: Date and time are specified following the 200 standard "Date and Time on the Internet specification", see 201 [RFC3339]. 203 o DN: Domain Name, domain name, see [RFC1034] 205 o DN Repository Object IDentifier, DNROID: an identifier assigned by 206 the Registry to each DN object that unequivocally identifies said 207 DN object. For example, if a new DN object is created for a name 208 that existed in the past, the DN objects will have different 209 DNROIDs. 211 o DNS: Domain Name System, see [RFC1034] 213 o DNL, Domain Name Label: A label as specified in [RFC1035]. For 214 IDNs the A-Label is used [RFC5890]. 216 o DNL List: A list of DNLs that are covered by a PRM. 218 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 220 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 222 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 224 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246]. 226 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 227 SMD PKI model. 229 o IDN: Internationalized Domain Name, see [RFC5890] 231 o LORDN, List of Registered Domain Names: This is the list of 232 effectively allocated DNs matching a DNL of a PRM. Registries 233 will upload this list to the TMDB (during the NORDN process). 235 o Lookup Key: A random string of up to 51 chars from the set [a-zA- 236 Z0-9/] to be used as the lookup Key by Registrars to obtain the 237 TCN using the CNIS. Lookup Keys are unique and are related to one 238 DNL only. 240 o NORDN, Notification of Registered Domain Names: The process by 241 which Registries upload their recent LORDN to the TMDB. 243 o PGP: Pretty Good Privacy, see [RFC4880] 245 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 247 o PRM, Pre-registered mark: Mark that has been pre-registered with 248 the TMCH. 250 o Registrant: Person or Organization registering a DN via a 251 Registrar. 253 o Registrar, Domain Name Registrar: Entity that registers DNs with 254 the Registry on behalf of the Registrant. 256 o Registry, Registry Operator, Domain Name Registry: Entity that 257 accepts DN registrations from Registrars, maintains the central 258 Database of Registered DNs. A Registry Operator is the 259 contracting party with ICANN for the TLD. 261 o SMD, Signed Mark Data: A cryptographically signed token issued by 262 the TMV to the TMH to be used in the Sunrise Period to apply for a 263 DN that matches a DNL of a PRM; see also [I-D.lozano-tmch-smd] 265 o SMD File: A file containing the SMD (see above) and some human 266 readable data. The latter is usually ignored in the processing of 267 the SMD File. See also Section 6.4. 269 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 270 lists of revoked SMDs (SMD Revocation List); see also 271 [I-D.lozano-tmch-smd] 273 o SMD Revocation List: The SMD Revocation List is used by Registries 274 (and optionally by Registrars) during the Sunrise Period to ensure 275 that an SMD is still valid (i.e. not revoked). The SMD Revocation 276 List has a similar function as CRLs used in PKI. 278 o SRS: Shared Registration System, see also 279 [ICANN-GTLD-AGB-20120604]. 281 o Sunrise Period: During this period DNs matching a DNL of a PRM can 282 be exclusively obtained by the respective TMHs. For DNs matching 283 a PRM, a special process applies to ensure a TMH gets informed on 284 the effective allocation of a DN matching his/her PRM. 286 o TLD: Top Level Domain Name, see [RFC1591] 288 o Trademark, mark: Marks are used to claim exclusive properties of 289 products or services. A mark is typically a name, word, phrase, 290 logo, symbol, design, image, or a combination of these elements. 291 For the scope of this document only textual marks are relevant. 293 o Trademark Claims, Claims: Provides information to enhance the 294 understanding of the Trademark rights being claimed by the TMH. 296 o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A 297 Trademark Claims Notice consist of one or more Trademark Claims 298 and are provided to prospective Registrants of DNs. 300 o Trademark Claims Notice Identifier, TCNID: An element of the 301 Trademark Claims Notice (see above), identifying said TCN. The 302 Trademark Claims Notice Identifier is specified in the element 303 . 305 o Trademark Claims Period: During this period, a special process 306 applies to DNs matching the DNL List, to ensure a TMH gets 307 informed of a DN matching his PRM. For DNs matching the DNL List, 308 Registrars show a TCN to prospective Registrants that has to be 309 acknowledged before effective allocation of the DN. 311 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 312 ICANN central repository for information to be authenticated, 313 stored, and disseminated, pertaining to the rights of TMHs. The 314 Trademark Clearinghouse is split into two functions TMV and TMDB 315 (see below). There could be several entities performing the TMV 316 function, but only one entity performing the TMDB function. 318 o TMDB, Trademark Clearinghouse Database: Serves as a database of 319 the TMCH to provide information to the new gTLD Registries and 320 Registrars to support Sunrise or Trademark Claims Services. There 321 is only one TMDB in the TMCH that concentrates the information 322 about the "verified" Trademark records from the TMVs. 324 o TMH, Trademark Holder: The person or organization owning rights on 325 a mark. 327 o TMV, Trademark Validator, Trademark validation organization: An 328 entity authorized by ICANN to authenticate and validate 329 registrations in the TMDB ensuring the marks qualify as registered 330 or are court-validated marks or marks that are protected by 331 statute or treaty. This entity would also be asked to ensure that 332 proof of use of marks is provided, which can be demonstrated by 333 furnishing a signed declaration and one specimen of current use. 335 o UTC: Coordinated Universal Time, as maintained by the Bureau 336 International des Poids et Mesures (BIPM); see also [RFC3339]. 338 4. Architecture 340 4.1. Sunrise Period 342 Architecture Sunrise Period 344 SMD hand over (out of band; 345 trivial if Registrant == TMH) 346 ........................................... 347 : : 348 : .'''''''''''''''''''. : 349 : . TMCH . : 350 : ..................... : 351 v . . : 352 .------------. . .-------------. . hv .-----. 353 | Registrant | . | TMV |<------->| TMH | 354 '------------' . '-------------' . vh '-----' 355 | . | ^ \ . 356 | . | | \. 357 tr | . vs | | \ 358 | . | | dv .\ 359 v . v | . \ 360 .-----------. sr . .---. | . \ 361 .->| Registrar |<.........| S | vd | . \ 362 : '-----------' . | M | | . \ 363 : | sy . | D | v . \ 364 : ry | .-----------| M | .---. . vc \ 365 : | | . '---' | T | . \ 366 : v v . | M | . v 367 : .-----------. . | D | . .----------. 368 : | Registry |----------------->| B | . | ICANN-CA | 369 : '-----------' . yd '---' . '----------' 370 : ^ . . | : 371 : | ''''''''''''''''''' | : 372 : | cy | : 373 : cr '---------------------------------------' : 374 :.....................................................: 376 Figure 1 378 4.2. Trademark Claims Period 380 Architecture Trademark Claims Period 382 .'''''''''''''. 383 . TMCH . 384 ............... 385 . . 386 .------------. . .-------. . hv .-----. 387 | Registrant | . | TMV |<------->| TMH | 388 '------------' . '-------' . vh '-----' 389 | . ^ . 390 tr | . | dv . 391 | . vd | . 392 v . v . 393 .-----------. dr . .-------. . 394 | Registrar |<--------| T | . 395 '-----------' . | | . 396 | . | M | . 397 ry | . | | . 398 v . | D | . 399 .----------. dy . | | . 400 | Registry |<------->| B | . 401 '----------' yd . '-------' . 402 . . 403 ''''''''''''' 405 Figure 2 407 4.3. Interfaces 409 In the sub-sections below follows a short description of each 410 interface to provide an overview of the architecture. More detailed 411 descriptions of the relevant interfaces follow further below 412 (Section 5). 414 4.3.1. hv 416 The TMH registers a mark with a TMV via the hv interface. 418 After the successful registration of the mark, the TMV makes 419 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 420 TMH to be used during the Sunrise Period. 422 The specifics of the hv interface are beyond the scope of this 423 document. 425 4.3.2. vd 427 After successful mark registration, the TMV ensures the TMDB inserts 428 the corresponding DNLs and mark information into the database via the 429 vd interface. 431 The specifics of the vd interface are beyond the scope of this 432 document. 434 4.3.3. dy 436 Not used during the Sunrise Period. 438 During the Trademark Claims Period the Registry fetches the latest 439 DNL List from the TMDB via the dy interface in regular intervals. 440 The protocol used on the dy interface is HTTPS. 442 4.3.4. tr 444 The Registrant communicates with the Registrar via the tr interface. 446 The specifics of the tr interface are beyond the scope of this 447 document. 449 4.3.5. ry 451 The Registrar communicate with the Registry via the ry interface. 452 The ry interfaces is typically implemented in EPP [RFC5730]. 454 4.3.6. dr 456 Not used during the Sunrise Period. 458 During the Trademark Claims Period, the Registrar fetches the TCN 459 from the TMDB (to be displayed to the Registrant via the tr 460 interface) via the dr interface. The protocol used for fetching the 461 TCN is HTTPS [RFC2818]. 463 4.3.7. yd 465 During the Sunrise period the Registry notifies the TMDB via the yd 466 interface of all DNs effectively allocated. 468 During the Trademark Claims period, the Registry notifies the TMDB 469 via the yd interface of all DNs effectively allocated that matched an 470 entry in the Registry previously downloaded DNL List during the 471 creation of the DN. 473 The protocol used on the yd interface is HTTPS. 475 4.3.8. dv 477 The TMDB notifies via the dv interface to the TMV of all DNs 478 effectively allocated that match a mark registered by that TMV. 480 The specifics of the dv interface are beyond the scope of this 481 document. 483 4.3.9. vh 485 The TMV notifies the TMH via the vh interface after a DN has been 486 effectively allocated that matches a PRM of this TMH. 488 The specifics of the vh interface are beyond the scope of this 489 document. 491 4.3.10. vs 493 The TMV requests to add a revoked SMD to the SMD Revocation List at 494 the SMDM. 496 The specifics of the vs interface are beyond the scope of this 497 document. 499 Not relevant during the Trademark Claims Period. 501 4.3.11. sy 503 During the Sunrise Period the Registry fetches the most recent SMD 504 Revocation List from the SMDM via the sy interface in regular 505 intervals. The protocol used on the sy interface is HTTPS. 507 Not relevant during the Trademark Claims Period. 509 4.3.12. sr 511 During the Sunrise Period the Registrar may fetch the most recent SMD 512 Revocation List from the SMDM via the sr interface. The protocol 513 used on the sr interface is the same as on the sy interface (s. 514 above), i.e. HTTPS. 516 Not relevant during the Trademark Claims Period. 518 4.3.13. vc 520 The TMV requests to add a revoked TMV certificate to the CRL at the 521 ICANN-CA via the vc interface. 523 The specifics of the vc interface are beyond the scope of this 524 document. 526 Not relevant during the Trademark Claims Period. 528 4.3.14. cy 530 During the Sunrise Period the Registry fetches the most recent CRL 531 from the ICANN-CA via the cy interface in regular intervals. The CRL 532 is mainly used for validation of TMV certificates. The protocol used 533 on the cy interface is HTTPS [RFC2818]. 535 Not relevant during the Trademark Claims Period. 537 4.3.15. cr 539 During the Sunrise Period the Registrar may fetch the most recent CRL 540 from the ICANN-CA via the cr interface. The protocol used on the cr 541 interface is the same as on the cy interface. 543 Not relevant during the Trademark Claims Period. 545 5. Process Descriptions 547 5.1. Bootstrap 549 5.1.1. Registries 551 5.1.1.1. Credentials 553 Each Registry Operator will receive authentication credentials from 554 the TMDB/SMDM to be used: 556 o During the Sunrise Period to fetch the SMD Revocation List from 557 the SMDM via the sy interface (Section 4.3.11). 559 o During Trademark Claims Period to fetch the DNL List from the TMDB 560 via the dy interface (Section 4.3.3). 562 o During the NORDN process to notify the LORDN to the TMDB via the 563 yd interface (Section 4.3.7). 565 Note: credentials are created per TLD and provided to the Registry 566 Operator. 568 5.1.1.2. IP Addresses for Access Control 570 Each Registry Operator MUST provide to the TMDB all IP addresses that 571 will be used to: 573 o Fetch the SMD Revocation List via the sy interface 574 (Section 4.3.11). 576 o Fetch the DNL List from the TMDB via the dy interface 577 (Section 4.3.3). 579 o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). 581 This access restriction MAY be applied by the TMDB/SMDM in addition 582 to HTTP Basic access authentication (for credentials to be used, see 583 Section 5.1.1.1). 585 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 586 Registry Operator. 588 5.1.1.3. TMCH Trust Anchor 590 Each Registry Operator MUST fetch the X.509 certificate ([RFC5280] / 591 [RFC6818]) of the ICANN-CA (Trust Anchor) from 592 < https://ca.icann.org/tmch.crt > to be used: 594 o During the Sunrise Period to validate the TMV certificates and the 595 CRL of TMV certificates. 597 5.1.1.4. TMDB/SMDM PGP Key 599 The TMDB MUST provide each Registry Operator with the public portion 600 of the PGP Key used by TMDB and SMDM, to be used: 602 o During the Sunrise Period to perform integrity checking of the SMD 603 Revocation List fetched from the SMDM via the sy interface 604 (Section 4.3.11). 606 o During Trademark Claims Period to perform integrity checking of 607 the DNL List fetched from the TMDB via the dy interface 608 (Section 4.3.3). 610 5.1.2. Registrars 612 5.1.2.1. Credentials 614 Each ICANN-accredited Registrar will receive authentication 615 credentials from the TMDB to be used: 617 o During the Sunrise Period to (optionally) fetch the SMD Revocation 618 List from the SMDM via the sr interface (Section 4.3.12). 620 o During Trademark Claims Period to fetch TCNs from the TMDB via the 621 dr interface (Section 4.3.6). 623 5.1.2.2. IP Addresses for Access Control 625 Each Registrar MUST provide to the TMDB all IP addresses, which will 626 be used to: 628 o Fetch the SMD Revocation List via the sr interface 629 (Section 4.3.12). 631 o Fetch TCNs via the dr interface (Section 4.3.6). 633 This access restriction MAY be applied by the TMDB/SMDM in addition 634 to HTTP Basic access authentication (for credentials to be used, see 635 Section 5.1.2.1). 637 The TMDB MAY limit the number of IP addresses to be accepted per 638 Registrar. 640 5.1.2.3. TMCH Trust Anchor 642 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 643 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 644 be used: 646 o During the Sunrise Period to (optionally) validate the TMV 647 certificates and the CRL of TMV certificates. 649 5.1.2.4. TMDB PGP Key 651 Registrars MUST receive the public portion of the PGP Key used by 652 TMDB and SMDM from the TMDB administrator to be used: 654 o During the Sunrise Period to (optionally) perform integrity 655 checking of the SMD Revocation List fetched from the SMDM via the 656 sr interface (Section 4.3.12). 658 5.2. Sunrise Period 660 5.2.1. Domain Name Registration 662 Registration during Sunrise Period 664 .------------. .-----------. .----------. 665 | Registrant | | Registrar | | Registry | 666 '------------' '-----------' '----------' 667 ^ | | | 668 | | Request DN | | 669 | | Registration | | 670 | | (with SMD) | | 671 | |------------->| Check DN availability | 672 | | |---------------------------->| 673 | | | | 674 | | DN unava. | DN unavailable .-------------. 675 '---|<-------------|<--------------------( DN available? ) 676 | | no '-------------' 677 | | | yes 678 | | DN available | 679 | |<----------------------------| 680 | | | 681 | | Request DN registration | 682 | | (with SMD) | 683 | |---------------------------->| 684 | | | 685 | | .------------------------------. 686 | | | DN registration validation / | 687 | | | SMD validation | 688 | | '------------------------------' 689 | Registration | | 690 | Error |.-----------. Error .----------------------. 691 |<-------------|| TRY AGAIN |<------( Validation successful? ) 692 | || / ABORT | no '----------------------' 693 | |'-----------' | yes 694 | | | 695 | | DN registered | 696 | DN regist. |<----------------------------| 697 |<-------------| | 698 | | | 700 Figure 3 702 5.2.2. DN Registration by Registries 704 Registries MUST perform a minimum set of checks for verifying each DN 705 registration during the Sunrise Period upon reception of a 706 registration request over the ry interface (Section 4.3.5). If any 707 of these checks fails the Registry MUST abort the registration. Each 708 of these checks MUST be performed before the DN is effectively 709 allocated. 711 In case of asynchronous registrations (e.g. auctions), the minimum 712 set of checks MAY be performed when creating the intermediate object 713 (e.g. a DN application) used for DN registration. If the minimum set 714 of checks is performed when creating the intermediate object (e.g. a 715 DN application) a Registry MAY effective allocate the DN without 716 performing the minimum set of checks again. 718 Performing the minimum set of checks Registries MUST verify that: 720 1. A SMD has been received from the Registrar along with the DN 721 registration. 723 2. The certificate of the TMV has been correctly signed by the 724 ICANN-CA. (The certificate of the TMV is contained within the 725 SMD.) 727 3. The time when the validation is done is within the validity 728 period of the TMV certificate. 730 4. The certificate of the TMV is not be listed in the CRL file 731 specified in the CRL distribution point of the TMV certificate. 733 5. The signature of the SMD (signed with the TMV certificate) is 734 valid. 736 6. The time when the validation is done is within the validity 737 period of the SMD based on and 738 elements. 740 7. The SMD has not been revoked, i.e., is not contained in the SMD 741 Revocation List. 743 8. The leftmost DNL (A-label in case of IDNs) of the DN being 744 effectively allocated matches one of the labels () 745 elements in the SMD. 747 These procedure apply to all DN effective allocations at the second 748 level as well as to all other levels subordinate to the TLD that the 749 Registry accepts registrations for. 751 5.2.3. TMCH Sunrise Services for Registries 753 5.2.3.1. SMD Revocation List 755 A new SMD Revocation List MUST be published by the SMDM twice a day, 756 by 00:00:00 and 12:00:00 UTC. 758 Registries MUST refresh the latest version of the SMD Revocation List 759 at least once every 24 hours. 761 Note: the SMD Revocation List will be the same regardless of the TLD. 762 If a Backend Registry Operator manages the infrastructure of several 763 TLDs, the Backend Registry Operator could refresh the SMD Revocation 764 List once every 24 hours, the SMD Revocation List could be used for 765 all the TLDs managed by the Backend Registry Operator. 767 Update SMD Revocation List 769 .----------. .------. 770 | Registry | | SMDM | 771 '----------' '------' 772 | | 773 .----------------. | 774 | Periodically, | | 775 | at least | | 776 | every 24 hours | | 777 '----------------' | 778 | | 779 |----------------------------------------------------->| 780 | Download latest revocation list for SMD certificates | 781 |<-----------------------------------------------------| 782 | | 783 | | 785 Figure 4 787 5.2.3.2. Certificate Revocation List 789 Registries MUST refresh their local copy of the CRL at least every 24 790 hours using the CRL distribution point specified in the TMV 791 certificate. 793 Operationally, the CRL file and CRL distribution point is the same 794 for all TMVs and (at publication of this document) located at 795 < http://crl.icann.org/tmch.crl >. 797 Note: the CRL file will be the same regardless of the TLD. If a 798 Backend Registry Operator manages the infrastructure of several TLDs, 799 the Backend Registry Operator could refresh the CRL file once every 800 24 hours, the CRL file could be used for all the TLDs managed by the 801 Backend Registry Operator. 803 Update CRL for TMV certificates 805 .----------. .----------. 806 | Registry | | ICANN-CA | 807 '----------' '----------' 808 | | 809 .----------------. | 810 | Periodically, | | 811 | at least | | 812 | every 24 hours | | 813 '----------------' | 814 | | 815 |------------------------------------------->| 816 | Download latest CRL for TMV certificates | 817 |<-------------------------------------------| 818 | | 819 | | 821 Figure 5 823 5.2.3.3. Notice of Registered Domain Names 825 The Registry MUST send a LORDN file containing DNs effectively 826 allocated to the TMDB (over the yd interface, Section 4.3.7). 828 The effective allocation of a DN MUST be reported by the Registry to 829 the TMDB within 26 hours of the effective allocation of such DN. 831 The Registry MUST create and upload a LORDN file in case there are 832 effective allocations in the SRS, that have not been successfully 833 reported to the TMDB in a previous LORDN file. 835 Based on the timers used by TMVs and the TMDB, the RECOMMENDED 836 maximum frequency to upload LORDN files from the Registries to the 837 TMDB is every 3 hours. 839 It is RECOMMENDED that Registries try to upload at least two LORDN 840 files per day to the TMDB with enough time in between, in order to 841 have time to fix problems reported in the LORDN file. 843 The Registry SHOULD upload a LORDN file only when the previous LORDN 844 file has been processed by the TMDB and the related LORDN Log file 845 has been downloaded and processed by the Registry. 847 The Registry MUST upload LORDN files for DNs effectively allocated 848 during the Sunrise or Claims period (same applies to DNs effectively 849 allocated using applications created during the Sunrise or Claims 850 period in case of using asynchronous registrations). 852 The yd interface (Section 4.3.7) MUST support at least 1 and MAY 853 support up to 10 concurrent connections from each IP address 854 registered by a Registry Operator to access the service. 856 The TMDB MUST process each uploaded LORDN file and make the related 857 log file available for Registry download within 30 minutes of the 858 finalization of the upload. 860 NORDN 862 .----------. .------. .-----. .-----. 863 | Registry | | TMDB | | TMV | | TMH | 864 '----------' '------' '-----' '-----' 865 | | | | 866 .------------------. | | | 867 | Periodically | | | | 868 | upload LORDN | | | | 869 | file | | | | 870 '------------------' | | | 871 | | | | 872 .--------->| Upload LORDN | | | 873 | |-------------------->| | | 874 | | | | | 875 | | .-------------------------. | | 876 | | | Verify each domain name | | | 877 | | | in the uploaded file | | | 878 | | | (within 30') | | | 879 | | '-------------------------' | | 880 | | | ._____. | | 881 | | Download Log file | | END | | | 882 | |<--------------------| '-----' | | 883 | | | ^ | | 884 | .-----------------. .---------------. | | | 885 | | Check whether | / everything fine \ no | | | 886 | | Log file | ( (i.e. no errors )---' | | 887 | | contains errors | \ in Log file )? / | | 888 | '-----------------' '---------------' | | 889 | | | yes | | 890 | .---------------. | | | 891 | / everything fine \ yes | | | 892 |( (i.e. no errors )-----. | Notify TMVs | | 893 | \ in Log file )? / | | on the LORDN | | 894 | '---------------' | | pre-registered | | 895 | | no v | with said TMV | | 896 | .----------------. .------. |--------------->| | 897 '-| Correct Errors | | DONE | | | | 898 '----------------' '------' | | Notify each | 899 | | | affected TMH | 900 | | |------------->| 901 | | | | 903 Figure 6 905 The format used for the LORDN is described in Section 6.3 907 5.2.4. DN registration by Registrars 909 Registrars MAY choose to perform the checks for verifying DN 910 registrations as performed by the Registries (see Section 5.2.2) 911 before sending the command to register a DN. 913 5.2.5. TMCH Sunrise Services for Registrars 915 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 916 also available for Registrars to optionally validate the SMDs 917 received. 919 5.3. Trademark Claims Period 921 5.3.1. Domain Registration 923 Registration during Trademark Claims Period 925 .------------. .-----------. .----------. .------. 926 | Registrant | | Registrar | | Registry | | TMDB | 927 '------------' '-----------' '----------' '------' 928 ^ | Request DN | | | 929 | | Registration | Check DN availability | | 930 | |------------->|---------------------------->| | 931 | | DN unava. | DN unavailable .-------------. | 932 '---|<-------------|<--------------------( DN available? ) | 933 | | no '-------------' | 934 | | | yes | 935 | | DN available | | 936 | |<----------------------------| | 937 | | Request Lookup key | | 938 | |---------------------------->| | 939 | | .---------. | 940 | |.----------. / Does DN \ | 941 | || CONTINUE |<---------( match DNL ) | 942 | || NORMALLY | no \ of PRM? / | 943 | |'----------' '---------' | 944 | | | yes | 945 | | Lookup key | | 946 | |<----------------------------| | 947 | | Request Claims Notice | 948 | Display |----------------------------------------->| 949 | Claims | | 950 | Notice | Return Claims Notice | 951 |<-------------|<-----------------------------------------| 952 | | | 953 .------. yes | Register DN (TCNID included) | 954 ( Ack? )--------->|---------------------------->| | 955 '------' | | | 956 ||no | Error .----------------------. | 957 || .-------. |<--------------( Validation successful? ) | 958 |'->| ABORT | | no '----------------------' | 959 | '-------' | | yes | 960 | DN regist. | DN registered | | 961 |<-------------|<----------------------------| | 962 | | | | 964 Figure 7 966 5.3.2. DN registration by Registries 968 During Trademark Claim Periods, Registries perform two main 969 functions: 971 o Registries MUST provide Registrars (over the ry interface, 972 Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs 973 that match the DNL List. 975 o Registries MUST provide the Lookup Key only when queried about a 976 specific DN. 978 o For each DN matching a DNL of a PRM, Registries MUST perform a 979 minimum set of checks for verifying DN registrations during 980 Trademark Claims Period upon reception of a registration request 981 over the ry interface (Section 4.3.5). If any of these checks 982 fails the Registry MUST abort the registration. Each of these 983 checks MUST be performed before the DN is effectively allocated. 985 o In case of asynchronous registrations (e.g. auctions), the minimum 986 set of checks MAY be performed when creating the intermediate 987 object (e.g. a DN application) used for DN effective allocation. 988 If the minimum set of checks is performed when creating the 989 intermediate object (e.g. a DN application) a Registry MAY 990 effective allocate the DN without performing the minimum set of 991 checks again. 993 o Performing the minimum set of checks Registries MUST verify that: 995 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been 997 received from the Registrar along with the DN registration. 999 If the three elements mentioned above are not provided by 1000 the Registrar for a DN matching a DNL of a PRM, but the DNL 1001 was inserted (or re-inserted) for the first time into DNL 1002 List less than 24 hours ago, the registration MAY continue 1003 without this data and the tests listed below are not 1004 required to be performed. 1006 2. The TCN has not expired (according to the expiration datetime 1007 sent by the Registrar). 1009 3. The acceptance datetime is no more than 48 hours in the past. 1011 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN 1012 being registered, the expiration datetime provided by the 1013 registrar, and the TMDB Notice Identifier extracted from the 1014 TCNID provided by the registrar compute the TCN Checksum. 1015 Verify that the computed TCN Checksum match the TCN Checksum 1016 present in the TCNID. 1018 These procedures apply to all DN registrations at the second level as 1019 well as to all other levels subordinate to the TLD that the Registry 1020 accepts registrations for. 1022 5.3.3. Trademark Claims Services for Registries 1024 5.3.3.1. Domain Name Label (DNL) List 1026 A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 1027 and 12:00:00 UTC. 1029 Registries MUST refresh the latest version of the DNL List at least 1030 once every 24 hours. 1032 Update DNL List 1034 .----------. .------. 1035 | Registry | | TMDB | 1036 '----------' '------' 1037 | | 1038 .----------------. | 1039 | Periodically, | | 1040 | at least | | 1041 | every 24 hours | | 1042 '----------------' | 1043 | | 1044 |-------------------------------->| 1045 | Download latest list of DNLs | 1046 |<--------------------------------| 1047 | | 1048 | | 1050 Figure 8 1052 Note: the DNL List will be the same regardless of the TLD. If a 1053 Backend Registry Operator manages the infrastructure of several TLDs, 1054 the Backend Registry Operator could refresh the DNL List once every 1055 24 hours, the DNL List could be used for all the TLDs managed by the 1056 Backend Registry Operator. 1058 5.3.3.2. Notice of Registered Domain Names 1060 The NORDN process during the Trademark Claims Period is almost the 1061 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1062 difference that only registrations subject to a Trademark Claim 1063 (i.e., at registration time the name appeared in the current DNL List 1064 downloaded by the Registry Operator) are included in the LORDN. 1066 5.3.4. DN Registration by Registrars 1068 For each DN matching a DNL of a PRM, Registrars MUST perform the 1069 following steps: 1071 1. Use the Lookup Key received from the Registry to obtain the TNC 1072 from the TMDB using the dr interface (Section 4.3.6) Registrars 1073 MUST only query for the Lookup Key of a DN that is available for 1074 registration. 1076 2. Present the TCN to the Registrant as described in 1077 [ICANN-GTLD-AGB-20120604]. 1079 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1080 consent with the TCN, before any further processing. (The 1081 transmission of a TCNID to the Registry over the ry interface, 1082 Section 4.3.5 implies that the Registrant has expressed his 1083 consent with the TCN.) 1085 4. Perform the minimum set of checks for verifying DN registrations. 1086 If any of these checks fails the Registrar MUST abort the DN 1087 registration. Each of these checks MUST be performed before the 1088 registration is sent to the Registry. Performing the minimum set 1089 of checks Registrars MUST verify that: 1091 1. The time when the validation is done is within the TCN 1092 validity based on the and elements. 1095 2. The leftmost DNL (A-label in case of IDNs) of the DN being 1096 effectively allocated matches the label () 1097 element in the TCN. 1099 3. The Registrant has acknowledged (expressed his consent with) 1100 the TCN. 1102 5. Record the date and time when the registrant acknowledged the 1103 TCN. 1105 6. Send the registration to the Registry (ry interface, 1106 Section 4.3.5) and include the following information: 1108 * TCNID () 1110 * Expiration date of the TCN () 1112 * Acceptance datetime of the TCN. 1114 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the 1116 TMDB, allowing the implementation of a cache by Registrars and enough 1117 time for acknowledging the TCN. Registrars SHOULD implement a cache 1118 of TCNs to minimize the number of queries sent to the TMDB. A cached 1119 TCN MUST be removed from the cache after the expiration date of the 1120 TCN as defined by . The TMDB MAY implement rate- 1121 limiting as one of the protection mechanisms to mitigate the risk of 1122 performance degradation. 1124 5.3.5. Trademark Claims Services for Registrars 1126 5.3.5.1. Claims Notice Information Service 1128 The TCNs are provided by the TMDB online and are fetched by the 1129 Registrar via the dr interface (Section 4.3.6). 1131 To get access to the TCNs, the Registrar needs the credentials 1132 provided by the TMDB (Section 5.1.2.1) and the Lookup Key received 1133 from the Registry via the ry interface (Section 4.3.5). The dr 1134 interface (Section 4.3.6) uses HTTPS with Basic access 1135 authentication. 1137 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1138 connections from each Registrar. 1140 The URL of the dr interface (Section 4.3.6) is: 1142 < https:///cnis/.xml > 1144 Note that the "lookupkey" may contain SLASH characters ("/"). The 1145 SLASH character is part of the URL path and MUST NOT be escaped when 1146 requesting the TCN. 1148 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1149 MUST be signed by a well-know public CA. Registrars MUST perform the 1150 Certification Path Validation described in Section 6 of [RFC5280]. 1151 Registrars will be authenticated in the dr interface using HTTP Basic 1152 access authentication. The dr (Section 4.3.6) interface MUST support 1153 HTTPS keep-alive and MUST maintain the connection for up to 30 1154 minutes. 1156 6. Data Format Descriptions 1158 6.1. DNL List file 1160 This section defines format of the list containing every Domain Name 1161 Label (DNL) that matches a Pre-Registered Mark (PRM). The list is 1162 maintained by the TMDB and downloaded by Registries in regular 1163 intervals (see Section 5.3.3.1). The Registries use the DNL List 1164 during the Trademark Claims period to check whether a requested DN 1165 matched a DNL of a PRM. 1167 The DNL List contains all the DNLs covered by a PRM present in the 1168 TMDB at the time it is generated. 1170 The DNL List is contained in a CSV-like formatted file that has the 1171 following structure: 1173 o first line: , 1175 Where: 1177 + , version of the file, this field MUST be 1. 1179 + , date and time in UTC that the 1180 DNL List was created. 1182 o second line: a header line as specified in [RFC4180] 1184 With the header names as follows: 1186 DNL,lookup-key,insertion-datetime 1188 o One or more lines with: ,, 1191 Where: 1193 + , a Domain Name Label covered by a PRM. 1195 + , lookup key that the Registry MUST provide to 1196 the Registrar. The lookup key has the following format: 1197
////, where: 1200 - YYYY: year that the TCN was generated. 1202 - MM: zero-padded month that the TCN was generated. 1204 - DD: zero-padded day that the TCN was generated. 1206 - vv: version of the TCN, possible values are 00 and 01. 1208 - X: one hexadecimal digit [0-9A-F]. This is the first, 1209 second and third hexadecimal digit of encoding the 1210 in base16 as specified in [RFC4648]. 1212 - Random bits: 144 random bits encoded in base64url as 1213 specified in [RFC4648]. 1215 - Sequential number: zero-padded natural number in the 1216 range 0000000001 to 2147483647. 1218 + , datetime in UTC that the DNL was 1219 first inserted into the DNL List. The possible two values 1220 of time for inserting a DNL to the DNL List are 00:00:00 and 1221 12:00:00 UTC. 1223 Example for DNL List 1225 1,2012-08-16T00:00:00.0Z 1226 DNL,lookup-key,insertion-datetime 1227 example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 1228 2010-07-14T00:00:00.0Z 1229 another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 1230 2012-08-16T00:00:00.0Z 1231 anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 1232 2011-08-16T12:00:00.0Z 1234 Figure 9 1236 To provide authentication and integrity protection, the DNL List will 1237 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1238 (see also Section 5.1.1.4). The PGP signature of the DNL List can be 1239 found in the similar URI but with extension .sig as shown below. 1241 The URL of the dy interface (Section 4.3.3) is: 1243 o < https:///dnl/dnl-latest.csv > 1245 o < https:///dnl/dnl-latest.sig > 1247 6.2. SMD Revocation List 1249 This section defines the format of the list of SMDs that have been 1250 revoked. The list is maintained by the SMDM and downloaded by 1251 Registries (and optionally by Registrars) in regular intervals (see 1252 Section 5.2.3.1). The SMD Revocation List is used during the Sunrise 1253 Period to validate SMDs received. The SMD Revocation List has a 1254 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1256 The SMD Revocation List contains all the revoked SMDs present in the 1257 TMDB at the time it is generated. 1259 The SMD Revocation List is contained in a CSV-like formatted file 1260 that has the following structure: 1262 o first line: , 1264 Where: 1266 + , version of the file, this field MUST be 1. 1268 + , datetime in UTC 1269 that the SMD Revocation List was created. 1271 o second line: a header line as specified in [RFC4180] 1273 With the header names as follows: 1275 smd-id,insertion-datetime 1277 o One or more lines with: , 1279 Where: 1281 + , identifier of the SMD that was revoked. 1283 + , revocation datetime in UTC of the 1284 SMD. The possible two values of time for inserting a DNL to 1285 the DNL List are 00:00:00 and 12:00:00 UTC. 1287 To provide integrity protection, the SMD Revocation List is PGP 1288 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1289 also Section 5.1.1.4). The SMD Revocation List is provided by the 1290 TMDB with extension .csv. The PGP signature of the SMD Revocation 1291 List can be found in the similar URI but with extension .sig as shown 1292 below. 1294 The URL of the sr interface (Section 4.3.12) and sy interface 1295 (Section 4.3.11) is: 1297 o < https:///smdrl/smdrl-latest.csv > 1299 o < https:///smdrl/smdrl-latest.sig > 1301 Example for SMD Revocation list 1303 1,2012-08-16T00:00:00.0Z 1304 smd-id,insertion-datetime 1305 2-2,2012-08-15T00:00:00.0Z 1306 3-2,2012-08-15T00:00:00.0Z 1307 1-2,2012-08-15T00:00:00.0Z 1309 Figure 10 1311 6.3. LORDN File 1313 This section defines the format of the List of Registered Domain 1314 Names (LORDN), which is maintained by each Registry and uploaded at 1315 least daily to the TMDB. Every time a DN matching a DNL of a PRM 1316 said DN is added to the LORDN along with further information related 1317 to its registration. 1319 The URI of the yd interface (Section 4.3.7) used to upload the LORDN 1320 file is: 1322 o Sunrise LORDN file: 1324 < https:///LORDN//sunrise > 1326 o Claims LORDN file: 1328 < https:///LORDN//claims > 1330 The yd interface (Section 4.3.7) returns the following HTTP status 1331 codes after a HTTP POST request method is received: 1333 o The interface provides a HTTP/202 status code if the interface was 1334 able to receive the LORDN file and the syntax of the LORDN file is 1335 correct. 1337 The interface provides the LORDN Transaction Identifier in the 1338 HTTP Entity-body that would be used by the Registry to download 1339 the LORDN Log file. The LORDN Transaction Identifier is a 1340 natural number zero-padded in the range 0000000000000000001 to 1341 9223372036854775807. 1343 The TMDB uses the element of the 1344 LORDN file as a unique client-side identifier. If a LORDN file 1345 with the same of a previously sent 1346 LORDN file is received by the TMDB, the LORDN Transaction 1347 Identifier of the previously sent LORDN file MUST be provided 1348 to the Registry. The TMDB MUST ignore the DN Lines present in 1349 the LORDN file if a LORDN file with the same was previously sent. 1352 The HTTP Location header field contains the URI where the LORDN 1353 Log file could be retrieved later, for example: 1355 202 Accepted 1357 Location: https:///LORDN/example/sunrise/ 1358 0000000000000000001/result 1360 o The interface provides a HTTP/400 if the request is incorrect or 1361 the syntax of the LORDN file is incorrect. The TMDB MUST return a 1362 human readable message in the HTTP Entity-body regarding the 1363 incorrect syntax of the LORDN file. 1365 o The interface provides a HTTP/401 status code if the credentials 1366 provided does not authorize the Registry Operator to upload a 1367 LORDN file. 1369 o The interface provides a HTTP/500 status code if the system is 1370 experiencing a general failure. 1372 For example, to upload the Sunrise LORDN file for TLD "example", the 1373 URI would be: 1375 < https:///LORDN/example/sunrise > 1377 The LORDN is contained in a CSV-like formatted file that has the 1378 following structure: 1380 o For Sunrise Period: 1382 * first line: ,, 1385 Where: 1387 - , version of the file, this field MUST be 1. 1389 - , date and time in UTC that the 1390 LORDN was created. 1392 - , number of DN Lines present in the 1393 LORDN file. 1395 * second line: a header line as specified in [RFC4180] 1397 With the header names as follows: 1399 roid,domain-name,SMD-id,registrar-id,registration- 1400 datetime,application-datetime 1402 * One or more lines with: ,,,,, 1406 Where: 1408 - , DN Repository Object IDentifier (DNROID) in the 1409 SRS. 1411 - , DN that was effectively allocated. For 1412 IDNs the A-Label is used [RFC5890] 1414 - , SMD ID used for registration. 1416 - , IANA Registrar ID. 1418 - , date and time in UTC that the 1419 domain was effectively allocated. 1421 - OPTIONAL , date and 1422 time in UTC that the application was created. The 1423 MUST be provided in 1424 case of a DN effective allocation based on an 1425 asynchronous registration (e.g., when using auctions). 1427 Example for LORDN during Sunrise 1429 1,2012-08-16T00:00:00.0Z,3 1430 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ 1431 application-datetime 1432 SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 1433 2012-07-15T00:50:00.0Z 1434 EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z 1435 HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z 1437 Figure 11 1439 o For Trademark Claims Period: 1441 * first line: ,, 1444 Where: 1446 - , version of the file, this field MUST be 1. 1448 - , date and time in UTC that the 1449 LORDN was created. 1451 - , number of DN Lines present in the 1452 LORDN file. 1454 * second line: a header line as specified in [RFC4180] 1456 With the header names as follows: 1458 roid,domain-name,notice-id,registrar-id,registration- 1459 datetime,ack-datetime,application-datetime 1461 * One or more lines with: ,,,,,, 1465 Where: 1467 - , DN Repository Object IDentifier (DNROID) in the 1468 SRS. 1470 - , DN that was effectively allocated. For 1471 IDNs the A-Label is used [RFC5890]. 1473 - , Trademark Claims Notice Identifier as specified 1474 in . 1476 - , IANA Registrar ID. 1478 - , date and time in UTC that the 1479 domain was effectively allocated. 1481 - , date and time in UTC 1482 that the TCN was acknowledged. 1484 - OPTIONAL , date and 1485 time in UTC that the application was created. The 1486 MUST be provided in 1487 case of a DN effective allocation based on an 1488 asynchronous registration (e.g., when using auctions). 1490 For a DN matching a DNL of a PRM at the moment of 1491 registration, created without the TCNID, expiration datetime 1492 and acceptance datetime, because DNL was inserted (or re- 1493 inserted) for the first time into DNL List less than 24 1494 hours ago, the string "recent-dnl-insertion" MAY be 1495 specified in and . 1498 Example for LORDN during Claims 1500 1,2012-08-16T00:00:00.0Z,3 1501 roid,domain-name,notice-id,registrar-id,registration-datetime,\ 1502 ack-datetime,application-datetime 1503 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1504 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1505 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1506 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1507 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1508 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1510 Figure 12 1512 6.3.1. LORDN Log File 1514 After reception of the LORDN file, the TMDB verifies its content for 1515 syntactical and semantical correctness. The output of the LORDN file 1516 verification is retrieved using the yd interface (Section 4.3.7). 1518 The URI of the yd interface (Section 4.3.7) used to retrieve the 1519 LORDN Log File is: 1521 o Sunrise LORDN Log file: 1523 < https:///LORDN//sunrise/ 1524 /result > 1526 o Claims LORDN Log file: 1528 < https:///LORDN//claims/ 1529 /result > 1531 A Registry Operator MUST NOT send more than one request per minute 1532 per TLD to download a LORDN Log file. 1534 The yd interface (Section 4.3.7) returns the following HTTP status 1535 codes after a HTTP GET request method is received: 1537 o The interface provides a HTTP/200 status code if the interface was 1538 able to provide the LORDN Log file. The LORDN Log file is 1539 contained in the HTTP Entity-body. 1541 o The interface provides a HTTP/204 status code if the LORDN 1542 Transaction Identifier is correct, but the server has not 1543 finalized processing the LORDN file. 1545 o The interface provides a HTTP/400 status code if the request is 1546 incorrect. 1548 o The interface provides a HTTP/401 status code if the credentials 1549 provided does not authorize the Registry Operator to download the 1550 LORDN Log file. 1552 o The interface provides a HTTP/404 status code if the LORDN 1553 Transaction Identifier is incorrect. 1555 o The interface provides a HTTP/500 status code if the system is 1556 experiencing a general failure. 1558 For example, to obtain the LORDN Log File in case of a Sunrise LORDN 1559 file with LORDN Transaction Identifier 0000000000000000001 and TLD 1560 "example" the URI would be: 1562 < https:///LORDN/example/sunrise/ 1563 0000000000000000001/result > 1565 The LORDN Log file is contained in a CSV-like formatted file that has 1566 the following structure: 1568 o first line: ,,,,,, 1572 Where: 1574 + , version of the file, this field MUST be 1. 1576 + , date and time in UTC that the 1577 LORDN Log was created. 1579 + , date and time in UTC of 1580 creation for the LORDN file that this log file is referring 1581 to. 1583 + , unique identifier of the LORDN Log 1584 provided by the TMDB. This identifier could be used by the 1585 Registry Operator to unequivocally identify the LORDN Log. 1586 The identified will be a string of a maximum LENGTH of 60 1587 characters from the Base 64 alphabet. 1589 + , whether the LORDN file has been accepted for 1590 processing by the TMDB. Possible values are "accepted" or 1591 "rejected". 1593 + , whether the LORDN Log has any warning result 1594 codes. Possible values are "no-warnings" or "warnings- 1595 present". 1597 + , number of DNs effective allocations 1598 processed in the LORDN file. 1600 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1601 a ="accepted" and ="no-warnings". 1603 o second line: a header line as specified in [RFC4180] 1605 With the header names as follows: 1607 roid,result-code 1609 o One or more lines with: , 1611 Where: 1613 + , DN Repository Object IDentifier (DNROID) in the SRS. 1615 + , result code as described in Section 6.3.1.1. 1617 Example for LORDN Log file 1619 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1620 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1621 accepted,no-warnings,1 1622 roid,result-code 1623 SH8013-REP,2000 1625 Figure 13 1627 6.3.1.1. LORDN Log Result Codes 1629 In Figure 14 the classes of result codes (rc) are listed. Those 1630 classes in square brackets are not used at this time, but may come 1631 into use at some later stage. The first two digits of a result code 1632 denote the result code class, which defines the outcome at the TMDB: 1634 o ok: Success, DN Line accepted by the TMDB. 1636 o warn: a warning is issued, DN Line accepted by the TMDB. 1638 o err: an error is issued, LORDN file rejected by the TMDB. 1640 In case that after processing a DN Line, the error result code is 1641 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the 1642 TMDB. If the LORDN file is rejected, DN Lines that are syntactically 1643 valid will be reported with a 2001 result code. A 2001 result code 1644 means that the DN Line is syntactically valid, however the DN Line 1645 was not processed because the LORDN file was rejected. All DNs 1646 reported in a rejected LORDN file MUST be reported again by the 1647 Registry because none of the DN Lines present in the LORDN file have 1648 been processed by the TMDB. 1650 LORDN Log Result Code Classes 1652 code Class outcome 1653 ---- ----- ------- 1655 20xx Success ok 1657 35xx [ DN Line syntax warning ] warn 1658 36xx DN Line semantic warning warn 1660 45xx DN Line syntax error err 1661 46xx DN Line semantic error err 1663 Figure 14 1665 In the following, the LORDN Log result codes used by the TMDB are 1666 described: 1668 LORDN Log result Codes 1670 rc Short Description 1671 Long Description 1673 ---- ------------------------------------------------------------- 1675 2000 OK 1676 DN Line successfully processed. 1678 2001 OK but not processed 1679 DN Line is syntactically correct but was not processed 1680 because the LORDN file was rejected. 1682 3601 TCN Acceptance Date after Registration Date 1683 TCN Acceptance Date in DN Line is newer than the Registration 1684 Date. 1686 3602 Duplicate DN Line 1687 This DN Line is an exact duplicate of another DN Line in same 1688 file, DN Line ignored. 1690 3603 DNROID Notified Earlier 1691 Same DNROID has been notified earlier, DN Line ignored. 1693 3604 TCN Checksum invalid 1694 Based on the DN effectively allocated, the TCNID and the 1695 expiration date of the linked TCN, the TCN Checksum is 1696 invalid. 1698 3605 TCN Expired 1699 The TCN was already expired at the time of acknowledgement. 1701 3606 Wrong TCNID used 1702 The TCNID used for the registration does not match 1703 the related DN. 1705 3609 Invalid SMD used 1706 The SMD used for registration was not valid at the moment of 1707 registration based on the and 1708 elements. 1709 In case of an asynchronous registration, this refer to the 1710 . 1712 3610 DN reported outside of the time window 1713 The DN was reported outside of the required 26 hours 1714 reporting window. 1716 3611 DN does not match the labels in SMD 1717 The DN does not match the labels included in the SMD. 1719 3612 SMDID does not exist 1720 The SMDID has never existed in the central repository. 1722 3613 SMD was revoked when used 1723 The SMD used for registration was revoked when used. 1724 In case of an asynchronous registration, 1725 the is used when 1726 validating the DN Line. 1728 3614 TCNID does not exist 1729 The TCNID has never existed in the central repository. 1731 4501 Syntax Error in DN Line 1732 Syntax Error in DN Line. 1734 4601 Invalid TLD used 1735 The TLD in the DN Line does not match what is expected for 1736 this LORDN. 1738 4602 Registrar ID Invalid 1739 Registrar ID in DN Line is not a valid ICANN-Accredited 1740 Registrar. 1742 4603 Registration Date in the future 1743 The in the DN Line is in the 1744 future. 1746 4604 Sunrise DN / application reported for TLD in Claims 1747 The was reported in Sunrise LORDN 1748 when the TLD was in Claims. 1749 In case of an asynchronous registration, 1750 the is used when 1751 validating the DN Line. 1753 4605 Claims DN / application reported for TLD in Sunrise 1754 The was reported in Claims LORDN 1755 when the TLD was in Sunrise. 1756 In case of an asynchronous registration, 1757 the is used when 1758 validating the DN Line. 1760 4606 TLD not in Sunrise or Claims 1761 The was reported when the TLD was 1762 not in Sunrise or Claims. 1763 In case of an asynchronous registration, 1764 the is used when 1765 validating the DN Line. 1767 4607 Application Date in the future 1768 The in the DN Line is in the 1769 future. 1771 4608 Application Date is later than Registration Date 1772 The in the DN Line is later 1773 than the . 1775 4609 TCNID wrong syntax 1776 The syntax of the TCNID is invalid. 1778 4610 TCN Acceptance Date is in the future 1779 The is in the future. 1781 Figure 15 1783 6.4. SMD File 1785 This section defines the format of the SMD File. After a successful 1786 registration of a mark, the TMV returns an SMD File to the TMH. The 1787 SMD File can then be used for registration of one or more DNs covered 1788 by the PRM during the Sunrise Period of a TLD. 1790 Two encapsulation boundaries are defined for delimiting the 1791 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1792 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1793 boundaries MUST be used by Registries and Registrars for validation 1794 purposes, i.e. any data outside these boundaries as well as the 1795 boundaries themselves MUST be ignored for validation purposes. 1797 The structure of the SMD File is as follows: 1799 o Marks: 1801 o smdID: 1803 o U-labels: 1806 o notBefore: 1808 o notAfter: 1810 o -----BEGIN ENCODED SMD----- 1812 o 1814 o -----END ENCODED SMD----- 1815 Example for SMD File (shortened at [...]): 1817 Marks: Example One 1818 smdID: 1-2 1819 U-labels: example-one, exampleone 1820 notBefore: 2011-08-16 09:00 1821 notAfter: 2012-08-16 09:00 1822 -----BEGIN ENCODED SMD----- 1823 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1824 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1825 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1826 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 1827 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 1828 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 1829 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 1830 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 1831 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 1832 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 1833 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 1834 [...] 1835 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 1836 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 1837 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 1838 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 1839 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 1840 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 1841 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1842 -----END ENCODED SMD----- 1844 Figure 16 1846 6.5. Trademark Claims Notice 1848 The TMDB MUST provide the TCN to Registrars in XML format as 1849 specified below. 1851 An enclosing element that describes the Trademark 1852 Notice to a given label. 1854 The child elements of the element include: 1856 o A element that contains the unique identifier of the 1857 Trademark Notice. This element contains the the TCNID. 1859 The TCNID is a string concatenation of a TCN Checksum and the 1860 TMDB Notice Identifier. The first 8 characters of the TCNID is 1861 a TCN Checksum. The rest is the TMDB Notice Identifier, which 1862 is a zero-padded natural number in the range of 1863 0000000000000000001 to 9223372036854775807. 1865 Example of a TCNID: 1867 370d0b7c9223372036854775807. 1869 Where: 1871 + TCN Checksum=370d0b7c 1873 + TMDB Notice Identifier=9223372036854775807 1875 The TCN Checksum is a 8 characters long Base16 encoded output 1876 of computing the CRC32 of the string concatenation of: label + 1877 unix_timestamp() + TMDB Notice Identifier 1879 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is 1881 defined as the number of seconds that have elapsed since 1970- 1882 01-01T00:00:00Z not counting leap seconds. For example, the 1883 conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: 1885 unix_time(2010-08-16T09:00:00.0Z)=1281949200 1887 The TMDB uses the and 1888 elements from the TCN along with the TMDB Notice Identifier to 1889 compute the TCN Checksum. 1891 A Registry MUST use the leftmost DNL (A-label in case of IDNs) 1892 of the DN being registered, the expiration datetime of the TCN 1893 (provided by the Registrar) and the TMDB Notice Identifier 1894 extracted from the TCNID (provided by the Registrar) to compute 1895 the TCN Checksum. For example the DN "foo.bar.example" being 1896 effectively allocated, the left most label would be "foo". 1898 Example of computation of the TCN Checksum: 1900 CRC32(example-one12819492009223372036854775807)=370d0b7c 1902 o A element that contains the start of the 1903 validity date and time of the TCN. 1905 o A element that contains the expiration date 1906 and time of the TCN. 1908 o A elements that contain the DNL (A-label in case 1909 of IDNs) form of the label that correspond to the DN covered by a 1910 PRM. 1912 o One or more elements that contain the Trademark 1913 Claim. The element contains the following child 1914 elements: 1916 * A element that contains the mark text 1917 string. 1919 * One or more elements that contains the 1920 information of the holder of the mark. An "entitlement" 1921 attribute is used to identify the entitlement of the holder, 1922 possible values are: owner, assignee or licensee. The child 1923 elements of include: 1925 + An OPTIONAL element that contains the name 1926 of the holder. A MUST be specified if 1927 is not specified. 1929 + An OPTIONAL element that contains the name of 1930 the organization holder of the mark. A MUST 1931 be specified if is not specified. 1933 + A element that contains the address 1934 information of the holder of a mark. A 1935 contains the following child elements: 1937 - One, two or three OPTIONAL elements 1938 that contains the organization's street address. 1940 - A element that contains the 1941 organization's city. 1943 - An OPTIONAL element that contains the 1944 organization's state or province. 1946 - An OPTIONAL element that contains the 1947 organization's postal code. 1949 - A element that contains the organization's 1950 country code. This a two-character code from 1951 [ISO3166-2]. 1953 + An OPTIONAL element that contains the 1954 organization's voice telephone number. 1956 + An OPTIONAL element that contains the 1957 organization's facsimile telephone number. 1959 + An OPTIONAL element that contains the email 1960 address of the holder. 1962 * Zero or more OPTIONAL elements that contains 1963 the information of the representative of the mark registration. 1964 A "type" attribute is used to identify the type of contact, 1965 possible values are: owner, agent or thirdparty. The child 1966 elements of include: 1968 + A element that contains name of the 1969 responsible person. 1971 + An OPTIONAL element that contains the name of 1972 the organization of the contact. 1974 + A element that contains the address 1975 information of the contact. A contains the 1976 following child elements: 1978 - One, two or three OPTIONAL elements 1979 that contains the contact's street address. 1981 - A element that contains the contact's 1982 city. 1984 - An OPTIONAL element that contains the 1985 contact's state or province. 1987 - An OPTIONAL element that contains the 1988 contact's postal code. 1990 - A element that contains the contact's 1991 country code. This a two-character code from 1992 [ISO3166-2]. 1994 + A element that contains the contact's voice 1995 telephone number. 1997 + An OPTIONAL element that contains the 1998 contact's facsimile telephone number. 2000 + A element that contains the contact's email 2001 address. 2003 * A element that contains the name (in 2004 English) of the jurisdiction where the mark is protected. A 2005 jurCC attribute contains the two-character code of the 2006 jurisdiction where the mark was registered. This is a two- 2007 character code from [WIPO.ST3]. 2009 * Zero or more OPTIONAL element that 2010 contains the description (in English) of the Nice 2011 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 2012 attribute contains the class number. 2014 * A element that contains the full 2015 description of the goods and services mentioned in the mark 2016 registration document. 2018 * An OPTIONAL element signals that the 2019 claim notice was added to the TCN based on other rule than 2020 exact match as defined in [ICANN-GTLD-AGB-20120604]. The 2021 contains one or more: 2023 + An OPTIONAL element that signals that the 2024 claim notice was added because of a previously abused name 2025 included in an UDRP case. The contains: 2027 - A element that contains the UDRP case 2028 number used to validate the previously abused name. 2030 - A element that contains the name 2031 of the UDRP provider. 2033 + An OPTIONAL element that signals that the 2034 claim notice was added because of a previously abused name 2035 included in an court's resolution. The 2036 contains: 2038 - A element that contains the reference 2039 number of the court's resolution used to validate the 2040 previously abused name. 2042 - A element that contains the two-character 2043 code from [ISO3166-2] of the jurisdiction of the court. 2045 - A element that contains the name of 2046 the court. 2048 Example of object: 2050 2051 2052 370d0b7c9223372036854775807 2053 2010-08-14T09:00:00.0Z 2054 2010-08-16T09:00:00.0Z 2055 example-one 2056 2057 Example One 2058 2059 Example Inc. 2060 2061 123 Example Dr. 2062 Suite 100 2063 Reston 2064 VA 2065 20190 2066 US 2067 2068 2069 2070 Joe Doe 2071 Example Inc. 2072 2073 123 Example Dr. 2074 Suite 100 2075 Reston 2076 VA 2077 20190 2078 US 2079 2080 +1.7035555555 2081 jdoe@example.com 2082 2083 UNITED STATES OF AMERICA 2084 2085 Advertising; business management; business administration. 2086 2087 2088 Insurance; financial affairs; monetary affairs; real estate. 2089 2090 2091 Bardus populorum circumdabit se cum captiosus populum. 2092 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2093 2094 2095 2096 Example-One 2097 2098 Example S.A. de C.V. 2099 2100 Calle conocida #343 2101 Conocida 2102 SP 2103 82140 2104 BR 2105 2106 2107 BRAZIL 2108 2109 Bardus populorum circumdabit se cum captiosus populum. 2110 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2111 2112 2113 2114 One 2115 2116 One Corporation 2117 2118 Otra calle 2119 Otra ciudad 2120 OT 2121 383742 2122 CR 2123 2124 2125 COSTA RICA 2126 2127 Bardus populorum circumdabit se cum captiosus populum. 2128 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2129 2130 2131 2132 234235 2133 CR 2134 Supreme Court of Justice of Costa Rica 2135 2136 2137 2138 2139 One Inc 2140 2141 One SA de CV 2142 2143 La calle 2144 La ciudad 2145 CD 2146 34323 2147 AR 2148 2149 2150 ARGENTINA 2151 2152 Bardus populorum circumdabit se cum captiosus populum. 2153 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 2154 2155 2156 2157 D2003-0499 2158 WIPO 2159 2160 2161 2162 2164 For formal syntax of the TCN please refer to Section 7.1. 2166 7. Formal Syntax 2168 7.1. Trademark Claims Notice 2170 The schema presented here is for a Trademark Claims Notice. 2172 Copyright (c) 2012 IETF Trust and the persons identified as authors 2173 of the code. All rights reserved. 2175 Redistribution and use in source and binary forms, with or without 2176 modification, are permitted provided that the following conditions 2177 are met: 2179 o Redistributions of source code must retain the above copyright 2180 notice, this list of conditions and the following disclaimer. 2182 o Redistributions in binary form must reproduce the above copyright 2183 notice, this list of conditions and the following disclaimer in 2184 the documentation and/or other materials provided with the 2185 distribution. 2187 o Neither the name of Internet Society, IETF or IETF Trust, nor the 2188 names of specific contributors, may be used to endorse or promote 2189 products derived from this software without specific prior written 2190 permission. 2192 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 2193 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 2194 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 2195 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 2196 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 2197 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 2198 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2199 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 2200 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 2201 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 2202 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 2204 BEGIN 2205 2206 2211 2212 2213 Schema for representing a Trademark Notice. 2214 2215 2216 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2238 2239 2240 2241 2242 2243 2245 2247 2248 2250 2251 2253 2254 2255 2256 2257 2258 2259 2260 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2311 2312 2313 2314 2315 2316 2317 2318 END 2320 8. Acknowledgements 2322 This specification is a collaborative effort from several 2323 participants in the ICANN community. Bernie Hoeneisen participated 2324 as co-author until version 02 providing invaluable support for this 2325 document. This specification is based on a model spearheaded by: 2326 Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author 2327 would also like to thank the thoughful feedbak provided by many in 2328 the tmch-tech mailing list, but particularly the extensive help 2329 provided by James Gould, James Mitchell and Francisco Arias. 2331 9. Change History 2333 [[RFC Editor: Please remove this section.]] 2335 9.1. Changes from draft-lozano-tmch-func-spec-06 to 2336 draft-lozano-tmch-func-spec-07 2338 1. Added result codes: 3611, 3612, 3613, 3614, 4607, 4608, 4609 and 2339 4610. 2341 2. Added mechanism to retrieve the LORDN Transaction Identifier 2342 based on a previously sent element. 2344 10. IANA Considerations 2346 This document uses URNs to describe XML namespaces and XML schemas 2347 conforming to a registry mechanism described in [RFC3688]. One URI 2348 assigment have been registered by the IANA. 2350 Registration request for the Trademark Claims Notice: 2352 URI: urn:ietf:params:xml:ns:tmNotice-1.0 2353 Registrant Contact: See the "Author's Address" section of this 2354 document. 2356 XML: None. Namespace URIs do not represent an XML specification. 2358 11. Security Considerations 2360 TBD 2362 12. References 2364 12.1. Normative References 2366 [I-D.lozano-tmch-smd] 2367 Lozano, G., "Mark and Signed Mark Objects Mapping", 2368 draft-lozano-tmch-smd-02 (work in progress), March 2013. 2370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2371 Requirement Levels", BCP 14, RFC 2119, March 1997. 2373 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2374 January 2004. 2376 12.2. Informative References 2378 [ICANN-GTLD-AGB-20120604] 2379 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2380 June 2012, . 2383 [ISO3166-2] 2384 ISO, "International Standard for country codes and codes 2385 for their subdivisions", 2006. 2387 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2388 STD 13, RFC 1034, November 1987. 2390 [RFC1035] Mockapetris, P., "Domain names - implementation and 2391 specification", STD 13, RFC 1035, November 1987. 2393 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 2394 RFC 1591, March 1994. 2396 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2397 E. Lear, "Address Allocation for Private Internets", 2398 BCP 5, RFC 1918, February 1996. 2400 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2401 Randers-Pehrson, "GZIP file format specification version 2402 4.3", RFC 1952, May 1996. 2404 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2405 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2406 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2408 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2410 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2411 Internet: Timestamps", RFC 3339, July 2002. 2413 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2414 Separated Values (CSV) Files", RFC 4180, October 2005. 2416 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2417 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2419 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2420 Encodings", RFC 4648, October 2006. 2422 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2423 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2425 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2426 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2428 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2429 Housley, R., and W. Polk, "Internet X.509 Public Key 2430 Infrastructure Certificate and Certificate Revocation List 2431 (CRL) Profile", RFC 5280, May 2008. 2433 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2434 STD 69, RFC 5730, August 2009. 2436 [RFC5890] Klensin, J., "Internationalized Domain Names for 2437 Applications (IDNA): Definitions and Document Framework", 2438 RFC 5890, August 2010. 2440 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2441 Infrastructure Certificate and Certificate Revocation List 2442 (CRL) Profile", RFC 6818, January 2013. 2444 [WIPO-NICE-CLASSES] 2445 WIPO, "Nice List of Classes", . 2448 [WIPO.ST3] 2449 WIPO, "Recommended standard on two-letter codes for the 2450 representation of states, other entities and 2451 intergovernmental organizations", March 2007. 2453 Appendix A. Document Changelog 2455 [RFC Editor: This section is to be removed before publication] 2457 Author's Address 2459 Gustavo Lozano 2460 ICANN 2461 12025 Waterfront Drive, Suite 300 2462 Los Angeles 90292 2463 US 2465 Phone: +1.3103015800 2466 Email: gustavo.lozano@icann.org