29 Rights Protection Mechanisms

Prototypical answer:

Response to Question 29 (Rights protection mechanisms)

1 Overview

As required by specification 7 of the new gTLD Agreement, the Registry Operator will implement and strictly adhere to any rights protection mechanisms („RPMs“) that are mandated by ICANN. All mandated and independently developed RPMs will be included in the Registry-Registrar Agreement for .IKANO. The Registry Operator will implement all required RPMs described in the Trademark Clearinghouse („TMCH“) function (once adopted by ICANN) and understands that ICANN may revise such requirements from time to time.

The Registry Operator will comply with PDDRP, RRDRP and URS procedures, and will implement and adhere to the remedies ICANN imposes via those processes.

The Registry Operator will also take reasonable steps to investigate and respond to any reports from law enforcement, governmental and quasi-governmental agencies of illegal conduct under the TLD, and understands that the Registry Operator will not be required to take any action that contradicts applicable law.

Details about the implementation of the various rights protection mechanisms are included below.

1.1 Safeguard Against Violation of the TLDs Eligibility Restrictions

The Ikano S.A. is the operator and thus registry for the top-level domain .IKANO. It allows the registration of second level domain names below the TLD .IKANO. The TLD .IKANO can be exclusively used by Ikano S.A. and its affiliated companies in the Internet, especially for the operation of websites, email communications and other DNS-based services. The domain names under the TLD .IKANO are not available to the public for registration and active use. The Ikano S.A. will act both as a registry, as well as the sole beneficiary registrant.

1.2 UDRP Support

It is understood that ICANN’s Uniform Dispute Resolution Process (UDRP) is largely concerned with registrars. Hence, the Registry Operator does not need to implement any specific process in order to support the UDRP specifically. However, the Registry Operator will support registrars in UDRP cases involving domain names under the TLD and will cooperate with approved Dispute Resolution Service Providers in order to assist in their work.

1.3 URS Support

The Registry Operator will comply with ICANN’s requirements regarding the Uniform Rapid Suspension (URS) process and understands that the following services are required (and will be provided) during the operation of .IKANO:

• Contact information: the Registry Operator will provide email and other contact information to accredited URS-DRPs (Dispute Resolution Provider) so that notices and other communication regarding URS cases can be communicated efficiently.
• Notice and locking of a domain: Upon receipt of a respective Notice from an accredited URS provider, the Registry Operator will “lock” the affected domain name within 24 hours by means of putting it into the LOCKED status. This means that modifications (including transfers) on the domain name and registration data will be rejected but the name will still resolve in the DNS. The Registry Operator will immediately notify the URS-DRP upon locking the domain.
• Remedies: In order for the URS-DRP to implement the Remedy, the Registry Operator will subsequently modify the registration (for example, by changing nameservers to the URS-DRP’s own hosts) or remove the LOCKED status on the domain or implement other such measures as instructed by the URS-DRP.
• Extend Registration: the Registry Operator will support successful Complainants if they wish to extend the registration period for one year at commercial rates.

The Registry Operator wishes to note that authentication of URS-DRP is a critical issue since Notices and other instructions may be sent via email to the Registry Operator and email itself does not provide any means of authentication. Hence, additional measures such as cryptographically signing such emails will be deemed necessary in order to identify a Notice as authentic and subsequently authorize requests to the Registry Operator.

1.4 PDDRP

The Registry Operator agrees to participate in the procedures required by the Post-Delegation Dispute Resolution Procedure (PDDRP) and be bound to all determinations that are the result of said procedures. The process implemented by the Registry Operator for actual complaints will be as follows:

• Once a Complaint is received electronically or in paper notice form from the Provider, the Registry Operator will verify the content requirements of the Complaint, according to section 7.2 of the current PDDRP specification (dated Sep 19 2011). The Complaint will be reviewed by legal staff of the Registry Operator.
• The Registry Operator will notify the Provider about the receipt of a complaint.
• If deemed necessary, the Registry Operator will submit papers within 10 days of receipt of the Complaint.
• Registry Operator will subsequently follow the process regarding implementation of the remedies, as described in the PDDRP specification.

1.5 RRDRP

The Registry Operator agrees to participate in the procedures required by the Registration Restriction Dispute Resolution Policy (RRDRP) and be bound to the determinations that are the result of said procedures, in accordance to Section 2a of Specification 7 of the New gTLD Agreement. The actual administrative steps for handling Complaints based on the RRDRP will be identical, process-wise, to the PDDRP process described above.

1.6 Trademark Claims (Clearinghouse)

It is understood that – according to the Trademark Clearinghouse („TMCH“) definition dated Jan 12 2012 – ICANN is going to define a TMCH provider who will in turn supply two primary functions (see Section 1.2 of the document), of which function (ii) (“serving as a database to provide information to new gTLDs”) will be directly relevant to the operation of this TLD.

It is also understood that ICANN’s work towards the establishment of such a TMCH is still in progress. Therefore, it is not yet possible to describe the actual process and technical interfaces by which the Registry will support the TMCH requirements.

The Registry Operator will, however, implement any reasonable measures and processes that are required by the TMCH function.

1.7 Sunrise Services

Although only the Ikano S.A. is entitled to register domain names under the TLD .IKANO, according to the requirements of the Registry Agreements of the Applicant Guidebook (as of 11⁄01⁄2012) a so-called ʺsunrise periodʺ for the protection of specific rights is preceded. The ʺsunrise periodʺ is subject to the provisions of the Trademark Clearinghouse Applicant Guidebook (currently as of 01⁄11⁄2012). Prerequisite for applying for a domain name during the Sunrise Period is the eligibility under the TLD .IKANO. Moreover, the order of registrations based on the principle ʺfirst come first servedʺ.

1.8 Other Reports

The following will be memorialized and be made binding via the Registry-Registrar and Registrar-Registrant Agreements:

- The registry may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:
a. to enforce registry policies and ICANN requirements; each as amended from time to time;
b. that is not accompanied by complete and accurate information as required by ICANN requirements and⁄or registry policies or where required information is not updated and⁄or corrected as required by ICANN requirements and⁄or registry policies;
c. to protect the integrity and stability of the registry, its operations, and the TLD system;
d. to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the registry;
e. to establish, assert, or defend the legal rights of the registry or a third party or to avoid any civil or criminal liability on the part of the registry and⁄or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;
f. to correct mistakes made by the registry or any accredited registrar in connection with a registration; or
g. as otherwise provided in the Registry-Registrar Agreement and⁄or the Registrar-Registrant Agreement.

1.9 Dispute-related Technical Functionality in the Registry System

In order to handle any disputes concerning a domain in the .IKANO zone according to the RPMs defined, the Registry Administration Panel (a web-based interface to the SRS to query and manipulate registry data) includes functionality to manually put domains into the “LOCKED” status (see Answer to question 27 – Registration Lifecycle). The dispute related functions are based on more than 12 years of experience in managing disputes under the “.at” TLD and provide the following functionality:

• Search for domain names and display WHOIS as well as registrar data
• For each domain, the following tasks can be performed:
** Delete the domain immediately (domain immediately enters PENDING DELETE state and thus cannot be restored by a registrar)
** Put the domain into the LOCKED state (which prevents modifications and transfers on the domain name, and also prohibits modifications on the associated registrant contact)
** Add the “serverHold” status to domain names under LOCKED (so that the name is excluded from the DNS, and hence technically disabled)
** Remove the “serverHold” status from a LOCKED domain
** Put domain names in LOCKED state back to their previous state (most commonly, REGISTERED).
** For each action, the system allows users to select one of several “reasons” to be recorded with the action.
** An additional free-form text box allows users to record additional information, such as pointers to external documents, or case numbers.
• List all domain names in LOCKED status
• Display data, reasons, and additional information of domains in LOCKED state
• Display historical data about such cases

1.10 Resourcing Plan for Implementation and Ongoing Maintainance

Basic functionality regarding rights protections mechanisms (domain locking, tracking of requests) is already implemented in the registry core system, hence no further resources are needed for this initial implementation.

However, it is understood that resources are necessary to implement further measures that require technical interaction with the registry system, as soon as they are clearly defined (especially the TMCH process and sunrise). The implementation effort cannot be foreseen at the time of writing, hence the concrete resourcing plan for the technical part of the implementation and ongoing maintenance cannot be provided. However, the Registry Operator is aware of the fact that during landrush and sunrise more resources will be allocated to handle the increased load on the day to day operations as well performing necessary changes on the system after completion of sunrise and landrush if instructed by ICANN rules to do so.

Still, the Registry Operator will implement any reasonable measures and processes that are required by ICANN in respect to rights protection and resources will be allocated accordingly to have the functionality available for the operation of the registry.

Similar gTLD applications: (0)