ICANN New gTLD Application


A venue for dialogue and creative engagement of all the parties concerned, .TATAR will serve as an on-line platform to represent the Tatars on the Internet as an ethnic group, with its background, language, historic and cultural riches.

For academic and experts, and other parties concerned, both in Tatarstan and overseas, .TATAR provides an ultimate pool of information and data best practices, whether for academic research, or every day, eg. culinary, artisan, etc., experiences.

For public associations and profile governmental organizations .TATAR grants access to a broad, diverse audience and forms an efficient way to mobilize and engage local residents, the civil society groups, and overseas stakeholders in various kinds of activities associated with the Tatars.
For businesses .TATAR provides a unique chance to most effectively reach out to, and market their products and services among a huge target audience and in so doing, establish their presence and promote their brands and values with a very broad circle of consumers. 

The overarching purpose of .TATAR is to bolster the target audiences - and in the first place ethnic Tatars’ - trust in the Internet per se and its opportunities and benefits for an ethnic group’s advancement. By indoctrinating certain groups to the Internet’s positive effects, .TATAR helps its expansion nationwide.

That the project on launching a new gTLD for the Tatars is indeed central to the Republic’s strive for promotion of ethnic and cultural diversity is proved by the support and endorsement from a number of leading local institutions.

.TATAR forms a specialized environment which consolidates a high-quality and rapidly increasing educational, historic, ethnic, cultural, etc. content whose safety rests upon rigorous administrative procedures and robust technical solutions. 

Once delegated, .TATAR should promote integration of educational, information projects and programs, games and contests, including interactive ones, etc. with a due account of the target audiences’ needs and interests.

.TATAR constitutes a genuinely multistakeholder undertaking, which engages civil society, business, academia, educational, government and technical community, thus qualifying as an exemplary self-regulated, open, voluntary and all-inclusive initiative in a region where such things are still nascent, thus paving the way for new initiatives of this sort. 

.TATAR gives impulse to the rise of new Internet resources for specific agents, thus encouraging software developers to embark on new, software development projects, thus boosting competition and creativity in the respective area. 

.TATAR focuses primarily on Tatar communities residing both in Russia and overseas; however, it may become a model project for different ethnic groups, should they take on similar efforts, which would add to diversity of the global Internet.

.TATAR contributes to socialization of the environment and promotion of the civil-society values. With the rise of new exciting resources and convenient tools, new population groups go online. The more comprehensive those resources and tools are, the more Tatars, the elderly and the young alike, will be keen to master and explore the Internet, thus bolstering both their respective skills and the Internet’s expansion in the Republic and in Russia as a whole, thus narrowing digital divide in the Republic and in Russia.

.TATAR offers ample marketing opportunities for a broad array of businesses. Not only will the new gTLD become home to corporate websites of local multi-billion undertakings, but its profile will enable businesses to narrow down their marketing strategies, more effectively establish and promote their brands and respective values, target very concrete audiences and reap additional benefits vis-à-vis potential rivals, as .TATAR will minimize search efforts for a potential multimillion community and maximize businesses’ on-line identity. The Applicant believes business initiatives will account for a relatively significant fraction within the gTLD, while another important one should become public agencies and municipal bodies and respective institutions. Their presence in .TATAR will help domestic communities and individuals to more closely and effectively monitor and evaluate their performance and make them more transparent and accountable, thus ensuring a greater efficacy of public service and the Republic’s fast progress on the path towards e-government. 

.TATAR offers the possibility for a transparent and easy-to-implement control over community-specific resources adhering to the Tatar’s fundamentals and long-standing traditions, meaning abiding by certain moral principles and zero tolerance towards hatred, including racial, ethnic, etc. one, opprobriousness, violence.

Thus, the use of the addressing within the gTLD ensures certain control (with the use of technical means and thanks, inter alia, to the societal and centralized expert control), while not precluding the possibility for users to pick a certain resource and safely surf across .TATAR.

.TATAR thus becomes a unique identifier attributing a given Internet resource to a specific ethnic and cultural community, the mark of its safety and security and observance with certain moral traditions and policies.

As .TATAR suggests unique content focused primarily on Tatar speakers, the gTLD is set to satisfy the needs of Tatars of all ages, walks of life, and countries of residence. Using Tatar as their native language, the users find it easy to key in the name of their favorite resource in the browser window using the Latin script, which is not foreign both to “Russian” Tatars, who used to practice the Latin version of the native alphabet and – even more so- to a broad audience across Newly Independent States, and overseas. 
So, all that will propel increase in the number of Internet users across Russia and helps them diversify their user skills and experiences worldwide.

The Applicant understands that the registration policies in the applied-for gTLD are to be in compliance with the standards, requirements and limitations outlined in the Registry Agreement, the Registry-Registrar Agreement (RRA), Registrar Accreditation Agreement (RAA), as well as other general policies, standards and procedures established by ICANN. 

In addition, the Applicant intends to establish in the applied-for gTLD supplementary policies, rules, procedures, requirements and limitations according to its mission and purposes. These regulations and rules shall be developed by the Applicant basing both on law of the Russian Federation, the ones of the Republic of Tatarstan, information presented in this Application, and the existing best practices.
The Applicant reserves the right to introduce certain supplementary policies in gTLD .TATAR in the future which shall not contradict standards, procedures, requirements and policies set by the ICANN and the Registry-Registrar Agreement.

Hereinafter Registrar refers to the ICANN-accredited registrar that has entered in Registry-Registrar Agreement with the Registry Operator of applied-for gTLD. 

The Registry Operator, Registrars and domain name holders are bound to comply with the conditions stipulated in the aforementioned documents. Registrars are also obligated to include necessary terms and conditions into their agreements with registrants (hereinafter - registration agreements), and must require one’s mandatory familiarization with and acceptance of these terms.

In pursuit of the mission of the new IDN gTLD, the Applicant plans to establish therein the following policies and basic principles:

1) Registration policies

a) The second-level domain names should be registered through ICANN-accredited registrars only. The Registry Operator enters into a Registry-Registrar Agreement with an ICANN-accredited registrar provided the latter fully shares and supports the mission, purpose and philosophy of gTLD .TATAR. 

b) Any corporation or individual has the right to register a second-level domain in .TATAR, provided the prospective registrant fully shares and supports the mission, purposes and philosophy of .TATAR.

c) There is no restriction on the number of domain names that may be registered by a registrant during the Landrush and Live periods.

d) A registrant may not register a domain name for the sole purpose of resale or transfer to another entity.

e) It is possible to register domain names that comply with the following conditions: 
- being from 3 up to 63 characters long;
- containing only letters of the Latin alphabet (a-z), numbers (0-9) and hyphens (-), or a combination of these; 
- starting and ending with a number or a letter, not a hyphen; and 
- not containing hyphens in the third and fourth position (eg. ab--cd.TATAR).  

f) Registration of domain names is possible for a term between 1 and 10 years, where “year” refers to a full calendar year. Domain name registration may be renewed for any term between 1 and 10 years. 

g) A clear and unequivocal identification of domain name registrants will be mandatory in .TATAR, with no possibility for any domain name registrant to retain complete anonymity. While submitting an application for domain name registration, the prospective registrant shall produce a set of data and⁄or documents per the respective list established by the Registry Operator, including commitment on the purpose of the domain registration and 2 recommendations by existing registrants in .TATAR. Where a registrant has made a false warranty or otherwise acted in bad faith in order to register a domain name, the Registry Operator reserves the right to cancel the domain name registration. 

h) The Registrars comply with the obligation to collect information about domain name registrants and verify its authenticity, and have the right to request respective documents to prove authenticity of the information given by registrant. Special incentives are planned for Registrars to improve WHOIS data accuracy, including marketing benefits for Registrars being most active in this regard, with all the Registrars being on equal footing in this respect.

i) The Applicant will introduce the Reserved List containing words and symbol combinations that may not be registered. 

j) It is prohibited to register domain names which include words contradicting public interests, the principles of humanity or morality, in particular, words of obscene content, slogans of antihuman character, which insult human dignity or religious feelings. Where Registry Operator has detected or got complain regarding such a domain name registered, Registry Operator reserves the right to cancel registration of the domain name. The Applicant will develop a detailed description of procedures and modus operandi for such situations. Measures on identification and prevention of an abusive registration of domain names are considered in a greater detail in the response to Evaluation Question #28 (Abuse prevention and mitigation).

k) The Applicant does not plan to implement any second-level domain names of special type to register third-level domain names. The registrant of a second-level domain name may carry out registration of a third-level domain in the registrant’s domain. The said registrant determines his own terms and procedures for the third-level domain name registration, provided they conform with the overarching registration and usage procedures and policies established for and in the TLD. 

l) It is envisaged that first there will be launched a Sunrise period intended for owners of exclusive rights to a trade mark, public agencies, registered mass media, and public associations, followed by the Landrush period during which domain names will be made available for any applicant at a premium price. Where more than one application for a certain second-level domain has been submitted during the Sunrise stage or the Landrush stage, then that domain name shall be set for an auction. Subsequently, registration will be carried out on the First Come First Served principle.

2) Domain name use policy

The Registry Operator is determined to control the use of domain names in accordance with the mission and purposes of the gTLD and with the registrant’s intended purpose as established in the registrant’s registration application. A set of strict measures will be adopted with regard to misuse of domain names aiming to prevent or minimize the phishing, spamming, malware distributing as well as bearing any content contradicting moral and public order, law, and⁄or mission and purpose of .TATAR.

a) Registrant is considered to be fully responsible for misuse (both in terms of malicious conduct or content placement) of the domain name and assumes the responsibility for any possible consequences for the actions, where a registrant allows third parties to post content on resources addressed in Internet with the use of the respective domain name. 

b) Where the Registry Operator detects abuse or receives an abuse complaint, then the Registry Operator reserves the right to take any immediate action to stop the abuse within a shortest possible time after such an abuse was exposed, including, but not limited to, cancelling the domain registration. Where it has been found out that the genuine purpose of a registered domain name is not in compliance with the mission and purpose of the .TATAR project, to terminate the abuse the Registry Operator reserves the right to impose on the domain name registrant sanctions to the extent of cancelation domain name registration.

Measures on identification and prevention of an abusive registration of domain names are considered in a greater detail in the response to Evaluation Question #28 Abuse prevention and mitigation.

The Applicant is a legal entity incorporated in the Russian Federation and shall abide by the Russian law. In accordance with the Federal Act of Russian Federation #152-FZ “On personal data”, the Registry Operator exercises a set of measures to protect registrants’ personal data. The Applicant will introduce policies and procedures regarding personal data processing including keeping, transferring and using such data while rendering domain name registration services, transferring the data to the registry, depositing, etc. 

Specifically, when a domain name registrant is a private individual, his⁄her written consent is required to display his⁄her data in WHOIS results. The Registry Operator requires from the Registrars to obtain such a written consent from domain name holders. Where a written consent to publish personal data in WHOIS is not granted, such data will be depersonalized. 

According to the above mentioned Federal Act, the Registry Operator may not disclose any personal data of individual domain name registrants, but Registrar may disclose the personal data of individuals only upon an official request by a government agency authorized for that in compliance with Russian and international law (law enforcement agencies, courts etc).

The Applicant understands that regular awareness raising and communication with various stakeholders are critical to expansion of .TATAR, as well as to building its identity among other top-level domains both in Russia and overseas. To this effect, the Applicant is committed to reaching out to various stakeholders, including both the primary audience and other audiences concerned, be those academic, social, educational institutions, public associations, public agencies and businesses, with a series of bold and explicit messages packaged in an integrated marketing strategy. The strategy is to ensure a synergy effect from the Registry Operator’s various PR and marketing activities tailored to promote the new gTLD and centering largely on Russian Federation and CIS countries wherein most Tatar-speaking Internet users reside. Meanwhile, special messages and communication channels should be designed to ensure a greater, Europe-wide and global outreach to and engagement of international audiences, including ethnic Tatars and other non-Tatar parties concerned. 

At this point, it should be noted that .TATAR is a commercial project whose potential audiences are local (Tatarstan) and nationwide (Russia as a whole) and international (both Tatar and non-Tatar, but sharing the same identity and culture) audiences representing all the above stakeholder groups. Thus, communication campaigns for .TATAR should be multi-faceted and cater to raising awareness among the said communities, key stakeholders and decision makers in the first place, as well as to their encouragement to use the Internet to their own advantage and promote their initiatives online.

The integrated marketing strategy will rest upon four pillars:

a) positioning of .TATAR as a global domain Embassy for both the Tatar-speaking and multilingual audience;
- .TATAR’s positioning is to exhibit its unique qualities and highlight its identity among other gTLDs. That should help reap competitive benefits from .TATAR having a unique, long-lasting presence in the Internet, which appears attractive and consonant with its target audience’s natural drive for ethnic-wise self-identification; 
- .TATAR aims at winning the Internet users’ confidence that registration of both profit-making and non-for-profit, social projects in the gTLD should become a common practice for all the parties concerned. Registrations are set to be run perpetually, as .TATAR is going to be a universal, rather than mono-ethnic TLD.

b) Marketing program to back distribution channels and engage registrars (and their resellers) in promotion of .TATAR
The fundamental components of this program are:
- marketing research to improve the Applicant’s knowledge of the target audiences’ needs and ensure a credible feedback from them;
- a program to raise the audiences’ awareness and encourage domain name registrations by cooperating with key players and associations: e.g. using a site as an advertising and sales channel; and .TATAR’s participation in major fairs and exhibitions. 
- Dissemination of marketing materials, which allows direct communication with prospective domain name administrators.
- Maintaining a distribution system to engage registrars in support to, and promotion of .TATAR.

c) Awareness raising campaign focusing on a broad audience of Internet users (on the primary market in the first place), which includes the following activities:
- Highlighting benefits and advantages of owning and operating a domain in .TATAR; 
- Showcasing individual success stories built on TATAR’s identity and opportunities it offers

d) Educational activities
- Engagement of nonprofit media, including social ones, to diffuse key messages to the audiences concerned;
- Holding workshops and seminars to educate customers about terms and conditions of domains registration of in .TATAR 

e) Building a set of incentives to bolster distribution channels for .TATAR’s services. To that end, certain messages will propagate extra benefits from being in and with .TATAR, such as subsidies, membership and organizational bonuses, etc. 
Integrated efforts to promote the project through engagement of all the stakeholders concerned and by versatile means will help communicate to the broad audience fundamental principles underpinning the .TATAR project, encourage emerging academic, societal, non-for-profit and business projects and materialize creative ideas of using the new gTLD for the benefit of the Tatar community and beyond.

1. INTRODUCTION

The Applicant plans to provide the following services:

a) Domain Name Registration Services.
b) Dissemination of TLD zone files.
c) Dissemination of contact or other information concerning domain name registrations (WHOIS).
d) DNS Security Extensions (DNSSEC).
e) Registrar services.
f) End-user services.

The registry services will be implemented with regard for stability and safety requirements set forth in ICANN policies.

To maintain the stable environment, registry services will be provided in accordance with applicable standards and recommendations of IETF and best practices whose value was proven by international Internet community and ICANN.

For safety reasons the access to services for registrars and other users is limited by using technical means, such as access list management, number of requests limit assignment, usage of cryptography and management of login names and passwords. Detailed security policies are described in the answer to Evaluation Question #30 (b).

The second-level domain name registration, as well as receipt or update of registry data are implemented in compliance with RFC 5730-5734, 3915 and do not affect the bandwidth, response time, data consistency or coherence of answers transferred to Internet servers or end-user systems.

DNS services comply with the officially applied standards (RFC 1035 and Specification 4 to the Registry Agreement (hereinafter – Specification 4)) and, due to employment of a distributed system, they do not create conditions which negatively impact bandwidth, response time, data consistency or coherence of answers transferred to Internet servers or end-user systems.

WHOIS service is implemented in compliance with Specification 4 and RFC 3912.

DNSSEC service is implemented in compliance with RFC 4033-4035, 5155, 5910.

2. DOMAIN NAME REGISTRATION SERVICES

A full range of standard domain registration services will be provided. All this services are made available for any ICANN-accredited registrar who has entered into Registry-Registrar Agreement (RRA) with Registry Operator (hereinafter – Registrar).

The services enumerated in this section cannot be provided for an object that has EPP status prohibiting the operation. The Registrar sponsoring object cannot override the restriction set by the Registry. The complete description of statuses is provided in RFC 5730-5733.

2.1. Domain name registration

Domain name registration service consists of the insertion of the domain name, registration period, registrant and registrant’s contacts, NS records into the registry database. The record is entered on the basis of an application submitted by the registrant to the Registrar.

Registrars process the registrantʹs domain name registration orders through SRS using EPP. The domain can be registered for a period from 1 to 10 years at the Registrar’s discretion, but no more than 10-year period, provided that:
- All necessary contact objects were created in the registry;
- The registered domain name meets the requirements set forth in the second-level domain registration policy in .TATAR gTLD (The registration policy overview is given in the answer to Evaluation Question #18);
- The domain name has not been registered and is not retained in the Reserved Names List;
- The Registrar fulfils all the terms set forth in the agreement with the Registry Operator including, but not limited to, compliance with the technical and administrative policies.

Having met these conditions, the domain name registration shall be carried out by SRS. Information on registered domain names shall be available via WHOIS public server.

Upon a successful domain name registration, the Registrar is charged a fee in the amount defined in RRA.

To manage domain name registration process EPP protocol is in use, as described in the answer to Evaluation Question #25. The service uses the EPP Domain Mapping «create» query command.

2.2. Domain name renewal

Domain name may be renewed for the period of 1 to 10 years, but no more than 10 years Renewal may be carried out only by the Registrar sponsoring the domain name.

Renewal is permitted from the moment of domain name registration in the registry database and through the beginning of the redemption grace period. Where the request for a domain renewal beyond the permitted period has been submitted or where after the renewal for the number of years defined by the Registrar the registration expiration timeline is in excess of 10 years, the request is rejected.

Upon successful completion of the domain renewal the sponsoring Registrar is charged a fee per RRA terms.

The service uses the EPP Domain Mapping «renew» query command.

2.3. Domain Auto-Renewal

When a domain reaches its expiration date the registry will automatically renew the domain for one additional year and charge the sponsoring Registrar. The Registrar has the Auto Renew grace period (0-45 days, depending on the Registrar policy) to delete the domain and receive a refund for the automatic renewal.

2.4. Domain recovery within Redemption Grace period (RGP)

The domain name can be recovered during the Redemption Grace Period in compliance with policies and procedures established in .TATAR gTLD and RFC 3915.

The service uses the EPP Domain Mapping «update» query command with the EPP Extension Redemption Grace Period Mapping «restore»; provided, however, that in the case of (i) Bulk Transfers under Part B of the ICANN Policy on Transfer of Registrations between Registrars and (ii) Large Incidents, Restore may be accomplished by e-mail or fax using a Restore Request Form as specified by Registry Operator .TATAR.

Upon successful recovery of the domain from RGP the sponsoring Registrar of the domain name is charged a domain name recovery fee per RRA terms.

2.5. Domain transfer

Domain transfer is performed by Registrars in compliance with ICANN Inter-Registrar Transfer Policy (IRTP), RRA agreement and .TATAR regulations.

For domain transfer the Registrars use the EPP Domain Mapping «transfer» request or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part.

The financial details of domain transfers are completely described in the answer to Evaluation Question #27.

The detailed restrictions of domain transfers are described in the answer to Evaluation Question #25 and #27.

2.6. Domain deletion

The domain can be deleted by the sponsoring Registrar prior to expiration of the domain registration term or during the Auto-Renew Grace period.

The service uses the EPP Domain Mapping «delete» query command.

The details of domain deletion including financial ones are described in the answer to Evaluation Question #27.

When a domain is deleted, all Host objects for which this domain is the parent domain will also be deleted. The orphan glue record policy is described in the answer to Evaluation Question # 28.

2.7. Transform functions

All services enumerated in this section are non-billable.

The following features allow data within the registry to be manipulated by Registrars:

2.7.1. Update Domain

A Registrar uses the Update Domain service to change attributes of a domain for which it is the sponsoring Registrar. Attributes that can be changed include: the corresponding contacts, nameservers, EPP Domain-related extensions, including DNSSEC, and domain status. The domain name cannot be delegated if less than 2 nameservers are associated with it. The sponsoring Registrar can set EPP-statuses for the domain, which preclude some operations: clientUpdateProhibited disables the domain information update, clientRenewProhibited disables the domain renewal, clientTransferProhibited disables the domain transfer, clientDeleteProhibited disables the domain deletion. Update Domain uses the EPP Domain Mapping «update» command.

2.7.2. Add Nameserver

Registrars use the Add Nameserver service to create a new host object in the registry. Nameservers can only be created by the sponsoring Registrar of the parent domain object. A nameserver can be created with up to 13 IP addresses. Add Nameserver uses the EPP Host Mapping «create» command.

2.7.3. Modify Nameserver

Registrars use the Modify Nameserver service to change the IP addresses associated with a nameserver or change the name or statuses. The modification of a nameserver can only be performed by the sponsoring Registrar of the nameserver. Modify Nameserver uses the EPP Host Mapping «update» command.

2.7.4. Delete Nameserver

Registrars use the Delete Nameserver service to remove a host object from the registry. A Registrar can only delete a nameserver for which it is the sponsoring Registrar. A nameserver can only be deleted if is not associated with any domains in the registry. Delete Nameserver uses the EPP Host Mapping «delete» command.

2.7.5. Add Contact

Registrars use the Add Contact service to create a new contact object in the registry. Add Contact uses the EPP Contact Mapping «create» command.

2.7.6. Modify Contact

Registrars use the Modify Contact service to change the attributes including statuses of a contact object. The modification of a contact can only be performed by the sponsoring Registrar of the contact. Modify Contact uses the EPP Contact Mapping «update» command.

2.7.7. Delete Contact

Registrars use the Delete Contact service to remove a contact object from the registry. A Registrar can only delete a contact for which it is the sponsoring Registrar. A contact can only be deleted if is not associated with any domains in the registry. Delete Contact uses the EPP Contact Mapping «delete» command.

2.7.8. Transfer Contact

Registrars use the Transfer Contact service to change a domainʹs sponsoring Registrar. Transfer Contact uses the EPP Contact Mapping «transfer» transform command. A contact can only be transferred if is not associated with any domains in the registry. The different operations that can be performed using the «transfer» command are: Request, Query, Cancel, Approve, Reject.

2.8. Querying functions

The following query types will be available to Registrars so they can examine information within the registry. All services enumerated in this section are non-billable.

2.8.1. Check Domain

Registrars use the Check Domain service to find out if a domain exists as a valid object in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ to the Check Domain request. Check Domain uses the EPP Domain Mapping «check» command.

2.8.2. Query Domain

Registrars use the Query Domain service to retrieve the domain information of a domain object in the registry. Only the sponsoring Registrar of a domain can retrieve its domain information. Query Domain uses the EPP Domain Mapping «info» command.

2.8.3. Query Domain Transfer Status

Registrars use the Query Domain Transfer Status service to find out the status of a domain transfer. Query Domain Transfer Status uses the EPP Domain Mapping «transfer» query command (while actually initiating a transfer is billable). Please note that this is different from the EPP «transfer» transform command.

2.8.4. Check Nameserver

Registrars use the Check Nameserver service to check to see if a nameserver object exists in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ for the nameserver requested. Check Nameserver uses the EPP Host Mapping «check» command.

2.8.5. Query Nameserver

Registrars use the Query Nameserver service to retrieve the host objectʹs information for a nameserver. Only the sponsoring Registrar of the nameserver can query for a nameserverʹs information. Query Nameserver uses the EPP Host Mapping «info» command.

2.8.6. Check Contact

Registrars use the Check Contact service to check to see if a contact object exists in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ for the contact requested. Checking contact existence is a non-billable operation. Check Contact uses the EPP Contact Mapping «check» command.

2.8.7. Query Contact

Registrars use the Query Contact service to retrieve the contact objectʹs information for a contact. Query Contact uses the EPP Contact Mapping «info» command.

2.8.8. Query Contact Transfer Status

Registrars use the Query Contact Transfer Status service to find out the status of a contact transfer. The query for contact transfer status information is a non-billable operation (while actually initiating a transfer is billable). Query Contact Transfer Status uses the EPP Contact Mapping «transfer» query command.

3. DISSEMINATION OF TLD ZONE FILES

All services enumerated in this section are non-billable.

3.1. Zone file generation and publication

Zone file generation constitutes the process of creation of a zone file using the SRS database as an authoritative source of information about registered domains and nameservers associated with them. The zone file is formed on the Primary Database server from the registry database records on schedule.

The zone file is transmitted onto both Hidden Primary DNS Servers through a special procedure which uses checksum verification. Should the checksums of the Primary Database and the Hidden Primary DNS match, the file handling continues, otherwise a zone file backup error message would be formed. Zone file is transmitted via RSYNC over SSH.

In the zone file updates all modifications, additions and deletions of objects made by Registrars in a given 30-minute period are recorded. Incomplete modifications are not recorded into the zone file during its generation, thus ensuring compliance with Specification 10 to Registry Agreement.

Serial numbers are assigned to every generated zone file using methods described in RFC 1982.

For the sake of an extra control during zone file generation special mechanisms are enabled. The number of delegated domains is calculated upon generation. Should the number of delegated domains be down by more than 10% vis-a-vis the value reported under the previous generation, a subsequent zone file processing is not performed and the error message to the operator is generated.

Where a suspicious decrease in number of records is not detected, both Hidden Primary DNS servers are pulled for the latest (=largest) Serial number from the SOA record. One (1) is added to this number and a new Serial number is entered into the formed zone file.

The state of the Hidden Primary DNS servers is monitored constantly to ensure the presence of pivotal sources, such as hard disc space, processor load rate, etc. Where resources have exhausted, a message is formed to notify the operator thereof. For example, where the available hard disc space is down to value under 4 GB an alerting message of approaching the minimum allowable threshold is formed, while where the available disk space is down to less than 2 GB, a message of disc space critical level is formed.

The zone file is generated in the RFC 1035 format in compliance with requirements set forth in Specification 4.

3.2. Zone file distribution

Zone distribution occurs immediately following zone publication on Hidden Primary DNS servers. Zone file being distributed to secondary DNS servers in a secure manner, using data encryption and secure channels. The zone is distributed onto secondary servers with the use of AXFR (RFC 5936) for entire zone file updates. IXFR (RFC 1995) incremental update method is supported and tested but will not be used due to the moderate zone files size for .TATAR TLD. The safeguard from modifications is ensured by using TSIG (RFC 2845). The keys for TSIG are subject to rollover every six months. The secondary servers are configured to accept updates only from Hidden Primary DNS servers.

For the time being the zone update is planned to be carried out by the generation and full zone file unload method. The dynamic updates use has been tested, and, where appropriate (for example, if during a new file generation time becomes unacceptably long), it is possible to switch over to them.

The roll-out of the zone file in DNS system will take 10 minutes or less than that.

Detailed architecture of the Hidden Primary and secondary DNS is described in the answer to the Evaluation Question #35.

3.3. Zone file access

Zone file access is provided according to the requirements listed in gTLD Registry Agreement, Specification 4 (sections 2.1 and 2.2). File format standard is a sub-format of the Master File format as described in section 2.1.4 of the Specification 4. Technical credentials will be implemented according to the requirements of the Specification 4.

3.4. Operations of the registry zone servers

Registry DNS servers, including Hidden Primary and secondary servers operate under FreeBSD with BIND including with the following settings appropriate for TLD zone operator: RECURSION is off, ADDITIONAL-FROM-CACHE off, NOTIFY is off for secondary DNS servers.

To ensure highly redundant DNS service the fifteen (15) geographically distributed DNS nodes with uniformed equipment and software configuration are installed, as described in the answer to Evaluation Question #35. Each DNS node carries two DNS servers (master and stand-by). In addition to BIND the NSD package is installed on stand-by DNS servers.

4. WHOIS SERVICE

TLD .TATAR will use “thick registry” model implying storage of all the information of registered in the registry database objects. The WHOIS service will contain data submitted by Registrars during the registration process. Any changes made to the data by a registrant will be submitted to the registry by the Registrar and will be reflected in the WHOIS, thus providing all interested parties with up-to-date information for every domain name. This WHOIS will be authoritative, consistent and accurate, people do not have to query different Registrars for WHOIS information, as there is one central WHOIS system.

WHOIS will be used to look up records in the registry database. Information about domain, host, contact and registrar objects can be searched using this WHOIS service.

The following WHOIS services are provided:

4.1. WHOIS service available via port 43 in compliance with RFC 3912. Access granted to all Internet users for free.

4.2. Web-based WHOIS service. Service is free and available for all Internet users.

4.3. The extended WHOIS search service is a search of objects by a fuzzy match of individual fields (e.g., domain name, registrant information, nameserver). Access to the service is granted to Registrars under RRA and to other authorized customers under service agreement. Service requires authorization.

4.4. Unlimited access to WHOIS service. Within the frame of RRA the Registrars are granted an unlimited access to WHOIS service via port 43 in order to check the availability of a name for registration. Access is controlled by IP access list, only Registrarʹs IP addresses allowed. Service will be provided for free.

To ensure a stable functioning of the system, technical measures are employed to limit the number of WHOIS queries from a given IP address over a time interval.

Information provided in the frame of the WHOIS service complies with Specification 4 To the Registry Agreement.

More information about WHOIS services is given in the answer to Evaluation Question #26.

5. DNS SECURITY EXTENSIONS

The .TATAR registry will support DNS Security Extensions (DNSSEC) to the extent provided for by RFC 4033-4035, 5155 (NSEC3).

The DNS servers of the registry will correctly handle queries for the sake of validation of accepted data on the queried zone.

The registry will deliver DS records for proper DNSSEC delegation in the root.

The Public key portions of DNSSEC will be announced to the public by Registry Operator, and, at a minimum, will be made available on its website. The DS records necessary for proper DNSSEC delegation will be delivered to the root.

End user applications that are DNSSEC-aware will ask queries of the DNS with a flag set for a signed response. The registry name servers will then respond with the correct response, including the signatures for the requested records. It is up to the end user to validate the signatures returned.

The sponsoring Registrar manages DS records for the domains as per RFC 5910.

The information on signed domains under the Registrar’s management is available to the Registrar among other reports (see the ‘Registrar services’ section).

More details about DNSSEC are in the answer to Evaluation Question # 43.

6. REGISTRAR SERVICES

The enumerated under this section services are delivered to Registrars.

6.1. Registrar accounts management

This service constitutes creation and modification of Registrar accounts. The service includes following operations:
- Creation of the account for the Registrar who has entered into RRA;
- Deletion of the account upon termination of RRA;
- Updating information about Registrars which is not modified other way;
- Updating the operational status of the Registrar’s accounts;
- Provision of a credit to the Registrar and entry of respective modifications into the Registrar’s balance.

6.2. Billing services

The billing subsystem handles all billing events from the registry that are created as part of normal registry operations. This mechanism also handles requests from the Web based Administration Interface. The billing mechanism interfaces with the Registry Operator’s financial system by way of a database interface.

The billing events require an immediate response enabling the registration process to take place. The billing implementation reflects a pre-paid billing model where a balance is debited for each billed event presented.

A negative response is returned by the billing subsystem if there are not sufficient funds available to complete the requested event. An EPP operation that receives a negative response from the billing subsystem will return an error response to the Registrar that initiated the operation.

Each billing system event has a dependency on the registry having done the following:
- Ensured that the Registrar is valid within the described Registrars;
- Ensured that the billing event is fully described with sufficient price information;
- Ensured that there is a balance for any Registrars who require processing for billable events.

The billing events must contain the ʺTransaction IDʺ as outlined in the EPP specification. This enables registry events to be traced in terms of their billing consequences.

The Registry Operator will implement an automatic Threshold Notification process for the Registrars to inform them about their low account balance. As soon as the Registrars balance falls below a pre determined threshold an out-of-band communication (e-mail) would be sent to the Registrars informing them. The Registrars are thus always aware of their low account balance and can make arrangements to transfer additional funds. This prevents the Registrars from losing business due to lack of funds.

The Registry Operator reserves the right to introduce additional fee-based services for Registrars and other users, which are rendered on the basis of an agreement concluded with them. In this regard, if there is a need for the Registry Operator to change the architecture or operation of an existing TLD registry service or introduce a new TLD registry service, there will be notification to ICANN and necessary negotiations in place in accordance with the ICANNʹs Registry Services Evaluation Policy.

6.3. Web-based Administration Interface for Registrar

Each Registrar will be provided with a username⁄password to access a secured website (HTTPS) where it can perform certain functions:
- Change of the password to access the Web-interface;
- Review of information on details of the access to the registry services;
- Receipt of SSL-certificates used to check the access to SRS system;
- Review of reports over a given period, including financial ones;
- Check the account balance;
- Review of the list of domain names registered as of the beginning of the current day;
- The interface will be bi-lingual (Russian and English).

6.4. Operation Test and Evaluation Certification Services

Before a Registrar is allowed to join the live Shared Registry System it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify the correct operation of a Registrarʹs client system.

6.4.1. Preparations for OT&E Certification

The OT&E certification process begins when a Registrar becomes accredited by ICANN to register names in the .TATAR TLD, at which point an OT&E welcome package will be provided to the Registrar. This package will include information that will assist the Registrar in developing its client application for the Shared Registry System. This package will include the following:
- Username and password to access the Registrar only area of the Registry Operator website.
-OT&E server information and username⁄password for two accounts to access OT&E environment for Registrar client testing. Two accounts due to necessity to test domain transfer functions.
- Instructions on where to download the Registrar Tool Kit.
- Instructions on where to download the documentation for the Registrar Tool Kit.
- Instructions on where to download the EPP specifications.
- Instructions on how to proceed with the OT&E certification process.
- Instructions on how to obtain an SSL certificate from an approved Certificate Authority.
- Instructions on how to provide Registry Operator with the list of subnets that will be used to access the live Shared Registry System.
- Documentation that will explain the tests to be performed during OT&E verification.

The Registrar is responsible for developing the client application that will interface to the registry using the EPP protocol, however the Registry Operator will offer assistance in application development for additional fee. The Registrar Tool Kit will be available to any interested party that would like to develop registrar client applications. A Registrar may opt to develop its application to conform to the EPP specification without the use of the Registrar Tool Kit. This is acceptable as long as the client is able to pass the OT&E certification process.

The registry-registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish this encrypted channel. The username⁄password and subnet list provides additional security as only a valid combination of SSL certificate; username⁄password and subnet will be allowed to access the live SRS.

During development of the client-side, the Registrar has access to .TATAR registry OT&E environment. In the OT&E environment, the Registrar may test the operation of its software to verify the correct handling of EPP commands and their responses. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live SRS. Registrars will continue to have access to the OT&E environment after certification, so that they may continue to test their software systems.

When a Registrar has completed the testing of its client systems and would like to proceed with OT&E certification, it will contact Registry Operator to schedule a time slot for certification tests.

6.4.2. Post OT&E Certification

All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certification results in a timely manner and provide feedback for those Registrars that failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E certification.

Upon successful OT&E certification, the Registrar becomes eligible for operation in the live SRS. A new username⁄password is assigned and the Registry Operator will configure the live system to recognize the SSL certificate, username and subnet blocks for the registrar. The Registrar may start operation when it has satisfied the financial requirements for going live.

The responsibilities of OT&E team include granting of welcome package, responding to Registrars’ questions, verification of test results and providing with report on test conduct. The procedure for issuing welcome package and for results estimation shall be automatized, while responding to questions shall be obligatory for Customer and Technical Support Services Group (see 7.6, ‘Customer and Technical Support Services’). In this way OT&E should not require additional staff units.

6.5. The Registrar Tool Kit

The Registrar Tool Kit (RTK) is a software development kit that will support the development of a registrar software system to perform registration of domain names in the registry using the EPP Protocol. The RTK will consist of software and documentation as described below.

The RTK can be used by the Registrar as a basis for connecting to the testbed environment during OT&E, and can also be used to develop a system for interfacing with the live registry once the Registrar has been certified.

The software will consist of a working Java API and samples that can be used to implement the EPP protocol that is used to communicate between the registry and Registrar.

The documentation will explain to the Registrar the details of the protocol specification. It will describe the commands that need to be sent to the registry in order to support domain registration events, as well as the possible responses that may be returned by the registry. The precise nature of the sequencing of commands, as well as the payload that must be assembled and transmitted to the registry, will be defined for each possible registration event.

The documentation will also describe the software (mentioned above) that implements the EPP Registry-Registrar protocol. This will consist of a description of the software package hierarchy, and an explanation of the defined objects and methods (including calling parameter lists, and expected response behavior).

The RTK will remain under development for the term of the Registry Agreement and will provide support for additional features as they become available.

6.6. Customer and Technical Support Services

The Registry Operator will provide complete package of Customer and Technical Support Services for general inquiries and billing related issues as well as operational and technical issues. These services will be dedicated primarily to operational Registrars, although inquiries from potential Registrars, or those in evaluation stages will be supported. Registrars will receive equal levels of support regardless of their location of operations. There will be a sufficient conduit for support escalation to a higher level when necessary. For the unlikely case of service failure, the responsibility matrix and escalation procedures are in place and procedures will be supported by Trouble Ticket Management System, able to act within complete off-line environment as described in the answer to Evaluation Question #39.

6.7. Report Generation

Registry Reports for each Registrar will be generated on a daily and weekly basis. These reports will contain domains, nameservers and contacts for which the Registrar is the sponsoring Registrar. The reports are generated as static colon-delimited files and available for download from the registrar Web administration Interface secure website.

6.7.1. Report Types

Two types of reports will be created for each Registrar: Daily Reports and Weekly Reports. These are described below.

6.7.1.1. Daily Reports

(i) Daily Transaction Report: This report includes Addition, Modification, Delete and domain Transfer activity by the Registrar. Domain operations produce one row for each associated nameserver. Nameserver operations produce one row for each associated IP address. A transaction ID is included in column 1 to allow unique identification of transactions. Column 2 contains the transaction operation. The content of column 3 and 4 is dependent on the operation according to the following rules:
Operation || Column 3 || Column 4
==================================================================
ADD_DOMAIN || Domain Name || Server Name
MOD_DOMAIN || Domain Name || Server Name
DEL_DOMAIN || Domain Name || Server Name
ADD_NAMESERVER || IP Address || Server Name
MOD_NAMESERVER || IP Address || Server Name
DEL_NAMESERVER || IP Address || Server Name
TRANSFER_DOMAIN || Domain Name || Null
==================================================================
Column 5 contains the transaction date (as illustrated in the example below).

For example,
1234567:ADD_DOMAIN:EXAMPLE1.TATAR:NS1.EXAMPLE1.TATAR:2001.07.01.11.12.54
1234568:ADD_DOMAIN:EXAMPLE1.TATAR:NS2.EXAMPLE1.TATAR:2001.07.01.11.12.54
1235789:ADD_DOMAIN:EXAMPLE2.TATAR:NS1.EXAMPLE1.TATAR:2001.07.01.11.13.30
1235790:ADD_DOMAIN:EXAMPLE2.TATAR:NS2.EXAMPLE1.TATAR:2001.07.01.11.13.30
1245734:ADD_NAMESERVER:111.222.123.211:NS1.EXAMPLE1.TATAR:2001.07.01.11.13.50
1245735:ADD_NAMESERVER:111.222.123.212:NS1.EXAMPLE1.TATAR:2001.07.01.11.13.50
2341413:TRANSFER_DOMAIN:TEST.TATAR::2001.07.01.11.14.31

(ii) Daily Transfer Reports: This report includes gaining and losing transfer activity. There are two separate reports for transfers:
- Gaining Transfer Report: indicates domains transferred to the Registrar (ʺGaining Registrarʺ).
- Losing Transfer Report: indicates domains transferred away from the Registrar (ʺLosing Registrarʺ).
- The Transfer Reports will have the following fields: Gaining Registrar name, Domain name, Losing Registrar name, Date⁄time of transfer request, Status (one of ACK, NACK or PENDING), Date⁄time of ACK⁄NACK. The value of Date⁄time of ACK⁄NACK will be NULL if the status is PENDING. For example:
Registrar A, Inc.:EXAMPLE1.TATAR:Registrar B Inc.:2001.07.01.15.13.41:PENDING:
Registrar A, Inc.:TEST.TATAR:Registrar B Inc.:2001.07.01.15.14.00:ACK:2001.07.03.04.23.12
Registrar A, Inc.:TEST2.TATAR:Registrar B Inc.:2001.07.01.15.25.00:NACK:2001.07.03.05.50.39

6.7.1.2. Weekly Reports

Weekly Domain Report: Lists all domain names currently sponsored by the Registrar. The domain is listed once with each current status and associated name server. For example:
EXAMPLE1.TATAR:ACTIVE:NS1.EXAMPLE1.TATAR
EXAMPLE1.TATAR:ACTIVE:NS2.EXAMPLE1.TATAR
EXAMPLE2.TATAR:ACTIVE:NS1.EXAMPLE1.TATAR
EXAMPLE2.TATAR:ACTIVE:NS2.EXAMPLE1.TATAR
TEST.TATAR:HOLD:NS1.TEST.TATAR
TEST.TATAR:HOLD:NS2.TEST.TATAR
HAPPY.TATAR:ACTIVE:

Weekly Nameserver Report: Lists all nameservers currently sponsored by the Registrar. The nameserver is listed once with each associated IP address. For example:
NS1.EXAMPLE1.TATAR:111.222.123.211
NS1.EXAMPLE1.TATAR:111.222.123.212
NS1.TEST.TATAR:123.14.2.4

Signed Domain names that enumerates which domain names are signed, along with their expiration time stamp.
DOMAIN1.TATAR: 2013.07.03.04.23.12
DOMAIN2.TATAR: 2013.05.04.05.27.43

Domains Hosted by Nameserver Weekly Report: Lists all domains hosted on nameservers currently sponsored by the Registrar. The nameserver is listed once with each associated domain name.
NS1.EXAMPLE1.TATAR:EXAMPLE1.TATAR
NS1.EXAMPLE1.TATAR:EXAMPLE2.TATAR
NS2.EXAMPLE1.TATAR:EXAMPLE1.TATAR
NS2.EXAMPLE1.TATAR:EXAMPLE2.TATAR
NS1.TEST.TATAR:TEST.TATAR
NS2.TEST.TATAR:TEST.TATAR

6.7.2. Report Frequency

Daily reports will be generated every day at 00:00 UTC and contain Registrar activity for the previous day.

Weekly reports will be generated on Sunday at 00:00 UTC and contain Registrar activity for the previous week.

6.7.3. Storage

Daily reports are maintained for each Registrar for seven days. Daily reports older than seven days will be removed.

Weekly reports are maintained for each Registrar for four weeks. Weekly reports older than four weeks will be removed.

6.7.4. Report Distribution

Registrar reports shall be available for download via a Reports section in the registrar Web administrative interface. Each Registrar will have secure, password-protected access to the Registrar administrative interface. A given Registrar will only have access to his own reports.

6.8. Registrar-Registry Synchronization

There are two methods available for the Registrar to synchronize data with the authoritative-source registry.

6.8.1. Bulk Synchronization

A Registrar may request a data file containing all domains registered by that Registrar, within a certain time interval. The data file will be generated and made available for download using a secure Web server. The data file will be a comma delimited file that contains all domains the Registrar has registered in the time period requested - including all associated host (nameserver) and contact information.

6.8.2. Single object synchronization via EPP

A Registrar can, at any time, use the EPP «info» command to obtain definitive data from the registry, for a known object: including domains, hosts (nameservers) and contacts. There is no need to contact registry support for this synchronization method.

6.8.3 Registry Notifications

In case of any changes in object state is provided by the Registry Operator, the notification describing changes is sent to the Registrar sponsoring changed object. The notification can be retrieved using EPP «poll» command.

6.9. Bulk Transfers

According to Inter-Registrar Transfer Policy ICANN may request Registry Operator to perform a bulk transfer of all registered objects from one Registrar to another Registrar. The bulk transfer will not be performed with the use of EPP commands. Instead it will be performed as a bulk database operation of the necessary fields for all objects currently sponsored by the losing Registrar. A complete log will be kept of this transaction for auditing purposes.

6.10. NTP service

The registry grants Registrars with access to clock synchronisation service used in operation of the registry. Thereat each Registrar specifies a list of IP addresses whence the access will be performed. The following NTP servers are used as a trusted clock source: ntp.ix.ru and ntp-spb.tcinet.ru.

7. END-USER SERVICES

The Registry Operator will operate a Name Watch Service available for legitimate subscribers thereto. The service will provide an indispensable tool to receive update notifications of new registrations containing a certain combination of characters which may raise the subscriber’s concern. The service is for information purposes only.

1. INTRODUCTION

Shared Registration System (SRS) allows many registrars to partake in registration of domain names. SRS for Registry operator will be in full compliance with prescribed standards.
The Registry Operator will outsource SRS functions to an external subcontractor, namely, JSC Technical Center Internet (hereinafter - Registry Service Provider or RSP). The Registry Service Provider’s duties will comprise installation, maintenance and troubleshooting of the SRS described below.

About the Technical Center of Internet (TCI)

The Technical Center of Internet, JSC (incorporated in Russian Federation, Primary State Registration Number (OGRN): 1097746536117, Taxpayer Identification Number (INN): 7702714697) is one of the largest worldwide technical centers and the only Russian one to service registry operators. A successor to Russian Institute for Public Networks, the Technical Center of Internet has a 20 year-long record of, and is already two years into, operation in its current status. TCI provides Full Registry Solution and DNS service with DNSSEC support to 2 ccTLD registry operators, supporting a total of 4.5m plus second-level domains in ccTLDs .SU, .RU (5th worldwide) and .РФ (1st worldwide IDN ccTLD). TCI serves 26 registrars, including several ICANN-accredited ones. TCI has a number of scattered worldwide DNS nodes, the geographically distributed fully redundant state-of the-art infrastructure and highly qualified staff.

2. GENERAL DESCRIPTION

RSP will implement SRS on the basis of proven technologies and technical solutions currently used for servicing TLDs .SU, .RU and .РФ. The technologies and technical solutions were designed to fully comply with requirements to gTLD RSP.

To provide the required SRS services to registrars the following elements of the RSP infrastructure will be used:
- communication channels, bandwidth providers and IP numbering schemes;
- networking equipment;
- hosting facilities;
- EPP, Web and database applications;
- server equipment;
- security and unauthorized access protection systems;
- SRS data storage;
- monitoring and troubleshooting services.

The 2 co-active SRS nodes are installed at 2 independent, geographically dispersed facilities. Each node includes 1 database server and 3 application servers. All internal service communications within SRS nodes used for data replication and transmission of service commands are completely secured thanks to private networking channels. Access for accredited Registrars is granted using IPv4 and IPv6. Both SRS nodes are located within hosting facilities with a guaranteed uninterrupted power supply, enhanced security and network connectivity with multiple destinations. SRS database servers run on the Sun ⁄ Oracle platform. At all times, one of the database servers is primary and the other one is stand-by. Data from the primary database are transmitted live to the stand-by database using the Oracle ʺdata guardʺ solution. Coupled with the fast database swap procedure, this technology guarantees an absence of data loss and a minimum database idle time to meet service level and operation continuity requirements. All six Application servers keep permanent connection with the primary database server. The database swapping is run in a semi-automated mode under Database Administrator’s supervision. Two co-active SRS nodes are connected by gigabit Ethernet (GE) channels. The channels take alternative routes which do not intersect in any given point. The connections between the nodes are protected.

The applicant’s technical architecture option is in compliance with geographical diversity and operational continuity parameters as described in the answers to Evaluation Questions #34 and #39.

To ensure a maximum protection of the Registry Operator’s data, an additional storage for the Registry Operator’s data will be arranged in the form of file server and RAID storage located at the facility in Frankfurt, Germany. The construction and tests completion of the German facilities is scheduled for September 2012. The procedure of back-up copying of the registry database will run regularly via the encrypted VPN over the public Internet interface with the 1 Gb transfer rate. The model was tested and produced great results. While running back-up copying, a full copy of the database and the set of registry database transaction files allowing restoration of an actual state of the registry database are saved. For the Oracle database back-up copies of the database transaction files in use bear the name of archive of redo logs. The off-shore deposit of the Oracle redo files allows fast recovery of SRS database data at any point in time up to one month backwards. For more details refer to the answer to Evaluation Question #37.

In addition, at the level of the mutual filesystem data exchange for RAID storages mirroring of some storage partitions of critical SRS data between nodes was arranged. That is to say, a section of the RAID storage containing critical data from one SRS node is mirrored onto a respective section of the RAID storage of another SRS node and vice versa. This provides critical data synchronization between SRS nodes at the filesystem level.

The employment of several alternative routes and protocols for data replication substantially reduces probability of data loss in the event of an unlikely emergency.

So, the two alternative schemes allowing protection of the registry database are deployed:
- databases replication at the level of database servers;
- replication of the RAID storage database, with all the Registry Operator’s data stored on its drives.
That is why SRS nodes are tagged ʺco-activeʺ.

The use of 6 Application servers (3 per each operational facility) is also dictated by the need to conform to requirements to geographical diversity and operational continuity. Access to Application servers and control of their accessibility are exercised using load balancing (SLB). An Application server can be put off- or online at all times.

The SRS architecture is shown in Figure Q24_SRSNodes.

3. PERFORMANCE METRICS

The SRS system has the service level SLR (monthly) parameters in compliance with requirements of SLA Matrix per Specification 10 to Registry Agreement:
- EPP service availability for registrars - 99,95%;
- EPP session-command RTT for at least 90% of the commands - 1000 ms;
- EPP query-command RTT for at least 90% of the commands - 300 ms;
- EPP transform-command RTT for at least 90% of the commands - 500 ms;
- Web applications availability - 99,95%.

The above SRS is capable to support up to 1000⁄sec EPP requests and maintain 20,000 concurrent EPP sessions.

4. HARDWARE AND SOFTWARE SPECIFICATION

4.1. Database servers

The Oracle database solution with the Sun server platform is used for database functions of SRS. The following hardware and software configuration is in use:

Moscow node
- SUN SPARC Enterprise M5000
- 2.66 GHz SPARC64 VII Quad-Core Processors
- DDRII 16*2GB DIMMs
- HDD 2*146GB SAS HD
- 2xGb Ethernet
- 2 PSU N+N redundancy
- FC Sun StorageTek PCI-E 40Gb
- Sun Solaris 5.10
- Oracle11g Enterprise Edition

St.Petersburg node
- Sun SPARC Enterprise M4000 Server,
- 2.4 GHz SPARC64 VII Quad-Core Processors
- DDRII 8 x 2 GB DIMMs
- 2 x 146 GB SAS HD
- 2xGb Ethernet
- 2 PSU N+N redundancy
- FC Sun StorageTek PCI-E 40Gb
- Sun Solaris 5.10
- Oracle11g Enterprise Edition

Database capabilities are described in detail in the answer to Evaluation Question #33.

4.2. SRS Data storage

Data storage system is one of the critical elements of the SRS nodes. RAID storages are in use as a data storage facility to conform to required disk space volumes, transactions speed and the need to prevent data loss in each location. This industry-standard storage is connected to the database and application servers. In Frankfurt, an EMC storage is used to store the backup data of the registry database and archive redo logs.

In addition to the RAID data storage scheme, the daily backup is performed in two SRS nodes to prevent data loss for an unlikely catastrophic event.

Moscow: EMC VNX 5100 (16x600GB FC, RAID 10)
St.Petersburg: EMC Clariion CX4-120 (15*300GB FC, RAID 10)
Frankfurt: EMC Clariion CX4-120 (11X1000GB SATAII, RAID 5)

To monitor critical functions the software is deployed to monitor general conditions of the storage volume such as the disks’ health, free space, memory and processor utilization.

This configuration of the storage elements provides a necessary operational capacity and prevents data losses.

4.3. Application servers

Registrars exercise EPP functions and Web https access to registration services using EPP and HTTPS protocols via front-end load- balancing Application servers. Their unified hard- and software configuration allows extending the number of servers without interrupting the service. EPP protocol, as described in the answer to Evaluation Question # 25, is in use in SRS to perform domain name registration functions for Registrars. Secured by HTTPS, Web access for Registrar gives access to statistics, billing information and accounts status. The Registry Operator publishes service information for Registrars at their service pages within the Registry Operatorʹs Web pages. The Application servers run on an Intel platform with the following hard- and software configuration:
- Intel 1U SR1625UR, 2CPU, 4GB RAM, 2HDx140GB RAID1
- Red Hat Enterprise Linux
- Oracle WebLogic 10.3 middleware

4.4. Version control

To keep up with the required service parameters all components of the SRS are updated from a single center. For database and application servers software version control there is a source code database run under Oracle with a set of instructions and scripts to install or roll-back software modules and manage source files according to ISO 27005 recommendations. Detailed procedures for version control are described in the answer to Evaluation Question # 39 ʺRegistry Continuityʺ.

5. NETWORK AND OTHER EQUIPMENT. IP-CONNECTIVITY

The following SRS network design proved ideal and is in use for many other critical Registry functions: there are pair of the network routers and switches connected to at least a pair of network connections with non-overlapping physical paths and different breeds of routing. The upstream providers for SRS supply DDoS free connections.

The following network equipment and load balancing system is in use:
- A pair of Cisco 7600 series routers is installed at each SRS node. These routers exercise routing, switching and perform load balancing ⁄ failure switching functions, and access policies, such as IP access lists, port filtering and other firewall functions.
- A pair of routers at SRS facility with the hot standby router protocol (HSRP) guarantee an automatic switchover if either router goes offline. There is the Cisco’s server load balancing (SLB) protocol to ensure the Application servers’ load balancing. If an Application server failed to execute 2 probe connections, SLB executes switch down the suspicious server and sends an alarm signal to the Monitoring Duty Operators. For traffic load balancing a simple round robin scheme is in use.

There are console routers at each SRS node connected to the network and server equipment via serial ports. This allows a remote command string execution for control purposes, such as service start and stop. Management of the applications and monitoring is run over secure VLAN connections.

A number of PDUs at SRS facilities allows remote power reset of the equipment. PDUs are connected via serial ports and can be managed over Ethernet too.

The network infrastructure for SRS node is also used by other critical registry elements, such as Hidden DNS server, DNSSEC sign server, WHOIS server, NTP server.

All servers and respective applications are connected over a number of VLANs according to the security policy, as described in the answer to Evaluation Question 30b.

Application servers are available for Registrars through both IPv4 and IPv6. The Anycast technology guarantees a secured and attack-resistant access.

The following Internet connectivity is in use for SRS Internet connectivity:
- 2 x Ethernet 100 Mbit⁄c Internet Exchange (SPB-IX) St.Petersburg
- 2 x Ethernet 1000 Mbit⁄c Internet Exchange (MSK-IX) Moscow
- Ethernet 1000 Mbit⁄c Internet (MAP) Moscow
- Ethernet 1000 Mbit⁄c Internet (RELARN) Moscow
- Ethernet 1000 Mbit⁄c Internet (RETN) St.Petersburg
- Ethernet 100 Mbit⁄c Internet (Relcom-SPB) St.Petersburg

Plus, there are 2 private Gigabit Ethernet connections run by separate fibers, with different operators and different paths for database live data replication.

6. RELATIONS TO OTHER SYSTEMS

SRS is a primary functional unit of the registry. It is an origin of data for the other elements of the registry database, such as zone file, WHOIS data, information for statistics and reports, billing data and internal service data. The SRS connections to other systems are shown in Figure Q24_SRSConnections.

The information from the database servers is transferred to Hidden Primary DNS servers and makes up a zone file for .TATAR TLD as described in the answer to Evaluation Question #35.

Information from SRS is a source of data used for RDDS ⁄ WHOIS as described in the answer to Evaluation Question #26.

The daily data exchange with the Data Escrow provider uses database information from SRS as described in the answer to Evaluation Question #38.

The Primary database server performs generation and delivery of the Oracle redo files to the remote location in Frankfurt, Germany.

The SRSʹs Primary database is a source of statistics and billing data for Registrars too.

7. DATA PROTECTION

An accredited Registrar is responsible for accuracy of transmitted to SRS data and their formats. But if the Registrar damaged the data by, the .TATAR Registry Operator will be at pains to recover those, as the architecture of the SRS system of .TATAR let data roll-back in accordance with parameters set for Registrar continuity in the answer to Evaluation Question #39.

8. SECURITY AND ACCESS CONTROL

To prevent an unauthorized access and data modification in SRS by service team several procedures are in place:
- Access rules control;
- Logging of executed commands in SRS applications;
- Regular audit of the staff operations and procedures;
- One-time access passwords for staff engaged in system management;
- Permanent anti-intrusion monitoring.

Upstream providers clean the incoming traffic from DDoS packets. The Cisco firewall solution, Cisco guard and Cisco detector protect SRS systems from external attacks.

The Security policy for SRS is described in the answer to Evaluation Question #30 (a). Security methods are described in the answer to Evaluation Question #30 (b).

9. SRS MONITORING AND MAINTENANCE

Monitoring of the SRS performance is run by the RSP’s Monitoring Department 24x7x365. Parameters of all the elements of SRS are displayed on the monitoring dashboard of the SRS elements. The monitoring reflects status of the elements’ load, the storage capacity, temperature, on- and off-line status, idle time. Active monitoring as a set of probes and executable procedures generates emergency reports if any critical elements of the SRS functions stop performing or functional parameters degrade. Trouble ticket management system and escalation matrix is in use in emergency, as described in the answer to Evaluation Question #42.

Once a month the RSP checks up the SRS system. Evaluation gives rise to SRS modification plans and upgrades of elements to meet required changes, such as network capacity, processor power, memory upgrades, etc. The Registrars’ input is considered very valuable for improving the system and enhance the quality of the service. SRS elements are also subject to failover testing as described in the answer to Evaluation Question #41.

10. SRS SCALABILITY

The planned capacity will be sufficient for the .TATAR Registry Operator in the long run, given that it has an agreement with Registry Service Provider that .TATAR will not use more than 10% of the total SRS capacity.

The SRS configuration can be easily upgraded without service interruption, as every service and network element is duplicated.

The SRS database is clustered, i.e. one element can be replaced with a cluster of many.

Hardware components are scaled by increasing the number of front- and backend servers. Servers can be added at any moment without interrupting service. CPUs and memory can be added to database servers with short service outage.

11. PERSONNEL

The following staff roles are engaged in development, initial implementation and maintenance for the SRS service:

11.1. Initial implementation and ongoing maintenance
Most of the architectural elements, such as networks and servers, are already in place, so minimum implementation is required.

- Applied Systems Administrator (Registry Services Department, RS Support Group): System administration of Application servers.
- Applied Systems Engineer (Registry Services Department, RS Support Group): Installation of server equipment and operating systems.
- Database Administrator (Registry Services Department, RS Support Group): Installation of SRS Database, system administration of database, applications performance tuning, system administration of database servers, supporting post implementation, database performance tuning
- Data Storage System Administrator (Registry Services Department, RS Support Group): Supporting pre- and post implementation RAID data storage.
- Network Engineer (Networking Department, IP-Network Group): Installation and maintenance of network equipment, IP numbering schemas design, installation and maintenance of communication channels, communication with colocation providers regarding IP-network issues.
- IT-Security Engineer (IT-Security Department): Development and review of Network security Plan.
- Project Manager (Quality Assurance Department): Provide direction to technology teams in defining and prioritizing features, enhancements, platform improvements and customer requests.

11.2. Development

- Application Developer (Registry Services dep., R&D Group): Design and implementation SRS system, design and implementation of solutions SRS security, supporting pre- and post implementation.
- Database Developer (Registry Services Department, R&D Group): Design and implementation of SRS database, supporting pre- and post implementation, design and implementation system monitoring, managing schema objects, such as tables, store procedures, functions, triggers, packages, views, building various queries.
- System Testing Engineer (Registry Services Department, Testing and Versioning Group): Testing and version control.

12. CONCLUSION

The co-active SRS architecture of the RSP satisfies the most rigorous requirements to construction of the critical infrastructure elements. Each element of SRS is duplicated, including servers, network equipment and channels. The critical data are copied on the database and file system levels onto RAID storages.

Backup location in Germany performs Primary database backup with a possibility for recovery of the registry database as of any moment in time in a span of 1 month backwards. Six Application servers maintain connection to the Primary Database providing Anycast access to the EPP, billing and statistics services. Their number can be increased without service stoppage.

The upgrade of the databasesʹ capacity can be performed without breaking the ultra-high continuity parameters. The service levels for SRS satisfy service levels set by ICANN.

1. INTRODUCTION

In compliance with ICANN requirements, while interacting with registrars SRS uses EPP protocol. The EPP protocol implementation used by SRS was developed in compliance with RFC 5730-5734.

SRS uses standardized EPP extensions: Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) implemented in compliance with RFC 3915 and Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) implemented in compliance with RFC 5910.

In addition to the standardized EPP protocol extensions, in gTLD .TATAR two proprietary EPP protocol extensions are used, which were implemented in compliance with RFC 3735. These extensions are designated to implement the following functionalities:
- «contact» object extension is designated for storing contact objectʹs additional attributes;
- «domain» object extension is designated for storing domain objectʹs additional attributes.

A more detailed description of the non-standard extensions is given below.

The Applicant will outsource EPP functionality as a part of Full Registry Solution to an external subcontractor, namely, JSC Technical Center Internet (hereinafter referred to as Registry Service Provider or RSP). The Registry Service Provider’s (RSP) duties will encompass initial EPP implementation and ongoing maintenance in accordance with Registry Operator’s requirements.

About the Technical Center of Internet (TCI)

The Technical Center of Internet, JSC (incorporated in Russian Federation, Primary State Registration Number (OGRN): 1097746536117, Taxpayer Identification Number (INN): 7702714697) is one of the largest worldwide and the only Russian technical centers to service registry operators. A legitimate successor to Russian Institute for Public Networks, the Technical Center of Internet has a 20 year-long background and is already two years in operation in its current status. TCI provides Full Registry Solution and DNS service with DNSSEC support to 2 ccTLD registry operators, supporting a total of 4.5m plus second level domains in ccTLDs .SU, .RU (5th worldwide) and .РФ (1st worldwide IDN ccTLD). TCI serves 26 registrars, among them several ICANN-accredited ones. TCI is in possession of a number of scattered worldwide DNS nodes, the geographically distributed fully redundant state-of the-art infrastructure and highly qualified staff.

2. IMPLEMENTATION

2.1. General Principles

The EPP server’s functionality is implemented on Java SE 5.0 (JSR 176) platform.

Registrars are recommended to use the EPP RTK library for Java (see http:⁄⁄epp-rtk.sourceforge.net) as a client along with the custom module developed by Registry Service Provider wherein API for the work with the contact and domain objects extensions is implemented (See below).

The detailed description of Registry Service Provider implementation is provided in the respective sections below.

2.2. Transport Mapping

The transport mapping is implemented in full compliance with RFC 5734.

2.2.1. Transport Mapping’s compliance with RFC 5730

1) The transport mapping MUST preserve command order.
- The commands order is preserved.
2) The transport mapping MUST address the relationship between sessions and the client-server connection concept.
- Each EPP session is mapped to a single TCP connection.
3) The transport mapping MUST preserve the stateful nature of the protocol.
- The original structure of the protocol is preserved.
4) The transport mapping MUST frame data units.
- The data block format explicitly defines the number of bytes used to transfer the EPP message.
5) Basing on a protocol, such as TCP, transport mapping should ensure congestion prevention.
- Load balancing is implemented according to the guidelines and practices described in RFC2581 and RFC2914.
6) The transport mapping MUST ensure reliability.
- TCP includes functions ensuring resiliency, flow control and multiplexing, as described in Section 1.5 RFC793.
7) The transport mapping MUST explicitly allow or prohibit pipelining.
- The pipelining is possible, but is explicitly PROHIBITED.
8) Commands must be processed independently of each other.
- Commands are processed independently of each other.
9) Depending on the transport, pipelining MAY be possible in the form of sending a complete session in a well-defined ʺbatchʺ.
- The pipelining in the form of sending a complete session in one ʺbatchʺ, IS NOT PERMITTED.
10) The transport mapping MUST describe how an error in processing a command affects continued operation of the session.
- The session can be interrupted because of an internal server error, authorization error, exhaustion of the open session limit or the session lifetime.

2.2.2. TCP-based transport mapping security

EPP as-is provides only simple client authentication services using identifiers and plain text passwords. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial command forgery. Protection against most other common attacks MUST be provided by other layered protocols.

When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0, as described in RFC2246 or its successors, using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication.

Authentication using the TLS Handshake Protocol confirms the identity of the client and server machines. EPP uses an additional client identifier and password to identify and authenticate the clientʹs user identity to the server, supplementing the machine authentication provided by TLS. The identity described in the client certificate and the identity described in the EPP client identifier can differ, as a server can assign multiple user identities for use from any particular client machine. Acceptable certificate identities MUST be negotiated between client operators and server operators using an out-of-band mechanism. Presented certificate identities MUST match negotiated identities before EPP service is granted.

There is a risk of login credential compromise if a client does not properly identify a server before attempting to establish an EPP session. Before sending login credentials to the server, a client needs to confirm that the server certificate received in the TLS handshake is an expected certificate for the server. A client also needs to confirm that the greeting received from the server contains expected identification information.

EPP TCP servers are vulnerable to common TCP denial-of-service attacks including TCP SYN flooding. Servers SHOULD take steps to minimize the impact of a denial-of-service attack using combinations of easily implemented solutions, such as deployment of firewall technology and border router filters to restrict inbound server access to known, trusted clients. These solutions are implemented and described in the respective sections of the Application.

For more detailed security considerations on TCP and TLS usage, see Sections 8 and 9 of RFC5734.

2.3. Protocol Identification

After establishing the TCP session, the EPP server MUST return a greeting to the client.

2.4. Greeting

Example EPP server greeting is provided in the attachment Q25_EPPServerGreetingExample.

Comments on the Registry data collection policy:
- Access is granted to all the identified data («all⁄»).
- Information is collected for the purpose of domain names registration («prov⁄») and may be used for administrative and technical support of the registration system («admin⁄»).
- Consumers of the information is provided are Registry Operators and Registrars («ours⁄»), as well as users of the WHOIS service («public⁄»).
- The data storage period is limited by the need to support the DNS system.

2.5. Protocol Extensions

2.5.1. Command-Response Extension

- Extension to operate the domain objectʹs DS records is implemented in compliance with RFC 5910.
- Extension to operate the domain objectʹs grace period is implemented in compliance with RFC 3915.
- Extension to operate an extended set of attributes of the domain object (see section 7.1 of the present document).
- Extension to operate an extended set of attributes of the contact object (see section 7.2 of the present document).

2.6. Objects Identification

All Registry Service Provider’s registry objects have continuous numbering.

2.7. Session Control Commands

2.7.1. EPP «login» Command

The EPP «login» command is implemented in compliance with RFC 5730.

In reply to a successful EPP «login» command EPP server will return an EPP response of a successful authentication.

The number of failed login attempts and the idle expiration time are parameterized and defined by the security policy.

Example «login» command is provided in the attachment Q25_ExampleLoginCommand.

2.7.2. EPP «logout» Command

The EPP «logout» command is implemented in compliance with RFC 5730.

Where the server receives an EPP «logout» command, the EPP server will close the EPP session and the associated with it TCP connection, in compliance with RFC 5734.

2.8. Query Commands

2.8.1. The «check» Command

The «check» command is implemented for the objects: Domain, Host and Contact, in compliance with RFC 5730-5733.

In order to save resources and boost the EPP server’s performance the number of objects subject to verification is parameterized and may be specified explicitly. By default, the number of objects subject to verification is not limited.

2.8.2. The «info» Command

The «info» command can be is implemented for the objects Domain, Host and Contact, in compliance with RFC 5730-5733.

2.8.3. The «poll» Command

The «poll» command is implemented in compliance with RFC 5730.

2.8.4. The «transfer» Query Command

The «transfer» command can be implemented for the objects Domain and Contact in compliance with RFC5730, RFC5733.

2.9. Object Transformation Commands

2.9.1. The «create» Command

The EPP «create» command is implemented for to the objects Domain, Host and Contact, in compliance with RFC5730-5733.

2.9.2. The «renew» Command

The «renew» command is implemented for the domain object, in compliance with RFC 5731.

2.9.3. The «transfer» Command

The «transfer» command is implemented for the objects Domain and Contact, in compliance with RFC 5730, RFC 5733.

2.9.4. The «update» Command

The «update» command is implemented for the objects: Domain, Host and Contact, in compliance with RFC 5730-5733.

2.10. Result Codes

The EPP commands result codes used in the Registry Service Provider’s EPP server implementation fully comply with RFC 5730.

2.11. Internationalization

- The Registry Service Providerʹs EPP server accepts EPP commands and delivers EPP responses ONLY using in the UTF-8 encoding.
- The descriptions of the EPP commands result codes specified in RFC 5730 have been translated. That is why the Registrars can receive them in both the Russian and English languages, at the Registrarʹs discretion.
- The error descriptions and causes for denial cited in EPP responses can be delivered in the Russian and English languages, at the Registrarʹs discretion.
- All date-time values presented through EPP are represented in UTC format with the use of the extended format in compliance with W3С Recommendation REC-xmlschema-2-20041028).

2.12. Security

To implement the interaction with EPP server through the TLS protocol (see more details in Section 2.2.2. of the present document), users must use only trusted certificates issued by Registry Service Provider. The peculiarities of generation and usage of trusted certificates are as follows:
- The trusted certificates are issued individually, for each Registrar and they are unique for the cluster of EPP servers of each registry.
- The trusted certificates are issued for a limited period, determined by the registry’s security policy and terms of the contract with the Registrar.
- The individual trusted certificates are available through the Registrarʹs Web-interface.

2.13. The distinction of the Registry Service Providerʹs implementation from the standard one.

The distinctive feature of the Registry Service Providerʹs implementation lies in employment of extensions for the objects: Domain and Contact (for greater details, see Section 7 of the present document).

3. EPP PROTOCOL IMPLEMENTATION’ S COMPLIANCE WITH RFC 5730-5734

The EPP protocol implementation is compliant with RFC 5730-5734: The extensions do not modify the existing protocol structure. The extensions are described by XML-schemas tci-contact-ext-1.0.xsd и tci-domain-ext-1.0.xsd. The extensions MAY NOT be modified, for greater details, see Section 7 of the present document).

4. PERSONNEL

The following staff roles are engaged in development, initial implementation and maintenance of the EPP service:

(i) Initial implementation and maintenance:
- Applied Systems engineer (Registry Services Department., RS Support Group), 1 person;
- Database Administrator (Registry Services Department, RS Support Group), 2 persons;
- Network Engineer of NOC (Networking Department, IP-Network for RS, DNS Group), 2 persons;
- Duty operators (Monitoring Department) 4 shifts of 2 officers each;
- Duty engineers of NOC (Networking Department, IP-Network for RS, DNS Group), 2 persons;
- RS Duty Engineer (Registry Services Department, RS Support Group), 2 persons.

(ii) Development:
- Application Developer (Registry Services Department, R&D group), 1 person;
- Database Developer (Registry Services Department, R&D Group), 1 person;
- System Testing engineer (Registry Services Department, Testing and Versioning Group), 1 person.

5. THE EPP PROTOCOL’S SCALE IN RELATION TO THE PLANNED SIZE OF THE REGISTRY

Theoretically, the number of EPP servers (Application servers) in the registry cluster is unlimited, which is why the cumulative performance (response time) of an EPP service depends only on performance (response time) of the registry’s database.

6. THE OUTLAY AND ITS CORRELATION WITH THE DESCRIPTION IN THE FINANCIAL SECTION

The costs are a combination of the hardware, software development and operational costs. No additional costs is related to the EPP environment.

7. PROPRIETARY EPP PROTOCOL EXTENSIONS

7.1. Extension for the EPP Domain Mapping

This mapping, an extension of the domain name mapping described in RFC 5731.

7.1.1. Objectʹs attributes

The extension adds new attributes to the domain object. This section describes each attribute in detail. For attributeʹs formal syntax, see Section 7.1.5, the Formal Syntax.

7.1.1.1. Additional information about the domain

The «description» attribute contains additional information about the domain name, e.g. a brief description of the resource properties, for example its content.

7.1.2. Description of EPP commands

Extensions to the EPP commands «create», «update» and the response to the EPP «info» command are provided for to operate an extended set of attributes to the domain object.

7.1.2.1. EPP «create» command

This extension determines additional elements for the command «create» described in RFC5731. Additional elements for the response to the command «create» are not determined.

The command «create» allows the customer to create a domain object. In addition to the elements of the command described in RFC5731, the command MUST contain the element «extension», which MUST comprise a child element «domain:create» which identifies the namespace and the location of the extensionʹs XML schema. The element «domain:create» contains the following child element:
- A single element «domain:description» containing an arbitrary comment.

7.1.2.2. EPP command «update»

This extension determines additional elements for the command «update» described in RFC5731. Additional elements for the response to the command «update» are not determined.

The EPP command «update» allows the customer to modify attributes to the contact object. In addition to the command elements described in RFC5731, the command MUST contain the element «extension», which MUST contain a child element «domain:update», which identifies the namespace and the location of the extensionʹs XML schema. The element «domain:update» contains the element «domain:chg», which contains the following child element:
- A single element «domain:description» containing an arbitrary comment.

7.1.2.3. EPP «info» Command

This extension does not add elements to the EPP «info» command described in RFC5731, but it does define additional elements for response.

Once the «info» command was successfully processed, the element «resData» MUST contain child elements described in RFC5731. Besides, the «extension» element MUST contain a child element «domain:infData» that identifies the namespace and the location of the extensionʹs XML schema. The «domain:infData» element contains the following child element:
- A single element «domain:description» containing an arbitrary comment.

7.1.3. Documentation

The documentation is written in RFC-like style, following the recommendations of RFC 3735, based on the template from RFC 5730 (Appendix A).

7.1.4. Formal Syntax

The extension formal syntax is described in the attachment Q25_XMLSchemaTCIDomain.

7.2. Extension for the EPP Contact Mapping

This mapping, an extension of the contact mapping described in RFC 5733.

7.2.1. Description of attributes

The extension adds new attributes to the contact object. In this section, each attribute is described in detail. For the attributes’ formal syntax see Section 7.2.5, ʺFormal Syntaxʺ.

7.2.1.1. Interface ʺPersonʺ

Interface ʺPersonʺ should be used where the registrant is a private individual. The «contact:person» element is employed for description.

(i) Individual Tax Identification Number
The attribute that contains the registrant’s individual taxpayer identification number has a string data type and has a fixed maximum length.

(ii) Date of birth
The attribute contains the registrant’s date of birth and is of the ʺdateʺ type.

(iii) Passport data
The attribute contains the registrant’s passport details and is of string type.

(iv) Information Disclosure Policy
The Registry defines the default disclosure policy. However, by using the «contact:disclose» element, the Registrar can determine those attributes of the contact which can be disclosed or hidden as an exception from the disclosure policy.

If the «contact:disclose» element has been determined, it MUST contain the attribute ʺflagʺ which takes a Boolean value. The value ʺtrueʺ or ʺ1ʺ means that the client authorizes disclosure of the said elements as an exception from the established policy, while the value ʺfalseʺ or ʺ0ʺ (decimal zero) means that disclosure is not permitted.

The «contact:disclose» element contains the following child elements:
- «contact:TIN⁄»;
- «contact:birthday»;
- «contact:passport».

7.2.1.2. Interface ʺOrganizationʺ

Interface ʺOrganizationʺ is used if the registrant is a corporation. Element «contact:org» is employed for description.

(i) Legal address

- The street, city, region
The description of the street, city and region is a string-type one and has a certain minimum and maximum length.

- Postal code
Postal code is a string-type presentation and has a certain minimum and maximum length.

- Country
The ISO3166-1 two-character code is used to identify the country.

(ii) Individual Taxpayer Identification Number

Attribute that contains the registrant’s individual taxpayer identification number is a string-type presentation and has a certain maximum length.

(iii) Disclosure Policy

The registry defines the disclosure policy by default. However, using the «contact:disclose» element, the Registrar can determine the attributes of the contact which may be disclosed or hidden as an exception from the disclosure policy.

If the «contact:disclose» element is determined, it MUST contain the attribute ʺflagʺ which takes a Boolean value. The ʺtrueʺ or ʺ1ʺ value means that the client authorizes disclosure of these elements as an exception from the established policy, while the value ʺfalseʺ or ʺ0ʺ (decimal zero) means that disclosure is not allowed.

Element «contact:disclose» contains the following child elements:
- «contact:legalAddr type=”int”»
- «contact:legalAddr type=”loc”»
- «contact:TIN⁄»

7.2.2. Description of EPP commands

7.2.2.1. EPP command «create»

This extension defines additional elements to the EPP command «create», as described in RFC5733. Additional elements to the respond to command «create» are not defined.

The EPP command «create» allows the client to create a contact object. In addition to the command elements described in RFC5731, the command MUST contain the element «extension», which MUST contain a child element «contact:create», which identifies the namespace and the location of the extensionʹs XML schema. Element «contact:create» contains child elements «contact:org» or «contact:person», depending on a type of the contact.

Element «contact:org» contains the following child elements:

(i) One or two «contact:legalAddr» elements containing the legal address. The reason for using two elements is that the postal address information can be presented in two forms, namely, the international and local ones; attribute ʺtypeʺ identifies one of the either formats. If the information is presented in the international format (type=ʺintʺ), then contents of the element HAS to be presented in the US-ASCII encoding. If the information is presented in the local format (type=ʺlocʺ), then contents of the element can be presented in the UTF-8 encoding. Element «contact:legalAddr» contains the following child elements:
- Element «contact:name» contains a particular name or the name of the registrant’s role.
- OPTIONAL element «contact:org» contains the name of the entity that the Registrar is affiliated with.
- Element «contact:addr» describes the Registrant’s address . Element «contact:addr» contains the following child elements:
a) One, two or three OPTIONAL «contact:street» elements containing the address of the Registrar.
b) Element «contact:city» contains the name of the city.
c) OPTIONAL element «contact:sp» contains the name of the region or area.
d) OPTIONAL element «contact:pc» contains the postal code.
e) Element «contact:cc» contains the code of the country of residence.
f) Element «contact:city» contains the name of the city.
g) OPTIONAL element «contact:sp» contains the name of the region or area.
h) OPTIONAL element «contact:pc» contains the postal code.
i) Element «contact:cc» contains the code of the country of residence.

(ii) Element «contact:TIN» contains the registrant’s TIN (Taxpayer Identification Number).

(iii) Element «contact:disclose» stands for the disclosure policy (par. 6.2.1.1.(iv))

Element «contact:person» contains the following child elements:
(i) Element «contact:TIN» the registrant’s TIN.
(ii) Element «contact:birthday» - registrantʹs date of birth.
(iii) Element «contact:passport» the registrant’s passport data.
(iv) Element «contact:disclose» stands for disclosure policy (par. 6.2.1.2.(iii)).

7.2.2.2. EPP command «update»

This extension defines additional elements to the command «update», as described in RFC5733. Additional elements to the respond to command «update» are not defined.

The EPP command «update» allows the customer to modify attributes to the contact object. In addition to the command elements described in RFC5731, the command MUST contain element «extension», which MUST contain a child element «contact:update» which identifies the namespace and the location of the extensionʹs XML schema. Element «contact:update» contains child element «contact:chg», which contains child elements «org» or «person», depending on the type of contact.

Element «contact:org» contains the following child elements:

- One or two OPTIONAL «contact:legalAddr» (described above).
- OPTIONAL element «contact:TIN» contains the registrant’s TIN (Taxpayer Identification Number).
- OPTIONAL element «contact:disclose» stands for the disclosure policy (par. 7.2.1.1.(iv)).

Element «contact:person» contains the following child elements:

- OPTIONAL element «contact:TIN» the registrant’s TIN.
- OPTIONAL element «contact:birthday» - registrant ʹs date of birth.
- OPTIONAL element «contact:passport» the registrant’s passport data.
- OPTIONAL element «contact:disclose» stands for disclosure policy (par. 7.2.1.2.(iii)).

7.2.2.3. EPP Command «info»

This extension does not add elements to the EPP «info» command, as described in RFC5731. But it does define additional elements to the response.

Upon successful processing of the EPP «info» command, element «resData» MUST contain child elements, as described in RFC5733. Additionally, element «extension» MUST contain a child element «contact:infData» that identifies the namespace and the location (location) of the extensionʹs XML schema. Element «contact:infData» contains child elements «org» or «person», depending on the type of contact.

Element «contact:org» contains the following child elements:
- One or two «contact:legalAddr» (described above)
- Element «contact:TIN» contains the registrant’s TIN (Taxpayer Identification Number).
- Element «contact:disclose» stands for the disclosure policy (par. 7.2.1.1.(iv))

Element «contact:person» contains the following child elements:
- Element «contact:TIN» the registrant’s TIN.
- Element «contact:birthday» -the registrantʹs date of birth.
- Element «contact:passport» the registrant’s passport data.
- Element «contact:disclose» stands for disclosure policy (par. 7.2.1.2.(iii)).

7.2.3. Documentation

The documentation has been drafted in the RFC-like style per the recommendations of RFC 3735 and basing on a template from RFC 5730 (Appendix A).

7.2.4. Formal Syntax

The extension formal syntax is described in the attachment Q25_XMLSchemaTCIContact.

1. INTRODUCTION

The Registry Operator will outsource WHOIS service as a part of Full Registry Solution to an external subcontractor, namely, JSC Technical Center Internet (hereinafter referred to as Registry Service Provider or RSP).

About the Technical Center of Internet (TCI)

The Technical Center of Internet, JSC (incorporated in Russian Federation, Primary State Registration Number (OGRN): 1097746536117, Taxpayer Identification Number (INN): 7702714697) is one of the largest worldwide and the only Russian technical centers to service registry operators. A legitimate successor to Russian Institute for Public Networks, the Technical Center of Internet has a 20 year-long background and is already two years in operation in its current status. TCI provides Full Registry Solution and DNS service with DNSSEC support to 2 ccTLD registry operators, supporting a total of 4.5m plus second level domains in ccTLDs .SU, .RU (5th worlwide) and .РФ (1st worldwide IDN ccTLD). TCI serves 26 registrars, among them several ICANN-accredited ones. TCI is in possession of a number of scattered worldwide DNS nodes, the geographically distributed fully redundant state-of the-art infrastructure and highly qualified staff.

The WHOIS service provides a free public access to information about domain names, registrars, nameservers of the TLD concerned. It handles the query in accordance with RFC 3912 via port 43; besides, there is a Web-form to place a WHOIS query and display results on the Web site.

Being a publicly accessible resource, WHOIS service has to meet the most rigorous standards with respect to reliability, accessibility and capacity.

The Registry Service Provider uses combination of architecture, hardware and software to meet requirements set out in Specifications No 4 and 10 to the Registry Agreement (hereinafter Specification 4 and Specification 10 correspondingly). The Registry Service Provider maintains the centralized WHOIS database. Modifications introduced by registrars into the registry are promptly (in no more than 10 minutes) displayed in the WHOIS database.

The Web-based format is intended for a user’s placement of a query to the WHOIS service. The query is checked for consistency with Registryʹs appropriate data format and channeled to the WHOIS service via port 43. The final response is displayed for the user on the Web site.

2. COMPLIANCE WITH RFC 3912

The WHOIS service handles the query in compliance with RFC 3912:
- WHOIS server listens on TCP port 43 for requests;
- The user accesses the server using TCP protocol (port 43);
- The user submits the query – the line of text;
- The query ends - with CR+LF symbols.

The program module forms and sends the response to the user and then closes the TCP connection.

3. WHOIS QUERY

The user enters letters or other symbols representing the domain name, the registrar name, the nameserver or an IP address. Once entered, the query is checked for the type of object matching the name entered. It is possible to place queries with regard to data of the following three types of objects: domain object, registrar object and nameserver object. Domains and registrars may be queried by the domain name and the registrar name, respectively. Nameservers may be queried by nameserver name or by one of nameserver IP addresses.

For accurate indication of the type of an object, the following keys can be used:
- ‘registrar’ indicates that the search by registrar is needed;
- ‘nameserver’ indicates that the search by the NS server’s name or IP address is needed.

Queries without a key suggest search by domain name or registrar’s name.

The search is performed by exact match and case insensitive.

4. WHOIS RESPONSE

According to requirements of the Specification 4, the response is given in text format followed by a blank line and a legal disclaimer specifying rights of the Registry Operator and the user who is submitting the query.

The provisional content of the legal disclaimer:
The WHOIS service is granted for information purposes and may be used only to obtain information regarding domain names and contact persons. By applying to the WHOIS service User agrees that he⁄she:
- will use the Data obtained only for lawful purposes
- under no circumstances will use the Data to support transmission by e-mail, facsimile or telephone of any unsolicited information
- will not enable high volume queries exceeding established limits.
It is forbidden:
- to make any changes in the Data obtained from the WHOIS service in the case of its further distribution for information purposes;
- to generate a further distribution of the Data obtained for commercial purposes.

Each data object is represented as a combination of a key and value in the following format:
- key;
- colon space delimiter;
- value.

For fields comprising several values (for example, the list of nameservers, telephone numbers), multiple key⁄value pairs with the same key are used.

The first key⁄value pair following the blank line is considered to be the start of a new entry and an identifier of the said entry.

The following fields are provided for domains:
- Domain Name;
- Domain ID;
- WHOIS Server;
- Referral URL;
- Updated Date;
- Creation Date;
- Expiry Date;
- Sponsoring Registrar;
- Sponsoring Registrar IANA ID;
- Domain Status;
- Registrant ID, Registrant Name, Registrant Organization, Registrant Street, Registrant City, Registrant State⁄Province, Registrant Postal Code, Registrant Country, Registrant Phone, Registrant Phone Ext, Registrant Fax, Registrant Fax Ext, Registrant Email;
- Admin ID, Admin Name, Admin Organization, Admin Street, Admin City, Admin State⁄Province, Admin Postal Code, Admin Country, Admin Phone, Admin Phone Ext, Admin Fax, Admin Fax Ext, Admin Email;
- Tech ID, Tech Name, Tech Organization, Tech Street, Tech City, Tech State⁄Province, Tech Postal Code, Tech Country, Tech Phone, Tech Phone Ext, Tech Fax, Tech Fax Ext, Tech Email;
- Nameserver;
- DNSSEC.

For registrars, the following fields are provided:
- Registrar Name;
- Street;
- City;
- State⁄Province;
- Postal Code;
- Country;
- Phone Number;
- Fax Number;
- Email;
- WHOIS Server;
- Referral URL;
- Admin Contact, Phone Number, Fax Number, Email;
- Technical Contact, Phone Number, Fax Number, Email.

For NS servers:
- Server Name;
- IP Address;
- Registrar;
- WHOIS Server;
- Referral URL.

The format of the following fields complies with the RFC for Extensible Provisioning Protocol (EPP, RFC 5730-5734) standards, as follows:
- Domain status – can contain several values (see RFC 5731 and answer to Evaluation Question #27.);
- Individual’s name (corporation’s name) – the symbol string in 7-bit ASCII, limited by length (min 1 symbol, max 255 symbols, see RFC 5733);
- Address (physical address) – symbol string in 7-bit ASCII, consists of information about the street (optional), city, state⁄province (optional), postal code (optional), country code (see RFC 5733);
- City, state⁄province – symbol string in 7-bit ASCII, limited by length (min 1 symbol, max 255 symbols, see RFC 5733);
- Postal code – symbol string, limited by length (min 1 symbol, max 16 symbols, see RFC 5733);
- Country – two-letter country code (ISO3166-1);
- Phone (fax) number – symbol ‘+’, the country code according to ITU.E164.2005, symbol ‘.’, sequence of digits (see RFC 5733);
- E-mail address – according to RFC 5322;
- Date and time – represented in UTC, capitalized ‘T’ and ‘Z’ are used to display time for the data containing date and time, e.g. 2012-01-12T08:15:00Z;
- The WHOIS service provides all data in 7-bit ASCII.

The content, order and format of the response fields can be modified by the System Administrator in accordance with the effective procedure without suspending operation of WHOIS services.

5. WHOIS SERVICE PERFORMANCE

5.1. WHOIS Service Architecture

The delivery of WHOIS service will be ensured by three independent servers. Two servers are located within the main facilities in Moscow and St.Petersburg (Russia). The third will be installed as a part of a node that is currently under construction in Frankfurt (Germany).

Each server operates a local database, which is a replica of the Primary database. Update from the Primary database is taking place every 5 minutes for an individual WHOIS server. Thus, all tree WHOIS servers update their database every 15 minutes. For more details regarding WHOIS service geographical distribution refer to the answer to Evaluation Question #34.

Server management and provision of the service is carried out through different interfaces to ensure access to the server under a high load on the service. To perform service management there are serial connection to the WHOIS server and secured VLAN connection.

Servers are Linux OS enabled with PostgreSQL v.9.1 database software. Domain name records changes in the Primary database are replicated to the WHOIS database once in five minutes. For data delivery there is Dblink software in use over secure connection.

The access to WHOIS service is provided by means of Anycast technology through a single Anycast cloud. The Firewall assigns access policy for port 43. The geographical separation and Anycast access to the WHOIS services ensures 24x7x365 redundancy. The diagram of the WHOIS architecture is displayed in Figure Q26_WHOISServiceArchitecture. In Moscow and St.Petersburg it consists of two Cisco routers and switches, PDUs for power reset functions, console router to access devices via serial ports and a WHOIS server. The WHOIS server is connected to both routers to ensure accessibility of the service. Where the connectivity between the WHOIS Server and either router has been disrupted, the accessibility of the service is secured through the other one. Where the WHOIS server located at either SRS node is down, the other node will secure the accessibility of the service. In Moscow, St.Petersburg and Frankfurt facilities, the network devices, such as routers, switches, PDUs and console routers are shared with other registry servers. WHOIS server at every node is connected to its own VLAN segment for security reasons. This is shown in the respective figures of the answer to Evaluation Question #32. In Frankfurt, as a part of backup facility there are one router and one switch connected to WHOIS server.
The updates from Primary Database takes place over secure connection. The service is constantly monitored as described in the answer to Evaluation Question #42. To check WHOIS service accessibility and performance parameters, test queries are sent to the WHOIS servers every 5 minutes.

The data flow of WHOIS service is shown in Figure Q26_WHOISDataFLow.
WHOIS service is performed in full compliance with Specification 10 parameters. Presently, the average (workload) for a single WHOIS server, which services 3 TLDs (.RU, .SU and .РФ) with a total of roughly 4.5m of domains, is 500 queries per second, while the peak one – 5,000 ones, and individual query processing time accounting for some 2 ms.

Thus, taking into account the planned expansion of TLD .TATAR, the RDDS query round-trip time (RTT) for no less than 95 percent of queries will be ensured at a level of 2,000 ms.

5.2. Hardware

The specification of the hardware used for WHOIS service provisioning is the following:
(i) Moscow location: CPU Intel Xeon E5405⁄ASUS 1U RS162-E4-RX4 (LGA771,i5000P,SVGA,DVD,SAS RAID,4xHotSwap, SAS⁄SATA, 2xGbLAN, 32DDRII FBDIMM, 700⁄HDD2x250 GB SATA-II⁄ DDR-II 8x4GB FB-DIMM 5300⁄API5FS22
(ii) St.Petersburg location: CPU Intel Xeon E5405⁄ASUS 1U RS162-E4-RX4 (LGA771,i5000P,SVGA,DVD,SAS RAID,4xHotSwap SAS⁄SATA, 2xGbLAN, 12DDRII FBDIMM, 700⁄HDD2x250 GB SATA-II⁄ DDR-II 8x4GB FB-DIMM 5300⁄API5FS22
(iii) Frankfurt location: the server configuration will be similar to the one in St.Petersburg.

5.3. Software

The WHOIS software was developed by Registry Service Provider and has been in use for several years without a single failure.

Data from SRS are being loaded to WHOIS servers every 5 minutes. The response to a user’s query is formed on the basis of data in the WHOIS local database. Each WHOIS server is equipped with a sufficient RAM capacity to have the basic data from the database be cached therein.

Its main components are:
- PostgreSQL database;
- the ‘WHOIS3D’ program. It listens on TCP port 43, controls the query queue, filters out those users who exceed the query frequency limits, forwards queries to the local database in several threads and maintains the logfile;
- the database “stored procedure” designated for generation of the text of the response to a user’s query;
- a set of scripts to launch, suspend, restart the WHOIS3D module, as well as to handle log files daily;
- the procedure of synchronization with the registry database.

Queries are handled continuously in a multithread mode. When the module that generates responses by the database is overloaded, the incoming queries are queued for processing. The denial of service is possible only once the queue is overflown.

6. THE EXTENDED SEARCH

The advanced search by WHOIS database is carried out via the Web-form (see Figure Q26_DomainSearchScreenshot).

The service is available to authorized customers under the service agreement.

The service enables to search data by a partial match, using the following fields:
- domain name;
- contact person’s name;
- registrant’s name;
- the contact person and registrant’s postal address, including all the sub-fields specified in EPP.

Symbol ‘%’ stands for an arbitrary symbol sequence.

The service enables data search by exact match using the following fields:
- registrar’s ID;
- registration date (date or an interval between dates);
- last update (date or an interval between dates);
- nameserver;
- IP address.

Additional bitwise operators are in use for the fields ‘domain name’, ‘nameserver’, ‘registrar identifier’:
- bitwise operator ‘OR’ (searched-for words are separated by the blank space);
- bitwise operator ‘NOT’ ( symbol ‘!’ precedes the searched-for word).

Search results include domain names relevant to all the search criteria (bitwise operator ‘AND’).

7. ABUSES AND REMEDIES

Potential abuses are:
- fetching a large number of domains for formation of one’s own database and its use for illegitimate purposes;
- flooding the WHOIS service with a large amount of queries and, as a consequence, deceleration of processing of other users’ queries;
- usage of the WHOIS contact data for spam purposes.

To preclude the abuses the following measures have been taken:
- bot protection in the Web interface;
- running a log to record incoming queries and results of their execution;
- blocking users who exceeded a certain threshold with regard to the number of queries per minute.

The queries rate from an individual IP address is limited. Where a certain threshold (100 queries in 3 minutes) value has been exceeded, a subsequent query is not processed until the expiration of the said 3-minute time slot and the following notification is communicated to the user instead: ”You have exceeded the allowed queries rate. Please try to connect later”. Where the user has repetitiously (4 times within a 15 minute-long period) exceeded the query rate limit, his every subsequent query submitted within the next hour is not processed. The following notification is communicated: ”You are not allowed to connect”.

The System Administrator may edit the list of IP addresses exempt from the said restrictions or for which those restrictions are eased.

The provisioning of extended search service via Web-form might cause additional abuses, including:
- fetching of a large number of domains for formation of one’s own database and its use for illegitimate purposes;
- flooding WHOIS service with ‘hard’ queries, and, as a consequence, deceleration of processing of other users’ queries;
- use of contact data for spam purposes.

The following measures are taken to prevent the abuses:
- access to the search form is executed using the https protocol;
- access is granted only from the IP addresses included in a certain access list ;
- authentication (entering the name and the password) is required;
- data delivery is limited by the number of domains (no more than 100);
- a log collected for incoming queries for analysis.

8. PERSONNEL

The following staff roles are engaged in implementation and maintenance of the WHOIS service:

(i) Initial implementation:
- Database Developer (Registry Services Department, R&D Group), 2 persons;

(ii) Ongoing maintenance:
- Database Administrator (Registry Services Department, RS Support), 2 persons.
- The Database Developer’s responsibilities include: development and enhancement of WHOIS software; implementations of WHOIS database; performing debugging and intermediate testing.
- The Database Administrator responsibilities include: installation and setup of WHOIS database and application; setup of access privileges; review of ongoing performance characteristics.

9. CONCLUSION

The applicant is absolutely confident that the technology of building a distributed WHOIS service with the use of three remote sites coupled with employment of Anycast technology ensures a high-quality and resilient service for Registrars and Internet users. The searchable Web-based WHOIS provides various methods of search: by domain name, registrant name, postal address, various contact properties, name servers and IP addresses. It supports Boolean searches. In order to protect privacy and implement anti-abuse measures, various mechanisms, such as limiting the number of requests from origin, are implemented.

The extended search capabilities are considered a very important tool for law- enforcement agencies and rights protection champions. The applicant will grant access to the extended search for such organizations after their identification and consultations with the ICANN.

1. THE BACKGROUND

The second-level domain life cycle in the applied-for .TATAR TLD is implemented in compliance with ICANN requirements to gTLD life cycle. All domain name registrations will be exercised pursuant to requirements of the Registry-Registrar Agreement (RRA).

Within the single life cycle, the domain can have one and more statuses cited in RFC 5731. In addition, EPP Extension ‘Registry Grace period’ is used pursuant to RFC 3915.

Of domain statuses enumerated in RFC 5731 pendingCreate, pendingRenew, pendingUpdate statuses are not used because the registry can estimate in in-sync state permissibility of «create», «renew», «update» commands submitted by the registrar.

During all the life cycle periods information on the domain name and the period in which it exists in a given moment in time is available via WHOIS service of .TATAR TLD.

All the notifications below are sent by the registrar at the registrant’s contact addresses and administrative and technical contacts addresses in compliance with RRA.

2. LIFE CYCLE PERIODS

The basic life cycle domain includes the following periods:
(i) Registration period;
(ii) Auto-Renew grace period;
(iii) Redemption period;
(iv) Pending delete period.

The second-level domain lifecycle also includes grace periods to allow flexible policies with regard to erroneous domain transfers (Transfer grace period) or domain renew (Renew grace period).

The lifecycle does not include Add Grace Period.

Specification of the services available for domain name control is described in the answer to Evaluation Question #23.

The detailed description of life cycle periods is given below.

3. BASIC DOMAIN LIFE CYCLE
This section establishes peculiarities of the basic domain cycle periods. For the sake of visualization it is given in the appended Figure Q27_DomainLifeCycle.

3.1 Registration period

Registration period starts at the moment of registration of a domain in the registry database. The date of creation of a domain name entry in the registry database is considered the registration date. The expiry date is calculated by adding the registration period to the registration date. The length of the registration period is specified in the request for registration. The expiry date is calculated by adding the registration period to the registration date.

Domain name can be registered for a period of between 1 and 10 years.

The ‘ok’, ‘inactive’ or ‘clientHold’ status is assigned to the domain according to RFC 5731.

Once the domain name is successfully registered, the registrar’s account is charged an amount calculated in proportion to the registration term in year equivalent basing on the annual cost of registration.

During the registration period the following operations with domains are allowed:
- Change of the delegation parameters;
- Renewal;
- Deletion;
- Transfer.

(i) The change of the domain name delegation parameters

During the registration period, the information about the domain name nameservers, the domain name delegation status and the DNSSEC-related data may be updated.

The ‘ok’, ‘inactive’ or ‘clientHold’ status is assigned to the domain according to RFC 5731.

(ii) Domain name renewal

Domain name registrations may be renewed prior to the expiration for a period up to ten years, provided that the expiration timeline for a domain name registration may not exceed ten years.

A registrar can renew only those domains to which it is the sponsoring registrar. In case of renewal, the expiration date of the registration period is deferred according to the specified term of renewal. A domain renew command with an extension period in excess of the 10 year margin will be rejected.

The registrar sponsoring the domain name at the time of renewal shall pay Renewal Fee in full (as stipulated in RRA).

Registrar should notify the registered name holder of the upcoming expiration no less than twice. The first notice is to be sent in one month or 30 days prior to the expiration date (+⁄- 4 days) and the other one - in one week prior to the expiration date (+⁄- 3 days). If more than two alert notifications are sent, the timelines of at least two of them should be the same as specified above. Notifications of the upcoming expiration must include method(s) that do not require any registrant’s action other than receipt of a standard e-mail order to receive such notifications.

The domain can also be renewed within the auto-renew grace period, as described below.

(iii) Domain name deletion

Within the registration period, the domain can be deleted by a respective sponsoring registrar. Thereat, the domain transits to Redemption Grace Period.

(iv) Domain name transfer

During the registration period, a domain transfer to another registrar can be initiated. The domain name transfer is carried out in compliance with Inter-Registrar Transfer Policy (IRTP).

To initiate the transfer, the gaining registrar should obtain an express authorization from either the registered name holder, or the administrative contact (hereinafter - ʺTransfer Contactʺ). Having received authorization details, the gaining registrar shall send the transfer request to the registry.

After the gaining registrar initiated the transfer, prior to completion or denial of the transfer the domain name is assigned the ‘pendingTransfer’ status. Then the Transfer Pending Period starts, which lasts for 5 days, within which the losing registrar shall decline, confirm or ignore the transfer request. Where the transfer request is ignored, according to the IRTP, the domain is transferred to the gaining registrar.

After the domain was successfully transferred, any subsequent EPP transfer request for the transferred domain must be denied for the span of 60 days. Upon change of sponsorship of registration of a domain name from one registrar to another, according to Part A IRTP, the term of registration of the domain name shall be extended for one year, provided that the maximum length of the registration as of the effective date of the sponsorship change shall not exceed ten years.

The bulk change of sponsorship of registration of domain names from one registrar to another, according to Part B IRTP, shall not result in an extension of the registration term and the Registry Operator may assist in such a change of sponsorship.

Upon receipt of the ʺtransferʺ command from the gaining registrar, the Registry Operator will transmit an electronic notification to both registrars. The response notification may be sent to the email address set up by each registrar for the purpose of facilitation of transfers.

Peculiarities of the Transfer Grace Period are provided below.

In the event of transfer the gaining registrar’s account should be charged an amount equivalent to the cost of the domain name renewal for 1 year.

3.2. Auto-renew Grace Period.

Auto-renew Grace Period is a period beginning on the day following the date of expiration of the registration period if the domain name has not been renewed until the end of the registration term. At this juncture, the system will automatically renew the registration on the first day after the expiration date. The duration of the period is 0-45 days, subject to the registrar’s policy.

Upon occurrence of the Auto-renew Grace Period, the registrar’s account is charged an amount equivalent to the cost of domain name renewal for 1 year

During the Auto-renew Grace Period, the following operations with domains are possible:

(i) Update. The registrar can change the DNS resolution path to effect a landing website different than the one used by the registrant prior to expiration, the page shown must explicitly say that the domain has expired and give instructions on how to recover the domain. Wording in the policy must make it clear that instructions shall be as simple as directing the registrant to a specific website.

(ii) Delete. If a domain is deleted within the Auto-Renew Grace Period, the sponsoring registrar at the time of the deletion receives the Auto-Renew fee credited to his account. The domain immediately goes into the Redemption Grace Period. Renew. A domain can be renewed within the Auto-Renew Grace Period for up to a total of ten years. The account of the sponsoring registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

(iii) Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Auto-Renew Grace Period, the Auto-Renew charge is credited to the losing registrar’s account and the year added by the Auto-Renew operation is cancelled. The domain’s expiration date is extended for between one year and no more than ten years and the gaining registrar is charged for that additional year, even where a full year is not added because of the 10-year registration cap.

(iv) Bulk Transfer (upon ICANN’s approval). Bulk transfers upon ICANN’s approval may be made during the Auto-Renew Grace Period according to the procedures set forth in Part B of the ICANN Policy on Transfer of Registrations between registrars. The expiration dates of transferred registrations are not affected.

Where the registrar sponsoring the domain name has not performed any operations with the domain name within the Auto-Renew Grace Period, the domain name transits to the Redemption Grace Period. Thereat the Auto-Renew fee is credited to the sponsoring registrar’s account at the end of the Auto-Renew Grace Period.

3.3. Redemption Grace Period

Redemption Grace Period is a period starting when the registrar requests deletion of a domain or when the domain was not renewed during the Auto-Renew Grace Period. The only action the registrar can undertake with respect to the domain within the Redemption Grace Period is to request its restoration. Any other registrar’s requests to modify, purge or update the domain will be rejected. Unless restored, the domain will be held in the Redemption Grace Period for a specified number of calendar days. The length of this Redemption Period for .TATAR TLD is set for 30 calendar days.

At the moment the period begins, the Registry automatically assigns «serverHold», «serverRenewProhibited», «serverTransferProhibited», «serverUpdateProhibited» and «pendingDelete» statuses to the domain in compliance with RFC 3915.

During the redemption grace period, the domain name will not be included in the zone file. Where the domain is successfully recovered, «serverHold», «serverRenewProhibited», «serverTransferProhibited», «serverUpdateProhibited» and «pendingDelete» statuses are removed and the domain can be managed in the usual manner.

The registrar incurs extra costs each time it requests domain restoration. The restored domain name will be auto-renewed for a period of one year and the registrar’s account will be charged a renewal fee.

3.4. Pending delete period

Pending Delete Period is a period starting where the domain has not been restored during the Redemption Grace Period.

During this period, the domain name will not be included in the zone file. All registrar’s requests to modify or otherwise update the domain in pendingDelete status will be rejected. The domain name is purged from the registry database in 5 calendar days after it has been assigned the pendingDelete status.

After the end of the Pending Delete Period, the domain name becomes available for re-registration.

3.5. Special occasions

Where disputes arise or complaints brought with regard to a domain name are considered, the Registry Operator can, in compliance with the terms of Registry Agreement, as well as with the Registry Operator’s policies and procedures, assign to the disputed domain name statuses «serverDeleteProhibited», «serverHold», «serverRenewProhibited», «serverTransferProhibited» or «serverUpdateProhibited», which are implemented according to RFC 5731. These statuses can be changed by a decision made per outcomes of consideration of the dispute or complaint.

The registrar has a possibility to set «clientDeleteProhibited», «clientHold», «clientRenewProhibited», «clientTransferProhibited» or «clientUpdateProhibited» statuses implemented according to RFC 5731 with the use of the EPP Mapping «update» command in compliance with RRA. Setting these statuses may be required in the event of a conflict situation, suspicion of an unauthorized access or initiation of the UDRP procedure. These statuses can be cancelled by the Registry Operator or by the registrar.

Where the registrar has set the «clientUpdateProhibited» status simultaneously with other prohibitive client statuses, in order to manage other statuses the registrar is required to cancel the «clientUpdateProhibited» status first.

When a domain, subject to a UDRP dispute, is deleted or expires in the course of the dispute, the complainant party to the UDRP dispute will have an option to renew or restore the name under the same commercial terms as the registrant. If the complainant renews or restores the name, the clientDeleteProhibited, clientRenewProhibited, clientTransferProhibited and clientUpdateProhibited statuses will be set, the WHOIS contact information for the registrant will be removed, and the WHOIS entry will indicate the name is subject to dispute. If the complaint is terminated, or the complainant has lost the UDRP case, the name will be deleted within 45 days. The registrant retains the right, under the existing Redemption Grace Period provisions, to recover the name at any time during the Redemption Grace Period, and retains the right to renew the name before it is deleted. More information about UDRP is included in the answer to Evaluation Question #29.

Where the clientTransferProhibited or serverTransferProhibited status is assigned to the domain name and the pendingTransfer status has been set thereto, the pendingTransfer status is removed.

4. GRACE PERIOD POLICY AND PROCEDURES

The Grace Period refers to a specified number of calendar days following a registry operation in which a domain action may be reversed and a credit may be issued by the registry to a registrar.

There are four grace periods provided by Registry Operatorʹs SRS: Renew Grace Period, Auto-Renew Grace Period, Transfer Grace Period, and Redemption Grace Period.

4.1 Grace Periods

4.1.1 Renew Grace Period

The Renew Grace Period is a specified number of calendar days following the renewal⁄extension of the domain name registration period. The current length of the Renew Grace Period is 5 calendar days. If Delete, Extend, or Transfer occurs within those five calendar days, the following rules apply:

Delete
If the domain is deleted within the Renew Grace Period, the sponsoring registrar at the time of the deletion has the Renew fee credited to his account. The domain immediately goes into the Redemption Grace Period. Exceptions therefrom are described in section 4.2. ʺOverlapping grace periodsʺ.

Renew
The domain can be extended within the Renew Grace Period for up to a total of ten years. The account of the sponsoring registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

Transfer (other than the ICANN-approved bulk transfer)
If the domain is transferred within the Renew Grace Period, this results in no credit. The expiration date of the domain registration is extended by one year and subsequent years making up a total of no more than ten (10) years. The number of years added results from the Extend retaining its validity with respect to the domain name concerned.

Bulk Transfer (upon the ICANN’s consent)
Bulk transfers upon the ICANN’s consent may be effected during the Renew Grace Period according to procedures set forth in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected.

4.1.2 Auto-Renew Grace Period

Auto-Renew Grace Period is described above as a domain name basic life cycle period.

4.1.3. Transfer Grace Period

The Transfer Grace Period is a specified number of calendar days following the domain transfer the according to Part A of the ICANN Policy on Transfer of Registrations between Registrars. The transfer grace period is implemented according to IRTP.

If Delete, Extend, or Transfer occurs within that five (5) calendar days, the following rules apply:

Delete
If the domain is deleted within the Transfer Grace Period, the sponsoring registrar at the time of the deletion has the transfer fee credited to his account. The domain immediately goes into the Redemption Grace Period.

Extend
If the domain registration is extended within the Transfer Grace Period, there is no credit for the transfer. The registrarʹs account will be charged for the number of years the registration is extended. The expiration date of the domain registration is extended by a number of years, up to a maximum of ten years, as specified by the registrarʹs requested Extend operation.

Transfer (other than ICANN-approved bulk transfer)
The ICANN Policy on Transfer of Registrations between Registrars does not allow transfers within the initial 60 days after the previous transfer; it is registrars’ responsibility to enforce this restriction.

Bulk Transfer (upon the ICANN’s consent)
Bulk transfers upon the ICANN’s consent may be carried out during the Transfer Grace Period according to procedures set forth in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing registrarʹs account is charged for a Transfer operation that occurred prior to the Bulk Transfer.

4.2 Overlapping Grace Periods

If an operation is performed that falls into more than one grace period, it is subject to procedures in effect for each of grace periods concerned.

If the domain is deleted within the Renew Grace Period, then the registration and renew amounts are credited to registrar’s account taking into consideration the number of years for which the registration and renewal were done.

If a domain is auto-renewed, then renewed, and then deleted within the Renew Grace Period, any earlier charged Auto-Renew fee, as well as extension fees (with a due regard to the number of years), will be refunded to the registrar’s account.

If several billable operations, including a transfer, are performed with the domain and the domain is deleted within grace periods of each of those operations, it is the fees for those operations that were performed after the most recent transfer, including the latest transfer, that are credited to the current registrar’s account.

5. STAFF RESPONSIBILITIES

All operations except introduction of administrative restrictions are automatically performed by SRS (as described in the answer to Evaluation Question #24). Assignment of prohibitive statuses necessitates no more than 2-3 man-hours a month. These functional duties can be assigned to the Customer Service without the need to deploy extra staff.

1. INTRODUCTION

Domain name registration policies in the prospective community-based gTLD .TATAR suggest that the domain name may be registered only upon presenting recommendations from two effective registrants in .TATAR. The Applicant believes that such requirement will form an additional regulating factor to lower the number of abuses and malpractices in .TATAR. That said, guided by the ICANN’s policies and recommendations, and the industry best practices the Applicant envisages implementation of sufficient and efficient anti-abuse measures in the TLD nonetheless.

The Applicant believes that abusive registrations or use of domain names in the applied-for gTLD .TATAR should not be tolerated.
Prior to the launch of the TLD, the Applicant will develop and publish on his website the respective Anti-Abuse Policies in the applied-for TLD based on materials set forth in the present section, the Application Guidebook requirements, ICANN standards and policies on abuse prevention and mitigation, as well as industry best practices.

Abuse minimization within this section suggests certain measures in the TLD that the prospective Registry Operator or Registrars (in accordance with requirements of Registry-Registrar Agreement (RRA)) can undertake in order to prevent or terminate abuse in case of its identification, as well as to mitigate consequences of such actions.

As it is impossible to foresee all possible kinds of abuse that may emerge in the future, the Applicant reserves the right to modify earlier established policies and procedures and introduce additional ones aimed at minimizing abuse in the TLD. In addition, the Applicant plans to apply and factor into all the abuse specifications, requirements and policies for gTLDs approved by ICANN as well as take into consideration the corresponding recommendations of ICANN and best practices in other TLDs.

The Applicant plans to interact with organizations that specialize in exposure, analysis and termination of various illegal usages of Internet resources and are competent in the field of abusive use of domain names. The Applicant sees the purpose of such an interaction in joint development and implementing procedures of abuse identification, prompt examination and expert evaluation by third parties. Besides, information on abusive actions in Internet, including those related to using domain names, can be later used to prepare regular reports and informing all the Internet community representatives concerned about examples of malicious behavior, particularly so for the sake of preparing the industry’s black lists.

Organizations exemplifying Russian NGOs and corporations which are recognized by the Internet community and the national law-enforcement bodies as experts in this area, are the Friendly Runet Foundation (an NGO specializing in fighting child pornography) and Group-IB Ltd (renders complex services in the field of investigation into information security incidents). The Applicant plans to establish contractual relations with these organizations and engage them as experts in post-moderation procedures and evaluation of abuses in the TLD.

2. ABUSE CLASSIFICATION

The Applicant considers as abuse in the applied-for gTLD .TATAR to be any illegal and excessive use of authority, position or ability that generates security and stability challenges to the Registry Operator, Registrars and registrants as well as for Internet users in general.

The Applicant foresees, without limitation, the following categories of abuses:
(i) Abusive registration of domain names;
(ii) Abusive use of registered domain names;
(iii) Abusive activities of registrars jeopardizing the registry’s stability and security.

It is suggested to employ specific measures for minimizing the listed abuses with regard to every category. Prevention and actions in case of detection of the said abuses are used in accordance with the policies and procedures given in this section of the application for the applied-for gTLD.

Hereinafter the term ʺRegistrarʺ means ʺthe ICANN accredited registrar which entered into the Registry-Registrar Agreement (RRA) with the TLD Registry Operator.ʺ

2.1. Abusive registration of domain names

2.1.1. Abusive registration of domain names implies (including but not limited to) registration of domain names with violation of standards, restrictions, requirements and policies of ICANN (established in the Registry Agreement and the Registrar Accreditation Agreement (RAA)) and the TLD Registry Operator (established by RRA and policies for the TLD ); abuse of stability and security of the TLD registry; as well as infringement or violation of rights of a certain or indefinite group of persons, the international or national law. Such registration issues are usually related to the core domain name-related activities performed by registrars and registries.

2.1.2. The applied-for TLD will provide for the following set of measures to prevent abusive registrations of domain names:

(i) Protection to trademark holders:

- The pre-launch Sunrise service in the TLD foresees employment of a specially developed procedure of priority registration of the second-level domain names for trademark and brand owners, intending to use these domains in conformity to the mission and purposes of the gTLD .TATAR and confirming these by respective commitment and warranty. It is also envisaged to implement the Trademark Claims service in accordance with requirements set by ICANN for gTLD registries. During the Sunrise period, corporations and individuals concerned will have a possibility to challenge registration of any second-level domain name in accordance with the respective policy for Sunrise dispute resolution. More detailed information on the TLD launch is given in the answer to Evaluation Question #29.
- To prevent potential abuse during the open registration in the TLD the registrant, in accordance with the TLD policies, will be recommended, before filing an application, to make sure there is no similarity between the domain name and trademarks, names of non-profits and state agencies and other types of intellectual property.
- In the event of any disputes regarding eligibility of registration of domain names associated with illegal use of trademarks, the claimant has the right to consider such a dispute in accordance with both the procedure under the Uniform Domain Name Dispute Resolution Policy (UDRP) and the applicable law.

(ii) Protection of geographic names

In accordance with Specification 5 to the Registry Agreement the TLD provides for the list of reserved domain names which includes geographic and geopolitical names. These domain names are not available for registration. However, the reserved names are not intended to be prohibited names and may be released to corresponding and appropriate entities basing on respective policies in the TLD. The list of reserved names may also be updated from time to time. More details on protection of geographic names can be found in the answer to Evaluation Question #22.

2.1.3. Identification of abusive registrations is exercised pursuant to petitions or complaints by the parties concerned.

Petitions⁄complaints of the parties concerned are processed in accordance with the procedure described in sub-section 3.2.

2.1.4. Possible actions in the event of abuse identification.

Where abusive registrations of domain names were identified, a decision to cancel the domain name registration can be made.

2.2. Abusive use of registered domain names

2.2.1. The abusive use of domain names in the TLD is understood as follows:

- Malicious use of domain names;

- Use of domain name for posting thereon and distributing materials, data, information inconsistent with the mission and purposes of gTLD .TATAR, as well as conflicting with the Russian law and commonly recognized international legal standards;

- Use of domain name for purposes that do not correspond to the warranty and commitment given by its registrant during the registration process.

Such domain name use issues concern the registrant’s actual operation does with the domain name after the domain is created, that is, the purpose the registrant puts the domain to, and⁄or the services that the registrant operates on it. These use issues are often independent of or do not involve any registration issues.

2.2.1.1. Malicious use

Malicious use includes (but is not limited to) the following kinds of activities:

(i) Spamming
Spam is defined as bulk unsolicited e-mail (or SMS, MMS) or posting of undesired content on the websites.

(ii) Phishing
Phishing is defined as use of websites fraudulently presenting themselves as trusted sites in order to deceive Internet users and receive their key information including, but not limited to, e-mails, passwords and banking credentials.

(iii) Malware distribution
Malware is defined as installation by a registrant or a person authorized by him⁄her of software designated for penetration in, or inflicting damage to, third parties without their knowledge.

(iv) Botnet control
Botnet control is defined as an exercise from a certain domain name of control over malicious software implanted on infected computers and intended for fulfillment of a concerted impact.

(v) Any other type of domain name use for abusive activities aimed at infringement of the Internet network elements (hardware or software) that do not belong to its registrant.

2.2.1.2. Use of domain names for posting and distribution of materials, data, information inconsistent with the mission and purposes of the applied-for TLD as well as conflicting with the Russian law and commonly recognized international legal standards. This kind of abuses includes the use of domain name for placement, distribution, reproduction, transmission, etc. by any means, as well as in any form (including but not limited to) of:

(i) materials⁄data⁄information promotion of which is either prohibited or restricted by law of the Russian Federation (such as, for instance, narcotics or psychotropic substances, liqueurs, tobacco products, etc.);

(ii) software and⁄or other materials that are, in part or in full, protected by copyright, author’s right and allied rights without consent of the rights holder, as well as content which concerns any patent, trade mark, commercial secret, copyright or other proprietary rights and⁄or author’s right and associated with it the third party’s rights;

(iii) hyperlinks to Internet resources whose contents contravene the Russian Federation law and commonly recognized international standards;

(iv) materials⁄data⁄information, contradicting to public and moral order, bona fide, infringing the rights of the third persons (for instance, those with obscene content, antihuman calls insulting human dignity, religious sentiments, etc.);

(v) materials⁄data⁄information of erotic and pornographic nature, which directly or indirectly promote unhealthy lifestyle, sects, extremism, threats to physical or mental health;

(vi) any other materials⁄data⁄information conflicting with Russian and⁄or international law;

(vii) any other materials⁄data⁄information inconsistent with the mission and purposes of the TLD.

2.2.1.3. Use of domain name for purposes that do not correspond to the warranty and commitment given by its registrant during the registration process. This abusive use may occur when the registrant use the domain name, for instance, to post and distribute materials⁄data⁄information which are legal by their own but contradict the purpose of the domain name use as stated by the registrant.

2.2.2. In order to prevent abusive use of domain names, the Applicant establishes a number of requirements to registrants therein that will be stipulated in the TLD registration policy and which the Registrar, in accordance with RRA, is bound to include in the registrants’ obligations under registration agreement.

(i) The registrant is bound to use the domain name in accordance with the mission and purposes of .TATAR domain.

(ii) While registering the domain name, the registrant is bound to provide commitment and warranty (by filling out the “descriptionʺ field during registration of domain, supported by the EPP extension schema as described in the answer to Evaluation Question #25), that purpose of the use of the domain name does not contradict the mission and purposes of the TLD. Where it has been found out that the domain name was used against these commitment and warranty, the registrant may become subject to sanctions to the extent of cancellation of the domain name registration.

(iii) Registrant is bound to present recommendations from two effective registrants in the TLD .TATAR in case the domain name is registered during the landrush and live period.

2.2.3. Identification of abusive use takes place basing on submission of petition or complaint by a party concerned.

(i) Petitions⁄complaints by parties concerned are processed in accordance with the procedure described in sub-section 3.2.

(ii) Where any disputes arise with respect to legality of usage of domain names related to abusive use of trademarks, decisions are made in accordance with the Uniform Dispute Resolution Policy, the Uniform Rapid Suspension System or other dispute resolution policies developed and approved by ICANN, as well as by the effective law of the Russian Federation.

2.2.4. Where an abusive use of a domain name has been identified, one of the following measures may become applicable:

(i) Suspension of the domain name delegation.
In case of application of this measure, the domain may not be delegated until the moment the detected violations are remedied (domain gets status EPP «inactive» and EPP «serverHold»).

(ii) Restrictions on the use of the domain name.
In case of application of this measure, the domain name may not be transferred to another Registrar, updated, renewed, or deleted (domain gets a combination of EPP statuses – «serverTransferProhibited», «serverRenewProhibited», «serverUpdateProhibited», «serverDeleteProhibited»). The measure can be applied together with the one referred to in p.(i).

(iii) Cancellation of the domain registration.
Where measures described in pp. (i)-(ii) are taken, the registrant is granted a certain period of time to eliminate the identified abuse. In case the registrant has failed to remedy the abuse within a given time period, the domain name is deleted. For a greater detail, see sub-section 3.2.

2.3. Abusive Registrar activities

2.3.1. Abusive Registrar’s activities constitute any acts by which Registrars breach restrictions, requirements and policies of the RRA agreement in the TLD and endangering the normal operation of the registry, the Registry Operator and registrants, DNS and the Internet on the whole.

The Applicant will also closely monitor Registrars’ activities related to noncompliance with ICANN standards, limitations and policies. To prevent and mitigate such activities, the Applicant plans to include into RRA respective obligations of, and the right to impose sanctions on Registrars, which would range from a temporary suspension of RRA to its termination. These sanctions, for instance, may be imposed in the case of non-compliance with the UDRP, the URS, or once it has been found out that the Registrar does not take necessary measures to react to reports about WHOIS data inaccuracy received from the WHOIS Data Problem Report System, despite of obligations under RAA.

2.3.2. In order to prevent Registrars’ abusive activities, the Applicant implements Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify accurate operation of Registrarʹs client system. For the sake of urgent consultations and support of Registrars Customer and Technical support services shall be deployed. More details are given in the answer to Evaluation Question #23.

2.3.3. Identification of Registrars’ abusive activities takes place pursuant to petitions⁄complaints by parties concerned in accordance with the complaints processing procedures described in sub-section 2.2, as well as on the basis of the registry database operational monitoring by the Registry Operator, described in the answer to Evaluation Question #42.

2.3.4. To identify Registrars’ abusive activities, the following measures can be applied:

(i) Suspend of RRA and delivery of a warning notification to the Registrar requiring to terminate the identified abuse and mitigate its consequences.

(ii) Termination of RRA.
The Registry Operator will send a prompt electronic and written notice to the Registrar, with respective copies sent in the same manner to ICANN, describing restrictions and policies the Registrar has violated. The ensuing procedure concerning the Registrarʹs eligibility to continue to sponsor registered domain names in the TLD is governed by the Registry-Registrar Agreement and the Registrar Accreditation Agreement.

3. GENERAL ORGANIZATIONAL MEASURES FOR ABUSE MINIMIZATION

This sub-section enumerates general organizational measures designed for minimization of abuses in the TLD.

3.1. Abuse point of contact

The proposed Registry Operator will establish and publish on its website a single abuse point of contact responsible for addressing matters requiring prompt attention and providing a timely response to abuse complaints with respect to all the domain names registered in the TLD through all the operating Registrars, including resellers.

The Registry Operator is bound to keep this contact data up-to-date at all times.

Processing of complaints received by the single abuse point of contact will be performed by the Duty Shift of the Anti-Abuse Team 24х7х365 with account taken of categories of complaints, as described in sub-section 3.2.

3.2. Abuse complaints processing procedure

This sub-section describes in a general form the procedure of processing complaints about abusive activities related to registration or use of domain names in the TLD.

The detailed procedure will be developed by Registry Operator and posted on its website.

A complaint regarding any problem related to operation of a domain name in the TLD can be filed by any party (a corporation, an individual, or a law enforcement agency) concerned.

The following categories of complaints with the corresponding response time are foreseen:

- Category 1: complaints with regard to abuse activities requiring an immediate action to minimize its potential effect (i.e. phishing, malware distribution, etc.): the response time to the complaint shall be no more than 3 hours;
- Category 2: other types of complaints: the response time shall be no more than 3 calendar days.

“Response time” means the time period within which the Duty Shift of the Anti-Abuse Team shall complete the initial processing of the complaint, including urgent steps to minimize the abuse impact.

The total time for processing of complaints by the Anti-Abuse Team may not exceed 60 calendar days from the moment of receipt of the abuse complaint and through the moment of closing the respective case in Trouble Ticket Management System (TTMS).

The procedure is designed to process complaints on a minimum required level, and to reduce abuse remedy time.

(i) Receipt of complaint

Any complaint received by the single abuse point of contact is registered in the TTMS. The registration is processed automatically if the complaint is submitted via e-mail or a special Web-interface on the Registry Operator’s website. If the complaint is submitted through other channels (e.g., by phone) the Anti-Abuse Team staff processes it manually. The complainant is given the Trouble Ticket Reference Number in TTMS. The case remains active in TTMS until the complaint processing is complete.

Information about incoming complaints as well as results of their processing by the Anti-Abuse Team is to be stored in the TTMS for 3 (three) years in case of law-enforcement agencies’ inquiry regarding any case.

(ii) Initial complaint processing

At this stage, the Duty Shift of the Anti-Abuse Team evaluates adequacy of the incoming complaint, and defines its category.

Where the incoming complaint is recognized inadequate, the complaint processing is terminated and the case in TTMS is closed. The corresponding notification is sent only to the complainant.

Where the incoming complaint is recognized adequate, the Duty Shift exercises activities in accordance with the category of the complaint:

- Category 1 complaint: the suspicious domain is blocked (the delegation is suspended and the ban on its transfer, renewal, update or deletion is established). The registrant and sponsoring Registrar receive due notification with the incoming complaint data and reasons for the domain name blocking;

- Category 2 complaint: the suspicious domain is NOT blocked. Due notification is sent to the registrant and sponsoring Registrar on a copy. The notification should include the incoming complaint data and suggestion to the registrant to produce clarifications regarding the complaint within the specified time period.

(iii) Main body complaint processing

Category 1 complaint:

Within 30 calendar days the registrant can request clarifications from the Anti-Abuse Team and confirm discontinuation of the identified abuse.
- If within 30 days the registrant has failed to refer to the Anti-Abuse Team, the domain name registration is cancelled. The complaint processing is complete.
- If the registrant has referred to the Anti-Abuse Team with clarifications, by results of the respective analysis and evaluation the domain name can be reactivated. The complaint processing is complete.

Category 2 complaint:

- The Anti-Abuse Team escalates the complaint to panel of experts for evaluating the suspicious domain. Experts operate on the basis of internal regulations consistent with the policies and procedures the Registry Operator established in the TLD.
- Where the registrant’s explication has been received within the noted time period, the Anti-Abuse Team submits it to experts for comprehensive evaluation of the situation. If the explication was received after the noted time period, experts do not consider it when processing the complaint.
- Upon receipt of the informed judgment, the Anti-Abuse Team: 1) dispatches notification of the evaluation findings to the registrant and sponsoring Registrar. Complaint processing is completed; or 2) blocks domain (suspends delegation, establishes prohibition to transfer, renew, update and delete the domain). The corresponding notification is sent to the registrant and sponsoring Registrar.
- Within 30 calendar days after the domain name blocking, the registrant may contact the Anti-Abuse Team for clarifications and confirmation of discontinuation of the abuse.
- If within 30 calendar days the registrant failed to refer to the Anti-Abuse Team, the domain registration is cancelled. The complaint processing is complete.
- If the registrant has referred to the Anti-Abuse Team with clarifications, they are subject to evaluation by results of which the domain may be reactivated. The complaint processing is complete.

(iv) Completion of complaint processing

When complaint processing is complete, notification of its results is dispatched to the complainant, registrant and sponsoring Registrar. The respective case is closed in TTMS.

(v) Remedy of abuse by the registrant

Where the registrant received notification of a complaint and of measures taken in response thereto and the registrant is able to remedy the abuse, he⁄she may undertake the necessary steps to remedy the abuse and report results to the Anti-Abuse Team. Where re-examination proves that the abuse has been remedied, sanctions against the domain name may be stopped and the domain may be re-activated.

3.3. Responding to law-enforcement requests concerning abuses

The Registry Operator provides for a special service level for law-enforcement requests.

Law-enforcement requests concerning any kinds of abuses classified in the TLD are processed in accordance with the complaint processing procedure (sub-section 3.2).

Where a law-enforcement agency’s request concerns any abuse that is not explicitly specified by the Registry Operator , the Anti-Abuse Team’s response time shall not exceed 1 (one) workday.

The Registry Operator may enter into an interaction agreement with a specific law-enforcement agency. Where such an agreement has been entered into, any requests from that law -enforcement agency are dispatched to the Anti-Abuse Team via a trusted channel (for instance, requests are sent from the authorized e- mail address or verified with electronic digital signature). For processing of such requests they are granted a priority status, which implies their processing in TTMS in a separate queue with mandatory granting the request the category 1 complaint status.

3.4. Processing of orphan glue records

When provided with evidence in writing that the glue is present in connection with malicious conduct (according to Specification 6 to the Registry Agreement), the orphan glue records are deleted.

In this case, the Registry Operator will exercise the following procedure:
- Identification of the registered domain names associated with the aforementioned orphan glue records;
- Examination of the list of nameservers necessary for the domain names delegation;
- In case of failure to meet the requirement to provide two appropriate nameservers, suspension of delegation of the domain;
- Sending notification to the domain name sponsoring registrar and its registrant on steps taken and the need to update information about nameservers for re-delegation of the domain.

4. RESOURCING PLANS. PERSONNEL.

To ensure operation of the single abuse point of contact and processing of abuse complaints, the Applicant concludes an agreement with a third-party contractor. The third-party contractor selected is JSC ʺTechnical Center of Internetʺ which has necessary personnel with required skill levels and extensive record of processing abuse complaints. The agreement sets strict service level requirements that must be followed by the contractorʹs personnel, in particular, the Duty shift’s response time with respect to category-1 complaints (no more than 3 hours) and category-2 ones (no more than 3 calendar days), complaints processing timelines, and other parameters.

Functions of the Anti-Abuse Team are performed by Duty Operators working in the 24х7х365 mode.

Based on available to the Applicant statistics of complaints with regard to abuse-related issues in the existing TLDs, it is possible to project a number of complaints to the Anti-Abuse Team. For 65,220 domain names registered by the end of the third year, the provisional monthly number of complaints should not exceed 14 per month. With an average claim processing time of 60 minutes in man-hour equivalent by one Anti-Abuse Team Operator, this accounts for 12-14 man-hours a month, excluding the time of expert organizations evaluations. Thus, the number of Operators assigned to the Duty Shift of the Anti-Abuse Team is considered to be sufficient.

The functional duties of the personnel assigned to the Anti-Abuse Team include:
- Observance of complaints processing procedures;
- Evaluation of the incoming abuse claims within the limits of their competence, including classification of complaints by the type of abuse in accordance with the service instructions;
- Interaction with expert organizations on conditions set forth by agreements the said expert organizations enter into with the Registry Operator;
- Interaction with the complainant, registrant and sponsoring registrar in the course of processing abuse;
- Observance of escalation procedures of queries to the Registry Operator or the Registry Service Provider’s corresponding services, if necessary.

Operations of the Duty Operators of Anti-Abuse Team are regulated by service instructions. These service instructions constitute an internal document for use only by the corresponding personnel and include description of required actions of the Duty Operators of the Anti-Abuse Team while processing complaints.

The JSC ʺTechnical Center of Internet” confirms the delivery of the Anti-Abuse Team Service as acknowledged by the Letter of Intent (See the attachment to Evaluation Question #46 - Q46_LOITCI).

5. WHOIS ACCURACY ENHANCEMENT MEASURES

This sub-section enumerates measures aimed at increasing the accuracy of WHOIS data.

The mission and purposes of the TLD require elimination of registration of domain names with anonymous or false WHOIS data. As information on registrants is collected by Registrars, certain requirements are laid toward Registrars within RAA and RRA.

5.1. Collection of registration data

In accordance with RAA and RRA provisions, Registrars in the TLD shall collect registration information from the registrant and check it to ensure validity of the domain-name registration. The Registrar must submit through the Shared Registration System (SRS) complete, accurate, and valid registration data, and must update that data when changes occur.

Where domains are registered by legal entities, the Registrar collects information that can be used for unambiguous identification of the corporate registrant (name, taxpayer identification number (TIN), principal place of business, postal address, phone number, e-mail). Data allowing automatic verification (e.g. TIN) shall be subject to such verification.

Where domains are registered by individuals, the Registrar collects information that can be used for their unambiguous identification (name in full, postal address, phone numbers, e-mails).

Besides, the Registrar collects recommendations from two effective registrants in the TLD .TATAR as well as commitment and warranty provided by the registrant during the domain name registration process and confirming consistency with the mission and purposes of the gTLD .TATAR.

5.2. Verification of registrant information

In accordance with RAA, after the domain name registration the Registrar is required to send the registrant a notification of the domain name renewal procedure, the policy of the domain deletion in case of his⁄her failure to renew it, as well as on the need to update the registrant data in case of its alteration and to update it at least annually. This notification should also include possible consequences of failure to respond to Registrars’ requests to confirm the earlier given WHOIS data to the extent of cancelling the domain registration.

In accordance with the RRA provisions, the Registrar will be obligated to make sure that the registrant provided genuine data and can be reached on⁄at the a contact he⁄she specified for each type of contacts (registrant, administrative contact, technical contact). In order to verify the registrant data the Registrars are bound to conduct specialized checkups, namely:

(i) Examination of the presence of two recommendations from effective registrants in TLD .TATAR as of the moment of registration of the domain name and presence of warrantees and commitment is consistent with the mission and purposes of the gTLD .TATAR.

(ii) Phone number verification
For instance, Registrar can use SMS-authorization, where an SMS is sent to the registrant’s contact phone number with a request for the registrant response actions to complete authorization or it can be a call placed by the Registrar’s staff to the phone number provided by the registrant given.

(iii) E-mail verification
For instance, back-verification is used, where the registrant must send a reply with certain content or receives an e-mail request sent by Registrar or where the registrant must use the given hyperlink to complete verification.

Besides, the Registry Operator will prepare recommendations for Registrars to conduct, at their discretion, checkups of documentary confirmations of registrant information.

In accordance with ICANN WHOIS Data Reminder Policy, at least annually, a registrar must present to the registrant current WHOIS data, and remind the registrant that provision of false WHOIS data can form grounds for cancellation of his⁄her domain name registration. Registrants must review their WHOIS data, and make respective modifications therein.

ICANN Restored Names Accuracy Policy states that when a registrar restores the name (from the redemption grace period) that had been deleted on the basis of submission of false contact data or because of failure to respond to Registrar’s inquiries, the name must be placed on the Registrar Hold status until the registrant has provided updated and accurate WHOIS data.

5.3. Encouragement of Registrars

The proposed Registry Operator plans to periodically conduct spot checks of registrant data collected by Registrars.

To conduct the check the Registry Operator may contact registrants by sending registered postal letters to his⁄her postal addresses (with delivery confirmation), e-mail queries at contact e-mail addresses or by placing calls to his⁄her contact phone numbers and those of administrative and technical contacts in order to confirm the relevance of the earlier provided WHOIS data.

Reports containing the spot check findings will be forwarded to all the gTLD Registrars. Based on the reports, those Registrars which have demonstrated a high level of authenticity and accuracy of registrant information will be awarded a possibility to take part in joint marketing campaigns with the Registry Operator.

Where the Registrar regularly exhibits a low level of accuracy of WHOIS data, the Registry Operator has the right to run a detailed examination of registration information with regard to domain names sponsored by that Registrar. By results of such an examination the Registry Operator is given time to remedy exposed abuses. Where the Registrar has failed to remedy the abuses within the prescribed time periods or where the Registrar has permanently abused the rules and policies, the decision may be made to suspend the effect of RRA as per terms and conditions set forth in RRA.

5.4. Other measures

In order to protect registrants and as well as to abide by Russian Federal Act FZ-152 ʺOn personal dataʺ, the Registry Operator does not disclose registrants personal data (including those of the administrative and technical contact) as well as e-mails and phone numbers in the publicly available WHOIS.

The Registry Operator obligates Registrars to ensure the possibility to contact the registrant without publication of his⁄her contact data in WHOIS (e-mail, phone number). This can be implemented, for instance, by means of publishing a web-form that allows sending messages to the registrant. The Registry publishes in its WHOIS the hyperlink to the web-form on the Registrar website.

6. PREVENTION OF UNAUTHORIZED ACCESS TO DOMAIN FUNCTIONS

Prevention of unauthorized access to domain functions must be implemented only within the frame of relations between the Registrar sponsoring the domain and its registrant. The Registry Operator establishes certain obligations under RRA for their mandatory observance by Registrars as well as recommendations for Registrars which can be translated into the registration agreement.

In accordance with the RRA provisions, the Registrars are obligated to check for complexity the passwords registrants use to carry out critical operations with their domain names.

Besides, the Registry Operator obligates the Registrars to implement the following measures:
- The Registrar is bound to grant registrant the possibility to control the domain name via Web-interfaces using HTTPS protocol.
- The Registrar is bound to send notifications to registrant, administrative and technical contacts upon completion of any critical operation with the domain (update, renewal, transfer, deletion) as well as to include in those notifications information of where one should refer to in the event the operation was not authorized by the registrant.
- The Registrar is bound to establish mechanisms to check for resiliency and security passwords the registrant uses to access to domain critical functions and to warn the registrant and his⁄her contacts of responsibility to ensure secure storage of passwords.

The Registrar is recommended to have registrants use machine-generated passwords to ensure proper access to domain functions.

Where domains are transferred, the parties engaged therein are bound to comply with the ICANN requirements to Holder-Authorized Transfers as set forth in the Inter-Registrar Transfer Policy (http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm).

7. CONCLUSION

The answer fully covers all issues of Evaluation Question #28. The Applicant describes the proposed policies and procedures to minimize abusive registrations and use of domain names as well as other activities that might have a negative impact on Internet users. The Applicant will implement and publish on its website a single abuse point of contact and establish the respective Abuse Complaint Processing Procedure. Measures for removal of orphan glue records are proposed. To promote accuracy of WHOIS, the Applicant will implement relevant measures including authentication of registrant information to be complete and accurate at the moment of registration, regular monitoring of registration data, employing most advanced authentication methods and establishing policies and procedures to address domain names with inaccurate or incomplete WHOIS data. The Applicant will ensure Registrars’ compliance with contractual requirements regarding WHOIS accuracy, including spot checks and financial encouragement of Registrars. Malicious or abusive behavior, including unambiguous definitions of the phenomena of abuse in the TLD and procedures that will allow an efficient mitigation of potential for abuse in the TLD are defined. The Applicant will establish special Service Level Requirements for abuse resolution, including service levels for responding to law enforcement agencies’ inquiries and requests. The Applicant will exercise adequate controls to ensure a proper access to domain critical functions.

1. INTRODUCTION

The Applicant considers implementation of Rights Protection Mechanisms (RMP) in the applied-for TLD an essential means to mitigate abusive registration and use of domain names to minimize confusion among customers, damage to Internet users and problems for holders of intellectual property rights.

With the focus on protection of interests, needs and rights of the respective community, the Applicant aims at building reputation of a secure and reliable TLD. Having registered domain names in the applied-for TLD, holders of intellectual property rights will also enjoy additional opportunities to market their products and services for the target audience.

The Applicant shall take all necessary efforts to prevent illegitimate registrations and disputes on domain names in the applied-for TLD, and if they arise, to provide administrative mechanisms as a “low-cost” alternative to court proceedings or other mechanisms. Specifically, the Applicant shall do his best to ensure compliance with general principles of protection of intellectual property rights basing on applicable international standards and best practices. RPMs specified for community-based TLDs will be implemented or elaborated by the Applicant as well.

To this end the Applicant sees its main tasks as follows:
(i) To develop domain name policies and procedures to prevent and mitigate any violation of legal rights and minimize potential causes for disputes between registrants and rightholders;
(ii) To complement traditional judicial procedures with relevant dispute resolution procedures so that disputes concerning domain names in the applied-for TLD could be settled efficiently and at a low cost.

The Applicant will focus on the following three aspects of practices and procedures of domain names registration which are paramount from the perspective of protection of intellectual property rightholders:
- Registration policy;
- Aggregation and verification of registrant information;
- Alternative mechanisms of resolution of dispute on domain name registrations.

The Applicant will implement the RPMs approved and subject to further approval by ICANN and adhere to them. The Applicant shall also take into consideration other recommendations by ICANN, World Intellectual Property Organization (WIPO) and Association of European Trade Mark Owners (MARQUES) and apply the existing TLD Registries’ record of launching new TLDs and industry best practices.

In addition to such RPMs, the prospective Registry Operator may develop and implement additional mechanisms to discourage or prevent registration of domain names that violate or abuse a third party’s legal rights or to settle any issues related to registration policies established in the applied-for community-based TLD.

2. PRE-LAUNCH RPMS

In accordance with requirements established by ICANN (Specification 7 to the Registry Agreement), the prospective Registry Operator will implement each of the mandatory RPMs set forth in the Trademark Clearinghouse model, which may be revised by ICANN from time to time. The Registry Operator will not mandate that any owner of applicable intellectual property rights use any other trademark information aggregation, notification, or validation service in addition to, or instead of the ICANN-designated Trademark Clearinghouse.

To conduct Sunrise or Trademark Claims Services the Applicant shall use the database of Trademark Clearinghouse Service Provider determined by ICANN. The Applicant shall not violate but comply with limited charter of Trademark Clearinghouse Service Provider or any other document which will regulate the use of Trademark Clearinghouse database.

While providing Sunrise Service and Trademark Claims Service, and using respective Trademark Clearinghouse Service Provider’s services, the Applicant shall provide non-discriminating conditions to trademark holders not included into the Trademark Clearinghouse database. All trademark holders shall be granted equal rights. Inclusion in the Clearinghouse is not proof of any right, nor does it engender any legal rights. Failure to submit trademarks into the Clearinghouse should not be perceived of as lack of vigilance by trademark holders or a waiver of any rights, nor can any negative influence be drawn from such failure.

2.1. Sunrise Registration Services

The purpose of Sunrise Services is to give respective categories of rightholders an opportunity to register domain names in the applied-for TLD prior to launching registration for all potential registrants. The Sunrise contributes to prevention of abusive registrations and malicious use of domain names which misleads the Internet users (e.g. phishing), and protection of Intellectual properties rightsholders.

The Applicant shall develop and publish on its website Sunrise policies describing all conditions of domain names registration within the Sunrise period and Sunrise registration service provisions including Sunrise Eligibility Requirements (SERs) and Sunrise Dispute Resolution Policy (SDRP) prior the Sunrise process starts. The Applicant’s SERs shall comply with the requirements set forth in Trademark Clearinghouse model as well as with other policies and procedures developed by ICANN for new gTLD Sunrise processes. The Applicant shall incorporate Sunrise Dispute Resolution Policy (SDRP) in accordance with requirements stipulated in the Trademark Clearinghouse model. Under the SDRP, third parties can initiate challenge proceedings asserting that the domain name registration does not comply with the conditions of Sunrise policies. Sunrise policies will state that information provided by applicants seeking a sunrise registration must be true and accurate, and that the sunrise applicants must provide all data sufficient to document their respective rights. As Trademark Clearinghouse’s functioning has not been yet finalized and approved by ICANN, the Registry Operator adjusts available and approved by ICANN mechanisms to validate the Sunrise registrations.

The Sunrise Services will be provided within not less than 90 days. The Applicant may decide to extend this period. The Applicant assumes that Sunrise period shall consist of, at least, four phases:
Phase 1: for legislative, executive and judicial bodies of the Republic of Tatarstan, which may register a domain name coinciding with the full or abbreviated official name of the body after being transliterated to Latin (with the respective list to be compiled by the Registry Operator upon consultations with the Government of the Republic of Tatarstan).
Phase 2: for owners of trademarks registered in compliance with the Russian or international regulations who may register the domain name coinciding with the trademark, its transliterated version or its graphic representation.
Phase 3: for owners of registered regional mass media may register a domain name coinciding with the official name of the mass media source.
Phase 4: for members of regional public associations may register any domain names, but no more than 5 per registrant.

Within the Sunrise period the domain name registrations will be implemented for the term of 1 to 10 years, but not more than 10 years, at the same price as that of domain name registrations in Live period. Modifications, transfers or deletion of domain names will be prohibited for one year following Sunrise registration.

The potential registrants will submit their applications during the respective phases of the Sunrise period via ICANN-accredited registrars that have entered into the Registry-Registrar Agreement (RRA) with Registry Operator (hereinafter Registrars). All the Sunrise applications received will be treated equally. Following the Sunrise eligibility requirements for each Phase, the applications received will be subject to examination. Where there is only one application for a domain name, that domain name will be registered on that sole applicant’s name. Where there are two or more applications for the same second-level domain name the following procedures will be exercised:

Due notification will be sent to the respective applicants encouraging them to find consensus regarding rights to use the domain name. Where the agreement has not been reached, the competing applications will be sent to the auction. The prospective Registry Operator will choose an auction provider to organize and hold the auction. The domain name will be ultimately awarded to the candidate who was pronounced the winner of the auction. Detailed rules of auction procedure will be published on the Registry Operator’s website.

If within the Sunrise period a domain name similar to the one included in the Trademark Clearinghouse database is requested, the applicant and trademark holder(s) will be sent respective notices of Sunrise registration in accordance with the procedure and form defined by ICANN in Trademark Clearinghouse model.

If the Sunrise application check reveals that the requested domain name fails to comply with the Trademark Clearinghouse record or the domain name applicant is not the holder of asserted rights, due notification will be sent to the domain name applicant.

A domain name applicant shall confirm its possession of the respective rights necessary for sunrise registration and that information provided is true and accurate.

Upon their registration, second-level domain names may be challenged nonetheless. The respective procedure, known as the Sunrise Challenge Procedure, will be implemented either in line with a respective consensus policy to be adopted by ICANN, or, if ICANN fails to adopt such a policy and procedure, the Registry Operator will provide for the following reasons to challenge a domain name registration:
(i) at the moment of registration of the domain name by its registrant there has been no valid trade- or service mark registered on him; or
(ii) the registered domain name appears different, whether textual- or element-wise, from the given trademark or service mark registration elements, as prescribed by the Sunrise policies; or
(iii) the trade- or service mark registration which has served as a basis of registration of the domain name by its registrant appears not of national effect; or
(iv) the trade- or service mark has been recognized null and void, canceled or otherwise abandoned; or
(v) the trade- or service mark registration which has served as a basis of registration of the domain name by its registrant was not granted to the registrant before the cut-off deadline set by the Trademark Clearinghouse.

The procedure will provide for the party, which has acquired the domain name during the Sunrise registration, the right to be informed of the challenge and have a chance to build a substantiated defense with regard to the case, which should be brought for consideration of a neutral dispute resolution party.

2.2. Trademark Claims service

The Registry Operator will implement the Trademark Claims Service (hereinafter referred to as TCS) in full conformity with to-be-developed terms of access to the Trademark Clearinghouse. TCS will be provided for at least the first 60 days post-launch. Besides, the Registry Operator may provide TCS through the whole period during which the Trademark Clearinghouse service remain accessible and available.
A second-level domain shall be examined against the Trademark Clearinghouse’s database to make sure it does not have an identical match in the said database. Where such a match has been found, the prospective registrant will be issued an alert communication thereof, with a Trademark Claims Notice containing information about the potentially disputed trademark, its claimant and reference data that indicate the respective entry in the Trademark Clearinghouse database. Before the continuation of registration of the selected second-level domain name, its potential registrant will be required to attest that:
(i) he⁄she has been alerted that the selected domain name is a match to the trade- or service mark contained in the Trademark Clearinghouse database;
(ii) he⁄she has received and understood the said alert;
(iii) if registered and in use, the said domain name will not affect the rights of a respective trade- or service mark rights holder.
Should the potential registrant be willing to continue with registration of the said domain name, due notification will be send to the mark holder(s) as per the Trademark Clearinghouse database.

2.3. Other services

The Applicant will implement a special tool which will allow any party concerned to check whether the applications for the particular domain name has been submitted during Sunrise period. It will be designed as WHOIS-like web-based interface service, but will be available prior to open registration of the domain name. Whether the Sunrise application for the requested domain name has been submitted, the service will provide information about trademark name, trademark registration date, trademark registration country, trademark registration number or Trademark Clearinghouse Claim Identification, sponsoring registrar, potential registrant’s name and contact data.

3. POST-LAUNCH RMPS

3.1. RMP in Registration Policy

The Applicant will develop the Domain Name Registration Policy that will define rights and obligations of registrants of second level domain names in the applied-for TLD. The Registry Operator will require Registrars to incorporate these rights and obligations in their registration agreement (agreement between Registrar and registrant).

The Registration Policy will include, inter alia, terms and conditions to prevent potential conflicts which may arise between the domain name registrant and any third party. The terms of second level domain name registration will be a key element to minimize abusive registration and use which could affect not just the interests of Internet users and intellectual property right holders, but the reputation and credibility of the gTLD as well. These restrictions will allow excluding violations (at least decrease their level), and will help deter infringers. The terms and conditions will include:
(i) Domain name shall comply with the purpose and mission of the applied-for TLD;
(ii) Registrant shall submit a written commitment and warrants of usage of the domain name in compliance with the purpose and mission of the applied-for TLD.

Registrant is bound to present recommendations from two effective registrants in the TLD .TATAR. Moreover, to prevent abusive behavior, such as pharming the domain name, Applicant will implement DNSSEC technology and encourage registrants and Registrars to use this service.

To ensure compliance with the Domain Name Registration Policy and to mitigate its violations, the Applicant will develop Anti-Abuse policy and publish on its website the single abuse point of contact. Hence all interested parties will be able to submit thereto their claims on suspicious domain names registration and use in case of identification of abusive registrations and other activities that have a negative impact on Internet users such as phishing or pharming. In case of complaint of violation of intellectual property rights, the Anti-Abuse Team will notify the Registrar and registrant concerned for further consideration. For more details, refer to the answer to Evaluation Question #28.

3.2. Uniform Domain-Name Dispute-Resolution Policy (UDRP)

In accordance with the RAA, all ICANN–accredited registrars are bound to comply with UDRP and include respective requirements into their registration agreements. The Registry Operator will require all the Registrars entered into Registry- Registrar Agreement in the TLD to duly incorporate UDRP into the terms of second level domain names registration, as well.

The UDRP does not require the Registry Operator to be involved in the procedure. However, where it has become known to the Registry Operator that a Registrar has failed to comply with terms and conditions of RAA with regard to UDRP, while no legal action has been undertaken, for instance, in accordance with paragraph 4(k) (Availability of Court Proceedings) of UDRP, the Registry Operator has the right to take reasonable steps to discontinue the non-compliance and seek the opportunity to penalize the Registrar that violated the procedure in accordance with its sanctions as per the answer to Evaluation Question #28.

The Registry Operator will take possible actions on any notifications⁄requests sent by ICANN personnel indicating Registrar’s non-compliance with ICANN policies and requirements.

3.3. Uniform Rapid Suspension (URS)

The Registry Operator will receive respective URS notifications, promptly respond to them and ensure its contribution to suspension of second level domain names, as per the ICANN policy. The Registry Operator will require all the Registrars to duly incorporate URS into the terms of second level domain names registration agreements, as per RAA.

Where it has become known to the Registry Operator that a Registrar has failed to comply with terms and conditions of URS, while no legal action has been undertaken, the Registry Operator will re-assign the domain name concerned to a compliant Registrar with whom the claimant has established an account and seek the opportunity to penalize the Registrar that violated the procedure in accordance with its sanctions as described in the answer to Evaluation Question #28.

While enforcing compliance, the Registry Operator will consistently follow the practice of ensuring a high-quality, reasonably-priced and competent URS evaluation and remedying by outsourcing this mission to an outside URS service provider.

The Registry Operator will take possible actions on any notifications⁄requests sent by ICANN personnel indicating Registrar’s non-compliance with ICANN policies and requirements.

3.4. Post Delegation Dispute Resolution Policy (PDDRP) and Registry Restriction Dispute Resolution Procedure (RRDRP)

The Applicant will observe and implement the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and Registry Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN. The Applicant agrees to implement and adhere to any remedies ICANN imposes following determination by any PDDRP or RRDP panel and to be guided by any such determination.

3.5. Trade or Service Mark Disputes

Where a second-level domain name has become subject to a dispute and such a dispute is brought for settlement before and by the court of law, and the Registry Operator has been made a party to the trial, the Registry Operator will continue being eligible for producing any and all claims and defenses at its possession. The Registry Operator will employ all legitimate and reasonable means and methods not to become involved in the trial as a party where the dispute over the purportedly infringed or infringing second-level domain name is recognized as being subject to the contest between the claimant and the registrant.

The Registry Operator shall honor, in good faith and in an expedited manner, verdicts, orders, exigencies, notices with regard to the disputed second-level domain names by the courts of respective instances where such courts exercise their powers and rule by law of the Russian Federation. Where a dispute over a domain name is considered by a court of law of a jurisdiction other than the Registry Operator’s, the Registry Operator will seek a qualified legal counseling with regard to the trial on the issue and shall satisfy a judgment on the disputed domain name, including but not limited to, submission of a certificate of control, where the trial takes places in the USA and under the United States Anti-Cybersquatting Protection Act or legal acts successive to it, which may stand as a reason for the court to rule that the domain name shall be alienated. The Registry Operator will comply with such verdicts to the extent it is not made a party to the trial, nor an object of the verdict. With the exception of the above, the Registry Operator will use its legal right to defend itself in the court or to resolve a potential dispute by any other legal means per law of the Russian Federation.

Where, as stipulated in UDRP or URS, the trial arises in the Mutual Jurisdiction, the Registry Operator shall lock the disputed second level domain name and ensure it remains locked through the whole period of trial and until the Registry Operator is in receipt of a verdict on the case from the court of law.

In all other instances, where a lawsuit has been brought to the court of law with respect to a second-level domain name in the TLD operated by the Registry Operator and the court of law duly notifies the Registry Operator thereof, the disputed domain name shall be locked by the Registry Operator through the whole period of litigation in courts of all instances whose jurisdiction extends to the registrant of the disputed domain name, or its Registrar, or the Registry Operator’s jurisdiction, or, where the trial takes place in the USA, upon the Registry Operator’s legal counselor in the USA.

3.6. Illicit Violation Issues

Where the Registry Operator is named a defendant in a trial on criminal infringement matters, the Registry Operator will honor, in good faith and in an expedited manner, verdicts, orders, exigencies, notices by the court of law in the Russian Federation as the Registry Operator’s jurisdiction. Where a lawsuit on criminal infringement has been brought against the Registry Operator in the USA, the Registry Operator will authorize its legal counselor to act on its behalf to ensure a full compliance with the court’s directive, but will retain all legal means and methods to defend itself in the trial.

3.7. Similarity Watch Service

The Registry Operator will operate watch service available for legitimate subscribers thereto. The service will provide an indispensable tool to receive periodical update notifications of new domain registrations containing a certain combination of characters which may raise the subscriber’s concern. In other words, any right holder will be able to monitor words and their combinations which, if registered, can infringe upon his⁄her legal rights. The service is for information purposes only. The service’s notifications do not alert that domain name containing certain combination of characters selected by the subscriber is or is not infringing on any legal right.

That said, where need be, the Registry Operator will be keen to design and implement, within limits of its competence and where the situation requires so, any additional reasonable methods and tools to ensure the right holders’ interests are protected in the course of preparation and launch of registration of second level domain names.

3.8. Additional RPM Tools

(i) Zone File Access.
According to the Zone File Access Agreement (Specification 4 to the Registry Agreement), the Registry Operator will grant third parties, such as commercial registration watch services providers, access to the zone file to have the intellectual property enforcement community enjoy the respective service and duly protect the holders’ rights.

(ii) WHOIS Extended Search
The Registry Operator will be at pains to deploy an efficient WHOIS search service as an extra instrument providing information about domain names and registrants in accordance with Specification 4 to the Registry Agreement (for details refer to the answer to Evaluation Question #26). This information may be helpful while an investigation with the aim to identify whether a registrant is involved in cybersquatting activities is conducted.

(iii) WHOIS Integrity
The Registry Operator will put WHOIS database to regular checks for its integrity and will ensure Registrars’ prompt respond to alerts received from the WHOIS Data Problem Report System. Where it has become known to the Registry Operator that the Registrar has failed to adequately respond to such or a third party’s alerts, the Registry Operator will immediately open an investigation into the case, which may result in suspension or cancellation of the domain name registration and sanctions against the Registrar (for details, see the answer to Evaluation Question #28).

(iv) Abuse Point of Contact
With reference to the answer to Evaluation Question #28 infringement of intellectual property rights or other rights will be enumerated as abuse complaints with respective case opening in the Trouble Ticket Management System and processes, with due notifications being channeled to the relevant Registrar and the registrant per the WHOIS database. The abuse complaint form will comprise references to mechanisms of enforcement of the above rights, including UDRP, URS and WHOIS Data Problem Reporting System.

4. RESOURCING PLANS. PERSONNEL

The Applicant has identified specific functions and tasks related to RPM processes and has assigned personnel to ensure their fulfillment:

(i) Legal work. The Applicant will engage the lawyer with a proven and extensive record of legal counseling and representation on matters pertaining to the Internet, to act both as a counselor and analyst to deal with legal challenges that may arise with respect to a court or a law-enforcement’s agency action or ruling which require their attention.
The key tasks will include:
- development of RPM – related policies and procedures;
- counseling;
- ongoing analysis of best practices with regard to RPMs and recommendations on improvements and new mechanisms.
(ii) Customer Service Group will provide counseling to Registrars (including prospective ones) regarding the RPM procedures and mechanisms.
(iii) The Anti-Abuse Team will receive and process abuse complaints, as described in the answer to Evaluation Question #28.

5. CONCLUSION

This answer demonstrates technical and operational preparedness to address the problem of unqualified registrations and protection of third party’s rights. The Applicant will implement both the Sunrise service and the Trademark Claims service. The Applicant has necessary capacity and means to implement URS, UDRP and other dispute-resolution mechanisms as well as has designed the set of legally binding instruments to ensure Registrars’ compliance and, in so doing, built an effective system of indirect control over registrants’ compliance, too. The above means, actions and instruments have been incorporated into technical, technological, organizational and operational procedures and policies in the applied-for TLD. The mechanisms of rightholders’ protection are embodied into operational procedures and legally binding documents with third parties. The applied-for gTLD offers registrants efficient mechanisms to check for potentially unqualified registrations. The procedures, mechanisms and instruments employed to buffer rights holders from infringement appear coherent and comprehensive enough to exceed the bounds of the requirements set forth for the Applicant for the new gTLD.

1. SECURITY POLICY IS A FUNDAMENTAL DOCUMENT ENSURING PROTECTION OF THE REGISTRY SERVICE PROVIDER’S INFORMATION

The policy is developed by IT-security department and approved by the CEO of the Registry Service Provider.

The policy is developed in accordance with effective national standards, law and mandatory information security regulation and procedures:
- ISO⁄IEC 27001:2005, ISO⁄IEC 27002:2005, ISO⁄IEC 27005:2005, ISO⁄IEC 17799:2005, ISO⁄IEC 15408, site – www.iso.org;
- FIPS PUB 199, site - csrc.nist.gov;
- GOST R ISO⁄MEK 27001, GOST R ISO⁄MEK 17799, GOST R ISO⁄MEK 13335-3-2007, GOST R ISO⁄MEK 15408, site - www.gost.ru;
- BSI-Standard 100-3, site - www.bsi.bund.de;
- Federal law of the RF No 152 ‘On personal data’ of 27.07.2006, site - www.duma.gov.ru;
- Federal law of the RF No 149 ‘On information, information technologies and protection of information’ of 27.07.2006, site - www.duma.gov.ru;
- Federal law of the RF No 126 ‘On communications’, site - www.duma.gov.ru.

2. THE SECURITY POLICY SPECIFIES LEVELS OF THE REGISTRY’S INFORMATION SECURITY:

Security level 1. RISK ASSESSMENT AND TREATMENT;
Security level 2. SECURITY POLICY;
Security level 3. ORGANIZING INFORMATION SECURITY;
Security level 4. ASSET MANAGEMENT;
Security level 5. HUMAN RESOURCES SECURITY;
Security level 6. PHYSICAL AND ENVIRONMENTAL SECURITY;
Security level 7. COMMUNICATIONS AND OPERATIONS MANAGEMENT;
Security level 8. ACCESS CONTROL;
Security level 9. INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT AND MAINTENANCE;
Security level 10. INFORMATION SECURITY INCIDENT MANAGEMENT;
Security level 11. BUSINESS CONTINUITY MANAGEMENT.

Security level 1. RISK ASSESSMENT AND TREATMENT

The level is implemented organizationally. A threat model is developed with account of peculiarities of the WHOIS service, EPP service, DNS service, NTP service, Data escrow service, system and network architecture. While detecting or predicting threats to protected assets the Registry Service Provider evaluates the probability of their implementation using all available means including engagement of specialized organizations. The Applicant acts for the benefit of registrants and all other participants in the registration system. Evaluation of probability of threats implementation and degree of their impact on the registration system is performed on the basis of a methodology allowing comparable and reproducible results;

A particular ‘Information risk management policy’ is applied.

Security level 2. SECURITY POLICY

The level is implemented organizationally. The Security Policy of the Registry Service Provider and a set of private Security Policies are developed. The Security Policy of Registry Service Provider is approved by the CEO of the Registry Service Provider.

Security level 3. ORGANIZING INFORMATION SECURITY

The level is implemented organizationally. Control over implementation and deployment of information security is assigned to a specialized structure subdivision – IT security department. The applicant is obligated to periodically (at least twice a year) run the internal audit of effectiveness of means of information protection in use. At least once in two years, an independent specialized organization shall inspect and review the policy implementation. In accordance with the ‘Security audit policy’, employees of the IT security department regularly carry out checks and tests of information security system including those of software and hardware means, and firewall policies.

The following specific policies are applied:
- ‘Security system documentation management policy’
- ‘Security management duties allocation policy’
- ‘Security audit policy’;

Security level 4. ASSET MANAGEMENT

The level is implemented organizationally. An identification and classification procedure has been performed. A regular inventory of resources is provided for. Owners of all resources such as servers, network equipment, software, databases are specified. The resource owner is responsible for its duly protection. The resource owner, is as a rule, a manager of the subdivision responsible for maintenance of the registry service, within which the given resource is mainly used.

Information assets are split into different categories. The classification of information assets is based on provisions of FIPS PUB 199.

A particular ‘Asset categorization (classification) policy’ is applied;

Security level 5. HUMAN RESOURCES SECURITY

The level is implemented organizationally. Measures to verify candidates for the job are carried out. The employee enters into a confidentiality agreement (NDA). Measures of periodical control are provided for.

A specific ‘Personnel security policy’ is applied.

Security level 6. PHYSICAL AND ENVIRONMENTAL SECURITY

The level is implemented organizationally in combination with technical means. The Network Operation Centers, registry nodes, DNS nodes, network equipment are located in protected data processing centers, which have an established security perimeter with respective protective barriers and access control mechanisms. They are physically shielded from an unauthorized access, damage and intrusion.

A specific ‘Physical Security Policy’ is applied.

Security level 7. COMMUNICATIONS AND OPERATIONS MANAGEMENT

The level is implemented organizationally in combination with technical means. The procedures of management and maintenance of technical systems providing the WHOIS service, EPP service, DNS service, NTP Service, Data escrow service, communication networks and security provision system operations are developed. If service is outsourced control over the necessary level of security is performed. The procedures of planning, protecting from malicious software (viruses), backup, network security management, data carrier turnover, information exchange, monitoring of information handling operations (access logs management and review, etc.) are carried out. The distributed architecture of the registry, together with the use of two completely interchangeable and geographically distributed co-active SRS nodes, ensures a safe storage and backup of EPP, WHOIS services information, registrar data and secondary DNS information. SSH is used to transfer data between primary and standby database that it connects via secure channel via L2 link. In accordance with the ‘Network security policy’ and ‘Security audit policy’ the regular checkups of firewall configuration and log files are carried out.

The following specific policies are applied:
- ‘Anti-virus protection policy’;
- ‘Internet Security Policy’;
- ‘Backup policy’;
- ‘Performance management policy’;
- ‘Network security policy’;
- ‘Data carrier use policy’;
- ‘Equipment authorization policy’;
- ‘Policy of monitoring, audit and registration of information security events’;
- ‘Policy of control over the data handling in systems’.

Security level 8. ACCESS CONTROL

The level is implemented organizationally in combination with technical means. The policies of control of access to the registry services are developed for the following participants in the system: TLD Registry Operator, Registry Service Provider, Registrars and Registrants. The technical means of access control built into the registration system services require password authentication, SSL certificate and use firewalls to set restrictions of access at the network level.

The following particular policies are applied:
- ‘Access Control policy’;
- ‘Account management policy’;
- ‘Password use policy’.

Security level 9. (INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT AND MAINTENANCE)

The level is implemented organizationally in combination with technical means. Registration system services such as the WHOIS, EPP, Secondary DNS service, NTP service, Data escrow service and others are supplied with built-in security provision mechanisms. The system security requirements were taken into account at the design and implementation stages. Solutions of the leading manufacturers such as Oracle, Cisco, HP are used.

The following particular policies are applied:
- ‘Cryptography and Key Management Policy’
- ‘Information system change management policy’
- ‘Instrumental analysis and vulnerability management policy’
- ‘Update management policy’.

Security level 10. INFORMATION SECURITY INCIDENT MANAGEMENT

The level is implemented organizationally in combination with software and hardware means of monitoring and notification system. The policies and procedures of response to information security incidents are developed.

A specific ‘Incident Response and Management’ policy is applied.

Security level 11. BUSINESS CONTINUITY MANAGEMENT

The level is implemented organizationally in combination with technical means. The registry architecture (described in the answer to Evaluation Question 32) ensures a fault and accident resistance. In combination with the backup system, data escrow system and DNS distributed system, the registry system ensures a steady and continuous technical support of business process. Business continuity support process is developed and maintained to meet the information security requirements pursuing the goal of ensuring continuity of the organization’s business. For the registry’s continuity this aspect is considered in a greater detail in the answer to Evaluation Question 39.

A specific ‘Business continuity support policy’ is applied.

3. THE SECURITY POLICY SPECIFIES DUTIES FOR THE PARTICIPANTS IN THE SHARED REGISTRATION SYSTEM (SRS): REGISTRY SERVICE PROVIDER, REGISTRY OPERATOR, REGISTRARS AND REGISTRANTS

(i) ensuring confidentiality of information in the SRS, including but not limited to:
- authentication data;
- Registrants’ personal data;
- other registration data which are not in public access;

(ii) ensuring integrity of information in the SRS, including but not limited to:
- registration data;
- authentication data;
- Registrants’ personal data;
- other data necessary for the registration system’s operation;

(iii) ensuring availability of information in the SRS, including but not limited to:
- registration data published via the WHOIS service;
- registration data disseminated via the DNS service;
- NTP service data;
- EPP service data;
- data using for the data escrow deposits;
- other data necessary for the SRS operation.

The obligation to ensure confidentiality means that the Registry Service Provider warrants unavailability of the registry’s information or nondisclosure of its content to unauthorized persons, subjects or processes.

The obligation to ensure integrity means that the Registry Service Provider warrants accuracy and completeness of the registry’s information.

The obligation to ensure availability means that the Registry Service Provider warrants the possibility to use the registry’s information where necessary.

4. SPECIAL INFORMATION SECURITY CONTROL AND MANAGEMENT MEASURES

In addition to the Security Policy’s information security levels the Registry Service Provider introduces four groups of special security control and management measures.

Group 1. Prevention of information incidents

Control identification of Registry system is multilayer.
As to registrars, within the given group the Registry obligates the registrar to employ the following measures:
- In compliance with RRA terms, the registrars are obligated to check passwords used by registrants to manage their domain names for complexity.
- To provide protection from an unauthorized access to domain name management on the part of third parties, the Registry Operator also plans to stimulate the employment of client certificates both in web-interfaces and in electronic documents. The Registry Operator believes that this instrument has a considerable potential for an efficient protection from the perspective of domain name management.
- The registrar is obligated to provide the registrant with access to domain name’s management within web-interfaces granted by the registrar over HTTPS protocol.
- To perform the critical operations with the domain (such as domain transfer to another registrar for maintenance, domain deletion, re-registration), the registrar is obligated to notify all the contact parties concerned (registrant, administrative and technical contacts) of exercise of these operations. The registrar is also obligated to include into the given notifications information on who one should turn to if the performed operation has not been authorized by the registrant.
- The registrar is obligated to install technical restrictions with regard to checking on steadiness and safety of passwords used by registrants to access the management of domain. The registrar is also obligated to alert the registrant and his contacts of the responsibility for adherence to password storage safety requirements.
- The registrar is recommended to install technical restrictions for registrants with regard to compulsory use of only automatically generated passwords to access domain management.
- To ensure security an access limitation is introduced for registrars receiving the registry services by indication of the end list of IP addresses for each contractor.

Group 2. ‘Detection’ –measures are undertaken to early detect incidents which have arisen in spite of preventive measures

Detection of early signs of DDOS attacks by employing special methods.

Group 3. ‘Limitation’ –measures are undertaken to reduce losses even where the incident occurred in spite of preventive measures

For example, independent ACL for each components of registry system, backup procedures, distributed Registry Operator’s architecture. For details, see the answers to Evaluation Questions #37 and #38.

Group 4. ‘Recovery’ – a full and timely information recovery is ensured

For example, the situation of a SRS failure can occur. The complete failure of the registration system, for instance, can result from a data deletion on the primary and standby database servers. Should that happen, the data recovery from the backup is carried out. Because the database archive redo logs backup is constantly performed, the data version immediately preceding the time of the failure can be recovered. Applications of any domain operations should be forbidden for f the duration of the database recovery from the backup.

In details see answers to Evaluation Questions #37 and #41.

5. In 2011 the ‘Group IB’, a Russian NGO company, rendering comprehensive consulting services with respect to investigation of information security incidents, completed an independent evaluation of information security support of the Registry Service Provider’s system. According to the report the following processes and procedures are in need for improvement:
- for any new components of registry system should be assigned ACL;
- interaction and collaboration with professional associations and expert forums in the sphere of security should be broadened;
- regulations specifying rules of acceptable asset use should be supplemented;
- the assets management policy and respective procedures should be supplemented with the need to obtain permission for an assets transfer and recording of facts of assets transfer and their return therein.

In accordance to the approved 2012 Registry Service Provider’s development plan an audit of the information security management system for compliance with requirements of international standard ISO 27001:2005 will be carried out in the IV quarter of 2012.

6. THE TECHNICAL SOLUTION OF THE INFORMATION PROTECTION SYSTEM IS BASED ON COMBINATION OF THE FOLLOWING SUBSYSTEMS:
- firewall subsystem;
- access control subsystem;
- antivirus protection subsystem;
- cryptographic protection subsystem;

The IT security department periodically evaluates internal normative regulations for their effectiveness and consistency and maintains the said documents in actual status.

7. DESCRIPTION OF THE ORGANIZATIONAL STRUCTURE OF INFORMATION PROTECTION

The functions of organizing the information protection process are assigned to IT-security department. More details on the organizational structure are given in the answer to Evaluation Question #30(b).

The research and development department is responsible for ensuring information security of the SRS⁄WHOIS⁄DNSSEC⁄ Billing systems.

The network infrastructure department is responsible for ensuring information security of the IP and Ethernet infrastructure.

8. INFORMATION SECURITY MEASURES IN THE REGISTRY SERVICE PROVIDER’S INFORMATION SYSTEM

Information security measures in the Registry Service Provider’s information system include:
- classification of the information system;
- specification of security threats to protected information during its processing in the information system;
- development of a specific threat model related to a concrete information system;
- development of a protection system on the basis of the specific threat model, which ensures neutralization of envisaged threats with the use of protective methods and ways provided for the respective class of information system.
- type classification of the information system was made on the basis of a threat model;
- deployment and implementation of protective means in accordance with the operational and technical documentation;
- staff training on operation with the protection means used in the information system;
- control of the used protection means, operational and technical documentation thereto and carriers of protected information;
- control of employees accessed to work with protected information in the information system;
- control over compliance with the terms of use of information protection means per the operational and technical documentation;
- investigate facts of inappropriate usage or violation of usage of protection means, which may lead to breaching the confidentiality of information or other kinds of erroneous moves decreasing the level of information security, to develop and implement measures on prevention of possible dangerous consequences of such failures from happening.

Alexander Elizarov	Chief Executive Officer
Guzel Mukhametova	Chief Accountant

GAU ʺTechnopark in the sphere of high technologies ʺIT-parkʺ	Not Applicable
GUP ʺCentre of information technologies of the Republic of Tatarstanʺ	Not Applicable

New gTLD Application Submitted to ICANN by: Limited Liability Company ʺCoordination Center of Regional Domain of Tatarstan Republicʺ

String: tatar

Originally Posted: 13 June 2012

Application ID: 1-1664-2308

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

8(c). Attach evidence of the applicant's establishment.

9(a). If applying company is publicly traded, provide the exchange and symbol.

9(b). If the applying entity is a subsidiary, provide the parent company.

9(c). If the applying entity is a joint venture, list all joint venture partners.

Applicant Background

11(a). Name(s) and position(s) of all directors

11(b). Name(s) and position(s) of all officers and partners

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility

Applied-for gTLD string

13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

14(a). If an IDN, provide the A-label (beginning with "xn--").

14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.

14(c). If an IDN, provide the language of the label (in English).

14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).

14(d). If an IDN, provide the script of the label (in English).

14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).

14(e). If an IDN, list all code points contained in the U-label according to Unicode form.

15(a). If an IDN, Attach IDN Tables for the proposed registry.

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.

15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.

16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).

Mission/Purpose

18(a). Describe the mission/purpose of your proposed gTLD.

18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

18(c). What operating rules will you adopt to eliminate or minimize social costs?

Community-based Designation

19. Is the application for a community-based TLD?

20(a). Provide the name and full description of the community that the applicant is committing to serve.

20(b). Explain the applicant's relationship to the community identified in 20(a).

20(c). Provide a description of the community-based purpose of the applied-for gTLD.

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

20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.

20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).

Geographic Names

21(a). Is the application for a geographic name?

Protection of Geographic Names

22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD.

Registry Services

23. Provide name and full description of all the Registry Services to be provided.

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

30(a). Security Policy: Summary of the security policy for the proposed registry

© Internet Corporation For Assigned Names and Numbers.