Application number: 1-1171-93026 for Tucows TLDs Inc.

Tucows TLDs Inc.

96 Mowat Avenue
Toronto Ontario M6K 3M1
CA

+1 416 538 5493

+1 416 531 1257

http:⁄⁄www.tucowsinc.com

Ms. Sharon ORourke

Executive Assistant

+1 416 538 5493

+1 416 531 1257

sorourke@tucows.com

Mr. Elliot Noss

President and CEO

+ 1 416 538 5494

enoss@tucows.com

Ontario Corporation

Incorporated under laws of Ontario Canada http:⁄⁄www.e-laws.gov.on.ca⁄html⁄statutes⁄english⁄elaws_statutes_90b16_e.htm#BK1

Not Available

Tucows.com Co, a wholly owned subsidiary of Tucows Inc. traded as TCX on NYSE Amex and TSX Exchanges

Allen Karp
Director, Member of Audit Committee
Elliot Noss
Director
Erez Gissin
Director
Eugene Lucas Fiume
Director
Jeffrey Nathan Schwartz
Director, Chair of Audit Committee, Member of Corporate Governance Committee
Joichi Ito
Director
Lloyd Morrisett
Director, Member of Audit and Corporate Governance Committees
Rawleigh Hazen Ralls IV
Director
Stanley Stern
Chairman, Chair of Corporate Governance Committee

Carla Goertz
Executive VP Human Resources
David John Woroch
Executive VP Sales and Support
Elliot Noss
President and CEO
Kenneth Derrick Schafer
Executive VP Product Management & Marketing
Michael Cooperman
CFO

group

Not Available

We ensured that there are no known operational or rendering problems concerning the applied-for gTLD string in three ways:
First, we researched whether any top-level string composed of the letters of the Latin alphabet has ever had any operational or rendering problems. We concluded from that research that there is no third-party experience or knowledge that would lead us to believe that there is any operational or rendering problems with the applied-for gTLD string.
Second, using Minds + Machines’ Espresso system, we created a test-bed version of the applied-for gTLD string as a top-level domain. We then conducted a series of tests, including simulations of many of the dayto-day registry functions, and found no operational or rendering problems.
Finally, we consulted with Robert Martin-Legène of PCH who confirmed that there are no known rendering issues with Latin alphabet domains at the second or at the top level. We concluded that there are no known operational or rendering problems with the applied-for gTLD string.

The purpose of .GROUP is to provide the worldwide Internet-using public with a greater selection of memorable and semantically relevant domain names than allowed by the current overcrowded gTLD namespaces, particular .COM, .NET and .ORG. 

The mission of .GROUP is to improve the use of the domain name space for the hundreds of thousands of people that have an existing domain name registration ending in “group.TLD” and to make memorable, relevant names available to new registrants.

Over the past decade, the market for domain name registrations has grown at a tremendous pace. From 2000 to 2011 domain name registrations increased from 40 million to 220 million domain names registered globally. Approximately 60% of these are gTLDs. The .COM TLD alone has almost 100 million domains currently registered.
Due to the success of these existing TLDs, new registrants often find the namespace so crowded that they have difficulty choosing a domain name that meets their needs - particularly in terms of memorability and semantic relevance to their purpose (i.e. The domain they end up with doesn’t always reflect the true nature of the site they are creating). 

Currently over 650,000 people have chosen domains of the form “〈name〉.GROUP.COM” with many more doing so in other generic top-level domains. For all of these registrants .GROUP provides the opportunity to use a simpler, more memorable domain, i.e. “〈name〉.GROUP”.

Because .GROUP brings more meaning to the namespace, it will provide Internet users with an easier means of recognizing the purpose and intent of the registrant. We believe less confusion provides a substantial benefit to the Internet user community, as it will allow them to more easily and more readily understand the purpose or motives of the registrant’s website or email, allowing for better, more efficient and more effective use of their time online.

.GROUP will protect third-party rights and prevent abusive uses of a .GROUP domain name. We intend to achieve this goal by making our Naming Policy, Acceptable Use Policy, and other policies readily understandable and easily accessible, and by making sure that our mechanisms for enforcing rights and preventing abuse (such as our Complaint Resolution Service) operate effectively, efficiently, and fairly, as well as by ensuring that they work in concert with other ICANN-mandated rights protection mechanisms such as the UDRP.

We have crafted a draft framework for registration of .GROUP domains that fully support the goals, mission and purposes set forth above. Our draft registration framework is based on advice from ICANN, WIPO, applicable laws, and a variety of other expert sources.

We are also able to draw on our vast experience in operating a significant portion of the existing domain name system. We are acknowledged by most as the industry leader in registrant-friendly policies and processes.

Specifically, the .GROUP draft framework includes these interrelated agreements setting forth our policies and regulations, all of which registrants must agree to be bound by: - The Registrant Agreement, which registrars contracted with .GROUP must present to registrants. This is a collateral agreement to the Registrar Registry Agreement (detailed below), and will bind registrants to .GROUPʹs Acceptable Use Policy (as detailed below), .GROUP’s Privacy & Whois Policy (detailed below), ICANN-mandated rights protection mechanisms (including the Universal Dispute Resolution Policy (“UDRP”), and the Complaint Resolution Service; - The Acceptable Use Policy (“AUP”), which details the proper use of domain names that end in .GROUP, which is incorporated by reference in the Registrant Agreement that registrants must agree to; - The Privacy and Whois Policy, which describes how a registrant’s personal data is to be used, which is also incorporated by reference in the Registrant Agreement; - The Registrar-Registry Agreement, which is the contract between .GROUP and its ICANN-accredited registrars which sets forth, inter alia, the duties and obligations of the registrar with respect to .GROUP registrants and the .GROUP registry; and - The Naming Policy, which sets out .GROUP’s policies governing prohibited, blocked or reserved domain names. These agreements and policies are designed to ensure transparent and non-discriminatory policies for the registration of .GROUP names; fair and competitive pricing; protection of personal data and privacy; adherence by registrars and registrants to the AUP; protection of trademarks, the names of natural and juristic persons and other property rights; prevention of the registration of illegal terms; and the prevention of violations of the law. Moreover, our policies promote competition among registrars, combat abuse of the DNS, address cybercrime, protect intellectual property rights, and align the .GROUP top-level domain with applicable regulatory and legislative environments and Internet registry best practices. These policies will effectively support the key mission, purposes and goals of the .GROUP top-level domain, which is to allow registrants who want to associate themselves with .GROUP while at the same time protecting third-party rights and preventing abuse.

No

Not Available

No

--PROPOSED MEASURES FOR PROTECTION OF GEOGRAPHIC NAMES AT THE SECOND AND OTHER LEVELS IN THE APPLIED-FOR GTLD--

We have accepted the advice of the Governmental Advisory Committee (GAC) that we should adopt appropriate procedures to block names with national or geographic significance at the second and other levels, and will do so in the manner described below:

The country and territory names contained in the following internationally recognized lists will be initially reserved at the second level, as follows:

The short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union; on the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and on the list of United Nations member states in the six official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

Procedurally, the geographical names contained in these lists, as described in Specification 5 of the New gTLD Agreement, will be added to the registry software system “prohibited word” function. This function, part of Espresso, our registry platform, allows strings to be blocked from registration. Upon an attempt via the EPP or web interface, the registration will not be allowed. Any attempt to register a domain containing those geographical names will be automatically denied, as they were similarly blocked in the .INFO TLD. If a Government or public authority decides to register a geographic name which has been blocked by the process describe above, the .INFO procedure for notice, authentication, and registration will be substantially adhered to, as follows:

 1. The Government or public authority concerned informs the GAC Secretariat of their request to register the name, and the designated beneficiary.
 2. The GAC Secretariat authenticates the request and transfers it to the ICANN staff and to the registry operator.
 3. The registry operator verifies the availability of the name and issues an authorization number that is transmitted directly to the designated beneficiary in the country concerned.
 4. The designated beneficiary (the Registrant) registers the name, paying the normal fee, with an ICANN-accredited registrar contracted with the registry operator using the authorization number as their authority.

The registry operator may at some point seek agreement with the applicable governments to release these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.

For protection of geographic names at other levels, we have a complaint mechanism in place and any geographic entity may register a complaint if they feel their national rights have been violated.

We believe that the measures outlined above incorporate GAC’s advice and serve as a pledge to block, at no cost to governments, geographically significant names and allow a means of challenging any abuse of the use of a geographically significant name.

We have selected Minds + Machines as our backend registry provider. Minds + Machines currently operates the .FM TLD and has a proven registry system. The names and full descriptions of the registry services Minds + Machines will provide are summarized in this section.

Minds + Machines will provide the critical registry functions as well as the usual and customary functions provided by a backend registry operator:

 1. The receipt of data from registrars concerning registrations of domain names and name servers (SRS) via EPP,
 2. Dissemination of top-level domain (TLD) zone files (DNS);
 3. Dissemination of contact or other information concerning domain name registrations (Whois service);
 4. Domain Name Services Security Extensions (DNSSEC); and
 5. Rights Protection Mechanisms and Abuse Prevention & Mitigation.
 6. Data Escrow
 7. Monthly reports to ICANN
 8. Access to bulk zone files
 9. IPv6 Support
 10. Internationalized Domain Names

The registry will use the Espresso registry service platform (“Espresso”) from Minds + Machines, an extensible provisioning protocol (“EPP”) registry service already in use by the .FM ccTLD that meets the Internet Corporation for Assigned Names and Numbers (ICANN)’s new generic top-level domain (gTLD) compliance standards. Espresso receives data from registrars, writes the data to the registry database, and disseminates TLD zone files to DNS services. 

The registry has a Whois function so that contact and domain registration information may be retrieved. Whois services will be rendered by a Port 43 Whois and via a web-based Whois at http:⁄⁄whois.nic.«stringforcode». Our current Whois provisioning provides for the same level of access and usability that a restful Whois implementation might and so we have no plans to implement a restful Whois in addition to our Port 43 Whois. The registry zone servers will hold the master zone files, and will be verifiable with DNSSEC. The registry system also automates required monthly reports to ICANN, and builds escrow data files according to ICANN requirements.

The registry services to be provided are customary services as listed at http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄rsep.html.

Registry services are managed via an Extensible Provisioning Protocol (EPP) Application Programming Interface (API). The domain registrant submits an order for a domain to the registrar. The registrar then uses EPP to check the registry database to see if the domain is available. If the domain is available, the registry sends an EPP confirmation to the registrar, confirming availability. The registrar then displays the availability of the domain name to the customer. The registrant submits contact information and domain registration details such as nameservers, length of registration, and payment. The registrar then sends this information to the registry via EPP. The domain order is accepted and written to the registry database. A confirmation is sent to the registrar. Each transaction is recorded for accounting and billing purposes.

In addition, there is a web-interface API with varying levels of access privileges made available to customer service, database administrators, and Registrars.

The TLD zone files are updated regularly. The master servers pull the new zone files using Berkeley Internet Name Domain (BIND) and distribute the new domain information to querying secondary servers.

The registry will maintain a searchable Whois lookup service that meets the requirements in Specification 4, Registration Data Publication Services.

The registry system supports IDN domain names. IDN Language tables as posted at the IANA website can easily be added to the registry platform, thereby making those scripts available at the second level for domain registrations.

The DNSSEC function is RFC compliant. Registrars are provided with the ability to submit and manage DS records using EPP, or through the web interface.

The registry system has billing and reporting components. Database transactions such as read, write and deletes are logged and made available for reporting. These reports are used by the operator to monitor the health of the technical service, thereby informing business decisions, and for accounting and reporting to ICANN.

Data will be escrowed in compliance with Specification 2 of the New gTLD Registry Agreement through our contracted third party escrow provider, NCC Group.

Rights protection mechanisms and abuse prevention and mitigation will be implemented at the registry to protect intellectual property owners and the general public from abusive or illegal practices.

Each of these registry services are non-unique to .GROUP. The registry services are standard and no new services are proposed for .GROUP. The proposed registry service will not have an effect on security of the DNS. No unauthorized access to or disclosure of information or resources on the Internet will occur as a result of the implementation of the registry system. No unauthorized disclosure, alteration, insertion or destruction of the registry data will result from the implementation of the registry. The registry will have no negative effect on the stability of the Internet. All registry services are compliant with applicable relevant standards that are authoritative and published by the Internet Engineering Task Force (IETF).

-HIGH-LEVEL SRS SYSTEM DESCRIPTION-
.GROUP will operate on Minds + Machines’ Espresso registry platform. Espresso’s design is proven to be secure, reliable and robust. The registry infrastructure is specifically configured to handle the high transaction volumes found in the TLD registry business. Espresso’s Shared Registry System (SRS) is an automated production environment dedicated to managing transactions to the registry database from multiple registrars.

The SRS system fully complies with Specification 10 of the registry agreement, including all Service Level Agreements (SLAs).

The EPP interface, Whois service and DNS service are all fully RFC compliant including all RFCs listed in Specification 6 and 10: DNS RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343 and 5966; EPP RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3915 and 3735; DNSSEC RFCs 4033, 4034, 4035, 4509, 4641 and 5155; IDN RFCs 5890, 5891, 5892, 5893; IPv6: RFCs 4472 and 3912. The registry will use anycast DNS networks. Whois and DNS servers are continually updated. Past performance and reliability records, based on service to the .FM domain registry, of the registry’s technical functions enable us to confidently commit to ICANN’s SLAs.

In addition to the core registry services described in Question 23, the registry system provides a comprehensive billing and reporting solution, data escrow services and full Internationalized Domain Name (IDN) support although IDNs are not currently envisaged for .GROUP. Services will be backed by a 24⁄7 help desk and network operations center provided by Minds + Machines.

The registry system uses a distributed architecture (as described in Question 32) that achieves the goals of scalability, reliability and extensibility. The registry system offers redundancy to function even if an entire server were to suffer catastrophic failure (see Question 39). The registry uses load balancers to mitigate hardware failure and assist in scalability. The registryʹs load balancing design allows hardware upgrades without customer impact.

Registry facilities and services will be operated in a minimum of two widely separated geographic locations, providing redundancy and fault tolerance. The primary registry facility is a live facility, meaning that it will be the normal full-time registry. The secondary registry facility is both a functional and standby facility, meaning that it will be activated for primary registry services if operational problems ever arise at the primary facility. The secondary facility is continuously synchronized with the primary. In case of a failover, the secondary site will be enabled to provide registry services such as reporting, daily zone file distribution and operational testing environment (OTE). A third site is used for database backup.

More information about facilities can be found in the answer to Question 34.

The registry system includes firewalls, routers, switches and virtual private network configurations. These are further detailed in the Security section of the application (Questions 30 and 31).

The registry operates multiple database servers to provide redundancy. The primary registry facility houses two database servers: one the main database and the other the secondary. The standby registry facility will house one database server which will be constantly synchronized with the primary registry. The database servers will be replicated but are not load balanced to ensure that there is one authoritative master database.

The SRS configuration and server allocation does not reflect the excessive multitude of servers presented by legacy registries in previous TLD application rounds. Hardware, software, database platforms and architecting have evolved significantly; it is no longer necessary to use dozens of servers to perform one registry function. Because we have access to state of the art systems, we have been able to architect the SRS so that our EPP servers are both business rule engines and protocol servers--less prone to errors and offering more efficient administration.

The Espresso platform is architected for ease of administration, which entails applications other than the registry transaction functions running on the same physical hardware. Currently, registering, updating, and deleting; any and all functions occur through the extensible provisioning protocol (EPP) servers. The software application contains all logic (business and policy) and applies them accordingly. Registrations, management of domains and management of accounts all occur through one application. Administrative changes and updating of business and policy rules are all EPP requests managed through the EPP servers. The registry configuration presented for .GROUP is greatly over-provisioned for the best-case projected number of registrations. Combined, the Espresso platform is comprises conceptually different pieces: the individual functions will be split into separate servers if the registry reaches a threshold of 25% capacity.

-REPRESENTATIVE NETWORK DIAGRAM-
Please see the attached “Q 24 SRS Overview” for a graphical representation of the SRS.

-NUMBER OF SERVERS-
The number of physical or virtual servers planned for the .GROUP registry SRS function (not including the DNS function, as fully detailed in the response to Question 35) are as follows:

At the primary location:
-2 Load balancers to listen and direct traffic to EPP servers: one primary, one standby;
-2 Database servers: one primary, one standby;
-2 Application servers to listen for EPP commands from registrars, query the database, and write to the database: one primary, one high availability spare;
-2 Hidden Master server instances for disseminating zone file information: one primary, one standby;
-1 System monitoring server for monitoring the health of servers, performing deep inspection and warning of denial of service and other malicious activities, plus external third party monitoring services;
-2 Whois Server instances to answer on Port 43 for RDDS queries: one primary, one standby
-2 Firewalls: one primary, one high availability spare;
-2 Routers⁄Switches: one primary, one high availability spare;
-2 VPN instances: one primary, one high availability spare;

In addition, a server is made available as an Operational and Testing Environment (OTE).

Technical resources required to run the SRS are adequate, on hand, committed and⁄or readily available.

-DESCRIPTION OF INTERCONNECTIVITY BETWEEN SERVERS-
Each registry instance is configured on a local area network. Servers are connected via redundant multi-homed 1 Gbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is over an encrypted VPN tunnel.

-FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS-
Local servers are synchronized constantly using encrypted asynchronous replication to update the database at the secondary facility.

-SYNCHRONIZATION SCHEME (E.G., HOT STANDBY, COLD STANDBY)-
The synchronization scheme is hot standby. The backup server is kept on and ready to failover should the primary database server fail. The secondary facility is also in hot standby. It runs idle, ready to failover should the primary facility be completely disabled. The monitoring system checks the health of the primary facility: if emergency thresholds are met, the system fails-over to the secondary facility.

-SYSTEM ENVIRONMENTS AVAILABLE-
Registrars are provided with an OTE to test connectivity and EPP schema, an automated production environment (both via EPP and web-based graphical user interface (GUI)) and a demonstration system for training.

-DOMAIN NAME PROVISIONING SERVICE TYPE-
The registry system is EPP with software code development specifically targeted to meet ICANN’s new gTLD requirements. A GUI for administrative use and for registrars that have yet to integrate via EPP is available and provides all functions available via the EPP interface.

-REGISTRAR TOOLKITS AVAILABLE-
Registrar tool kits (EPP schema made available to Registrars to shorten development time and ensure accurate communications) will be made available for download from the Registry Administration site, as is standard across most TLDs. Special EPP extensions are also made available for registrar implementation.

-WHOIS SERVICE-
The Whois service is RFC 3912 compliant. The registry administrator may determine what information is displayed through the Whois server depending on additional policies established for the TLD.

-WHOIS CHECK SERVICE-
The Whois check service is RFC 3912 compliant. It accepts and returns ASCII queries. In anticipation of rapid adoption of IDNs, we also have a unicode-enabled Whois service allowing for querying and display of non-Roman characters. The Whois service also meets ICANN’s new gTLD “thick registry” requirements (where the registry collects registrant data and must provide Whois, rather than only the registrar providing Whois) and IP ranges can be black- or white-listed for specified lookup limits.

-REGISTRY PORTAL WEB APPLICATION-
The web portal is intuitive, easy to use and every registry function is accessible. For example, the Whois service is easily configured via the GUI.

-REGISTRY DATABASE-
The Registry database is fully scalable and over-provisioned to meet the requirements of our highest projected registration volumes. The registry database has 60 times the transactional capability required by registries of 1.25 million domains. When greater transaction capabilities are required, the system will be reconfigured to split out separate functions onto multiple protocol servers.

-DNS SERVICE-
We have contracted with Packet Clearing House (PCH) for DNS services. PCH complies with the RFCs as listed in Specification 6 and 10. The DNS uses BIND and is configured to respond to queries over TCP, UDP and all IANA-recognized DNS resource record types. Access to DNS servers over IPv6 is possible through enabled dual-stack IPv4⁄IPv6 connectivity. PCH utilizes anycast technology, which enables zero downtime as traffic can be redirected to alternate locations if local servers are overloaded or unavailable. PCH has provided Minds + Machines, our outsourced Registry Service Provider, with SLAs guaranteeing 100% uptime, with a twenty-year history proving 100% reliability.

-REGISTRY SUPPORT-
Critical support is available 24⁄7 with on-call technicians responding immediately upon notification. Support staff may be reached via telephone, email, or SMS.

-DISASTER RECOVERY SERVICES (BUSINESS CONTINUITY)-
Registry continuity in compliance with Specification 6 is assured through high availability and highly redundant network operations and is detailed in Question 39. In case of a physical disaster, anycast DNS and hot swapping to off-site registry mirror ensures no interruption to services. Regular off-site backups and escrow deposits ensure integrity of data. Our registry continuity plan follows ICANN’s specifications and is tested regularly (as described in the answer to Question 39). In case of business failure, we also have in place mutual registry transition agreements with an alternate registry operator to ensure an uninterrupted, smooth transition of registry operations (as described in the answer to Question 40).

-SERVICE LEVEL AGREEMENT-
We will meet or exceed the SLAs required by ICANN and outlined in Specification 10 (Registry Performance Specifications) as evidenced by our current operational record of the .FM registry. Anycast DNS, high availability, redundancy and an off-site mirror ensure that SLAs will be met.

-WILDCARD PROHIBITION-
The registry will return a “Name Error” response for any domain names which are either not registered, do not have valid NS records or the status does not allow them to be published in the DNS, as prescribed in RFCs 1034 and 4592. Wildcarding will not be implemented in the registry.

-ICANN REPORTING-
The registry system outputs and submits all required reports to ICANN, including monthly the Per-Registrar Transaction Report and Registry Functions Activity Report as defined in Specification 3.

-IDNA2008 COMPLIANT-
The registry software is IDNA2008 compliant. It accepts xn--registrations into the database. The registry allows input of non-ASCII characters into “local language” registrant fields.

-IPV6 ENABLED-
The registry supports and resolves IPv6 records in the host fields.

-DNSSEC-
DNSSEC will be implemented and TLD zones will be signed in compliance with RFCs 4033, 4034, 4035, 4509 and 5155 and their successors. Key signature storage and processing methodologies have been developed and implemented at registry level.

-SETUP OF ESCROW SERVICES-
The registry operator will provide compressed, encrypted and signed secure data file transfers (SFTP) to the outsourced escrow agent on a daily and weekly basis and will validate every file within 24 hours. All requirements detailed in Specification 2 will be met.

-SETUP OF MANAGED DNS SERVICES-
Zone files will be disseminated through DNS via BIND. DNS system performance tests will show network availability, server and load capacity, query latency, reachability and transaction capability. DNSSEC support, including the full life cycle of KSK and ZSK keys will be proven. Since the DNS system is already operational and used by more than 19 different TLDs, setting up managed DNS services is a routine task for PCH staff.

-OBTAINING IANA DELEGATION-
All requirements for delegation will be satisfied, including adherence to relevant ICP-1 instructions.

-ON-GOING MANAGED DOMAIN NAME REGISTRY SERVICES-
Day-to-day operations of the TLD once it is set up involve several aspects of DNS: technical, administrative, support, financial and policy. From a technical perspective, all hardware and software on the system will be maintained and updated regularly. Monitoring of system stability and security occurs constantly. Escrow deposits will be made on a daily basis and ICANN reports will be submitted when required. Registrar relations will be managed, including OTE, EPP and Whois support. Specialized accounting and traffic reports will be produced and shared with relevant parties required for business operation and systems maintenance. Required configuration updates or changes will be made. Consensus or temporary policy changes enacted by ICANN will be incorporated into the system.

Question 31, is a summary of responses to Questions 32-44. All staff necessary for critical registry services and vital business operations only a registry service provider can provide are listed below and described in the attachment “Q 24 Staff.” In the response to each specific question that follows, allocation of resources for each function is noted and described.

-RESOURCING PLANS-
We are outsourcing registry service provision to Minds + Machines. This response lists the personnel in their registry operation. For complete descriptions of each position, please refer to attachment “Q 24 Staff.”
CEO
CFO
CMO
CTO
VP Policy
VP Client Services
VP Corporate Development
Director Legal Affairs
Compliance Administrator
Controller
Registrar Liaison
Registrar Cust Svc Admin 1
Registrar Cust Svc Admin 2
Registrar Cust Svc Tech 1
Registrar Cust Svc Tech 2
Network Ops Manager
Network Engineer 1
Network Engineer 2
Network Engineer 3
Espresso Application Developer
Espresso Application Developer 2
Espresso Application Developer 3
Database Developer
Database Developer 2
Information Security Officer
Database Administrator
Database Administrator 2
Marketing Manager
Public Relations Associate
IT Support Specialist
Executive Assistant
Office Manager
Network Architect
Ombudsperson

-DNS: PCH-
PCH’s technical advisory board sets strategic direction, provides expertise to make specific projects possible and drives them forward. Each member has built major Internet exchanges or backbone networks and together they provide a basis of operational experience that spans more than twenty years of Internet development around the world.

PCH Staff
All PCH staff members are listed in Question 35.

-NCC (Escrow)-
NCC’s resourcing information is described in detail in our answer to Question 38.

-Secondary NOC-
The Secondary NOC (hot standby) site is managed by Tucows. NOC staff that manage the Tucows facility in Brampton, CA also monitor and manage Minds + Machines’ secondary failover NOC. Network Operations Center (NOC) indicates the co-location facility where the hardware is stored; i.e. the datacenter.

For complete information about Tucows’ staff and staffing procedures, please see attachment “Q 24 Staff.”

The registry will make use of Espresso, a proprietary fork of the CoCCA SRS, which for many years has utilized an EPP API for the Registrar interface. The Registry System’s early adoption and implementation of EPP ensures that all EPP-enabled registrars will be able to easily ʺspeakʺ to the EPP enabled registry. This standardization minimizes development efforts and ensures regularity for registry transactions. The Espresso EPP implementation adheres strictly to ICANN and IETF standards, and was written according to and is fully compliant with the EPP standards as defined in the following RFCs listed below in RFCs Governing EPP Standards:

5730: Extensible Provisioning Protocol (EPP)
5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping
5732: Extensible Provisioning Protocol (EPP) Host Mapping
5733: Extensible Provisioning Protocol (EPP) Contact Mapping
3735: Extensible Provisioning Protocol (EPP) Transport over TCP

The Espresso Registry EPP provides the four basic service elements as defined in RFC 5730: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.

The EPP tool used for the registry interface is compliant with IETF RFC standards, is extensible, scalable, fault-tolerant, configurable, secure, and fully auditable.

Espresso’s EPP templates and schemas match the relevant RFCs. The following is a snapshot of EPP schema used by registrars during a one-hour period. More than 30 top-level domains and over 250 registrars are already using CoCCA Tools, the EPP-based ccTLD system Espresso is based on. The registry system is already fully established, validated, and used daily in existing TLDs. When we launch .GROUP, contracted registrars will be provided immediate access and will be able to offer the TLD to their established customer bases as soon as they connect to the registry system. OTE is needed at all times for new registrars to test connectivity, and for old registrars to test new functions.

The Espresso Registry EPP component is EPP 1.0 and has all standard extensions. All the EPP Schemas and Templates that are utilized in Espresso are defined in the EPP RFCs listed above.

The Espresso EPP schema follow the IETF standardized EPP format. Please refer to “REQUEST, RESPONSEʺ in attachment “Q 25 EPP Sample Schemas” for an example of the REQUEST, RESPONSE.

Espresso supports the standard EPP schema including: login, logout, check, info, poll, transfer, create, delete, renew, transfer, update.

Please refer to “Live EPP Schema and Requestsʺ in attachment “Q 25 EPP Sample Schemas” examples showing live EPP schema and requests sent from registrars in the past. They are provided to fulfill the request for sample EPP schema demonstrating the ability to support EPP.

The secondary mode of interface offered to registrars is a secure web administration portal known as the graphic user interface (GUI). This web interface is accessible from any security-enabled browser connected to the Internet, allowing registrars to log into their accounts and manually manage domain portfolios on behalf of their customers. The web interface enables user-friendly registry system administration, TLD management, and registrar portfolio viewing. Registrars may register, renew, transfer, delete, and perform every domain management function. Offering a web interface allows administrative and finance, and customer service users to easily access the full functionality of the registry system. This extended functionality eases use, supports system clients, and expands market reach.

--EXTENSIONS--
In addition to the EPP operations detailed in RFCs 5730 - 5734, the Espresso Registry adds three extensions compliant with the extension framework described in RFC 5730. The additional functionality includes: a redemption grace period, an Intellectual Property verification mechanism, and the ability to provide contact proxies for display in Whois results. Please refer to “EPP Greeting Response Reportsʺ in attachment “Q 25 EPP Sample Schemas” for the EPP greeting response reports the extensions.


Espresso’s EPP extensions are made possible by the extension framework established in the EPP protocol. The framework provides for extensions at all of the protocol, object, and command-response levels, but Espresso has made extensions at only the command-response level. All of Espresso’s extensions relate to existing query or transform protocol commands. The specifics of each extension and the commands they relate to are described in the relevant extension sections that follow.

Espresso’s extensions have been made to query and transform commands and responses as categorized in RFC 5730. The set of query commands is: check, info, poll, and transfer. The set of transform commands is: create, delete, renew, transfer, and update. The specific commands from these sets that apply to each extension will be explicitly stated.

--REDEMPTION GRACE PERIOD (RGP)--
The redemption grace period extension is an extension of the EPP Domain mapping, and is a direct implementation of RFC 3915. Its purpose is to allow a grace period during which a registrar can reverse an action performed against a domain object and receive a refund for the original action. For instance, a registrar can renew a domain, then decide the renewal was a mistake and, by requesting that the domain be “restored” to its previous state, receive a refund. The refund and overall ability to restore a domain is contingent on the registrar exercising the restore request during the grace period. A domain’s state can be restored following any of the transform actions that typically incur a fee or result in a status change: registration, renewal, automated renewal, transfer, and delete. The redemption grace period extension is consistent with the registration life cycle as described in Question 27.

The RGP extension extends the domain info command’s response and the domain update command.

The domain info response extension simply tells the state that the domain is in with regard to the grace period by including the element rgpStatus. Please refer to “Extension Element from an Example Response for the info Commandʺ in attachment “Q 25 EPP Sample Schemas” for the extension element from an example response for the info command run on a domain that was recently registered.

The domain update command extension instructs the registry to restore a domain by including a restore element. The restore element can contain an optional report element. Until a report has been filed via EPP or the Registry’s web interface, the restore request will remain in a pending state and will not be completed.

An important requirement is that the update request must contain an empty domain:chg, domain:rem, or domain:add element within the standard domain:update element.

Please refer to “Domain Update Command (Report Not Included)ʺ in attachment “Q 25 EPP Sample Schemas” for an example domain update command that requests a restore of the domain but does not include a report.

Please refer to “Domain Update Command (Report Included)ʺ in attachment “Q 25 EPP Sample Schemas” for an example domain update command that requests a restore of the domain and includes the report.

Please refer to “Domain Name Extension Schema for Registry Grace Period Processingʺ in attachment “Q 25 EPP Sample Schemas” for the formal syntax for the extension.

--INTELLECTUAL PROPERTY (IP) VERIFICATION--
The Espresso Registry adds an extension to support IP verification via the Trademark Clearing House (TMCH) verification.

Using TMCH verification, a client can receive automated, realtime pre-approval for a domain. This is especially helpful during the sunrise and landrush periods as the domain is registered immediately upon TMCH validation rather than going through the application process. When TMCH validation fails, the domain is given statuses pendingCreate and serverHold, thereby preventing the domain from being published to the zone files. The domain validation is then retried through the Registryʹs admin interface. A notification is sent to the administrator that a domain is pending approval. If an audit of the request proves legitimate, the domain is then published to the zone.

When a registrar includes a TMCH code in the registration request, TMCH validation is performed first against the domain, then against the registrant. If the Registry chooses to not use TMCH verification, registrars will receive an explanatory error in response to the domain:create command.

The IP verification extension extends only the domain:create command. The registrar adds the TMCH element to the extension section.

Please refer to “Example of the domain:create Extension Element with TMCH Informationʺ in attachment “Q 25 EPP Sample Schemas” for an example of the domain:create extension element with TMCH information.

Please refer to “Example of the domain:create Extension Element with Trademark Informationʺ in attachment “Q 25 EPP Sample Schemas” for an example of the domain:create extension element with trademark information.

Please refer to “Formal Syntax for the domain:create Extension with TMCH Informationʺ in attachment “Q 25 EPP Sample Schemas” for the formal syntax for the extension.

--WHOIS CONTACT PROXIES--
The proxy extension provides a framework for registrars to establish a full set of information to be provided in Whois responses while maintaining domain contacts’ privacy and still supplying the registry with the required contact related information. The registrar is able to create a contact proxy with similar data elements to those supplied when creating a typical contact. Once created, a proxy can be assigned to any contact controlled by the registrar. For contacts that have been assigned a proxy, Whois responses display the information from the proxy rather than the information for the actual contact.

The contact:create command and contact:create response were extended to facilitate contact proxies via EPP. A registrar may add an extension element that contains the structure to either create a new proxy or assign an existing proxy to the contact. The response to the contact:create command will contain the reference value for the proxy.

All proxies are identified by a reference. The reference can be provided during creation or is otherwise assigned by the Registry. When a proxy already exists, a registrar provides the existingProxy element which contains a reference element. The proxy identified by this reference will be assigned to the contact that is created as a result of the contact:create command.

Creating and updating a proxy is done by providing the newProxy element rather than the existingProxy element. The newProxy element contains a proxyDetails element as a container for the information necessary to create a proxy. The proxyDetails optionally contains a proxy:reference element. If the proxy:reference element matches an existing proxy, the existing proxy will be updated with the proxy details provided, otherwise a new proxy is created. When the proxy:reference element is not included, a reference value is assigned by the Registry.

The EPP aspect of the contact proxies is limited in scope. Only the contact:create command and contact:create command response were extended for contact proxies. The functional gaps in the EPP extension are adequately covered by Espresso’s GUI, described above. From the GUI a registrar can assign a proxy to an existing contact, unassign a proxy from a contact, create, update, and delete a proxy.

Please refer to “Example of the Extension Element Creating a New Contact Proxyʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension element when creating a new contact proxy.

Please refer to “Example of the Extension Element Assigning an Existing Contact Proxy to a Contactʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension element when assigning an existing contact proxy to a contact.

Please refer to “Example of the Extension Section in a Response to a contact:create Command that Assigned a Proxy to a Contactʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension section in a response to a contact:create command that assigned a proxy to a contact.

Please refer to “Formal Syntax for the Contact Proxy Extensionʺ in attachment “Q 25 EPP Sample Schemas” for formal syntax for the contact proxy extension.

--EPP PERSONNEL RESOURCES--
The number and type of personnel from Minds + Machines, our registry service provider, allocated to the implementation and maintenance of the EPP interface will vary depending on the stage of registry operations. Since the core registry system is already built, operational, and interfaces daily with registrars, the initial number of personnel allocated to EPP development will be limited to the man-hours required to create and fulfill any outstanding requirements, such as connecting to the Trademark Clearinghouse. Most ICANN-accredited registrars have already passed the OTE and are actively interfacing with Espresso on a daily basis for a TLD that is currently in operation. The Espresso Application Developers will actively keep the EPP extensions and connections up to date with relevant RFCs. The number of developers will scale accordingly as new requirements or functions are introduced, and new registrars that require assistance contract with the registry and require assistance passing the OTE.

The developers will collaborate with the Database Developers and Database Administrators to keep the EPP schema and Espresso platform up to date and in compliance with the relevant RFCs (as detailed in the introduction to Question 25: EPP). The Registrar Technical Customer Service personnel will assist the Registrars during their implementation and operation of the Espresso EPP schema. The Information Security Officer will ensure that all security policies and procedures are followed during the development, implementation, and daily use of the Espresso EPP functionality.

The technical resources required to manage the EPP are adequate, on hand or committed, and⁄or readily available. We have contracted with Cybercoders of Los Angeles for staff resources. Their analysis of the industry indicates that resourcing for the technical functions of the registry will be fully possible in years 1, 2, or 3 of operations.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 5% 5% 5% 5%
Developer 1 30% 30% 30% 30%
Developer 2 -- -- 30% 30%
Developer 3 -- -- -- 30%
Database Dev 1 5% 5% 5% 5%
Database Dev 2 -- -- -- 5%
Database Admin 1 -- 5% 5% 5%
Database Admin 2 -- -- -- 5%
Cust Serv Tech 1 3% 3% 3% 3%
Cust Serv Tech 2 -- -- 3% 3%
ISO 1% 1% 1% 1%

26.1 --A HIGH-LEVEL WHOIS SYSTEM DESCRIPTION--
The registry will operate a Whois service on Port 43 according to Specification 4 and in accordance with RFC 3912. The registry will also provide a free public query-based directory service on the web at http:⁄⁄whois.nic.«stringforcode». The Whois directory will display domain name, registrar, and nameserver data. The fields will be formatted to conform to the mappings specified in EPP RFCs 5730, 5731, 5732, 5733 and 5734.

The Whois directory will support standard and Boolean searches (including AND, OR and NOT logical operators). Search results will include domain names matching the search criteria. We will implement appropriate measures to avoid abuse of the feature and ensure that the feature is in compliance with any applicable privacy laws or policies.

We will offer searchability on the web-based Directory Service. We will offer partial match capabilities on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s full postal address. We will offer exact match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address for in-zone hosts (glue records).

The user will choose one or more search criteria, combine them by Boolean operators (AND, OR, NOT) and provide partial or exact match regular expressions for each of the criterion name-value pairs. The domain names matching the search criteria will be returned to the user.

Mitigation against abuse is achieved via black⁄white listing of IP addresses of known parties. We also configure a maximum hit threshold per IP range. The threshold applies to hits within a certain time, both from a single IP and a network.

Our Whois service meets Specifications 4 and 10 of the new gTLD Registry Agreement:
- Whois service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at whois.nic.«stringforcode» providing free public query-based access.
- The format of responses follows a semi-free text format, followed by a blankline and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
- Each data object is be represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
- For fields where more than one value exists, multiple key⁄value pairs with the same key shall be allowed (for example to list multiple name servers). The first key⁄value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
- RDDS availability SLA 
- RDDS update time SLA 
- RDDS query RTT SLA

Whois output meets the requirements listed in Specification 4 (Registration Data Publication Services). Additionally, each field can be toggled on or off for display on a per-zone basis to ensure compliance with any applicable privacy laws or policies. In other words, the Whois can be configured to accommodate more stringent privacy policies than the full disclosure that is possible. We will comply with Specification 4 such that the data objects listed will be displayed for public Whois records as follows:

 Domain Name Data Objects:
 Domain Name
 Domain ID
 Whois Server
 Referral URL
 Updated Date
 Creation Date
 Expiration Date
 Sponsoring Registrar
 Sponsoring Registrar IANA ID
 Status
 DNSSEC
 Registrant Data Objects:
 Registrant ID
 Registrant Name
 Registrant Organization
 Registrant Street1
 Registrant City
 Registrant State⁄Province
 Registrant Postal Code
 Registrant Country
 Registrant Phone
 Registrant Phone Ext
 Registrant Fax
 Registrant Fax Ext
 Registrant Email
 Admin Contact Data Objects:
 Admin ID
 Admin Name
 Admin Organization
 Admin Street1
 Admin City
 Admin State⁄Province
 Admin Postal Code
 Admin Country
 Admin Phone
 Admin Phone Ext
 Admin Fax
 Admin Fax Ext
 Admin Email
 Tech Contact Data Object:
 Tech ID
 Tech Name
 Tech Organization
 Tech Street
 Tech City
 Tech State⁄Province
 Tech Postal Code
 Tech Country
 Tech Phone
 Tech Phone Ext
 Tech Fax
 Tech Fax Ext
 Tech Email
 Registrar Data Objects:
 Registrar Name
 Address fields
 Phone Number
 Fax Number
 Whois Server
 Referral URL
 Admin Contact
 Phone Number
 Fax Number
 Email
 Technical Contact
 Phone Number
 Fax Number
 Email
 Last update of Whois database
 Nameserver Data Objects:
 Server Name
 IP Addresses
 Registrar
 Whois Server
 Referral URL
 Last update of Whois database

In addition to the RFC-compliant functions, the system allows character sets that are not ASCII as additional Whois display fields (Local Language contact details).

The registry system will implement abuse-prevention measures, such as white-listing contracted registrars’ IP address ranges for search, black-listing known bad-actors or previous violators, and capping the number of Whois searches possible during a time frame.

The registry administration will comply with applicable laws and policies regarding privacy (see Question 28: Abuse Prevention and Mitigation). The registry, in conjunction with the Vice President for Policy of Minds + Machines, will balance the ICANN Whois data display requirements with local laws, and will ensure compliance by users through enforcement of registration policies.

Third party access to zone files will be provided according to the requirements detailed in Section 2 of Specification 4. The zone files will match the file format standard, and use of data by users will only be permitted for lawful purposes. Bulk access to the zone files will be provided to ICANN and Emergency Operators as specified.

Thin registration data (domain name, registrar, Whois server, referral URL, nameservers, status, update date, creation date and expiration date) access will be granted to ICANN periodically, and thick registration data will be made available in case of a registrar failure.

The registry Whois service complies with RFC 3912 by listening on TCP port 43 for requests from Whois clients. Anyone with Internet access can use the Whois portal to check the registration data for a domain name. The Whois server replies with text content, and terminates in ASCII. As soon as the output is finished the Whois server closes the connection to the client.
--RESOURCE ALLOCATION--
The registry system, Espresso, is already in operation and regularly supports Whois requests for current TLDs. The Minds + Machines software development team will update the registry system code to meet IETF Whois RFC specifications as necessary. Since the Whois function is already built and operational, the software development team allocates personnel resources as needed when changes are required.

26.2 Relevant network diagram: Please see the attached diagram, “Q 26 Whois,” which shows the interrelationships of the Whois with the internal and external registry components.

26.3 --IT AND INFRASTRUCTURE RESOURCES--
The technical resources required to run Whois are adequate, on hand, committed, and readily available. The registry will operate two instances of Whois at the primary registry location, one primary and one hot standby backup; and another two Whois servers at the secondary location.

In the event of failure of one hardware component at the primary registry location, the backup server will handle all transactions until the failed server becomes available again. For further details about failover of Whois, see Question 39: Registry Continuity and Question 41: Failover. Any fail-over of the application or Whois service will not affect registrar transactions as fail-over testing has proven only seconds of downtime.

26.4 --INTERCONNECTIVITY WITH OTHER REGISTRY SYSTEMS--
Connectivity between the Internet, the Primary Site, and the Secondary Remote Site is via multiple redundant connections, as further described in Question 32: Architecture. In addition, connections between servers on the internal Registry Network are via redundant multi-homed 1 Gbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is via redundant SSH connections. In addition, a third data backup in a remote location is connected for disaster recovery.

High capacity routers and switches are used to route traffic to registry services (see response to Question 32: Architecture). Load balancing is used to distribute load across resources.

Internet connectivity will be supplied via a 100Mbps solution with fully diverse connections to multiple Internet service providers. Further details can be found in Question 32: Architecture and Question 35: DNS. The Registry Internet connections at both the Primary and Secondary Sites will be provisioned to support burstable 1 Gbps capacity.

When an update, for example, to a domain registrant record is made to the registry database, Whois automatically reflects these changes because it is an element of the overall SRS. There is never inaccuracy of the published data because of this configuration.

26.5 --DATACENTER CONNECTIVITY--
Our primary datacenter is at a co-location facility hosted by IX2, in Los Angeles, US. At the core of all IX2 connectivity, IX2 owns and maintains redundant 432+ strand Corning single-mode dark fiber. The redundant fiber traverses diverse paths to and from multiple IX2 datacenters including IX2ʹs space in One Wilshire Buildingʹs ʺMeet-Me-Roomʺ and adjacent buildings occupied by IX2. IX2 also has direct dark-fiber to multiple Tier 1 carriers (Level3, Cogent, AT&T, Verizon, etc.) as well as low-hop connectivity to hundreds of ISP backbone networks. Many Tier 1 providers also co-locate within IX2ʹs datacenters. Over IX2ʹs fiber connections, IX2 can transport many types of circuits from; TDM OC192 Sonet, to 10Gig Ethernet, down to TDM T1, to 10⁄100 FastEthernet.

Our secondary datacenter, managed by Tucows at Q9, in Brampton, CA, is directly connected to major Internet backbones and regional ISPs available in the vicinity of the Q9 datacenter. In addition, Q9 has a 1Gb Fibre connection to 151 Front (co-location facility) and a 1Gb Fibre connection to Tucows’ main office at 96 Mowat Ave. The office at 96 Mowat Ave has a 1Gb Fibre connection to 151 Front (co-location facility) creating a 3 x 1Gb triangle between the Q9 datacenter, 151 Front and 96 Mowat. At the Q9 datacenter, Tucows has a 1Gb Internet connection to Allstream. At the 151 Front, Tucows has a 1Gb Internet connection with Cogent and a 1Gb Internet connection with Level3. Tucows peers with TORIX and Rogers at 151 Front and, if needed, can aggregate up to 3Gb of Internet traffic to the Q9 datacenter via the 2 x 1Gb links to 151 Front and 96 Mowat + 1 Gb from Allstream. Tucows currently owns all its IP blocks, has its own ASN and BGP configuration and retains full control of peering and IP space. Tucows is fully autonomous and do not rely on third parties to provide or manage network peering capabilities.

Tucows maintains a dedicated, high-speed, low-latency, path-diverse network between its facilities in each geographic region. These regional networks are used to provide reliable, cost-effective connectivity based in different Tucows datacenters within the same region.

The secondary datacenter provides customers with a redundant Internet connection, a 100 per cent availability SLA and the flexibility to scale to higher bandwidth requirements.

Q9 maintains a dedicated, high-speed, low-latency path-diverse network between its facilities in each geographic region. These regional networks are used to provide reliable, cost-effective connectivity for customers with multi-site solutions based in different Q9 datacenters within the same region. Solutions range from traditional switched Ethernet to dedicated wavelengths.

26.6 --FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS--
Updates from the SRS to the Whois servers happens in real-time via an asynchronous publish⁄subscribe messaging architecture. These are updated in each slave within the required SLA of 95% ≤ 60 minutes. See Question 30: Security and Question 32: Architecture for further details.

26.7 --POTENTIAL FORMS OF ABUSE OF SEARCHABLE WHOIS, AND MITIGATION--
Because the IETF Whois protocol has no provisions for strong security, the Whois directory service is vulnerable to abuse of access control, integrity, and confidentiality. The registry system Espresso features several functions to mitigate data mining, server overload, and access abuse, as explained below.

The web interface for Whois can be configured through the Espresso Registry administrative area. CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is used on the web form to mitigate data mining. Network and IP limits are configurable to prevent overloading the Whois server with malicious or extraneous requests. Whois look-ups will be set to 100 requests every 60 minutes for unknown IP ranges. Network limits will be set to 1000 request every 1440 minutes for unknown networks. When the limits are reached, the requests will be restricted and a message will be displayed notifying the user that the limit has been reached. The message also provides instructions to the user to contact the registry if they would like to have their IP or Network range white-listed. Whois request records will be archived, in order to provide law enforcement officials with any necessary information they require for enforcement.

A blacklist is used to block IP addresses or networks of known bad actors. Similarly, a white list may be used to allow trusted users greater Whois look-up access. Terms of use will be displayed on the Whois interface, notifying all users of the terms and conditions for access to the Whois database.

The registry system logs all Whois queries. A server status field displays the number of active requests for a specified time range. The request logs can be searched by the minute, hour, day, month, year, and since delegation. These logs can be output and downloaded as comma-separated value (CSV) files and subsequently used to generate any type of report required.

The Whois server is constantly monitored to ensure 100% uptime. The monitoring tool outputs reports showing the number of queries, and response rates over variable time periods. Whois service will be in full compliance with the final specification of ICANN’s Registration Data Publication Services Document.

26.8 --RESOURCE ALLOCATION--
The SRS registry system, Espresso, is already operational and regularly supports Whois requests for the current TLD operated by Minds + Machines, .FM. The software development team will update the registry system code to meet IETF WHOIS RFC specifications as necessary. The CTO allocates personnel resources as needed to maintain the Whois infrastructure, and to update the code and hardware when changes are required. The Network Operations Managers and technical staff maintain the hardware that supports the Whois function. The Database Developers and Administrators ensure that the Whois element of the application is able to access real-time data from the registry database. The Director of Legal Affairs and the compliance administrator assures that the Whois function and data displayed complies with ICANN consensus policy, privacy policies, and applicable laws and regulations. The Registrar Customer Service technical support personnel assist registrars with Whois access, including white-listing known and trusted IP ranges.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 2% 2% 2% 2%
Director Legal Affairs 2% 2% 2% 2%
Compliance Administrator -- 5% 5% 5%
Registrar CS Tech 1 2% 2% 2% 2%
Registrar CS Tech 2 -- -- 2% 2%
Network Operations Mgr 2% 2% 2% 2%
Network Engineer 1 2% 2% 2% 2%
Network Engineer 2 -- -- 2% 2%
Network Engineer 3 -- -- -- 2%
Espresso Application Dev 10% 10% 10% 10%
Espresso Application Dev 2 -- -- 10% 10%
Espresso Application Dev 3 -- -- -- 10%
Database Developer 5% 5% 5% 5%
Database Developer 2 -- -- -- 5%
Information Security Officer 5% 5% 5% 5%
Database Administrator -- 5% 5% 5%
Database Administrator 2 -- -- -- 5%

The proposed registration life cycle for this TLD is similar to the life cycle requirements for current gTLDs. The registry adheres to all IETF EPP RFCs relevant to the domain life cycle. The proposed life cycle for the TLD is consistent with the technical, operational, and financial plans proposed for this TLD.

The following paragraphs and timeline describe the proposed life cycle of the domain as well as the criteria and procedures used to change the state.

The Registry will support the following registration states:

- Active: The registry sets this status. The domain can be modified by the registrar. The domain can be renewed. The domain will be included in the zone if the domain has been delegated to at least two nameservers.

- Registry Hold: The registry sets this status. The domain cannot be modified or deleted by the registrar. The registry must remove the Registry Hold status for the registrar to modify the domain. The domain can be renewed. The domain will not be included in the zone.

- Registrar Hold: The sponsoring registrar sets this status. The domain cannot be modified or deleted. The registrar must remove Registrar Hold status to modify the domain. The domain can be renewed. The domain will not be included in the zone.

- Suspend: The domain is suspended and no longer resolves. The domain cannot be transferred. The domain is still part of the zone file but the nameservers have been temporarily modified to ns1.suspended.«stringforcode».

- Exclude: The domain name is excluded from the zone file. It is still entered in the registry database but will not resolve nor display as “available”.

- Redemption Period: The registry sets this status when a registrar requests that the domain name be deleted from the registry and the domain has been registered for more than 5 calendar days (if the delete request is received within 5 days of initial domain registration it will instead be deleted immediately). The domain will not be included in the zone. The domain cannot be modified or purged; it can only be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. The domain will be held in this status for a maximum of 30 calendar days.

- Pending Restore: The registry sets this status after a registrar requests restoration of a domain that is in Redemption Period status. The domain will be included in the zone. Registrar requests to modify or otherwise update the domain will be rejected. The domain will be held in this status while the registry waits for the registrar to provide required restoration documentation. If the registrar fails to provide documentation to the registry within 7 calendar days to confirm the restoration request, the domain will revert to Redemption Period status. The domain status will be set to Active only if the registrar provides documentation to the registry within 7 calendar days to confirm the restoration request.

- Pending Delete: The registry sets this status after a domain has been set in Redemption Period status and the domain has not been restored by the registrar. The domain will not be included in the zone. Once in this status all registrar requests to modify or otherwise update the domain will be rejected. The domain will be purged from the registry database after being in this status for 5 calendar days.

- Suspend and pending delete: The domain has been suspended and is pending deletion.

- Exclude and pending delete: The domain has been excluded from the zone and is pending deletion.

- Inactive: The domain is not actively resolving in the .GROUP zone. This status occurs when the nameservers associated with the domain are inaccurate or not working.

- Pending Transfer: A request has been made by the registrar to transfer the domain to another registrar. It remains in pending state until the transfer has been authenticated.

- Deleted: The domain has been deleted from the database, and will be made available again for registration.

- Server Lock: The nameservers are locked by the registrar to prevent any unauthorized changes.

- Registrar Lock (also known as “Client Lock”): The sponsoring registrar sets this status. The domain cannot be modified or deleted. The registrar must remove Registrar Lock status to modify the domain. The domain can be renewed. The domain will be included in the zone.

- Registry Lock: The registry sets this status. The domain cannot be modified or deleted by the registrar. The registry must remove the Registry Lock status for the registrar to modify the domain. The domain can be renewed. The domain will be included in the zone if the domain has been delegated to at least two nameservers.

--REGISTRATION LIFE CYCLE--
The following process describes the typical registration life cycle and all intervening steps of a steady-state domain registration that may apply through the full life cycle:

- A domain name is available to be registered.

- A registration request for a one to ten year term is received at the registry, the domain is created, the domain status is “Active,” and the domain is added to the zone file. The domain may be locked.

- If the domain is renewed, the status remains “Active.”

- If the domain record is updated, the status remains “Active.”

- If the domain is transferred, the status remains “Active.”

- If the domain is deleted, the status is updated at the database as “deleted,” and the domain is removed from the zone file.

- A five-day “Add-Grace” period exists where names deleted during that Add-Grace period become available for re-registration.

- Once the domain expires, The “Auto-Renew Grace” period begins. It lasts 30 days from the date of the domain expiry. The domain may be in the zone file during this time, but the state is changed to “suspended.” The domain can be renewed and transferred during this time.

After the Auto-Renew Grace period is over, the “Redemption Grace” period begins. This is also known as the “Pending Delete-Restore” period. The domain is no longer in the zone (the website and email no longer function), but the record is still in the registry database. The Redemption Grace is a 30-day period. During this period, the registrant can “redeem” their domain name, thereby renewing it and making it active again. The domain cannot be transferred during this time.

If the domain is not redeemed within the 30 day Redemption Grace period, the “Pending Delete” period of 5 days begins. The domain is no longer in the zone and the website and email no longer function.

Finally, the domain is released from the registry database and made available for registration. The registration life cycle begins anew.

--DOMAIN TRANSFER PROCESS--
The following process describes the typical Domain Transfer process between Registrars:

- A request for the transfer of the domain is received at the registry.

- If the domain is active and not locked, and the correct authentication code is submitted, the domain is instantly transferred to the new registrar.

- If no authentication code is submitted, the domain goes into “Pending Transfer” status. The losing registrar must confirm the transfer out to the gaining registrar.

- If an incorrect authentication code is submitted, the transfer is denied.

- Once the transfer is complete the domain reverts to “Active” status.

--DOMAIN EXPIRATION--
The following process describes the typical process when a domain expires:

- When the domain has expired the status changes to “on-hold,” and the domain no longer resolves.

- During Auto-Renew Grace Period the domain may be renewed for the regular price; the domain cannot be transferred until it is renewed.

- During the Redemption Grace Period, the status is Pending-Delete-Restorable. The domain is no longer in the zone file. A redemption fee may be paid to re-gain the domain during the Redemption Grace Period.

- After the 30-day Redemption Grace Period, the domain can no longer be automatically restored; status is Pending-Delete.

- After five days at Pending-Delete status, the domain is dropped from the registry database and made available for registration once again.

27.1 --SUNRISE LIFE CYCLE--
Implementation of the Trademark Clearinghouse (TMCH) process may alter the typical registration life cycle during Sunrise. Until the TMCH process is finalized, the registry will continue to support the historical Sunrise registration life cycle as follows:

- Application received at registry, domain is created, status is Inactive.

- Application approved by auditor, domain status is Pending.

- If application is unique, domain status is updated to Active and may be locked to prevent transfer, server update, renewal or deletion.

- If application is not unique, applicant wins collision auction, domain status is updated to Active and may be locked.

- If application is not unique and applicant loses collision auction, registration application is denied and record is archived.

--LANDRUSH LIFE CYCLE--
The following process describes the typical Registration Life Cycle during Landrush:

- Application received at registry, domain is created, status is Inactive.

- If application is unique, domain status is updated to Active and may be locked.

- If application is not unique, applicant wins collision auction, domain status is updated to Active and may be locked.

- If application is not unique, applicant loses collision auction, application is denied and record is archived.

--STEADY STATE DOMAIN REGISTRATION LIFE CYCLE--
The following process describes the typical Registration Life Cycle during Steady State Domain Registration: Full Life Cycle
Domain name is available.

- A registration for a one- to ten-year term is received at the registry, the domain is created, the domain status is “Active,” and the domain is added to the zone file. The domain may be locked.

- If domain is renewed, status remains “Active.”

- If domain record is updated, status remains “Active.”

- If domain is transferred, status remains “Active.”

- If domain is deleted, status is updated at database as “deleted,” and domain is removed from the zone file.

- A five day Add-Grace Period exists where names deleted during Add-Grace become available for re-registration.

- Once the domain expires, The Auto-Renew Grace Period begins. It lasts 30 days from the domain expired date. The domain may be in the zone file during this time but the state is changed to “suspended.” The domain can be renewed and transferred during this time.

- After the Auto-Renew Grace Period is over, the Redemption Grace Period begins. This is also known as the Pending Delete-Restore period. The domain is no longer in the zone (the website and email no longer function), but the record is still in the registry database. The Redemption Grace is for 30 days. During this period, the registrant can “redeem” their domain name, renewing it and making it active again. The domain cannot be transferred during this time.

- If the domain is not redeemed, within the 30 day Redemption Grace Period, the Pending Delete period of 5 days begins. The domain is no longer in the zone and the website and email no longer function.

- Finally, the domain is released from the registry database and made available for registration. The registration life cycle begins anew.

The life cycle of a domain in steady-state (in other words, after the Sunrise and Landrush periods) is illustrated in the attachment “Q 27 Life Cycle Diagram” which captures definitions, explanations of trigger points, and transitions from state to state.

--RESOURCE ALLOCATION--
The registry platform, Espresso, has been built to meet the standard ICANN gTLD life cycle formats. Almost every domain name life cycle function is automated; EPP commands from the registrar to the registry to modify status such as pending transfer, delete, etc. require no personnel resources. The Sunrise validation will be automated with the implementation of the required Trademark Clearinghouse. The Database Administrator manages some life cycle elements such as exclusion and the manual approval of domain names that are on hold. The Compliance Administrator ensures that the Espresso Registration Life Cycle is in compliance with ICANN consensus policies, and IETF RFC requirements. The Development team ensure the life cycle process and fields are supported by the application and in the database. The Vice President for Policy intervenes when a domain name may contravene our Acceptable Use Policy or other policy. The registrar technical support staff assist the registrars with any life cycle issues.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
Compliance Administrator -- 5% 5% 5%
Registrar CS Tech 1 2% 2% 2% 2%
Registrar CS Tech 2 -- -- 2% 2%
Espresso Application Developer 5% 5% 5% 5%
Database Developer 5% 5% 5% 5%
Database Administrator -- 5% 5% 5%

28.1 --ABUSE POINT OF CONTACT--
Strong abuse prevention is an important benefit to the Internet community. .GROUP and its registry services provider, Minds + Machines, agree that a registry must not only aim for the highest standards of technical and operational competence but must also act as a steward on behalf of the Internet community in promoting the public interest. One of those public interest functions for a responsible domain name registry includes working towards the eradication of abusive domain name registrations, including, but not limited to, those resulting from:
 * illegal or fraudulent actions 
 * spam
 * phishing
 * pharming 
 * distribution of malware 
 * fast flux hosting 
 * botnets 
 * distribution of child pornography 
 * online sale or distribution of illegal pharmaceuticals

Minds + Machines provides the staff and technology to handle abuse prevention and mitigation. Roles and responsibilities refer to Minds + Machines staff. The Compliance Administrator (CA) serves as the primary Abuse Point of Contact (as required by ICANN). CA will be responsible for overall policy development and enforcement.

CA will administer the complaint resolution process, and communicate with registrars (with the assistance of the Registrar Liaison), with law enforcement, the World Intellectual Property Organization and industry organizations such as the Anti-Phishing Working Group and the Registration Abuse Policies Working Group. Minds + Machines’ Chief Technical Officer (CTO) will also serve as the secondary Abuse Point of Contact. The CA, CTO or other personnel will be reachable on a 24⁄7 basis to deal with any alleged abuses that require immediate attention, whether from law enforcement or otherwise.

On the technical side, the Chief Technology Officer (CTO) is responsible for implementing abuse prevention and mitigation software on the Espresso registry platform and the abuse information and reporting features of the website.

All of the Registry staff will be trained to (i) respond to communication concerning abuse via the published (the required abuse point-of-contact) and restricted (only available to law enforcement and the customers) contact details; (ii) perform sufficient verification to distinguish genuine claims from the malicious and from false positives; (iii) enter the details into the abuse tracking and monitoring system; (iv) identify and contact the registrar of record, inform them of the complaint, initiate a prompt investigation of the complaint and note any information received back from the registrar; and (v) report progress to the complainant at appropriate times.

Primary and secondary Abuse Points of Contact, as well as designated employees, will be supplied with pagers and smart phones, and create an “on call” roster to assure 24x7 availability of abuse prevention and mitigation resources.

The website will prominently display and provide easy access to policies, resources available for handling complaints regarding abuse, and how to contact the designated Abuse Point of Contact. The Abuse Point of Contact staff will provide timely responses to complaints.

An abuse and complaint tracking and monitoring system will be set up as part of the registry software and maintained by Minds + Machines on our behalf. No further resourcing or provisioning will be required to maintain this effective 24x7 system.

28.2 --ABUSE PREVENTATION AND MITIGATION PROGRAM--
The abuse prevention and mitigation program (the “Program”) is based on best practice policy recommendations developed by the Council of Country Code Administrators (CoCCA), on lessons learned from previous new gTLD launches, on the operating experience of TLDs such as .COM, and on participation in policy working groups and debate at ICANN. All policies are consistent with and conform to ICANN consensus policies where applicable. Twenty‐five ccTLDs use the CoCCA policy framework to ensure protection of the registry, and to minimize abusive registrations and other activities that affect the legal rights of others. We have updated the best parts of these policies to the new gTLD environment to protect the specific needs of the registry and the registrants, and the rights and needs of third parties. Wherever applicable, we follow the recommendations of NIST SP 800-83 Guide to Malware Incident Prevention and Handling.

The Program is comprised of policies, procedures and resource allocation that aim to prevent and mitigate abusive practices at all levels of registry operations and domain name use.

The Program aims to: (i) prevent the registration of names that violate policies; (ii) provide efficient procedures for the reporting and removal of names that violate policies if they are registered; (iii) provide efficient procedures for the reporting and removal of domains which engage in abusive or unlawful practices; and (iv) secure and protect domain name ownership and Whois information.

The Program is designed to provide for the transparent and non-discriminatory registration of domain names; to protect Whois data and privacy; to ensure adherence by registrars and registrants to the Acceptable Use Policy (AUP); to protect trademarks and prevent registration of blocked and reserved names; to prevent the registration of illegal terms and inappropriate names; to prevent violations of the law; to combat abuse of the DNS; to address cybercrime; to protect intellectual property, and to align use of the registry with the applicable regulatory and legislative environments. We note that while as a registry operator we cannot remove prohibited or unlawful content from the Internet, we can and will seek to ensure that the network is not part of the abuse or publication chain.

The Program is balanced between the need to prevent abusive registrations and uses, the need to properly implement ICANN policies and follow applicable laws, and the need to respect the legal rights of registrants and others. The goal is to encourage legitimate use while discouraging abusive or illegal use. We recognize the importance for the overall health and reputation of the registry that we handle abusive registrations and use quickly, fairly and impartially.

The Program will be administered to (i) ensure that registrars adhere to registration policies; (ii) enforce the policies with registrars and registrants; and (iii) prevent any violations as effectively and efficiently as possible. The means for enforcing policies and procedures will be the comprehensive contract, which sets out penalties for non-compliance; and the registry software, through which some regulations and procedures will be enforced (for instance, blocking reserved names and displaying Trademark Clearinghouse notices and warnings).

The Program employs a model that includes registry-level suspensions for AUP and other policy violations; and also provides that the use of a domain is subject at all times to the AUP’s provisions concerning cybercrime, prohibited content, intellectual property abuses and other issues of importance to the Internet, security, intellectual property, legal and law enforcement communities.

Below we describe various agreements and policies, each of which will be a part of the Program:

 (1) REGISTRANT AGREEMENT - The Registrant Agreement, which must be presented to the registrant for agreement by the registrar as a condition of registration, binds the registrant to ICANN-mandated rights protection mechanisms, including the Uniform Dispute Resolution Policy (“UDRP”), AUP, Privacy Policy, Whois Policy, and the Complaint Resolution Service. At the time of registration, registrars will be contractually required, pursuant to the Registry-Registrar Agreement, to bind registrants to these agreements.
 (2) REGISTRY-REGISTRAR AGREEMENT (RRA) - The primary mechanism for ensuring that registrars adhere to registration guidelines, meet the obligations set forth in the policies and pass them on to registrants will be through the RRA we will sign with registrars. The terms of the RRA adhere to ICANN policies and contain additional abuse safeguards. The RRA includes provisions that must also be included in the contract between registrars and registrants. Registrars may include additional provisions, but those provisions may not conflict with the language provided by us, and registrars must include the terms and conditions in their entirety, and legally bind registrants to them. It is by this mechanism that registration and use policies, regulations and procedures will be passed on to registrants. The RRA contains provisions to combat abusive registrations or use as required by ICANN policies, applicable laws, and the registryʹs Acceptable Use Policy.

 (3) ACCEPTABLE USE POLICY (AUP) - The AUP is incorporated by reference into the Registrant Agreement. It defines the acceptable use of second-level domains, and is designed to ensure that the registry is used for appropriate and legal purposes. It specifically bans, among other practices, the use of a domain name for abusive or illegal activities, including (i) illegal, fraudulent, misleading, or deceptive actions or behavior; (ii) spamming (the use of electronic messaging systems to send unsolicited bulk messages, including email spam, instant messaging spam, mobile messaging spam, the spamming of Web sites and Internet forums, and use of email in a Distributed Denial of Service (DDoS) attack); (iii) phishing (the use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data); (iv) pharming (the redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning); (v) willful distribution of malware (the dissemination of software designed to infiltrate or damage a computer system without the owner’s consent--e.g. computer viruses, worms, keyloggers and Trojan horses); (vi) fast-flux hosting (use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities); (vii) botnet command and control (services run on a domain name that are used to control a collection of compromised computers or “zombies,” or to direct DDoS attacks); (viii) distribution of obscene material, including but not limited to child pornography, bestiality, excessive violence; (ix) illegal or unauthorized access to computer networks or data (illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another party’s system, often referred to as “hacking,” or any activity that may be used as a precursor to an attempted system penetration, such as port scanning, stealth scanning, probing, surveillance or other information gathering activity); (x) deceptive or confusing uses of the domain or any content provided thereon with respect to any third party’s rights; (xi) disrupting the registry network or the provision of any content capable of disruption of computer or systems or data networks; (xii) providing circumvention technologies, technical information or other data that violates export control laws; (xiii) spoofing (forging email network headers or other identifying information); and (xiv) distribution of any other illegal or offensive material including hate speech, harassment, defamation, abusive or threatening content, or any other illegal material that violates the legal rights of others including but not limited to rights of privacy or intellectual property protections.

 (4) PRIVACY AND WHOIS POLICY - The Privacy & Whois Policy is incorporated into the terms and conditions presented to potential registrants. It is designed to prevent abuse by: (i) requiring that registrants provide us with accurate information to be included in their “thick” Whois listing; (ii) by requiring that registrars proactively require registrants to verify and⁄or modify their Whois information to ensure its accuracy on an ongoing basis as per ICANN policy; and (iii) making the failure to provide or maintain complete and accurate Whois information a material breach of the Registrant Agreement, which will allow us to cancel any registration for which the Whois information is not accurate or complete.

 (5) EXPIRED DOMAIN DELETION POLICY – As per ICANN policy, the Expired Domain Deletion Policy sets out how a domain name is registered and renewed, and includes policies and procedures for redemption and grace periods.

 (6) NAMING POLICY - The Naming Policy sets out policies governing prohibited, blocked, and reserved names and eligibility criteria for registrants. It also provides registrants with information regarding trademark and third party rights in names, and offers guidance on choosing a domain name that comports with the policies, regulatory and legal policies, and the rights of third parties. This Policy will provide registrants with the list of blocked and reserved names; explain the rights of trademark holders and the role of the Trademark Clearing House in the registration process; and explain the policies concerning “typosquatting” - misspellings, “typos” or other names that give false or misleading impressions.

A plain language version of the policies will be made available to registrars and potential registrants. Registrants will be required to give their informed consent to be bound by the policies during the registration process, but we recognize that registrants may not fully understand what they are agreeing to when they register a domain name, because the contractual language can be difficult, particularly for a non-native reader of English. As an example, registrars will present the terms and conditions to the registrants and secure their agreement prior to registration. The terms and conditions are many pages long and contain words and concepts that may not be familiar to an average Internet user. Since registrants cannot adhere to policies if they cannot understand them, we will also require registrars to provide a prominent link to a “plain-language” overview of the policies posted on the website. This link will set forth the major terms and conditions in non-legal terms in order to make them understandable to the average registrant. While contracts will be the official and legally binding agreements, we believe the plain-language overview will be very useful for conveying to registrants the major points of their obligations with regard to their domain name itself and their use of that domain name.

The policies and the plain language overview will be prominently available on the website together with explanations and links to the Uniform Rapid Suspension (URS) Service, the UDRP, and the Complaint Resolution Service, with instructions and facilities for reporting alleged abuses to us directly.

28.3 --ANTI-ABUSE MEASURES PRIOR TO REGISTRATION--
The Program will include policies and procedures designed to prevent abusive registrations and use from the start by providing users with guidelines for choosing names, informing them of the proper and improper use of those names, and the consequences of abuse. The anti-abuse measures prior to registration include:

 (1) Implementation of the Trademark Claims Service (TCS): In the case where a potential registration is an exact match to an applicable trademark in the Trademark Clearing House, the TCS automated notification service will inform registrants that the name they may be about to register may be a violation of the trademark rights of a third party, and that their registration may be subject to challenge and possible cancelation. We will not, however, reserve or block domain name registration of terms, or confusingly similar terms, which might infringe intellectual property or other rights. The Naming Policy will however advise registrants that prior to registering the name, it is the registrants’ responsibility to determine whether or not any particular term might infringe the intellectual property or other legal rights of an entity or individual. The Policy will also encourage registrants to perform a trademark search with respect to the term comprising the domain name prior to registration, and inform the registrant that it is solely liable in the event that the name constitutes an infringement or other violation of a third party’s rights, which may include criminal liability for willful, fraudulent conduct.

 (2) Prohibition of a duplicate application for registration of a domain name with another registrar: The policies prohibit a registrant from submitting an application for a domain name if the registrant has previously submitted an application for registration of a domain name for the same term with another registrar where the registrant is relying on the same eligibility criteria for both domain name applications, and the name has previously been rejected by a registrar or by the registry.

 (3) Preventing numerous attempts to register reserved or blocked names: The policies provide that registrants who repeatedly try to register reserved or blocked names, or names that infringe the rights of others, will be banned from registering domain names. Further, any domain names registered to them will be cancelled or transferred, as provided for in the Registrant Agreement and AUP. We specifically inform such users that we reserve the right to refer them to appropriate legal authorities.

 (4) Blocking⁄flagging certain names: We will be able to enforce many of the registration policies at the point of registration through the Espresso platform. For example, the Espresso platform can block certain prohibited names from registration. In addition, domain names that are doubtful--for instance names that contain within them blocked or reserved names--or portions thereof--may be flagged for further review before they are delegated. We believe that a robust implementation of registration policies through the registry software is the best first line of defense against certain types of violations. The Espresso platform is easily programmed to disallow any registrations set forth on the list of blocked or reserved names.

28.4 --POST-REGISTRATION ANTI-ABUSE MEASURES--
Even with policy implementation, oversight, and automated anti-abuse features, abuse registration and use may occur. In addition, innocuous domain names may be used for abusive purposes, such as phishing or spamming. Therefore, post-registration policies and procedures are designed to effectively and efficiently prevent and mitigate abuses with respect to registered domain names themselves and also their use.

 (1) Suspension⁄Cancellation: The policy framework allows us to suspend or cancel registrations that violate certain terms of the Registrant Agreement and related policies. We reserve the right to cancel or suspend any name that in our sole judgment is in violation of the terms of service. With cancelation, to the extent permitted by applicable law, we may publish notice of the cancelation, along with a rationale for the decision.

We believe that this step is important for several reasons: (i) It will help us keep the trust of Internet users, who will see that our actions are not arbitrary; (ii) it will act as a deterrent, as violators’ names will be published; and (iii) it will provide valuable additional information to users about which names are considered violations, by providing examples of names that have been canceled because they are offending terms.

In the case of clear-cut violations of the policies, we will take immediate action without refund of the registration fee.

 (2) Putting domain names in a “pending” status: In certain cases where we determine that a registration may be in breach of the policies, we may put a registration in “pending” status, in which the registration itself is not affected, but in which the domain name will not resolve. Names in a “pending” state can be restored to operational status. In this case, we will inform the registrant of the initial determination and provide the registrant with a speedy mechanism, such as the Complaint Resolution Service, to assist us in resolving the issue, or to appeal the decision.

 (3) Infringement of trademarks: With respect to registrations that infringe trademarks, ICANN has policies and procedures in place that provide a wide net of protections. These policies provide for very quick cancelation of obvious infringements via the Uniform Rapid Suspension (URS), and for less obvious violations, the UDRP. These policies are the result of many years’ experience and extensive negotiations with the trademark community. Additionally, these mechanisms are reasonably well understood by both trademark holders and registrants. We believe that abiding by ICANN’s established policies for dealing with alleged trademark infringing registrations provides the best level of protections for both trademark owners and applicants. We will make the URS and UDRP mandatory procedures for handling such disputes through contracts with the registrars.

A more detailed discussion of the rights protection mechanisms may be found in Question 29: Rights Protection Mechanisms.

 (4) Complaint Resolution Service (CRS): While ICANN has a number of procedures in place to prevent abusive registrations, especially with regard to violations of intellectual property rights, we will in addition implement a CRS. The CRS is a formal process that provides a low-cost, efficient, neutral, and clear-cut mechanism for complaints from the public concerning alleged illegal content, abusive or disruptive use of a domain name (e.g. phishing or spam) or other inappropriate conduct to be fairly adjudicated. The policies provide that the CRS is available to anyone, including rights holders. The CRS is a multi-step process designed to ensure fairness and is analogous to an ombudsperson process. It provides an easy method for lodging complaints while protecting registrants from arbitrary, harassing, or repetitive meritless claims. The CRS is described in detail in Question 29.

 (5) Trademark Claims Service (TCS): In addition to warning potential registrants prior to registration that their choice of domain name may infringe the rights of others, the TCS will inform trademark holders that a potential infringement of their mark has been registered. This will provide the trademark holder with the opportunity to challenge the registration, via the URS, UDRP, or court action. The TCS will provide means to inform trademark holders who have successfully deposited their trademarks in the Trademark Clearing House that a domain name has been registered that exactly matches their trademark.

28.5 --PROMOTION OF WHOIS ACCURACY--
As set forth in the Registrant Agreement, Whois Privacy Policy and related agreements we will take significant steps to collect and maintain complete and accurate Whois information.

To ensure Whois accuracy, the Registration Agreement requires that a registrant provide us with (i) true, current, complete, accurate, and reliable registration information; and requires (ii) that the registrant will maintain, update, and keep their registrant information true, current, complete, accurate, and reliable by notifying their registrar of a change to any such information in a timely manner. The Registration Agreement makes clear that providing true, current, complete, and accurate contact information is an absolute condition of registration of a domain name. Registrants are required to acknowledge that a breach of these provisions will constitute a material breach of the Registration Agreement, and that if any registration information provided during registration or subsequent modification to that information is false, inaccurate, incomplete, or misleading, or conceals or omits pertinent information, we may in our sole discretion terminate, suspend or place on hold the domain name of any Registrant without notification and without refund to the Registrant.

Whois accuracy verification at the point of registration as well as over the life of a registration will be carried out by the ICANN-accredited registrars pursuant to the terms of ICANN policy as embodied in the RRA.

Registrants are required to provide the following information to an accredited registrar, who will then provide it to us: (i) Legally recognized first and last name of the contact person for the registrant (this contact person may be the registrant itself), and if the Registrant is an organization, association, corporation, Limited Liability Company, Proprietary Limited Company, or other legally recognized entity, we require that the contact person must be a person authorized under the applicable law in the applicable territory to legally bind the entity; (ii) valid postal address of the Registrant; (iii) working e-mail address of the Registrant, and (iv) working telephone number for the Registrant, including country code, area code, and proper extension, if applicable. Attempted registrations lacking any of these fields will be automatically rejected by the system.

The Registration Agreement provides that the registrant is responsible for keeping the registrant information up to date and responding in a timely fashion to communications from registrars regarding their registered domain names.

Validation of Whois information prior to registration has not met with success among top-level domains. Historically, in many country-code top-level domains, pre-validation has been abandoned due to depressed user adoption and criticism from end users and industry businesses, such as web hosting companies, ISPs, and domain name registrars. With few exceptions, major registries validate Whois information after the domain name is delegated, if at all. This reduces cost, which keeps prices down and allows for the near-instant registration of domain names by ordinary registrants.

We will not use pre-delegation validation of registrant data. The strong policies against abusive registrations, combined with the easy-to-use CRS and active enforcement response, will better balance the needs of consumers and law enforcement or other users of Whois information than pre-verification, and in addition will result in higher customer satisfaction.

We will discourage illegitimate or abusive registrations by pricing our domain names above the price of .COM or .BIZ, which we believe will discourage various forms of noxious behaviors, as cybercriminals typically register large numbers of domains for their schemes and will therefore face a larger cost of doing business if they attempt to use the registry for their schemes. We therefore propose to price domain names at a wholesale cost higher than existing gTLDs as a way to discourage malicious use of second-level domain names. With fewer illegitimate registrations, we expect that Whois accuracy will be higher.

28.6 --ADEQUATE CONTROLS TO ENSURE PROPER ACCESS TO DOMAIN FUNCTIONS--
The RRA provides that a registrar must ensure that access to registrant accounts are adequately protected, at a minimum, by secure log-in process that requires username and password authentication, and comport with other security related ICANN registrar accreditation requirements. Registrars must ensure that its connection to the Shared Registry System (SRS) is secure and that all data exchanged between registrar’s system and the SRS is protected against unintended disclosure. Registrars are required to use multi-factor authentication and encryption methods for each EPP session with the SRS using both a server certificate identified by the Registry and the registrar password, which is disclosed only on a need to know basis.

To protect unauthorized transfers of domain names, the registry generates a Unique Domain Authentication ID, or UDAI (also known as an “authorization code” or “auth code”), and provides the UDAI only to the registrant, in a secure manner. A UDAI is a randomly generated unique identifier used to authenticate requests to transfer domain names from one registrar to another. A UDAI is generated when a domain name is registered. Registrars will be obliged to promptly support domain transfers from qualified registrants upon request and may not withhold them to prevent a domain name from being transferred, nor may they require burdensome manual steps (such as requiring a signature) as a condition of transferring a domain name to a new registrar.

Registrars will further be required to identify a duly authorized officer (or similar senior manager) to handle cases where a company or organization wants to make changes but where the original registration was performed by an individual working for the company in his or her own name. For example, a company might hire a web developer to design a web site, and ask the developer to register a domain name, which they may do, but in his or her own name. The purpose of this policy is to prevent mistakes in the case of a transfer of ownership. The instructions on the change of registrant form must ensure (i) that the current authorized registrant is authorizing the changes; (ii) that the prospective registrant is identified and that all relevant contact information has been provided; (iii) that the prospective registrant acknowledges the changes and agrees to be bound by all of agreements and policies; (iv) that the process utilized by the registrar for the change of registrant process is clearly identified to registrants; and (v) that all documentation and correspondence relating to the transfer is retained. Registrars may request a statutory declaration where they have concerns about the authority to effect the change in registrant details if the registrars have concerns about the authority to effect a change in registration or any detail thereof and include an indemnity clause for any costs, losses, or liabilities incurred in the reasonable performance of their duties in processing the registrantʹs request, or in dealing with claims arising from the allocation or use of the name.

The Minds + Machines CA will be responsible for ensuring that the ICANN-accredited registrars are implementing security protocols to provide adequate controls regarding access to registrants’ registration information. The RRA will provide that we may audit the registrant account access policies and procedures of the ICANN-accredited registrars to ensure their compliance with the policies. These audits will be carried out by the CA on a random basis or in response to a report or a complaint that a registrar is not complying with the account access policies. Failure to correct deficiencies identified in any audit may be considered a material breach of the RRA.

28.7 --ORPHAN GLUE RECORDS--
The registry policies and Shared Registration System (SRS) rules do not allow for orphan glue records in the zone. All glue records are automatically removed from the zone when the parent domain is deleted by the Espresso SRS. This automated registry software process prevents what are known as “fast-flux” phishing attacks.

28.8 --RESOURCE ALLOCATION--
The Abuse Prevention and Mitigation functions will be carried out by members of the Minds + Machines Technical and Legal staff. The CTO oversees the technical team in their development and implementation of, abuse prevention mechanisms such as black lists, removal of orphan glue records, automated warning emails, and creation and ongoing management of domain status fields such as “suspended” when a domain registration is under review for policy violation. The VP of Policy, the Director of Legal Affairs and the Compliance Administrator perform the duties of Abuse Point of Contact, complaint review, collaboration with law enforcement, and other legal duties necessary to conform to ICANN consensus policies, registry Acceptable Use Policies, and local laws.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 2% 2% 2% 2%
VP Policy 10% 10% 10% 10%
Director Legal AffairS 5% 5% 5% 5%
Compliance Administrator -- 5% 5% 5%
Registrar Cust Svc - Tech 1 2% 2% 2% 2%
Registrar Cust Svc - Tech 2 -- -- 2% 2%
Espresso Application Developer -- 2% 2% 2%
Espresso Application Developer 2 -- -- 2% 2%
Espresso Application Developer 3 -- -- -- 2%
Database Developer 2% 2% 2% 2%
Database Developer 2 -- -- -- 2%
Information Security Officer -- 5% 5% 5%
Database Administrator -- 2% 2% 2%
Database Administrator 2 -- -- -- 2%

--PROTECTION OF LEGAL RIGHTS: A CORE OBJECTIVE--
Ensuring the protection of the legal rights of others is a core objective. We believe that protecting third-party rights enhances the reputation of the registry and encourages registrants. We are therefore committed to the protection of legal rights and have developed a series of mechanisms, including but not limited to, those minimum requirements for rights protection mechanisms as detailed in Specification 7. These mechanisms are intended to prevent infringing or abusive registrations and to identify and address the abusive use of registered names on an ongoing basis and in a timely manner. As part of this commitment, we have developed and will maintain and implement a series of related policies and practices specifically designed to prevent infringing and abusive registrations and uses of domains that affect the legal rights of others. We will take reasonable steps to investigate and respond to any reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of the TLD.

--OVERVIEW--
As well as implementing all ICANN rights protection mechanisms (RPMs), we will introduce other additional RPMs that go beyond the current ICANN protections.

In order to do so, we have developed a detailed policy framework based on best practices from the ccTLD .NZ, from the Council of Country Code Administrators (CoCCA), and from existing gTLDs. This tapestry of policies provides rules and procedures regarding registrant eligibility; sets out which type of names can be registered and which cannot; defines abusive registration and usage and provides for penalties for non-compliance; describes and implements ICANN-mandated RPMs; and binds registrars and registrants to the major policies.

The major policies are the Naming Policy, which defines which names can be registered, and by whom; the Acceptable Use Policy, which describes permitted and non-permitted uses of registered names; the Whois and Privacy Policy, which helps registrants understand what we can and cannot do with their personal data; and the Complaint Resolution Services (CRS).

Registrants are bound to these four policies as a condition of registration through their contracts with their registrars, who are in turn compelled by us to get registrant consent to the policies as a condition of registration.

The Naming Policy first of all defines blocked and reserved names, which include geographical names at the second level, thereby adhering to ICANN rules and protecting the rights of governments. Secondly, it prohibits the registration of infringing names and specifically binds registrants to ICANN RPMs. It contains provisions beyond ICANN RPMs, such as prohibiting multiple attempts at blocked names, either through the same or by using different registrars. The Naming Policy further provides that we may sanction registrants who do not abide by its provisions by revoking names (with or without refund) and in appropriate cases informing law enforcement.

The Acceptable Use Policy (AUP) addresses abusive use of second-level domain names, prohibiting spam, phishing pharming, malware, illegal content and other abusive uses of second-level domain, including abusive registrations, particularly registrations that infringe the rights of third parties. Many best practices concerning infringing registrations that were developed in among ccTLD world have in the gTLD world been superseded by Consensus Policies developed at ICANN. Where ICANN has procedures and policies, we follow them. Therefore, the AUP requires that registrants abide by the terms of the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension service (URS), and the Trademark Claims Services (TCS). Another ICANN-mandated rights protection mechanisms (RPM), the Sunrise Period, will be implemented as described later in this response.

Above and beyond the ICANN-mandated RPMs, the AUP contains provisions that exceed ICANN policy minimums to provide a higher standard of protection for the legal rights of others. The AUP allows us to suspend or cancel names, or multiple names by the same registrant, if an egregious use or pattern of abusive or infringing use is engaged in by a registrant. In addition, the Complaint Resolution Service (CRS) provides means for Internet users to alert us to abusive or infringing registrations.

Additional prevention or mitigation of abusive or infringing registrations include rapid takedown procedures; cancelation or suspension of multiple domain names registered to the same flagrant abuser; higher prices to discourage mass registrants of abusive names; and protection of second-level geographic names.

We first describe the implementation of ICANN-mandated mechanisms, then follow that with a description of the additional policies we plan to implement to prevent registration abuse and rights infringement.

--SUNRISE--
The Sunrise Period is mandated by ICANN, as per Section 6.2 of Specification 10 of the registry agreement. It is a process by which owners of legal rights have the opportunity to register domain names before the process opens to the public or others. Specifically, rights holders may use the Sunrise Service to assert a priority right to register a second-level domain which matches their eligible word mark, as defined in paragraph 7.2 of Specification 10 of the registry agreement. An identical match (as defined in paragraph 6.1.5 of Specification 10 of the registry agreement) is required between the eligible word registered in the Trademark Clearing House (“TCH”) and the domain applied for as a condition of participation in the Sunrise Period. All Sunrise applications will be validated by a third-party verification agent through the ICANN-mandated TCH to check the eligibility of the legal right claimed.

We will offer the Sunrise period for a minimum of 30 days during the pre-launch phase, and according to the terms of the Sunrise Policy. Applications received within that period are treated as filed at the same time. Where there is a contest between valid claimants, allocation will be determined by auction.

The Sunrise policy will provide for a Sunrise Dispute Resolution policy, which will allow a challenge under the four grounds required in paragraph 6.2.4 of Specification 10 of the registry agreement. Other grounds may be added as experience reveals their advantages.

Policy oversight of the Sunrise Service will be provided by the Minds + Machines Vice-President of Policy, Peter Dengate Thrush. Peter is an intellectual property barrister experienced in intellectual property cases, especially involving domain names. He was involved in ICANN’s Working Group A which developed the UDRP, and with the New Zealand Working Group which developed the Dispute Resolution Process for .NZ. Operational oversight of the Sunrise Period will be provided by Minds + Machines’ CEO, Antony Van Couvering. Antony is a veteran of several Sunrise periods as the head of a registrar (NameEngine) specializing in providing services to large brands and other holders of trademarks. We will provide all necessary infrastructure and sufficient resources to support the Sunrise Period.

--TRADEMARK CLAIMS SERVICE--
We will provide a TCS during an initial launch period for eligible marks as defined in para 7.1 of Specification 10 of the registry agreement. This launch period will last at least the first 60 days of general registration, and will be operated according to the terms of Trademark Claims Policy.

The TCS allows a trademark owner to register a claim asserting trademark rights by putting potential registrants on notice of its possible legal claim of the domain name being considered for registration. We will provide notice in the approved format to all prospective registrants of domains that match trademarks in the TCH that their registration may infringe a trademark right. The mandatory form requires a prospective registrant to specifically warrant that: (i) the prospective registrant has received notification that the mark(s) is included in the TCH; (ii) the prospective registrant has received and understood the notice; and (iii) to the best of the prospective registrant’s knowledge, the registration and use of the requested domain name will not infringe on the rights that are the subject of the notice.

Additionally, the Trademark Claims Notice will provide the prospective registrant with access to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance understanding of the trademark rights being claimed by the trademark holder. These links (or other sources) will be provided in real time without cost to the prospective registrant. The Trademark Claims Notice will be provided in the language used for the rest of the interaction with the registrar or registry, and will be provided in the most appropriate UN-sponsored language as specified by the prospective registrant or registrar⁄registry.

Oversight of TCS will also rest with the Vice President of Policy (VPP). We will provide the necessary infrastructure and sufficient resources to support the VPP in this role, including adequate computers, connectivity, telephones including cell phones and administrative support.

Responsibility for implementing the customer-facing (registrar) aspects of the Trademark Sunrise Service and TCS will rest with the Registrar Liaison as part of their on-going responsibilities. Responsibility for the technical implementation of the Trademark Sunrise and TCS will rest with the Registry under the contract to provide registry services. Minds + Machines’ CTO, network engineer, and systems engineer will maintain the functionality of the automated Trademark Clearinghouse system. No additional resourcing is required to support these functions, as they are part of the base level requirements for the Registrar Liaison and the CTO. We will pay fees to the TCH for Sunrise and TCS services. At the present time no fees details are available, but we assume that the higher fees we propose to charge Sunrise applicants during the 60-day TCS period will be sufficient to cover the fees likely to be charged by the TCH.

--PHISHING AND PHARMING--
Phishing and pharming are a kind of rights infringement in which the malefactor pretends to be a trusted source by using another’s trademark, brand look-and-feel, or other protected property in order to lure Internet users to perform some action that benefits the perpetrator. These practices are prohibited by the AUP and will result in cancelation of any second-level domain name involved, and possibly in cancelation of additional names registered to the abuser.

--POST DELEGATION DISPUTE RESOLUTION POLICY--
In the Registry Agreement with ICANN, we will agree to participate in all post-delegation procedures and to be bound by the resulting determinations. Because we are fully committed to combatting abusive use and abusive registration of second-level registrations, we do not expect to have occasion to be involved in any proceedings stemming from ICANN’s Post Delegation Dispute Resolution Policy (PDDRP), which deals with registries who knowingly engage in trademark infringement or abet those who do. We will comply with all Consensus Policies adopted by ICANN, including the PDDRP.

--ADDITIONAL ANTI-ABUSE POLICES--
We will be implementing RPMs and anti-abuse measures that go beyond the UDRP, URS, Sunrise, TCS and other ICANN-mandated mechanisms and procedures. These additional measures are detailed below.

--COMPLAINT RESOLUTION SERVICE--
The Complaint Resolution Service (CRS) is an alternative to litigation for resolution of complaints between the registrant of a domain name and a complainant who alleges a registrant or a domain name is in violation of the AUP. The CRS provides a transparent, efficient, and cost effective way for the public, law enforcement agencies, regulatory bodies, and intellectual property owners to address concerns regarding abuse on the system.

The CRS provides a reliable and simple way for the public to inform us if they think there is a problem. Submissions of suspected infringement or abuse are monitored by Registrar Customer Service personnel and escalated according to severity. Upon escalation, we may take immediate action to protect registry system or the public interest or refer the matter to law enforcement if we suspect criminal activity. In the case of a non-critical complaint, the CRS also provides an amicable complaint resolution and adjudication service conducted by an Ombudsperson hired by Minds + Machines. The CRS is a service intended to supplement parties’ existing legal rights to resolve a dispute in a court of law. Any proceeding brought under the CRS will be suspended upon any pleading to a court, decision-making body, or tribunal, and only re-started if directed to do so by one of those bodies.

The Ombudsperson is a neutral third-party specialist with respect to conflict resolution who will provide informal arms-length mediation and adjudication of any complaints of alleged registrant abuses and violations of the AUP. The Ombudsperson shall have the power to direct that a domain name should be cancelled, suspended, transferred, modified or otherwise amended.

If the Ombudsperson takes a decision that a domain name registration should be cancelled, suspended, transferred, modified, or otherwise amended, the Ombudsperson will implement that decision by requesting the Registry to make the necessary changes to the Register. The CRS provides for a right of appeal by registrants if they believe the AUP has been enforced in error.
We will comply with the decisions of the Ombudsperson and the Appeal Panel under the direction of the VPP.

--PROVISIONS OF THE ACCEPTABLE USE POLICY--
The AUP defines a set of unacceptable behaviors by domain name registrants in relation to the use of their domain names. It is incorporated by reference into the Registrant Agreement. It defines the acceptable use of second-level domains, and is designed to ensure that the registry is used for appropriate and legal purposes.

The AUP specifically bans, among other practices, the use of a domain name for abusive or illegal activities, including:

 (i) illegal, fraudulent, misleading, or deceptive actions or behavior;
 (ii) spamming (the use of electronic messaging systems to send unsolicited bulk messages, including email spam, instant messaging spam, mobile messaging spam, the spamming of Web sites and Internet forums, and use of email in a Distributed Denial of Service (DDoS) attack);
 (iii) phishing (the use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data);
 (iv) pharming (the redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning);
 (v) willful distribution of malware (the dissemination of software designed to infiltrate or damage a computer system without the owner’s consent--e.g. computer viruses, worms, keyloggers and Trojan horses);
 (vi) fast-flux hosting (use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities);
 (vii) botnet command and control (services run on a domain name that are used to control a collection of compromised computers or “zombies,” or to direct DDoS attacks);
 (viii) distribution of obscene material, including but not limited to child pornography, bestiality, excessive violence;
 (ix) illegal or unauthorized access to computer networks or data (illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another party’s system, often referred to as “hacking,” or any activity that may be used as a precursor to an attempted system penetration, such as port scanning, stealth scanning, probing, surveillance or other information gathering activity);
 (x) deceptive or confusing uses of the domain or any content provided thereon with respect to any third party’s rights;
 (xi) disrupting the registry network or the provision of any content capable of disruption of computer or systems or data networks;
 (xii) providing circumvention technologies, technical information or other data that violates export control laws;
 (xiii) spoofing (forging email network headers or other identifying information); and
 (xiv) distribution of any other illegal or offensive material including hate speech, harassment, defamation, abusive or threatening content, or any other illegal material that violates the legal rights of others including but not limited to rights of privacy or intellectual property protections.

--MALWARE--
The AUP prohibits the use of the second-level domains to spread or install malware. Malware is software that is installed without the knowledge of the end user, or without the full understanding by the user of the software’s effects, which are often deleterious or dangerous. It should be noted that malware cannot be spread by the registration of a domain name. Where applicable, we will adhere to and implement the recommendations of NIST SP 800-83, “Guide to Malware Incident Prevention and Handling.” We have documented polices, processes, and procedures to mitigate operating system and application vulnerabilities that malware might exploit, as explained in further detail in our answers to Question 30: Security and Question 32: Architecture. We will implement a malware awareness program that includes guidance to users on malware incident prevention, detection and how to report suspect infections.

As recommended in NIST Special Publication 800-61, “Computer Security Incident Handling Guide,” we have instituted a robust incident response process to address malware, which has four main phases: preparation, detection and analysis, containment⁄eradication⁄recovery, and post-incident activity. In order to be prepared, we will implement malware-specific incident handling policies and procedures. As part of our detection objective, we will review malware incident data from primary sources and monitor malware advisories and alerts to identify likely impending malware incidents. We understand that we can play a critical role in the containment and eradication process of malware, and we will develop strategies and implement procedures, reflecting the appropriate level of risk, to contain and mitigate malware threats. The policies will clearly define who has the authority to make major containment decisions and under what circumstances various actions are appropriate. We reserve the right in contracts, and will not hesitate to use that right, to shut down or block services, such as email, that are used as vectors by malware producers. We also reserve the right and are prepared to place additional temporary restrictions on network connectivity to contain a malware incident, such as suspending Internet access or physically disconnecting systems from network, even while we recognize the impact such restrictions might have on organizational functions. Our strategy for the recovery phase from malware incidents is to restore the functionality and data of infected systems and to lift temporary containment measures. Our strategy for handling malware incidents in the final phase includes conducting a robust assessment of lessons learned after major malware incidents to prevent similar incidents from occurring in the future.

Additionally, we will work with the Anti-Phishing Working Group and other industry leaders, including ICANN working groups on phishing and pharming, to ensure that our practices allow parties to act quickly when a registrant is in violation of the policies. Finally, we reserve the right to immediately terminate any activity deemed, in our sole judgment, to be abusive, in violation of the AUP or related policies, or against the public interest.

--RAPID TAKE-DOWN PROCEDURES--
The AUP and related policies provide for a rapid take-down of abusive domains that are in violation of the policies, including mass domain shutdowns to act against DDoS, phishing abuse, and Botnet exploitation of domain names. Experience has shown that aggressive policy enforcement, combined with user-accessible complaint procedures to shut down obviously abusive names discourages malefactors, who have the option of registering in more loosely administered TLDs, such as .COM or .INFO.

--PROTECTION OF GEOGRAPHIC NAMES--
We will enact measures for the protection of country and territory names. The geographical names contained in the lists described in Specification 5 of the registry agreement will be added to the registry software system “prohibited word” function. Any attempt to register a domain containing those geographical names will be automatically denied, as they were similarly blocked in the .INFO TLD. See our answer to Question 22: Protection of Geographic Names for a more complete description of polices to protect geographic names.

--COMMUNITY FLAGGING--
We will use the common practice of community flagging of abusive uses of domains in order to rapidly detect a possible abuse so that a rapid response may be provided, including a rapid take-down of an abusive domain. Community members can easily flag a domain name as potentially abusive by filing notice through the Complaint Resolution Service. The CRS provides a “community flagging” mechanism that allows Internet users to report suspected violations and has proven to be an effective and speedy policy to prevent unwanted behavior. Internet web sites such as Craigslist, OK Cupid and many others use community flagging as their primary means of combating illegal and abusive behavior, and we will implement it in the registry.

--SUSPENDING MULTIPLE DOMAINS FOR FLAGRANT ABUSE--
The Registry reserves the right to suspend all domain names registered to or associated with any user for flagrant or repetitive abuse of any domain name as a means of preventing and curtailing abuse of the systems.

--TRANSFER FEES TO MITIGATE ABUSE--
To create a deterrent to abuse in the registry, we will charge registrants with a processing fee for transferring domains to another registrar or registrant. The transfer processing fee assessed will not be high, but will act as a deterrent by those who register multiple domain names for their schemes.

--QUALIFICATION OF REGISTRANTS--
We will have no general eligibility requirements for registration as pre-qualification of registrations is not applicable to our business model. Validation of Whois information prior to registration has been met with widespread user non-adoption among top-level domains historically. In country-code top-level domains such as .FR (France), .ES (Spain), .PT (Portugal), and .SE (Sweden), pre-validation has been abandoned due to depressed user adoption and criticism from end users and industry businesses, such as web hosting companies, ISPs, and domain name registrars. With few exceptions, major registries validate Whois information after the domain name is delegated, if at all. This reduces cost, which keeps prices down and allows for the near-instant registration of domain names by ordinary registrants.

We will not use pre-delegation validation of registrant data. Our strong policies against abusive registrations, combined with the easy-to-use CRS and active enforcement response, will better balance the needs of consumers and law enforcement or other users of Whois information than pre-verification, and in addition will result in higher customer satisfaction.

We will discourage illegitimate or abusive registrations by pricing our domain names above the price of .COM or .BIZ, which we believe will discourage various forms of noxious behaviors, as cybercriminals typically register large numbers of domains for their schemes and will therefore face a larger cost of doing business if they attempt to use the registry for their schemes. We therefore will price domain names at a wholesale cost higher than existing gTLDs as a way to discourage malicious use of second-level domain names. With fewer illegitimate registrations, we expect that Whois accuracy will be higher.

--IMPLEMENTATION OF POLICY--
The Vice-President of Policy will oversee the management and maintenance of all policies and coordinate their implementation with Minds + Machines’ CTO and other technical staff and any third-party service provider partners. The VP of Policy will also be responsible for assuring that the policies are complied with by both registrars and registrants. We are committed to providing sufficient resources to ensure full functioning and effective implementation of these policies, as described below.

We will implement all decisions rendered under the URS and UDRP and courts of law in an ongoing and timely manner. We have designated the Vice-President of Policy as the URS Point of Contact (URSPOC) for proceedings brought under the URS against registrations in the Registry. The URSPOC will monitor the receipt of emails from URS providers informing that a URS complaint has passed Administrative Review, and will, on receipt of such an email, immediately arrange to lock the relevant domain name. Resolution services shall not be affected. The USPOC will also monitor emails from URS providers for determinations in URS cases, and will act on them according to their terms. In those cases where the complainant has succeeded in the URS complaint, the domain name status will be moved from “locked” to “suspended”, and will not longer resolve. Where a complainant has been unsuccessful, the domain name will be unlocked, with full control being restored to the registrant. If an appeal is filed, the URSPOC will monitor emails for any change of status resulting from such appeals. The software will designate the status of names during URS proceedings and provide for monitoring to ensure deadlines are met. In order to be able to monitor emails or phone calls and respond quickly, the VPP will be aided by one or more of the Registrar Customer Service representatives.

In the event that the rate of complaints is too high for existing personnel to handle, we will work to automate what can be automated, and hire additional staff as necessary. If a high percentage of complaints are nuisance complaints, or harassing complaints, we may institute a small fee for the Complaint Resolution service in order to prevent capricious use of the service.

Responsibility for maintaining and implementing technical protection mechanisms via the Registry software and hardware rests with the CTO. The CTO will be aided by developers, architect, and technicians in the NOC.

--RIGHTS PROTECTION MECHANISMS--
The Vice-President of Policy will oversee the management and maintenance of all the policies and coordinate their implementation with Minds + Machines’ CTO and other technical staff and any third-party service provider partners. The VP of Policy, in co-ordination with the Compliance Administrator, will also be responsible for assuring that the policies are complied with by both registrars and registrants. We are committed to providing sufficient resources to ensure full functioning and effective implementation of these policies, as described below.

In the event that the rate of complaints is too high for existing personnel to handle, we will work to automate what can be automated, and hire additional staff as necessary. If a high percentage of complaints are nuisance complaints, or harassing complaints, we may institute a small fee for the Complaint Resolution service in order to prevent capricious use of the service.

Responsibility for maintaining and implementing technical protection mechanisms via the Registry software and hardware rests with Minds + Machines’ CTO, who has worked extensively with enforcing Rights Protections in registries through software applications. The CTO will direct the technical team as necessary. The technical team will implement the trademark clearinghouse and sunrise services at the application level, including connecting to the TMCH, and managing the API for sunrise auction tools.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 2% 2% 2% 2%
VP Policy 10% 10% 10% 10
Compliance Administrator -- 5% 5% 5%
Registrar CS Tech 1 2% 2% 2% 2%
Registrar CS Tech 2 -- -- 2% 2%
Espresso Application Dev -- 5% 5% 5%
Espresso Application Dev 2 -- -- 5% 5%
Espresso Application Dev 3 -- -- -- 5%
Database Developer 2% 2% 2 2%
Database Developer 2 -- -- -- 2%

SUMMARY OF SECURITY POLICY
Registry services are outsourced to Minds + Machines & their subcontracted partners, PCH (DNS, DNSSEC), NCC (data escrow) & Tucows (Secondary Failover Site). The registry is built to meet the security & stability requirements as defined in the ICANN new gTLD Applicant Guidebook. It is a secure, stable, scalable registry with high availability, dependability, & the flexibility needed to meet new gTLD requirements.

Appropriate security features will be documented & embedded within the registry services. Data confidentiality, integrity, & availability is the goal of the security policy. This response provides an explanation of how the security controls & mechanisms that will be put in place are relevant & how independent auditors will validate those controls. In the following discussion, all features mentioned in the present tense currently exist; those in the future tense will be implemented prior to operations.

Registry operations will be run in accordance with the ISO27001 framework. ISO27001 specifies a high level of requirements & best practices for managing internal company & external customer information. It incorporates periodic risk assessments appropriate to all threat scenarios. The policy covers the infrastructure, datacenters, & services including SRS⁄EPP, Whois, & DNS.

Once the registry is operational, ISO27001 certification will be pursued. We are committed to providing the highest level of data security. A formal program to maintain the certification will be established, providing the registry with a current & sustainable security policy that is able to handle emerging security threats.

A layered security model will be employed. This approach increases the cost & difficulty of penetration for an attacker. Layering creates multiple points of resistance to intruders, ensures high availability, & decreases the likelihood that attackers will pursue attacks against our organization.

The computing environment is comprised of networks, operating systems, applications, & databases. Customer data is the basic underlying component of the business that we strive to protect; therefore, we focus on providing multiple layers of resistance to unauthorized access to that data.

There will be four basic security functions that will work in a complimentary manner to secure each layer of our computing environment: examination, detection, prevention, & encryption.

Examination identifies vulnerabilities in all computing layers before they become compromised. Automated examination appliances will be employed at the network layer, operating in-line with the network, discovering all assets in the network & then identifying vulnerabilities in each asset.

Using the monitoring tools described in Q 42, each layer of the operating system is monitored, providing detailed information about each host by discovering user accounts, fingerprinting software, & OSes. Vulnerabilities will be scanned for & thus identified by using a pre-defined, regularly-updated rules set. Examination at the OS level provides more in-depth information about a host than network-level examinations, & will be deployed with the use of agents on each host.

In addition to network & OS layer examination, applications & databases are also examined, focusing on vulnerabilities of a software application or database environment.

These products, fully described in Q 32, are written for our software packages & database. Examination products focused on software packages & databases provide the most granular level of security in a layered security model.

Detection products search for pre-existing problems in a computing environment. In-line detection and intrusion prevention products will be employed at the firewall layer, allowing attack signatures to be used to detect intrusions prior to entering our network.

Information will also be kept secure by using prevention products described in the response to Q 32 & Q 42. These tools filter entry into a specific network, & include virtual private networks (VPNs), access control for router & switches, & advanced state-full firewalls using policies to evaluate network traffic.

Firewalls at the network & host layer will use network addresses, port numbers, host names, & services to evaluate whether traffic is allowed into a specific network. Network-based firewalls are the first line in guarding against intrusion. Since this is a multi-site architecture, firewalls have been implemented at the edge to increase intra-site security while protecting against intrusion from the internal network & the external Internet.

Encryption products for data security both in transmission & storage will be employed. Encryption tools modify readable text into a non-readable state prior to decryption. VPN tools, further described in Q 32 (see: Firewall Specifications) focus on creating a secured transmission medium that prevents interception & deciphering of data. Other encryption products focus on securing stored data, both in databases & applications.

Encryption tools allow for secured remote management of critical system resources; allowing establishment of a connection through a secured tunnel to firewalls, servers, & other critical systems.

Regular security audits by an accredited independent third party are commissioned to formally test & evaluate vulnerabilities & controls within the operations environment. Biannual internal security reviews are performed. The reviews emulate the evaluation performed in a security audit, but also provide detailed reviews of processes, procedures, & systems performance metrics. The documentation that results from internal reviews & external audits are securely archived, & these records can be made available for third parties with management approval.

ACCESS CONTROL
Systems supporting the registry are protected by the state-of-the-art tools described in Q 32 & Q 42, & are maintained in a secure manner. Network access is managed & logged. Access to systems, networks, peripheral devices, power, or other datacenter services is restricted. At datacenters, keycard protocols & round-the-clock interior & exterior surveillance are used to monitor access. Only authorized personnel are granted access to datacenters. No one else may enter the production area without prior clearance & an appropriate escort. Every datacenter employee undergoes background security checks before being hired. Physical access is provided only to personnel who are pre-authorized to perform maintenance. Devices requiring service or maintenance will have parts available to swap in as replacements. 

All employees will be screened prior to hire & must agree to the System Access & Usage Policy as part of their contract. Security Awareness training will be provided. A security policy acknowledgement form must be completed & signed by new employees to acknowledge acceptance. Usage-policy statements outlining usersʹ roles & responsibilities will be maintained. Acceptance of Information Security policies & procedures is required from contracted companies & individuals.

At the primary & secondary facilities, access privileges begin with HR. Once the HR team has a signed offer letter & start date, they begin the process to procure equipment, assign seating, create system accounts & grant access. The security team is required to approve all system access requests, whether a new hire or existing hire. Based on the job role, the security team has built access profiles so that all Operations & NOC staff tasked with creating accounts implement the appropriate levels of access.

External access is treated identically. If the profile calls for external access, the employee must be provided with a VPN client & encryption certificate from the Operations team that uniquely identifies the user & provides a second level of authentication. This ensures that external access authentication is two-factor & cannot be shared. External access follows the same profiling hierarchy & is simply an extension, i.e. if an internal employee does not have access to databases, they will continue to NOT have access to databases externally.

The only direct access to the network for Internet traffic is application traffic to & from pre-determined IP Addresses used in combination with recognized protocols on defined port numbers. Security at the network & protocol levels is controlled by the Internet routers & firewalls & is restricted by Access Control Lists.

Network access requires multiple layers of authentication. The system will identify who is connected & where they are, thereby assuring that users will have access to the network resources they need for their defined jobs while business systems & processes are protected from compromise.

For remote access to the system, specific points of entry for special access required by system or network administrators & the security team will be achieved by use of a VPN requiring a client profile & a private shared key, & a unique username⁄password validated against authentication databases.

System, Firewall, Network & other configurations will be updated at scheduled maintenance. The configuration changes are stored in a revision control system for review by security & network personnel, who must approve the changes prior to implementation.

PHYSICAL SECURITY
A variety of physical security systems are used to ensure that unauthorized personnel have no access to sensitive equipment or data.

All servers containing sensitive data are physically secured. Only a controlled list of people can obtain access. All internal networks are isolated from public access, & external Internet links are firewall-protected to prevent intrusion.

Physical precautions inside the server rooms include 24⁄7 video cameras to alert security personnel in case of intrusion. Alarms are fitted to all doors that access the datacenters. Trained Datacenter security staff are present at all times. Appropriate personnel will be contacted when necessary to help contain the situation as per the incident escalation procedure.

Access to the server room is controlled via two-factor authentication system. All access to the server room is logged & archived. Lost or stolen access card are immediately deactivated. Closed circuit TV is in place at all sites.

CAPACITY TO WITHSTAND ATTACKS
Operational security practices are employed to safeguard the registry infrastructure. Network & server resources are over-provisioned to ensure they can handle large attacks without performance degradation. IP transit link sizes are also over-provisioned, ensuring that capable routing & switching hardware is employed & that servers are sufficiently powerful to serve large query loads.

Hardware firewalls & Deep Packet Inspection (DPI) systems are used to ensure that only required UDP & TCP ports are exposed to the Internet. DPI systems check packet structure & DNS protocol validity on the wire to ensure that correctly-constructed DNS packets are answered by the name servers, reducing the burden on individual name servers by pre-filtering invalid traffic. Strict physical & administrative access policies are enforced.

RESOLUTION PROVISIONING AND DNS SERVICES
The anycast DNS network provided by PCH is designed to provide ample network resources to withstand extreme load situations such as DDoS attack. For overburdened Internet connections the placement of name servers in key exchange points allows DNS responses to reach the servers via an alternative provider. In the event a given site has both Internet connections overburdened, the geographical diversity & number of locations means that there will be another DNS server available.

The PCH anycast networks has more than 70 locations across the globe. The .GROUP TLD will be available at all times, & registrants will be able to count on resolution services.

Integrity between the registry & name servers in the PCH anycast cloud is ensured via TSIG-signed IXFRs or AXFRs, ensuring the DNS provider is receiving the zones from a valid source.

The PCH DDoS mitigation approach involves knowing what attack profiles to watch for, having the technology capability & capacity to identify & deflect attacks while allowing legitimate traffic to reach its destination, & possessing the skills & experience to address issues appropriately. See Q 35 for a complete description of the DDoS mitigation approach.

INCIDENT ESCALATION
Support engineers follow established standard operating procedures consistent with the ISO27001 framework. These procedures will be continually reviewed & updated. Responsibilities & escalation amongst response teams will be clearly defined. Measures to test contingency plans for short-term, medium-term, & long-term network or service outages will be employed. These periodic tests will ensure the viability of the procedures, escalation model, & accountability.

THIRD PARTY AUDITS
Regular security audits performed by an accredited third party will be commissioned. Audits involve formally testing & evaluating vulnerabilities & controls within the operations environment. Internal security reviews will also be performed. These reviews involve the evaluation performed in a security audit in addition to detailed review of processes, procedures, & systems performance metrics. The resulting detailed documentation from each internal review & external audit will be securely archived. These records & documents can be made available, with management approval, for third parties when necessary.

Information Security Certification or Assessment
The .GROUP registry will undergo annual information security assessments once it is operational. Minds + Machines undergoes annual assessments as well. Tucows, our secondary facility provider, undergoes yearly to bi-yearly IT audits. Tucows has gone through SOX audit & compliance & are PCI certified. Attached as Q 30a Security-Attestation to Compliance is the PCI certification questionnaire. While its purpose & intent are to protect the Cardholder environment, it is very exhaustive & has been extended across all systems when possible. 

NETWORK SECURITY
Multi-factor authentication, user identification, passwords & IP range checking will be required for all restricted services including but not limited to access to the Registry database, servers, zone files, & DNS services.

Secure File Transfer Protocols will be used for all file transfers between the Registry & registrars (RFC2228, RFC2577, or similar equivalent).

System maintenance will be performed via SSH, VPN or similarly secured connections.

Each system will operate a very restricted set of basic services in the relevant sections for DNS, Contact Info, FTP, SCP & WWW services. Systems are firewall-protected in hardware, & IP filtering rule sets are in place to reject inappropriate packets.

DNS servers run a limited set of applications & system services. Frequent checks take place on all DNS servers to ensure that data integrity is maintained.

IP-restricted services have each IP address specified individually. Network addresses will not to be used, as this adds the risk that a host could masquerade as a spare IP address on an internal network.

Packet sniffers, designed to check all traffic passing through a network interface, will be in place to catch suspicious traffic. These actively scan for incorrect or illegal packets, & alert the security team. They also give further indications of the source of an attack, used for profiling & preventing that attack in the future.

Network security practices will be verified by a security audit process which involves scanning all TCP & UDP ports on servers operated by the registry.

Security tests will be periodically performed on the servers & the corresponding report is reviewed on a regular basis. Tests attempt to take advantage of specific security flaws using a variety of attack methods, & the results are reported & archived. Known attacks include:

* Buffer overflow exploit
* Missing format string exploit
* Packet fragmentation attack
* Data flooding (SMURF ping, etc.)
* DNS⁄IP spoofing
* FTP spoofing
* Dictionary passwords
* Replay attack
* DDoS
* SQL injection

Tests will be updated as new vulnerabilities, security flaws, or techniques are discovered. These updates are based on industry best practices.

BACKUP SECURITY
Backups are performed through a secure network. Encryption for the backup of all sensitive data is employed. Data is sent to secure locations where it is stored, maintained & recovered for later use. Please see the response to Q 37 for a complete review of the backup security & measures taken to ensure integrity & security of the registry data.

AUDITING & REPORTING
Security reviews are run regularly. In order to maintain ISO27001 certification, there will be an annual external third party security audit performed. Security audits & reviews test all systems for configuration issues and security holes, & compliance with both internal processes & ISO27001 standards. Results of audits form the basis of security reports, which detail any recommendations for system alterations & the timeline for remediation. All security breaches will be recorded, documented, & reported to management.

ROBUST PERIODIC SECURITY MONITORING
Comprehensive monitoring ensures stability & security of critical systems & services. Industry-standard monitoring & alerting practices will be used & will ensure remediation when an impacting event is detected.

See the response to Q 42 for a complete description on security monitoring.

BACKUP
Network access control lists, network & system activities, VPN access, EPP system access logs, & any other form of logging are backed up & stored securely locally & off-site at the secondary datacenter. Access to backup information is restricted by policy. Archives are encrypted & password-protected on a limited-access server & are retained for a minimum period of one year.

SECURITY CAPABILITIES
Minds + Machines’ security capabilities are consistent with the requirements of the datacenters & with the overall business approach & planned size of the registry. The CTO & ISO will be responsible for enforcing the Registry Security Policy & ensuring that the registry technical system complies with ISO27001 standards.

COMMITMENTS MADE REGARDING SECURITY MEASURES
Security levels are appropriate for the nature of the use & level of trust associated with the .GROUP TLD. Registrants can expect a registry environment with the same or better security levels & functionality that current gTLDs provide. The Registry Policies define commitments made to registrants, specifically regarding privacy & protection of personal data.

ADEQUATE RESOURCING IN THE PLANNED COSTS
The planned costs detailed in the financial section show that our registry operations, including security, are provided by Minds + Machines in exchange for a fee. The secure datacenter, Firewall & VPN hardware, & staffing for compliance, enforcement, & further security development are all considered in the cost discussion noted in the response to Q 47.

PERSONNEL ALLOCATED
The Information Security Officer (ISO) is responsible for identifying, developing, implementing & maintaining processes across the organization to reduce risks to information & information technology. The ISO also responds to incidents, establishes appropriate standards & controls, & directs the establishment & implementation of policies & procedures. The ISO is responsible for information-related compliance & ensures security policies are kept up-to-date & followed by staff.

Each member of the technical team is tasked with ensuring the registry remains secure. They also ensure the integrity of updates between registry systems & nameservers.