ICANN New gTLD Application

The mission and purpose of the proposed .TELECITY Top Level Domain (TLD) is the creation and operation of a TLD dedicated to the Applicant, its brand, services and key customers. As such the objective is that the .TELECITY TLD will serve as an official, trusted, secure and dedicated name space for the TELECITY brand and services. To this end the Applicant seeks to launch the .TELECITY TLD and to create and operate an innovative and secure platform in a manner which is consistent with its subject matter whilst committing to the promotion of consumer trust, consumer protection and integrity of the .TELECITY TLD and the associated Internet space.

The Applicant is committed to ensure that it fully complies and meets or exceeds the requirements of ICANN in terms of competition, consumer protection, security, stability and resiliency, malicious abuse issues, and rights protection in relation to the expansion of the generic Top Level Domain name space by devising and implementing mechanisms in line with ICANN’s Consensus Policies and Temporary Policies.

The Applicant proposes to launch and operate the .TELECITY TLD to create a new Internet ecosystem dedicated to the Applicant and its Affiliates and to enable and facilitate potential innovations, creation and promotion of new initiatives from the Applicant. The domain name space associated with the .TELECITY TLD will create a new environment which will enhance diversity, choice and utility of the Domain Name System, based on a segmented approach, hence encouraging specialisation, differentiation, consumer recognition, and consumer choice in line with ICANN policy development.

In order to ensure the integrity, success and to build confidence in the .TELECITY TLD and the associated domain name space, the Applicant is dedicated to ensuring that appropriate safeguards are put in place with a view to protecting, among other things, public interest, customers, trade mark owners and other third party rights owners.

Operating and overseeing this new Internet space in a transparent, fair and efficient manner will be essential to create goodwill in the .TELECITY TLD and to develop confidence and trust in the .TELECITY TLD.

The fact that the Applicant intends to operate the .TELECITY TLD as a single registrant⁄single user registry model will allow the Applicant and its Affiliates to control the operations of the .TELECITY TLD and prevent violation of public interest, trade mark infringement and other types of malicious conducts. The .TELECITY TLD will thus create an environment where opportunities for abuse and malevolent conduct will be virtually eliminated.

Furthermore, the Applicant is dedicated to ensuring that the creation and operation of the .TELECITY TLD will not have an adverse or negative affect on the operational security and stability of the Internet and the Domain Name System.

The .TELECITY TLD will be a continuously evolving platform and serve as a base for potential innovative uses, content and services with a view to optimising specialisation, high level of service, reliable quality content, consumer trust and innovation.

The Applicant has considered potential uses of the .TELECITY TLD which would include creating second-level domain names that correspond with:

1. The specialisation areas of the Applicant and its Affiliates, such as:
COLOCATION.TELECITY
CLOUD.TELECITY

2. Internal management and information, such as:
LEGAL.TELECITY

3. Investor relations and corporate portal for key customers, such as:
INVESTOR.TELECITY
CUSTOMER.TELECITY

These are some of the potential uses which have been identified as being in line with the operation of the proposed .TELECITY TLD following the single registrant⁄single user registry model. In addition, the Applicant and its Affiliates will explore potential new ways of ensuring that the .TELECITY TLD is an environment which is conducive to innovation, consumer choice and recognition, business visibility and specialisation and may in this respect implement additional types of use of the .TELECITY TLD within the scope of the Registry Agreement to be executed before delegation of the .TELECITY TLD.

1.1 The TELECITY business

The Applicant is TelecityGroup International Limited, with its registered office at MASTERS HOUSE, 107 HAMMERSMITH ROAD, LONDON W14 0QH registered with the United Kingdom Companies House under Company No. 00153088.

TelecityGroup specialises in the design, build and management of highly connected, resilient and secure environments in which customers can house their telecoms, internet and IT infrastructure.

TelecityGroup is Europe’s leading provider of premium carrier-neutral data centres.

Headquartered in London, the Applicant and its Affiliates operate data centres in prime city centre positions in Amsterdam, Dublin, Frankfurt, London, Manchester, Milan, Paris and Stockholm. 
TelecityGroup provides premium data centre and colocation services in key connectivity hubs across Europe, designed to meet its customers data centre needs and connectivity requirements. Every data centre brings customers flexible, scalable, efficient and secure solutions with the widest choice of connectivity options.

A TelecityGroup data centre is a thriving, connected, digital ecosystem providing direct access to a wide choice of telecoms and content distribution networks, key internet exchange points, and cloud hubs, all of which facilitate the sharing, distribution and storage of data, content, applications and media.

To help their customers meet their security requirements, the Applicant and its Affiliates offer a range of security services including managed firewall, intrusion detection and prevention and DDoS mitigation.

The Applicantʹs comprehensive data backup, recovery and archiving services help keep its customers business-critical data protected and their business fully compliant with industry regulations for data retention. 

The Applicantʹs ultimate parent company is listed on the London Stock Exchange (LSE: TCY).

1.2 The TELECITY brand

Since its formation in April 1998, Telecity has acquired and constantly developed reputation and goodwill in its TELECITY brand and services worldwide through continuous and significant investment, use and effort.

The Applicant owns numerous trade mark registrations in the term TELECITY in many jurisdictions (including the European Union, the United Kingdom, the United States, Canada, New Zealand, Russia, China, Japan and Switzerland) in several classes of goods and services, including class 35 (business advisory services, information services), class 37 (equipment installation and maintenance, fault recovery and maintenance services), class 38 (rental of modems and telecommunications equipment, telecommunication services) and 42 (monitoring services, facilities management services, facilities management services for Internet service providers, facility management services for telecommunications service providers, rental of computers and software, software design services, computer and information technology consultancy services, provision of on-line Internet and telecommunication facilities).

Reflecting its global reach, the Applicant and its Affiliates own numerous domain names consisting of or comprising the term TELECITY in numerous available gTLDs (including under .COM, .INFO, .MOBI, .NET, .ORG, .TEL and .XXX), ccTLDs (including but not limited to .AT, .BG, .CH, .CN, .CO, .COM.ES, .COM.GR, .COM.PT, .COM.RO, .COM.RU, .CZ, .DE, .DK, .ES, .GR, .HK, .IE, .IN, .JP, .LI, .LU, .NL, .NU, .PT, .RO, .SE, .SI, .SK, .US, and .SG.) and regional TLDs (including .EU and .ASIA).

The TELECITY brand, trade marks and domain names are invaluable assets and serve to identify the TELECITY business as a trusted source of the highest quality goods and services.

The main goals of the .TELECITY TLD are specialisation, visibility, differentiation, innovation and enhancement of consumer recognition and trust.

Given the intended mission and purpose for the .TELECITY TLD, the volume of second level domain name registrations will not be a pertinent indicator to assess or measure its success.  The Applicant will rather focus and strive to achieve a high level of consumer recognition and trust in the .TELECITY TLD.

Operating and overseeing this new dedicated Internet space in a transparent, fair and efficient manner will be a key factor in creating goodwill in the .TELECITY TLD that will match the reputation the Applicant has developed in its brand.  As a result Internet users and customers of TELECITY will come to have the same levels of confidence and trust in the .TELECITY TLD.

The creation of a dedicated Internet name space which is indelibly associated with the TELECITY brand assurance of quality, will create a clear benefit to Internet users and to the Applicant and its Affiliates as it will establish certainty and trust as to the source of the content.

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

(a)	Goals in terms of speciality

The creation and operation of the .TELECITY TLD will create specialisation by creating a segment of the Domain Name System solely dedicated to the Applicant and its Affiliates.

Currently there is no Top Level Domain that specifically corresponds to the Applicant and to its businesses, brands, trade marks, services and key customers. Thus no existing Top Level Domain could conceivably deliver the level of specialisation which could potentially be achieved by the .TELECITY TLD.

Based on the significant goodwill and consumer recognition that the Applicant has acquired and developed in the term TELECITY, it is anticipated that the .TELECITY TLD will, by association, clearly and visibly demonstrate the specialised nature of the .TELECITY TLD resulting in consumer recognition and trust.  Internet users will know that they are getting genuine information and be able to access content, information and services relating to the Applicant by virtue of the .TELECITY TLD.

Specialisation is a key element for the Applicant and for the proposed creation and operation of the .TELECITY TLD.  It is anticipated that this drive for specialisation will in the future become the standard for Internet users, key customers and other third parties.  As such the .TELECITY TLD will provide a defined, unique and clear indication to Internet users that the .TELECITY domain name space is one that is dedicated to the Applicant.

Therefore, the .TELECITY TLD will be designed as a single source dedicated segment of the Internet and the Domain Name System where it will be possible to locate and access data in an efficient manner relating to the products and services of the Applicant and its Affiliates with the same level of trust which the Applicantʹs customers place in the Applicantʹs brand, all within a secure environment.

(b)	Goals in terms of service levels

The Applicant is fully committed to providing the highest levels of service in the course of the operation of the .TELECITY TLD.  Security is one of the cornerstones of the Applicantʹs business and as a result of this the Applicant and its Affiliates have extensive experience in data related and online security issues and would seek to deploy this experience in the .TELECITY TLD.

Given the Applicantʹs commitments in terms of service levels associated with the .TELECITY TLD, the Applicant has entered into contractual agreements for the provision of services by third party service providers who are all leaders in their respective fields of activity. Thus the Applicant is seeking to ensure that both its internal resources and third party service providers have the capacity to achieve the highest levels of service performance in the course of the operation of the .TELECITY TLD.

A key goal of the Applicant in the operation of the .TELECITY TLD will be to provide services in a highly secure environment so as to significantly reduce opportunities for malicious conduct. As the Applicant intends to operate the .TELECITY TLD following the single registrant⁄single user registry model, the Applicant will be able to fully control operation of the .TELECITY TLD and to ensure that services will be provided through the TELECITY TLD in a secured, reliable and trusted manner.

(c)	Goals in terms of reputation

The Applicant will use best endeavours to ensure that it operates the .TELECITY TLD in a manner that furthers its excellent reputation in terms of quality of content and service, security and compliance.

Since its formation in 1998, the Applicant has acquired and constantly developed reputation and goodwill in its TELECITY brand and services through continuous and significant investment, use and effort.

Thus, the creation, delegation and operation of the .TELECITY TLD will be consistent with the Applicantʹs continuously increasing use of its TELECITY brand and will allow the Applicant to further promote the Applicant and its Affiliates’ reputation for excellence, technological advancement, innovation and specialisation.

Given the increasing importance of the Internet as part of the Applicantʹs business and services, for instance as a result of the development of cloud computing, creating and operating a dedicated segment of the Internet is of utmost importance to the Applicant, its Affiliates and their credibility and reputation.

As the Applicant intends to operate the .TELECITY TLD following the single registrant⁄single user registry model, the Applicant will be able to fully control and oversee operation of the .TELECITY TLD. As a result, the .TELECITY TLD will by its very nature be associated with trusted and genuine content which will help the Applicant furthering the development of its reputation and consumer recognition in its TELECITY brand. Whilst the very nature of the .TELECITY TLD will help avoiding abuse and infringements, the Applicant is fully committed to address potential abuses and infringements in a timely and efficient manner if and when they occur.

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

(a)	Goals in terms of competition

The .TELECITY TLD will contribute to the creation of a more competitive Domain Name System by operating a Top Level Domain dedicated to a particular commercial entity and thus incentivising competitors to position themselves on this new market in order not to lose ground to the Applicant and its Affiliates and to potentially provide new services or content or existing services or content in new ways.

Thus the Applicant will contribute by its .TELECITY TLD initiative to the development of dedicated and specialised segments of the Domain Name Space and the diversification of content and services available on the Internet.

The .TELECITY TLD initiative, the specialisation, innovation and high level of consumer recognition and trust that the Applicant and its Affiliates anticipate to achieve through the .TELECITY TLD will likely trigger a reaction from other economic agents and thus indirectly lead to the creation and availability of new and improved resources, products, services, and contents on the Internet.  
Thus, the creation and operation of the .TELECITY TLD will benefit consumers by fostering innovation, competition, diversity of content and availability of specialised choices for consumers.

(b)	Goals in terms of differentiation

The .TELECITY TLD will be operated on a single registrant⁄single user registry model and second level domain names will be reserved for exclusive registration by the Applicant for the exclusive use of the Applicant and its Affiliates.

The .TELECITY TLD will, by its very nature, be highly distinctive and differentiated from all other Top Level Domains currently available and likely to be available in the future because it will be comprised of the Applicantʹs renowned and distinctive TELECITY brand.

Thus the .TELECITY TLD will clearly and officially indicate to users the source of the TLD.

The .TELECITY TLD and all second level domain name registrations under it will act as a clear corporate identifier of the source of the dedicated services or contents. 

Therefore, differentiation will be achieved in three ways:

•	At the Top Level
•	At the second level
•	Through dedicated content

(c)	Goals in terms of innovation

The Applicant and its Affiliates have established a reputation as a leading company in the field of technological innovation and the Applicantʹs purpose in applying for the .TELECITY TLD is to pursue further innovation and technological advancement through a new dedicated platform based on the creation of the .TELECITY TLD.

The .TELECITY TLD will serve as a base for allowing the Applicant and its Affiliates to provide their products and services to each other, their key customers and Internet users in innovative and diverse ways.

The .TELECITY TLD will be a new technological ecosystem for the Applicant and its Affiliates to take their mission of innovation further.

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

Given that the Applicant will operate and oversee the .TELECITY TLD on a single registrant⁄single user registry model, user experience will in this context refer to two types of use:

(a)	Exclusive use by the Applicant and its Affiliates

The Applicant will design a platform within the .TELECITY TLD which will allow the Applicant and its Affiliates to use this dedicated segment of the Internet in rationalised and unprecedented ways and allow access, experience, exchange, provision and updating of content and information.

Only the Applicant and its Affiliates will have the possibility to alter content with respect to domain names, to manage domain names and to take other actions necessary for the maintenance of domain names under the .TELECITY TLD.

(b)	Passive use by third parties

Whilst the exclusive use of the .TELECITY TLD will be reserved for the Applicant and its Affiliate, other users such as key customers will be able to access content, information and services within the .TELECITY TLD.

The .TELECITY TLD will provide a single, genuine, secure and trusted ecosystem where users worldwide will be able to experience and access content, information and services relating to the Applicant and its Affiliates. The specialisation and visibility of the .TELECITY TLD as the dedicated Top Level Domain of the Applicant and its Affiliates will provide considerable legitimacy and recognition to the .TELECITY TLD and thus be an online landmark for users worldwide.

By virtue of operating its own dedicated TLD registry this will enable the Applicant to ensure a high degree of content quality and integrity which should result in an optimal user experience within the new .TELECITY dedicated segment of the Internet name space.

18(b)(4):  Provide a complete description of the Applicant’s intended registration policies in support of the goals listed above.

The Applicant intends to create and operate the .TELECITY TLD as a single registrant⁄single user registry and will reserve domain names under the .TELECITY TLD for exclusive registration by the Applicant to the exclusion of other parties. Thus it will not be possible for individuals or entities who are not the Applicant to register domain names under the .TELECITY TLD.

In addition, the Applicant does not intend to sell, distribute or transfer control or use of any second level domain name registrations in the .TELECITY TLD to any party that is not an Affiliate of the Applicant as defined in the Draft New gTLD Registry Agreement in section 2.9 (c) version 2012-01-11.

As a result, rules and regulations aiming at protecting the public interest in the event of the opening of a TLD to general registration will not be relevant.

Accordingly the intended registration policies in support of the goals set out in the Applicantʹs .TELECITY TLD application will not contain provisions relating to registration by parties that are not the Applicant who will solely and wholly control and maintain registrations under the .TELECITY TLD.

Such policies will be consistent with all applicable ICANN’s Consensus Policies and Temporary Policies and the Applicant is committed to ensure that said policies are strictly complied with.

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

Given that the Applicant will operate the .TELECITY TLD on a single registrant⁄single user registry model, confidential information relating to the sole registrant (the Applicant) and exclusive users (the Applicant and its Affiliates) will be the responsibility of the Applicant and its Affiliates and will be addressed by existing internal policies implemented within the Applicantʹs organisation.

As Europe’s leading provider of premium carrier-neutral data centres, the Applicant and its Affiliates have extensive experience in data related and online security issues. The Applicant and its Affiliates have stringent policies and procedures in place in relation to access to their data centres, individual customerʹs racks and to security and protection of such data. The Applicant and its Affiliatesʹ policies, procedures and infrastructures help ensuring the protection of their customers business-critical data and that their business is fully compliant with industry regulations for data retention.  The Applicantʹs data centres are certified to several international standards including ISO 27001:2005 standard for security management which ensures best practice for security controls to protect information assets.  Detail of the Applicantʹs standards accreditation is available at http:⁄⁄www.telecitygroup.com⁄data-centre-industry-standards-accreditations.htm.

In addition, in relation to third party users who will visit the websites associated with domain names under .TELECITY, the Applicant will implement policies and procedures in line with its current policies contained in Telecityʹs website privacy policy available at the following URL http:⁄⁄www.telecitygroup.com⁄privacy-policy.htm. In relation to the information on users who will access content, information and services within the .TELECITY TLD, the Applicant will ensure that the operation of the .TELECITY TLD is at all times consistent with the Applicantʹs privacy policies as well as applicable laws and regulations.

The Applicant will seek to deploy this experience in the .TELECITY TLD with a view to protecting the privacy and confidential information of users.

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

It is anticipated that the use made of the .TELECITY TLD will continuously evolve so as to ensure adaptation and innovation mirroring market trends, consumer demand and fostering technological advancement.

As the Applicant identifies new demands, needs, innovative and beneficial types of uses, the Applicant may implement new types of use of the .TELECITY TLD.

Communication on the .TELECITY TLD and the services that it will offer will be crucial and the Applicant and its Affiliates will make extensive use of its in-house capabilities and experience.  In addition, the Applicant and its Affiliates will use preferred third party service providers if necessary to ensure efficient and visible communication, promotion and public information on the .TELECITY TLD and on the content, information and services available within this dedicated segment of the Internet.

Given that the Applicant intends to operate the .TELECITY TLD as a single registrant⁄single user registry, the Applicant will be the only registrant of second level domain names under the .TELECITY TLD to the exclusion of any other entity or individual.

In light of the intended structure and operating model of the .TELECITY TLD, the Applicant does not anticipate that its Top Level Domain will have any known negative consequences or cost implications to consumers.

The .TELECITY TLD operating model which will be based on the Applicant and its Affiliatesʹ sole control should actually create an environment with an unprecedented level of security, consumer trust, consumer protection, content quality and reliable indication of source.

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

The Applicant will be the only registrant of second level domain names under the .TELECITY TLD to the exclusion of any other entity or individual.

Given the closed nature of the proposed single registrant⁄single user registry model for the .TELECITY TLD, the Applicant does not anticipate that the scenario of multiple applications for a particular domain name could ever occur.

In view of the above, it is neither necessary nor pertinent within the context of the .TELECITY TLD to implement mechanisms to resolve multiple applications for a particular domain name.

For the sake of completeness, should the Applicant, after the delegation of the .TELECITY TLD, wish to apply to ICANN for a modification of its single registrant⁄single user registry model, then the Applicant undertakes that it will implement appropriate mechanisms to ensure resolution of multiple applications for a particular domain name in the most transparent and fair manner and in accordance with all applicable ICANN’s Consensus Policies and Temporary Policies.

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

The Applicant will be the only registrant of second level domain names under the .TELECITY TLD to the exclusion of any other entity or individual.

Given the closed nature of the proposed single registrant⁄single user registry model for the .TELECITY TLD, there are no cost benefits to implement for registrants given that the only registrant under the .TELECITY TLD will be the Applicant.

In view of the above, it is neither necessary nor pertinent within the context of the .TELECITY TLD to implement any cost benefits for registrants.

For the sake of completeness, should the Applicant, after the delegation of the .TELECITY TLD, wish to apply to ICANN for a modification of its single registrant⁄single user registry model, then the Applicant undertakes that it will implement appropriate mechanisms to achieve cost benefits for registrants in the most transparent and fair manner and in accordance with all applicable ICANN’s Consensus Policies and Temporary Policies.

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

The Applicant will be the only registrant of second level domain names under the .TELECITY TLD to the exclusion of any other entity or individual.

Given the closed nature of the proposed single registrant⁄single user registry model for the .TELECITY TLD, contractual commitments to registrants regarding price escalation will not be relevant to the Applicant’s mission or goals for the .TELECITY TLD.

In view of the above, it is neither necessary nor pertinent within the context of the .TELECITY TLD to implement the types of mechanisms contemplated by question 18(c)(3).

For the sake of completeness, should the Applicant, after the delegation of the .TELECITY TLD, wish to apply to ICANN for a modification of its single registrant⁄single user registry model, then the Applicant undertakes that it will implement appropriate mechanisms in order to comply with the Registry Agreement and all applicable ICANN’s Consensus Policies and Temporary Policies.

Introduction

TelecityGroup International Limited (ʺApplicantʺ) is aware of the substantial amount of work and effort that has gone into developing policy to address the issue of the reservation and release of geographic names under new gTLDs with valuable input from ICANNʹs Governmental Advisory Committee (GAC), the Generic Names Supporting Organisation Reserved Names Working Group, Registry Operators and from elsewhere within the ICANN community.

The Applicant is aware of the requirements set forth in the New gTLD Applicant Guidebook and the GAC advice with regard to protection of geographic names at the second level (or other levels) under .TELECITY and thus the Applicant has incorporated GAC advice as set out below.

As a result of this, the Applicant will implement appropriate measures to ensure that it meets its responsibilities and complies with these requirements as a gTLD Registry Operator with regard to both the reservation and release of such geographic names at the second level (or other levels).

Reservation of Geographic Names

The initial GAC advice on the protection of geographic names is contained in the GAC document “Principles Regarding New gTLDs” which was presented by the GAC on 28 March 2007.  At Section 2.7(a) of this document it is stated that new gTLD applicants should “adopt, before the new gTLD is introduced, appropriate procedures for blocking, at no cost and upon demand of governments, public authorities or IGOs, names with national or geographic significance at the second level of any new gTLD”.

Specification 5 of the New gTLD Registry Agreement provides further clarity and details the Schedule of Reserved Names at the Second Level (or other levels) in gTLD Registries, whereby the Registry Operator undertakes to reserve certain domain names and prevent them from being registered, delegated or used.  

Section 2 of Specification 5 of the New gTLD Registry Agreement requires that all two character labels are initially reserved.  This is to avoid conflicts and confusion with existing ccTLD extensions.

Section 5 of Specification 5 of the New gTLD Registry Agreement is more comprehensive and states that:

“5. Country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:

5.1. the short form (in English) of all country and territory names contained on the ISO 3166-
1 list, as updated from time to time, including the European Union, 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〉;

5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and

5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names”.

In order to meet this requirement regarding country and territory names, the Applicant will ensure that it is in possession of current copies of the aforementioned internationally recognized lists and that all labels contained therein are afforded the requisite levels of protection.

Accordingly the Applicant undertakes to ensure that all labels that match the above requirements will initially not be available for registration, delegation or use at the second level (or other levels).  In order to ensure that this is implemented correctly, all such labels will be blocked from registration by the Applicant in order to prevent their delegation and use.

Release of Reserved Geographic Names

Specification 5 of the New gTLD Registry Agreement also contains provisions for the release of country and territory names on the basis that agreement is reached with “the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN”.  In addition, the Applicant has thoroughly reviewed the .INFO methodology for reservation and release of country names.  

As specified throughout this application and as defined in the registration policies, Applicant plans to operate the applied-for TLD as a single registrant⁄single user registry with domain names being allocated only to the Applicant.  As such the Applicant will not permit any third party to register any second-level domain names within the TLD.

On this basis the Applicant would like to explore with ICANN and the GAC the possibility to seek to have the release of such reserved terms for the exclusive use by the Applicant and⁄or its Affiliates for promoting, providing information about and⁄or offering the Applicant’s goods and services directly to the customers or potential customers from the relevant country or territory indicated by the domain name.

At all times, the Applicant will ensure through internal guidelines that all reasonable efforts will be made to reduce user confusion regarding the source or affiliation of the geographic domain name, and that security measures will be taken to protect confidential third-party information in accordance with that geographic area’s data and financial privacy laws.

In addition to the above, the Applicant will also adhere to and implement ICANN policy with regards to the reservation and release of such terms as and when required.

Nominet, the registry services provider, will administer a comprehensive list of registry services all of which are developed, managed and maintained in house. The services Nominet will provide are:

- Operation of authoritative nameservers for .TELECITY
- Dynamic updates to zone files
- Extensible Provisioning Protocol (EPP)
- Dissemination of zone files
- Whois service (port 43 and web based)
- Searchable Whois
- Domain Name System Security Extensions (DNSSEC)
- Billing
- Customer support
- Abuse prevention

All registry services will be supported and reachable over both Internet Protocol (IP) Version 4 (IPv4) and IP Version 6 (IPv6).
It should be noted that Internationalised Domain Names (IDNs) are not being implemented for .TELECITY.

DNS operations

Nominet will operate authoritative nameservers for .TELECITY. The DNS constellation consists of a ʹhiddenʹ master nameserver, DNSSEC signer, one primary Unicast DNS node, six slave Unicast DNS nodes and four primary Anycast nodes.

Dynamic updates to zone files

All changes to nameservers for domain names result in an update to the .TELECITY zone file. All zone file changes are applied dynamically for the most rapid publishing to DNS. Propagation of updates through the nameserver network will be done using incremental zone transfer (IXFR).

EPP

An EPP system, compliant with Request for Comments (RFC) 5730 will be provided for registrars to register and administer domain names, contacts and nameservers. The EPP server is provided over TCP and is compliant with RFC 5734. EPP connectivity is protected using the Secure Sockets Layer (SSL) protocol.
Registrars may register new domain names in .TELECITY using the object definitions given in RFC 5731. Once a domain name is registered, the registrar of record will be able to update, renew, delete and query that domain name, using the respective operations as defined in RFC 5731. All registrars may issue domain check or domain transfer operations using the EPP system. If a domain transfer operation is requested, the correct authInfo value must be provided by the new registrar. The registrar of record is notified and has five days to prevent the transfer from occurring.

Registrars may also issue requests to create new contact and host objects, in compliance with RFC 5733 and 5732 respectively. Only the registrar of record may then issue requests to update, delete and query contact and host objects in line with those RFCs. A delete operation will only be successful if there are no domain names linked to the object. Host update operations will be successful only if all the domain names linked to the host are sponsored by that registrar.

All ICANN accredited registrars that have signed a .TELECITY registrar agreement will be eligible to use the EPP system. The identity of registrars will be verified with SSL certificates - if a valid SSL certificate is not used, the server will close the connection and no operations will be possible.
Registrars may only transform or query domain names if they are the registrar of record. The exception is for transfer operations, which may be requested by all registrars if they have access to the authInfo field for the domain name. The registrar of record may prevent transfer operations from completing.

Nominetʹs EPP server is fully standards compliant and all operations described by RFC 5730, RFC 5731, RFC 5732 and RFC 5733 will be accepted by the server. All inputs to the server are checked for validity and action is taken if an input will adversely affect the service provision. All data fields are sanitised to prevent Structured Query Language (SQL) Injection attacks. Bind variables are always used for database query statements. If a connection is open but unused for more than a given time, it is closed. If a registrar opens more than a given number of connections then the oldest connection is closed.
Nominetʹs EPP service is hosted at a primary data centre and fully replicated at a secondary data centre to ensure stability. Failover procedures are well practiced and comply with BS 25999.

The dot UK service Nominet currently provides accepts RFC compliant commands and meets all of the SLAs within Specification 10 of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11 (Specification 10) comfortably. In December 2011 Nominet handled an average daily load of more than 1.3 million EPP operations with a read-write ratio of 12 to 1. EPP availability has averaged at 99.9% over the 12 months to December 2011.

Dissemination of zone file data

Nominet will provide daily zone files to ICANNʹs Zone File Dissemination Partner using the format specified in RFC 1034 section 3.6.1 and RFC 1035 section 5. Transportation will be via a method agreed with them.

Zone server status updates

Nominet will update registrars on changes to zone server status using a variety of methods including:

- email updates
- zone server status web page
- RSS feeds
- Twitter updates

Whois Services

Nominet will provide a real time Whois service for domain names, nameserver data and for registrar data. The Whois may be accessed by any internet user either through a web-based portal or via the Port 43 service.

The Whois Service will accept Transmission Control Protocol (TCP) connections on port 43 at whois.nic.telecity. Queries, terminated as specified in RFC 3912 by a carriage return and line feed, will be accepted. If the domain name is registered in .TELECITY then Whois information will be returned to the client. If it is not then an appropriate error message is returned.

The web-based Whois will be available at whois.nic.telecity. The user may enter the domain name, nameserver or registrar into a web form and will receive a response.

For both interfaces, if the request cannot be parsed as a domain name, nameserver or registrar then an appropriate error message will be returned.
The Whois service that Nominet currently provides for dot UK handles an average of between 800,000 and 1,000,000 lookups per day. Over the year to December 2011, the average monthly availability for this service was 99.99%. The server is designed to allow the limiting of requests from a single IP address to prevent denial of service. Nominet also monitors usage and performs statistical analysis to detect distributed abuse of the Whois.

Searchable Whois

Nominet will provide a searchable Whois service. This will be available on subscription to internet users. Nominet have provided this service for the dot UK domain name registry since 2006.

Nominetʹs searchable Whois allows for wildcard searches to be made on the domain name and registrant name. Results can be then exported as a comma separated values (CSV) file. Nominet will also offer the facility to allow users to set up to 20 search terms to be monitored automatically. Notifications will be sent by daily email if domain names are registered matching these search terms.

DNSSEC

The .TELECITY zones will be signed using DNSSEC. Nominetʹs EPP server will support the DNSSEC extensions defined in RFC 5910 to allow DS records to be set in the zone.

Customer services

Nominet has a large customer support department from which it will provide support to registrars, registrants and other stakeholders.

Billing system

Nominet has developed a customised billing system for domain names. Whenever a chargeable event, such as a registration or renewal, occurs in the registry, a record is made in the billing system. This feeds through to the monthly invoicing runs.

The billing system has an automated and fully configurable credit management system. The available credit or funds are audited for all registrars with warnings sent using email if they run low. The system may be configured to set any credit limit for registrar, including a zero limit to allow no credit.
Nominet also provide an online service for registrars to pay invoices and to put money on account.

Abuse prevention

Nominet has extensive abuse prevention policies and measures which include the following:

- technical solutions to enforce usage policies
- Sharing information with registrars about notifications from anti phishing companies such as Netcraft
- Registry⁄registrar agreement policies to enforce good practice
- Checking the quality of Whois data

Stability

A registry service has an adverse effect on internet stability if it is not applicable with relevant authoritative standards or adversely affects the throughput, response time, consistency or coherence of responses to servers or end systems which are themselves operating in accordance with relevant authoritative standards.

Nominetʹs registry services will be fully stable as:

- They will full comply with all RFCs listed in specification 6 to the Registry Agreement
- All responses given will be consistent and coherent.
- Nominetʹs registry systems will be responsive, comfortably meeting all SLAs given in Specification 10.

Security

To prevent the unauthorised disclosure or access to information or to registry systems architecture and to prevent the unauthorised disclosure, alteration, insertion or destruction of registry data, Nominet secures its registry systems in a number of ways including, but not restricted to:

- Securing of networks using SSL
- Access to different network segments (both internally and externally) is controlled through firewalls, and VPNs
- VPN access uses two factor authentication.
- Role based authentication of users providing the lowest level of access required to perform required functions
- Permanently manned reception and CCTV
- Geographically diverse datacentres
- Two factor authentication for physical entry to datacentres - one of which must be biometric
- Regular penetration testing by an independent organisation
- Regular vulnerability scanning by an independent organisation

Availability and continuity

All components making up Nominetʹs .TELECITY Registry Services will be provided on duplicated load balanced servers. A minimum of two virtualised servers will be provisioned on separate server racks and configured to each handle half of the traffic. In the event of a problem with one server, the load balancers will automatically direct traffic to the other server. The servers will be set up so that in the event of the loss of one server, the remaining servers will have enough capacity to handle the traffic.

The architecture making up the .TELECITY Registry Services will be fully provisioned upon Nominetʹs primary datacentre and replicated in full on the secondary datacentre. The database on the secondary datacentre will be replicated to within a few seconds of the primary.

This architecture allows Nominet to have standard operating procedures to enable transition within minutes if necessary and this procedure will be practiced on a monthly basis with the secondary datacentre becoming the primary and vice versa.

SRS overview

Nominet, the registry service provider, will administer a Shared Registry System (SRS) consisting of an Extensible Provisioning Protocol (EPP) interface to the registry. The interface is compliant with Specification 6 (section 1.2) of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11, complying with Request for Comments (RFCs) 5910, 5730, 5731, 5732, 5733 and 5734.

The implementation of EPP for .TELECITY is based upon Nominetʹs current EPP service for dot UK and will be deployed on the same architecture as the dot UK domain.

Nominet has run the dot UK EPP for the last 8 years and the service is used by 900 registrars, representing over 6 million domains out of the total of 10 million on the register. The dot UK EPP service easily handles over 2 million transactions per day with an average availability for 2011 of 99.90%.

High Level SRS system description

The network infrastructure for Nominetʹs SRS consists of two firewalls, two EPP application servers, and two middleware servers. All are load balanced. This is shown in figure 24.1 of the attachment Q24_SRS_Figures.pdf. The server specifications are shown in table 24.1 of the attachment Q24_SRS_Tables.pdf.

Nominetʹs EPP architecture for .TELECITY has been designed using a three-tier architecture. The two EPP application servers handle connection management and authentication along with confirming that requests are well-formed. The two middleware servers handle all business logic and manipulation of domain names and their associated objects. Finally, the registry data is stored in an Oracle database.

All EPP application and middleware servers are load balanced using a pair of f5 Network Big-IP servers.

Like Nominetʹs dot UK implementation, the EPP network for .TELECITY will be fully reachable over Internet Protocol Version 6 (IPv6).

Interconnectivity with other registry systems

All registry systems connect to one clustered Oracle database, which provides a single point of truth and prevents the occurrence of conflicting registration data updates.

When a domain is registered by a registrar using EPP, an entry is made in the database representing that domain name. Because the Whois reads directly from this database, the domain immediately becomes visible in the Whois with no delay.

Whenever changes are made to nameservers - when domains are registered or deleted or the nameservers are modified - a row is inserted into a database table that represents a list of updates to be made to the zone file. These updates are then pushed into the DNS using the IXFR protocol.

If a domain name is registered or renewed, then the SRS service programmatically triggers an update to the billing system. A chargeable event representing the registration or renewal is generated which feeds into the monthly invoicing system.

Availability and continuity

All components making up Nominetʹs Registry Services, including the EPP service, are provided on duplicated load balanced servers. A minimum of two virtualised servers will be provisioned on separate server racks and configured to each handle half of the traffic. In the event of a problem with one server, the load balancers will automatically direct traffic to the other server. The servers will be set up so that in the event of the loss of one server, the remaining servers will have enough capacity to handle the traffic.

The EPP architecture is shown in Figure 24.1 of the attachment Q24_SRS_Figures.pdf. Nominet will provision the network in full on both their primary and secondary datacentres. In particular, the database will be replicated in both datacentres. Nominetʹs two datacentres will be connected by two 10GB dual path and geographically diverse links. Each link will have a latency of less than one millisecond. Replication between the two datacentres will be asynchronous but the replicated data will only be a few milliseconds behind that of the live data. Should connectivity to one datacentre fail, the other will automatically assume the role of being the primary datacentre. The two datacentres will be connected to Nominetʹs main office by 1GB links. This allows mechanisms to be put in place to avoid possible ʺsplit brainʺ scenarios where connectivity between the datacentres is lost but both believe the other is lost and assume the primary datacentre role. Each datacentre will have a multi-homed 100MB transit link to the outside world. This connectivity will be handled by six Tier-1 providers in order to ensure availability and redundancy. Nominet will also maintain 100MB links to peering points with Internet Exchanges such as the London Internet Exchange (LINX https:⁄⁄www.linx.net⁄) and the London Access Point (LoNAP http:⁄⁄www.lonap.net⁄) from each datacentre.

This architecture will allow Nominet to have standard operating procedures to enable transition within minutes if necessary and this procedure will be practiced on a monthly basis, with the secondary data centre becoming the primary and vice versa. The relational database in the secondary datacentre will be asynchronously updated from the primary using Oracleʹs Dataguard Maximum Performance architecture.

In the very unlikely scenario that connectivity was lost to both datacentres (such that none of the six Tier-1 providers could connect to either datacentre), Nominet will maintain a third datacentre in Geneva, Switzerland that will be able to provide essential registry services in such a catastrophe.

Nominet already has a comprehensive business continuity management system with a full set of business continuity plans in place and is certified to the British Standard for business continuity, BS25999-2:2007.

Scalability

Provisioning applications on load balanced virtual machines means that Nominet can easily provision further servers should the load increase. However, Nominetʹs experience with operating the dot UK top level domain with its 10 million domain names, indicates that two application servers will easily meet the performance requirements in Specification 10 of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11 (Specification 10).

The EPP service for .TELECITY will be deployed on dedicated virtual servers in Nominetʹs datacentre. The servers making up the .TELECITY EPP service will have their own dedicated resources as shown in Figure 24.1 of the attachment Q24_SRS_Figures.pdf.

Connectivity is shared with the other registry systems deployed at the datacentre for .TELECITY, dot UK and up to five other gTLDs. The total available bandwidth is 10 gigabits per second and the available connectivity for each service will be throttled to an appropriate level to both provide sufficient connectivity for the EPP traffic levels and to mitigate against the impact of any traffic surges.

Performance

Nominet measures the internal processing time of all commands submitted to the EPP server to ensure that the SLAs set out in Specification 10 are met. Recent performance and availability figures for this are given in table 24.2 of the attachment Q24_SRS_Tables.pdf.

Based on all projections Nominet is more than confident that the capacity and redundancy of the SRS system for the .TELECITY domain, with an expected maximum of 50 domain names after 2 years, will result in equal performance figures to the dot UK domain.

Resource plan

Nominet has fully developed its SRS systems with pre-launch testing to be done in 2012. Nominet has large development, infrastructure and customer support teams experienced in running all its dot UK services. Nominet will dedicate the following resources and time from these existing teams, as well as additional resources where appropriate, to the pre-launch and post launch maintenance tasks:

Pre-launch

- Testbed deployment: 5 days by a system administrator
- Testing: 5 days by a developer
- Packaging: 2 days by a developer
- Production deployment: 5 days by a system administrator

Total pre-launch resource time 17 days.

Post launch

- Customer support: 1 hour per week
- Technical support: 1 hour per week

Total post launch resource 2 hours per week.

Introduction

Registrars will use Extensible Provisioning Protocol (EPP) to register and administer domain names, nameservers and contact objects for .TELECITY. Nominet, the registry service provider, will administer an EPP server which is fully compliant with Request for Comments (RFCs) 5730 to 5734. DNSSEC extensions compliant with RFC 5910 will be implemented.

Grace periods as defined in RFC 3915 will not be implemented for .TELECITY. However, they have been included in the underlying architecture and can be added at any point.

Nominet will modify the EPP server as necessary to support and comply with any EPP extensions which may emerge from ICANNʹs policy making process.
The EPP interface fully supports the registration lifecycle given in the answer to question 27.

Technical Plan

Nominet is experienced in running a highly available EPP service and has provided such a service to dot UK registrars since February 2008. It is used by 900 registrars, representing over 6 million domain names out of the total of 10 million on the register. The EPP server is provided over TCP and is compliant with RFC 5734. EPP connectivity is protected using SSL. The dot UK EPP service easily handles over 2 million queries per day and the monthly percentage availability figures for the 12 months to December 2011 are shown in table 25.1 of attachment Q25_EPP_Tables.pdf.

The EPP implementation for .TELECITY has been designed and will be built to match the scope and size of the dot UK registry implementation outlined above.
The EPP system has been designed using a three-tier interface-middleware-database architecture. The backend registry database will be Oracle 11g R2 Enterprise Edition based. Duplicate nodes will be used to ensure stability. The middleware will handle all business logic and will be implemented using Java and the Spring Framework (www.springsource.org). The interface module will handle connectivity and authentication of commands, and will be implemented using Java and Netty (www.jboss.org⁄netty).

Domain Name Mapping (RFC 5731)

The EPP server for .TELECITY will implement the domain object mapping defined in RFC 5731 and the following commands for domain objects will be available to registrars, as specified in that RFC:

- Info command to query the attributes of a domain name, including its nameservers, contacts and status values.
- Check command to check if a domain name is registered and the likely success of a subsequent Create command.
- Transfer query to query the status of a previous transfer request.
- Create command to register a domain name.
- Delete command to cancel or ʺunregisterʺ a domain name.
- Renew command to renew a domain name and extend its expiry date.
- Transfer command to move a domain name to a new registrar. This command may also be used to accept or reject transfer requests made on domain names by other registrars.
- Update command to modify the attributes of a domain name.

Registrars can use the EPP update command to set status values on domain names to prevent operations as specified in RFC 5731:

- clientDeleteProhibited. If this is set, requests to delete the domain are rejected.
- clientRenewProhibited. If this is set, requests to renew the domain are rejected. Automatic renewal on expiry still occurs.
- clientTransferProhibited. If this is set, requests to transfer the domain are rejected.
- clientUpdateProhibited. If this is set, requests to update the attributes of the domain are prohibited
- clientHold. If this is set, the domain name is not published in the zone file.

Domain Name System Security Extensions (DNSSEC) extensions Mapping (RFC5910)

DS records may be added to domain names in .TELECITY using the EPP extensions defined in RFC 5910.

Host Mapping (RFC 5732)

The EPP server will implement the host object mapping defined in RFC 5732 and the following commands for host objects will be available to registrars as specified in that RFC:

- Info command to query the attributes of the host object.
- Check command to find if a host object exists in the registry and the anticipated success of a subsequent create command.
- Create command to add a host object to the registry.
- Delete command to remove a host object from the registry, provided there are no domain names linked to it.
- Update command to modify the IP addresses or status values for the host object. IP addresses are only set if the superordinate domain name for the host is in the .TELECITY registry.

Registrars will be able to use the EPP update command to set status values on host objects to prevent operations as specified in RFC 5732:

- clientDeleteProhibited. If this is set, requests to delete the host object will be rejected.
- clientUpdateProhibited. If this is set, requests to update the attributes of the host object - to add or remove IP addresses or status values - will be rejected.

Contact Mapping (RFC 5733)

The EPP server for .TELECITY will implement the contact object mapping defined in RFC 5733 and the following commands for contact objects will be available as specified in that RFC:

- Info command to query the attributes of a contact object
- Check command to determine if a client identifier has been provisioned in the registry and the anticipated success of a subsequent create command.
- Transfer query command to query the status of a previously requested transfer operation.
- Create command to add a new contact object to the registry.
- Delete command to remove a contact object from the registry, provided no domain names are linked to it.
- Transfer command to move the object to a new registrar.
- Update command to modify the attributes of a contact object.

Registrars will be able to use the EPP update command to set status values on contact objects to prevent operations as specified in RFC 5733:

- clientTransferProhibited. If this status is set then requests to transfer the contact will be rejected.
- clientDeleteProhibited. If this status is set then requests to delete the contact will be rejected.
- clientUpdateProhibited. If this status is set then requests to update the contacts attributes will be rejected.

Resource Plan

The EPP server for .TELECITY has been implemented with pre production load testing and customisation to be completed in 2012. Nominet has large development, infrastructure and customer support teams experienced in running all its dot UK services. Nominet will dedicate the following resources and time from these existing teams, as well as additional resources where appropriate, to the post launch maintenance tasks:

- Monitoring and involvement in EPP standards development: 1 hour per week by a research team member and development team member.

Resources for technical and customer support of EPP have been included in the answer to question 24 and are not duplicated here.

High-level System Description

Nominet, the registry service provider, will provide a real time Whois for domain names, nameserver data and for registrar data. The Whois may be accessed by any Internet user either through a web-based portal or via the port 43 service. A searchable Whois will also be provided.

The Whois services interface with the rest of the registry via a shared database. This ensures that data is correct and up-to-date, and a correct response can be generated at the instant that a query is received. The searchable Whois maintains its own cache for efficiency, which is refreshed hourly, directly from the shared registry database.

The services are implemented in a virtualised architecture (see Q32) and share a common infrastructure.

Standards compliance

The .TELECITY Whois service will be compliant with Specification 4 of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11 (Specification 4). It will be available on whois.nic.telecity. The Whois services (port 43 and web based) respond as described in Specification 4; an outline for this is presented in the paragraphs ʺData Objectsʺ below.

The web-based Whois will also be available at whois.nic.telecity as required by specification 4. The user may enter the domain name, nameserver or registrar into a web form and will receive a response. If the request cannot be parsed as any of these three categories then an appropriate error message will be returned.

The Whois service will be compliant with Request for Comments (RFC) 3912. As specified by the RFC, the Whois service will listen on Transmission Control Protocol (TCP) port 43 for requests from clients. If a valid request, terminated as specified in RFC 3912 by an ascii carriage return and line feed, is received then a response will be returned.

Performance and availability of the Whois service exceed the requirements given in Specification 10 of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11.

Data objects

The Whois services (port 43 and searchable) respond as described in Specification; an outline for this is presented in the paragraphs below.

Data objects: Domain names

If a request for a valid and registered .TELECITY domain name is received by either Whois interface then a response will be returned displaying information about that domain name in the key-value pair format described in Specification 4. The following information will be returned:

- Domain Name
- Whois server
- Dates - creation, last update, expiry
- Registrar details
- Any status values
- All contact details - Registrant, admin, tech and billing
- Nameserver information including Domain Name System Security Extensions (DNSSEC) status information.
- Time of last update of Whois database, which is the time at which the lookup was made.

If a valid request is received and parsed as a domain name, but the domain name is either not registered or out-of-registry then an appropriate error message will be returned.

Data objects: Hosts

If a request for a nameserver held within the registry is received then a response will be returned displaying information about that nameserver. Nameserver information will be displayed in the key value pair format described in Specification 4. The following information will be returned:

- Nameserver name
- Internet Protocol (IP) addresses, both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6)
- Registrar information
- Time of update of the Whois database, which is the time at which the lookup was made.

If a request is parsed as a nameserver but is not in the registry then an appropriate error message will be returned.

Data objects: Registrars

If a request for a .TELECITY registrar is received then a response will be returned displaying information about that registrar in the key-value pair format described in Specification 4. The following information will be returned:

- Name
- Address
- Contact name, phone numbers, fax numbers and email addresses.
- Website information

If a valid registrar Whois request is received and the requested registrar is not in the registry then an appropriate error message will be returned.

Bulk access

Nominet will provide ICANN with bulk access to Whois data as described in Specification 4:

- Nominet will provide a weekly data file, using the Data Escrow format described in Specification 2 of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11 (Specification 2), containing the thin Whois data described in Specification 4. The file will be made available to ICANN for download by SFTP. Other download methods will be provided to ICANN if requested in the future.

- In the case of registrar failure or other event that prompts the transfer of a registrars domain names to another registrar, Nominet will provide ICANN with up-to-date data for the domain names affected. Nominet will provide the data to ICANN in the Data Escrow Format described in Specification 2 within two business days. The file will be made available for download by SFTP or by any other method agreed with ICANN.

Data Protection

Nominet will ensure that data supplied by registrants is protected in accordance with all applicable laws (specifically the UK Data Protection Act 1998 and the European Union (EU) Data Protection Directive which informed it), including through an appropriately designed Whois implementation.

It should be noted that EU data protection laws place significant restrictions on the circumstances under which personal data can be distributed to the public. The Information Commissioner’s Office (the UK data protection authority to which the registry would be subject) has indicated to Nominet that the indiscriminate publishing of the personal data of individual registrants via the Whois would not be compatible with EU data protection laws. They regard an opt-out model of the kind used by dot UK and dot TEL to be the best compromise between ensuring the integrity of the Whois and protecting the data protection rights of individuals.

It is not intended to allow consumers to register domain names in .TELECITY as it is a closed registry. In the event that consumers are invited to register domain in .TELECITY, they be given the option of preventing their addresses from appearing on the Whois. This will be implemented using the 〈contact:disclose〉 field of the EPP contact mapping defined in RFC 5733.

Abuse

Potential forms of abuse to a Whois service include:

- Harvesting data - querying all domain names to provide a catalogue of contact details.
- Denial of service - making many connections to the Whois server, or flooding connections with data.
- Structured Query Language (SQL) Injection - crafting queries to the service to attempt to modify the underlying database.

The Whois server has a number of measures built into it to prevent such abuse:

- If a clientʹs request is not terminated within a reasonable number of characters then the connection with the client is closed automatically.
- Whois lookups are checked and sanitised to prevent SQL injection attacks.
- Bind variables are always used in all our database queries to prevent SQL injection attacks.
- The Whois server is implemented in a way that allows a limit to be placed on lookups from any single location.

Statistical analysis on lookups to detect distributed abuse is also performed.

Stability, availability and performance

Nominet is experienced in providing a stable Whois system and has done so for dot UK for many years. The Whois server is provided on a primary data-centre and fully duplicated on a secondary data-centre. Failover procedures are well practiced.

Percentage availability figures for the dot UK Whois are shown in table 26.1 of attachment Q26_Whois_Tables.pdf

Performance and availability will exceed the requirements given in Specification 10 of the new gTLD Agreement.

Searchable Whois

Nominet will provide a searchable Whois service to Internet Users on a subscription basis. Nominet has provided this service for the dot UK domain name registry since 2006 (known as the Public Register Search Service (PRSS)).

The Searchable Whois technology enables wildcard searches to be made on any fields, including:

- domain name
- registrant name
- postal address
- contact names
- registrar ids
- nameservers
- IP addresses

Searches on multiple fields may be combined using boolean logic.

Results can be exported as a comma separated values (CSV) file. Nominet also has the facility to allow users to set up to 20 search terms to be monitored automatically. Notifications are sent by daily email if domain names are registered matching the search terms.

The searchable Whois uses a separate database to the main Whois. This database uses the search and indexing technology provided by Apache Solr (http:⁄⁄lucene.apache.org⁄solr) to provide optimum search facility and speeds. The search database will be synchronised with the main registry database on an hourly basis.

The Searchable Whois has measures to detect and deal with abuse, similar to those for the port 43 Whois (see above).

Whois Architecture

The Whois server obtains its information directly from the main registry database so its responses are real time. The Whois server is developed in Java using the Spring Framework. Connection management is implemented using Netty (www.jboss.org⁄netty).

The Port 43 Whois infrastructure is shown in figure 26.1 of attachment Q26_Whois_Figures.pdf

The Port 43 Whois server specifications shown in table 26.2 of attachment Q26_Whois_Tables.pdf

The Searchable Whois Architecture is as shown in figure 26.2 of attachment Q26_Whois_Figures.pdf

The Searchable Whois server specifications are shown in table 26.3 of attachment Q26_Whois_Tables.pdf

The Searchable Whois is implemented as part of Nominetʹs interactive online services using the Spring Framework. The front end handles the interface with the user, including authentication, taking details of the search required and presenting the results. The middleware handles the mechanics of the search.
The front end and middleware servers are each provisioned as a load balanced pair, using the same load balancer topology and technology as the main Whois architecture above, namely a pair of F5 Networks big-IP servers.

The Whois service for .TELECITY will be deployed on dedicated virtual servers in Nominetʹs datacentres. The servers making up the .TELECITY Whois service will have their own dedicated resources as shown in Figure 26.1 of the attachment Q26_Whois_Figures.pdf.

Connectivity is shared with the other registry systems deployed at the datacentre for .TELECITY, dot UK and up to five other gTLDs. The total available bandwidth is 10 gigabits per second and traffic through each server will be throttled to an appropriate level to both provide sufficient connectivity for the Whois traffic levels and to mitigate against the impact of any traffic surges.

It is estimated that there will be a maximum of 1,000 Whois lookups per day. The .TELECITY Whois service is provisioned to handle more than 1,000,000 lookups per day.

IT and infrastructure resources

Nominetʹs two datacentres will be connected by two 10GB dual path and geographically diverse links. Each link has a latency of less than one millisecond. Replication between the two datacentres will be asynchronous but the replicated data will be only a few milliseconds behind that of the live data. Should connectivity to one datacentre fail, the other will automatically assume the role of being the primary datacentre.

The two datacentres will be connected to Nominetʹs main office by 1GB links. This allows mechanisms to be put in place to avoid possible ʺsplit brainʺ scenarios where connectivity between the datacentres is lost and both believe the other is lost and assume the primary datacentre role. Each datacentre will have a multi-homed 100MB transit link to the outside world. This connectivity will be handled by six Tier-1 providers in order to ensure availability and redundancy. Nominet will also maintain 100MB links to peering points with Internet Exchanges such as the London Internet Exchange (LINX https:⁄⁄www.linx.net⁄) and the London Access Point (LoNAP http:⁄⁄www.lonap.net⁄) from each datacentre.

The Whois infrastructure is described in the preceding paragraph ʺWhois Architectureʺ.

Service continuity

Nominet will provide the Whois network architectures shown in figures 26.1 and 26.2 of attachment Q26_Whois_Figures.pdf in a primary datacentre and replicated in full in a secondary datacentre. The registry database is replicated from the primary datacentre to the secondary using Dataguardʹs Maximum Performance Replication. The SOLR index is generated on both datacentres for the searchable Whois. This architecture allows Nominet to have standard operating procedures to enable transition within minutes if necessary and this procedure will be practiced on a monthly basis. The Whois servers maintain high availability via SAN and virtualisation replication technologies. Should connectivity to the primary datacentre be lost the service will instantly be available in the secondary datacentre.

Customisation of Whois service

Nominet will customise the .TELECITY Whois service as required to handle any change in Whois output that may be deemed necessary by ICANN.
Resource plan

The .TELECITY main Whois service has been implemented, with pre production testing and customisation to be completed in 2012. Nominet has large development, infrastructure and customer support teams experienced in running all its dot UK services. Nominet will dedicate the following resources and time from these existing teams, as well as additional resources where appropriate, to the pre-launch and post launch maintenance tasks:

Pre-launch

- Test bed deployment: 5 days by a Systems administrator
- Pre-launch load testing: 5 days split between a systems administrator and a java developer
- Packaging for production: 2 days by a java developer
- Deployment to production: 5 days by a systems administrator

Total pre launch resource time 17 days.

Post launch

- Customer support: 8 hours per week
- Technical support: 4 hours per week
- Monitoring of and involvement in Whois standards development: 2 hours per week by a research team member and member of development team

Total post launch resource 14 hours per week.

Nominet, the registry provider, has implemented a lifecycle for .TELECITY domains which is based around Request for Comments (RFCs) 5730 and 5731. These RFCs define the Extensible Provisioning Protocol (EPP) interface for domain names including domain name registrations, updates, transfers, renewals and deletes.

Because the registry is closed, grace periods, as defined in RFC 3915, have not been implemented for .TELECITY.

Registrars who have signed a .TELECITY registry⁄registrar agreement will be able to register domain names that are not already registered for a period of one to 10 years. Registrars are able to renew their domain names to extend the registration period and may also delete domain names. If a domain name reaches the end of its registration period then it is automatically renewed for one year. If a domain is cancelled then it becomes immediately available for re-registration.

The lifecycle for .TELECITY domain names is shown in the state diagram in Figure 27.1 of attachment Q27_Registration_Lifecycle_Figures.pdf. Domain name states, which represent the stage that a domain name is at in the lifecycle, are shown in boxes. Trigger points, representing events that move a domain name onto a new stage in the lifecycle, are shown by arrows on the diagram. A domain name can also change state as the result of the passage of time. Domain name states are described below:

State: Available for registration

A domain name in this state is not registered and may be registered on a first come, first served basis by a registrar. The only EPP command that may be performed on the domain name is a 〈create〉 command to register the domain name.

State: Registered

This is the default state for a registered domain name. The registrar of record may use EPP to perform 〈update〉, 〈renew〉, 〈transfer〉 or 〈delete〉 commands.

State: Renewed

A domain name is in this state immediately after it has been successfully renewed, either by the registrar or automatically by the registry at expiry.
Trigger points represent the events that cause a domain name to change state, that is to move to a new stage in the lifecycle. The trigger points are described below:

Trigger point: create

This trigger point represents the registration of new domain names. Any registrar, that has signed a registry-registrar agreement for .TELECITY, may use the EPP 〈create〉 command to register a new domain name subject to the following pre-conditions:

- The domain name is a sub-domain of .TELECITY.
- The domain name is in the ʺavailable for registrationʺ state and so not already registered.
- The domain name is not reserved.
- The domain name consists only of the lower case ascii letters a-z, the numbers 0-9 or a hyphen -.
- The domain name does not have hyphens in the third and fourth characters.
- The domain name label does not begin or end with a hyphen.

If the above pre-conditions hold, a registration request will be successful and the domain name will be added to the registry database. The registration period and expiry date will be set according to the period specified in the 〈create〉 command. Following this, if the domain name has nameservers, a dynamic update will be made to add the domain name to the zone file.

All registration requests are performed immediately and there is no pending state.

Following registration, the domain name moves into the ʺregisteredʺ state.

Trigger point: renew

A domain name may be renewed, at any time by the registrar of record using the EPP 〈renew〉 command, subject to the following pre-conditions:

- The resultant expiry date for the domain name is less than 10 years in the future
- The domain name does not have either clientRenewProhibited or serverRenewProhibited locks set.

If these preconditions hold then the renewal will take place and the expiry date for the domain name will be extended by the period specified in the renewal request. The domain name moves into the ʺrenewedʺ state.

Trigger point: auto-renew

A .TELECITY domain name will be renewed by the registry if the following pre-conditions hold:

- The expiry date for the domain name has passed.
- The domain name does not have either clientRenewProhibited or serverRenewProhibited status values set.
The expiry date will be moved forward by one year and the domain name is placed into the ʺrenewedʺ state.

Trigger point: complete-renew

This trigger point occurs immediately after a domain name is placed into the ʺrenewedʺ state. The domain name is placed back into the ʺregisteredʺ state.

Trigger point: delete

A registrar may use the EPP 〈delete〉 command to cancel a domain name at any time provided the following pre-conditions hold:

- The registrar is the registrar of record for the domain name.
- The domain name does not have either serverDeleteProhibited or clientDeleteProhibited locks set.

Once a domain name has been deleted, it is placed into the ʺavailable for registrationʺ state and is immediately available for re-registration.

Grace Periods

Grace periods are defined in RFC 3915 and add registration states and trigger points to implement time periods following registrations, renewals, transfers and cancellations where the command can be reversed without penalty. Because .TELECITY is a closed registry, there is no penalty for undoing any of these commands at any time and grace periods are therefore not required. If, at any time, .TELECITY is opened up then grace periods can be easily added.

Domain Transfers

Domain transfers follow the process described in ICANN policy on transfer of registrations between registrars.

When a domain name is in the ʺregisteredʺ state, any registrar may issue a transfer request to move sponsorship of the domain to them. Transfer requests take up to 5 days to complete, during which time the registrar of record may reject the transfer and prevent it from completing.

The transfer process state diagram is shown in Figure 27.2 of the attachment Q27_Registration_Lifecycle_Figures.pdf. Domain name states are shown in boxes with arrows depicting the events that trigger change of state. The states and trigger points are described below.

State: registered

Any currently registered domain name may be transferred.

State: transfer pending

A domain name in the ʺtransfer pendingʺ state has had a transfer request submitted within the last 5 days and the registrar of record has neither accepted nor rejected the request.

When a domain name has been in the ʺtransfer pendingʺ state for 5 days, the ʺtransfer pendingʺ state is removed and the ʺtransfer acceptedʺ state is added.
State: transfer accepted
A domain name in the ʺtransfer acceptedʺ state has had a transfer request accepted, either directly by the registrar of record positively accepting the request using EPP or indirectly by the domain spending 5 days in the ʺtransfer pendingʺ state.

Trigger point: transfer request

A registrar may request a transfer for a domain name at any time provided the following preconditions are true:

- The registrar has signed a .TELECITY registry-registrar agreement
- The registrar can provide the correct authInfo value
- The domain name does not have the transfer pending status set
- The domain name does not have either the clientTransferProhibited or serverTransferProhibited locks set.

The transfer pending status is added to the domain name for five days and the registrar of record is notified. If, after five days, the ʺtransfer pendingʺ state is still set, the domain name is moved to the requesting registrar and the ʺtransfer pendingʺ state is removed.

Trigger point: reject transfer

The registrar of record may reject a transfer request when the domain name is in the ʺtransfer pendingʺ state. The ʺtransfer pendingʺ state is removed and the domain name returns to the ʺregisteredʺ state.

Trigger point: accept transfer

The registrar of record may accept a transfer request when the domain name is in the ʺtransfer pendingʺ state. The ʺtransfer pendingʺ state is removed and the domain name has the ʺtransfer acceptedʺ state added.

Trigger point: transfer

This trigger point happens immediately after the domain name has the ʺtransfer acceptedʺ state set.

The domain name is moved to the registrar that requested the transfer, the ʺtransfer acceptedʺ state is removed and the domain name returns to the ʺregisteredʺ state.

If a registration period was specified in the request, and adding that period to the current expiry date will result in the expiry date being less than 10 years in the future, then the domain is renewed for the period requested. The renew trigger point in the registration lifecycle described above is triggered.

Domain name attribute updates

A registrar may update the attributes of a .TELECITY domain name at any time provided the following preconditions are true:

- The registrar is the registrar of record for the domain name
- The domain name does not have either clientUpdateProhibited or serverUpdateProhibited locks set

The registrar may change the nameservers, add or remove contacts, or add or remove a lock.

If the clientUpdateProhibited lock is set and the other preconditions above hold then the registrar of record may remove the clientUpdateProhibited lock only.

Nominet would make updates to .TELECITY domain names upon direct request by Telecity themselves. This may include a transfer or addition of one of the registry set domain locks listed below.

Domain name locks

The registry and registrar of record may place locks upon the domain name to prevent EPP commands from succeeding. The registrar of record may place the following locks upon a domain name:

- clientUpdateProhibited to prevent update of the domain nameʹs attributes
- clientDeleteProhibited to prevent cancellation of the domain name
- clientTransferProhibited to prevent transfer of the domain name
- clientRenewProhibited to prevent renewal of the domain name
- clientHold to prevent publication of the domain name in the zone file.

The registry may place any of the following locks upon a domain name:

- serverUpdateProhibited to prevent update of the domain nameʹs attributes
- serverDeleteProhibited to prevent cancellation of the domain name
- serverTransferProhibited to prevent transfer of the domain name
- serverRenewProhibited to prevent renewal of the domain name
- serverHold to prevent publication of the domain name in the zone file.

Resourcing plan

Nominetʹs registry systems supporting the lifecycle in this document have been fully developed. Nominet has large development, infrastructure and customer support teams experienced in running all its dot UK services. Nominet will dedicate the following resources and time from these existing teams, as well as additional resources where appropriate, to the following post launch maintenance tasks:

Post launch:

- Technical support: 1 hour per week by a customer support advisers

Total post launch resource: 1 hour per week.

This support level is consistent with the number of registrars and domain names that will be registered in the .Telecity TLD.

The .TELECITY Top Level Domain (TLD) will be a single registrant ⁄ single user registry. All domain names will be registered to and used by authorised representatives of Telecity, the registry operator. As such, domain names will be subject to direct controls by the registry operator to avoid abuse and the risk of abusive registrations and uses will therefore be virtually eliminated or at least significantly mitigated.

Abuse

Abuse is defined as action in the registration or usage of a domain in the TLD that would cause actual and substantial harm, and is illegal or illegitimate. Such abuse may occur at any stage of the domain name lifecycle.

In the context of domain name registration, abuse includes infringement of a third party right where the domain is used in a way that is unfairly detrimental to that third party. Abuse also includes phishing, pharming, botnets, fraud and other abuses that are identified in the future or that are brought to the Registry’s attention.

Abusive activity also includes that which gives rise to the Registry’s reasonable belief that the .TELECITY domain space is being brought into disrepute; or where the activity related to a .TELECITY domain name risks placing the Registry in breach of any applicable laws, government rules or requirements; requests of law enforcement; or where any such activity would be likely to give rise to any liability, civil or criminal, on the part of the Registry Operator and Registry Services Provider, affiliates, subsidiaries, officers, directors, and employees.

Single point of contact

In advance of the launch of the .TELECITY TLD, a single abuse point of contact responsible for addressing matters requiring expedited attention will be published. This will be clearly visible on the registryʹs existing website at Telecitygroup.com and on the new Registry website.

Registration policy

Telecity will establish a Naming Committee to be responsible for the development, maintenance and enforcement of the .TELECITY Registry Domain Management Policy (DMP). This policy defines the rules associated with eligibility and domain name allocation, sets out the license terms governing the use of a .TELECITY domain name and describes the dispute resolution policies for the .TELECITY TLD. This policy is intended to be updated and revised regularly to reflect Telecity’s strategic plans and, where appropriate, ICANN consensus policies.

The policy sets out that registration must comply with the following regarding abuse prevention:

- Domains must be used solely for purposes that enhance the strategic goals of Telecity.
- .TELECITY domain names may not be used in a way which knowingly infringes any third party intellectual property rights.
- A .TELECITY registration must be an acceptable term that will not give rise to any moral or public order questions or in any way damage the strategic interests or reputation of Telecity.
- All .TELECITY domain names will carry accurate and up to date registration records.
- .TELECITY domain names may not be used for illegal activities
- .TELECITY domain names may not be used for other activities that would be considered as abusive or malicious. This includes, but is not limited to: phishing, pharming, fraud, distribution of malware.

The Naming Committee reserves the right to place the domain name in ʹserverHoldʹ status, thus removing it from the zone file, or to delete a Telecity domain name at any time.

Complaints policy and procedure

Telecity treats complaints from members of the public extremely seriously and will establish a complaints procedure to enable members of the public to complain about .TELECITY domain names, or any content accessed via those domain names. The procedure will be publicised on the Registry’s existing website at telecitygroup.com and at the new Registry website. It will provide a first stage complaints procedure to Telecity’s dedicated complaints team, a second stage internal appeals procedure to the Naming Committee and a third stage procedure for further appeal, to Telecity’s senior management team. Complainants will be able to submit their complaint via the website, by post or by telephone and Telecity will generally respond to complaints within 10 working days. Telecityʹs response may include, if appropriate, an apology and an explanation as to how Telecity intends to resolve the complaint.

Any person wishing to complain about alleged abusive registrations or other activities concerning the operation of the .TELECITY TLD would be entitled to utilise this complaints procedure in the usual manner.

In the event that resolving a complaint requires the suspension (removing the domain name from the zone file, but not from Whois records) or cancellation of a domain name, this will be handled by the Naming Committee.

Rights holders will also have the option to complain via the UDRP and URS about any registration that they regard as abusive, but the Applicant would encourage any concerned rights holders to contact it in the first instance to attempt to resolve their concerns informally. Further details regarding rights protection can be found in the answer to question 29.

Nominet, the registry provider, have well-established relationships with UK Law Enforcement agencies. Nominet and Telecity will work together to respond to complaints by these agencies, and such complaints will be acknowledged by Nominetʹs abuse team within twenty four hours.

Following review, the complaint may result in one of the following actions:

- Modification of the usage of the domain name
- Suspension of the domain name
- Cancellation of the domain name.

Proposed measures for removal of orphan glue records

The default process for .TELECITY is to automatically detect and remove orphan glue records. However, where clear evidence in written form is presented that orphan glue records are present in the zone files of .TELECITY, Nominet, the registry service provider, will take the following action:

- A change request will be presented to Nominet’s second line support team by the person handling the complaint. The orphan glue record will be manually removed from the register and, if necessary, locks will be put in place which will prevent any further changes being made to the domain name record in question.
- The .TELECITY zone files update dynamically and so within 5 minutes of the change being made on the register the zone files will reflect the changed name server record.

Nominet runs a daily audit of the contents of its zone files and compares these against the contents of the registry database. In the event of a mismatch, Nominet personnel are alerted and the mismatch is corrected. This audit will help to reduce the occurrence of orphan glue records.

Measures to promote WHOIS accuracy

Telecity is committed to transparency in relation to domain name registration records and to the provision of complete and accurate Whois records.

As a closed registry, in which only Telecity personnel will be able to register second level domain names and only for business purposes, Telecity will be able to ensure the accuracy and completeness of all Whois records.

All domain names must be registered through the Naming Committee. As part of this process, Telecity personnel requesting the registration of a new second level domain will be required to provide a statement as to their business need for the domain name as well as full contact details of their name, position and business area.

The Naming Committee will perform regular audits to ensure this data remains up to date and accurate.

Information sharing

Nominet is well established in national and international industry networks covering registry specific threats as well as threats to the broader Internet landscape. It will continue this work, ensuring .TELECITY is as resilient and secure as it can be.

Nominet provides an aggregated feed of information highlighting domain names in its domains used for phishing purposes to the relevant registrar. This feed is collated from trusted sources and allows registrars to take prompt action against abusive domains. In the event that any .TELECITY domain names appear in the feed, action will be taken by Telecityʹs Naming Committee to remove abusive content or to place the domain name in ʹserverHoldʹ

Controls to ensure proper access to domain functions

The ability to register domain names and amend details on the register will be limited to members of the Naming Committee. Access to the mechanisms by which such changes can be made will be password protected as a minimum, and consideration will be given to implementing further security measures (such as multi-factorial authentication). Records will be kept of all registration and amendment requests to maintain a full audit trail.

Resource plan

Telecity will establish a Naming Committee that will be responsible for all domain name registrations for Telecity. It is anticipated that this team will be responsible for the accuracy of Whois details.
In addition, Telecity has a dedicated team responsible for responding to complaints. As to whether additional personnel will be required to accommodate any uplift in complaints as a result of the operation of .TELECITY will be closely monitored and addressed as necessary.

Nominet has a large customer support team from which it operates the dot UK registry. It will provide sufficient resources to deal with orphan glue records and Law enforcement complaints. It is expected that this will require less than one hour per week from this team.

The purpose of the .TELECITY registry is to provide a stable and secure platform for electronic communication that is within the direct control of Telecity; to keep Telecity at the forefront of Internet technological development and to ensure that the integrity of the Telecity brand is maintained. One of Telecityʹs core objectives is to (1) prevent abusive registrations, and (2) identify and address the abusive use of registered domain names on an on-going basis.

Safeguards against unqualified registrations

To ensure that all registrations are made in compliance with the registryʹs policies and eligibility restrictions, all .TELECITY registrations are managed through the Naming Committee. As part of this process, Telecity personnel requesting the registration of a new second level domain name which shall exclusively be in the name of Telecity will be required to provide a statement as to their business need for the domain name as well as full contact details of their name, position and business area. The Naming Committee will scrutinise each statement prior to passing the application for rights protection clearance.

Rights protection

It is Telecityʹs policy and practice to treat the intellectual property rights of others with respect. In particular, Telecity already has well-developed internal processes for clearing domain names prior to their adoption by the business so as to ensure as far as possible that new models, services and other initiatives do not infringe the rights of others. These processes include conducting a search against relevant trademark databases and a fuller legal advice process in the event that problems are identified by this search.

Telecity will implement and adhere to any rights protections mechanisms that may be mandated by ICANN at any time and will adhere to all requirements listed in Specification 7 of the draft new gTLD Registry Agreement contained in ICANNʹs gTLD Applicant Guidebook version 2012-01-11.

Sunrise period

ICANN mandate that sunrise registration services must be offered for a minimum of 30 days during the pre-launch phase. A 30 day sunrise period will be offered for .TELECITY and during this period eligible trademark owners registered in the Trademark Clearinghouse will have an early opportunity to register names in the TLD.
It should be noted that as only members of Telecity’s corporate group will be eligible to register domain names in .TELECITY, there will be limited registrations during the Sunrise period.

Trademark claims service

ICANN mandate that a trademark claims service is offered for at least the first 60 days that the registration is open for general registration. During this period, all potential registrants must be notified of the presence of trademark holders registered in ICANNʹs Trademark Clearinghouse.

A trademark claims service will be offered for .TELECITY and attempts to register a domain name which corresponds with a mark registered in the Trademark Clearinghouse will have to be approved by Telecity’s in-house Legal Team.

The checks will be carried out by Nominet UK, the Applicant’s registry services provider, who will fulfil the requirements to send notices out under the claims service, in order to keep the process at arms’ length.

This service will be continued past the minimum initial 60 days and trademark clearing house checks will be made for all registrations in .TELECITY.

Abusive use and takedown procedures

While registrations in the .TELECITY registry will clearly be subject to the UDRP and URS, the Applicant’s preference is for any rights holders with a concern about .TELECITY registrations to approach it in the first instance to discuss their concerns.

In the rare event that Telecity receives such a complaint of trademark infringement, this is treated extremely seriously. Telecity has a dedicated in-house Legal team who investigate such complaints and respond accordingly.

Because .TELECITY will be a closed registry, Telecity does not anticipate that it will be subject to a significant number of third party claims of abusive registrations or activities otherwise harmful to the legal rights of others. That said, Telecity is committed to providing appropriate mechanisms to enable third parties to complain in the event that they consider their rights to have been infringed or otherwise harmed by Telecityʹs conduct, and to provide a remedy in the unlikely event that such a claim is made out. Complaints will initially be addressed by Telecity in-house Legal team and if a complaint is considered to be well-founded, Telecity will take one or more of the following actions:

- cease the harmful conduct
- suspend the domain name to remove it from the zone file
- cancel the domain name.

If at any time the complainant is unsatisfied with Telecityʹs response then they can utilise the UDRP or URS policies. Alternatively, Telecity will ask Nominet to mediate the dispute. The mediation will be provided by Nominetʹs two qualified mediators who have substantial experience of such disputes from their role in mediating dot UK disputes under the dot UK Dispute Resolution Service.

Uniform Rapid Suspension (URS)

The URS process offers an accelerated process for trademark holders to protect their marks. The process will award in favour of the aggrieved party if they are able to show for a registered domain name the following:

- the domain name is identical or confusingly similar to their eligible trade mark
- the registrant has no legitimate right or interest to the domain name
- the domain name is being used in bad faith.

If the URS process awards in favour of an aggrieved party then the domain name in question will be suspended. The nameservers for the domain name will be redirected to an informational web page provided by the URS Provider about the URS. The Whois will continue to display the original registrant information and will reflect that the Whois will not be transferred, deleted or modified for the life of the registration.

When a domain name that is subject to URS expires, then it will be deleted.

The .TELECITY registry will adhere to all URS decisions. Results of URS decisions will be implemented by Nominet, the registry services provider. Nominet has significant experience in implementing the results of dispute resolution processes as it has operated the dot UK Dispute Resolution Service for more than 10 years.

Nominetʹs four-person second-line support team will deal with any URS notifications relating to .TELECITY domain names as soon as is reasonably practicable, and in any event within 24 hours of receipt of the decision from the URS provider. The support team works 08:00 to 18:00 local UK time, with one member on-call outside of those hours to address any urgent issues. The on-call support team member will implement all URS notifications received outside of core working hours.

Uniform Dispute Resolution Policy (UDRP)

Under the UDRP, a trademark owner may submit a complaint to an approved dispute resolution service provider. In the event that the provider finds for the complainant then they may order a transfer, deletion or other action on the domain name. UDRP decisions are implemented by the relevant ICANN accredited registrar.

The .TELECITY registry will fully comply with all UDRP decisions and it will be a requirement on .TELECITY registrars to do so.

Resource plan

Telecity already has a dedicated in-house Legal team responsible, inter alia, for responding to complaints of IP infringement. As to whether additional personnel will be required to accommodate any uplift in complaints as a result of the operation of .TELECITY, this will be closely monitored and addressed as necessary. However, given the modest number of registrations expected in the .TELECITY TLD, it is not presently anticipated that further resource will be necessary.

Nominetʹs existing Dispute Management team incorporating 2 qualified lawyers and 2 experienced mediators will handle mediation. URS decisions will be handled by Nominetʹs abuse team made up of four staff.

Nominet, the Registry Services Provider has been running the dot UK TLD for the past 15 years and has an impeccable security record in protecting both the dot UK TLD and the information within the registry. Nominet works at the forefront of information security and contributes to the development of both global and national security standards to further protect the security, stability and resilience of the Internet.

The aim of Nominetʹs Security Programme is to secure the business, its data, its people, and the services that the organisation provides. Nominet maintains policies, standards and procedures that are designed to protect the company assets according to their sensitivity, criticality and value.

The goals of Nominetʹs Security programme are:

- Allocation of responsibility by Nominet management for development, implementation, monitoring and review of information security policies and standards
- Monitoring, evaluation and management of information security threats, vulnerabilities and risks
- Awareness of, and adherence to, all published information security policies, standards and processes applicable to management or use of information assets by Nominet Personnel with access to such information assets
- Access controls and business continuity management of Nominet information processing facilities, information assets and business processes
- Implementation of an information security incident management process
- Periodic review of the Information Security Programme to ensure its effectiveness.

Processes and Solutions

Nominet employs security capabilities which are robust and appropriate for the high profile and large TLD registry that it operates. Nominet is fully compliant and certified with the British Standard for Business Continuity BS25999-2:2007. Any gTLD that Nominet operates will benefit from this proven security approach.

Physical security at Nominet includes a permanently manned reception area with CCTV monitoring of all entrances including recording of video. All staff wear visible corporate photo ID cards and are encouraged to challenge unaccompanied strangers. Access to server areas requires biometric identification in addition to ID cards. In addition to these physical checks already mentioned, Nominetʹs datacentre locations employ further physical security measures including a 24x7 manned reception, ballistic resistant glass mantrap, and air locks. Security staff ensure that access is only available to those specifically authorised. Nominetʹs servers are housed in a secure caged area within the datacentre with a card access controlled door.

Server security starts with a minimal install of the operating system, with extra software only being installed if required. Access is restricted to those required to administer the server and its software, with audits carried out at regular intervals to ensure that access is still required.

Patching is carried out as part of a regular and ongoing patch management programme to ensure that critical servers and services are kept secure. Nominet also maintain a very close relationship with DNS software providers and have reported bugs to them to help patch their software, following responsible disclosure guidelines.

All external connections to Nominetʹs systems are encrypted using TLS (Transport Layer Security), with internal connections being encrypted where possible. TLS ensures that where appropriate TCP, UDP and BGP connections are encrypted. All privileged access to Nominetʹs servers is protected with two factor authentication. HSMs are used where appropriate to store private key information.

Networks are separated with firewalls (Juniper SRX3600) deployed between different network segments to help protect Nominetʹs sensitive information. All external access to Nominetʹs services is through firewalls to servers located in a DMZ. Wireless access points in Nominetʹs offices are also located in a DMZ to prevent direct access to internal systems. Wireless access is encrypted following best practice guidelines. Only authorised devices are permitted to connect to the company network.

Access to all devices (desktop devices, servers, network devices etc) is via individual usernames and passwords controlled by a central directory service (Microsoft Active Directory). This allows easy control of all user access from a single location, helping simplify user access control. Access to Nominetʹs systems is forbidden unless expressly permitted, and users are granted the minimal access required to perform their job function effectively. Users are assigned unique user ids, and these user ids are never re-issued to other users. Accounts are disabled for any user who no longer requires access or has left the company, and user access is reviewed on a regular basis. The following roles are not carried out by the same people - Systems operation, Systems development, Systems⁄Network administration.

The following controls are also applied to separate systems:

- Development and production software are run in separate environments.
- Development and test work are separated.
- Development facilities are not loaded on production systems.
- Development personnel use separate logon IDs for development and test systems to reduce the risk of error.
- Development staff do not have access to production systems.

Anti-virus software from a reputable supplier is used to scan computers and media on a routine basis. Anti-virus software is kept up to date on a centralised basis.

All access to Nominetʹs services and servers is logged locally, and also to a central location. Nominet also collect logs from firewalls, Intrusion Detection Systems (IDS)⁄Intrusion Prevention Systems (IPS), network devices, security devices, applications, databases etc. Event correlation is performed on all these logs to help identify any unusual activity. Nominet use security information and event management software (Arcsight Express) to do this event correlation.

In addition to the monitoring that is carried out by the devices listed above, Nominet has developed a proprietary technology platform to capture and analyse traffic at its name servers. With this technology Nominet can discover trends, identify abuse patterns and research the behaviour of botnets etc. Using this Nominet can identify security flaws and help the company understand the effect they may have on global DNS infrastructure.

Security for in-house written applications is controlled in many ways:

- All application code is peer reviewed.
- Security guidelines for software development have been written and are followed.
- All source code is held in a central repository, access to which is restricted by password.
- All changes to code are regression tested to ensure the application continues to function as expected.
- All changes to code can be attributed to the developer who made them.

Secure disposal of equipment is tightly controlled, with all storage media removed from equipment prior to disposal and all media is then wiped in accordance with best practice guidelines.

Change control is a tightly controlled process at Nominet, with identification and recording of significant changes, including all changes to security configuration. Approval must be gained at every stage, with all changes tested before being put into the live environment. System owners are always involved in these changes to ensure that no registry system is affected without the business being made aware of upcoming changes. Assessment of the potential impact of any changes is made, and there is an approval procedure for proposed changes. Nominet try to ensure that implementation of change causes minimal disruption to normal operations, bundling up changes into a formal release where applicable. All changes must have an approved rollback plan for recovering from unsuccessful changes.

Staff are encouraged to report security incidents, and all such incidents are investigated by Nominetʹs system administration team, who have access to the research team if required. Action is taken to reduce the impact of the problem initially, and the root cause of the problem is determined. Action is then taken to deal with problem, making changes as required. Any affected users are notified along with any recommended action (such as changing passwords).

Independent Assessment Reports

Nominet currently undergoes specific security testing as part of an approach to maintain PCI-DSS (Payment Card Industry Data Security Standard) Compliance. Using a third party (Trustkeeper), monthly scans are carried out against a section of Nominetʹs internet facing systems to test for vulnerabilities. These scans are designed to detect more than 5,000 known network, operating system and application vulnerabilities including the SANS Institute Top 20 list and are executed without any impact on Nominetʹs systems. The most recent scan was carried out on the 17th January 2012 and the result was a pass.

Nominet is also undergoing a three year programme of security testing using an ISO27001 certified third party assessor (First Base Technologies). The scope of the testing that First Base is carrying out includes (but is not limited to):

- Public IP Address Scan
- External Infrastructure Penetration Test
- Authenticated Remote Access Test
- Web Application Penetration Test
- Internal Infrastructure Penetration Test
- Server and Network technical Audit
- Wireless network Discovery
- Wireless Client Device Discovery and Analysis
- Building Access Test
- Email Spear Phishing
- USB Spear Phishing
- Telephone Social Engineering
- Technical Workshop participation

In addition to the above, First Base have also carried out training programmes for staff on information security vulnerability, and social engineering compliance. Nominet is fully committed to passing the programme of work being carried out by First Base, and where applicable, putting suitable remediation plans in place.

Other Security Measures

Nominet is fully engaged with National and International security agencies to fully understand the ever changing global risk register for security vulnerabilities. Agencies include the US NTIA, UK Cabinet Office, UK GCHQ (Government Communications Head Quarters), UK EC-RRG (Electronic Communications Resilience and Response Group) and many other formal and informal security groups.

Nominet works closely within the internet community to develop, support and publicise security standards and best practice across the global internet. Staff at Nominet helped develop the global DNSSEC security standard and authored a number of the key RFCs (Requests for Comments) that make up this standard. Nominet is currently at the forefront of DNS research, attempting to understand patterns of misuse and criminal behaviour with the global DNS. Nominetʹs Director of IT was selected as one of 12 global experts to analyse and audit ICANNʹs security, stability and resilience work and report back to both the ICANN board and the NTIA on areas for improvement. Nominetʹs Head of Research is a member of the DSSAWG (Domain Stability and Security Working Group) looking into how best to coordinate global DNS security incidents.

Resourcing plan

Nominet employs a dedicated Head of Information and Technology Security to help develop best-practice security policy and to liaise with national and international security agencies, organisations and groups in order to ensure that both Nominet and the TLDs that it operates are as secure as possible.

The implementation of Nominetʹs security policy is already in place. Nominet has a dedicated security team and large infrastructure team from which it will dedicate the following resources to post launch maintenance tasks related to the security policies that will be used by the .TELECITY registry.

- Maintenance, review and improvement of the security policy and arrangements: 5 hours a week by the Head of IT Security
- Technical support: 5 hours per week

Total post launch resource: 10 hours per week.

BRIAN DAVID McARTHUR-MUSCROFT	Group Finance Director
MICHAEL TOBIN	Chief Executive Officer
ROBERT COUPLAND	Chief Operating Officer

MICHAEL TOBIN	Chief Executive Officer
ROBERT COUPLAND	Chief Operating Officer

New gTLD Application Submitted to ICANN by: TelecityGroup International Limited

String: TELECITY

Originally Posted: 13 June 2012

Application ID: 1-1113-2279

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.