ICANN New gTLD Application

Q18b
How do you expect that your proposed gTLD will benefit Registrants, Internet users, and others?

The Applicantʹs primary intention is to provide a favorable ecosystem for the growth and evolution of the sector. The key to achieving this aim are significant provisions for brand integrity and protection of intellectual property. The Applicant intends to push the boundaries of what can be done through innovative design of the new top level domain, including technologies that capitalize on the sectorʹs needs. A close relationship with the sectorʹs stakeholders is essential to this purpose, and will enable .men to grow in response to both Registrant and user needs. The gTLD also contains significant opportunities as a next generation organizational scheme for online content, including provisions for abuse prevention to defend users against malicious registrations. The gTLD has been meticulously designed by a team of industry leaders from an array of different fields. This has enabled the creation of an airtight financial strategy, an inspired technological development plan as well as a close and dynamic relationship with the sector community - all critical needs on the path to the enduring success of the gTLD.

18(b)(i) What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation?

Specialty

The Applicant’s key specialty goal is to enable a secure and stable gTLD dedicated to providing global Internet users with a targeted space for subject matter of interest. This gTLD will serve as a home for both Registrants and end-users who feel an affinity with this sector and its associated content. Consequently they will prefer to register domain names, create and post content and seek information in a highly targeted manner.

Allowing users the ability to create a targeted, unique space within the new gTLD will enable them to customize their online offering and presence. The .men gTLD will by itself clearly signal the nature and purpose of such websites to Internet users.

The applicant intends to actively promote gTLD specific vertical searching in the gTLD for the benefit of Registrants, end-users and other stakeholders. This specialization through Vertical Search will also benefit Internet users seeking authentic online information and products or services as they will no longer have to wade through content completely unrelated to their desired results.

As the gTLD is sector specific it will provide a better context for second level strings allowing for a much higher number of relevant and more conscise domains. This more targeted environment will simplify the user experience across multiple platforms specifically with smartphones and tablets where minimal input is favoured.

Service Levels

The goal of the gTLD Registry is to offer domain name registration services of the highest level, exceeding both ICANN requirements and current sector norms. To achieve these goals, the Applicant has contracted with well established, proven service providers offering the highest possible level of quality in Registry and Registrar services. The expertise of the service providers will ensure that the security and quality of the gTLD will be uncompromised.

The Applicant will further provide the highest level of service to trademark, legal rights owners and second-level domain owners. To achieve this goal the Applicant will be implementing a range of Abuse Prevention and Mitigation policies and procedures. The Applicant is also firmly committed to the protection of Intellectual Property rights and will implement all the mandatory Rights Protection Mechanisms (RPMs) contained in the Applicant Guidebook. Aswell as these The Applicant will further protect the rights of others through the implementation of additional RPMs. The RSPʹs experience will ensure that the gTLD provides this high level of service to trademark and other legal rights owners to combat abusive and malicious activity within the gTLD.

The Registry will respond to abuse or malicious conduct complaints on a 24⁄7⁄365 basis, respond to requests from governmental and quasi-governmental agencies and law enforcement in a timely manner, and promptly abide by decisions and judgments of UDRP and URS panels, in accordance with ICANN consensus policies.

The Applicant will also provide fast and responsive (24⁄7⁄365) customer support to both Registrars and end-users in a number of languages to assist with general enquiries as well as complaints of abusive or malicious conduct.

Service Levels related to Registry Backend Services

The Applicant will work with ARI Registry Services Inc. (hereinafter “RSP”) whose extensive experience spans more than a decade. This will ensure delivery of the protected, trusted, and permanently-running Registry infrastructure necessary to reliably host and operate a gTLD. The Applicant will also work with its Registrars to ensure that consumers receive secure, fast, and reliable domain name registration services with a high-level of customer service.

The global DNS network that will be utilised for the resolution of domains in this gTLD has already been operating for over 10 years. It currently delivers DNS resolution for several TLD customers and provides low latency query responses with a 100% DNS uptime service level agreement.

The Applicant will further leverage the RSP’s existing DNSSEC infrastructure, capabilities, and experience to provide a robust and standards compliant implementation that ensures DNSSEC services are always available as part of the DNS.

The Shared Registry System (“SRS”) to be used for the Applicantʹs gTLD is a production-proven, standards-based, highly reliable and high-performance domain name registration and management system that has been designed to operate at the highest performance levels. The Applicantʹs RSP has been able to meet or exceed their SLA requirements nearly every month since itʹs inception. Their Registry has achieved a 99.997% success rate in meeting SLAs since 2004.

The Applicantʹs RSP has extensive experience providing ICANN and RFC-compliant WHOIS services for each of the gTLDs that it operates as a Registry Operator for both gTLDs and ccTLDs. The RSPʹs thick WHOIS solution is production proven, highly flexible, and scalable with a track record of 100% availability over the past 10 years.

The Applicant will comply with all the data escrow requirements documented in the Registry Data Escrow (“RyDE”) Specification of the Registry Agreement and has a contract in place with Iron Mountain Intellectual Property Management, Inc. (“IM”) for RyDE Services. The Applicant and its RSP will in conjunction with Iron Mountain work to ensure that the escrow deposit process is compliant 100% of the time.

Reputation

The Applicant will ensure that the Registry enjoys an excellent reputation through its core focus on creating a secure, sustainable, and specialized gTLD, thus supporting ICANN’s primary goals for the new gTLD program in promoting consumer trust, consumer choice, competition and innovation.

The Applicant will strive to become a reputable and successful new gTLD by providing secure, fast and reliable customer service throughout the registration life cycle of all domains in the gTLD.

The Applicant will endeavour to ensure that only non-fraudulent Registrants have domain names in the gTLD via a WHOIS that is searchable, thick and reliable and by being highly responsive to complaints from legal rights owners. The Applicant will further implement an industry leading range of Abuse Prevention and Mitigation policies and procedures as well as RPMs.

The Applicant will provide the financial and operational stability to protect Registrants and ensure the reputation of the Registry. The Applicant has estimated the maximum costs of the critical functions for a three year period by taking the largest single year cost estimate (year 5) and multiplying this by 3. If the calculation used a lower figure the costs estimate would not be at the potential highest amount during the 5 years and the COI instrument would be too small in order to fund the costs of the 5 critical functions for at least 3 years.

The Applicant has decided to commit to providing the highest level of protection to Registrants and Stakeholders by providing ICANN with a COI for the maximum amount as recommended by ICANN in its COI Guidance. This ensures the Registry is reputable, remains conservative and mirrors ICANN’s core objectives. In a worst case scenario where the Applicant will not receive any revenue Registrants will be protected not only by the COI, but also by the fact that the Applicant has enough capital to operate for over 3 years.

Question 18(b)(ii) What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

It is expected that .men will provide significant competition for existing and forthcoming gTLDs. The .men gTLD will provide a blank canvas of second level domains that will inevitably lead to increased consumer choice and significant innovation from the sector. It will allow Registrants to seek new and varied ways to separate themselves from the competition.

Competition

The Applicant will enhance competition by allowing new Registrants to create new online products and services serving the global marketplace and connecting geographically diverse Registrants and users with a common affinity for the specialized subject matter exemplified by the new gTLD. The new gTLD process and its resulting gTLDs are likely to incentivize top-level domains to improve the security and quality of their online products and services as well as introducing new ones. Thus, this gTLD will benefit consumers by increasing the likelihood of new innovative online products and services.The addition of a new gTLD such as .men will also increase competition between existing registries.

The Applicant will promote competition to the benefit of the Registrants by amongst other things:

- Building a healthy growth trend of domain registrations to validate the specialty space
- Promote the migration of sector relevant content from other TLDs
- Maintaining competitive pricing of domains

Differentiation

Currently, there is no gTLD available on the Internet that signifies the specialized products, services, and subject matter encompassed by this gTLD. The gTLD string itself will give a clear indication to website visitors that the site has content relevant to the sector. This will result in the gTLD becoming globally recognizable and viewed as a trusted source of goods, services and information.

Innovation

The gTLD will demonstrate innovation through cutting edge RPMs.

Firstly the Applicant considers the Protection of Intergovernmental Organization (ʺIGOʺ) names to be very important. The Applicant will use strings registered as second level domains in the .int gTLD as the basis for this protection. To register in the .int domain, the Registrants must be an IGO that meets the requirements found in RFC 1591. The Applicant will reserve these strings and only allow for their future release if an IGO on the “reserve list” wishes to make use of the protected string in the gTLD and provides the Applicant with sufficient documentation.

Finally if a Registrant during sunrise and landrush applies to register a domain name identical to a capital city name of a country or territory listed in the ISO 3166-1 standard it will receive a Capital City Claims (“CCC”) notification stating this. Subsequently they will have to reply unconditionally agreeing to comply with requirements to protect the reputation of the capital city and any further terms.

These functions will enhance Internet stability, security and will demonstrate to Registrars, Registrants, and end-users of the Registry that abusive or malicious conduct will not be tolerated. They will further contribute significantly to the integrity of the gTLD enabling an environment where stakeholders can innovate with confidence.

Question 18(b)(iii) What goals does your proposed gTLD have in terms of user experience?

The Applicant’s goals for the new gTLD are to provide a trusted, secure, and user friendly environment whereby domain names and content relating to its specific affinity group can flourish.

The Applicant believes that the success of the gTLD will be determined by the sector’s key stakeholders globally. The Applicant believes that stakeholders should have the opportunity to influence the gTLD and the way it is governed. Accordingly, the Applicant is establishing a Governance Council (“GC”), to serve as an advisory body.

.men will be developed with consumer trust, choice and satisfaction in mind and after the initial 2 years, the Applicant will conduct a survey to analyse the gTLDʹs success in these areas to help further improve the user experience.

To ensure a high level of service the Applicant will further measure:

- Service Availability Targets for the Critical Registry Functions
- The number of abuse incidents and takedowns
- ICANN Compliance
- Rights protection incidents (i.e. UDRP and URS)
- WHOIS data accuracy

The Applicant intends to promote consumer choice by providing the following:

- Highly available and geographically diverse Registrar distribution channel;
- Effective sunrise and trademark services.

Question 18(b)(iv) Provide a complete description of the applicantʹs intended registration policies in support of the goals listed above.

Registration Policies

The purpose and goal of the Applicant’s policies are to ensure competition, fairness, trust and reliability for Registrars, Registrants, the user community, and other stake holders, while maintaining security and stability for the gTLD.

General Policy

Aside from certain start-up mechanisms, all domain names will generally be registered on a first-come, first-served basis. A Trademark Claims service will be offered for the first 90 days of general registration, with the intent of providing clear notice to potential Registrants of the existing rights of trademark owners with registered trademarks in the Trademark Clearinghouse.

Registration Policies

As per ICANN’s requirements, the Applicant will be operating both a Sunrise and Landrush period ahead of general availability for the gTLD.

Governance Council

The Applicant is establishing a the GC, to be comprised of key sector stakeholders that will serve as an advisory body. Each GC will elect its own Board of Directors, which will be responsible for self-governance, the recommendation of sector-specific registration policies,the formulation of guidance on intellectual property and other best practices related to the gTLD.

The Applicant aims to develop an Abuse Prevention and Mitigation Working Group in conjunction with the GC. It will give the Applicant’s team advice on abuse preventions and mitigation and how this may effect registration policies. The group will meet to regularly discuss the latest trends in domain name abuse and the most effective way to prevent and remedy them.

Question 18(b)(v) Will your proposed gTLD impose any measures for protecting the privacy or confidential information of Registrants or users? If so, please describe any such measures.

Data and Privacy Policies

The Applicant shall comply with all the Data, WHOIS, and Privacy requirements in the Applicant Guidebook required by ICANN. The Applicant will take all possible steps to maintain the security and privacy of information or data that it may collect in connection with the planned function and usage of names domains, and will remain in compliance with all confidentiality and security regulations in relevant jurisdictions. This data will be held by the Applicant in accordance with the Registry Agreement that the Applicant will execute with ICANN.

The Applicant has further ensured that its suppliers also understand that keeping information secure and private is of crucial importance and will take all available steps to maintain the security and privacy of information collected from the Applicants in the Sunrise, Landrush and General Availability Phases.

Question 18(b) Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

The Applicant plans on making the gTLD the premier gTLD where individuals and organizations can register, build and maintain websites relating to their specific interest area. Thus, communication with the public and development of an outreach campaign are important goals in connection with the gTLD.

During the gTLD evaluation process, the Applicant plans to conduct a two-to-three month communications campaign aimed at reaching sector stakeholders and informing them of the gTLD’s mission and the opportunity to participate in the GC. The communication outreach will include email communications to hundreds of leading sector organizations. It will also be accompanied by the launch of a website for communicating information about the gTLD and allowing interested members of the related sector to express interest in serving on the GC. Other communications efforts, including but not limited to, press releases and social media campaigns may all be initiated to raise further awareness regarding the gTLD.

Shortly after completing the evaluation process and being awarded the gTLD, the Applicant will institute marketing and outreach efforts to inform the public about the new gTLD, its launch schedule, and its intended affinity group. The Applicant will use different outreach and communications methods and venues to get the new gTLD mission and message out to the public, including but not limited to the following: online and print press releases, communications with various media outlets, domain name sector groups, mobile apps and various social media platforms. The GC will be used as a further means of outreach and communication to the Internet community.
-end-

Q18C
What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences⁄costs imposed upon consumers?

The Applicant fully appreciates the concerns of ICANN, the GAC and other consumer protection authorities about the need to operate new gTLDs in ways that minimize social costs, consumer vulnerabilities as well as other time and financial resource costs.  To achieve these goals this gTLD will not only employ the ICANN mandated minimum protections, but will also deploy the following innovative protection measures that will put the gTLD at the forefront of addressing these critical issues:

1) Abuse Prevention and Mitigation Policies and Procedures 

The Applicant’s core mission and purpose is to create an environment where individuals and companies can interact and express themselves in ways never before seen on the Internet, in a more targeted, secure and stable environment. To achieve this goal the Applicant will be implementing a range of Abuse Prevention and Mitigation (ʺAPMʺ) policies and procedures. 

These Policies and Procedures will include: 1) gTLD APM Plan, 2) Policies and Procedures to Minimize Abusive Registrations ,3) Abuse Point of Contact, 4) Policies for Handling Complaints Regarding the Abuse Policies, 5) Acceptable Use Policy (“AUP”), 6) Proposed Measures for Removal of Orphan Glue Records, 7) Resourcing plans for the initial implementation of, and ongoing maintenance of, the APM initiatives, 8) Registry semi-annual WHOIS verification, 9) Regular monitoring of WHOIS registration data for accuracy and completeness, 10) Registrar WHOIS self-certification, 11) WHOIS data reminder process, 12) Establishing policies and procedures to ensure Registrar compliance, which may include audits, financial incentives, penalties, or other means, 13) Registrar verification of WHOIS, 14) Abuse Response Process, 15) Policies and procedures that define malicious or abusive behaviour, 16) Service Level Requirements for resolution regarding APM issues, 17) Service Level Requirements for Law enforcement requests regarding APM issues, 18) Coordination of APM efforts with sector Groups and Law Enforcement, 19) Rapid takedown and suspension, 20) Controls to Ensure Proper Access to Domain Functions, 21) Enabling two-factor authentication from Registrants to process update, transfers, and deletion requests, 22) Enabling multiple, unique points of contact to request and⁄or approve update, transfer, and deletion requests, 23) Enabling the notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted, 24) Additional Mechanism for Protection of Capital City Names, 25) Additional Mechanisms to Protect and Reserve IGO Names, 26) Governance Council Structure, 27) Efforts to increase Registrant Security Awareness, 28) Registrant Disqualification, 29) Restrictions on Proxy Registration Services, 30) Registry Lock. (Q28 for detail)

2) Rights Protection Mechanisms 

The Applicant is firmly committed to the protection of Intellectual Property rights and to implementing all the mandatory Rights Protection Mechanisms (“RPMs”) contained in the Applicant Guidebook and detailed in Specification 7 of the Registry Agreement. Use of domain names that infringe upon the legal rights of others in the gTLD will not be tolerated and preventing abusive registrations is a core objective of the Applicant. The nature of such uses creates security and stability issues for the Registry, Registrars, and Registrants, as well as for users of the Internet in general. The Applicant will minimize time or financial resources costs by preventing abusive registrations and reduce opportunities for behaviours such as phishing or pharming. This will be achieved by implementing comprehensive registration, anti-abuse, and rights protection guidelines as defined in its AUP, as well as innovative additional RPMs such as the Mechanism to Protect IGO Names by blocking second level labels currently present in the .int zone file and the Mechanism for Further Protection of Capital City Names, as described below. In order to identify and address the abusive use of registered names on an ongoing basis, the Applicant will also incorporate and abide by the following RPMs and all other RPMs as specified in Specification 7 of the Registry Agreement and as adopted by the ICANN Board of Directors as ICANN Consensus Policies.

These Rights Protection Mechanisms will among other things include: 1) Trademark Clearinghouse, 2) Applicant’s Sunrise Period, 3) Trademark Claims Service , 4) Uniform Domain Name Dispute Resolution Policy, 5) Uniform Rapid Suspension System, 6) Trademark Post-Delegation Dispute Resolution Procedure, 7) Mechanism to protect IGO Names, 8) Mechanism for Further Protection of Capital City Names, 9) Efforts to promote WHOIS Accuracy, 10) Thick Searchable WHOIS, 11) Semi Annual Audits to Ensure Accurate WHOIS, 12) Policies Handling Complaints Regarding Abuse and Rights Issues, 13) Registry Acceptable Use Policy (“AUP”), 14) Monitoring for Malicious Activity. (Q29 for detail)

3) Governance Council Structure

The Applicant believes that sector stakeholders should be afforded the opportunity to influence the manner in which the gTLD is governed. Accordingly, the Applicant will establish a Governance Council (the “GC”) comprised of key sector stakeholders that will serve as an advisory body tasked with defining best practice recommendations for the gTLD space. The Applicant believes that the success of the gTLD will be determined largely by the sector’s key stakeholders.  Not only will these stakeholders have the primary interest in registering domains in the gTLD, but they will also be motivated to protect the sector from practices that would negatively impact the sector overall. The GC exists to provide guidance on matters related to best practices, intellectual property, authentication, certification, and other matters of importance to the sector and it will elect its own Board of Directors, which will be responsible for self-governance, the recommendation of sector-specific policies, and other best practices related to the gTLD.

4) BITS and Coalition for Online Accountability (“COA”) Recommendations

The Applicant will further structure its policies around the BITS and COA Recommendations where relevant to this gTLD. The Applicant’s goal is to provide a safe and secure experience for consumers. A domain within this gTLD that is owned, operated by or compromised by a malicious party could cause harm to consumers, to the gTLDʹs reputation and to the reputation of the Internet itself. As such, additional controls are in place relating to the validity of registrations, as well as measures to ensure the correct identity of both Registrants and Registrars relating to changes made within the SRS, and to protecting the integrity of the DNS service as a whole.

The Security Standards Working Group (SSWG) formed by BITS drafted a set of policy recommendations that should be applied to financial TLDs. The policy comprises of a set of 31 recommendations that should be adopted by ICANN in evaluating any applicant of a financial gTLD. The recommendations were posted by BITS in the form of a letter to ICANN at [http:⁄⁄www.icann.org⁄en⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf].

The Coalition for Online Accountability have drafted a set of policy recommendations, also endorsed by many other international organizations representing the creative industries, that should be applied to entertainment gTLDs - especially those dependent on copyright protection. The policy comprises of a set of 7 recommendations that should be adopted by ICANN in evaluating any applicant for an entertainment-based gTLD. The recommendations were posted by COA in the form of a letter to ICANN at http:⁄⁄bit.ly⁄HuHtmq.

We welcome the recommendations from BITS and the COA and will strongly consider the recommendations relating to the implementation of this gTLD where considered relevant.

5) Registry Operators Startup Plan

The Applicant proposes to implement the following start-up plan so that the new gTLD is introduced in an orderly, transparent and stable manner. This will safeguard competition, fairness, trust and reliability for Registrants, the User Community, ICANN Accredited Registrars, and other Stakeholders. 
The Applicant’s startup plan is designed to minimize social costs (e.g., time or financial resources costs, as well as various types of consumer vulnerabilities) by instilling a number of RPMs as well as APMs.
The plan consists of the following multi-phase process that will be executed by the Registry Operator. The timeline for the gTLDs start-up process and associated RPMs in the Applicants gTLD is as follows:

Phase 1 – Sunrise Process:

-	Day 1: Sunrise round opens
-	Day 60: Sunrise round Closes
-	Day 61: Sunrise Allocation Including contention resolution mechanisms opens
-	Day 71: Sunrise Allocation contention resolution mechanisms closes

•	The following Rights Protection Mechanisms apply: 
	a.	Trademark Clearinghouse (“TMCH”)
	b.	Sunrise Eligibility Requirements (“SER”)
	c.	Sunrise Dispute Resolution Policy (“SDRP”)
	d.	Uniform Domain Name Dispute Resolution Policy (“UDRP”)
	e.	Uniform Rapid Suspension System (ʺURSʺ)
	f.	Mechanism for the Protection of IGO Names (“PIN”)
	g.	Trademark Claims Service (“TCS”) *

Phase 2 – Landrush process:

-	Day 72: Landrush opens
-	Day 102: Landrush closes
-	Day 103: Landrush contention resolution mechanisms opens
-	Day 113: Landrush contention resolution mechanisms closes

-	The following Rights Protection Mechanisms apply:

	a.	UDRP
	b.	URS
	c.	PIN
	d.	Mechanism for Further Protection of Capital City Names (“CCC”)
	e.	TCS *

Phase 3 – General Availability⁄Registrations:

-	Day 114: General availability begins

-	The following Rights Protection Mechanisms apply:

	a.	UDRP
	b.	URS
	c.	PIN
	d.	Trademark Post-Delegation Dispute Resolution Procedure (“PDDRP”)
	e.	TCS for the 90 days after day 114 *

* To ease the concerns of trademark owners and mitigate the impact of infringing registrations, the Applicant will be implementing the TCS in all three phases of launch. It is important to note that during the General Availability Phase, the TCS will be used for 90 days, 30 days longer than the ICANN mandated minimum.

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

Sunrise and Landrush periods:

During the gTLDs launch period, multiple applications for a particular domain name will be resolved through a Contention Resolution Mechanism (“CRM”) involving auctions. These CRMs will apply to the Sunrise and Landrush application phases. The CRMs will be conducted by Sedo GMBH, an experienced provider of domain auction services. The mechanisms offered will involve closed auctions where only specific bidders can participate.

During the Applicants Sunrise process, if there are two or more eligible applicants for one domain name string, then the contention will be resolved by auction. Auctions held during the Sunrise phase (“Sunrise Auctions”) will be closed and the only bidders will be eligible applicants according to the gTLDs Sunrise eligibility requirements including the TMCH.

During the Applicants Landrush process, if there are two or more eligible applicants for one domain name string, then the contention will be resolved by auction. Auctions held during the Landrush phase (“Landrush Auctions”) will be closed and the only bidders will be eligible applicants according to the gTLDs Landrush eligibility requirements.

General Availability:

After the two initial startup phases of the Registry the allocation of domain names will occur on a first-come first-serve basis, taking into account the registries APM and RPM mechanisms.

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

Incentive, Marketing and Outreach Programs

The Applicant will implement a number of incentive, marketing assistance, awareness and PR programs to assist the Registrar channel in providing a sector leading experience to end-users and to provide cost benefits for registrants. The Applicant will work with the global Registrar channel to ensure that the new gTLD offer is clearly visible on registrar sites resulting in  an increase in the awareness and in the number of new gTLD registrations. Achieving this visibility requires (1) a clear business case and incentives for registrars to motivate them and (2) mechanisms and assets to make it easy for them to do so.

The Applicant will at the time of launch depending upon market conditions consider incentive programs that will deliver cost benefits to registrants through either the use of advantageous pricing, introductory discounts, bulk registration discounts or other similar methods. The Applicant is aware of Specification 9 – Registry Operator Code of Conduct, and will not directly or indirectly show any preference or provide any special consideration to any Registrar in its marketing efforts.

Example incentive mechanisms the Applicant will provide to the registrars may include:

Marketing Incentives

The Applicant intends to provide expertise, tools and creative assets to the registrars as part of general marketing and co-marketing programs. There is a significant cost saving if the expertise, tools and assets are developed centrally and the costs amortized across the registrar base. Significant cost savings can occur relating to Market Research, Social Customer Relationship Management (“SCRM”), Content Management Systems (“CMS”), Direct Marketing Tools, Marketing Collateral and Analytics Solutions. 

The Applicant will employ some or all of the following marketing techniques jointly with registrars globally: (1) Direct Response Print, (2) General Web Marketing, (3) Email campaigns without Incentive, (4) Email with Incentive, (5) Email Marketing - Prospect List, (6) Email Marketing - Sponsored Newsletter, (7) Direct Marketing with Incentive, (8) Web Marketing with Incentive, (9) Viral Marketing (Social, Video, Micro-sites), (10) Develop User Interface Improvement best practices, (11) Develop Search Engine Optimization best practices, (12) Email Marketing - Registrar List
As an example of a marketing initiative, the Applicant will forward leads to the Registrars “buy” pages as an incentive via the means of Pay-Per-Click (“PPC”) search marketing. The Applicant will run multiple PPC campaigns targeting gTLD Registrants and point these to landing pages on the Registrar’s websites.  Conversions are directly trackable from all PPC campaigns and keywords with a high Click-Through-Rate (“CTR”) or conversions will also be leveraged for SEO best practice purposes. 

PR and Awareness Incentives:

In addition to the core outreach to the Registrar Channel, the Applicant will engage in a wider outreach to build awareness of the new gTLD with customers, end-users and other stakeholders. The Applicant will engage with a number of high profile individuals associated with the gTLD and will seek to reach end consumers through webcasts, podcasts, traditional broadcast TV as well as radio.

Provision of customer retention toolkits to Registrars:

The Applicant will use propensity modelling to build retention marketing programs to minimize churn whilst building renewal sustainability. The Applicant will develop econometric models designed to measure the likelihood of a customer segment to purchase a product or offer bundle, at a certain point in the relationship lifecycle. They are used to predict the best time, and the best combination of products, to offer to customers who match a certain profile. They are especially effective where there are large numbers of customers and reliable data can be gathered. The Applicant expects that registration volume in the gTLD will provide sufficient data for this modelling.

Measure, benchmark and improve the customer experience:

The Applicant will engage in a program to develop best practice policies related to the customer experience at differing levels of the channel. This will include the entire ecosystem from Registry through Registrar to Resellers and finally end-users. One key metric might be, for example, to reduce the number of clicks to make a purchase equivalent to the most customer friendly e-commerce sites in the world. 
The Applicant might, for example, provide website performance tracking tools to registrars, which would benchmark current performance and provide insights into customers’ needs and behaviour at the point of purchase.
The Applicant will engage in a Social Customer Relationship Management Program to monitor social media feedback to questions, concerns or other issues. The Applicant will further seek to measure marketing communication expenditure and activity.

Other initiatives that will be considered by the Applicant in its outreach efforts: 

(a) Customized Vertical Search App for major mobile platforms.
(b) Designated Twitter channel for the stakeholder community.
(c) Social Media outreach through Facebook and other social media solutions.

Translation into other languages:

At present, the Applicant plans to translate marketing collateral and other content that it considers to have geographically diverse appeal in to the 6 official UN languages, namely Arabic, Chinese (Mandarin), English, French, Russian and Spanish.

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

The Applicant will follow the lifecycle and business rules found in the majority of gTLDs today. Our back-end operator has in excess of ten years of experience managing numerous gTLDs that utilize standard and unique business rules and lifecycles.

Initial registrations of registered names may be made in the registry in one (1) year increments for up to a maximum of ten (10) years. For the avoidance of doubt, the registration term for registered names may not exceed ten (10) years. Further the renewal of registered names may be made in one (1) year increments for up to a maximum of ten (10) years. For the avoidance of doubt, renewal of registered names may not extend their registration period beyond ten (10) years from the time of the renewal.

The Applicant plans to review domain name registration rates on an annual basis and will make a determination at that time regarding adjustments, depending upon market factors. Thus, at this time, the Applicant does not plan to make specific guarantees regarding pricing increases.

The Applicant will provide ICANN and each ICANN accredited registrar that has executed the registry-registrar agreement for the gTLD advance written notice of any price increase (including as a result of the elimination of any refunds, rebates, discounts, product tying or other programs which had the effect of reducing the price charged to registrars, unless such refunds, rebates, discounts, product tying or other programs are of a limited duration that is clearly and conspicuously disclosed to the registrar when offered) that complies with the requirements as outlined in the New gTLD Registry Agreement.
-end-

Q23
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. This response describes the registry services for our TLD, as provided by ARI.

1 INTRODUCTION

ARI’s Managed TLD Registry Service is a complete offering, providing all of the required registry services. What follows is a description of each of those services.

2 REGISTRY SERVICES
The following sections describe the registry services provided. Each of these services has, where required, been designed to take into account the requirements of consensus policies as documented here:
[http:⁄⁄www.icann.org⁄en⁄resources⁄Registrars⁄consensus-policies]
At the time of delegation into the root this TLD will not be offering any unique Registry services.

2.1 Receipt of Data from Registrars

The day-to-day functions of the registry, as perceived by Internet users, involves the receipt of data from Registrars and making the necessary changes to the SRS database. Functionality such as the creation, renewal and deletion of domains by Registrars, on behalf of registrants, is provided by two separate systems:
– An open protocol-based provisioning system commonly used by Registrars with automated domain management functionality within their own systems.
– A dedicated website providing the same functionality for user interaction.
Registrants (or prospective registrants) who wish to manage their existing domains or credentials, register new domains or delete their domains will have their requests carried out by Registrars using one of the two systems described below.
ARI operates Extensible Provisioning Protocol (EPP) server software and distributes applicable toolkits to facilitate the receipt of data from Registrars in a common format. EPP offers a common protocol for Registrars to interact with SRS data and is favoured for automating such interaction in the Registrar’s systems. In addition to the EPP server, Registrars have the ability to use a web-based management interface (SRS Web Interface), which provides functions equivalent to the EPP server functionality.

2.1.1 EPP

The EPP software allows Registrars to communicate with the SRS using a standard protocol. The EPP server software is compliant with all appropriate RFCs and will be updated to comply with any relevant new RFCs or other new standards, as and when they are finalised. All standard EPP operations on SRS objects are supported.
Specifically, the EPP service complies with the following standards:
– RFC 5730 Extensible Provisioning Protocol (EPP).
– RFC 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping.
– RFC 5732 Extensible Provisioning Protocol (EPP) Host Mapping.
– RFC 5733 Extensible Provisioning Protocol (EPP) Contact Mapping.
– RFC 5734 Extensible Provisioning Protocol (EPP) Transport over TCP.
– RFC 5910 Domain Name System (DNS) Security Extensions for the Extensible Provisioning Protocol (EPP).
– RFC 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP).
– Extensions to ARI’s EPP service comply with RFC 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP).

2.1.1.1 Security for EPP Service

To avoid abuse and to mitigate potential fraudulent operations, the EPP server software uses a number of security mechanisms that restrict the source of incoming connections and prescribe the authentication and authorisation of the client. Connections are further managed by command rate limiting and are restricted to only a certain number for each Registrar, to help reduce unwanted fraudulent and other activities. Additionally, secure communication to the EPP interface is required, lowering the likelihood of the authentication mechanisms being compromised.
The EPP server has restrictions on the operations it is permitted to make to the data within the registry database. Except as allowed by the EPP protocol, the EPP server cannot update the credentials used by Registrars for access to the SRS. These credentials include those used by Registrars to login to ARI’s SRS Web Interface and the EPP service.
Secure communication to the EPP server is achieved via the encryption of EPP sessions. The registry system and associated toolkits support AES 128 and 256 via TLS.
The Production and Operational Testing and Evaluation (OTE) EPP service is protected behind a secure firewall that only accepts connections from registered IP addresses. Registrars are required to supply host IP addresses that they intend to use to access the EPP service.
Certificates are used for encrypted communications with the registry. Registrars require a valid public⁄private key pair signed by the ARI CA to verify authenticity. These certificates are used to establish a TLS secure session between client and server.
EPP contains credential elements in its specification which are used as an additional layer of authentication. In accordance with the EPP specification, the server does not allow client sessions to carry out any operations until credentials are verified.
The EPP server software combines the authentication and authorisation elements described above to ensure the various credentials supplied are associated with the same identity. This verification requires that:
– The username must match the common name in the digital certificate.
– The certificate must be presented from a source IP listed against the Registrar whose common name appears in the certificate.
– The username and password must match the user name and password listed against the Registrar’s account with that source IP address.
To manage normal operations and prevent an accidental or intentional Denial of Service, the EPP server can be configured to rate limit activities by individual Registrars.

2.1.1.2 Stability Considerations

The measures that restrict Registrars to a limit of connections and operations for security purposes also serve to keep the SRS and the EPP server within an acceptable performance and resource utilisation band. Therefore, scaling the service is an almost linear calculation based on well-defined parameters.
The EPP server offers consistent information between Registrars and the SRS Web Interface. The relevant pieces of this information are replicated to the DNS within seconds of alteration, thus ensuring that a strong consistency between the SRS and DNS is maintained at all times.

2.1.2 SRS Web Interface

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

2.1.2.1 Security and Consistency Considerations for SRS Web Interface

The SRS Web Interface contains measures to prevent abuse and to mitigate fraudulent operations. By restricting access, providing user level authentication and authorisation, and protecting the communications channel, the application limits both the opportunity and scope of security compromise.
Registrars are able to create individual users that are associated with their Registrar account. By allocating the specific operations each user can access, Registrars have full control over how their individual staff members interact with the SRS. Users can be audited to identify which operations were conducted and to which objects those operations were applied.
A secure connection is required before credentials are exchanged and once authenticated. On login, any existing user sessions are invalidated and a new session is generated, thereby mitigating session-fixation attacks and reducing possibilities that sessions could be compromised.

2.1.3 Securing and Maintaining Consistency of Registry-Registrar Interaction Systems

ARI ensures all systems through which Registrars interact with the SRS remain consistent with each other and apply the same security rules. Additionally, ARI also ensures that operations on SRS objects are restricted to the appropriate entity. For example:
– In order to initiate a transfer a Registrar must provide the associated domain password (authinfo) which will only be known by the registrant and the current sponsoring Registrar.
– Only sponsoring Registrars are permitted to update registry objects.
All operations conducted by Registrars on SRS objects are auditable and are identifiable to the specific Registrar’s user account, IP address and the time of the operation.

2.2 Disseminate Status Information of TLD Zone Servers to Registrars

The status of TLD zone servers and their ability to reflect changes in the SRS is of great importance to Registrars and Internet users alike. ARI will ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication might be prior to the status change, during the status change and⁄or after the status change (and subsequent reversion to normal) – as appropriate to the party being informed and the circumstance of the status change.
Normal operations are those when:
– DNS servers respond within SLAs for DNS resolution.
– Changes in the SRS are reflected in the zone file according to the DNS update time SLA.
The SLAs are those from Specification 10 of the Registry Agreement.
A deviation from normal operations, whether it is registry wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

2.2.1 Communication Policy

ARI maintains close communication with Registrars regarding the performance and consistency of the TLD zone servers.
A contact database containing relevant contact information for each Registrar is maintained. In many cases, this includes multiple forms of contact, including email, phone and physical mailing address. Additionally, up-to-date status information of the TLD zone servers is provided within the SRS Web Interface.
Communication using the Registrar contact information discussed above will occur prior to any maintenance that has the potential to effect the access to, consistency of, or reliability of the TLD zone servers. If such maintenance is required within a short time frame, immediate communication occurs using the above contact information. In either case, the nature of the maintenance and how it affects the consistency or accessibility of the TLD zone servers, and the estimated time for full restoration, are included within the communication.
That being said, the TLD zone server infrastructure has been designed in such a way that we expect no down time. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate with 100% availability.

2.2.2 Security and Stability Considerations

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

2.3 Zone File Access Provider Integration

Individuals or organisations that wish to have a copy of the full zone file can do so using the Zone Data Access service. This process is still evolving; however the basic requirements are unlikely to change. All registries will publish the zone file in a common format accessible via secure FTP at an agreed URL.

ARI will fully comply with the processes and procedures dictated by the Centralised Zone Data Access Provider (CZDA Provider or what it evolves into) for adding and removing Zone File access consumers from its authentication systems. This includes:

– Zone file format and location.
– Availability of the zone file access host via FTP.
– Logging of requests to the service (including the IP address, time, user and activity log).
– Access frequency.

2.4 Zone File Update

To ensure changes within the SRS are reflected in the zone file rapidly and securely, ARI updates the zone file on the TLD zone servers using software compliant with RFC 2136 (Dynamic Updates in the Domain Name System (DNS UPDATE)) and RFC 2845 (Secret Key Transaction Authentication for DNS (TSIG)).
This updating process follows a staged but rapid propagation of zone update information from the SRS, outwards to the TLD zone servers – which are visible to the Internet. As changes to the SRS data occur, those changes are updated to isolated systems which act as the authoritative primary server for the zone, but remain inaccessible to systems outside ARI’s network. The primary servers notify the designated secondary servers, which service queries for the TLD zone from the public. Upon notification, the secondary servers transfer the incremental changes to the zone and publicly present those changes.
The protocols for dynamic update are robust and mature, as is their implementation in DNS software. The protocols’ mechanisms for ensuring consistency within and between updates are fully implemented in ARI’s TLD zone update procedures. These mechanisms ensure updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions. ARI has used this method for updating zone files in all its TLDs including the .au ccTLD, pioneering this method during its inception in 2002. Mechanisms separate to RFC 2136-compliant transfer processes exist; to check and ensure domain information is consistent with the SRS on each TLD zone server within 10 minutes of a change.

2.5 Operation of Zone Servers

ARI maintains TLD zone servers which act as the authoritative servers to which the TLD is delegated.

2.5.1 Security and Operational Considerations of Zone Server Operations

The potential risks associated with operating TLD zone servers are recognised by ARI such that we will perform the steps required to protect the integrity and consistency of the information they provide, as well as to protect the availability and accessibility of those servers to hosts on the Internet. The TLD zone servers comply with all relevant RFCs for DNS and DNSSEC, as well as BCPs for the operation and hosting of DNS servers. The TLD zone servers will be updated to support any relevant new enhancements or improvements adopted by the IETF.
The DNS servers are geographically dispersed across multiple secure data centres in strategic locations around the world. By combining multi-homed servers and geographic diversity, ARI’s zone servers remain impervious to site level, supplier level or geographic level operational disruption.
The TLD zone servers are protected from accessibility loss by malicious intent or misadventure, via the provision of significant over-capacity of resources and access paths. Multiple independent network paths are provided to each TLD zone server and the query servicing capacity of the network exceeds the extremely conservatively anticipated peak load requirements by at least 10 times, to prevent loss of service should query loads significantly increase.
As well as the authentication, authorisation and consistency checks carried out by the Registrar access systems and DNS update mechanisms, ARI reduces the scope for alteration of DNS data by following strict DNS operational practices:
– TLD zone servers are not shared with other services.
– The primary authoritative TLD zone server is inaccessible outside ARI’s network.
– TLD zone servers only serve authoritative information.
– The TLD zone is signed with DNSSEC and a DNSSEC Practice⁄Policy Statement published.

2.6 Dissemination of Contact or Other Information

Registries are required to provide a mechanism to identify the relevant contact information for a domain. The traditional method of delivering this is via the WhoIs service, a plain text protocol commonly accessible on TCP port 43. ARI also provides the same functionality to users via a web-based WhoIs service. Functionality remains the same with the web-based service, which only requires a user to have an Internet browser.
Using the WhoIs service, in either of its forms, allows a user to query for domain-related information. Users can query for domain details, contact details, nameserver details or Registrar details.
A WhoIs service, which complies with RFC 3912, is provided to disseminate contact and other information related to a domain within the TLD zone.

2.6.1 Security and Stability Considerations

ARI ensures the service is available and accurate for Internet users, while limiting the opportunity for its malicious use. Many reputation and anti-abuse services rely on the availability and accuracy of the WhoIs service, however the potential for abuse of the WhoIs service exists.
Therefore, certain restrictions are made to the access of WhoIs services, the nature of which depend on the delivery method – either web-based or the traditional text-based port 43 service. In all cases, there has been careful consideration given to the benefits of WhoIs to the Internet community, as well as the potential harm to registrants – as individuals and a group – with regard to WhoIs access restrictions.
The WhoIs service presents data from the registry database in real time. However this access is restricted to reading the appropriate data only. The WhoIs service does not have the ability to alter data or to access data not related to the WhoIs service. The access limitations placed on the WhoIs services prevent any deliberate or incidental denial of service that might impact other registry services.
Restrictions placed on accessing WhoIs services do not affect legitimate use. All restrictions are designed to target abusive volume users and to provide legitimate users with a fast and available service. ARI has the ability to ‘whitelist’ legitimate bulk users of WhoIs, to ensure they are not impacted by standard volume restrictions.
The data presentation format is consistent with the canonical representation of equivalent fields, as defined in the EPP specifications and ICANN agreement.

2.6.1.1 Port 43 WhoIs

A port 43-based WhoIs service complying with RFC 3912 is provided and will be updated to meet any other relevant standards or best practice guidelines related to the operation of a WhoIs service.
While the text-based service can support thousands of simultaneous queries, it has dynamic limits on queries per IP address to restrict data mining efforts. In the event of identified malicious use of the service, access from a single IP address or address ranges can be limited or blocked.

2.6.1.2 Web-based WhoIs

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

2.7 IDNs – Internationalised Domain Names

An Internationalised Domain Name (IDN) allows registrants to register domains in their native language and have it display correctly in IDN aware software. This includes allowing a language to be read in the manner that would be common for its readers. For example, an Arabic domain would be presented right to left for an Arabic IDN aware browser.
The inclusion of IDNs into the TLD zones is supported by ARI. All the registry services, such as the EPP service, SRS Web Interface and RDPS (web and port 43), support IDNs. However there are some stability and security considerations related to IDNs which fall outside the general considerations applicable individually to those services.

2.7.1 Stability Considerations Specific to IDN

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

2.7.1.1 Prevent Cross Language Registrations

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

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

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

2.8 DNSSEC

DNSSEC provides a set of extensions to the DNS that allow an Internet user (normally the resolver acting on a user’s behalf) to validate that the DNS responses they receive were not manipulated en-route.
This type of fraud, commonly called ‘man in the middle’, allows a malicious party to misdirect Internet users. DNSSEC allows a domain owner to sign their domain and to publish the signature, so that all DNS consumers who visit that domain can validate that the responses they receive are as the domain owner intended.
Registries, as the operators of the parent domain for registrants, must publish the DNSSEC material received from registrants, so that Internet users can trust the material they receive from the domain owner. This is commonly referred to as a ‘chain of trust’. Internet users trust the root (operated by IANA), which publishes the registries’ DNSSEC material, therefore registries inherit this trust. Domain owners within the TLD subsequently inherit trust from the parent domain when the registry publishes their DNSSEC material.
In accordance with new gTLD requirements, the TLD zone will be DNSSEC signed and the receipt of DNSSEC material from Registrars for child domains is supported in all provisioning systems.

2.8.1 Stability and Operational Considerations for DNSSEC

2.8.1.1 DNSSEC Practice Statement

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

2.8.1.2 Receipt of Public Keys from Registrars

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

2.8.1.3 Resolution Stability

DNSSEC is considered to have made the DNS more trustworthy; however some transitional considerations need to be taken into account. DNSSEC increases the size and complexity of DNS responses. ARI ensures the TLD zone servers are accessible and offer consistent responses over UDP and TCP.
The increased UDP and TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.
ARI complies with all relevant RFCs and best practice guides in operating a DNSSEC-signed TLD. This includes conforming to algorithm updates as appropriate. To ensure Key Signing Key Rollover procedures for child domains are predictable, DS records will be published as soon as they are received via either the EPP server or SRS Web Interface. This allows child domain operators to rollover their keys with the assurance that their timeframes for both old and new keys are reliable.

3 APPROACH TO SECURITY AND STABILITY

Stability and security of the Internet is an important consideration for the registry system. To ensure that the registry services are reliably secured and remain stable under all conditions, ARI takes a conservative approach with the operation and architecture of the registry system.
By architecting all registry services to use the least privileged access to systems and data, risk is significantly reduced for other systems and the registry services as a whole should any one service become compromised. By continuing that principal through to our procedures and processes, we ensure that only access that is necessary to perform tasks is given. ARI has a comprehensive approach to security modelled of the ISO27001 series of standards and explored further in the relevant questions of this response.
By ensuring all our services adhering to all relevant standards, ARI ensures that entities which interact with the registry services do so in a predictable and consistent manner. When variations or enhancements to services are made, they are also aligned with the appropriate interoperability
-end-

Q24
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q24 – ARI Background & Roles.pdf’. This response describes the SRS as implemented by ARI.

1 INTRODUCTION
ARI has demonstrated delivery of an SRS with exceptional availability, performance and reliability. ARI are experienced running mission critical SRSs and have significant knowledge of the industry and building and supporting SRSs.
ARI’s SRS has successfully supported a large group of Registrars for ASCII and IDN based TLDs. The system is proven to sustain high levels of concurrency, transaction load, and system uptime. ARI’s SRS meets the following requirements:
– Resilient to wide range of security & availability threats
– Consistently exceeds performance & availability SLAs
– Allows capacity increase with minimal impact to service
– Provides fair & equitable provisioning for all Registrars

2 CAPACITY
ARI’s SRS was built to sustain 20M domain names. Based on ARI’s experience running a ccTLD registries and industry analysis, ARI were able to calculate the conservative characteristics of a registry this size.
Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
– An average of 70 SRS TPS per domain, per month
– A ratio of 3 query to 2 transform txs
This indicates an expected monthly transaction volume of 1,400M txs (840M query and 560M transforms).
Through statistical analysis of the .au registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
– The peak daily TPS is 6% of monthly total
– The peak 5 min is 5% of the peak day
Thus we expect a peak EPP tx rate of 14,000 TPS (5,600 transform TPS and 8,400 query TPS)
Through conservative statistical analysis of the .au registry we know:
– The avg no. contacts⁄domain is 3.76
– The avg no. hosts⁄domain is 2.28
This translates into a requirement to store 75.2M contacts and 45.6M hosts.
Finally through real world observations of the .au registry, which has a comprehensive web interface when compared to those offered by current gTLD registries, we know there is an avg of 0.5 HTTP requests⁄sec to the SRS web interface per Registrar. We also know that this behaviour is reasonably flat. To support an estimated 1000 Registrars, would require 500 requests⁄second.
For perspective on the conservativeness of this, the following was taken from data in the May 2011 ICANN reports referenced above:
– .info: ~7.8M names peaks at ~1,400 TPS (projected peak TPS of ~3,600 with 20M)
– .com: ~98M names peaks at ~41,000 TPS (projected peak TPS of ~8,300 TPS with 20M)
– .org: ~9.3M names, peaks at ~1,400 TPS (projected peak TPS of ~3,100 with 20M)
After performing this analysis the projected TPS for .com was still the largest value.
ARI understand the limitations of this method but it serves as a best estimate of probable tx load. ARI has built overcapacity of resources to account for limitations of this method, however as numbers are more conservative than real world observations, we are confident this capacity is sufficient.
This TLD is projected to reach 〈domain-count〉 domains at its peak volume and will generate 〈srs-tx-count〉 EPP TPS. This will consume 〈srs-percent〉% of the resources of the SRS infrastructure. As is evident ARI’s SRS can easily accommodate this TLD’s growth plans. See attachment ‘Q24 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s SRS infrastructure will be 60% utilized. The SRS infrastructure capacity can be easily scaled as described in Q32
ARI benchmarked their SRS infrastructure and used the results to calculate the required computing resources for each of the tiers within the architecture; allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server, and the network bandwidth & packet throughput requirements for the anticipated traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions, and headroom for growth. Despite doubling numbers, effective estimated capacity is still reported as 20M. The technical resource allocations are explored in Q32.

3 SRS ARCHITECTURE
ARI’s SRS has the following major components:
– Network Infrastructure
– EPP Application Servers
– SRS Web Interface Application Servers
– SRS Database
Attachment ‘Q24 – SRS.pdf’ shows the SRS systems architecture and data flows. Detail on this architecture is in our response to Q32. ARI provides two distinct interfaces to the SRS: EPP and SRS Web. Registrar SRS traffic enters the ARI network via the redundant Internet link and passes (via the firewall) to the relevant application server for the requested service (EPP or SRS Web). ARI’s EPP interface sustains high volume and throughput domain provisioning transactions for a large number of concurrent Registrar connections. ARI’s SRS Web interface provides an alternative to EPP with a presentation centric interface and provides reporting and verification features additional to those provided by the EPP interface.

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

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

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

3.4 Number of Servers
EPP Servers – The EPP cluster consists of 3 servers that can more than handle the anticipated 20M domains. This TLD will utilize 〈srs-percent〉% of this capacity at its peak volume. As the utilisation increases ARI will add additional servers ensuring the utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.
SRS Web Servers – The SRS Web cluster consists of 2 servers that can more than handle the anticipated 20M domains. This TLD will utilize 〈srs-percent〉% of this capacity at its peak volume. As the utilisation increases ARI will add additional servers ensuring the utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.
SRS DB Servers – The SRS DB cluster consists of 4 servers that can more than handle the anticipated 20M domains. This TLD will utilize 〈srs-percent〉% of this capacity at its peak volume. As the utilisation increases ARI will add additional servers ensuring the total utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.

3.5 SRS Security
ARI adopts a multi-layered security solution to protect the SRS. An industry leading firewall is deployed behind the edge router and is configured to only allow traffic on the minimum required ports and protocols. Access to the ARI EPP service is restricted to a list of known Registrar IPs.
An Intrusion Detection device is in-line with the firewall to monitor and detect suspicious activity.
All servers are configured with restrictive host based firewalls, intrusion detection, and SELinux. Direct root access to these servers is disabled and all access is audited and logged centrally.
The SRS database is secured by removal of non-essential features and accounts, and ensuring all remaining accounts have strong passwords. All database accounts are assigned the minimum privileges required to execute their business function.
All operating system, database, and network device accounts are subject to strict password management controls such as validity & complexity requirements.
Registrar access to the SRS via EPP or the Web interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows:
– Registrar’s source IP must be allowed by the front-end firewalls. This source IP is received from the Registrar via a secure communication channel from within the SRS Web interface
– Registrar must use a digital certificate provided by ARI
– Registrar must use authentication credentials that are provided by encrypted email
All communication between the Registrar and the SRS is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

3.6 SRS High Availability
SRS availability is of paramount. Downtime is eliminated or minimised where possible. The infrastructure contains no single points of failure. N+1 redundancy is used as a minimum, which not only protects against unplanned downtime but also allows ARI to execute maintenance without impacting service.
Redundancy is provided in the network with hot standby devices & multiple links between devices. Failure of any networking component is transparent to Registrar connections.
N+N redundancy is provided in the EPP and SRS Web application server tiers by the deployment of multiple independent servers grouped together as part of a load-balancing scheme. If a server fails the load balancer routes requests to the remaining servers.
N+N redundancy is provided in the database tier by the use of Oracle Real Application Cluster technology. This delivers active⁄active clustering via shared storage. This insulates Registrars from database server failure.
Complete SRS site failure is mitigated by the maintenance of a remote standby site – a duplicate of the primary site ready to be the primary if required.
The standby site database is replicated using real time transaction replication from the main database using Oracle Data Guard physical standby. If required the Data Guard database can be activated quickly and service resumes at the standby site.

3.7 SRS Scalability
ARI’s SRS scales efficiently. At the application server level, additional computing resource can be brought on-line rapidly by deploying a new server online. During benchmarking this has shown near linear.
The database can be scaled horizontally by adding a new cluster node into the RAC cluster online. This can be achieved without disruption to connections. The SRS has demonstrated over 80% scaling at the database level, but due to the distributed locking nature of Oracle RAC, returns are expected to diminish as the number of servers approaches double digits. To combat this ARI ensures that when the cluster is ‘scaled’ more powerful server equipment is added rather than that equal to the current members. Capacity can be added to the SAN at any time without downtime increasing storage and IOPs.

3.8 SRS Inter-operability and Data Synchronisation
The SRS interfaces with a number of related registry systems as part of normal operations.

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

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

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

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

5 SLA, RELIABILITY & COMPLIANCE
ARI’s SRS adheres to and goes beyond the scope of Specification 6 and Specification 10 of the Registry Agreement. ARI’s EPP service is XML compliant and XML Namespace aware. It complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts & contacts are compliant with RFC 5731, 5732 & 5733 respectively. The transport over TCP is compliant with RFC5734. The service also complies with official extensions to support DNSSEC, RFC5910, & Redemption Grace Period, RFC 3915.
ARI’s SRS is sized to sustain a peak transaction rate of 14,000 TPS while meeting strict internal Operational Level Agreements (OLAs). The monthly-based OLAs below are more stringent than those in Specification 10 (Section 2).
EPP Service Availability: 100%
EPP Session Command Round Trip Time (RTT): 〈=1000ms for 95% of commands
EPP Query Command Round Trip Time (RTT): 〈=500ms for 95% of commands
EPP Transform Command Round Trip Time (RTT): 〈=1000ms for 95% of commands
SRS Web Interface Service Availability: 99.9%
ARI measure the elapsed time of every query, transform and session EPP transaction, and calculate the percentage of commands that fall within OLA on a periodic basis. If percentage value falls below configured thresholds on-call personnel are alerted.
SRS availability is measured by ARI’s monitoring system which polls both the EPP and SRS Web services status. These checks are implemented as full end to end monitoring scripts that mimic user interaction, providing a true representation of availability. These ‘scripts’ are executed from external locations on the Internet.

6 RESOURCES
This function will be performed by ARI. ARI staff are industry leading experts in domain name registries with the experience and knowledge to deliver outstanding SRS performance.
The SRS is designed, built, operated and supported by the following ARI departments:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided in attachment ‘Q24 – ARI Background & Roles.pdf’. This attachment describes the functions of the teams and the number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a vast experience in estimating the number of resources required to support a SRS.
Based on past experience ARI estimates that the existing staff is adequate to support an SRS that supporting at least 50M domains. Since this TLD projects 〈domain-count〉 domains, 〈resource-percent〉% of these resources are allocated to this TLD. See attachment ‘Q24 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required, trained resources can be added to any of the teams with a 2 month lead time.
The Products and Consulting team is responsible for product management of the SRS solution including working with clients and the industry to identify new features or changes required. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
The Production Support Group (PSG) is responsible for the design, deployment and maintenance of the SRS infrastructure including capacity planning and monitoring as well as security aspects – ensuring the SRS services are available and performing at the appropriate level and operating correctly. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrator
– 1 Network Engineer
The development team is responsible for implementing changes and new features into the SRS as well as bug fixing and complex issue diagnosis. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.
-end-

Q25
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q25 – ARI Background & Roles.pdf’. This response describes the Extensible Provisioning Protocol (EPP) interface as implemented by ARI.

1 INTRODUCTION

ARI’s EPP service is XML compliant and XML Namespace aware. The service complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts and contacts are compliant with RFC5731-3 respectively. The transport over TCP is implemented in compliance with RFC5734. The service also complies with the official extensions to support DNSSEC, RFC5910 and Redemption Grace Period, RFC3915. ARI implemented EPP draft version 0.6 in 2002, then migrated to EPP RFC 1.0 on its publishing in 2004. The system has operated live since 2002 in the .au ccTLD.
Descriptions in this response follow the terminology used in the EPP RFCs. When referring to the software involved in the process, ARI’s EPP interface is called the server, and the software used by Registrars is called the client.

2 TRANSPORT LAYER

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

2.1 Authentication
Registrar access to the EPP interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows. Registrars must:
– present a certificate, during TLS negotiation, signed by the ARI Certificate Authority (CA). The server returns a certificate also signed by the ARI CA. Not presenting a valid certificate results in session termination. ARI requires that the Common Name in the subject field of the certificate identifies the Registrar.
– originate connections from an IP address that is known to be assigned to the Registrar with that Common Name.
– Registrar must use authentication credentials provided to the Registrar via encrypted email
– Registrars aren’t able to exceed a fixed number of concurrent connections. The connection limit is prearranged and designed to prevent abuse of Registrars’ systems from affecting the Registry. The limit is set to reasonable levels for each Registrar, but can be increased to ensure legitimate traffic is unaffected. If any of the above conditions aren’t met the connection is terminated.
All communication between the Registrars and the EPP service is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

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

3 EPP PROTOCOL

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

3.1 Session Management
Session management refers to login and logout commands, used to authenticate and end a session with the SRS. The Login command is used to establish a session between the client and the server. This command succeeds when:
– The username supplied matches the Common Name in the digital certificate used in establishing the TLS session.
– The provided password is valid for the user.
– The user’s access to the system isn’t suspended.
The Logout command is used to end an active session. On processing a logout the server closes the underlying connection. The Hello command can be used as a session keep-alive mechanism.

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

4 EPP OBJECT MAPPINGS

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

The EPP domain, contact and host object mapping describes an interface for the check, info, create, delete, renew (domain only), transfer (domain & contact only) and update commands. For domain objects the server doesn’t support the use of host attributes as described by RFC5731, but rather uses host objects as described by RFC5731 and RFC5732. Details of each command are:
– check command: checks availability of 1 or more domain, contact or host objects in the SRS. Domain names will be shown as unavailable if in use, invalid or reserved, other objects will be unavailable if in use or invalid.
– info command: retrieves the information of an object provisioned in the SRS. Full information is returned to the sponsoring client or any client that provides authorisation information for the object. Non-sponsoring clients are returned partial information (no more than is available in the WhoIs).
– create command: provisions objects in the SRS. To ascertain whether an object is available for provisioning, the same rules for the check command apply.
– delete command: begins the process of removing an object from the SRS. Domain names transition into the redemption period and any applicable grace periods are applied. Domain names within the Add Grace Period are purged immediately. All other objects are purged immediately if they are not linked.
– renew command (domain only): extends the registration period of a domain name. The renewal period must be between 1 to 10 years inclusive and the current remaining registration period, plus the amount requested in the renewal mustn’t exceed 10 years.
– transfer command (domain and contact only): provides several operations for the management of the transfer of object sponsorship between clients. Clients that provide correct authorisation information for the object can request transfers. Domain names may be rejected from transfer within 60 days of creation or last transfer. The requesting client may cancel the transfer, or the sponsoring client may reject or approve the transfer. Both the gaining and losing clients may query the status of the current pending or last completed transfer.
– update command: updates authorisation information, delegation information (domains), and registration data pertaining to an object.

5 NON-PROPRIETARY EPP MAPPINGS

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

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

5.2 DNSSEC Mapping
The Domain Name System (DNS) Security Extensions Mapping for EPP, as per RFC5910, is used to support the provisioning of DNS Security Extensions. ARI requires clients use the Key Data interface. Clients may associate a maximum of 4 keys per domain. The registry system generates the corresponding DS data using the SHA-256 digest algorithm for the domain and any active variant domains.
ARI is aware of issues DNSSEC causes when transferring DNS providers – a transfer of Registrar usually means a change in DNS provider. DNSSEC key data won’t be removed from the SRS or the DNS if a transfer occurs. It is the responsibility of and requires the cooperation of the registrant, Registrars, and DNS providers, to provide a seamless transition. ARI observes progress with this issue and implements industry agreed solutions as available. DNSSEC information is included in info responses when the secDNS namespace in login.

6 PROPRIETARY MAPPING

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

6.1 Internationalised Domain Names
ARI has developed an extension to facilitate the registration and management of Internationalised Domain Names as per RFCs 5890-5893 (collectively known as the IDNA 2008 protocol). This extension extends the domain create command and the info response.
The create command is extended to capture the language table identifier that identifies the corresponding IDN language table for the domain name. Additionally the extension requires the Unicode form to avoid an inconsistency with DNS-form, as per RFC 5891.
The domain info command is extended to identify the language tag and Unicode form provided in the initial create command. This information is disclosed to all querying clients that provided the extension namespace at login. This extension is documented in the attachment ‘Q25 – idnadomain-1.0.pdf’.

6.2 Variant
ARI has developed an extension to facilitate the management of Domain Name variants. This extension extends the domain update command and the domain create and info responses. The domain update command is extended to allow the addition (activation) and removal (de-activation) of domain name variants subject to registry operator policy.
The domain create and info responses are extended to return the list of activated domain name variants. This information is disclosed to all querying clients that provided the extension namespace at login. The extension is documented in the attachment ‘Q25 – variant-1.1.pdf’.

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

7 ADDITIONAL SECURITY

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

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

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

8 COMPLIANCE

Compliance with EPP RFCs is achieved through design and quality assurance (QA). The EPP interface was designed to validate all incoming messages against the respective XML Schema syntax. The XML Schema is copied directly from the relevant RFCs to avoid any ambiguity on version used. Inbound messages that are either malformed XML or invalid are rejected with a 2400 response. Outbound messages are validated against the XML Schema, and if an invalid response is generated, it is replaced with a known valid pre-composed 2400 response, and logged for later debugging.
A QA process provides confidence that changes don’t result in regressions in the interface. Automated build processes execute test suites that ensure every facet of the EPP service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs and the EPP service specification. These tests are executed prior to committing code and automatically nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging process.
New versions of the EPP Service follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars are encouraged during this stage to test their systems operate correctly. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior reaching production.
ARI surveys Registrars for information about the EPP client toolkit. These surveys indicated that while many Registrars use ARI toolkits, several Registrars use either their own or that from another registry. The ability for Registrars to integrate with the ARI EPP service without using the supplied toolkit indicates the service is compliant with RFCs.
ARI is committed to providing an EPP service that integrates with third party toolkits and as such tests are conducted using said toolkits. Any issues identified during testing fall into the following categories:
– Third-party toolkit not compliant with EPP
– EPP service not compliant with EPP
– Both third-party toolkit and EPP service are compliant, however another operational issue causes an issue
Defects are raised and change management processes are followed. Change requests may also be raised to promote integration of third-party toolkits and to meet common practice.

9 CAPACITY

This TLD is projected to reach 〈domain-count〉 domains at its peak volume and will generate 〈srs-tx-count〉 EPP TPS. This will consume 〈srs-percent〉% of the EPP resources. ARI’s SRS can easily accommodate this TLD. This was described in considerable detail in the capacity section of question 24.

10 RESOURCES

This function will be performed by ARI. ARI provides a technical support team to support Registrars and also provides Registrars with a tool kit (in Java and C++) implementing the EPP protocol. Normal operations for all registry services are managed by ARI’s Production Support Group (PSG), who ensure the EPP server is available and performing appropriately.
Faults relating to connections with or functionality of the EPP server are managed by PSG. ARI monitors EPP availability and functionality as part of its monitoring practices, and ensures PSG staff are available to receive fault reports from Registrars any time. PSG has the appropriate network, Unix and application (EPP and load balancing) knowledge to ensure the EPP service remains accessible and performs as required. These ARI departments support EPP:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q25 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that existing staff are adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 〈domain-count〉 domains, 〈resource-percent〉% of these resources are allocated to this TLD. See attachment ‘Q25 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required, trained resources can be added to any of the above teams with a 2-month lead time.

10.1 Team Details
The products and consulting team is responsible for product management of the EPP solution, and works with clients and industry to identify required system features or changes. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
The Production Support Group (PSG) is responsible for the design, deployment and maintenance of the EPP infrastructure including capacity planning, monitoring, and security. This team ensures the EPP services are available and performing appropriately. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrator
– 1 Network Engineer
The development team is responsible for EPP changes and features, bug fixes and issue diagnosis. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our financial responses.
-end-

Q26
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q26 – ARI Background & Roles.pdf’. This response describes the WhoIs interface as implemented by ARI.

1 INTRODUCTION

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

2 PORT 43 WHOIS SERVICE

WhoIs is on TCP port 43 in accordance with RFC3912. Requests are made in semi-free text format and ended by CR & LF. The server responds with a semi-free text format, terminating the response by connection close.
To support IDNs and Localised data we assume the query is encoded in UTF-8 and sends responses encoded in UTF-8. UTF-8 is backwards compatible with the ASCII charset and its use is consistent with the IETF policy on charsets as defined in BCP 18 [http:⁄⁄tools.ietf.org⁄html⁄bcp18].

2.1 Query Format
By default WhoIs searches domains. To facilitate the queries of other objects keywords must be used. Supported keywords are:
– Domain
– Host⁄Nameserver
– Contact
– Registrar
Keywords are case-insensitive. The rest of the input is the search string. Wildcard chars may be used in search strings to match zero or more chars (%), or match exactly one char(_). Wildcard chars must not be in the first 5 chars.

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

2.3 Domain Data
Domain data is returned in response to a query with the keyword omitted, or with the ‘domain’ keyword. Domain queries return information on domains that are provisioned in the registry database.
The IDN domains may be specified in either the ASCII-compatible encoded form or the Unicode form. Clients are expected to perform any mappings, in conformance with relevant guidelines such as those specified in RFC5894 and UTS46.
Variant domains may be specified in the search string and WhoIs will match (using case-insensitive comparison) and return information for the primary registered domain.
For queries containing wildcard chars, if only one domain name is matched its details are returned, if more than one domain name is matched then the first 50 matched domain names are listed.

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

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

2.4 Nameserver Data
Nameserver data is returned in response to a query where the ‘nameserver’ or ‘host’ keywords have been used. Nameserver queries return information on hosts that are provisioned in the registry.
The search string for a nameserver query can be either a hostname or IP. Queries using the hostname produce one result unless wildcards are used. Queries using the IP produce one or more results depending on the number of hostnames that match that address. Queries for the hostname are matched case-insensitively.
The quad-dotted notation is expected for IPv4 and the RFC3513 – IPv6 Addressing Architecture format for IPv6. Wildcards cannot be used for IP queries.

2.5 Contact Data
Contact data is returned in response to a query where the ‘contact’ keyword was used. Contact queries return information on contacts that are provisioned in the registry.
The search string for a contact query is the contact identifier. Contact identifiers are matched using a case-insensitive comparison. Wildcards cannot be used.

2.6 Registrar Data
Registrar data is returned in response to a query where the ‘Registrar’ keyword was used. Registrar queries return information on Registrar objects that are provisioned in the registry.
The search string for a Registrar query can be name or IANA ID. Queries using the name or the IANA ID produce only one result. Queries for the name are matched using a case-insensitive comparison. Wildcards cannot be used.

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

3 WEB-BASED WHOIS SERVICE

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

4 SECURITY CONTROLS

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

5 BULK ACCESS

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

5.1 Periodic Access to Thin Registration Data
ARI shall provide ICANN with Periodic Access to Thin Registration Data. The data will contain the following elements as specified by ICANN. The format of the data will be consistent with the format specified for Data Escrow. The Escrow Format prescribes an XML document encoded in UTF-8. The generated data will be verified to ensure that it is well formed and valid.
The data will be generated every Monday for transactions committed up to and on Sunday unless otherwise directed by ICANN. The generated file will be made available to ICANN using SFTP. Credentials, encryption material, and other parameters will be negotiated between ARI and ICANN using an out-of-band mechanism.

5.2 Exceptional Access to Thick Registration Data
If requested by ICANN, ARI shall provide exceptional access to thick registration data for a specified Registrar. The data will contain full information for the following objects:
– Domain names sponsored by the Registrar
– Hosts sponsored by the Registrar
– Contacts sponsored by the Registrar
– Contacts linked from domain names sponsored by the Registrar
As above the format of the data will be consistent with the format specified for Data Escrow. And will be made available to ICANN using SFTP.

6 CAPACITY

ARI’s WhoIs infrastructure is built to sustain 20M domain names. Based on ARI’s experience running a high volume ccTLD registry (.au) and industry analysis, ARI were able to calculate the conservative characteristics of a registry of this size.
Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
– An average of 30 SRS txs per domain, per month.
Which indicates an expected monthly transaction volume of 600M txs?
Through statistical analysis of the .au registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
– The peak daily transactions is 6% of the monthly total
– The peak 5 min is 5% of the peak day
Thus we expect a peak WhoIs tx rate of WhoIs 6,000 TPS.
For perspective on the conservativeness of this, the following numbers were taken from data in the May 2011 ICANN reports referenced above:
– .info ~7.8M domain names, peaks at ~1,300 TPS (projected peak TPS of ~3,400 with 20M names).
– .mobi ~1M domain names, peaks at ~150 TPS (projected peak TPS of ~3,000 TPS with 20M names).
– .org ~9.3M domain names, peaks at ~1,300 TPS (projected peak TPS of ~2,800 with 20M names).
ARI understand the limitations of these calculations but they serve as a best estimate of probable transaction load. ARI has built overcapacity of resources to account for limitations of this method, however as conservative numbers were used and these are greater than real world observations, we are confident these capacity numbers are sufficient.
ARI benchmarked their WhoIs infrastructure and used the results to calculate the required computing resources for each of the tiers within the WhoIs architecture – allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server within the architecture, as well as the network bandwidth and packet throughput requirements for the anticipated WhoIs traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions and head room for growth. The technical resource allocations are explored in question 32.
This TLD is projected to reach 〈domain-count〉 domains at its peak volume and will generate 〈whois-tx-count〉 WhoIs transactions per second. This will consume 〈whois-percent〉% of the resources of the WhoIs infrastructure. As is evident ARI’s WhoIs can easily accommodate this TLD’s growth plans. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s WhoIs infrastructure will be only 60% utilized. The WhoIs infrastructure capacity can also be easily scaled as described in question 32

7 ARCHITECTURE

WhoIs uses a database separate from the SRS database as it operates from the secondary site such that network and database resources are decoupled from the operation of the SRS. Oracle Data Guard ensures the two databases are synchronised in real-time. The WhoIs service is operated live from the SRS ‘failover’ site, with the SRS ‘primary’ site serving as the ‘failover’ site for the WhoIs service. Both sites have enough capacity to run both services simultaneously, however by separating them, in normal operating modes headroom above the already over provisioned capacity is available. The architecture and data flow diagrams are described below and shown in the attachment ‘Q26 – WhoIs.pdf’.
Traffic enters the network from the Internet through border routers and then firewalls. All traffic destined for this service except for TCP ports 43, 80 & 443 is blocked. Load balancers forward the request to one of the application servers running ARI built WhoIs software. Each server is connected to the database cluster through another firewall further restricting access to the. Each server uses a restricted Oracle user that has read only access to the registry data and can only access the data that is relevant to the WhoIs queries. This ensures that in the unlikely event of an application server compromise the effects are limited.
All components are configured and provisioned to provide N+1 redundancy. Multiple Internet providers with separate upstream bandwidth suppliers are used. At least one additional component of all hardware exists, enabling maintenance without downtime. This configuration provides a service exceeding the availability requirements in Specification 10.
The use of load balancing allows addition of application servers with no downtime. From a database perspective, the ability to scale is enabled by utilising Oracle RAC database clustering. The entire service, including routers, firewalls and application is IPv6 compatible and WhoIs is offered on both IPv4 and IPv6. Detail about this architecture is available in our response to Question 32.

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

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

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

8 COMPLIANCE

Compliance with WhoIs RFCs is achieved through design and QA. The WhoIs interface was designed to conform to the RFCs as documented and independent test cases have been developed.
QA processes provide confidence that any changes to the service don’t result in regression of the WhoIs. Automated build processes execute test suites that ensure every facet of the WhoIs service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs. These tests are executed prior to the committing of code and nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging of the software.
New versions of the WhoIs follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars who rely on WhoIs functionality are encouraged during this stage to test their systems operate without change. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior to reaching production.
ARI is committed to providing a WhoIs service that integrates with third party tools and as such tests are conducted using these tools such as jWhoIs, a popular UNIX command line WhoIs client. Any issues identified during integration fall into 1 of the following categories:
– Third-party tool not compliant with the WhoIs specification
– WhoIs service not compliant
– Both third-party tool and WhoIs service are compliant, however another operational issue causes a problem
Defects are raised and follow the change management. Change requests may also be raised to promote integration of third-party tools and to meet common practice.

9 RESOURCES

This function will be performed by ARI. The WhoIs system is supported by a number of ARI departments:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
– Legal, Abuse and Compliance Team (6 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q26 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 〈domain-count〉 domains, 〈resource-percent〉% of these resources are allocated to this TLD. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The products and consulting team is responsible for product management of the WhoIs solution including working with clients and the industry to identify new features or changes required to the system. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
ARI employ a development team responsible for the maintenance and continual improvement of the WhoIs software. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
ARI’s Production Support Team ensures the successful operation of the WhoIs system. The team comprises Database Administrators, Systems Administrators and Network Administrators. This team routinely checks and monitors bandwidth, disk and CPU usages to plan and respond to expected increases in the volume of queries, and perform maintenance of the system including security patches and failover and recovery testing. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support)
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrators
– 1 Network Engineers
ARI’s registry provides abuse monitoring detection mechanisms to block data mining. ARI support staff may be contacted to remove blacklisted users during which they may be referred to the Legal, Abuse and Compliance Team for evaluation of their activities. Additionally the support team in conjunction with the Legal, Abuse and Compliance team administer requests for listing on the whitelist. The team consists of:
– 1 Legal Manager
– 1 Legal Counsel
– 4 Policy Compliance Officers
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.
-end-

Q27
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q27 – ARI Background & Roles.pdf’. This response describes the Registration Lifecycle as implemented by ARI.

1 INTRODUCTION

The lifecycle described matches current gTLD registries. All states, grace periods and transitions are supported by the EPP protocol as described in RFC5730 – 5734 & the Grace Period Mapping published in RFC3915. An overview is in attachment ‘Q27 – Registration Lifecycle.pdf’.

2 REGISTRATION PERIODS

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

3 STATES

The states that a domain can exist in are: Registered, Pending Transfer, Redemption, Pending Restore & Pending Delete.
All domain name statuses (RFC3915, 5730-5734 and 5910) are covered below

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

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

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

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

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

4 GRACE PERIODS

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

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

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

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

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

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

4.6 Overlap of Grace Periods
The 4 possible overlapping grace periods are:
– Add Grace Period with 1 or more Renew Grace Periods.
– Renew Grace Period with 1 or more other Renew Grace Periods.
– Transfer Grace Period with 1 or more Renew Grace Periods.
– Auto-Renew Grace Period with 1 or more Renew Grace Periods.
These are treated independently with respect to timelines however action that is taken has the combined effects of all grace periods still current.

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

5 TRANSITIONS

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

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

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

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

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

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

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

5.8 Pending Restore 〉 Redemption
Seven calendar days after the transition to the Pending Restore state, if no restore report is received the domain transitions to the Redemption state, which begins a new redemption period. The domain is removed from the DNS. The restore has no refund.

5.9 Redemption 〉 Pending Delete
Thirty calendar days after the transition to the Redemption state, if no restore request is received the domain transitions to the Pending Delete state.

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

6 LOCKS

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

7 SPECIAL CONSIDERATIONS

7.1 ICANN-Approved Bulk Transfers
ICANN-Approved Bulk Transfers do not follow the typical transfer lifecycle. Existing grace periods are invalidated and no refunds are credited to the losing Registrar. The prohibition of transfer period on domains created or transferred within 60 days does not apply.

7.2 Uniform Rapid Suspension
In the Uniform Rapid Suspension (URS) process, as described in the ‘gTLD Applicant Guidebook’ 11th January 2012, the following modification to the above processes is required.
Remedy allows for the addition of a year to the registration period, limited to the 10 year maximum. During this time no transform operations may be performed other than to restore the domain as allowed by Appeal. At the expiration of the registration period the domain is not automatically renewed, but proceeds to the Redemption state as per the lifecycle described above, and it is not eligible for restoration.

8 UPDATE⁄DNS

The update command does not impact the state of the domain through the Registration Lifecycle, however the command can be used to add and remove delegation information, which changes the DNS state of the domain.
A domain is required to have 2 or more nameservers published in the DNS. An update that results in a domain having less than 2 nameservers removes the domain from the DNS. An exception is when 1 nameserver remains assigned to a domain due to deletion of its other nameservers due to purge of their parent domain. The next update that modifies delegation information ends the exception and from then on the domain requires 2 nameservers be in the DNS.

9 RESOURCES

This function will be performed by ARI. ARI’s registry performs all time-based transitions automatically and enforces all other business rules – without requiring human resources for normal operation. If changes to the automatic behaviours or restrictions enforced by the policy system are required, ARI has a development team for this.
Domain Name Lifecycle aspects requiring human resources to manage are included in the ARI outsourcing include:
– Processing Add Grace Period exemptions as requested by Registrars.
– Processing restore reports provided by Registrars.
– Meeting the registry operator’s obligations under ICANN’s Transfer Dispute Policy.
– Performing exception processing in the case of approved transfers during the 60 day transfer prohibition window.
The Registration Lifecycle is designed, built, operated and supported by these ARI departments:
– Products and Consulting Team (7 staff)
– Legal, Abuse and Compliance Team (6 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q27 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 〈domain-count〉 domains, 〈resource-percent〉% of these resources are allocated to this TLD. See attachment ‘Q27 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Products and Consulting team is responsible for product management of the Registration Lifecycle, including working with clients and the industry to identify new features or changes required to the system. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
Most manual tasks fall to the Legal, Abuse and Compliance team, with staff experienced in development of policy for policy rich TLD environments. They have the required legal and industry background to perform this function. The team consists of:
– 1 Legal Manager
– 1 Legal Counsel
– 4 Policy Compliance Officers
The automated aspects of the Registration lifecycle are supported by ARI’s Domain Name Registry software. ARI has a development team for maintenance and improvement of the software. The team consist of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
Information on these roles is in Resources in our response to Question 31. These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.
-

Q28
The Applicant’s core mission and purpose is to create an environment where individuals and companies can interact and express themselves in ways never before seen on the Internet, in a more targeted, secure and stable environment. To achieve this goal the Applicant will be implementing a range of Abuse Prevention and Mitigation policies and procedures. The following is an overview of initiatives undertaken by the Applicant:

1.	gTLD Abuse Prevention and Mitigation Implementation Plan
2.	Policies and Procedures to Minimize Abusive Registrations 
2.1.	Implementation plan for Abuse Point of Contact
2.2.	Policies for Handling Complaints Regarding the Abuse Policies
2.3.	Proposed Measures for Removal of Orphan Glue Records
2.4.	Resourcing plans for the initial implementation of, and ongoing maintenance of, the Abuse Prevention and Mitigation initiatives
3.	Measures to promote WHOIS accuracy both directly by the Registry and by Registrars via requirements in the Registry-Registrar Agreement (“RRA”)):
3.1.	Regular monitoring of registration data for accuracy and completeness
3.2.	Registrar WHOIS policy self-certification and authentication
3.3.	WHOIS data reminder process
3.4.	Establishing policies and procedures to ensure Registrar compliance with WHOIS policies, which may include audits, financial incentives, penalties, or other means
3.5.	Registry semi-annual WHOIS verification 
3.6.	Registrar semi-annual verification of WHOIS
4.	Policies and procedures that define malicious or abusive behaviour
4.1.	Service Level Requirements for resolution
4.2.	Service Level Requirements for Law enforcement requests
4.3.	Coordination with sector Groups and Law Enforcement
4.4.	Rapid takedown and suspension
5.	Controls to Ensure Proper Access to Domain Functions:
5.1.	Enabling two-factor authentication from Registrants to process update, transfer, and deletion requests;
5.2.	Enabling multiple, unique points of contact to request and⁄or approve update, transfer, and deletion requests;
5.3.	Enabling the notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted 
6.	Additional Abuse Prevention and Mitigation initiatives
6.1.	Additional Mechanism for Protection of Capital City Names
6.2.	Additional Mechanisms to Protect and Reserve IGO Names
6.3.	Governance Council
7.	Resource Planning 
7.1.	Resource Planning Specific to Backend Registry Activities
7.2.	Administrative Services Provider – Famous Four Media Limited
8.	ICANN Prescribed Measures
9.	Increasing Registrant Security Awareness
10.	Registrant Disqualification
11.	Restrictions on Proxy Registration Services
12.	Registry Lock
13.	Scope⁄Scale Consistency
13.1    Scope⁄Scale Consistency Specific to Backend Registry Activities
14.	Acceptable Use Policy (“AUP”)
15.	Abuse Response Process


1	gTLD Abuse Prevention and Mitigation Implementation Plan 
The Applicant will be implementing a thorough and extensive Abuse Prevention and Mitigation plan, designed to minimise abusive registrations and other detrimental activities that may negatively impact internet users. This plan includes the establishment of a single abuse point of contact, responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the gTLD through all Registrars of record, including those involving a reseller. Details of this point of contact will be clearly published on the Applicant’s website. 
Strong abuse prevention for a new gTLD is an important benefit to the internet community. The Applicant and its backend services provider agree that a Registry must not only aim for the highest standards of technical and operational competence, but also needs to act as a steward of the space on behalf of the Internet community and ICANN in promoting the Registry’s stakeholders’ interest. The Applicant’s Backend Services Provider brings extensive experience establishing and implementing registration policies. This experience will be leveraged to help the Applicant combat abusive and malicious domain activity within the new gTLD space.
One of the key functions of a responsible domain name Registry includes working towards the eradication of domain name abuse including, but not limited to, those resulting from:

-	Illegal or fraudulent actions 
-	Spam
-	Phishing
-	Pharming 
-	Distribution of malware 
-	Fast flux hosting 
-	Botnets
-       Illegal distribution of copyrighted material 
-	Distribution of child pornography 
-	Online sale or distribution of illegal pharmaceuticals.

Further explanation of behaviour considered to be abusive can be found in the Acceptable Use Policy (“AUP”) below. Any second-level domain found to be facilitating such behaviours, either upon registration or subsequently, will be subject to rapid compliance action as per the policies outlined below.
The Applicant believes that the success of the gTLD will be determined largely by the sectorʹs broad-spectrum of key stakeholders, who operate globally. The Applicant believes that these stakeholders will be motivated to protect the sector from detrimental practices. The Applicant further believes that sector stakeholders should be afforded the opportunity to influence the manner in which the gTLD is governed, including its abuse prevention policies where appropriate. Accordingly, the Applicant is establishing a Governance Council, to be comprised of key sector stakeholders that will serve as an advisory body.  The Governance Council will elect its own Board of Directors, which will be responsible for self-governance, the recommendation of sector-specific policies, and the formulation of guidance on other best practices related to the gTLD. The Applicant aims to develop an Abuse Prevention and Mitigation Working Group in conjunction with the GC. It will give the Applicant’s team advice on abuse preventions and mitigation and how this may effect registration policies. The group will meet to regularly discuss the latest trends in domain name abuse and the most effective way to prevent and remedy them. Registrants, Registrars and the Registry will all be involved in this working group.This will likely prove important as the battle with abusive behaviour online must continuously evolve given that abusive behaviour itself mutates and changes. The Governance Council will offer significantly greater opportunities to identify emerging threats and rapidly establish procedures to deal with them than might have been possible simply with a Registry perspective.


2	Policies and Procedures to Minimize Abusive Registrations

Regardless of how well intentioned its user-base is, a Registry must have the policies, resources, personnel, and expertise in place to combat abusive DNS practices. The Applicantʹs Registry Backend Services Provider is at the forefront of the prevention of such abusive practices. We also believe that a strong program is essential given that Registrants have a reasonable expectation that they are in control of the data associated with their domains, especially its presence in the DNS zone. Because domain names are sometimes used as a mechanism to enable various illegitimate activities on the Internet, often the best preventative measure to thwart these attacks is to remove the names completely from the DNS before they can impart harm, not only to the domain name Registrant, but also to millions of unsuspecting Internet users.
Removing the domain name from the zone has the effect of shutting down all activity associated with the domain name, including the use of all websites and e-mail. The use of this technique should not be entered into lightly. The Applicant has an extensive, defined, and documented process for taking the necessary action of removing a domain from the zone when its presence in the zone poses a threat to the security and stability of the infrastructure of the Internet or the Registry.

Coalition for Online Accountability (“COA”) Recommendations
The Applicant will further structure its policies around the COA Recommendations where relevant to this gTLD. The Applicant’s goal is to provide a safe and secure browsing experience for consumers of this gTLD. A domain within this gTLD that is owned, operated by or compromised by a malicious party could cause harm to consumers, to the gTLDʹs reputation and to the reputation of the Internet itself. As such, additional controls are in place relating to the validity of registrations, as well as additional measures to ensure the correct identity of both Registrants and Registrars relating to changes made within the SRS, and to protecting the integrity of the DNS service as a whole.
The Coalition for Online Accountability have drafted a set of policy recommendations, also endorsed by many other international organizations representing the creative industries, that should be applied to entertainment gTLDs - especially those dependent on copyright protection. The policy is comprised of a set of 7 recommendations that should be adopted by ICANN in evaluating any applicant for an entertainment-based gTLD. The recommendations were posted by COA in the form of a letter to ICANN at http:⁄⁄bit.ly⁄HuHtmq. We welcome the recommendations from the COA and will strongly consider the recommendations relating to the implementation of this gTLD where considered relevant.

BITS Recommendations
The Applicant will further structure its policies around the BITS Recommendations where relevant to this gTLD. The Applicantʹs goal is to provide a safe and secure browsing experience for consumers of this gTLD. A domain within this gTLD that is owned, operated by or compromised by a malicious party could cause harm to consumers, to the gTLD’s reputation and to the reputation of the Internet itself. As such, additional controls are in place relating to the validity of registrations, as well as additional measures to ensure the correct identity of both Registrants and Registrars relating to changes made within the SRS, and to protecting the integrity of the DNS service as a whole.
The Security Standards Working Group (SSWG) formed by BITS drafted a set of policy recommendations that should be applied to financial gTLDs. The policy is comprised of a set of 31 recommendations that should be adopted by ICANN in evaluating any applicant of a financial gTLD. The recommendations were posted by BITS in the form of a letter to ICANN at [http:⁄⁄www.icann.org⁄en⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf]. We welcome the recommendations from SSWG and will strongly consider the recommendations relating to the implementation of this gTLD where considered relevant.


2.1	Implementation plan for Abuse Point of Contact
 
As required by the Registry Agreement, The Applicant will establish and publish on its website a single abuse point of contact responsible for addressing inquiries from law enforcement and the public related to malicious and abusive matters requiring expedited attention. The Applicant will provide a timely response to abuse complaints concerning all names registered in the gTLD by registrars and their resellers. The Applicant will also provide such information to ICANN prior to the delegation of any domain names in the gTLD. This information shall consist of, at a minimum, a valid name, e-mail address dedicated solely to the handling of malicious conduct complaints and a telephone number and mailing address for the primary contact. The Applicant will ensure that this information will be kept accurate and up to date and will be provided to ICANN if and when changes are made. In addition, with respect to inquiries from ICANN-Accredited Registrars, the Applicant’s Registry Backend Services Provider shall have an additional point of contact, as it does today, handling requests by Registrars related to abusive domain name practices.
 
2.2	Policies for Handling Complaints Regarding the Abuse Policies

In order to operate under the new gTLD, Registrants must accept the Acceptable Use Policy. The new gTLD Registry’s Acceptable Use Policy clearly delineates the types of activities that constitute “abuse” and the repercussions associated with an abusive domain name registration. In addition, the policy will be incorporated into the applicable Registry-Registrar Agreement (“RRA”) and reserve the right for the Registry to take the appropriate actions based on the type of abuse. This will include locking down the domain name preventing any changes to the contact and name server information associated with the domain name, placing the domain name “on hold” rendering the domain name non-resolvable, transferring the domain name to another Registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. When appropriate, the Applicant will also share information with law enforcement. Each ICANN and gTLD accredited Registrar must agree to pass the Acceptable Use Policy on to its Resellers (if applicable) and ultimately to the gTLD Registrants. The Registry’s initial Acceptable Use Policy that the Applicant will use in connection with the gTLD  is outlined in a section below.

2.3	Proposed Measures for Removal of Orphan Glue Records

As the Security and Stability Advisory Committee of ICANN (“SSAC”) rightly acknowledges, although orphaned glue records may be used for abusive or malicious purposes, the “dominant use of orphaned glue supports the correct and ordinary operation of the DNS.” See http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf. 
While orphan glue records often support the correct and ordinary operation of the DNS, we understand that such glue records can be used maliciously to point to name servers that host domains used in illegal phishing, botnets, malware, and other abusive behaviours. Problems occur when the parent domain of the glue record is deleted but its children glue records still remain in DNS.
Thus, the Registry Operator will remove orphan glue records (as defined at the above link) when provided with evidence in written form that such records are present in connection with malicious conduct. Registrars are required to delete⁄move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, the Registry Backend Services Provider performs the following checks before removing a domain or name server:

Checks during domain delete: 
-	Parent domain delete is not allowed if any other domain in the zone refers to the child name server. 
-	If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone.
Check during explicit name server delete: 
-	The Registry Backend Services Provider confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server. 
Zone-file impact:
-	If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a serverHold status, then the parent domain goes out of the zone but the name server glue record does not. 
-	If no domains reference a name server, then the glue record is removed from the zone file.

2.4	Resourcing plans for the initial implementation of, and ongoing maintenance of, the Abuse Prevention and Mitigation initiatives

Details related to resourcing plans for the initial implementation and ongoing maintenance of the Applicant’s abuse plan are provided in Section 7 of this response.


3	Measures to promote WHOIS accuracy both directly by the Registry and by Registrars via requirements in the Registry-Registrar Agreement (“RRA”):


The Applicant acknowledges that ICANN has developed a number of mechanisms over the past decades that are intended to address the issue of inaccurate WHOIS information. Such measures alone have not proven to be sufficient and the Applicant will offer a mechanism whereby third parties can submit complaints directly to the Applicant about inaccurate or incomplete WHOIS data. Such information shall be forwarded to the sponsoring Registrar, who shall be required to address those complaints with their Registrants. Thirty days after forwarding the complaint to the Registrar, the Applicant will examine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or any other action was taken. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, the Applicant reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies. Further efforts to pre-empt inaccurate WHOIS data made by the Applicant will include:

1)	The Applicant will in general discourage the use of proxy registration services. The Applicant understands that there are instances when proxy registrations may be required and will develop best practices for when these instances occur. 
2)	The Applicant will maintain a web-based form for third parties to submit claims regarding false and⁄or inaccurate WHOIS data and the Applicant will forward credible claims to the Registrar for investigation⁄resolution. The Applicant will follow up to verify that the claim has been satisfactorily resolved. Failure of the Registrar or the Registrant to resolve the problem may result in the Applicant placing the domain name on hold, except in extraordinary circumstances.
3)	The Applicantʹs Registry Backend Services Provider will regularly remind Registrars of their obligation to comply with ICANN’s WHOIS Data Reminder Policy. This policy requires Registrars to validate the WHOIS information provided during the registration process, to investigate claims of fraudulent WHOIS information, and to cancel domain name registrations for which WHOIS information is determined to be invalid.
4)	WHOIS Verification by Registrars. As part of their Registry-Registrar Agreement all accredited Registrars will be required to revalidate WHOIS data for each record they have registered in the gTLD. The Applicant will leave the ultimate determination of how this procedure takes place to the Registrar, but it must include one of the following approved methods. (1) Email notification (2) Outbound telemarketing effort to the individual listed as the administrative contact for the domain.
 
3.1	Regular monitoring of registration data for accuracy and completeness

As part of their Registry-Registrar Agreement, all of the Applicant’s Registrars will be required to revalidate WHOIS data for each record they have registered on a bi-annual basis. This revalidation will require the Registrar to notify its Registrants in the gTLD about this requirement. While the Applicant reserves the right to suspend domain names that are not verified in a timely manner, the Applicant will engage in other outreach to the Registrant prior to suspending any domain name. As part of the gTLD Abuse reporting system, users can report missing or incomplete WHOIS data via the Registry website. The Applicant will also perform randomized audits of verified WHOIS information to ensure compliance and accuracy.
The Applicant’s selected Registry Backend Services Provider has established policies and procedures to encourage Registrar compliance with ICANN’s WHOIS accuracy requirements..


3.2	Registrar WHOIS policy self-certification and authentication
 
The self-certification program consists, in part, of evaluations applied equally to all operational ICANN accredited Registrars for the gTLD and is conducted from time to time throughout the year. Process steps are as follows:
The Registry Backend Services Provider sends an email notification to the ICANN primary Registrar contact, requesting that the contact go to a designated URL, log in with his⁄her Web ID and password, and complete and submit the online form. The contact must submit the form within 15 business days of receipt of the notification. 
When the form is submitted, the Registry Backend Services Provider sends the Registrar an automated email confirming that the form was successfully submitted.
The Registry Backend Services Provider reviews the submitted form to ensure the certifications are compliant.
The Registry Backend Services Provider sends the Registrar an email notification if the Registrar is found to be compliant in all areas. 
If a review of the response indicates that the Registrar is out of compliance or if the Registry Backend Services Provider has follow-up questions, the Registrar has 10 days to respond to the inquiry.
If the Registrar does not respond within 15 business days of receiving the original notification, or if it does not respond to the request for additional information, the Registry Backend Services Provider sends the Registrar a Breach Notice and gives the Registrar 30 days to cure the breach.
If the Registrar does not cure the breach, the Registry Backend Services Provider may terminate the Registry-Registrar Agreement (RRA).

3.3	WHOIS data reminder process.
 
The Registry Backend Services Provider regularly reminds Registrars of their obligation to comply with ICANN’s WHOIS Data Reminder Policy, which was adopted by ICANN as a consensus policy on 27 March 2003 (http:⁄⁄www.icann.org⁄en⁄Registrars⁄wdrp.htm). The Registry Backend Services Provider sends a notice to all Registrars once a year reminding them of their obligation to be diligent in validating the WHOIS information provided during the registration process, to investigate claims of fraudulent WHOIS information, and to cancel domain name registrations for which WHOIS information is determined to be invalid.

 
3.4	Establishing policies and procedures to ensure Registrar compliance with policies, which may include audits, financial incentives, penalties, or other means.

The Applicant will require as part of the RRA obligations that all accredited Registrars for the gTLD participate in the abuse prevention and mitigation procedures and policies, as well as efforts to improve the accuracy and completeness of WHOIS data. In addition, the Applicant will work to develop an economic incentive program, such as Market Development Funds for Registrars who meet certain SLAs for performance in this area.
 
3.5	Registry bi-annual WHOIS verification

Additionally, the Applicant will, of its own volition and no less than twice per year, perform a manual review of a random sampling of gTLD domain names in its Registry to test the accuracy of the WHOIS information. Although this will not include verifying the actual information in the WHOIS record, the Applicant will be examining the WHOIS data for prima facie evidence of inaccuracies. In the event that such evidence exists, it shall be forwarded to the sponsoring Registrar, who shall be required to address those complaints with their Registrants. Thirty days (30) after forwarding the complaint to the Registrar, the Applicant will reexamine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or some other action was taken. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, The Applicant reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

3.6	Registrar bi-annual verification of WHOIS

The Applicant will require in the Registry-Registrar Agreement that all accredited Registrars in this gTLD will be obliged to verify WHOIS data for each record they have registered in the gTLD twice a year. Verification can take place via email, phone or any other method to confirm the accuracy of the WHOIS data associated with the domain name. The Applicant will randomly audit WHOIS records to ensure compliance and accuracy. As part of the gTLD Abuse reporting system, users can report missing or incomplete WHOIS data via the Registry website.

4	Policies and procedures that define malicious or abusive behaviour

The applicant has developed policies and procedures that define malicious and abusive behaviour. More information on these policies and procedures can be found in section 14 - Acceptable Use Policy.

4.1	Service Level Requirements for resolution of APM related activities

As pertains to the Applicant’s service level requirements for resolution, we aim to address and potentially rectify the issue as it pertains to all forms of abuse and fraud within 24 hours. Once abusive behaviour is detected or reported, the Applicant’s Customer Service center immediately creates a support ticket in order to monitor and track the issue through resolution. This support team is operational 24⁄7⁄365. A preliminary assessment will be performed in order to determine whether the abuse claim is legitimate. We will classify each incidence of legitimately reported abuse into one of two categories based on the probable severity and immediacy of harm to Registrants and Internet users.

Category 1:
-	Probable Severity or Immediacy of Harm: Low
-	Examples of types of abusive behaviour: Spam, Malware
-	Mitigation steps:
	- Investigate
	- Notify Registrant
-	Response times – up to 3 days depending on severity.

Category 2:

-	Probable Severity or Immediacy of Harm: Medium to High
-	Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
-	Mitigation steps:
	- Suspend domain name 
        - Investigate
	- Restore or terminate domain name
-	Response times - up to 1 day.

4.2     Service Level Requirements and Coordination regarding Law enforcement APM requests

With the assistance of its Registry Backend Services Provider, the Applicant will meet its obligations under Section 2.8 of the Registry Agreement where required to take reasonable steps to investigate and respond to reports from law enforcement, governmental and quasi-governmental agencies of illegal conduct in connection with the use of the gTLD. The Registry will respond to legitimate law enforcement inquiries within one business day from receiving the request. Such a response shall include, at a minimum, an acknowledgement of receipt of the request, questions or comments concerning the request, and an outline of the next steps to be taken by the Applicant for rapid resolution of the request. 
In the event such request involves any of the activities which can be validated by the Registry and involves the type of activity set forth in the Acceptable Use Policy, the sponsoring Registrar is then given 24 hours to investigate the activity further and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the Registrar has not taken the requested action after the 24-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry may place the domain on “ServerHold”.

4.3	Coordination with sector Groups and Law Enforcement

One of the reasons for which the Registry Backend Services Provider was selected to serve as the Registry Backend Services Provider by the Applicant is the Registry Backend Services Provider’s extensive experience and its close working relationship with a number of law enforcement agencies. 
The Registry Backend Services Provider is also a participant in a number of sector groups aimed at sharing information amongst key sector players about the abusive registration and use of domain names. Through these organizations the Registry Backend Services Provider shares information with other registries, Registrars, ccTLDs, law enforcement, security professionals, etc. Not only on abusive domain name registrations within its own gTLDs, but also provides information uncovered with respect to domain names in other registries. The Registry Backend Services Provider has often found that rarely are abuses found only in the gTLDs which it manages, but also within other gTLDs. The Registry Backend Services Provider routinely provides this information to the other registries so that it can take the appropriate action.  
When executed in accordance with the Registry Agreement, plans will result in compliance with contractual requirements.
The Applicant believes that the proposed collection of protections that involve both proactive and reactive mechanisms outlined above will provide an unmatched level of security and anti-abuse activity within the gTLD. These mechanisms will be part of both the Registry-Registrar Agreement as well as the Registrant Registration Agreement.

4.4	Rapid takedown and suspension system

The Applicant is committed to ensuring that the use of the internet within its Registry is compliant with all relevant laws and legal directions.
The Applicant notes that its role as the Registry operator is not one of judge and jury in all jurisdictions and as such shall direct all complainants to the legal process in the relevant jurisdiction. Upon receiving a valid and enforceable legal judgment or direction it shall comply forthright with the appropriate action which shall include rapid takedown and⁄or suspension.

5	Controls to Ensure Proper Access to Domain Functions

5.1	Enabling two-factor authentication from Registrants to process update, transfers, and deletion requests;

To ensure proper and secure access to domain functions, the Applicant will develop best practices for its Registrars relating to enabling its Registrants to utilize two factor authentication in its interaction with their Registrar and ultimately the Registry.  
The goal of these best practices is to improve domain name security and assist Registrars in protecting the accounts they manage by providing another level of assurance that only authorized registrants can communicate through the registrar with the Registry.

5.2	Enabling multiple, unique points of contact to request and⁄or approve update, transfer, and deletion requests;

The Applicant will investigate the costs and benefits for introducing a service whereby a Registrant can elect to designate multiple points of contact for each domain registered to approve changes to a domain before they are effectuated. The Applicant is of the opinion that these additional checks could improve the security of each domain and will look for ways to deploy them in the most cost-effective and user-friendly manner possible.

5.3	Enabling the notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted

The Applicant will investigate the costs and benefits for introducing a service where by a Registrant can elect to designate multiple points of contact for each domain registered to receive notification of changes to a domain when they are effectuated. The Applicant is of the opinion that these additional checks could improve the security of each domain and will look for ways to deploy them in the most cost-effective and user-friendly manner possible.


6.	 Additional Abuse Prevention and Mitigation initiatives
 
6.1	Additional Mechanism for Protection of Capital City Names

In parallel with the Landrush Period defined in the answer to question 18, the Applicant will implement a Capital City Claim (“CCC”) service whereby additional protection will be granted to the capital city names of a country or territory listed in the ISO 3166-1 standard. The CCC process is as follows:

1. 	Any prospective domain name Registrant applying to register a domain name identical to the capital city name of a country or territory listed in the ISO 3166-1 standard will receive from the Applicant a CCC notification highlighting the fact that the applied-for domain name corresponds to a capital city name of a country or territory listed in the ISO 3166-1 standard. 
2. 	A potential domain name Registrant receiving a CCC notification will have to send a response to the Applicant whereby it will unconditionally comply with the requirements as to representations and warranties required by the Applicant. This will protect the reputation of the capital city as well as any further relevant terms and conditions provided.
3. 	Unconditional acceptance of the warranties set out in the CCC notification will be a material requirement for a prospective Registrant to be eligible to register the domain name in question should said prospective Registrant be successful in the Landrush period.
4. 	Upon registration during the Landrush period of a domain name identical to a capital city name of a country or territory listed in the ISO 3166-1 standard, the Applicant will send a notification in writing to the ICANN Government Advisory Committee (ʺGACʺ) Chair.

6.2	Additional Mechanisms to Protect and Reserve IGO Names
The Applicant considers the Protection of Intergovernmental Organization (ʺIGOʺ) names to be very important. The Applicant will use strings registered as second level domains in the .int gTLD as the basis for this protection. To register in the .int domain, the Registrants must be an IGO that meets the requirements found in RFC 1591. The .int domain is used for registering organizations established by international treaties between or among national governments and which are widely considered to have independent international legal personality. Thus, the names of these organizations, as with geographic names, can lend an official imprimatur, and if misused, be a source of public confusion or deception.
 
Reservation of IGO names:

In addition to the mandated and additional reservation of geographic names as provided for in response to Question 22, the Applicant will reserve, and thereby prevent registration of, all names that are registered as second level domains in the most recent .int zone as of 1st November 2012. By doing so, the Applicant will extend additional protection to IGOs that comply with the current eligibility requirements for the .int gTLD as defined at http:⁄⁄www.iana.org⁄domains⁄int⁄policy⁄, and that have obtained a second-level registration in the .int zone.

Release of IGO names:

In the future, should any of the IGOs wish to make use of the protected strings, the Registry will release and assign the domain to the respective IGOs using the following process:

a) The IGO submits a request to the Applicant in the hope of the reserved name being assigned to themselves and provides the necessary documentation and details of the proposed registrant entity for the domain name registration.
b) The Applicant will validate and authenticate the request to establish that it is a genuine bona fide request.
c) Once the request has been approved the Applicant will notify the requesting IGO as well as ICANN and the GAC of the approval for the assignment of the domain name.
d) The Applicant will issue a unique authorization code to the proposed IGO registrant.
e) The proposed IGO registrant will then be able to request that the assignment of the domain name is given to them using the authorization code with an ICANN and gTLD accredited Registrar of their choice.

6.3	Governance Council

The Applicant believes that the success of the gTLD will be determined in large by the gTLD’s stakeholders. Not only will these stakeholders have the primary interest of registering domains on the gTLD, but they will also be motivated to protect the sector from practices that would negatively impact the sector overall. The Applicant further believes that sector stakeholders should be afforded the opportunity to influence the manner in which the gTLD is governed. Accordingly, the Applicant is establishing a Governance Council (the “GC”), to be comprised of key sector stakeholders that will serve as an advisory body.

The GC will elect its own Board of Directors, which will be responsible for self-governance, the recommendation of sector-specific policies, and the formulation of guidance on intellectual property and other best practices related to the gTLD. This will lead the policy development process of defining how the APM Reporting Website should best reflect the options users, rights holders, etc., have for addressing infringing content or other issues.


7.	Resource Planning

7.1	Resource Planning Specific to Backend Registry Activities

ARI’s Anti-Abuse Service serves to prevent and mitigate abusive behavior in the gTLD as well as activities that may infringe trademarks. These responsibilities will be undertaken by three teams:
 
(1) ARI’s Development Team will be responsible for developing the technical platforms and meeting technical requirements needed to implement the procedures and measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse.
 
(2) ARI’s Abuse and Compliance Team will be responsible for the ongoing implementation of measures to minimize abusive registrations and other activities that have a negative impact on Internet users.
 
(3) ARI’s Service Desk will be responsible for responding to reports of abuse received through the abuse point of contact on the Registry’s website and logging these in a ticket in ARI’s case management system.

ARI Abuse and Compliance Team
ARI’s Abuse and Compliance Team will be staffed by six full-time equivalent positions. These roles will entail the following:
Policy Compliance Officers: A principal responsibility of the Policy Compliance Officers will be handling notifications of abuse through the SAPOC. This will involve managing the expedited process, identifying and categorizing suspected abuse according to our Anti-Abuse Policy, and carrying out the appropriate mitigation response for all categorized abuses. When abuse is identified, Policy Compliance Officers will investigate other domain names held by a Registrant whose domain name is subject to a mitigation response. They will maintain a list of and disqualify Registrants found to have repeatedly engaged in abusive behavior. They will also be responsible for analyzing Registry data in search of behaviors indicative of abuse, reviewing sector lists in search of data that may identify abuse in the gTLD.
Another key responsibility of Policy Compliance Officers will be implementing measures to promote WHOIS accuracy (including managing and addressing all reports of inaccurate WHOIS information received from the web submission service) and verifying the physical address provided by a Registrant against various databases for format and content requirements for the region.
Policy Compliance Officers will act on the instructions of verified LEA and Dispute Resolution Providers and participate in ICANN and sector groups involved in the promulgation of policies and best practices to address abusive behavior. They will escalate complaints and issues to the Legal Manager when necessary and communicate with all relevant stakeholders (Registrars, Registrants, LEA, general public) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis, supported outside of ordinary business hours by ARI’s Service Desk.
Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, comprehensive knowledge of abusive behavior in a gTLD and related policies, Internet sector knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.

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

Legal Counsel: A qualified lawyer will be responsible for all in-house legal advice, including responding to LEA and dealing with abusive behavior.
The globally distributed team consists of:

Policy Compliance Officers - 4 people
Legal Manager - 1 person
Legal Counsel - 1 person

ARI Service Desk
ARI’s Service Desk will be staffed by 14 full-time equivalent positions. Responsibilities of Service Desk relevant to ARI’s Anti-Abuse Service include the following: responding to notifications of abuse through the abuse point of contact and expedited process for LEA, logging notifications as a ticket in ARI’s case management system, notifying us of a report received through the expedited process for LEA, government and quasi-governmental agencies, and forwarding tickets to ARI’s Abuse and Compliance team for resolution in accordance with the Anti-Abuse Policy. 

ARI Development Team
All tools and systems needed to support the initial and ongoing implementation of measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse will be developed and maintained by ARI. ARI has a software development department dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.
ARI’s Development Team participate actively in the sector; this facilitates collaboration with relevant organizations on abuse related issues and ensures that the ARI Development Team is responsive to new and emerging domain name abuses and the tools and systems required to be built to address these abuses. This globally distributed team consists of:

Development Manager - 1 person
Business Analysts - 2 people
Developers - 6 people
Quality Analysts – 2 people 

7.2	Administrative Services Provider – Famous Four Media Limited

In addition to those resources set out above provided by the Registry’s backend services provider the Applicant‘s Administration Services Provider shall provide the following extra resources:

-	Sunrise Validation Team - This shall comprise of 11 employees of which at least one shall be a qualified lawyer specializing in intellectual property law.
-	Ongoing Rights Protection Team - This shall comprise of 11 employees of which at least one shall be a qualified lawyer specializing in intellectual property law.

The two key objectives of the Sunrise Validation Team and the Ongoing rights Protection Team (together the “Rights Team”) is to:

a.	Prevent abusive registrations; and
b.	Identify and address the abusive use of registered names on an ongoing basis
Because rights protection is a fundamental core objective of the Applicant it has contracted with its Registry Administration Services Provider that the number of full time personnel made available to the Applicant will be 125% of the estimated requirement to ensure that at all times the Applicant is over resourced in this area. In addition the Applicant shall instruct outside Counsel in any relevant jurisdiction on all matters that are unable to be adequately dealt with by the Sunrise Validation Team or the Ongoing Rights Protection Team.

8.	ICANN Prescribed Measures

In accordance with its obligations as a Registry operator, the Applicant will comply with all requirements in the ‘gTLD Applicant Guidebook’. In particular, we will comply with the following measures prescribed by ICANN which serve to mitigate the potential for abuse in the gTLD:

-	DNSSEC deployment, which reduces the opportunity for pharming and other man-in-the-middle attacks. We will encourage Registrars and Internet Service Providers to deploy DNSSEC capable resolvers in addition to encouraging DNS hosting providers to deploy DNSSEC in an easy-to-use manner in order to facilitate deployment by Registrants. Prohibition on Wild Carding as required by section 2.2 of Specification 6 of the Registry Agreement.
-	Removal of Orphan Glue records (discussed above in section 4).


9.	Increasing Registrant Security Awareness

In order to operate a secure and reliable gTLD, the Applicant will attempt to improve Registrant awareness of the threats of domain name hijacking, Registrant impersonation and fraud, and emphasise the need for and responsibility of Registrants to keep registration (including WHOIS) information accurate. Awareness will be raised by:
-	Publishing the necessary information on the Abuse page of our Registry website in the form of presentations and FAQ’s.
-	Developing and providing to Registrants and resellers Best Common Practices that describe appropriate use and assignment of domain auth Info codes and risks of misuse when the uniqueness property of this domain name password is not preserved.
The increase in awareness renders Registrants less susceptible to attacks on their domain names owing to the adoption of the recommended best practices thus serving to mitigate the potential for abuse in the gTLD. The clear responsibility on Registrants to provide and maintain accurate registration information (including WHOIS) further serves to minimise the potential for abusive registrations in the gTLD.


10.	Registrant Disqualification

Registrants, their agents or affiliates found through the application of the AUP to have repeatedly engaged in abusive registration may be disqualified from maintaining any registrations or making future registrations. This will be triggered when the Registry Backend Services Provider’s records indicate that a Registrant has had action taken against it an unusual number of times through the application of our Anti-Abuse Policy. Registrant disqualification provides an additional disincentive for qualified Registrants to maintain abusive registrations in that it puts at risk even otherwise non-abusive registrations, through the possible loss of all registrations.
In addition, name servers that are found to be associated only with fraudulent registrations will be added to a local blacklist and any existing or new registration that uses such fraudulent NS record will be investigated.
The disqualification of ‘bad actors’ and the creation of blacklists mitigates the potential for abuse by preventing individuals known to partake in such behaviour from registering domain names.
For a Registrant to be placed on a list of bad actors, the Applicant will examine the factors noted above, and such determination shall be made by the Applicant at its sole discretion.  Once the Applicant determines that a Registrant should be placed onto the list of bad actors, the Applicant will notify its Registry Backend Services Provider, who will be instructed to cause all of the Registrant’s second-level domains in the gTLD to resolve to a page which notes that the domain has been disabled for abuse-related reasons.  The second-level domains at issue will remain in this state until the expiration of the Registrant’s registration term or a decision from a UDRP panel or court of competent jurisdiction requires the transfer or cancellation of such domains.

  
11.	Restrictions on Proxy Registration Services

The Applicant will in general discourage the use of proxy registration services. The Applicant further understands that there are instances when proxy registrations may be required and will develop best practices when these instances occur. Whilst it is understood that implementing measures to promote WHOIS accuracy is necessary to ensure that the Registrant may be tracked down, it is recognised that some Registrants may wish to utilise a proxy registration service to protect their privacy. In the event that Registrars elect to offer such services, the following conditions apply:

-	Registrars should take the best practice guidance developed by the Applicant and the Governance Council for the gTLD into account when making Proxy registration services available to its Registrants. 
-	Registrars must ensure that the actual WHOIS data is obtained from the Registrant and must maintain accurate records of such data.
-	Registrars must provide Law Enforcement Agencies (“LEA”) with the actual WHOIS data upon receipt of a verified request.

These conditions will be implemented contractually by inclusion of corresponding clauses in the RRA as well as being published on the Abuse page of the Registry website. Individuals and organisations will be encouraged through the Abuse page to report any domain names they believe violate the above restrictions, following which appropriate action may be taken by the Registry Backend Services Provider. Publication of these conditions on the Abuse page of the Registry website ensures that Registrants are aware that despite utilisation of a proxy registration service, actual WHOIS information will be provided to LEA upon request in order to hold Registrants liable for all actions in relation to their domain name. 
The certainty that WHOIS information relating to domain names which draw the attention of LEA will be disclosed results in the gTLD being less attractive to those seeking to register domain names for abusive purposes, thus mitigating the potential for abuse in the gTLD.


12.	Registry Lock

Certain mission-critical domain names such as transactional sites, email systems and site supporting applications may warrant a higher level of security. Whilst the Applicant will take efforts to promote the awareness of security amongst Registrants, it is recognised that an added level of security may be provided to Registrants by ‘Registry locking’ the domain name and thereby prohibiting any updates at the Registry operator level. The Registry lock facility will be offered to all Registrars who may request this service on behalf of their Registrants in order to prevent unintentional transfer, modification or deletion of the domain name. This facility mitigates the potential for abuse by prohibiting any unauthorised updates that may be associated with fraudulent behaviour. For example, an attacker may update nameservers of a mission-critical domain name, thereby redirecting customers to an illegitimate website without actually transferring control of the domain name.
Upon receipt of a list of domain names to be placed on Registry lock by an authorised representative from a Registrar, the Registry Backend Services Provider will:

1. Validate that the Registrar is the Registrar of record for the domain names.
2. Set or modify the status codes for the names submitted to serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited depending on the request.
3. Record the status of the domain name in the Shared Registration System (SRS).
4. Provide a monthly report to Registrars indicating the names for which the Registry lock service was provided in the previous month.


13.	Scope⁄Scale Consistency

The Applicant believes that the proposed collection of protections that involve both proactive and reactive mechanisms outlined above will provide an unmatched level of security and anti-abuse activity within the gTLD and is appropriate for the size and scale of the gTLD. 

13.1	Scope⁄Scale Consistency Specific to Backend Registry Activities

The Registry Backend Services Provider is an experienced backend Registry provider that has developed and uses proprietary system scaling models to guide the growth of its gTLD supporting infrastructure. These models direct the Registry Backend Services Provider’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. The Registry Backend Services Provider periodically updates these models to account for the adoption of more capable and cost-effective technologies. 
The Registry Backend Services Provider’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, The Registry Backend Services Provider derived the necessary infrastructure required to implement and sustain this gTLD and its APM policies.

14.	Acceptable Use Policy

This Acceptable Use Policy gives the Registry the ability to quickly lock, cancel, transfer or take ownership of any domain name, either temporarily or permanently, if the domain name is being used in a manner that appears to threaten the stability, integrity or security of the Registry, or any of its Registrar partners and⁄or that may put the safety and security of any Registrant or user at risk. The process also allows the Registry to take preventive measures to avoid any such criminal or security threats.
The Acceptable Use Policy may be triggered through a variety of channels, including, among other things, private complaint, public alert, government or enforcement agency outreach, and the on-going monitoring by the Registry or its partners. In all cases, the Registry or its designees will alert the Registry’s Registrar partners about any identified threats, and will work closely with them to bring offending sites into compliance.
The following are some (but not all) activities that may be subject to rapid domain compliance:

-	Phishing; a criminal activity employing tactics to defraud and defame Internet users via sensitive information with the intent to steal or expose credentials, money or identities. A phishing attack often begins with a spoofed email posing as a trustworthy electronic correspondence that contains hijacked brand names e.g.(financial institutions, credit card companies, e-commerce sites). The language of a phishing email is misleading and persuasive by generating either fear and⁄or excitement to ultimately lure the recipient to a fraudulent Web site. It is paramount for both the phishing email and Web site to appear credible in order for the attack to influence the recipient. As with the spoofed email, phishers aim to make the associated phishing Web site appear credible. The legitimate target Web site is mirrored to make the fraudulent site look professionally designed. Fake third-party security endorsements, spoofed address bars, and spoofed padlock icons falsely lend credibility to fraudulent sites as well. The persuasive inflammatory language of the email combined with a legitimate looking Web site is used to convince recipients to disclose sensitive information such as passwords, usernames, credit card numbers, social security numbers, account numbers, and mother’s maiden name.
-	Malware; malicious software that was intentionally developed to infiltrate or damage a computer, mobile device, software and⁄or operating infrastructure or website without the consent of the owner or authorized party. This includes, amongst others, Viruses, Trojan horses, and worms. 
-	Domain Name or Domain Theft; the act of changing the registration of a domain name without the permission of its original Registrant.
-	Botnet Command and Control; Services run on a domain name that is used to control a collection of compromised computers or “zombies,” or to direct Distributed Denial of Service attacks (“DDoS attacks”)
-	Distribution of Malware; The intentional creation and intentional or unintentional distribution of “malicious” software designed to infiltrate a computer system without the owner’s consent, including, without limitation, computer viruses, worms, keyloggers, and Trojans. 
-	Fast Flux Attacks⁄Hosting; A technique used to shelter Phishing, Pharming, and Malware sites and networks from detection and to frustrate methods employed to defend against such practices, whereby the IP addresses associated with fraudulent sites are changed rapidly so as to make the true location of the sites difficult to find.
-	Hacking; the attempt to gain unauthorized access (or exceed the level of authorized access) to a computer, information system, user account or profile, database, or security system.
-	Pharming; The redirecting of unknown users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
-	Spam; The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and spamming of websites and Internet forums.
-	Child Pornography: the storage, publication, display and⁄or dissemination of pornographic materials depicting individuals under the legal age in the relevant jurisdiction.
-	Further abusive behaviours include, but are not limited to; Cybersquatting,Front-Running,Gripe Sites, Deceptive and⁄or Offensive Domain Names, Fake Renewal Notices,Cross-gTLD Registration Scam, Name Spinning, Pay-per-Click, Traffic Diversion, False Affiliation, Domain Kiting ⁄ Tasting, fast-flux and 419 scams.

The Registry reserves the right, at its sole discretion, to take any administrative and operational actions necessary, including the use of computer forensics and information security technological services, among other things, in order to implement the Acceptable Use Policy. In addition, the Registry reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on Registry lock, hold or similar status, that it deems necessary, to its discretion; (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 the Registry as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by the Registry or any Registrar in connection with a domain name registration. The Registry also reserves the right to place upon Registry lock, hold or similar status a domain name during resolution of a dispute. 
Registrants must also agree that they will not use their domain for any purposes which are prohibited by the laws of the jurisdiction(s) in which they do business or any other applicable law. You may not use your domain for any purposes or in any manner which violate a statute, rule or law governing use of the Internet and⁄or electronic commerce, including those statutes related to gaming and⁄or online gambling.
In addition, The Applicant reserves the right to deny attempted registrations from repeat violators of the Registry’s Acceptable Use Policy. The Registry’s Acceptable Use Policy will incorporate a certification by the Registrant that the domain will be used only for licensed, legitimate activities, and not to facilitate piracy or infringements. The Registrant will be required to accept these terms as part of its registration agreement. The Applicant reserves the right to suspend or cancel a domain for violation of the Registry’s Acceptable Use Policy.

15. Abuse Response Process

The Registry is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the gTLD, or are part of a real-time investigation by law enforcement. 
Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring Registrar will be notified and be given 48 hours to investigate the activity. This will result in either the take down of the domain name by placing the domain name on hold or the deletion of the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the Registrar has not taken the requested action after the 48-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry may place the domain on “ServerHold”. Although this action removes the domain name from the gTLD zone, the domain name record still appears in the gTLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.
 
Additionally, the Applicant will require Registrars to adhere to the following abuse-prevention procedures:

-	Each new gTLD accredited Registrar must provide and maintain a valid primary point of contact for abuse complaints. The Applicant will require this as part of the new gTLD RRA.
-	The Applicant will explicitly define for Registrars what constitutes abusive behaviour including but not limited to, malicious, negligent, and reckless behaviour. The definition of abusive behaviour will be contained in the AUP and the Applicant will require this as part of the new gTLD RRA.
-	Registrars must notify the Registry Operator immediately regarding any investigation or compliance action including the nature of the investigation or compliance action by ICANN or any outside party (e.g., law enforcement, etc.), along with the gTLD impacted. This will be required as part of the new gTLD RRA.
-	The Applicant will initiate an Abuse Prevention and Mitigation Working Group. This group will be developed in conjunction with the gTLD Governance Council mentioned above. Its aim will be to give the Applicant’s team alternate perspectives about handling incidents of abuse and ways to mitigate them. The group will meet regularly to discuss the latest trends in domain name abuse and the most effective way to prevent and remedy them for the gTLD.
-end-

Q29
The Applicant will be implementing an extensive range of Rights Protection Mechanisms (“RPMs”) designed to minimize abusive registrations and other activities that may affect the legal rights of others. The Applicant will implement and comply with all ICANN required RPMs and will in addition implement further measures to better protect the rights of others and minimize abusive registrations.

The following is an overview of Applicantʹs response to Q29:

1.	Rights Protection as a core objective
2.	Plans for Rights Protection Mechanisms as part of Start-Up
3.	ICANN Mandated Rights Protection Mechanisms
3.1.	Trademark Clearinghouse (“TMCH”)
3.2.	Applicant’s Sunrise Period (“ASP”)
3.3.	Trademark Claims Service (“TCS”)
3.4.	Uniform Domain Name Dispute Resolution Policy (“UDRP”)
3.5.	Uniform Rapid Suspension System (ʺURSʺ)
3.6.	Trademark Post-Delegation Dispute Resolution Procedure (“PDDRP”)
4.	Additional Rights Protection Mechanisms to be implemented by the Applicant on a Voluntary Basis
4.1.	Mechanism to protect IGO Names (“PIN”)
4.2.	Mechanism for Further Protection of Capital City Names (“CCC”)
5.	Efforts to promote WHOIS Accuracy
5.1.	Thick WHOIS
5.2.	Semi Annual Audits to Ensure Accurate WHOIS
6.	Policies Handling Complaints Regarding Abuse and Rights Issues
7.	Registry Acceptable Use Policy(“AUP”)
8.	Monitoring for Malicious Activity
9.	Resourcing Plans Specific to Backend Registry Activities


1 Rights Protection as a core objective
The Applicant is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory RPMs contained in the Applicant Guidebook and detailed in Specification 7 of the Registry Agreement. Use of domain names that infringe upon the legal rights of others in the gTLD will not be tolerated and preventing abusive registrations is a core objective of the Applicant. The nature of such uses creates security and stability issues for the Registry, Registrars, and Registrants, as well as for users of the Internet in general. The Applicant will prevent abusive registrations and reduce opportunities for behaviours such as phishing or pharming by implementing comprehensive registration, anti-abuse, and rights protection guidelines as defined in its AUP, as well as innovative additional RPMs such as PIN and the CCC, as described below. In order to identify and address the abusive use of registered names on an ongoing basis, the Applicant will also incorporate and abide by all mandated RPMs as specified in Specification 7 of the Registry Agreement and as adopted by the ICANN Board of Directors as ICANN Consensus Policies.

2 Plans for Rights Protection Mechanisms as part of Start-Up

The timeline for start-up RPMs in the Applicantʹs gTLD is as follows:

Phase 1 – Sunrise Process:

-	Day 1: Sunrise round opens
-	Day 60: Sunrise round Closes
-	Day 61: Sunrise Allocation including Contention Resolution Mechanisms (ʺCRMʺ) opens
-	Day 71: Sunrise Allocation CRM closes

-	The following Rights Protection Mechanisms apply: 
	a.	TMCH
	b.	Sunrise Eligibility Requirements (“SER”)
	c.	Sunrise Dispute Resolution Policy (“SDRP”)
	d.	UDRP
	e.	URS
	f.	PIN
	g.	TCS*

Phase 2 – Landrush process:

-	Day 72: Landrush opens
-	Day 102: Landrush closes
-	Day 103: Landrush CRM opens
-	Day 113: Landrush CRM closes

-	The following Rights Protection Mechanisms apply:
	a.	UDRP
	b.	URS
	c.	PIN
	d.	CCC
	e.	TCS*

Phase 3 – General Availability⁄Registrations:

-	Day 114: General availability begins

-	The following Rights Protection Mechanisms apply:
	a.	UDRP
	b.	URS
	c.	PIN
	d.	PDDRP 
	e.	TCS* (90 days)

* To ease the concerns of trademark owners and mitigate the impact of infringing registrations, the Applicant will be implementing the Trademark Claims service in all three phases of launch. It is important to note that during the General Availability Phase, the Trademark Claims service will be used for 90 days, 30 days longer than the ICANN mandated minimum.

3 ICANN Mandated Rights Protection Mechanisms

3.1 Trademark Clearinghouse (“TMCH”)
The first mandatory RPM required of each new gTLD Registry is support for, and interaction with, the TMCH. The TMCH is intended to serve as a central repository for information pertaining to the rights of trademark holders to be authenticated, stored, and disseminated. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although the operational details of how the TMCH will interact with Registry operators and Registrars are still being developed by ICANN, the Applicant is actively monitoring the developments of the Implementation Assistance Group (“IAG”). The IAG is working with ICANN staff to refine and finalize the rules, procedures and technical requirements for the TMCH. In addition, the gTLD’s Registry Backend Services Provider is actively participating in the IAG to ensure that the protections afforded by the clearinghouse and associated RPMs are feasible, implementable, and well understood.

Utilizing the TMCH, the Applicant will offer: (i) a Sunrise registration service for 60 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a TCS in all 3 phases of launch including 90 days after phase 3 general availability.

3.2 Applicant’s Sunrise Period (“ASP”)
All domain names registered during the Sunrise Period will be subject to the Applicant’s domain name registration policy. The Applicant will surpass ICANNʹs mandated minimum by offering a Sunrise Period for sixty (60) days. Owners of trademarks listed in the TMCH that also meet the Applicant’s domain name registration requirements will be able to register domain names that are an identical match of their listed trademarks. The Applicant has engaged Famous Four Media Limited (“FFM”) as well as other suppliers to assist with this process. The FFM Sunrise Validation Team will consist of a minimum of 11 employees who will work with the Applicant’s Trademark Validation Team (“TVT”) and outside counsel, to receive and authenticate all Sunrise registrations.

Registrars who are accredited to sell names in the gTLD will ensure that all Sunrise Registrants meet SERs, which will be verified by Clearinghouse data. The proposed SERs include: (i) ownership of a mark that is (a) nationally or regionally registered and for which proof of use, such as a declaration and a single specimen of current use – was submitted to, and validated by, the TMCH; or (b) that have been court-validated; or (c) that are specifically protected by a statute or treaty currently in effect and that was in effect on or before 26 June 2008, (ii) optional Registry-elected requirements regarding the international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark. 

Upon submission of all of the required information and documentation, the Registrar will forward the information to the Applicant’s TVT for authentication. The Applicant’s TVT will review the information and documentation and verify the trademark information and registration eligibility, and notify the potential registrant of any deficiencies. 

The Applicant will also incorporate a SDRP. The SRDP will allow challenges to Sunrise Registrations by third parties after acceptance of the registration based on the following four grounds: (i) at the time the challenged domain name was registered, the registrant did not hold a trademark registration of national or regional effect or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national or regional effect or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not have the necessary protections on or before the effective date of the Registry Agreement.

After receiving a Sunrise Complaint, the TVT will review the Complaint to see if the Complainant reasonably asserts a legitimate challenge as defined by the SDRP. If not, the TVT will send a notice to the Complainant that the complaint does not fall within one of the delineated grounds as defined by the SDRP and that the Applicant considers the matter closed.

If the domain name is found to not meet the SERs, the TVT will immediately suspend the domain name. Thereafter, the TVT will immediately notify the Sunrise Registrant of the suspension of the domain name, the nature of the complaint, and provide the registrant with the option to correct the SER deficiencies in a timely manner or the domain name will be cancelled. 

If the registrant responds in a timely manner, the response will be reviewed by the TVT to determine if the SERs are met. If the TVT is satisfied by the registrant’s response, the TVT will submit a request to lift the suspension of the domain name and notify the Complainant that their dispute was denied. If the registrant does not respond in a timely manner, the TVT will then notify the Complainant that the complaint was upheld and the registration will be cancelled.

3.3 Trademark Claims Service
The Applicant will offer a TCS in Sunrise and Landrush as well as 90 days of general registration (30 days longer than the ICANN mandated minimum period.) The TCS will be monitored by the TVT. Registrars who are accredited to sell names in the gTLD will be required to review all domain names requested to be registered during the Trademark Claims period to determine if they are an identical match of a trademark that has been filed with the TMCH. A domain name will be considered an identical match when the domain name consists of the complete and identical textual elements of the mark, and includes domain names where (a) spaces contained within a mark are either replaced by hyphens or omitted; (b) certain special characters contained within a trademark are spelled out with appropriate words describing it (e.g., @ and &); and (c) punctuation or special characters contained within a mark that are unable to be used in a second-level domain name are either (i) omitted or (ii) replaced by hyphens or underscores. Domain names that are plural forms of a mark or that merely contain a mark as a sub string will not qualify as an identical match.

If the Registrar determines that a prospective domain name registration is identical to a mark registered in the TMCH, the Registrar will be required to ensure that a “Trademark Claims Notice” (“Notice”) in English is sent to the prospective registrant of the domain name and a blind copy is sent to the Applicant’s TVT. The Notice will provide the prospective registrant with information regarding the trademark referenced in the notice to enhance understanding of the Trademark rights being claimed by the trademark holder. The Notice will be provided in real time without cost to the prospective registrant. 

After sending the Notice, the Registrar will require the prospective registrant to specifically warrant within five (5) days that: (i) the prospective registrant has received notification that the mark(s) is included in the Clearinghouse; (ii) the prospective registrant has received and understood the notice; and (iii) to the best of the prospective registrant’s knowledge that the registration and use of the requested domain name will not infringe on the rights that are the subject of the notice. If the warranty satisfies these requirements, the Registrar will effectuate the registration and notify the Applicant’s TVT. 

After the effectuation of a registration that is identical to a mark listed in the TMCH, the Registrar will be required to notify the trademark owner that a domain name representing the listed mark has been registered. A copy of this communication will also be sent to the TVT. The trademark owner then has the option of filing a Complaint under the UDRP and the URS against the domain name registrant. The Applicant will require in its relevant agreements that the Registry, Registrar, and registrant all submit to and abide by the determinations of the UDRP and the URS providers.

3.4 Uniform Domain Name Dispute Resolution Policy
The Applicant will abide by all decisions rendered by UdrpP providers and will specify in its Registry Registrar Agreement (ʺRRAʺ) and Registration Agreements (ʺRAʺ) that all parties must also abide by all decisions made by panels in accordance with the UDRP. On the Applicant’s Registry website, the Applicant will designate a Rights Protection Contact (“Rights Contact”) which will receive all UDRP Complaints and decisions. Upon receipt of a determination, the Rights Contact will work with technical staff at the Registry Backend Services Provider to temporarily lock any domain names as required, and will notify the appropriate Registrar to cancel or transfer all registrations determined by a UDRP panel to be infringing. 

3.5 Uniform Rapid Suspension System
The Applicant will implement the URS as provided in the Applicant Guidebook. The Applicant will also specify in its RRA that all parties abide by all decisions made by panels in accordance with the URS. In response to complaints made by trademark owners that the UDRP was too cost prohibitive and slow, and that more than 70 percent of UDRP cases were “clear cut” cases of cybersquatting, ICANN adopted the Implementation Review Team’s (ʺIRTʺ) recommendation that all new gTLD registries be required, pursuant to their contracts with ICANN, to take part in a URS. The purpose of the URS is to provide a more cost effective and timely mechanism for brand owners than the UDRP to protect their trademarks and to promote consumer protection on the Internet. 
The URS is not meant to address questionable cases of alleged infringement (e.g., use of terms in a generic sense) or for anti-competitive purposes or denial of free speech, but rather for those cases in which there is no genuine contestable issue as to the infringement and abuse that is taking place. 
Unlike the UDRP which requires little involvement of gTLD registries, the URS envisages much more of an active role at the Registry-level. For example, rather than requiring the Registrar to lock down a domain name subject to a UDRP dispute, under the URS it is the Registry that must lock the domain within 24 hours of receipt of the complaint from the URS Provider to restrict all changes to the registration data, including transfer and deletion of the domain names. 
The Rights Contact will receive all URS Complaints verified by the URS Provider and provide its contact information. In the event of a decision in favour of the complainant, the Registry is required to suspend the domain name. This suspension remains in effect for the remainder of the registration period and would not resolve the original website. The nameservers would be redirected to an informational web page describing the URS Process. The WHOIS for that domain will state that the domain name will not be able to be transferred, deleted, or modified for the life of the registration. Finally, there is an option for a successful complainant to extend the registration period for one additional year at commercial rates. Upon receipt of a decision in the registrant’s favour, Rights Contact will notify the Registry operator to unlock the domain name.

3.6 Trademark Post-Delegation Dispute Resolution Procedure (“PDDRP”)
The Applicant will participate in all post-delegation procedures required by the Registry agreement, including the PDDRP, and will abide by any decisions of any PDDRP Provider as required in Specification 7 of the Registry Agreement.


4 Additional Rights Protection Mechanisms to be implemented by the Applicant

4.1 Mechanism to Protect IGO Names
The Applicant considers the Protection of Intergovernmental Organization (ʺIGOʺ) names to be very important. The Applicant will use strings registered as second level domains in the .int gTLD as the basis for this protection. To register in the .int domain, the Registrants must be an IGO that meets the requirements found in RFC 1591. The .int domain is used for registering organizations established by international treaties between or among national governments and which are widely considered to have independent international legal personality. Thus, the names of these organizations, as with geographic names, can lend an official imprimatur, and if misused, be a source of public confusion or deception. 

Reservation of IGO names:
In addition to the mandated and additional reservation of geographic names as provided for in response to Question 22, the Applicant will reserve, and thereby prevent registration of, all names that are registered as second level domains in the most recent .int zone as of 1st November 2012. By doing so, the Applicant will extend additional protection to IGOs that comply with the current eligibility requirements for the .int gTLD as defined at http:⁄⁄www.iana.org⁄domains⁄int⁄policy⁄, and that have obtained a second-level registration in the .int zone. 

Release of IGO names:
In the future, should any of the IGOs wish to make use of the protected strings, the Registry will release and assign the domain to the respective IGOs using the following process:

a)The IGO submits a request to the Applicant in the hope of the reserved name being assigned to themselves and provides the necessary documentation and details of the proposed registrant entity for the domain name registration.
b)The Applicant will validate and authenticate the request to establish that it is a genuine bona fide request.
c)Once the request has been approved the Applicant will notify the requesting IGO as well as ICANN and the GAC of the approval for the assignment of the domain name.
d)The Applicant will issue a unique authorization code to the proposed IGO registrant.
e)The proposed IGO registrant will then be able to request that the assignment of the domain name is given to them using the authorization code with an ICANN and gTLD accredited Registrar of their choice.

4.2 Mechanism for Further Protection of Capital City Names
In parallel with the Landrush Period defined in the answer to question 18, the Applicant will implement a Capital City Claim (CCC) service whereby additional protection will be granted to the capital city names of a country or territory listed in the ISO 3166-1 standard. The CCC process is as follows:
a)Any prospective domain name registrant applying to register a domain name identical to the capital city name of a country or territory listed in the ISO 3166-1 standard will receive from the Applicant a CCC notification highlighting the fact that the applied-for domain name matches a capital city name of a country or territory listed in the ISO 3166-1 standard. 
b)A potential domain name registrant receiving a CCC notification will have to send a response to the Applicant whereby they will agree to unconditionally comply with requirements as to representations and warranties required by the Applicant in order to protect the reputation of the capital city as well as any further relevant terms and conditions provided.
c)Unconditional acceptance of the warranties set out in the CCC notification will be a material requirement for a prospective registrant to be eligible to register the domain name in question should said prospective registrant be successful in the Landrush period.
d)Upon registration during the Landrush period of a domain name identical to a capital city name of a country or territory listed in the ISO 3166-1 standard, the Applicant will send a notification in writing to the ICANN Government Advisory Committee (ʺGACʺ) Chair.

5 Efforts to promote WHOIS Accuracy

5.1. Thick WHOIS
The Applicant will include a thick searchable WHOIS database both accessible on port 43 as well as on port 80 (http) as required in Specification 4 of the Registry Agreement. A thick WHOIS provides numerous advantages including a centralized location of registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience, as well as greater transparency, a factor critical to rights holders as well as law enforcement in pursuing abusive uses of a domain.

5.2. Bi-Annual Audits to Ensure Accurate WHOIS
The Applicant’s TVT will perform a bi-annual review of a random sampling of domain names within the applied-for gTLD to test the accuracy and authenticity of the WHOIS information. Through this review, the Applicant’s TVT will examine the WHOIS data for evidence of inaccurate or incomplete Whois information. In the event that such errors or missing information exists, it shall be forwarded to the Registrar, who shall be required to address such deficiencies with its Registrants. 

6 Policies Handling Complaints Regarding Abuse and Rights Issues
In addition to the RPMs addressed above, the Applicant will implement a number of measures to handle complaints regarding the abusive registration of domain names in its gTLD that may infringe on the rights of others. Further details are described in the response to Question 28.

7 Registry Acceptable Use Policy
One of the key policies each new gTLD Registry needs is to have an AUP that clearly delineates the types of activities that constitute “abuse” and the repercussions associated with an abusive domain name registration. The policy must be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the Registry to take the appropriate actions based on the type of abuse. This may include locking down the domain name preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name “on hold” rendering the domain name non-resolvable, transferring the domain name to another Registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. The gTLD’s AUP, set forth in our response to Question 28, will include prohibitions on phishing, pharming, dissemination of malware, fast flux hosting, hacking, and child pornography. In addition, the policy will include the right of the Registry to take action necessary to deny, cancel, suspend, lock, or transfer any registration in violation of the policy. 
In addition, the Applicant reserves the right to deny attempted registrations from repeat violators of the Registry’s AUP. The Registry’s AUP will incorporate a certification by the registrant that the domain will be used only for licensed, legitimate activities, and not to facilitate piracy or infringements. The registrant will be required to accept these terms as part of its registration agreement. The Applicant reserves the right to suspend or cancel a domain for violation of the Registry’s AUP.

8 Monitoring for Malicious Activity 
The Applicant is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the AUP are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the gTLD, or are part of a real-time investigation by law enforcement. 
Once a complaint is received or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring Registrar will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety, or to provide a compelling argument to the Registry to keep the name in the zone. If the Registrar has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry may place the domain on “ServerHold”. Although this action removes the domain name from the gTLD zone, the domain name record still appears in the gTLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.

9 Resourcing Plans Specific to Backend Registry Activities
Responsibility for rights protection rests with a variety of functional groups. The Trademark Validation Team and Sunrise Validation Teams are primarily responsible for investigating claims of marks for domain registration. The customer service team also plays an important role in assisting with the investigations, responding to customers, and notifying Registrars of abusive domains. Finally, the Policy⁄Legal team is responsible for developing the relevant policies and procedures. 

This function will be performed by ARI. Abuse services will be supported by the following departments:

- Legal, Abuse and Compliance Team - 6 people
- Development Team - 11people


The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of gTLDs that ARI provides Registry services to.

ARI provides Registry backend services to 5 gTLDs and has very substantial experience in estimating the number of resources required to support a Registry system.

Based on past experience ARI estimates that the existing staff is adequate to support a Registry system that supports in excess of 50M domains. 

ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.

The measures described serve to prevent and mitigate abusive behavior in the gTLD as well as activities that may infringe. These responsibilities will be undertaken by two teams. ARI’s Development Team will be responsible for developing the technical platforms and meeting technical requirements needed to implement the RPMs discussed above ARI’s Legal, Abuse and Compliance Team will be responsible for the ongoing operations of our measures to minimize abusive registrations and other activities that affect trademark rights recognized through the RPMs.

ARI Legal, Abuse and Compliance Team
ARI’s Policy Compliance Team will be staffed by five full-time people. These roles will entail the following:

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

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

The team consists of:

- Policy Compliance Officers - 4 people
- Legal Manager – 1person

Based on the projections and the experience of ARI, the resources described here are more than sufficient to accommodate the needs of this gTLD.

ARI Development Team
All tools and systems used for the transmission and receipt of information related to rights protection mechanisms will be developed and maintained by ARI. ARI has a Development Team dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.

ARI will ensure that systems and tools will be compliant with the appropriate processes for dealing with Registrars, the TMCH, URS and Trademark PDDRP providers as these processes are defined. ARI has been and will remain active in the formulating of these processes. ARI will use its resources to remain current with the approved measures for exchange of RPM-related material or any other material relevant to RPMs, whether that is during sunrise, landrush or on an ongoing basis. This team consists of:

- Development Manager - 1 person
- Business Analysts - 2 people
- Developers - 6 people
- Quality Analysts - 2 people

Administrative Services Provider – Famous Four Media Limited

In addition to those resources set out above provided by the Registry’s backend services provider the Applicant‘s Administration Services Provider shall provide the following extra resources:
-Sunrise Validation Team - This shall comprise of 11 employees of which at least one shall be a qualified lawyer specializing in intellectual property law.
-Ongoing Rights Protection Team - This shall comprise of 11 employees of which at least one shall be a qualified lawyer specializing in intellectual property law.
The two key objectives of the Sunrise Validation Team and the Ongoing rights Protection Team (together the “Rights Team”) is to:

a)Prevent abusive registrations; and
b)Identify and address the abusive use of registered names on an ongoing basis
Given that rights protection is a fundamental core objective of the Applicant it has contracted with its Registry Administration Services Provider that the number of full time personnel made available to the Applicant will be 125% of the estimated requirement to ensure that at all times the Applicant is over resourced in this area.
In addition the Applicant shall instruct outside Counsel in any relevant jurisdiction on all matters that are unable to be adequately dealt with by the Sunrise Validation Team or the Ongoing Rights Protection Team.
-end-

Q30A
The Applicant has engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background on ARI see attachment ‘Q30a – ARI Background & Roles.pdf’. This response describes Security as implemented by ARI under direction from the Registry operator taking into account any specific needs for this TLD.

1 SECURITY POLICY SUMMARY
ARI operates an ISO27001 compliant Information Security Management System (ISMS) for Domain Name Registry Operations; see attachment ‘Q30a – SAI Global Certificate of Compliance.pdf’. The ISMS is an organisation-wide system encompassing all levels of Information Security policy, procedure, standards, and records. Full details of all the policies and procedures included in the ISMS are included in the attachment to Question 30b.

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

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

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

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

1.2.3 Problem Management
The goal of problem management is to drive long term resolution of underlying causes of incidents. This centres on finding and resolving the root causes of incidents. It defines escalation points to third parties or other ARI departments such as Development, as well as verification of the solution prior to problem closure.

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

1.2.5 Access Management
This process handles all access changes to systems. HR must authorize new users, and access changes are authorized by departmental managers and approved by the Information Security Officer.
When staff leave or significantly change roles, a separation process is followed which ensures all access that may have been granted during their employment (not just their initially granted access) is checked and where appropriate, revoked.
Finally, quarterly review of all access is undertaken by the ISO, reviewing and approving or rejecting (with an action ticket) as appropriate.

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

2.1 Physical Security Infrastructure
ARI maintains a series of physical security infrastructure measures including but not limited to biometric and physical key access control to secured areas and security camera recording, alarm systems and monitoring.

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

The Applicant will be implementing a thorough and extensive Abuse Prevention and Mitigation plan, designed to minimise abusive registrations and other detrimental activities that may impact security and negatively impact internet users. For other security related initiatives undertaken by the Applicant see Q28.

4 AUGMENTED LEVEL OF SECURITY
This TLD is a generic TLD and as such requires security considerations that are commensurate with its purpose.

The following attributes describe the security with respect to the TLD:
-ARI, follows the highest security standards with respect to its Registry Operations. ARI is ISO 27001 certified and has been in the business of providing a Registry backend for 10 years. ARI have confirmed their adherence to all of the security standards as described in this application. As per recommendation 24 this ensures that the technical implementations do not compromise elevated security standards
-Registrant will only be permitted to make changes to their domain name after a authenticating to their Registrar.
-Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
-Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
-Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
-Registrars will only be permitted to use a certificate signed by ARI to connect with the Registry systems. Self-signed certificates will not be permitted.
-The Registry is DNSSEC enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to question 43. The following additional requirements will exist for Registrars who want to get accredited to sell this TLD:
-Registrars must support DNSSEC capabilities within its control panels.
-If the Registrar provides Managed DNS services to Registrants within this TLD they must provide the option for DNSSEC. This ensures that DNSSEC is deployed at each zone and subsequent sub-zones at Registry, Registrar and Registrant level as per recommendation 26.
-Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 27. This is described in detail in our responses to Question 24 and Question 25.
-Registrant access to all Registrar and Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 28. This is described in detail in our response to Question 25, Question 27 and Question 29.
-All communication between the Registrar or the Registrars systems and the registry system is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57. This includes the following communication:
-Secure websites and control panels provided by the Registrar to the Registrant.
-Ticketing systems provided by the Registrar to the Registrant.
-Web and EPP interfaces provided by ARI to the Registrars.
-Ticketing systems provided by ARI to the Registrar.
-Any communication between the Registrant, Registrar and Registry that is deemed as critical or contains credentials or sensitive information.
Where these requirements put controls on Registrars these will be enforced through the RRA.

BITS Recommendations
The Applicant will structure its policies around the BITS Recommendations where relevant to this gTLD.
The Applicants goal with this gTLD is to provide a safe and secure browsing experience for consumers of this gTLD. A domain within this gTLD that is owned, operated by or compromised by a malicious party could cause harm to consumers, to the TLD’s reputation and to the reputation of the Internet itself. As such, additional controls are in place relating to the validity of registrations, as well as additional measures to ensure the correct identity of both Registrants and Registrars relating to changes made within the SRS, and to protecting the integrity of the DNS service as a whole.
The Security Standards Working Group (ʺSSWGʺ) formed by BITS drafted a set of policy recommendations that should be applied to financial TLDs. The policy comprises of a set of 31 recommendations that should be adopted by ICANN in evaluating any applicant of a financial TLD. The recommendations were posted by BITS in the form of a letter to ICANN at [http:⁄⁄www.icann.org⁄en⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf]
We welcome the recommendations from SSWG and will strongly consider the recommendations relating to the implementation of this gTLD where considered relevant.

Coalition for Online Accountability (“COA”) Recommendations
The Applicant will structure its policies around the COA Recommendations where relevant to this gTLD.
The Applicant’s goal with this gTLD is to provide a safe and secure browsing experience for consumers of this gTLD. A domain within this gTLD that is owned, operated by or compromised by a malicious party could cause harm to consumers, to the gTLDʹs reputation and to the reputation of the Internet itself. As such, additional controls are in place relating to the validity of registrations, as well as additional measures to ensure the correct identity of both Registrants and Registrars relating to changes made within the SRS, and to protecting the integrity of the DNS service as a whole.
The COA have drafted a set of policy recommendations, also endorsed by many other international organizations representing the creative industries, that should be applied to entertainment gTLDs -especially those dependent on copyright protection. The policy comprises of a set of 7 recommendations that should be adopted by ICANN in evaluating any applicant for an entertainment-based gTLD. The recommendations were posted by COA in the form of a letter to ICANN at http:⁄⁄bit.ly⁄HuHtmq.
We welcome the recommendations from the COA and will strongly consider the recommendations relating to the implementation of this gTLD where considered relevant.

5 RESOURCES
This function will be performed by ARI. Resources allocated to deliver the services:
-Executive Management 4 staff,Production Support Group 27 staff
ARI has ten years’ experience designing, developing, deploying, securing and operating critical Registry systems, as well as TLD consulting and technology leadership.
ARI’s senior management are technology and methodology leaders in their respective fields who ensure the organisation maintains a focus on technical excellence and hiring, training and staff management.
Executive Management is heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
-COO,CTO
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q30a -ARI Background & Roles.pdf’.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. See attachment ‘Q30a -Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Production Support Group is responsible for the deployment and operation of TLD registries.
-Production Support Manager (also the ISO)
-Service Desk:
-1 Level 1 Support Team Lead, 8 Customer Support Rep(Level 1 support), 1 Level 2 Support Team Lead, 4 Registry Specialists (Level 2 support),
-Operations (Level 3 support):
-1 Operations Team Lead, 2 Systems Admin, 2 Database Admin, 2 Network Engineers
-Implementation:
-1 Project Manager, 2 Systems Admin,1 Database Admin,1 Network Engineers
ARI employs a rigorous hiring process and screening (Police background checks for technical staff and Australian Federal Government ‘Protected’ level security clearances for registry operations staff).
-end-

Charles Ashley Richard Melvin	Chief Operating Officer
Iain Simon Roache	Chief Executive Officer
Timothy James Ireton	Chief Financial Officer

New gTLD Application Submitted to ICANN by: Exclusive Registry Limited

String: men

Originally Posted: 13 June 2012

Application ID: 1-1215-86537

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.