Back

29 Rights Protection Mechanisms

gTLDFull Legal NameE-mail suffixDetail
.SAPSAP AGknipp.deView
Q29 - Rights Protection Mechanisms

Whenever a new TLD is introduced, the protection of intellectual property, legal rights and trademarks (TMs) is an important objective. Using suitable technical means and appropriate policies and procedures, rights owners and trademark (TM) holders must be protected from abusive domain registrations throughout a TLDʹs launch phase(s), as well as during the period of general availability (GA) which follows these launch phase(s).

The SAP AG (and Knipp as its technical provider) are committed to make all necessary technical and organisational provisions in order to achieve this objective. This includes, but is not limited to, full compliance with all respective specifications, agreements and ICANN policies. Details about the measures put in place are laid out in the following.


1. Sunrise Period

A proven way to allow eligible rights owners to secure domain names related to their registered TMs is to conduct one or more so-called ʺSunriseʺ phases prior to the TLDʹs GA launch. During Sunrise, domain names are awarded only to registrants supplying appropriate and valid data manifesting their ownership of a TM that matches the desired name.

Technically, Sunrise phases differ from the GA period in some important aspects:

* In addition to the usual domain data, registrars need to collect TM information (such as TM name, number, type, application⁄registration dates) from the registrants and submit this data to the registry when applying for domain names.
* The specified TM information needs to be validated. This involves verifying the data with the help of a so-called ʺTrademark Clearinghouseʺ (TCH), a central repository authenticating, storing and disseminating TM information (providers for this service are to be designated by ICANN). In addition, manual reviews may be part of the validation process, for which appropriate tools should be in place.
* The results of the TM validation need to be received and properly processed. This includes notifying all involved parties (such as the registrar and registrant).
* It is possible that multiple applications for the same domain name are received. To distinguish these applications, a unique ʺapplication IDʺ is assigned to each of them. If more than one of the applications for a domain name carry valid TM data, contention resolution measures need to be taken in order to determine the registrant to whom the domain is awarded.

The TANGO Registration System used by Knipp to operate the .sap TLD fully supports these and other requirements of Sunrise phases via features described in the following.


1.1 Sunrise EPP Extension Support

The system supports an EPP extension for submission of TM data along with domain applications during launch phases such as Sunrise. For multi-phase Sunrise periods, the extension also supports the specification of the phase for which an application is submitted.

Moreover, the extension offers the possibility to submit additional textual information along with an application, such as e.g. the intended use for the domain name, or a URL demonstrating the previous use of the domain name under other TLDs. The registryʹs Sunrise policy governs whether specifying this information is required, which kind of data this information needs to provide, and how this information affects the decision about whether or not a domain name is awarded.

Please refer to the answer to Question 25 for more information about the launch phase EPP extension.


1.2 Sunrise Whois Support

Knipp provides special Whois services during launch phases like Sunrise. This allows registrants to check the status of their applications independently from information they may obtain from their registrars.

However, the Whois search options and the information returned during Sunrise differs from GA (as described in the answer to Question 26). Only the search for application IDs is enabled, without any support for wildcards. If an application ID exactly matches the Whois clientʹs query string, the applicationʹs data (domain name, registrar, application date, contact data and TM information) is returned, along with information about the applicationʹs status (such as ʺapprovedʺ or ʺunder reviewʺ). See the Sunrise⁄Landrush life cycle specification below for details about possible application states.


1.3 Registration Life Cycle Support for Sunrise (and Other Launch Phases)

The system supports the special steps of the registration life cycle that occur during Sunrise, i.e. the initial asynchronous TM validation and⁄or selection processes.

The registration life cycle described in the answer to Question 27 applies to the GA phase of the .sap TLD, i.e. the normal ʺFirst-Come, First-Servedʺ (FCFS) period that usually starts after a TLD has finished its initial launch phase(s). Launch phases like Sunrise and Landrush usually involve a special life cycle that adds some complexity to the initial domain creation step.

During Sunrise phases, this step comprises the validation of TM data and the determination of the winning application if multiple ones were received. Depending on the concrete registry policy in place, one or multiple Sunrise phases may be conducted.

So-called ʺLandrushʺ phases are usually conducted after (or in parallel to) Sunrise phases in order to limit the load on the Shared Registration System (SRS) that usually occurs during the initial run on popular, generic names. Their goal is to replace the brute-force FCFS approach of the GA by a fair, controlled domain assignment process that does not encourage registrars to flood the SRS with requests when GA starts. Similar to Sunrise, most Landrush approaches let registrars submit multiple applications for the same domain name, among which a winner is determined by asynchronous contention resolution measures as defined by the registryʹs policies. In contrast to Sunrise, usually no special proof of eligibility needs to be supplied by registrars or validated by the registry during Landrush.


1.3.1 Life Cycle Support for Sunrise

During both Sunrise and Landrush, the first step of the normal domain life cycle (ʺcreate domainʺ, position (A) in the GA life cycle diagram Q27-F1 from the answer to Question 27) consists itself of a number of individual steps representing the registryʹs rights protection workflow. The steps during Sunrise are depicted in Figure Q29-F1:

(A1) Registrars are required to submit Sunrise applications for domain names by sending EPP <domain:create> commands containing a special EPP extension for the specification of relevant TM data. In addition, a second EPP extension may be used to specify data required to resolve a potential contention with regard to the domain name (e.g. the registrantʹs bid for the case that an auction should be held to decide the final assignment of the domain name).

Application data is stored in the registry database. Checking this data for validity may involve manual evaluation that needs to be done asynchronously. Also, multiple valid applications for the same domain name may be submitted during Sunrise, which is why applications are collected until the end of the Sunrise submission period, after which evaluations (and, if required, contention resolution) take place to determine the final outcome. The final result of the application is later communicated to the registrar via an EPP poll message.

(A2) The registry system accesses the API of the connected TCH in an attempt to validate the submitted TM information in relation to the desired domain name.

(A3) If the check with the TCH fails, i.e. the provided TM information is found to be evidently invalid, the application is rejected immediately without further manual review. An EPP poll message is placed in the registrarʹs message queue to inform the registrar about the negative outcome of the application. The applicationʹs status is now ʺinvalidʺ, which is also displayed in the special launch phase Whois output when the application ID is queried.

This step in the life cycle may also be reached later in the validation process, i.e. after the application was found invalid during a manual review, or when a contention resolution for a name with multiple valid applications was lost by the registrant. In the latter case, the applicationʹs status is ʺrejectedʺ.

(A4) If the check with the TCH succeeds, i.e. the provided TM information is found to be (at least tentatively) valid, the application is added to the pool of automatically validated applications for the given name. The applicationʹs status is now ʺpendingʺ. Such applications are collected in the registry database until the end of the Sunrise submission period. The registrar may withdraw the application by sending an EPP <domain:delete> before the Sunrise submission period ends.

(A5) At the end of the Sunrise submission period, the application may be further evaluated, potentially involving manual checks. If the outcome of this evaluation is that the application is invalid, the application is rejected by going to step (A3).

(A6) All remaining, valid applications for the given name are examined. If there is only one valid application (left) for the given name, this application may be approved in step (A7). Otherwise, a contention resolution needs to be conducted to determine the final assignee for the application, which is done in step (A8).

(A7) The application is approved, the domain is allocated and assigned to the registrar. An EPP poll message is placed in the registrarʹs message queue to inform the registrar about the positive outcome of the application. The domain proceeds into the registered state. The applicationʹs status is now ʺallocatedʺ.

(A8) Since multiple valid applications for the same name were submitted, a contention resolution is required to determine the registrant to which the domain is awarded (the actual contention resolution used for .sap is described below). If the resolution is won, the next step is (A7); if it is lost, the next step is (A3). During the contention resolution, the applicationʹs status is ʺvalidatedʺ.


1.3.2 Life Cycle Support for Landrush

The steps during a Landrush phase are quite similar to the ones for Sunrise. As depicted in Figure Q29-F2, the basic approach is the same, except that no TM information is submitted or reviewed in the process; the only aspects governing the assignment of the domain name during Landrush are

* whether more than one application was received for the name and
* if this should be the case, which of these applications wins the contention resolution.

The availability of Landrush support in the TANGO Registration System does not imply that dedicated Landrush phases must be held. While they are technically feasible, registry policy may also dictate that Sunrise and Landrush are conducted in a single phase, or in overlapping phases. The TANGO Registration System is prepared for such cases. A combined Sunrise⁄Landrush phase is e.g. possible by allowing applications during Sunrise to be submitted without carrying any TM data (which marks them as Landrush applications). During the selection process, applications carrying TM data (i.e. proper Sunrise applications) then always take precedence over ones that were submitted without such data; only if no valid Sunrise applications are received for a name, the Landrush applications for the name are considered, and the winning one is determined in accordance with the registryʹs contention resolution policies.

Another alternative to a dedicated Landrush phase is the use of a FCFS approach for GA with staggered pricing; in this approach, a domainʹs initial registration price is relatively high when GA starts, but is decreased over time. Registrants willing to pay the high price may register the domain early on, others will try waiting until the price goes down. Despite the FCFS principle, such staggered pricing will usually prevent a flood of requests from registrars at the beginning of GA. The TANGO Registration System supports this approach by its flexible billing module, which allows the definition of specific prices for certain time periods, e.g. the first day after the start of GA, the second day and so forth.

The billing module, in conjunction with the rule engine described in the answer to Question 28, may also be used to charge individual, higher prices for attractive, generic names (ʺpremiumʺ domains).

See below for more information on the GA approach designated for .sap.


1.4 Trademark Clearinghouse (TCH) Support

The TANGO Registration System is prepared for accessing APIs of the TCH in order to validate the TM information submitted by the registrar during Sunrise. In addition, the system also contains provisions to make use of the TCH APIs for providing a Trademark Claims Service as soon as .sap enters a period of general availability (see below for more information on this service).

Since TCH Service Providers have not been assigned by ICANN at the time of writing, the full technical specifications for these APIs are not yet known. While basic provisions have been made in the TANGO Registration System to connect to these providers, the details will therefore have to be finalised once the service providers have been announced and API specifications are available. As described below, appropriate developer resources are allocated to perform this task.


1.5 Support for Multiple Applications for the Same Domain Name

The TANGO Registration System is designed to maintain multiple domain objects representing the same domain name at a given point in time. This feature is required to store multiple applications for the same name during launch phases like Sunrise.

To distinguish between the various applications for the name in the database (as well as in external APIs), each application is assigned a unique application ID. These application IDs are returned to registrars in the responses to domain applications via EPP and may subsequently be used, among other things, to enquire an applicationʹs review status. Also, review results are reported back to registrars via poll messages carrying the unique application ID. Registrars can utilise the ID to clearly associate results with their various applications. Registrants may query the status of their applications from the .sap Whois server using the ID.


1.6 Issue System

When manual reviews of Sunrise applications are required, this typically involves a specific support team workflow that, among other things, consists of

* storing application data in a database,
* making application data available to the support staff via a web interface,
* assigning the task of reviewing applications for a certain domain name to a specific support member (for the purpose of clear responsibilities),
* having the application reviewed by the assigned person, who in the process may
** request additional information or documentation from the registrant,
** add such documentation, as well as comments concerning the review, to the application,
** make a decision about the applicationʹs outcome or
** forward the task to a different support person with better insight or higher decision privileges (who may then make the final decision).

To support this workflow, the TANGO Registration System is equipped with a built-in Issue System that offers registry personnel a convenient web interface to review domain name applications and approve or reject them accordingly.

The Issue System

* offers an SSL-secured web interface accessible by .sap registry staff only;
* allows searching for applications by various criteria (e.g. domain name or current workflow⁄approval state);
* allows a registry support person to find newly submitted or otherwise unassigned applications and to take responsibility for them;
* offers a two-level review workflow that allows the delegation of pre-selection tasks to the first level support staff, after which a final decision - if still required - can be made by second level personnel;
* conveniently displays all application details, including registrant information, the supplied TM information, as well as the results of the verification of that TM data with the TCH;
* fully tracks and documents application status and history, allowing for a complete audit in case of disputes or legal enquiries and
* is fully integrated with the registry backend, i.e. it automatically notifies the SRS about the reviewersʹ decisions and immediately activates the respective domain in case of an approval. The Issue System also triggers the creation of appropriate EPP poll messages in order to keep registrars informed about the outcome of their applications.

The Issue System was first employed using puntCATʹs elaborate multi-phase Sunrise period in 2006 and proved to be an invaluable tool for efficiently organising a TLD roll-out process. It ensures that the registry staff reviewing Sunrise applications finds all information relevant to a domain name in one place and comes to well-founded decisions in a timely manner. As a technical provider for CORE Internet Council of Registrars (which conducted the .cat Sunrise phases and still operates the .cat TLD today), Knipp developed the Issue System as part of COREʹs Shared Registry System. The experience gathered from developing and operating the Issue System in that context helped to develop a second-generation version that is now part of the TANGO Registration System.


1.7 Support for Resolving Contention

If multiple valid and eligible applications for a domain name are received, a well-defined and deterministic process is required to nominate the winning application. The details of this contention resolution procedure highly depend on a specific TLDʹs policies. However, even after such policy-based considerations, multiple candidates for the winner of an application may be left in contention. In such a situation, different tie-breaker rules can be applied to make a decision.


1.7.1 First-Come, First-Served (FCFS)

The obvious tie-breaker rule is to simply award the domain to the first application submitted, i.e. the one that carries the earliest time stamp among the ones in the contention set. Since the TANGO Registration System assigns a unique time stamp to each received application in a fair, unbiased manner and makes it available to the review staff of the SAP AG, this FCFS strategy is a viable, technically supported way to resolve contentions.


1.7.2 Auctions

However, FCFS selection processes based on application submission times have the drawback of potentially encouraging registrants and registrars to submit all their requests as soon as the registry starts accepting applications, which imposes time pressure on the involved parties, puts a considerable load on the involved systems and may cause an unfair advantage for registrars with better connectivity to the SRS.

Therefore, the TANGO Registration System also supports a simple auction-based tie-breaker approach out-of-the-box. It allows the registrar to submit a single, blind bid amount along with the Sunrise or Landrush application (via a special EPP extension). In the case of a contention, the application that was submitted with the highest bid wins. In the unlikely event that two applications were submitted with the exact same bid amount, the one with the earlier time stamp wins. Only the winning applicant pays his bid, i.e. there is no extra fee for placing a bid; this ensures that the process cannot be regarded as a lottery. If no contention should arise (i.e. there is only one applicant left before bids would be considered as a tie-breaker), the bid amount is irrelevant and only the standard application fee is paid.


2. Compliance with Specification 7 of the gTLD Applicant Guidebook

The SAP AG will fully comply with the rules defined in Specification 7 of ICANNʹs gTLD Applicant Guidebook (ʺMinimum Requirements for Rights Protection Mechanismsʺ). The details of this compliance is outlined in the following.


2.1 Implementation of All Mandated Rights Protection Mechanisms

In particular, this means that the SAP AG will include all ICANN mandated and independently developed Rights Protection Mechanisms (as described here) in the registry-registrar agreement (RRA) to be signed by all registrars authorised to register names in the .sap TLD. The SAP AG will also, in accordance with requirements established by ICANN, implement each of the mandatory Rights Protection Mechanisms set forth in the ICANN-designated TCH.

During the conducted Sunrise phase, which will at least be offered for 30 days prior to entering a GA period, the SAP AG will consult the ICANN-designated TCH in order to verify TM data submitted by registrants. Details about this process are depicted above.


2.2 Trademark Claims Service

For further compliance with Specification 7, the SAP AG will implement a continuous Trademark Claims Service (TCS) to ensure that even after Sunrise, registrants are notified whenever their registered domain name potentially violates a TM holderʹs rights as stored in the TCH. Likewise, the service makes the TM holder aware of any domain registrations that potentially infringe on his TMs registered with the TCH.

As required by ICANN, the TCS of .sap will at least cover the first 60 days of GA; it is considered that the TCS will be provided indefinitely, i.e. on a continuous basis beyond the first 60 days of GA.

When a match of a registered name is found via the API provided by the TCH, the TCS is supposed to provide clear notice to a prospective registrant of the scope of the mark holderʹs rights. The registrant will in turn be required to provide statement that

* he received notification that the mark is included in the TCH,
* he received and understood the notice and
* his registration and use of the requested domain name will not infringe on the rights that are subject of the notice.

The registrant will be directed to the TCH Database information referenced in the Trademark Claims Notice to enhance understanding of the TM rights being claimed by the TM holder.

Also, if a domain name is registered in the TCH, the registry will, through an interface with the TCH, promptly notify the mark holders(s) of the registration after it becomes effective.


2.3 Prevention of Otherwise Unqualified Registrations

In addition to protecting the rights of TM holders as described above, the SAP AG will also ensure that no registrations will be allowed which are in violation of the registry’s eligibility restrictions or policies. Technically, this is achieved by utilising the advanced domain name rule engine that is part of the TANGO Registration System and described in detail in the answer to Question 28. As laid out there, the underlying set of checks can be tuned to block registrations of .sap names based on various syntactic rules, multiple reserved names lists, and patterns. Prior to the launch of the .sap TLD, the rule engine will be configured in accordance with the policies of the SAP AG. Reserved names lists will be populated as governed by all eligibility restrictions that need to be enforced, which means that such names are not available for registration by registrars.

However, should eligible parties approach the SAP AG (via a registrar) providing sufficient evidence of their eligibility for a specific reserved domain name, the SAP AG can enable the chosen registrar to register the domain name for that specific registrant only (circumventing the rule engine check that would otherwise prevent the registration).


2.4 Reducing Opportunities for Phishing and Pharming

The abusive behaviours of phishing and pharming constitute a severe violation of the legal rights of others. Both practises are usually applied to make users enter confidential information on fake web sites pretending to be operated by a certain company or institution. In the case of phishing, the attack is usually done by trying to conceal the real domain name in the URL, or by using a domain name very similar to the one the user originally meant to visit. In the case of pharming, the attack happens on the DNS level, i.e. while the user still sees the correct domain name of the site he meant to visit, the IP address his resolver determined for the domain name somehow gets manipulated to point to the fake web site.

Due to the way these attacks are conducted, neither phishing nor pharming can be entirely prevented on the registry level. However, the registry can put mechanisms and policies in place that will make such exploits harder or limit their duration and impact.


2.4.1 Phishing

One important tool to rapidly address phishing activities shown by a web site operated under the .sap TLD is the Rapid Takedown Policy described in the answer to Question 28. It allows a fast takedown of an offending site after respective activities were reported and confirmed.

In addition, the flexible rule engine used by the TANGO Registration System to validate permissible .sap domain names can be utilised in the context of phishing. Should a certain .sap domain name (or a pattern of such names) be repeatedly involved in attempts to mimic a rights holderʹs legitimate .sap name for phishing purposes, the set of registration validation rules can be easily augmented to prevent the offending domain name (and, if need be, even an entire pattern of names deemed too similar to a rights holderʹs legitimate domain name) from being registered again after takedown. Of course, this practise will be exercised in close collaboration with ICANN and other parties potentially involved in the definition of names deemed not eligible for registration within the .sap TLD.

As described in the answer to Question 28, the sophisticated IDN handling implemented by the TANGO Registration System is designed to provide protection against the most common cases of IDN-based phishing attempts, such as IDN homograph attacks. Please refer to the answers to Question 28, as well as Question 44, for more information on this topic.


2.4.2 Pharming

With regard to pharming, neither the quick takedown of offending domain names nor the blocking of such names are suitable as countermeasures. Due to the nature of the attack, the registryʹs approach needs to aim at a robust DNS infrastructure for .sap, which ideally should guarantee the integrity and authenticity of DNS lookup results all the way from the registry-operated TLD name servers to the userʹs local resolver.

As described in detail in the answer to Question 35, the SAP AG will deploy a highly reliable and secure DNS subsystem for the .sap TLD, which is powered by the elaborate DNSSEC setup laid out in the answer to Question 43. The SAP AG is therefore able to safeguard against any attempts to perform DNS manipulation on the level of the name servers operating the .sap zone.

However, due to the way the domain name system (and DNSSEC in particular) works, preventing manipulations of the .sap TLD name servers alone is not sufficient to avoid pharming attacks. In order to provide complete protection, DNSSEC support is required on every level of the domain resolution process, from the root zone via the TLD name servers and the delegated name servers down to a userʹs resolver. This means that registrars need to sign the zones they host on their name servers (and offer this service to their registrants), and resolvers (or other clients looking up .sap domain names) need to verify the signatures and notify their users when inconsistencies are detected. Consequently, the SAP AG will encourage and advertise the widespread support and use of DNSSEC among registrars, registrants and end users. Once DNSSEC has been widely adopted, web browsers, e-mail clients and similar applications will increasingly support the verification of the related signatures out-of-the-box (rather than via the extensions available today), which will drastically diminish opportunities for pharming.

Since .sap is a brand TLD using a single-registrar, single-registrant model (with both being under the control of the SAP AG), the support of DNSSEC on the delegated name servers for .sap names can and will be enforced. Also, end users within the control of SAP AG (like its employees) will be required to install software for DNSSEC verification (such as extensions for web browsers or e-mail clients) where available.


2.5 Compliance with Dispute Resolution and Suspension Procedures

In case of complaints put forward by rights holders with regard to domain names registered under .sap, the SAP AG will fully comply with all resolution procedures endorsed or mandated by ICANN. In particular, this includes supporting the Uniform Rapid Suspension (URS) procedures and the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP).

The SAP AG is committed to implement decisions rendered under the URS. In particular, the SAP AG will

* readily receive notifications about complaints (“Notice of Complaint”) from URS providers,
* lock the affected domain within 24 hours of receipt of the Notice of Complaint from the URS Provider, blocking all changes to the registration data, including transfer and deletion of the domain name (while retaining the domain name in the .sap zone, i.e. the name will continue to resolve),
* notify the URS Provider immediately upon locking the domain name (”Notice of Lock”).

Once the complaint was decided upon, the following steps will be taken:

* If registrant was relieved, the SAP AG will unlock the domain and return full control to the registrant.
* In case of a determination in favour of the complainant, the SAP AG will, in accordance with the URS rulings, immediately suspend the domain name and keep it suspended for the remainder of its registration period; this means that the domain will remain locked and that the domainʹs name servers are redirected to an information web page supplied by the URS provider. In this situation, SAP AG will also make sure that the Whois output for the domain keeps displaying the original data (except for the altered name servers) and reflects that the domain name will not be able to be transferred, deleted or modified for the remainder of its registration period.
* The successful complainant will get the option to extend the registration period for one additional year at commercial rates.

In addition to these URS related procedures, the SAP AG is also committed to take any necessary steps required to support decisions emerging from the Uniform Domain Name Dispute Resolution Policy (UDRP). After a respective complaint has been filed in a court of proper jurisdiction or with an approved dispute resolution service provider, the SAP AG will implement all required measures arising from its function as a registry, including an immediate transfer of the domain to the legitimate rights holder (if the caseʹs determination is in the complainantʹs favour).

In case the SAP AG becomes involved in a Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP), it will fully adhere to the general rules of the procedure as set out by ICANN, as well as the individual requirements defined by the Trademark PDDRP Provider. However, it should be noted that the SAP AG has taken (and will continue to take) thorough precautions to ensure that a Trademark PDDRP will not become necessary. Nevertheless, should it become necessary, the SAP AG will abide by the remedies recommended by the Expert Panel, and potential fees imposed.

The Registry Restrictions Dispute Resolution Procedure (RRDRP) is not relevant in the context of .sap, since .sap is not a community-based gTLD.


3. Sunrise and Landrush Policies for the .sap TLD

.sap is a so-called brand⁄institutional TLD using a single-registrar, single-registrant model for the exclusive use of the SAP AG. Therefore, the protection of TMs and other rights is guaranteed, since the SAP AG is committed to restrict its registration and use of names in the .sap TLD in a way that doesnʹt infringe on such rights, and no other parties are eligible to register .sap domains.

The TCS is implemented as described above to ensure that both the SAP AG and rights holders are notified about registered domain names that potentially violate TMs stored in the TCH. The SAP AG will abide by all requirements arising from the regulations of the TCS described above.

In addition, the compulsory Sunrise phase is conducted for 30 days after the registryʹs launch. However, the .sap Sunrise eligibility requirements clearly mandate that only the SAP AG itself qualifies as an applicant, and only domain names for its own (or its affiliates) TMs, services, products, offerings or other legitimate interests are permissible as Sunrise registrations. Due to the exclusive use of by the registry, no contentions will occur, which means that no contention resolution strategies (such as auctions) are required for .sap.

Since the .sap TLD will not be open to any third-party registrations, no Landrush phase is required.


4. Resourcing Plans

The TANGO Registration System already supports the rights protection features described above at the time of writing. No coding is required for this, which means that no special developing resources will be needed. The staff on duty at Knipp will be in charge of performing manual reviews of TM data where required.

Since the TCH API is not fully defined at the time of writing, some software development will have to be done in order to integrate it into the Sunrise workflow and the TCS.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 5 man days
* System Administrator: configuring system for policies: 1 man day
* First Level Support: training: 4 man hours per person
* Software Developer: integration of TCH API: 10 man days

For the Sunrise phase, the following resources are allotted:

* First Level Support: 30 man days per month
* Second Level Support: 30 man days per month

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 1 man day per month

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp in the past over the course of 12 months.

gTLDFull Legal NameE-mail suffixDetail
.terraTelefónica S.A.interdomain.orgView
Q29 - Rights Protection Mechanisms

Whenever a new TLD is introduced, the protection of intellectual property, legal rights and trademarks (TMs) is an important objective. Using suitable technical means and appropriate policies and procedures, rights owners and trademark (TM) holders must be protected from abusive domain registrations throughout a TLDʹs launch phase(s), as well as during the period of general availability (GA) which follows these launch phase(s).

The .terra Registry (and CORE as its technical provider) are committed to make all necessary technical and organisational provisions in order to achieve this objective. This includes, but is not limited to, full compliance with all respective specifications, agreements and ICANN policies. Details about the measures put in place are laid out in the following.


1. Sunrise Period

A proven way to allow eligible rights owners to secure domain names related to their registered TMs is to conduct one or more so-called ʺSunriseʺ phases prior to the TLDʹs GA launch. During Sunrise, domain names are awarded only to registrants supplying appropriate and valid data manifesting their ownership of a TM that matches the desired name.

Technically, Sunrise phases differ from the GA period in some important aspects:

* In addition to the usual domain data, registrars need to collect TM information (such as TM name, number, type, application⁄registration dates) from the registrants and submit this data to the registry when applying for domain names.
* The specified TM information needs to be validated. This involves verifying the data with the help of a so-called ʺTrademark Clearinghouseʺ (TCH), a central repository authenticating, storing and disseminating TM information (providers for this service are to be designated by ICANN). In addition, manual reviews may be part of the validation process, for which appropriate tools should be in place.
* The results of the TM validation need to be received and properly processed. This includes notifying all involved parties (such as the registrar and registrant).
* It is possible that multiple applications for the same domain name are received. To distinguish these applications, a unique ʺapplication IDʺ is assigned to each of them. If more than one of the applications for a domain name carry valid TM data, contention resolution measures need to be taken in order to determine the registrant to whom the domain is awarded.

The CORE Registration System used by CORE to operate the .terra TLD fully supports these and other requirements of Sunrise phases via features described in the following.


1.1 Sunrise EPP Extension Support

The system supports an EPP extension for submission of TM data along with domain applications during launch phases such as Sunrise. For multi-phase Sunrise periods, the extension also supports the specification of the phase for which an application is submitted.

Moreover, the extension offers the possibility to submit additional textual information along with an application, such as e.g. the intended use for the domain name, or a URL demonstrating the previous use of the domain name under other TLDs. The registryʹs Sunrise policy governs whether specifying this information is required, which kind of data this information needs to provide, and how this information affects the decision about whether or not a domain name is awarded.

Please refer to the answer to Question 25 for more information about the launch phase EPP extension.


1.2 Sunrise Whois Support

CORE provides special Whois services during launch phases like Sunrise. This allows registrants to check the status of their applications independently from information they may obtain from their registrars.

However, the Whois search options and the information returned during Sunrise differs from GA (as described in the answer to Question 26). Only the search for application IDs is enabled, without any support for wildcards. If an application ID exactly matches the Whois clientʹs query string, the applicationʹs data (domain name, registrar, application date, contact data and TM information) is returned, along with information about the applicationʹs status (such as ʺapprovedʺ or ʺunder reviewʺ). See the Sunrise⁄Landrush life cycle specification below for details about possible application states.


1.3 Registration Life Cycle Support for Sunrise (and Other Launch Phases)

The system supports the special steps of the registration life cycle that occur during Sunrise, i.e. the initial asynchronous TM validation and⁄or selection processes.

The registration life cycle described in the answer to Question 27 applies to the GA phase of the .terra TLD, i.e. the normal ʺFirst-Come, First-Servedʺ (FCFS) period that usually starts after a TLD has finished its initial launch phase(s). Launch phases like Sunrise and Landrush usually involve a special life cycle that adds some complexity to the initial domain creation step.

During Sunrise phases, this step comprises the validation of TM data and the determination of the winning application if multiple ones were received. Depending on the concrete registry policy in place, one or multiple Sunrise phases may be conducted.

So-called ʺLandrushʺ phases are usually conducted after (or in parallel to) Sunrise phases in order to limit the load on the Shared Registration System (SRS) that usually occurs during the initial run on popular, generic names. Their goal is to replace the brute-force FCFS approach of the GA by a fair, controlled domain assignment process that does not encourage registrars to flood the SRS with requests when GA starts. Similar to Sunrise, most Landrush approaches let registrars submit multiple applications for the same domain name, among which a winner is determined by asynchronous contention resolution measures as defined by the registryʹs policies. In contrast to Sunrise, usually no special proof of eligibility needs to be supplied by registrars or validated by the registry during Landrush.


1.3.1 Life Cycle Support for Sunrise

During both Sunrise and Landrush, the first step of the normal domain life cycle (ʺcreate domainʺ, position (A) in the GA life cycle diagram Q27-F1 from the answer to Question 27) consists itself of a number of individual steps representing the registryʹs rights protection workflow. The steps during Sunrise are depicted in Figure Q29-F1:

(A1) Registrars are required to submit Sunrise applications for domain names by sending EPP ʺdomain:createʺ commands containing a special EPP extension for the specification of relevant TM data. In addition, a second EPP extension may be used to specify data required to resolve a potential contention with regard to the domain name (e.g. the registrantʹs bid for the case that an auction should be held to decide the final assignment of the domain name).

Application data is stored in the registry database. Checking this data for validity may involve manual evaluation that needs to be done asynchronously. Also, multiple valid applications for the same domain name may be submitted during Sunrise, which is why applications are collected until the end of the Sunrise submission period, after which evaluations (and, if required, contention resolution) take place to determine the final outcome. The final result of the application is later communicated to the registrar via an EPP poll message.

(A2) The registry system accesses the API of the connected TCH in an attempt to validate the submitted TM information in relation to the desired domain name.

(A3) If the check with the TCH fails, i.e. the provided TM information is found to be evidently invalid, the application is rejected immediately without further manual review. An EPP poll message is placed in the registrarʹs message queue to inform the registrar about the negative outcome of the application. The applicationʹs status is now ʺinvalidʺ, which is also displayed in the special launch phase Whois output when the application ID is queried.

This step in the life cycle may also be reached later in the validation process, i.e. after the application was found invalid during a manual review, or when a contention resolution for a name with multiple valid applications was lost by the registrant. In the latter case, the applicationʹs status is ʺrejectedʺ.

(A4) If the check with the TCH succeeds, i.e. the provided TM information is found to be (at least tentatively) valid, the application is added to the pool of automatically validated applications for the given name. The applicationʹs status is now ʺpendingʺ. Such applications are collected in the registry database until the end of the Sunrise submission period. The registrar may withdraw the application by sending an EPP ʺdomain:deleteʺ before the Sunrise submission period ends.

(A5) At the end of the Sunrise submission period, the application may be further evaluated, potentially involving manual checks. If the outcome of this evaluation is that the application is invalid, the application is rejected by going to step (A3).

(A6) All remaining, valid applications for the given name are examined. If there is only one valid application (left) for the given name, this application may be approved in step (A7). Otherwise, a contention resolution needs to be conducted to determine the final assignee for the application, which is done in step (A8).

(A7) The application is approved, the domain is allocated and assigned to the registrar. An EPP poll message is placed in the registrarʹs message queue to inform the registrar about the positive outcome of the application. The domain proceeds into the registered state. The applicationʹs status is now ʺallocatedʺ.

(A8) Since multiple valid applications for the same name were submitted, a contention resolution is required to determine the registrant to which the domain is awarded (the actual contention resolution used for .terra is described below). If the resolution is won, the next step is (A7); if it is lost, the next step is (A3). During the contention resolution, the applicationʹs status is ʺvalidatedʺ.


1.3.2 Life Cycle Support for Landrush

The steps during a Landrush phase are quite similar to the ones for Sunrise. As depicted in Figure Q29-F2, the basic approach is the same, except that no TM information is submitted or reviewed in the process; the only aspects governing the assignment of the domain name during Landrush are

* whether more than one application was received for the name and
* if this should be the case, which of these applications wins the contention resolution.

The availability of Landrush support in the CORE Registration System does not imply that dedicated Landrush phases must be held. While they are technically feasible, registry policy may also dictate that Sunrise and Landrush are conducted in a single phase, or in overlapping phases. The CORE Registration System is prepared for such cases. A combined Sunrise⁄Landrush phase is e.g. possible by allowing applications during Sunrise to be submitted without carrying any TM data (which marks them as Landrush applications). During the selection process, applications carrying TM data (i.e. proper Sunrise applications) then always take precedence over ones that were submitted without such data; only if no valid Sunrise applications are received for a name, the Landrush applications for the name are considered, and the winning one is determined in accordance with the registryʹs contention resolution policies.

Another alternative to a dedicated Landrush phase is the use of a FCFS approach for GA with staggered pricing; in this approach, a domainʹs initial registration price is relatively high when GA starts, but is decreased over time. Registrants willing to pay the high price may register the domain early on, others will try waiting until the price goes down. Despite the FCFS principle, such staggered pricing will usually prevent a flood of requests from registrars at the beginning of GA. The CORE Registration System supports this approach by its flexible billing module, which allows the definition of specific prices for certain time periods, e.g. the first day after the start of GA, the second day and so forth.

The billing module, in conjunction with the rule engine described in the answer to Question 28, may also be used to charge individual, higher prices for attractive, generic names (ʺpremiumʺ domains).

See below for more information on the GA approach designated for .terra.


1.4 Trademark Clearinghouse (TCH) Support

The CORE Registration System is prepared for accessing APIs of the TCH in order to validate the TM information submitted by the registrar during Sunrise. In addition, the system also contains provisions to make use of the TCH APIs for providing a Trademark Claims Service as soon as .terra enters a period of general availability (see below for more information on this service).

Since TCH Service Providers have not been assigned by ICANN at the time of writing, the full technical specifications for these APIs are not yet known. While basic provisions have been made in the CORE Registration System to connect to these providers, the details will therefore have to be finalised once the service providers have been announced and API specifications are available. As described below, appropriate developer resources are allocated to perform this task.


1.5 Support for Multiple Applications for the Same Domain Name

The CORE Registration System is designed to maintain multiple domain objects representing the same domain name at a given point in time. This feature is required to store multiple applications for the same name during launch phases like Sunrise.

To distinguish between the various applications for the name in the database (as well as in external APIs), each application is assigned a unique application ID. These application IDs are returned to registrars in the responses to domain applications via EPP and may subsequently be used, among other things, to enquire an applicationʹs review status. Also, review results are reported back to registrars via poll messages carrying the unique application ID. Registrars can utilise the ID to clearly associate results with their various applications. Registrants may query the status of their applications from the .terra Whois server using the ID.


1.6 Issue System

When manual reviews of Sunrise applications are required, this typically involves a specific support team workflow that, among other things, consists of

* storing application data in a database,
* making application data available to the support staff via a web interface,
* assigning the task of reviewing applications for a certain domain name to a specific support member (for the purpose of clear responsibilities),
* having the application reviewed by the assigned person, who in the process may
** request additional information or documentation from the registrant,
** add such documentation, as well as comments concerning the review, to the application,
** make a decision about the applicationʹs outcome or
** forward the task to a different support person with better insight or higher decision privileges (who may then make the final decision).

To support this workflow, the CORE Registration System is equipped with a built-in Issue System that offers registry personnel a convenient web interface to review domain name applications and approve or reject them accordingly.

The Issue System

* offers an SSL-secured web interface accessible by .terra registry staff only;
* allows searching for applications by various criteria (e.g. domain name or current workflow⁄approval state);
* allows a registry support person to find newly submitted or otherwise unassigned applications and to take responsibility for them;
* offers a two-level review workflow that allows the delegation of pre-selection tasks to the first level support staff, after which a final decision - if still required - can be made by second level personnel;
* conveniently displays all application details, including registrant information, the supplied TM information, as well as the results of the verification of that TM data with the TCH;
* fully tracks and documents application status and history, allowing for a complete audit in case of disputes or legal enquiries and
* is fully integrated with the registry backend, i.e. it automatically notifies the SRS about the reviewersʹ decisions and immediately activates the respective domain in case of an approval. The Issue System also triggers the creation of appropriate EPP poll messages in order to keep registrars informed about the outcome of their applications.

The Issue System was first employed using puntCATʹs elaborate multi-phase Sunrise period in 2006 and proved to be an invaluable tool for efficiently organising a TLD roll-out process. It ensures that the registry staff reviewing Sunrise applications finds all information relevant to a domain name in one place and comes to well-founded decisions in a timely manner. The experience gathered from developing and operating the Issue System in that context helped to develop a second-generation version that is now part of the CORE Registration System.


1.7 Support for Resolving Contention

If multiple valid and eligible applications for a domain name are received, a well-defined and deterministic process is required to nominate the winning application. The details of this contention resolution procedure highly depend on a specific TLDʹs policies. However, even after such policy-based considerations, multiple candidates for the winner of an application may be left in contention. In such a situation, different tie-breaker rules can be applied to make a decision.


1.7.1 First-Come, First-Served (FCFS)

The obvious tie-breaker rule is to simply award the domain to the first application submitted, i.e. the one that carries the earliest time stamp among the ones in the contention set. Since the CORE Registration System assigns a unique time stamp to each received application in a fair, unbiased manner and makes it available to the review staff of the .terra Registry, this FCFS strategy is a viable, technically supported way to resolve contentions.


1.7.2 Auctions

However, FCFS selection processes based on application submission times have the drawback of potentially encouraging registrants and registrars to submit all their requests as soon as the registry starts accepting applications, which imposes time pressure on the involved parties, puts a considerable load on the involved systems and may cause an unfair advantage for registrars with better connectivity to the SRS.

Therefore, the CORE Registration System also supports a simple auction-based tie-breaker approach out-of-the-box. It allows the registrar to submit a single, blind bid amount along with the Sunrise or Landrush application (via a special EPP extension). In the case of a contention, the application that was submitted with the highest bid wins. In the unlikely event that two applications were submitted with the exact same bid amount, the one with the earlier time stamp wins. Only the winning applicant pays his bid, i.e. there is no extra fee for placing a bid; this ensures that the process cannot be regarded as a lottery. If no contention should arise (i.e. there is only one applicant left before bids would be considered as a tie-breaker), the bid amount is irrelevant and only the standard application fee is paid.


2. Compliance with Specification 7 of the gTLD Applicant Guidebook

The .terra Registry will fully comply with the rules defined in Specification 7 of ICANNʹs gTLD Applicant Guidebook (ʺMinimum Requirements for Rights Protection Mechanismsʺ). The details of this compliance is outlined in the following.


2.1 Implementation of All Mandated Rights Protection Mechanisms

In particular, this means that the .terra Registry will include all ICANN mandated and independently developed Rights Protection Mechanisms (as described here) in the registry-registrar agreement (RRA) to be signed by all registrars authorised to register names in the .terra TLD. The .terra Registry will also, in accordance with requirements established by ICANN, implement each of the mandatory Rights Protection Mechanisms set forth in the ICANN-designated TCH.

During the conducted Sunrise phase, which will at least be offered for 30 days prior to entering a GA period, the .terra Registry will consult the ICANN-designated TCH in order to verify TM data submitted by registrants. Details about this process are depicted above.


2.2 Trademark Claims Service

For further compliance with Specification 7, the .terra Registry will implement a continuous Trademark Claims Service (TCS) to ensure that even after Sunrise, registrants are notified whenever their registered domain name potentially violates a TM holderʹs rights as stored in the TCH. Likewise, the service makes the TM holder aware of any domain registrations that potentially infringe on his TMs registered with the TCH.

As required by ICANN, the TCS of .terra will at least cover the first 60 days of GA; it is considered that the TCS will be provided indefinitely, i.e. on a continuous basis beyond the first 60 days of GA.

When a match of a registered name is found via the API provided by the TCH, the TCS is supposed to provide clear notice to a prospective registrant of the scope of the mark holderʹs rights. The registrant will in turn be required to provide statement that

* he received notification that the mark is included in the TCH,
* he received and understood the notice and
* his registration and use of the requested domain name will not infringe on the rights that are subject of the notice.

The registrant will be directed to the TCH Database information referenced in the Trademark Claims Notice to enhance understanding of the TM rights being claimed by the TM holder.

Also, if a domain name is registered in the TCH, the registry will, through an interface with the TCH, promptly notify the mark holders(s) of the registration after it becomes effective.


2.3 Prevention of Otherwise Unqualified Registrations

In addition to protecting the rights of TM holders as described above, the .terra Registry will also ensure that no registrations will be allowed which are in violation of the registry’s eligibility restrictions or policies. Technically, this is achieved by utilising the advanced domain name rule engine that is part of the CORE Registration System and described in detail in the answer to Question 28. As laid out there, the underlying set of checks can be tuned to block registrations of .terra names based on various syntactic rules, multiple reserved names lists, and patterns. Prior to the launch of the .terra TLD, the rule engine will be configured in accordance with the policies of the .terra Registry. Reserved names lists will be populated as governed by all eligibility restrictions that need to be enforced, which means that such names are not available for registration by registrars.

However, should eligible parties approach the .terra Registry (via a registrar) providing sufficient evidence of their eligibility for a specific reserved domain name, the .terra Registry can enable the chosen registrar to register the domain name for that specific registrant only (circumventing the rule engine check that would otherwise prevent the registration).


2.4 Reducing Opportunities for Phishing and Pharming

The abusive behaviours of phishing and pharming constitute a severe violation of the legal rights of others. Both practices are usually applied to make users enter confidential information on fake web sites pretending to be operated by a certain company or institution. In the case of phishing, the attack is usually done by trying to conceal the real domain name in the URL, or by using a domain name very similar to the one the user originally meant to visit. In the case of pharming, the attack happens on the DNS level, i.e. while the user still sees the correct domain name of the site he meant to visit, the IP address his resolver determined for the domain name somehow gets manipulated to point to the fake web site.

Due to the way these attacks are conducted, neither phishing nor pharming can be entirely prevented on the registry level. However, the registry can put mechanisms and policies in place that will make such exploits harder or limit their duration and impact.


2.4.1 Phishing

One important tool to rapidly address phishing activities shown by a web site operated under the .terra TLD is the Rapid Takedown Policy described in the answer to Question 28. It allows a fast takedown of an offending site after respective activities were reported and confirmed.

In addition, the flexible rule engine used by the CORE Registration System to validate permissible .terra domain names can be utilised in the context of phishing. Should a certain .terra domain name (or a pattern of such names) be repeatedly involved in attempts to mimic a rights holderʹs legitimate .terra name for phishing purposes, the set of registration validation rules can be easily augmented to prevent the offending domain name (and, if need be, even an entire pattern of names deemed too similar to a rights holderʹs legitimate domain name) from being registered again after takedown. Of course, this practice will be exercised in close collaboration with ICANN and other parties potentially involved in the definition of names deemed not eligible for registration within the .terra TLD.

As described in the answer to Question 28, the sophisticated IDN handling implemented by the CORE Registration System is designed to provide protection against the most common cases of IDN-based phishing attempts, such as IDN homograph attacks. Please refer to the answers to Question 28, as well as Question 44, for more information on this topic.


2.4.2 Pharming

With regard to pharming, neither the quick takedown of offending domain names nor the blocking of such names are suitable as countermeasures. Due to the nature of the attack, the registryʹs approach needs to aim at a robust DNS infrastructure for .terra, which ideally should guarantee the integrity and authenticity of DNS lookup results all the way from the registry-operated TLD name servers to the userʹs local resolver.

As described in detail in the answer to Question 35, the .terra Registry will deploy a highly reliable and secure DNS subsystem for the .terra TLD, which is powered by the elaborate DNSSEC setup laid out in the answer to Question 43. The .terra Registry is therefore able to safeguard against any attempts to perform DNS manipulation on the level of the name servers operating the .terra zone.

However, due to the way the domain name system (and DNSSEC in particular) works, preventing manipulations of the .terra TLD name servers alone is not sufficient to avoid pharming attacks. In order to provide complete protection, DNSSEC support is required on every level of the domain resolution process, from the root zone via the TLD name servers and the delegated name servers down to a userʹs resolver. This means that registrars need to sign the zones they host on their name servers (and offer this service to their registrants), and resolvers (or other clients looking up .terra domain names) need to verify the signatures and notify their users when inconsistencies are detected. Consequently, the .terra Registry will encourage and advertise the widespread support and use of DNSSEC among registrars, registrants and end users. Once DNSSEC has been widely adopted, web browsers, e-mail clients and similar applications will increasingly support the verification of the related signatures out-of-the-box (rather than via the extensions available today), which will drastically diminish opportunities for pharming.

Since .terra is a brand TLD using a single-registrar, single-registrant model (with both being under the control of the .terra Registry), the support of DNSSEC on the delegated name servers for .terra names can and will be enforced. Also, end users within the control of .terra Registry (like its employees) will be required to install software for DNSSEC verification (such as extensions for web browsers or e-mail clients) where available.


2.5 Compliance with Dispute Resolution and Suspension Procedures

In case of complaints put forward by rights holders with regard to domain names registered under .terra, the .terra Registry will fully comply with all resolution procedures endorsed or mandated by ICANN. In particular, this includes supporting the Uniform Rapid Suspension (URS) procedures and the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP).

The .terra Registry is committed to implement decisions rendered under the URS. In particular, the .terra Registry will

* readily receive notifications about complaints (“Notice of Complaint”) from URS providers,
* lock the affected domain within 24 hours of receipt of the Notice of Complaint from the URS Provider, blocking all changes to the registration data, including transfer and deletion of the domain name (while retaining the domain name in the .terra zone, i.e. the name will continue to resolve),
* notify the URS Provider immediately upon locking the domain name (”Notice of Lock”).

Once the complaint was decided upon, the following steps will be taken:

* If registrant was relieved, the .terra Registry will unlock the domain and return full control to the registrant.
* In case of a determination in favour of the complainant, the .terra Registry will, in accordance with the URS rulings, immediately suspend the domain name and keep it suspended for the remainder of its registration period; this means that the domain will remain locked and that the domainʹs name servers are redirected to an information web page supplied by the URS provider. In this situation, .terra Registry will also make sure that the Whois output for the domain keeps displaying the original data (except for the altered name servers) and reflects that the domain name will not be able to be transferred, deleted or modified for the remainder of its registration period.
* The successful complainant will get the option to extend the registration period for one additional year at commercial rates.

In addition to these URS related procedures, the .terra Registry is also committed to take any necessary steps required to support decisions emerging from the Uniform Domain Name Dispute Resolution Policy (UDRP). After a respective complaint has been filed in a court of proper jurisdiction or with an approved dispute resolution service provider, the .terra Registry will implement all required measures arising from its function as a registry, including an immediate transfer of the domain to the legitimate rights holder (if the caseʹs determination is in the complainantʹs favour).

In case the .terra Registry becomes involved in a Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP), it will fully adhere to the general rules of the procedure as set out by ICANN, as well as the individual requirements defined by the Trademark PDDRP Provider. However, it should be noted that the .terra Registry has taken (and will continue to take) thorough precautions to ensure that a Trademark PDDRP will not become necessary. Nevertheless, should it become necessary, the .terra Registry will abide by the remedies recommended by the Expert Panel, and potential fees imposed.

The Registry Restrictions Dispute Resolution Procedure (RRDRP) is not relevant in the context of .terra, since .terra is not a community-based gTLD.


3. Sunrise and Landrush Policies for the .terra TLD

.terra is a so-called brand⁄institutional TLD using a single-registrar, single-registrant model for the exclusive use of the .terra Registry. Therefore, the protection of TMs and other rights is guaranteed, since the .terra Registry is committed to restrict its registration and use of names in the .terra TLD in a way that doesnʹt infringe on such rights, and no other parties are eligible to register .terra domains.

The TCS is implemented as described above to ensure that both the .terra Registry and rights holders are notified about registered domain names that potentially violate TMs stored in the TCH. The .terra Registry will abide by all requirements arising from the regulations of the TCS described above.

In addition, the compulsory Sunrise phase is conducted for 30 days after the registryʹs launch. However, the .terra Sunrise eligibility requirements clearly mandate that only the .terra Registry itself qualifies as an applicant, and only domain names for its own (or its affiliates) TMs, services, products, offerings or other legitimate interests are permissible as Sunrise registrations. Due to the exclusive use of by the registry, no contentions will occur, which means that no contention resolution strategies (such as auctions) are required for .terra.

Since the .terra TLD will not be open to any third-party registrations, no Landrush phase is required.


4. Resourcing Plans

The CORE Registration System already supports the rights protection features described above at the time of writing. No coding is required for this, which means that no special developing resources will be needed. The staff on duty at CORE will be in charge of performing manual reviews of TM data where required.

Since the TCH API is not fully defined at the time of writing, some software development will have to be done in order to integrate it into the Sunrise workflow and the TCS.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 5 man days
* System Administrator: configuring system for policies: 1 man day
* First Level Support: training: 4 man hours per person
* Software Developer: integration of TCH API: 10 man days

For the Sunrise phase, the following resources are allotted:

* First Level Support: 30 man days per month
* Second Level Support: 30 man days per month

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 1 man day per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.