Application number: 1-1346-3935 for League of Arab States

League of Arab States

General Secretariat for the League of Arab States
Tahrir Square,
Cairo 11642
EG

+202 25750511

+202 25740331

http:⁄⁄www.arableagueonline.org

Mr. Mohammed At-Twaijri

Assistant Secretary General for Economic Affairs

+202 25750511

aTLDcontact@las.int

Mr. Khaled Fouda

Manager for ICT Development

+202 27738092

aTLDsecondary@las.int

Regional Organization

Intergovernmental Organization

Not Available

H.E Dr. Mohammed At-Twaijri
Assistant Secretary General for Economic Affairs
H.E. Adnan Al-Khudair
Assistant Secretary General for Human Resources and Financial Affairs
H.E. Dr. Nabil Elaraby
Secretary General

arab

Not Available

The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the Registry Services for this TLD as provided by TRA.
Operational and rendering issues may arise with the delegation, and subsequent operation and use of a new TLD. Some of these issues may be experienced just by the users of one or two particular TLDs, due to the nature or composition of the string itself; whereas other issues (such as software support) may be experienced across all new TLDs.
Evaluation of the potential operational and rendering issues for this TLD was delegated to TRA. TRA is experienced with:
– The operational issues of operating TLDs
– TLDs that offer registrations at the third level (eg .co.ae, .gov.ae) and below
– The rendering and operational issues surrounding the introduction of IDNs
TRA has executed tests to evaluate any issues arising from the use of the TLD string. TRA configured a test environment that consisted of DNS software, web server software, and an email server configured for sample domains in this TLD. TRA also attempted to test many equivalent applications, however the number of and different versions of applications means that testing was limited to the most common environments.
Tests executed by TRA indicate that this TLD is subject to the same issues already experienced by TLDs in the root, which are neither new nor unique. A summary of these common issues is provided below:
- Some applications make assumptions about known valid TLDs and fail to recognise new TLDs
- Some Non-IDN aware applications require the user to provide input in A-labels
- Some IDN aware applications present the user with the domain name using A-labels instead of U-labels
- Some IDN aware applications fail to render URIs in a manner consistent with user expectations.
TRA will work with us to ensure that maintainers of applications are made aware of the delegation and operation of this TLD. When relevant, we will refer the maintainers to the verification code produced by ICANN in the area for Universal Acceptance of All Top Level Domains thereby mitigating operational issues for other TLDs.
TRA will with work us and maintainers of applications to provide subject matter knowledge, and provide directions to the tools provided by third parties such as the International Components for Unicode project and groups, that can assist the application maintainer in adding the required support. User education may be required enabling users to configure their applications for correct functioning of this TLD. An informational section on the TLD website will be considered to address questions raised by the Internet community.
The steps TRA will take to mitigate these issues are adequate. We do not believe this TLD raises stability concerns and should not be denied on an operational and rendering issues bases.

(a) Describe the mission ⁄ purpose of your proposed gTLD

The mission and purpose of the applied-for gTLD will be to: 

• promote the identity of Arabs and their diverse communities as well as the use of the Arabic language and script on the Internet;

• provide the members of the Arabic community as a whole with effective and dedicated means to communicate with each other and other users of the Internet, using their own identities, company and brand names, as well as generic domain names in a gTLD that expressly targets such community;

• provide for an alternative generic Internet top-level domain for the people, organizations, companies and governments of the Arab Region, next to the existing country-code top-level domains; 

• support and promote the Arabic culture on the global Internet, as well as the facilitation of economic, social and scientific integration and progress; and

• promote and operate a regional Internet namespace that has global recognition and caters to the needs of the community in the Arab region as well as Arabs worldwide.

The above objectives can be achieved by the League of Arab States, which will coordinate the development, implementation and management of the applied-for gTLD. 

The League of Arab States is a regional intergovernmental organization of 22 Arab states, with headquarters in Cairo, Egypt. Its primary goal is to draw closer the relations between its Member States and co-ordinate collaboration between them, to safeguard their independence and sovereignty, and to consider in a general way the affairs and interests of the Arab countries. 

The League was declared formally established when the then independent Arab countries signed the constituent instrument, the Charter, on March 22, 1945; i.e. nearly six months ahead of the setting up of the United Nations. In an historical perspective, the Charter of the League was indeed drafted in response to the common attitude of public opinion in all Arab countries. 

For one full half of a century, the League of Arab States has markedly managed to serve as ʺthe common house of Arabsʺ where Arabs call get together and exchange views on how best to enhance the future of the nation - a process which tacitly and in turn consolidates the functions of the League arid ensures that it be the creditable reflector of the policies of member states. 

The experience and performance of the League over the fifty years of its history, together with the regional and international developments, have all prompted the broadening of the scope of joint Arab action, the diversification of its areas and the creation of new institutions and mechanisms, which have in due course gained considerable effectiveness. Consequently, League activities have been so much expanded that they now cover almost all areas of essential importance for the Arab world.

Each Member State of the League retains the right to withdraw from the League on condition that its intention to do so be communicated to the Council at least six months ahead of the desired date of actual withdrawal. The Council of the League has the competence to declare dissociated any state that does not live up to its obligations as are defined in the Charter. Any resolution to this effect need be unanimously approved, excluding the vote of the state concerned. 

The Economic and Social Council for the League of Arab States is the unit responsible for all collaborative Arab efforts within the economic or social sectors, as well as supervising the functions of all units acting within its framework. It is also responsible to set general policies for Arab Eco-Social integration, and also to plan, and oversee programs related to its implementation.

The Arab Telecommunication and Information Council of Ministers (ATICM) is part of the structure of the Economic and Social Council for the League, responsible for all collaborative efforts between Arab States in the fields of ICT, including general strategies, infrastructure, services, regional and international cooperation. As declared by the Arab Summit, held in 2001 in Amman, the ATICM is also recognized as the highest executive authority responsible for the development of the Arab Information and Telecommunications Society.

Over the past years, the ATICM has been assigning tasks to specialized technical teams working within its structure to define the Arab gTLD Project, and will continue to do so in the months and years to come, as deemed appropriate. The Arab gTLD Project is framed in parallel with efforts to promote an Arabic Domain Names System focused on standardization for the use of Arabic script in domain names whether for the Arabic language in specific or for different languages using the Arabic script.

As part of this project, activities are underway for the establishment of a pan-Arab registry to manage and operate the new Arab gTLDs ʺ.arabʺ and its IDN equivalent in Arabic script ʺ.عربʺ. These activities are undertaken by LAS, particularly the Arab Working Group on Internet Issues (AWGII).

The League of Arab States is therefore considered to be the Applicant for the applied-for gTLD, and – following ICANN’s delegation of the TLD to the League – will become the Registry Operator. However, the League has decided to delegate the actual operation of the Arab gTLDs to TRA following delegation by ICANN of the applied-for gTLD to the League. Therefore, TRA will be managing and operating the Arab gTLD(s) following delegation by ICANN thereof to the League, in the name of the League, but for its own account. This arrangement has been laid down in an agreement entered into between both organizations.

The League of Arab States has submitted applications for two gTLDs, which both focus on the Arab community, region, language, and culture: one TLD in standard Latin script ⁄ US ASCII, and one in Arabic script ⁄ IDN. Both TLDs are hereinafter referred to as the “Arab gTLDs”.

The Arab gTLDs have the objective to provide for an alternative (in Latin and Arabic script) Internet top-level domain for the people, organizations, companies and governments of the Arab Region. In addition, it aims to support and promote the Arabic language and culture on the global Internet, as well as the facilitation of economic, social and scientific integration and progress.

The League’s main objective is to promote and operate a regional Internet namespace that has global recognition and caters to the needs of the community in the Arab region as well as Arabs worldwide.

The League of Arab States provides oversight and guidance. Therefore, the League of Arab States has the mission to promote the Arab community’s identity as well as the use of the Arabic language on the Internet, by providing access to domain name registration systems that support the Arabic community and provide the members of this community with effective means to communicate with each other as well as other users of the Internet using their own identities, brand names, trademarks and proprietary TLDs.

The pioneering role of the League of Arab states in the Arab gTLDs is considered to be of great importance, giving legitimacy to both gTLDs from both a governance, cultural and organizational perspective.

With respect to the IDN gTLD, domain name registrations in the applied-for gTLD will be in Arabic script only, which provides domain name registrants and Internet users at large with the opportunity to use Arabic only domain names in Internet communications, and hence promote the Arabic region as a whole. 

This offering is similar to what the .EU registry – EURid – is doing within Europe and, to a certain extent, how the DotAsia Organization is trying to position its activities and posture within the Asian-Pacific continent.

In order to reflect the specific focus and character of the Arab gTLDs, the Registry Operator will implement the following eligibility requirements for domain name registrants in either of the two Arab gTLDs, which shall be incorporated in the domain name registration policies of both extensions:

The Registry shall register domain names in one or both Arab TLDs through any Registrar requested by any:

(i) undertaking having its registered office, central administration or principal place of business within the Community, or

(ii) organization established within the Community without prejudice to the application of national law, or

(iii) natural person resident within the Community, or

(iv) any of the above who has associated one of the contacts relating to the domain name registration, which contact is residing or established in the Community.

The term “Community” will be deemed to include the territories of the Member States of the League of Arab States.

The League of Arab States defines the word “Arab” as “a person whose language is Arabic, who lives in an Arabic speaking country, who is in sympathy with the aspirations of the Arabic speaking people”. In the virtual world, out of the estimated 347,000,000 people who speak Arabic, only 5.4% use the Internet. With this percentage, the Arabic language holds the 7th place in the top ten languages used in the web (about 65 million Internet users) but it holds the 5th place according to the estimated number of population. 

The Arabic language has been the fastest growing language on the Internet over the past decade, with an increase of more than 2,500%.

According to a 2009 estimate, the population of the member states of the LAS amounts to more than 360 million. 

The Registry Operator will, following award of at least one of the Arab gTLDs to the League of Arab States, provide for the following measures in order to protect the privacy of registrants in such gTLD:

First of all, it will restrict automatic access to and harvesting of WHOIS data, by:

- implementing a CAPTCHA process following receipt of a web-based WHOIS query; and
- limiting the number of queries per IP address for a given period of time (both web and port 43).

Furthermore, the Registry Operator will enable registrants not to disclose certain information through the public WHOIS, and limit such information to what is strictly necessary in order to comply with ICANN’s requirements. If, for a valid reason (e.g., following request by a competent public authority, or if there is a risk that a particular domain name that is registered in the TLD infringes the trademark rights of a third party), the Registry Operator will in any case promptly disclose full contact data. 


The LAS has developed a detailed action plan for the .ARAB registry, which will ensure that potential domain name registrants from the Arab Region and beyond are made aware of the .ARAB initiative, and what they need to do in order to register domain names in these new extensions. This action plan has been developed in the context of a Pre-Feasibility Study commissioned by UN-ESCWA, as well as in the Charter that has been adopted by the .ARAB Steering Committee in 2011.

Below, we will elaborate on the high-level steps that will be taken in order to effectively market the TLDs, taking into account where possible the issues and constraints identified above. It is believed to be key for the success of the .ARAB Project that a number of these steps are taken as soon as possible, even prior to the submission of the applications to ICANN.

1. Pre-Delegation Phase

The LAS has identified the following organizations that can play a role in creating awareness about the .ARAB Project, of which some of them can be very actively involved in the ultimate success of the Registry and its operations. In addition thereto, a number of action points have been formulated in order to achieve this objective.

1.1. Ministers and Ministries of Telecommunication represented in the League of Arab States

It is important for the success of the .ARAB Project that it obtains sufficient government support from the Member States of the League of Arab States. Following award of the applied-for gTLD, the Registry Operator will develop a high-level action plan together with each of the Ministers of Telecommunication of the Member States of the LAS.

1.2. Telecom operators active in the Arab Region

Telecom operators have an enormous client base with people, organizations and companies that will have – in one way or another – an interest in registering domain names within the Arab TLDs.

Given such large client base, there may be an opportunity for such actors to apply with ICANN to become an ICANN Accredited Registrar or Reseller, as this can bring in additional business for them. Additionally, such status could support such telecom operators to expand their business in other countries in the Arab Region, and in particular in other Member States of the League of Arab States.

Even if these organizations would not be interested in such an activity, liaising with them (on a regular ⁄ continuous basis) will allow the League of Arab States to raise awareness regarding the .ARAB Project, and may incite some of them to be involved in this project further down the road in, perhaps, another capacity (such as acting as a Reseller).

1.3. ccTLD registries in the Arab Region

The LAS has determined on various occasions that the (timely) involvement of ccTLD registries in the Arab Region is crucial for the success of the .ARAB Project. In order to allow these registries not only to become “morally” involved, but also reap part of the (financial, technical and operational) benefits of this initiative, appropriate steps will be taken in order to ensure such involvement. 

Given the fact that many ccTLD registries of the Arab Region have actively participated in the preparation of the .ARAB TLD project and the preparation of this application for the .ARAB gTLD, it is clear that the LAS enjoys a lot of goodwill from their end in order to make this project a success.

1.4. Domain name registrars with ccTLDs in the Arab Region

Although the requirements for becoming an ICANN Accredited Registrar could be too cumbersome for many existing registrars with ccTLDs in the Arab Region, the LAS (and existing ccTLD operators within the Arab Region) should be able to identify a few organizations that could be “thought leaders” in the .ARAB initiative. Therefore, LAS and ccTLD operators within the Arab Region will provide for guidance and advice in order for these registrars to become ICANN Accredited Registrars.


1.5. Existing ICANN Accredited Registrars from outside the Arab Region

The Registry may opt to convince a number of large ICANN Accredited Registrars to set up an operation in the region, and provide operational and marketing support to them in order to effectively reach out to its targeted community.

This operation will consist of providing access to a web site dedicated to the .ARAB gTLDs, and have staff on the ground promoting the registration and adoption of domain names in these TLDs to businesses, organizations and individuals within the region.

2. Delegation Phase
2.1. Introduction

The Registry Operator, working closely with its selected registry back-end services provider, will develop a detailed marketing and outreach plan, in order to make sure that the .ARAB gTLDs are adequately promoted and a sustainable registry operation is guaranteed. This plan will be developed and rolled out following award of the gTLD to the League of Arab States.

This Marketing & Outreach Plan will in any case be a working document, which will need to be adapted to the specific needs and circumstances that arise following the delegation of the first Arab TLD to the League of Arab States. 

In particular, detailed plans will be drawn up in order to market these gTLDs within the Arab Region, creating a workable competition amongst ICANN Accredited Registrars, considering that only few of them have actually deployed activities within the Arab Region. Furthermore, this plan shall take into consideration the development of the domain name market at that time.

2.2. Draft High-Level Marketing & Outreach Plan

During the Delegation Phase, the Registry Operator’s Marketing & Outreach Plan will cover the following aspects:

- attendance at or co-ordination of a to be agreed upon number of major events at which presentations will be made to members of the IP community, the Registrar community, and the domain name community, including ICANN meetings;

- drafting of a General Information and RPM (Rights Protection Mechanisms) section of the Registry’s website, including materials for other relevant web sites (e.g. ccTLD registries in the Arab Region, registrars, resellers, …);

- drafting of a Registrar website focused on the .ARAB launch and RPMs;

- drafting of detailed information sheets for Accredited Registrars, IP owners, and the domain name community at large;

- drafting of presentations materials and brochures for IP owners, law firms, trademark attorneys and Registrars;

- the preparation of information that can be used in briefing sheets for the general and specialized press.

All of the above tasks need to be executed and⁄or supervised by a dedicated resource appointed by or under the authority of the Registry Operator.

2.3. Language Aspects

Taking into account the fact that many members of the LAS’ targeted distribution networks and Community (i.e. individuals, companies and organizations that are using the Arab language) may reside or be established abroad, the Registry should effectively reach out to ICANN Accredited Registrars in order to obtain the necessary marketing support outside the LAS region.

Since most of these registrars will not master the Arab language, specific information and marketing packages and initiatives need to be developed in order to make sure that such targeted Community members obtain all the necessary information in order to effectively register domain names in the .ARAB gTLDs.

3. Launch Phase
3.1. Introduction

An important element in the launch of any TLD is the provision, by or on behalf of the Registry Operator, of detailed and accurate information with respect to the policies it is going to implement, the processes that will accompany the launch of the TLD, and the pricing charged to Registrars. These three elements need to be clearly defined in detailed information memoranda and legal terms before they are distributed to Registrars, the intellectual property community and the public at large.

In order to ensure that an adequate marketing campaign is being set up, the Registry Operator will develop and implement a Marketing & Outreach Plan that takes the following aspects into account: 

- designing clear, unambiguous information for the relevant stakeholders, including the intellectual property community (with respect to the Sunrise aspects), the domainer community (with respect to the Landrush aspects) and Registrars;

- consult with these stakeholders, and do regular follow-ups with them;

- tracking and identifying any outreach campaigns these stakeholders are organising;

- trying to be involved in any marketing, consultation, information, … activities organised by these stakeholders, and provide them with regular reporting on new information that is going to be released before it is actually released;

- etc.

3.2. General Marketing & Outreach Activities

Marketing & Outreach Activities during the Execution Phase include:

- updating of the General Information website including RPM FAQ;

- organization⁄participation in web seminars ⁄ webcasts for IP owners, the domain name community;

- attendance at or co-ordination of events for the IP and domain name communities;

- attendance⁄co-ordination of events for Registrars and their clients;

- co-ordinate an e-newsletter for Registrars covering general points of information, updating them on dates, FAQ answers, etc.;

- meetings and briefings of the general media and specialized press with the Registry.

3.3. Involvement of telecom operators, ccTLD registries and their registrars

In order for the .ARAB gTLD to be successful in terms of numbers of domain name registrations, the LAS might reach out to the ccTLD operators of its member states in order to support the initiative. Such support could consist of any of the following:

- marketing the .ARAB gTLD to its customer base, by organizing seminars, sending mailings to registrars and domain name registrants, etc.;

- offering domain names in the .ARAB gTLD together with registrations in their own ccTLD;

- actively promoting the .ARAB gTLD on their respective web sites;

- etc.

In this respect, the Registry Operator’s dedicated Marketing Manager will need to play a liaison function between ccTLD operators on the one hand and ICANN Accredited Registrars on the other hand in order to make sure that the .ARAB gTLDs are properly marketed. 

3.4. Accredit Registrars

Once delegated the applied-for gTLD, the LAS will be required to accredit ICANN Accredited Registrars in order to effectively offer domain name registrations in these new gTLDs.

A dedicated resource, appointed by or on behalf of the Registry Operator, will forge relationships with the .ARAB Accredited Registrars. The Registry Operator’s dedicated Marketing Manager will have the task to provide detailed information to them, and keep them updated on new developments, promotions, etc.

First of all, the gTLD will be launched using a lengthy and thorough start-up process, which will likely consist of the following steps:

• Pre-Sunrise: Solicitation of reserved domain names from ccTLDs and governments (through GAC representatives, through the ccTLD registry operators, etc.). The duration could range from 60 days up to one year.

• Sunrise I: Corresponding governments and⁄or relevant entities may ʺactivateʺ domains from the reserved domains list obtained during Pre-Sunrise on a First-Come-First-Served basis. However, this step maybe skipped; governments can, after the launch of the gTLD, decide at any time when to activate the domains on the reserved list. Approximate duration: 60 days.

• Sunrise II: Public bodies, holders⁄licensees of trademarks, holders of other prior rights (such as company names, trade names, business identifiers, personal names, …) may apply for domain names based on the names for which they hold prior rights. Approximate duration: 90 days, although this period can be shortened in case ICANN would decide to implement the IPR Clearinghouse that was proposed by the Implementation Recommendation Team.

• Quiet Period: No registration period. Approximate duration: 30 days. The Quiet Period can be shortened or even abandoned in case ICANN would decide to implement the recommendation to set up an IPR Clearinghouse, which would automatically validate prior right claims on domain names during Sunrise II.

• Landrush: Anyone that meets the charter eligibility requirements may apply for any domain name. Approximate duration: 15 days.

• Auction: For domains that received more than one valid application during Sunrise II and Landrush, closed auctions will be held for all competing applicants. This can run in parallel to phases 3-5. Approximate duration: 30 days.

• Go Live: live First-Come-First-Served registrations commence.

This well-structured start-up process has been developed with the objective in mind to minimize the risk that significant (social) costs will be incurred as a result of the launch of the Arab gTLDs.

Secondly, the Registry Operator and, in particular, its selected back-end registry services provider will, prior to the launch, already have engaged in marketing activities, as described above. Therefore, chances are high that the initially targeted community (Arabs that are connected to the Internet) will have learned about the Arab gTLDs and have prepared themselves in order to secure domain names in this new extension.


i. How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

As indicated above, a mix of auction-based and first-come, first-served allocation models will be used, depending on the phase of operations.

The principle of “first-come-first-served” will be the basic principle for resolving a dispute between holders of prior rights after the phased registration period; for conflicting domain name applications submitted during a particular phase in the phased registration period, an auction system is proposed. After the termination of the phased registration, the principle of first come first served will apply in the allocation of domain names.


ii. Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

No particular cost benefits have been foreseen by the Registry Operator at this stage.


iii. Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

The League of Arab States or TRA will not allow domain name registrations for periods of more than ten years. Currently, they also do not envisage any price increases, and, if such increases should be necessary, it will provide an advance written notice to all registrars, as set out by ICANN.

Given the fact that the actual success of the Arab gTLDs in terms of volume is unclear at this stage, the League nor TRA will make any commitments as regards the stability of its registry fees in the medium or long term.


officially decided in their meeting of July 2008, following ICANN meeting in Paris, to proceed with the necessary steps to apply for both domain names. LAS also formed a “Steering Committee of the Arab gTLD Project” to work on and oversee the project steps, with advisory technical assistance from ITU and ESCWA for the practical implementation of such a registry. 

A Preliminary Feasibility study on Establishment of the Domain Name Registry for the “.arab” and “.عرب” Generic Top Level Domains was developed to provide an initial assessment of the viability of establishing a domain name registry for the ʺ.arabʺ and .عربʺ” gTLDs through studying relevant technical and operational requirements and over viewing business, marketing, legal, financial and capital funding aspects related to establishing this registry.

This Preliminary Feasibility study was submitted for revision at LAS meetings and was endorsed accordingly although proposed institutional⁄governance structures of the registry remained open for discussion. The study also provides a high-level plan for forthcoming tasks and milestones. 

LAS AWGII also defined administrative, legal, technical, operational, financial, and business terms and conditions that should be applied to the organization⁄corporation that is going to be selected to manage the Arab gTLDs registry, in the form of “LAS Preliminary Guidelines” document. Decisions that have been taken as regards the governance, operation, structure and setup have been laid down in a document that is referred to as “The Arab TLD Charter: A Strategic Framework for Defining, Implementing and Managing the Arab gTLDs (2010 – 2014)”, which has been prepared by UN-ESCWA in 2010 and is updated on a regular basis, keeping pace with policy and implementation developments within ICANN.


(a) Provide a description of the community-based purpose of the applied-for gTLD;

Considering the above, it is clear that the LAS has the mission to promote the Arab community’s identity as well as the use of the Arabic language on the Internet. 

The .ARAB initiative forms an indispensable cornerstone in this respect, as this will enable physical persons, organizations and companies in the Arab Region with access to domain name registration systems that support the Arabic community and provide the members of this community with effective means to communicate with each other as well as other users of the Internet using their own identities, brand names, trademarks and proprietary TLDs.


(b) Explain the relationship between the applied- for gTLD string and the community identified in 20(a).

The .ARAB TLD refers to various aspects that unambiguously and undisputedly identify and characterize the members of the Arab community:

- language: one of the common denominators of most physical persons, organisations and companies in the Arab Region is that they communicate in Arabic, next to a number of other languages; 

- script: the Arabic script is one of the first comprehensive scripts that have been developed by man and is currently still being used by hundreds of millions of people within and outside the Arab Region;

- culture: the Arab culture is one of the first cultures that have been established, and is currently still in existence and experienced throughout the world.


(c) Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.

Arab gTLDs will be open for registrants who are residents of, established, incorporated or having their principal place of business in one of the 22 Member States of the LAS. This geographic nexus requirement is inspired LAS’ authority described in its founding documents, which is in any case geographically limited to the 22 Member States of LAS. The selected Candidate will be required in this regard to verify compliance with this requirement post registration, and this for a random sample of 1% of the total number of domain name registration volume, on a periodical basis (preferably on a quarterly basis).

Furthermore, Arab gTLDs registrants should have the right to choose to register one or more domain names in only one or both gTLDs. The registry will not automatically “bundle” or “package” domain name registrations.

The registry will also put in place a dynamic list containing reserved domain names (for the registry and for governmental authorities) and blocked domain names (e.g., for domain names that are considered unlawful, or immoral) with the possibility of wildcarding (i.e., provide for the possibility that domain names containing a string that is mentioned in the list of blocked or reserved domain names cannot be registered). 

To be included by TLD Manager: a description of the process and policy for the management of this list, and for requests for including additional domain names on it.

Moreover, all data relevant to registry operations of Arab TLDs will be the exclusive property of LAS. 

No

Not Available

No

The League of Arab States (LAS) have engaged Telecommunications Regulatory Authority UAE (TRA) to deliver services for this TLD. This response describes protection of geographic names as implemented by TRA.

1 PROTECTION OF GEOGRAPHIC NAMES

In accordance with Specification 5 of the New gTLD Registry Agreement, the registry operator must initially reserve all geographic names at the second level, and at all other levels within the TLD at which the registry operator provides for registrations.
TRA supports this requirement by using the following internationally recognised lists to develop a comprehensive master list of all geographic names that are initially reserved:
– The 2-letter alpha-2 code of all country and territory names contained on the ISO 3166-1 list, including all reserved and unassigned codes [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm].
– The short form (in English) of all country and territory names contained on the ISO 3166-1 list, including the European Union, which is exceptionally reserved on the ISO 3166-1 List, and its scope extended in August 1999 to any application needing to represent the name European Union [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU].
– The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardisation of Geographical Names, Part III Names of Countries of the World. This lists the names of 193 independent States generally recognised by the international community in the language or languages used in an official capacity within each country and is current as of August 2006 [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn%20tech%20ref%20manual_M87_combined.pdf].
– The list of UN member states in six official UN languages prepared by the Working Group on Country Names of the United Nations Conference on the standardisation of Geographical Names [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄UNGEGN⁄docs⁄9th-uncsgn-docs⁄econf⁄9th_UNCSGN_e-conf-98-89-add1.pdf].
Names on this reserved list in TRA’s registry system are prevented from registration.
A corresponding list of geographic names will also be available to the public via the registry operators website, to inform Registrars and potential registrants of reserved names. The lists noted above, are regularly monitored for revisions, therefore the reserved list (both within the registry and publicly facing) will be continually updated to reflect any changes.
In addition to these requirements, TRA are able to support the wishes of the Governmental Advisory Council (GAC) or any individual Government in regard to the blocking of individual terms on a case by case basis. TRA’s registry system allows such additions to be made by appropriately authorised staff, with no further system development changes required.
The following applies to all Domain Names contained within the registry’s reserved list:
– Attempts to register listed Domain Names will be rejected.
– WhoIs queries for listed Domain Names will receive responses indicating their reserved status.
– Reserved geographic names will not appear in the TLD zone file.
– DNS queries for reserved domain names will result in an NXDOMAIN response.

2 PROCEDURES FOR RELEASE

We understand that if we wish to release the reserved names at a later date, this will require agreement from the relevant government(s) or review by the GAC, and subsequent approval from ICANN. 

The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the Registry Services for this TLD as provided by TRA.


1 REGISTRY SERVICES

The following sections describe the registry services provided. Each of these services has, where required, been designed to take into account the requirements of consensus policies as documented here:
[http:⁄⁄www.icann.org⁄en⁄resources⁄Registrars⁄consensus-policies] 

1.1 Receipt of Data from Registrars

The day-to-day function of the Registry, as perceived by Internet users, involves the receipt of data from Registrars and making the necessary changes to the Shared Registry System (SRS) database. Functionality such as the creation, renewal and deletion of domains by Registrars on behalf of Registrants is provided by two separate systems:
– An open protocol-based provisioning system commonly used by Registrars with automated domain management functionality within their own systems.
– A dedicated website providing the same functionality for user interaction.

Registrants (or prospective Registrants) who wish to either manage their existing domains or credentials, register new domains or delete their domains, will have their requests carried out by Registrars using one of the two systems described below.

TRA operates Extensible Provisioning Protocol (EPP) server software and distributes applicable toolkits to facilitate the receipt of data from Registrars in a common format. EPP offers a common protocol for Registrars to interact with SRS data and is favoured for automating such interaction in the Registrar’s systems. In addition to the EPP server, Registrars have the ability to use a web-based management interface (SRS Web Interface), which provides functions equivalent to the EPP server functionality.

1.1.1 EPP

The EPP software allows Registrars to communicate with the SRS using a standard protocol. The EPP server software is compliant with all appropriate Requests for Comments (RFCs) and will be updated to comply with any relevant new RFCs or other new standards, as and when they are finalised. All standard EPP operations on SRS objects are supported.

Specifically, the EPP service complies with the following standards:
– RFC 5730 Extensible Provisioning Protocol (EPP).
– RFC 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping.
– RFC 5732 Extensible Provisioning Protocol (EPP) Host Mapping.
– RFC 5733 Extensible Provisioning Protocol (EPP) Contact Mapping.
– RFC 5734 Extensible Provisioning Protocol (EPP) Transport over TCP.
– RFC 5910 Domain Name System (DNS) Security Extensions for the Extensible Provisioning Protocol (EPP).
– RFC 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP).
– Extensions to TRA’s EPP service comply with RFC 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP).

1.1.1.1 Security for EPP Service

To avoid abuse and to mitigate potential fraudulent operations, the EPP server software employs a number of security mechanisms which restrict the source of incoming connections and prescribe the authentication and authorisation of the client. Connections are further managed by command rate limiting and are restricted to only a certain number for each Registrar, in order to reduce unwanted fraudulent and disingenuous activities. Additionally, secure communication to the EPP interface is a requirement, lowering the likelihood of the authentication mechanisms being compromised.

The EPP server has restrictions on the operations it is permitted to make to the data within the Registry database. Except as allowed by the EPP protocol, the EPP server cannot update the credentials used by Registrars for access to the SRS. These credentials include those used by Registrars to login to TRA’s SRS Web Interface and the EPP service.

Secure communication to the EPP server is achieved via the encryption of EPP sessions. The Registry system and associated toolkits support AES 128 and 256 via TLS.

The Production and Operational Testing and Evaluation (OTE) EPP service is protected behind a secure firewall that only accepts connections from registered IP addresses. Registrars are required to supply all of the host IP addresses that they intend to use to access the EPP service.

Certificates are used for encrypted communications with the Registry. Registrars require a valid public⁄private key pair signed by the TRA Certificate Authority (CA) to verify authenticity. These certificates are used to establish a TLS secure session between client and server.

EPP contains credential elements in its specification which are used as an additional layer of authentication. In accordance with the EPP specification, the server does not allow client sessions to carry out any operations until credentials are verified.

The EPP server software combines the authentication and authorisation elements described above to ensure the various credentials supplied are associated with the same identity. This verification requires that:
– The username must match the common name in the digital certificate.
– The certificate must be presented from a source IP listed against the Registrar whose common name appears in the certificate.
– The username and password must match the user name and password listed against the Registrar’s account with that source IP address.

To manage normal operations and prevent an accidental or intentional Denial of Service (DoS), the EPP server can be configured to rate limit activities by individual Registrars.

1.1.1.2 Stability Considerations

The security measures that restrict Registrars to a limit of connections and operations also serve to keep the SRS and the EPP server within an acceptable performance and resource utilisation band. Therefore, scaling the service is an almost linear calculation based on well-defined parameters.

The EPP server offers consistent information between Registrars and the SRS Web Interface, with the relevant pieces of this information being replicated to the DNS within seconds of alteration; thus ensuring that a strong consistency between the SRS and DNS is maintained at all times.

1.1.2 SRS Web Interface

The Registry SRS Web Interface offers Registrars an alternative SRS interaction mechanism to the EPP server. Available over HTTPS, this interface can be used to carry out all operations which would otherwise occur via EPP, as well as many others. Registrars can use the SRS Web Interface, the EPP server interface or both — with no loss of consistency within the SRS.

1.1.2.1 Security and Consistency Considerations for SRS Web Interface

The SRS Web Interface contains measures to prevent abuse and to mitigate fraudulent operations. By restricting access, providing user level authentication and authorisation, and protecting the communications channel, the application limits the opportunity and scope of security compromise.

Registrars are able to create individual users that are associated with their Registrar account. By allocating the specific operations each user can access, Registrars have full control over how their individual staff members interact with the SRS. Users can be audited to identify which operations were conducted and to which objects those operations were applied.

A secure connection is required before credentials are exchanged and once authenticated. Upon login, any existing user sessions are invalidated and a new session is generated, thereby mitigating session-fixation attacks and reducing the possibility that sessions could be compromised.

1.1.3 Securing and Maintaining Consistency of Registry-Registrar Interaction Systems

TRA ensures all systems through which Registrars can interact with the SRS remain consistent with each other and apply the same security rules. Additionally, TRA also ensures that operations on SRS objects are restricted to the appropriate entity. For example:
– In order to initiate a transfer, a Registrar must provide the associated domain password (authinfo) which will be known only by the Registrant and the current sponsoring Registrar.
– Only sponsoring Registrars are permitted to update Registry objects.

All operations conducted by Registrars on SRS objects are auditable and identifiable to the specific Registrar’s user account, their IP address and the time of the operation.

1.2 Disseminate Status Information of TLD Zone Servers to Registrars

The status of TLD zone servers and their ability to reflect changes in the SRS is of vital importance to Registrars and Internet users alike. TRA will ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication may be prior to the status change, during the status change and⁄or after the status change (and subsequent reversion to normal) — as appropriate to the party being informed and the circumstance of the status change. Normal operations are those when:
– DNS servers respond within SLAs for DNS resolution.
– Changes in the SRS are reflected in the zone file according to the DNS update time SLA.

The SLAs are those from Specification 10 of the Registry Agreement.
A deviation from normal operations, whether registry-wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

1.2.1 Communication Policy

TRA maintains close communication with Registrars regarding performance and consistency of the TLD zone servers. A contact database containing relevant contact information for each Registrar is maintained. In many cases, this will include multiple forms of contact including email, phone and physical mailing address. Additionally, up-to-date status information of the TLD zone servers is provided within the SRS Web Interface.

Communication using the Registrar contact information discussed above will occur prior to any maintenance performed with the potential to effect the access to, consistency of, or reliability of the TLD zone servers. If such maintenance is required within a short time frame, immediate communication occurs using the above contact information. In either case, the nature of the maintenance, how it affects the consistency or accessibility of the TLD zone servers and the estimated time for full restoration are included within the communication.

The TLD zone server infrastructure has been designed in such a way that no down time is expected. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate at 100% availability.

1.2.2 Security and Stability Considerations

TRA restricts zone server status communication to Registrars, thereby limiting the scope for malicious abuse of any maintenance window. Additionally, TRA ensures Registrars have effective operational procedures to deal with any status change affecting the TLD name servers and will seek to align its communication policy with those procedures.

1.3 Zone File Access Provider Integration

Individuals or organisations who wish to have a copy of the full zone file can do so using the Zone Data Access service. This process is still evolving; however the basic requirements are unlikely to change. All registries will publish the zone file in a common format that is accessible via secure File Transfer Protocol (FTP) at an agreed URL. TRA will fully comply with the processes and procedures as dictated by the Centralised Zone Data Access (CZDA or what it evolves into) Provider for adding and removing Zone File access consumers from authentication systems. This includes:
– Zone file format and location.
– Availability of the zone file access host via FTP.
– Logging of requests to the service (including the IP address, time, user and activity log).
– Access frequency.

1.4 Zone File Update

To ensure changes within the SRS are rapidly and securely reflected in the zone file, TRA updates the zone file on the TLD zone servers using software compliant with RFC 2136 (Dynamic Updates in the Domain Name System (DNS UPDATE)) and RFC 2845 (Secret Key Transaction Authentication for DNS (TSIG)).

This updating process follows a staged but rapid propagation of zone update information from the SRS, outwards to the TLD zone servers – which are visible to the Internet. As changes to the SRS data occur, those changes are updated to isolated systems which act as the authoritative Primary server for the zone, but remain inaccessible to systems outside TRA’s network, with the exception of externally located secondary services (discussed in 2.5). The primary servers notify the designated Secondary servers, which service queries for the TLD zone from the public. Upon notification, the secondary servers transfer the incremental changes to the zone and publically present those changes.

The protocols for dynamic update are robust and mature, as is their implementation in DNS software. The protocols’ mechanisms for ensuring consistency within and between updates are fully implemented in TRA’s TLD zone update procedures. These mechanisms ensure that updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions. Mechanisms separate to RFC 2136-compliant transfer processes exist in order to ensure domain information is consistent with the SRS on each TLD zone server within 10 minutes of a change.

1.5 Operation of Zone Servers

TRA uses ARI Registry Services (ARI) to deliver DNS services for the TLD. The following section describes ARI’s TLD zone server service.

1.5.1 Security and Operational Considerations of Zone Server Operations

The TLD zone servers comply with all relevant RFCs for DNS, DNSSEC and BCPs for the operation and hosting of DNS servers. The TLD zone servers will be updated to support any relevant new enhancements or improvements adopted by the IETF.

The DNS servers are geographically dispersed across multiple secure data centres in strategic locations around the world. By combining multi-homed servers and geographic diversity, ARI’s zone servers remain impervious to site level, supplier level or geographic level operational disruption.

The TLD zone servers are protected from loss in accessibility by malicious intent or misadventure via the provision of significant over-capacity of resources and access paths. Multiple independent network paths are provided to each TLD zone server, and the query-servicing capacity of the network exceeds the extremely conservatively anticipated peak load requirements by at least 10 times, in order to prevent loss of service should query loads significantly increase.

As well as the authentication, authorisation and consistency checks carried out by the Registrar access systems and DNS update mechanisms, TRA reduces the scope for alteration of DNS data by following strict DNS operational practices:
– Requirement that ARI TLD zone servers are not shared with other services.
– TRA’s primary authoritative TLD zone server is inaccessible from outside their network with the strict and only exception of ARI’s TLD zone server network.
– TLD zone servers only serve authoritative information.
– The TLD zone is signed with DNSSEC and a published DNSSEC Practice⁄Policy Statement.

1.6 Dissemination of Contact or Other Information

Registries are required to provide a mechanism to identify the relevant contact information for a domain. The traditional method of delivering this is via the WhoIs service, a plain text protocol commonly accessible on TCP port 43. TRA also provides the same functionality to users via a web-based WhoIs service. Functionality remains the same with the web-based service, which only requires a user to have an Internet browser.

Using the WhoIs service, in either of its forms, allows a user to query for domain-related information. Users can query for domain details, contact details, nameserver details or Registrar details. A WhoIs service which complies with RFC 3912 is provided to disseminate contact and other information related to a domain within the TLD zone.

1.6.1 Security and Stability Considerations

TRA ensures the service is available and accurate for Internet users, while limiting the opportunity for its malicious use. Many reputation and anti-abuse services rely on the availability and accuracy of the WhoIs service, however the potential for abuse of the WhoIs service exists.

Therefore certain restrictions are made to the access of WhoIs services, the nature of which depend on the delivery method – either web based or the traditional text based port 43 service. In all cases, there has been careful consideration given to the benefits of WhoIs to the Internet community, as well as the potential harm to Registrants as individuals and a group, with regard to WhoIs access restrictions.

The WhoIs service presents data from the Registry Database in real time. However this access is restricted to reading the appropriate data only. The WhoIs service does not have the ability to alter data or to access data not related to the WhoIs service. The access limitations placed on the WhoIs services prevent any deliberate or incidental denial of service which might impact other Registry Services.

Restrictions placed on accessing WhoIs services do not affect legitimate use. All restrictions are designed to target abusive volume users, and to provide legitimate users a fast and available service. TRA has the ability to white list legitimate bulk users of WhoIs to ensure they are not impacted by standard volume restrictions.

The data presentation format is consistent with the canonical representation of equivalent fields as defined in the EPP specifications and ICANN agreement.

1.6.1.1 Port 43 WhoIs

A port 43-based WhoIs service that complies with RFC 3912 is provided and will be updated to meet any other relevant standards or best practice guidelines related to the operation of a WhoIs service.

While the text-based service can support thousands of simultaneous queries, in order to restrict data mining efforts, it has dynamic limits on queries per IP address. In the event of identified malicious use of the service, access from a single IP address or address ranges can be limited or blocked.

1.6.1.2 Web Based WhoIs

TRA’s web-based WhoIs service provides information that is consistent with that contained within the SRS. The web based WhoIs service contains an Image Verification Check (IVC) and query limits per IP address. These restrictions strike a balance between acceptable public usage and abusive use or data mining. The web based WhoIs service can blacklist IP addresses or ranges to prevent abusive use of the service.

1.7 IDNs — Internationalised Domain Names

An Internationalised Domain Name (IDN) allows registrants to register domains in their native language and have it display correctly in IDN-aware software. This includes allowing a language to be read in the manner that would be common for its readers. For example, an Arabic domain would be presented right to left within an Arabic IDN aware browser.

The inclusion of IDNs into the TLD zones is supported by TRA. All of the Registry services, such as the EPP service, SRS Web Interface and Registration Data Directory Services (RDDS) (web and port 43) support IDNs. However there are some stability and security considerations related to IDNs, which fall outside the general considerations applicable individually to those services.

1.7.1 Stability Considerations Specific to IDN

To avoid the intentional or accidental registration of visually-similar chars, and to avoid identity confusion between domains, there are several restrictions on the registration of IDNs.

1.7.1.1 Prevent Cross Language Registrations

Domains registered within a particular language are restricted to just the chars of that language. This avoids the use of visually-similar chars within one language, which mimic the appearance of a label within another language, regardless of whether that label is already within the DNS or not.

1.7.1.2 Inter-language and Intra-language Variants to Prevent Similar Registrations

TRA restricts child domains to a specific language and prevents registrations in one language being confused with a registration in another language, for example Cyrillic а (U+0430) and Latin a (U+0061).

1.8 Domain Name System Security Extensions (DNSSEC)

DNSSEC provides a set of extensions to the DNS that allows an Internet user (normally the resolver acting on a user’s behalf) to validate that the DNS responses they receive were not manipulated en-route.

This type of fraud, commonly called ‘man in the middle’, allows a malicious party to misdirect internet users. DNSSEC allows a domain owner to sign their domain and to publish the signature, so that all DNS consumers who visit that domain can validate that the responses they receive are as intended by the domain owner.
Registries, as the operators of the parent domain for registrants, must publish the DNSSEC material received from registrants, so that Internet users can trust the material received from the domain owner. This is commonly referred to as a ‘chain of trust’. Internet users trust the root (operated by IANA), which publishes the registries’ DNSSEC material, therefore registries inherit this trust. Domain owners within the TLD subsequently inherit trust from the parent domain when the registry publishes their DNSSEC material.

In accordance with new gTLD requirements, the TLD zone will be DNSSEC signed, and the receipt of DNSSEC material from Registrars for child domains is supported in all provisioning systems.

1.8.1 Stability and Operational Considerations for DNSSEC

1.8.1.1 DNSSEC Practice Statement

TRA’s DNSSEC Practice Statement is included in the response to Question 43. The DPS follows the guidelines set out in the draft IETF DNSOP DNSSEC DPS Framework document.

1.8.1.2 Receipt of Public Keys from Registrars

The public key for a child domain is received by TRA from the Registrar via either the EPP or SRS Web Interface. TRA uses an SHA-256 digest to generate the DS Resource Record (RR) for inclusion into the zone file.

1.8.1.3 Resolution Stability

DNSSEC is considered to have made the DNS more trustworthy; however some transitional considerations need to be taken into account. DNSSEC increases the size and complexity of DNS responses. TRA and ARI, as the zone server provider, ensure the TLD zone servers are accessible and offer consistent responses over UDP and TCP.

The increased UDP & TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.
ARI complies with all relevant RFCs and best practice guides in operating a DNSSEC-signed TLD. This includes conforming to algorithm updates as appropriate. To ensure Key Signing Key Rollover procedures for child domains are predictable, DS records will be published as soon as they are received, via the EPP server or SRS Web Interface. This allows child domain operators to rollover their keys with the assurance that their timeframes for both old and new keys are reliable.


2 APPROACHES TO SECURITY AND STABILITY

Stability and security of the Internet is a key consideration for the Registry system. To ensure that the Registry services are reliably secured and remain stable under all conditions, TRA takes a conservative approach with the operation and architecture of the Registry system.

By architecting all Registry Services to use the least privileged access to systems and data, risk is significantly reduced for other systems and the Registry services as a whole should any one service become compromised. By applying that principle to procedures and processes, it is ensured that access is given only to that which is necessary to perform tasks. TRA has a comprehensive approach to security which is modelled off the ISO27001 series of standards and explored further in the relevant questions of this response.

By ensuring all the services adhere to all relevant standards, TRA ensures entities which interact with the Registry Services do so in a predictable and consistent manner. When variations or enhancements to services are made, they are also aligned with the appropriate interoperability standards.

The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the Shared Registry System (SRS) for this TLD as provided by TRA.

1 INTRODUCTION

TRA has demonstrated delivery of an SRS with exceptional availability, performance and reliability. TRA are experienced running mission critical SRSs and with ARI have significant knowledge of the industry and building and supporting SRSs.

TRA’s SRS has successfully supported a large group of Registrars for American Standard Code for Information Interchange (ASCII) and Internationalised Domain Names (IDN) based TLDs. The system is proven to sustain high levels of concurrency, transaction load, and system uptime. TRA’s SRS meets the following requirements:
– Resilient to wide range of security & availability threats.
– Consistently exceeds performance & availability SLAs.
– Allows capacity increase with minimal impact to service.
– Provides fair & equitable provisioning for all Registrars.

2 CAPACITY

TRA’s SRS was built to sustain 2M domain names. Based on TRA’s experience running ccTLD registries and industry analysis, TRA were able to calculate the conservative characteristics of a registry this size.

Through statistical analysis of the .ae registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is an average of 70 SRS TPS per domain, per month, and a ratio of 3 queries to 2 transform txs. This indicates an expected monthly transaction volume of 140M txs (84M query and 56M transforms).

Through statistical analysis of the .ae registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
- The peak daily TPS is 6% of monthly total.
- The peak 5 min is 5% of the peak day.
Thus, we expect a peak EPP tx rate of 1,400 TPS (560 transform TPS and 840 query TPS)

Through statistical analysis of the .ae registry we know:
- The avg no. contacts⁄domain is 3.76.
- The avg no. hosts⁄domain is 2.28.
This translates into a requirement to store 7.52M contacts and 4.56M hosts.

Finally, through real world observations of the .ae registry, which has a comprehensive web interface when compared to those offered by current gTLD registries, we know there is an avg of 0.5 HTTP requests⁄sec to the SRS web interface per Registrar. We also know that this behaviour is reasonably flat. To support an estimated 200 Registrars, would require 100 requests⁄second.

For perspective on the conservativeness of this, the following was taken from data in the May 2011 ICANN reports referenced above:
– .info: ~7.8M names peaks at ~1,400 TPS 
– .com: ~98M names peaks at ~41,000 TPS
– .org: ~9.3M names, peaks at ~1,400 TPS 

After performing this analysis the projected TPS for .com was still the largest value.
TRA understand the limitations of this method but it serves as a best estimate of probable tx load. TRA has built overcapacity of resources to account for limitations of this method, however as numbers are more conservative than real world observations, we are confident this capacity is sufficient.
This TLD is projected to reach 50,333 domains at its peak volume and will generate 35 EPP TPS. This will consume 2.52% of the resources of the SRS infrastructure. As is evident TRA’s SRS can easily accommodate this TLD’s growth plans. See attachment ‘Q24 - Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

TRA expects to provide Registry services to 8 TLDs and with a maximum of 2M domains by end of 2014. With all the TLDs and domains combined, TRA’s SRS infrastructure will be 60% utilised. The SRS infrastructure capacity can be easily scaled as described in Q32
TRA benchmarked their SRS infrastructure and used the results to calculate the required computing resources for each of the tiers within the architecture; allowing TRA to accurately estimate the required CPU, IOPS, storage and memory requirements for each server, and the network bandwidth & packet throughput requirements for the anticipated traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions, and headroom for growth. Despite doubling numbers, effective estimated capacity is still reported as 2M. The technical resource allocations are explored in Q32.


3 SRS ARCHITECTURE

TRA’s SRS has the following major components:
– Network Infrastructure
– EPP Application Servers
– SRS Web Interface Application Servers
– SRS Database

Attachment ‘Q24 – SRS.pdf’ shows the SRS systems architecture and data flows. Details on this architecture are in our response to Q32. TRA provides two distinct interfaces to the SRS: EPP and SRS Web. Registrar SRS traffic enters the TRA network via the redundant Internet link and passes (via the firewall) to the relevant application server for the requested service (EPP or SRS Web). TRA’s Extensible Provisioning Protocol (EPP) interface sustains high volume and throughput domain provisioning transactions for a large number of concurrent Registrar connections. TRA’s SRS Web interface provides an alternative to EPP with a presentation centric interface and provides reporting and verification features additional to those provided by the EPP interface.

3.1 EPP

TRA’s EPP application server is based on EPP as defined in RFCs 5730 – 5734. Registrars send XML based transactions to a load balanced EPP interface which forwards to one of the EPP application servers. The EPP application server then processes the XML and converts the request into database calls that retrieve or modify registry objects in the SRS database. The EPP application server tier comprises of three independent servers with dedicated connections to the registry database. Failure of any one of these servers will cause Registrar connections to automatically re-establish with one of the remaining servers. Additional EPP application servers can be added easily without any downtime. All EPP servers accept EPP both IPv4 & IPv6.

3.2 SRS Web

The SRS Web application server is a Java web application. Registrars connect via the load balancer to a secure HTTP listener running on the web servers. The SRS web application converts HTTPs requests into database calls which query or update objects in the SRS database. The SRS Web application server tier consists of two independent servers that connect to the database via JDBC. If one of these servers is unavailable, the load balancer re-routes requests to the surviving server. Additional servers can be added easily without any downtime. These servers accept both IPv4 & IPv6.

3.3 SRS Database

The SRS database provides persistent storage for domains and supporting objects. It offers a secure way of storing and retrieving objects provisioned within the SRS and is built on the Oracle 11g Enterprise Edition RDBMS. The SRS Database tier consists of four servers clustered using Oracle Real Application Clusters (RAC). In the event of failure of a database server, RAC will transparently transition its client connections to a surviving database host. Additional servers can be added easily without any downtime.

3.4 Number of Servers

EPP Servers – The EPP cluster consists of 3 servers that can more than handle the anticipated 2M domains. This TLD will utilize 2.52% of this capacity at its peak volume. As the utilisation increases TRA will add additional servers ensuring the utilization doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.

SRS Web Servers – The SRS Web cluster consists of 2 servers that can more than handle the anticipated 2M domains. This TLD will utilise 2.52% of this capacity at its peak volume. As the utilization increases TRA will add additional servers ensuring the utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.

SRS DB Servers – The SRS DB cluster consists of 4 servers that can more than handle the anticipated 2M domains. This TLD will utilise 2.52% of this capacity at its peak volume. As the utilisation increases TRA will add additional servers ensuring the total utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.

3.5 SRS Security

TRA adopts a multi-layered security solution to protect the SRS. An industry leading firewall is deployed behind the edge router and is configured to only allow traffic on the minimum required ports and protocols. Access to the TRA EPP service is restricted to a list of known Registrar IPs.

An Intrusion Detection device is in-line with the firewall to monitor and detect suspicious activity.

All servers are configured with restrictive host based firewalls, intrusion detection, and SELinux. Direct root access to these servers is disabled and all access is audited and logged centrally.

The SRS database is secured by removal of non-essential features and accounts, and ensuring all remaining accounts have strong passwords. All database accounts are assigned the minimum privileges required to execute their business function.
All operating system, database, and network device accounts are subject to strict password management controls such as validity & complexity requirements.

Registrar access to the SRS via EPP or the Web interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows:
- Registrar’s source IP must be allowed by the front-end firewalls. This source IP is received from the Registrar via a secure communication channel from within the SRS Web interface
- Registrar must use a digital certificate provided by TRA
- Registrar must use authentication credentials that are provided by encrypted email

All communication between the Registrar and the SRS is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

3.6 SRS High Availability

SRS availability is of paramount. Downtime is eliminated or minimised where possible. The infrastructure contains no single points of failure. N+1 redundancy is used as a minimum, which not only protects against unplanned downtime but also allows TRA to execute maintenance without impacting service.

Redundancy is provided in the network with hot standby devices & multiple links between devices. Failure of any networking component is transparent to Registrar connections.
N+N redundancy is provided in the EPP and SRS Web application server tiers by the deployment of multiple independent servers grouped together as part of a load-balancing scheme. If a server fails the load balancer routes requests to the remaining servers.
N+N redundancy is provided in the database tier by the use of Oracle Real Application Cluster technology. This delivers active⁄active clustering via shared storage. This insulates Registrars from database server failure.

Complete SRS site failure is mitigated by the maintenance of a remote standby site — a duplicate of the primary site ready to be the primary if required.

The standby site database is replicated using real time transaction replication from the main database using Oracle Data Guard physical standby. If required, the Data Guard database can be activated quickly and service resumes at the standby site.

3.7 SRS Scalability

TRA’s SRS scales efficiently. At the application server level, additional computing resource can be brought on-line rapidly by deploying a new server online. During benchmarking this has shown near linear.

The database can be scaled horizontally by adding a new cluster node into the RAC cluster online. This can be achieved without disruption to connections. The SRS has demonstrated over 80% scaling at the database level, but due to the distributed locking nature of Oracle RAC, returns are expected to diminish as the number of servers approaches double digits. To combat this TRA ensures that when the cluster is ‘scaled’ more powerful server equipment is added rather than that equal to the current members. Capacity can be added to the SAN at any time without downtime increasing storage and IOPs.

3.8 SRS Inter-operability and Data Synchronisation

The SRS interfaces with a number of related registry systems as part of normal operations.

3.8.1 DNS Update

Changes made in the SRS are propagated to the DNS via an TRA proprietary DNS Update process. This process runs on the ‘hidden’ primary master nameserver and waits on a queue. It is notified when the business logic inserts changes into the queue for processing. The DNS Update process reads these queue entries and converts them into DNS update (RFC2136) commands that are sent to the nameserver. The process of synchronising changes to SRS data to the DNS occurs in real-time.

3.8.2 WhoIs

The provisioned data supporting the SRS satisfies WhoIs queries. Thus the WhoIs and SRS share data sets and the WhoIs is instantaneously updated. Under normal operating conditions the WhoIs service is provided by the infrastructure at the secondary site in order to segregate the load and protect SRS from WhoIs demand (and vice versa). WhoIs queries that hit the standby site will query data stored in the standby database — maintained in near real-time using Oracle Active Data Guard. If complete site failure occurs WhoIs and SRS can temporarily share the same operations centre at the same site (capacity numbers are calculated for this).

3.8.3 Escrow

A daily Escrow extract process executes on the database server via a dedicated database account with restricted read-only access. The results are then transferred to the local Escrow Communications server by SSH.

4 OPERATIONAL PLAN

TRA follow defined policies⁄procedures that have developed over time by running critical registry systems. Some principals captured by these are:
– Conduct all changes & upgrades under strict and well-practised change control procedures
- test, test and test again
– Maintain Staging environments as close as possible to production infrastructure⁄configuration
– Eliminate all single points of failure
– Conduct regular security reviews & audits
– Maintain team knowledge & experience via skills transfer⁄training
– Replace hardware when no longer supported by vendor
– Maintain spare hardware for all critical components
– Execute regular restore tests of all backups
– Conduct regular capacity planning exercises
– Monitor everything from multiple places but ensure monitoring is not ‘chatty’
– Employ best of breed hardware & software products & frameworks (such as ITIL, ISO27001 and Prince2)
– Maintain two distinct OT&E environments to support pre-production testing for Registrars

5 SLA, RELIABILITY & COMPLIANCE

TRA’s SRS adheres to and goes beyond the scope of Specification 6 and Specification 10 of the Registry Agreement. TRA’s EPP service is XML compliant and XML Namespace aware. It complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts & contacts are compliant with RFC 5731, 5732 & 5733 respectively. The transport over TCP is compliant with RFC5734. The service also complies with official extensions to support DNSSEC, RFC5910, & Redemption Grace Period, RFC3915.
TRA’s SRS is sized to sustain a peak transaction rate of 1,400 TPS while meeting strict internal Operational Level Agreements (OLAs). The monthly-based OLAs below are more stringent than those in Specification 10 (Section 2).
EPP Service Availability: 100%
EPP Session Command Round Trip Time (RTT): 〈=1000ms for 95% of commands
EPP Query Command Round Trip Time (RTT): 〈=500ms for 95% of commands
EPP Transform Command Round Trip Time (RTT): 〈=1000ms for 95% of commands
SRS Web Interface Service Availability: 99.9%

TRA measure the elapsed time of every query, transform and session EPP transaction, and calculate the percentage of commands that fall within OLA on a periodic basis. If percentage value falls below configured thresholds, on-call personnel are alerted.
SRS availability is measured by TRA’s monitoring system, which polls both the EPP and SRS Web services status. These checks are implemented as full end to end monitoring scripts that mimic user interaction, providing a true representation of availability. These ‘scripts’ are executed from external locations on the Internet. 


6 RESOURCES

TRA’s resources to perform tasks to deliver services are:
The SRS is designed, built, operated and supported by the following TRA departments:
– Technical Operations and Development (TOD)
and
ARI Registry Services (software development)

The TOD is responsible for the design, deployment and maintenance of the SRS infrastructure including capacity planning, monitoring, and security. This team ensures the SRS services are available and performing appropriately. The team consists of:
– 1 Manager TOD
– Service Desk:
 – 2 Registrar Support Specialists (Level 2)
– Operations and Implementation (Level 3):
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network and Security Engineers

ARI Registry Services is responsible for SRS changes and features, bug fixes and issue diagnosis. Both the Business and Technical Operations and Development teams liaise with ARI Services as necessary to resolve issues and deploy new features. 

Based on experience with the .ae and .emarat (IDN) ccTLDs and after consultation with ARI (who operate the .au TLD) current staff resources should be sufficient to meet the needs of a registry with 2M domains under management (DUM). This is based on the expected traffic, customer query levels and the operational demands of the required scale of infrastructure needed to deliver an appropriate level of service to registrants and Internet users. We expect that this TLD will represent approximately 2.52% of work effort TRA devotes towards registry operations throughout the year. This is commensurate with the comparative size of this TLD which at 50333 peak DUM will represent roughly 2.52% of the registry infrastructure. The allocation and rationalisation methodology can be reviewed in detail within the file “Q24 – Registry Scale Estimates & Resource Allocation.xlsx”.

Question 25 - The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the Software (including the EPP daemon) licensed from ARI Registry Services (ARI) for this TLD and provided by TRA.

1 INTRODUCTION

TRA’s Extensible Provisioning Protocol (EPP) service is XML compliant and XML Namespace aware. The service complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts and contacts are compliant with RFC5731-3 respectively. The transport over TCP is implemented in compliance with RFC5734. The service also complies with the official extensions to support DNSSEC (RFC5910) and Redemption Grace Period (RFC3915). The registry software used by TRA was implemented by ARI as EPP draft version 0.6 in 2002, then migrated to EPP RFC1.0 on its publishing in 2004. The system has operated live since 2002 in the .au ccTLD and since 2008 in the .ae ccTLD.

Descriptions in this response follow the terminology used in the EPP RFCs. When referring to the software involved in the process, TRA’s EPP interface is called the server, and the software used by Registrars is called the client.


2 TRANSPORT LAYER

The TRA EPP service implements the RFC5734 – EPP Transport over TCP. Connections are allowed using TLSv1 encryption, optionally supporting SSLv2 Hello for compatibility with legacy clients. AES cipher suites for TLS as described in RFC3268 are the only ones allowed.

2.1 Authentication

Registrar access to the EPP interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows. Registrars must:
- present a certificate, during TLS negotiation signed by the TRA Certificate Authority (CA). The server returns a certificate also signed by the TRA CA. Not presenting a valid certificate results in session termination. TRA requires that the Common Name in the subject field of the certificate identifies the Registrar.
– Originate connections from an IP address that is known to be assigned to the Registrar with that Common Name.
- Registrar must use authentication credentials provided to the Registrar via encrypted email
- Registrars aren’t able to exceed a fixed number of concurrent connections. The connection limit is prearranged and designed to prevent abuse of Registrars’ systems from affecting the Registry. The limit is set to reasonable levels for each Registrar, but can be increased to ensure legitimate traffic is unaffected. 

If any of the above conditions aren’t met the connection is terminated.
- All communication between the Registrars and the EPP service is encrypted using at least 128 bit encryption which has been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

2.3 Connection Close

The server may close the connection as a result of a logout, an error where the state of the connection is indeterminate, or after a timeout. Timeout occurs where no complete EPP message is received on the connection for more than 10 minutes.


3 EPP PROTOCOL

This section describes the interface relating to the EPP protocol described in RFC 5730. This includes session management, poll message functionality and object mappings for domains, hosts and contacts.

3.1 Session Management
Session management refers to login and logout commands, used to authenticate and end a session with the SRS. The Login command used to establish a session between the client and the server. This command succeeds when:
– The username supplied matches the Common Name in the digital certificate used in establishing the TLS session.
– The provided password is valid for the user.
– The user’s access to the system isn’t suspended.

The Logout command is used to end an active session. On processing a logout, the server closes the underlying connection. The Hello command can be used as a session keep-alive mechanism.

3.2 Service Messages

Offline notifications pertaining to certain events are stored in a queue. The client is responsible for polling this queue for new messages and to acknowledge read messages. Messages include notification about server modification of sponsored objects, transfer operations and balance thresholds.


4 EPP OBJECT MAPPINGS

This section covers the interface for the 3 core EPP objects; domain, host and contact objects, as per RFC5731, 5732 & 5733 respectively.

The EPP domain, contact and host object mapping describes an interface for the check, info, create, delete, renew (domain only), transfer (domain and contact only) and update commands. For domain objects, the server doesn’t support the use of host attributes as described by RFC5731, but rather uses host objects as described by RFC 5731 and RFC 5732. Details of each command are:
- check command: checks availability of 1 or more domain, contact or host objects in the SRS. Domain names will be shown as unavailable if in use, invalid or reserved; other objects will be unavailable if in use or invalid.
- info command: retrieves the information of an object provisioned in the SRS. 

Full information is returned to the sponsoring client or any client that provides authorisation information for the object. Non-sponsoring clients are returned partial information (no more than is available in the WhoIs).
- create command: provisions objects in the SRS. To ascertain whether an object is available for provisioning, the same rules for the check command apply.
- delete command: begins the process of removing an object from the SRS. Domain names transition into the redemption period and any applicable grace periods are applied. Domain names within the Add Grace Period are purged immediately. All other objects are purged immediately if they are not linked.
- transfer command (domain and contact only): extends the registration period of a domain name. The renewal period must be between 1 to 10 years inclusive and the current remaining registration period, plus the amount requested in the renewal mustn’t exceed 10 years.
- transfer command: provides several operations for the management of the transfer of object sponsorship between clients. Clients that provide correct authorisation information for the object can request transfers. Domain names may be rejected from transfer within 60 days of creation or last transfer. The requesting client may cancel the transfer, or the sponsoring client may reject or approve the transfer. Both the gaining and losing clients may query the status of the current pending or last completed transfer. 
- update command: updates authorisation information, delegation information (domains), and registration data pertaining to an object.


5 NON-PROPRIETARY EPP MAPPINGS

TRA’s EPP service implements 2 non-proprietary EPP mappings, to support the required domain name lifecycle and to provide & manage DNSSEC information. The relevant schema documents aren’t provided as they are published as RFCs in the RFC repository.

5.1 Grace Period Mapping

The Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (as per RFC3915) is used to support the domain name lifecycle as per existing TLDs. The update command is extended by the restore command to facilitate the restoration of previously deleted domains in the redemption period. This command defines 2 operations, request & report, described here:
- request operation: requests the restoration of a domain name during the redemption period.
- report operation: completes the restoration by specifying the information supporting the restoration of the domain. The restore report must include a copy of the WhoIs information at both the time the domain was deleted & restored, including the restore reason.

5.2 DNSSEC Mapping

The Domain Name System (DNS) Security Extensions Mapping for EPP, as per RFC5910, is used to support the provisioning of DNS Security Extensions. TRA requires clients use the Key Data Interface. Clients may associate a maximum of 4 keys per domain. The Registry system generates the corresponding DS data using the SHA-256 digest algorithm for the domain and any active variant domains.

TRS is aware of issues DNSSEC causes when transferring DNS providers – a transfer of Registrar usually means a change in DNS provider. DNSSEC key data won’t be removed from the SRS or the DS data be removed from publication in the DNS if a transfer occurs. It is the responsibility of and requires the cooperation of the Registrant, Registrars, and DNS providers, to provide a seamless transition. TRA observes progress with this issue and implements industry agreed solutions as available. DNSSEC information is included in info responses when the secDNS namespace in login.

6 PROPRIETARY MAPPING

The Registry system supports 3 additional EPP extensions where no published standard for the required functionality exists. Developed to conform to the requirements specified in RFC3935, these extensions include the provisioning of Internationalised Domain Names and domain name variants, and the association of arbitrary data with a domain name. These 3 extensions are introduced below, and further described in the attached schema documentation.

6.1 Internationalised Domain Names

TRA through ARI has developed an extension to facilitate the registration and management of Internationalised Domain Names as per RFCs 5890-5893 (collectively known as the IDNA 2008 protocol). This extension extends the domain create command and the info response.

The create command is extended to capture the language table identifier that identifies the corresponding IDN language table for the domain name. Additionally the extension requires the Unicode form to avoid an inconsistency with DNS-form, as per RFC 5891.

The domain info command is extended to identify the language tag and Unicode form provided in the initial create command. This information is disclosed to all querying clients that provided the extension namespace at login. This extension is documented in the attachment ‘Q25 – idnadomain-1.0.pdf’.

6.2 Variant

TRA through ARI has developed an extension to facilitate the management of Domain Name variants. This extension extends the domain update command and the domain create and info responses. The domain update command is extended to allow the addition (activation) and removal (de-activation) of domain name variants subject to Registry Operator policy.

The domain create and info responses are extended to return the list of activated domain name variants. This information is disclosed to all querying clients that provided the extension namespace at login. The extension is documented in the attachment ‘Q25 – variant-1.1.pdf’.

6.3 Key-Value

TRA through ARI has developed an extension to facilitate the transport of arbitrary data between clients and the SRS without the need for developing EPP Extensions for each specific use-case. This extension extends the domain create and domain update transform commands and the domain info query command. This extension is documented in the attachment ‘Q25 – kv-1.0.pdf’.


7 ADDITIONAL SECURITY

The Registry system provides additional mechanisms to support a robust interface. The use of command rate limiting enables the Registry to respond to and withstand erroneous volumes of commands, while a user permission model provides fine-grained access to the EPP interface. These 2 mechanisms are described below.

7.1 Rate Limiting

The Registry system supports command and global rate limits using a token-bucket algorithm. Limits apply to each connection to ensure fair and equitable use by all clients that exceed limits receive a command failed response message indicating breach of the limits.

7.2 User Permission Model

The Registry system supports a fine-grained permission model controlling access to each specific command. By default, clients receive access to all functionality; however it is possible to remove access to a specific command in response to abuse or threat to stability of the system. Clients that attempt a command they have lost permission to execute, receive an EPP command failed response indicating loss of authorisation.


8 COMPLIANCE

TRA’s registry software provider ARI’s compliance assurance:
Compliance with EPP RFCs is achieved through design and quality assurance (QA). The EPP interface was designed to validate all incoming messages against the respective XML Schema syntax. The XML Schema is copied directly from the relevant RFCs to avoid any ambiguity on version used. Inbound messages that are either malformed XML or invalid are rejected with a 2400 response. Outbound messages are validated against the XML Schema, and if an invalid response is generated, it is replaced with a known valid pre-composed 2400 response, and logged for later debugging.

A QA process provides confidence that changes don’t result in regressions in the interface. Automated build processes execute test suites that ensure every facet of the EPP service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs and the EPP service specification. These tests are executed prior to committing code and automatically nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging process. 

TRA’s acceptance process:
Upon receipt of registry software, the following process occurs: 
1. The software is deployed to TRA’s staging environment where the registry software Acceptance Test Procedure (ATP) is run to review the software.
a. This procedure includes tests for regression testing existing functions and is modified as appropriate to test any new functions. New functions will enter the ATP and remain as part of the regression test suite for subsequent release tests.
b. Any anomalies are referred to ARI and the ATP is repeated on any revised software received.
2. Upon completion of the ATP, the new software is deployed to TRA’s Operation and Testing Environment 2(OTE2). This environment contains upcoming system software, and registrars are encouraged to preview any new functionality and validate existing functionality using their systems.
a. TRA will respond to registrars to address any functionality changes or anomalies they identify. This may result in changes to registrar instruction material.
b. TRA will leave new software within the OTE2 stage an appropriate length of time depending on the significance of the software change. New software will remain in OTE2 for at least 7 days. The exact length of public testing will be announced to registrars at the commencement of the test period. 
3. Once the software has been deployed in the OTE2 for the announced period, it will be released to the OTE1, Accreditation and Production environments simultaneously. Stakeholders will be notified of the schedule for this release at the time the software is released to the OTE2.


9 Capacity

This TLD is projected to reach 50333 domains at its peak volume and will generate 35 EPP TPS. This will consume 2.52% of the EPP resources. TRA’s SRS can easily accommodate this TLD. This was described in considerable detail in the capacity section of question 24.


10 RESOURCES

TRA provides a technical support team to support Registrars and its software provider ARI also provides Registrars with a toolkit (in Java and C++) implementing the EPP protocol. Normal operations for all Registry Services are managed by TRA’s Technical Operations and Development team (TOD), who ensures the EPP server is available and performing appropriately.

Faults relating to connections with or functionality of the EPP server are managed by TOD. TRA monitors EPP availability and functionality as part of its monitoring practices, and ensures TOD staff are available to receive fault reports from Registrars any time. TOD has the appropriate network, Unix and application (EPP and load balancing) knowledge to ensure the EPP service remains accessible and performs as required. EPP is supported by these TRA departments:
– Business Operations and Development
– Technical Operations and Development
and
ARI Registry Services (SRS software provider)

The Business Operations and Development team are responsible for liaising with registrars and include the customer service staff who handle level 1 support for registrars:
– 1 Business Development Officer
– 4 Customer Support Representative (Level 1)

The TOD is responsible for the design, deployment and maintenance of the SRS infrastructure including capacity planning, monitoring, and security. This team ensures the SRS services are available and performing appropriately. The team consists of:
– 1 Manager Technical Operations and Development 
– Service Desk:
 – 2 Registrar Support Specialists (Level 2)
– Operations and Implementation (Level 3):
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network and Security Engineers

TRA’s software provider ARI Registry Services is responsible for SRS changes and features, bug fixes and issue diagnosis. Both the Business and Technical Operations and Development teams liaise with ARI Services as necessary to resolve issues and deploy new features.

Question 26 - The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the WhoIs for this TLD as provided by TRA.

1 INTRODUCTION

TRA’s WhoIs service is for all domain names, contacts, nameservers and Registrars provisioned in the registry database. This response describes the port 43 and web interfaces of WhoIs, security controls to mitigate abuse, compliance with bulk access requirements for registration data and the architecture delivering the service.


2 PORT 43 WHOIS SERVICE

WhoIs is available on TCP port 43 in accordance with RFC3912. Requests are made in semi-free text format and ended by an ASCII CR and then an ASCII LF. The server responds with a semi-free text format, terminating the response by connection close.

To support IDNs and Localised data, we assume the query is encoded in 7-bit US-ASCII. WhoIs assumes the query is encoded in UTF-8 and always sends responses encoded in UTF-8. UTF-8 is backwards compatible with the ASCII charset and its use is consistent with the IETF policy on charsets as defined in BCP 18. [http:⁄⁄tools.ietf.org⁄html⁄bcp18].

2.1 Query Format

By default, WhoIs searches for domains. To facilitate the queries of other objects, keywords must be used. Supported keywords are:
– Domain
– Host⁄Nameserver
– Contact
– Registrar

Keywords are case-insensitive. The rest of the input is the search string. Wildcard chars may be used in search strings to match zero or more chars (%), or match exactly one char(_). Wildcard chars must not be in the first five characters.

2.2 Response Format

The response follows a semi-structured format consisting of the object-specific data, followed by query-related meta-information, then a disclaimer.
The object-specific data is represented by key⁄value pairs, beginning with the key, followed by a colon and a space, then the value, and terminated by an ASCII CR and an ASCII LF. Where no object is found, ‘No Data Found’ is returned.
The meta-information is used to identify data freshness and indicate when limits have been exceeded. It appears on one line within ‘〉〉〉’ and ‘〈〈〈’ chars.
The legal disclaimer is presented without leading comment marks wrapped at 72 chars. This format is consistent with that in the registry agreement.

2.3 Domain Data

Domain data is returned in response to a query with the keyword omitted, or with the ‘domain’ keyword. Domain queries return information on domains that are provisioned in the registry database.
The IDN domains may be specified in either the ASCII-compatible encoded form or the Unicode form. Clients are expected to perform any mappings in conformance with relevant guidelines such as those specified in RFC5894 and UTS46.
Variant domains may be specified in the search string and WhoIs will match (using case-insensitive comparison) and return information for the primary registered domain.

For queries containing wildcard chars, if only one domain name is matched, its details are returned; if more than one domain name is matched then the first 50 matched domain names are listed.

2.3.1 Internationalised Domain Names

The WhoIs response format, prescribed in Specification 4, does not provide a mechanism to identify active variant domain names. TRA will include active variant domain names in WhoIs responses until a common approach for handling and display of variant names is determined.

2.3.2 Reserved Domain Names
Domain names reserved from allocation will have a specific response that indicates the domain is not registered, but also not available. 

2.4 Nameserver Data

Nameserver data is returned in response to a query where the ‘nameserver’ or ‘host’ keywords have been used. Nameserver queries return information on host objects that are provisioned in the registry.

The search string for a nameserver query can be either a hostname or IP. Queries using the hostname produce one result unless wildcard characters are used. Queries using the IP produce one or more results depending on the number of hostnames that match that address. Queries for the hostname are matched case-insensitively.
The quad-dotted notation is expected for IPv4 and the RFC3513 - IPv6 Addressing Architecture format for IPv6. Wildcards cannot be used for IP queries.

2.5 Contact Data

Contact data is returned in response to a query where the ‘contact’ keyword was used. Contact queries return information on contacts that are provisioned in the registry.

The search string for a contact query is the contact identifier. Contact identifiers are matched using a case-insensitive comparison. Wildcards cannot be used.

2.6 Registrar Data

Registrar data is returned in response to a query where the ‘Registrar’ keyword was used. Registrar queries return information on Registrar objects that are provisioned in the registry database.

The search string for a Registrar query can be either by name or IANA id. Queries using the name or the IANA id produce only one result. Queries for the name are matched using a case-insensitive comparison. Wildcard cannot be used.

2.7 Non-standard Data

The SRS supports domain-related data beyond that outlined above. It may include information used to claim eligibility to participate in the sunrise process, or other arbitrary data collected using the Key-Value Mapping to the EPP. This information will be included in the WhoIs response after the last object-specific data field and before the meta-information.


3 WEB-BASED WHOIS SERVICE

WhoIs is also available via port 80 using HTTP, known as Web-based WhoIs. This interface provides identical query capabilities to the port 43 interface via an HTML form.


4 SECURITY CONTROLS

WhoIs has an in-built mechanism to blacklist malicious users for a specified duration. Blacklisted users are blocked by source IP address and receive a specific blacklisted notification instead of the normal WhoIs response. Users may be blacklisted if TRA’s monitoring system determines excessive use. A whitelist is used to facilitate legitimate use by law enforcement agencies and other reputable entities.


5 BULK ACCESS

The registry system complies with the requirements for the Periodic Access to Thin Registration Data and Exceptional Access to Thick Registration Data as described in Specification 4.

5.1 Periodic Access to Thin Registration Data

TRA shall provide ICANN with Periodic Access to Thin Registration Data. The data will contain the following elements as specified by ICANN. The format of the data will be consistent with the format specified for Data Escrow. The Escrow Format prescribes an XML document encoded in UTF-8. The generated data will be verified to ensure that it is well formed and valid.

The data will be generated every Monday for transactions committed up to and on Sunday unless otherwise directed by ICANN. The generated file will be made available to ICANN using SFTP. Credentials, encryption material and other parameters will be negotiated between TRA and ICANN using an out-of-band mechanism.

5.2 Exceptional Access to Thick Registration Data

If requested by ICANN, TRA shall provide exceptional access to thick registration data for a specified Registrar. The date will contain full information for the following objects:
– Domain names sponsored by the Registrar
– Hosts sponsored by the Registrar
– Contacts sponsored by the Registrar
– Contacts linked from domain names sponsored by the Registrar

As above, the format of the data will be consistent with the format specified for Data Escrow, and will be made available to ICANN using SFTP.


6 CAPACITY

TRA’s WhoIs infrastructure is built to sustain 2M domain names. Based on TRA’s experience running a ccTLD registry, communication and consultation with ARI the .au ccTLD operator and industry analysis, TRA were able to calculate the conservative characteristics of a registry of this size.

Through statistical analysis of the .ae registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
- An average of 30 Shared Registry System (SRS) txs per domain, per month.

Which indicates an expected monthly transaction volume of 60M txs?
Through statistical analysis of the .ae registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
 - The peak daily transactions is 6% of the monthly total
 - The peak 5 min is 5% of the peak day
Thus we expect a peak WhoIs tx rate of WhoIs 600 TPS.

For perspective on the conservativeness of this, the following numbers were taken from data in the May 2011 ICANN reports referenced above:
– .info ~7.8M domain names, peaks at ~1,300 TPS (projected peak TPS of ~3,400 with 20M names).
– .mobi ~1M domain names, peaks at ~150 TPS (projected peak TPS of ~3,000 TPS with 20M names).
– .org ~9.3M domain names, peaks at ~1,300 TPS (projected peak TPS of ~2,800 with 20M names).

TRA understand the limitations of these calculations but they serve as a best estimate of probable transaction load. TRA has built overcapacity of resources to account for limitations of this method, however as conservative numbers were used and these are greater than real world observations, we are confident these capacity numbers are sufficient.

TRA benchmarked their WhoIs infrastructure and used the results to calculate the required computing resources for each of the tiers within the WhoIs architecture — allowing TRA to accurately estimate the required CPU, IOPS, storage and memory requirements for each server within the architecture, as well as the network bandwidth and packet throughput requirements for the anticipated WhoIs traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions and head room for growth. The Technical resource allocations are explored in question 32.

This TLD is projected to reach 50333 domains at its peak volume and will generate 15 WhoIs transactions per second. This will consume 2.52% of the resources of the WhoIs infrastructure. As is evident TRA’s WhoIs can easily accommodate this TLD’s growth plans. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

TRA expects to provide Registry services to 8 TLDs and a total of 200K domains by end of 2014. With all the TLDs and domains combined, TRA’s WhoIs infrastructure will be only 10% utilised. The WhoIs infrastructure capacity can also be easily scaled as described in question 32.


7 ARCHITECTURE

WhoIs uses a database separate from the SRS database, as it operates from the secondary site such that network and database resources are decoupled from the operation of the SRS. Oracle Data Guard ensures the two databases are synchronised in real-time. The WhoIs service is operated live from the SRS ‘failover’ site, with the SRS ‘primary’ site serving as the ‘failover’ site for the WhoIs service. Both sites have enough capacity to run both services simultaneously, however by separating them in normal operating modes, headroom above the already over provisioned capacity is available. The architecture and data flow diagrams are described below and shown in the attachment ‘Q26 - WhoIs.pdf’.

Traffic enters the network from the Internet through border routers and then firewalls. All traffic destined for this service, except for TCP over ports 43, 80 and 443, is blocked. Load balancers forward the request to one of the application servers running TRAʹs-ARI-built WhoIs software that facilitates the WhoIs requests. Each application server is connected to the database cluster through another firewall, further restricting access to the database to only the required ports from the application servers. Each application uses a restricted Oracle user that has read-only access to the registry data and can only access the data relevant to the WhoIs queries. This ensures that, in the unlikely event of an application server compromise, the effects are limited.

All components are configured and provisioned to provide N+1 redundancy. Multiple Internet providers with separate upstream bandwidth suppliers are used. At least one additional component of all hardware exists, enabling maintenance without downtime. This configuration provides a service exceeding the availability requirements in Specification 10.

The use of load-balancing allows addition of application servers with no downtime. From a database perspective, the ability to scale up as the load profile increases is enabled by utilising Oracle RAC database clustering. The entire service, including routers, firewalls and application is IPv6 compatible and WhoIs is offered on both IPv4 and IPv6. Detail about this architecture is available in our response to Question 32.

7.1 Synchronisation

The WhoIs database is synchronised with the SRS database using Oracle Data Guard. Committed transactions in the SRS database are reflected in the WhoIs database in real-time. Should synchronisation break, WhoIs continues to operate with the latest available data until the issue is reconciled. The channel between the two sites consists of two independent, dedicated, point-to-point links, as well as the Internet. Replication traffic flows via the dedicated links, or if both links fail, replication traffic flows Internet tunnels.

7.2. Interconnectivity with Other Services

The WhoIs service is not directly interconnected with other registry services or systems. The software has been developed to provide the WhoIs service exclusively and retrieve response information from a database physically separate to the SRS transactional database. This database is updated as described in ‘Synchronisation’ above. Although for smaller system the WhoIs and SRS can be configured to use the same data store. The WhoIs servers log every request to a central repository that is logically separate from the WhoIs database. This repository is used for query counts, detection of data mining and statistical analysis on query trends.

7.3 IT and Infrastructure Resources

The WhoIs service is provided utilising Cisco networking equipment, IBM servers & SAN. They are described in the attachment ‘Q26 - WhoIs.pdf’. For more information on the architecture including server specifications and database capabilities please see Questions 32 & 33.


8 COMPLIANCE

Compliance with WhoIs RFCs is achieved through design and Quality Assurance. The WhoIs interface was designed to conform to the RFCs as documented and independent test cases have been developed.

QA processes provide confidence that any changes to the service don’t result in regression of the WhoIs. Automated build processes execute test suites that ensure every facet of the WhoIs service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs. These tests are executed prior to the committing of code and nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging of the software.

New versions of the WhoIs follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars who rely on WhoIs functionality are encouraged during this stage to test their systems operate without change. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior to reaching production.

TRA is committed to providing a WhoIs service that integrates with third party tools and as such tests are conducted using these tools such as jWhoIs, a popular UNIX command line WhoIs client. Any issues identified during integration fall into one of the following categories:
– Third-party tool not compliant with the WhoIs specification
– WhoIs service not compliant
– Both third-party tool and WhoIs service are compliant, however another operational issue causes a problem

Defects are raised and follow the change management. Change requests may also be raised to promote integration of third-party tools and to meet common practice.


9 RESOURCES

TRA’s resources to perform tasks to deliver services are:
The SRS is designed, built, operated and supported by the following TRA departments:
– Technical Operations and Development (TOD)
and
ARI Registry Services (software development)

The TOD is responsible for the design, deployment and maintenance of the WhoIs infrastructure including capacity planning, monitoring, and security. This team ensures the WhoIs systems are available and performing appropriately. The team consists of:
– Service Desk:
 – 2 Registrar Support Specialists (Level 2)
– Operations and Implementation (Level 3):
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network and Security Engineers

ARI Registry Services is responsible for SRS changes and features, bug fixes and issue diagnosis. This includes software used for WhoIs servers. Both the Business and Technical Operations and Development teams liaise with ARI Services as necessary to resolve issues and deploy new features. 

Based on experience with the .ae and .emarat (IDN) ccTLDs and after consultation with ARI (who operate the .au TLD) current staff resources should be sufficient to meet the needs of a registry with 2M domains under management (DUM). This is based on the expected traffic, customer query levels and the operational demands of the required scale of infrastructure needed to deliver an appropriate level of service to registrants and Internet users. We expect that this TLD will represent approximately 2.52% of work effort TRA devotes towards registry operations throughout the year. This is commensurate with the comparative size of this TLD which at 50333 peak DUM will represent roughly 2.52% of the registry infrastructure. The allocation and rationalisation methodology can be reviewed in detail within the file “Q26 – Registry Scale Estimates & Resource Allocation.xlsx”.

TRA’s registry provides abuse monitoring detection mechanisms to block data mining. TRA support staff may be contacted to remove blacklisted users, during which they may be referred to the Legal, Abuse and Compliance team for evaluation of their activities. Additionally, the support team, in conjunction with the Legal, Abuse and Compliance teams, administer requests for listing on the whitelist. The Legal Affairs team consists of:
– 1 Director of Legal Affairs
– 2 Legal Counsel

The policy compliance team consists;
- 1 Manager Internet Advancement
– 3 Policy Compliance Officers

Information on these roles is in the Resources section of our response to Question 31. 

Question 27 - The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver registry services for this TLD. This response describes the Registration Lifecycle of Domain Names for this TLD as provided by TRA.

1 INTRODUCTION

The lifecycle described matches current gTLD Registries — with adaptations for new gTLDs. All states, grace periods and transitions are supported by the Extensible Provisioning Protocol (EPP) as described in RFC5730 - 5734, & the Grace Period Mapping published in RFC3915. An overview of states and transitions is in attachment ‘Q27 – Registration Lifecycle.pdf’.


2 REGISTRATION PERIODS

The registry supports initial registration periods up to 10 years and renewals for 1 to 10 years. The total current validity period can’t exceed 10 years.
Transfers under part A of the ICANN Policy on Transfer of Registrations between Registrars (Adopted 7 November 2008) extend registration by 1 year. The period truncates to 10 years if required.


3 STATES

The states that a domain can exist in are: Registered, Pending Transfer, Redemption, Pending Restore & Pending Delete.

3.1 Registered

EPP Status: ok
In DNS: Yes
Allowed Operations: Update, Renew, Transfer (request) & Delete
The default state of a domain - no pending operations. The Sponsoring Registrar may update the domain.

3.2 Pending Transfer

EPP Status: pendingTransfer
In DNS: Yes
Allowed Operations: Transfer (cancel, reject, approve)
Another Registrar has requested transfer of the domain and it is not yet completed. All transform operations, other than those to cancel, reject, or approve the transfer, are rejected.

3.3 Redemption

EPP Status: pendingDelete
RGP Status: redemptionPeriod
In DNS: No
Allowed Operations: Restore (request)
Domain has been deleted. The sponsor may request the restoration of the domain. The domain continues to be withheld from the DNS, unless it is restored. No transform operations, other than restore, are allowed.

3.4 Pending Restore

EPP Status: pendingDelete
RGP Status: pendingRestore
In DNS: No
Allowed Operations: Restore (report)
A restore request is pending. The sponsor must submit a restore report. The domain remains withheld from the DNS. No transform operations, other than the restore report, are allowed.

3.5 Pending Delete

EPP Status: pendingDelete
RGP Status: pendingDelete
In DNS: No
Allowed Operations: None
The Redemption Grace Period has lapsed and the domain is pending purge from the registry. This state prohibits the sponsor from updating, restoring or modifying the domain. This status applies to the domain for five (5) days. At the end of this period, the domain is purged from the Database and made available for registration.


4 GRACE PERIODS

The registry system supports 4 grace periods: add, renew, auto-renew and transfer, described below with consideration for overlap of grace periods. States described here are additional to those above.

4.1 Add Grace Period

Length: 5 days
RGP Status: addPeriod
Allows for the no-cost cancellation of a domain registration resulting from typing mistakes and other errors by Registrars and registrants — beginning with the creation of a domain and lasting for 4 days. When the following operations are performed during this period, these rules apply:
– Delete: the sponsoring Registrar, who must have created the domain, may delete the domain and receive a refund. The domain is deleted with immediate effect. The refund is subject to the Add Grace Period Limits consensus policy. Excess deletions over 50 or 10% of creates (whichever is greater), are not subject to a refund under normal circumstances.
– Renew: the sponsor may renew the domain, but does not receive any refund for the initial registration fee. The Registrar is charged for the renewal operation. The total period for the domain is the sum of the initial period in the create and any renewal term, limited to a 10-year maximum.
– Transfer: Under ICANN Policy, a transfer can’t occur during the Add Grace Period or at any other time in the first 60 days after the initial registration. The registry system enforces this, rejecting such requests.
– Bulk Transfers: Under Part B of the ICANN Policy on Transfer of Registrations between Registrars, a bulk transfer can occur during the Add Grace Period. Any bulk transfer causes the Add Grace Period to not apply.
The Add Grace Period has no impact on other commands.

4.2 Renew Grace Period

Length: five days
RGP Status: renewPeriod
Allows the sponsoring Registrar to undo a renewal via the deletion of a domain — beginning on the receipt of a renewal command and lasting for 5 days. If any of the following operations are performed during this period, these rules apply:
– Delete: the sponsoring Registrar, who must have initiated the renewal, may delete the domain and receive a renewal fee refund. The extension to the registration period caused by the preceding renew is reversed and unless the domain is also in the Add Grace Period, the domain enters the Redemption state. If also in the Add Grace Period, it is deleted with immediate effect and availability for registration.
– Renew: the sponsoring Registrar, who must have performed the initial renew, can subsequently renew the domain again, causing a second independent Renewal Grace Period to start. The Registrar is charged for the operation and the total registration period for the domain is extended by the renewal term, limited to the 10-year maximum.
– Transfer: an approved transfer command ends the current Renew Grace Period without a refund and begins a Transfer Grace Period.
– Bulk Transfers: bulk transfers cause the Renew Grace Period to end without a refund; consequently registration periods are not changed.

The Renew Grace Period has no impact on other commands.

4.3 Auto-Renew Grace Period

Length: 45 days
RGP Status: autoRenewPeriod
Auto-Renew Grace Period allows for domains to remain in the DNS past the registration expiration, while giving adequate time for the sponsoring Registrar to obtain intention of renewal from the registrant.
This period begins on the expiration of the domain and lasts for 45 days. If any of the following are performed during this period, these rules apply:
– Delete: the sponsoring Registrar, who must be the sponsor when the Auto-Renew Grace Period commenced, may delete the domain and receive an auto-renew fee refund. The registration period auto-renew extension is reversed and the domain enters the Redemption state.
– Renew: the sponsoring Registrar, who must be the sponsor when the auto-renew occurred, can renew the domain again causing an independent Renewal Grace Period to begin. The Registrar is charged and the registration period is extended by the renewal term, limited to the 10-year maximum.
– Transfer: an approved transfer command ends the current Auto-Renew Grace Period with a refund to the losing Registrar and begins a Transfer Grace Period. The registration period auto-renew extension is reversed and the registration is extended by the period specified in the transfer.
– Bulk Transfers: bulk transfers cause the Auto-Renew Grace Period to end without a refund; consequently, registration periods are not changed.

The Auto-Renew Grace Period does not have any impact on other commands.

4.4 Transfer Grace Period

Length: five days
RGP Status: transferPeriod
Transfer Grace Period allows the sponsoring Registrar to undo the registration period extension (due to a transfer command) via the deletion of a domain. This period begins on a transfer completion and lasts for five calendar days. If the following are performed during the period, these rules apply:
– Delete: the sponsoring Registrar, who must have initiated the transfer, may delete the domain and receive a transfer fee refund. The extension to the registration period of the preceding transfer is reversed and the Redemption state is entered.
– Renew: the sponsoring Registrar can renew the domain thus causing an independent Renewal Grace Period to begin. The Registrar is charged and the registration period for the domain is extended by the renewal term, limited to the 10-year maximum.
– Transfer: under Part A of the ICANN Policy on Transfer of Registrations between Registrars, a transfer may not occur during the 60-day period after transfer (except in special circumstances). The registry system enforces this — effects of transfer do not require consideration. Should a special situation require transfer back to the losing Registrar, this is dealt with by taking into account the specific situation. The registry system does not allow this without intervention by registry staff.
– Bulk Transfers: bulk transfers cause the Transfer Grace Period to end without a refund; consequently registration periods are not changed.

The Transfer Grace Period does not have any impact on other commands.

4.5 Redemption Grace Period
Length: 30 days
RGP Status: as described in Redemption state
Redemption Grace Period refers to the period of time the domain spends in the Redemption state, starting after a domain is deleted. The Redemption state description provides information on operations during this period.

4.6 Overlap of Grace Periods
The four possible overlapping grace periods are:
– Add Grace Period with one or more Renew Grace Periods.
– Renew Grace Period with one or more other Renew Grace Periods.
– Transfer Grace Period with one or more Renew Grace Periods.
– Auto-Renew Grace Period with one or more Renew Grace Periods.

These are treated independently with respect to timelines, however action that is taken has the combined effects of all grace periods still current.

4.6.1 Transfer Clarification

If several billable operations, including a transfer, are performed on a domain and it is deleted in the operations’ grace periods, only those operations performed after⁄including the latest transfer are eligible for refund.


5 TRANSITIONS

5.1 Available 〉 Registered

Triggered by the receipt of a create command to register the domain. The sponsoring Registrar is charged for the creation amount. This transition begins the Add Grace Period.

5.2 Registered 〉 Pending Transfer

Triggered by the receipt of a request transfer command, the transfer must result in domain registration extension — the gaining Registrar is charged for the transfer. Requests to transfer the domain within 60 days of creation or a previous transfer are rejected. As per ‘4.4 Transfer Grace Period’, exceptions specified in ICANN’s Transfer Policy apply, which are dealt with individually.

5.3 Pending Transfer 〉 Registered
Triggered by 1 of 4 operations:
– Operation 1 (Cancel): during the Pending Transfer period, the gaining Registrar may cancel the transfer by issuing a cancel transfer command. The gaining Registrar is refunded the transfer fee, the registration period remains unchanged and all existing grace periods at the time of transfer request remain in effect.
– Operation 2 (Reject): during the Pending Transfer period, the losing Registrar may reject the transfer by issuing a reject transfer command. The gaining Registrar is refunded the transfer. The registration period remains unchanged and all grace periods existing at the time of transfer request remain in effect, if not elapsed.
– Operation 3 (Approve): During the Pending Transfer period, the losing Registrar may approve the transfer by issuing an approve transfer command. If the transfer was requested during the Auto-Renew Grace Period, the extension to the registration period is reversed and the losing Registrar is refunded the auto-renew. The registration period is extended by the amount specified in the transfer request. This begins the Transfer Grace Period.
– Operation 4 (Auto-Approve): If, after 5 days, no action has been taken, the system approves the transfer. If the transfer was requested during the Auto-Renew Grace Period, the extension to the registration period is reversed and the losing Registrar is refunded the auto-renew. The registration period is extended by the amount specified in the transfer request. This begins the Transfer Grace Period.

5.4 Registered 〉 Deleted

On receipt of a delete command if the domain is in the Add Grace Period, it is purged from the Database and immediately available for registration. Renew Grace Period may also be in effect.

5.5 Registered 〉 Redemption

On receipt of a delete command if the domain is not in the Add Grace Period, it transitions to the Redemption Period state and all grace periods in effect are considered.

5.6 Redemption 〉 Pending Restore

On receipt of a restore command if the Redemption Period has not lapsed, the domain transitions to the Pending Restore state. The sponsoring Registrar is charged a fee for the restore request.

5.7 Pending Restore 〉 Registered

During the Pending Restore period, the sponsoring Registrar may complete the restore via a restore report containing the WhoIs information — submitted prior to the deletion, containing the WhoIs information at the time of the report and the reason for the restoration.

5.8 Pending Restore 〉 Redemption

If no restore report is received by seven calendar days after the transition to the Pending Restore state, the domain transitions to the Redemption state, which begins a new redemption period. The restore has no refund.

5.9 Redemption 〉 Pending Delete

If no restore request is received by 30 calendar days after the transition to the Redemption state, the domain transitions to the Pending Delete state.

5.10 Pending Delete 〉 Deleted

Five calendar days after the transition to the Pending Delete state, the domain is removed from the Database and is immediately available for registration.


6 LOCKS

Locks may be applied to the domain to prevent specific operations occurring. The sponsoring Registrar may set the locks prefixed with ‘client’, while locks prefixed with ‘server’ are added and removed by the registry operator. Locks are added and removed independently but they can be combined to facilitate the enforcement of higher processes such as ‘Registrar Lock’, and outcomes required as part of UDRP. All locks are compatible with EPP RFCs. The available locks are:
– clientDeleteProhibited, serverDeleteProhibited - Requests to delete the object are rejected
– clientHold, serverHold - DNS information is not published
– clientRenewProhibited, serverRenewProhibited - Requests to renew the object are rejected. Auto-renew is allowed
– clientTransferProhibited, serverTransferProhibited - Requests to transfer the object are rejected
– clientUpdateProhibited, serverUpdateProhibited - Requests to update the object are rejected, unless the update removes this status


7 SPECIAL CONSIDERATIONS

7.1 ICANN-Approved Bulk Transfers

ICANN-Approved Bulk Transfers performed in accordance with Part B of the Inter-Registrar Transfer Policy do not follow the typical transfer lifecycle. Existing grace periods are invalidated and no refunds are credited to the losing Registrar. The prohibition of transfer period on domains created or transferred within 60 days does not apply.

7.2 Uniform Rapid Suspension

In the Uniform Rapid Suspension (URS) process, as described in the ‘gTLD Applicant Guidebook’ 11th January 2012, the following modification to the above processes is required.

Remedy allows for the addition of one year to the registration period, limited to the 10-year maximum. During this time, no transform operations may be performed, other than to restore the domain as allowed by Appeal. At the expiration of the registration period the domain is not automatically renewed, it proceeds to the Redemption state as per the lifecycle described above and it is not eligible for restoration.


8 UPDATE⁄DNS

The update command does not impact the state of the domain through the Registration Lifecycle, however the command can be used to add and remove delegation information, which changes the DNS state of the domain.

A domain is required to have 2 or more nameservers published in the DNS. An update that results in a domain having less than 2 nameservers removes the domain from the DNS. An exception is when 1 nameserver remains assigned to deletion of its other nameservers due to a purge of their parent domain. The next update that modifies delegation information ends the exception and, from then on the domain requires 2 nameservers be published in the DNS.


9 RESOURCES

TRA’s resources to perform tasks in delivering services are:
TRA’s registry performs all time-based transitions automatically and enforces all other business rules without requiring human resources for normal operation. If changes to the automatic behaviours or restrictions enforced by the policy system are required, TRA will use ARI Registry Services (ARI), with whom they have a software support contract to develop changes. TRA has used ARI to deliver registry software for the ccTLDs of the UAE since 2007 and, as a result, has a strong relationship and history with ARI.

Domain Name Lifecycle aspects requiring human resources, which TRA will provide for this TLD include:
– Processing Add Grace Period exemptions, as requested by Registrars.
– Processing restore reports provided by Registrars.
– Meeting the registry operators’ obligations under ICANN’s Transfer Dispute Policy.
– Performing exception processing in the case of approved transfers during the 60-day transfer prohibition window.
The Registration Lifecycle is designed, built, operated and supported by these TRA departments:
– Technical Operations and Development team
– Legal Affairs team
- ICT Planning ⁄ Compliance team
and
ARI Registry Services (ARI)

The Technical Operations and Development team is responsible for product management of the Registration Lifecycle, including working with clients and the industry to identify new features or changes required to the system. The team consists of:
The team consists of:
– 1 Manager Technical Operations and Development
– Service Desk:
 – 2 Registrar Support Specialists (Level 2)
– Operations and Implementation (Level 3):
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network and Security Engineers

Most manual tasks fall to Compliance staff along with legal staff, who are experienced in implementation of policy in TLD environments. They have the required legal and industry background to perform this function:
– 1 Director of Legal Affairs
– 2 Legal Counsel 
- 1 Manager ICT Planning⁄Policy Compliance
– 3 Policy Compliance Officers 
The automated aspects of the Registration lifecycle are supported by TRA’s Domain Name Registry software. TRA uses ARI for software support and maintenance. This includes delivering updates and feature changes, as required. ARI will provide support resources as required to assist with feature changes and maintenance. TRA already makes use of this capacity on demand in delivering the .ae and .emarat (IDN) ccTLDs and expects to continue to do so.

Question 28 Abuse

1 INTRODUCTION

The efforts that will be undertaken in this TLD to minimise abusive registrations and other activities that have a negative impact on Internet users are described below. The League of Arab States (LAS) will be utilising the Anti-Abuse Service of our managed registry service provider, TRA. This service includes the implementation of our comprehensive Anti-Abuse Policy. This policy, developed in consultation with TRA, clearly defines abusive behaviour and identifies particular types of abusive behaviour and the mitigation response to such behaviour.


2 OVERVIEW

The League of Arab States has engaged TRA to deliver registry services for this TLD. TRA will, owing to their extensive industry experience and established anti-abuse operations under .ae ccTLD, implement and manage on our behalf various procedures and measures adopted to mitigate the potential for abuse, identify abuse, and handle identified abuse. TRA will forward to us all matters requiring determination by the registry operator that fall beyond the scope of TRA’s Anti-Abuse Service. This is described below in the context of the implementation of our Anti-Abuse Policy.
Despite utilisation of TRA’s Anti-Abuse Service, we are nonetheless cognisant of our responsibility to minimise abusive registrations and other activities that have a negative impact on Internet users who are using domain names registered in the TLD. In recognition of this responsibility, TRA will play an instrumental role in overseeing the implementation of the Anti-Abuse Service by TRA. We will also have contractual commitments in the form of SLA’s in place to ensure that TRA’s delivery of the Anti-Abuse Service is aligned with our strong commitment to minimise abuse in our TLD.
Please note that the various policies and practices that will be implemented to minimise abusive registrations and other activities that affect the rights of trademark holders are described in detail in our response to Question 29.


3 POLICY

In consultation with TRA we have developed a comprehensive Anti-Abuse Policy, which is the main instrument that captures our strategy in relation to abuse in the TLD.

3.1 Definition of Abuse

Abusive behaviour in a TLD may relate to the core domain name-related activities performed by registrars and registries including, but not limited to:
– The allocation of registered domain names.
– The maintenance of and access to registration information.
– The transfer, deletion, and reallocation of domain names.
– The manner in which the registrant uses the domain name upon creation.
Challenges arise in attempting to define abusive behaviour in the TLD due to its broad scope. Defining abusive behaviour by reference to the stage in the domain name lifecycle in which the behaviour occurs presents difficulty given that a particular type of abuse may occur at various stages of the life cycle.
With this in mind, TRA has fully adopted the definition of abuse developed by the Registration Abuse Policies Working Group (Registration Abuse Policies Working Group Final Report 2010), which does not focus on any particular stage in the domain name life cycle.
Abusive behaviour in a TLD may be defined as an action that:
– causes actual and substantial harm, or is a material predicate of such harm.
– is illegal or illegitimate, or is otherwise considered contrary to the intention and design of the mission⁄purpose of the TLD.
In applying this definition the following must be noted:
1. The party or parties harmed, and the severity and immediacy of the abuse, should be identified in relation to the specific alleged abuse.
2. The term ʺharmʺ is not intended to shield a party from fair market competition.
3. A predicate is a related action or enabler. There must be a clear link between the predicate and the abuse, and justification enough to address the abuse by addressing the predicate (enabling action).
For example, Whois data can be used in ways that cause harm to domain name registrants, intellectual property rights holders and Internet users. Harmful actions may include the generation of spam, the abuse of personal data, intellectual property infringement, loss of reputation or identity theft, loss of data, phishing and other cybercrime-related exploits, harassment, stalking, or other activity with negative personal or economic consequences. Examples of predicates to these harmful actions are automated email harvesting, support of false or misleading registrant data, and the use of Whois data to develop large email lists for commercial purposes. The misuse of Whois data is therefore considered abusive because it is contrary to the intention and design of the stated legitimate purpose of Whois data.

3.2 Aims and Overview of Our Anti-Abuse Policy

Our Anti-Abuse Policy will put registrants on notice of the ways in which we will identify and respond to abuse and serve as a deterrent to those seeking to register and use domain names for abusive purposes. The policy will be made easily accessible on the Abuse page of our registry website which will be accessible and have clear links from the home page along with FAQs and contact information for reporting abuse.
Our policy:
– Defines abusive behaviour in our TLD.
– Identifies types of actions that constitute abusive behaviour, consistent with our adoption of the RAPWG definition of ‘abuse’.
– Classifies abusive behaviours based on the severity and immediacy of the harm caused.
– Identifies how abusive behaviour can be notified to us, and the steps that we will take to determine whether the notified behaviour is abusive.
– Identifies the actions that we may take in response to behaviour determined to be abusive.

We will include the following text in the Registry-Registrar Agreement (RRA), which will oblige all registrants to comply with the Anti-Abuse Policy:
Compliance with terms and conditions:
The registrar shall comply with each of the following requirements, and further shall include in its registration agreement with each registrant, as applicable, an obligation for each registrant to comply with each of the following requirements:
‘operational standards, policies, procedures, and practices for the TLD established from time to time by the registry operator in a non-arbitrary manner and applicable to all registrars, including affiliates or resellers of the registry operator, and consistent with ICANNʹs standards, policies, procedures, and practices and the registry operator’s Registry Agreement with ICANN. Additional or revised registry operator operational standards, policies, procedures, and practices for the TLD shall be effective upon thirty days notice by the registry operator to the registrar. If there is a discrepancy between the terms required by this Agreement and the terms of the registrar’s registration agreement, the terms of this Agreement shall supersede those of the registrar’s registration agreement’

3.3 Anti-Abuse Policy

Our Anti-Abuse Policy is as follows:
Anti-Abuse Policy
Introduction:
The abusive registration and use of domain names in the TLD cannot be tolerated given that the inherent nature of such abuses creates security and stability issues for all participants in the Internet environment.
Definition of Abusive Behaviour:
Abusive behaviour is an action that:
– causes actual and substantial harm, or is a material predicate of such harm; or
– is illegal or illegitimate, or is otherwise considered contrary to the intention and design of the mission⁄purpose of the TLD.
A ‘predicate’ is an action or enabler of a harm.
‘Material’ means that something is consequential or significant.
Examples of abusive behaviour falling within this definition:
– Spam: the use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks.
– Phishing: the use of a fraudulently presented web site to deceive Internet users into divulging sensitive information such as usernames, passwords or financial data.
– Pharming: the redirecting of unknowing users to fraudulent web sites or services, typically through DNS hijacking or poisoning, in order to deceive Internet users into divulging sensitive information such as usernames, passwords or financial data.
– Wilful distribution of malware: the dissemination of software designed to infiltrate or cause damage to devices or to collect confidential data from users without the owner’s informed consent.
– Fast Flux hosting: the use of DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves in order to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast flux hosting may only be used with prior permission of the registry operator.
– Botnet command and control: the development and use of a command, agent, motor, service or software which is implemented: (1) to remotely control the computer or computer system of an Internet user without their knowledge or consent, (2) to generate direct denial of service (DDOS) attacks.
– Distribution of pornography: the storage, publication, display and⁄or dissemination of pornographic materials including those depicting individuals under the age of majority in the relevant jurisdiction.– Illegal access to other computers or networks: the illegal accessing of computers, accounts, or networks belonging to another party, or attempt to penetrate security measures of another individual’s system (hacking). Also, any activity that might be used as a precursor to an attempted system penetration.
Detection of Abusive Behaviour:
Abusive behaviour in the TLD may be detected in the following ways:
– By us through our on-going monitoring activities and industry participation.
– By third parties (general public, law enforcement, government agencies, industry partners) through notification submitted to the abuse point of contact on our website, or industry alerts.
Handling of abusive behaviour:
When abusive behaviour is detected in our TLD through notification by a third party, a preliminary assessment will be performed in order to determine whether the notification is legitimately made. Applying the definitions of types of abusive behaviours identified in this policy, we will classify each incidence of legitimately reported abuse into one of two categories based on the probable severity and immediacy of harm to registrants and Internet users. These categories are provided below and are defined by reference to the action that may be taken by us. The examples of types of abusive behaviour falling within each category are illustrative only.
Category 1:
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware
Mitigation steps:
1. Investigate
2. Notify registrant
Category 2:
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
Mitigation steps:
1. Suspend domain name 
2. Investigate
3. Restore or terminate domain name
In the event that we receive specific instructions regarding a domain name from a law enforcement agency, government or quasi-governmental agency utilising the expedited process for such agencies, our mitigation steps will be in accordance with those instructions provided that they do not result in the contravention of applicable law. In addition, we will take all reasonable efforts to notify law enforcement agencies of abusive behaviour in our TLD which we believe may constitute evidence of a commission of a crime, e.g. distribution of child pornography.
Note that these expected actions are intended to provide a guide to our response to abusive behaviour rather than any guarantee that a particular action will be taken.
The identification of abusive behaviour in the TLD, as defined above, shall give us the right, but not the obligation, to take such actions in accordance with the following text in the RRA, which provides that the registry operator:
‘reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that we deem necessary, in our discretion to;
1. protect the integrity and stability of the registry;
2. comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process;
3. avoid any liability, civil or criminal, on the part of the registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees, per the terms of the registration agreement; and
4. correct mistakes made by the registry operator or any registrar in connection with a domain name registration.’
We reserve the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.
We also reserve the right to deny registration of a domain name to a registrant who has repeatedly engaged in abusive behaviour in our TLD or any other TLD.
We may amend or otherwise modify this policy to keep abreast of changes in consensus policy or new and emerging types of abusive behaviour in the Internet.
Registrar’s failure to comply with this Anti-Abuse Policy shall constitute a material breach of the RRA, and shall give rise to the rights and remedies available to us under the RRA.


4 ABUSE PREVENTION AND MITIGATION

This section describes the implementation of our abuse related processes regarding:
– Building awareness of the Anti-Abuse Policy.
– Mitigating the potential for abusive behaviour.
– Identifying abusive behaviour.
– Handling abusive behaviour.

4.1. Awareness of Policy

The Anti-Abuse Policy will be published on the Abuse page of our registry website, which will be accessible and have clear links from the home page. In addition, the URL to the Abuse page will be included in all email correspondence to the registrant, thereby placing all registrants on notice of the applicability of the Anti-Abuse Policy to all domain names registered in our TLD. The Abuse page of our registry website will emphasise and evidence our commitment to combating abusive registrations by clearly identifying what our policy on abuse is and what effect our implementation of the policy may have on registrants. We anticipate that this clear message, which communicates our commitment to combating abusive registrations, will serve to minimise abusive registrations in our TLD.

4.2 Pre-emptive – Mitigating of the Potential for Abuse

The following practices and procedures will be adopted to mitigate the potential for abusive behaviour in our TLD.

4.2.1 ICANN Prescribed Measures

In accordance with our obligations as a registry operator, we will comply with all requirements in the ‘gTLD Applicant Guidebook’. In particular, we will comply with the following measures prescribed by ICANN which serve to mitigate the potential for abuse in the TLD:
– DNSSEC deployment, which reduces the opportunity for pharming and other man-in-the-middle attacks. We will encourage registrars and Internet Service Providers to deploy DNSSEC capable resolvers in addition to encouraging DNS hosting providers to deploy DNSSEC in an easy-to-use manner in order to facilitate deployment by registrants. DNSSEC deployment is further discussed in the context of our response to Question 43.
– Prohibition on Wild Carding as required by section 2.2 of Specification 6 of the Registry Agreement.
– Removal of Orphan Glue records (discussed below in ‎‘3.2.8 Orphan Glue Record Management’).

4.2.2 Increasing Registrant Security Awareness

In accordance with our commitment to operating a secure and reliable TLD, we will attempt to improve registrant awareness of the threats of domain name hijacking, registrant impersonation and fraud, and emphasise the need for registrants to keep registration information accurate. Awareness will be raised by:
– Publishing the necessary information on the Abuse page of our registry website in the form of videos, presentations and FAQ’s.
– Developing and providing to registrants and resellers Best Common Practices that describe appropriate use and assignment of domain auth Info codes and risks of misuse when the uniqueness property of this domain name password is not preserved.
The increase in awareness renders registrants less susceptible to attacks on their domain names owing to the adoption of the recommended best practices thus serving to mitigate the potential for abuse in the TLD.

4.2.3 Mitigating the Potential for Abusive Registrations that Affect the Legal Rights of Others

Many of the examples of abusive behaviour identified in our Anti-Abuse Policy relate to affecting the rights of trademark holders. While our Anti-Abuse Policy addresses abusive behaviour in a general sense, we have additionally developed specific policies and procedures to combat behaviours that affect the rights of trademark holders at start-up and on an ongoing basis. These include the implementation of a trademark claims service and a sunrise registration service at start-up and implementation of the UDRP, URS and PDDRP on an ongoing basis. The implementation of these policies and procedures serves to mitigate the potential for abuse in the TLD by ensuring that domain names are allocated to those who hold a corresponding trademark.
These policies and procedures are described in detail in our response to Question 29.

4.2.4 Safeguards Against Allowing for Unqualified Registrations

Our primary safeguard against allowing for unqualified registrations is the enforcement of general eligibility requirements on an ongoing basis through adoption of the Charter Eligibility Dispute Resolution Policy. The Charter Eligibility Dispute Resolution Policy will serve to facilitate our identification of unqualified registrations and will be implemented contractually by inclusion of the necessary terms in the Registration Agreement between registrars and registrants as required by the RRA. The Charter Eligibility Dispute Resolution Policy allows challenges against a registration on the grounds that it does not satisfy TLD eligibility requirements.
Having in place eligibility restrictions, providing an administrative process for enforcing these and taking action when notified of eligibility violations mitigates potential for abuse. This is achieved through the risk of cancellation in the event that it is determined in a challenge procedure that eligibility criteria are not satisfied.
Eligibility requirements for this TLD are explored in our response to Question 18.
This safeguard will be implemented contractually through our RRA, which will require registrars to provide the following in their Registration Agreements:
– Registrant warrants that it satisfies eligibility requirements.
– Registrant agrees to be bound by the Charter Eligibility Dispute Resolution Policy.
– Registrant acknowledges that its registration may be cancelled in the event that a challenge against it under the Charter Eligibility Dispute Resolution Policy is successful.

4.2.5 Registrant Disqualification

Abusive domain registration has historically attracted a small number of individuals and organisations that engage in high volume registrations, driven by the marginal profitability of individual abusive registrations. As specified in our Anti-Abuse Policy, we reserve the right to deny registration of a domain name to a registrant who has repeatedly engaged in abusive behavior in the TLD.
Registrants, their agents or affiliates found through the application of our Anti-Abuse Policy to have repeatedly engaged in abusive registration will be disqualified from maintaining any registrations or making future registrations. This will be triggered when our records indicate that a registrant has had action taken against it an unusual number of times through the application of our Anti-Abuse Policy. Registrant disqualification provides an additional disincentive for qualified registrants to maintain abusive registrations in that it puts at risk even otherwise non-abusive registrations, through the possible loss of all registrations.
In addition, name servers that are found to be associated only with fraudulent registrations will be added to a local blacklist and any existing or new registration that uses such fraudulent NS record will be investigated.
The disqualification of ‘bad actors’ and the creation of blacklists mitigate the potential for abuse by preventing individuals known to partake in such behaviour from registering domain names.

4.2.6 Restrictions on Proxy Registration Services

It is recognized that implementing measures to promote Whois accuracy is necessary to ensure that the registrant may be tracked down. Whilst it is understood that privacy of information is important however we recognize that tracking user information when incidents occur is difficult and slow with existence of privacy services. We will prohibit the usage of proxy registration services and therefore registrars will be obliged to pass the correct, accurate and complete Whois information to TRA.
These conditions will be implemented contractually by inclusion of corresponding clauses in the RRA as well as being published on the Abuse page of our registry website. Individuals and organisations will be encouraged through our Abuse page to report any domain names they believe violate the restriction on the availability of proxy registrations to individuals, following which appropriate action may be taken by us. Publication of these conditions on the Abuse page of our registry website ensures that registrants are aware that Whois information will be available publically and to law enforcement agencies (LEAs) in order to hold registrants liable for all actions in relation to their domain name. The certainty that Whois information relating to domain names that have drawn the attention of LEAs will be disclosed results in the TLD being less attractive to those seeking to register domain names for abusive purposes thus mitigating the potential for abuse in the TLD.

4.2.7 Registry Lock

Certain mission-critical domain names such as transactional sites, email systems and site supporting applications may warrant a higher level of security. Whilst we will take efforts to promote the awareness of security amongst registrants, it is recognised that an added level of security may be provided to registrants by ‘registry locking’ the domain name thereby prohibiting any updates at the registry operator level. The registry lock service will be offered to all registrars who may request this service on behalf of their registrants in order to prevent unintentional transfer, modification or deletion of the domain name. This service mitigates the potential for abuse by prohibiting any unauthorised updates that may be associated with fraudulent behaviour. For example, an attacker may update name servers of a mission-critical domain name, thereby redirecting customers to an illegitimate website without actually transferring control of the domain name.
Upon receipt of a list of domain names to be placed on registry lock by an authorised representative from a registrar, TRA will:
1. Validate that the registrar is the registrar of record for the domain names.
2. Set or modify the status codes for the names submitted to serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited depending on the request.
3. Record the status of the domain name in the Shared Registration System (SRS).
4. Provide a monthly report to registrars indicating the names for which the registry lock service was provided in the previous month.

4.2.8 Orphan Glue Record Management

The TRA registry SRS database does not allow orphan records. Glue records are removed when the delegation point NS record is removed. Other domains that need the glue record for correct DNS operation may become unreachable or less reachable depending on their overall DNS service architecture. It is the registrant’s responsibility to ensure that their domain name does not rely on a glue record that has been removed and that it is delegated to a valid name server. The removal of glue records upon removal of the delegation point NS record mitigates the potential for use of orphan glue records in an abusive manner.

4.2.9 Promoting Whois Accuracy

The provision of inaccurate Whois information significantly hampers the ability to enforce policies in relation to abuse in the TLD by allowing the registrant to remain anonymous. In addition, law enforcement agencies (LEAs) rely on the integrity and accuracy of Whois information in their investigative processes to identify and locate wrongdoers. In recognition of this, we will implement a range of measures to promote the accuracy of Whois information in our TLD including:
– Random monthly checks: registrants of randomly selected domain names are contacted by telephone using the provided Whois information by a member of the TRA Abuse and Compliance Team in order to verify the phone number and confirm other Whois information. Where the registrant is not contactable by telephone, alternative contact details (email, postal address) will be used to contact the registrant, who must then provide a contact number that is verified by the member of the TRA Policy Compliance team. In the event that the registrant is not able to be contacted by any of the methods provided in Whois, the domain name will be cancelled following five contact attempts or one month after the initial contact attempt (based on the premise that a failure to respond is indicative of inaccurate Whois information and is grounds for terminating the registration agreement).
– Email reminders: to update Whois information to be sent to registrants every 6 months.
– Reporting system: a web-based submission service for reporting Whois accuracy issues available on the Abuse page of our registry website.
– Analysis of registry data: to identify patterns and correlations indicative of inaccurate Whois (e.g. repetitive use of fraudulent details).
Registrants will continually be made aware, through the registry website and email reminders, to update Whois information of the ramifications of a failure to respond to random monthly checks and maintain accurate Whois information. Ramifications include but are not limited to termination of the Registration Agreement.
The measures to promote Whois accuracy described above strike a balance between the need to maintain the integrity of the Whois service, which facilitates the identification of those taking part in illegal or fraudulent behaviour, and the operating practices of the registry operator and registrars which aim to offer domain names to registrants in an efficient and timely manner.
Awareness by registrants that we will actively take steps to maintain the accuracy of Whois information mitigates the potential for abuse in the TLD by discouraging abusive behaviour given that registrants may be identified, located and held liable for all actions in relation to their domain name.

4.2.10 Eligibility Restrictions
Eligibility for domains in the .arab TLD requires that at least one contact for the domain originate from (and remain within) the Arab region (i.e. a Member State of the League of Arab States). This criteria plays a key role in ensuring the integrity of the .arab TLD as a namespace for and populated with, registrants from the Arab region. Registrar agreements and accreditation practices will emphasise the obligation of Registrars to ensure that domain name registrations meet this criteria and continue to do so as long as they are registered. Registrars will be required to ensure that at least one contact for any new registrations has a presence within the Arab region. On any update to the domain, the registrar will be required to ensure that changes to the domain’s contacts do not result in a situation where no contacts originate from within the Arab region.

These obligations will be codified within the Registry-Registrar Agreement. The practical application of such checks will be included as part of the initial accreditation process for registrars. 

4.3 Reactive – Identification

The methods by which abusive behaviour in our TLD may be identified are described below. These include detection by TRA or notification from third parties. These methods serve to merely identify and not determine whether abuse actually exists. Upon identification of abuse, such behaviour will be handled in accordance with ‘3.4 Abuse Handling’.

4.3.1 Detection – Analysis of Data

TRA will routinely analyse registry data in order to identify abusive domain names by searching for behaviours typically indicative of abuse. The following are examples of the data variables that will serve as indicators of a suspicious domain name and may trigger further action by the TRA Abuse and Compliance Team:
– Unusual Domain Name Registration Practices: practices such as registering hundreds of domains at a time, registering domains which are unusually long or complex or include an obvious series of numbers tied to a random word (abuse40, abuse50, abuse60) may, when considered as a whole, be indicative of abuse.
– An Unusual Number of Changes to the NS record: the use of fast-flux techniques to disguise the location of web sites or other Internet services, to avoid detection and mitigation efforts, or to host illegal activities is considered abusive in the TLD. Fast flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. As such an unusual number of changes to the NS record may be indicative of the use of fast-flux techniques given that there is little, if any, legitimate need to change the NS record for a domain name more than a few times a month.
– Results of Monthly Checks: The random monthly checks to promote Whois accuracy described above are not limited to serving that purpose but may also be used to identify abusive behaviour given the strong correlation between inaccurate Whois data and abuse.
– Analysis of cross-validation of registrant Whois data against Whois data known to be fraudulent.
– Analysis of Domain Names belonging to a registrant subject to action under the Anti-Abuse Policy: in cases where action is taken against a registrant through the application of the Anti-Abuse Policy, we will also investigate other domain names that have been registered by the same registrant (which will be done on the basis of querying the same name, nameserver IP address, email address, postal address etc in the SRS database).
- Analysis of contact locality: The data from random monthly checks will be cross-referenced in order to ensure that eligibility criteria, specifically the necessity to have one contact from within the Arab region, have not been breached.

4.3.2 Abuse Reported by Third Parties

Whilst we are confident in our abilities to detect abusive behaviour in the TLD owing to our robust ongoing monitoring activities, we recognise the value of notification from third parties to identify abuse. To this end, we will incorporate notifications from the following third parties in our efforts to identify abusive behaviour:
– Industry partners through TRA’s participation in industry forums which facilitate the sharing of information.
– LEAs, through a single abuse point of contact (our Abuse page on the registry website, as discussed in detail below) and an expedited process (described in detail in ‘3.4 Abuse Handling’) specifically for LEAs.
– Members of the general public through a single abuse point of contact (our Abuse page on the registry website).

4.3.2.1 Industry Participation and Information Sharing

One of TRA mandates is to manage the national computer emergency response team (aeCERT). The aeCERT look after issues such as fighting against cyber-attacks and resolving cybcer security incidents. The TRA is also a member of the Anti-Phishing Working Group (APWG) where it receives periodic advises and reports related to phishing incidents. TRA’s strong participation in the industry facilitates collaboration with relevant organisations on abuse-related issues and ensures that TRA is responsive to new and emerging domain name abuses.
The information shared as a result of this industry participation will be used to identify domain names registered or used for abusive purposes. Information shared may include a list of registrants known to partake in abusive behaviour in other TLDs. Whilst presence on such lists will not constitute grounds for registrant disqualification, TRA will investigate domain names registered to those listed registrants and take appropriate action. In addition, information shared regarding practices indicative of abuse will facilitate detection of abuse by our own monitoring activities.

4.3.2.2 Single Abuse Point of Contact on Website

In accordance with section 4.1 of Specification 6 of the Registry Agreement, we will establish a single abuse point of contact (SAPOC) responsible for addressing and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller. Complaints may be received from members of the general public, other registries, registrars, LEA, government and quasi-governmental agencies and recognised members of the anti-abuse community.
The SAPOC’s accurate contact details (email and mailing address as well as a primary contact for handling inquiries related to malicious behaviour in the TLD) will be provided to ICANN and published on the Abuse page of our registry website, which will also include:
– All public facing policies in relation to the TLD, including the Anti-Abuse Policy.
– A web-based submission service for reporting inaccuracies in Whois information.
– Registrant Best Practices.
As such, the SAPOC may receive complaints regarding a range of matters including but not limited to:
– Violations of the Anti-Abuse Policy.
– Inaccurate Whois information.
– Violation of the restriction of proxy registration services to individuals.
The SAPOC will be the primary method by which we will receive notification of abusive behaviour from third parties. It must be emphasised that the SAPOC will be the initial point of contact following which other processes will be triggered depending on the identity of the reporting organisation. Accordingly, separate processes for identifying abuse exist for reports by LEA⁄government and quasi-governmental agencies and members of the general public. These processes will be described in turn below.

4.3.2.2.1 Notification by LEA of Abuse

We recognise that law enforcement agencies (LEA), governmental and quasi-governmental agencies may be privy to information beyond the reach of others which may prove critical in the identification of abusive behaviour in our TLD. As such, we will provide an expedited process, which serves as a channel of communication for law enforcement agencies, government and quasi-governmental agencies to, amongst other things, report illegal conduct in connection with the use of the TLD.
The process will involve prioritisation and prompt investigation of reports identifying abuse from those organisations. The steps in the expedited process are summarised as follows:
1. We will identify relevant LEA, government and quasi-governmental agencies who may take part in the expedited process, depending on the mission⁄purpose and jurisdiction of our TLD.
2. We will establish back channel communication with each of the identified agencies in order to obtain information that may be used to verify the identity of the agency upon receipt of a report utilising the expedited process.
3. We will publish contact details on the Abuse page of the registry website for the SAPOC to be utilised by only those taking part in the expedited process.
4. All communication to this contact will be responded to by a member of the TRA Abuse and Compliance Team within 24 hours.
5. We will verify the identity of the reporting agency employing methods specific to that agency established during back channel communication (TRAʹs Security Policy has strict guidelines regarding the verification of external parties over the telephone).
6. Upon verification of the reporting agency, we will obtain the details necessary to adequately investigate the report of abusive behaviour in the TLD.
7. Reports from verified agencies may be provided in the Incident Object Description Exchange Format (IODEF) as defined in RFC 5070. Provision of information in the IODEF will improve our ability to resolve complaints by simplifying collaboration and data sharing.
8. The report identifying abuse will then be dealt with in accordance with ‘3.4 Abuse Handling’.

4.3.2.2.2 Notification by General Public of Abuse

Abusive behaviour in the TLD may also be identified by members of the general public, including but not limited to other registries, registrars or security researchers. The steps in this notification process are summarised as follows:
1. We will publish contact details on the Abuse page of the registry website for the SAPOC (note that these contact details are not the same as those provided for the expedited process).
2. All communications to this contact will be responded to by one of TRA’s Policy Compliance Officers.
3. The details of the report identifying abuse will be documented using a standard information gathering template and forwarded to a member of the Abuse and Compliance Team.
4. The report identifying abuse will then be dealt with in accordance with ‎‘3.4 Abuse Handling’.

4.4 Abuse Handling

Upon being made aware of abuse in the TLD, whether by ongoing monitoring activities or notification from third parties, the TRA Abuse and Compliance Team will perform the following functions:

4.4.1 Preliminary Assessment and Categorisation

Each report of purported abuse will undergo an initial preliminary assessment by the TRA Abuse and Compliance Team to determine the legitimacy of the report. This step may involve simply visiting the offending website and is intended to weed out spurious reports, and will not involve the in-depth investigation needed to make a determination as to whether the reported behaviour is abusive.
Where the report is assessed as being legitimate, the type of activity reported will be classified as one of the types of abusive behaviour as found in the Anti-Abuse Policy by the application of the definitions provided. In order to make this classification, the TRA Abuse and Compliance Team must establish a clear link between the activity reported and the alleged type of abusive behaviour such that addressing the reported activity will address the abusive behaviour.
While we recognise that each incident of abuse represents a unique security threat and should be mitigated accordingly, we also recognise that prompt action justified by objective criteria are key to ensuring that mitigation efforts are effective. With this in mind, we have categorised the actions that we may take in response to various types of abuse by reference to the severity and immediacy of harm. This categorisation will be applied to each validated report of abuse and actions will be taken in accordance with the table below. It must be emphasised that the actions to mitigate the identified type of abuse in the table are merely intended to provide a rough guideline and may vary upon further investigation.
Category 1
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware
Mitigation steps:
1. Investigate
2. Notify registrant
Category 2
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
Mitigation steps:
1. Suspend domain name
2. Investigate
3. Restore or terminate domain name
The mitigation steps for each category will now be described:

4.4.2 Investigation – Category 1

Types of abusive behaviour that fall into this category include those that represent a low severity or immediacy of harm to registrants and Internet users. These generally include behaviours that result in the dissemination of unsolicited information or the publication of illegitimate information. While undesirable, these activities do not generally present such an immediate threat as to justify suspension of the domain name in question. We will contact the registrant to instruct that the breach of the Anti-Abuse Policy be rectified. If the TRA Abuse and Compliance Team’s investigation reveals that the severity or immediacy of harm is greater than originally anticipated, the abusive behaviour will be escalated to Category 2 and mitigated in accordance with the applicable steps. These are described below.

4.4.3 Suspension – Category 2

Types of abusive behaviour that fall into this category include those that represent a medium to high severity or immediacy of harm to registrants and Internet users. These generally include behaviours that result in intrusion into other computers’ networks and systems or financial gain by fraudulent means. Following notification of the existence of such behaviours, the TRA Abuse and Compliance Team will suspend the domain name pending further investigation to determine whether the domain name should be restored or cancelled. Cancellation will result if, upon further investigation, the behaviour is determined to be one of the types of abuse defined in the Anti-Abuse Policy. Restoration of the domain name will result where further investigation determines that abusive behaviour, as defined by the Anti-Abuse Policy, does not exist. Due to the higher severity or immediacy of harm attributed to types of abusive behaviour in this category, TRA will, in accordance with their contractual commitment to us in the form of SLA’s, carry out the mitigation response within 24 hours by either restoring or cancelling the domain name.

Phishing is considered to be a serious violation of the Anti-Abuse Policy owing to its fraudulent exploitation of consumer vulnerabilities for the purposes of financial gain. Given the direct relationship between phishing uptime and extent of harm caused, we recognise the urgency required to execute processes that handle phish domain termination in a timely and cost effective manner. Accordingly, the TRA Abuse and Compliance Team will prioritise all reports of phishing from brand owners, anti-phishing providers or otherwise and carry out the appropriate mitigation response within 12 hours in accordance with the SLA’s in place between us and TRA. In addition, since a majority of phish domains are subdomains, we believe it is necessary to ensure that subdomains do not represent an unregulated domain space to which phishers are known to gravitate. Regulation of the subdomain space is achieved by holding the registrant of the parent domain liable for any actions that may occur in relation to subdomains. In reality, this means that where a subdomain determined to be used for phishing is identified, the parent domain may be suspended and possibly cancelled, thus effectively neutralising every subdomain hosted on the parent. In our RRA we will require that registrars ensure that their Registration Agreements reflect our ability to address phish subdomains in this manner.

4.4.4 Executing LEA Instructions

We understand the importance of our role as a registry operator in addressing consumer vulnerabilities and are cognisant of our obligations to assist LEA’s, government and quasi-governmental agencies in the execution of their responsibilities. As such, we will make all reasonable efforts to ensure the integration of these agencies into our processes for the identification and handling of abuse by, amongst other things:
1. Providing expedited channels of communication (discussed above).
2. Notifying LEA of abusive behaviour believed to constitute evidence of a commission of a crime e.g. distribution of child pornography.
3. Sharing all available information upon request from LEA utilising the expedited process, including results of our investigation.
4. Providing bulk Whois information upon request from LEA utilising the expedited process.
5. Acting on instructions by the agency.
TRA will, in accordance with their contractual commitment to us in the form of SLAs, respond to all reasonable requests for information from LEA within 12 hours.
It is anticipated that these actions will assist agencies in the prevention, detection, investigation, prosecution or punishment of criminal offences or breaches of laws imposing penalties. The relevant agencies are not limited to those enforcing criminal matters but may also include those enforcing civil matters in order to eliminate consumer vulnerabilities.
Upon notification of abusive behaviour by LEA, government or quasi- governmental agencies through the expedited process and verification of the reporting agency, one of the following may occur:
1. The reported behaviour will be subject to preliminary assessment and categorised as described above. The reported behaviour will then be mitigated based on the results of the categorisation. A report describing the manner in which the notification from the agency was handled will be provided to the agency within 24 hours.
OR
2. Where specific instructions are received from the reporting agency in the required format, TRA will act in accordance with those instructions provided that they do not result in the contravention of applicable law. TRA will, in accordance with their contractual commitment to us in the form of SLA’s, execute the instructions of the reporting agency within 12 hours. The following criteria must be satisfied by the reporting agency at this stage:
 a. The request must be made in writing to TRA using a Pro Forma document on the agency’s letterhead. The Pro Forma document will be sent to the verified agency upon request.
 b. The Pro Forma document must be delivered to TRA by fax.
 c. The Pro Forma document must:
 i. Describe in sufficient detail the actions the agency seeks TRA to take.
 ii. Provide the domain name⁄s affected.
 iii. Certify that the agency is an “enforcement body 
 iv. Certify that the requested actions are required for the investigation and⁄or enforcement of relevant legislation which must be specified.
 v. Certify that the requested actions are necessary for the agency to effectively carry out its functions.
Following prompt execution of the request, a report will be provided to the agency in a timely manner.
Finally, whilst we do not anticipate the occurrence of a security situation owing to our robust systems and processes deployed to combat abuse, we are aware of the availability of the Expedited Registry Security Request Process to inform ICANN of a present or imminent security situation and to request a contractual waiver for actions we might take or have taken to mitigate or eliminate the security concern.

5 RESOURCES

As this function is outsourced to TRA the following is a description, provided by TRA, of the resources that are allocated to performing the tasks required to deliver the services described.
These mechanisms serve to prevent and mitigate abusive behaviour in the TLD as well as activities that may infringe trademarks. These responsibilities will be undertaken by two teams. A development team from ARI Registry Services (ARI), under contract to TRA, will be responsible for developing the technical platforms and meeting technical requirements needed to implement the procedures and measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse. TRA’s Abuse and Compliance Team will be responsible for the ongoing implementation of measures to minimise abusive registrations and other activities that have a negative impact on Internet users.
The responsibilities of both of these teams relevant to the initial implementation and ongoing maintenance of our measures to minimise abusive registrations and other activities that affect the rights of trademark holders are described in our response to Question 29.
All of the responsibilities undertaken by TRA’s Development Team and Abuse and Compliance Team are inclusive in TRA’s Managed TLD Registry services fee, which is accounted for as an outsourcing cost in our response to Question 47. The resources needs of these teams have been determined by applying the conservative growth projections for our TLD (which are identified in our response to Question 48) to the team’s responsibilities at start-up and on an ongoing basis.

5.1 ARI Registry Services (ARI)

All tools and systems needed to support the initial and ongoing implementation of measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse will be developed and maintained by TRA’s software provider ARI. ARI has a software development department dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.
ARI’s Development Team participate actively in the industry; this facilitates collaboration with relevant organisations on abuse related issues and ensures that the ARI Development Team is responsive to new and emerging domain name abuses and the tools and systems required to be built to address these abuses. TRA’s contract with ARI ensures that all issues and required system enhancements are delivered by ARI in a timely fashion.

5.2 TRA Abuse and Compliance Team

TRA’s Abuse and Compliance Team are staffed by 4 full-time equivalent positions. These roles will entail the following:
Policy Compliance Officers: A principal responsibility of the Policy Compliance Officers will be handling notifications of abuse through the SAPOC. This will involve managing the expedited process, identifying and categorising suspected abuse according to our Anti-Abuse Policy, and carrying out the appropriate mitigation response for all categorised abuses. When abuse is identified, Policy Compliance Officers will investigate other domain names held by a registrant whose domain name is subject to a mitigation response. They will maintain a list of and disqualify registrants found to have repeatedly engaged in abusive behaviour. They will also be responsible for analysing registry data in search of behaviours indicative of abuse, reviewing industry lists in search of data that may identify abuse in the TLD.
Another key responsibility of Policy Compliance Officers will be implementing measures to promote Whois accuracy (including managing and addressing all reports of inaccurate Whois information received from the web submission service) and verifying the physical address provided by a registrant against various databases for format and content requirements for the region.
Policy Compliance Officers will act on the instructions of verified agencies or Dispute Resolution Providers and participate in ICANN and industry groups involved in the promulgation of policies and best practices to address abusive behaviour. They will escalate complaints and issues to the Legal Advisor when necessary and communicate with all relevant stakeholders (registrars, registrants, LEA, general public) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis.

Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, comprehensive knowledge of abusive behaviour in a TLD and related policies, Internet industry knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.

The team consists of:
– 1 Manager Internet Advancement
– 3 ICT Analysts (Policy Compliance Officers)


5.3 Legal Team
TRA’s Legal Team are staffed by 3 full-time equivalent positions. These roles will entail the following:

Legal Advisor: The Legal Advisor will be responsible for handling all potential disputes arising in connection with the implementation of TRA’s Anti-Abuse service and related policies. This will involve assessing escalated complaints and issues, liaising with Legal Director and the registry operator, resolving disputes and communicating with all relevant stakeholders (registrars, registrants, LEA, general public) as needed in fulfilling these responsibilities. The Legal Advisor will be responsible for forwarding all matters requiring determination by the registry operator which fall outside the scope of TRA’s Anti-Abuse functions. The Legal Advisor will be required to have the following skills⁄qualifications: legal background (in particular, intellectual property⁄information technology law) or experience with relevant tertiary or post-graduate qualifications, dispute resolution experience, Internet industry experience, strong negotiation skills, excellent communication and professional skills, good computer skills, high-level problem solving skills.

Legal Director: A qualified lawyer who will be responsible for all in-house legal advice, including responding to LEA and dealing with abusive behaviour.

The team consists of;
- 1 Director Legal Affairs
- 2 Legal Advisors

For more information on the skills and responsibilities of these roles please see the in-depth resources section in the attached resource allocation sheet.
Based on the projections and the experience of TRA, the resources described here are more than sufficient to accommodate the needs of this TLD.
The use of these resources and the services they enable is included in the fees paid to TRA which are described in the financial responses.

Question 29—Rights Protection Mechanisms

We have engaged TRA to deliver registry services for this TLD. This response describes Rights Protection Mechanisms (RPMs) as implemented by TRA.


1 INTRODUCTION

Our approach to RPMs has been designed to implement and comply with all of the RPMs mandated by the ‘gTLD Applicant Guidebook’. Our response below is organised by first addressing the RPMs that we will apply during start-up of our TLD (sunrise and trademark claims service) and then by addressing the RPMs that we will apply on an ongoing basis (URS, UDRP and efforts to avoid infringement trademark infringement including implementation of and compliance with the Trademark PDDRP). Each measure is described and the technological and contractual steps needed for its implementation are identified.
The abusive behaviour primarily targeted by sunrise, the trademark claims service, the URS, the UDRP, and the Trademark PDDRP is cybersquatting, which is the registration of domain names constituting trademarks by registrants lacking rights in such trademarks. Cybersquatting is one of the many forms of abuse that we will seek to minimise in our TLD. Our approach to combating abusive behaviours other than cybersquatting is described in detail in our response to Question 28. Some overlap between the responses to Questions 28 and Question 29 is inherent because the prevention of cybersquatting can also serve to minimise other abusive behaviours such as phishing and pharming. By implementing the RPMs discussed below we thus aim to minimise not only cybersquatting but also some of the abusive behaviours identified in the response to Question 28.
Finally, to clarify, we acknowledge that the legal rights protected by ICANN-mandated RPMs are limited to trademarks; this is consistent with the ‘gTLD Applicant Guidebook’ and applicable consensus policy. That said, different RPMs define the scope of protectable trademarks slightly differently; in our discussion below we clearly identify the scope of protectable marks as respects each RPM.

2 MANDATED START-UP RPMS

Below we identify our start-up RPM timeline and describe the way in which we will implement:
– A sunrise registration service.
– The trademark claims service during the land rush period.

2.1 Start-up RPMs Timeline

Pre-Sunrise: Solicitation of reserved domain names from ccTLDs and governments (through GAC representatives, through the ccTLD registry operators, etc.). The duration could range from 60 days up to one year.

Sunrise I: Corresponding governments and⁄or relevant entities may ʺactivateʺ domains from the reserved domains list obtained during Pre-Sunrise on a First-Come-First-Served basis. However, this step maybe skipped; governments can, after the launch of the gTLD, decide at any time when to activate the domains on the reserved list. Approximate duration: 60 days.

Sunrise II: Public bodies, holders⁄licensees of trademarks, holders of other prior rights (such as company names, trade names, business identifiers, personal names, …) may apply for domain names based on the names for which they hold prior rights. Approximate duration: 90 days.

Quiet Period: No registration period. Approximate duration: 30 days. 

Landrush: Anyone that meets the charter eligibility requirements may apply for any domain name. Approximate duration: 15 days. This will also imply the start of the Trademark Claims period, that will last for at least 60 days.

Auction: For domains that received more than one valid application during Sunrise II and Landrush, closed auctions will be held for all competing applicants. This can run in parallel to phases 3-5. Approximate duration: 30 days.

Go Live: live First-Come-First-Served registrations commence. The first 45 days of go Live will include the remainder of the Trademark Claims period. 


2.2 Sunrise Registration Service

Our sunrise registration service will provide trademark holders with a 90-day priority period in which to register their trademarks as domain names.
The following stakeholders are involved in implementation of the sunrise registration service:
– TMCH Service Provider(s)
– Trademark owner prospective domain name registrants
– Registrars
– Registry operator
– Auction provider
The role played by these stakeholders is described below by reference to:
– A summary of our Sunrise Policy and Sunrise Dispute Resolution Policy (SDRP)
– Our Sunrise Implementation Plan
– Our SDRP Implementation Plan
– Our implementation of sunrise and SDRP through contractual relationships

2.2.1 Sunrise Policy Summary and SDRP Summary

This section provides a summary of our Sunrise Policy and SDRP. Details regarding the implementation of these policies are provided in the next section of this response.
Our Sunrise Policy will meet the requirements laid down in (i), (iii) and (iv) of the eligibility requirements proposed in the ‘gTLD Applicant Guidebook’ at Trademark Clearinghouse section 6.2.3 will be eligible to apply for a domain name. However, in order to qualify for a domain name registration, the registrant must also meet the TLD-specific eligibility requirements set out in our response to Question 18. Trademark holders not meeting these requirements, may request their brand name to be put on a reserved list, and made unavailable for registration. Our Sunrise Policy will specify that applications received by a registrar throughout the sunrise period will be accepted for participation in the sunrise. This sunrise period will be the first opportunity for registration of domain names in our TLD.
Our Sunrise Policy will mandate that the trademarks upon which sunrise applications are based must fall within section 7.2 of the ‘gTLD Applicant Guidebook’ (Trademark Clearinghouse) and be supported by an entry in the TMCH.
In our Sunrise Policy we will describe how we will allocate domain names applied for during the sunrise period: sunrise allocation will start at the end of the 90-day sunrise period. Where only one validated application is received for a domain name, that domain name will be allocated to the applicant during the 10-day period between the close of the sunrise applications period and start of the land rush. Where multiple validated applications are received for a domain name, applicants will be invited to participate in an auction to determine the party to which the domain name will be allocated. Our Sunrise Policy will specify that by making a sunrise application (or, where relevant, by agreeing to participate in an auction), the applicant agrees to purchase the domain name if that name is allocated to the applicant. Domain names registered during the sunrise period will have a term of one year from the date of registration of the domain name.
Additionally we will adopt a Sunrise Dispute Resolution Policy (‘SDRP’) to allow any party to raise a challenge on the four grounds identified in the ‘gTLD Applicant Guidebook’ at Trademark Clearinghouse, section 6.2.4. The remedy offered by our SDRP will be cancellation or deletion of a successfully challenged domain name. As discussed below in the context of our implementation of sunrise through contractual relationships, all registrants in our TLD will be required to submit to proceedings under the SDRP. Our SDRP will specify that SDRP claims may be raised at any time after registration of a domain name applied for during sunrise and will require that complaints clearly identify the challenger, the challenged domain name, and the ground(s) upon which the complaint is based, and explain why the challenger believes that the ground(s) are satisfied.
If a TMCH service provider is not able to receive challenges directly as part of its undertaking to ‘maintain the SERs, validate and authenticate marks, as applicable, and hear challenges’ (‘gTLD Applicant Guidebook’ at Trademark Clearinghouse, section 6.2.5), TRA will receive SDRP challenges and communicate these to the SDRP provider. How these policies will specifically be implemented is detailed in our implementation plans below.

2.2.2 Implementation

Our Sunrise and SDRP Implementation Plans are set out below followed by a description of the implementation that will take place through contractual relationships. However, our Implementation Plans may change if third parties with whom the TRA will be required to operate, and in particular the Trademark Clearinghouse’s processes would be different than what has been assumed below.

2.2.2.1 Sunrise Implementation Plan

1. Prior to or during our 90-day sunrise period, trademark holders can apply for validation of trademarks by the TMCH and inclusion of validated marks in the TMCH database.
2. TRA will develop a website and make available on that website our Sunrise Policy and SDRP.
3. A trademark holder satisfying the sunrise eligibility requirements set out in our Sunrise Policy (as described above) will submit to a registrar its application to register a domain name corresponding to its TMCH entry along with evidence of the corresponding TMCH entry. A non-refundable sunrise application⁄validation fee will be payable by the applicant to the registrar on submitting the sunrise application.
4. Registrars will be required to communicate sunrise application information to TRA. On receipt of this information, TRA will charge the sunrise application⁄validation fee to the submitting registrar.
5. TRA will perform standard checks (including IDN validity checks where relevant, reserved and restricted words in accordance with the Registry Agreement, composition requirements, etc.) to ensure that the domain name being applied for is technically valid and an error message will be returned to the registrar if the domain name fails any of these checks. If the domain name passes these checks, TRA will hold the application for allocation after the close of the 90-day sunrise period.
6. Allocation of sunrise applications will commence upon conclusion of the 90-day sunrise period. As an initial step, TRA will compile a list of applied-for names and reserve these from registration in land rush and general availability.
7. Through an interface with the TMCH, TRA will identify all sunrise applications which constitute an ‘Identical Match’ (as defined in the ‘gTLD Applicant Guidebook’ at Trademark Clearinghouse section 6.1.5) with a TMCH entry and provide notice to the holders of those trademarks of the filing of a corresponding sunrise registration.
8. Where a single sunrise application exists for a particular domain name, between the end of the sunrise application period and start of the land rush application period TRA will enable the sponsoring registrar to CREATE (using EPP or the SRS web interface) the domain name and charge the sunrise registration fee to the registrar, who will collect this fee from the registrant.
9. Where multiple sunrise applications exist for an identical domain name, TRA will compile and communicate to a third-party auction services provider a list of competing applicants, who will be invited to participate in an auction for the domain name.
10. The auction services provider will facilitate the auction process and upon completion of the auction will notify all participants of the outcome and collect the auction payment from the winning participant.
11. Upon payment of the auction bid, the auction services provider will communicate to TRA the details of the winning auction participant and will submit the revenue collected to TRA.
TRA will validate the communication from the auction services provider and enable the sponsoring registrar to CREATE (using EPP or the SRS web interface) the domain name. TRA will charge the sunrise registration fee to the winning auction participant’s registrar, who will collect this fee from the registrant.

2.2.2.2 SDRP Implementation Plan

1. If a TMCH service provider is not able to directly receive complaints under our SDRP, we will specify in our SDRP the email address to which SDRP filings must be sent. This email address will be monitored by TRA’s Policy Compliance Team.
2. TRA will develop a process of manual or automatic interface with the TMCH to communicate our sunrise eligibility requirements and (if necessary) SDRP challenges received by TRA. This interface will also enable the relevant TMCH Service Provider to notify TRA of successful SDRP challenges.
3. Upon notification from a TMCH service provider of a successful SDRP challenge, TRA will cancel or delete the domain name the subject of the successful challenge.

2.2.2.3 Implementation through Contractual Relationships

The following features of the Sunrise and SDRP implementation plans described above will be executed by the inclusion of corresponding clauses in our RRA, which will require inclusion in registrars’ Domain Name Registration Agreements:
– By making a sunrise application (or, where relevant, by agreeing to participate in an auction), the applicant agrees to purchase the domain name if that name is allocated to the applicant.
– The sunrise application fee is non-refundable.
– All sunrise applicants must submit to proceedings under the SDRP.

2.3 Trademark Claims Service During Land Rush

Ten days after the day that sunrise allocations begin, a 60-day land rush period will commence during which we will offer the trademark claims service. The trademark claims service is a notification service whereby prospective domain name registrants in new gTLDs receive notice of existing trademark rights matching their applied-for domain name and trademark owners receive notice of domain name registrations matching their trademark. In accordance with the ‘gTLD Applicant Guidebook’, our trademark claims service will be supported exclusively by the TMCH and will recognise and honour all word marks falling within the ‘gTLD Applicant Guidebook’ at Trademark Clearinghouse section 7.1.
The following stakeholders are involved in implementation of the trademark claims service:
– Trademark Clearinghouse Service Provider(s)
– Trademark owners
– Land rush domain name applicants
– Land rush domain name registrants
– Registrars
– Registry operator
The role played by these stakeholders is described below by reference to:
– Our Land rush⁄Trademark Claims Service Implementation Plan.
– Our implementation of land rush⁄trademark claims service through contractual relationships.

2.3.1 Implementation

Our Land rush⁄Trademark Claims Service Implementation Plan is set out below followed by a description of the implementation that will take place through contractual relationships.

2.3.1.1 Land Rush⁄Trademark Claims Service Implementation Plan

1. Prior to or during our 60-day land rush period trademark holders can apply for validation of their trademarks by the TMCH and inclusion of validated marks in the TMCH database. This will enable the provision of notice to land rush applicants of entries in the TMCH and the provision of notice to trademark holders of domain name registrations matching TMCH entries (how and by whom this will be achieved is detailed in subsequent steps of this implementation plan).
2. An applicant will make an application to a registrar for a domain name during the 60-day land rush period. A non-refundable land rush application⁄validation fee will be payable by the applicant to the registrar on submitting the application.
3. Registrars will be required to communicate land rush application information to TRA. On receipt of this information, TRA will charge the land rush application⁄validation fee to the submitting registrar.
4. Registrars will be required to interface with the TMCH to determine whether an applied-for domain name constitutes an ‘Identical Match’ with a trademark in the TMCH. If an ‘Identical Match’ is identified, the registrar will provide to the land rush applicant a Trademark Claims Notice in the form prescribed by the ‘gTLD Applicant Guidebook’. Following receipt of this notice a land rush applicant must communicate to the registrar its decision either to proceed with or abandon the application. If the applied-for name does not constitute an ‘Identical Match’ with a trademark in the TMCH, no Trademark Claims Notice will be generated.
5. TRA will utilise the manual or automatic interface it establishes for implementation of the SDRP (described above in our SDRP Implementation Plan) to facilitate reporting by the TMCH of attempts to register domain names that are an ‘Identical Match’ with a trademark (within the scope of the ‘gTLD Applicant Guidebook’ at Trademark Clearinghouse section 7.1) in the TMCH database.
6. TRA will perform standard checks (including IDN validity checks where relevant, reserved and restricted words in accordance with the Registry Agreement, composition requirements, etc) on all land rush applications (irrespective of whether they have generated a Trademark Claims Notice) to ensure that the domain name being applied for is technically valid and an error message will be returned to the registrar if the domain name fails any of these checks. If the domain name passes these checks, TRA will hold the application for allocation after the close of the land rush application period.
7. Allocation of land rush applications will commence upon conclusion of the 60-day land rush applications period. Where a single land rush application exists for a particular domain name, between the end of the land rush application period and start of general availability, TRA will enable the sponsoring registrar to CREATE (using EPP or the SRS web interface) the domain name and charge the land rush registration fee to the registrar, who will collect this fee from the registrant.
8. Where multiple land rush applications exist for an identical domain name, TRA will compile and communicate to a third-party auction services provider a list of competing applicants, who will be invited to participate in an auction for the domain name.
9. The auction services provider will facilitate the auction process and upon completion of the auction will notify all participants of the outcome and collect payment from the winning participant.
10. Upon payment of the auction bid, the auction services provider will communicate to TRA the details of the winning participant and will submit the revenue collected to TRA.
11. TRA will validate the communication from the auction services provider and enable the winning auction participant’s registrar to CREATE (using EPP or the SRS web interface) the domain name. TRA will charge the land rush registration fee to the registrar, who will collect this fee from the registrant.
12. The registrar will interface with the TMCH to promptly notify relevant mark holders of the registration of a domain name constituting an ‘Identical Match’ to their TMCH entry.
13. Ten days after the start of the land rush allocation period, general availability of domain names (using first-come, first-served allocation) will commence.

2.3.1.2 Implementation through Contractual Relationships

The following features of our Land rush⁄Trademark Claims Service Implementation Plan described above will be executed by the inclusion of corresponding clauses in our RRA:
– Registrars must comply with the TMCH as required by ICANN and the TMCH Service Provider⁄s.
– Registrars must not in their provision of the trademark claims service make use of any other trademark information aggregation, notification or validation service other than the TMCH.
– In order to prevent a chilling effect on registration, registrars must ensure that land rush applicants are not prevented from registering domain names considered an ‘Identical Match’ with a mark in the TMCH.
– Registrars must provide clear notice in the specific form provided by the ‘gTLD Applicant Guidebook’ to the prospective registrant of relevant entries in the TMCH.
– The land rush application fee is non-refundable. Registrars must also include this in their Domain Name Registration Agreements.

3 MANDATED ONGOING RPMS

Below we describe the way in which we will implement on an ongoing basis the URS and UDRP and address issues related to the Trademark PDDRP. These RPMs serve to mitigate not only cybersquatting but other types of abusive behaviour that frequently occur in conjunction with cybersquatting such as phishing and pharming.

3.1 URS

The URS [Uniform Rapid Suspension] procedure is a new RPM the implementation of which is mandated in all new gTLDs. The URS is targeted at providing a rapid takedown solution to clear-cut cases of trademark cybersquatting. It is intended to have a deterrent effect and reduce the number of disputes under the UDRP.
The URS is intended to supplement and not replace the UDRP, and the ‘gTLD Applicant Guidebook’ foreshadows (at ‘gTLD Applicant Guidebook’, URS sections 8.6 and 13) the likelihood of URS claimants also commencing UDRP claims. For this reason, as part of its planning to implement the URS we have considered in our URS Implementation Plan the potential interaction between URS stakeholders and UDRP stakeholders.
The following stakeholders are involved in implementation of the URS:
– URS claimants (holders of valid and enforceable trade or service marks)
– Domain name registrants
– Registrar
– Registry operator
– URS provider(s) (not yet selected by ICANN)
– URS Examiner (to be selected by URS provider(s))
– The role played by these stakeholders is described below by reference to:
 – Our URS Implementation Plan
 – Our implementation of the URS through contractual relationships
In our implementation plan we identify certain aspects of implementation that are not clearly addressed in the ‘gTLD Applicant Guidebook’. For example, the Guidebook does not specify how, from an operational perspective, suspension of a domain name will transform to another domain name status (e.g. the transfer of a domain name following a successful UDRP challenge); we assume that such a status change would only occur upon expiry of the registration, but acknowledge the potential for further developments of the URS policy to allow for change of status as a result of a subsequent UDRP decision.
In addition to identifying such gaps, our URS Implementation Plan identifies our proposed method of addressing these. Furthermore, understanding that a fundamental aim of the URS is expediency, all of the steps in our Implementation Plan below will be undertaken as soon as practical but without compromising security or accuracy.

3.1.1 Implementation

Our URS Implementation Plan is set out below followed by a description of the implementation that will take place through contractual relationships.

3.1.1.1 URS Implementation Plan

1. As an initial step, TRA will notify to each URS provider an email address to which URS-related correspondence can be sent. On an ongoing basis, TRA will monitor this email address for receipt of communications from URS providers, including the Notice of Complaint, Notice of Default, URS Determination, Notice of Appeal and Appeal Panel Findings.
2. TRA will validate correspondence from a URS provider to ensure that it originates from the URS Provider.
3. TRA will within 24 hours of receipt of a URS Notice of Complaint lock the domain name(s) the subject of that complaint by restricting all changes to the registration data, including transfer and deletion of the domain name. The domain name will continue to resolve while in this locked status.
4. TRA will immediately notify the URS provider in the manner requested by the URS provider once the domain name(s) have been locked.
5. Upon receipt of a favourable URS Determination TRA will lock the domain name the subject of the Determination for the balance of the registration period and redirect the name servers to an informational web page provided by the URS provider. While a domain name is locked, TRA will continue to display all of the Whois information of the original registrant except for the redirection of the nameservers and (subject to future policy development taking into account the transfer of a URS-locked domain name following a successful UDRP challenge) the additional statement that the domain name will not be able to be transferred, deleted or modified for the life of the registration.
6. Upon receipt of notification from the URS provider of termination of a URS proceeding TRA will promptly unlock the domain name and return full control to the registrant.
7. Where a default has occurred (because a registrant has not submitted an answer to a URS complaint in accordance with the ‘gTLD Applicant Guidebook’ at URS section 6.1) and a Determination has been made in favour of the complainant, in the event that TRA receives notice from a URS provider that a Response has been filed in accordance with the ‘gTLD Applicant Guidebook’ at URS section 6.4, TRA will as soon as practical restore a domain name to resolve to the original IP address while preserving the domain’s locked status until a Determination from de novo review is notified to TRA.
8. TRA will ensure that no changes are made to the resolution of a registration the subject of a successful URS Determination until expiry of the registration or the additional registration year unless otherwise instructed by a UDRP provider.
9. TRA will make available to successful URS complainants an optional extension of the registration period for one additional year at commercial rates. We understand that this requirement has been based on the provision in the Expired Domain Deletion Policy (3.7.5.7 of the 2009 RAA), under which there is no requirement of notification to the complainant that a name is due to expire. From this we conclude that there is likewise no requirement in the operation of our TLD that TRA notify a successful URS complainant that a name is due to expire.
10. The ‘gTLD Applicant Guidebook’ specifies that renewal must be offered ‘at commercial rates’, but it is not specified how and to whom payment for renewal should be made. If payment is to be made to a stakeholder other than the registry operator, it is not clear how payments will be received by the registry operator. TRA’s Policy Compliance Team will be prepared and have the expertise and flexibility necessary to develop the technical and financial interfaces necessary to facilitate the receipt of renewal fees by TRA.

3.1.1.2 Implementation of the URS through Contractual Relationships

The following features of our URS Implementation Plan described above will be executed by the inclusion of corresponding clauses in our RRA:
– In the event that a registrant does not submit an answer to a URS complaint in accordance with the ‘gTLD Applicant Guidebook’ at URS section 6.1 (default), registrars must prevent registrants from making changes to the Whois information of a registration while it is in URS default.
– Registrars must prevent changes to a domain name when a domain is in locked status to ensure that both the registrar’s systems and registry’s systems contain the same information for the locked domain name.
– Registrars must not take any action relating to a URS proceeding except as in accordance with a validated communication from TRA or a URS provider.

3.2 UDRP

The UDRP [Uniform Domain Name Dispute Resolution Policy] is applicable to domain name registrations in all new gTLDs. It is available to parties with rights in valid and enforceable trade or service marks and is actionable on proof of all of the following three grounds:
i. the registrant’s domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights.
ii. the registrant has no rights or legitimate interests in respect of the domain name.
iii. the registrant’s domain name has been registered and is being used in bad faith.
The remedies offered by the UDRP are cancellation of a domain name or transfer of a domain name registration to a successful UDRP claimant.
The following stakeholders are involved in implementation of the UDRP:
– UDRP claimants
– Domain name registrants
– Registrar
– Registry operator
– UDRP providers (currently 4 approved by ICANN)
The role played by these stakeholders is described below by reference to:
– Our UDRP Implementation Plan
– Our implementation of the UDRP through contractual relationships
Our UDRP Implementation Plan considers the potential overlap between URS implementation and UDRP implementation because we consider it likely that URS complainants will commence UDRP claims as a second recourse or simultaneously. We note that neither policy prohibits complainants from commencing proceedings simultaneously.

3.2.1 Implementation

Our UDRP Implementation Plan is set out below followed by a description of the implementation that will take place through contractual relationships.

3.2.1.1 UDRP Implementation Plan

Our UDRP Implementation Plan focuses on interaction with registrars because at present there is no interaction between existing gTLD registry operators and UDRP providers. On this basis we consider that TRA has two responsibilities in order to facilitate registrars’ implementation of the UDRP.
1. TRAʹs Abuse and Compliance Team (details about which are provided in ‘4 RESOURCES’) will maintain awareness of UDRP requirements and be capable of taking action when required and sufficiently skilled and flexible to respond to any changes to UDRP policy arising from future consensus policy reviews.
2. TRA will provide EPP and the SRS web interface to enable registrars to perform required UDRP functions in accordance with the Policy on Transfer of Registrations between registrars.

3.2.1.2 Implementation of the UDRP through Contractual Relationships

The UDRP is applicable to domain name registrations in all new gTLDs by force of a contractual obligation (Registry Agreement Art. 2.9) on registry operators to use only ICANN-accredited registrars, who in turn are contractually required (Registrar Accreditation Agreement, 21 May 2009, at 3.8) to incorporate the UDRP in their Domain Name Registration Agreements.

3.3 Preventing Trademark Infringement in Operating the Registry

We take seriously our responsibilities in running a registry and we understand that while offering a sunrise registration service and the trademark claims service during start-up of our TLD and the URS and UDRP on an ongoing basis serves to minimise abuse by others, this does not necessarily serve to minimise trademark infringement in our operation of the TLD. This responsibility is now clearly expressed and imposed upon registries through the new Trademark PDDRP [Post-Delegation Dispute Resolution Procedure], which targets infringement arising from the registry operator’s manner of operation or use of its TLD.
Whilst we will as required under the Registry Agreement agree to participate in all Trademark PDDRP procedures and be bound by the resulting determinations, we will also have in place procedures to identify and address potential conflicts before they escalate to the stage of a Trademark PDDRP claim.
The following stakeholders are involved in our implementation of measures to prevent trademark infringement in our running of the TLD:
– Trademark holders
– Registry operator
– Trademark PDDRP provider⁄s (not yet selected by ICANN)
The role played by these stakeholders is described below by reference to:
– Our Trademark PDDRP Implementation Plan
– Our implementation of our Trademark PDDRP through contractual relationships

3.3.1 Implementation

Our Trademark PDDRP Implementation Plan is set out below followed by a description of the implementation that will take place through contractual relationships.

3.3.1.1 Trademark PDDRP Implementation Plan

1. TRA will notify to the Trademark PDDRP provider(s) contact details to which communications regarding the Trademark PDDRP can be sent.
2. As described in our response to Question 28, TRA will publish our Anti-Abuse Policy on a website specifically dedicated to abuse handling in our TLD. This website will include information necessary to enable trademark holders to raise concerns regarding infringement of their trademarks and resultant harm caused by our manner of operation or use of our TLD.
3. Using the single abuse point of contact discussed in detail in our response to Question 28, a complainant can notify TRA of its belief that one or more of its marks have been infringed and harm caused by our manner of operation or use of our TLD. The complainant will be required to provide the following information:
– Name of the complainant
– Contact details
– Trademark name
– Jurisdiction
– Registration date
– Registration number
– Nature of entitlement to trademark
– Explanation of why complainant believes that its mark has been infringed and harm caused by our manner of operation or use of the TLD
4. A TRA Customer Service Representative (CSR) will receive complaints submitted through the single abuse point of contact. The details of the complaint (which will at a minimum include the information above) will be documented using a standard information gathering template and forwarded to a member of TRA’s Abuse & Compliance Team.
5. Upon receipt of a complaint, the Abuse & Policy Compliance Team will conduct a preliminary assessment to ensure that a complaint is not spurious. If the Abuse & Policy Compliance Team determines that a complaint is not spurious, a member of the team will use the contact details provided in the complaint to acknowledge receipt of the complaint and commence investigation of the subject matter of the complaint and good faith negotiations with the complainant in accordance with the ‘gTLD Applicant Guidebook’ at Trademark PDDRP section 7.2.3(d).
6. On an ongoing basis, TRA’s Policy Compliance Team will monitor the email address notified to the Trademark PDDRP provider(s) for all communications from the Trademark PDDRP provider, including the threshold determination, Trademark PDDRP complaint, complainant’s reply, notice of default, expert panel determinations, notice of appeal and determinations of an appeal panel.
7. In the event that a complaint cannot be resolved and a Trademark PDDRP claim is made, TRA will do the following:
– File a response to the complaint in accordance with Trademark PDDRP policy section 10 (thus avoiding, whenever possible, a default situation).
– Where appropriate, make and communicate to the Trademark PDDRP provider decisions regarding the Trademark PDDRP proceeding, including whether to request a three-person Trademark PDDRP Expert Panel (Trademark PDDRP policy section 13.2), request discovery (section 15.1), request and attend a hearing (section 16), request a de novo appeal (section 20.1), challenge an ICANN-imposed Trademark PDDRP remedy (section 21.3), initiate dispute resolution under the Registry Agreement (section 21.4), or commence litigation in the event of a dispute arising under the Trademark PDDRP (section 22).
– Where appropriate, undertake discovery in compliance with Trademark PDDRP policy section 15, attend hearings raised under section 16 if required, and gather evidence in compliance with sections 20.5 and 20.6.
8. TRA will upon notification of an Expert Panel finding in favour of the Claimant (Trademark PDDRP policy section 14.3), reimburse the Trademark PDDRP Claimant.
9. TRA will implement any remedial measures recommended by the expert panel pursuant to Trademark PDDRP policy section 18.3.1 and take all steps necessary to cure violations found by the expert panel (Trademark PDDRP policy section 18.3.2) and notified by ICANN (Trademark PDDRP policy section 21.3).

3.3.2 Implementation of Trademark PDDRP through Contractual Relationships

All new gTLD registry operators are bound to comply with the Trademark PDDRP by force of Specification 7, clause 2 of the Registry Agreement.

4 RESOURCES

TRA’s Abuse & Compliance Team and Legal Team will be responsible for the ongoing operations of our measures to minimise activities that affect trademark rights.

All of the responsibilities undertaken by TRA’s Legal Team, and Abuse & Compliance Team are inclusive in TRA’s Managed TLD Registry services fee, which is accounted for as an outsourcing cost in our responses to Question 47. The resources needs of these teams have been determined by applying the conservative growth projections for our TLD (which are identified in our response to Question 48) to the team’s responsibilities at start-up and on an ongoing basis.

4.1 ARI Registry Services (ARI)

All tools and systems used for the transmission and receipt of information related to rights protection mechanisms by TRA will be developed and maintained by ARI through their registry software supplier contract with TRA. ARI has a development team dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.
TRA will ensure that systems and tools will be compliant with the appropriate processes for dealing with registrars, the TMCH, URS and Trademark PDDRP providers as these processes are defined and will include these requirements as acceptance criteria for any software provided by ARI. TRA has been and will remain active in the formulating of these processes. TRA will use its resources to remain current with the approved measures for exchange of RPM-related material or any other material relevant to RPMs, whether that is during sunrise, landrush or on an ongoing basis. The Abuse & Compliance and Business Operations & Development teams, and Registrar Support Specialists will assess the software.

4.2 TRAʹs Abuse and Compliance Team

TRA’s Abuse & Policy Compliance Team will be staffed by 4 full-time equivalent positions. These roles will entail the following:
Policy Compliance Officers will be responsible for managing sunrise and land rush applications, supporting the SDRP, trademark claims service, URS, UDRP and Trademark PDDRP, managing communications with the TMCH, receiving, assessing and managing trademark infringement complaints received through the single abuse point of contact, escalating complaints and issues to the Legal Advisor when necessary, and communicating with all relevant stakeholders (registrars, registrants, trademark holders, general public) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis. Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, complete knowledge of all RPMs offered by the TLD and related policies, Internet industry knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.

The team consists of:
– 1 Manager Internet Advancement
– 3 ICT Analysts (Policy Compliance Officers)



4.3 TRAʹs Legal Affairs Team

The Legal Advisor will be responsible for handling all potential disputes arising in connection with RPMs and related policies. This will involve assessing complaints and issues, liaising with legal counsel and management, resolving disputes and communicating with all relevant stakeholders (registrars, registrants, trademark holders, general public) as needed in fulfilling these responsibilities. The Legal Advisor will be required to have the following skills⁄qualifications: legal background (in particular, intellectual property⁄information technology law) or experience with relevant tertiary or post-graduate qualifications, dispute resolution experience, Internet industry experience, strong negotiation skills, excellent communication and professional skills, good computer skills, high-level problem solving skills.

The team consists of;
- 1 Director Legal Affairs
- 1 Legal Advisor

The League of Arab States (LAS) has engaged the Telecommunications Regulatory Authority UAE (TRA) to deliver Registry Services for this TLD. This response describes the Security Policy for this TLD as provided by TRA.

Questions 30(a) Security Policy (external)

TRA provides Registry Services for two TLDs which are the .ae ccTLD and .emarat (IDN) ccTLD. For more background information on TRA please see the attachment ‘Q30a – TRA Background & Roles.pdf’. This response describes Security as implemented by TRA under direction from the registry operator taking into account any specific needs for this TLD.


1 SECURITY POLICY SUMMARY

TRA operates an International Organization for Standardization 
(ISO)27001 compliant Information Security Management System (ISMS) for Domain Name Registry Operations, for which certification is expected by the middle of 2012. The ISMS is an organisation-wide system encompassing all levels of Information Security policy, procedure, standards, and records. Full details of all the policies and procedures included in the ISMS are included in the attachment to Question 30b.

1.1 The ISMS

TRA ISMS’s governing policy:
- Defines the scope of operations to be managed (Domain Name Registry Operations).
- Designates the responsible parties (EDTDA, Director TRA and MTOD) for governance as ISMS Management Committee, ISO for implementation and maintenance, ISA for internal audit and the TOD to support ISO for technical deployed..
- Requires a complete Risk Assessment (a developed Security Threat Profile for the Service – in this case Registry Services for the TLD – and a Risk Analysis tracing threats and vulnerabilities through to Risks) and Risk Treatment Plan (each major risk in the Risk Assessment references the Statement of Applicability indicating controls to be implemented, responsible parties, and the effectiveness metrics for each).
- Includes a series of major sub policies governing security, which include but are not limited to:
 - TRA acceptable use policy and physical security policies.
 - TRA Security Policy which outlines the registry operations policies, the management of end-user devices, classification of networks and servers according to the classification of information they contain, networking, server & database configuration and maintenance guidelines, vulnerability and patch management, data integrity controls, access management, penetration testing, third party management, logging and monitoring, and cryptography.
- Requires ongoing review:
 - Of risks, threats, the Risk Treatment Plan, client requirements and commitments, process and policy compliance, process and policy effectiveness, user etc.
 - Regular internal and external penetration testing & vulnerability scanning.
 - Ad-hoc review raised during normal operations, common sources being change management processes, scheduled maintenance or project debriefs, and security incidents.
 - Yearly review cycle which includes both internal and external audits, including audits for compliance.
 - Additional yearly security controls assessment reviews, which include analysis of the security control implementations themselves (rather than compliance with any particular standard).
 - At 12 month intervals, external penetration testing of TRA infrastructure including data centre sites.
 - Periodic ISO reaccreditation
TRA ISMS encompasses the following standards:
- Configuration standards for operating systems, networking devices and databases based on several key publications, including those released by NIST (e.g. SP800-123, SP800-44v2, SP-800-40, SP800-41) and the NSA, staff testing and experience, and vendor supplied standards.
- Security Incident Classification, which identifies the various classifications of security incidents and events to ensure that events that qualify as security incidents.
- Information Classification and Handling which specifies the information classification scheme and the specific requirements of handling, labelling, management and destruction for each level of classification.

1.2 SECURITY PROCESSES

Processes are used to implement the policies. These include, but are not limited to:

1.2.1 Change Management

This includes change management and its sub-processes for access management, software deployment, release of small changes and scheduled maintenance. This process includes:
– The classification of changes and the flow into sub processes by classification.
– The release and deployment process for change control into production environments, outlining peer review, testing steps, approval points, checklist sets, staging requirements and communication requirements.
– The software release and deployment process with its specific testing and staged rollout requirements.
– The scheduled maintenance process and its various review points.

1.2.2 Incident Management

This includes incident management process and its sub-process for unplanned outages. These outline:
– How incidents are managed through escalation points, recording requirements, communication requirements etc.
– The unplanned outage procedure which applies directly to situations where the registry itself or other critical services are unexpectedly offline.

1.2.3 Problem Management

The goal of problem management is to drive long term resolution of underlying causes of incidents. This process centres on finding and resolving the root causes of incidents. It defines escalation points to third parties or within TRA, as well as verification of the solution prior to problem closure.

1.2.4 Security Incident Management

This process deals with the specific handling of security incidents. It outlines the requirements and decision points for managing security incidents. Decision points, escalation points to senior management and authorities are defined, along with evidence-gathering requirements, classification of incidents and incident logging.

1.2.5 Access Management

This process handles all access changes to systems. HR must authorize new users, and access changes are authorized and approved by departmental managers and verified by the Information Security Officer. When staff leave or significantly change roles, a separation process is followed which ensures all access that may have been granted during their employment (not just their initially granted access) is checked and where appropriate, revoked.

Finally, biannual review of all access is undertaken by the ISO, reviewing and approving or rejecting (with an action ticket) as appropriate.


2 TRA SECURITY INFRASTRUCTURE SOLUTIONS

TRA has developed a layered approach to IT security infrastructure. At a high level, some of the layers are as follows:
– DDoS countermeasures are employed outside TRA networks. These include routing traps for DDoS attacks, upstream provider intervention, private peering links and third party filtering services.
– Routing controls at the edge of the network at a minimum ensures that only traffic with valid routing passes into TRA networks.
– Overprovisioning and burstable network capabilities help protect against DoS and DDoS attacks.
– Network firewalls filter any traffic not pre-defined by network engineering staff as valid.
– Application layer firewalls then analyse application level traffic and filter any suspicious traffic. Examples of these would be an attempt at SQL injection, script injection, cross-site scripting, or session hijacking.
– Server firewalls on front-end servers again filter out any traffic that is not strictly defined by systems administrators during configuration as valid traffic.
– Only applications strictly necessary for services are running on the servers.
– These applications are kept up-to-date with the latest security patches, as are all of the security infrastructure components that protect them or that they run on.
– TRA infrastructure is penetration-tested by external tools and contracted security professionals for vulnerabilities to known exploits.
– TRA applications are tested to security standards such as OWASP and penetration-tested for vulnerabilities to common classes of exploits by external security professionals such as aeCERT.
– TRA configures SELinux on its production servers. Specific details of this configuration is confidential; essentially any compromised application is extremely limited in what it can do.
– Monitoring is used to detect security incidents at all layers of the security model. Specifically:
 – Network Intrusion Detection systems are employed to monitor TRA networks for suspicious traffic.
 – TRA maintains its own host-based Intrusion Detection system based on tripwire, which has now undergone four years of development. Specific details are confidential, but in summary, the system can detect any unusual activity with respect to configuration, program files, program processes, users, or network traffic.
 – More generic monitoring systems are used as indicators of security incidents. Any behaviour outside the norm across over 950 individual application, database, systems, network and environmental checks is investigated.
– Capacity management components of the monitoring suite are also used to detect and classify security incidents. Some examples are:
 – Network traffic counts, packet counts and specific application query counts.
 – Long term trend data on network traffic vs. specific incident windows.
 – CPU, Storage, Memory and Process monitors on servers.
– A second layer of hardware firewalling separates application and middle tier servers from database servers.
– Applications only have as much access to database information as is required to perform their function.
– Finally, database servers have their own security standards, including server-based firewalls, vulnerability management for operating system and RDBMS software, and encryption of critical data.

2.1 Physical Security Infrastructure

TRA maintains a series of physical security infrastructure measures including but not limited to physical access controls to secured areas and security camera recording, alarm systems and monitoring.


3 COMMITMENTS TO REGISTRANTS

We commit to the following:
– Safeguarding the confidentiality, integrity and availability of registrant’s data.
– Compliance with the relevant regulation and legislation with respect to privacy.
– Working with law enforcement where appropriate in response to illegal activity or at the request of law enforcement agencies.
– Maintaining a best practice information security management system that is established on ISO27001 compliance.
– Validating requests from external parties requesting data or changes to the registry to ensure the identity of these parties and that their request is appropriate. This includes requests from ICANN.
– That access to DNS and contact administrative facilities requires multi-factor authentication by the Registrar on behalf of the registrant.
– That Registry data cannot be manipulated in any fashion other than those permitted to authenticated Registrars using the EPP or the SRS web interface. Authenticated Registrars can only access Registry data of domain names sponsored by them.
- A Domain transfer can only be done by utilizing the AUTH CODE provided to the Domain Registrant.
– Those emergency procedures are in place and tested to respond to extraordinary events affecting the integrity, confidentiality or availability of data within the registry.


4 AUGMENTED LEVEL OF SECURITY

This TLD is a generic TLD and as such requires security considerations that are commensurate with its purpose. Our goal with this TLD is to provide registrants with adequate protections against unauthorized changes to their names, without making the registration process too onerous and thus increasing costs.
The following attributes describe the security with respect to the TLD:
 - TRA’s Domain Administration Department follows the highest security standards with respect to its Registry Operations. TRA is pursuing the ISO 27001 certification and has been operating a Registry backend for around4 years. TRA has confirmed their adherence to all of the security standards as described in this application. 
 - Registrant will only be permitted to make changes to their domain name after authenticating to their Registrar.
 - Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
 - Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
 - Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
 - Registrars will only be permitted to use a certificate signed by TRA to connect with the Registry systems. Self-signed certificates will not be permitted.
- The Registry is Domain Name Security Extensions (DNSSEC) enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to question 43. The following additional requirements will exist for Registrars who want to get accredited to sell this TLD:
 - Registrars must support DNSSEC capabilities within its control panels.
 - If the Registrar provides Managed DNS services to Registrants within this TLD they must provide the option for DNSSEC. This ensures that DNSSEC is deployed at each zone and subsequent sub-zones at Registry, Registrar and Registrant level.
- Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication. This is described in detail in our responses to Question 24 and Question 25.
- Registrant access to all Registrar and Registry Systems will be via TLS and secured with multi-factor authentication. This is described in detail in our response to Question 25, Question 27 and Question 29. 
 - All communication between the Registrar or the Registrars systems and the registry system is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57. This includes the following communication:
 - Secure websites and control panels provided by the Registrar to the Registrant.
 - Ticketing systems provided by the Registrar to the Registrant.
 - Web and EPP interfaces provided by TRA to the Registrars.
 - Ticketing systems provided by TRA to the Registrar.
 - Any communication between the Registrant, Registrar and Registry that is deemed as critical or contains credentials or sensitive information.

Where these requirements put controls on Registrars these will be enforced through the Registry Registrar Agreement (RRA).


5 RESOURCES

This function will be performed by TRA. The following resources are allocated to performing the tasks required to deliver the services described:
– Executive Management Team (3 staff)
– Technical Operations & Development (9 staff)
aeDA has 4 years’ experience designing, deploying, securing and operating critical Registry systems.
TRA’s senior management are technology and methodology leaders in their respective fields who ensure the organization maintains a focus on technical excellence and hiring, training and staff management.
Executive Management are heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
- Executive Director Technology Development Affairs
- Director aeDA
A detailed list of the departments, roles and responsibilities in TRA is provided as attachment ‘Q30a – TRA Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to operate and support the Shared Registry System (SRS) does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that TRA provides Registry Services to.
TRA provides registry backend services to 2 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience TRA estimates that the existing staff is adequate to support a registry system that supports in excess of 2M domains. Since this TLD projects 50333 domains, 2.52% of these resources are allocated to this TLD. See attachment ‘Q30a – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
TRA protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally TRA can scale resources as required. Additional trained resources can be added to any of the above teams with a 3 month lead time.
The TRA is responsible for the deployment and operation of TLD registries.
The TOD team consists of:
- 1 Manager – Technical Operations & Development
- Service Desk:
 - 2 Registry Specialists (Level 2 support)
- Operations (Level 3):
 - 2 Systems Administrators
 - 2 Database Administrators
 - 2 Network Engineers
The BOD team consists of;
- 1 Business Operations Officer
- 4 Customer Support Representatives (Level 1 support)

TRA employs a rigorous hiring process and screening (Police background checks for technical staff and UAE Federal Government level security clearances for registry operations staff).