idnits 2.17.1 draft-lozano-tmch-func-spec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1542 has weird spacing: '... 36xx domai...' == Line 1544 has weird spacing: '... 43xx heade...' == Line 1545 has weird spacing: '... 44xx heade...' == Line 1546 has weird spacing: '... 45xx domai...' == Line 1547 has weird spacing: '... 46xx domai...' -- 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: At 03:00 UTC, the last uploaded LORDN file is considered final, given no ERRORs (i.e. only OKs and warnings) occur during the processing of the file at the TMDB. If a LORDN file is considered final, it is stored in the TMDB, and information is sent to the TMVs for informing the TMHs. Any LORDN file (for the same date) that is uploaded later than 03:00 will be ignored. The TMDB SHOULD not allow upload of LORDN files outside the 00:00 to 03:00 window. -- The document date (April 02, 2013) is 4041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 2026, but no explicit reference was found in the text == Unused Reference: 'RFC1952' is defined on line 2030, 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) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 4 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: Informational B. Hoeneisen 5 Expires: October 4, 2013 Ucom.ch 6 April 02, 2013 8 TMCH functional specifications 9 draft-lozano-tmch-func-spec-02 11 Abstract 13 This document describes the requirements, the architecture and the 14 interfaces between the Trademark Clearing House (TMCH) and Domain 15 Name Registries as well as between the TMCH and Domain Name 16 Registrars for the provisioning and management of domain names during 17 Sunrise and Trademark Claims Period of a domain name Registry. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 4, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9 59 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 60 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . . 14 77 5.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.1.1. Registries . . . . . . . . . . . . . . . . . . . . . . 14 79 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 14 80 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 81 5.1.1.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 82 5.1.1.4. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 15 83 5.1.2. Registrars . . . . . . . . . . . . . . . . . . . . . . 15 84 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 85 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 86 5.1.2.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 16 87 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 16 88 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 17 89 5.2.1. Domain Registration . . . . . . . . . . . . . . . . . 17 90 5.2.2. DN Registration by Registries . . . . . . . . . . . . 18 91 5.2.3. TMCH Sunrise Services for Registries . . . . . . . . . 20 92 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 20 93 5.2.3.2. Certificate Revocation List . . . . . . . . . . . 21 94 5.2.3.3. Notice of Registered Domain Names . . . . . . . . 22 95 5.2.4. DN registration by Registrars . . . . . . . . . . . . 24 96 5.2.5. TMCH Sunrise Services for Registrars . . . . . . . . . 24 97 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 25 98 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 25 99 5.3.2. DN registration by Registries . . . . . . . . . . . . 26 100 5.3.3. Trademark Claims Services for Registries . . . . . . . 28 101 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 28 102 5.3.3.2. Notice of Registered Domain Names . . . . . . . . 28 103 5.3.4. DN Registration by Registrars . . . . . . . . . . . . 29 104 5.3.5. Trademark Claims Services for Registrars . . . . . . . 30 105 5.3.5.1. Claims Notice Information Service . . . . . . . . 30 106 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 31 107 6.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 31 108 6.2. SMD revocation list . . . . . . . . . . . . . . . . . . . 33 109 6.3. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 35 110 6.3.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 38 111 6.3.1.1. LORDN Result Codes . . . . . . . . . . . . . . . . 41 112 6.4. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 44 113 6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 46 114 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 50 115 7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 50 116 8. Status of this Draft . . . . . . . . . . . . . . . . . . . . . 52 117 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 53 120 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 121 12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 122 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 123 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 54 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 126 1. Introduction 128 Domain Name Registries may operate in special modes within certain 129 periods of time to facilitate registration of domain names. 131 Along with the upcoming introduction of new generic Top Level Domains 132 (gTLD), two special modes will come into effect: 134 o Sunrise Period 136 o Trademark Claims Period 138 The Sunrise and Trademark Claims Periods are defined in the gTLD 139 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 141 This document describes the requirements, the architecture and the 142 interfaces between the Trademark Clearing House (TMCH) and Domain 143 Name Registries as well as between the TMCH and Domain Name 144 Registrars for the provisioning and management of domain names during 145 the Sunrise and Trademark Claims Periods. 147 After the Terminology (Section 2) the Glossary (Section 3) is listed, 148 followed by the architecture (Section 4) and the different process 149 descriptions (Section 5). Afterwards, in Section 6, the necessary 150 Data Formats are defined, followed by their formal syntax 151 (Section 7). 153 For any date and/or time indications, Coordinated Universal Time 154 (UTC) applies. 156 1.1. Discussion 158 Any interested parties are invited to contribute to the discussion of 159 this draft and provide feedback. The discussion currently takes 160 place on the tmch-tech discussion list . 161 Interested parties can subscribe to this mailing list via 162 . 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 XML is case sensitive. Unless stated otherwise, XML specifications 171 and examples provided in this document MUST be interpreted in the 172 character case presented in order to develop a conforming 173 implementation. 175 "tmNotice-1.0" is used as an abbreviation for 176 "urn:ietf:params:xml:ns:tm-notice-1.0". The XML namespace prefix 177 "tmNotice" is used, but implementations MUST NOT depend on it and 178 instead employ a proper namespace-aware XML parser and serializer to 179 interpret and output the XML documents. 181 3. Glossary 183 In the following the most common terms are briefly Explained: 185 o Backend Registry Operator: Entity that manages (a part of) the 186 technical infrastructure for a Registry Operator. The Registry 187 Operator may also be the Backend Registry Operator. 189 o CA: Certificate Authority, see [RFC5280] and [RFC6818] 191 o CSV: Comma-Separated Values, see [RFC4180] 193 o CNIS, Claims Notice Information Service: This service provides 194 trademark claims notices to Registrars. 196 o CRC32, algorithm used in the ISO 3309 standard and in section 197 8.1.1.6.2 of ITU-T recommendation V.42. 199 o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. 201 o Date and time, datetime: Date and time are specified following the 202 standard "Date and Time on the Internet specification", see 203 [RFC3339]. 205 o DN: Domain Name, see [RFC1034] 207 o DNS: Domain Name System, see [RFC1034] 209 o DNL, Domain Name Label: An ASCII string used in the DNS (an FQDN 210 is composed by such labels separated by dots) as defined in 211 [RFC1034]. For IDNs the A-Label is used [RFC5890]. 213 o EPP: Extensible Provisioning Protocol, see [RFC5730]. 215 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) 217 o HTTP: Hypertext Transfer Protocol, see [RFC2616] 218 o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. Only 219 TLS 1.0, 1.1 and 1.2 are supported. 221 o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the 222 SMD PKI model. 224 o IDN: Internationalized Domain Names, see [RFC5890] 226 o LORDN, List of Registered Domain Names: This is the list of 227 registered domain names matching a DNL of a PRM that Registries 228 daily upload to the TMDB (during the NORDN process). 230 o Lookup Key: A random string of up to 64 chars from the set [a-zA- 231 Z0-9/] to be used as the lookup Key by Registrars to obtain the 232 claims notice using the CNIS. Lookup Keys are unique and are 233 related to one DNL only. 235 o NORDN, Notification of Registered Domain Names: The process by 236 which Registries daily upload their recent LORDN to the TMDB. 238 o PGP: Pretty Good Privacy, see [RFC4880] 240 o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] 242 o PRM, Pre-registered mark: Mark that has been pre-registered with 243 the TMCH. 245 o Registrant: Person or Organization registering a Domain Name via a 246 Registrar. 248 o Registrar, Domain Name Registrar: Entity that registers Domain 249 Names with the Registry on behalf of the Registrant. 251 o Registry, Registry Operator, Domain Name Registry: Entity that 252 accepts Domain Name registrations from Registrars, maintains the 253 central Database of Registered Domains. A Registry Operator is 254 the contracting party for the TLD. 256 o SMD, Signed Mark Data: A cryptographically signed token issued by 257 the TMV to the TMH to be used in the Sunrise Period to apply for a 258 Domain Name that matches a DNL of a PRM; see also 259 [I-D.lozano-tmch-smd] 261 o SMD File: A file containing the SMD (see above) and some human 262 readable data. The latter is usually ignored in the processing of 263 the SMD File. See also Section 6.4. 265 o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining 266 lists of revoked SMDs; see also [I-D.lozano-tmch-smd] 268 o SMD revocation list: The SMD revocation list is used by Registries 269 (and optionally by Registrars) during the Sunrise Period to ensure 270 that an SMD is still valid (i.e. not revoked). The SMD revocation 271 list has a similar function as CRLs used in PKI. 273 o SRS: Shared Registration System, see also 274 [ICANN-GTLD-AGB-20120604]. 276 o Sunrise Period: During this period Domain Names matching a DNL of 277 a PRM can be exclusively obtained by the respective mark holders. 278 For domain names matching a PRM, a special process applies to 279 ensure a TMH gets informed on the registration of a domain name 280 matching his/her PRM. Every launch of a new gTLD Registry starts 281 with a Sunrise Period, followed by a Trademark Claims Period (see 282 below). 284 o TLD: Top Level Domain Name, see [RFC1591] 286 o Trademark, mark: Trademarks are used to claim exclusive properties 287 of products or services. A trademark is typically a name, word, 288 phrase, logo, symbol, design, image, or a combination of these 289 elements. For the scope of this document only textual trademarks 290 are relevant. 292 o Trademark Claims, Claims: Provides information to enhance the 293 understanding of the Trademark rights being claimed by the 294 Trademark Holder. 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 Domain Names. 300 o Trademark Claims Notice Identifier, Claims Notice Identifier, 301 Claims Notice ID, TCNID: An element of the Trademark Claims Notice 302 (see above), identifying said Claims Notice. The Trademark Claims 303 Notice identifier is specified in the element . 305 o Trademark Claims Period: During this period, a special process 306 applies to DNs matching DNL derived from PRMs, to ensure a TMH 307 gets informed on the registration of a domain name matching his 308 PRM. For DNs matching DNL derived from PRMs, Registrars show a 309 Trademark Claims Notice to prospective Registrants that has to be 310 acknowledged before registration. 312 o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an 313 ICANN central repository for information to be authenticated, 314 stored, and disseminated, pertaining to the rights of trademark 315 holders. The Clearinghouse is split into two functions TMV and 316 TMDB (see below). There could be several entities performing the 317 TMV function, but only one entity performing the TMDB function. 319 o TMDB, Trademark Clearinghouse Database: Serves as a database of 320 the TMCH to provide information to the new gTLD Registries and 321 Registrars to support Sunrise or Trademark Claims Services. There 322 is only one TMDB in the TMCH that concentrates the information 323 about the "verified" Trademark records from the TMVs. 325 o TMH, Trademark Holder: The person or organization owning rights on 326 a Trademark. 328 o TMV, Trademark Validator, Trademark validation organization: An 329 entity authorized by ICANN to authenticate and validate 330 registrations in the TMDB ensuring the marks qualify as registered 331 or are court-validated marks or marks that are protected by 332 statute or treaty. This entity would also be asked to ensure that 333 proof of use of marks is provided, which can be demonstrated by 334 furnishing a signed declaration and one specimen of current use. 336 o UTC: Coordinated Universal Time, as maintained by the Bureau 337 International des Poids et Mesures (BIPM); see also [RFC3339]. 339 4. Architecture 341 4.1. Sunrise Period 343 Architecture Sunrise Period 345 SMD hand over (out of band; 346 trivial if Registrant == TMH) 347 ........................................... 348 : : 349 : .'''''''''''''''''''. : 350 : . TMCH . : 351 : ..................... : 352 v . . : 353 .------------. . .-------------. . hv .-----. 354 | Registrant | . | TMV |<------->| TMH | 355 '------------' . '-------------' . vh '-----' 356 | . | ^ \ . 357 | . | | \. 358 tr | . vs | | \ 359 | . | | dv .\ 360 v . v | . \ 361 .-----------. sr . .---. | . \ 362 .->| Registrar |<.........| S | vd | . \ 363 : '-----------' . | M | | . \ 364 : | sy . | D | v . \ 365 : ry | .-----------| M | .---. . vc \ 366 : | | . '---' | T | . \ 367 : v v . | M | . v 368 : .-----------. . | D | . .----------. 369 : | Registry |----------------->| B | . | ICANN-CA | 370 : '-----------' . yd '---' . '----------' 371 : ^ . . | : 372 : | ''''''''''''''''''' | : 373 : | cy | : 374 : cr '---------------------------------------' : 375 :.....................................................: 377 Figure 1 379 4.2. Trademark Claims Period 381 Architecture Trademark Claims Period 383 .'''''''''''''. 384 . TMCH . 385 ............... 386 . . 387 .------------. . .-------. . hv .-----. 388 | Registrant | . | TMV |<------->| TMH | 389 '------------' . '-------' . vh '-----' 390 | . ^ . 391 tr | . | dv . 392 | . vd | . 393 v . v . 394 .-----------. dr . .-------. . 395 | Registrar |<--------| T | . 396 '-----------' . | | . 397 | . | M | . 398 ry | . | | . 399 v . | D | . 400 .----------. dy . | | . 401 | Registry |<------->| B | . 402 '----------' yd . '-------' . 403 . . 404 ''''''''''''' 406 Figure 2 408 4.3. Interfaces 410 In the sub-sections below follows a short description of each 411 interface to provide an overview of the architecture. More detailed 412 descriptions of the relevant interfaces follow further below 413 (Section 5). 415 4.3.1. hv 417 The TMH registers a mark with a TMV via the hv interface. 419 After the successful registration of the mark, the TMV makes 420 available a SMD (Signed Mark Data) file (see also Section 6.4) to the 421 TMH to be used during the Sunrise Period. 423 The specifics of the hv interface are beyond the scope of this 424 document. 426 4.3.2. vd 428 After successful mark registration, the TMV ensures the TMDB inserts 429 the corresponding DNLs and mark information into the database via the 430 vd interface. 432 The specifics of the vd interface are beyond the scope of this 433 document. 435 4.3.3. dy 437 Not used during the Sunrise Period. 439 During the Trademark Claims Period the Registry fetches the latest 440 DNL list from the TMDB via the dy interface in regular intervals. 441 The protocol used on the dy interface is HTTPS. 443 4.3.4. tr 445 The Registrant communicates with the Registrar via the tr interface. 447 The specifics of the tr interface are beyond the scope of this 448 document. 450 4.3.5. ry 452 The Registrar communicate with the Registry via the ry interface. 453 The ry interfaces is typically implemented in EPP [RFC5730]. A TMCH 454 specific EPP standard extension is yet to be developed. 456 4.3.6. dr 458 Not used during the Sunrise Period. 460 During the Trademark Claims Period the Registrar fetches the 461 Trademark Claims Notice from the TMDB (to be displayed to the 462 Registrant via the tr interface) via the dr interface. The protocol 463 used for fetching the Trademark Claims Notice is HTTPS [RFC2818]. 465 4.3.7. yd 467 During the Sunrise period the Registry notifies the TMDB daily via 468 the yd interface of all domain names registered. 470 During the Trademark Claims period, the Registry notifies daily the 471 TMDB via the yd interface of all domains registered that matched an 472 entry in the Registry's DNL during the creation of the domain name. 474 The protocol used on the yd interface is HTTPS. 476 4.3.8. dv 478 The TMDB notifies the TMV of all domains registered that match a mark 479 registered in the TMDB by that TMV as informed by Registries via the 480 dv interface. 482 The specifics of the dv interface are beyond the scope of this 483 document. 485 4.3.9. vh 487 The TMV notifies the TMH via the vh interface after a domains has 488 been registered that matches a PRM of this TMH. 490 The specifics of the vh interface are beyond the scope of this 491 document. 493 4.3.10. vs 495 The TMV requests to add a revoked SMD to the list of revoked SMDs at 496 the SMDM. 498 The specifics of the vs interface are beyond the scope of this 499 document. 501 Not relevant during the Trademark Claims Period. 503 4.3.11. sy 505 During the Sunrise Period the Registry fetches the most recent list 506 of revoked SMDs from the SMDM via the sy interface in regular 507 intervals. The protocol used on the sy interface is HTTPS. 509 Not relevant during the Trademark Claims Period. 511 4.3.12. sr 513 During the Sunrise Period the Registrar may fetch the most recent 514 list of revoked SMDs from the SMDM via the sr interface. The 515 protocol used on the sr interface is the same as on the sy interface 516 (s. above), i.e. HTTPS. 518 Not relevant during the Trademark Claims Period. 520 4.3.13. vc 522 The TMV requests to add a revoked TMV certificate to the CRL at the 523 ICANN-CA via the vc interface. 525 The specifics of the vc interface are beyond the scope of this 526 document. 528 Not relevant during the Trademark Claims Period. 530 4.3.14. cy 532 During the Sunrise Period the Registry fetches the most recent CRL 533 from the ICANN-CA via the cy interface in regular intervals. The CRL 534 is mainly used for validation of TMV certificates. The protocol used 535 on the cy interface is HTTPS [RFC2818]. 537 Not relevant during the Trademark Claims Period. 539 4.3.15. cr 541 During the Sunrise Period the Registrar may fetch the most recent CRL 542 from the ICANN-CA via the cr interface. The protocol used on the cr 543 interface is the same as on the cy interface (s. above). 545 Not relevant during the Trademark Claims Period. 547 5. Process Descriptions 549 5.1. Bootstrap 551 5.1.1. Registries 553 5.1.1.1. Credentials 555 Each Registry will receive authentication credentials from the TMDB/ 556 SMDM 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 4.3.11). 561 o During Trademark Claims Period to fetch the lists of DNLs from the 562 TMDB via the dy interface (Section 4.3.3). 564 o During the NORDN process to notify the LORDN to the TMDB via the 565 yd interface (Section 4.3.7). 567 o Credentials are created per TLD and provided to the Registry 568 Operator. 570 5.1.1.2. IP Addresses for Access Control 572 Each Registry Operator MUST provide to the TMDB all IP addresses that 573 will be used to: 575 o fetch the list of revoked SMDs via the sr interface 576 (Section 4.3.11). 578 o fetch the lists of DNLs from the TMDB via the dy interface 579 (Section 4.3.3). 581 o notify the LORDN to the TMDB via the yd interface (Section 4.3.7). 583 This access restriction MAY be applied by the TMDB/SMDM in addition 584 to HTTP Basic access authentication (for credentials to be used, see 585 Section 5.1.1.1). 587 The TMDB/SMDM MAY limit the number of IP addresses to be accepted per 588 Registry Operator. 590 5.1.1.3. TMCH Trust Anchor 592 Each Registry MUST fetch the X.509 certificate ([RFC5280] / 593 [RFC6818]) of the ICANN-CA (Trust Anchor) from 594 < https://ca.icann.org/tmch.crt > to be used: 596 o during the Sunrise Period to validate the TMV certificates and the 597 CRL of TMV certificates. 599 5.1.1.4. TMDB/SMDM PGP Key 601 The TMDB MUST provide each Registry with the public portion of the 602 PGP Key used by TMDB and SMDM, to be used: 604 o During the Sunrise Period to perform integrity checking of the 605 list of revoked SMDs fetched from the SMDM via the sy interface 606 (Section 4.3.11). 608 o During Trademark Claims Period to perform integrity checking of 609 the list of DNL fetched from the TMDB via the dy interface 610 (Section 4.3.3). 612 5.1.2. Registrars 614 5.1.2.1. Credentials 616 Each ICANN-accredited Registrar will receive authentication 617 credentials from the TMDB to be used: 619 o During the Sunrise Period to (optionally) fetch the lists of 620 revoked SMDs from the SMDM via the sr interface (Section 4.3.12). 622 o During Trademark Claims Period to fetch Claims Notices from the 623 TMDB via the dr interface (Section 4.3.6). 625 5.1.2.2. IP Addresses for Access Control 627 Each Registrar MUST provide to the TMDB all IP addresses, which will 628 be used to: 630 o fetch the list of revoked SMDs via the sr interface 631 (Section 4.3.12). 633 o fetch Trademark Claims Notices via the dr interface 634 (Section 4.3.6). 636 This access restriction MAY be applied by the TMDB/SMDM in addition 637 to HTTP Basic access authentication (for credentials to be used, see 638 Section 5.1.2.1). 640 The TMDB MAY limit the number of IP addresses to be accepted per 641 Registrar. 643 5.1.2.3. TMCH Trust Anchor 645 Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of 646 the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to 647 be used: 649 o during the Sunrise Period to (optionally) validate the TMV's 650 certificates and the CRL of TMV certificates. 652 5.1.2.4. TMDB PGP Key 654 Registrars MUST receive the public portion of the PGP Key used by 655 TMDB and SMDM from the TMDB administrator to be used: 657 o during the Sunrise Period to (optionally) perform integrity 658 checking of the list of revoked SMDs fetched from the SMDM via the 659 sr interface (Section 4.3.12). 661 5.2. Sunrise Period 663 5.2.1. Domain Registration 665 Registration during Sunrise Period 667 .------------. .-----------. .----------. 668 | Registrant | | Registrar | | Registry | 669 '------------' '-----------' '----------' 670 | | | 671 | Request DN | | 672 | Registration | | 673 | (with SMD) | | 674 |------------->| Check DN availability | 675 | |---------------------------->| 676 | | | 677 | |.-------. DN unavail. .-------------. 678 | || ABORT |<-----------( DN available? ) 679 | |'-------' no '-------------' 680 | | | yes 681 | | | 682 | | Request DN registration | 683 | | (with SMD) | 684 | |---------------------------->| 685 | | | 686 | | .-------------------------------. 687 | | | Validate SMD and | 688 | | | corresponding TMV certificate | 689 | | '-------------------------------' 690 | | | 691 | |.-------. Error .----------------------. 692 | || TRY |<------( Validation successful? ) 693 | || AGAIN | no '----------------------' 694 | || OR | | yes 695 | || ABORT | | 696 | |'-------' | 697 | | | 698 | | DN registered | 699 | DN regist. |<----------------------------| 700 |<-------------| | 701 | | | 703 Figure 3 705 5.2.2. DN Registration by Registries 707 Registries MUST perform a minimum set of checks for verifying DN 708 registrations during Sunrise Period upon reception of a registration 709 request over the ry interface (Section 4.3.5). If any of these 710 checks fails the Registry MUST abort the DN registration. Each of 711 these checks MUST be performed before the DN is registered (see 712 Section 3). 714 In case of asynchronous registrations (e.g. auctions), the minimum 715 set of checks MAY be performed when creating the intermediate object 716 (e.g. a domain name application) used for DN registration. However, 717 the validation of the SMD compared to the moment of effective 718 registration of the DN MUST NOT be older than a period of time (i.e., 719 the SMD-validation validity period) that is defined in the RPM 720 requirements document referenced in Specification 7 of the gTLD 721 Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 723 Performing the minimum set of checks Registries MUST verify that: 725 1. A SMD has been received from the Registrar along with the DN 726 registration. 728 2. The certificate of the TMV has been correctly signed by the 729 ICANN-CA. (The certificate of the TMV is contained within the 730 SMD.) 732 3. The validity period of the TMV certificate is within the allowed 733 range. 735 4. The certificate of the TMV is not be listed in the CRL file 736 specified in the CRL distribution point of the TMV certificate. 738 5. The signature of the SMD (signed with the TMV certificate) is 739 valid. 741 6. The validity period of the SMD is within the allowed range ( and elements). 744 7. The SMD has not been revoked, i.e., is not contained in the SMD 745 revocation list. 747 8. The leftmost DNS label (A-label in case of IDNs) of the DN being 748 registered matches one of the labels () elements in 749 the SMD. 751 These procedure apply to all DN registrations at the second level as 752 well as to all other levels subordinate to the TLD that the Registry 753 accepts registrations for. 755 5.2.3. TMCH Sunrise Services for Registries 757 5.2.3.1. SMD Revocation List 759 A new SMD revocation list MUST be published by the SMDM twice a day, 760 by 00:00 and 12:00 UTC. 762 Registries MUST refresh the latest version of the SMD revocation list 763 at least once every 24 hours. 765 Note: the SMD Revocation List will be the same regardless of the TLD. 766 If a Backend Registry Operator manages the infrastructure of several 767 TLDs, the Backend Registry Operator could refresh the SMD Revocation 768 List once every 24 hours, the SMD Revocation List could be used for 769 all the TLDs managed by the Backend Registry Operator. 771 Update SMD revocation list 773 .----------. .------. 774 | Registry | | SMDM | 775 '----------' '------' 776 | | 777 .----------------. | 778 | Periodically, | | 779 | at least | | 780 | every 24 hours | | 781 '----------------' | 782 | | 783 |----------------------------------------------------->| 784 | Download latest revocation list for SMD certificates | 785 |<-----------------------------------------------------| 786 | | 787 | | 789 Figure 4 791 5.2.3.2. Certificate Revocation List 793 Registries MUST refresh their local copy of the CRL at least every 24 794 hours using the CRL distribution point specified in the TMV 795 certificate. 797 Operationally, the CRL file and CRL distribution point is the same 798 for all TMVs and (at publication of this document) located at 799 < http://crl.icann.org/tmch.crl >. 801 Note: the CRL file will be the same regardless of the TLD. If a 802 Backend Registry Operator manages the infrastructure of several TLDs, 803 the Backend Registry Operator could refresh the CRL file once every 804 24 hours, the CRL file could be used for all the TLDs managed by the 805 Backend Registry Operator. 807 Update CRL for TMV certificates 809 .----------. .----------. 810 | Registry | | ICANN-CA | 811 '----------' '----------' 812 | | 813 .----------------. | 814 | Periodically, | | 815 | at least | | 816 | every 24 hours | | 817 '----------------' | 818 | | 819 |------------------------------------------->| 820 | Download latest CRL for TMV certificates | 821 |<-------------------------------------------| 822 | | 823 | | 825 Figure 5 827 5.2.3.3. Notice of Registered Domain Names 829 The Registry MUST send the LORDN file containing all DNs registered 830 on the previous calendar day (UTC), to the TMDB (over the yd 831 interface, Section 4.3.7) between 00:00 and 03:00 UTC each day. 833 The yd interface (Section 4.3.7) MAY support up to 10 concurrent 834 connections from each IP address allowed to access the service. 836 The TMDB MUST process each uploaded LORDN file within 30 minutes of 837 the finalization of the upload and have the response indicating the 838 errors and warnings to the Registry. 840 A LORDN file with headers and no data elements is used to indicate 841 that there were no registrations the previous calendar day (UTC). 843 If a new LORDN file (containing the registered DNs for the same date) 844 is uploaded before 03:00 UTC, the previous LORDN file will be 845 discarded and the new LORDN file will be processed instead. 847 At 03:00 UTC, the last uploaded LORDN file is considered final, given 848 no ERRORs (i.e. only OKs and warnings) occur during the processing of 849 the file at the TMDB. If a LORDN file is considered final, it is 850 stored in the TMDB, and information is sent to the TMVs for informing 851 the TMHs. Any LORDN file (for the same date) that is uploaded later 852 than 03:00 will be ignored. The TMDB SHOULD not allow upload of 853 LORDN files outside the 00:00 to 03:00 window. 855 In case that a LORDN file was not received for the previous calendar 856 day or errors are encountered, a manual process between the TMDB and 857 the Registry will be performed to transmit the file. 859 NORDN 861 .----------. .------. .-----. .-----. 862 | Registry | | TMDB | | TMV | | TMH | 863 '----------' '------' '-----' '-----' 864 | | | | 865 .------------------. .-----------. | | 866 | Periodically; | | Wait for |<-------. | | 867 | every 24 hours | | LORDN | | | | 868 | (between 00:00 | '-----------' | | | 869 | and 03:00 UTC) | | | | | 870 '------------------' | | | | 871 | | | | | 872 .--------->| Upload LORDN | | | | 873 | |-------------------->| | | | 874 | | | | | | 875 | | .-------------------------. | | | 876 | | | Verify each domain name | | | | 877 | | | in the uploaded file | | | | 878 | | | and write results to a | | | | 879 | | | .err-file (within 30') | | | | 880 | | '-------------------------' | | | 881 | | | | | | 882 | | Download log file | | | | 883 | |<--------------------| | | | 884 | | | | | | 885 | .-----------------. .---------------. | | | 886 | | Check whether | / everything fine \ no | | | 887 | | log file | ( (i.e. no errors )----' | | 888 | | contains errors | \ in log file )? / | | 889 | '-----------------' '---------------' | | 890 | | | yes | | 891 | .---------------. | | | 892 | / everything fine \ yes | | | 893 |( (i.e. no errors )-----. | Notify TMVs | | 894 | \ in log file )? / | | on the LORDN | | 895 | '---------------' | | pre-registered | | 896 | | no v | with said TMV | | 897 | .----------------. .------. |--------------->| | 898 '-| Correct Errors | | DONE | | | | 899 '----------------' '------' | | Notify each | 900 | | | affected TMH | 901 | | |------------->| 902 | | | | 904 Figure 6 906 The format used for the LORDN is described in Section 6.3 908 5.2.4. DN registration by Registrars 910 Registrars MAY choose to perform the checks for verifying DN 911 registrations as performed by the Registries (see Section 5.2.2) 912 before sending the command to register a DN. 914 5.2.5. TMCH Sunrise Services for Registrars 916 The processes described in Section 5.2.3.1 and Section 5.2.3.2 are 917 also available for Registrars to optionally validate the SMDs 918 received. 920 5.3. Trademark Claims Period 922 5.3.1. Domain Registration 924 Registration during Trademark Claims Period 926 .------------. .-----------. .----------. .------. 927 | Registrant | | Registrar | | Registry | | TMDB | 928 '------------' '-----------' '----------' '------' 929 | | | | 930 | Request DN | | | 931 | Registration | Check DN availability | | 932 |------------->|---------------------------->| | 933 | | | | 934 | |.-------. DN unavail. .-------------. | 935 | || ABORT |<-----------( DN available? ) | 936 | |'-------' no '-------------' | 937 | | | yes | 938 | | DN available & .---------. | 939 | |.----------. no claim / Does DN \ | 940 | || CONTINUE |<---------( match DNL ) | 941 | || NORMALLY | no \ of PRM? / | 942 | |'----------' '---------' | 943 | | | yes | 944 | | DN avail (Lookup key inc.) | | 945 | |<----------------------------| | 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 | | | | 961 | DN regist. | DN registered | | 962 |<-------------|<----------------------------| | 963 | | | | 965 Figure 7 967 5.3.2. DN registration by Registries 969 During Trademark Claim Periods, Registries perform two main 970 functions: 972 o Registries MUST provide Registrars (over the ry interface, 973 Section 4.3.5) the Lookup Key used to retrieve the Trademark 974 Claims for domain names that matches a DNL of a PRM and are 975 available for registration. 977 o Registries MUST provide the Lookup Key only when queried about a 978 specific DN. 980 o For any DN matching a DNL of a PRM, Registries MUST perform a 981 minimum set of checks for verifying DN registrations during 982 Trademark Claims Period upon reception of a registration request 983 over the ry interface (Section 4.3.5). If any of these checks 984 fails the Registry MUST abort the DN registration. Each of these 985 checks MUST be performed before the DN is registered (see 986 Section 3). 988 o In case of asynchronous registrations (e.g. auctions), the minimum 989 set of checks MAY be performed when creating the intermediate 990 object (e.g. a domain name application) used for DN registration. 991 However, the acknowledgement of the Trademark Notice compared to 992 the moment of effective registration of the DN MUST NOT be older 993 than a period of time (i.e., the TCN-Ack validity period) that is 994 defined in the RPM requirements document referenced in 995 Specification 7 of the gTLD Applicant Guidebook 996 [ICANN-GTLD-AGB-20120604]. 998 o Performing the minimum set of checks Registries MUST verify that: 1000 1. The Claims Notice Identifier, expiration datetime and 1001 acceptance datetime of the Trademark Notice, have been 1002 received from the Registrar along with the DN registration. 1004 If the three elements mentioned above are not provided by 1005 the Registrar for a DN matching a DNL of a PRM, but the DNL 1006 was inserted (or re-inserted) for the first time into DNL 1007 list less than 24 hours ago, the registration MAY continue 1008 without this data and the tests listed below are not 1009 required to be performed. (Note however, that such DN 1010 registrations MUST be included in the LORDN.) 1012 2. The claim notice has not expired (according to the expiration 1013 datetime sent by the Registrar). 1015 3. The acceptance datetime is no more than 48 hours in the past. 1017 4. Using the leftmost DNS label (A-label in the case of IDNs) of 1018 the DN being registered, the expiration datetime provided by 1019 the registrar and the TMDB identifier extracted from the 1020 Claims Notice identifier provided by the registrar compute the 1021 checksum. Verify using that the checksum match the checksum 1022 present in the Claims Notice identifier. 1024 These procedures apply to all DN registrations at the second level as 1025 well as to all other levels subordinate to the TLD that the Registry 1026 accepts registrations for. 1028 5.3.3. Trademark Claims Services for Registries 1030 5.3.3.1. Domain Name Label (DNL) List 1032 A new DNL list MUST be published by the TMDB twice a day, by 00:00 1033 and 12:00 UTC. 1035 Registries MUST refresh the latest version of the DNL list at least 1036 once every 24 hours. 1038 Update DNL list 1040 .----------. .------. 1041 | Registry | | TMDB | 1042 '----------' '------' 1043 | | 1044 .----------------. | 1045 | Periodically, | | 1046 | at least | | 1047 | every 24 hours | | 1048 '----------------' | 1049 | | 1050 |-------------------------------->| 1051 | Download latest list of DNLs | 1052 |<--------------------------------| 1053 | | 1054 | | 1056 Figure 8 1058 Note: the DNL List will be the same regardless of the TLD. If a 1059 Backend Registry Operator manages the infrastructure of several TLDs, 1060 the Backend Registry Operator could refresh the DNL List once every 1061 24 hours, the DNL List could be used for all the TLDs managed by the 1062 Backend Registry Operator. 1064 5.3.3.2. Notice of Registered Domain Names 1066 The NORDN process during the Trademark Claims Period is almost the 1067 same as during Sunrise Period as defined in Section 5.2.3.3 with the 1068 difference that only registrations subject to a Trademark Claim 1069 (i.e., at registration time the name appeared in the current DNL list 1070 downloaded by the Registry) are included in the LORDN. 1072 5.3.4. DN Registration by Registrars 1074 For any DN matching a DNL of a PRM, Registrars MUST perform the 1075 following steps: 1077 1. Use the Lookup Key received from the Registry (while verifying DN 1078 availability) to obtain the Claims Notice from the TMDB using the 1079 dr interface (Section 4.3.6) 1081 2. Present the Claims Notice to the Registrant as described in 1082 [ICANN-GTLD-AGB-20120604]. 1084 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST 1085 consent with the Claims Notice, before any further processing. 1086 (The transmission of a Trademark Claims Identifier to the 1087 Registry over the ry interface, Section 4.3.5 implies that the 1088 Registrant has expressed his consent with the Claims Notice.) 1090 4. Perform the minimum set of checks for verifying DN registrations. 1091 If any of these checks fails the Registrar MUST abort the DN 1092 registration. Each of these checks MUST be performed before the 1093 registration is sent to the Registry. Performing the minimum set 1094 of checks Registrars MUST verify that: 1096 1. The claim notice has not expired (using expiration date 1097 (). 1099 2. The claim notice validity based on the (). 1102 3. The leftmost DNS label (A-label in case of IDNs) of the DN 1103 being registered matches the label () element 1104 in the Trademark Claim Notice. 1106 4. The Registrant has acknowledged (expressed his consent with) 1107 the Claims Notice. 1109 5. Record the date and time when the registrant acknowledged the 1110 trademark claims notice. 1112 6. Send the registration to the Registry (ry interface, 1113 Section 4.3.5) and include the following information: 1115 * Trademark Claims Identifier () 1117 * Expiration date of the claims notice () 1118 * Acceptance datetime of the trademark claims notice. 1120 Claims notices are generated twice a day. The expiration date of the 1121 claims notice is set to 48 hours in the future, allowing the 1122 implementation of a cache by Registrars and enough time for the 1123 registration workflow process to finalize. Registrars SHOULD 1124 implement a cache of claims notices to minimize the number of queries 1125 sent to the TMDB. The cached TM Notice must be removed from the 1126 cache after the expiration date of the TM notice as defined by 1127 . The TMDB MAY implement rate-limiting as one of 1128 the protection mechanisms to mitigate the risk of performance 1129 degradation. 1131 5.3.5. Trademark Claims Services for Registrars 1133 5.3.5.1. Claims Notice Information Service 1135 The Trademark Claims Notices are provided by the TMDB online and are 1136 fetched by the Registrar via the dr interface (Section 4.3.6). 1138 To get access to the Trademark Claims Notices, the Registrar needs 1139 the credentials provided by the TMDB (Section 5.1.2.1) and the Lookup 1140 Key received from the Registry via the ry interface (Section 4.3.5). 1141 The dr interface (Section 4.3.6) uses HTTPS with Basic access 1142 authentication. 1144 The dr interface (Section 4.3.6) MAY support up to 10 concurrent 1145 connections from each Registrar. 1147 The URL of the dr interface (Section 4.3.6) is: 1148 /cnis/.xml> 1150 Note that the "lookupkey" may contain SLASH characters ("/"). 1152 The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) 1153 MUST be signed by a well-know public CA. Registrars MUST perform 1154 standard validation of the TLS (HTTPS) certificate. Registrars are 1155 authenticated in the dr interface using HTTP Basic access 1156 authentication. The dr (Section 4.3.6) interface MUST support HTTPS 1157 keep-alive and MUST maintain the connection for up to 30 minutes. 1159 6. Data Format Descriptions 1161 6.1. DNL List file 1163 This section defines format of the list containing every Domain Name 1164 Label (DNL) that matches a Pre-Registered Mark (PRM). The list is 1165 maintained by the TMDB and downloaded by Registries in regular 1166 intervals (see Section 5.3.3.1). The Registries use the DNL list 1167 during the Trademark Claims period to check whether a requested DN 1168 matched a DNL of a PRM. 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. Version 1 MUST always be 1178 present. 1180 + , date and time that the DNL was 1181 created. 1183 o second line: a header line as specified in [RFC4180] 1185 With the header names as follows: 1187 DNL,lookup-key,insertion-datetime 1189 o One or more lines with: ,, 1192 Where: 1194 + , a domain label covered by a trademark. 1196 + , lookup key that the registry MUST provide to 1197 the registrar. 1199 + , datetime when the DNL was first 1200 inserted into the DNL. The possible two values of time for 1201 inserting a DNL to the DNL list are 00:00 and 12:00. 1203 Example for DNL list 1205 1,2012-08-16T00:00:00.0Z 1206 DNL,lookup-key,insertion-datetime 1207 example,j8f/KR6/Dex/dac5KfYddfEr,2010-07-14T00:00:00.0Z 1208 another-example,lj3/l4F/33F/f4HGgg42l5Ts,2012-08-16T00:00:00.0Z 1209 anotherexample,h7h/nm9/FEJ/iHH82mkj3d2c,2011-08-16T12:00:00.0Z 1211 Figure 9 1213 To provide authentication and integrity protection, the DNL list will 1214 be PGP [RFC4880] signed by the TMDB with the private key of the TMDB 1215 (see also Section 5.1.1.4). The PGP signature of the DNL list can be 1216 found in the similar URI but with extension .sig as shown below. 1218 The URL of the dy interface (Section 4.3.3) is: 1220 o /dnl/dnl-latest.csv> 1222 o /dnl/dnl-latest.sig> 1224 6.2. SMD revocation list 1226 This section defines format of the list of SMDs that have been 1227 revoked. The list is maintained by the SMDM and downloaded by 1228 Registries (and optionally by Registrars) in regular intervals (see 1229 Section 5.2.3.1). The SMD revocation list is used during the Sunrise 1230 Period to validate SMDs received. The SMD revocation list has a 1231 similar function as CRLs used in PKI [RFC5280] / [RFC6818]. 1233 The SMD revocation list is contained in a CSV-like formatted file 1234 that has the following structure: 1236 o first line: , 1238 Where: 1240 + , version of the file. Version 1 MUST always be 1241 present. 1243 + , datetime that the 1244 SMD revocation list was created. 1246 o second line: a header line as specified in [RFC4180] 1248 With the header names as follows: 1250 smd-id 1252 o One or more lines with: 1254 Where: 1256 + , identifier of the SMD that was revoked. 1258 To provide integrity protection, the SMD revocation list is PGP 1259 [RFC4880] signed by the TMDB with the private key of the TMDB (see 1260 also Section 5.1.1.4). The SMD revocation list is provided by the 1261 TMDB with extension .csv. The PGP signature of the SMD revocation 1262 list can be found in the similar URI but with extension .sig as shown 1263 below. 1265 The URL of the sr interface (Section 4.3.12) and sy interface 1266 (Section 4.3.11) is: 1268 o /smdrl/smdrl-latest.csv> 1270 o /smdrl/smdrl-latest.sig> 1271 Example for SMD Revocation list 1273 1,2012-08-16T00:00:00.0Z 1274 smd-id 1275 2-2 1276 3-2 1277 1-2 1279 Figure 10 1281 6.3. LORDN File 1283 This section defines the format of the List of Registered Domain 1284 Names (LORDN), which is maintained by each Registry and uploaded 1285 daily to the TMDB. Every time a DN matching a DNL of a PRL said DN 1286 is added to the LORDN along with further information related to its 1287 registration. 1289 The URI of the dy interface (Section 4.3.3) used to upload the LORDN 1290 file is: 1292 o https:///LORDN// 1294 o For example, to upload the LORN file for 2012-08-15 and TLD 1295 "example", the URL would be 1296 https:///LORDN/example/2012-08-15 1298 The LORDN is contained in a CSV-like formatted file that has the 1299 following structure: 1301 o For Sunrise Period: 1303 * first line: ,,,, 1306 Where: 1308 - , version of the file. Version 1 MUST always be 1309 present. 1311 - , date and time that the LORDN 1312 was created. 1314 - , day when the domains were 1315 registered. 1317 - : Sunrise 1319 - , number of domain names registered 1321 * second line: a header line as specified in [RFC4180] 1323 With the header names as follows: 1325 roid,domain-name,SMD-id,registrar-id,application- 1326 datetime,registration-datetime 1328 * One or more lines with: ,,, ,, 1332 Where: 1334 - , Repository Object IDentifier (ROID) in the SRS. 1336 - , domain name that was registered. 1338 - , SMD ID used when the domain was registered. 1340 - , IANA registrar ID. 1342 - OPTIONAL , date and 1343 time that the application was created, in case of a 1344 domain registration based on an asynchronous registration 1345 (e.g., when using auctions). 1347 - , date and time that the domain 1348 was registered. 1350 Example for LORDN during Sunrise 1352 1,2012-08-16T00:00:00.0Z,2012-08-15,Sunrise,3 1353 roid,domain-name,SMD-id,registrar-id,application-datetime,\ 1354 registration-datetime, 1355 SH8013-REP,example1.gtld,1-2,9999,2012-07-15T00:50:00.0Z,\ 1356 2012-08-15T13:20:00.0Z 1357 EK77-REP,example2.gtld,2-2,9999,,2012-08-15T14:00:03.0Z 1358 HB800-REP,example3.gtld,3-2,9999,,2012-08-15T15:40:00.0Z 1360 Figure 11 1362 o For Trademark Claims Period: 1364 * first line: ,,,, 1367 Where: 1369 - , version of the file. Version 1 MUST always be 1370 present. 1372 - , date and time that the LORDN 1373 was created. 1375 - , day when the domains were 1376 registered. 1378 - : Claims 1380 - , number of domain names registered 1382 * second line: a header line as specified in [RFC4180] 1384 With the header names as follows: 1386 roid,domain-name,notice-id,registrar-id,application- 1387 datetime,registration-datetime,ack-datetime 1389 * One or more lines with: ,,,< 1390 IANA registrar id>,,, 1393 Where: 1395 - , Repository Object IDentifier (ROID) in the SRS. 1397 - , domain name that was registered. 1399 - , trademark notice identifier as specified 1400 in . 1402 - , IANA registrar ID. 1404 - OPTIONAL , date and 1405 time that the application was created, in case of a 1406 domain registration based on an asynchronous registration 1407 (e.g., when using auctions). 1409 - , date and time that the domain 1410 was registered. 1412 - , date and time 1413 that the TM notice was acknowledged. 1415 For a DN matching a DNL of a PRM at the moment of 1416 registration, created without the Claims Notice Identifier, 1417 expiration datetime and acceptance datetime, because DNL was 1418 inserted (or re-inserted) for the first time into DNL list 1419 less than 24 hours ago, the string "recent-dnl-insertion" 1420 MUST be specified in and . 1423 Example for LORDN during Claims 1425 1,2012-08-16T00:00:00.0Z,2012-08-15,Claims,3 1426 roid,domain-name,notice-id,registrar-id,application-datetime,\ 1427 registration-datetime,ack-datetime 1428 SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 1429 9999,,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z 1430 EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 1431 9999,,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z 1432 HB800-REP,example3.gtld,recent-dnl-insertion,\ 1433 9999,,2012-08-15T13:20:00.0Z,recent-dnl-insertion 1435 Figure 12 1437 6.3.1. LORDN Log File 1439 After reception of the LORDN File, the TMDB verifies its content for 1440 syntactical and semantical correctness. The output of the LORDN File 1441 verification is retrieved using the dy interface (Section 4.3.3). 1443 The URI of the dy interface (Section 4.3.3) used to retrieve the 1444 LORDN Log File is: 1446 o https:///LORDN///result 1448 o For example, to obtain the LORN Log File for 2012-08-15 and TLD 1449 "example" the URI would be 1450 https:///LORDN/example/2012-08-15/result 1452 The LORDN log file is contained in a CSV-like formatted file that has 1453 the following structure: 1455 o first line: ,, ,,,,, 1459 Where: 1461 + , version of the file. Version 1 MUST always be 1462 present. 1464 + , date and time that the LORDN 1465 Log was created. 1467 + , date and time of creation 1468 for the LORDN file that this log file is referring to. 1470 + , day when the domains were 1471 registered as indicated in the related LORDN file. 1473 + , Sunrise or Claims. 1475 + , unique identifier of the LORDN Log 1476 provided by the TMDB. This identifier could be used by the 1477 Registry Operator to unequivocally identify the LORDN Log. 1478 The identified will be a string of a maximum LENGHT of 60 1479 characters from the Base 64 alphabet. 1481 + , whether the LORDN file has been accepted for 1482 processing by the TMDB. Possible values are "accepted" or 1483 "rejected". 1485 + , whether the LORDN Log has any warning result 1486 codes. Possible values are "no-warnings" or "warnings- 1487 present". 1489 + , number of processed lines. 1491 A Registry Operator is NOT REQUIRED to process a LORDN Log with 1492 a ="accepted" and ="no". 1494 o second line: a header line as specified in [RFC4180] 1496 With the header names as follows: 1498 roid,result-code 1500 o One or more lines with: , 1502 Where: 1504 + , Repository Object IDentifier (ROID) in the SRS. 1506 + , result code as described in Section 6.3.1.1. 1508 Example for LORDN Log file 1510 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 1511 2012-08-15,Claims,\ 1512 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ 1513 accepted,no-warnings,1 1514 roid,result-code 1515 SH8013-REP,2000 1517 Figure 13 1519 6.3.1.1. LORDN Result Codes 1521 In Figure 14 the classes of result codes (rc) are listed. Those 1522 classes in square brackets are not used at this time, but may come 1523 into use at some later stage. The first two digits of a result code 1524 denote the result code class, which defines the outcome at the TMDB: 1526 o ok: Success, domain name line accepted 1528 o warn: a warning is issued, domain name line accepted 1530 o err: an error is issued, LORDN file rejected 1532 LORDN Result Code Classes 1534 code Class outcome 1535 ---- ----- ------- 1537 20xx Success ok 1539 33xx [ header line syntax warning ] warn 1540 34xx [ header line semantic warning ] warn 1541 35xx [ domain name line syntax warning ] warn 1542 36xx domain name line semantic warning warn 1544 43xx header information syntax error err 1545 44xx header information semantic error err 1546 45xx domain name line syntax error err 1547 46xx domain name line semantic error err 1549 Figure 14 1551 In the following the LORDN result codes used by the TMDB are 1552 described: 1554 LORDN result Codes 1556 rc Short Description 1557 Long Description 1558 ---- ------------------------------------------------------------ 1560 2000 OK 1561 Domain Name line successfully processed 1563 3601 TCN Acknowledgement Date after Registration Date 1564 TCN Acknowledgement Date in Domain Name is newer than the 1565 Registration Date 1567 3602 Duplicate DN Line 1568 This DN Line is an exact duplicate of another line in same 1569 file, DN line ignored 1571 3603 ROID Notified Earlier 1572 Same ROID has been notified earlier, DN line ignored 1574 3604 Checksum Invalid 1575 Based on the DN registered, the TMC-ID and 1576 the expiration date of the linked TM notice, the 1577 checksum is invalid. 1579 3605 TMC-ID Expired 1580 Trademark Claim Notice Identifier was expired 1581 when accepted, but still accepted. 1582 In case of an asynchronous registration, this may refer 1583 to the date of the application creation. 1585 3606 Wrong TMC-ID used 1586 The TMC-ID used for the registration was not valid 1587 for this DN. 1589 3607 SMD-Validation too old 1590 The validation of the SMD was done outside of the SMD-validation 1591 validity period, and still was used for registration. 1593 3608 TCN-Acknowledgement too old 1594 The Acknowledgement of the TCN was done outside of the TCN-Ack 1595 validity period, and still was used for registration. 1597 3609 Invalid SMD used 1598 The SMD used for registration was not valid. In case of 1599 an asynchronous registration, this may refer to the date of 1600 the application creation. 1602 4301 Syntax Error in Header 1603 Syntax Error in Header information. 1605 4401 Domain Name Count Mismatch 1606 The number of Domain Names in Header does not match 1607 the count of DN lines 1609 4402 Creation Date in past or future 1610 Creation Date of LORDN is out of range 1612 4403 Registration Date in past or future 1613 Registration date of LORDN is out of range 1615 4404 Sunrise/Claims mismatch 1616 The LORDN is for Sunrise, but the TLD is marked in the TMDB 1617 as being in Claims or vice versa 1619 4501 Syntax Error in DN line 1620 Syntax Error in Domain Name line 1622 4601 Invalid TLD used 1623 The TLD in the DN line does not match what is expected for this LORDN 1625 4602 Registrar ID Invalid 1626 Registrar ID in DN line is not valid 1628 4603 Registration Date out of range 1629 Registration Date in the DN line is in the past or the future 1631 Figure 15 1633 6.4. SMD File 1635 This section defines the format of the SMD File. After a successful 1636 registration of a mark, the TMV returns an SMD File to the TMH. The 1637 SMD file can then be used for registration of one or more DNs covered 1638 by the PRM during the Sunrise Period of a TLD. 1640 Two encapsulation boundaries are defined for delimiting the 1641 encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" 1642 and "-----END ENCODED SMD-----". Only data inside the encapsulation 1643 boundaries MUST be used by Registries and Registrars for validation 1644 purposes, i.e. any data outside these boundaries as well as the 1645 boundaries themselves MUST be ignored for validation purposes. 1647 The structure of the SMD File is as follows: 1649 o Marks: 1651 o smdID: 1653 o U-labels: 1655 o notBefore: 1657 o notAfter: 1659 o -----BEGIN ENCODED SMD----- 1661 o 1663 o -----END ENCODED SMD----- 1664 Example for SMD File (shortened at [...]): 1666 Marks: Example One 1667 smdID: 1-2 1668 U-labels: example-one, exampleone 1669 notBefore: 2011-08-16 09:00 1670 notAfter: 2012-08-16 09:00 1671 -----BEGIN ENCODED SMD----- 1672 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu 1673 ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN 1674 YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ 1675 CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 1676 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt 1677 cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt 1678 cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz 1679 NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu 1680 b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K 1681 ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB 1682 ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 1683 [...] 1684 UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy 1685 NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND 1686 cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR 1687 eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG 1688 TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl 1689 cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 1690 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= 1691 -----END ENCODED SMD----- 1693 Figure 16 1695 6.5. Trademark Claims Notice 1697 The TMDB MUST provide the Trademark Claim Notice to Registrars in XML 1698 format as specified below. 1700 An enclosing element that describes the Trademark 1701 Notice to a given label. 1703 The child elements of the element include: 1705 o A element that contains the unique identifier of the 1706 Trademark Notice. 1708 The Trademark Notice identifier is a concatenation of a 1709 checksum and the TMDB identifier. The first 8 characters of 1710 the Trademark Notice identifier is a checksum. The rest is the 1711 TMDB identifier, which is a zero-padded number in the range of 1712 1 to 9223372036854775808. 1714 Example of a Trademark Notice identifier 1715 a7b216ed9223372036854775808. 1717 Where: 1719 + Checksum=a7b216ed 1721 + TMDB identifier=9223372036854775808 1723 The checksum is a 8 characters long Base16 encoded output of 1724 computing the CRC32 of the string concatenation of: label + 1725 unix_timestamp() + TMDB identifier 1727 The TMDB uses the and 1728 elements from the Trademark Notice along with the TMDB 1729 identifier to compute the checksum. 1731 A registry MUST use the leftmost DNS label (A-label in case of 1732 IDNs) of the DN being registered, the expiration datetime of 1733 the Trademark Notice and the TMDB identifier extracted from the 1734 Trademark Notice identifier provided by the Registrar to 1735 compute the checksum. For example the DN "foo.bar.example" 1736 being registered, the left most label would be "foo". 1738 Example of computation of the checksum: CRC32(example- 1739 one12819492009223372036854775808)=a7b216ed 1741 o A element that contains the start of the 1742 validity date and time of the TM notice. 1744 o A element that contains the expiration date 1745 and time of the TM notice. 1747 o A elements that contain the DNS label (A-label in 1748 case of IDNs) form of the label that correspond to the DN covered 1749 by a PRM. 1751 o One or more elements that contain the claim. The 1752 element contains the following child elements: 1754 * A element that contains the mark text 1755 string. 1757 * One or more elements that contains the 1758 information of the holder of the mark. An "entitlement" 1759 attribute is used to identify the entitlement of the holder, 1760 possible values are: owner, assignee and licensee. 1762 * Zero or more OPTIONAL elements that contains 1763 the information of the representative of the mark registration. 1764 A "type" attribute is used to identify the type of contact, 1765 possible values are: owner, agent or thirdparty. 1767 * A element that contains the name (in 1768 English) of the jurisdiction where the trademark is protected. 1769 A jurCC attribute contains the two-character code of the 1770 jurisdiction where the trademark was registered. This is a 1771 two-character code from [WIPO.ST3]. 1773 * Zero or more OPTIONAL element that 1774 contains the description (in English) of the Nice 1775 Classification as defined in [WIPO-NICE-CLASSES]. A classNum 1776 attribute contains the class number. 1778 * A element that contains the full 1779 description of the goods and services mentioned in the mark 1780 registration document. 1782 Example of object: 1784 1785 1786 a7b216ed9223372036854775808 1787 2010-08-14T09:00:00.0Z 1788 2010-08-16T09:00:00.0Z 1789 example-one 1790 1791 Example One 1792 1793 Example Inc. 1794 1795 123 Example Dr. 1796 Suite 100 1797 Reston 1798 VA 1799 20190 1800 US 1801 1802 1803 1804 Joe Doe 1805 Example Inc. 1806 1807 123 Example Dr. 1808 Suite 100 1809 Reston 1810 VA 1811 20190 1812 US 1813 1814 +1.7035555555 1815 jdoe@example.com 1816 1817 UNITED STATES OF AMERICA 1818 1819 Advertising; business management; business administration. 1820 1821 1822 Insurance; financial affairs; monetary affairs; real estate. 1823 1824 1825 Bardus populorum circumdabit se cum captiosus populum. 1826 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 1827 1828 1829 1830 Example-One 1831 1832 Example S.A. de C.V. 1833 1834 Calle conocida #343 1835 Conocida 1836 SP 1837 82140 1838 BR 1839 1840 1841 BRAZIL 1842 1843 Bardus populorum circumdabit se cum captiosus populum. 1844 Smert populorum circumdabit se cum captiosus populum qui eis differimus. 1845 1846 1847 1849 This example generates a TRADEMARK NOTICE with two mark claims. 1851 For formal syntax of the Trademark Claims Notice please refer to 1852 Section 7.1. 1854 7. Formal Syntax 1856 7.1. Trademark Claims Notice 1858 The schema presented here is for the Trademark Claims Notice. 1860 Copyright (c) 2012 IETF Trust and the persons identified as authors 1861 of the code. All rights reserved. 1863 Redistribution and use in source and binary forms, with or without 1864 modification, are permitted provided that the following conditions 1865 are met: 1867 o Redistributions of source code must retain the above copyright 1868 notice, this list of conditions and the following disclaimer. 1870 o Redistributions in binary form must reproduce the above copyright 1871 notice, this list of conditions and the following disclaimer in 1872 the documentation and/or other materials provided with the 1873 distribution. 1875 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1876 names of specific contributors, may be used to endorse or promote 1877 products derived from this software without specific prior written 1878 permission. 1880 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1881 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1882 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1883 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1884 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1885 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1886 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1887 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1888 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1889 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1890 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1892 BEGIN 1893 1894 1899 1900 1901 Schema for representing a Trademark Notice. 1902 1903 1904 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1926 1927 1928 1929 1930 1931 1933 1935 1936 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 END 1983 8. Status of this Draft 1985 This draft is the product of several discussions regarding the 1986 interaction between the TMCH and Registries/Registrars. It does by 1987 no means claim to be complete and minor updates are likely to be 1988 added in future versions of this document. 1990 9. Acknowledgements 1992 TBD 1994 10. IANA Considerations 1996 TBD 1998 11. Security Considerations 2000 TBD 2002 12. References 2004 12.1. Normative References 2006 [I-D.lozano-tmch-smd] 2007 Lozano, G., "Mark and Signed Mark Objects Mapping", 2008 draft-lozano-tmch-smd-02 (work in progress), March 2013. 2010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2011 Requirement Levels", BCP 14, RFC 2119, March 1997. 2013 12.2. Informative References 2015 [ICANN-GTLD-AGB-20120604] 2016 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 2017 June 2012, . 2020 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2021 STD 13, RFC 1034, November 1987. 2023 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 2024 RFC 1591, March 1994. 2026 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2027 E. Lear, "Address Allocation for Private Internets", 2028 BCP 5, RFC 1918, February 1996. 2030 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2031 Randers-Pehrson, "GZIP file format specification version 2032 4.3", RFC 1952, May 1996. 2034 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2035 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2036 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2038 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2040 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2041 Internet: Timestamps", RFC 3339, July 2002. 2043 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 2044 Separated Values (CSV) Files", RFC 4180, October 2005. 2046 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2047 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2049 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2050 Housley, R., and W. Polk, "Internet X.509 Public Key 2051 Infrastructure Certificate and Certificate Revocation List 2052 (CRL) Profile", RFC 5280, May 2008. 2054 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2055 STD 69, RFC 5730, August 2009. 2057 [RFC5890] Klensin, J., "Internationalized Domain Names for 2058 Applications (IDNA): Definitions and Document Framework", 2059 RFC 5890, August 2010. 2061 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 2062 Infrastructure Certificate and Certificate Revocation List 2063 (CRL) Profile", RFC 6818, January 2013. 2065 [WIPO-NICE-CLASSES] 2066 WIPO, "Nice List of Classes", . 2069 [WIPO.ST3] 2070 WIPO, "Recommended standard on two-letter codes for the 2071 representation of states, other entities and 2072 intergovernmental organizations", March 2007. 2074 Appendix A. Document Changelog 2076 [RFC Editor: This section is to be removed before publication] 2078 Authors' Addresses 2080 Gustavo Lozano (editor) 2081 ICANN 2082 12025 Waterfront Drive, Suite 300 2083 Los Angeles 90292 2084 US 2086 Phone: +1.3103015800 2087 Email: gustavo.lozano@icann.org 2089 Bernie Hoeneisen 2090 Ucom Standards Track Solutions GmbH 2091 CH-8000 Zuerich 2092 Switzerland 2094 Phone: +41 44 500 52 44 2095 Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) 2096 URI: http://www.ucom.ch/