idnits 2.17.1 draft-lozano-tmch-func-spec-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2013) is 4056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-lozano-tmch-smd-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano, Ed. 3 Internet-Draft ICANN 4 Intended status: Standards Track B. Hoeneisen 5 Expires: September 13, 2013 Ucom.ch 6 March 12, 2013 8 TMCH functional specifications 9 draft-lozano-tmch-func-spec-00 11 Abstract 13 This document describes the requirements, the architecture and the 14 interfaces between the Trademark Clearing House (TMCH) and Domain 15 Name Registries as well as between TMCH and Domain Name Registrars 16 for the provisioning and management of domain names during Sunrise 17 and Trademark Claims Period of a domain name Registry. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9 60 5.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 61 5.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6. Process Decriptions . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1.1. Registries . . . . . . . . . . . . . . . . . . . . . . 13 80 6.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 81 6.1.1.2. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 82 6.1.1.3. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 14 83 6.1.2. Registrars . . . . . . . . . . . . . . . . . . . . . . 14 84 6.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 14 85 6.1.2.2. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 86 6.1.2.3. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 14 87 6.1.2.4. IP Addresses for Access Control . . . . . . . . . 15 88 6.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 16 89 6.2.1. Domain Registration . . . . . . . . . . . . . . . . . 16 90 6.2.2. DN Registration by Registries . . . . . . . . . . . . 17 91 6.2.3. TMCH Sunrise Services for Registries . . . . . . . . . 18 92 6.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18 93 6.2.3.2. Certificate Revocation List . . . . . . . . . . . 18 94 6.2.3.3. Notice of Registered Domain Names . . . . . . . . 19 95 6.2.4. DN registration by Registrars . . . . . . . . . . . . 21 96 6.2.5. TMCH Sunrise Services for Registrars . . . . . . . . . 21 97 6.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 21 98 6.3.1. Domain Registration . . . . . . . . . . . . . . . . . 21 99 6.3.2. DN registration by Registries . . . . . . . . . . . . 23 100 6.3.3. Trademark Claims Services for Registries . . . . . . . 24 101 6.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 24 102 6.3.3.2. Notice of Registered Domain Names . . . . . . . . 24 103 6.3.4. DN Registration by Registrars . . . . . . . . . . . . 24 104 6.3.5. Tradermark Claims Services for Registrars . . . . . . 26 105 6.3.5.1. Claims Notice Information Service . . . . . . . . 26 106 7. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 26 107 7.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 26 108 7.2. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 27 109 7.2.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 28 110 7.2.2. LORDN Error Codes . . . . . . . . . . . . . . . . . . 29 111 7.3. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 7.4. SMD revocation list . . . . . . . . . . . . . . . . . . . 30 113 7.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 31 114 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 32 115 8.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 33 116 9. Status of this Draft . . . . . . . . . . . . . . . . . . . . . 36 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 118 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 119 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 121 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 122 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 123 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 37 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 126 1. Introduction 128 Domain Name Registries may operate in special modes within certain 129 periods of time to facilitate allocation of domain names. 131 Along with the upcoming introduction of new global Top Level Domains 132 (gTLD), two special modes will come into effect: 134 o Sunrise Period 136 o Trademark Claims Period 138 The Sunrise and Trademark Claims Periods are defined in the gTLD 139 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 141 This document describes the requirements, the architecture and the 142 interfaces between the Trademark Clearing House (TMCH) and Domain 143 Name Registries as well as between TMCH and Domain Name Registrars 144 for the provisioning and management of domain names during the 145 Sunrise and Trademark Claims Periods. 147 After the Terminology (Section 2) and Glossary (Section 3) the 148 Requirements (Section 4) are listed, followed by the architecture 149 (Section 5) and the different process descriptions (Section 6). 150 Afterwards, in Section 7, the necessary Data Formats are defined, 151 followed by their formal syntax (Section 8). 153 1.1. Discussion 155 Any interested parties are invited to contribute to the discussion of 156 this draft and provide feedback. The discussion currently takes 157 place on the tmch-tech discussion list . 158 Interested parties can subscribe to this mailing list via 159 < https://mm.icann.org/mailman/listinfo/tmch-tech >. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 XML is case sensitive. Unless stated otherwise, XML specifications 168 and examples provided in this document MUST be interpreted in the 169 character case presented in order to develop a conforming 170 implementation. 172 "tmNotice-1.0" is used as an abbreviation for 173 "urn:ietf:params:xml:ns:tm-notice-1.0". The XML namespace prefix 174 "tmNotice" is used, but implementations MUST NOT depend on it and 175 instead employ a proper namespace-aware XML parser and serializer to 176 interpret and output the XML documents. 178 3. Glossary 180 In the following the most common terms are briefly Explained: 182 o Allocated DN: A DN is considered Allocated when the DN object for 183 the DN has been created in the SRS of the Registry. A DN object 184 in status "pendingCreate" or any other status that precedes the 185 first time a DN is in "ok" status is not considered Allocated. 186 Also a DN object created internally by the Registry for subsequent 187 delegation to another Registrant is not considered Allocated; see 188 also [ICANN-GTLD-AGB-20120604]. 190 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 192 o CSV: Comma-Separated Values, see [RFC4180] 194 o CNIS, Claims Notice Information Service: This service provides 195 trademark claims notices to Registrars. 197 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 199 o DN: Domain Name, see [RFC1034] 201 o DNS: Domain Name System, see [RFC1034] 203 o DNL, Domain Name Label: An ASCII string used in the DNS (an FQDN 204 is composed by such labels separated by dots) as defined in 205 [RFC1034]. For IDNs the A-Label is used [RFC5891]. 207 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 209 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 211 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 213 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818] 215 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 216 SMD PKI model. 218 o IDN: Internationalized Domain Names, see [RFC5891] 219 o LORDN, List of Registered Domain Names: This is the list of 220 registered domain names matching a DNL of a PRM that Registries 221 daily upload to the TMDB (during the NORDN process). 223 o Lookup Key: A random string of 32 chars from the set [a-zA-Z0-9/] 224 to be used as the lookup Key by Registrars to obtain the claims 225 notice using the CNIS. Lookup Keys are unique and are related to 226 one DNL only. 228 o NORDN, Notification of Registered Domain Names: The process where 229 Registries daily upload the recent LORDN to the TMCH. 231 o PGP: Pretty Good Privacy, see [RFC4880] 233 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 235 o PRM, Pre-registered mark: Mark that has been pre-registered with 236 the TMCH. 238 o Registrant: Person or Organization registering a Domain Name via a 239 Registrar. 241 o Registrar, Domain Name Registrar: Registers Domain Names with the 242 Registry on behalf of the Registrant. 244 o Registry, Domain Name Registry: Entity that accepts Domain Name 245 registrations from Registrars, maintains the central Database of 246 Registered Domains. 248 o SFTP: Secure File Transfer Protocol 250 o SMD, Signed Mark Data: A cryptographically signed token issued by 251 the TMV to the TMH to be used in the Sunrise Period to apply for a 252 Domain Name that matches a DNL of a PRM; see also 253 [I-D.lozano-tmch-smd] 255 o SMD File: A file containing the SMD (see above) and some human 256 readable data. The latter is usually ignored in the processing of 257 the SMD File. See also Section 7.3. 259 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 260 lists of revoked SMDs; see also [I-D.lozano-tmch-smd] 262 o SMD revocation list: The SMD revocation list is used by Registries 263 (and optionally by Registrars) during the Sunrise Period to ensure 264 that an SMD is still valid (i.e. not revoked). The SMD revocation 265 list has a similar function as CRLs used in PKI. 267 o SRS: Shared Registration System, see also 268 [ICANN-GTLD-AGB-20120604]. 270 o Sunrise Period: During this period Domain Names matching a DNL of 271 a PRM can be exclusively obtained by the respective mark holders. 272 For domain names matching PRM, a special process applies to ensure 273 a TMH gets informed on the registration of a domain name matching 274 his PRM. Every launch of a new gTLD Registry starts with a 275 Sunrise Period, followed by a Trademark Claims Period (see below). 277 o TLD: Top Level Domain Name, see [RFC1591] 279 o Trademark, mark: Trademarks are used to claim exclusive properties 280 of products or services. A trademark is typically a name, word, 281 phrase, logo, symbol, design, image, or a combination of these 282 elements. For the scope of this document only textual trademarks 283 are relevant. 285 o Trademark Claims, Claims: Trademark Claims should enhance 286 understanding of the Trademark rights being claimed by the 287 Trademark Holder. 289 o Trademark Claims Notice, Claims Notice: A Trademark Claims Notice 290 consist of Trademark Claims (see above) provided in real time to 291 prospective Registrants of Domain Names. 293 o Trademark Claims Notice Identifier, Claims Notice Identifier, 294 Claims Notice ID: Part of the Trademark Claims Notice (see above), 295 identifying said Claims Notice. During Trademark Claims period it 296 is used to confirm to the Registry that the Claims Notice has been 297 fetched from the TMCH and the Registrant has agreed to the Claims 298 Notice. 300 o Trademark Claims Period: During this period, a special process 301 applies to DNs matching DNL of a PRM, to ensure a TMH gets 302 informed on the registration of a domain name matching his PRM. 303 For DNs matching DNL of a PRM, Registrars show a Trademark Claims 304 Notice to prospective Registrants to be acknowledged. 306 o TMCH, Trademark Clearing House: The Trademark Clearinghouse is an 307 ICANN central repository for information to be authenticated, 308 stored, and disseminated, pertaining to the rights of trademark 309 holders. The Clearinghouse is split into two functions TMV and 310 TMDB (see below). There are several entities carrying out the TMV 311 function, but only one single entity performing the TMDB function. 313 o TMDB, Trademark Clearinghouse Database: Serves as a database of 314 the TMCH to provide information to the new gTLD Registries and 315 Registrars to support Sunrise or Trademark Claims Services. There 316 is only one TMDB in the TMCH Global System that concentrates the 317 information about the "verified" Trademark records from the 318 different TMVs. 320 o TMH, Trademark Holder: The person or organization owning rights on 321 a Trademark. 323 o TMV, Trademark Validator, Trademark validation organization: An 324 entity authorized by ICANN to authenticate and validate 325 registrations ensuring the marks qualify as registered or are 326 court-validated marks or marks that are protected by statute or 327 treaty. This entity would also be asked to ensure that proof of 328 use of marks is provided, which can be demonstrated by furnishing 329 a signed declaration and one specimen of current use. 331 o UTC: Coordinated Universal Time, as maintained by the Bureau 332 International des Poids et Mesures (BIPM); see also [RFC3339]. 334 4. Requirements 336 TBD 338 5. Architecture 340 5.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 5.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 5.3. Interfaces 409 In the following sub-sections a short description of each interface 410 to provide an overview of the architecture. More detailed 411 descriptions of the relevant interfaces follow further below 412 (Section 6). 414 5.3.1. hv 416 Via the hv interface the TMH registers a mark with a TMV. 418 After the successful registration of the mark, the TMV makes 419 available a SMD (Signed Mark Data) file (see also Section 7.3) to the 420 TMH to be used during Sunrise Period. 422 The specifics of the hv interface are beyond the scope of this 423 document. 425 5.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 5.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 SFTP. 442 5.3.4. tr 444 Via the tr interface the Registrant communicates with the Registrar. 445 Every Registrar is free to use its own protocol. 447 The specifics of the tr interface are beyond the scope of this 448 document. 450 5.3.5. ry 452 Via the ry interface the Registrar communicate with the Registry. 453 The ry interfaces is typically implemented in EPP [RFC5730]. TMCH 454 specific EPP extensions are to be developed by the community, mainly 455 by Registries and Registrars. 457 5.3.6. dr 459 Not used during the Sunrise Period. 461 During the Trademark Claims Period the Registrar fetches the 462 Trademark Claims Notice from the TMDB (to be displayed to the 463 Registrant via the tr interface) via the dr interface. The protocol 464 used for fetching the Trademark Claims Notice is HTTPS [RFC2818]. 466 5.3.7. yd 468 During the Sunrise period the Registry notifies the TMDB daily via 469 the yd interface of all domain names registered. (Note: Only domain 470 names matching a DNL of a PRM can be registered during the Sunrise 471 Period.) 472 During the Trademark Claims period, the Registry notifies daily the 473 TMDB via the yd interface of all domains registered that included a 474 Claims Notice Identifier during the creation of the domain name. 476 The protocol used on the yd interface is SFTP. 478 5.3.8. dv 480 Via the dv interface the TMDB notifies the TMV of all domains 481 registered as informed by Registries. 483 The specifics of the dv interface are beyond the scope of this 484 document. 486 5.3.9. vh 488 Via the vh interface the TMV notifies the TMH after a domains has 489 been registered that matches a PRM of this TMH. 491 The specifics of the vh interface are beyond the scope of this 492 document. 494 5.3.10. vs 496 Via the vs interface the TMV requests to add a revoked SMD to the 497 list of revoked SMDs at the SMDM. 499 The specifics of the vs interface are beyond the scope of this 500 document. 502 Not relevant during the Trademark Claims Period. 504 5.3.11. sy 506 During the Sunrise Period the Registry fetches the most recent list 507 of revoked SMDs from the SMDM via the sy interface in regular 508 intervals. The protocol used on the sy interface is SFTP. 510 Not relevant during the Trademark Claims Period. 512 5.3.12. sr 514 During the Sunrise Period the Registrar may fetch the most recent 515 list of revoked SMDs from the SMDM via the sr interface. The 516 protocol used on the sr interface is the same as on the sy interface 517 (s. above), i.e. SFTP. 519 Not relevant during the Trademark Claims Period. 521 5.3.13. vc 523 Via the vc interface the TMV requests to add a revoked TMV 524 certificate to the CRL at the ICANN-CA. 526 The specifics of the vc interface are beyond the scope of this 527 document. 529 Not relevant during the Trademark Claims Period. 531 5.3.14. cy 533 During the Sunrise Period the Registry fetches the most recent CRL 534 from the ICANN-CA via the cy interface in regular intervals. The CRL 535 is mainly used for validation of TMV certificates. The protocol used 536 on the cy interface is HTTPS [RFC2818]. 538 Not relevant during the Trademark Claims Period. 540 5.3.15. cr 542 During the Sunrise Period the Registrar may fetch the most recent CRL 543 from the ICANN-CA via the cr interface. The protocol used on the cr 544 interface is the same as on the cy interface (s. above). 546 Not relevant during the Trademark Claims Period. 548 6. Process Decriptions 550 6.1. Bootstrap 552 6.1.1. Registries 554 6.1.1.1. Credentials 556 All Registries receive credentials to be used: 558 o during the Sunrise Period to fetch the lists of revoked SMDs from 559 the SMDM via the sy interface (Section 5.3.11). 561 o during Trademark Claims Period to fetch the lists of DNL from the 562 TMDB via the dy interface (Section 5.3.3). 564 o during the NORDN process to notify the LORDN to the TMDB via the 565 yd interface (Section 5.3.7). 567 6.1.1.2. TMCH Trust Anchor 569 All Registries fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 570 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 571 be used: 573 o during the Sunrise Period to validate the TMV's certificates and 574 the CRL of TMV certificates. 576 6.1.1.3. TMDB/SMDM PGP Key 578 All Registries receive the public portion of the PGP Key used by TMDB 579 and SMDM, from the TMDB administrator to be used: 581 o during the Sunrise Period to perform integrity checking of the 582 list of revoked SMDs fetched from the SMDM via the sy interface 583 (Section 5.3.11). 585 o during Trademark Claims Period to perform integrity checking of 586 the list of DNL fetched from the TMDB via the dy interface 587 (Section 5.3.3). 589 6.1.2. Registrars 591 6.1.2.1. Credentials 593 All Registrars receive credentials to be used: 595 o during the Sunrise Period to (optionally) fetch the lists of 596 revoked SMDs from the SMDM via the sr interface (Section 5.3.12). 598 o during Trademark Claims Period to fetch Claims Notices from the 599 TMDB via the dr interface (Section 5.3.6). 601 6.1.2.2. TMCH Trust Anchor 603 Registrars may fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 604 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 605 be used: 607 o during the Sunrise Period to (optionally) validate the TMV's 608 certificates and the CRL of TMV certificates. 610 6.1.2.3. TMDB PGP Key 612 Registrars receive the public portion of the PGP Key used by TMDB and 613 SMDM from the TMDB administrator to be used: 615 o during the Sunrise Period to (optionally) perform integrity 616 checking of the list of revoked SMDs fetched from the SMDM via the 617 sr interface (Section 5.3.12). 619 6.1.2.4. IP Addresses for Access Control 621 The Registrars need to provide to the TMDB administrator all IP 622 addresses, which are used by their hosts to fetch Trademark Claims 623 Notices via the dr interface (Section 5.3.6). The TMDB restricts 624 access to known IP Addresses only. This access restriction is 625 applied in addition to HTTP Basic access authentication (for 626 credentials to be used, see Section 6.1.2.1). 628 6.2. Sunrise Period 630 6.2.1. Domain Registration 632 Registration during Sunrise Period 634 .------------. .-----------. .----------. 635 | Registrant | | Registrar | | Registry | 636 '------------' '-----------' '----------' 637 | | | 638 | Request DN | | 639 | Registration | | 640 | (with SMD) | | 641 |------------->| Check DN availability | 642 | |---------------------------->| 643 | | | 644 | |.-------. DN unavail. .-------------. 645 | || ABORT |<-----------( DN available? ) 646 | |'-------' no '-------------' 647 | | | yes 648 | | | 649 | | .-------------------------------. 650 | | | Validate SMD and | 651 | | | corresponding TMV certificate | 652 | | '-------------------------------' 653 | | | 654 | | | 655 | |.-------. Error .----------------------. 656 | || TRY |<------( Validation successful? ) 657 | || AGAIN | no '----------------------' 658 | || OR | | yes 659 | || ABORT | | 660 | |'-------' .-----------------. 661 | | | Add DN to LORDN | 662 | | '-----------------' 663 | | | 664 | | DN registered | 665 | DN regist. |<----------------------------| 666 |<-------------| | 667 | | | 668 | | | 670 Figure 3 672 6.2.2. DN Registration by Registries 674 Registries MUST perform a minimum set of checks for verifying DN 675 registrations during Sunrise Period upon reception of a registration 676 request over the ry interface (Section 5.3.5). If any of these 677 checks fails the Registry MUST abort the DN registration. Each of 678 these checks MUST be performed before the DN is Allocated (see 679 Section 3). 681 Performing the minimum set of checks Registries MUST verify that: 683 1. The IP address of the Registrant has been received from the 684 Registrar along with the DN registration. 686 2. The IP address used by the Registrant is a global unicast IP 687 address, in particular it is not a private IP address as defined 688 in [RFC1918]. This check is only required, if the IP address of 689 the Registrant has been provided by the Registrar. 691 3. An SMD has been received from the Registrar along with the DN 692 registration. 694 4. The certificate of the TMV has been correctly signed by the 695 ICANN-CA. (The certificate of the TMV is contained within the 696 SMD.) 698 5. The validity period of the TMV certificate is within the allowed 699 range. 701 6. The Key Usage extension in the TMV certificate is marked as 702 "critical" [RFC5280] 704 7. Only the "digitalSignature" bit (Key Usage) is set and no 705 Extended Key Usage is set in the TMV certificate [RFC5280]. 707 8. The certificate of the TMV is not be listed in the CRL file 708 specified in the CRL distribution point of the TMV certificate. 710 9. The signature of the SMD (signed with the TMV certificate) is 711 valid. 713 10. The validity period of the SMD is within the allowed range 714 ( and elements). 716 11. The SMD has not been revoked, i.e. is not contained in the SMD 717 revocation list. 719 12. The DN being registered matches at least one of the labels 720 () elements in the SMD. 722 For any date or time indications, Coordinated Universal Time (UTC) 723 applies. 725 Note: These procedures apply to all DN registrations at the second 726 level as well as to all other levels subordinate to the TLD that the 727 Registry accepts registrations for. 729 6.2.3. TMCH Sunrise Services for Registries 731 6.2.3.1. SMD Revocation List 733 A new SMD revocation list is published by the SMDM twice a day, 734 namely at 00:00 and 12:00 UTC. 736 Registries MUST download the latest version of the SMD revocation 737 list at least once in 24 hours. 739 Update SMD revocation list 741 .----------. .------. 742 | Registry | | SMDM | 743 '----------' '------' 744 | | 745 .----------------. | 746 | Periodically, | | 747 | at least | | 748 | every 24 hours | | 749 '----------------' | 750 | | 751 |----------------------------------------------------->| 752 | Download latest revocation list for SMD certificates | 753 |<-----------------------------------------------------| 754 | | 755 | | 757 Figure 4 759 6.2.3.2. Certificate Revocation List 761 Registries MUST update their local copy of the CRL at least every 4 762 hours using the CRL distribution point specified in the TMV 763 certificate. 765 Operationally, the CRL file and CRL distribution point is the same 766 for all TMVs and (at publication of this document) located at 767 < https://crl.icann.org/tmch.crl >. 769 Update SMD revocation list 771 .----------. .----------. 772 | Registry | | ICANN-CA | 773 '----------' '----------' 774 | | 775 .---------------. | 776 | Periodically, | | 777 | at least | | 778 | every 4 hours | | 779 '---------------' | 780 | | 781 |------------------------------------------->| 782 | Download latest CRL for TMV certificates | 783 |<-------------------------------------------| 784 | | 785 | | 787 Figure 5 789 6.2.3.3. Notice of Registered Domain Names 791 The Registry MUST send the LORDN file containing all DNs registered 792 on the previous calendar day (UTC), to the TMDB (over the yd 793 interface, Section 5.3.7) between midnight and 3 a.m. UTC. 795 If a new LORDN file (containing the registered DNs for the same date) 796 is uploaded before 3 a.m. UTC, the previous LORDN file is discarded 797 and the new LORDN file is processed instead. At 3 a.m. UTC, the 798 last uploaded LORDN file is considered final, given no ERRORs (i.e. 799 only OKs and warnings) occur during the processing of the file at the 800 TMDB. If a LORDN file is considered final, it is stored in the TMDB, 801 and information is sent to the TMVs for informing the TMHs. Any 802 LORDN file (for the same date) that is uploaded later than 3 a.m. 803 will be ignored. 805 For any date or time indications, Coordinated Universal Time (UTC) 806 applies. 808 NORDN 810 .----------. .------. .-----. .-----. 811 | Registry | | TMDB | | TMV | | TMH | 812 '----------' '------' '-----' '-----' 813 | | | | 814 .------------------. .-----------. | | 815 | Periodically, | | Wait for |<-------. | | 816 | every 24 hours | | LORDN | | | | 817 | (between 0 and 3 | '-----------' | | | 818 | o'clock UTC) | | | | | 819 '------------------' | | | | 820 | | | | | 821 .--------->| Upload LORDN | | | | 822 | |-------------------->| | | | 823 | | | | | | 824 | | .-------------------------. | | | 825 | | | Verify each domain name | | | | 826 | | | in the uploaded file | | | | 827 | | | and write results to a | | | | 828 | | | .err-file (within 30') | | | | 829 | | '-------------------------' | | | 830 | | | | | | 831 | | Download .err file | | | | 832 | |<--------------------| | | | 833 | | | | | | 834 | .-----------------. .---------------. | | | 835 | | Check whether | / everything fine \ no | | | 836 | | .err-file | ( (i.e. no errors )----' | | 837 | | contains errors | \ in .err-file)? / | | 838 | '-----------------' '---------------' | | 839 | | | yes | | 840 | .---------------. | | | 841 | / everything fine \ yes | | | 842 |( (i.e. no errors )-----. | Notify TMVs | | 843 | \ in .err-file)? / | | on the LORDN | | 844 | '---------------' | | pre-registered | | 845 | | no v | with said TMV | | 846 | .----------------. .------. |--------------->| | 847 '-| Correct Errors | | DONE | | | | 848 '----------------' '------' | | Notify each | 849 | | | affected TMH | 850 | | |------------->| 851 | | | | 852 | | | | 854 Figure 6 856 The format used for the LORDN is described in Section 7.2 858 6.2.4. DN registration by Registrars 860 Registrars MAY choose to perform the checks for verifying DN 861 registrations as performed by the Registries (see Section 6.2.2) 862 before sending the application to register a DN. 864 Registrars MUST forward the SMD received from the Registrant along 865 with the IP address seen on tr interface (Section 5.3.4); i.e. the IP 866 address used by the customer who submitted the application for 867 registration of the DN. 869 6.2.5. TMCH Sunrise Services for Registrars 871 The processes described in Section 6.2.3.1 and Section 6.2.3.2 are 872 also available for Registrars to optionally validate the SMDs 873 received. 875 6.3. Trademark Claims Period 877 6.3.1. Domain Registration 878 Registration during Trademark Claims Period 880 .------------. .-----------. .----------. .------. 881 | Registrant | | Registrar | | Registry | | TMCH | 882 '------------' '-----------' '----------' '------' 883 | | | | 884 | Request DN | | | 885 | Registration | Check DN availability | | 886 |------------->|---------------------------->| | 887 | | | | 888 | |.-------. DN unavail. .-------------. | 889 | || ABORT |<-----------( DN available? ) | 890 | |'-------' no '-------------' | 891 | | | yes | 892 | | DN available & .---------. | 893 | |.----------. no claim / Does DN \ | 894 | || CONTINUE |<---------( match DNL ) | 895 | || NORMALLY | no \ of PRM? / | 896 | |'----------' '---------' | 897 | | | yes | 898 | | DN avail./claims exists | | 899 | | (Lookup Key included) | | 900 | |<----------------------------| | 901 | | | | 902 | | Request Claims Notice | 903 | Display |----------------------------------------->| 904 | Claims | | 905 | Notice | Return Claims Notice | 906 |<-------------|<-----------------------------------------| 907 | | | 908 | | Register DN | 909 .------. yes | (Claims Notice ID included) | | 910 ( Agree? )--------->|---------------------------->| | 911 '------' | | | 912 ||no |.-------. Error .----------------------. | 913 || .-------. || TRY |<-----( Validation successful? ) | 914 |'->| ABORT | || AGAIN | no '----------------------' | 915 | '-------' || OR | | yes | 916 | || ABORT | .-----------------. | 917 | |'-------' | Add DN to LORDN | | 918 | | '-----------------' | 919 | DN regist. | DN registered | | 920 |<-------------|<----------------------------| | 921 | | | | 922 | | | | 924 Figure 7 926 6.3.2. DN registration by Registries 928 During Trademark Claim Periods, Registries perform two main 929 functions: 931 o Whenever a Registrar queries the domain availability that matches 932 a DNL of a PRM (over the ry interface, Section 5.3.5) for 933 availability, the Registry MUST return the corresponding Lookup 934 Key. 936 o For any DN matching a DNL of a PRM, Registries MUST perform a 937 minimum set of checks for verifying DN registrations during 938 Trademark Claims Period upon reception of a registration request 939 over the ry interface (Section 5.3.5). If any of these checks 940 fails the Registry MUST abort the DN registration. Each of these 941 checks MUST be performed before the DN is Allocated (see 942 Section 3). Performing the minimum set of checks Registries MUST 943 verify that: 945 1. The Claims Notice Identifier, expiration date of the Trademark 946 Claim notice and the IP address of the Registrant have been 947 received from the Registrar along with the DN registration. 948 If the expiration date, Claims Notice Identifier and IP 949 address of the Registrant is not provided during registration 950 and the DNL was inserted (or re-inserted) into the list of DNL 951 less than 24 hours ago, the registration MAY continue without 952 this data. (Note that such DN registrations MUST also be 953 included to the LORDN.) 955 2. The claim notice has not expired (using the expiration date 956 (). This check is REQUIRED only if the 957 expiration date has been provided by the Registrar. 959 3. The IP address used by the Registrant is a global unicast IP 960 address, in particular it is not a private IP address as 961 defined in [RFC1918]. This check is only required, if the IP 962 address of the Registrant has been provided by the Registrar. 964 For any date or time indications, Coordinated Universal Time (UTC) 965 applies. 967 Note: These procedures apply to all DN registrations at the second 968 level as well as to all other levels subordinate to the TLD that the 969 Registry accepts registrations for. 971 Note: Even if a Claims Notice Identifier is provided for a DN not 972 present in the DNL list, the Registry MUST include this DN 973 registration in the LORDN file. 975 6.3.3. Trademark Claims Services for Registries 977 6.3.3.1. Domain Name Label (DNL) List 979 A new DNL list is published by the TMDB twice a day, namely at 00:00 980 and 12:00. 982 Registries MUST download the latest version of the DNL list at least 983 once in 24 hours. 985 Update DNL list 987 .----------. .------. 988 | Registry | | TMDB | 989 '----------' '------' 990 | | 991 .----------------. | 992 | Periodically, | | 993 | at least | | 994 | every 24 hours | | 995 '----------------' | 996 | | 997 |-------------------------------->| 998 | Download latest list of DNLs | 999 |<--------------------------------| 1000 | | 1001 | | 1003 Figure 8 1005 6.3.3.2. Notice of Registered Domain Names 1007 The NORDN process during the Trademark Claims Period is almost the 1008 same as during Sunrise Period as defined in Section 6.2.3.3 with the 1009 only difference that just registrations subject to a Trademark Claim 1010 are included in the LORDN. 1012 6.3.4. DN Registration by Registrars 1014 For any DN matching a DNL of a PRM, Registrars MUST perform the 1015 following steps: 1017 1. Use the Lookup Key received from the Registry (while verifying DN 1018 availability) to obtain the Claims Notice from the TMDB using the 1019 dr interface (Section 5.3.6) 1021 2. Present the Claims Notice to the Registrant as described in 1022 [ICANN-GTLD-AGB-20120604]. 1024 3. Ask Registrant for confirmation, i.e. the Registrant MUST consent 1025 with the Claims Notice, before any further processing. (The 1026 transmission of a Trademark Claims Identifier to the Registry 1027 (over the ry interface, Section 5.3.5) implies that the 1028 Registrant has expressed his consent with the Claims Notice.) 1030 4. Record the IP address as seen on tr interface (Section 5.3.4, 1031 i.e. the IP address used by the customer who submitted the 1032 application for registration of the DN) 1034 5. Perform the minimum set of checks for verifying DN registrations. 1035 If any of these checks fails the Registrar MUST abort the DN 1036 registration. Each of these checks MUST be performed before the 1037 registration is sent to the Registry. Performing the minimum set 1038 of checks Registrars MUST verify that: 1040 1. The claim notice has not expired (using expiration date 1041 (). 1043 2. The DN being registered matches the label () 1044 element in the Trademark Claim Notice. 1046 3. The Registrant has acknowledged (expressed his consent with) 1047 the Claims Notice. 1049 6. Send the registration to the Registry (ry interface, 1050 Section 5.3.5) and include the following information: 1052 * recorded IP address as seen on tr interface 1054 * Trademark Claims Identifier () 1056 * Expiration date of the claims notice () 1058 Note: Claims notices are generated twice a day, namely at 00:00 and 1059 12:00 UTC. The expiration date of the claims notice is set to 48 1060 hours in the future, allowing the implementation of a cache within 1061 the Registrar and enough time for the registration workflow process 1062 to finalize. Registrars SHOULD implement a cache of claims notices 1063 to minimize the number of queries sent to the TMDB. The TMDB 1064 implements rate-limiting as one of the protection mechanisms to 1065 mitigate the risk of performance degradation. 1067 6.3.5. Tradermark Claims Services for Registrars 1069 6.3.5.1. Claims Notice Information Service 1071 The Trademark Claims Notices are provided by the TMDB online and are 1072 fetched by the Registrar via the dr interface (Section 5.3.6). To 1073 get access to the Trademark Claims Notices, the Registrar needs the 1074 credentials provided by the TMDB (Section 6.1.2.1) and the Lookup Key 1075 received from the Registry via the ry interface (Section 5.3.5). The 1076 dr interface (Section 5.3.6) uses HTTPS with Basic access 1077 authentication. Furthermore the Registrar has to ensure that all IP 1078 addresses used by his own systems on dr interface have been informed 1079 to the TMDB to be entered into the list known IP Addresses 1080 (Section 6.1.2.4). 1082 The URL of the dr interface (Section 5.3.6) is: 1083 < https:///cnis/.xml.gz > 1085 The TLS certificate (HTTPS) used on the dr interface (Section 5.3.6) 1086 MUST be signed by a well know public CA. 1088 7. Data Format Descriptions 1090 7.1. DNL List file 1092 This section defines format of the list containing every Domain Name 1093 Label (DNL) that matches a Pre-Registered Mark (PRM). The list is 1094 maintained by the TMDB and downloaded by Registries in regular 1095 intervals (see Section 6.3.3.1). The Registries use the DNL list 1096 during the Trademark Claims period to check whether a requested DN 1097 matched a DNL of a PRM. 1099 The DNL list is contained in a CSV file that has the following 1100 structure: 1102 o first line: , 1104 o One or more lines with: ,, 1107 Example for DNL list 1109 1.0,1362965626 1110 example, j8f/KR6/Dex/T4H/dac5KfM3FKhevbYEaevbYddfEr,1362955239 1111 another-example,lj3/l4F/dsd/33F/f434HGgsfeg44HGgsfeg42l5Ts,1362955316 1112 anotherexample, h7h/nm9/FEJ/NJ4/iHHtFJL8f2mkHtFL8f2mkj3d2c,1362956532 1114 Figure 9 1116 To provide authentication and integrity protection, the DNL list is 1117 PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1118 (see also Section 6.1.1.3). The DNL list is provided by the TMDB as 1119 gzip [RFC1952] compressed tarball containing two files: 1121 o CSV 1123 o PGP Signature 1125 7.2. LORDN File 1127 This section defines the format of the List of Registered Domain 1128 Names (LORDN), which is maintained by each Registry and uploaded 1129 daily to the TMDB. Every time a DN matching a DNL of a PRL said DN 1130 is added to the LORDN along with further information related to its 1131 registration. 1133 The LORDN is contained in a CSV file that has the following 1134 structure: 1136 o For Sunrise Period: 1138 * first line: ,, 1141 * One or more lines with: ,,,,, 1144 o For Trademark Claims Period: 1146 * first line: ,, 1149 * One or more lines with: , ,,,, 1153 Example for LORDN 1155 1.0,1362965626,2013-02-27 1156 SH8013-REP,example1.gtld,j8yKR69DevT5KfM3FKhevbjqd680YEr, \ 1157 977,1362965626,128.66.3.73 1158 EK77-REP,example2.gtld,l5Fdssa5G333lj324lF4Fyds2d3v3Ff, \ 1159 6,1362965626,128.66.0.19 1160 HB800-REP,example3.gtld,tbk56h7hgndm96FEvJ64UNJRi66H4Ht, \ 1161 1238,1362965626,2001:DB8::dead:c0:ffee 1163 Figure 10 1165 7.2.1. LORDN Log File 1167 After reception of the LORDN File, the TMDB verifies its content for 1168 syntactical and semantical correctness and writes the results of this 1169 check to a log file (suffix .log). It uses return codes to indicate 1170 success, warning or error. 1172 In case there are warnings or errors, additional files are generated, 1173 i.e.: 1175 o a file with suffix .warn contains only the warnings, if any 1177 o a file with suffix .err contains only the errors, if any 1179 The LORDN log file is contained in a CSV file that has the following 1180 structure: 1182 o first line: ,,, 1185 o One or more lines with: , 1187 Example for LORDN Logfile 1189 1.0,1362965626,1362965624,2013-02-27 1190 SH8013-REP,2202 1191 EK77-REP,1020 1192 HB800-REP,2032 1194 Figure 11 1196 7.2.2. LORDN Error Codes 1198 TBD 1200 7.3. SMD File 1202 This section defines the format of the SMD File. After a successful 1203 registration of a mark, TMV returns an SMD File to the TMH. The SMD 1204 file can then be used for registration of one or more DNs covered by 1205 the PRM during the Sunrise Period. 1207 Two encapsulation boundaries are defined for delimiting the 1208 encapsulated base64 encoded SMD, i.e. "-----BEGIN ENCODED SMD-----" 1209 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1210 boundaries MUST be used by Registries (and Registrars) for validation 1211 purposes, i.e. any data outside these boundaries as well as the 1212 boundaries themselves MUST be ignored for validation purposes. 1214 The structure of the SMD File is as follows: 1216 o Marks: 1218 o smdID: 1220 o U-labels: 1222 o notBefore: 1224 o notAfter: 1226 o -----BEGIN ENCODED SMD----- 1228 o 1230 o -----END ENCODED SMD----- 1231 Example for SMD File (shortened at [...]) 1233 Marks: Example One 1234 smdID: 1-2 1235 U-labels: example-one, exampleone 1236 notBefore: 2011-08-16 09:00 1237 notAfter: 2012-08-16 09:00 1238 -----BEGIN ENCODED SMD----- 1239 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1240 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1241 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1242 [...] 1243 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 1244 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1245 -----END ENCODED SMD----- 1247 Figure 12 1249 7.4. SMD revocation list 1251 This section defines format of the list of SMDs that have been 1252 revoked. The list is maintained by the SMDM and downloaded by 1253 Registries (and optionally by Registrars) in regular intervals (see 1254 Section 6.2.3.1). The SMD revocation list is used during the Sunrise 1255 Period to validate SMDs received. The SMD revocation list has a 1256 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1258 The SMD revocation list is contained in a CSV file that has the 1259 following structure: 1261 o first line: , 1263 o One or more lines with: 1265 Example for SMD Revocation list 1267 1.0,1362965626 1268 cdfghjtedxcvbnjrewsdsbhhjkjkllllt 1269 avixukrjfiknenncl2dd45ggsdt456hyt 1270 jwmchtgenblksalalotlajhhfddfasfee 1272 Figure 13 1274 To provide integrity protection, the SMD revocation list is PGP 1276 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1277 also Section 6.1.1.3). The SMD revocation list provided is provided 1278 by the TMDB as gzip [RFC1952] compressed tarball containing two 1279 files: 1281 o CSV 1283 o PGP Signature 1285 7.5. Trademark Claims Notice 1287 The TMDB provides the Trademark Claim Notice to Registrars as an XML 1288 file compressed using gzip. 1290 Example of object: 1292 1293 AJDJEICMEOWALWJFIWJWJELEL53454345343 1294 2009-08-16T09:00:00.0Z 1295 2010-08-16T09:00:00.0Z 1296 example-one 1297 1298 Example One 1299 1300 Example Inc. 1301 1302 123 Example Dr. 1303 Suite 100 1304 Reston 1305 VA 1306 20190 1307 US 1308 1309 1310 US 1311 Advertising; business management; 1312 business administration; office functions 1313 Insurance; financial affairs; 1314 monetary affairs; real estate affairs 1315 Dirigendas et eiusmodi 1316 featuring infringo in airfare et cartam servicia. 1317 1318 1319 1320 Example One 1321 1322 Example Inc. 1323 1324 123 Example Dr. 1325 Suite 100 1326 Reston 1327 VA 1328 20190 1329 US 1330 1331 1332 1333 US 1334 Puerto Rico 1335 1336 Dirigendas et eiusmodi 1337 featuring infringo in airfare et cartam servicia. 1338 1339 1340 1341 Example One 1342 1343 Example Inc. 1344 1345 123 Example Dr. 1346 Suite 100 1347 Reston 1348 VA 1349 20190 1350 US 1351 1352 1353 Dirigendas et eiusmodi 1354 featuring infringo in airfare et cartam servicia. 1355 1356 US 1357 1358 1360 Note: this example generates a TRADEMARK NOTICE with three mark 1361 claims. 1363 For formal syntax of the Trademark Claims Notice please refer to 1364 Section 8.1. 1366 8. Formal Syntax 1367 8.1. Trademark Claims Notice 1369 The schema presented here is for the Trademark Claims Notice. 1371 Copyright (c) 2012 IETF Trust and the persons identified as authors 1372 of the code. All rights reserved. 1374 Redistribution and use in source and binary forms, with or without 1375 modification, are permitted provided that the following conditions 1376 are met: 1378 o Redistributions of source code must retain the above copyright 1379 notice, this list of conditions and the following disclaimer. 1381 o Redistributions in binary form must reproduce the above copyright 1382 notice, this list of conditions and the following disclaimer in 1383 the documentation and/or other materials provided with the 1384 distribution. 1386 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1387 names of specific contributors, may be used to endorse or promote 1388 products derived from this software without specific prior written 1389 permission. 1391 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1392 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1393 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1394 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1395 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1396 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1397 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1398 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1399 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1400 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1401 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1403 BEGIN 1404 1405 1412 1413 1414 Schema for representing a Trademark Notice. 1415 1416 1418 1421 1423 1424 1425 1426 1427 1428 1429 1431 1432 1433 1434 1435 1436 1437 1439 1442 1444 1445 1447 1448 1449 1450 1452 1453 1455 1456 1457 1459 1460 1461 1462 1464 1466 1467 1468 1470 1471 1472 1473 1475 1476 1477 1478 1480 1481 1482 1483 1484 1485 1486 1488 1489 1490 1491 1492 1493 1494 1495 1496 1498 1499 1500 1501 1502 1503 1504 1505 1506 END 1508 9. Status of this Draft 1510 This (-00) version is intended to provide a first version of the TMCH 1511 functional specifications. This draft is the product of several 1512 discussions regarding the interaction between the TMCH and 1513 Registries/Registrars. It does by no means claim to be complete and 1514 minor updates are likely to be added in future versions of this 1515 document. 1517 10. Acknowledgements 1519 TBD 1521 11. IANA Considerations 1523 TBD 1525 12. Security Considerations 1527 TBD 1529 13. References 1531 13.1. Normative References 1533 [I-D.lozano-tmch-smd] 1534 Lozano, G., "Mark and Signed Mark Objects Mapping", 1535 draft-lozano-tmch-smd-00 (work in progress), March 2013. 1537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1538 Requirement Levels", BCP 14, RFC 2119, March 1997. 1540 13.2. Informative References 1542 [ICANN-GTLD-AGB-20120604] 1543 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 1544 June 2012, . 1547 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1548 STD 13, RFC 1034, November 1987. 1550 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1551 RFC 1591, March 1994. 1553 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1554 E. Lear, "Address Allocation for Private Internets", 1555 BCP 5, RFC 1918, February 1996. 1557 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1558 Randers-Pehrson, "GZIP file format specification version 1559 4.3", RFC 1952, May 1996. 1561 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1562 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1563 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1565 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1567 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1568 Internet: Timestamps", RFC 3339, July 2002. 1570 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 1571 Separated Values (CSV) Files", RFC 4180, October 2005. 1573 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1574 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1576 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1577 Housley, R., and W. Polk, "Internet X.509 Public Key 1578 Infrastructure Certificate and Certificate Revocation List 1579 (CRL) Profile", RFC 5280, May 2008. 1581 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1582 STD 69, RFC 5730, August 2009. 1584 [RFC5891] Klensin, J., "Internationalized Domain Names in 1585 Applications (IDNA): Protocol", RFC 5891, August 2010. 1587 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 1588 Infrastructure Certificate and Certificate Revocation List 1589 (CRL) Profile", RFC 6818, January 2013. 1591 Appendix A. Document Changelog 1593 [RFC Editor: This section is to be removed before publication] 1595 draft-lozano-tmch-functional-spec-00: 1597 o Initial version 1599 Authors' Addresses 1601 Gustavo Lozano (editor) 1602 ICANN 1603 12025 Waterfront Drive, Suite 300 1604 Los Angeles 90292 1605 US 1607 Phone: +1.3103015800 1608 Email: gustavo.lozano@icann.org 1610 Bernie Hoeneisen 1611 Ucom Standards Track Solutions GmbH 1612 CH-8000 Zuerich 1613 Switzerland 1615 Phone: +41 44 500 52 44 1616 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 1617 URI: http://www.ucom.ch/