Internet Engineering Task Force G. Lozano Internet-Draft ICANN Intended status: Informational Jul 23, 2015 Expires: January 24, 2016 TMCH functional specifications draft-lozano-tmch-func-spec-10 Abstract This document describes the requirements, the architecture and the interfaces between the Trademark Clearing House (TMCH) and Domain Name Registries as well as between the TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 24, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lozano Expires January 24, 2016 [Page 1] Internet-Draft TMCH functional specifications Jul 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . . 14 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . . 14 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 14 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 5.1.1.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14 5.1.1.4. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 15 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . . 16 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 16 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 16 5.1.2.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 16 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 16 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Domain Name Registration . . . . . . . . . . . . . . . 17 5.2.2. Sunrise DN Registration by Registries . . . . . . . . 18 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . . 19 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 19 5.2.3.2. Certificate Revocation List . . . . . . . . . . . 20 5.2.3.3. Notice of Registered Domain Names . . . . . . . . 21 5.2.4. Sunrise DN registration by Registrars . . . . . . . . 23 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . . 24 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 25 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 25 5.3.2. Trademark Claims DN registration by Registries . . . . 27 Lozano Expires January 24, 2016 [Page 2] Internet-Draft TMCH functional specifications Jul 2015 5.3.3. TMBD Claims Services for Registries . . . . . . . . . 29 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 29 5.3.3.2. Notice of Registered Domain Names . . . . . . . . 30 5.3.4. Trademark Claims DN Registration by Registrars . . . . 31 5.3.5. TMBD Claims Services for Registrars . . . . . . . . . 33 5.3.5.1. Claims Notice Information Service . . . . . . . . 33 5.4. Qualified Launch Program Period . . . . . . . . . . . . . 34 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 34 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . . 36 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 36 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 37 6.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 37 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 39 6.3. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 41 6.3.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 46 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . . 49 6.4. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 55 6.6. Sunrise List File . . . . . . . . . . . . . . . . . . . . 63 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 65 7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 69 9.1. Changes from draft-lozano-tmch-func-spec-06 to draft-lozano-tmch-func-spec-07 . . . . . . . . . . . . . . 69 9.2. Changes from draft-lozano-tmch-func-spec-07 to draft-lozano-tmch-func-spec-08 . . . . . . . . . . . . . . 69 9.3. Changes from draft-lozano-tmch-func-spec-08 to draft-lozano-tmch-func-spec-09 . . . . . . . . . . . . . . 69 9.4. Changes from draft-lozano-tmch-func-spec-09 to draft-lozano-tmch-func-spec-10 . . . . . . . . . . . . . . 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 12.1. Normative References . . . . . . . . . . . . . . . . . . . 70 12.2. Informative References . . . . . . . . . . . . . . . . . . 71 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 Lozano Expires January 24, 2016 [Page 3] Internet-Draft TMCH functional specifications Jul 2015 1. Introduction Domain Name Registries may operate in special modes within certain periods of time to facilitate registration of domain names. Along with the upcoming introduction of new generic Top Level Domains (gTLD), two special modes will come into effect: o Sunrise Period o Trademark Claims Period The Sunrise and Trademark Claims Periods are defined in the gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604]. This document describes the requirements, the architecture and the interfaces between the Trademark Clearing House (TMCH) and Domain Name Registries (called Registries in the rest of the document) as well as between the TMCH and Domain Name Registrars (called Registrars in the rest of the document) for the provisioning and management of domain names during the Sunrise and Trademark Claims Periods. For any date and/or time indications, Coordinated Universal Time (UTC) applies. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. "tmNotice-1.0" is used as an abbreviation for "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "tmNotice" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. 3. Glossary In the following section, the most common terms are briefly Lozano Expires January 24, 2016 [Page 4] Internet-Draft TMCH functional specifications Jul 2015 explained: o Effective allocation: A DN is considered effectively allocated when the DN object for the DN has been created in the SRS of the Registry and has been assigned to the effective user. A DN object in status "pendingCreate" or any other status that precedes the first time a DN is assigned to an end-user is not considered an effective allocation. A DN object created internally by the Registry for subsequent delegation to another Registrant is not considered an effective allocation. o Backend Registry Operator: Entity that manages (a part of) the technical infrastructure for a Registry Operator. The Registry Operator may also be the Backend Registry Operator. o CA: Certificate Authority, see [RFC5280] and [RFC6818] o CSV: Comma-Separated Values, see [RFC4180] o CNIS, Claims Notice Information Service: This service provides TCNs to Registrars. o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818]. o Date and time, datetime: Date and time are specified following the standard "Date and Time on the Internet specification", see [RFC3339]. o DN: Domain Name, domain name, see [RFC1034] o DN Repository Object IDentifier, DNROID: an identifier assigned by the Registry to each DN object that unequivocally identifies said DN object. For example, if a new DN object is created for a name that existed in the past, the DN objects will have different DNROIDs. o DNS: Domain Name System, see [RFC1034] o DNL, Domain Name Label: A label as specified in [RFC1035]. For IDNs the A-Label is used [RFC5890]. o DNL List: A list of DNLs that are covered by a PRM. o EPP: Extensible Provisioning Protocol, see [RFC5730]. Lozano Expires January 24, 2016 [Page 5] Internet-Draft TMCH functional specifications Jul 2015 o FQDN: Fully Qualified Domain Name (e.g. myname.example.com) o HTTP: Hypertext Transfer Protocol, see [RFC2616] o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246]. o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the SMD PKI model. o IDN: Internationalized Domain Name, see [RFC5890] o LORDN, List of Registered Domain Names: This is the list of effectively allocated DNs matching a DNL of a PRM. Registries will upload this list to the TMDB (during the NORDN process). o Lookup Key: A random string of up to 51 chars from the set [a-zA- Z0-9/] to be used as the lookup Key by Registrars to obtain the TCN using the CNIS. Lookup Keys are unique and are related to one DNL only. o NORDN, Notification of Registered Domain Names: The process by which Registries upload their recent LORDN to the TMDB. o PGP: Pretty Good Privacy, see [RFC4880] o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818] o PRM, Pre-registered mark: Mark that has been pre-registered with the TMCH. o Registrant: Person or Organization registering a DN via a Registrar. o Registrar, Domain Name Registrar: Entity that registers DNs with the Registry on behalf of the Registrant. o Registry, Registry Operator, Domain Name Registry: Entity that accepts DN registrations from Registrars, maintains the central Database of Registered DNs. A Registry Operator is the contracting party with ICANN for the TLD. o Qualified Launch Program period, QLP period: During this OPTIONAL period, a special process applies to DNs matching the Sunrise List and/or the DNL List, to ensure a TMH gets informed of a DN matching his PRM. o SMD, Signed Mark Data: A cryptographically signed token issued by the TMV to the TMH to be used in the Sunrise Period to apply for a Lozano Expires January 24, 2016 [Page 6] Internet-Draft TMCH functional specifications Jul 2015 DN that matches a DNL of a PRM; see also [I-D.lozano-tmch-smd] o SMD File: A file containing the SMD (see above) and some human readable data. The latter is usually ignored in the processing of the SMD File. See also Section 6.4. o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining lists of revoked SMDs (SMD Revocation List); see also [I-D.lozano-tmch-smd] o SMD Revocation List: The SMD Revocation List is used by Registries (and optionally by Registrars) during the Sunrise Period to ensure that an SMD is still valid (i.e. not revoked). The SMD Revocation List has a similar function as CRLs used in PKI. o SRS: Shared Registration System, see also [ICANN-GTLD-AGB-20120604]. o Sunrise Period: During this period DNs matching a DNL of a PRM can be exclusively obtained by the respective TMHs. For DNs matching a PRM, a special process applies to ensure a TMH gets informed on the effective allocation of a DN matching his/her PRM. o Sunrise List, SURL: The list of DNLs that are covered by a PRM and eligible for Sunrise. o TLD: Top Level Domain Name, see [RFC1591] o Trademark, mark: Marks are used to claim exclusive properties of products or services. A mark is typically a name, word, phrase, logo, symbol, design, image, or a combination of these elements. For the scope of this document only textual marks are relevant. o Trademark Claims, Claims: Provides information to enhance the understanding of the Trademark rights being claimed by the TMH. o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A Trademark Claims Notice consist of one or more Trademark Claims and are provided to prospective Registrants of DNs. o Trademark Claims Notice Identifier, TCNID: An element of the Trademark Claims Notice (see above), identifying said TCN. The Trademark Claims Notice Identifier is specified in the element . o Trademark Claims Period: During this period, a special process applies to DNs matching the DNL List, to ensure a TMH gets informed of a DN matching his PRM. For DNs matching the DNL List, Lozano Expires January 24, 2016 [Page 7] Internet-Draft TMCH functional specifications Jul 2015 Registrars show a TCN to prospective Registrants that has to be acknowledged before effective allocation of the DN. o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an ICANN central repository for information to be authenticated, stored, and disseminated, pertaining to the rights of TMHs. The Trademark Clearinghouse is split into two functions TMV and TMDB (see below). There could be several entities performing the TMV function, but only one entity performing the TMDB function. o TMDB, Trademark Clearinghouse Database: Serves as a database of the TMCH to provide information to the new gTLD Registries and Registrars to support Sunrise or Claims services. There is only one TMDB in the TMCH that concentrates the information about the "verified" Trademark records from the TMVs. o TMH, Trademark Holder: The person or organization owning rights on a mark. o TMV, Trademark Validator, Trademark validation organization: An entity authorized by ICANN to authenticate and validate registrations in the TMDB ensuring the marks qualify as registered or are court-validated marks or marks that are protected by statute or treaty. This entity would also be asked to ensure that proof of use of marks is provided, which can be demonstrated by furnishing a signed declaration and one specimen of current use. o UTC: Coordinated Universal Time, as maintained by the Bureau International des Poids et Mesures (BIPM); see also [RFC3339]. Lozano Expires January 24, 2016 [Page 8] Internet-Draft TMCH functional specifications Jul 2015 4. Architecture 4.1. Sunrise Period Architecture Sunrise Period SMD hand over (out of band; trivial if Registrant == TMH) ........................................... : : : .'''''''''''''''''''. : : . TMCH . : : ..................... : v . . : .------------. . .-------------. . hv .-----. | Registrant | . | TMV |<------->| TMH | '------------' . '-------------' . vh '-----' | . | ^ \ . | . | | \. tr | . vs | | \ | . | | dv .\ v . v | . \ .-----------. sr . .---. | . \ .->| Registrar |<.........| S | vd | . \ : '-----------' . | M | | . \ : | sy . | D | v . \ : ry | .-----------| M | .---. . vc \ : | | . '---' | T | . \ : v v . | M | . v : .-----------. . | D | . .----------. : | Registry |----------------->| B | . | ICANN-CA | : '-----------' . yd '---' . '----------' : ^ . . | : : | ''''''''''''''''''' | : : | cy | : : cr '---------------------------------------' : :.....................................................: Figure 1 Lozano Expires January 24, 2016 [Page 9] Internet-Draft TMCH functional specifications Jul 2015 4.2. Trademark Claims Period Architecture Trademark Claims Period .'''''''''''''. . TMCH . ............... . . .------------. . .-------. . hv .-----. | Registrant | . | TMV |<------->| TMH | '------------' . '-------' . vh '-----' | . ^ . tr | . | dv . | . vd | . v . v . .-----------. dr . .-------. . | Registrar |<--------| T | . '-----------' . | | . | . | M | . ry | . | | . v . | D | . .----------. dy . | | . | Registry |<------->| B | . '----------' yd . '-------' . . . ''''''''''''' Figure 2 Lozano Expires January 24, 2016 [Page 10] Internet-Draft TMCH functional specifications Jul 2015 4.3. Interfaces In the sub-sections below follows a short description of each interface to provide an overview of the architecture. More detailed descriptions of the relevant interfaces follow further below (Section 5). 4.3.1. hv The TMH registers a mark with a TMV via the hv interface. After the successful registration of the mark, the TMV makes available a SMD (Signed Mark Data) file (see also Section 6.4) to the TMH to be used during the Sunrise Period. The specifics of the hv interface are beyond the scope of this document. 4.3.2. vd After successful mark registration, the TMV ensures the TMDB inserts the corresponding DNLs and mark information into the database via the vd interface. The specifics of the vd interface are beyond the scope of this document. 4.3.3. dy Not used during the Sunrise Period. During the Trademark Claims Period the Registry fetches the latest DNL List from the TMDB via the dy interface in regular intervals. The protocol used on the dy interface is HTTPS. 4.3.4. tr The Registrant communicates with the Registrar via the tr interface. The specifics of the tr interface are beyond the scope of this document. 4.3.5. ry The Registrar communicate with the Registry via the ry interface. The ry interfaces is typically implemented in EPP [RFC5730]. Lozano Expires January 24, 2016 [Page 11] Internet-Draft TMCH functional specifications Jul 2015 4.3.6. dr Not used during the Sunrise Period. During the Trademark Claims Period, the Registrar fetches the TCN from the TMDB (to be displayed to the Registrant via the tr interface) via the dr interface. The protocol used for fetching the TCN is HTTPS [RFC2818]. 4.3.7. yd During the Sunrise period the Registry notifies the TMDB via the yd interface of all DNs effectively allocated. During the Trademark Claims period, the Registry notifies the TMDB via the yd interface of all DNs effectively allocated that matched an entry in the Registry previously downloaded DNL List during the creation of the DN. The protocol used on the yd interface is HTTPS. 4.3.8. dv The TMDB notifies via the dv interface to the TMV of all DNs effectively allocated that match a mark registered by that TMV. The specifics of the dv interface are beyond the scope of this document. 4.3.9. vh The TMV notifies the TMH via the vh interface after a DN has been effectively allocated that matches a PRM of this TMH. The specifics of the vh interface are beyond the scope of this document. 4.3.10. vs The TMV requests to add a revoked SMD to the SMD Revocation List at the SMDM. The specifics of the vs interface are beyond the scope of this document. Not relevant during the Trademark Claims Period. Lozano Expires January 24, 2016 [Page 12] Internet-Draft TMCH functional specifications Jul 2015 4.3.11. sy During the Sunrise Period the Registry fetches the most recent SMD Revocation List from the SMDM via the sy interface in regular intervals. The protocol used on the sy interface is HTTPS. Not relevant during the Trademark Claims Period. 4.3.12. sr During the Sunrise Period the Registrar may fetch the most recent SMD Revocation List from the SMDM via the sr interface. The protocol used on the sr interface is the same as on the sy interface (s. above), i.e. HTTPS. Not relevant during the Trademark Claims Period. 4.3.13. vc The TMV requests to add a revoked TMV certificate to the CRL at the ICANN-CA via the vc interface. The specifics of the vc interface are beyond the scope of this document. Not relevant during the Trademark Claims Period. 4.3.14. cy During the Sunrise Period the Registry fetches the most recent CRL from the ICANN-CA via the cy interface in regular intervals. The CRL is mainly used for validation of TMV certificates. The protocol used on the cy interface is HTTPS [RFC2818]. Not relevant during the Trademark Claims Period. 4.3.15. cr During the Sunrise Period the Registrar may fetch the most recent CRL from the ICANN-CA via the cr interface. The protocol used on the cr interface is the same as on the cy interface. Not relevant during the Trademark Claims Period. Lozano Expires January 24, 2016 [Page 13] Internet-Draft TMCH functional specifications Jul 2015 5. Process Descriptions 5.1. Bootstrapping 5.1.1. Bootstrapping for Registries 5.1.1.1. Credentials Each Registry Operator will receive authentication credentials from the TMDB/SMDM to be used: o During the Sunrise Period to fetch the SMD Revocation List from the SMDM via the sy interface (Section 4.3.11). o During Trademark Claims Period to fetch the DNL List from the TMDB via the dy interface (Section 4.3.3). o During the NORDN process to notify the LORDN to the TMDB via the yd interface (Section 4.3.7). Note: credentials are created per TLD and provided to the Registry Operator. 5.1.1.2. IP Addresses for Access Control Each Registry Operator MUST provide to the TMDB all IP addresses that will be used to: o Fetch the SMD Revocation List via the sy interface (Section 4.3.11). o Fetch the DNL List from the TMDB via the dy interface (Section 4.3.3). o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). This access restriction MAY be applied by the TMDB/SMDM in addition to HTTP Basic access authentication (for credentials to be used, see Section 5.1.1.1). The TMDB/SMDM MAY limit the number of IP addresses to be accepted per Registry Operator. 5.1.1.3. TMCH Trust Anchor Each Registry Operator MUST fetch the X.509 certificate ([RFC5280] / [RFC6818]) of the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to be used: Lozano Expires January 24, 2016 [Page 14] Internet-Draft TMCH functional specifications Jul 2015 o During the Sunrise Period to validate the TMV certificates and the CRL of TMV certificates. 5.1.1.4. TMDB/SMDM PGP Key The TMDB MUST provide each Registry Operator with the public portion of the PGP Key used by TMDB and SMDM, to be used: o During the Sunrise Period to perform integrity checking of the SMD Revocation List fetched from the SMDM via the sy interface (Section 4.3.11). o During Trademark Claims Period to perform integrity checking of the DNL List fetched from the TMDB via the dy interface (Section 4.3.3). Lozano Expires January 24, 2016 [Page 15] Internet-Draft TMCH functional specifications Jul 2015 5.1.2. Bootstrapping for Registrars 5.1.2.1. Credentials Each ICANN-accredited Registrar will receive authentication credentials from the TMDB to be used: o During the Sunrise Period to (optionally) fetch the SMD Revocation List from the SMDM via the sr interface (Section 4.3.12). o During Trademark Claims Period to fetch TCNs from the TMDB via the dr interface (Section 4.3.6). 5.1.2.2. IP Addresses for Access Control Each Registrar MUST provide to the TMDB all IP addresses, which will be used to: o Fetch the SMD Revocation List via the sr interface (Section 4.3.12). o Fetch TCNs via the dr interface (Section 4.3.6). This access restriction MAY be applied by the TMDB/SMDM in addition to HTTP Basic access authentication (for credentials to be used, see Section 5.1.2.1). The TMDB MAY limit the number of IP addresses to be accepted per Registrar. 5.1.2.3. TMCH Trust Anchor Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to be used: o During the Sunrise Period to (optionally) validate the TMV certificates and the CRL of TMV certificates. 5.1.2.4. TMDB PGP Key Registrars MUST receive the public portion of the PGP Key used by TMDB and SMDM from the TMDB administrator to be used: o During the Sunrise Period to (optionally) perform integrity checking of the SMD Revocation List fetched from the SMDM via the sr interface (Section 4.3.12). Lozano Expires January 24, 2016 [Page 16] Internet-Draft TMCH functional specifications Jul 2015 5.2. Sunrise Period 5.2.1. Domain Name Registration Registration during Sunrise Period .------------. .-----------. .----------. | Registrant | | Registrar | | Registry | '------------' '-----------' '----------' ^ | | | | | Request DN | | | | Registration | | | | (with SMD) | | | |------------->| Check DN availability | | | |---------------------------->| | | | | | | DN unava. | DN unavailable .-------------. '---|<-------------|<--------------------( DN available? ) | | no '-------------' | | | yes | | DN available | | |<----------------------------| | | | | | Request DN registration | | | (with SMD) | | |---------------------------->| | | | | | .------------------------------. | | | DN registration validation / | | | | SMD validation | | | '------------------------------' | Registration | | | Error |.-----------. Error .----------------------. |<-------------|| TRY AGAIN |<------( Validation successful? ) | || / ABORT | no '----------------------' | |'-----------' | yes | | | | | DN registered | | DN regist. |<----------------------------| |<-------------| | | | | Figure 3 Note: the figure depicted above represents a synchronous DN registration workflow (usually called first come first served). Lozano Expires January 24, 2016 [Page 17] Internet-Draft TMCH functional specifications Jul 2015 5.2.2. Sunrise DN Registration by Registries Registries MUST perform a minimum set of checks for verifying each DN registration during the Sunrise Period upon reception of a registration request over the ry interface (Section 4.3.5). If any of these checks fails the Registry MUST abort the registration. Each of these checks MUST be performed before the DN is effectively allocated. In case of asynchronous registrations (e.g. auctions), the minimum set of checks MAY be performed when creating the intermediate object (e.g. a DN application) used for DN registration. If the minimum set of checks is performed when creating the intermediate object (e.g. a DN application) a Registry MAY effective allocate the DN without performing the minimum set of checks again. Performing the minimum set of checks Registries MUST verify that: 1. A SMD has been received from the Registrar along with the DN registration. 2. The certificate of the TMV has been correctly signed by the ICANN-CA. (The certificate of the TMV is contained within the SMD.) 3. The time when the validation is done is within the validity period of the TMV certificate. 4. The certificate of the TMV is not be listed in the CRL file specified in the CRL distribution point of the TMV certificate. 5. The signature of the SMD (signed with the TMV certificate) is valid. 6. The time when the validation is done is within the validity period of the SMD based on and elements. 7. The SMD has not been revoked, i.e., is not contained in the SMD Revocation List. 8. The leftmost DNL (A-label in case of IDNs) of the DN being effectively allocated matches one of the labels () elements in the SMD. These procedure apply to all DN effective allocations at the second level as well as to all other levels subordinate to the TLD that the Registry accepts registrations for. Lozano Expires January 24, 2016 [Page 18] Internet-Draft TMCH functional specifications Jul 2015 5.2.3. TMDB Sunrise Services for Registries 5.2.3.1. SMD Revocation List A new SMD Revocation List MUST be published by the SMDM twice a day, by 00:00:00 and 12:00:00 UTC. Registries MUST refresh the latest version of the SMD Revocation List at least once every 24 hours. Note: the SMD Revocation List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the SMD Revocation List once every 24 hours, the SMD Revocation List could be used for all the TLDs managed by the Backend Registry Operator. Update SMD Revocation List .----------. .------. | Registry | | SMDM | '----------' '------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |----------------------------------------------------->| | Download latest revocation list for SMD certificates | |<-----------------------------------------------------| | | | | Figure 4 Lozano Expires January 24, 2016 [Page 19] Internet-Draft TMCH functional specifications Jul 2015 5.2.3.2. Certificate Revocation List Registries MUST refresh their local copy of the CRL at least every 24 hours using the CRL distribution point specified in the TMV certificate. Operationally, the CRL file and CRL distribution point is the same for all TMVs and (at publication of this document) located at < http://crl.icann.org/tmch.crl >. Note: the CRL file will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the CRL file once every 24 hours, the CRL file could be used for all the TLDs managed by the Backend Registry Operator. Update CRL for TMV certificates .----------. .----------. | Registry | | ICANN-CA | '----------' '----------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |------------------------------------------->| | Download latest CRL for TMV certificates | |<-------------------------------------------| | | | | Figure 5 Lozano Expires January 24, 2016 [Page 20] Internet-Draft TMCH functional specifications Jul 2015 5.2.3.3. Notice of Registered Domain Names The Registry MUST send a LORDN file containing DNs effectively allocated to the TMDB (over the yd interface, Section 4.3.7). The effective allocation of a DN MUST be reported by the Registry to the TMDB within 26 hours of the effective allocation of such DN. The Registry MUST create and upload a LORDN file in case there are effective allocations in the SRS, that have not been successfully reported to the TMDB in a previous LORDN file. Based on the timers used by TMVs and the TMDB, the RECOMMENDED maximum frequency to upload LORDN files from the Registries to the TMDB is every 3 hours. It is RECOMMENDED that Registries try to upload at least two LORDN files per day to the TMDB with enough time in between, in order to have time to fix problems reported in the LORDN file. The Registry SHOULD upload a LORDN file only when the previous LORDN file has been processed by the TMDB and the related LORDN Log file has been downloaded and processed by the Registry. The Registry MUST upload LORDN files for DNs effectively allocated during the Sunrise or Claims period (same applies to DNs effectively allocated using applications created during the Sunrise or Claims period in case of using asynchronous registrations). The yd interface (Section 4.3.7) MUST support at least 1 and MAY support up to 10 concurrent connections from each IP address registered by a Registry Operator to access the service. The TMDB MUST process each uploaded LORDN file and make the related log file available for Registry download within 30 minutes of the finalization of the upload. Lozano Expires January 24, 2016 [Page 21] Internet-Draft TMCH functional specifications Jul 2015 NORDN .----------. .------. .-----. .-----. | Registry | | TMDB | | TMV | | TMH | '----------' '------' '-----' '-----' | | | | .------------------. | | | | Periodically | | | | | upload LORDN | | | | | file | | | | '------------------' | | | | | | | .--------->| Upload LORDN | | | | |-------------------->| | | | | | | | | | .-------------------------. | | | | | Verify each domain name | | | | | | in the uploaded file | | | | | | (within 30') | | | | | '-------------------------' | | | | | ._____. | | | | Download Log file | | END | | | | |<--------------------| '-----' | | | | | ^ | | | .-----------------. .---------------. | | | | | Check whether | / everything fine \ no | | | | | Log file | ( (i.e. no errors )---' | | | | contains errors | \ in Log file )? / | | | '-----------------' '---------------' | | | | | yes | | | .---------------. | | | | / everything fine \ yes | | | |( (i.e. no errors )-----. | Notify TMVs | | | \ in Log file )? / | | on the LORDN | | | '---------------' | | pre-registered | | | | no v | with said TMV | | | .----------------. .------. |--------------->| | '-| Correct Errors | | DONE | | | | '----------------' '------' | | Notify each | | | | affected TMH | | | |------------->| | | | | Figure 6 The format used for the LORDN is described in Section 6.3 Lozano Expires January 24, 2016 [Page 22] Internet-Draft TMCH functional specifications Jul 2015 5.2.4. Sunrise DN registration by Registrars Registrars MAY choose to perform the checks for verifying DN registrations as performed by the Registries (see Section 5.2.2) before sending the command to register a DN. Lozano Expires January 24, 2016 [Page 23] Internet-Draft TMCH functional specifications Jul 2015 5.2.5. TMDB Sunrise Services for Registrars The processes described in Section 5.2.3.1 and Section 5.2.3.2 are also available for Registrars to optionally validate the SMDs received. Lozano Expires January 24, 2016 [Page 24] Internet-Draft TMCH functional specifications Jul 2015 5.3. Trademark Claims Period 5.3.1. Domain Registration Registration during Trademark Claims Period .------------. .-----------. .----------. .------. | Registrant | | Registrar | | Registry | | TMDB | '------------' '-----------' '----------' '------' ^ | Request DN | | | | | Registration | Check DN availability | | | |------------->|---------------------------->| | | | DN unava. | DN unavailable .-------------. | '---|<-------------|<--------------------( DN available? ) | | | no '-------------' | | | | yes | | | DN available | | | |<----------------------------| | | | Request Lookup key | | | |---------------------------->| | | | .---------. | | |.----------. / Does DN \ | | || CONTINUE |<---------( match DNL ) | | || NORMALLY | no \ of PRM? / | | |'----------' '---------' | | | | yes | | | Lookup key | | | |<----------------------------| | | | Request Claims Notice | | Display |----------------------------------------->| | Claims | | | Notice | Return Claims Notice | |<-------------|<-----------------------------------------| | | | .------. yes | Register DN (TCNID included) | ( Ack? )--------->|---------------------------->| | '------' | | | ||no | Error .----------------------. | || .-------. |<--------------( Validation successful? ) | |'->| ABORT | | no '----------------------' | | '-------' | | yes | | DN regist. | DN registered | | |<-------------|<----------------------------| | | | | | Figure 7 Lozano Expires January 24, 2016 [Page 25] Internet-Draft TMCH functional specifications Jul 2015 Note: the figure depicted above represents a synchronous DN registration workflow (usually called first come first served). Lozano Expires January 24, 2016 [Page 26] Internet-Draft TMCH functional specifications Jul 2015 5.3.2. Trademark Claims DN registration by Registries During Trademark Claim Periods, Registries perform two main functions: o Registries MUST provide Registrars (over the ry interface, Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs that match the DNL List. o Registries MUST provide the Lookup Key only when queried about a specific DN. o For each DN matching a DNL of a PRM, Registries MUST perform a minimum set of checks for verifying DN registrations during Trademark Claims Period upon reception of a registration request over the ry interface (Section 4.3.5). If any of these checks fails the Registry MUST abort the registration. Each of these checks MUST be performed before the DN is effectively allocated. o In case of asynchronous registrations (e.g. auctions), the minimum set of checks MAY be performed when creating the intermediate object (e.g. a DN application) used for DN effective allocation. If the minimum set of checks is performed when creating the intermediate object (e.g. a DN application) a Registry MAY effective allocate the DN without performing the minimum set of checks again. o Performing the minimum set of checks Registries MUST verify that: 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been received from the Registrar along with the DN registration. If the three elements mentioned above are not provided by the Registrar for a DN matching a DNL of a PRM, but the DNL was inserted (or re-inserted) for the first time into DNL List less than 24 hours ago, the registration MAY continue without this data and the tests listed below are not required to be performed. 2. The TCN has not expired (according to the expiration datetime sent by the Registrar). 3. The acceptance datetime is no more than 48 hours in the past. 4. Using the leftmost DNL (A-label in the case of IDNs) of the DN being registered, the expiration datetime provided by the registrar, and the TMDB Notice Identifier extracted from the Lozano Expires January 24, 2016 [Page 27] Internet-Draft TMCH functional specifications Jul 2015 TCNID provided by the registrar compute the TCN Checksum. Verify that the computed TCN Checksum match the TCN Checksum present in the TCNID. These procedures apply to all DN registrations at the second level as well as to all other levels subordinate to the TLD that the Registry accepts registrations for. Lozano Expires January 24, 2016 [Page 28] Internet-Draft TMCH functional specifications Jul 2015 5.3.3. TMBD Claims Services for Registries 5.3.3.1. Domain Name Label (DNL) List A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC. Registries MUST refresh the latest version of the DNL List at least once every 24 hours. Update DNL List .----------. .------. | Registry | | TMDB | '----------' '------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |-------------------------------->| | Download latest list of DNLs | |<--------------------------------| | | | | Figure 8 Note: the DNL List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the DNL List once every 24 hours, the DNL List could be used for all the TLDs managed by the Backend Registry Operator. Lozano Expires January 24, 2016 [Page 29] Internet-Draft TMCH functional specifications Jul 2015 5.3.3.2. Notice of Registered Domain Names The NORDN process during the Trademark Claims Period is almost the same as during Sunrise Period as defined in Section 5.2.3.3 with the difference that only registrations subject to a Trademark Claim (i.e., at registration time the name appeared in the current DNL List downloaded by the Registry Operator) are included in the LORDN. Lozano Expires January 24, 2016 [Page 30] Internet-Draft TMCH functional specifications Jul 2015 5.3.4. Trademark Claims DN Registration by Registrars For each DN matching a DNL of a PRM, Registrars MUST perform the following steps: 1. Use the Lookup Key received from the Registry to obtain the TCN from the TMDB using the dr interface (Section 4.3.6) Registrars MUST only query for the Lookup Key of a DN that is available for registration. 2. Present the TCN to the Registrant as described in [ICANN-GTLD-AGB-20120604]. 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST consent with the TCN, before any further processing. (The transmission of a TCNID to the Registry over the ry interface, Section 4.3.5 implies that the Registrant has expressed his consent with the TCN.) 4. Perform the minimum set of checks for verifying DN registrations. If any of these checks fails the Registrar MUST abort the DN registration. Each of these checks MUST be performed before the registration is sent to the Registry. Performing the minimum set of checks Registrars MUST verify that: 1. The time when the validation is done is within the TCN validity based on the and elements. 2. The leftmost DNL (A-label in case of IDNs) of the DN being effectively allocated matches the label () element in the TCN. 3. The Registrant has acknowledged (expressed his consent with) the TCN. 5. Record the date and time when the registrant acknowledged the TCN. 6. Send the registration to the Registry (ry interface, Section 4.3.5) and include the following information: * TCNID () * Expiration date of the TCN () * Acceptance datetime of the TCN. Lozano Expires January 24, 2016 [Page 31] Internet-Draft TMCH functional specifications Jul 2015 TCN are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours in the future by the TMDB, allowing the implementation of a cache by Registrars and enough time for acknowledging the TCN. Registrars SHOULD implement a cache of TCNs to minimize the number of queries sent to the TMDB. A cached TCN MUST be removed from the cache after the expiration date of the TCN as defined by . The TMDB MAY implement rate- limiting as one of the protection mechanisms to mitigate the risk of performance degradation. Lozano Expires January 24, 2016 [Page 32] Internet-Draft TMCH functional specifications Jul 2015 5.3.5. TMBD Claims Services for Registrars 5.3.5.1. Claims Notice Information Service The TCNs are provided by the TMDB online and are fetched by the Registrar via the dr interface (Section 4.3.6). To get access to the TCNs, the Registrar needs the credentials provided by the TMDB (Section 5.1.2.1) and the Lookup Key received from the Registry via the ry interface (Section 4.3.5). The dr interface (Section 4.3.6) uses HTTPS with Basic access authentication. The dr interface (Section 4.3.6) MAY support up to 10 concurrent connections from each Registrar. The URL of the dr interface (Section 4.3.6) is: < https:///cnis/.xml > Note that the "lookupkey" may contain SLASH characters ("/"). The SLASH character is part of the URL path and MUST NOT be escaped when requesting the TCN. The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) MUST be signed by a well-know public CA. Registrars MUST perform the Certification Path Validation described in Section 6 of [RFC5280]. Registrars will be authenticated in the dr interface using HTTP Basic access authentication. The dr (Section 4.3.6) interface MUST support HTTPS keep-alive and MUST maintain the connection for up to 30 minutes. Lozano Expires January 24, 2016 [Page 33] Internet-Draft TMCH functional specifications Jul 2015 5.4. Qualified Launch Program Period 5.4.1. Domain Registration During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program (QLP) period effective allocations of DNs to third parties could require that Registries and Registrars provide Sunrise and/or Claims services. If required, Registries and Registrars MUST provide Sunrise and/or Claims services as described in: Section 5.2 and Section 5.3. The effective allocation scenarios are: o If the leftmost DNL (A-label in case of IDNs) of the DN being effectively allocated (QLP Name in this section) matches a DNL in the SURL, and an SMD is provided, then Registries MUST provide Sunrise Services (see Section 5.2) and the DN MUST be reported in a Sunrise LORDN file during the QLP period. o If the QLP Name matches a DNL in the SURL but does not match a DNL in the DNL List, and an SMD is NOT provided (see section 2.2 of [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP period. o If the QLP Name matches a DNL in the SURL and also matches a DNL in the DNL List, and an SMD is NOT provided (see section 2.2 of [QLP-Addendum]), then Registries MUST provide Claims services (see Section 5.3) and the DN MUST be reported in a Claims LORDN file during the QLP period. o If the QLP Name matches a DNL in the DNL List but does not match a DNL in the SURL, then Registries MUST provide Claims services (see Section 5.2) and the DN MUST be reported in a Claims LORDN file during the QLP period. Lozano Expires January 24, 2016 [Page 34] Internet-Draft TMCH functional specifications Jul 2015 The following table lists all the effective allocation scenarios during a QLP Period: +--------+---------+-----------------+-------------+----------------+ | QLP | QLP | SMD was | Registry | Registry MUST | | Name | Name | provided by the | MUST | report DN | | match | match | potential | provide | registration | | in the | in the | Registrant | Sunrise or | in | | SURL | DNL | | Claims | LORDN file | | | List | | Services | | +--------+---------+-----------------+-------------+----------------+ | Y | Y | Y | Sunrise | Sunrise | | | | | | | | Y | N | Y | Sunrise | Sunrise | | | | | | | | N | Y | -- | Claims | Claims | | | | | | | | N | N | -- | -- | -- | | | | | | | | Y | Y | N (see section | Claims | Claims | | | | 2.2 of | | | | | | [QLP-Addendum]) | | | | | | | | | | Y | N | N (see section | -- | Sunrise (using | | | | 2.2 of | | special | | | | [QLP-Addendum]) | | SMD-id) | +--------+---------+-----------------+-------------+----------------+ QLP Effective Allocation Scenarios The TMDB MUST provide the following services to Registries during a QLP period: o SMD Revocation List (see Section 5.2.3.1) o Notice of Registered Domain Names (see Section 5.2.3.3) o Domain Name Label List (see Section 5.3.3.1) o Sunrise List (see Section 5.4.2.1 The TMDB MUST provide the following services to Registrars during a QLP period: o SMD Revocation List (see Section 5.2.3.1) o Claims Notice Information Service (see Section 5.3.5.1) Lozano Expires January 24, 2016 [Page 35] Internet-Draft TMCH functional specifications Jul 2015 5.4.2. TMBD QLP Services for Registries 5.4.2.1. Sunrise List (SURL) A new Sunrise List MUST be published by the TMDB twice a day, by 00: 00:00 and 12:00:00 UTC. Registries offering the OPTIONAL QLP period MUST refresh the latest version of the Sunrise List at least once every 24 hours. Update Sunrise List .----------. .------. | Registry | | TMDB | '----------' '------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |-------------------------------->| | Download latest list of DNLs | |<--------------------------------| | | | | Figure 9 Note: the Sunrise List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the Sunrise List once every 24 hours, the Sunrise List could be used for all the TLDs managed by the Backend Registry Operator. Lozano Expires January 24, 2016 [Page 36] Internet-Draft TMCH functional specifications Jul 2015 6. Data Format Descriptions 6.1. DNL List file This section defines the format of the list containing every Domain Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list is maintained by the TMDB and downloaded by Registries in regular intervals (see Section 5.3.3.1). The Registries use the DNL List during the Trademark Claims period to check whether a requested DN matches a DNL of a PRM. The DNL List contains all the DNLs covered by a PRM present in the TMDB at the time it is generated. The DNL List is contained in a CSV-like formatted file that has the following structure: o first line: , Where: + , version of the file, this field MUST be 1. + , date and time in UTC that the DNL List was created. o second line: a header line as specified in [RFC4180] With the header names as follows: DNL,lookup-key,insertion-datetime o One or more lines with: ,, Where: + , a Domain Name Label covered by a PRM. + , lookup key that the Registry MUST provide to the Registrar. The lookup key has the following format:
////, where: - YYYY: year that the TCN was generated. - MM: zero-padded month that the TCN was generated. Lozano Expires January 24, 2016 [Page 37] Internet-Draft TMCH functional specifications Jul 2015 - DD: zero-padded day that the TCN was generated. - vv: version of the TCN, possible values are 00 and 01. - X: one hexadecimal digit [0-9A-F]. This is the first, second and third hexadecimal digit of encoding the in base16 as specified in [RFC4648]. - Random bits: 144 random bits encoded in base64url as specified in [RFC4648]. - Sequential number: zero-padded natural number in the range 0000000001 to 2147483647. + , datetime in UTC that the DNL was first inserted into the DNL List. The possible two values of time for inserting a DNL to the DNL List are 00:00:00 and 12:00:00 UTC. Example for DNL List 1,2012-08-16T00:00:00.0Z DNL,lookup-key,insertion-datetime example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 2010-07-14T00:00:00.0Z another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 2012-08-16T00:00:00.0Z anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 2011-08-16T12:00:00.0Z Figure 10 To provide authentication and integrity protection, the DNL List will be PGP [RFC4880] signed by the TMDB with the private key of the TMDB (see also Section 5.1.1.4). The PGP signature of the DNL List can be found in the similar URI but with extension .sig as shown below. The URL of the dy interface (Section 4.3.3) is: o < https:///dnl/dnl-latest.csv > o < https:///dnl/dnl-latest.sig > Lozano Expires January 24, 2016 [Page 38] Internet-Draft TMCH functional specifications Jul 2015 6.2. SMD Revocation List This section defines the format of the list of SMDs that have been revoked. The list is maintained by the SMDM and downloaded by Registries (and optionally by Registrars) in regular intervals (see Section 5.2.3.1). The SMD Revocation List is used during the Sunrise Period to validate SMDs received. The SMD Revocation List has a similar function as CRLs used in PKI [RFC5280] / [RFC6818]. The SMD Revocation List contains all the revoked SMDs present in the TMDB at the time it is generated. The SMD Revocation List is contained in a CSV-like formatted file that has the following structure: o first line: , Where: + , version of the file, this field MUST be 1. + , datetime in UTC that the SMD Revocation List was created. o second line: a header line as specified in [RFC4180] With the header names as follows: smd-id,insertion-datetime o One or more lines with: , Where: + , identifier of the SMD that was revoked. + , revocation datetime in UTC of the SMD. The possible two values of time for inserting an SMD to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. To provide integrity protection, the SMD Revocation List is PGP [RFC4880] signed by the TMDB with the private key of the TMDB (see also Section 5.1.1.4). The SMD Revocation List is provided by the TMDB with extension .csv. The PGP signature of the SMD Revocation List can be found in the similar URI but with extension .sig as shown below. The URL of the sr interface (Section 4.3.12) and sy interface Lozano Expires January 24, 2016 [Page 39] Internet-Draft TMCH functional specifications Jul 2015 (Section 4.3.11) is: o < https:///smdrl/smdrl-latest.csv > o < https:///smdrl/smdrl-latest.sig > Example for SMD Revocation list 1,2012-08-16T00:00:00.0Z smd-id,insertion-datetime 2-2,2012-08-15T00:00:00.0Z 3-2,2012-08-15T00:00:00.0Z 1-2,2012-08-15T00:00:00.0Z Figure 11 Lozano Expires January 24, 2016 [Page 40] Internet-Draft TMCH functional specifications Jul 2015 6.3. LORDN File This section defines the format of the List of Registered Domain Names (LORDN), which is maintained by each Registry and uploaded at least daily to the TMDB. Every time a DN matching a DNL of a PRM said DN is added to the LORDN along with further information related to its registration. The URIs of the yd interface (Section 4.3.7) used to upload the LORDN file is: o Sunrise LORDN file: < https:///LORDN//sunrise > o Claims LORDN file: < https:///LORDN//claims > During a QLP period, Registries MAY be required to upload Sunrise or Claims LORDN files. The URIs of the yd interface used to upload LORDN files during a QLP period is: o Sunrise LORDN file (during QLP period): < https:///LORDN//sunrise/qlp > o Claims LORDN file (during a QLP period): < https:///LORDN//claims/qlp > The yd interface (Section 4.3.7) returns the following HTTP status codes after a HTTP POST request method is received: o The interface provides a HTTP/202 status code if the interface was able to receive the LORDN file and the syntax of the LORDN file is correct. The interface provides the LORDN Transaction Identifier in the HTTP Entity-body that would be used by the Registry to download the LORDN Log file. The LORDN Transaction Identifier is a natural number zero-padded in the range 0000000000000000001 to 9223372036854775807. The TMDB uses the element of the LORDN file as a unique client-side identifier. If a LORDN file with the same of a previously sent LORDN file is received by the TMDB, the LORDN Transaction Lozano Expires January 24, 2016 [Page 41] Internet-Draft TMCH functional specifications Jul 2015 Identifier of the previously sent LORDN file MUST be provided to the Registry. The TMDB MUST ignore the DN Lines present in the LORDN file if a LORDN file with the same was previously sent. The HTTP Location header field contains the URI where the LORDN Log file could be retrieved later, for example: 202 Accepted Location: https:///LORDN/example/sunrise/ 0000000000000000001/result o The interface provides a HTTP/400 if the request is incorrect or the syntax of the LORDN file is incorrect. The TMDB MUST return a human readable message in the HTTP Entity-body regarding the incorrect syntax of the LORDN file. o The interface provides a HTTP/401 status code if the credentials provided does not authorize the Registry Operator to upload a LORDN file. o The TMDB MUST return a HTTP/404 status code when trying to upload a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP period plus 26 hours. o The interface provides a HTTP/500 status code if the system is experiencing a general failure. For example, to upload the Sunrise LORDN file for TLD "example", the URI would be: < https:///LORDN/example/sunrise > The LORDN is contained in a CSV-like formatted file that has the following structure: o For Sunrise Period: * first line: ,, Where: - , version of the file, this field MUST be 1. Lozano Expires January 24, 2016 [Page 42] Internet-Draft TMCH functional specifications Jul 2015 - , date and time in UTC that the LORDN was created. - , number of DN Lines present in the LORDN file. * second line: a header line as specified in [RFC4180] With the header names as follows: roid,domain-name,SMD-id,registrar-id,registration- datetime,application-datetime * One or more lines with: ,,,,, Where: - , DN Repository Object IDentifier (DNROID) in the SRS. - , DN that was effectively allocated. For IDNs the A-Label is used [RFC5890] - , SMD ID used for registration. - , IANA Registrar ID. - , date and time in UTC that the domain was effectively allocated. - OPTIONAL , date and time in UTC that the application was created. The MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions). Lozano Expires January 24, 2016 [Page 43] Internet-Draft TMCH functional specifications Jul 2015 Example for LORDN during Sunrise 1,2012-08-16T00:00:00.0Z,3 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ application-datetime SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 2012-07-15T00:50:00.0Z EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z Figure 12 o For Trademark Claims Period: * first line: ,, Where: - , version of the file, this field MUST be 1. - , date and time in UTC that the LORDN was created. - , number of DN Lines present in the LORDN file. * second line: a header line as specified in [RFC4180] With the header names as follows: roid,domain-name,notice-id,registrar-id,registration- datetime,ack-datetime,application-datetime * One or more lines with: ,,,,,, Where: - , DN Repository Object IDentifier (DNROID) in the SRS. - , DN that was effectively allocated. For IDNs the A-Label is used [RFC5890]. Lozano Expires January 24, 2016 [Page 44] Internet-Draft TMCH functional specifications Jul 2015 - , Trademark Claims Notice Identifier as specified in . - , IANA Registrar ID. - , date and time in UTC that the domain was effectively allocated. - , date and time in UTC that the TCN was acknowledged. - OPTIONAL , date and time in UTC that the application was created. The MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions). For a DN matching a DNL of a PRM at the moment of registration, created without the TCNID, expiration datetime and acceptance datetime, because DNL was inserted (or re- inserted) for the first time into DNL List less than 24 hours ago, the string "recent-dnl-insertion" MAY be specified in and . Example for LORDN during Claims 1,2012-08-16T00:00:00.0Z,3 roid,domain-name,notice-id,registrar-id,registration-datetime,\ ack-datetime,application-datetime SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z HB800-REP,example3.gtld,recent-dnl-insertion,\ 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion Figure 13 Lozano Expires January 24, 2016 [Page 45] Internet-Draft TMCH functional specifications Jul 2015 6.3.1. LORDN Log File After reception of the LORDN file, the TMDB verifies its content for syntactical and semantical correctness. The output of the LORDN file verification is retrieved using the yd interface (Section 4.3.7). The URI of the yd interface (Section 4.3.7) used to retrieve the LORDN Log File is: o Sunrise LORDN Log file: < https:///LORDN//sunrise/ /result > o Claims LORDN Log file: < https:///LORDN//claims/ /result > A Registry Operator MUST NOT send more than one request per minute per TLD to download a LORDN Log file. The yd interface (Section 4.3.7) returns the following HTTP status codes after a HTTP GET request method is received: o The interface provides a HTTP/200 status code if the interface was able to provide the LORDN Log file. The LORDN Log file is contained in the HTTP Entity-body. o The interface provides a HTTP/204 status code if the LORDN Transaction Identifier is correct, but the server has not finalized processing the LORDN file. o The interface provides a HTTP/400 status code if the request is incorrect. o The interface provides a HTTP/401 status code if the credentials provided does not authorize the Registry Operator to download the LORDN Log file. o The interface provides a HTTP/404 status code if the LORDN Transaction Identifier is incorrect. o The interface provides a HTTP/500 status code if the system is experiencing a general failure. For example, to obtain the LORDN Log File in case of a Sunrise LORDN file with LORDN Transaction Identifier 0000000000000000001 and TLD Lozano Expires January 24, 2016 [Page 46] Internet-Draft TMCH functional specifications Jul 2015 "example" the URI would be: < https:///LORDN/example/sunrise/ 0000000000000000001/result > The LORDN Log file is contained in a CSV-like formatted file that has the following structure: o first line: ,,,,,, Where: + , version of the file, this field MUST be 1. + , date and time in UTC that the LORDN Log was created. + , date and time in UTC of creation for the LORDN file that this log file is referring to. + , unique identifier of the LORDN Log provided by the TMDB. This identifier could be used by the Registry Operator to unequivocally identify the LORDN Log. The identified will be a string of a maximum LENGTH of 60 characters from the Base 64 alphabet. + , whether the LORDN file has been accepted for processing by the TMDB. Possible values are "accepted" or "rejected". + , whether the LORDN Log has any warning result codes. Possible values are "no-warnings" or "warnings- present". + , number of DNs effective allocations processed in the LORDN file. A Registry Operator is NOT REQUIRED to process a LORDN Log with a ="accepted" and ="no-warnings". o second line: a header line as specified in [RFC4180] With the header names as follows: Lozano Expires January 24, 2016 [Page 47] Internet-Draft TMCH functional specifications Jul 2015 roid,result-code o One or more lines with: , Where: + , DN Repository Object IDentifier (DNROID) in the SRS. + , result code as described in Section 6.3.1.1. Example for LORDN Log file 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ accepted,no-warnings,1 roid,result-code SH8013-REP,2000 Figure 14 Lozano Expires January 24, 2016 [Page 48] Internet-Draft TMCH functional specifications Jul 2015 6.3.1.1. LORDN Log Result Codes In Figure 15 the classes of result codes (rc) are listed. Those classes in square brackets are not used at this time, but may come into use at some later stage. The first two digits of a result code denote the result code class, which defines the outcome at the TMDB: o ok: Success, DN Line accepted by the TMDB. o warn: a warning is issued, DN Line accepted by the TMDB. o err: an error is issued, LORDN file rejected by the TMDB. In case that after processing a DN Line, the error result code is 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the TMDB. If the LORDN file is rejected, DN Lines that are syntactically valid will be reported with a 2001 result code. A 2001 result code means that the DN Line is syntactically valid, however the DN Line was not processed because the LORDN file was rejected. All DNs reported in a rejected LORDN file MUST be reported again by the Registry because none of the DN Lines present in the LORDN file have been processed by the TMDB. LORDN Log Result Code Classes code Class outcome ---- ----- ------- 20xx Success ok 35xx [ DN Line syntax warning ] warn 36xx DN Line semantic warning warn 45xx DN Line syntax error err 46xx DN Line semantic error err Figure 15 In the following, the LORDN Log result codes used by the TMDB are described: LORDN Log result Codes rc Short Description Long Description Lozano Expires January 24, 2016 [Page 49] Internet-Draft TMCH functional specifications Jul 2015 ---- ------------------------------------------------------------- 2000 OK DN Line successfully processed. 2001 OK but not processed DN Line is syntactically correct but was not processed because the LORDN file was rejected. 3601 TCN Acceptance Date after Registration Date TCN Acceptance Date in DN Line is newer than the Registration Date. 3602 Duplicate DN Line This DN Line is an exact duplicate of another DN Line in same file, DN Line ignored. 3603 DNROID Notified Earlier Same DNROID has been notified earlier, DN Line ignored. 3604 TCN Checksum invalid Based on the DN effectively allocated, the TCNID and the expiration date of the linked TCN, the TCN Checksum is invalid. 3605 TCN Expired The TCN was already expired (based on the field of the TCN) at the time of acknowledgement. 3606 Wrong TCNID used The TCNID used for the registration does not match the related DN. 3609 Invalid SMD used The SMD used for registration was not valid at the moment of registration based on the and elements. In case of an asynchronous registration, this refer to the . 3610 DN reported outside of the time window The DN was reported outside of the required 26 hours reporting window. 3611 DN does not match the labels in SMD The DN does not match the labels included in the SMD. 3612 SMDID does not exist Lozano Expires January 24, 2016 [Page 50] Internet-Draft TMCH functional specifications Jul 2015 The SMDID has never existed in the central repository. 3613 SMD was revoked when used The SMD used for registration was revoked more than 24 hours ago of the . In case of an asynchronous registration, the is used when validating the DN Line. 3614 TCNID does not exist The TCNID has never existed in the central repository. 3615 Recent-dnl-insertion outside of the time window The DN registration is reported as a recent-dnl-insertion, but the (re) insertion into the DNL ocurred more than 24 hours ago. 3616 Registration Date of DN in claims before the end of Sunrise The registration date of the DN is before the end of Sunrise and the DN was reported in a claims LORDN file. 3617 Registrar has not been approved by the TMDB Registrar ID in DN Line has not completed Claims integration testing with the TMDB. 3618 Registration Date of DN in a QLP LORDN file outside of the QLP period The registration date of the DN in a QLP LORDN file is outside of the QLP period. 3619 TCN was not valid The TCN was not valid (based on the field of the TCN) at the time of acknowledgement. 4501 Syntax Error in DN Line Syntax Error in DN Line. 4601 Invalid TLD used The TLD in the DN Line does not match what is expected for this LORDN. 4602 Registrar ID Invalid Registrar ID in DN Line is not a valid ICANN-Accredited Registrar. 4603 Registration Date in the future The in the DN Line is in the future. Lozano Expires January 24, 2016 [Page 51] Internet-Draft TMCH functional specifications Jul 2015 4606 TLD not in Sunrise or Claims The was reported when the TLD was not in Sunrise or Claims. In case of an asynchronous registration, the is used when validating the DN Line. 4607 Application Date in the future The in the DN Line is in the future. 4608 Application Date is later than Registration Date The in the DN Line is later than the . 4609 TCNID wrong syntax The syntax of the TCNID is invalid. 4610 TCN Acceptance Date is in the future The is in the future. 4611 Label has never existed in the TMDB The label in the registered DN has never existed in the TMDB. Figure 16 Lozano Expires January 24, 2016 [Page 52] Internet-Draft TMCH functional specifications Jul 2015 6.4. SMD File This section defines the format of the SMD File. After a successful registration of a mark, the TMV returns an SMD File to the TMH. The SMD File can then be used for registration of one or more DNs covered by the PRM during the Sunrise Period of a TLD. Two encapsulation boundaries are defined for delimiting the encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" and "-----END ENCODED SMD-----". Only data inside the encapsulation boundaries MUST be used by Registries and Registrars for validation purposes, i.e. any data outside these boundaries as well as the boundaries themselves MUST be ignored for validation purposes. The structure of the SMD File is as follows: o Marks: o smdID: o U-labels: o notBefore: o notAfter: o -----BEGIN ENCODED SMD----- o o -----END ENCODED SMD----- Lozano Expires January 24, 2016 [Page 53] Internet-Draft TMCH functional specifications Jul 2015 Example for SMD File (shortened at [...]): Marks: Example One smdID: 1-2 U-labels: example-one, exampleone notBefore: 2011-08-16 09:00 notAfter: 2012-08-16 09:00 -----BEGIN ENCODED SMD----- PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+ CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4 YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4 [...] UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0 dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= -----END ENCODED SMD----- Figure 17 Lozano Expires January 24, 2016 [Page 54] Internet-Draft TMCH functional specifications Jul 2015 6.5. Trademark Claims Notice The TMDB MUST provide the TCN to Registrars in XML format as specified below. An enclosing element that describes the Trademark Notice to a given label. The child elements of the element include: o A element that contains the unique identifier of the Trademark Notice. This element contains the the TCNID. The TCNID is a string concatenation of a TCN Checksum and the TMDB Notice Identifier. The first 8 characters of the TCNID is a TCN Checksum. The rest is the TMDB Notice Identifier, which is a zero-padded natural number in the range of 0000000000000000001 to 9223372036854775807. Example of a TCNID: 370d0b7c9223372036854775807. Where: + TCN Checksum=370d0b7c + TMDB Notice Identifier=9223372036854775807 The TCN Checksum is a 8 characters long Base16 encoded output of computing the CRC32 of the string concatenation of: label + unix_timestamp() + TMDB Notice Identifier TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is defined as the number of seconds that have elapsed since 1970- 01-01T00:00:00Z not counting leap seconds. For example, the conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: unix_time(2010-08-16T09:00:00.0Z)=1281949200 The TMDB uses the and elements from the TCN along with the TMDB Notice Identifier to compute the TCN Checksum. A Registry MUST use the leftmost DNL (A-label in case of IDNs) of the DN being registered, the expiration datetime of the TCN (provided by the Registrar) and the TMDB Notice Identifier Lozano Expires January 24, 2016 [Page 55] Internet-Draft TMCH functional specifications Jul 2015 extracted from the TCNID (provided by the Registrar) to compute the TCN Checksum. For example the DN "foo.bar.example" being effectively allocated, the left most label would be "foo". Example of computation of the TCN Checksum: CRC32(example-one12819492009223372036854775807)=370d0b7c o A element that contains the start of the validity date and time of the TCN. o A element that contains the expiration date and time of the TCN. o A elements that contain the DNL (A-label in case of IDNs) form of the label that correspond to the DN covered by a PRM. o One or more elements that contain the Trademark Claim. The element contains the following child elements: * A element that contains the mark text string. * One or more elements that contains the information of the holder of the mark. An "entitlement" attribute is used to identify the entitlement of the holder, possible values are: owner, assignee or licensee. The child elements of include: + An OPTIONAL element that contains the name of the holder. A MUST be specified if is not specified. + An OPTIONAL element that contains the name of the organization holder of the mark. A MUST be specified if is not specified. + A element that contains the address information of the holder of a mark. A contains the following child elements: - One, two or three OPTIONAL elements that contains the organization's street address. - A element that contains the organization's city. Lozano Expires January 24, 2016 [Page 56] Internet-Draft TMCH functional specifications Jul 2015 - An OPTIONAL element that contains the organization's state or province. - An OPTIONAL element that contains the organization's postal code. - A element that contains the organization's country code. This a two-character code from [ISO3166-2]. + An OPTIONAL element that contains the organization's voice telephone number. + An OPTIONAL element that contains the organization's facsimile telephone number. + An OPTIONAL element that contains the email address of the holder. * Zero or more OPTIONAL elements that contains the information of the representative of the mark registration. A "type" attribute is used to identify the type of contact, possible values are: owner, agent or thirdparty. The child elements of include: + A element that contains name of the responsible person. + An OPTIONAL element that contains the name of the organization of the contact. + A element that contains the address information of the contact. A contains the following child elements: - One, two or three OPTIONAL elements that contains the contact's street address. - A element that contains the contact's city. - An OPTIONAL element that contains the contact's state or province. - An OPTIONAL element that contains the contact's postal code. Lozano Expires January 24, 2016 [Page 57] Internet-Draft TMCH functional specifications Jul 2015 - A element that contains the contact's country code. This a two-character code from [ISO3166-2]. + A element that contains the contact's voice telephone number. + An OPTIONAL element that contains the contact's facsimile telephone number. + A element that contains the contact's email address. * A element that contains the name (in English) of the jurisdiction where the mark is protected. A jurCC attribute contains the two-character code of the jurisdiction where the mark was registered. This is a two- character code from [WIPO.ST3]. * Zero or more OPTIONAL element that contains the description (in English) of the Nice Classification as defined in [WIPO-NICE-CLASSES]. A classNum attribute contains the class number. * A element that contains the full description of the goods and services mentioned in the mark registration document. * An OPTIONAL element signals that the claim notice was added to the TCN based on other rule than exact match as defined in [ICANN-GTLD-AGB-20120604]. The contains one or more: + An OPTIONAL element that signals that the claim notice was added because of a previously abused name included in an UDRP case. The contains: - A element that contains the UDRP case number used to validate the previously abused name. - A element that contains the name of the UDRP provider. + An OPTIONAL element that signals that the claim notice was added because of a previously abused name included in a court's resolution. The contains: Lozano Expires January 24, 2016 [Page 58] Internet-Draft TMCH functional specifications Jul 2015 - A element that contains the reference number of the court's resolution used to validate the previously abused name. - A element that contains the two-character code from [ISO3166-2] of the jurisdiction of the court. - A element that contains the name of the court. Lozano Expires January 24, 2016 [Page 59] Internet-Draft TMCH functional specifications Jul 2015 Example of object: 370d0b7c9223372036854775807 2010-08-14T09:00:00.0Z 2010-08-16T09:00:00.0Z example-one Example One Example Inc. 123 Example Dr. Suite 100 Reston VA 20190 US Joe Doe Example Inc. 123 Example Dr. Suite 100 Reston VA 20190 US +1.7035555555 jdoe@example.com UNITED STATES OF AMERICA Advertising; business management; business administration. Insurance; financial affairs; monetary affairs; real estate. Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum qui eis differimus. Lozano Expires January 24, 2016 [Page 60] Internet-Draft TMCH functional specifications Jul 2015 Example-One Example S.A. de C.V. Calle conocida #343 Conocida SP 82140 BR BRAZIL Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum qui eis differimus. One One Corporation Otra calle Otra ciudad OT 383742 CR COSTA RICA Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum qui eis differimus. 234235 CR Supreme Court of Justice of Costa Rica One Inc One SA de CV Lozano Expires January 24, 2016 [Page 61] Internet-Draft TMCH functional specifications Jul 2015 La calle La ciudad CD 34323 AR ARGENTINA Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum qui eis differimus. D2003-0499 WIPO For formal syntax of the TCN please refer to Section 7.1. Lozano Expires January 24, 2016 [Page 62] Internet-Draft TMCH functional specifications Jul 2015 6.6. Sunrise List File This section defines the format of the list containing every Domain Name Label (DNL) that matches a Pre-Registered Mark (PRM) eligible for Sunrise. The list is maintained by the TMDB and downloaded by Registries in regular intervals (see Section 5.4.2.1). The Registries use the Sunrise List during the Qualified Launch Program period to check whether a requested DN matches a DNL of a PRM eligible for Sunrise. The Sunrise List contains all the DNLs covered by a PRM eligible for Sunrise present in the TMDB at the time it is generated. The Sunrise List is contained in a CSV-like formatted file that has the following structure: o first line: , Where: + , version of the file, this field MUST be 1. + , date and time in UTC that the Sunrise List was created. o second line: a header line as specified in [RFC4180] With the header names as follows: DNL,insertion-datetime o One or more lines with: , Where: + , a Domain Name Label covered by a PRM eligible for Sunrise. + , datetime in UTC that the DNL was first inserted into the Sunrise List. The possible two values of time for inserting a DNL to the Sunrise List are 00:00:00 and 12:00:00 UTC. Lozano Expires January 24, 2016 [Page 63] Internet-Draft TMCH functional specifications Jul 2015 Example for Sunrise List 1,2012-08-16T00:00:00.0Z DNL,insertion-datetime example,2010-07-14T00:00:00.0Z another-example,2012-08-16T00:00:00.0Z anotherexample,2011-08-16T12:00:00.0Z Figure 18 To provide authentication and integrity protection, the Sunrise List will be PGP [RFC4880] signed by the TMDB with the private key of the TMDB (see also Section 5.1.1.4). The PGP signature of the Sunrise List can be found in the similar URI but with extension .sig as shown below. The URL of the dy interface (Section 4.3.3) is: o < https:///dnl/surl-latest.csv > o < https:///dnl/surl-latest.sig > Lozano Expires January 24, 2016 [Page 64] Internet-Draft TMCH functional specifications Jul 2015 7. Formal Syntax 7.1. Trademark Claims Notice The schema presented here is for a Trademark Claims Notice. Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN Lozano Expires January 24, 2016 [Page 65] Internet-Draft TMCH functional specifications Jul 2015 Schema for representing a Trademark Notice. Lozano Expires January 24, 2016 [Page 66] Internet-Draft TMCH functional specifications Jul 2015 Lozano Expires January 24, 2016 [Page 67] Internet-Draft TMCH functional specifications Jul 2015 END Lozano Expires January 24, 2016 [Page 68] Internet-Draft TMCH functional specifications Jul 2015 8. Acknowledgements This specification is a collaborative effort from several participants in the ICANN community. Bernie Hoeneisen participated as co-author until version 02 providing invaluable support for this document. This specification is based on a model spearheaded by: Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author would also like to thank the thoughful feedbak provided by many in the tmch-tech mailing list, but particularly the extensive help provided by James Gould, James Mitchell and Francisco Arias. 9. Change History [[RFC Editor: Please remove this section.]] 9.1. Changes from draft-lozano-tmch-func-spec-06 to draft-lozano-tmch-func-spec-07 1. Added result codes: 3611, 3612, 3613, 3614, 4607, 4608, 4609 and 4610. 2. Added mechanism to retrieve the LORDN Transaction Identifier based on a previously sent element. 9.2. Changes from draft-lozano-tmch-func-spec-07 to draft-lozano-tmch-func-spec-08 1. Updated result codes: 3613. 2. Added result codes: 3615, 3616, 3617 and 4611. 3. Removed result codes: 4605 and 4606 to support Limited Registration Periods as defined in the latest RPM Requirements document. 4. Minor editorial fixes. 9.3. Changes from draft-lozano-tmch-func-spec-08 to draft-lozano-tmch-func-spec-09 1. Added support for QLP. 2. Updated result codes: 3605. 3. Added result codes: 3618 (QLP) and 3619. Lozano Expires January 24, 2016 [Page 69] Internet-Draft TMCH functional specifications Jul 2015 4. XML Schema fix. 5. Minor editorial fixes. 9.4. Changes from draft-lozano-tmch-func-spec-09 to draft-lozano-tmch-func-spec-10 Draft expired. 10. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. One URI assigment have been registered by the IANA. Registration request for the Trademark Claims Notice: URI: urn:ietf:params:xml:ns:tmNotice-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. 11. Security Considerations TBD 12. References 12.1. Normative References [I-D.lozano-tmch-smd] Lozano, G., "Mark and Signed Mark Objects Mapping", draft-lozano-tmch-smd-03 (work in progress), September 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . Lozano Expires January 24, 2016 [Page 70] Internet-Draft TMCH functional specifications Jul 2015 12.2. Informative References [ICANN-GTLD-AGB-20120604] ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2012, . [ISO3166-2] ISO, "International Standard for country codes and codes for their subdivisions", 2006. [QLP-Addendum] ICANN, "Qualified Launch Program Addendum", April 2014, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ RFC2616, June 1999, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ RFC2818, May 2000, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Lozano Expires January 24, 2016 [Page 71] Internet-Draft TMCH functional specifications Jul 2015 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- Separated Values (CSV) Files", RFC 4180, DOI 10.17487/ RFC4180, October 2005, . [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/ RFC4346, April 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/ RFC4880, November 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 2013, . [WIPO-NICE-CLASSES] Lozano Expires January 24, 2016 [Page 72] Internet-Draft TMCH functional specifications Jul 2015 WIPO, "Nice List of Classes", . [WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the representation of states, other entities and intergovernmental organizations", March 2007. Appendix A. Document Changelog [RFC Editor: This section is to be removed before publication] Author's Address Gustavo Lozano ICANN 12025 Waterfront Drive, Suite 300 Los Angeles 90292 US Phone: +1.3103015800 Email: gustavo.lozano@icann.org Lozano Expires January 24, 2016 [Page 73]