Dear Working Group members, Please see below the responses to follow-up questions from the Trademark Clearing House (TMCH) refresher presentation that was held on 14 November. This was a session with staff from ICANN’s Global Domains Division (GDD) to explain in some detail the TMCH Functional Specification, i.e. “how it works” rather than “what it is”. Best, Mary, Ariel, Berry, and Julie Responses to Follow-Up Questions Translation of Claims Notice: The Trademark Notice must be provided by the registrar to the potential domain name registrant in English. Additionally, to best serve its potential domain name registrants, registrars should provide the Trademark Notice to potential domain name registrants in the language of the registrant’s registration agreement. As provided in the TMCH Requirements, "The Claims Notice MUST be provided by the registrar to the potential domain name registrant in English and SHOULD be provided by the registrar to the potential domain name registrant in the language of the registration agreement.” Spanning the Dot: For the .TATTOO example given, the registry employed two sunrise periods, known as Sunrise A and Sunrise B. Sunrise A would be the regular period involving the Trademark Clearinghouse and mandated by ICANN. Sunrise B would allow trademark owners to apply for SLDs that do not exactly match their trademark and may "span the dot", as in ''toms.tattoo" for the trademark "Tom's Tattoo.” This service would occur during a “Sunrise B” period described in the TLD Startup Information as: The pre-launch opportunity for Sunrise A applicants for whom the terminal portion of the trademark string corresponds to the TLD may respond to invitations to register second-level names in the TLD truncated prior to such terminal portion – i.e. in which the trademark “spans the dot.” Such labels would not match labels in the SMD file according to the matching rules, and would not generate any notices by the TMCH unless the registry made specific arrangements for such service. Contracts, including expiration of Deloitte validator contract and potential for multiple Clearinghouses: A summary of the original validator agreement with Deloitte is here: https://newgtlds.icann.org/en/about/trademark-clearinghouse/validation-frame.... This agreement was auto-renewed on 12 July 2018 and extended on 12 November 2018 to 31 Dec 2022. This agreement provides that: Deloitte will initially be the sole provider of the validation services, but following the completion of ten (10) Qualified Sunrise Periods by Registries pursuant to the New gTLD Program, ICANN may then select additional third parties (“Additional Validators”) to perform the Trademark Clearinghouse validation services, in addition to Deloitte’s providing of the Trademark Clearinghouse Validation Function, provided, however, that ICANN shall use commercially reasonable efforts to ensure that such Additional Validators provide the Trademark Clearinghouse Validation Function without regard to region or type of Trademark and operating under the same terms and conditions as Deloitte hereunder, unless ICANN determines, following public discussion, to (i) appoint Additional Validators for specific regions, (ii) specify the types of Trademarks to be validated by such Additional Validators or (iii) modify the terms and conditions pursuant to which such Additional Validators shall operate. A summary of the database framework agreement with IBM is here: https://newgtlds.icann.org/en/about/trademark-clearinghouse/database-framewo... The Statement of Work with IBM for the TMCH database platform is here: https://newgtlds.icann.org/en/about/trademark-clearinghouse/database-platfor... The Statement of Work with IBM for the TMCH Sunrise and Claims services is here: https://newgtlds.icann.org/en/about/trademark-clearinghouse/sunrise-claims-s... How does ICANN org monitor the TMCH, and what happens if one of the services is down: Both ICANN org and IBM monitor the technical infrastructure of the Trademark Clearinghouse. ICANN's monitoring is proactive and simulates the standard workflow used by the contracted parties. If issues are detected, communications are sent to IBM’s 24/7 Service Desk for internal escalation and ICANN staff for follow-up. IBM investigates the issue, conducts troubleshooting activities, and rectifies the issues. If the issue was considered a Severity 1 incident in which critical functions were unavailable, IBM conducts a root cause analysis. Once the causes are identified, IBM, in consultation with ICANN, takes corrective measures to keep the issue from reoccurring. Overall Service Level performance is posted on ICANN.org at https://www.icann.org/resources/pages/metrics-systems-2015-08-05-en.