ICANN New gTLD Application

1. GOAL OF .SHOP

1.1 SPECIALTY

* Our goal for .Shop in terms of area of specialty is to be the first choice generic TLD among new registrants seeking to communicate a direct offering to sell or purchase goods, services and⁄or merchandise online. The .Shop registry will provide registrants the opportunity for first choice of their preferred domain name on a generic global TLD.

The .shop extension is intended to provide the registrant an immediately recognized domain name that tells their potential customers the registrant’s products or services can be purchased online.

1.2 SERVICE LEVELS

Our goal for .Shop in terms of service levels is to go above and beyond the ICANN SLAs. ICANN provides for its expected SLA in Specification 10 in the Registry Agreement in the Applicant guidebook.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provides registry services for a number of TLDs including the .au ccTLD.

Our contract with ARI is attached to our response to Q46. This contract details the SLA we intend on achieving with this TLD. As can be seen in the contract we have exceeded the ICANN required SLA on every parameter.

Our response to Q34 and Q35 provides details on ARI’s distributed anycast DNS network. ARI’s DNS network provides for 16 geo distributed sites resulting in a very low resolution latency for end-users, amongst the lowest in the industry.

It is our objective to provide 100% uptime, a resilient global DNS infrastructure, and very low latency in terms of DNS resolution for this TLD

1.3 REPUTATION

Reputation of our TLD is of paramount importance to us. The reputation of our TLD directly relates to how end-users on the internet perceive our Registrants. We will ensure the highest reputation of .Shop by ensuring the following –
* Maintaining a high quality bar with respect to Registrants in the TLD
* Well defined Acceptable usage and content policies
* Well defined dispute resolution mechanisms
* Ensuring Whois accuracy to support abuse mitigation
* Well defined and implemented abuse mitigation processes
* Well defined and implemented rights protection mechanisms
* Exceptional service levels

To this effect we have created unprecedented Abuse mitigation policies and Rights protection mechanisms that go significantly above and beyond mandatory requirements and common practice described in considerable detail in our response to Q28 and Q29. We also commit to extremely high service levels that go beyond the stipulated service levels in the applicant guidebook.

2. CONTRIBUTION OF .SHOP TO THE NAMESPACE

2.1 CONTRIBUTION IN TERMS OF COMPETITION, DIFFERENTIATION, OR INNOVATION

* Per ICANN’s Bylaws as amended June 24, 2011, ICANN’s core value number six is “Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest.”

* The .Shop registry will be a new direct and formidable competitor to for the current group of global generic TLDs. This will be especially true in the key growing international markets.

* The .Shop registry’s innovation will focus on two areas, the themed meaning of our string: a “virtual global market”, and our enhanced abuse management programs.

* The .Shop registry’s differentiation will be “the virtual global market”. More than any of the other global generic gTLD registries, we will provide registrants a domain space that intrinsically implies the purpose of associated web services: business-to-consumer commerce. Additionally, by offering a new top level domain with vast second-level name availability, we will also aspire to be the first choice gTLD of an e-commerce registrant seeking to sell their products and⁄or services to consumers. .Shop will provide registrants the option to register more desirable and shorter names as opposed to names they would have otherwise registered in existing gTLDs due to the high saturation of the existing namespaces.

* Despite the prevalence of English as a language of commerce, past gTLD registries have largely focused on North America and European marketplaces. Directi will be offering the .Shop to international markets, with the goal of a truly global distribution of registrants and hence and their products and⁄or services. The .Shop virtual global market will bring international e-commerce registrants a greater opportunity to display their products on the world stage rather than being lost in the millions of websites within .com.

* Most gTLDs have largely focused on developed markets with 70+% internet penetration. Domain Name and website growth is yet to occur in other developing markets like India, Brazil, Russia, China, Indonesia etc. However as the market for websites and domain names grows in these economies the existing gTLD space in TLDs like .com, .net, .org etc will already be saturated with all tier 1 names no longer available to markets like Asia, Africa. 70% of .com check-availability checks return unavailable (data obtained fromour Internal Research). New companies have to resort to 2nd tier long multi-word names for their businesses in these markets. .Shop will broaden the namespace by providing an alternative for the business-to-customer e-commerce market in developing markets to register the domain name of their choice creating competition.

* .Shop will also allow Registrants in the e-commerce market to differentiate themselves from the 200+ million domain names out there. As of now a domain belonging to an online store appears identical to any other domain name in a .gTLD (com) or .ccTLD extension (eg .in). .Shop provides the ability for Registrants to create a differentiated identity wherein just by looking at the URL end-users will be able to recognize and identify the URL as a destination at which they can buy something or shop, and essentially realize that they are visiting a virtual store.

* Our intent is to operate .Shop with a focus on integrity and quality for the .Shop brand. This entails running robust abuse mitigation programs and pioneering Rights Protection Mechanisms from initiation, which in our case not only meets ICANN’s requirements, but extends significantly beyond it as described in our response to Q28 and Q29.

3. USER EXPERIENCE GOALS

.Shop considers both its Registrants and the end-users that access .Shop websites as its users. Our goal is to create a highly reliable namespace and provide an outstanding user experience to both Registrants and end-users of .Shop.

Registrants of .Shop have an assurance of a scalable, resilient registry with 100% uptime, low latency, and exemplary security standards. Registrants will have the option to register the domain name of their choice, without much saturation of the namespace. Our registration policies and abuse mitigation policies ensure that Registrants will get advantages like higher recognition, better branding and more desirable, shorter names.

Our content and acceptable use policies and abuse mitigation processes ensure that end-users are benefited from a clean namespace. These are described in further detail in our response to Q28 and Q29.

4. REGISTRATION POLICIES IN SUPPORT OF GOALS

4.1 GENERAL NAMES

The goals of .Shop are outlined in the sections above. These goals are supported by the following artifacts –
* Registration policies and processes
* Acceptable usage policies and content guidelines
* Abuse mitigation processes
* Rights protection mechanisms
* Dispute resolution polices

To this effect we have created unprecedented Abuse mitigation policies and Rights protection mechanisms that go significantly above and beyond mandatory requirements and common practice. The salient aspects of all of the above are described below -
* DotShop Inc. is a wholly owned subsidiary within the Directi Group. The Directi Group runs various businesses including several ICANN Accredited Domain Registrars (ResellerClub.com and BigRock.com) and Web Hosting companies. With over four million active domain names registered through its registrars, Directi has significant experience (over 10 years) of managing domain name abuse mitigation and rights protection. Directi has been heralded as a white hat registrar and the undisputed leader with respect to abuse mitigation.
* Our Abuse and compliance processes will be run by the Directi Group
* We have an elaborate and detailed Accepted usage and content policy that covers over 11 macro forms of violations
* .Shop will create a zero-tolerance reputation when it comes to abuse
* We have a defined SLA for responding to abuse complaints ensuring guaranteed turn-around time on any abuse complaint depending on its severity
* We will work closely with LEA and other security groups to mitigate abuse within the TLD by providing them with special interfaces (eg searcheable whois) and interacting with them regularly in terms of knowledge sharing.
* Other abuse mitigation steps we undertake include profiling, blacklisting, proactive quality reviews, industry collaboration and information sharing, regular sampling, contractual enforcements and sanctions
* The protection of trademark rights is a core goal of .Shop. .Shop will have a professional plan for rights protection. It will incorporate best practices of existing TLDs, going above and beyond the ICANN mandated RPMs to prevent abusive registrations and rapidly take-down abuse when it does occur.
* Standard RPMs such as Sunrise, Trademarks claims service, URS, UDRP, SDRP, PDDRP, SPOC etc are all provided for. Additional RPMs such as Optional Trademark declaration, profiling and blacklisting, proactive quality reviews, APWG Review and others will also be provided.

The above salient points barely scratch the surface in detailing the steps that .Shop will take in order to build a reputation of operating a clean, secure and trusted namespace. Significant details of all of the above and more are provided in our responses to Q26, Q27, Q28 and Q29

4.2. OTHER NAMES

* We will reserve the following classes of domain names, which will not be available to registrants via the Sunrise or subsequent periods:
** The reserved names required in Specification 5 of the new gTLD Registry Agreement.
** The geographic names required in Specification 5 of the new gTLD Registry Agreement. See our response to Question 22 (“Protection of Geographic Names”) for details.
** The registry operator will reserve its own name and variations thereof, and registry operations names (such as nic.Shop, registry.Shop, and www.Shop), so that we can point them to our Web site. Reservation of the registry operator’s names was standard in ICANN’s past gTLD contracts.
** We will also reserve names related to ICANN and Internet standards bodies (iana.Shop, ietf.Shop, w3c.Shop, etc.), for delegation of those names to the relevant organizations upon their request. Reservation of this type of names was standard in ICANN’s past gTLD contracts. The list of reserved names will be published publicly before the Sunrise period begins, so that registrars and potential registrants will know which names have been set aside.
* We will reserve generic names which will be set aside for distribution via special mechanisms.

5. PROTECTING PRIVACY OF REGISTRANTS’ OR USERS’ INFORMATION

.Shop is committed to providing a secure and trusted namespace to its Registrants and end-users. To that extent we will have several measures for protecting the privacy or confidential information of registrants or users -

* Our Whois service (web-based whois, port 43 whois and searchable whois) all have built in abuse prevention mechanisms to prevent unauthorized access, data mining, data scraping and any other abusive behavior. Details of this are provided in our response to Q26

* .Shop will allow Registrants to use privacy protection services provided by their Registrars in the form of a Proxy whois service as long as they follow the guidelines stipulated within our response to Q28 to prevent any abuse of the same

* As per the requirements of the new gTLD Registry Agreement (Article 2.17), we shall notify each of our registrars regarding the purposes for which data about any identified or identifiable natural person (“Personal Data”) submitted to the Registry Operator by such registrar is collected and used, and the intended recipients (or categories of recipients) of such Personal Data. (This data is basically the registrant and contact data required to be published in the WHOIS.)

* We will also require each registrar to obtain the consent of each registrant in the TLD for such collection and use of Personal Data. As the registry operator, we shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars.

* As the registry operator we shall take significant steps to protect Personal Data collected from registrars from loss, misuse, unauthorized disclosure, alteration, or destruction. In our responses to Q24, Q30 and Q38 we detail the security policies and procedures we will use to protect the registry system and the data contained there from unauthorized access and loss.

* As registry operator we impose certain operational standards for our registrars. In order gain and maintain accreditation for our TLD, we require them to adhere to certain information technology policies designed to help protect registrant data. These include standards for access to the registry system. Please see our response to Q24, Q25 and Q30 for details.

* We offer a “registry lock” service, designed to help protect participating registrants’ contact data from unauthorized modification, and against unauthorized domain transfers and deletions. Please see our response to Q27 for details.

* .Shop implements DNSSEC at the zone which guarantees origin authentication of DNS data, authenticated denial of existence, and data integrity. This protects end-users from a man-in-the-middle attack protecting the privacy of data of end-users.

6. OUTREACH AND COMMUNICATIONS

* Our goal for .Shop is to create a global virtual market for e-commerce registrants seeking a themed TLD to identify a business-to- consumer commerce offering, reaching shoppers around the world.

* To achieve this, we will emphasize distribution channels internationally – not just in one or more focused regions.

* Our outreach efforts will thus be directed towards our target market in coordination with Registrar partners, to ensure greater adoption of the .Shop TLD. One important method of outreach will involve co-marketing programs with registrars. We will also leverage Directi’s existing channel of 65,000 Resellers, and its strategic relationships with other ICANN Accredited Registrars.

* We will also engage in relevant PR and outreach programs as well as ensure appropriate publication of information on our website.

The communication and outreach will focus on -
* Education amongst the e-commerce market.
* Generating awareness of our Registration policies, Acceptable usage and content policies, Abuse mitigation processes and Rights protection mechanisms

This completes our answer to Q18(b).

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

1. INTRODUCTION

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

2. REGISTRY SERVICES

The following sections describe the registry services provided. Each of these services has, where required, been designed to take into account the requirements of consensus policies as documented here:
[http:⁄⁄www.icann.org⁄en⁄resources⁄Registrars⁄consensus-policies]

2.1 RECEIPT OF DATA FROM REGISTRARS

The day-to-day functions of the Registry, as perceived by Internet users, involves the receipt of data from Registrars and making the necessary changes to the SRS database. Functionality such as the creation, renewal and deletion of domains by Registrars, on behalf of Registrants, is provided by two separate systems:

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

2.1.1 EPP

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

2.1.1.1 SECURITY FOR EPP SERVICE

To avoid abuse and to mitigate potential fraudulent operations, the EPP server software uses a number of security mechanisms that restrict the source of incoming connections and prescribe the authentication and authorisation of the client. Connections are further managed by command rate limiting and are restricted to only a certain number for each Registrar, to help reduce unwanted fraudulent and other activities. Additionally, secure communication to the EPP interface is required, lowering the likelihood of the authentication mechanisms being compromised.

The EPP server has restrictions on the operations it is permitted to make to the data within the Registry database. Except as allowed by the EPP protocol, the EPP server cannot update the credentials used by Registrars for access to the SRS. These credentials include those used by Registrars to login to ARI’s SRS Web Interface and the EPP service.

Secure communication to the EPP server is achieved via the encryption of EPP sessions. The Registry system and associated toolkits support AES 128 and 256 via TLS.

All communication between the Registrar or the Registrars systems and the SRS is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.
The Production and Operational Testing and Evaluation (OTE) EPP service is protected behind a secure firewall that only accepts connections from registered IP addresses. Registrars are required to supply host IP addresses that they intend to use to access the EPP service.

Certificates are used for encrypted communications with the Registry. Registrars require a valid public⁄private key pair signed by the ARI CA to verify authenticity. These certificates are used to establish a TLS secure session between client and server.

EPP contains credential elements in its specification which are used as an additional layer of authentication. In accordance with the EPP specification, the server does not allow client sessions to carry out any operations until credentials are verified.

The EPP server software combines the authentication and authorisation elements described above to ensure the various credentials supplied are associated with the same identity. This verification requires that:
* The username must match the common name in the digital certificate.
* The certificate must be presented from a source IP listed against the Registrar whose common name appears in the certificate.
* The username and password must match the user name and password listed against the Registrar’s account with that source IP address.

To manage normal operations and prevent an accidental or intentional Denial of Service, the EPP server can be configured to rate limit activities by individual Registrars.
Further details are provided for in Q24 and Q25.

2.1.1.2 STABILITY CONSIDERATIONS

The measures that restrict Registrars to a limit of connections and operations for security purposes also serve to keep the SRS and the EPP server within an acceptable performance and resource utilisation band. Therefore, scaling the service is an almost linear calculation based on well-defined parameters.

The EPP server offers consistent information between Registrars and the SRS Web Interface. The relevant pieces of this information are replicated to the DNS within seconds of alteration, thus ensuring that a strong consistency between the SRS and DNS is maintained at all times.

2.1.2 SRS WEB INTERFACE

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

2.1.2.1 SECURITY AND CONSISTENCY CONSIDERATIONS FOR SRS WEB INTERFACE

The SRS Web Interface contains measures to prevent abuse and to mitigate fraudulent operations. By restricting access, providing user level authentication and authorisation, and protecting the communications channel, the application limits both the opportunity and scope of security compromise.

Registrars are able to create individual users that are associated with their Registrar account. By allocating the specific operations each user can access, Registrars have full control over how their individual staff members interact with the SRS. Users can be audited to identify which operations were conducted and to which objects those operations were applied.

A secure connection is required before credentials are exchanged and once authenticated. On login, any existing user sessions are invalidated and a new session is generated, thereby mitigating session-fixation attacks and reducing possibilities that sessions could be compromised.

2.1.3 SECURING AND MAINTAINING CONSISTENCY OF REGISTRY-REGISTRAR INTERACTION SYSTEMS

ARI ensures all systems through which Registrars interact with the SRS remain consistent with each other and apply the same security rules. Additionally, ARI also ensures that operations on SRS objects are restricted to the appropriate entity. For example:

* In order to initiate a transfer a Registrar must provide the associated domain password (authinfo) which will only be known by the Registrant and the current sponsoring Registrar.
* Only sponsoring Registrars are permitted to update Registry objects.
All operations conducted by Registrars on SRS objects are auditable and are identifiable to the specific Registrar’s user account, IP address and the time of the operation.

2.2 DISSEMINATE STATUS INFORMATION OF TLD ZONE SERVERS TO REGISTRARS

The status of TLD zone servers and their ability to reflect changes in the SRS is of great importance to Registrars and internet users alike. ARI will ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication might be prior to the status change, during the status change and⁄or after the status change (and subsequent reversion to normal) — as appropriate to the party being informed and the circumstance of the status change.

Normal operations are those when:
* DNS servers respond within SLAs for DNS resolution.
* Changes in the SRS are reflected in the zone file according to the DNS update time SLA.

The SLAs are those from Specification 10 of the Registry Agreement.
A deviation from normal operations, whether it is registry wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

2.2.1 COMMUNICATION POLICY

ARI maintains close communication with Registrars regarding the performance and consistency of the TLD zone servers.

A contact database containing relevant contact information for each Registrar is maintained. In many cases, this includes multiple forms of contact, including email, phone and physical mailing address. Additionally, up -to -date status information of the TLD zone servers is provided within the SRS Web Interface.

Communication using the Registrar contact information discussed above will occur prior to any maintenance that has the potential to effect the access to, consistency of, or reliability of the TLD zone servers. If such maintenance is required within a short time frame, immediate communication occurs using the above contact information. In either case, the nature of the maintenance and how it affects the consistency or accessibility of the TLD zone servers, and the estimated time for full restoration, are included within the communication.

That being said, the TLD zone server infrastructure has been designed in such a way that we expect no down time. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate with 100% availability.

2.2.2 SECURITY AND STABILITY CONSIDERATIONS

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

2.3 ZONE FILE ACCESS PROVIDER INTEGRATION

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

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

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

2.4 ZONE FILE UPDATE

To ensure changes within the SRS are reflected in the zone file rapidly and securely, ARI updates the zone file on the TLD zone servers using software compliant with RFC 2136 (Dynamic Updates in the Domain Name System (DNS UPDATE)) and RFC 2845 (Secret Key Transaction Authentication for DNS (TSIG)).

This updating process follows a staged but rapid propagation of zone update information from the SRS, outwards to the TLD zone servers – which are visible to the Internet. As changes to the SRS data occur, those changes are updated to isolated systems which act as the authoritative Primary server for the zone, but remain inaccessible to systems outside ARI’s network. The primary servers notify the designated Secondary servers, which service queries for the TLD zone from the public. Upon notification, the secondary servers transfer the incremental changes to the zone and publicly present those changes.

The protocols for dynamic update are robust and mature, as is their implementation in DNS software. The protocols’ mechanisms for ensuring consistency within and between updates are fully implemented in ARI’s TLD zone update procedures. These mechanisms ensure updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions. ARI has used this method for updating zone files in all its TLDs including the .au ccTLD, pioneering this method during its inception in 2002.
Mechanisms separate to RFC 2136-compliant transfer processes exist; to check and ensure domain information is consistent with the SRS on each TLD zone server within 10 minutes of a change.

2.5 OPERATION OF ZONE SERVERS

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

2.5.1 SECURITY AND OPERATIONAL CONSIDERATIONS OF ZONE SERVER OPERATIONS

The potential risks associated with operating TLD zone servers are recognised by ARI such that we will perform the steps required to protect the integrity and consistency of the information they provide, as well as to protect the availability and accessibility of those servers to hosts on the Internet. The TLD zone servers comply with all relevant RFCs for DNS and DNSSEC, as well as BCPs for the operation and hosting of DNS servers. The TLD zone servers will be updated to support any relevant new enhancements or improvements adopted by the IETF.

The DNS servers are geographically dispersed across multiple secure data centres in strategic locations around the world. By combining multi-homed servers and geographic diversity, ARI’s zone servers remain impervious to site level, supplier level or geographic level operational disruption.

The TLD zone servers are protected from accessibility loss by malicious intent or misadventure, via the provision of significant over-capacity of resources and access paths. Multiple independent network paths are provided to each TLD zone server and the query servicing capacity of the network exceeds the extremely conservatively anticipated peak load requirements by at least 10 times, to prevent loss of service should query loads significantly increase.

As well as the authentication, authorisation and consistency checks carried out by the Registrar access systems and DNS update mechanisms, ARI reduces the scope for alteration of DNS data by following strict DNS operational practices:
* TLD zone servers are not shared with other services.
* The Primary authoritative TLD zone server is inaccessible outside ARI’s network.
* TLD zone servers only serve authoritative information.
* The TLD zone is signed with DNSSEC and a DNSSEC Practice⁄Policy Statement published.

2.6 DISSEMINATION OF CONTACT OR OTHER INFORMATION

Registries are required to provide a mechanism to identify the relevant contact information for a domain. The traditional method of delivering this is via the Whois service, a plain text protocol commonly accessible on TCP port 43. ARI also provides the same functionality to users via a web -based Whois service. Functionality remains the same with the web -based service, which only requires a user to have an Internet browser.

Using the Whois service, in either of its forms, allows a user to query for domain -related information. Users can query for domain details, contact details, nameserver details or Registrar details.

A Whois service, which complies with RFC 3912, is provided to disseminate contact and other information related to a domain within the TLD zone.

2.6.1 SECURITY AND STABILITY CONSIDERATIONS

ARI ensures the service is available and accurate for Internet users, while limiting the opportunity for its malicious use. Many reputation and anti-abuse services rely on the availability and accuracy of the Whois service, However the potential for abuse of the Whois service exists.

Therefore, certain restrictions are made to the access of Whois services, the nature of which depend on the delivery method – either web -based or the traditional text -based port 43 service. In all cases, there has been careful consideration given to the benefits of Whois to the Internet community, as well as the potential harm to Registrants - as individuals and a group - with regard to Whois access restrictions.

The Whois service presents data from the Registry Database in real time. However this access is restricted to reading the appropriate data only. The Whois service does not have the ability to alter data or to access data not related to the Whois service. The access limitations placed on the Whois services prevent any deliberate or incidental denial of service that might impact other Registry Services.

Restrictions placed on accessing Whois services do not affect legitimate use. All restrictions are designed to target abusive volume users and to provide legitimate users with a fast and available service. ARI has the ability to ‘whitelist’ legitimate bulk users of Whois, to ensure they are not impacted by standard volume restrictions.

The data presentation format is consistent with the canonical representation of equivalent fields, as defined in the EPP specifications and ICANN agreement.

2.6.1.1 PORT 43 WHOIS

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

2.6.1.2 WEB -BASED WHOIS

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

2.6.1.3 SEARCHABLE WHOIS

ARI will provide a Web-based Searchable Whois Service for the identification of domain names having similar registration data. This service, deployed as a web-interface alongside the SRS Web Interface, is restricted to pre-authorised clients.

The service is made available to authorized third parties. ARI will perform relevant background checks on a user before providing them with access to the searchable whois. The user will be required to change their password on first successful login, and every 6 months thereafter. Clients that have not used the service in a 3-month period will have their access revoked. ARI will periodically review the information submitted by the client to ensure that contact and usage information is up to date.

Access is logged and monitored to protect against abuse of this service. All searches are logged with the client and timestamp of the request. IP address, port, and browser information is collected in the event that this information is required to assist in identifying the user. The use of HTTPS is enforced for the entire service to prevent exposure of the information from client-side or middle-box caches.

ARI will conduct periodic audits of query logs to identify usage patterns and identify potential occurrences of data mining. Usage patterns will be matched back to the client’s specified reason for use. The client may be suspended from use of the service if ARI believes that abuse is occurring.

Further details on this service are described in the answer to Question 26 2.7 IDNs— Internationalised Domain Names

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

2.7.1 STABILITY CONSIDERATIONS SPECIFIC TO IDN

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

2.7.1.1 PREVENT CROSS LANGUAGE REGISTRATIONS

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

2.7.1.2 INTER-LANGUAGE AND INTRA-LANGUAGE VARIANTS TO PREVENT SIMILAR REGISTRATIONS

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

2.8 DNSSEC

DNSSEC provides a set of extensions to the DNS that allow an internet user (normally the resolver acting on a user’s behalf) to validate that the DNS responses they receive were not manipulated en-route.
This type of fraud, commonly called ‘man in the middle’, allows a malicious party to misdirect internet users. DNSSEC allows a domain owner to sign their domain and to publish the signature, so that all DNS consumers who visit that domain can validate that the responses they receive are as the domain owner intended.

Registries, as the operators of the parent domain for registrants, must publish the DNSSEC material received from registrants, so that Internet users can trust the material they receive from the domain owner. This is commonly referred to as a ‘chain of trust’. Internet users trust the root (operated by IANA), which publishes the registries’ DNSSEC material, therefore registries inherit this trust. Domain owners within the TLD subsequently inherit trust from the parent domain when the registry publishes their DNSSEC material.

In accordance with new gTLD requirements, the TLD zone will be DNSSEC signed and the receipt of DNSSEC material from Registrars for child domains is supported in all provisioning systems.
Recommendation 26 calls for DNSSEC deployment at each zone and subsequent sub-zones at Registry, Registrar and Registrant level. Our compliance wrt the same is detailed in Q43.

2.8.1 STABILITY AND OPERATIONAL CONSIDERATIONS FOR DNSSEC

2.8.1.1 DNSSEC PRACTICE STATEMENT

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

2.8.1.2 RECEIPT OF PUBLIC KEYS FROM REGISTRARS

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

2.8.1.3 RESOLUTION STABILITY

DNSSEC is considered to have made the DNS more trustworthy; however some transitional considerations need to be taken into account. DNSSEC increases the size and complexity of DNS responses. ARI ensures the TLD zone servers are accessible and offer consistent responses over UDP and TCP.

The increased UDP and TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.

ARI complies with all relevant RFCs and best practice guides in operating a DNSSEC -signed TLD. This includes conforming to algorithm updates as appropriate. To ensure Key Signing Key Rollover procedures for child domains are predictable, DS records will be published as soon as they are received via either the EPP server or SRS Web Interface. This allows child domain operators to rollover their keys with the assurance that their timeframes for both old and new keys are reliable.

3. APPROACH TO SECURITY AND STABILITY

Stability and security of the Internet is an important consideration for the Registry system. To ensure that the Registry services are reliably secured and remain stable under all conditions, ARI takes a conservative approach with the operation and architecture of the Registry system.

By architecting all Registry Services to use the least privileged access to systems and data, risk is significantly reduced for other systems and the Registry services as a whole should any one service become compromised. By continuing that principal through to our procedures and processes, we ensure that only access that is necessary to perform tasks is given. ARI has a comprehensive approach to security modeled of the ISO27001 series of standards and explored further in the relevant questions of this response.

By ensuring all our services adhering to all relevant standards, ARI ensures that entities which interact with the Registry Services do so in a predictable and consistent manner. When variations or enhancements to services are made, they are also aligned with the appropriate interoperability standards.

This completes our response to Q23.

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

1. INTRODUCTION

ARI has demonstrated delivery of an SRS with exceptional availability, performance and reliability. ARI’s SRS has successfully supported a large group of Registrars for ASCII and IDN based TLDs. ARI’s SRS meets the following requirements:

* Resilient to wide range of security & availability threats
* Consistently exceeds performance & availability SLAs
* Allows capacity increase with minimal impact to service
* Provides fair & equitable provisioning for all Registrars

2. CAPACITY

ARI’s SRS infrastructure was built to sustain 20M domain names at less than 50% utilization. Based on ARI’s experience and industry analysis, ARI were able to calculate the conservative characteristics of a registry of this size.

Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com & .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:

* An average of 70 SRS TPS per domain, per month; and
* A ratio of 3 query to 2 transform txs

For a Registry with 20M domains this indicates an expected monthly transaction volume of 1,400M txs (840M query and 560M transforms).

Through conservative comparison of .au registry numbers and the .net RFP response - specifically http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄applications⁄sentan.htm we also know:

* The peak daily txs is 6% of the monthly total (.au:6%, .net: 5%)
* The peak 5 min txs is 5% of the peak daily (.au and .net: 5%)

Hence for 20M domains we expect a peak EPP tx rate of 14,000 TPS (5,600 transform TPS and 8,400 query TPS)
Through conservative statistical analysis of the .au registry we additionally know:

* The avg no. of contacts⁄domain is 3.76 (overall not assigned)
* The avg no. of hosts⁄domain is 2.28 (overall not assigned)

This translates into a requirement to store 75.2M contacts and 45.6M hosts.
Finally through real world observations of the .au registry, which has a comprehensive web interface when compared to those offered by current gTLD registries, we know that there is an avg of 0.5 HTTP requests⁄sec to the SRS web interface per registrar. We also know that this behaviour is reasonably flat. To support an estimated 1000 Registrars, would require into a HTTP request load of 500 requests⁄second.

For perspective on the conservativeness of this, the following was taken from data in the May 2011 ICANN reports referenced above:

* .info: ~7.8M domain names peaks at ~1,400 TPS (projected peak TPS of ~3,600 with 20M)

* .com: ~98M domain names peaks at ~41,000 TPS (projected peak TPS of ~8,300 TPS with 20M)

* .org: ~9.3M domain names, peaks at ~1,400 TPS (projected peak TPS of ~3,100 with 20M)

After performing this analysis the projected TPS for .com was still the largest value seen. ARI’s estimated value of 14,000 TPS for a registry with 20M Domains is roughly twice that of the .com projected peak of ~8300 TPS.

ARI benchmarked their SRS infrastructure and used the results to calculate the required computing resources for each of the tiers within the SRS architecture; allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server in the architecture, and the network bandwidth & and packet throughput requirements for the anticipated traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions, and headroom. Despite doubling numbers, effective estimated capacity is still reported as 20M. The technical resource allocations are explored in Q32.

.Shop is projected to reach 70,094 domains at its peak volume and will generate 49 EPP TPS. This will consume 0.35% of the resources of the SRS infrastructure. As is evident ARI’s SRS can easily accommodate this TLD’s growth plans. See attachment ‘Q24 - Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s SRS infrastructure will be only 60% utilized in 2014. The SRS infrastructure capacity can also be easily scaled as described in Q32

3. SRS ARCHITECTURE

ARI’s SRS has the following major components:
* Network Infrastructure
* EPP Application Servers
* SRS Web Interface Application Servers
* SRS Database

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

3.1 EPP

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

3.2 SRS WEB

The SRS Web application server is a Java web application. Registrars connect via the load balancer to a secure HTTPS listener running on the web servers. The SRS web application converts HTTPS requests into database calls which query or update objects in the SRS database. The SRS Web application server tier consists of 2 independent servers that connect to the database via JDBC. If one of these servers is unavailable the load balancer re-routes requests to the surviving server. These servers accept both IPv4 & IPv6.

3.3 SRS DATABASE

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

The SRS database is stored on a storage area network concurrently accessed by all of the database servers which supports N+N redundancy. The SAN consists of 2 switches, 2o control enclosures (each with dual controllers), and 2 expansion enclosures per control enclosure. Each database server host is configured with two 4-port Fibre Channel Host Bus Adaptors (HBAs). Each HBA has 2 SAN fabric connections, one to each SAN switch — providing a total of 4 fabric connections per database server.

Each SAN switch has dual redundant connections to each controller in each Control Enclosure. All disks under the control of a Control Enclosure are configured in a highly resilient RAID 10 array. The Storwize V7000 uses SAN mirroring technology to duplicate data across Control Enclosures. This SAN design provides protection against failure of any component within the Storage Area Network including complete loss of a Control Enclosure and associated expansion enclosures.

3.4 NUMBER OF SERVERS

EPP Servers – The EPP cluster consists of 3 EPP servers that can more than handle the anticipated 20M. .Shop will utilize 0.35% of this at its peak volume. As the utilization increases ARI will add additional EPP servers ensuring the total utilization doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime and does not impact the infrastructure.

SRS Web Servers – The SRS Web cluster consists of 2 SRS Web servers that can more than handle the anticipated 20M. .Shop will utilize 0.35% of this at its peak volume. As the utilization increases ARI will add additional SRS Web servers ensuring total utilization doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime and does not impact the infrastructure.

SRS DB Servers – The SRS DB cluster consists of 4 SRS DB servers that can more than handle the anticipated 20M. .Shop will utilize 0.35% of this at its peak volume. As the utilization increases ARI will add additional SRS DB servers ensuring total utilization doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime and does not impact the infrastructure.

3.5 SRS SECURITY

ARI adopts a multi-layered security solution to protect the SRS. An industry leading firewall is deployed behind the edge router and is configured to only allow traffic on the minimum required ports and protocols. Access to the ARI EPP service is restricted to a list of known Registrar IPs.

An Intrusion Detection device is in-line with the firewall to monitor and detect suspicious activity.

All servers are configured with restrictive host based firewalls, intrusion detection, and SELinux. Direct root access to these servers is disabled and all access is audited and logged centrally.

The SRS database is secured by removal of non-essential features and accounts, and ensuring all remaining accounts have strong passwords. All database accounts are assigned the minimum privileges required to execute their business function.

All operating system, database, and network device accounts are subject to strict password management controls such as validity & complexity requirements.

Registrar access to the SRS via EPP or the Web interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows:

* Registrar’s source IP address must be allowed by the front-end firewalls. This source IP address is received from the Registrar via a secure communication channel from within the SRS Web interface;
* Registrar must use a digital certificate provided by ARI;
* Registrar must use authentication credentials that are provided by to the Registrar via encrypted email.

3.6 SRS HIGH AVAILABILITY

SRS availability is of paramount importance. Downtime is eliminated or minimised where possible. The infrastructure contains no single points of failure. N+1 redundancy is used as a minimum, which not only protects against unplanned downtime but also allows ARI to execute maintenance without impacting service.

Redundancy is provided in the network with hot standby devices & multiple links between devices. Failure of any networking component is transparent to Registrar connections.

N+N redundancy is provided in the EPP and SRS Web application server tiers by the deployment of multiple independent servers grouped together as part of a load -balancing scheme. If a server fails the load balancer routes requests to the remaining servers.

N+N redundancy is provided in the database tier by the use of Oracle Real Application Cluster technology. This delivers active⁄active clustering via shared storage. This insulates Registrars from database server failure.

Complete SRS site failure is mitigated by the maintenance of a remote standby site — a duplicate of the primary site ready to be the primary if required.

The standby site database is replicated using real time transaction replication from the main database using Oracle Data Guard physical standby. If required the Data Guard database can be activated quickly and service resumes at the standby site.

3.7 SRS SCALABILITY

ARI’s SRS scales efficiently. At the application server level, additional computing resource can be brought on-line rapidly by deploying a new server online. During benchmarking this has shown near linear.

The database can be scaled horizontally by adding a new cluster node into the RAC cluster online. This can be achieved without disruption to connections. The SRS has demonstrated over 80% scaling at the database level, but due to the distributed locking nature of Oracle RAC, returns are expected to diminish as the number of servers approaches double digits. To combat this ARI ensures that when the cluster is ‘scaled’ more powerful server equipment is added rather than that equal to the current members. Capacity can be added to the SAN at any time without downtime increasing storage and IOPs.

Additional capacity can be added to the SAN at anytime without downtime. This would result in increasing storage and IOPs.

3.8 SRS INTER-OPERABILITY AND DATA SYNCHRONISATION

The SRS interfaces with a number of related Registry systems as part of normal operations.

3.8.1 DNS UPDATE

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

3.8.2 WHOIS

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

3.8.3 ESCROW

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

4. OPERATIONAL PLAN

ARI follow defined policies⁄procedures that have developed over time by running critical Registry systems. Some principals captured by these are:

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

5. DESCRIPTION OF SLA, RELIABILITY & COMPLIANCE

ARI’s SRS adheres to and goes beyond the scope of Specification 6 and Specification 10 of the Registry Agreement

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

6. RESOURCES

This function will be performed by ARI. ARI staff are industry leading experts in domain name registries with the experience and knowledge to deliver outstanding SRS performance.

The SRS is designed, built, operated and supported by the following ARI departments:

* Products and Consulting team (7 staff)
* Production Support Group (27 staff)
* Development Team (11 staff)

A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q24 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.

ARI provides registry backend services to 5 TLDs and has a vast wealth of experience in estimating the number of resources required to support a Registry System.

Based on past experience ARI estimates that the existing staff is adequate to support a Registry System that is supporting at least 50M domains. Since .Shop projects 70,094 domains, 0.14% of these resources are allocated to this TLD. See attachment ‘Q24 - Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

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

7. FINANCIAL COSTS

The usage of the ARI’s staff and Registry Systems is included in our contract with ARI attached to Q46. This cost is shown in the financial answers.

This completes our response to Q24.

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

1. INTRODUCTION

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

2. TRANSPORT LAYER

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

2.1 AUTHENTICATION

Registrar access to the EPP interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows. Registrars must:

* Present a certificate, during TLS negotiation, signed by the ARI Certificate Authority (CA). The server returns a certificate also signed by the ARI CA. Not presenting a valid certificate results in session termination. ARI requires that the Common Name in the subject field of the certificate identifies the Registrar.

* Originate connections from an IP address that is known to be assigned to the Registrar with that Common Name.
** Registrar must use authentication credentials provided to the Registrar via encrypted email

* Registrars aren’t able to exceed a fixed number of concurrent connections. The connection limit is prearranged and designed to prevent abuse of Registrars’ systems from affecting the Registry. The limit is set to reasonable levels for each Registrar, but can be increased to ensure legitimate traffic is unaffected. If any of the above conditions aren’t met the connection is terminated.

All communication between the Registrars and the EPP service is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

2.2 CONNECTION CLOSE

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

3. EPP PROTOCOL

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

3.1 SESSION MANAGEMENT

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

3.2 SERVICE MESSAGES

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

4. EPP OBJECT MAPPINGS

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

The EPP domain, contact and host object mapping describes an interface for the check, info, create, delete, renew (domain only), transfer (domain & contact only) and update commands. For domain objects The server doesn’t support the use of host attributes as described by RFC5731, but rather uses host objects as described by RFC5731 and RFC5732. Details of each command are:.

* Check command: checks availability of 1 or more domain, contact or host objects in the SRS. Domain names will be shown as unavailable if in use, invalid or reserved, other objects will be unavailable if in use or invalid.

* info command: retrieves the information of an object provisioned in the SRS. Full information is returned to the sponsoring client or any client that provides authorisation information for the object. Non-sponsoring clients are returned partial information (no more than is available in the WhoIs).

* Create command: provisions objects in the SRS. To ascertain whether an object is available for provisioning, the same rules for the check command apply.

* Delete command: begins the process of removing an object from the SRS. Domain names transition into the redemption period and any applicable grace periods are applied. Domain names within the Add Grace Period are purged immediately. All other objects are purged immediately if they are not linked.

* Renew command (domain only): extends the registration period of a domain name. The renewal period must be between 1 to 10 years inclusive and the current remaining registration period, plus the amount requested in the renewal mustn’t exceed 10 years.

* Transfer command (domain and contact only): provides several operations for the management of the transfer of object sponsorship between clients. Clients that provide correct authorisation information for the object can request transfers. Domain names may be rejected from transfer within 60 days of creation or last transfer. The requesting client may cancel the transfer, or the sponsoring client may reject or approve the transfer. Both the gaining and losing clients may query the status of the current pending or last completed transfer.

* Update command: updates authorisation information, delegation information (domains), and registration data pertaining to an object.

5. NON-PROPRIETARY EPP MAPPINGS

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

5.1 GRACE PERIOD MAPPING

The Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (as per RFC 3915) is used to support the domain name lifecycle as per existing TLDs.The update command is extended by the restore command to facilitate the restoration of previously deleted domains in the redemption period. This command defines 2 operations, request & report, described here:

* Request operation: requests the restoration of a domain.

* Report operation: completes the restoration by specifying the information supporting the restoration of the domain. The restore report must include a copy of the Whois information at both the time the domain was deleted & restored, including the restore reason.

5.2 DNSSEC MAPPING

The Domain Name System (DNS) Security Extensions Mapping for EPP, as per RFC5910, is used to support the provisioning of DNS Security Extensions. ARI requires clients use the Key Data Interface. Clients may associate a maximum of 4 keys per domain. The Registry system generates the corresponding DS data using the SHA-256 digest algorithm for the domain and any active variant domains.

ARI is aware of issues DNSSEC causes when transferring DNS providers – a transfer of Registrar usually means a change in DNS provider. DNSSEC key data won’t be removed from the SRS or the DNS if a transfer occurs. It is the responsibility of and requires the cooperation of the Registrant, Registrars, and DNS providers, to provide a seamless transition. ARI observes progress with this issue and implements industry agreed solutions as available. DNSSEC information is included in info responses when the secDNS namespace in login.

6. PROPRIETARY MAPPING

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

6.1 INTERNATIONALISED DOMAIN NAMES

ARI has developed an extension to facilitate the registration and management of Internationalised Domain Names as per RFCs 5890-5893 (collectively known as the IDNA 2008 protocol). This extension extends the domain create command and the info response.
The create command is extended to capture the language table identifier that identifies the corresponding IDN language table for the domain name. Additionally the extension requires the Unicode form to avoid an inconsistency with DNS-form, as per RFC 5891.

The domain info command is extended to identify the language tag and Unicode form provided in the initial create command. This information is disclosed to all querying clients that provided the extension namespace at login. This extension is documented in the attachment ‘Q25 – idnadomain-1.0.pdf’.

6.2 VARIANT

ARI has developed an extension to facilitate the management of Domain Name variants. This extension extends the domain update command and the domain create and info responses. The domain update command is extended to allow the addition (activation) and removal (de-activation) of domain name variants subject to registry operator policy.

The domain create and info responses are extended to return the list of activated domain name variants. This information is disclosed to all querying clients that provided the extension namespace at login. The extension is documented in the attachment ‘Q25 – variant-1.1.pdf’.

6.3 KEY-VALUE

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

7. ADDITIONAL SECURITY

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

7.1 RATE LIMITING

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

7.2 USER PERMISSION MODEL

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

8. COMPLIANCE

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

* Third-party toolkit not compliant with EPP
* EPP service not compliant with EPP
* Both third-party toolkit and EPP service are compliant, however another operational issue causes an issue

Defects are raised and change management processes are followed. Change requests may also be raised to promote integration of third-party toolkits and to meet common practice.

9. CAPACITY

.Shop is projected to reach 70,094 domains at its peak volume and will generate 49 EPP TPS. This will consume 0.35% of the EPP resources of the SRS infrastructure. ARI’s SRS can easily accommodate this. These numbers were described in considerable detail in the capacity section of Q24.

10 RESOURCES

This function will be performed by ARI. ARI provides a technical support team to support Registrars and also provides Registrars with a tool kit (in Java and C++) implementing the EPP protocol. Normal operations for all Registry Services are managed by ARI’s Production Support Group (PSG), who ensure the EPP server is available and performing appropriately.

Faults relating to connections with or functionality of the EPP server are managed by PSG. ARI monitors EPP availability and functionality as part of its monitoring practices, and ensures PSG staff are available to receive fault reports from Registrars any time. PSG has the appropriate network, Unix and application (EPP and load balancing) knowledge to ensure the EPP service remains accessible and performs as required. these ARI departments support EPP:

* Products and Consulting Team (7 staff)
* Production Support Group (27 staff)
* Development Team (11 staff)

A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q25 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.

ARI provides registry backend services to 5 TLDs and has a vast wealth of experience in estimating the number of resources required to support a Registry System.

Based on past experience ARI estimates that the existing staff is adequate to support a Registry System that is supporting at least 50M domains. Since .Shop projects 70,094 domains, 0.14% of these resources are allocated to this TLD. See attachment ‘Q25 - Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

11. FINANCIAL COSTS

The usage of the ARI’s staff and Registry Systems is included in our contract with ARI attached to Q46. This cost is shown in the financial answers.

This completes our response to Q25.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. For more background information on ARI please see the attachment ‘Q26 – ARI Background & Roles.pdf’. This response describes the Whois interface as implemented by ARI.

1. INTRODUCTION

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

2. PORT 43 WHOIS SERVICE

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

2.1 Query Format

By default Whois searches for domains. To facilitate the queries of other objects a keyword must be included before the search string. Supported keywords are:
* Domain
* Host⁄Nameserver
* Contact
* Registrar
Keywords are case-insensitive. The remainder of the input is the search string. Wildcard chars may be used in search strings to match zero or more chars (%), or match exactly one char. Wildcard chars must not appear in the first 5 chars.

2.2. RESPONSE FORMAT

The response consists -
* An object-specific response represented by multiple key⁄value pairs. Where no object could be found the response is ‘No Data Found’
* query-related meta-information to identify data freshness
* legal disclaimer
This format is consistent with that prescribed in the Registry agreement.

2.3, DOMAIN DATA

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

2.3.1. INTERNATIONALISED DOMAIN NAMES

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

2.3.2. RESERVED DOMAIN NAMES

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

2.4. NAMESERVER DATA

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

2.5. CONTACT DATA

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

2.6. REGISTRAR DATA

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

2.7. NON-STANDARD DATA

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

3. WEB-BASED WHOIS SERVICE

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

4. SECURITY CONTROLS

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

5. BULK ACCESS

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

5.1. PERIODIC ACCESS TO THIN REGISTRATION DATA

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

5.2 Exceptional Access to Thick Registration Data

If requested by ICANN, ARI shall provide exceptional access to thick registration data for a specified Registrar. The date will contain full information for the following objects:

* Domain names sponsored by the Registrar
* Hosts sponsored by the Registrar
* Contacts sponsored by the Registrar
* Contacts linked from domain names sponsored by the Registrar
As above, the format of the data will be consistent with the format specified for Data Escrow. And will be made available to ICANN using SFTP.

6. CAPACITY

ARI’s Whois infrastructure is built to sustain 20M domain names at less than 50% utilization. Based on ARI’s experience running a high volume ccTLD registry (.au) and industry analysis, ARI were able to calculate the conservative characteristics of a registry of this size.

* An average of 30 Whois txs per domain, per month.

Which indicates an expected monthly transaction volume of 600M txs for a registry with 20M DUMs

Through conservative comparison of .au registry numbers and the .net RFP response - specifically http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄applications⁄sentan.htm we also know:

* The peak daily transactions is 6% of the monthly total (.au:6%, .net: 5%)
* The peak 5 min is 5% of the peak day (.au:5%, .net: 0.6%)

Thus we expect a peak WhoIs tx rate of 6,000 TPS.

For perspective on the conservativeness of this, the following numbers were taken from data in the May 2011 ICANN reports referenced above:

* .info ~7.8M domain names, peaks at ~1,300 TPS (projected peak TPS of ~3,400 with 20M names).
* .mobi ~1M domain names, peaks at ~150 TPS (projected peak TPS of ~3,000 TPS with 20M names).
* .org ~9.3M domain names, peaks at ~1,300 TPS (projected peak TPS of ~2,800 with 20M names).

After performing this analysis the projected TPS for .info was still the largest value seen. ARI’s estimated value of 6,000 TPS for a registry with 20M Domains is roughly twice that of the .info projected peak of ~3400 TPS.

ARI benchmarked their WhoIs infrastructure and used the results to calculate the required computing resources for each of the tiers within the WhoIs architecture — allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server within the architecture, as well as the network bandwidth and packet throughput requirements for the anticipated traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions and head room for growth. Despite doubling numbers, effective estimated capacity is still reported as 20 million domain names. The technical resource allocations are explored in question 32.

ARI understand the limitations of these calculations but they serve as a best estimate of probable transaction load. Over and above this ARI has built significant overcapacity of resources and as the numbers themselves are more conservative than real world observations, we are confident these capacity numbers are sufficient.
.Shop is projected to reach 70,094 domains at its peak volume and will generate 21 WhoIs transactions per second. This will consume 0.35% of the resources of the WhoIs infrastructure. As is evident ARI’s WhoIs can easily accommodate this TLD’s growth plans. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s WhoIs infrastructure will be only 60% utilized. The WhoIs infrastructure capacity can also be easily scaled as described in question 32

7. ARCHITECTURE

Whois uses a separate replica database independent of the SRS database. Oracle Data Guard ensures the two databases are synchronised in real-time. The Whois service is operated live from the SRS ‘failover’ site, with the SRS ‘primary’ site serving as the ‘failover’ site for the Whois service. Both sites have enough capacity to run both services simultaneously. The architecture and data flow diagrams are described below and shown in the attachment ‘Q26 – WhoIs.pdf’

Traffic enters the network from the Internet through border routers and then firewalls. All traffic destined for this service except for TCP ports 43, 80 & 443 is blocked. Load balancers forward the request to one of the application servers running ARI built Whois software. Each server is connected to the database cluster through another firewall further restricting access to the. Each server uses a restricted Oracle user that has read only access to the Registry data and can only access the data that is relevant to the Whois queries. This ensures that in the unlikely event of an application server compromise the effects are limited.

All components are configured and provisioned to provide N+1 redundancy. Multiple Internet providers with separate upstream bandwidth suppliers are used. At least one additional component of all hardware exists, enabling maintenance without downtime. This configuration provides a service exceeding the availability requirements in Specification 10.

The use of load balancing allows addition of application servers with no downtime. From a database perspective, the ability to scale is enabled by utilising Oracle RAC database clustering.
The entire service, including routers, firewalls and application layer is IPv6 compatible and Whois is offered on both IPv4 and IPv6 interfaces. Detail about this architecture is available in our response to Question 32.

7.1. SYNCHRONIZATION

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

7.2. INTERCONNECTIVITY WITH OTHER SERVICES

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

7.3. IT AND INFRASTRUCTURE RESOURCES

The WhoIs service is provided utilizing Cisco networking equipment, IBM application servers &, IBM database servers and SAN. They are described in the attachment ‘Q26 - WhoIs.pdf’. For more information on the IT infrastructure including server specifications and database capabilities please see Q32 & Q33.

8. COMPLIANCE

Compliance with WhoIs RFCs is achieved through design and QA.
QA processes provide confidence that any changes to the service don’t result in regression issues. Automated build processes execute test suites, prior to the committing of code and nightly, that ensure every facet of the WhoIs service is covered and compliant with RFCs. The final deliverable is packaged and tested again.
New versions follow a deployment schedule. The new version is deployed into an OT&E environment for registrar integration testing. After a fixed time in OT&E without issue, they are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments.
ARI is committed to providing a WhoIs service that integrates with third party tools without issue and as such tests are conducted using third party tools such as jWhoIs, a popular UNIX command line WhoIs client.
Defects are raised and follow the change management process for all issues where the WhoIs service has been determined to not comply with the RFCs.

9. SEARCHABLE WHOIS

ARI will provide a Web-based Searchable Whois Service restricted to pre-authorised clients.

9.1. DESCRIPTION OF SERVICE

The service provides search capabilities defined in Specification 4 and allows for:

* Exact-match on the registrar id, name server name, and name server’s IP address;
* Partial-match on domain name, contacts, address (street, city, state or province, postcode, country); and
* Boolean search capabilities.

Matches for contact name and all postal address fields are case-insensitive. The client is restricted to one concurrent search to prevent unnecessary load on the system. The results include a list of domain names that match the criteria. The service allows for addition or removal of search criterion to meet local laws.

9.2. AUTHORISATION OF CLIENTS

Potential clients will request access to this service by providing the following on fax:
* Name
* Organisation
* Position
* Contact information
* Reason
* Query volume
* IP address

Access will be approved after background checks. Access is logged and monitored to protect against abuse. The use of HTTPS is enforced for the entire service.

Periodic audits of query logs will be used to identify any occurrences of data mining to suspend abusive clients.

10. RESOURCES

This function will be performed by the following ARI departments:
* Products and Consulting team (7 staff)
* Production Support Group (27 staff)
* Development Team (11 staff)
* Legal, Abuse and Compliance Team (6 staff)
and the following departments outsourced to the Directi Group:
* Abuse and Compliance Team (20 staff)

The products and consulting team is responsible for product management of the Whois solution including working with clients and the industry to identify new features or changes required to the system.

ARI employ a development team responsible for the maintenance and continual improvement of the Whois software

ARI’s Production Support Team ensures the successful operation of the Whois system. The team comprises Database Administrators, Systems Administrators and Network Administrators. This team routinely checks and monitors bandwidth, disk and CPU usages to plan and respond to expected increases in the volume of queries, and perform maintenance of the system including security patches and failover and recovery testing.

The Directi Group and ARI Abuse and compliance teams provide abuse monitoring detection mechanisms to block data mining. Additionally the support team in conjunction with both the Compliance teams administer requests for listing on the Whitelist, as well as requests for access to the searchable whois

A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q26 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within. A detailed list of the Abuse and Compliance desk of Directi is provided in Q28.

ARI provides registry backend services to 5 TLDs and has a vast wealth of experience in estimating the number of resources required to support a Registry System.

Based on past experience ARI estimates that the existing staff is adequate to support a Registry System that is supporting at least 50M domains. Since .Shop projects 70,094 domains, 0.14% of these resources are allocated to this TLD. See attachment ‘Q26 - Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

The Directi Group is protected against loss of staff due to its scale of operations. This is described in further detail in Q39

11. FINANCIAL COSTS
The usage of the ARI’s staff and Registry Systems is included in our contract with ARI attached to Q46. This cost is shown in the financial answers.

The usage of Directi Group’s staff is included in our contract with Directi attached to Q46. This cost is shown in the financial answers.

This completes our answer to Q26.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. For more background please see attachment ‘Q27 – ARI Background & Roles.pdf’. This response describes the Registration Lifecycle as implemented by ARI.

1. INTRODUCTION

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

2. REGISTRATION PERIODS

The Registry supports registration up to 10 years and renewals for 1 to 10 years. Transfers extend registration by 1 year. The total validity period can’t exceed 10 years.

3. STATES

The states that a domain can exist in are: Registered, Pending Transfer, Redemption, Pending Restore & Pending Delete.

All domain name statuses (RFC 3915, 5730-5734 and 5910) are covered below

3.1 REGISTERED

EPP Status: ok
In DNS: Yes
Allowed Operations: Update, Renew, Transfer (request) & Delete
The default state of a domain - No pending operations. The Sponsoring Registrar may update the domain.

3.2 PENDING TRANSFER

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

3.3 REDEMPTION

EPP Status:pendingDelete
RGP Status:redemptionPeriod
In DNS:No
Allowed Operations:Restore (request)

Domain has been deleted. The sponsor may request restoration of the domain. The domain continues to be withheld from the DNS unless restored. No transform operations other than restore allowed.

3.4 PENDING RESTORE

EPP Status:pendingDelete
RGP Status:pendingRestore
In DNS:No
Allowed Operations:Restore (report)
a restore request is pending. Sponsor must submit a restore report. The domain remains withheld from the DNS. No transform operations other than restore report allowed.

3.5 PENDING DELETE

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

4. GRACE PERIODS

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

4.1 ADD GRACE PERIOD

Length:5 days
RGP Status:addPeriod
Allows for the no-cost cancellation of a domain to rectify errors within 5 days from registration. The following rules apply for operations during this period:

* Delete: Sponsoring Registrar may delete the domain with immediate effect and receive a refund subject to the Add Grace Period Limits consensus policy.
* Renew: sponsor may renew the domain and is charged for the operation. The total period is extended by the renewal term, limited to 10 yr maximum.
* Transfer: The Registry system rejects transfers in the first 60 days after the initial registration as per ICANN Policy.
* Bulk Transfers: A bulk transfer is permitted during the Add Grace Period as per ICANN policy, and causes the Add Grace Period to not apply.

4.2 RENEW GRACE PERIOD

Length:5 days
RGP Status:renewPeriod
Allows the Sponsoring Registrar to undo a renewal within 5 days of the renewal command. The following rules apply for operations during this period:

* Delete: Sponsoring Registrar may delete the domain and receive a refund. The extension caused by the preceding renew is reversed and unless the domain is also in the Add Grace Period, the domain enters the Redemption state. If in the Add Grace Period it is deleted with immediate effect and available for registration.
* Renew: sponsor can renew a domain again and is charged for the operation, causing a second independent Renewal Grace Period to start. The total period is extended by the renewal term, limited to 10 yr maximum.
* Transfer: an approved transfer command ends the current Renew Grace Period without a refund and begins a Transfer Grace Period.
* Bulk Transfers: cause the Renew Grace Period to end without a refund, consequently registration periods are not changed.

4.3 AUTO-RENEW GRACE PERIOD

Length:45 days
RGP Status:autoRenewPeriod
Allows for domains to remain in the DNS past expiration giving time for the Registrar to obtain renewal confirmation from the Registrant.
This period lasts for 45 days after expiration. The following rules apply for operations during this period:

* Delete: the Registrar, may delete the domain and receive a refund. The domain enters the Redemption state.
* Renew: the Registrar can renew a domain again and is charged for the operation, causing a second independent Renewal Grace Period to start. The total period is extended by the renewal term, limited to 10 yr maximum.
* Transfer: an approved transfer command ends the current Auto-Renew Grace Period with a refund to the losing Registrar and begins a Transfer Grace Period. The registration period auto-renew extension is reversed and the registration is extended by the period specified in the transfer.
* Bulk Transfers: bulk transfers cause the Auto-Renew Grace Period to end without a refund consequently registration periods are not changed.

4.4 TRANSFER GRACE PERIOD

Length: 5 days
RGP Status:transferPeriod
Transfer Grace Period allows the Sponsoring Registrar to undo the registration period extension (due to a transfer command), via the deletion of a domain within 5 calendar days. The following rules apply for operations during this period:

* Delete: the Registrar may delete the domain and receive a transfer fee refund. The extension to the registration period of the preceding transfer is reversed and the Redemption state is entered.
* Renew: the Registrar can renew the domain causing a Renewal Grace Period to begin. The Registrar is charged and the total period is extended by the renewal term, limited to 10 yr maximum
* Transfer: The Registry system rejects transfers in the first 60 days after the initial registration as per ICANN Policy. Special situations requiring a transfer back to the losing Registrar are dealt with case by case manually.
* Bulk Transfers: bulk transfers cause the Transfer Grace Period to end without a refund; consequently registration periods are not changed.
The Transfer Grace Period does not have any impact on other commands.

4.5 REDEMPTION GRACE PERIOD

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

4.6 OVERLAP OF GRACE PERIODS

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

4.6.1 TRANSFER CLARIFICATION

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

5. TRANSITIONS

5.1. AVAILABLE 〉 REGISTERED

Triggered by the receipt of a create command to register the domain. The Sponsoring Registrar is charged for the creation amount. this transition begins the Add Grace Period.

5.2 REGISTERED 〉 PENDING TRANSFER

Triggered by the receipt of a request transfer command. The transfer must result in domain registration extension — the gaining Registrar is charged for the transfer. Requests to transfer the domain within 60 days of creation or a previous transfer are rejected.

5.3 PENDING TRANSFER 〉 REGISTERED

Triggered by 1 of 4 operations:

* Cancel: the Gaining Registrar may cancel a transfer
* Reject: the Losing Registrar may reject the transfer
* Approve: the Losing Registrar may approve the transfer.
* Auto-Approve: If after 5 days, no action has been taken, the system approves the transfer.

In case of Cancel⁄Reject. The Gaining Registrar is refunded the transfer fee. The registration period remains unchanged and all grace periods existing at the time of transfer request remain in effect if not elapsed.

In case of Approve ⁄ Auto-Approve if the transfer was requested during the Auto-Renew Grace Period, the extension to the registration period is reversed and the Losing Registrar is refunded the auto-renew. The registration period is extended by the amount specified. This begins the Transfer Grace Period.

5.4 REGISTERED 〉 DELETED

On receipt of a delete command if the domain is in the Add Grace Period, it is purged from the Database and immediately available for registration.

5.5 REGISTERED 〉 REDEMPTION

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

5.6 REDEMPTION 〉 PENDING RESTORE

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

5.7 PENDING RESTORE 〉 REGISTERED

During the Pending Restore period the Sponsoring Registrar may complete the restore via a restore report containing the Whois information — submitted prior to the deletion, the Whois information at the time of the report, and the reason for the restoration.

5.8 PENDING RESTORE 〉 REDEMPTION

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

5.9 Redemption 〉 Pending Delete

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

5.10 PENDING DELETE 〉 DELETED

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

6. LOCKS

Locks may be applied to the domain to prevent specific operations. The Sponsoring Registrar may set the locks prefixed with ‘client’ while locks prefixed with ‘server’ are added and removed by the Registry Operator. Locks are added and removed independently but they can be combined to facilitate the enforcement of higher processes, such as ‘Registrar Lock’, and outcomes required as part of UDRP. All locks are compatible with EPP RFCs. The available locks are:

* clientDeleteProhibited, serverDeleteProhibited - Requests to delete the object are rejected: – clientHold, serverHold - : DNS information is not published
* clientRenewProhibited, serverRenewProhibited - : Requests to renew the object are rejected. Auto-renew is allowed
* clientTransferProhibited, serverTransferProhibited - : Requests to transfer the object are rejected
* clientUpdateProhibited, serverUpdateProhibited - : Requests to update the object are rejected, unless the update removes this status

7. TYPICAL REGISTRATION LIFECYCLE

A typical domain is provisioned immediately on registration. The domain name may be updated over its lifetime to reflect changes in contact or delegation information. The domain name will remain active in the registry by automatic renewals once the registration period has lapsed however Registrars may elect to explicitly renew the domain before the automatic renewal or to extend the registration period by more than one year. The registrar may delete the domain following non-payment or request from the registrant resulting in the immediate removal from the DNS. A time-delayed set of server events will result in the purging of the name from the registry database if the name is not restored during a 30-day redemption period.

8. SPECIAL CONSIDERATIONS

8.1 ICANN-APPROVED BULK TRANSFERS

ICANN-Approved Bulk Transfers performed in accordance with Part B of the Inter-Registrar Transfer Policy do not follow the typical transfer lifecycle. Existing grace periods are invalidated and no refunds are credited to the Losing Registrar. The prohibition of transfer period on domains created or transferred within 60 days does not apply.

8.2 UNIFORM RAPID SUSPENSION

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

9. UPDATE⁄DNS

The update command does not impact the state of the domain through the Registration Lifecycle, however the command can be used to add and remove delegation information, which changes the DNS state of the domain.

10. RESOURCES

This function will be performed by the following ARI departments:
* Products and Consulting team (7 staff)
* Development Team (11 staff)
the following departments outsourced to the Directi Group:
* Abuse and Compliance Team (20 staff)

ARI’s Registry performs all time-based transitions automatically and enforces all other business rules — without requiring human resources for normal operation. If changes to the automatic behaviours or restrictions enforced by the policy system are required, ARI has a development team for this.

Domain Name Lifecycle aspects requiring human resources to manage are included in the ARI outsourcing include:
* Processing Add Grace Period exemptions as requested by Registrars.
* Processing restore reports provided by Registrars.
* Meeting the Registry Operators obligations under ICANN’s Transfer Dispute Policy.
* Performing exception processing in the case of approved transfers during the 60 day transfer prohibition window.

The Products and Consulting team is responsible for product management of the Registration Lifecycle, including working with clients and the industry to identify new features or changes required to the system.

The automated aspects of the Registration lifecycle are supported by ARI’s Domain Name Registry software. ARI has a development team for maintenance and improvement of the software

Most manual tasks fall to the Abuse and Compliance teams of the Directi Group, with staff experienced in development of policy for policy rich TLD environments. They have the required legal and industry background to perform this function.

The Compliance team outsourced to the Directi Group is responsible for any abuse of the registration policies within .Shop and supervising the role of any external agency involved in validation

A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q27 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within. A detailed list of the Abuse and Compliance desk of Directi is provided in Q28.

ARI provides registry backend services to 5 TLDs and has a vast wealth of experience in estimating the number of resources required to support a Registry System.

Based on past experience ARI estimates that the existing staff is adequate to support a Registry System that is supporting at least 50M domains. Since .Shop projects 70,094 domains, 0.14% of these resources are allocated to this TLD. See attachment ‘Q27 - Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

The Directi Group is protected against loss of staff due to its scale of operations. This is described in further detail in Q39

11. FINANCIAL COSTS

The usage of the ARI’s staff and Registry Systems is included in our contract with ARI attached to Q46. This cost is shown in the financial answers.

The usage of Directi Group’s staff is included in our contract with Directi attached to Q46. This cost is shown in the financial answers.

This completes our answer to Q27.

DotShop Inc. is a wholly owned subsidiary within the Directi Group. The Directi Group runs various businesses including several ICANN Accredited Domain Registrars (including ResellerClub.com and BigRock.com) and Web Hosting companies. The Directi Group manages centralized functions for all its businesses. We have outsourced our Abuse and Compliance functions to the Directi Group and our Abuse and Compliance desk will be staffed as a cost center by them.

This response aims to provide a 360 degree perspective on our policies and processes to prevent abusive activities, and ensure swift mitigation when abuse does occur. We have prepared this plan based on over a decade’s experience of fighting abuse as a Registrar, learnings through active industry participation, best-practices from existing registry operators and expert inputs from our back-end technical partner ARI (AusRegistry International).

1. ABUSE MITIGATION EXPERIENCE AND CAPABILITIES

With over four million active domain names registered through its registrars, Directi has significant experience (over 10 years) of managing domain names and is fully cognizant of the threat that stems from their abuse.
As one of the world’s top ten registrars, we equally understand our ability to make a sizable contribution towards curbing internet abuse, and believe that mitigating this threat is one of our foremost responsibilities. By instituting policies, processes and services which go significantly above and beyond our obligation as a registrar, Directi has taken various initiatives to make the Internet a safer ground.
To drive this effort, Directi has a committed function working towards identifying abusive domain names and enforcing its policies. Our Abuse Desk functions 24⁄7 and takes prompt and effective action (both reactively and proactively) against domains reported or co-networked to be involved in any sort of online abuse. Complaints ranging from phishing, spam, malware perpetration, 419 scams, child pornography, copyright infringement and varied forms of abuse are subject to investigation at our Abuse Desk on a daily basis. The nature of abuse and the types of complaints received are varied in nature and intensity, and are documented in more detail further.
On average we already address, 15000 reported or detected abuse cases per year. Abuse cases are addressed within pre-determined SLAs, and our team is committed to ensure that each incident is resolved satisfactorily. The Directi abuse team has been heralded on many occasions by various security groups, law enforcement organizations and the general anti-abuse community for the manner in which abuse mitigation has been handled by us. Additionally, we have always become highly involved, and continue to remain committed to industry-wide efforts to address organized abuse such as botnets (see below) and large scale phishing attacks, and any other malfeasances.

1.1 NOTABLE INSTANCES OF DIRECTI’S SUCCESSFUL ABUSE MITIGATION INITIATIVES

Our abuse mitigation team has developed strong relationships with many security groups and individuals in the abuse mitigation community, with the aim of sharing intelligence and facilitating quick action on abusive domain names. These sources provide us actionable intelligence on domains bought through our registrar. We have also participated in coordinated takedowns with such agencies in the past and are committed to doing so in the future. Please refer to Attachment ʹQ28_Recommendationsʹ which showcases letters from several global agencies including the IRS and the FBI, commending our work and cooperation on several fronts. Following are some examples of cases where our efforts paid great results in abuse mitigation –

1.1.1 MARIPOSA WORKING GROUP

Directi was part of the Mariposa Working Group which was responsible for taking down the largest known botnet network at the time.
(Ref: http:⁄⁄defintel.com⁄docs⁄Mariposa_White_Paper.pdf)

ʺDirecti is BY FAR THE BEST registrar we have ever worked with at taking down criminal domains in a timely, efficient and professional manner. Your team was absolutely key to the Mariposa Working Group taking down one of the largest Botnets in the history of the Internet. You and your team should be VERY proud of that :)ʺ -- Christopher Davis, Former CEO of Defence Intelligence

1.1.2 IM WORM BOTNET TAKEDOWN COORDINATED BY IID

Since 1996, IID (Internet Identity) has been providing technology and services that secure the Internet presence for an organization and its extended enterprise. It recently introduced a number of unique approaches to secure organizations’ use of Internet infrastructure with ActiveTrust® BGP, ActiveTrust DNS, and ActiveTrust Resolver with TrapTrace. Directi worked with IID, acting against problematic domain names and sharing intelligence to take down a notorious botnet that was plaguing the internet for quite some time.

ʺThank you for your exceptional coordination with our team and the other providers … during the simultaneous shutdown. We wanted to follow up with you and let you know that despite the last minute unanticipated scramble, the takedown was a success and the botnet has been shutdown.ʺ -- Lauren Lamp, Manager ⁄ Service Delivery - internetidentity.com

1.1.3 FAKE PHARMACY TAKEDOWNS COORDINATED BY LEGITSCRIPT

LegitScript is the leading source of information for patients, Internet users, physicians, businesses and other third parties who need to know if an Internet pharmacy is acting in accordance with the law and accepted standards of ethics and safety. LegitScript is identified by the National Association of Boards of Pharmacy as the only Internet pharmacy verification service that adheres to its standards. After affiliating with LegitScript, we have witnessed a steep downfall in fake pharma-related registrations. ResellerClub (referred below) is our wholesale registrar brand.
(Ref:http:⁄⁄legitscriptblog.com⁄2009⁄03⁄directi-no-safe-haven-for-rogue-internet-pharmacies⁄)

ʺSome registrars claim that they cannot shut down dangerous ʹno-prescription-requiredʹ and fake online pharmacies. ResellerClub has proven that this is not true. By refusing to profit from dangerous, criminal activity at the expense of Internet users, ResellerClub has established itself as a responsible example for the rest of the
Internet community.ʺ John Horton, President, LegitScript.com

We have enclosed a commendation letter from LegitScript in
Attachment ʹQ28_Recommendationsʹ, which speaks of our leadership in fighting fake and rouge pharmacies.

1.1.4 419 FEEDBACK LOOP WITH ARTISTS AGAINST 419 (AA419.ORG)

An honorary member of the APWG (Anti-Phishing Working Group), Artists Against 419 is a premier organization with expertise in identifying, cataloging, and terminating fraud sites. Our tie-up with them has been greatly successful in eliminating fraudulent registrations within our portfolio. (Ref: http:⁄⁄blog.aa419.org⁄?p=134)

ʺMany registrars do respond to abuse reports and take action against them. However none do it as quickly and efficiently as Directi. If all registrars and hosters take this approach, it might then be possible to reduce internet fraud.ʺ -- aa419.org

We have enclosed a letter from Artists Against 419 in Attachment ʹQ28_Recommendationsʹ commending the speed and impact of our proactive abuse mitigation activities.

1.1.5 FBI’S ABUSE MITIGATION CASE STUDY FEATURING DIRECTI: Brussels, February 2011

In light of Directi’s efforts towards abuse prevention, we were approached by the Federal Bureau of investigation, USA to make a presentation and share Directiʹs success story at a Registry-Registrar-ISP conference in Belgium. A detailed presentation on our abuse mitigation efforts was delivered by the FBI, describing how Directiʹs abuse desk functions, as a template for domain registrars to adopt.

ʺ… Directi is one of the shining stars of the registrar community in eliminating fraud, exercising due diligence and having a good reputation. We believe our meeting in Brussels would be an excellent platform for you to highlight the success story of Directi. We are very interested to hear your methods.ʺ SSA Bobby Flamin, Operational Technology Division, FBI.

Our collaboration with organizations like these has given us great perspective into abuse mitigation, and helped us in our goal of being a ‘zero -abuse tolerance registrar’. We shall leverage these relationships to similar effect with the .Shop, and ensure that the best practices from our registrar business will be emulated here. We will also encourage registrars to adopt these practices to achieve the goal of keeping .generic free of all abuse.

We have enclosed a commendation letter from the FBI in Attachment ʹQ28_Recommendationsʹ, which congratulates us for a great job in helping them cut down fraud.

2. PROPOSED ABUSE POLICY FOR .SHOP

We have fully adopted the definition of abuse developed by the Registration Abuse Policies Working Group (Registration Abuse Policies Working Group Final Report 2010).

Our abuse policies described in this section apply to initial and ongoing domain registrations, ie any domain name must comply with these policies during registration and throughout its tenure.

Abusive behaviour in a TLD may relate can be categorized into:

2.1 REGISTRATION POLICY VIOLATIONS

.Shop adopts certain Registration policies and any violations of these policies would be treated as an Abuse.

2.1.1 SUNRISE POLICY VIOLATION

.Shop will have a sunrise period as described in the response to Question 29. Our sunrise policy will have an overarching goal to protect interests of IP holders globally, and be based on best practices seen in previous TLD launches. We will implement the Trademark Claim Service and partner with experienced service providers to run the TM verification, Sunrise Challenge and Auction processes. All Sunrise domain names will be validated before they are activated. Hence the possibility of a Sunrise policy violation is low. However the Sunrise process provides for a Sunrise Dispute Resolution Policy, and any disputes that fall within its scope will be referred to the Sunrise Dispute Resolution provider. If the abuse desk receives any complaints concerning a sunrise domain which violates the Sunrise eligibility policy the abuse desk will direct the complainant to the Sunrise Dispute Resolution provider

2.1.2 WHOIS INACCURACY

.Shop requires Whois accuracy as per its contracts. Any domain name with inaccurate whois information will be deemed to be in violation of its contract and hence will be deemed as an abuse and handled in the manner described ahead.

2.1.3 TRADEMARK INFRINGEMENT VIOLATION AND UDRP

.Shop requires registrants to abide by UDRP. If the abuse desk receives any complaints concerning a domain name which infringes upon the trademark right of a 3rd party, the abuse desk will direct the complainant to the Uniform Dispute Resolution provider.

All names registered under .Shop will be subject to the UDRP and URS processes. We believe that URS will deter cybersquatting, and some malicious activities that illegitimately use brand names. We will seek to expeditiously process all URS cases, and are already equipped with mature processes and tracking systems to manage and keep track of all cases.

The URS process will be run by our compliance team, who has significant experience in processing UDRP complaints for our Registrar businesses.

While Registrars will be responsible for processing all UDRP cases related to the .Shop, we will reserve the right to act on their behalf when necessary, and process all court orders that are directed to us.

2.2 ACCEPTABLE USAGE RELATED VIOLATIONS

.Shop adopts certain Content and Acceptable usage policies and any violations of these would be treated as an Abuse. The following are deemed as violations of our content and acceptable usage policy

2.2.1 INTELLECTUAL PROPERTY, TRADEMARK, COPYRIGHT, AND PATENT VIOLATIONS, INCLUDING PIRACY

Intellectual property (IP) is a term referring to a number of distinct types of creations of the mind for which a set of exclusive rights are recognized—and the corresponding fields of law. Under intellectual property law, owners are granted certain exclusive rights to a variety of intangible assets, such as musical, literary, and artistic works; discoveries and inventions; and words, phrases, symbols, and designs. Common types of intellectual property rights include copyrights, trademarks, patents, industrial design rights and trade secrets in recognized jurisdictions. Any act resulting in theft, misuse, misrepresentation or any other harmful act by any individual or a company is categorized as Intellectual Property violation.

2.2.2 SPAMMING

The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums. Unsolicited emails advertising legitimate and illegitimate products, services, and⁄or charitable requests and requests for assistance are also considered as spam.

2.2.3 PHISHING (and various forms of identity theft)

Fraudulent web services and applications meant to represent⁄confuse or mislead internet users into believing they represent services or products for nefarious purposes, such as illegally gaining login credentials to actual legitimate services.

2.2.4 PHARMING AND DNS HIJACKING

Redirection of DNS traffic from legitimate and intended destinations, by compromising the integrity of the relevant DNS systems. This leads unsuspecting Internet users to fraudulent web services and applications for nefarious purposes, such as illegally gaining login credentials to actual legitimate services.

2.2.5 DISTRIBUTION OF VIRUSES OR MALWARE

Most typically the result of a security compromised web service where the perpetrator has installed a virus or “malevolent” piece of software meant to infect computers attempting to use the web service in turn. Infected computers are then security compromised for various nefarious purposes such as gaining stored security credentials or personal identity information such as credit card data. Additionally compromised computers can sometimes be remotely controlled to inflict harm on other internet services (see botnet below).

2.2.6 CHILD PORNOGRAPHY

Child pornography refers to images or films (also known as child abuse images) and, in some cases, writings depicting sexually explicit activities involving a minor.

2.2.7 USING FAST FLUX TECHNIQUES

A methodology for hiding multiple source computers delivering malware, phishing or other harmful services behind a single domain hostname, by rapidly rotating associated IP addresses of the sources computers through related rapid DNS changes. This is typically done at DNS zones delegated below the level of a TLD DNS zone.

2.2.8 RUNNING BOTNET COMMAND AND CONTROL OPERATIONS

A Botnet is a significant coordinated net of compromised (sometimes tens of thousands) computers running software services to enact various forms of harm - ranging from unsanctioned spam to placing undue transaction traffic on valid computer services such as DNS or web services. Command and control refers to a smaller number of computers that issue⁄distribute subsequent commands to the Botnet. Compromised botnet computers will periodically check in with a command and control computer that hides behind a list of date triggered, rotating domain registrations, which are pre-loaded in the compromised computer during its last check-in.
Registries play a key role in breaking this cycle of pre-determined domain registrations by deactivating said registrations prior to the compromised computers being able to use them to contact the command and control computer. Successful intervention results in the botnet losing contact with their command and control computers, leaving them inactive and reducing potential harms.

2.2.9 HACKING

Hacking constitutes illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of other individuals. Also includes any activity that might be used as a precursor to an attempted system penetration.

2.2.10 FINANCIAL AND OTHER CONFIDENCE SCAMS

Financial scams, including but not limited to the cases defined below, are operated by fraudsters to lure investors into fraudulent money making schemes. Prominent examples that will be treated as abusive are –
1. Ponzi Schemes. A Ponzi scheme is essentially an investment fraud wherein the operator promises high financial returns or dividends that are not available through traditional investments. Instead of investing victimsʹ funds, the operator pays ʺdividendsʺ to initial investors using the principle amounts ʺinvestedʺ by subsequent investors. The scheme generally falls apart when the operator flees with all of the proceeds, or when a sufficient number of new investors cannot be found to allow the continued payment of ʺdividends.ʺ
2. Money Laundering. Money laundering, the metaphorical ʺcleaning of moneyʺ with regard to appearances in law, is the practice of engaging in specific financial transactions in order to conceal the identity, source, and⁄or destination of money, and is a main operation of the underground economy.
3. 419 Scams. ʺ419ʺ scam (aka ʺNigeria scamʺ or ʺWest Africanʺ scam) is a type of fraud named after an article of the Nigerian penal code under which it is prosecuted. It is also known as ʺAdvance Fee Fraudʺ. The scam format is to get the victim to send cash (or other items of value) upfront by promising them a large amount of money that they would receive later if they cooperate.

2.2.11 ILLEGAL PHARMACEUTICAL DISTRIBUTION

Distribution and promotion of drugs, locally within a nation or overseas, without prescription and appropriate licenses as required in the country of distribution are termed illegal.

2.2.12 OTHER VIOLATIONS

Other violations that will be expressly prohibited under the .Shop include
* Network attacks
* Violation of applicable laws, government rules and other usage policies

3. PROCEDURES TO MINIMIZE ABUSIVE REGISTRATIONS

3.1 BUILDING A ZERO-TOLERANCE REPUTATION

Our Anti-Abuse Policy will put Registrants on notice of the ways in which we will identify and respond to abuse and serve as a deterrent to those seeking to register and use domain names for abusive purposes. The policy will be made easily accessible on the Abuse page of our Registry website which will be accessible and have clear links from the home page along with FAQs and contact information for reporting abuse.

Directi has vast experience in minimizing abusive registrations. Our zero tolerance procedures and aggressive proactive takedown measures as a Domain Registrar have resulted in a white-hat reputation discouraging abusive registrations to begin with. We intend on following the same approach with respect to Registry operations for .Shop. Our proactive abuse procedures are geared towards building a reputation that discourages miscreants and malicious intent. Once it is known that abusive registrations and registrations in violation of our policies are suspended rapidly, both abusive registrations and abusive behavior will be discouraged.

Our Abuse policies described in section 2 above apply to new and ongoing registrations.

3.2 BUILDING AWARENESS OF OUR ANTI-ABUSE POLICY

The Abuse Policy will be published on the abuse page of our Registry website which will be accessible and have clear links from the home page. The abuse page of our Registry website will emphasise and evidence our commitment to combating abusive registrations by clearly identifying what our policy on abuse is and what effect our implementation of the policy may have on registrants. We anticipate that the clear message, which communicates our commitment to combating abusive registrations, will further serve to minimise abusive registrations in our TLD.

3.3 ICANN PRESCRIBED MEASURES

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

* DNSSEC deployment, which reduces the opportunity for pharming and other man-in-the-middle attacks. We will encourage registrars and Internet Service Providers to deploy DNSSEC capable resolvers in addition to encouraging DNS hosting providers to deploy DNSSEC in an easy to use manner in order to facilitate deployment by registrants. DNSSEC deployment is further discussed in the context of our response to Question 43;
* Prohibition on Wild Carding as required by section 2.2 of specification 6 of the Registry Agreement

* Removal of Orphan Glue records: ICANN requires a policy and procedure to take action to remove orphan glue records from the zone when provided with evidence that the glue is indeed present and aiding malicious conduct. The ARI Managed TLD Registry SRS database does not allow orphan records. Glue records are removed when the delegation point NS record is removed. Other domains that need the glue record for correct DNS operation may become unreachable or less reachable depending on their overall DNS service architecture. It is the Registrant’s responsibility to ensure that their domain name does not rely on a glue record that has been removed and that it is delegated to a valid name server. The removal of glue records upon removal of the delegation point NS record mitigates the potential for use of orphan glue records in an abusive manner

3.4 REGISTRANT DISQUALIFICATION

Abusive domain registration has historically attracted a small number of individuals and organisations that engage in high volume registrations, driven by the marginal profitability of individual abusive registrations. As specified in our Anti-Abuse Policy, we reserve the right to deny registration of a domain name to a Registrant who has repeatedly engaged in abusive behaviour in our TLD or any other TLD.

Registrants, their agents or affiliates found through the application of our Anti-Abuse Policy to have repeatedly engaged in abusive registration will be disqualified from maintaining any registrations or making future registrations. This will be triggered when our records indicate that a Registrant has had action taken against it an unusual number of times through the application of our Anti-Abuse Policy.

Registrant disqualification provides an additional disincentive for qualified registrants to maintain abusive registrations in that it puts at risk even otherwise non-abusive registrations through the possible loss of all registrations.

In addition, name servers that are found to be associated only with fraudulent registrations will be added to a local blacklist and any existing or new registration that uses such fraudulent NS record will be investigated.

The disqualification of ‘bad actors’ and the creation of blacklists mitigates the potential for abuse by preventing individuals known to partake in such behaviour from registering domain names.

3.5 PROACTIVE DETERMINATION OF POTENTIAL ABUSE

There are several tell-tale signs which are indicative of abusive intent. The following are examples of the data variables will serve as indicators that we will monitor with the help of our registry technical partner.

* Unusual Domain Name Registration Practices: practices such as registering hundreds of domains at a time, registering domains which are unusually long or complex or include an obvious series of numbers tied to a random word (abuse40, abuse50, abuse60) may when considered as a whole be indicative of abuse

* Domains or IP addresses identified as members of a Fast Flux Service Network (FFSN): Our service provider ARI uses the formula developed by the University of Mannheim and tested by participants of the Fast Flux PDP WG to determine members of this list. IP addresses appearing within identified FFSN domains, as either NS or A records shall be added to this list.

* An Unusual Number of Changes to the NS record: the use of fast-flux techniques to disguise the location of web sites or other Internet services, to avoid detection and mitigation efforts, or to host illegal activities is considered abusive in the TLD. Fast flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. As such an unusual number of changes to the NS record may be indicative of the use of fast-flux techniques given that there is little, if any, legitimate need to change the NS record for a domain name more than a few times a month.

* Results of Monthly Checks: The random monthly checks to promote Whois accuracy (described ahead) are not limited to serving that purpose but may also be used to identify abusive behaviour given the strong correlation between inaccurate Whois data and abuse.

* Analysis of Cross Validation of Registrant Whois data against Whois Data Known to be Fraudulent.

* Analysis of Domain Names belonging to Registrant subject to action under the Anti-Abuse policy: in cases where action is taken against a registrant through the application of our Anti-Abuse policy, we will also investigate other domain names by the same registrant (same name, nameserver IP address, email address, postal address etc).

4. PROCEDURES FOR HANDLING COMPLAINTS

4.1 MECHANISMS FOR REPORTING COMPLAINTS

In order to make it easy for security agencies, law enforcement bodies and vigilant users to report incidents of abusive behavior within .Shop, we shall enable several channels of communication.

4.1.1 SINGLE POINT OF CONTACT

In accordance with section 4.1 of specification 6 of the Registry Agreement we will establish a single abuse point of contact (SAPOC) responsible for addressing and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller. Complaints may be received from members of the general public, other registries, registrars, LEA (Law Enforcement Agencies), government and quasi governmental agencies and recognised members of the anti-abuse community.

The SAPOC’s accurate contact details (email, fax and mailing address) will be provided to ICANN and published on the abuse page of our Registry website. The SAPOC will in turn represent the entire compliance desk operated by the Directi group on behalf of .Shop as an outsourced function.

The Registry website will additionally also include:

* All public facing policies in relation to the TLD including the Anti-Abuse Policy described in section 2
* A web based submission service for reporting inaccuracies in Whois information
* Registrant Best Practices
* Conditions that apply to proxy registration services and direction to the SAPOC to report domain names that violate the conditions

As such, the SAPOC may receive complaints regarding a range of matters concerning the abuse policy defined in section 2

The SAPOC will be the primary method by which we will receive notification of abusive behaviour from third parties. It must be emphasised that the SAPOC will be the initial point of contact following which other processes will be triggered depending on the identity of the reporting organization and the type of abuse. Accordingly, separate processes for identifying abuse will exist for reports by LEA⁄government and quasi governmental agencies and members of the general public.

When any party makes a report via the Abuse POC e-mail address or the abuse web form, he or she will receive back a ticket number from a ticketing system. Our abuse team will then examine these reports, and use a ticketing system to track each issue. This process will leverage a dedicated software that we have used for handling abuse reports to our registrar businesses. It is our goal to provide a timely response to all abuse complaints concerning domains registered in the TLD, as per the SLAs defined by us.

4.1.2 LAW ENFORCEMENT AGENCIES

We recognise that LEA, governmental and quasi governmental agencies may be privy to information beyond the reach of others which may prove critical in the identification of abusive behaviour in our TLD. As such, we will provide an expedited process which serves as a channel of communication for law enforcement, government and quasi-governmental agencies to, amongst other things, report illegal conduct in connection with the use of the TLD.

The process will involve prioritization and prompt investigation of reports identifying abuse from those organizations. The steps in the expedited process are summarised as follows:

1. We will identify relevant LEA, government and quasi governmental agencies who may take part in the expedited process
2. We will establish back channel communication with each of the identified agencies in order to obtain information that may be used to verify the identity of the agency upon receipt of a report utilising the expedited process;
3. We will publish contact details on the abuse page of the Registry website for the SAPOC to be utilised by only those taking part in the expedited process;
4. All calls to this number will be responded to by a member of our 24⁄7 Compliance Team
5. We will verify the identity of the reporting agency employing methods specific to that agency established during back channel communication;
6. Upon verification of the reporting agency, we will obtain the details necessary to adequately investigate the report of abusive behaviour in the TLD;
7. Reports from verified agencies may be provided in the Incident Object Description Exchange Format (IODEF) as defined in RFC 5070. Provision of information in the IODEF will improve our ability to resolve complaints by simplifying collaboration and data sharing
8. The report identifying abuse will then be dealt with in accordance to our process defined in subsequent sections of this answer

4.2 EVALUATION OF COMPLAINTS

The next step is for our abuse desk staff to review each complaint. The abuse team looks at the facts of each complaint in order to verify the complaint. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants while at the same time, taking timely action to mitigate abusive behaviour and to minimize impact.

Evaluation of complaints thus forms a very important part of the process. The following factors are considered for each case:

* Type, Severity and immediacy of the abuse: Upon initial review, all incoming complaints will face an initial evaluation on the basis of severity and harm cased due to the abuse. While we will adhere to the SLAs laid down for our abuse mitigation processes, regardless of the type of complaint, there will be some complaints that will be considered relatively more severe and of greater malicious impact than others. Complaints with a higher severity⁄malicious impact and immediacy will be processed with greater urgency than others.

* Determining the origin of the complaint: a credible complainant e.g. a law enforcement agency, a security group etc. automatically lends genuineness to a complaint while a complaint from a previously unknown source will require a background check to ensure that the complaint is not from a miscreant looking to create unnecessary trouble for a domain owner. Thus while we may take immediate action complaints from reliable sources, those from other sources, not backed by enough evidence, may require further due-diligence before action is taken.

* Evaluating proof submitted along with a complaint: A complaint is also evaluated based on the supporting evidence provided which further determines the validity of a complaint. At this stage we will also attempt to establish a clear link between the activity reported and the alleged type of abusive behaviour. This is done to ensure that addressing the reported activity will address the abusive behaviour. In some cases the abuse is evident, which will result in immediate processing of the complaint from our side without much further due-diligence. In some cases, where the abuse may not be evident upfront, our desk will rely on supplementary evidence provided by the complainant which may be further ratified. While not limited to this list, supporting evidence could range from links, screen-shots of websites, copy right ⁄ trademark details, emails, email headers, whois information, ID proof etc.

* Evaluating historical data: As mentioned before, we will maintain a log of all complaints received, including the contact details of complainants, the whois details of the abusers, the nameservers of abusive domain registrations, the type of domain names, the IPs of spamming domains etc. This will further help us in establishing trends for further action as required. A registration that re-sounds alarms from previously seen abusive trends will ascertain the necessary pre-emptive mitigation processes.

Assessing abuse reports requires good judgment, and we will rely upon our, specially trained abuse desk staff.

While we recognise that each incident of abuse represents a unique security threat and should be mitigated accordingly, we also recognise that prompt action justified by objective criteria are key to ensuring that mitigation efforts are effective. With this in mind, we have categorised the actions that we may take in response to various types of abuse by reference to the severity and immediacy of harm. This categorisation will be applied to each validated report of abuse and actions will be taken accordingly. It must be emphasised that the actions to mitigate the identified type of abuse in the section⁄s below are merely intended to provide a rough guideline and may vary upon further investigation.

4.3 CATEGORIZATION OF COMPLAINTS

Each confirmed case of abuse is bucketed into one of the following categories

4.3.1 CATEGORY 1

Probable Severity or Immediacy of Harm - Low
Examples of types of abusive behaviour – Small Scale Spam, Whois Inaccuracy

Mitigation steps:

1. Preliminary Investigation
2. Delegate to Registrar
3. Monitor response time-frame vis-à-vis SLA
4. Take direct action in case of Registrar non-conformance.

4.3.2 CATEGORY 2

Probable Severity or Immediacy of Harm - Medium
Examples of types of abusive behaviour – Medium scale spam, inactive botnets and other forms of abuse which have a higher degree of impact than the ones bucketed as category 1, but still relatively limited in terms of potential damage.

Mitigation steps:

1. Preliminary Investigation
2. Delegate to Registrar
3. Monitor response time-frame vis-à-vis SLA
4. Take direct action in case of Registrar non-conformance.

4.3.3 CATEGORY 3

Probable Severity or Immediacy of Harm - High
Examples of types of abusive behaviour – Fast Flux Hosting, Phishing, Large scale hacking, Pharming, Botnet command and control, Child Pornography and all other cases deemed to carry a very high risk of large scale impact

Mitigation steps for Abuse policy violation:

1. Suspend domain name
2. Investigate
3. Restore or terminate domain name

4.4 MITIGATION OF COMPLAINTS

The mitigation steps for each category will now be described:

4.4.1 CATEGORY 1

Types of abusive behaviour that fall into this category include those that represent a low severity or immediacy of harm to registrants and internet users. These generally include behaviours that result in the dissemination of unsolicited information or the publication of illegitimate information. While undesirable, these activities do not generally present such an immediate threat as to justify suspension of the domain name in question. Each of these cases will be delegated down to the Registrar and the registrar’s performance, in terms of response and resolution rate, will be monitored and recorded by us. In case of non-conformance by the Registrar, we will take-over the issue.

We will also continually monitor the issue to track possible increases in the severity of harm. In case the threat level is above what was originally anticipated, we will escalate the issue to category two or three and act in accordance.

4.4.2 CATEGORY 2

Types of abusive behaviour that fall into this category include those that represent a medium severity or immediacy of harm to registrants and internet users. These generally include medium scale spam, network intrusion, inactive botnets etc. Following the notification of the existence of such behaviours, our compliance team will delegate the issue to registrars and invoke the more aggressive SLAs that apply to this category of risk.

As was the case with category 1, we will continue to monitor the registrar’s conformance with the SLAs and take direct action when necessary. We will also check for possible increases in risk levels and escalate the abuse category if required.

4.4.3 CATEGORY 3

Highly serious, sensitive and large scale issues like phishing, child pornography and large-scale botnet are considered to be a serious violation of the Anti-Abuse Policy owing to its fraudulent exploitation of consumer vulnerabilities, high level of risk and far-reaching consequences. Given the direct relationship between the uptime of these activities, and extent of harm caused, we recognise the urgency required to execute processes that handle these cases directly, without any delegation.
As soon as the abuse is substantiated, we will proceed to suspend the domain name pending further investigation to determine whether the domain name should be unsuspended or cancelled. Cancellation will result if upon further investigation, the behaviour is determined to be one of the types of abuse defined in the Anti Abuse Policy.

In some cases we may change the nameservers associated with the domain and⁄or use EPP prohibited statuses in appropriate combinations to restrict activity against the domain such as contact updates, deletes or transfers.

In the past we have modified Nameservers to sinkhole malicious domains, so research partners can measure botnets and monitor malware activity. We believe this to be an extremely effective mechanism which takes down large scale attacks from the source, and assists researchers to build processes and tools which prevent future attacks from the same source. Our team will follow the same process for domains belonging to our registry.

We have built special systems to suspend individual and bulk batches of domains. This will allow us to quickly take care of cases where criminals have obtained bulk batches of domain names. This will be of use if malware designers use generation algorithms to register domains.

Reactivation of the domain name will result where further investigation determines that abusive behaviour, as defined by the Anti Abuse Policy, does not exist and that the domain name is not causing any harm.

4.5 PROPOSED RESOLUTION METRICS AND SERVICE LEVEL AGREEMENTS

SLA RESPONSE CONSIDERATIONS FOR REPORTED ABUSE CASES

As described earlier, each abuse case and goes into one of three response categories depending on the severity and immediacy of the harm caused by the abuse. In the case of any failed SLA responses, the Registry reserves the right to act directly to suspend and⁄or lock the domains associated with a given abuse case. Additionally, highly serious, sensitive and large scale issues are ranked as category 3 and prioritized above all other cases.

Attachment ʹQ28_Abuse Mitigation SLAʹ, shows the flowchart and SLA response for each category of abuse complaint

4.5.1 CATEGORY 1

Some examples of abuses cases that will be categorized as 1 include:

* Low scale Spam
* Whois Inaccuracy
* Low scale Malware
* Any other abuse case deemed as low risk

RESPONSE SLA COMMITMENTS:

* Initial Registry Response to Complainant: 2 business days from the time of receipt of the complaint
* Registry Notification to Registrar: 2 business days from the time of receipt of the complaint
* Initial Response from Registrar: 3 business days from the time that the complaint notification is sent to the Registrar
* Update from Registrar as action taken or intended: 7 business days from the time that the complaint notification is sent to the Registrar
* Final Resolution: 15 business days from the time the issue was reported to us

4.5.2 CATEGORY 2

Some examples of abuses cases that will be categorized as 2 include:

* Medium scale Spam
* Confirmed but inactive botnet domains
* All other abuse cases deemed as medium scale

RESPONSE SLA COMMITMENTS:

* Initial Registry Response to Complainant: 2 business days from the time of receipt of the complaint
* Registry Notification to Registrar: 2 business days from the time of receipt of the complaint
* Initial Response from Registrar: 2 business days from the time that the complaint notification is sent to the Registrar by the Registry
* Update from Registrar as action taken or intended: 3 business days from the time that the complaint notification is sent to the Registrar by the Registry
* Final Resolution: 8 business days from the time of receipt of the complaint

4.5.3 CATEGORY 3

Some examples of abuses cases that will be categorized as 3 include:

* Confirmed Cases of child pornography
* Confirmed cases of Phishing
* Confirmed and active botnets domains
* Any other case deemed as large scale

RESPONSE SLA COMMITMENTS:

* Initial Registry Response to Complainant: 1 business day from the time of receipt of the complaint
* Registry time to direct takedown: 3 business days from the time of receipt of the complaint

4.6 FOLLOW-UP AND CAPTURE OF METRICS

The abuse staff will track each abuse complaint ticket to resolution. Our ticketing system allows us to capture many metrics. We will measure resolution times, and we can see what percentage of abuse reports could be confirmed. We will also capture how many domains were suspended, and we will break down statistics by registrar in the TLD. This will help us identify registrars that have regular problems, and we can work with them to systematically identify and act against bad actors.

4.7 CONTRACTUAL PROVISIONS

As the registry operator, we will use the Registry-Registrar Agreement (RRA) to establish the registry’s right to act against abusive registrations as described in the preceding sections. We will also use the contract to impose certain obligations on the registrars, and make some obligations binding on the registrants by obligating specific terms in the registrar-registrant contract. The contract will be a mandatory part of the Registrar accreditation process with the Registry. Production access to the Registry will not be granted until the contract is duly signed AND the registrar has provided copy of their Registry Registrant Agreement to demonstrate the inclusion of any required pass-through provisions. The registrar is also fully obligated to their accreditation contracts with ICANN (via the RAA) which includes elements such as the UDRP.

In general, the contracts will establish that the registry operator may reject a registration request, or can delete, revoke, update, suspend, cancel, or transfer a registration for violations of our anti-abuse policies. The terms in our proposed agreement will empower us to take necessary action including, but not limited to:

* Discretionary action against domain names that are not accompanied by complete and accurate information as required by ICANN Requirements and⁄or Registry Policies or where required information is not updated and⁄or corrected as required by ICANN Requirements and⁄or Registry Policies;

* Action as may be required to protect the integrity and stability of the Registry, its operations, and the TLD system;

* Action as may be required to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the Registry;

* Action as may be required to establish, assert, or defend the legal rights of the Registry or a third party or to avoid any civil or criminal liability on the part of the Registry and⁄or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;

* Action as may be required to correct mistakes made by the Registry or any Accredited Registrar in connection with a registration; or

* Enforcement of Registry policies and ICANN requirements; each as amended from time to time;

* Actions as otherwise provided in the Registry-Registrar Agreement and⁄or the Registry-Registrant Agreement.

Below are some additional points that we will look to cover in the RRA. These clauses will enable us to enforce some additional, proactive measures to curb and deter abuse:

* We will reserve the right to deny registration of a domain name to a registrant who has repeatedly engaged in abusive behaviour in our TLD or any other TLD.

* We will reserve the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.

* We may amend or otherwise modify this policy to keep abreast of changes in consensus policy or new and emerging types of abusive behaviour in the Internet.

* Relevant language that enforces Registrars to conform with the SLAs provided for abuse cases delegated to them and provides the Registry with rights to take relevant actions in those cases.

* Relevant language for sanctions against a Registrar leading to termination with respect to repeated offences and violations of their obligations with respect to abuse mitigation.

* Relevant language that requires Registrars to provide for the following in their agreement with the Registrants
** Whois accuracy provisions
** Acceptable content and usage policy
** Sunrise policy and submission to SDRP
** UDRP
** Rights granted to the Registrar and Registry to take necessary action wrt abuse prevention including sharing information with regulatory bodies and LEA and domain takedowns where appropriate
** Indemnification

All of the contracts above will be regularly reviewed (atleast once a year) based on the experience gained by the Registry during actual operation and any relevant changes required to mitigate abuse will be appropriately introduced in consultation with ICANN and the Registrars

4.8 ADDITIONAL MITIGATION MEASURES

Based on our experience of running a leading Registrar, we have also devised some powerful mechanisms which will prevent possible abuse, and quickly diffuse abusive domains. These mechanisms include:

4.8.1 PROFILING & BLACKLISTING

This process, currently in practice for our registrar businesses within the Directi Group, is used for gathering intelligence on known offenders. We maintain abuse ratios for each of the 1,000,000 plus registrants and 65,000 plus resellers who use Directi.

Experience has enabled us to use these ratios accurately to uncover registrants who are known and repeated offenders. Expert offenders rarely reuse the same registrant profile and often maintain a myriad number of profiles to mask their true identity. Through pattern mapping we try and group registrant profiles that we believe belong to the same operator.

The same process is followed at the reseller level too, to identify those resellers who are knowingly harboring offenders, or are themselves involved in abuse.
When a registrant profile is confirmed to be involved in organized abuse, including but not limited to cybersquatting, phishing, pharming etc., our immediate step is to suspend that customer’s control over his abusive domain portfolio. Our compliance team then carefully analyzes each domain name to identify those which are abusive and not already taken-down. The necessary action is undertaken to diffuse any ongoing abuse.

We plan to adopt the ‘Profiling and Blacklisting’ process within our registry operations. Since all of our compliance resources will be trained and experienced in running this process, its implementation into .Shop will be simple. Specifics of this policy and process, as it applies to our registry business, will be drawn out.

4.8.2 PROACTIVE QUALITY REVIEW

As a preventive safeguard against abusive domain registration, we follow a consistent review process for domain registrations on our registrar, where a sample of newly registered domain names are analyzed for potential abusive activity. Coupled with our profiling process (described above), it enables us to take proactive measures against domain names that are registered solely to perpetrate malicious activities such as phishing, or otherwise infringe on the rights of others. This helps us curb abusive activity before it can affect too many Internet users. We shall seek to implement similar safeguards for .Shop, and encourage registrars to incorporate this practice as part of their abuse mitigation processes.

4.9 INDUSTRY COLLABORATION AND INFORMATION SHARING

Upon obtaining Registry Accreditation, we will join the Registry Internet Safety Group (RISG), whose mission is to facilitate data exchange and promulgate best practices to address internet identity theft, especially phishing and malware distribution. In addition, Directi coordinates with the Anti-Phishing Working Group (APWG), other DNS abuse prevention organizations and is subscribed to the NXdomain mailing list.
Directi’s strong participation in the industry facilitates collaboration with relevant organizations on abuse related issues and ensures that Directi is responsive to new and emerging domain name abuses.

The information shared as a result of this industry participation will be used to identify domain names registered or used for abusive purposes. Information shared may include a list of registrants known to partake in abusive behavior in other TLDs. While presence on such lists will not directly constitute grounds for registrant disqualification, we will investigate domain names registered to those listed registrants and take appropriate action. In addition, information shared regarding practices indicative of abuse will facilitate detection of abuse by our own monitoring activities.

5. PROMOTING AND ENSURING WHOIS ACCURACY

All registrants shall be required, via required language in every Registrar – Registrant Agreement, to provide accurate Registrar Data Directory Services, RDDS (WHOIS) contact details, and to keep those details current. Additionally, Registrars shall have direct responsibility to ensure Whois accuracy through their accreditation contracts with ICANN. Whois Data Reminder Policy or WDRP is an example of a direct Registrar⁄ICANN contractual obligation to monitor that RDDS (WHOIS) information is accurate and up to date – it includes requiring Registrars to notify their registrants at least once a year to ensure their RDDS (WHOIS) data is correct and up to date.

The threat of inaccurate Whois information significantly hampers the ability to enforce policies in relation to abuse in the TLD by allowing the registrant to remain anonymous. In addition, LEA’s rely on the integrity and accuracy of Whois information in their investigative processes to identify and locate wrongdoers.

In recognition of this, we propose that .Shop have the following measures to promote RDDS (WHOIS) accuracy.

5.1 WHOIS INACCURACY REPORTING SYSTEM

On the abuse page of our Registry website, we will provide a web based submission service for reporting Whois accuracy issues. Each of these issues will then be resolved as per the process detailed in the previous sections.

5.2 REGULAR MONITORING & SAMPLING

Registrants of randomly selected domain names will be contacted by telephone using the provided Whois information by a member of our team in order to verify the phone number and confirm other Whois information. Where the registrant is not contactable by telephone, alternative contact details (email, postal address) will be used to contact the registrant who must then provide a contact number that is verified by our team. In the event that the registrant is not able to be contacted by any of the methods provided in Whois, the domain name will be cancelled following five contact attempts or one month after the initial contact attempt (based on the premise that a failure to respond is indicative of inaccurate Whois information and is grounds for terminating the registration agreement)

5.3 ANALYSIS OF REGISTRY DATA

We will adopt some processes to identify patterns and correlations indicative of inaccurate Whois (e.g. repetitive use of fraudulent details).

5.4 PROMOTING ACCURATE WHOIS DATA

WDRP (Whois Data Reminder Policy) implemented by ICANN at the Registrar level, mandates regular e-mail communication to registrants reminding them to keep their whois data accurate and updated. In addition, we will also identify effective mediums to remind registrants to update Whois information and inform them of the ramifications of a failure to respond to our random monthly checks. Ramifications include but are not limited to termination of the registration agreement.

5.5 ENFORCEMENT AT REGISTRAR LEVEL

Registrars will also be contractually required to promptly investigate reports of RDDS (WHOIS) accuracy submitted to them, and resolve each case within a predefined time-frame stipulated through our SLA.

For all cases where inaccuracy is confirmed, we will record the registrar from whom the domain was sourced. We will use this data to capture the ratio of inaccuracies as a percentage of total domains managed, and identify the registrars that seem to attract an abnormally high number of inaccuracy issues. We will then work with those registrars to find potential ways in which they can progressively reduce the number of whois inaccuracy incidents.

The measures to promote Whois accuracy described above strike a balance between the need to maintain the integrity of the Whois service, which facilitates the identification of those taking part in illegal or fraudulent behaviour, and the operating practices of the Registry Operator and Registrars which aim to offer domain names to registrants in an efficient and timely manner.

Awareness among registrants that we will actively take steps to maintain the accuracy of Whois information mitigates the potential for abuse in the TLD. It deters abusive behaviour given that registrants may be identified, located and held liable for all actions in relation to their domain name.

5.6 PROXY ⁄ PRIVACY PROTECTION

We have designed a policy that will maximize the legitimate use of proxy and privacy services, and will minimize use by criminals and abusers.

.Shop will allow the use of proxy and privacy services, where permitted by ICANN policies and requirements. These services have legitimate uses. Millions of registrants use them to protect their privacy and personal data from spammers and other parties that mine zone files and RDDS (WHOIS) data.

It is undeniable that criminals also use whois proxy services, to hide their true identities. To deter that practice, our policy will require that:

* Registrants must use only a privacy⁄proxy service operated, contracted or owned by the domain’s sponsoring registrar, and cannot use third-party proxy services unaffiliated with the domain’s sponsoring registrar. This means that a domain’s sponsoring registrar will always be in possession of the underlying contact data.

*. Registrars and resellers must provide the underlying registrant information to the registry operator upon request, and⁄or upon a legitimate law-enforcement request, within 24 hours. The registry operator will keep this data confidential, unless #3 below applies.

* Registrars and resellers must remove the proxy protection and publish the underlying registrant information in the RDDS (WHOIS) if it is determined by the registry operator and⁄or the registrar that the registrant has breached any terms of service, such as anti-abuse policies.

The registrar obligations outlined above shall apply with equal force to all registrations sponsored by a registrar, whether those registrations were placed directly with the registrar or through a reseller.

These conditions will be implemented contractually by inclusion of corresponding clauses in the RRA as well as being published on the abuse page of our Registry website. Individuals and organisations will be encouraged through our abuse page to report any domain names they believe violate the restriction on the availability of proxy registrations, following which appropriate action may be taken by us. Publication of these conditions on the abuse page of our Registry website ensures that registrants are aware that despite utilisation of a proxy registration service, actual Whois information will be provided to LEA upon request in order to hold registrants liable for all actions in relation to their domain name. The certainty of Whois disclosure of domain names which draw the attention of LEA, deters those seeking to register domain names for abusive purposes.

6. CONTROLS FOR PROPER ACCESS TO DOMAIN FUNCTIONS

We realize that registrants often do not willfully use their domain names for abusive purposes, but domain names end up being compromised because of a lapse in security. Though this cannot always be controlled or mitigated by the registry, we are nevertheless committed to ensure that adequate safeguards are implemented to prevent domain names from being compromised and thereby making them prone to abuse.

6.1 MULTI-FACTOR AUTHENTICATION AND SECURE CONNECTIVITY FOR REGISTRARS

Through the contractual agreement with the registry, registrars will be expected to develop and employ in their domain name registration business, all necessary technology and restrictions to ensure that their connection to the registry is secure. All data exchanged between the registrarʹs system and the registry shall be protected to avoid unintended disclosure of information. Each EPP session shall be authenticated and encrypted using two-way secure socket layer (ʺSSLʺ) protocol. Registrars will also agree to authenticate every EPP client connection with the registry using both an X.509 server certificate issued by a commercial Certification Authority identified by the registry and their registrar password, disclosed only to their respective employees on a need-to-know basis. Registrars will also access the SRS Web interface by utilizing an additional two-factor authentication token. Further details on this is provided in the response to Question 24 and 25

6.2 ENFORCEMENT OF STRONG AUTHCODES

Every domain name will have a strong authorization (authinfo) code, composed of alphabets, numerals, and special characters. An inter-registrar domain name transfer will not be permitted unless the registrant provides this authorization code at the time of executing the transfer process.

6.3 NOTIFICATION FOR EVERY UPDATE

We plan to notify the domain name holder upon any update made to a domain name. The notification will be committed through email to either or both of the registrant and technical contact of the domain name.

6.4 REGISTRY LOCK

Certain mission-critical domain names such as transactional sites, email systems and site supporting applications may warrant a higher level of security. ‘Registry locking’ is a feature which allows registrants to prohibit any updates at the Registry Operator level. This service will be available programmatically via EPP, so all registrars will be able to offer it in real-time to their registrants. The feature will prevent unintentional transfer, modification or deletion of the domain name, and mitigates the potential for abuse by prohibiting any unauthorised updates that may be associated with fraudulent behaviour. For example, an attacker may update name servers of a mission critical domain name, thereby redirecting customers to an illegitimate website without actually transferring control of the domain name. This is described in detail in our response to Question 27

6.5 AWARENESS PROGRAMS

In accordance with our commitment to operating a secure and reliable TLD, we will attempt to improve registrant awareness of the threats of domain name hijacking, registrant impersonation and fraud, and emphasize the need for registrants to keep registration information accurate and confidential. Awareness will be raised by:

* Publishing the necessary information on the Abuse page of our Registry website in the form of videos, presentations and FAQs;

* Developing and providing to registrants, resellers and Registrars Best Common Practices that describe appropriate use and assignment of domain auth info codes and risks of misuse when the uniqueness property of this domain name password is not preserved.

7. RESOURCING PLANS

7.1 PERSONNEL

Functions described herein will be performed by -
* Directi Group staff under contract with us -
** Abuse & Compliance Team
* Dispute Resolution Service Providers that are selected wrt UDRP and SDRP

Directi Group possesses an exemplary track record of diffusing abuse on 4 million plus domains under their Registrar. The abuse mitigation function of our Registry will be handled by the same team that currently manages this process for the registrar businesses.

The existing compliance team comprises of:
* 1 Compliance Manager
* 1 Team Supervisor
* 4 Cyber Security Analysts
* 9 Compliance Officers

The compliance function is staffed on a 24⁄7⁄365 basis and capable of handling up to a peak of 52,800 unique abuse incidents per year. Each incident by itself can relate to a few to hundreds of domain names.

While this team is trained to investigate and verify all types of issues, they can also fall back on support from our technical staff when required. Similarly, abuse cases following new or unexpected parameters may also be escalated to legal support staff for expert counsel.

Our estimates of resource sizing are directly derived from the abuse case incident volumes currently experienced. On a base of 4 million domains across our Registrar businesses within Directi, each year we experience approximately:

* 6000 malware related abuses
* 1600 phishing abuses
* 1200 spam cases
* 600 pharmacy related abuses
* 5600 large botnet related abuse cases annually

This averages an incident rate of approximately 15,000 cases of abuse per year or 3.75 incidents per 1000 names

Since registries delegate a large portion of their abuse responsibilities to registrars, it is fair to assume that our registry’s abuse incident ratio will be lower than what we experience as registrars. In fact, in our case 2⁄3 categories of incidents will be delegated to the registrar and our direct involvement is expected in only 25%-35% of all incidents. However, given our proactive approach, importance on ensuring a clean and secure namespace, and aggressive SLAs, we choose to be conservative by assuming that we will be involved in 75% of all incidents.

Based on our projections, we expect .Shop to reach 70,094 domain names at the end of the 3rd year. Extrapolating from our current rate of 3.75 incidents per 1000 names, we can expect around 263 abuse incidents yearly and be involved in 197 (75%) of them. Including the estimated 12 RPM incidents (details in our response to Q29), brings our total projected incident count to 209. This conservative estimate also accounts for the aggressive SLAs at multiple levels, law enforcement interfacing and having a single POC available at all times.

The Compliance desk works as a centralized team and all team members are responsible for all abuse complaints across all businesses of Directi. Costs of the Compliance team are then allocated to each business based on the % utilization of the compliance team by each business. We have assumed 25% of 2 compliance officers’ time towards .Shop. Given that our 15 people team has the capacity to handle 52,800 incidents yearly, 2 officers with 25% of their time, will have a total capacity to handle 1760 incidents annually. It is important to point out that 25% of the 2 officers is merely a cost allocation method and in actuality all 15 members and more of the Compliance team will be available to resolve abuse issues for TLD.

Our planning provides us redundant capacity of 14.5X in Y1, 10X in Y2 and 7X in Y3, to handle both abuse as well as RPM related cases such as those involving URS. This leaves substantial headroom for rapid growth of domains under management, or a sudden surge in abuse incident rates per domain.

It is also important to note that there exists some economies of scale in our operations since a large number of these cases are dealt with in bulk, or large batches, as they relate to the same instigator(s).

The abuse team has a structured training program in place which enables them to rapidly scale-up resources when required. Typically a team of recruits are given four weeks of training and two weeks on the floor before they are fully activated.

Given the rapid growth rate of Directi businesses, Directi will continue to hire and maintain a sizable buffer over and above anticipated growth.

7.2 FINANCIAL CONSIDERATIONS

The usage of Directi Group’s staff is included in our contract with Directi attached to Q46 (ʹQ46_References: Service and Facilities Commitment Agreementʹ). This cost is shown in the financial answers.

This completes our response to Q28.

DotShop Inc. is a wholly owned subsidiary within the Directi Group. The Directi Group runs various businesses including several ICANN Accredited Domain Registrars (including ResellerClub.com and BigRock.com) and Web Hosting companies. At Directi, through our decade long experience as a domain name registrar, we have consciously strived to ensure that domain registrations through our platform do not violate the intellectual property or other rights of any person or organization.

Our experience as a domain name registrar gives us insight into the necessity and importance of rights protection, and the mechanisms that must be employed to assure it. With .Shop, we shall leverage our experience to implement a comprehensive set of policies and procedures that will uphold intellectual property rights to the greatest possible extent.

The protection of trademark rights is a core goal of .Shop. .Shop will have a professional plan for rights protection. It will incorporate best practices of existing TLDs, going above and beyond the ICANN mandated RPMs to prevent abusive registrations and rapidly take-down abuse when it does occur.

1. PREVENT ABUSIVE REGISTRATIONS

We will put into place the following measures to ensure prevention of registrations that infringe the IP rights of others

1.2 SUNRISE PROCESS

Our sunrise registration service will provide trademark holders with atleast a 30-day priority period in which to register their trademarks as domain names.

Sunrise Timeline -
Day 1:Single sunrise round opens
Day 30:Sunrise round closes
Day 31:Sunrise allocation begins and Sunrise period ends

1.2.1 SUNRISE POLICY SUMMARY AND SDRP SUMMARY

This section provides a summary of our Sunrise Policy and SDRP. We have formulated our policies and processes based on existing guidance concerning Sunrise and TMCH provided by ICANN. Any additional guidance in the future that requires changes to our process and policies will be implemented.

Through our Sunrise Policy we will offer atleast one 30-day sunrise round in which trademark holders satisfying the Sunrise eligibility requirements proposed in the ‘gTLD Applicant Guidebook’ will be eligible to apply for a domain name. This sunrise period will be the first opportunity for registration of domain names in .Shop. Trademarks upon which sunrise applications are based must meet the criteria defined in the ‘gTLD Applicant Guidebook’ and be supported by an entry in the TMCH.

Sunrise allocation will start at the end of the 30-day sunrise period. If one validated application is received for a domain name, the same will be allocated to the applicant in the 10-day period following the end of the sunrise period. Where multiple validated applications are received for a domain name, the name will be allocated by auction. Domain names registered during the sunrise period will have a minimum term of 2 yrs.

We will adopt a Sunrise Dispute Resolution Policy (‘SDRP’) to allow any party to raise a challenge on the four grounds identified in the ‘gTLD Applicant Guidebook’. All registrants will be required to submit to proceedings under the SDRP. SDRP claims may be raised at any time after registration of a domain name.

1.2.2 IMPLEMENTATION

1.2.2.1 SUNRISE PRICING

We plan to charge a non-refundable Sunrise application fee or validation fee of $80 for every Sunrise application. We have arrived at the fee to offset the cost of the trademark validation and other administrative over-heads.

1.2.2.2 SUNRISE IMPLEMENTATION PLAN

1. Prior to sunrise, trademark holders should apply for inclusion of their marks in the TMCH database.
2. Our Sunrise Policy and SDRP will be published on our website.
3. A trademark holder satisfying the sunrise eligibility requirements will pay the non-refundable sunrise application fee and submit its application corresponding to its TMCH entry to a registrar along with evidence of the corresponding TMCH entry.
4. Registrars will send the sunrise applications to ARI. They will be charged the application fee at this time.
5. ARI will perform standard checks to ensure that the domain name is technically valid and hold the application for subsequent allocation.
6. Upon conclusion of the 30-day sunrise period, ARI will compile a list of applied-for names and reserve these from registration in land rush and general availability.
7. Sometime during this process ARI or the registrar (as prescribed) will identify all sunrise applications which constitute an ‘Identical Match’ (as defined in the ‘gTLD Applicant Guidebook’) with a TMCH entry and provide notice to the holders of the filing of a sunrise registration.
8. Where a single sunrise application exists for a particular domain name ARI will enable the sponsoring registrar to CREATE the domain name and we will charge the sunrise registration fee to the registrar.
9. Where multiple sunrise applications exist for a domain name, ARI will compile and communicate to a 3rd-party auction services provider appointed by us a list of competing applicants, who will be invited to participate in an auction for the domain name.
10. The auction services provider will facilitate the auction process and upon completion of the auction will notify all participants of the outcome and collect the auction payment from the winning participant.
11. Upon payment of the auction bid, the auction services provider will communicate to ARI the details of the winning auction participant and will submit the revenue collected to ARI.
ARI will validate the communication from the auction services provider and enable the sponsoring registrar to CREATE the domain name.

1.2.1.3 SDRP IMPLEMENTATION PLAN

When a domain is awarded and granted to a registrant, that domain will be available for lookup in the public WHOIS.

After a Sunrise name is awarded it will also remain under a “Sunrise Lock” status for at least 60 days. During this period the domain will not resolve and cannot be modified, transferred, or deleted by the sponsoring registrar. A domain name will be unlocked at the end of that lock period only if it is not the subject of a Sunrise Challenge. Challenged domains will remain locked until the dispute resolution provider has issued a decision, which the registry operator will promptly execute.

SDRP filings will be handled by an appropriate service provider as per ICANN guidance and policy.

1.2.1.4 IMPLEMENTATION THROUGH CONTRACTUAL RELATIONSHIPS

The following features of the Sunrise and SDRP implementation plans described above will be executed by the inclusion of corresponding clauses in our RRA, which will require inclusion in registrars’ Domain Name Registration Agreements:
* By making a sunrise application the applicant agrees to purchase the domain name if that name is allocated to the applicant.
* The sunrise application fee is non-refundable.
* All sunrise applicants must submit to proceedings under the SDRP.

1.3 TRADEMARK CLAIMS SERVICE

For atleast 60 days during general availability we will offer the trademark claims service as described in the ‘gTLD Application Guidebook’.

1.3.1 IMPLEMENTATION

1.3.1.1 TRADEMARK CLAIMS SERVICE IMPLEMENTATION PLAN
This process will be executed for atleast the first 60 days of general availability:
1. an applicant will make an application to a registrar for a domain name.
2. Registrars will be required to communicate land rush application information to our registry backend provider - ARI.
3. ARI or Registrars (as prescribed) will interface with the TMCH to determine whether an applied-for domain name constitutes an ‘Identical Match’ with a trademark in the TMCH. If an ‘Identical Match’ is identified, the registrar will provide to the land rush applicant a Trademark Claims Notice in the form prescribed by the ‘gTLD Applicant Guidebook’. Following receipt of this notice a land rush applicant must communicate to the registrar its decision either to proceed with or abandon the registration.
4. ARI or Registrar (as prescribed) will interface with the TMCH to promptly notify relevant mark holders of the registration of a domain name constituting an ‘Identical Match’ to their TMCH entry.

1.3.1.2 IMPLEMENTATION THROUGH CONTRACTUAL RELATIONSHIPS

The following features of our Trademark Claims Service Implementation Plan described above will be executed by the inclusion of corresponding clauses in our RRA:
* Registrars must comply with the TMCH as required by ICANN and the TMCH Service Provider⁄s.
* Registrars must not in their provision of the trademark claims service make use of any other trademark information aggregation, notification or validation service other than the TMCH.
* In order to prevent a chilling effect on registration, registrars must ensure that land rush applicants are not prevented from registering domain names considered an ‘Identical Match’ with a mark in the TMCH.
* Registrars must provide clear notice in the specific form provided by the ‘gTLD Applicant Guidebook’ to the prospective registrant of relevant entries in the TMCH.
* Registrars must interface with the TMCH as prescribed to relevant mark holders of the registration of a domain name constituting an ‘Identical Match’ to their TMCH entry.

2. ONGOING RIGHTS PROTECTION AND ABUSE PREVENTION

Below we describe ongoing RPMs which we will implement to mitigate cybersquatting and other types of abusive behaviour such as phishing and pharming.

2.1 UNIFORM RAPID SUSPENSION (URS)

The URS (Uniform Rapid Suspension) procedure is a new RPM the implementation of which is mandated in all new gTLDs. Understanding that a fundamental aim of the URS is expediency, all of the steps in our Implementation Plan below will be undertaken as soon as practical but without compromising security or accuracy.

2.1.1 IMPLEMENTATION

2.1.1.1 URS IMPLEMENTATION PLAN

1. We will provide to each URS provider an email address to which URS-related correspondence can be sent. On an ongoing basis, our compliance desk will monitor this email address for receipt of communications from URS providers, including the Notice of Complaint, Notice of Default, URS Determination, Notice of Appeal and Appeal Panel Findings.
2. We will validate correspondence from a URS provider to ensure that it originates from the URS Provider.
3. We will within 24 hours of receipt of a URS Notice of Complaint lock the domain name⁄s the subject of that complaint by restricting all changes to the registration data, including transfer and deletion of the domain name. The domain name will continue to resolve while in this locked status.
4. We will immediately notify the URS provider in the manner requested by the URS provider once the domain name⁄s have been locked.
5. Upon receipt of a favourable URS Determination we will unlock the domain name and redirect the nameservers to an informational web page provided by the URS provider. While a domain name is locked, our backend provider - ARI - will continue to display all of the WHOIS information of the original registrant except for the redirection of the nameservers and the additional statement that the domain name will not be able to be transferred, deleted or modified for the life of the registration.
6. Upon receipt of notification from the URS provider of termination of a URS proceeding we will promptly unlock the domain name and return full control to the registrant.
7. Where a default has occurred (because a registrant has not submitted an answer to a URS complaint in accordance with the ‘gTLD Applicant Guidebook’) and a Determination has been made in favour of the complainant, in the event that we receive notice from a URS provider that a Response has been filed in accordance with the ‘gTLD Applicant Guidebook’, we will as soon as practical restore a domain name to resolve to the original IP address while preserving the domain’s locked status until a Determination from de novo review is notified to us.
8. We will ensure that no changes are made to the resolution of a registration the subject of a successful URS Determination until expiry of the registration or the additional registration year unless otherwise instructed by a UDRP provider.
9. We will make available to successful URS complainants an optional extension of the registration period for one additional year.

2.1.1.2 IMPLEMENTATION OF THE URS THROUGH CONTRACTUAL RELATIONSHIPS

The following features of our URS Implementation Plan described above will be executed by the inclusion of corresponding clauses in our RRA:

* In the event that a Registrant does not submit an answer to a URS complaint in accordance with the ‘gTLD Applicant Guidebook’, registrars must prevent registrants from making changes to the WHOIS information of a registration while it is in URS default.
* Registrars must prevent changes to a domain name when a domain is in locked status to ensure that both the Registrar’s systems and Registry’s systems contain the same information for the locked domain name.
* Registrars must not take any action relating to a URS proceeding except as in accordance with a validated communication from us or a URS provider.

2.2 UDRP

The UDRP (Uniform Domain Name Dispute Resolution Policy) is applicable to domain name registrations in all new gTLDs. It is available to parties with rights in valid and enforceable trade or service marks and is actionable on proof of all of the following three grounds:
1. The registrant’s domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights.
2. The registrant has no rights or legitimate interests in respect of the domain name.
3. The registrant’s domain name has been registered and is being used in bad faith.

The remedies offered by the UDRP are cancellation of a domain name or transfer of a domain name registration to a successful UDRP claimant.

2.2.1 IMPLEMENTATION

2.2.1.1 UDRP IMPLEMENTATION PLAN

We have two responsibilities in order to facilitate registrars’ implementation of the UDRP -
1. Our backend provider – ARI - will maintain awareness of UDRP requirements and be capable of taking action when required and sufficiently skilled and flexible to respond to any changes to UDRP policy arising from future consensus policy reviews.
2. We will provide EPP and the SRS web interfaces to enable registrars to perform required UDRP functions in accordance with the Policy on Transfer of Registrations between Registrars.

2.2.1.2 IMPLEMENTATION OF THE UDRP THROUGH CONTRACTUAL RELATIONSHIPS

The UDRP is applicable to domain name registrations in all new gTLDs by force of a contractual obligation on Registry Operators to use only ICANN-accredited registrars, who in turn are contractually required to incorporate the UDRP in their Domain Name Registration Agreements.

3. ADDITIONAL RIGHTS PROTECTION MECHANISMS

The protection of trademark rights is a core goal of .Shop. Our Right Protection Mechanisms, policies and procedures go significantly above and beyond the minimum mandated RPMs to prevent abusive registrations, rapidly take-down abuse when it occurs, and foster a clean namespace for .Shop

This section describes several other RPMs that .Shop will implement that exceed the minimum requirements for RPMs and align with our goal of creating a namespace that provides maximum protection to trademark holders.

3.1 OPTIONAL TRADEMARK DECLARATION

This is a unique feature of our .Shop. During General Availability, we will continue to make available, the EPP Trademark extension fields that are provided during sunrise. Registrants will be able to specify their IPR details against their domain names even after sunrise. The fields will include – word mark, registration number, applied date, registration date, jurisdiction, class. These fields will be editable by the Registrant and visible in Whois.

The ability for a Registrant to voluntarily declare Trademark data even during general availability will reduce potential confusion amongst mark holders and the general public and reduce unnecessary UDRP procedures.

3.2 PROFILING & BLACKLISTING

3.3 PROACTIVE DOMAIN QUALITY ASSURANCE

3.4 INDUSTRY COLLABORATION

3.4.1 ACTIVE INVOLVEMENT WITH SECURITY AGENCIES

In order to mitigate abuse of domain names on our registrar business, our abuse team has active involvement in helping security vendors and researchers fight domain abuse. They provide us a constant feed of abuse instances and help us identify domain names involved in activities like phishing or pharming. Some of the prominent organizations we work with include PhishLabs (phishing), LegitScript (illegal pharmaceutical distribution), Artists Against 419 (financial scams), Knujon (spam) etc. We will leverage these relationships to ensure oversight for all domain names registered within .Shop.

3.4.2 APWG REVIEW

Every six months, the Anti-Phishing Working Group (APWG) publishes its latest Global Phishing Survey [See http:⁄⁄www.apwg.org⁄resources.html#apwg]. This study contains an analysis of phishing per TLD. We will review the performance of our anti-abuse program against the APWG reports, and other metrics created by the security community. We will work closely with APWG to combat phishing within .Shop

3.4.3. MESSAGE OF ZERO TOLERANCE

The Directi Group has vast experience in minimizing abusive registrations. Our zero tolerance procedures and aggressive proactive takedown measures as a Domain Registrar have resulted in a white-hat reputation discouraging abusive registrations to begin with. We intend on following the same approach with respect to Registry operations for .Shop. Our proactive abuse procedures are geared towards building a reputation that discourages miscreants and malicious intent. Once it is known that abusive registrations and registrations in violation of our policies are suspended rapidly, this will directly result in discouraging abusive registrations and creating a clean namespace. While following this path will mean a higher compliance and abuse vigilance cost for us, we believe this effort will pay us long term rewards through abusers keeping away and .Shop becoming recognized as a reputable namespace.

4. REDUCING PHISHING AND PHARMING

All of the measures we have described in the preceding sections significantly reduce phishing and pharming within .Shop. These include RPMs like URS and UDRP.

Over and above this our coordination with APWG, Industry Collaboration, Profiling and Blacklisting processes and Proactive measures described in Section 3 above will go a long way in ensuring a clean namespace for .Shop and considerably reduced phishing and pharming activities.

5. PREVENTING TRADEMARK INFRINGEMENT IN OPERATING THE REGISTRY

We take seriously our responsibilities in running a registry and we understand that while offering a sunrise registration service and the trademark claims service during start-up of our TLD and the URS and UDRP on an ongoing basis serves to minimise abuse by others, this does not necessarily serve to minimise trademark infringement in our operation of the TLD. This responsibility is now clearly expressed and imposed upon registries through the new Trademark PDDRP [Post-Delegation Dispute Resolution Procedure], which targets infringement arising from the Registry Operator’s manner of operation or use of its TLD.

Whilst we will as required under the Registry Agreement agree to participate in all Trademark PDDRP procedures and be bound by the resulting determinations, we will also have in place procedures to identify and address potential conflicts before they escalate to the stage of a Trademark PDDRP claim.

5.1 IMPLEMENTATION

1. We will notify to the Trademark PDDRP provider⁄s contact details to which communications regarding the Trademark PDDRP can be sent.
2. We will publish our Anti-Abuse Policy on a website specifically dedicated to abuse handling in our TLD.
3. Using the single abuse point of contact discussed in detail in our response to Q28, a complainant can notify us of its belief that that one or more of its marks have been infringed and harm caused by our manner of operation or use of our TLD
4. We will receive complaints submitted through the single abuse point of contact.
5. The Compliance Team will acknowledge receipt of the complaint and commence investigation of the subject matter of the complaint and good faith negotiations with the complainant in accordance with the ‘gTLD Applicant Guidebook’.
6. On an ongoing basis, our Compliance Team will monitor the email address notified to the Trademark PDDRP provider⁄s for all communications from the Trademark PDDRP provider, including the threshold determination, Trademark PDDRP complaint, complainant’s reply, notice of default, expert panel determinations, notice of appeal and determinations of an appeal panel.
7. In the event that a complaint cannot be resolved and a Trademark PDDRP claim is made, we will do the following:

* File a response to the complaint in accordance with Trademark PDDRP policy section 10 (thus avoiding, whenever possible, a default situation).
* Where appropriate, make and communicate to the Trademark PDDRP provider decisions regarding the Trademark PDDRP proceeding, including whether to request a three-person Trademark PDDRP Expert Panel, request discovery, request and attend a hearing, request a de novo appeal, challenge an ICANN-imposed Trademark PDDRP remedy, initiate dispute resolution under the Registry Agreement, or commence litigation in the event of a dispute arising under the Trademark PDDRP.
* Where appropriate, undertake discovery in compliance with Trademark PDDRP policy section 15, attend hearings raised under section 16 if required, and gather evidence in compliance with sections 20.5 and 20.6.
8. We will upon notification of an Expert Panel finding in favour of the Claimant (Trademark PDDRP policy section 14.3), reimburse the Trademark PDDRP Claimant.
9. We will implement any remedial measures recommended by the expert panel pursuant to Trademark PDDRP policy and take all steps necessary to cure violations found by the expert panel and notified by ICANN.

6. RESOURCING PLANS

6.1 PERSONNEL

Functions described herein will be performed by:

* Directi Group Abuse and Compliance team under contract with us -
** Overseeing Sunrise process
** URS
** Abuse complaints concerning RPM

* ARI’s backend Registry
* Service Providers that are selected wrt TMCH, UDRP, URS and SDRP

* Director of Technology at .Shop & Account Management staff at .Shop
** Overseeing Sunrise process
** Communication of the sunrise process to Registrars

Directi Group possesses an exemplary track record of diffusing abuse on 4 million plus domains under their Registrar business. The Rights protection and abuse mitigation function of our Registry will be handled by the same team that currently manages this process for the registrar businesses.

The existing compliance team comprises of:

* 1 Compliance Manager
* 1 Team Supervisor
* 4 Cyber Security Analysts
* 9 Compliance Officers

Our estimates of resource sizing are directly derived from the abuse case incident volumes currently experienced. On a base of 4 million domains as a Registrar, we experience approximately the following incidents per year:
* UDRP Cases - 200
* Other RPM incidents - 20 cases

This averages an incident rate of approximately 220 cases of abuse per year or 0.055 incidents per 1000 names. Given that this is based on a more mature base of names, it would be prudent to assume a higher rate of activity for .Shop. Based on our experience we have assumed the increase in activity rate to be three fold (300% of the current rate) and increase it to 0.165 per 1000 names.

Based on our projections, we expect .Shop to reach 70,094 domain names at the end of the third year. Extrapolating from our estimated rate of 0.165 incidents per 1000 names, we can expect around 12 incidents yearly. Including the estimated 197 Abuse incidents that the registry will handle (details in our response to Q28), brings our total projected incident count to 209.

The Compliance desk works as a centralized team and all team members are responsible for all abuse complaints across all businesses of Directi. Costs of the Compliance team are then allocated to each business based on the % utilization of the compliance team by each business. We have assumed 25% of 2 compliance officers’ time towards .Shop. Given that our 15 people team has the capacity to handle 52,800 incidents yearly, 2 officers with 25% of their time, will have a total capacity to handle 1760 incidents annually which is more than adequate for the Registry. It is important to point out that 25% of the 2 officers is merely a cost allocation method and in actuality all 15 members and more of the Compliance team will be available to resolve abuse issues for TLD.

It is also important to note that there exist some economies of scale in our operations since a large number of these cases are dealt with in bulk, or large batches, as they relate to the same instigator(s).

The Abuse and Compliance team has a structured training program in place which enables them to rapidly scale-up resources when required. Typically a team of recruits are given four weeks of training and two weeks on the floor before they are fully activated.

Given our rapid growth rate and business expansion plans, we will continue to hire and maintain a sizable buffer over and above anticipated growth.

6.2 FINANCIAL COSTS

The usage of Directi Group’s staff is included in our contract with Directi attached to Q46. This cost is shown in the financial answers.

This completes our response to Q29.

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

1. SECURITY POLICY SUMMARY

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

1.1 THE ISMS

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

1.2 SECURITY PROCESSES

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

1.2.1 CHANGE MANAGEMENT

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

1.2.2 INCIDENT MANAGEMENT

This includes incident management process and its sub-process for unplanned outages.

These outline:
* How incidents are managed through escalation points, recording requirements, communication requirements etc.
* The unplanned outage procedure which applies directly to situations where the registry itself or other critical services are unexpectedly offline.

1.2.3 PROBLEM MANAGEMENT

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

1.2.4 SECURITY INCIDENT MANAGEMENT

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

1.2.5 ACCESS MANAGEMENT

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

2. ARI’s SECURITY INFRASTRUCTURE SOLUTIONS

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

2.1 PHYSICAL SECURITY INFRASTRUCTURE

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

3. COMMITMENTS TO REGISTRANTS

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

4. AUGMENTED LEVEL OF SECURITY

This TLD is a generic TLD and as such requires security considerations that are commensurate with its purpose. Our goal with this TLD is to provide registrants with adequate protections against unauthorized changes to their names, without making the registration process too onerous and thus increasing costs.
The following attributes describe the security with respect to the TLD:
* ARI, follows the highest security standards with respect to its Registry Operations. ARI is ISO 27001 certified and has been in the business of providing a Registry backend for 10 years. ARI have confirmed their adherence to all of the security standards as described in this application.
* Registrant will only be permitted to make changes to their domain name after a authenticating to their Registrar.
* Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
* Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
* Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
* Registrars will only be permitted to use a certificate signed by ARI to connect with the Registry systems. Self-signed certificates will not be permitted.
* The Registry is DNSSEC enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to question 43.
* Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication. This is described in detail in our responses to Question 24 and Question 25.
Where these requirements put controls on Registrars these will be enforced through the RRA.

5. RESOURCES

This function will be performed by ARI. The following resources are allocated to performing the tasks required to deliver the services described:
* Executive Management Team (4 staff)
* Production Support Group (27 staff)
ARI has ten years’ experience designing, developing, deploying, securing and operating critical Registry systems, as well as TLD consulting and technology leadership.
As a technology company, ARI’s senior management are technology and methodology leaders in their respective fields who ensure the organization maintains a focus on technical excellence and hiring, training and staff management.
Executive Management are heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
* Chief Operations Officer
* Chief Technology Officer
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q30a – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.

ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.

Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 70,094 domains, 0.14% of these resources are allocated to this TLD. See attachment ‘Q30a – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.

The Production Support Group is responsible for the deployment and operation of TLD registries.

ARI employs a rigorous hiring process and screening (Police background checks for technical staff and Australian Federal Government ‘Protected’ level security clearances for registry operations staff).

This completes our response to Q30(a).

Brijesh Joshi	Director & GM
Vishal Manjalani	Director & VP

Bhavin Turakhia	Founder
Brijesh Joshi	Director & GM
Namit Merchant	GM
Vishal Manjalani	Director & VP

New gTLD Application Submitted to ICANN by: DotShop Inc.

String: shop

Originally Posted: 13 June 2012

Application ID: 1-1051-32260

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.