Name	Position
Brijesh Joshi	Director & GM

Name	Position
Bhavin Turakhia	Founder
Brijesh Joshi	Director & GM
Namit Merchant	General Manager
Vishal Manjalani	Director & VP

Name	Position
Radix FZC	Not Applicable

Name	Position
Radix FZC	Not Applicable

GOAL OF .tech

1.1 SPECIALTY

* Our goal for .tech in terms of area of specialty is to be the preferred choice of generic TLD where businesses that have an online presence can post news for easy access and consumption by their stakeholders

* As mentioned in Answer 18 (a), the .tech registry also aims to benefit registrants and users by offering better search efficiency, easier access and better differentiation

1.2 SERVICE LEVELS

Our goal for .tech 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 CentralNic to deliver services for this TLD. CentralNic provides registry services for a number of TLDs including the .LA and .PW ccTLDs.

Our contract with CENTRALNIC 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 meet or exceed the ICANN required SLA on every parameter. .

Our response to Q34 and Q35 provides details on CentralNic's DNS system. This system has operated at 100% service availability since 1996 and has been developed into a secure and stable platform for domain resolution. Partnering with Community DNS, CentralNic’s DNS system includes nameservers in more than forty cities, on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.

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 .tech 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 .tech 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 string is self-explanatory and users will expect to find news information and news content related to the business on CompanyName.tech.

By offering more and better choice of names, we will also aspire to be the primary choice gTLD for News companies looking for a global online presence.

Lastly .tech 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. Our intent is to operate .tech with a focus on integrity and quality for the .tech 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

.tech considers both its Registrants and the end-users that access .tech 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 .tech.

Registrants of .tech 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 .tech 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 –

* We have an elaborate and detailed Accepted usage and content policy that covers over 11 macro forms of violations
* .tech 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 TLD by providing them with special interfaces 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 .tech. .tech 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 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 .tech 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.tech, registry.tech, and www.tech), 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.tech, ietf.tech, w3c.tech, 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

.tech 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) 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

* .tech 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.

* .tech 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 outreach efforts will thus be directed towards our target market in coordination with Registrar partners, to ensure greater adoption of the .tech TLD. One important method of outreach will involve co-marketing programs these Registrar partners.
* We will emphasize distribution channels internationally – not just in one or more focused regions.

* 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 generating awareness of our Registration policies, Acceptable usage and content policies, Abuse mitigation processes and Rights protection mechanisms.

This completes our response to Q18(b).

.tech considers both its Registrants and the end-users that access .tech 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 .tech. To that extent it is our goal to –

* Reduce ⁄ minimize any incremental costs ⁄ negative consequences imposed upon our users
* Increase ⁄ maximize the value added to our Registrants and end-users
* Ensure that the net effect of .tech on its users is that of positive value creation

In this response we explore how .tech achieves a net benefit for Registrants and End-users.

1. MINIMIZING COSTS

1.1 REGISTRANTS

It is our goal to provide Registrants of .tech incremental value and minimize any negative consequences and costs associated with .tech. We address this in the following manner

1.1.1 SUNRISE, TMCH, RPMs

Rights protection is a core goal of .tech. Our Right Protection mechanisms go significantly above and beyond the mandatory RPMs ensuring protection of trademark and IP rights of domain registrants and reducing the costs associated with rights protection for Registrants. Our elaborate RPMs are described in significant detail in our response to Q29. Some salient aspects of these are as follows -

* We offer a sunrise period to provide an opportunity for legitimate Registrants to block domain names in .tech before general availability begins, preventing unnecessary post-facto litigation

* We will integrate with the Trademark Clearing House in the manner prescribed to provide the Trademarks claims service, so as to alert potential Registrants of any trademark violations prior to registration, as well as notify mark holders of potential mark violations

* We will provide SDRP, URS, UDRP and PDDRP reducing litigation costs by providing legitimate Registrants the opportunity to resolve disputes through standardized arbitration proceedings.

* Additionally we have pioneering RPMs like Profiling and Blacklisting, Proactive Quality assurance, APWG review etc – all intended to reduce rights violations and hence reduce costs for Registrants

The above salient points barely scratch the surface in detailing the steps that .tech will take in order to reduce costs of Registrants with respect to rights violations. Significant details of all of the above and more are provided in our responses to Q26, Q27, Q28 and Q29.

1.1.2 MULTIPLE APPLICATIONS FOR A DOMAIN

All of the RPMs described in section 1.1.1 above ensure that applicants for domain names in .tech are legitimate right holders for the applied string.

During general availability domain names will be allocated on a first come first serve basis amongst applicants. During the initial registry launch periods of Sunrise and Landrush if multiple applications for the same domain name are received from applicants then the same will be distributed in the following manner –

* Incase of multiple sunrise applications for the same domain name, all applications will be validated against the TMCH for a valid trademark. Applications that do not qualify will be dropped.

* All remaining applications will be distributed through a fair auction.

1.1.3 COST BENEFITS FOR REGISTRANTS

The ICANN new gTLD program marks a historical event in the timeline of the Internet. It is an unprecedented event and one that will yield tremendous benefits for consumers. At this preliminary stage it is impossible to determine the true value consumers will derive from increase in competition and choice. However there is historical data to go by. Upon the launch of Domain Registrars and creation of competition amongst registrars, the Registrants benefited from reduced pricing.

With .tech our goal is to provide fair pricing for domains within .tech that reflect the value proposition derived by the Registrants of .tech. While we do not have any committed pricing plans as yet and the same will be determined during the launch process, we do anticipate providing promotional offers through the life of .tech for the purpose of customer acquisition. This is not too dissimilar from other gTLD registries currently in existence who offer ongoing promotional offers to their customer base.

1.1.4 PRICE ESCALATIONS

The ICANN new gTLD program is an unprecedented event and the actual nature of pricing pressures will only be determinable once several TLDs have successfully launched. At this preliminary stage it is impossible to commit to any pricing strategy on our part. We strongly believe that ultimately, the open market will determine the viability of pricing models and dictate pricing strategy for everyone. We intend to maintain the freedom to set pricing to accommodate for the existence of 100s of TLDs and business models and create a sustainable long term business model. Our goal is to provide fair pricing for domains within .tech that reflect the value proposition derived by the Registrants of .tech.

1.2 END USERS

It is our goal to provide end users of .tech incremental value and minimize any negative consequences and costs associated with .tech. We address this in the following manner

End-users bear a considerable amount of cost as a result of various forms of Internet abuse such as spam, malware, phishing, pharming, hacking, identity theft etc. Any TLD that implements policies and processes to create a clean namespace will result in a considerable reduction of these forms of abuse and hence a significant saving in terms of cost to consumers

.tech intends to set an example when it comes to abuse mitigation and preventing abuse within .tech. 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. These are detailed in our response to Q28. We strongly believe these practices will result in a significant reduction in online abuse and considerable savings for end users of .tech. We similarly hope to set an example for other TLDs and cooperate with the industry in creating a clean internet experience for internet users.

2. COST BENEFIT ANALYSIS

There has been considerable debate within the community concerning the cost benefit analysis of launching new gTLDs. We strongly believe that the launch of new gTLDs and our implementation of .tech will and add considerable value and result in a net positive effect on Registrants and end-users worldwide.

We recognize that there will be a post launch review of the New gTLD Program, from the perspective of assessing the relative costs and benefits achieved in the expanded gTLD space.

To this extent we would like to offer the following pointers concerning .tech as well as the general expansion of the new gTLD space in determining the net positive value generated for Registrants and end users –

* .tech will reduce overall cost for end-users in combating fraud and other forms of online abuse by implementing pioneering processes and anti-abuse policies as described in our response to Q28. Billions of dollars are spent worldwide combating various forms of fraud such as malware, phishing, spamming etc. Our abuse policies will result in overall reduction of these forms of abuses within .tech resulting in a considerable reduction in global costs spent towards combating these abuses. We also strongly believe that introduction of new gTLDs will result in increased competition which will drive significant innovation as well as competitive pressures for everyone in the industry to improve their abuse mitigation processes resulting in overall cost reduction for end-users

* The value of a Registrant getting the name they want is immeasurably larger than any costs resulting from expansion of the namespace. Our stats show that 70% of the users who check for a .com domain name do not get their desired name. Until this launch of the new gTLD program there were very limited alternatives and none very viable⁄desirable for Registrants to choose from. .tech will expand the namespace thus providing a higher probability for new Registrants to obtain names they desire

* In general increased competition always results in pricing benefits for Registrants. .tech will provide additional options to new Registrants resulting in overall benefits to Registrants

* By virtue of registering a domain name within .tech a Registrant presents their URL as a direct web destination at which customers can engage and interact with their brand⁄business in real time. This adds considerable value in terms of searchability, SEO, creating trust, branding and a sense of belonging. As of now the only mechanism that exists for users to find a specific website are search engines. Search engines however do not classify the results in any manner to make it easier for users to determine which links are relevant to them with respect to their current search. .tech enables Registrants to standout amongst search results and allow end users to directly co-relate as to whether a search result will likely be what they are looking for. This adds considerable value to Registrants who can categorize their news related content, and to end-users who will take lesser time to find news related to businesses of interest.

This completes our response to Q18(c).

We have engaged CentralNic to deliver services for this TLD. This response describes protection of geographic names as implemented by CentralNic.

1. PROTECTION OF GEOGRAPHIC NAMES

In accordance with Specification 5 of the New gTLD Registry Agreement, we will initially reserve all geographic names at the second level, and at all other levels within the TLD at which the registry operator provides for registrations.

CentralNic supports this requirement by using the following internationally recognised lists to develop a comprehensive master list of all geographic names that are initially reserved:

– The 2-letter alpha-2 code of all country and territory names contained on the ISO 3166-1 list, including all reserved and unassigned codes [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm].

– The short form (in English) of all country and territory names contained on the ISO 3166-1 list, including the European Union, which is exceptionally reserved on the ISO 3166-1 List, and its scope extended in August 1999 to any application needing to represent the name European Union [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU].

– The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardisation of Geographical Names, Part III Names of Countries of the World. This lists the names of 193 independent States generally recognised by the international community in the language or languages used in an official capacity within each country and is current as of August 2006[http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn⁄docs⁄pubs⁄UNGEGN%20tech%20ref%20manual_m87_combined.pdf].

– The list of UN member states in six official UN languages prepared by the Working Group on Country Names of the United Nations Conference on the standardisation of Geographical Names [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄UNGEGN⁄docs⁄9th-uncsgn-docs⁄econf⁄9th_UNCSGN_e-conf-98-89-add1.pdf].

Names on this reserved list in CentralNic’s registry system are prevented from registration.

A corresponding list of geographic names will also be available to the public via our website, to inform Registrars and potential registrants of reserved names. The lists noted above, are regularly monitored for revisions, therefore the reserved list (both within the registry and publicly facing) will be continually updated to reflect any changes.

In addition to these requirements, CentralNic are able to support the wishes of the Governmental Advisory Council (GAC) or any individual Government in regard to the blocking of individual terms on a case by case basis. CentralNic’s registry system allows such additions to be made by appropriately authorised staff, with no further system development changes required.

The following applies to all Domain Names contained within the registry’s reserved list:

– Attempts to register listed Domain Names will be rejected.
– WhoIs queries for listed Domain Names will receive responses indicating their reserved status.
– Reserved geographic names will not appear in the TLD zone file.
– DNS queries for reserved domain names will result in an NXDOMAIN response.

2. PROCEDURES FOR RELEASE

We understand that if we wish to release the reserved names at a later date, this will require agreement from the relevant government(s) or review by the GAC, and subsequent approval from ICANN.

This completes our response to Q22.

Dot Tech LLC has chosen CentralNic as the registry infrastructure provider for the TLD. Please see Appendix 23.1 for the acceptance letter from CentralNic. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to CentralNic’s registry infrastructure systems.
Dot Tech LLC and CentralNic hereby explicitly confirm that all registry services stated below are engineered and will be provided in a manner compliant with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy) and applicable technical standards. Except for the registry services described above, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for the TLD;(iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement.
There are no other products or services, except those described above that the Registry Operator will provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of Dot Tech LLC being designated as the Registry Operator.
Any changes to the registry services that may be required at a later time in the course of Dot Tech LLC operating the registry will be addressed using rules and procedures established by ICANN such as the Registry Services Evaluation Policy.
Dot Tech LLC proposes to operate the following registry services, utilisingCentralNic's registry system:

23.1. Receipt of Data From Registrars
CentralNic will operate a Shared Registry System (SRS) for the TLD. The SRS consists of a database of registered domain names, host objects and contact objects, accessed via an Extensible Provisioning Protocol (EPP) interface, and a web based Registrar Console. Registrars will uses these interfaces to provide registration data to the registry.
The SRS will be hosted at CentralNic's primary operations centre in London, UK. The primary operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. The primary operations centre is hosted in Level 3's flagship European data centre and boasts significant physical security capabilities, including 24x7 patrols, CCTV and card-based access controls.
CentralNic's existing SRS system currently supports more than 250,000 domain names managed by over 1,500 registrars. CentralNic has effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of the TLD and provide additional capacity during periods of elevated activity (such as during Sunrise periods).
The SRS and EPP systems are described more fully in Q24 and Q25. The Registrar Console is described in Q31.
EPP is an extensible protocol by definition. Certain extensions have been put in place to comply with the new gTLD registry agreement, ICANN Consensus Policies and technical standards:
1. Registry Grace Period Mapping - compliant with RFC 3915(http://tools.ietf.org/html/rfc3915)
2. DNSSEC Security Extensions - compliant with RFC 5910 (http://tools.ietf.org/html/rfc5910)
3. Launch Phase Extension - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft https://github.com/wil/EPP-Launch-Phase-Extension-Specification/blob/master/draft-tan-epp-launchphase.txt
More information on EPP extensions is provided in Q25.
The SRS will implement and support all ICANN Consensus Policies and Temporary Policies, including:
*Uniform Domain Name Dispute Resolution Policy
*Inter-Registrar Transfer Policy
*Whois Marketing Restriction Policy
*Restored Names Accuracy Policy
*Expired Domain Deletion Policy
*AGP Limits Policy

23.2. Provision to Registrars of Status Information Relating to the Zone Servers
CentralNic will operate a communications channel to notify registrars of all operational issues and activity relating to the DNS servers which are authoritative for the TLD. This includes notifications relating to:
1. Planned and unplanned maintenance;
2. Denial-of-service attacks;
3. unplanned network outages;
4. delays in publication of DNS zone updates;
5. security incidents such as attempted or successful breaches of access controls;
6. significant changes in DNS server behaviour or features;
7. DNSSEC key rollovers.
Notifications will be sent via email (to preregistered contact addresses), with additional notifications made via an off-site maintenance site and via social media channels.

23.3. Dissemination of TLD Zone Files
CentralNic will make TLD zone files available via the Centralized Zone Data Access Provider according to specification 4, section 2 of the Registry Agreement.
Dot Tech LLC will enter into an agreement with any Internet user that will allow such user to access an Internet host server or servers designated by Dot Tech LLC and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider (the “CZDA Provider”). Dot Tech LLC will provide access to zone file data using the file format described in Section 2.1.4 of Specification 4 of the New gTLD Registry Agreement.
Dot Tech LLC , through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address, and the Internet host machine name and IP address.
Dot Tech LLC will provide the Zone File FTP (or other Registry supported) service for an ICANN-specified and managed URL for the user to access the Registry’s zone data archives. Dot Tech LLC will grant the user a non-exclusive, non-transferable, limited right to access Dot Tech LLC ’s Zone File FTP server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using FTP, or other data transport and access protocols that may be prescribed by ICANN.
Dot Tech LLC will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035(http://tools.ietf.org/html/rfc1035), Section 5, including all the records present in the actual zone used in the public DNS.
Dot Tech LLC , through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. Dot Tech LLC will allow users to renew their Grant of Access.
Dot Tech LLC will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.

23.4. Operation of the Registry Zone Servers
The TLD zone will be served from CentralNic's authoritative DNS system. This system has operated at 100% service availability since 1996 and has been developed into a secure and stable platform for domain resolution. Partnering with Community DNS, CentralNic's DNS system includes nameservers in more than forty cities, on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.
The DNS system is described further in Q35.

23.5. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
CentralNic will operate a Whois service for the TLD. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service compliant with RFC 3912 (http://tools.ietf.org/html/rfc3912). The Whois service will permit interested parties to obtain information about the Registered Name Holder, Administrative, Technical and Billing contacts for domain names. The Whois service will return records in a standardised format which complies with ICANN specifications.
CentralNic will provide access to the Whois service at no cost to the general public.
CentralNic's Whois service supports a number of features, including rate limiting to prevent abuse and privacy protections for natural persons. The Whois service is more fully described in Q26.
Should ICANN specify alternative formats and protocols for the dissemination of Domain Name Registration Data, CentralNic will implement such alternative specifications as soon as reasonably practicable.

23.6. DNSSEC
The TLD zone will be signed by DNSSEC. CentralNic uses the award-winning signer technology from Xelerance Corporation. Zone files will be signed using NSEC3 with opt-out, following a DNSSEC Practice Statement detailed in Q43.
CentralNic's DNSSEC implementation complies with RFCs 4033, 4034, 4035, 4509 and follows the best practices described in RFC 4641(http://tools.ietf.org/html/rfc4641). Hashed Authenticated Denial of Existence (NSEC3) will be implemented, which complies with RFC 5155(http://tools.ietf.org/html/rfc5155). The SRS will accept public-key material from child domain names in a secure manner according to industry best practices (specifically the secDNS EPP extension, described in RFC 5910(http://tools.ietf.org/html/rfc5910)). CentralNic will also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. CentralNic will publish its DPS following the format described in the “DPS-framework” Internet Draft within 180 days after that draft becomes an RFC.

23.7. Rights Protection Mechanisms
Dot Tech LLC will provide all mandatory Rights Protection Mechanisms that are specified in Dot Tech LLC Guidebook (version 11 January 2012), namely Trademark Claims Service (section 6.1) and Sunrise service (section 6.2). All the required RPM-related policies and procedures such as UDRP, URS, PDDRP and RRDRP will be adopted and used in the TLD. More information is available in Q29.
In addition to such RPMs, Dot Tech LLC may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Dot Tech LLC will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in the TLD. Dot Tech LLC shall implement these mechanisms in accordance with requirements established by ICANN each of the mandatory RPMs set forth in the Trademark Clearinghouse.
The "LaunchPhase" EPP extension (described above) will be used to implement an SRS interface during the Sunrise period for the TLD. Depending on the final specification for the Trademark Claims Service (details of which have not yet been published), an additional EPP extension may be required in order to implement this service. If this is necessary, the extension will be designed to minimise its effect on the operation of the SRS and the requirements on registrars, and will only be in place for a limited period while the Trademark Claims Service is in effect for the TLD.

23.8. Registrar Support and Account Management
CentralNic will leverage its 16 years of experience of supporting over 1,500 registrars to provide high-quality 24x7 support and account management for the TLD registrars. CentralNic's experienced technical and customer support personnel will assist the TLD registrars during the on-boarding and OT&E process, and provide responsive personal support via email, phone and a web based support ticketing system.

23.9. Reporting to ICANN
Dot Tech LLC and CentralNic will compile and transmit a monthly report to ICANN relating to the TLD. This report will comply with Specification 3 of the New gTLD Registry Agreement.

23.10. Personnel Resources of CentralNic
The technical, operations and support functions of the registry will performed in-house by CentralNic's personnel. These personnel perform these functions on a full-time basis.

23.10.1. Technical Operations
Technical Operations refers to the deployment, maintenance, monitoring and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. Internal helpdesk and incident reporting is also performed by the Technical Operations team. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are co-ordinated.
CentralNic intends to maintain a Technical Operations team consisting of the following positions. These persons will be responsible for managing, developing and monitoring the registry system for the TLD on a 24x7 basis:
*Senior Operations Engineer(s)
*Operations Engineer(s)
*Security Engineer

23.10.2. Technical Development
The Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, Zone file generation, data escrow, reporting, backoffice and web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team.
CentralNic intends to maintain a Technical Development team consisting of the following positions. These persons will be responsible for maintaining and developing the registry software which will support the TLD:
*Senior Technical Developer x 2
*Technical Developer x 3

23.10.3. Technical Support
Technical Support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.
1st line support issues are normally dealt with by these personnel. 2bd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.
The Technical Support team will consist of the following positions:
*Operations Manager
*Support Manager
*Support Agent(s)
Our overseas account managers also perform basic support functions, escalating to the support agents in London where necessary.

23.10.4. Key Personnel

23.10.4.1. Gavin Brown - Chief Technology Officer
Gavin has worked at CentralNic since 2001, becoming CTO in 2005. He has overall responsibility for all aspects of the SRS, Whois, DNS and DNSSEC systems. He is a respected figure in the domain industry and has been published in several professional technical journals, and co-authored a book on the Perl programming language. He also participates in a number of technical, public policy and advocacy groups and several open source projects. Gavin has a BSc (hons) in Physics from the University of Kent.

23.10.4.2. Jenny White - Operations Manager
Jenny has been with CentralNic for nine years. Throughout this time she has expertly managed customer relations with external partners, prepared new domain launch processes and documentation, managed daily support and maintenance for over 1,500 Registrars, carried out extensive troubleshooting within the registrar environment to ensure optimum usability for registrars across communication platforms, handled domain disputes (from mediation to WIPO filing), and liaised with WIPO to implement changes to the Dispute Resolution Procedure when necessary.

23.10.4.3. Adam Armstrong - Senior Operations Engineer
Adam has recently joined CentralNic as Senior Operations Engineer. In this role he is responsible for the operation and development of the system and network infrastructure for the registry system. Adam has previously worked at a number of large UK ISPs including Jersey Telecom and Packet Exchange. He is also the lead developer of Observium, a network management system used by ICANN (amongst others). Adam has brought his strong knowledge of network design, management and security to bear at CentralNic and will oversee the operation of the SRS for the TLD.

23.10.4.4. Milos Negovanovic - Senior Technical Developer
Milos has worked at CentralNic since 2009. He has a background in building rich web applications and protocol servers. His main areas of responsibility are the Registrar Console, EPP and backoffice functions.

23.10.4.5. Mary O'Flaherty - Senior Technical Developer
Mary has worked at CentralNic since 2008. She plays an integral role in the ongoing design, development and maintenance of the registry as a whole and has specific experience with the EPP system, Registrar Console and Staff Console. Mary has a 1st class Honors degree in Computer Science from University College Cork and has previously worked for Intel and QAD Ireland.

23.10.5. Job Descriptions
CentralNic will recruit a number of new employees to perform technical duties in relation to the TLD and other gTLDs. The following job descriptions will be used to define these roles and select candidates with suitable skills and experience.

23.10.5.1. Operations Engineer
Operations Engineers assist in the maintenance and development of the network and server infrastructure of the registry system. Operations Engineers have a good knowledge of the TCP/IP protocol stack and related technologies, and are familiar with best practice in the areas of network design and management and system administration. They should be competent system administrators with a good knowledge of Unix system administration, and some knowledge of shell scripting, software development and databases. Operations Engineers have 1-2 year's relevant commercial experience. Operations Engineers report to and work with the Senior Operations Engineer, who provides advice and mentoring. Operations Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.

23.10.5.2. Security Engineer
Security Engineers enhance and assure the security of the registry system. Day-to-day responsibilities are: responding to security incidents, performing analysis and remediating vulnerabilities, conducting tests of access controls, refining system configuration to improve security, training other team members, reviewing source code, maintaining security policies and procedures, and gathering intelligence relating to threats to the registry. Security Engineers have 1-2 year's relevant commercial experience. This role reports to and works with the Senior Operations Engineer and CTO. Security Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.

23.10.5.3. Technical Developer
Technical Developers are maintain the software which supports the registry. Day-to-day responsibilities are developing new systems in response to requests from management and customers, correcting bugs in existing software, and improving its performance. Technical Developers have a good knowledge of general programming practices including use of revision control and code review systems. Developers have a good awareness of security issues, such as those described in advisories published by the oWASP Project. Developers have at least one years' commercial experience in developing applications in programming languages such as PHP, Perl, and Python, although knowledge of domain technologies such as EPP and DNS is not critical. Technical Developers work as part of a team, with advice and mentoring from the Senior Technical Developers, to whom they report.

23.10.6. Resource Matrix
To provide a means to accurately and objectively predict human resource requirements for the operation of the registry system, CentralNic has developed a Resourcing Matrix, which assigns a proportion of each employee's available time to each aspect of registry activities. These activities include technical work such as operations and development, as well as technical support, registrar account management, rights protection, abuse prevention, and financial activity such as payroll, cash collection, etc. This matrix then permits the calculation of the total HR resource assigned to each area.
A copy of the Resourcing Matrix is included as Appendix 23.2. It is important to note that the available resources cover the operation of CentralNic's entire registry operations: this includes CentralNic's own domain registry portfolio (uk.com, us.com, etc), the .LA and .PW ccTLDs, as well as the gTLDs which CentralNic will provides registry service for.
The actual proportion of human technical resources required specifically for the TLD is determined by the relative size of the TLD to the rest of CentralNic's operations. This calculation is based on the projected number of domains after three years of operation: the optimistic scenario is used to ensure that sufficient personnel is on hand to meet periods of enhanced demand. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names.
Since the optimistic projection for the number of domains registered in the TLD after three years is 295,200, the TLD will therefore require 6.56% of CentralNic's total available HR resources in order operate fully and correctly. In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

Except where specified, this answer refers to the operations of Dot Tech LLC 's outsource Registry Service Provider, CentralNic.
24.1. Registry Type
CentralNic operates a "thick" registry in which the registry maintains copies of all information associated with registered domains. Registrars maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and contact information associated with registered domains. The Extensible Provisioning Protocol (EPP) adopted supports the thick registry model. See Q25 for further details.

24.2. Architecture
Figure 24.1 provides a diagram of the overall configuration of the SRS. This diagram should be viewed in the context of the overall architecture of the registry system described in Q32.
The SRS is hosted at CentralNic's primary operations centre in London. It is connected to the public Internet via two upstream connections, one of which is provided by Qube. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via two BGP routers which connect to the firewalls which implement access controls over registry services.
Within the firewall boundary, connectivity is provided to servers by means of resilient gigabit ethernet switches implementing Spanning Tree Protocol.
The registry system implements two interfaces to the SRS: the standard EPP system (described in Q25) and the Registrar Console (described in Q31). These systems interact with the primary registry database (described in Q33). The database is the central repository of all registry data. Other registry services also interact with this database.
An internal "Staff Console" is used by CentralNic personnel to perform management of the registry system.

24.3. EPP System Architecture
A description of the characteristics of the EPP system is provided in Q25. This response describes the infrastructure which supports the EPP system.
A network diagram for the EPP system is provided in Figure 24.2. The EPP system is hosted at the primary operations centre in London. During failover conditions, the EPP system operates from the Isle of Man Disaster Recovery site (see Q34).
CentralNic’s EPP system has a two-layer logical and physical architecture, consisting of load balancers and a cluster of application servers. Each layer can be scaled horizontally in order to meet demand.
Registrars establish TLS-secured TCP connections to the load balancers on TCP port 700. Load is balanced using DNS round-robin load balancing.
The load balancers pass sessions to the EPP application servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp module. These servers implement the EPP state diagram and handle registrar commands using application code.
Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontal scaling: commodity hardware is used throughout the system and can be rapidly added to the system, without disruption, to meet an unexpected growth in demand.
The EPP system will comprise of the following systems:
*3x load balancers (1U rack mount servers with quad-core Intel processors, 16GB RAM, 40GB solid-state disk drives, running the CentOS operating system using the Linux Virtual Server [see http://www.linuxvirtualserver.org/])
*12x EPP protocol servers (1U rack mount servers with dual-core Intel processors, 16GB RAM, solid-state disk drives, running the CentOS operating system using Apache and mod_epp)

24.3.1. mod_epp
mod_epp is an Apache server module which adds support for the EPP transport protocol to Apache. This permits implementation of an EPP server using the various features of Apache, including CGI scripts and other dynamic request handlers, reverse proxies, and even static files. mod_epp was originally developed by Nic.at, the Austrian ccTLD registry. Since its release, a large number of ccTLD and other registries have deployed it and continue to support its development and maintenance. Further information can be found at http://sourceforge.net/projects/aepps. CentralNic uses mod_epp to manage EPP sessions with registrar clients, and to convert EPP commands into HTTP requests which can then be handled by backend application code.

24.4. Performance
CentralNic performs continuous remote monitoring of its EPP system, and this monitoring includes measuring the performance of various parts of the system. As of writing, the average round-trip times (RTTs) for various functions of the EPP system were as follows:
*connect time: 40ms
*login time: 20ms
*hello time: 7ms
*check time: 15ms
*logout time: 6ms
These figures include an approximate latency of 3.2ms due to the distance between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.

24.5. Scaling
Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also encourages effective mechanisms to ensure high-availability, and eliminate single points of failure in the system.
Vertical scaling leverages Moore's Law: when units are depreciated and replaced, the new equipment is likely to be significantly more powerful. If the average lifespan of a server in the system is three years, then its replacement is likely to be around four times as powerful as the old server.
For further information about Capacity Management and Scaling, please see Q32.

24.6. Registrar Console
The Registrar Console is a web-based registrar account management tool. It provides a secure and easy-to-use graphical interface to the SRS. It is hosted on a virtual platform at the primary operations centre in London. As with the rest of the registry system, during a failover condition it is operated from the Isle of Man. The virtual platform is described in Figure 24.3.
The features of the Registrar Console are described in Q31.
The virtual platform is a utility platform which supports systems and services which do not operate at significant levels of load, and which therefore do not require multiple servers or the additional performance that running on "bare metal" would provide. The platform functions as a private cloud, with redundant storage and failover between hosts.
The Registrar Console currently sustains an average of 6 page requests per minute during normal operations, with peak volumes of around 8 requests per minute. Volumes during weekends are significantly lower (fewer than 1 requests per minute). Additional load resulting from this and other new gTLDs is expected to result in a trivial increase in Registrar Console request volumes, and CentralNic does not expect additional hardware resources to be required to support it.

24.7. Quality Assurance
CentralNic employs the following quality assurance (QA) methods:
1. 24x7x365 monitoring provides reports of incidents to NOC
2. Quarterly review of capacity, performance and reliability
3. Monthly reviews of uptime, latency and bandwidth consumption
4. Hardware depreciation schedules
5. Unit testing framework
6. Frequent reviews by QA working group
7. Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis
8. Revision control software with online annotation and change logs
9. Bug Tracking system to which all employees have access
10. Code Review Policy in place to enforce peer review of all changes to core code prior to deployment
11. Software incorporates built-in error reporting mechanisms to detect flaws and report to Operations team
12. Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment
13. Evidence-based project scheduling
14. Specification development and revision
15. Weekly milestones for developers
16. Gantt charts and critical path analysis for project planning
Registry system updates are performed on an ongoing basis, with any user-facing updates (ie changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest.

24.8. Billing
CentralNic operates a complex billing system for domain name registry services to ensure registry billing and collection services are feature rich, accurate, secure, and accessible to all registrars. The goal of the system is to maintain the integrity of data and create reports which are accurate, accessible, secured, and scalable. The foundation of the process is debit accounts established for each registrar. CentralNic will withdraw all domain fees from the registrar’s account on a per-transaction basis. CentralNic will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) to a registrar for as long as that registrar’s account shows a positive balance.
Once ICANN notifies Dot Tech LLC that a registrar has been issued accreditation, CentralNic will begin the registrar on-boarding process, including setting up the registrar's financial account within the SRS.

24.9. Registrar Support
CentralNic provides a multi-tier support system on a 24x7 basis with the following support levels:
*1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.
*2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
*3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.
CentralNic provides a support ticketing system for tracking routine support issues. This is a web based system (available via the Registrar Console) allowing registrars to report new issues, follow up on previously raised tickets, and read responses from CentralNic support personnel.
When a new trouble ticket is submitted, it is assigned a unique ID and priority. The following priority levels are used: n
1. Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
2. Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
3. Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.
4. Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.
Depending on priority, different personnel will be alerted to the existence of the ticket. For example, a Priority 1 ticket will cause a notification to be emailed to the registrar customer support team, but a Priority 4 ticket will result in a broadcast message sent to the pagers of senior operations staff including the CTO. The system permits escalation of issues that are not resolved within target resolution times.

24.10. Enforcement of Eligibility Requirements
The SRS supports enforcement of eligibility requirements, as required by specific TLD policies.
Figure 24.4 describes the process by which registration requests are validated. Prior to registration, the registrant's eligibility is validated by a Validation Agent. The registrant then instructs their registrar to register the domain. The SRS returns an "Object Pending" result code (1001) to the registrar.
The request is sent to the Validation Agent by the registry. The Validation Agent either approves or rejects the request, having reconciled the registration information with that recorded during the eligibility validation. If the request has been approved, the domain is fully registered. If it is rejected, the domain is immediately removed from the database. A message is sent to the registrar via the EPP message queue in either case. The registrar then notifies the registrant of the result.

24.11. Interconnectivity With Other Registry Systems
The registry system is based on multiple resilient stateless modules. The SRS, Whois, DNS and other systems do not directly interact with each other. Interactions are mediated by the database which is the single authoritative source of data for the registry as a whole. Individuals modules perform "CRUD" (create, read, update, delete) actions upon the database. These actions then affect the behaviour of other registry systems: for example, when a registrar adds the "clientHold" status to a domain object, this is recorded in the database. When a query is received for this domain via the Whois service, the presence of this status code in the database results in the "Status: CLIENT HOLD" appearing in the whois record. It will also be noted by the zone generation system, resulting in the temporary removal of the delegation of the domain name from the DNS.

24.12. Resilience
The SRS has a stateless architecture designed to be fully resilient in order to provide an uninterrupted service in the face of failure or one or more parts of the system. This is achieved by use of redundant hardware and network connections, and by use of continuous "heartbeat" monitoring allowing dynamic and high-speed failover from active to standby components, or between nodes in an active-active cluster. These technologies also permit rapid scaling of the system to meet short-term increases in demand during "surge" periods, such as during the initial launch of a new TLD.

24.12.1. Synchronisation Between Servers and Sites
CentralNic's system is implemented as multiple stateless systems which interact via a central registry database. As a result, there are only a few situations where synchronisation of data between servers is necessary:
1. replication of data between active and standby servers (see Q33). CentralNic implements redundancy in its database system by means of an active/standby database cluster. The database system used by CentralNic supports native real-time replication of data allowing operation of a reliable hot standby server. Automated heartbeat monitoring and failover is implemented to ensure continued access to the database following a failure of the primary database system.
2. replication is used to synchronise the primary operations centre with the Disaster Recovery site hosted in the Isle of Man (see Q34). Database updates are replicated to the DR site in real-time via a secured VPN, providing a "hot" backup site which can be used to provide registry services in the event of a failure at the primary site.

24.13. Operational Testing and Evaluation (OT&E)
An Operational Testing and Evaluation (OT&E) environment is provided for registrars to develop and test their systems. The OT&E system replicates the SRS in a clean-room environment. Access to the OT&E system is unrestricted and unlimited: registrars can freely create multiple OT&E accounts via the Registrar Console.

24.14. Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.
CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 295,200 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 6.56% of the total resources available for this area of the registry system.
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

Except where specified this answer refers to the operations of Dot Tech LLC 's outsource Registry Service Provider, CentralNic.
The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.
CentralNic has operated its EPP system since 2005, and it currently operates at significant load in terms of registrars, sessions and transaction volumes. CentralNic's EPP system is fully compliant with the following RFC specifications:
*5730 - Base Protocol
*5731 - Domains
*5732 - Host Objects
*5733 - Contact Objects
*5734 - TCP Transport
*3735 - Extension Guidelines
*3915 - RGP Extension
*5910 - DNSSEC Extension

25.1. Description of Interface
EPP is a stateful XML protocol layered over TCP (see RFC 3734 (http://tools.ietf.org/html/rfc3734)). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).
EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.
EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.
EPP commands fall into three categories: session management, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.
Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.
EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.

25.1.1. Objects supported
Registrars may create and manage the following object types in the CentralNic EPP system:
*domains (RFC 5731 (http://tools.ietf.org/html/rfc5731))
*host objects (RFC 5732 (http://tools.ietf.org/html/rfc5732))
*contact objects (RFC 5733 (http://tools.ietf.org/html/rfc5733))

25.1.2. Commands supported
CentralNic supports the following EPP commands:
*<hello> - retrieve the <greeting> from the server
*<login> and <logout> - session management
*<poll> - message queue management
*<check> - availability check
*<info> - object information
*<create> - create object
*<update> - update object
*<renew> - renew object
*<delete> - delete object
*<transfer> - manage object transfer

25.2. EPP state diagram
Figure 25.1 describes the state machine for the EPP system. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.

25.3. EPP Object Policies
The following policies apply to objects provisioned via the EPP system:

25.3.1. domains
1. domains must comply with the syntax described in RFC 1035 (http://tools.ietf.org/html/rfc1035) §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.
2. domains must have a registrant attribute which is associated with a contact object in the database.
3. domains must have an administrative contact attribute which is associated with a contact object in the database.
4. domains must have a technical contact which attribute is associated with a contact object in the database.
5. domains may have an billing contact attribute which is associated with a contact object in the database.
6. domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS
7. the host object model for domains is used rather than the host attribute model.
8. domains may have a number of status codes. The presence of certain status codes indicates the domain's position in the lifecycle, described further in §27.
9. where policy requires, the server may respond to a <domain:create> command with an "Object Pending" (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.
10. when registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.
11. when renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. domains which auto-renew are renewed for one year at a time.
12. domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.
13. domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910 (http://tools.ietf.org/html/rfc5910).
14. only the sponsoring registrar of the domain may submit <update>, <renew> or <delete> commands for the domain.

25.3.2. Host objects
1. host names must comply with RFC 1035 (http://tools.ietf.org/html/rfc1035). The maximum length of the host name may not exceed 255 characters.
2. in-bailiwick hosts must have an IPv4 address. They may optionally have an IPv6 address.
3. multiple IP addresses are not currently permitted.
4. sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.
5. if a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must be the sponsor of the new parent domain.
6. registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it us subordinate to a non-existent in-bailiwick domain.
7. a host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
8. inter-registrar transfers are not permitted.
9. only the sponsoring registrar of the host may submit <update> or <delete> commands for the object.

25.3.3. Contact objects
1. contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
2. phone numbers and email addresses must be valid as described in RFC 5733 (http://tools.ietf.org/html/rfc5733) §2.5 and §2.6.
3. contact information is accepted and stored in "internationalized" format only: that is, contact objects only have a single <contact:postalInfo> element and the type attribute is always "int".
4. the <contact:org>, <contact:sp>, <contact:pc>, <contact:phone> and <contact:fax> elements are optional.
5. contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.
6. a contact cannot be deleted if one or more domains are associated with it.
7. only the sponsoring registrar of the contact may submit <update> or <delete> commands for the object.

25.4. EPP Extensions
CentralNic supports the following EPP extensions. CentralNic's implementations fully comply with the required specifications.

25.4.1. Registry Grace Period Mapping
Various grace periods and hold periods are supported by the Registry Grace Period mapping, as defined in RFC 3915 (http://tools.ietf.org/html/rfc3915). This is described further in §27.

25.4.2. DNSSEC Security Extensions Mapping
Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.
CentralNic supports the specification defined in RFC 5910 (http://tools.ietf.org/html/rfc5910). This supports two interfaces: the DS Data Interface and Key Data Interface. CentralNic supports the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the <secDNS:dsData> element. The maxSigLife element is optional in the specification and is not currently supported.

25.4.3. Launch Phase Extension
CentralNic has assisted development of a standard EPP extension for registry "launch phases" (ie Sunrise and Landrush periods), during which the steady-state mode of "first-come, first-served" operation does not apply. This extension permits registrars to submit requests for domains with claimed rights such as a registered trademark. The extension is currently described in an Internet-Draft (see http://tools.ietf.org/html/draft-tan-epp-launchphase-00). It is hoped that this draft will eventually be published as an RFC which can be implemented by other registries and registrars.
CentralNic's system implements this extension and will support the most recent version of the draft during the initial launch of the TLD. Once the TLD enters General Availability, this extension will no longer be available for use by registrars. Example frames describing the use of this extension are included in Appendix 25.2. As of writing, the current draft does not include a full schema definition, but a schema from a previous version has been included in Appendix 25.3. When the Draft is updated to include a schema, it will be based on this version.
25.4.4. IDN Extension
The IDN extension allows registrars to specify the IDN table associated with an IDN domain at the point of registration. It also extends the <domain:info> response to return the IDN table associated with an IDN domain. This extension is specified at http://tools.ietf.org/html/draft-obispo-epp-idn.
25.4.5. Balance Mapping
The Balance Mapping is a limited object mapping which allows registrars to query their current account balance over EPP. This extension was developed by Verisign and is specified in http://www.verisigninc.com/assets/epp-balance-mapping.pdf.

25.5. Registrar Credentials and Access Control
Registrars are issued with a username (their registrar ID) and a password. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the "Management" access level can change their EPP password via the Registrar Console.
RFC 5730 (http://tools.ietf.org/html/rfc5730) requires "mutual, strong client-server authentication". CentralNic requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with CentralNic via the Registrar Console. Registrar officers with the "Management" access level can upload SSL certificates for their account.

25.6. Session Limits and Transaction Volumes
There are no limits on the number of active sessions a registrar can maintain with the server. Similarly, there are no limits on the volume of transactions a registrar may send. However the system is fully capable of imposing connection limits and this measure may be used in future to ensure equal access amongst registrars.

25.7. Transaction Logging and Reporting
All "transform" commands are logged. Transform commands are: <create>, <renew>, <update>, <delete> and <transfer>. The system logs the time and date when the command was received, the registrar which submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.
The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain, host name, contact ID), result code and timestamp.
Query commands (<check>, <info>, <poll op="req">) and session commands (<login>, <logout> and <hello>) are not logged due to the large volume of such queries (particularly <check> queries). The EPP system uses counters for these commands to facilitate generation of monthly reports.

25.8. EPP Message Queue
The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic currently supports the following EPP message notifications:
*approved inbound transfer
*rejected inbound transfer
*new outbound transfer
*cancelled outbound transfer
*approved or rejected domain registration request (where TLD policy requires out-of-band approval of <domain:create> requests)

25.9. Registrar Support, Software Toolkit
CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries:
*Net::EPP, a general purpose EPP library for Perl. See http://code.google.com/p/perl-net-epp/
*Preppi, a graphical EPP client written in Perl. See https://www.centralnic.com/company/labs/preppi
*Net_EPP, a PHP client class for EPP. See https://github.com/centralnic/php-epp
*Simpleepp, a Python client class for EPP. See https://bitbucket.org/milosn/simpleepp
*tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python. See https://bitbucket.org/milosn/tx-epp-proxy
These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.

25.10. Quality Assurance, RFC Compliance
To ensure that its EPP system fully complies with the relevant specifications documents, CentralNic has implemented the following:

25.10.1. Schema Validation
The EPP system automatically validates all response frames against the XSD schema definitions provided in the RFCs. Should a non-validating response be sent to a registrar, an alert is raised with the NOC to be investigated and corrected. By default, this feature is disabled in the production environment but it is enabled in all other environments (as described below).

25.10.2. Multi-stage Deployment and Testing
EPP system code is developed, tested and deployed in a multi-stage environment:
1. Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.
2. All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).
3. Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.

25.10.3. Registrar Feedback
Registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation on the responses they receive. When issues are detected by registrars, they are encouraged to submit bug reports so that developers can rectify the issues.

25.11. EPP System Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time person.
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.
CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 295,200 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 6.56% of the total resources available for this area of the registry system.
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

Except where specified this answer refers to the operations of Dot Tech LLC 's outsource Registry Service Provider, CentralNic.
Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.
Whois is described by RFC 3912 (http://tools.ietf.org/html/rfc3912), which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.

26.1. Compliance
The Whois service for the TLD will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as RDAP) then CentralNic will implement these as soon as reasonably practicable.
CentralNic will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. CentralNic will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.

26.2. Domain Name
By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:
*Domain ROID
*Domain Name
*Domain U-label (if IDN)
*Creation Date
*Last Updated
*Expiration Date
*EPP status codes
*Registrant Contact Information
*Administrative Contact Information
*Technical Contact Information
*Billing Contact Information (if any)
*Sponsoring Registrar ID
*Sponsoring Registrar Contact Information
*DNS servers (if any)
*DNSSEC records (if any)
An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730 (http://tools.ietf.org/html/rfc5730), Q2.8. The ROID field corresponds to the <domain:roid> element of EPP <info> responses.
A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:
*PENDING CREATE - a <domain:create> command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
*ADD PERIOD - the domain is in the Add Grace Period
*CLIENT HOLD - the registrar has added the clientHold status
*DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)
*INACTIVE - the domain has no DNS servers
*PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion
*PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period
*PENDING RESTORE - a restore request has been received, but the Restore Report has not been received
*PENDING TRANSFER - there is an active inter-registrar transfer for the domain
*RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
*RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)
*SERVER HOLD - the registry has added the serverHold status
*TRANSFER PERIOD - the domain is in the Transfer Grace Period
*TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)
*UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)
*OK - present if none of the above apply.
The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.
Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the "INACTIVE" status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.

26.3. Contact
Users can query for information about a contact by submitting a query of the form "contact [ID]", where "[ID]" is the contact ID equivalent to the <contact:id> element in EPP <info> responses. This is also the ID used when referring to contacts in domain responses.
The following information is included in Dontact records:
*Contact ID
*Sponsoring Registrar
*Creation Date
*Last Updated Date
*EPP Status Codes
*Contact Name
*Organisation
*Street Address (1-3 fields)
*City
*State/Province
*Postcode
*Country Code (2 character ISO-3166 code)
*Phone number (e164a format)
*Fax number (e164a format)
*Email address
An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:
*DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
*TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
*UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
*PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
*LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status

26.4. Host Objects
Users can query for information about a host object by submitting a query of the form "nameserver [HOST]". The following information is included in host records:
*Server Name
*IPv4 address (if any)
*IPv6 address (if any)
*EPP status codes
*Sponsoring Registrar
*Creation Date
*Referral URL (if any)
*An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is "in-bailiwick", ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for "out-of-bailiwick" hosts.
Host objects may only have two status codes:
*INACTIVE - the host is not associated with any domain names
*LINKED - the host is associated with one or more domain names
The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original <create> request.

26.5. Character Encoding
Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.

26.6. IDN Support
The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.

26.7. Bulk Access
CentralNic will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). CentralNic will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.
At ICANN's request, CentralNic will provide ICANN with up-to-date data for the domain names of de-accredited registrar to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. CentralNic will provide the data within 2 business days.

26.8. Load Projections
As described in Q31, CentralNic's existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.
The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in the TLD and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.
CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use whois to perform availability checks, to encourage them to EPP instead. CentralNic believes this query rate will also apply for the TLD. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.

26.9. Technical Implementation
A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service is operated at the primary operations centre in London. During failover conditions, it is operated at the Disaster Recovery site in the Isle of Man (see Q34).
Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one a server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.

26.9.1. Application Server Architecture
Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whoisng Apache module (see https://www.centralnic.com/registry/labs/mod-whois) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.

26.9.2. Caching
Application servers use caching to reduce database load. Subsequent identical queries are returned a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.

26.9.2. Database
The Whois service draws data directly from the primary database. The query volume required to sustain the Whois service is comparable to that of a modest web application such as a small e-commerce site, and as a result a dedicated database for the Whois system is not required. As can be seen in Figure 26.1, a separate logging database is used to aggregate log data for use with the rate limiting system.

26.10. Web based Whois Service
CentralNic provides a web interface to the Whois service on its website. In addition, Dot Tech LLC will provide a similar service on the TLD registry website. The web Whois acts as a proxy to the port 43 Whois service: users enter a query into a form, and a server-side process submits the query to the Whois server, and displays the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.

26.11. Anti-Abuse Mechanisms
CentralNic has implemented measures to mitigate the threat of abuse of the Whois service. The primary threat to the Whois service are so-called "dictionary" attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.
The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing /48 will be blocked.
Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the whois is restricted to levels which are unappealing for attackers.
CentralNic keeps a "white list" of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists are also incorporated into the white list, and IP addresses registered on ICANN's RADAR system will also be included. Queries from IP addresses that appear on the white list are not rate-limited. Interested parties can request addition to the white list by contacting CentralNic's public customer service team.
The web-based Whois does not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.

26.11.1. Denial-of-Service attacks
The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of CentralNic's network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system (see Q42) proactively detects these threats. As the Whois service directly queries the primary SRS database, CentralNic rate-limits on the database backend to prevent an attack against the Whois service from disrupting the SRS.

26.12. Monitoring and Logging
Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.

26.13. Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to almost one full-time person (83%.
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.
CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 295,200 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 6.56% of the total resources available for this area of the registry system.
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

Except where specified this answer refers to the operations of Dot Tech LLC 's outsource Registry Service Provider, CentralNic.
The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.

27.1. Available
The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a "NOT FOUND" response to queries. An EPP <check> command will return an "avail" status of 1.

27.2. Registered
A registar submits an EPP <create> command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrar's balance. The initial registration period may be any whole number of years between one (1) and ten (10).
For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).
While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain name's DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a <renew> EPP command or using the Registrar Console.
The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.

27.3. Expired
When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrar's account.
For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.

27.4. Redemption Grace Period
Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from the TLD zone.
For the first thirty (30) days after receipt of the delete request, the domain is in the "Pending Delete Restorable" state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the "Pending Restore" state.
The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the "Pending Delete Restorable" state.

27.5. Redemption Period State Diagram
Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915 (http://tools.ietf.org/html/rfc3915).

27.6. Pending Delete
Forty (40) days after the receipt of the delete request, the domain leaves the "Pending Delete Restorable" and enters the "Pending Delete" status. The registrar cannot submit a Restore Request during this period.

27.7. Released
Five (5) days after the domain enters the "Pending Delete" status the domain name is purged from the database and is once again available for registration.

27.8. Other Grace Periods
The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.

27.8.1. Add Grace Period
As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.

27.8.2. Auto-renew Grace Period
As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.

27.8.3. Renew Grace Period
The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP <renew> command, or via the Registrar Console.

27.8.4. Transfer Grace Period
The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.

27.9. Hold Periods
The registry implements the following hold periods:

27.9.1. Registration Hold Period
The Registration Hold Period forbids inter-registrar transfers of domain names within sixty (60) days of initial registration.

27.9.2. Transfer Hold Period
The Transfer Hold Period forbids transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.

27.10. Lock Statuses
The registry system permits the following lock statuses for domain names:

27.10.1. clientHold
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.

27.10.2. clientDeleteProhibited
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP <delete> command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP <update> command before they can delete the domain.

27.10.3. clientRenewProhibited
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP <renew> command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP <update> command before they can renew the domain.

27.10.4. clientUpdateProhibited
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP <update> command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the <update> request frame includes a <rem> element to remove this status. Once the status has been removed, subsequent <update> commands will succeed.

27.10.5. clientTransferProhibited
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP <transfer> command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.

27.10.6. serverHold
This status is set by the registry in accordance with policy. It cannot be removed by registrars. Domains with this status are removed from the DNS and will not resolve.

27.10.7. serverDeleteProhibited
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP <delete> command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.8. serverUpdateProhibited
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP <update> command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.9. serverRenewProhibited
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP <renew> command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.10. serverTransferProhibited
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP <transfer> command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.11. Lifecycle Processing
Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.
Billing runs take place once per day. The billing run performs the following batch jobs:
*auto-renewal of expired domains
*processing of registration and renewal fees for domains that move outside their grace periods
*processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
*purging of domains scheduled for deletion
The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.

27.12. Inter-Registrar Transfer Period
When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.

27.13. pendingCreate Status
The Registry system supports the "pendingCreate" status for domain names, as described in RFC 5731 (http://tools.ietf.org/html/rfc5731), Q3.3. Domains in this state are fully registered in the database (subsequent <create> commands would fail with an Object Exists error) but are not present in the DNS.
This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.
If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain which begins to resolve.

27.14. Resourcing
The domain registration lifecycle is managed through automated backend processes that generally require no human intervention, and real-time business logic implemented in Shared Registry System application code. Operations personnel will be responsible for maintaining and developing the computing infrastructure which supports the lifecycle processing systems. Backend systems are hosted on a flexible virtual infrastructure hosted at the primary operations centre at the Goswell Road Data Centre in London.
The domain registration lifecycle does have customer and registrar support requirements, so a proportion of the time of the Operations Manager, Support Manager and Support Agent has been dedicated to this area. This time primarily relates to dealing with questions and comments from registrars and registrants about the status of their domain names.
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 30% of a full time person. Because of the maturity and stability of this system (which has been in use for more than 16 years), only 5% of time of a technical developer has been allocated to this area.
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.
CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 295,200 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 6.56% of the total resources available for this area of the registry system.
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

General Statement of Policy

Abuse within the registry will not be tolerated. DOT Tech, LLC will implement very strict policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. DOT Tech, LLC’s homepages will provide clear contact information for its Abuse Team, and in accordance with ICANN policy DOT Tech, LLC shall host NIC.TECH, providing access to .TECH’s WhoIs services, the Abuse Policy, and contact information for the Abuse Team.

Anti-Abuse Policy

DOT Tech, LLC will implement in its internal policies and its Registry-Registrar Agreements (RRAs) that all registered domain names in the TLD will be subject to a Domain Name Anti-Abuse Policy (“Abuse Policy”).

The Abuse Policy will provide DOT Tech, LLC with broad power to suspend, cancel, or transfer domain names that violate the Abuse Policy. DOT Tech, LLC will publish the Abuse Policy on its home website at NIC.TECH and clearly provide DOT Tech, LLC’s Point of Contact (“Abuse Contact”) and its contact information. This information shall consist of, at a minimum, a valid e-mail address dedicated solely to the handling of abuse complaints, and a telephone number and mailing address for the primary contact. DOT Tech, LLC will ensure that this information will be kept accurate and up to date and will be provided to ICANN if and when changes are made.

In addition, with respect to inquiries from ICANN-Accredited Registrars, the Abuse Contact shall handle requests related to abusive domain name practices.

Inquiries addressed to the Abuse Contact will be routed to DOT Tech, LLC’s Legal Team who will review and if applicable remedy any Complaint regarding an alleged violation of the Abuse Policy as described in more detail below. DOT Tech, LLC will catalog all abuse communications in its CRM software using a ticketing system that maintains records of all abuse complaints indefinitely. Moreover, DOT Tech, LLC shall only provide access to these records to third parties under limited circumstances, such as in response to a subpoena or other such court order or demonstrated official need by law enforcement.

The Abuse Policy will state, at a minimum, that DOT Tech, LLC reserves the right to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary to ; (1) to protect the integrity and stability of the registry; (2) to comply with applicable laws, government rules or requirements, or court orders; (3) to avoid any liability, civil or criminal, on the part of DOT Tech, LLC, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) to correct mistakes made by the DOT Tech, LLC, registry services provider, or any Registrar in connection with a domain name registration; (5) during resolution of any dispute regarding the domain; and or (6) to prevent the bad faith use of a domain name that is identical to a registered trademark and being used to confuse users.

The Abuse Policy will define the abusive use of domain names to include, but not be limited to, the following activities:

• Illegal or fraudulent actions: use of the DOT Tech, LLC’s or Registrarʹs services to violate the laws or regulations of any country, state, or infringe upon the laws of any other jurisdiction, or in a manner that adversely affects the legal rights of any other person;
• Spam: use of electronic messaging systems from email addresses from domains in the TLD 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;
• Trademark and Copyright Infringement: DOT Tech, LLC will take great care to ensure that trademark and copyright infringement does not occur within the .TECH TLD. DOT Tech, LLC will employ notice and takedown procedures based on the provisions of the Digital Millennium Copyright Act (DMCA) ;
• Phishing: use of counterfeit Web pages within the TLD that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
• Pharming: redirecting of unknowing users to fraudulent Web sites or services, typically through DNS hijacking or poisoning;
• Willful distribution of malware: dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses.
• Fast flux hosting: use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. 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. Fast flux hosting may be used only with prior permission of DOT Tech, LLC;
• Botnet command and control: services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks);
• Distribution of pornography;
• Illegal Access to Other Computers or Networks: illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity);
• Domain Kiting⁄Tasting: registration of domain names to test their commercial viability before returning them during a Grace Period;
• High Volume Registrations⁄Surveying: registration of multiple domain names in order to warehouse them for sale or pay-per-click websites in a way that can impede DOT Tech, LLC from offering them to legitimate users or timely services to other subscribers;
• Geographic Name: registering a domain name that is identical to a Geographic Name, as defined by Specification 5 of the Registry Agreement;
• Inadequate Security: registering and using a domain name to host a website that collects third-party information but does not employ adequate security measures to protect third-party information in accordance with that geographic area’s data and financial privacy laws;
• Front Running: Registrars mining their own web and WhoIs traffic to obtain insider information with regard to high-value second-level domains, which the Registrar will then register to itself or an affiliated third party for sale or to generate advertising revenue;
• WhoIs Accuracy: Intentionally inserting false or misleading Registrant information into the TLD’s WhoIs database in connection with the bad faith registration and use of the domain in question;
• WhoIs Misuse: abusing access to the WhoIs database by using Registrant information for data mining purposes or other malicious purposes;
• Fake Renewal Notices; misusing WhoIs Registrant information to send bogus renewal notices to Registrants on file with the aim of causing the Registrant to spend unnecessary money or steal or redirect the domain at issue.

Domain Anti-Abuse Procedure

DOT Tech, LLC will provide a domain name anti-abuse procedure modeled after the DMCA’s notice-and-takedown procedure.

At all times, DOT Tech, LLC will publish on its home website at NIC.TECH the Abuse Policy and the contact information for the Abuse Contact. Inquiries addressed to the Point of Contact will be addressed to and received by DOT Tech, LLC’s Legal Team who will review and if applicable remedy any Complaint regarding an alleged violation of the Abuse Policy. DOT Tech, LLC will catalog all abuse communications and provide them to third parties only under limited circumstances, such as in response to a subpoena or other such court order or demonstrated official need by law enforcement.

Any correspondence (“Complaint”) from a complaining party (“Complainant”) to the Abuse Contact will be ticketed in DOT Tech, LLC’s CRM software and relayed to DOT Tech, LLC’s Abuse Team. A member of DOT Tech, LLC’s Abuse Team will then send an email to the Complainant within forty-eight (48) hours of receiving the Complaint confirming receipt of the email and that DOT Tech, LLC will notify the Complainant of the results of the Complaint within ten (10) days of receiving the Complaint.

DOT Tech, LLC’s Abuse Team will review the Complaint and give it a “quick look” to see if the Complaint reasonably falls within an abusive use as defined by the Abuse Policy. If not, the Contact will write an email to the Complainant within thirty-six (36) hours of sending the confirmation email that the subject of the complaint clearly does not fall within one of the delineated abusive uses as defined by the Abuse Policy and that DOT Tech, LLC considers the matter closed.

If the quick look does not resolve the matter, DOT Tech, LLC’s Abuse Team will give the Complaint a full review. Any Registrant that has been determined to be in violation of DOT Tech, LLC policies shall be notified of the violation of such policy and their options to cure the violation.
Such notification shall state:
1) the nature of the violation;
2) the proposed remedy to the violation;
3) the time frame to cure the violation; and
4) the Registry’s options to take subsequent action if the Registrant does not cure the violation.
If an abusive use is determined DOT Tech, LLC’s Abuse Team will alert it’s Registry services team to immediately cancel the resolution of the domain name. DOT Tech, LLC’s Abuse Team will immediately notify the Registrant of the suspension of the domain name, the nature of the complaint, and provide the Registrant with the option to respond within ten (10) days or the domain will be canceled.
If the Registrant responds within ten (10) business days, it’s response will be reviewed by the DOT Tech, LLC’s Abuse Team for further review. If DOT Tech, LLC’s Abuse Team is satisfied by the Registrant’s response that the use is not abusive, DOT Tech, LLC’s Abuse Team will submit a request by the registry services provider to reactivate the domain name. DOT Tech, LLC’s Abuse Team will then notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial. If the Registrant does not respond within ten (10) business days, DOT Tech, LLC will notify the registry services team to cancel the abusive domain name.

This Anti-Abuse Procedure will not prejudice either party’s election to pursue another dispute mechanism, such as URS or UDRP.

With the resources of DOT Tech, LLC’s registry services personnel, DOT Tech, LLC can meet its obligations under Section 2.8 of the Registry Agreement where required to take reasonable steps to investigate and respond to reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of its TLD. The Registry will respond to legitimate law enforcement inquiries within one (1) business day from receiving the request. Such response shall include, at a minimum, an acknowledgement of receipt of the request, questions, or comments concerning the request, and an outline of the next steps to be taken by Application for rapid resolution of the request.

In the event such request involves any of the activities which can be validated by DOT Tech, LLC and involves the type of activity set forth in the Abuse Policy, the sponsoring Registrar is then given forty-eight (48) hours to investigate the activity further and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the registry to keep the name in the zone. If the Registrar has not taken the requested action after the 48-hour period (i.e., is unresponsive to the request or refuses to take action), DOT Tech, LLC will place the domain on “serverHold”.

Maintenance of Registration Criteria

1) All Registrants awarded a “.TECH” domain will agree to a one year minimum contract, which will need to be renewed on an annual basis. Renewal is the sole responsibility of the Registrant.
2) DOT Tech, LLC is not liable or responsible in any way for any errors, omissions or any other actions by any third party (including any Registrar service) arising out of or related to a given Registrant’s application for, registration of, renewal of, or failure to register or renew a particular domain name.

3) Through the registration process all Registrants will be expected to designate an administrative contact for their application, which would possess all the rights granted by DOT Tech, LLC or its designated agents to act in respect to the given domain including but not limited to managing the domain name or any services associated thereto. It is the Registrant’s responsibility to update and maintain accurate contact information for their registrations.

Orphan Glue Removal

As the Security and Stability Advisory Committee of ICANN (SSAC) rightly acknowledges, although orphaned glue records may be used for abusive or malicious purposes, the “dominant use of orphaned glue supports the correct and ordinary operation of the DNS.” See http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.

While orphan glue often supports correct and ordinary operation of the DNS, we understand that such glue records can be used maliciously to point to name servers that host domains used in illegal phishing, bot-nets, malware, and other abusive behaviors. Problems occur when the parent domain of the glue record is deleted but its children glue records still remain in the DNS. Therefore, when DOT Tech, LLC has written evidence of actual abuse of orphaned glue, DOT Tech, LLC will take action to remove those records from the zone to mitigate such malicious conduct.

DOT Tech, LLC’s registry service operator will run a daily audit of entries in its DNS systems and compare those with its provisioning system. This serves as an umbrella protection to make sure that items in the DNS zone are valid. Any DNS record that shows up in the DNS zone but not in the provisioning system will be flagged for investigation and removed if necessary. This daily DNS audit serves to not only prevent orphaned hosts but also other records that should not be in the zone.

In addition, if either DOT Tech, LLC or its registry services operator becomes aware of actual abuse on orphaned glue after receiving written notification by a third party through its Abuse Contact or through its customer support, such glue records will be removed from the zone.

WhoIs Accuracy

DOT Tech, LLC will provide WhoIs accessibility in a reliable, consistent, and predictable fashion in order to promote Whois accuracy. The Registry will adhere to port 43 WhoIs Service Level Agreements (SLAs), which require that port 43 WHOIS service be highly accessible and fast.

DOT Tech, LLC will offer thick WhoIs services, in which all authoritative WhoIs data—including contact data—is maintained at the registry. DOT Tech, LLC will maintain timely, unrestricted, and public access to accurate and complete WhoIs information, including all data objects as specified in Specification 4.

In order to further promote WhoIs accuracy, DOT Tech, LLC will offer a mechanism whereby third parties can submit complaints directly to the DOT Tech, LLC (as opposed to ICANN or the sponsoring Registrar) about inaccurate or incomplete WhoIs data. Such information shall be forwarded to the Registrar, who shall be required to address those complaints with their Registrants. Thirty days after forwarding the complaint to the Registrar, DOT Tech, LLC will examine the current WhoIs data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, DOT Tech, LLC reserves the right to cancel or suspend the applicable domain name(s) should DOT Tech, LLC determine that the domains are being used in a manner contrary to DOT Tech, LLC’s abuse policy.

DOT Tech, LLC will also maintain historical databases of Registrants and associated information which have provided inaccurate WhoIs information. DOT Tech, LLC will endeavor to use this database to uncover patterns of suspicious registrations which DOT Tech, LLC shall then flag for further authentication or for review of the Registrant’s use of the domain in question to ensure Registrant’s use is consonant with DOT Tech, LLC’s abuse policy.

In addition, DOT Tech, LLC’s Abuse Team shall on its own initiative, no less than twice per year, perform a manual review of a random sampling of domain names within the applied-for TLD to test the accuracy of the WhoIs information. Although this will not include verifying the actual information in the WHOIS record, DOT Tech, LLC will be examining the WHOIS data for prima facie evidence of inaccuracies. In the event that such evidence exists, it shall be forwarded to the Registrar, who shall be required to address those complaints with their Registrants. Thirty days after forwarding the complaint to the Registrar, the DOT Tech, LLC will examine the current WhoIs data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, DOT Tech, LLC reserves the right to suspend the applicable domain name(s) should DOT Tech, LLC determine that the Registrant is using the domain in question in a manner contrary to DOT Tech, LLC’s abuse policy. DOT Tech, LLC shall also reserve the right to report such recalcitrant Registrar activities directly to ICANN.

DOT Tech, LLC is committed to implementing strong and integrated Rights Protection Mechanisms (RPM). Use of domain names that infringe upon the legal rights of others in the TLD will not be tolerated. The nature of such uses creates security and stability issues for the registry, Registrars, and Registrants, as well as for users of the Internet in general. DOT Tech, LLC will protect the legal rights of others by implementing RPMs and anti-abuse policies backed by robust responsiveness to complaints and requirements of DOT Tech, LLC’s Registrars.

Trademark Clearinghouse

Each new gTLD Registry will be required to implement support for, and interaction with, the Trademark Clearinghouse (“Clearinghouse”). The Clearinghouse is intended to serve as a central repository for information to be authenticated, stored, and disseminated pertaining to the rights of trademark holders. The data maintained in the Clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service.

Utilizing the Clearinghouse, all operators of new gTLDs must offer: (i) a Sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a Trademark Claims Service for at least the first 90 days that second-level registrations are open. The Trademark Claims Service is intended to provide clear notice to a potential Registrant of the rights of a trademark owner whose trademark is registered in the Clearinghouse.

Sunrise Period

DOT Tech, LLC will offer a Sunrise Period. The Sunrise Period will last 60 days for owners of trademarks listed in the Clearinghouse to register domain names that consist of an identical match of their listed trademarks. All domain names registered during the Sunrise Period will be subject to DOT Tech, LLC’s domain name registration policies. DOT Tech, LLC will assign 3-5 employees to specifically work as the Rights Protection Team, these employees will receive and authenticate all Sunrise Registrations. The DOT Tech, LLC RPM team will specifically deal with trademark protection issues and mitigate or assist in resolving any rights protection issues which arise during the Sunrise processes.

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

DOT Tech, LLC will incorporate a Sunrise Dispute Resolution Policy (SDRP). The SRDP will allow challenges to Sunrise Registrations by third parties for a sixty-day period after the end of the Sunrise period on the following four grounds: (i) at time the challenged domain name was registered, the Registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the Registrant based its Sunrise registration; (iii) the trademark registration on which the Registrant based its Sunrise registration is not of national or regional effect or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name Registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

After receiving a Sunrise Complaint, DOT Tech, LLC’s RPM Team will review the Complaint to see if the Complaint reasonably asserts a legitimate challenge as defined by the SDRP. If not, DOT Tech, LLC’s RPM Team will send an email to the Complainant within thirty-six (36) hours of sending the confirmation email that the subject of the complaint clearly does not fall within one of the delineated grounds as defined by the SDRP and that DOT Tech, LLC considers the matter closed.

If the domain name is not found to have adequately met the SERs, DOT Tech, LLC RPM Team will alert the Registrar and registry services provider to immediately suspend the resolution of the domain name. Thereafter, DOT Tech, LLC’s RPM Team will immediately notify the Sunrise Registrant of the suspension of the domain name, the nature of the complaint, and provide the Registrant with the option to respond within ten (10) days to cure the SER deficiencies or the domain name will be canceled.

If the Registrant responds within ten (10) business days, its response will be reviewed by DOT Tech, LLC’s RPM Team to determine if the SERs are met. If DOT Tech, LLC’s RPM Team is satisfied by the Registrant’s response, DOT Tech, LLC’s RPM Team will submit a request to the Registrar and the registry services provider to un-suspend the domain name. DOT Tech, LLC’s RPM Team will then notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial.

Founder’s Program
Applications for the Founder’s Program will be accepted after the close of the Sunrise Periods. Potential Registrants should understand that certain expectations, as described herein will accompany the issuance of a domain name under the Founder’s Program and all registrations resulting from this program will be required to follow the below listed guidelines, which will be further described in their Program Agreement:
a) Registrants awarded a domain through the Founder’s Program must use their best efforts to launch a “.TECH” website within 30 days of signing the Program Agreement.
b) In addition, each Registrant will be required to issue a press release announcing the launch of their “.TECH” Founder Website, concurrent with the launch of their “.TECH” Founder Website, said press release must be approved by DOT Tech, LLC;
c) Founders are expected to proactively market and promote “.TECH” gTLD in a manner that is likely to produce widespread awareness of the unique advantages gained through the “.TECH” string.
d) Founders will allow DOT Tech, LLC to use in good faith Founder’s name, likeness, trademarks, logos, and Application contents (other than Confidential Information,) as well as other Founder information and content as may be mutually agreed, in DOT Tech, LLC’s marketing, promotional and communications materials.
DOT Tech, LLC will randomly verify compliance of the above listed expectations and have the right to revoke any Founder’s site, should they be deemed non-compliant. Additionally, DOT Tech, LLC may suspend or delete a Founder’s site without prior notice to the Registrar or Registrant if the Founder’s site is deemed in violation of any of DOT Tech’s registration guidelines or policies.
Registrants participating in the Founders program will receive 25% discounted registration, renewal pricing and term extensions (not to exceed 5 years) from DOT Tech’s Registrars as recognition for their participation in the Founders Program.
Landrush
Landrush is a limited time opportunity for companies that want to secure a high value “.TECH” name for a small fee (above the basic registration cost). The landrush period will last 30 days. Applications will be accepted and evaluated to determine if they meet the requirements for registration. At the end of the Landrush period domain names with only one application will be awarded directly to the Applicant. Domain names with two or more applications will proceed to a closed mini auction, between the respective Applicants, where the highest bidder wins.
General Availability Period
Applicant must meet all registration requirements.
Names will be awarded on a first-come, first serve basis which is determined as of the time of the initial request, not when authentication occurs.
Domain Name Contentions
Name contentions will arise when multiple applications for the same domain name are received during Sunrise and it will be resolved via auctions.

Auctions
Sunrise names found to be in contention as described above will result in Auction. DOT Tech, LLC plans to have a qualified third party conduct our auction processes, therefore the rules contained in this document are subject to change based on the selection of an auctioneer:
a) All auction participants are expected to keep their account information current, throughout the auction process.
b) Auction participants will receive up to date communication from the auctioneer as the auction progresses, bidding status changes, or issues arise.
Bidding
a) Auctions will follow a standard process flow: scheduled (upcoming), open and closed.
b) You will receive an “Auction Scheduled” notice at least ten (10) days prior to the scheduled auction start date. You will receive an “Auction Start” notice on the auction start date, which will indicate that you may begin placing bids through the interface. Once closed, the auction is complete and if you are the winning bidder, you will proceed to the payment process.
c) If you choose to bid for a particular domain and you are the highest bidder at the end of an auction, you are obligated to complete the transaction and pay the Auctioneer the amount of your winning bid. Carefully consider your bids prior to placing them - bids are not retractable under any circumstances.
d) If no bids are placed on a particular domain, the Registry will register the domain on behalf of the first customer (in the respective phase) to submit an application through a Registrar.
Extensions
a) A normal auction period is anticipated to last a minimum of 7 (seven) days. However, in the event of significant auction activity, an auction close may extend during the last twenty-four (24) hours of scheduled operation to better need the volume of the auction.
b) Auction extensions are meant to provide a mechanism that is fair for bidders in all time zones to respond to being outbid.
c) An auction extension will occur whenever the auction lead changes in the last twenty- four (24) hours of the schedule of an auction. The close will be revised to reflect a new closing time set at twenty- four (24) hours after the change in auction lead occurred. Essentially, this means that a winning maximum bid has to remain unchallenged for a period of twenty- four (24) hours before the auction will close.
d) It is important to note that extensions are not simply based on the auction value changing since this could occur as a result of proxy bidding where the same bidder retains their lead. In this case, the maximum bid has not changed, the leader has not changed and therefore no extension will occur.
Payment Default
In the event that you as the winning bidder decide not to honor your payment obligations (or in the event of a reversal of payment or a charge back by a credit card company or other payment provider) on any outstanding balance, the Registry has the right to cancel any⁄all of your winning registrations for any .TECH domain name, regardless of whether they have been paid for or not. You do not have the right to “pick and choose” the names you wish to keep or not keep. Winning an auction creates an obligation to remit payment. Failure to remit payment is a breach of your agreement.. You will lose any previously won domains and will no longer be allowed to bid on any current or future auctions sponsored by DOT Tech, LLC. Participants are encouraged therefore to consider carefully each bid submitted as any bid could be a winning bid.
Trademark Claims Service

DOT Tech, LLC will offer a Trademark Claims Service to provide maximum protection and value to rights holders. The Trademark Claims Service will be monitored and operated by DOT Tech, LLC’s RPM Team that will receive all communications regarding the Trademark Claims Service and catalog them. DOT Tech, LLC’s Registrar will review all domain name requests to determine if they are an identical match of a trademark filed with the Trademark Clearinghouse. A domain name will be considered an identical match when the domain name consists of the complete and identical textual elements of the mark, and includes domain names where (a) spaces contained within a mark that are either replaced by hyphens (and vice versa) or omitted; (b) certain special characters contained within a trademark are spelled out with appropriate words describing it (e.g., @ and &); and (c) punctuation or special characters contained within a mark that are unable to be used in a second-level domain name are either (i) omitted or (ii) replaced by spaces, hyphens or underscores. Domain names that are plural forms of a mark, or that merely contain a mark, will not qualify as an identical match.

If the Registrar determines that a prospective domain name registration is identical to a mark registered in the Trademark Clearinghouse, the Registrar will be required to email a “Trademark Claims Notice” (Notice) in English to the protective Registrant of the domain name and copy DOT Tech, LLC’s RPM Team. The Notice will provide the prospective Registrant information regarding the trademark referenced in the Trademark Claims Notice to enhance understanding of the Trademark rights being claimed by the trademark holder. The Notice will be provided in real time without cost to the prospective Registrant.

After receiving the notice, the Registrar will provide the prospective Registrant five (5) days to reply to the Trademark Claims Service with a signed document that specifically warrants that: (i) the prospective Registrant has received notification that the mark is included in the Clearinghouse; (ii) the prospective Registrant has received and understood the notice; and (iii) to the best of the prospective Registrant’s knowledge the registration and use of the requested domain name will not infringe on the rights that are the subject of the notice. If the warranty document satisfies these requirements, the Registrar will effectuate the registration and notify DOT Tech, LLC’s RPM Team.

After the effectuation of a registration that is identical to a mark listed in the Trademark Clearinghouse, the Registrar will provide clear notice to the trademark owner consisting of the domain name that has been registered and copy DOT Tech, LLC’s RPM Team. The trademark owner then has the option of filing a Complaint under the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS).

Uniform Rapid Suspension System (URS)

DOT Tech, LLC will specify in the Registry Agreement, all RRAs, and all Registration Agreements used in connection with the TLD that it and its Registrars will abide by all decisions made by panels in accordance with the Uniform Rapid Suspension System (URS). DOT Tech, LLC’s RPM Team will receive all URS Complaints and decisions, and will notify its Registrar to suspend all registrations determined by a URS panel to be infringing within a commercially reasonable time of receiving the decision. DOT Tech, LLC’s RPM Team will catalog all abuse communications, but only provide them to third-parties under limited circumstances, such as in response to a subpoena or other such court order or demonstrated official need by law enforcement.

Uniform Domain Name Dispute Resolution Policy (UDRP)

DOT Tech, LLC will specify in the Registry Agreement, all Registry-Registrar Agreements, and Registration Agreements used in connection with the TLD that it will promptly abide by all decisions made by panels in accordance with the Uniform Domain Name Dispute Resolution Policy (UDRP). DOT Tech, LLC’s RPM Team will receive all UDRP Complaints and decisions, and will notify its Registrar to cancel or transfer all registrations determined to by a UDRP panel to be infringing within ten (10) business days of receiving the decision. DOT Tech, LLC’s RPM Team will catalog all abuse communications, but only provide them to third-parties under limited circumstances, such as in response to a subpoena or other such court order or demonstrated official need by law enforcement.

Proven Registrars

In order to reduce abusive registrations and other activities that affect the legal rights of others, DOT Tech, LLC will only contract with ICANN-accredited Registrars. The Registrar, according to the RRA, will not be able to register any domain names, thus eliminating the possibility of front-running.

Thick WhoIs

DOT Tech, LLC will include a thick WhoIs database as required in Specification 4 of the Registry agreement. A thick WhoIs provides numerous advantages including a centralized location of Registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience.

Takedown Procedure

DOT Tech, LLC will provide a Takedown Procedure modeled after the Digital Millennium Copyright Act’s notice-and-takedown procedure.

At all times, DOT Tech, LLC will publish on its home website at NIC.TECH contact information for receiving rights protection complaints (Complaint) from rights holders, including but not limited to trademark and copyright Complaints. Complaints will be addressed to and received by DOT Tech, LLCs RPM Team who will catalogue and ticket in DOT Tech, LLC’s CRM software and review as outlined herein. DOT Tech, LLC will catalog all rights protection communications and only provide them to third parties under limited circumstances, such as in response to a subpoena or other such court order or demonstrated official need by law enforcement.

Any Complaint from a rights holder will be relayed to DOT Tech, LLC’s RPM Team. A member of DOT Tech, LLC’s RPM Team will then send an email to the Complainant within forty-eight (48) hours of receiving the Complaint confirming receipt of the email, and that DOT Tech, LLC will notify the Complainant of the results of the Complaint within (10) days of receiving the Complaint.

After sending the confirmation email, DOT Tech, LLC’s RPM Team will review the Complaint. If DOT Tech, LLC or its Registrar determines that the registration was in bad faith, DOT Tech, LLC or its Registrar may cancel or suspend the resolution of the domain name. Bad faith registration includes, but is not limited to, the registration of a domain identical to a registered trademark where the Registrant has proceeded with registration after receipt of a Clearinghouse notice, as described above.

If the Registrant responds within ten (10) business days, its response will be reviewed by the DOT Tech, LLC’s RPM Team. If DOT Tech, LLC’s RPM Team is satisfied by the Registrant’s response that the content has been taken down or is not infringing, DOT Tech, LLC’s RPM Team will un-suspend the domain name. DOT Tech, LLC’s RPM Team will then notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial. If the Registrant does not respond within ten (10) business days, DOT Tech, LLC or its Registrar may cancel or suspend the resolution of the domain name.

This Takedown Procedure will not prejudice any party’s election to pursue another dispute mechanism, such as URS or UDRP, as set forth in DOT Tech, LLC’s response to Question 28.

Except where specified this answer refers to the operations of Dot Tech LLC 's outsource Registry Service Provider, CentralNic.
30(a).1. Introduction
CentralNic's Information Security Management System (ISMS) has been certified against ISO 27001. A copy of the certificate issued by Lloyd's Register Quality Assurance (LRQA), a UKAS accredited certifier, is provided as Appendix 30.1.1. The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001.

30(a).2. Independent Assessment
As part of ISO 27001 compliance, CentralNic's security policies are subject to biannual external audit. Further details can be found in Q30(b).

30(a).3. Augmented Security Levels
Dot Tech LLC believes that the TLD requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, Dot Tech LLC and CentralNic will operate the TLD to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.
Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast ("Anycast") addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a "hot" Disaster Recovery site in the Isle of Man, as well as a backup provider relationship with GMO Registry in Japan.

30(a).4. Commitments to Registrars
Dot Tech LLC and CentralNic will make the following commitments to the TLD registrars:
*The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
*The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
*The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of the TLD.
*The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in Q43).
*Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
*Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
*Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.

30(a).5. Access Controls
CentralNic operates an access control policy for the registry system. For example, the web-based Staff Console which is used to administer the SRS and manage registrar accounts supports a total of ten different access levels, ranging from "Trainee", who have read-only access to a subset of features, to "System Administrator" who have full access to all systems.
Underlying server and network infrastructure is also subjected to access control. A centralised configuration manager is used to centrally control access to servers. Individual user accounts are created, managed and deleted via the configuration server. Access to servers is authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the "sudo" command which is logged and audited as described below.
Only operations personnel have access to production environments. Development personnel are restricted to development, staging and OT&E environments.

30(a).6. Security Enforcement
Security controls are continually monitored to ensure that they are enforced. Monitoring includes use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).
Since CentralNic operates a centralised logging and monitoring system (see Q42), access logs are analysed in order to generate access reports which are then reviewed by NOC personnel. This includes access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems is investigated with a view to correcting any breaches and/or revoking access where appropriate.

30(a).8. Security Incident Response Policy
CentralNic operates a Security Incident Response Policy which applies to all events and incidents as defined by the policy, and to all computer systems and networks operated by CentralNic.
The Policy provides a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It also defines the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).
The Policy established an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.
The Policy makes use of CentralNic's existing support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy also describes the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.

30(a).9. Role of the Network Operations Centre (NOC)
In addition to its role in managing and operating CentralNic's infrastructure, the NOC plays a key role in managing security. The NOC responds to any and all security incidents, such as vulnerability reports received from registrars, clients and other stakeholders; monitoring operator and security mailing lists (such as the DNS-OARC lists) to obtain intelligence about new security threats; responding to security-related software updates; and acting upon security alerts raised by firewall and intrusion detection systems.

30(a).10. Information Security Team
CentralNic maintains an Information Security Team (IST) to proactively manage information security. The IST is a cross-functional team from relevant areas of CentralNic. These key members of staff are responsible for cascading rules, regulations and information to their respective departments. They are also the first port of call for their departmental staff to report potential security incidences and breaches, the IST are all members of an internal email group used to co-ordinate and discuss security related issues.
The IST is comprised of the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.
IST responsibilities include:
*Review and monitor information security threats and incidents.
*Approve initiatives and methodologies to enhance information security.
*Agree and review the security policy, objectives and responsibilities.
*Review client requirements concerning information security.
*Promote the visibility of business support for information security company-wide.
*Manage changes to 3rd party services that may impact on Information Security
*Perform internal audits with the assistance of Blackmores.

30(a).11 Auditing and Review
ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. The IST periodically reviews the ISMS and conducts a gap analysis, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work.

30(a).12. Testing of Controls and Procedures
CentralNic will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both "black box" testing of public registry services such as Whois and the Registrar Console, "grey box" testing of authenticated services such as EPP, and tests of physical security at CentralNic's offices and facilities.
CentralNic will retain the services of a reputable security testing company such as SecureData (who, as MIS-CDS, performed the 2009 assessment of CentralNic's security stance). The results of this test will be used in annual reviews and audits of the ISMS.

30(a).13. Dot Tech LLC Security Policy
In addition to the security of our technical back-end by CentralNic, we will implement the following security measures in our offices:
The office building will have a 24⁄7 alarm system and cameras throughout the building, with a full view of entry and exits to the main areas. All critical physical and digital file storage areas are also closely monitored with controlled access.
The office doors are only accessible with access cards provided to employees. All entries and exits are recorded by the system. Access cards are de-activated as part of the employee discontinuation policy.
Access to sensitive areas are controlled by the electronic access control system managed by the IT team.
The facility will be designed to have 100% power backup in case of a power failure. Currently, we have generators which are capable of providing power backup to critical requirements like servers, workstations & lights for atleast 48 hours.
With regards to our company systems and network security, we have adopted the following policies and processes:
Password Policy: We have policies and procedures to manage the creating, changing, and safeguarding of passwords.
*A password cannot contain your User Name and cannot match your first or last name
*A password must contain at least eight characters, and contain at least one alphabetic character and one number
*The last three passwords cannot be re-used when changing to a new password
*Account lockout after 8 failed login attempts, reset only possible after logging a ticket to internal IT help desk team
*Passwords are force-changed every quarter

Systems Security Policy:
*We use well-known Anti-Virus/Malware tools that constantly run scans during off peak hours and are updated on a regular basis
*Automatic Screen locking systems for idle users to prevent unauthorized access
*Hard disk encryption with domain login password preventing data duplication if the hard drive is attached to a different system
*Access to information that is deemed sensitive, requires the input of the employee’s password in conjunction with the password of a member from senior management
*Password protected BIOS in each system preventing any hardware level tampering
*Phishing/Malware sites blocked on all browsers by our Internet Security tools
*Unauthorized software is blocked and only while-listed after proper business justification and approvals
*We have an internal process to back-up critical data on a regular basis
*Redundancy for our all Critical Applications and Servers is ensured

Network Security Policy:
*The default passwords are always reset on all network devices
*Firewall is configured to block outbound traffic from VLAN workgroups or entire network segments that have no business establishing client connections to internet servers
*Requests to our internal servers are blocked unless authorized explicitly
*Our wireless network is encrypted using a signed certificate
*VPN traffic is encrypted using a CA signed certificate
*DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports
*Inbound Internet traffic is limited to servers in DMZ zone only
*Servers that store data are on an internal network zone are segregated from the DMZ and other untrusted networks
*We occasionally run intruder detection tests to identify insecure services/protocols/ports
*We have processes to ensure that ios/firmware/patches to switches/firewall/routers are updated regularly
*Tests are run regularly to ensure the internet redundancy links are working fine on our edge routers

Intranet Security Policy:
*Constant collaboration with leading security vendors and experts on specific threats
*Internal Mails (Webmail, SMTP, POP3, IMAP) are only accessible via VPN
*Internal Mail over mobile device is password protected screen locks with remote wipe supported if the device is lost
*Penetrating tests for each system (including virtual machine/network device) are run to check for weak passwords and security vulnerabilities
*SSO (Single Sign On) login for all our internal sites only work over our VPN
*Security audit logs are archived for a year
*Revoking all privileges and re-setting access details as part of the employee discontinuation process
*Some of the monitoring tools we use internally are:
*Cacti
*Nagios
*Zenoss
*Pingdom
*Whats up gold
*Observium

We are and will continue to be working with CentralNic and other security experts to enhance physical and network security measures in addition to policy development and employee training.

Given that the string is a generic TLD that does not propose to offer unique security policies beyond those detailed; we will not be making specific security commitments to our registrants. We trust that we will become known for providing a safe and secure platform for individuals and companies.

© Internet Corporation For Assigned Names and Numbers.