Application number: 1-975-59500 for Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)

Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)

2, Prospekt Marshala Zhukova
MOSCOW 123308
RU

+7 495 789 82 07

+7 495 7377673

http:⁄⁄www.faitid.org

Mr. Jonas Bylund

Application Manager

+32 2 234 6320

+32 2 234 7911

faitid-app@sedari.com

Mr. Sergey Gorbunov

Head of International Relations Department

+7 495 789 8207

+7 495 737 7673

s.gorbunov@faitid.org

Not for profit organisation

Russian Federation Ministry of Justice under Presidentʹs decree No. 1313 dated October 13, 2004 ʺIssues of the Ministry of Justice of the Russian Federationʺ

Not Available

Alexander Panov
Board Member of FAITID
Dmitry Burkov
Chairman of the Board of Directors of FAITID
Pavel Khramtsov
Board Member of FAITID
Vasiliy Dolmatov
Board Member of FAITID

Alexander Panov
President of FAITID
Anastasia Ponomareva
Chief Financial Officer of FAITID
Matvey Alexeev
Deputy Director of FAITID

MOSCOW

Not Available

There are no known issues, specific operational or rendering issues with the applied for string. It is a Latin alphabet-based string that conforms to the specifications laid out in RFC 1035.
As with all new TLDs there is the potential for legacy applications to fail to recognize the new TLD string. Some older applications may have hardcoded lists of ʺvalidʺ TLDs or, worst case, assume anything that isnʹt ʺ.comʺ, ʺ.netʺ or ʺ.orgʺ is not valid. There are existing initiatives, including The Public Suffix List operated by the Mozilla Foundation, which we will work with to help educate the broader Internet community.

This gTLD is a volume related top-level domain that will sell names at the second-level.

It will reserve some names at the second-level for public-facing entities or entities that perform services for the public, including but not exclusively governmental bodies, and populate the related third-level free of cost.

FAITID is applying for two related but independent strings: .MOSCOW and the Cyrillic version of .MOSCOW (.МОСКВА). These strings are economically independent and separate financial modeling and projections have been developed for each string. Conceptually, the two strings are related to the extent that they relate to the same word expressed in English and in Cyrillic.

Mission 

Creation of opportunity and content: the new gTLD will provide new opportunities for Internet users to create Moscow-associated content. 

Branding for Moscow: the gTLD will make the city more visible on the Internet and help to create its online brand.

Example to others: as the first city domain in Russia, the gTLD will serve as an example for other Russian cities. Other Russian cities have already expressed their potential interest in emulating this model to create their own city gTLD. 

Mission In Context 

ICANN has set out a number of goals regarding the introduction of new generic top-level domains (gTLDs). Among the most important of these are the following:
o the need to maintain the Internetʹs stability, and especially the protection of domain name holders from the effects of registry or registration system failure;
o the extent to which approval of the application would lead to an effective proof of concept concerning the expansion of the number of top-level domains including:
- the diversity the proposed TLD would bring to the top-level of the Internet to include fully open top-level domains, restricted and chartered domains with limited scope, commercial domains and personal domains;
- support of a variety of business models and geographic locations.
o the enhancement of competition for registration services at the registry and registrar level;
o the enhancement of the utility of the DNS;
o the extent to which the proposal would meet previously unmet needs;
o the importance of appropriate protections of the rights of others, including intellectual property rights in connection with the operation of the TLD, especially during the start-up phases.

Purpose

The purpose of this TLD is to:
o advance the goals of ICANN as set out above;
o fulfill the TLDʹs mission as stated above.

i. Goal In Terms Of Specialty, Service Levels Or Reputation

Definitions

Registrants: registrants include all those who register a domain name in the TLD and who act in accordance with the stated user policies.

Users: users include the broader Internet community of users who interact with the TLD.

Others: others whose interest is relevant to this application include regulators, policy makers and other public authorities.

Specialty

The team operating the TLD brings considerable speciality experience in the Internet industry in relation to high-level policy development, launch, operation and management. Significant marketing resources together with registrar partnerships and technical facilities, enable FAITID to specialise in the provision of a competitive open top-level domain that provides a genuine alternative to existing TLDs and opens the top-level of the Internet to new users. 

Focus on Moscow: the local market is currently largely served by .RU and Cyrillic .РФ country codes. The proposed new gTLD will enable particular focus on the city of Moscow as opposed to the entire country of Russia. Registrants in the gTLD will be communicating an explicit association with the Russian capital. This will help attract users towards their websites. Thus websites under the gTLD could become an additional business tool for the online presence of Moscow companies. FAITID is applying for both .MOSCOW and the Cyrillic equivalent .МОСКВА. FAITID considers these two domains as complementary services that could be inter alia offered as a package at a special price. Users will benefit from a better focus and search facility of Moscow-related websites.

Economic stimulus: the gTLD implementation will stimulate the start of new Internet projects and consequently the development of Internet technologies in the city of Moscow. FAITID anticipates associated benefits and synergies, including the overall enhancement of investment in Moscow. 

Charitable re-investment: TheLlandrush application window will start with high domain registration cost that will be reduced in a step-by-step way and at the start of General availability will become standard. By organizing Landrush in this manner the most valuable names will be allocated in a transparent and fair way. A major portion of the Landrush proceeds resulting from contested names will go to a charitable fund to assist Internet-related projects in the Moscow area. 

Service Levels

In order to advance its mission as stated above, FAITID has brought together a team with expertise, experience and technical capacity to ensure that the TLD is operated to the best industry standards in the provision of services. FAITID will provide a substantial network infrastructure that can guarantee maximum performance and reliability as well as scale seamlessly to meet variations in demand. 

FAITID domain name registry services will be driven by customer focus, technological innovation and channel management expertise. The creativity and participation of the online community are important drivers of the services provided by FAITID. FAITID is mindful of the critical importance of confidence in the operation of the Internet. It is core to the application to be a registry that is a leading model for Internet innovation and development.. 

Reputation

FAITID is concerned to ensure that both the reputation of the TLD as well as the reputation of the Internet generally is enhanced by this delegation. 
 
FAITID takes the view that its responsibility as a registry extends beyond registrants and users of the Internet, to potential users, governments, regulators, policy-makers and communities at large. To this end, FAITID has a Board of Trustees with representatives of government, law enforcement bodies and public organisations. The Trustees maintain an oversight role with a specific mandate to represent the public interest.
 
ii. Added Competition, Differentiation, Innovation

Competition 

The relevant market is currently served largely by the .RU and Cyrillic .РФ country codes. The new gTLD will provide additional opportunities for registrants and users for Moscow-related websites. This will eventually make the Russian domain market itself more competitive. .MOSCOW will become an alternative to .RU for registrants who would like to get an ASCII name for placement of Moscow-related content. At the same time .МОСКВА will become an alternative to .РФ for registrants who would like to get a Cyrillic name for placement of Moscow-related content.

Differentiation

.MOSCOW and .МОСКВА gTLDs will provide differentiation from the TLDs where Russians currently register. Currently, registration is either in undifferentiated generics such as .COM or the country-wide ccTLD of .RU or Cyrillic .РФ for Russia. 

The gTLD will also reserve a number of second-level names for use by public entities or entities that perform services for the public, but not exclusively governmental bodies. This will create a hierarchy for subsequent population at the third-level. Domain names of this type will also be reserved in Cyrillic under the Cyrillic .МОСКВА gTLD. This hierarchy is not available under existing TLDs. Examples of such second-level names are .MUSEUM.MOSCOW for .MOSCOW. and .ШКОЛА.МОСКВА (can be translated as .SCHOOL.MOSCOW) for .МОСКВА.

Innovation

The gTLD implementation will stimulate the start of new Internet projects and consequently the development of Internet technologies in the city. FAITID is committed to innovation by evolution, consistent with the overarching objective of a stable and secure Internet. By investing in new developments at the top-level of the Internet, FAITID is declaring itself to be an advocate for the goals of the Internet, for the city of Moscow and for the advancement of industry related to this innovation.

iii. User Experience Goals

Consistent with FAITID key goals to work co-operatively and positively in the provision and management of a vital public resource, FAITID aims to ensure that the user experience is centered on the following goals:
o rapid, responsive and reliable customer service;
o full accessibility; 
o robust neutrality; 
o robust data security and privacy;
o robust data escrow;
o Internet standards regarding naming and reserved names; 
o industry standard acceptable-use policy and registrar agreements;
o leading protocols on technology, anti-cybersquatting and WHOIS.

A key user experience goal is improved focus on where the user can find what they are looking for, as a result of greater geographic specificity and easier search. The second-level public sector hierarchy will further enhance the user experience. This hierarchy will be the result of reservation of names for entities at the second-level that will allow related third-level registrations to fall into a natural order beneath a specified category. FAITID has determined to reserve these names so that key public-facing services will have the opportunity to establish their presence in the domain and ensure that information of value to the public is searchable in a clear and reliable manner. 

iv. Policies To Support Goals of iii

General Registration Policy

In general names will be openly available on a first-come first served basis. FAITID will additionally provide an early launch period that gives preference to companies and organizations from Moscow, Russian Federation. No similar priority will be given to individuals. This preference will advance the utility of the TLD as a designated and defined location for the registrations with a clear connection to the city of Moscow.

Reservation and registration of sub-domains: reservation and registration of second-level domain names for the state needs will be done in order to protect the interests of governmental and municipal bodies, enterprises and organizations. The list of domains registered and reserved for this purpose will be composed in cooperation with Moscow Government.

Pre-registration reservation will be arranged on the basis of existing industry standards relating to reserved names. Reservation will be followed by Sunrise A where top-priority names registration will be given to trademark holders. 

A small number of domains such as .MUSEUM.MOSCOW and .THEATRE.MOSCOW will be reserved for further third-level registrations. A similar list will be implemented for Cyrillic .МОСКВА.

Third-level registration in these domains will then be available or allocated. An example of allocation is the reservation of .MUSEUM.MOSCOW which will, at the third-level, be intended for names for Moscow museums.

Telephone Hotline

 FAITID will establish its own or cooperate with an existing telephone hotline for complaints about abusive registrations and content, providing advice on dispute resolutions mechanisms and its own registration policies.

v. Privacy And Confidentiality Measures

Protection Of Privacy 

FAITID recognizes the importance of balancing individual privacy rights with the rights of intellectual property owners, law enforcement and other interested third parties to have access to WHOIS data for legitimate uses. Comprehensive privacy and authentication rules are built into the operation of the proposed gTLD consistent with requirements under the Registry Agreement. 

As privacy and confidentiality of personal information is a key element in the provision of a positive user experience, FAITID will take all reasonable steps to protect personal data from loss, misuse, unauthorized disclosure, alteration or destruction. FAITID will also comply, in accordance with the Registry Agreement, with all existing and future consensus policies as formally adopted by ICANN. 

FAITID will operate a WHOIS service in accordance with Specification 4 of the Registry Agreement and operate this service in full compliance with applicable privacy laws or policies. FAITID will also implement appropriate measures to avoid abuse of WHOIS in order that access is restricted to legitimate authorized users. As FAITID will only use ICANN-accredited registrars, the registrars will be required to implement the data privacy policies as defined in the Registrar Accreditation Agreement.

Outreach And Communication

Website

A promotional website www.domainmoscow.org has been live since September 2010. 

Signature Campaign

Via the website www.domainmoscow.org, a signature collection campaign was launched in September 2010 with a view to:
o setting up an informal gTLD launch-related community; 
o informing the target audience about the gTLD. 

Events

The gTLD is regularly presented at Russiaʹs important IT events (exhibitions, conferences and workshops).

Press And Media

An ongoing press and media campaign has resulted in good coverage in major Russian mass media including:
The Izvestia (30.09.2011, ʺThe Capital Tends to Be Equal to the State on the Internetʺ), The Vedomosti (30.09.2011, ʺMoscow Wants its Own Domainʺ), RBC TV channel (30.09.2011, ʺA .МОСКВА TLD Can Appear on the Internet for Moscowʺ), NTV (05.09.2011, ʺWebsites With ʺMoscow Registrationʺ May Appear on the Internetʺ), The Kommersant (21.06.2011, ʺThe Internet with Three Dots Markʺ), The Argumenty i Fakti (03.09.2010, ʺ.MOSCOW and .МОСКВА TLDs Will Appear on the Internetʺ), The Metro Russia (02.09.2010, ʺA TLD for Moscow Can Appearʺ).

Chamber Of Commerce

After delegation FAITID plans to work with the Moscow Chamber of Commerce to promote the gTLD to businesses as potential registrants. 

SME Organisation

After delegation FAITID plans to work with the trade-association Union of Moscow SMEs to promote the gTLD to businesses as potential registrants. 

i. Resolving Competing Applications

In relation to competitions that involve intellectual property, FAITID will minimise costs to consumers in protecting their intellectual property through the following mechanisms:
o implementation of the Schedule of Reserved Names set out in Specification 5 of the Registry Agreement;
o implementation and adherence to rights protection mechanisms that may be mandated from time to time by ICANN, including all mechanisms mandated in Specification 7 of the Registry Agreement;
o implementation in accordance with the requirements established by ICANN of each of the mandatory rights protection mechanisms set forth in the Trademark Clearinghouse;
o compliance with ICANN rules on dispute resolution mechanisms as they may be revised from time to time, including the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) when the final procedure is adopted;
o compliance with the Uniform Rapid Suspension system (URS);
o Sunrise registration services in accordance with the Registry Agreement; 
o a Notification service to trademark owners who have registered in the Trademark Clearinghouse that someone else is applying for a Sunrise registration for an exact match;
o a Trademark Claims service (for at least 60 days) to provide notice to potential registrants of existing trademark rights that are registered in the Trademark Clearinghouse (i.e. a warning to NOT register a name that might infringe).

Competing Applications - Landrush And General Availability 

The Applicant is dedicated to ensuring a fair opportunity for all users to register a domain name to which they are legally entitled:
o following Sunrise FAITID will operate Landrush to allocate premium names and in accordance with the general registration policies described above;
o at the close of Landrush, General Availability will start. This will be on a first-come first-served model; 
o expired names: the Registry believes that all domain name registrants should be on an equal footing in terms of securing an expired domain name. For this reason, certain expired names may be pooled for auction.

ii. Cost Benefits eg Pricing

Consistency With Existing Market Pricing

Pricing will be competitive for this market place. The gTLDs pricing policy will reflect the prevailing prices of the existing ccTLDs .RU and Cyrillic .РФ. 

Discounts For Registrants In Both New TLDs

As FAITID is applying for both .MOSCOW and its Cyrillic equivalent .МОСКВА, it plans to offer a special package price for registrants who register two names in both gTLDs at once.

iii. Price Increase Policy

There are no plans to increase prices in the first three years. After that the pricing policy will reflect local inflation rates as they affect the cost base.

No

Not Available

Yes

Note Spec 5 of Reg agreement
The TLD itself is a geographic name. The applicant does not intend to allow any second-level or subsequent level registrations that conflict with the geographic name reserve lists specified by ICANN.

Our various registry services fall into these categories: 
* Services to Registrars 
o Object Registration and Management (Extensible Provisioning Protocol (EPP) , Registrar Web Interface, Registrar Toolkit) 
o Notification, information, and documentation 
* Services to Registrants 
o Internationalized Domain Name (IDN) registration 
o DNSSEC 
o Publication of zone file data (DNS name servers) 
o Anycast management of replicated DNS servers 
* Services to the public 
o Classic WHOIS 
o Tiered access by registered and authenticated users 
* Maintenance services for the registry itself 
o Generation of zone files 
o DNSSEC signing of zone files 
o Dissemination of zone files 
o Zone file access
* Abuse Mitigation and Prevention
o Server protection strategies and mechanisms
o Abuse monitoring, recording, and analysis
o Security and Stability Operational Practices
* Registry Operations Center (ROC) 
OPERATIONS 
Registry Operations Team 
Registry operations are outsourced through JSC International Network Technical Center (INTC) to Internet Systems Consortium, Inc (ISC). 
About the International Network Technical Center
JSC International Network Technical Center (INTC) is a company providing the full range of services related to the support of Internet address space infrastructure.
The INTC team involves experts with considerable experience in building global computer networks, setting up Internet exchange points as well as implementing and operating computing infrastructure for top-level domains. 
INTC tasks include development of domain name registration systems and domain registries within the ICANN New gTLD program. INTC will ensure secure and reliable operation of new top-level domains.
INTC uses the most forward-looking solutions in the field of Internet technology and cooperates with the largest Russian and international companies and organizations.
Today, the key project of INTC is the development and maintenance of the technical platform for .MOSCOW and .MOCKBA TLDs registries. The project is being carried out in cooperation with the Foundation for Assistance for Internet Technologies and Infrastructure Development and with Internet Systems Consortium, Inc. (ISC) - the world leader in DNS software and service development. 

About Internet Systems Consortium, Inc (ISC)
Founded in 1994, ISC has been a vanguard in the growth and stability of the Internet. In addition to its better-known role as a technology leader and developer, ISC is one of the worldʹs most important organizations entrusted with management of Internetʹs essential infrastructures. From respected and prolific standards development for DNS, DNSSEC and IPv6; development and maintenance of the widely-used BIND and DHCP open source software; deployment and operation of critical global Internet services such as F-Root and SNS; to leadership in abuse prevention and mitigation strategies and tools, ISC is the worldʹs preeminent expert in the technology and operation of the Domain Name System. 
ISC operates the F-root server, one of the 13 root server complexes on the internet. ISC pioneered use of the anycast routing technology that allows DNS servers to be replicated to improve performance, reliability, and resistance to attack. Today the F-root has 59 anycasted instances that are globally distributed and strategically placed at highly-connected nexus locations. F-root instances are also installed in more remote regions around the world such as in Mongolia and Fiji. This diversity was specifically pursued to increase resilience and performance for small and remote developing countries. This anycast architecture has been adopted by other root server operators and also by many gTLDs and ccTLDs, including .com, .net, and .org. Since shortly after its founding in 1994, ISC has maintained 100% up-time for F-root, and today the servers that implement F-root handle approximately 25% of the Internetʹs root traffic. 
ISC provides other critical resources and services such as Secondary DNS for more than 50 ccTLD registries and non-profit organizations (including ICANN). ISC has long operated its own hosting facilities and provided hosting to key Internet open source projects such as Linux, Mozilla, FreeBSD, and the Internet Archive. 
As new needs arise, ISC continues to develop and offer new services to support an open and robust Internet. One such project is the Resiliency and Security Forum, which operates the Security Information Exchange (SIE). SIE provides summary or distilled feeds of combined global DNS activities in real time to qualified recipients, which enables a pro-active defense against cybercrime. Recently ISC was a participant in a public⁄private partnership with law enforcement agencies around the world to assist with the largest takedown of a botnet in history. 
ISC has one of the worldʹs largest operational deployments of DNSSEC. 
ISC and its people are widely trusted around the world. Of the 21 people worldwide (known as the Trusted Community Representatives, or TCRs) who are entrusted with the DNSSEC keys to the root zone, two are ISC employees and a third is a principle member of the Registry Operator.
Under such pedigree, ISC has developed the next-generation Registry Services Platform presented in this application. 
The Internet Systems Consortium is incorporated in the US state of Delaware, with employees in numerous countries around the world. 
Registry Systems 
Our systems are state-of-the-art and designed to meet the highest standards of TLD operational performance, reliability, scalability, and security. All components of the technical infrastructure for the registry have been built with 8 to 10 times the forecast capacity for our largest scenario of registration volumes. Thus, the capacity of the technical infrastructure is scaled at a level that covers the full range of projected volumes from ʺWorst Caseʺ to ʺBest Caseʺ without large or incremental capital costs for infrastructure and is easily scalable to higher volumes if required. 
The registry is built as several major subsystems, each of which, in turn, is implemented as a collection of subsidiary services. This way we can use the most appropriate technologies for each subsystem and service, to obtain flexibility and scalability while retaining security, robust resilience to load and attack, and high availability. 
Many of the major components of the registry system have been in use in commercial services on the Internet. The components that were developed specifically for Registry use have been carefully integrated with and tested with those existing components. 
Our registry protects registration data and performance levels across all of its information services. Our system engineers have put a major emphasis on design review, high-reliability engineering methodologies, and structured testing to ensure that consistency and referential integrity is maintained even in the event of a catastrophic incident. 
Every aspect of every module is designed and built to be robust, replicated, and recoverable: 
* Multiple data centers, with wide geographic diversity, that mutually support one another for backup and failover. 
* Hardware uses redundant elements such as power supplies, RAID storage, and Error Correcting (ECC) memory. 
* All network connectivity uses redundant interfaces, geographically differentiated pathways, and automatic fall backs. 
* User facing systems are all replicated with no single point of failure and automatic failover to a backup system. 
* Load balancing techniques are incorporated to prevent overload of any single user-facing component. 
* Firewalls are used to prevent most malicious traffic from even reaching registry systems. 
* All registrar and other non-public network service interfaces are protected by access lists, encryption, and authentication. 
* Public network service interfaces are protected by rate limiters that can be activated when needed. 
* Databases are built using an architecture employing master servers with hot standbys. 
* The database has been configured so that rigorous quality and consistency checks are automatically enforced throughout the lifetime of the data. 
* Database files can be backed up or moved without interrupting online services. 
* All systems are monitored 24x7x365 by a worldwide array of hardware and performance monitors backed by the Registry Operations Center (ROC). 
* The Registry Operations Center is backed by a worldwide staff that is ready to assist the operations staff or (in case of disaster) to take over its operation, all without interrupting user services. 
* Every transaction is time stamped and permanently logged in journals that can be used for audits or data reconstruction. 
* Data, systems, and operations are distributed so that no single event could cause an outage longer than a few seconds while transition occurs. Most systems would have no user perceived outages at all. 
The use of replication as a fundamental design element means that the system can scale and adapt in response to equipment, software, or network failures. 
SERVICES 
Object Registrations 
One of the principal objectives of any Internet Domain Registry is to manage the allocation, registration, and status of Internet Objects: Domain Names, Contacts, and Hosts (name servers). 
From the point of view of the registry, a Domain Name comes into existence when it has been registered by an accredited Registrar, there is no requirement of zone file appearance for a domain name to be considered as registered. This is clearly stated in RFC 5731 (section 3.2.1). To be eligible to be included in the TLD zone file, at least two name servers must be associated with the registered domain name. In other words, names that are registered but which do not have at least two name servers are not published into the TLD zone file. Whois data is published for a registered name whether or not that name is included in the TLD zone file. 
Contact information is managed as specified in RFC 5733. Our base requirement is that contact information be in English (US-ASCII). However, in order to allow local language communities to make full use of our registry we allow contact information in other languages and their characters sets. This provides the opportunity for fully localized contact or domain records, both of which show information in both English (US-ASCII) as well as the localized languages that might be required. 
Host Registrations 
Host registrations are subjected to a series of checks to prevent unauthorized creation of glue records. In the same manner, periodic audits are performed to detect and flag lame server delegations (name servers to which a domain has been delegated but which have not been configured to serve any data for that domain.) 
Host registrations are verified for compliance with RFC 953 and RFC 1035 and compliance with the restrictions related to IDN that have been explained elsewhere in this document. 
Periodic audits are performed on contact information to flag potentially inaccurate or incomplete information. 
Registrars are notified of suspect contact data via the messaging interfaces in the EPP protocol and our Registrar Web Interface. 
Blocked Name or ʺDesignated Resolver Nameʺ 
ʺBlocked Namesʺ are names which a trademark owner does not want to use but wants to prevent others from using. Blocked names are offered during Sunrise, and go through the same registration path as Sunrise names. With a ʺblocked name,ʺ however, the TM owner indicates in the Sunrise application that it desires a blocked name instead of a resolving name. The WHOIS for a blocked name looks like that of a Sunrise name. The registrant of a blocked name cannot change the nameservers. 
Receipt of Data From Registrars 
Our Back-end Registry Service provides ICANN-accredited registrars with a standards-based interface to perform domain registration operations. 
Registrars may use this service in two ways: 
* An Extensible Provisioning Protocol (EPP) interface. 
* A Registrar Web interface. 
Extensible Provisioning Protocol Interface 
Our platform implements the standard EPP protocol as described by RFC 5730. We also implement Internet Engineering Task Force (IETF) defined mappings for Domain Names (RFC 5731), Internet Hosts (RFC 5732), and Contacts (RFC 5733). Our EPP is carried over the TCP protocol (RFC 5734) and operates in dual stack IPv4⁄IPv6 mode. 
Strong security ensures that this interface may be used only by known entities that have been accredited by both ICANN and our Registry. Use of this secure Registry Service is tightly controlled at multiple levels: 
* Secure encrypted channels (TLS) using X.509 Certificate validation back to a known certificate issuing authority. 
* Dual static IPv4⁄IPv6 DPI Firewalls to filter out irrelevant and suspect incoming traffic. 
* Behavior and anomaly traffic monitoring using IPFIX technologies. 
* IPv4⁄IPv6 source address verification (IP address whitelists). 
* User authentication (user⁄password) at the application level. 
In conformance with standard gTLD registry practices, the Registry Service implements the DNS security extensions for the EPP protocol (RFC 5910), allowing registrars to include secure delegation points to DNSSEC signed zones. 
Similarly, the system incorporates Domain Grace Period Mapping (RFC 3915), to comply with TLD extended life cycles. 
To support Internationalized Domain Names (IDN), we use a custom EPP extension to specify the language tag in which the domain name has been coded, allowing the application of IDN registration policy as mandated by the TLD manager. 
Scalability and high performance are achieved through the use of multiple front-end servers, each running the EPP service. Each Front-end EPP instance is capable of querying multiple Back-end servers that, in turn, have access to a master database for read⁄write operations. In addition there are server and database replicas to support read-only operations (checks, info, etc.) and thus reduce the burden of the read-write database facility. 
With EPP, registrars can verify the result of each transaction and have confidence that the operations reported as successful have indeed been processed by the registry. 
We time stamp and log all EPP transactions for auditing, capacity planning, offline attack analysis, or forensic reconstruction. We retain these logs indefinitely and securely. 
Registrar Web Interface 
The Registrar Web Interface is designed to complement the EPP Interface, to provide Registrars with backup access to the registry in the unlikely event that its EPP clients are not functional. The Registrar Web Interface supplies a set of domain management functions of the EPP interface and also additional functionality not available within the EPP protocol itself. The Registrar Web Interface provides: 
* EPP services 
o Management of Internet Objects (domain, hosts and contacts) 
o Registrar notification messages 
* Financial balance checks and reporting 
* Operational and statistical reporting (including DNS server activity) 
* Problem and abuse reporting and tracking 
* Access to registry support services 
Access to the Registrar Web Interface is restricted using the same techniques used for the EPP Interface, which include Signed TLS Certificate, IP address white lists, firewalls, and authentication via login. 
Dissemination of TLD zone files 
DNS Service 
No matter how good the registration system, Internet users require that domain names resolve quickly and reliably. Our DNS service provides name resolution for all domain names in our registry. 
This registry was constructed on top of an already-operational worldwide publication⁄distribution system and network of name servers. These name servers employ IP-Anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and to give excellent response to widely geographically diverse clients. 
DNSSEC and IPv6 are already fully integrated into this network and its component servers. 
Our DNS publication system uses both scheduled and on-demand updates. When it is time to perform an update, the process starts by generating all needed certified zone files from the authoritative registry database. Candidate files are validated and checked for errors. 
Our system signs each zone with DNSSEC before distribution to the global network of publication servers. Those publication servers are the advertised DNS servers for these domains. 
Our DNS master servers compute the changes from the prior zone file and send secure incremental updates via our distribution system. Any lost updates are automatically healed by full-fetch refresh transactions initiated by the publication name servers themselves whenever conditions suggest, or even hint, that incremental synchronization has been lost. A full-fetch refresh can also be initiated by the Registry Operations Center. 
Every published zone is stored in a version control system. This allows us to compare zone data as it changes, for recovery, capacity planning, security monitoring, and forensic reconstruction. 
Zone File Access 
In accordance with ICANN requirements, all gTLD registries must offer a zone file access service through which one may download copies of the TLD zone file (as snapshotted once a day.) This service is offered only to registered users. The intent is to facilitate the work of companies, researchers, and individuals who are looking for evidence of malicious conduct. 
Eligible individuals and entities may apply for Zone File Access. Access credentials will be issued by the Registry. Those credentials permit controlled retrieval of the zone file images. 
Dissemination of contact or other information concerning domain name registrations 
Port 43 Whois: 
Port 43 Whois implements the RFC-3912 Whois protocol specification. This is the classic Whois - it provides public exact-match searches for Internet objects held by the registry. 
Our Port 43 Whois servers are geographically distributed in several locations. This improves user experience, performance, reliability, and load distribution. 
To prevent abusive behavior, our Port 43 Whois servers implement configurable per-IP rate-limiting controls. In addition, queries are logged for abuse detection, statistical analysis, capacity planning, and reporting. 
Tiered Access Searchable Whois: 
Tiered Access Searchable Whois begins where Port 43 Whois leaves off. 
Tiered Access Searchable Whois is a RESTful web service: The query is expressed as part of a URI that is sent by the user to the registry via secure HTTP (HTTPS) as part of a GET or HEAD operation. The default format for the response data is XML. Other formats (such as JSON) may be requested in the URI. 
In its basic mode a Tiered Access URI contains a simple match criterion on the name, as with Port 43 Whois. In searchable mode the URI contains search criteria such as partial-match and wildcard searches on the name and use of additional registration fields (such as creation date.) 
The searchable mode accommodates situations where customers or law enforcement require capabilities not provided by traditional Port 43 Whois. 
Both of these modes facilitate access by user-written software tools. The basic mode interface may be made available to the public. The searchable mode is available only to contracted, identified, credentialed users for lawful public benefit purposes and subject to an agreement to use the data only in compliance with applicable privacy laws and regulations. The searchable mode is also available, in accord with registry procedures, to law enforcement. 
Whois queries made to the system, whether they come from the Tiered Access Searchable Whois or the Port 43 Whois are logged for analysis, capacity planning, and abuse detection. 
Whois API 
Tiered Access Searchable Whois is a service for registered and authenticated users to perform wildcard searches on object registrations and retrieve them in a user-friendly way. 
An Applications Programming Interface (API) also is provided, thereby enabling information systems to integrate with our RESTful whois service. 
If the user of the Tiered Access Searchable Whois system is also the current registrant of a particular domain name, an additional feature is available which allows the user to view whois query reporting information based on the data collected from the monitoring service for that domain name. 
Among the items made available to the registrant are: 
* Number of times the registrantʹs domain name has appeared on port-43 whois results, over time, and by country; 
* General and detailed information on who has been searching for them in the RESTful Whois Interface; and 
* Registry system statistics associated with their domain names such as number of DNS queries 
Internationalized Domain Names 
An Internationalized Domain Name (IDN) is a name that contains at least one non-ASCII character, as permitted according to ICANN and its IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄idn-guidelines-02sep11-en.htm), and IETF standards such as RFC 3490, RFC 3491, and RFC 3492. 
IDN Registrations 
The top level domain name for which we are applying, MOSCOW, is not itself an internationalized domain name (IDN.) All second domain registrations will be in the Latin script (English) only.
IDN Whois 
Our whois implementation allows UTF-8 input by default on the query command, but defaults to ASCII responses in order to provide backwards compatibility for ASCII-only clients. Domain name objects that include characters other than ASCII are shown in the A-LABEL form. 
The reason for this behavior, is that port-43 Whois (RFC 3912) does not have a mechanism to signal the use of character encodings. The use of ASCII-only responses guarantees backwards client compatibility. If the response contains characters other than US-ASCII, a disclaimer note is shown referencing a URL where the complete UTF-8 encoded information is available. 
The RESTful interface (in XML format by default) are pretty-formatted if rendered using a web-browser. The content is UTF-8 encoded to allow for extended character sets other than US-ASCII. The format of that XML file is detailed in our answer to question 26 (Whois Service), and will be reviewed and kept up-to-date with IETF proposed standards and best current practices. 
DNS Security Extensions (DNSSEC) 
Our registry backend operator, Internet Systems Consortium (ISC) has significant experience with DNSSEC. ISC participated in the development of the DNSSEC protocol itself within IETF, and is author of one of the earliest and most popular current free open source DNSSEC implementations available (BIND). ISC operates and manages one of the largest portfolios of DNSSEC signed zones and DNSSEC capable servers. 
Registrars collect Delegation Signer (DS) information from Registrants and submit it to the Registry using the EPP service covered under RFC 5910 (DS Data Interface) (DNSSEC Mapping for EPP) or via the Registrar Web Interface. 
The TLD zone with all of its resource records are signed using the best current practices for DNSSEC operations. 
It is our intent to utilise Hardware Security Modules (HSMs) to securely store both the Key Signing Keys (KSKs) and Zone Signing Keys (ZSKs). However, due to import restrictions on HSMs, we may not be able to deploy HSMs on our primary site located in Moscow, Russia. In that event, we will utilize Software Security Modules (SSMs) and enhanced security measures for key management at the primary site.
Except for the HSMs which will be provisioned after approval of this TLD, our DNSSEC system is fully operational and in daily use by several ccTLDs and commercial second-level DNS zones. 
DNSSEC key management, protection, and signing formalities are in accord with developing norms such as those being used on the root zone itself. (See answer to question 43 for additional information) 
Registry Operations Center (ROC) 
We have centralized registry management, control, reporting, measurement, and repair functions into a facility we call the Registry Operations Center (or ROC). 
There is a secure physical facility that serves as the primary home of the ROC. 
Backup ROC facilities may be established on a temporary basis should the need arise. 
The ROC is the primary point of contact for all registry issues. The ROC can receive input via several means - PSTN telephone, VoIP telephone, web input, e-mail, and text messages, etc. Special access methods are available to registrars and law enforcement. 
The ROC assures that all incoming reports are logged, assigned identifiers, triaged, assigned to staff for resolution, and tracked. A strict reporting structure assures that all issues are handled and, if necessary, escalated and assigned additional resources. 
The ROC is also a collection point for the receipt and analysis of monitoring and logging data. 
The ROC is supported by geographically distributed staff members who are able to provide assistance if needed. Should there be a failure that takes the ROC offline, those remote staff members will have the tools and security credentials to take over operations until the ROC comes back online. 
ISC has successfully used these methods for several years to support F-Root and other critical Internet services. 
Abuse Mitigation and Prevention 
We anticipate that our Registry (like all registries) will be the target of various kinds of abuse. 
* We anticipate that our registration, whois, and name servers will be the target of frequent attacks ranging from heavy-load Distributed Denial of Service (DDoS) attacks to sophisticated penetration attempts. 
* Registered names may be mis-used in ways that violate the rights of others. 
To deal with direct attacks, we do this: 
* Armor our networks and systems with firewalls and filters. 
* Pre-deploy significant overcapacity to absorb excess load. 
* Use system architectures that allow us to shed an individual device that is under attack. 
* Use reasonably secure hardware and software which we will keep up-to-date as vulnerabilities are discovered. 
* Monitor for attacks and penetrations so that we can initiate countermeasures. 
* Have replicated data (and off-site backups), audit trails, and journals to allow recovery from data damage and to assist law enforcement. 
In addition we use an Adaptive Intelligent Mitigation (AIM) strategy in which we use a real-time global system to evaluate actual DNS and Whois activity for signs of errors, trouble, abuse, or attack. 
To reduce the abuse of names, our Registry Operations Center maintains active contact points for the reporting of abusive behavior. This is backed by procedures and systems to research the abuse claim, to track progress of the handling of that claim, and to take remedial actions. 
Our Registry Operations Center also serves as the primary point of contact for law enforcement interactions with the registry. 
To redress name-registration abuse, we: 
* Implement ICANNʹs Uniform Dispute Resolution Policy (ʺUDRPʺ). 
* Implement a sunrise protection and registration program that uses ICANNʹs Trademark Clearinghouse (ʺTMCHʺ). 
* Implement ICANNʹs Uniform Rapid Suspension Policy (ʺURSʺ). 
System Security and Stability 
Our systems have been engineered using standards and best current practices in information system security. 
Our systems are protected by multiple security mechanisms ranging from firewalls to multiple levels of authentication, IP address white-lists, real-time monitoring, and audit logs of transaction and system events. 
We maintain several levels of non-incremental data backup. We perform realtime data replication among our master and hot stand-by nodes. The replication is designed to safeguard against hardware or software failures. To handle human errors -- for instance, erroneous deleting of records -- a comprehensive backup policy is in place. 
We participate in trusted security committees and forums so that we can quickly learn of new threats and solutions. 
However, new threats arise every day. No system can be totally secured against every threat. Therefore we have procedures, resources, and backups ready to detect problems at an early stage so we can prevent further harm and restore our systems back to full operational status. 
Monitoring of Whois and DNS Query Streams 
The registry offers a service through which network operators, law enforcement, security companies, and research organizations are able to monitor actual DNS and Whois query⁄response activity. 
This service is available only under strict access controls and only to credentialed, identified users operating for the public interest under contractual constraints or to law enforcement personnel. 
This service passively monitors queries sent to both the Whois and the DNS service. The monitored transactions are classified into set of channels. Subscribers to a channel can view that channelʹs DNS and Whois transaction activity. 
This is far more than a simple packet monitoring service because the transactions are preserved in a searchable database for historical analysis. 
In addition, this information is used to feed our analysis systems. Among other things the analysis tries to recognize malicious domain name activity. Suspicious behavior is logged and reported to the Registry Operations Center and, if warranted, to the appropriate registrar. 
Overall, this system gives us a unique real-time view of our performance. 
Front Desk for Abuse Reporting and Mitigation 
Through our Registry Operations Center (ROC), anyone can report suspicious activity. Requests are assigned a number (ticket number) and entered into a tracking system, so that the request can be tracked as it is being handled by our team. 
Requests resulting in a determination of misuse of a domain name generate a notification for the registrar so they can deal with the registrant to resolve the problem. 
In case there is no response from the registrar within a reasonable period of time, a take-down policy will come into effect, where the domain name is disabled (not deleted) until matters can be settled. 
GENERAL RESOURCING PLANS FOR THE REGISTRY 
The management is committed to providing world-class registry services, including all necessary assurances for performance and availability of those services to the community at large. 
ISC has extensive experience operating critical infrastructure such as F-Root and ISC-SNS. These are globally DNS services which have reliably served millions of users without interruption since they were deployed. 
Operations staff with this level of experience will be in charge of all aspects of the back-end registry operations, including DNS, EPP, and WHOIS services. As additional guarantees, ISC has 50+ employees with dedicated operations, support and software engineering resources that will be available to contribute to both the initial implementation and to the ongoing operation, monitoring, and maintenance of the registry system. ISCʹs engineering and operations staffs specialize in the technologies that are required to build and operate a registry and its associated systems. 
Additionally, ISC has a world-renowned cyber-security engineering team that will create and maintain a proactive approach to security. ISC is actively involved in major Internet industry security organizations like SSAC and various trusted groups. This team will assist and support the appointed Chief Information Security Officer (CISO) and the Computer Incident Response Team (CIRT) when needed. 
All resources required for the fulfilment of the obligations derived from the operation of this TLD will be fully available when registries operations begin. These resources have been enumerated through all the responses of this application and have been accounted for in the corresponding business, operations and⁄or disaster recovery plans 
Performance of service and compliance with SLAs is insured due to the over-provisioning that is built in by-design. Ongoing investment in the platform, vendor support and parts to replace failed components are further evidence of the effort that goes into supporting all operational and business functions. Vendor support in particular is an important factor: All critical components of the service platform are covered by 7x24 support contracts with response within 4 or 8 hours. This level of support is supplemented by on-hand spares, allowing the on-site staff to recover from most hardware failures on short notice. 
A custom monitoring platform complemented with third party monitoring services and systematic service health checks reinforce the ability to maintain responses within the terms of the SLAs. 
The highly critical DNS service is provided with a combination of the ISC-SNS service -- a worldwide, anycast-based DNS secondary service -- and dedicated DNS service provisioned by INTC.
A comprehensive Disaster Recovery Plan that is tested and reviewed frequently, supported through the Security Policy, guarantees the ability to restore services to maintain aggressive availability targets, insuring services are available to the public at all times. 
Failover Testing and other aspects of the disaster recovery planning are managed by a designated person dedicated to that task, our Disaster Recovery Specialist or DRS. The DRS has at his or her disposal resources from the whole organization -- including management resources -- to ensure that the testing plans are executed and its results and lessons are incorporated into the operation toward the future. 
The DRS is responsible for obtaining and properly storing machine logs as well as the service monitoring reports that accompany each test depicted below. This information is preserved and considered an integral part of the Test Report, that remains available for reassessing findings or post-mortem analysis. 
The Registry Operations Center (ROC) that is supported by a 24x7 call center and custom automation will receive, aggregate and respond to normal and abnormal issues arising from the operation of the registry services. This organization serves as the focal point for response coordination, threat mitigation and effective policy controls implementation.
Costs and procurement of the resources described here are detailed in response to Question 47. 
Human Resources 
Management Staff 
Management provides guidance and support for the deployment and operation of the registry. 
Key members of the Registry Operations Group can be viewed in EXHIBIT ʺ23-Key-Resource-Profiles.pdfʺ.

Contents
* SHARED REGISTRY SYSTEM 
o EPP Software 
* Software Development Process 
* Coding Guidelines 
* Code Review
* Code Versioning
* Software Testing 
* Unit Tests
* Protocol Conformance Tests
o Platform 
* Network
* Site Configuration
o EPP System Performance 
* Setup
* Server Specifications
* Procedure
* Results 
* Session Command
* Query Commands
* Object Transformations
* Server Load
o Registrar Web Interface
* RESOURCING PLANS 
o Human Resources
* ABOUT THIS RESPONSE

SHARED REGISTRY SYSTEM 
Our Shared Registry System (SRS) is a set of registrar-facing servers, each offering an Extensible Provisioning Protocol (EPP) interface and a Registrar Web Interface. These servers interact with a high-performance redundant back-end system that applies registry policy, and that in turn uses a distributed database master⁄slave cluster. 
Our high-performance database system, built on PostgreSQL, uses live streaming replication to update multiple servers simultaneously. Any of these replicas can be promoted to full read⁄write operation if necessary, replacing the master server in case of a failure affecting that master. 
Non-master servers share the load of database read-only operations, giving the overall database cluster a significant speed advantage over traditional single-server systems; however, write operations are exclusively and carefully routed to the master server to ensure consistency. Changes to the master are replicated to the other servers after being committed at the master. 
Each system component has been engineered to be fully redundant. The hardware used to host them has been designed to allow for single component failures, including power supplies, hard drives, and network interface cards. 
In addition to that fully redundant hardware, the software that implements each service has been engineered so that it can operate as multiple instances of that service running on multiple servers. This ability to replicate components (both hardware and software) is critical to the scalability of any high volume, critical service. By having replicated services, the overall system may be geographically distributed among several data centers, which gives multiple-site redundancy to the registry and its services. 
The servers in our system all use the Network Time Protocol (NTP) to synchronize their internal clocks, enabling the proper recording of audit traces so that event correlation can be performed at any instant. We operate our own Stratum 1 clock which (along with access to several other Stratum 1 clocks operated by other organizations) gives all of our servers a highly consistent, reliable, and accurate time baseline. 
The internal communication between a server and the back-end system is performed with authenticated Representation State Transfer (RESTful) operations layered on HTTPS transport. 
Our systems support both IPv4 and IPv6. Our registration systems and name server systems are fully DNSSEC compliant. 
For information on Whois and DNS service implementation and performance, please refer to our answer to questions 26 and 35. 
EPP Software 
Internet Systems Consortiumʹs Shared Registry System (ISC-SRS) is a software package created from the ground up. Its design is based on the set of requirements specified in the ICANN gTLD Applicantʹs Guidebook and on our previous experience with registry software. This is a second generation implementation; its predecessor (OpenReg) had been an earlier initiative within ISC to provide an Open Source registry solution. 
OpenReg was used by a few organizations, but mostly became a reference implementation for various software implementers who used it as the platform on which to build their solutions. 
The experience gained from OpenReg, and the incorporation into ISCʹs staff of engineers and operations staff with background in registry operations, has led to the creation of a new and innovative system that makes use of modern software technologies to achieve simplicity, scalability, and resiliency with high performance and high integrity. 
Software Development Process 
ISC makes use of the Agile Software Development methodology, advocating frequent releases in short development cycles, with the intention of increasing productivity and introducing checkpoints where new requirements can be adopted. 
Our methodology focuses on having extensive code reviews (by at least one other person), unit testing of all code, measurability by code-coverage analysis, and prioritizing based on functionality. 
Coding Guidelines 
For ISC-SRS, we follow the guidelines and recommendations of the BIND 9 Coding guidelines as published in http:⁄⁄bind10.isc.org⁄wiki⁄BIND9CodingGuidelines 
Code Review 
As is standard for all ISC software development, code must be reviewed by peers before it can be considered ready for production testing. This ensures that coding guidelines have been followed, the code is consistent and factored appropriately. 
Code Versioning 
Source code is stored using the GIT version control system, which is widely used by many organizations that do software development. Among them are: Linux Kernel, Perl, Eclipse, Gnome, KDE, PostgreSQL, etc. 
The main features of this system are: 
* Distributed development: provides a full copy of the entire repository for developers; 
* Strong support for non-linear development: rapid support for branching and merging; 
* Efficient handling of large projects; 
* Cryptographic authentication of history; and 
* Easy integration with existing unix command line tools. 
Software Testing 
Unit Tests 
Unit Testing is where software development starts. Once there is a clear definition of the functionality that we want to achieve, we proceed to write code that is capable of executing in small or factored pieces. 
When the tests have been written, we run them, and verify that all of them fail. 
Once the testing framework for a specific project has been put into place, we write the actual implementation, making sure that there is complete coverage of what the tests will be looking for. 
When the code has been written, the tests can verify each specific code function, always aiming at a 100% source code coverage. 
Having a full set of unit tests written from the beginning enables us to do regression testing, a vital step to make sure that new code additions do not break existing functionality. 
Protocol Conformance Tests 
In addition to Unit Testing, we run a different set of tests, which allow us to verify that the code conforms with protocol specifications. 
To achieve this, we have developed a set of testing tools to check for specific use cases, as defined in Request For Comments (RFC) documents. 
As with Unit Tests, it enables regression testing and backwards compatibility with changes going forward. 
Platform 
The ISC-SRS system is a high performance, scalable platform built for simultaneous support of multiple TLDs. ISC-SRS has the ability to scale with its customer base by adding resources (processors, storage, memory, network capacity) incrementally as needed. 
The initial platform for this TLD consists of two live sites located at: 
* Data center, Moscow, Russia hosted at StoreData (Master)
* Chicago, IL, USA hosted at Equinix (warm standby). 
A third site (another warm standby) is planned to be deployed as soon as the risk assessment, to be performed during mid 2012, is complete. 
Each site is fully capable of handling the entire largest-case expected load of SRS operations, and it is designed to be fully redundant from its component base to its network connectivity. 
Network 
For Internet connectivity the ISPs that provide connectivity to our sites meet the following set of requirements: 
* IPv4 and IPv6 native connectivity 
* Ability to deliver multiple links through different network paths 
* Ability to use an IGP (Internal Gateway Protocol), to automatically re-route traffic 
* Presence at chosen data centers 
* Good peering diversity 
* Not provide Internet transit services to another of our registry sites 
Complementing the ISP-provided Internet access two private links are provisioned between registry sites, providing a redundant path with consistent low latency for the purpose of guaranteeing database replication and front-end to back-end communication. 
See EXHIBIT: ʺ24-Diagram-Network-Sites.pngʺ for a visual description of the connectivity for the sites. 
On each site, connections are terminated in two routers having: 
* One Internet Transit Link for Management 
* One Internet Transit Link for Services 
* One Inter-Site link 
* One connection towards the other router 
* One connection towards each firewall. 
The routers provide the ability to adapt the network to link failures, providing the best available path for inter-site traffic and the rest of the world (Internet). 
Site Configuration 
The configuration for each registry site is as follow: 
* Two (2) Routers 
* Two (2) Network Firewalls 
* Two (2) Network Switches 
* Two (2) Local Load Balancers 
* One (1) Global Load Balancer 
* Two (2) High Performance Database Servers 
* Two (2) EPP Servers 
* Two (2) Whois Servers 
* Two (2) Back-end Servers 
* Two (2) Management Servers 
* One (1) DNS Server 
* Two (2) Hardware Security Modules (HSMs) 
DNS Services are provided using ISC-SNS platform, which is an Anycast cloud-based service that disseminates and serves DNS information using a globally distributed system. 
There is also an additional DNS server per registry site, in Unicast mode, for additional redundancy and diversity. 
EPP System Performance 
Our platform is not yet in use for this TLD, so we cannot measure performance with live traffic. We have done performance testing using a laboratory system to determine the load limits of our system and platform. 
The laboratory testing platform on which these measurements were made consisted of only one server with low I⁄O performance (only one hard drive) that was executing three competing system components: EPP front-end, SRS back-end, and the database system. 
Our laboratory performance measurements understate the performance that will be delivered in full production. As compared to the lab systems, the production EPP servers have higher capacity (more CPU cores, more RAM, faster memory bus). Further, the production servers are dedicated systems that do not perform any other functions that compete for resources. 
The hardware profile of the servers is expected to change over the lifetime of the project as industry trends change. At the time of this writing, production servers are based on x86 architecture and fitted with enough RAM and storage capacity to run the expected workloads with a considerable excess capacity. 
Setup 
To measure performance, the platform was provisioned in a lab under the following conditions: 
* Both the client and the server were located in the same room 
* A 1-GigE switch was used to provide network connectivity 
* No firewall or packet filtering was used for the test 
* Each server had two network cables attached to the switch: 
o (1) for Management 
o (1) for Client-Server communication 
Server Specifications 
The hardware chosen for the laboratory testing platform differs from the production architecture. For actual deployment we use a multi-level system to provide load balancing in conjunction with high performance dedicated database systems to minimize the impact of Input⁄Output bottlenecks. Our test system did not have any of that extra capacity or high-performance backend. 
Our test platform is thus less powerful than that which we will actually use. We anticipate that in full production, our platforms will exhibit much higher performance capacity. 
Yet even on this scaled-down test platform we easily meet the requirements of Specification 10. The test configuration can be seen at EXHIBIT: ʺ24-Table-Server-Specifications.pdfʺ 
Procedure 
To test the platform, the performance software (perf-epp) simulated a registrar performing a high volume of operations on the server. Performance metrics were collected to measure the number of transactions per second (TPS) as well as the round trip time (RTT) of each individual operation. 
The ʹperf-eppʹ software simulated: 
* 1 registrar sending a stream of operations; 
* 2,4,8,16,32,64 and 128 parallel connections performing operations. 
Once the client has been initialized with the command line options, it proceeds to: 
* Start Phase 1, which: 
o Generates a 1 client connection to the EPP server 
o Generates a random list of 500 unique domain names 
o Generates 500 EPP ʺcreateʺ,ʺinfoʺ and ʺdeleteʺ commands 
o Send all the ʺcreateʺ, ʺinfoʺ and ʺdeleteʺ commands and store performance metrics in a file 
o Continue to Phase 2 
* Phases 2-8 perform the same steps as above, but using 2,4,8,16,32,64 and 128 parallel connections to the EPP server. 
* Once all the processes have completed, a post-processing routine analyzes the files to produce the statistical results of the operation. 
* For the purpose of measuring the EPP session commands, we decided to time how long it would take to perform an EPP ʺloginʺ command on the server. 
The perf-epp collected the ʺloginʺ RTT as it progressed through the test. 
Results 
Session Command 
All the session initiation commands were performed under the SLA as specified in the Specification 10 document in the Applicantʹs Guidebook. 
See EXHIBIT: ʺ24-Chart-EPP-Graph-login.pngʺ for a visual interpretation of the data generated by the test. 
The Y-axis represents the Round-trip-Time (RTT) time in seconds, while X-axis the time in seconds elapsed during the test. The blue ʹplottedʹ line, shows the round-trip times as observed by the tool. The red line, shows the SLA is the Service Level Agreement as shown in Specification 10. 
Query Commands 
To test the EPP query operations, the perf-epp system uses the ʺinfoʺ command. 
See EXHIBIT: ʺ24-Chart-EPP-rtt-graph-query.pngʺ for the round trip times observed during the test. The test shows consistent response times under the SLA specification in the Applicantʹs Guidebook. 
See EXHIBIT: ʺ24-Chart-EPP-qps-graph-query.pngʺ for the simultaneous number of queries that the test system was able to perform with 1 to 128 simultaneous clients. 
Object Transformations 
Object creation and deletions are part of the EPP transform commands. EXHIBIT: ʺ24-Chart-EPP-rtt-graph-create.pngʺ and EXHIBIT: ʺ24-Chart-EPP-rtt-graph-delete.pngʺ graphically compare the results of the performance test against the SLA in specification 10 of the Applicantʹs Guidebook. 
EXHIBIT: ʺ24-Chart-EPP-qps-graph-create.pngʺ and EXHIBIT: ʺ24-Chart-EPP-qps-graph-delete.pngʺ show the number of transactions per second (TPS) that the system was able to achieve during simultaneous client connections. To stress the system, 1,2,4,8,16,32,64 and 128 simultaneous were used. 
The results of these tests clearly show that our system exceeds the SLA specification for transform operations as defined in specification 10. 
Server Load 
During the time the test was running, we collected system performance data using the linux command vmstat. Among other variables, this command reports on CPU usage (both user and system), which we used to observed how the system behaved under heavy load. 
After reviewing the performance data, the server maintained an average 75% load during EPP ʺcreateʺ and ʺinfoʺ queries, but later the CPU usage went high when performing massive EPP ʺdeleteʺ commands. This is easily remedied by separating functions not competing on CPU resources on the front-end. 
See EXHIBIT: ʺ24-Chart-EPP-Vmstat-graph.pngʺ. 
Registrar Web Interface 
The registrar web interface complements the functionality provided by the underlying EPP protocol, with rich features to instill confidence in the registrar, aimed at providing: 
* Management of Internet Objects (hosts, domain and contacts) 
* Administrative information such as: 
o Balance checks 
o Financial reporting 
* Operational and statistical reporting: 
o Registry services status 
o DNS platform stability and performance 
* Registrar messages and event notifications 
* Registry support services 
As with the the EPP Interface, the system uses a multi layer authentication system that includes: 
* TLS Certificate to identify the client 
* User⁄password combination to authenticate access the system 
* Devices accessing for the first time into the system must be approved by an email challenge sent to the registrar operational contact 
* Any changes to Internet Objects within the registry will also require an email challenge sent to the operational contact 
Since this web interface uses a communication channel specifically designed for registrars, we can be innovative with regard to the services offered through and we can adapt to new challenges and technologies as they come along. 
This service is intended to be used as a backup or in unusual circumstances by the registrars; we do not envision high load demands over it. 
RESOURCING PLANS 
Costs and procurement of the resources described here are detailed in response to Question 47. 
Human Resources 
The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23. 
The accompanying chart shows the human resources allocated to the functions depicted in this response. 
See EXHIBIT: ʺ24-Chart-Resourcing.pngʺ for human resource assignments. 
ABOUT THIS RESPONSE 
We believe this answer is complete and must be awarded the full score: 
* We includes a complete description of the SRS solution proposed by ISC, including a high-level description of the system, a representative network diagram, a table with the initial number of servers in the solution, a description of the interconnections with other components, a discussion about the synchronization scheme -- both time and database synchronization are explained early in the response -- including the frequency of synchronization (instantaneous and continuous) and the synchronization scheme (live streaming replication). 
* This solution provides high performance, high integrity, and high availability - it provides full service through foreseeable failures and includes sufficient resilience and backup to assure business continuity. 
* The system architecture is readily expansible: it can obtain increased performance by adding new servers. 
* This solution meets, and exceeds, the performance requirements of Specification 10. 
* We fully support EPP, DNSSEC, IPv4, and IPv6. 

Contents
* EPP SERVICE 
o Standards Compliance
o EPP Service Features
o Service Architecture 
* Authentication
* Server Selection
* EPP Session Handling
* EPP EXTENSIONS 
o Internationalized Domain Names
o Launch Phase
* RESOURCING PLANS 
o Human Resources
o Technical Platform
o Facilities 
* Power
* Cooling
* Flood Control
* Fire Detection and Suppression
* Earthquake
* ABOUT THIS RESPONSE
EPP SERVICE 
EPP service is the primary interface between registrars and registries. Our EPP service supports a high transaction volume. 
Our other registrar-facing service interface is a web-based service that has some additional capabilities not present in EPP, but with lower transactional volume. This web-based service is described in our answer to question 23. 
Our EPP service is extensible, robust, secure, accountable, scalable, and conforms to all relevant ICANN requirements, internet standards and published best practices. 
Our EPP service is designed with simplicity and intelligence at the application level to facilitate the most demanding operational models. 
We believe that for a high-volume critical service to succeed, it must be modular. Therefore we have designed and built our EPP service to use multiple geographically distributed servers. These servers are front-ended with security firewalls and high performance load balancers. These load balancers ensure that client requests are sent to the least busy (hence best) EPP server. 
The load balancers also monitor individual EPP server performance metrics and availability. Thus, in the case of failure or maintenance, the load balancers will automatically stop routing new work to non-responsive EPP server(s) and spread that work among the best of the remaining servers. This substantially improves the scalability of the registry by making it a relatively easy and non-critical task to add or remove EPP servers without interrupting ongoing operations. 
Standards Compliance 
Our EPP server implements the following RFCs: 
* RFC 5730 - Extensible Provisioning Protocol (EPP) 
This RFC describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. 
* RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping 
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. 
* RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping 
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. 
* RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping 
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ʺcontactsʺ) stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. 
* RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over TCP; 
This RFC describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. 
* RFC 5910 - Domain Name System (DNS) Security Extensions Mapping 
This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. 
* RFC 3915 - Domain Registry Grace Period Mapping 
This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. 
* RFC 5646 - Tags for Identifying Languages 
This RFC describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. 
For IDN support, our implementation uses the following RFCs as guidelines: 
* RFC 3454 - Preparation of Internationalized Strings (ʺstringprepʺ); 
This RFC describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. 
* RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework 
This RFC is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. 
* RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol 
This RFC is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. 
In addition to the above-mentioned published RFCs, we have implemented a custom extension to associate the domain name to a language tag, as required by ICANNʹs Registry Implementation Committee. The specification of that extension has been prepared as an experimental Internet draft, suitable for eventual IETF consideration for the standards track. 
EPP Service Features 
Our EPP implementation includes the following features: 
* Both IPv6 and IPv4 transport and record support. 
* Automatic load balancing among server instances. 
* Geographic distribution of servers with diversity of communications paths to mitigate the extent of local or regional failures. 
* Transaction journaling and statistics for both performance and transactions. 
* Authentication: our EPP implementation uses a multi-factor system to authenticate registrars; the process is as follows: 
o Source IP address is verified and checked against a whitelist at connection time; 
o X.509 Certificate validation back to a known certificate issuing authority at TLSv1.2 session initiation; and 
o User⁄Password authentication at the EPP level. 
* All data transmitted over the network is encrypted using TLS v1.2. 
* Well-formedness check: If at any given time, a command is sent to the server in a format other than proper well-formed XML, the server will drop the connection and de-authenticate the client. This protects against defective clients and adds a measure of protection against exploration by rogue users. 
* XML Validation: every EPP command is validated against the associated XML Schema, as specified in the RFC or custom extension. When a client sends an XML command that does not pass the validation check, the EPP server sends the registrar a ʺSyntaxʺ error response signaling the inappropriate message format. 
* Time Outs: Every session automatically times out after 15 seconds of client inactivity. Issuing an EPP ʺhelloʺ or ʺgreetingʺ command resets the time out counter, allowing the registrar to use it as a keep-alive method. Once the registrar has been authenticated, it is allowed to perform commands to manage the session, query and transform objects, as permitted by registry policy. When issuing a ʺlogoutʺ command, the server acknowledges it and terminates the session. 
Service Architecture 
Authentication 
Service authentication is achieved using a multi level system to authenticate access to the EPP interface, as shown in the EXHIBIT ʺ25-Figure-EPP-Authentication.pngʺ. 
By using three successive access control methods, we significantly improve the overall system security. Registrars wishing to use the EPP system must provide in advance the list of IPv4 and IPv6 addresses from which they will access the EPP Service. Each service request will be authenticated in the following manner: 
* At the firewall level the system will check for source IP, comparing it to those in the registered Access Control Lists; 
* Once the IP has been verified, the next step is to initiate the TLS session, which will trigger: 
o Secure Channel communication 
o Client X.509 certificate check, which must be signed by the registry-operated Certificate Authority (CA), and must not be in the revocation list; 
* The registrar must authenticate itself to the EPP service with a user⁄password combination. 
This multilayer approach to client authentication protects against many forms of unauthorized access. 
Server Selection 
Our system performs load balancing to send clients to the best available EPP server. This balancing is done as part of the DNS name resolution process when the client seeks to connect to an EPP server. Each load balancer continuously monitors performance metrics, such as server load and geographic location, to determine the best server binding for each incoming client. This choice is delivered to the client through the address records in the DNS response returned to the client when it looks up the EPP server by name. 
EXHIBIT ʺ25-Figure-EPP-Network-Diagram.pngʺ, explains how the client is directed to the EPP Servers using DNS queries to which the response is determined by performance data. 
Server selection description: 
* Clients (Registrar A and B) initiate the process by sending a DNS query to EPP.[TLD].registry.isc.org, where [TLD] is the string that represents the top-level domain 
* [TLD].registry.isc.org. is a sub-domain delegated to the load balancers, thus the queries are sent to one of the load balancers (it does not matter which load balancer receives the clientʹs query.); 
* Each load balancer evaluates the performance metrics from all four EPP Servers, and decides which EPP server is the best fit and returns the IP address of that server to the client; 
* Clients connect to the IP as supplied by the Load Balancer that handled its request, initiate the EPP connection, and perform the desired EPP operations using that IP address. 
EPP Session Handling 
The numbers on this diagram correspond to the numbers in the EXHIBIT ʺ25-Figure-EPP-Flow-Diagram.pngʺ: 
Once the Registrar has passed the source-IP verification and the TLS X.509 certificate validation, the EPP session follows this life cycle: 
* Registrar initiates a connection to the server on TCP port 700 (EPP Port); 
* The server replies with an EPP ʺgreetingʺ response, displaying the namespaces for objects and extensions available on the system; 
* The Client processes the greeting and sends an EPP ʺloginʺ command with its credentials (user⁄password), along with the namespaces of the extensions that it wishes to use during this session; 
* The EPP server checks the credentials against the Back-end system, and answers either with an EPP success or failure response; 
* The registrar evaluates the authentication response from the server. In case it is a failure, it has the option of either disconnecting itself, timing out, or to try sending new authentication credentials again (step 3); 
* If authentication succeeds, the client reads the next available command from its command queue and forwards it to the EPP Server; 
* The server processes the command and responds back to the client with the requested data, confirmation receipt or EPP failure response; 
* The client will then read another command from its queue; if that queue is empty, it will send an EPP ʺlogoutʺ command 
* If the command requested was an EPP ʺlogoutʺ the server disconnects the client after sending the EPP success⁄ending session response back to the client. 
EPP EXTENSIONS 
Internationalized Domain Names 
See EXHIBIT ʺ25-EXHIBIT-EPP-IDN.pdfʺ 
Launch Phase 
Domain registries typically operate in special modes within certain periods of time to facilitate allocation of domain names for a subset of the zone namespace that becomes available. This document uses the term ʺlaunch phaseʺ to refer to such a period. 
The EPP domain name mapping RFC5731 is designed for the steady state operation of a registry. During a launch phase, registries typically accept multiple applications for a given domain name. This document proposes an extension to the domain name application in order to unambiguously manage the received applications. 
See EXHIBIT ʺ25-EXHIBIT-EPP-LaunchPhase.pdfʺ 
RESOURCING PLANS 
Costs and procurement of the resources described here are detailed in response to Question 47. 
Human Resources 
See EXHIBIT: ʺ25-Chart-Resourcing.pngʺ 
The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23. 
The accompanying chart shows the human resources allocated to the functions depicted in this response. 
Technical Platform 
A total of four (4) high performance servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a eighty percent (80%) of the systemʹs total capacity. Provision of additional EPP servers does not disrupt ongoing operations. 
Each of the registry locations will, by itself, be able to sustain the entire estimated traffic level. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience. 
In addition, the Registry Operations Center will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary. 
Facilities 
Two carrier grade data centers will be used to host the registry platform. 
Although the sites have not yet been provisioned, the plan for the deployment of the registry takes into consideration the contracting of the datacenter space in mid 2012 so that it is fully provisioned by the time of delegation. 
Each facility must cover the following criteria: 
Power 
Provide a minimum N+1 redundancy for every power system, to maximize uptime availability. 
Uninterruptible Power Supply (UPS) systems to prevent power spikes, surges, and brownouts, and redundant backup diesel generators provide additional runtime. 
Provide continuous monitoring of all power system components on-site or remotely, to respond quickly to any situations. 
Cooling 
Includes a robust HVAC system to provide stable airflow, temperature and humidity, with minimum N+1 redundancy for all major equipment. 
Representative Specifications: 
* 13,652 BTUH per cabinet 
* Six (6) 750-ton centrifugal chillers 
* Six (6) variable primary chilled water pumps 
* Six (6) condenser pumps 
* Six (6) cooling towers 
* 24 air handling units in the colocation area 
Flood Control 
Built above sea level with no basements and have the following flood control features: 
* Moisture barriers on exterior walls 
* Dedicated pump rooms 
* Drainage⁄evacuation systems 
* Moisture detection sensors 
Fire Detection and Suppression 
Key features of the fire detection and suppression system must include: 
* Multi-zoned, dry-pipe, double-interlock, pre-action fire suppression system 
* Very Early Smoke Detection and Alarm (VESDA) 
Earthquake 
Must meet or exceed local building codes for lateral seismic design forces. Equipment and nonstructural components, including cabinets, are anchored and braced. 
ABOUT THIS RESPONSE 
This answer meets the requirements of this question: 
* Our EPP protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs. 
* Our EPP service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over. 
* We have defined an EPP extension (to support internationalized names) in conformance with all relevant internet standards and RFCs. We will be submitting this extension to the IETF. 
* That EPP extension is documented fully in this answer. 
* That EPP extension is fully integrated into our registry technical approach and operations; it has no significant financial or resource impact. 
* Our EPP service in conjunction with the EPP extensions defined here are consistent with the technical, operational, and financial approach as described in this application. 
* Many of the needed technical resources (computers, network access, software, facilities, and management) are either already on-hand (and in some cases are already operational). Other technical resources are easily acquired as commercial off-the-shelf (COTS) items (such as servers, firewalls, and routers.) We already have presence in several data centers. And we already have the financial and staff resources. 

Contents
* 1 WHOIS SERVICE 
o 1.1 Architecture 
* 1.1.1 Scalability
* 1.1.2 Frequency of Updates
o 1.2 Port 43 Whois 
* 1.2.1 Software 
* 1.2.1.1 Development Process
* 1.2.1.2 Features
* 1.2.2 Query Format
* 1.2.3 Query Response
o 1.3 Tiered Access Web⁄RESTful Interface 
* 1.3.1 Summary
* 1.3.2 Searchability
* 1.3.3 Architecture
* 1.3.4 Query Format 
* 1.3.4.1 Exact Matches
* 1.3.4.2 Searchable Keywords
* 1.3.5 Query Response 
* 1.3.5.1 XML Format
o 1.4 Privacy and Transparency
o 1.5 Abuse Mitigation
* 2 RESOURCING PLANS 
o 2.1 Human Resources
o 2.2 Technical Platform
* 3 SYSTEM PERFORMANCE 
o 3.1 Procedure
o 3.2 Results
o 3.3 Queries per Second
o 3.4 Round Trip Times
o 3.5 Server Load
* 4 ABOUT THIS RESPONSE
WHOIS SERVICE 
Architecture 
Our whois service is highly robust, geographically scalable, flexible, allows resources to be added or replaced without service disruption, and executes seamless failover. As shown in EXHIBIT ʺ26-Figure-Whois-Architecture.pngʺ it is located in two data centers. Each data center is internally redundant with local Load Balancers (LB) and firewalls, and each provides backup for the other. Global LB apportions the query traffic among the two centers. Each facility can handle the entire anticipated whois traffic load. 
The LB servers provide two distinct forms of access: Port 43 Whois (RFC 3912), providing classic Whois service; and Tiered Whois Access using a RESTful web interface supporting various search facilities, and returns answers in XML. 
When a user contacts the whois service, the LBs will route the user to the most appropriate data center and server. Should a server or a data center be unavailable, the LBs will spread the work among the rest of the servers to improve reliability. EXHIBIT ʺ26-Figure-Whois-Overview.jpgʺ further shows the front-end to back-end communication path. 
Scalability 
Every element of the whois service platform can be expanded without disrupting operations, and each single server can provide all necessary components of the system. Hence, a server can be placed in any location as chosen by the Registry Operations Center (ROC). In case of a large demand spike, such as DoS attacks or unpredicted traffic bursts, additional servers can be quickly deployed to distribute the load on a temporary basis. 
Frequency of Updates 
Whois servers query a database cluster that is part of our live database replication system. 
This means that servers are up to date quickly after the submission of the operation. The servers are designed to be able to handle user queries even when isolated from the main database cluster replication mechanism. When replication is not possible, the system falls back to periodic (1 hour) updates. 
Port 43 Whois 
Our standard Whois service implementation consists of a high capacity Internet server that answers RFC 3912 requests on TCP port 43, waits for a query string and returning a text response. The system supports various anti-abuse mechanisms to protect the service. 
Software 
The whois server is a custom designed solution that uses our front-end architecture to interact with high performance back-end components. 
Servers can be provisioned individually to increment the service capacity transparently. Systems architecture allows servers either to have their own read-only replica database, or to share a cluster among them for increased-demand scenarios. 
Development Process 
The Agile software development process used for this service is the same that is explained in our answer to Question 24. 
Features 
Our Whois system implements the following features: 
* Input timeouts to limit resource usage (default 4 seconds). 
* Input length verification to prevent resource exhaustion attacks (default 1024 bytes). 
* Response Caching 
* Statistics collection 
Query Format 
RFC 3912 specifies the format in which a Whois query is to be sent to the server. After the client has initiated the TCP connection to port 43 of a Whois server, the server expects to receive a valid query within the input timeout interval. 
Any mixture of upper- or lower-case letters may be used in a query; the protocol is not case sensitive. 
Queries are encoded using either US-ASCII or UTF-8; this allows for extended character sets while keeping backwards compatibility with older implementations. 
To maintain compatibility with whois clients that use keywords before the query (usually to restrict the search to a specific type of object) the whois server is also capable of understanding queries with the CONTACT, HOST, DOMAIN or REGISTRAR prefixes: DOMAIN example.tld[CR][LF] 
To permit querying of an IDN domain name, either the IDNʹs A-Label or the U-Label is allowed in the query string. 
Query Response 
The whois response consists of US-ASCII encoded text with a set of key⁄value pairs and informative notes describing the object queried and legal disclaimers. 
Data objects are represented in key⁄value pairs. Lines start with a key followed by a colon ʹ:ʹ and a space as delimiters, followed by the value. 
Fields that contain multiple values for the same key repeat the key at the beginning of the line. 
This format conforms to Specification 4 of the Registry Agreement. 
The EXHIBIT: ʺ26-Table-WHOIS-Responses.pdfʺ contains examples of the response for a WHOIS query for a domain, registrar and name server. 
All of the fields specified in the response will conform with the mappings specified in the RFCs related to EPP: RFC 5730, RFC 5731, RFC 5732, RFC 5733, RFC 5734 and RFC 5910. 
Tiered Access Web⁄RESTful Interface 
Summary 
To overcome the limitations of the Whois protocol as specified in RFC 3912 we have developed a tiered system that supports varying levels of access to Whois information. 
The Tiered Access system uses a web-based RESTful (Representational State Transfer) interface to query the registry. 
Tiered Access to Whois data is subject to strict security and access controls to ensure that access is limited to identifiable qualified users. 
All transfers are encrypted using the HTTPS protocol. 
Tiered Access queries can either be general exact-match queries similar to the port-43 service, or wildcard search strings that can yield more than one result. The particular information that is made available to the service user is configurable according to registry policy. 
The registry operator can grant bulk data access to qualified organizations. Such use will be governed by a contract that sets forth the conditions and limitations of such access. Bulk data access is performed using a specialized RESTful interface based on HTTPS. 
Currently the RESTful interface lacks any IETF standardization. ISC participates in this effort within the IETF and will adjust its operational implementation to be RFC compliant once such an RFC exists. 
Searchability 
The Tiered Access RESTful⁄Web-whois service is not bound to the same protocol technology restrictions as the port 43 (RFC 3912). Consequently there is room for innovation in the way clients interact with the service. 
The system allows the user to query the whois database using keywords. These keywords will be partially matched against the following database fields: 
* Domain name; 
* contact names (including registrant), and: 
o Postal Addresses; 
o City; 
o State; 
o Country; and 
o Any other subfields as needed 
In addition to the partially matched queries, the system will also support exact match on the following fields: 
* Registrar ID; 
* Name server (using a Fully Qualified Domain Name); 
* IP addresses (IPv4 and IPv6) 
Multiple keywords may be combined using the following boolean operations: AND, OR and NOT. 
Search results will consist of lists of objects that match the userʹs search criteria. 
This search capability meets or exceeds the requirements of Specification 4 of the Registry Agreement. 
Architecture 
The Tiered Access interface to the whois system uses the same underlying architecture as described previously in this answer. The only difference is the way the system is queried and the format of the responses. 
The architecture uses a RESTful interface, as described in http:⁄⁄en.wikipedia.org⁄wiki⁄Representational_state_transfer. 
When issuing a Tiered Access query the following HTTP methods are supported: 
* GET - This is used to obtain information about an object. 
* HEAD - This is used to check object existence without obtaining the actual data. 
Query Format 
All the queries to the system are performed through HTTPS (HTTP Secure) using URLs crafted to contain the query information. These are described below. 
Exact Matches 
For exact match searches the user will issue an HTTP query of the following form: https:⁄⁄whois.nic.@TLD@⁄rest⁄OBJECT⁄NAME where OBJECT corresponds to any of the following keywords: 
* domain - for domain objects; 
* host - for name servers; 
* contact - for contact objects; and 
* registrar - for registrar information 
NAME corresponds to the object ID that the client wishes to retrieve. 
Searchable Keywords 
Searchable Whois accommodates those cases where customers such as law enforcement require additional capabilities not available via traditional Port 43 whois. To access the searchable part of the Tiered Access service, customers must have obtained authorization credentials by registering into the Web whois system, and providing at least: 
* Email Address 
* Desired Password 
* First Name 
* Last Name 
* Affiliation or Capacity 
Once the requester has submitted the registration form, an email address will be sent to verify the email address. This allow us to certify that the email is valid, and that it is in use by the current requester. 
For a searchable Tiered Access Whois query the user will issue an HTTPS query of the following form: 
https:⁄⁄USER:PASSWORD@whois.nic.[TLD]⁄search⁄OBJECT⁄KEYWORDS?key=value
 where [TLD] is the string that represents the top-level domain.
USER:PASSWORD provides the authentication credentials to use the RESTful interface. 
OBJECT corresponds to any of the following keywords: 
* domain - for domain objects; 
* host - for name servers; 
* contact - for contact objects; and 
* registrar - for registrar information 
KEYWORDS correspond to partially matched string corresponding to the identifier of the object, for example, the query: 
https:⁄⁄foo:bar@whois.nic.[TLD]⁄search⁄domain⁄exam?country=US&state=CA 
Will result in the list of domain names that start with exam* and that have a registrant in the United States. By default the system uses the AND boolean operator to perform the search. However a + and ! character can be prepended to the value string to indicate OR or NOTʹ operations. 
For example, a query similar to the one described above but for domain names where the registrant is NOT in the US would be: 
https:⁄⁄foo:bar@whois.nic.[TLD]⁄search⁄domain⁄exam?country=!US 
Note that this interface is still under development. We are tracking the efforts of the IETF WIERDS working group in this area. Our interface will evolve in response to the IETFʹs work. 
Query Response 
The Tiered Access interface allows the output to be in XML format. XML tools such as XSLT and stylesheets make it possible to convert or re-format the data as desired. 
XML Format 
The current proposed format for the XML response, will use namespaces as similar as possible to those provided in RFC 5731, RFC 5732, RFC 5733 and RFC 5734. 
The following exhibit shows an example of a whois response for example.[TLD].: 
https:⁄⁄whois.nic.[TLD]⁄rest⁄domain⁄example.tld. 
See EXHIBIT: ʺ26-Exhibit-Restful-Whois.pdfʺ. 
The format consist of a ʺresponseʺ tag that contains exactly one object, in this example, the domain object example.tld. 
Any objects mentioned within the response object will be returned in the ʺadditionalʺ section using the same object-notation format. 
This format is subject to change when the IETF working group standardizes the interface. 
Privacy and Transparency 
ISC SRS implements the ability to specify the fields that can be publicly displayed as described in RFC 5733. Fields marked to prohibit disclosure are not shown to public or unauthorized users. Registrars can set the level of privacy based on the relevant jurisdiction and will be required to comply with applicable privacy protection laws. We will provide registrars with a set of default privacy level protections based on the country of the registrant, to the extent that such privacy protections are known. As the party collecting data, registrars are best positioned to provide the required notifications, warnings or terms of service to their customers as dictated by jurisdictional requirements. The RFC 5733 mechanism is combined with appropriate language in the registrar agreement to facilitate compliance with jurisdictional requirements on the information that is presented to third parties and under what circumstances. 
ISC SRS also implements the ability to remove Contact objects when those are not required for other active registrations, allowing inactive registrants to remove their personal information from the registry database, allowing compliance with all current privacy requirements at the required jurisdictions. . 
Certain jurisdictions, notably the European Union, have implemented data protection regulations and principles that may conflict with one another and with which there has been tension and ongoing discussion in relation to ICANN policies and requirements. While we cannot track and implement multiple conflicting data protection requirements on a global basis, the primary commercial relationship is between the registrar and the registrant. 
We will continue to monitor policy developments in this area, which principally occur in venues such as the Internet Governance Forum and the ICANN Government Advisory Committee, to remain abreast of best practices in this area. We will require its accredited registrars to maintain compliance with relevant regulations in their respective jurisdictions, and receive input from impacted registrars to detemine how our Whois practices can best accomodate the continued expansion of domain name availability into jurisdictions under-served by local registrars and which may present conflicts that may need to be addressed with the appropriate authority in such jurisdictions. 
Abuse Mitigation 
Whois services are subject to multiple forms of attack, some of them well known in the industry. The first and most common line of defense is to rate-limit the number of queries one client can perform according to various criteria. 
Since it is not possible to envision every type of attack against a whois server, the registry will collect queries in real time and stream them into an analysis system to detect unusual patterns and behaviors, feeding the ROC with the information it needs for defense. 
The provision of Whois services will be subject to terms prohibiting the use of Whois data for mass marketing and other inappropriate uses. We will actively seek to detect these activities, investigate third party reports of misuse of Whois data, and de-accredit registrars if they or their resellers are found to be facilitating or engaging in such activies. We will also seek judicially-available sanctions against non-registrar abusers of Whois data in violation of the terms of service. 
RESOURCING PLANS 
Costs and procurement of the resources described here are detailed in our response to Question 47. 
Human Resources 
See EXHIBIT: 26-Chart-Resourcing.png 
The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23. 
The accompanying chart shows the human resources allocated to the functions depicted in this response. 
Technical Platform 
Four servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a 80% of any systemʹs total capacity. Adding servers does not disrupt ongoing operations. 
Each of the registry locations is able to sustain the entire estimated traffic level by itself. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience. 
The ROC will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary. 
SYSTEM PERFORMANCE 
Procedure 
To test the whois service, a custom software defined as ʹperf-whoisʹ was written with the purpose of simulating client connections. 
The test was executed using: 
 perf-whois -h 10.1.2.1 -p 43 -n 1000 -q ʹdomain example3.iscʹ -d results⁄
The software then proceeded to generate: 
* One stream of 1000 sequential queries 
* 2,4,8,16,32,128 parallel streams of 1000 queries each 
The software was collects the round-trip-time and the number of queries per second of the whois queries. 
Results 
Queries per Second
The EXHIBIT ʺ26-Chart-Qps-graph.pngʺ is a graphical view of the number of queries per second collected by the tool. 
Round Trip Times
The current Service Level Agreement (SLA), as described in Specification 10 of the Applicants Guidebook, references a maximum of 2000 milliseconds for at least 95% the RTT of the whois service. During our test we did not see any RTT values go higher than 229 ms. 
Since we are planning to deploy four (4) high performance Whois servers, we expect to exceed the SLA with the setup that we currently have in place. 
The EXHIBIT ʺ26-Chart-Rtt-graph.pngʺ is a graphical view of the raw data as collected by the tool. 
Server Load 
During the performance test, we collected CPU usage (system and user). We did not observe the system to be even slightly stressed during the procedure. The CPU usage levels increased to a maximum of 70%, clearly with enough capacity to keep performing other functions. 
The EXHIBIT ʺ26-Chart-Vmstat-graph.pngʺ show the results of the CPU usage of the server during the test. 
ABOUT THIS RESPONSE 
This answer meets the requirements of this question: 
* Our Whois protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs. 
* We support a searchable whois via our Whois Tiered Access interface. 
* Access to our Tiered Whois Service is protected by security and access control. 
* All of our Whois services are protected against foreseeable attacks. 
* Our Whois service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over. 
* Our Whois service is fully integrated into our registry technical approach and operations. 
* Our Whois service complies with Specifications 4 and 10 of the Registry Agreement. 
This answer exceeds the requirements of this question: 
* We provide a searchable Whois service using a RESTful web service interface that allows searching by several registration fields and with combinations of search operators. We provide a service that is compliant with relevant privacy protection laws. 
* Our Whois services are protected by access controls and rate limitations. Advanced features are constrained so that they may be used only by known users who have been granted access credentials.

Contents
* 1 DOMAIN REGISTRATION LIFECYCLE 
o 1.1 Note on the Status Codes
o 1.2 Initial Registration ⁄ Add-Grace
o 1.3 Registration Changes Affecting The Registration Lifecycle
o 1.4 Expiration of Registration Term
o 1.5 Delete Cycle and Redemption Grace Period
o 1.6 Deletion 
* 2 RESOURCING PLANS 
o 2.1 Human Resources
* 3 ABOUT THIS RESPONSE
DOMAIN REGISTRATION LIFECYCLE 
The domain registration cycle for second-level domain name registrations is substantially the same as the well-understood life cycle in the existing generic top-level domains. 
Second-level domain names are registered for a term which is an integer number of years, up to a maximum registration term of ten years. 
An initial Add Grace Period (AGP) of five days is provided during which domain names registered as a consequence of error or registrar malfunction can be cancelled. To deter the abusive practice of ʺdomain tastingʺ or ʺdomain kitingʺ registrars must provide a report of circumstances under which the Add Grace Period is invoked, and are limited to a fixed proportion of such instances. 
During the registration period, second-level domain names may be transferred from one registrant to another, and from one registrar to another. Such names are subject to transfers, cancellations, and de-activation in accordance with intellectual property protection and abuse policies described under the relevant responses of this Application. 
The significant events of a standard domain lifecycle are explained in the following sections, and graphically depicted in the two flow diagrams as follows: 
See EXHIBIT ʺ27-Figure-Domain-Lifecycle-1.pngʺ referenced as 27-1 below; and 
See EXHIBIT ʺ27-Figure-Domain-Lifecycle-2.pngʺ referenced as 27-2 below. 
Note on the Status Codes 
Object status codes used in this answer have been based on the status codes explained in the following references 
* RFC 3915 -- Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 
* RFC 5730 -- Extensible Provisioning Protocol (EPP) 

Initial Registration ⁄ Add-Grace 
Referring to step 1 of Exhibit 27-1, a second level domain name is accepted for registration if (a) it is not already registered or reserved, (b) it satisfies the string requirements (e.g. 63 allowable characters, no trailing dashes, etc.), and (c) administrative requirements of the Registrar Accreditation Agreement are satisfied, such as prohibition against securing registrations for which a registrar has not obtained assurance of payment. 
During the first five days of registration, at step 2, the domain name is subject to an initial Add-Grace period (AGP). The purpose of the AGP is to provide an opportunity for a registrar to discontinue a registration made in error, such as by a malfunction of registrar software resulting in unintended registrations. As shown in steps 3-5, if a delete command is received during the AGP, the registrar is refunded the registration fee, and the registration proceeds to immediate deletion at step 39 (label D, Exhibit 27-2). During the AGP, the ICANN Add Grace Period Limits Policy (http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) shall be applied to deter ʺdomain tastingʺ. 
Significant provisions of the ICANN AGP include: 
A. During any given month, the registry shall not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new registrations in that month (calculated as the total number of net adds of one-year through ten-year registrations), or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted for extraordinary circumstances. 
B. A registrar may seek a specific one month retroactive exemption from application the AGP restrictions upon the documented showing of extraordinary circumstances. For any registrar requesting such an exemption, the registrar must confirm in writing to the registry how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and⁄or were outside the Registrarʹs control. Acceptance of any exemption will be at the sole and reasonable discretion of the registry in consultation with ICANN. ʺExtraordinary circumstancesʺ which reoccur regularly for the same Registrar will not be deemed extraordinary. Invocation of such circumstances for any two one-month periods in a single year will result in application of the second-tier penalties described in the response to Question 29, and successive tiered penalties for each month thereafter, leading to de-accreditation. 
C. The registry shall report each instance of application of an exemption to ICANN, along with a brief descriptive identification of the type of extraordinary circumstance and the action, approval or denial that was taken by the registry. 
If the registration is not deleted during the AGP, it proceeds to the registration term (step 6). 
Registration Changes Affecting The Registration Lifecycle 
Registrations during the contracted term will be subject to actions which do not affect the lifecycle, such as WHOIS updates and nameserver changes. Also, during the registration term we may re-assign nameservers to prevent resolution of a domain name due to action taken under our Abuse Policy (see Question 29), or in response to a decision under the Uniform Rapid Suspension Policy (URS) requiring that the domain name resolve to a designated web page indicating that the domain name has been disabled. We will also implement such changes as may be ordered by a court of competent jurisdiction or necessitated by registrar de-accreditation. Absent such unusual circumstances, any of the following actions prior to expiration of the registration term, will result in extension or shortening of the term: 
Extension of Term (EPP command ʺrenewʺ), step 8: A registration can be extended prior to expiration of the registration term in one year increments up to a total of ten years maximum. The account of the sponsoring registrar at the time of the additional extension will be charged for the number of years the registration is extended. As indicated in steps 12-14, if a delete command is received within a period of five days, the registrar will be credited for the previously charged extension, and the registration will proceed to the Delete Cycle (label A, Exhibit 27-2). 
Express Deletion (EPP command ʺdeleteʺ), step 9: An express deletion issued by the sponsoring registrar during the registration term will initiate the Delete Cycle (label A, Exhibit 27-2). 
Registrar Transfer (EPP command ʺtransferʺ), step 10: If a gaining registrar issues a transfer command, the registry will re-assign the authoritative registrar for a domain name upon receipt of a valid transfer request and authorization code. Transfers shall be implemented in accordance with the current version of the ICANN Inter-Registrar Transfer Policy (http:⁄⁄www.icann.org⁄en⁄transfers⁄). If the losing registrar expressly authorizes the transfer, the transfer shall proceed immediately. Otherwise, the transfer will proceed within five days. When the registration is assigned to the gaining registrar, the expiration date of the domain is extended by at least one year, and limited by the maximum registration term of ten years, and the gaining registrar is charged accordingly. As indicated in steps 21-23, if an express deletion is issued by the gaining registrar within five days, the registrar is credited for the renewal fee mandated by the transfer, and the registration proceeds to the Delete Cycle (label A, Exhibit 27-2). Otherwise, the registration continues in accordance with the new registration term (step 6). 
Expiration of Registration Term 
Registrars will be required to implement the relevant provisions of the ICANN Expired Domain Deletion Policy (EDDP) (http:⁄⁄www.icann.org⁄en⁄registrars⁄eddp.htm) for names subject to deletion as a consequence of non-renewal, and to accept renewal payments for names subject to dispute in accordance with the provisions of the EDDP relating to domain dispute procedures. 
At, step 7, upon the completion of the contracted registration term, the registration proceeds to an Auto-Renew Grace Period (ARGP) of forty five days in step 24. The sponsoring registrar is required to notify the registrant of impending expiration at least twice prior to expiration - once at least 30 days prior to expiration and once within 30 days of expiration. By default under the ARGP, expired domain names will be automatically renewed by the registry for a single year. 
In steps 25 and 26, if a domain is deleted within the ARGP, the sponsoring registrar at the time of the deletion receives a credit of the renewal fee (step 14), and the registration proceeds to the Delete Cycle (label A, Exhibit 27-2). If no delete command is issued during the ARGP, then the renewal is confirmed, and the registration proceeds in accordance with the renewed term (step 6). A registration can also be expressly renewed and its term extended beyond a single year during the Auto-Renew Grace Period, subject to a limit of ten years total. 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. 
In step 27 of Exhibit 27-1, if a domain is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge (step 28), the year added by the Auto-Renew operation is canceled, and the registration proceeds to the transfer process described above (label E, Exhibit 27-1). In the event of a bulk transfer with ICANN approval during the Auto-Renew Grace Period (such as may occur upon de-accreditation of the sponsoring registrar), the expiration dates of transferred registrations are not affected and the losing registrarʹs account is charged for the Auto-Renew. 
Delete Cycle and Redemption Grace Period 
A Redemption Grace Period (RGP) is applied at the initial step 30 of the Delete Cycle. The RGP is a period of 30 days, during which the subject registration is placed on REGISTRY-HOLD, and nameserver records for the registration are removed from the zone file, such that the domain name will not resolve. Rendering the registration non-functional in this manner is effectively the final notice to the registrant that the name is subject to deletion at the end of the RGP, even if inaccurate contact data or other technical issue resulted in failure of the registrant to receive renewal reminders or expiration notices. 
During the RGP, as indicated in steps 31-35, the registration may only be restored to the original registrant, subject to issuance of a ʺrestoreʺ command (step 32), followed by receipt of a redemption report from the sponsoring registrar (step 35) within a Restore Lock Period of five calendar days (step 34). During the RLP, the nameservers are restored, and the domain status is:
PENDING RESTORE + UPDATE PROHIBITED + DELETE PROHIBITED + RENEW PROHIBITED + TRANSFER PROHIBITED
If a Restore Report is not received from the registrar within the RLP, the nameservers are removed, and the domain is returned to step 30 until expiration of the RGP with status of:
PENDING DELETE RESTORABLE + HOLD
In order to restore the registration, a redemption report submitted in step 35 must indicate that the registrar has (a) verified identity of the party seeking redemption of the registration, (b) paid a renewal fee, and (c) paid an RGP service fee for reviewing the redemption report circumstances of requested redemptions. If so, the registration returns to step 6 of Exhibit 27-1 for the renewed term of registration. 
Deletion 
If the registration is not redeemed during the RGP, it proceeds to Pending Delete status in step 36. Here, the lifecycle varies significantly from the standard gTLD registration lifecycle. Instead of a deterministic interval between the end of RGP and the start of deletion, a random, non-published time interval of 1 to 30 days is set for final deletion of the registration. When the random deletion period has elapsed (step 38), the registration proceeds to final deletion from the registry (step 39). 
Registrars found to be engaging in unreasonably repetitive registration attempts of registrations during the Quiet Period (such as attributable to automated processes being conducted by or through the registrar, and not as a consequence of manual availability queries by end users) will be suspended from registry access until the cause of such repetitive attempts are eliminated. 
RESOURCING PLANS 
Costs and procurement of the resources described here are detailed in response to Question 47. 
Human Resources 
See EXHIBIT: ʺ27-Chart-Resourcing.pngʺ. 
ABOUT THIS RESPONSE 
We believe that this answer meets the requirements and addresses all the points of this question: 
* We have provided a complete and detailed statement of the registration lifecycle to be used .
* This lifecycle is substantially the same as the well-understood life cycle in the existing generic top-level domains. 
* This lifecycle is coupled to and consistent with our abuse mitigation policies. 
* We have adequate technical, operational, legal, and financial resources to handle this lifecycle. 

The registry operator will take the appropriate technical and operational steps required to limit domain abuse, promote WHOIS accuracy and to remove out-dated and inaccurate data. 

WHOIS accuracy will be enforced via the Registrar-Registry agreement and will include requiring the completeness of WHOIS information. Technical measures to deter WHOIS abuse will include Implementing measures to deter WHOIS abuse, including rate-limiting, data syntax validation, enforcing requirements via the Registrar-Registry agreement. 

The Anti-Abuse policy will be posted on the Registry website and will include clear definitions on abuse and provide a point-of-contact for reporting suspected abuse. Repeat violations of the abuse policy will be dealt with on a case-by-case basis and the registry operator reserves the right to levy sanctions .
Procedures will be published and maintained for the removal of orphan glue records for names removed from the zone.


Anti-Abuse Policy

The Anti-Abuse policy will be effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The registry operator definition of abusive use of a domain includes, but is not limited to:

* Child endangerment: The use of domains that promote the exposure of children to psychological, emotional or physical abuse.
* Botnet command and control: Services originating from a domain name that are used to control a collection of compromised computers or which is used to direct a distributed denial-of-service attack;
* Phishing: The use of counterfeit web pages that are designed to miss-represent and fraudulently obtain sensitive data such as usernames, passwords or financial data;
* Pharming: The redirecting of unsuspecting users to fraudulent sites or services, typically through DNS hijacking or cache poisoning;
* Spam: the use of electronic messaging to send unsolicited bulk messages. This includes, but is not limited to, email, instant messaging, mobile messaging and social network sites.

Pursuant to the Registry-Registrar Agreement, registry operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. Registry operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute. 

The policy will be accompanied by procedures for the submission of a policy related complaint to the registry operatorʹs abuse point of contact.

Abuse point of contact and procedures for handling abuse complaints.

The registry operator will establish an abuse point of contact. This contact will be a role-based e-mail address in the form abuse@registry.TLD, where TLD is the TLD string applied for in this application. For tracking purposes the registry operator will have a ticketing system with which all complaints will be tracked internally. The use of a ticketing system permits multiple staff members to monitor abuse reports on a 24x7 basis and work towards closure of the issue as each case requires.

The registry operatorʹs designated abuse handlers will evaluate complaints and will decide, on a case by case basis, whether a particular issue is of concern, and decide what action, if any, is appropriate.

Assessing abuse reports requires a high level of expertise in such matters. The goals of the registry operator are accuracy, consistent record keeping and zero false-positives. 

For the most part, there are two types of domain abuse that must be addressed:
1. Malicious Registrations. These domains are registered for the purpose of abuse and are targets for suspension since they have no legitimate use. 
2. Compromised domains. These domains have been hacked or otherwise compromised and the registrant is not responsible for the malicious activity. The goal in such case is to get word to the registrant that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner.

The standard procedure will be to forward a credible alleged case of malicious domain name use, along with any supporting evidence, to the domainʹs sponsoring registrar with a request to investigate the case and act appropriately. 

The registrar is the party with a direct relationship with the registrant and has information about the domain that is not available to the registry operator. This may include payment records, additional identifying information such as IP address and possibly past sales history. Much of this information is not shared with the registry operators due to privacy laws and liability concerns. The registrar will determine whether the alleged abuse violates either the registry Anti-Abuse policy or the registrarʹs own terms of service. 

Registrars will be expected to include language in their own terms of service to reference both the registryʹs and ICANNʹs policies and to include language that will permit the suspension or cancellation of a domain name. 

Should a registrar not take action within 48hrs, the registry operator may decide to take action itself. The registry operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

The registry operator reserves the right to call upon relevant law enforcement bodies as needed and will comply with valid court orders or seizure warrants from courts or law enforcement agencies of relevant jurisdiction. 

Removal of orphan glue records

A glue record is a artefact of the DNS system and are necessary to guide iterative resolves to delegated nameservers. A record becomes an orphan when its parent nameserver record is removed without also removing the glue records. 

An orphan glue record may be created when a domain is placed on EPP ServerHold or ClientHold. In this case the orphan must remain in place should other innocent sites also be using the affected domain as a nameserver.

In the case where there are no longer other domains using the orphan, it should be removed.

In keeping with ICANN SSAC recommendations, the following procedures will be followed with respect to orphan glue records.

When a request to a delete a domain is received from a registrar, the registry first checks for the existence of glue records. If no glue records exist, the request to delete the domain will be accepted. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If no other domains are using the glue records, the glue records will be removed and the request to the delete the domain will be accepted. If other domains are using the glue records then the request to delete the domain will fail until no other domains are using the glue records.

The registry operator will accept and evaluate complaints about the malicious use of orphan glue records. These requests must be made in writing and submitted via the registry operators abuse point of contact. 

Promoting WHOIS Accuracy

The primary conduit for the promotion of WHOIS accuracy will be the registrar-registry agreement. 

The registry operator will be requiring base level of WHOIS verification on every domain registries. This will include fully populated data and basic syntactical checking of the data. 

Abuse Prevention and Mitigation Resourcing

Costs and procurement of the resources described here are detailed in response to Question 47. 

28.2.1. Human Resources 

See EXHIBIT: 28-Chart-Resourcing.png 
The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23. 
The accompanying chart shows the human resources allocated to the functions depicted in this response. 
FAITID maintains retainer relationships with two attorneys having extensive experience in internet matters, who will be responsible for reviewing and authorizing response to any abuse incident, report, or law enforcement or court action requiring legal review such as jurisdictional analysis. At any time, at least one of these attorneys shall be ʺon callʺ to immediately address such incidents as circumstances warrant. 

The registry operator is committed to a system of Rights Protection Mechanisms (RPMs) and Dispute Resolution Mechanisms (DRMs) listed in Specification 7.
1. SAFEGUARDS FOR RIGHTS PROTECTION AT THE LAUNCH OF THE TLD 
The registry operator is committed to a series of rights protections mechanisms at launch such as Sunrise, use of the Trademark Clearing House, and the operation of a Trademark Claims Service that supports the defined ICANN process for checking a registration request and alerting trademark holders of potential rights infringement. 
Launch outline
The Registry intends to offer the following launch model.
Sunrise A (favouring trademarks)
Sunrise B (favouring holders of certain business names)
Landrush (seeking to sell premium names)
General Availability (steady state pricing)
Sunrise
The Sunrise process is separated into two phases: 

* Sunrise A provides priority for eligible trademark owners to obtain domains corresponding to those trademarks including Russian trademarks.

* Sunrise B provides priority for certain other rights holders or entities to obtain relevant domains and will include business names, appellations of product origin, and non-profit entities related to the City of Moscow. 

The registration process during Sunrise is on a first-come, first-served basis.

The Registry will publish full details of its Sunrise policy and eligibility. What follows is an outline of the policy with some key definitions. To be eligible to submit a REGISTRATION REQUEST under Sunrise A (trademarks), a Sunrise APPLICANT must comply with the SUNRISE ELIGIBILITY REQUIREMENTS.

Sunrise definitions
The policy will be based inter alia upon the following key definitions.

ELIGIBLE. 
A trademark or service mark conforming to the SUNRISE ELIGIBILITY REQUIREMENTS (SERs).

OWNERSHIP. 
Ownership of an ELIGIBLE trademark may mean owner, co-owner or assignee. 
For an assignee, the PROVIDER may request appropriate evidence that the assignment has taken place, and meets the legal requirements to be an effective assignment in the jurisdiction in which the mark is registered.
For a co-owner, the PROVIDER may request appropriate evidence that the co-owners have joined in the application.
Any dispute will be decided upon by the PROVIDER.

PROVIDER. 
An independent entity or entities appointed by the Registry to provide certain rights protection services which may include inter alia verification, validation, and dispute resolution related to eligibility of trademarks.

REGISTRATION REQUEST. 
An application submitted by an ACCREDITED REGISTRAR on behalf of an APPLICANT to register a name in the TLD.

SUNRISE DISPUTE RESOLUTION POLICY.
The REGISTRY will operate a Sunrise Dispute Resolution Policy either itself or via the PROVIDER full details and the fees for which will be published on the REGISTRY WEBSITE.

The policy will allow challenges based on the following grounds: 
(a) at the time the challenged domain name was registered, the domain name REGISTRANT did not hold an ELIGIBLE trademark; 

(b) the trademark registration on which the domain name REGISTRANT based its Sunrise registration is not ELIGIBLE;

(c) the domain name is not identical to the trademark on which the domain name REGISTRANT based its Sunrise registration;

(d) the REGISTRATION REQUEST which led to the award of the domain name was in some way incorrect, misleading or fraudulent.


SUNRISE ELIGIBILITY REQUIREMENTS (SERs).
These are cumulative. 
(a) OWNERSHIP of a word mark registered in the Trademark Clearinghouse;
OR OWNERSHIP of a word mark of national or regional or international effect registered in one of the states or entities under international procedure, and active or registered in Russia, that is in full force and effect at the time of submission of the REGISTRATION REQUEST, and at the time of Registration of any awarded name, and for which acceptable evidence of USE in the class for which it is registered is provided;
OR OWNERSHIP of a word mark that has been court-validated; 
OR OWNERSHIP of a word mark that is specifically protected by a statute or treaty currently in effect and that was in effect on or before 26 June 2008; 

(b) a word mark which directly corresponds to the name in the REGISTRATION REQUEST; 

(c) an affidavit signed by the APPLICANT: 
(i) that the information provided is true, correct and complete;
(ii) that no pertinent information has been withheld;
(iii) that acknowledges the fact that if there is any information withheld, that it automatically results in the loss of rights in any domain name(s) acquired, or the loss of the right to seek to register same;
(iv) that the application is compliant with the relevant Sunrise requirements;

(d) provision of data conforming to the SUNRISE INFORMATION REQUIREMENTS sufficient to document rights in the trademark;

(e) is not a word mark that includes the STRING as a portion of the trademark; 

(f) is not a trademark for which an application for registration has been filed, but is not actually registered;

(g) is not a trademark for which an application has lapsed, been withdrawn, revoked, or cancelled;

(h) is not an unregistered trademark including such common law marks; 

(i) is not a U.S. state trademark or service mark or a U.S. supplemental registration;

(j) is not an international application for the registration of trademarks, made through the Madrid system, unless based on or have resulted in a registered trademark of national effect; 

(k) is not intellectual property other than a word mark such as rights in a sign or name, including domain names, trade names, and appellations of origin.

(l) is not a trademark registration that came into full effect after the effective date of the Registry Agreement;

(m) is not a trademark registration that was applied for after the 1 May 2012 being the date at which ICANN announced the applications received.

One key objective of the SERs is to facilitate marks registered and used in good faith and not merely as a means to register a domain name.

SUNRISE INFORMATION REQUIREMENTS.
APPLICANTS in Sunrise A must submit the following information, either in an ACCEPTABLE ELECTRONIC FORMAT or via a link to the relevant database of the trademark registry, as part of a REGISTRATION REQUEST:

EITHER 1: the Trademark name and its corresponding Trademark Clearing House identity number;

OR 2 all of the following:
(a) the trademark corresponding to the name to be Registered;
(b) the country, region, or organization found in WIPO STANDARD ST.3 in which the trademark is registered;
(c) the current registration number of the trademark;
(d) the date on which the trademark application was submitted
(e) the date on which the trademark was registered;
(f) the class or classes under the latest publication of the Nice system (or its equivalent) for with the trademark is registered; and
(g) the status of the APPLICANT being one of owner, co-owner, or assignee of the trademark.

USE. Acceptable evidence of use will be a signed declaration and a single specimen of current use, which might consist of labels, tags, containers, advertising, brochures, screen shots, or something else that evidences current use in the relevant jurisdiction, provided in an ACCEPTABLE ELECTRONIC FORMAT. 

The form of the signed declaration will be as follows. 
ʺI⁄We [name of applicant] declare that I⁄we have used the trademark [name of work mark] since [date] in [country] on [state goods or services] and attach a sample of [type of sample] as evidence.ʺ

Landrush 
Landrush is a period designed to allocate by price domain names that may be regarded by the market as desirable (premium names). Domain Names are offered via a step by step price reduction. During Landrush the price of a domain name falls each Landrush incremental period (such as a day) until it reaches the General Availability price. Names are awarded first-come first-served.

To be eligible for Landrush an applicant must AFFIRM COMPLIANCE with the POLICY of the REGISTRY.

An applicant may submit one or more REGISTRATION REQUESTS during Landrush for any available name.

The registry operator reserves the right to reserve domain names it deems necessary for the registry operation. 

General Availability
General Availability starts at the close of Landrush. Domain names are available at fixed prices (via Registrars) on a first-come first-served model.

2. ON-GOING RIGHTS PROTECTION MECHANISMS
The Registry will conform to all ICANN RPMs defined in Specification 7 of the new TLD agreement including UDRP, URS, PDDRP, RRDRP.

Uniform Domain-Name Dispute-Resolution Policy (UDRP)
FAITID will require registrars to incorporate the UDRP into the terms of registration of second level domain names, just as all existing ICANN-accredited registrars already are required to do so by the ICANN Registrar Accreditation Agreement. 

The UDRP, by its own terms, does not require registry involvement; however, FAITID is aware that occasional issues relating to registrar compliance with the UDRP have arisen, which typically have led to de-accreditation of registrars found in habitual non-compliance. FAITID will receive and act on any communications received from ICANN registrar compliance personnel indicating registrar non-compliance with the UDRP. In the event of a registrarʹs failure to comply with the conditions of the UDRP, and in the absence of factors such as litigation filed under UDRP 4(k) (under which names are not to be transferred upon filing of a court action in the UDRP Mutual Jurisdiction), FAITID will re-assign the domain name(s) in question to a compliant registrar with which the transferee has established an account, and may charge, suspend or de-accredit the non-compliant registrar in accordance with the schedule of incentives and penalties set forth in the response to Question 28. 


Uniform Rapid Suspension (URS)
FAITID will require registrars to incorporate the Uniform Rapid Suspension System (URS) into the terms of registration of second level domain names. The URS requires that domain names subject to suspension will resolve to a designated web page until the domain name expires. FAITID will receive and respond to URS determinations by updating and locking the nameservers for a domain name subject to suspension to designated servers which will resolve the domain name to the requisite web page indicating that the domain name has been suspended (or other terminal status the URS, subject to ICANN Consensus Policy or Board action may require). 

FAITID will receive and act on any communications received from ICANN registrar compliance personnel indicating registrar non-compliance with the URS. In the event of registrar failure to comply with the conditions of the URS and in the absence of factors such as litigation filed in a competent jurisdiction (under which names are not to be disabled upon filing of a court action in the URS Mutual Jurisdiction), FAITID will re-assign the domain name(s) in question to a compliant registrar, and may charge, suspend or de-accredit the non-compliant registrar in accordance with the graduated penalties discussed in the response to Question 28. 

At present, ICANN has projected a cost of US $300 for URS disputes. However, no presently ICANN-accredited dispute resolution provider has confirmed that it can provide URS services at that price. In the event that ICANN-accredited dispute resolution providers cannot provide URS services in the indicated price range, FAITID will contract with a URS provider in consultation with leading experts in domain dispute procedures, which can provide competent determinations of the type of clear violations which the URS is intended to address, to ensure a low cost advisory, mediation or suspension mechanism. 

Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and Registration Restriction Dispute Resolution Procedure (RRDRP). 
The Registry will implement appropriate procedures to comply with the above. 
Protection Rights via the RRA
The following will be made binding via the Registry-Registrar and Registrar-Registrant Agreements. 

The Registry may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:

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

Reducing Opportunities for behaviours such as phishing or pharming
The registry operator has described its anti-abuse policy and procedures in Question 28. Please refer to our response for full details.

Since all criminal activity is precluded by the policies of the registry operator, it is not expected to be a problem and the registry operator is prepares to take prompt and effective steps to eliminate the activity.

This approach addresses registered domain names and will not infringe upon the rights of eligible registrants to register domains. It provides for the use of internal controls as well as community-developed policies (UDRP, URS) to deal with any complaints.

3. RESOURCING PLANS
See EXHIBIT: ʺ29-Chart-Resourcing.pngʺ for information on the human resources assignment. 

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23. The accompanying chart shows the human resources allocated to the functions depicted in this response. 

FAITID maintains retainer relationships with attorneys having extensive experience in internet matters, who will be responsible for reviewing and authorizing response to any incident, report, or law enforcement or court action requiring legal review such as jurisdictional analysis. 

* 1 REGISTRY SECURITY POLICY: SUMMARY 
o 1.1 Physical Security
o 1.2 System Security
o 1.3 Network Security
o 1.4 Service Security
o 1.5 Data Security
o 1.6 Security Monitoring
o 1.7 Attack Mitigation
o 1.8 Personnel Policies
o 1.9 Security Incident Response
* 2 INDEPENDENT ASSESSMENT ON SECURITY CONTROLS
* 3 ABOUT THIS RESPONSE
REGISTRY SECURITY POLICY: SUMMARY 
In order to provide end-to-end privacy and security, the Registry Service is built in accordance with recognized best practices in architectural and operational security, providing security at each level in the design and deployment. Confidentiality, integrity, and availability of registry data is of the utmost importance to us. We intend to maintain user trust and confidence. 
Our Registry commits to its registrants that their registration information will always be kept appropriately secure according to ICANN policy, that reliable global DNS service will always resolve the registered names, and that all changes to registration will be properly authenticated. To meet these promises, we have minimum threshold levels of physical, network, system, service, and data security. The policies summarized here outline the thought and principles behind our security. 
In broad terms, the ISC Registry Security Policy begins with the provision of multi-layered ʺDefense In Depthʺ for every element of the Registry, including: 
* Physical Security 
* Network Security 
* System Security 
* Service Security 
* Data Security 
Augmenting these defenses are mechanisms to detect Security Events, including: 
* Centralized Logging and Log Analysis 
* Network Aberration Alerting 
* System Integrity Analysis 
Our systems are highly redundant and are architecturally arranged to limit the effect of security events. 
Should a Security Event occur, a set of Attack Mitigation mechanisms will be triggered. 
For purposes of data recovery, forensic reconstruction, and event analysis we maintain deep backup, transaction journals, and audit trails. 
We have a formal Security Incident Response Plan in place to resolve each incident. We subsequently review and evaluate our response to learn where we can make improvements. 
Physical Security 
All registry servers are housed in carrier grade, first-tier dedicated data center spaces that are secured and monitored 24x7 by the data center vendor (by video surveillance and⁄or by guard patrols). Access is secured by an access control list, and requires a biometric scan (hand or retina) for entry. Only our own staff members are permitted to have physical access to the equipment hosted in these facilities. 
Our contracts with data center vendors must all require that we be quickly notified if there is suspicious activity or an event that affects our equipment or networks. 
System Security 
The computer systems used by both Registry Services and SNS are enterprise-class servers running an appropriate operating system software. Maintenance of these systems follows industry standard best practices, including regular security updates, configuration management, and backups. Configuration requirements include running only the minimal set of services that are required, local firewalling, and per-user change tracking. Remote administration of the systems is done by a limited set of authorized staff, using secure channels with limited points of network ingress. Only authorised ISC employees may have any form of access (physical or administrative) to Registry systems. 
The computer systems used by both Registry Services and SNS use operating systems and applications software that have a high resistance to computer viruses or ʺrootkitsʺ. 
Business office systems, which are more vulnerable, are protected by industry best practice anti-virus tools as well as by procedures to reduce system exposure or limit the introduction of viruses. 
Network Security 
The network elements used by Registry Services are carrier-grade routers, switches, and load balancers. These elements are hardened against attack according to industry and ISC best practices. They are managed by expert certified network administrators. Configuration data is replicated and archived centrally. Changes are logged per user. Remote administration of the network elements is done by a limited set of authorized staff, using secure channels with limited points of network ingress. Only ISC employees or carefully-vetted contractors can have any form of access (physical or administrative) to Registry systems. In case of emergency, police and fire officers may be permitted access, duly documented and monitored by the data center staff. 
In addition to securing the network elements themselves, dedicated or embedded firewalling capabilities are used to ensure that only authorized and appropriate network traffic reaches the registry systems. Should elevated or atypical network traffic be detected, appropriate notifications will be made to the monitoring system. Every system is monitored, and all monitoring data is centrally gathered and logged. 
Service Security 
Access to the SRS service is permitted only to those registrars that have current signed agreements with the TLD operator. Registrars will provide a list of IP addresses to be permitted to connect to the EPP servers. No connections are permitted from unauthorized client addresses. In addition the system uses SSL-based certificates to establish secure TCP connections, allowing the client and the server to authenticate one another, before supplying a mandatory user⁄password combination to authenticate an EPP session. 
Services that are exposed to the Internet such as Whois, and DNS, are designed and deployed with secure techniques that prevent data from unauthorized alteration. 
Tiered access services, such as the RESTful Whois interface, use SSL encryption for transmission of all sensitive information, such as passwords, or privileged information. 
Data Security 
While the DNS zones created by the registry from registrantsʹ submissions are publicly visible data, a need might evolve to keep some data private. Our system is ready for this eventuality. All data (whether private or not) is secured during network communication by end to end encryption. The integrity of public DNS data is ensured through the use of cryptographic shared secrets for all internal transfers. Once on the servers, regular backups are made to ensure no data is lost, and copies of backups are replicated to geographically distant data centers. Backups are encrypted, and copies of those encrypted backups will be in secure locations. 
Security Monitoring 
Despite security-oriented design and hardening, it is inevitable that any service provided on the Internet will receive unwanted traffic. It is critical that the SNS and Registry systems be able to detect anomalous traffic, and to correlate events across multiple elements to alert operators and provide key data to differentiate between increased benign traffic and a true attack. The SNS and Registry systems perform this functionality via centralized logging and analysis, detection of anomalous traffic by the network elements, and application-specific alerts. Additionally, all servers are regularly scanned for unauthorized code, and the entire system is periodically swept with network scans. The Registry Operations Center is responsible for determining the frequency of such scans and sweeps, but never less frequent than once per calendar quarter. 
All security information is received by, and distributed by (as needed), the help desk⁄call center and the Registry Operations Center. Any distribution of security-related information outside the Registry Operator must be via the Registry Operatorʹs corporate management and not by any operations personnel except with explicit per-case specific approval by corporate management. 
Attack Mitigation 
Industry best practices are used to mitigate the effect of any attack. Such mitigation includes topological containment of the attack (isolating it to some portion of the network) and service continuity using alternate servers or sites. 
Significant over provisioning, load balancing, and firewalls are used to dilute, divert, and deflect the force of brute force attacks. Anycast routing limits the scope of attacks on our name server infrastructure. 
Personnel Policies 
Registry operations personnel are all subject to background checks. 
Job duties are arranged, and supported by data⁄system access constraints, so that no person has more access than is needed for the performance of their job duties. 
We will have an employee handbook that will define employee duties and obligations. Employees will have to assent, in writing, to that handbook at least once a year. 
Consultants, contractors, and other third parties will be required to enter into an appropriate Non Disclosure Agreement that will define their duties and limitations. 
Security Incident Response 
Should a Security Event be detected or reported, the Registry System Security Response Plan will be triggered. This plan defines formal roles for staff, a process for technical analysis of the event, proper communications procedures and event resolution. 
INDEPENDENT ASSESSMENT ON SECURITY CONTROLS 
The registry platform, policies and procedures following industry best practices and sound commercial guidelines to ensure the highest levels of commercially reasonable security. This encompasses as a minimum: Physical Security, System Security, Network Security, Service Security and Data Security. The fact that we are beginning as a registry operator with a clean slate allows for the application of best-practice policies and controls from day one. 
That said (and regardless of the level of preparedness shown in the design and implementation of our policies and security controls), it is impossible for any newly formed entity beginning its duties as a registry operator to present an effective, meaningful and Independent Assessment of the effectiveness of security controls; as this is an area that needs to be evaluated on a day to day basis - based on operations which in our case, have not yet begun. 
ABOUT THIS RESPONSE 
This answer is extended in our answer to question 30b.