29 Rights Protection Mechanisms

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.reisedotreise GmbHdotreise.deView

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 .reise. 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.
But as the detailed implementation of the TMCH function is still unspecified to a greater extent, the Registry Operator is only able to outline its intentions for the Sunrise phase for the .reise Community. Implementation details, e.g. as to what extent it possibly could be intertwined with the TMCH Sunrise phase instead of being held separately afterwards, need to be developed and if necessary adjusted as the circumstances with the TMCH functions proceed.
The Registry Operator will not mandate that owners of applicable intellectual property rights have to use any other trademark information aggregation, notification or validation service in addition to or instead of the ICANN-designated TMCH.
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

To meet the requirements of ICANN to a community-based designation of the application, the registrant must use the .reise domain in connection to the Travel community.
Restrictions may include, but are not limited to a requirement that each registered domain name is also being used beyond pure DNS resolution itself.
The .reise Registry will, from time to time, in its sole discretion or upon evidence or advice conduct continuing or recurring manual audits of domain names registered to ensure continued compliance with these requirements. Failure to comply will result in a notice providing 20-days to comply. Non-compliance following such a notice period may result in take-down of the relevant domain name, at the discretion of the Registry.
The Registry is entitled to lock, cancel, initiate the gTLD-deletion cycle or transfer domain names that do not meet the registration criteria. It will set up a process for any questions and challenges that may arise from registrations. Complainants will be provided a single point of contact via the Registry’s website to submit any questions and complaints regarding alleged abuse. The Registry also follows the standard dispute policies as defined in Q 28 and Q 39.

In detail the following measures will be carried out by the Registry to enforce the policies:
- Policies against domain name abuse and an Eligibility Requirements Dispute Resolution Policy (ERDRP)
- Dispute Policy based on local law
- Anti-Abuse Policies
By these policies the Registry is allowed to block, delete or transfer domain names.

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 .reise :
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.


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.


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

Registration of the .reise Sunrise is defined accordingly:
As part of its intended service for the Community of .reise, the Registry Operator intends to implement a Sunrise period, where applicants will be validated using the Trademark Clearinghouse services. Eligible are all registrants whose trademarks were validated by the Trademark Clearinghouse. The Sunrise period has a 30-day duration; allocation follows the first-come, first-served principle.
The current draft Sunrise Policy will be completed and or in parts be replaced by the mandatory rules of the ICANN Trademark Clearinghouse as soon as they become available.

1.7.1 - Timing of the phased registration

D -180 - information on the registration phase
3-6 months before the expected approval of the .reise, the Registry informs the public, administration, media and associations and chambers of the planned Sunrise and other procurement phases.
D0 - Approval of the .reise top-level domain by ICANN
D30 to D60 - Implementation of the Trademark Clearinghouse Sunrise period
During a period of 30 days, the Registry will receive requests for domain registrations via ICANN accredited registrars and conduct a review of the applications received.
D 90 - Start of the general registration period (Landrush)

1.7.2 Requirements and Restrictions

Those wishing to register their marks in the .reise domain during the TMCH Sunrise Phase must own a current trademark or service mark listed in the TMCH.
Notice will be provided to all trademark holders in the TMCH if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the TMCH that are an Identical Match (as defined in the TMCH) to the name to be registered during Sunrise.
Sunrise registration will require a minimum term of one year.
An application is only considered complete when the applicant provides the Registry, via a registrar, with at least the following information:
a) the full name of the applicant; where no name of a company or organisation is specified, the individual requesting registration of the domain name is considered the Applicant; if the name of the company or the organisation is specified, then the company or organisation is considered the applicant;
- Address and country of the registered office, central administration or principal place of business of the applicants organization, or
b) the full name, address, and the land of an administrative contact person (natural person);
c) the e-mail addresses of the applicant or his representative and the administrative contact;
d) telephone and fax number by which the applicant or his representative and the administrative contact can be reached;
e) the requested domain;
f) the complete name for which a Prior Right is claimed;
g) the type of Prior Right claimed by the applicant;
h) the country in which the Prior Right claimed is protected.
The information referred to (f) and (h) above is deemed to constitute the legal basis in national or Community law for the claimed Prior Right to the name.
The Domain Name applied must consist of the complete name for which a Prior Right is claimed.
The Registry is entitled to exchange the above information with the Validation Agent(s) (including their agents and subcontractors) in order to effect validation of the rights claimed.

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 .reise 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: (7)

gTLDFull Legal NameE-mail suffixzDetail
.immodotimmobilie GmbHdotimmobilie.de-4.26Compare
.versicherungdotversicherung-registry GmbHdotversicherung.de-4.22Compare
.gmbhTLDDOT GmbHdotgmbh.de-4.03Compare
.hamburgHamburg Top-Level-Domain GmbHdothamburg.de-3.84Compare
.berlindotBERLIN GmbH & Co. KGdotberlin.de-3.84Compare
.TIROLpunkt Tirol GmbHtirol.com-3.82Compare
.wienpunkt.wien GmbHpunktwien.at-3.81Compare