ICANN New gTLD Application


Shubert Internet, Inc. is applying to ICANN for the new gTLD, .TICKETS.

As a business, we intend for .TICKETS to realize revenues, but our goal is not to maximize profits, but to build and perpetuate the live performing arts, particularly the professional theatre, and to benefit our community of venues, artists, producers and presenters of legitimate forms of arts and entertainment (collectively, sometimes referred to herein as the “Arts & Entertainment Community”),  and related service providers and their designees and agents involved in the sale and distribution of tickets (collectively, sometimes referred to herein as the “Ticketing Services Community”). 

The core commercial structure of ticketing of admission to events has evolved from one of local supply and local demand, to today’s global demand and distribution as a result of wide internet ticketing capabilities. While this broader access to event ticketing has been a boon to many suppliers and primary inventory owners, there is significant confusion in the marketplace owing to the wide dispersion of urls and businesses selling on the internet. A new .TICKETS gTLD will inject much needed transparency into this marketplace, by improving the concentration of online ticket distribution into a more uniform internet presence.

At present, no specific .TICKETS domain name, or useful top-level alternative domain name, exists for the Arts & Entertainment Community and the Ticketing Services Community, or people, organizations and businesses that want to communicate with them. Those wanting a domain name that indicates some level of association with or recognition of the  Arts & Entertainment Community and the Ticketing Services Community could seek a second level domain name such as theatretickets.com, or theatretickets.org, but such domains (or similar names) are rarely available under the limited number of existing secondary domain names, and more importantly only provide a secondary (at best) or weak (at worst) relationship between the domain name and ticketing for arts and entertainment, which we believe is the primary goal of the registrant of such names. From a competitive perspective, registrants that want a domain name that effectively and efficiently shows an association with the provision of ticketing services for the Arts & Entertainment Community, or registrants that want a domain name that allows them to identifiably communicate with people who associate or identify with the Arts & Entertainment Community and the provision of ticketing services, face a domain name marketplace that provides them with few--if any--options for their purposes. The .TICKETS top-level domain will resolve this problem by providing registrants with an efficient, effective, prominent, instantly understood means of showing their association with tickets and the provision of ticketing services for arts and entertainment, while at the same time providing competition with the existing TLDs and new gTLDs that will be approved by ICANN, thereby increasing consumer choice.

The mission of .TICKETS is to:

 - Promote arts and entertainment around the world, with a primary emphasis on the professional theatre.
 
 - Promote the sale of tickets through authorized, official channels and provide the consumer with a clear channel for information about the Arts & Entertainment and Ticketing Services Communities. 

 - Promote all things related to tickets from legitimate sources for the Arts & Entertainment Community: shows, theatres, issues, causes, interests, perspectives, positions, policies, supporters and admirers by making domain names ending in .TICKETS available to qualified parties to use such .TICKETS domain names for their legal purposes, and by having information of any and all types and for any and all legal and authorized purposes available and disseminated from websites and email addresses ending in .TICKETS for the registrants and users own authorized purposes in the United States and worldwide.

 - Provide the Arts & Entertainment Community and the Ticketing Services Community with a forum to communicate information about their forms of entertainment, ticketing information, and related services on the Internet.

 - Provide an identifiable means for people, organizations and businesses to communicate with those who associate or identify with the Arts & Entertainment Community, the Ticketing Services Community and the distribution of tickets.

 - Increase the number of people and organizations worldwide that publicly identify themselves via the Internet with all things “Tickets” through their use of .TICKETS domain names and email accounts by making such .TICKETS domain names affordable and readily available (subject to compliance with the rules governing .TICKETS discussed elsewhere in this Application). 

The purpose of the .TICKETS gTLD is to:
 
 - Provide a central market place for the Arts & Entertainment Community and the Ticketing Services Community to communicate directly with consumers and to provide greater transparency in the ticket distribution process. 

-  Provide a central market place for buying and selling tickets to arts and entertainment and related services (e.g., travel and lodging) from legitimate sources. 

 - Provide all those interested and qualified, worldwide, in selling or purchasing ticket-related goods, services, or information with a convenient and recognizable domain name that associates them and⁄or their goods, services, or information with tickets.

 - Provide a top-level domain name that provides an identifiable means of communicating with people, organizations and businesses that associate or identify with tickets.

 - Provide arts and entertainment venues and their ticketing service providers with an additional choice of available domain names at competitive prices. 

ABOUT THE APPLICANT

Shubert Internet, Inc. is a newly formed entity for the purposes of this application. It is funded by its corporate parent, The Shubert Organization, Inc. (“Shubert”). Shubert owns and operates seventeen (17) Broadway theatres and one (1) off-Broadway theatre in mid-town Manhattan. Shubert is generally regarded as the preeminent provider of legitimate theatrical entertainment on Broadway. Shubert (and its predecessors) has been in business for over one hundred years. 

Through its ticketing services division, Shubert Ticketing, Shubert provides internet and telephonic ticketing services, including through its website, telecharge.com. Telecharge is the leading provider of ticketing services to Broadway and off-Broadway events, (currently, it provides ticketing services for 27 of the 40 Broadway venues as well as to a number of off-Broadway venues) and, in addition, provides ticketing services for live entertainment events in a number of other venues across the United States.   Shubert also owns Broadway Inbound, Inc. and Plum Benefits, LLC. Broadway Inbound provides ticketing services focused on the travel industry and Plum Benefits specializes in marketing forms of live entertainment through human resources departments. 

We believe that the introduction and administration of the .TICKETS top level domain is the next logical step in Shubert’s long held position as a respected leader in the arts and entertainment and ticketing distribution fields.


There is currently a great deal of confusion among consumers as to where tickets can be purchased for legitimate forms of arts and entertainment. Our goal is for .TICKETS to serve as a central market place where the content on the associated web sites is affiliated with the Arts & Entertainment and Ticketing Services Communities and where all tickets sold on .TICKETS sites are through approved and legitimate channels. The Arts & Entertainment Community will benefit by the availability of an effective, efficient and centralized market place for communicating directly to consumers and for the buying and selling of tickets to various forms of arts and entertainment; consumers will benefit from greater transparency in the ticket distribution process, and enhanced reliability regarding the source and legitimacy of their online ticket purchases. In order to educate the consumer, .TICKETS will be marketed via social media, digital campaigns, and other media as the source for tickets to arts and entertainment; and news and information about the Arts & Entertainment Community and the Ticketing Services Community.

To protect .TICKETS’s reputation and the associational benefits it offers registrants and Internet users, we will actively promote and enforce our Acceptable Use and Abuse Prevention and Naming policies and procedures, which we believe will effectively combat improper or unlawful unprotected speech and online conduct. We believe that these mechanisms will be effective in assuring the reputation of the .TICKETS top-level domain and its registrants, and will foster greater confidence among Internet users with respect to internet services and, in particular, the provision of online ticketing services. 

The .TICKETS top-level domain will be marketed to potential registrants who want to associate themselves, their products, services, thoughts, ideas or anything else in a positive way with .TICKETS and the Arts & Entertainment Community, as well as to those who want to communicate with them in an easily identifiable way. Therefore, we believe that the great majority of potential registrants who apply for a .TICKETS domain name will do so because of its association with legitimate purveyors of arts and entertainment and related service industries or because they want to reach those who do, and not for other reasons. In these ways, the .TICKETS top-level domain will bring a special association with arts and entertainment and the Ticketing Services Community to the top-level domain name space.

We believe that the .TICKETS top-level domain will add significantly to competition and differentiation in the top-level domain space, both for registrants and Internet consumers. Registrants are presently extremely limited in their choice of domain names that allow them to efficiently and effectively associate themselves with the Arts & Entertainment Community and the distribution of tickets. The availability of useful, effective, straight-forward domain names on existing top-level domains, such as .com, .net and .org, are few and far between, or may be for sale at prices that are out of reach for most. Moreover, existing leading generic top-level domains names, such as .com, .net and .org no longer require and no longer represent any real differentiation in association, purpose or content. 

The .TICKETS gTLD will allow registrants to obtain useful, effective, straight-forward domain names rather than be forced to purchase, for example, their fifth, sixth or even later choice .com or .net name, which may well barely relate to the registrant’s purpose or use of the domain name and⁄or may be confusingly similar with numerous other .com or .net domain names. In addition, some existing generic top-level domain names, though newer, such as .xxx, would be inappropriate for most registrants for content associational reasons, while country-code top-level domains, though numerous, are not useful or appropriate for many registrants for geographical associational reasons. Registrants will benefit for a central market place that clearly, effectively and efficiently associates their domain name with ticketing services for arts and entertainment; Internet users will benefit from greater transparency and choice in a single market place dedicated to ticketing services and the Arts & Entertainment Community. Internet users will also benefit from this new market place and increase in competition, as less confusing and clearly-associated .TICKETS domain names will make it easier for them to obtain information about the Arts & Entertainment Community and how to buy tickets.  

The .TICKETS TLD will also increase competition in the top-level domain name space by assuring that .TICKETS domain names are priced at levels that are appropriate to the vast majority of potential registrants to whom .TICKETS is targeted. 

The .TICKETS TLD benefits the Arts & Entertainment Community by providing venue owners and operators, artists, producers and presenters of legitimate forms of entertainment the ability to better control the sale and distribution of their tickets.

In terms of user experience, one goal of .TICKETS is to provide users with a top-level domain name that easily allows them to recognize that the registrant seeks to have its second-level domain name (and content) associated with ticketing, the provision of ticketing services, and the Arts & Entertainment Community. We believe this will be of 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.


Another goal of .TICKETS in terms of user experience is to protect third-party rights as well as to prevent abusive uses of a .TICKETS domain name. We intend to achieve this goal by crafting our Naming Policy, Acceptable Use Policy, and other policies to be 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 complement other ICANN-mandated rights protection mechanisms such as the UDRP. 

We will provide a framework for registration of .TICKETS domains that fully support the goals, mission and purposes set forth above. Our registration framework is based on advice from our consultants, applicable laws, and a variety of other expert sources. Specifically, the planned .TICKETS framework includes these interrelated sets of agreements setting forth our policies and regulations, all of which registrants must agree to be bound by:

 1) The Registrant Agreement, which registrars contracted with .TICKETS must present to registrants. This is a collateral agreement to the Registrar Registry Agreement, and will bind registrants to .TICKETS’s Acceptable Use Policy, .TICKETS’s Privacy & Whois Policy, ICANN-mandated rights protection mechanisms (including the Universal Dispute Resolution Policy (“UDRP”)), and the Complaint Resolution Service;

 2) The Acceptable Use Policy (“AUP”), which details the proper use of domain names that end in .TICKETS, which is incorporated by reference in the Registrant Agreement that registrants must agree to;

 3) 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;

 4) The Registrar-Registry Agreement, which is the contract between .TICKETS and its ICANN-accredited registrars which sets forth, inter alia, the duties and obligations of the registrar with respect to .TICKETS registrants and the .TICKETS registry; and

 5) The Naming Policy, which sets out .TICKETS’s policies governing prohibited, blocked or reserved domain names and the qualifications for registration of a .TICKETS domain name. We intend to use eligibility criteria for the .Tickets TLD, but we are cognizant of the fact that the use of eligibility criteria could significantly reduce our applicant pool. Therefore, we plan to issue clear criteria that are not overly restrictive, but which further our mission, encourage good registrant behavior and foster consumer trust by offering greater transparency in the ticketing distribution process. 

These agreements and policies are designed to ensure transparent and non-discriminatory policies for the registration of .TICKETS 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 will promote competition among registrars, combat abuse of the DNS, address cybercrime, protect intellectual property rights, and align the .TICKETS 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 .TICKETS top-level domain, by allowing qualified registrants who want to associate themselves with the Arts & Entertainment Community and the provision of ticketing services to do so, while at the same time protecting third-party rights and preventing abuse.

With respect to protecting registrant privacy and confidential information, we will comply with applicable ICANN rules, including Whois policies, and all applicable laws, rules and regulations of appropriate jurisdictions. Registrant privacy and use of confidential information are set forth in our Privacy & Whois Policy. Information concerning updates and changes to the Privacy & Whois Policy will be promptly and prominently displayed on the .TICKETS Registry Network Information Center (www.nic.TICKETS) web site. 

.TICKETS’s back-end registry services provider will also be required to employ industry standard procedures to prevent the unauthorized or illegal access of registrant privacy or confidential information.

With respect to users, .TICKETS’s Registration Agreement will require that all registrants must comply with any and all applicable laws, rules or regulations concerning user privacy and confidential information for applicable jurisdictions, and that failure to do so may result in suspension or loss of their .TICKETS name, and may in addition result in legal actions by appropriate authorities. 

Outreach to targeted potential registrants will be important to .TICKETS achieving its projected benefits by allowing it to cost-effectively and quickly market to the most likely potential registrants, and to promote the ways in which .TICKETS will allow them to associate themselves with the Arts & Entertainment Community and the provision of ticketing services, and how their association with .TICKETS helps further their interest and that of the greater Arts & Entertainment and Ticketing Services Communities. To achieve this outreach, we intend to leverage our existing relationships with groups with an association with Shubert, our industry partners, and other arts-related and ticketing services organizations by engaging in advertising, promotion, social media outreach, and other methods of reaching potential registrants. We believe that outreach to people and organizations that already identify with the Arts & Entertainment and Ticketing Services Communities gives us the best chance of a strong launch of the top-level domain, giving us the best chance of long-term viability, and thus the best chance of fulfilling our mission and purpose.

We will keep in touch with our registrants to understand how they would like to see .TICKETS develop, and to understand how we can improve our policies, registration rules, or other aspects of our operations or administration.
.

-HIGH-LEVEL SRS SYSTEM DESCRIPTION-
.TICKETS 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 .TICKETS. 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 .TICKETS 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 .TICKETS 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 Data Center-
The Secondary data center (hot standby) site is managed by Tucows. Data center staff that manage the Tucows facility in Brampton, CA also monitor and manage Minds + Machines’ secondary failover data center.

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 .TICKETS, 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. Minds + Machines has 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.tickets. 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.tickets 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.

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.tickets.

- 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 .TICKETS 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.

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. To ensure the highest level of compliance, Shubert Internet, Inc. will outsource the technical Abuse Prevention and Mitigation functions to Minds + Machines. Minds + Machines provides the staff and technology to handle abuse prevention and mitigation. Roles and responsibilities identified in response to this question refer to Minds + Machines staff. The Compliance Administrator (CA) serves as our primary Abuse Point of Contact (as required by ICANN). The CA will be responsible for overall policy development and enforcement. 

The CA will administer the complaint resolution process, and communicate with registrars (with the assistance of our 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 our 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 www.nic.Tickets registry information 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 our 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.

Our Registry Network Information Center website (www.nic.Tickets) will prominently display and provide easy access to our policies, resources available for handling complaints regarding abuse, and how to contact our designated Abuse Point of Contact. Our 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
Our 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 our registry and our 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 our policies; (ii) provide efficient procedures for the reporting and removal of names that violate our 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 qualified applicants; to protect Whois data and privacy; to ensure adherence by registrars and registrants to our 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 our 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. Our goal is to encourage legitimate use while discouraging abusive or illegal use. We recognize the importance for the overall health and reputation of our registry that we handle abusive registrations and use quickly, fairly and impartially.

The Program will be administered to (i) ensure that registrars adhere to our registration policies; (ii) enforce the policies with our registrars and our registrants; (iii) and prevent any violations as effectively and efficiently as possible. The means for enforcing policies and procedures will be our comprehensive contract, which sets out penalties for non-compliance; and our 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 - Our Registrant Agreement, which must be presented to the registrant for agreement by the registrar as a condition of registration, binds the registrant to our AUP, Privacy & WHOIS Policy, ICANN-mandated rights protection mechanisms, including the Uniform Dispute Resolution Policy (“UDRP”), and our Complaint Resolution Service. At the time of registration, registrars will be contractually required, pursuant to our 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 our 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, but contain additional abuse safeguards. Our 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 our 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. Our RRA contains provisions to combat abusive registrations or use, as required by ICANN policies, applicable laws, and registry policy.

(3) ACCEPTABLE USE POLICY (AUP) - Our AUP is incorporated by reference into the Registrant Agreement. It defines the acceptable use of second-level domains, and is designed to ensure that our 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 - Our 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) requiring that our 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 our 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, our 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 - Our Naming Policy sets out our 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 our policies, regulatory and legal policies, and the rights of third parties. This Policy will provide registrants with our 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 our policies concerning “typosquatting” - misspellings, “typos” or other names that give false or misleading impressions.

A “plain language” version of our policies will be made available to registrars and potential registrants. Registrants will be required to give their informed consent to be bound to our 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 our 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 our policies if they cannot understand them, we will also require our registrars to provide a prominent link to a “plain-language” overview of our policies posted on the Registry Network Information Center website (www.NIC.TICKETS). 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 our contracts will be the official and legally binding agreements, we believe our 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.

Our policies and the plain language overview will be prominently available on our website together with explanations and links to the Universal Rapid Suspension (URS) Service, the UDRP, and our 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. Our 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. Our Naming Policy will however advise registrants that prior to registering the name, it is the registrant’s 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 the registrant 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: Our 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: Our policies provide that registrants who repeatedly try to register reserved or block names, or names that infringe the rights of others, will be banned from registering domain names and will have any domain names registered to them 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 our registration policies at the point of registration through the Espresso Shared Registration System (SRS) 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 our 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 our 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: Our 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 our 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 will be named publicly; 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 our 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 our 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 our 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 our decision.

(3) Infringement of trademarks: With respect to registrations that infringe trademarks, ICANN has in place policies and procedures that together 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 our 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. Our 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 our 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, our Registration Agreement requires (i) that a registrant provide us with true, current, complete, accurate, and reliable registration information; and (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.


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 our system.

Our 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.

 We are considering implementing pre-delegation validation of registrant data (Whois). We recognize, however, that 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. Therefore, we are proceeding cautiously in our consideration of adopting pre-delegation validation of registrant data and have yet to make a final decision on whether to adopt such a policy.


Regardless of whether we adopt a policy of pre-delegation validation, we believe that Mind + Machines’ strong policies against abusive registrations, combined with their easy-to-use CRS and active enforcement response, will result in higher customer satisfaction. In addition, we are developing eligibility criteria for potential registrants (see Response to Q29). Possible loss of domain use if violation of eligibility criteria occurs will discourage various forms of noxious behaviors and should improve Whois accuracy. 

28.6 ADEQUATE CONTROLS TO ENSURE PROPER ACCESS TO DOMAIN FUNCTIONS
Our 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. Each registrar 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 authenticate and encrypt each EPP session with the SRS using both a server certificate identified by the Registry and the registrar password, which is disclosed on a need to know only 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; (v) and 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 our ICANN-accredited registrars are implementing our security protocols to provide adequate controls regarding access to registrants’ registration information. Our RRA will provide that we may audit the registrant account access policies and procedures of our ICANN-accredited registrars to ensure their compliance with our 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 our 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
Our 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. Please see Question 47 for a full discussion of cost allocation. Please also see the attachment to Question 31: Technical Overview-Resource Descriptions for complete descriptions of each staff position.

Title                               
CTO                             
VP Policy                   
Director Legal Affairs       
Compliance Administrator          
Registrar Cust Svc - Tech 1         
Registrar Cust Svc - Tech 2         
Espresso Application Developer    
Espresso Application Developer 2    
Espresso Application Developer 3   
Database Developer                  
Database Developer 2            
Information Security Officer       
Database Administrator              
Database Administrator 2

29.1 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 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.

To ensure the highest level of compliance, Shubert Internet, Inc. will outsource the technical functions of Rights Protection Mechanisms to Minds + Machines. Staff roles and responsibilities identified in response to this question refer to Minds + Machines staff, except as specifically noted in subsection 29.15 “QUALIFICATION OF REGISTRANTS”.

29.2 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 our major policies.

Our major policies are our Naming Policy, which defines which names can be registered, and by whom; our Acceptable Use Policy, which describes permitted and non-permitted uses of registered names; our Whois and Privacy Policy, which helps registrants understand what we can and cannot do with their personal data; and our 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 our policies as a condition of registration.

Our 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 Naming Policy will also define the criteria used for qualifying registrants for domain registration in the .TICKETS TLD (see subsection 29.15 below entitled “QUALIFICATION OF REGISTRANTS”).

Our 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 below in subsection 29.3 SUNRISE.

Above and beyond the ICANN-mandated RPMs, our 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, our 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 our own 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 our implementation of ICANN-mandated mechanisms, then follow that with a description of the additional methods we plan to implement to prevent registration abuse and rights infringement.

29.3 SUNRISE
Our Sunrise Period is mandated by ICANN, as per Section 6.2 of the Trade Mark Clearinghouse module 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 our 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 the Trade Mark Clearinghouse module of the registry agreement. An identical match (as defined in paragraph 6.1.5 of the Trade Mark Clearinghouse module 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 our 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 and⁄or by RFP process.

Our 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 the Trade Mark Clearinghouse module 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 our 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 our Sunrise Period.

29.4 TRADEMARK CLAIMS SERVICE
We will provide a Trademark Claims Service (TCS) during an initial launch period for eligible marks as defined in paragraph 7.1 of the Trade Mark Clearinghouse module 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 the our 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 our Trademark Claims service will also rest with the Vice President of Policy. We will provide the necessary infrastructure and sufficient resources to support the Vice President of Policy 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 Trademark Claims Service will rest with the Registrar Liaison as part of their on-going responsibilities. Responsibility for the technical implementation of the Trademark Sunrise and Trademark Claims Services will rest with the Registry under our 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, which are part of the base level requirements for the Registrar Liaison and the CTO, respectively. Fees will be paid to the TCH for Sunrise and TCS services. At the present time no fees details are available, but we assume that the 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.

29.5 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 our AUP and will result in cancelation of any second-level domain name involved, and possibly in cancelation of additional names registered to the abuser.

29.6 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 combating 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.

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

29.8 COMPLAINT RESOLUTION SERVICE
Our 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. Our 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 our 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, and 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 makes 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 Vice President of Policy.

29.9 PROVISIONS OF THE ACCEPTABLE USE POLICY
Our 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.

29.10 MALWARE
The AUP prohibits the use of our 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. Our 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 our 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 our policies. Finally, we reserve the right to immediately terminate any activity it deems in our sole judgment to be abusive, in violation of our AUP or related policies, or against the public interest.

29.11 RAPID TAKE-DOWN PROCEDURES
Our 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.

29.12 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: Geographic Protection for a more complete description of polices to protect geographic names.

29.13 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 our 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 method 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 our registry.

29.14 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 our systems.

29.15 QUALIFICATION OF REGISTRANTS

Eligibility requirements for domain registration will be put in place. We (Shubert Internet, Inc.) are currently developing eligibility criteria for potential registrants and considering implementing pre-delegation validation of registrant data.

Assuming we adopt a policy of pre-delegation validation, we would manually review and validate each domain registration application.

Regardless of whether we adopt a policy of pre-delegation validation, we believe that Mind + Machines’ strong policies against abusive registrations, combined with their easy-to-use CRS and active enforcement response, will result in higher customer satisfaction. In addition, possible loss of domain use if violation of eligibility criteria occurs will discourage various forms of noxious behaviors.

29.16 IMPLEMENTATION OF POLICY
Mind + Machines’ Vice-President of Policy will oversee the management and maintenance of all our policies and coordinate their implementation with the 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 our 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 our URS complaint, the domain name status will be moved from “locked” to “suspended”, and will not 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. Our 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 Vice President of Policy 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, who has worked extensively with enforcing Rights Protections in registries through software applications. The CTO will be aided by developers, architects, and technicians in our NOC (Network Operations Center). 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.

29.17 RESOURCE ALLOCATION
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. Please see Question 47 for a full discussion of cost allocation. Please also see the attachment to Question 31: Technical Overview-Resource Descriptions for complete descriptions of each staff position.

Title
CTO
VP Policy
Compliance Administrator
Registrar CS Tech 1
Registrar CS Tech 2
Espresso Application Dev
Espresso Application Dev 2
Espresso Application Dev 3
Database Developer

SUMMARY OF SECURITY POLICY
Registry services are outsourced to Minds + Machines and their subcontracted partners, PCH (DNS, DNSSEC), NCC (data escrow) and 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 and embedded within the registry services. Data confidentiality, integrity, and availability is the goal of the security policy. This response provides an explanation of how the security controls and mechanisms that will be put in place are relevant and 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 and best practices for managing internal company and 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 and sustainable security policy that is able to handle emerging security threats.

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

The computing environment is comprised of networks, operating systems, applications, and 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, and 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, and will be deployed with the use of agents on each host.

In addition to network and OS layer examination, applications and 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 & data center 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 .TICKETS 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 .TICKETS 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 .TICKETS 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.

David E. Andrews	Director
Elliot Greene	Director
Robert E. Wankel	Chairman of the Board

David E. Andrews	Vice President
Elliot Greene	Vice President, Chief Financial Officer and Secretary
Robert E. Wankel	President

New gTLD Application Submitted to ICANN by: Shubert Internet, Inc.

String: tickets

Originally Posted: 13 June 2012

Application ID: 1-1973-48269

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.