ICANN New gTLD Application

Describe the mission⁄purpose of your proposed gTLD:

1.	Mission : Our mission is to commence a new generic top level domain name avenue for global navigation satellite systems (GNSS) industry and users, that enables and improve for commercial entities to illustrate, manage, market their products, services, education and experience, which enhance visibility and makes it easy for users to recognize GNSS activity on internet. We also want to ensure the establishment of Internet security and stability, customer relationship orientated with registrars and introduce innovative webmail features for registrant’s advanced business approach on World Wide Web.

2.	Purpose: JSC (Joint Stock Company) NIS (Navigation Information System) is a national navigation service provider engaged in formation of integrated technology policy for navigation services. As today’s global navigation satellite services and activities are penetrating all segments of society and are becoming a common tool in the daily life of all citizens worldwide, various applications are continuously being developed, covering all lifestyle and sectors of the world economy, JSC “NIS” would like to take the opportunity of ICANN’s New Generic Top-Level Domains (gTLDs) expansion program and intent to establish a new generic top level domain .gdn to represent “Geo Domain Network” 

The .gdn “Geo Domain Network” core purpose is to provide GNSS associated business and activities its own place on the internet, by having a meaningful and verifiable identity, regardless of their product, service or activity area of specialization, size and region –opportunity for better visibility on the internet. 

JSC “NIS” seeks ICANN authorization for new top level domain .gdn for purpose of GNSS business and support on the internet. 

The ever-increasing growth and demand of navigation satellite business and activities requires the support of a hierarchy of generic TLD to logically classify domain names according to their purpose and role.  

The new gTLD is a unique vision and platform to encourage GNSS upcoming technologies and business awareness, by efficiently supporting the naming needs of the rapidly expanding of the World Wide Web. Instant handling information between merchant and consumer, especially in retail industry for customer relation management is an essential to the future success of the GNSS industry. 

GNSS technology is not only limited to navigation devices, as today Location Based Services (LBS) market is experiencing a most rapid growth in GNSS business, mapping API, Point of Interest and group-buying plug-in were introduced into API are having leading progress in GNSS industry. Therefore .gdn gTLD also intends to target the business community for publish additional supplement web page to promote their location based service (LBS) information and to be identified by a global audience via their unique identity on the Internet. Hence, the structure of the .gdn name space makes it easy for users to identify the purpose of web page and as well give opportunity to promote specific keyword related to location For example, www.lectuce.com restaurant is located at 4 different locations and willing to promote lunch buffet special offer at particular their branch, thus www.lectuce.com by publishing additional web page under the .gdn gTLD  www.lectucelunchbuffet.gdn will deliver the clear message of location based information to internet viewer itself. As well www.lectucelunchbuffet.gdn shall have the possibilities to promote their offer at targeted geographical area by using .gdn location-based email marketing tool.  

The .gdn generic top level domain shall offer high security, attentive customer support, and webmail account with location-based email marketing function and competitive pricing. That provides them a better visibility of their brand on World Wide Web, beside additional marketing tool, effective use of internet technology and expertise in customer support. This will also allow the general internet audience to do an instant and quick search throughout the web resources and get to the information required. 

Summary: 

3.1 Concept: Commence new generic top level domain .gdn name registry and seek authorization from ICANN to establish and support new gTLD for GNSS industry. 

3.2 Market:  VeriSign’s study shows continue growth in domain name registration with more than 5.9 million quarterly and by end of 4th quarter of 2011 there were more than 225 million domain names registration across all Top Level Name (TLDs). As well the registered domain of .com and .net TLDs growth lead to 113.8 million itself. It has become merely impossible to find an available desirable name and becoming exponentially more difficult in the present situation. Meantime, reported by WIPO (World Intellectual Property Organization) Trademark registrations worldwide grow by 21.4% in 2010. Around 3.16 million trademarks were registered across the world in 2010, a 21.4% increase on 2009, and more than 18 million trademarks in force around the globe in 2010

Other hand, high precision GNSS Markets and System reported from IT analysis ABI Search that GNSS market is moving into period of sustained growth that will reach 100 percent by 2016. Market such as agriculture, construction, aviation, GIS mapping and military are all forecast to grow strongly, as well GPS enabling new devices, services and markets are open for laptops, handhelds, and communication devices.

Reported by GSA (The European GNSS Agency) the worldwide GNSS market is growing fast and revenues are expected to increase at a 11% CAGR over the next decade.  The total enabled GNSS market size in 2020 is estimated at €244 bln, the core global GNSS market is estimated at €165 bln.

Explosive market growth and strong price erosion in GNSS products and activities will encourage new online product outlets, applications reseller, solution providers and many more other relevant activities, which will bring demand of internet media for various prospects especially online reseller, applications API, marketing, and educational resources. 

“If your business is not on the internet, your business will be out of business” quoted by Bill Gates - founder of Microsoft. 

In conclusion, while GNSS market penetration is expanding rapidly, JSC “NIS” strongly believe that support of a hierarchy of generic TLD to logically classify domain names according to their business nature, purpose and role would be essential and give extra edge to GNSS business visibility on World Wide Web. Hence, JSC “NIS” is positioned to clearly differentiate itself by offering new generic top level domain to GNSS industry and users.

3.3 Management

JSC “NIS” has signed with strong market player whom are not only technically highly skilled and qualified but also carrying healthy experience and expertise in management. JSC “NIS” management has over 15 years experience of GNSS business activities; combined with internet technology, registry system and marketing experts. 

	3.3.1 JSC “NIS” Partners: 

To serve ideally at internet world JSC “NIS” has partnered with Qinetics Solutions Berhad, and JSC ʺTechnology Centerʺ Geoinformatics” to implement, support, maintain and market a domain name registry and obtain maximum market share in GNSS industry.  

JSC “NIS” has strengthened their technical and marketing skill by bringing in partnership with recognized international brand and experienced partners. Qinetics Solutions Berhad is a well known in shared registry system (SRS) and carrying 7 years successful working history in the domain name industry.

Another key player is JSC ʺTechnology Centerʺ Geoinformatics”, is assigned as a technical operation partner, at present engaged in development, and implement of GIS based application and systems with their highly skilled technical team, Geoinformatics will be developing web client and email hosting for exclusive .gdn regist

The goal of .gdn is to introduce new indentify on World Wide Web for GNSS products manufacturer, resellers, service provider, institutes, other associated activates and users with no physical boundaries, JSC “NIS” ability and resources to market to the entire world. Innovative marketing plans and pricing contracts have been designed to retain customers and reward them for additional referrals. In addition, JSC “NIS” wants to be an asset for GNSS industry and users, same time to Internet community.

1.0 Market Analysis:

Our marketing and demographic data is based on accepted historical data and current projections of future market trends. This data has been compiled from standard industry sources.

1.1 Industry Analysis - GNSS Global Market Overview: (Reported by GSA): The GNSS market is the market of products and services using GNSS based positioning and navigation as a significant enabler. When assessing the size of the market for multi-purpose products like mobile phones, a correction factor is taken into account to reflect only the (retail) value of the parts related to positioning and navigation, for example:
• PND: 100% of retail value as GNSS is the key enabler;
• GNSS-enabled phone: For the core market, only the value of chipsets, maps and navigation software is counted. For the enabled market, the full retail value of the phone is counted;
• Subscription to a GNSS-enabled location based service such as local search:
100% of retail value;
• Precision agriculture system: only the retail value of the GNSS receivers, the maps and the navigation software is counted.

1.1.1 GNSS core market vs. enabled market:
The core market include only the parts of the retail value of the product and services that are attributable to GNSS, e.g. chipset, maps, navigation software.
The enabled market includes the full retail value of the GNSS-enabled platform, e.g. in Location based Services mobile device and online .

1.1.2 Four market segments covered
• The following segments have been selected as they represent the largest volume of users and⁄or public benefits.
• Road: including PND and in-vehicle systems
• LBS: including GNSS-enabled mobile phones and services
• Agriculture: including low and high technology
• Aviation: including GNSS devices for commercial and general aviation

LBS market is experiencing a most rapid growth in GNSS business, online and mobile devices are the most developed area in LBS activities. Mapping API, life service Point of Interest, Micro blogging compatibility, group-buying plug-in were introduced into API. As the result of ever enriched off-line information, application content became enormously appealing for end-users. LBS user’s activity has risen above than 20% in compare 2010. The usage and recognition of LBS features become positive factors to the industrial development.

2.0 Industry forecast

BIA⁄Kelsey issued a forecast that predicted small and medium-sized businesses (SMBs) will spend the vast majority of their marketing budgets on digital advertising, performance-based platforms and customer retention business solutions by 2015.

Trademark growths illustrate the demand of brand name domain and there required protection on World Wide Web.

GNSS associated business activities and technology growth simultaneously will develop various new dimension demands in internet media.

2.1 GNSS Market Forecast
• Core GNSS market will reach €165 billion by 2020
• In Europe only LBS handset sales make up the majority of GNSS device sales, about 174 million in 2020 and 200 million GNSS devices shipped every year by 2016.
• Penetration of GNSS in road sector will exceed 50% in the European Union already in 2012 and will continue to grow up to 87% in 2020. The Japanese and North American markets will reach almost 100% penetrations from 2015 and 2018 respectively.
• According to research report “World GPS Market Forecast to 2013”, it is projected that shipment of GPS devices will grow at a CAGR of more than 20% during 2011-2013 to reach around 900 Million units by 2013 itself. The accumulation of devices as well increased the demand of application market in navigation, machine control, and logistics tracking, traffic control, agriculture, robotics etc.
• GlobalMarket reported, the penetration rate of GPS Navigation Software in western countries has reached a high of 90%, and that in Japan 95%.

2.2 Impact
GNSS industry penetration simultaneous will hike growth in GNSS all business segment such as OEM hardware manufacturers, resellers, software developments, solution providers and institutions. Beside corporate websites the location based online solution and niche marketing domain names will bring sufficient demand. Where as to find an available desirable brand or relevant activity name is already serious challenging, as well to decide from available generic top level domains bring exponentially more confusing for registrants.

Hence, JSC “NIS” believes that the potential for continued growth of domain name registrations will bring .gdn gTLD extensive demand and opportunity in GNSS industry activities related registrations.

Product and Benefits

JSC “NIS” primary intention to promote GNSS business activities and awareness worldwide and introducing .gdn new generic Top Level Domain will be an asset for GNSS industry. In fact there is not a single top level domain which cans identically represent GNSS commercial entities and activities. Most of them are become too broad in its scope and so general that it’s no longer identically stand for its original intention. Others TLDs are core in different category of business nature which are not appropriate from any course to use in GNSS relevance.

Hence, there are three main acute issues in existing arena,

1) Desirable name availability
2) TLDs to represent GNSS industry activities and awareness.
3) Unique platform to promote GNSS commercial entities.

By offering .gdn new generic top level domain in internet will enhance the visibility of GNSS products, services and all other associated activities in World Wide Web.

Purpose and benefits from .gdn new gTD shall be,

• Unique identity platform to promote GNSS business and resources
• Preferred GNSS brand and product name availability
• Represent brand, product and services under GNSS business category TLD.
• GNSS products and services maximum brand name protection
• Bring together GNSS business entities with no physical boundaries
• Develop GNSS activities and technology awareness in internet users.
• Build trust & loyalty between GNSS commercial entities and internet community.
• Enhanced GNSS technology and products presence on World Wide Web
• Improved GNSS product and services visibility and better understanding for internet users.
• Additional exposure for resellers on internet media by promoting GNSS product and services at dedicated web catalogue and marketing broachers under GNSS business category string.
• Highly secure and stable registry system
• Customer support oriented registrars.
• Provide Location based email marketing solutions as a value adds product (VAP) for registrants.
• Offer FREE 1 (One) webmail account with 1 (One) Giga Bites (GB) space.
• Free 500+ professionally designed email templates for registrant with webmail account.
• More than 1000+ contacts can be stored in free version.
• Registrant’s can send 500+ emails per day in free version.

JSC “NIS” shall introduce webmail service with integrated location based email marketing solutions and will be provided 1 (ONE) email account with no additional cost upon signing 1 (year) registration. This shift will present exciting opportunities for registrant to tap into the power of internet marketing for target specific geographically located audiences.

JSC “NIS” shall introduce preloaded 500+ professionally designed email templates and allow registrant to compose their own marketing campaign contents. At the same time, .gdn will provide prospect to all GNSS commercial entities to host their own sponsored email marketing HTML templates at .gdn webmail control panel to be utilized by the .gdn registrants. Thus it will help to promote their brand and product name among the .gdn registrants as well. The registrant shall have possibilities to organize their email contact listing by category and geographically location.

The .gdn innovative Internet location based email marketing solution not only bring benefits to the GNSS business owners but also give opportunity to other Internet users to start their own location-based business. One can simply register a .gdn domain name and run location-based opt-in email marketing campaign with no extra cost.

Hereby, JSC “NIS” goal is to provide .gdn registrants not only unique and secure identity for GNSS business activities but also use and knowledge of geographical information system inimitable features and tools on the Internet.

One of key objectives of the .gdn gTLD is to also encourage the GNSS products and services retail industry to do online sales and marketing, as globally one-third of online consumer say they primarily do their internet shopping at retailers that have only an online presence. Beside, reviews of a product are most important when it comes to purchasing consumer electronics: 57 percent of online respondents consider reviews prior to buying reported by Nielsen Company.

The .gdn gTLD shall be targeting worldwide electronic retailers to promote GNSS associated products online from additional specific niche-based marketing domain such as www.abceletronic.com can have www.abcelectronicgarmin.gdn which deliver internet audience meaningful and verifiable identity to understand that they resell Garmin navigation devices at their store along with hundreds of other electronic products. Online shoppers in the United States itself will spend US$327 billion in 2016 according to a projection released by Forrester Research Inc.

JSC “NIS” believes that location based content providers and the advertisement industry is an important segment for .gdn gTLD, where they shall have possibilities to low-down their contents using a niche domain name for better visibility on search engine and bring obvious understanding for viewers. Domain names are extensively used in advertising and we are all now very familiar with advertising messages that include a website address. This could be to encourage consumers to make an actual purchase of the product or service being advertised, to find out more information about the product, or simply for corporate branding. Nominet 2010 analysis reported that 65% of adverts contain a website address. Business was the top 2011 domain category following with shopping and computers (http:⁄⁄db.nominet.org.uk⁄), reported by Sedo, other hand godaddy.com domain market report shows Most Sold Keywords will be the most useful data for most domain name investors.

The registry will also be offering IDN domain names to the registrant in Russian, Arabic, Japanese, Korean, and Chinese languages to allure local registrants.

Target Market
Our first year target includes all GNSS an associated product manufactures, reseller, service providers, developers and worldwide institutes. In addition, JSC “NIS” will encourage location-based advertisers to simplify the process of reaching a specific targeted market.
Through an aggressive and innovative marketing campaign we will educate and attract the global Internet communities especially Russian and Chinese language countries to use the unique .gdn TLD. The nature of our proposed TLD is such that it is also expected to attract other global, non-Internet businesses to use the Internet to easily and effectively reach their targeted markets.
After the first year, our target demographic model expands to include smaller organizations and individuals by introducing a system of categorically focused sub-domains allowing them to effectively reach smaller, even private, target markets.
Customer Profile
Globally, the key customers for .gdn registrants are GNSS associated commercial entities, location based content providers, advertisers, resellers and educational institutes, in further small companies and individual who are interested in running location-based marketing campaign.
Major Competitors and Risk Factors
By promoting specific industry activities and introducing innovative internet marketing features for registrants the .gdn gTLD become itself as a unique in compare with existing gTLD and ccTLD.
Market Segmentation
At the beginning stage our market will consist of only GNSS associated in existence commercial entities, registered Trademark holders, owners of Famous brands, and ICANN accredited registrars to promote our product bundle at their websites. During the period following start-up and continuing until the 1st year tenor end our market will be expanded to include any and all businesses or related entities which meet our domain registration restrictions.
Beginning second year tenor, our market will be expanded to include any small companies or individual who meet our domain registration restrictions. At this time all entities meeting the registration restrictions will be accepted. Any expansion or modification of our market beyond this point will be in reaction to the market itself and determined by the .gdn Policy committee.
Research and Development
JSC “”NIS” being experienced in GNSS technology research and development since several years thus understand GNSS market from all dimensions and that provide extra edge to them in .gdn gTLD business development. JSC “NIS” will employ separate RND team to develop and enhance advance internet LBS email features and functions. Thus they can play key role in improvement of delivering content, interaction with registrants, deliver advanced and unique features for registrant use.
Marketing Planning

JSC “NIS” will be selling TLD registrations through ICANN-accredited registrars and advertising on the Internet, to corporations, small businesses, and individuals. Although direct competition will be limited to other TLD registries, no other current TLD registries offer our combination of value-added products, logical organization of the GNSS industry activities, global unification focus, or technological superiority.
Geoinformatics as an operational and marketing partner for JSC “NIS”, has appointed Web Commerce Communication LTD (Webnic) to operate as the marketing arm to provide an outsourcing service for marketing and business development of the .gdn gTLD, whereas Webnic create market awareness of .gdn .gTLD registry to its current reseller’s base of estimated 2000 in over 50 countries, promote .gdn gTLD registry in event and exhibitions, sign up ICANN accredited registrars globally and develop relevant contacts and marketing material in engaging with registrars.
Meantime, Geoinformatics will be following direct marketing strategy and circulate .gdn registry awareness to all GNSS associated commercial entities. And will pursue establishing affinity revenue sharing relationships with selected sites and build relationship with hosting companies.
JSC ”NIS” preliminary market scope consist of audience awareness thus the registry will adopt various media channels including internet advertisement, television, radio and print media to promote brand and educate internet community and globally that are not yet on the Internet as well.
JSC “NIS” will be promoting .gdn registry by participating and sponsoring globally in all major trade shows and exhibition.
The Mobile TeleSystems OJSC (ʺMTSʺ), the 2nd largest service provider in Europe with 140 subscriptions, Sistema owned 51.2% majority shares, will be additional marketing arm for JSC “NIS” at Russia, India, Ukraine, Uzbekistan and Armenia.

JSC “NIS” sales projection are presented in the provided financial projection template, based on very conservative estimates after considered GNSS business industry volume, internet activates and users, consent with registrars, partners, and advertising experts, appraise the response of the number of domain registration to each publication and emphasize on niche marketing, then multiple it by factor measured reachable with these ads and channels. All presented estimations are not the final figures nor stand for any pledge.

Domain Registration Policies

1.0 General Policy: The .gdn TLD is intended to serve the global navigation satellite system commercial entities and activities. .gdn is NOT restricted to only people, organizations, associations, and private, governmental and non-governmental agencies whom are contributor in the GNSS business industry. The .gdn may establish safeguard policies for GNSS industry activities relevant registered trademarks for registrants by published policy statement. The .gdn may NOT allow to registrant at first place to use registered GNSS business industry trademarks prior issuing acknowledgement notice to trademark owner. The .gdn will reserved those trademarks as a premium domain name for registrants. The .gdn reserved rights to amend registration policy from time to time by published policy statement.

In event, .gdn premium domain name list missing those names that are registered as a trademark; registrant’s shall be treated as first-come first serve basis.

Application: The process of applying for a name registration does not require any authentication of eligibility by the applicant as far applicant is not breaching any .gdn application published restriction policies. The .gdn will permit registration of an available domain name upon completion of a data submission and accepting defined restriction policies. In the event, applicant is applied name from registered Trademark reserved .gdn list, the request will be hold by .gdn for maximum 10 (ten) days from the date of application, the .gdn issue 7 (seven) days notice to Trademark owner to reserve name at .gdn registry system prior .gdn release to applicant.

Name Selection - General Policy:

The composition of a domain name shall contain a string of minimum 1 (one) character and can contain up to a maximum of 63 (sixty-three) characters, excluding the .GDN TLD extension. A guideline of the characters accepted by the Registry includes:
- The alphabets from “A” to “Z”. There will be no distinction between upper-case and lower-case characters i.e. “A” is treated as “a” and vice-versa;
- The numerals from “0” to “9”; and
- The hyphen character. It shall not occupy the beginning, end or the third and⁄or fourth character of a domain name.

There are two types of .gdn Name selection policies shall be applies:
Name selection restrictions that flow from ICANN policies and contracts; and
Name selection restrictions that flow solely from the .gdn delegated authority.

The .gdn defined Name Policy :

Names are allowed to register - No Limitation – Any applicant that is eligible under ICANN defined policies and contract, will be entitled to register any domain name that is not registered at the time of their registration submission through an approved registrar.

NO Limitation in Number: Registrants are not limited in the number of names they may register

Registrant Representations – The registration application and registrant agreement will contain positive representations from the registrant whom are applying for the registered trademark name (s) that they are entitled to apply or have registered. Breach of such representative will allow the .gdn to revoke ineligible names at any time. Provided .gdn registry has issued prior approval to registrant at the time of applying such name.

Equivalent Rights – The .gdn will accept any registration application on a first-come, first-served basis. In the event an application does

The Registry shall provide Registry Services as defined below:
(i) the receipt of data from registrars concerning registrations of domain names and name servers;
(ii) provision to registrars of status information relating to the zone servers for the TLD;
(iii) dissemination of TLD zone files;
(iv) operation of The Registry zone servers;
(v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by The Registry Agreement;
(vi) Internationalized Domain Names (IDN);
(vii) DNS Security Extensions (DNSSEC);
(viii) WHOIS Data Watch Service;
(ix) Searchable WHOIS Service and
(x) Other products or services that The Registry Operator is required to provide because of the establishment of a Consensus Policy

The Registry will be engaging Qinetics Solutions Berhad of Malaysia as the back-end registry service provider for the new gTLD operations.

Registry System

The system is based on RegistryASP SRS Application Suite that is deployed in ccTLD Registries, namely .sg (Singapore), .hk (Hong Kong, SAR), .cd (Congo, Democratic Republic) and .my (Malaysia).

RegistryASP utilizes a ‘thick’ registry model which is EPP (Extensible Provisioning Protocol) version 1.0 compliant, where registrant data is maintained on a central registry database as a contact set.

- Stealth DNS (Zone Generation)
The resolution of domain names is a crucial function in a registry system. The DNS system supports both IPv4 and IPv6. The stealth DNS stores the generated zone file from the database, which will undergo a complicated reconciliation process before the data is reloaded into the master zone. The Stealth DNS is hidden in the internal network and is only visible to the primary DNS server. The primary DNS server is hidden as well and is responsible for the zone transfer to external secondary DNS servers. RegistryASP has achieved 100% uptime for all country codes that they are supporting on DNS resolution. The DNS is in compliance to RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

- External DNS (Zone Resolution)
The external DNS setup consists of the secondary DNS servers dedicated to resolution of the extension domain worldwide. The Secondary DNS are utilizing 2 of the main providers in the world that supports AnyCast DNS with more than 100 nodes all around the world. The provider is CommunityDNS. All zone transfer will be protected using TSIG. The DNS is in compliance to RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

- DNSSEC
The Registry shall provide DNSSEC services to registrars comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. The DNSSEC services shall include the publishing of Delegation Signature (DS) records and signed records to the root zones of the applied TLD.

- WHOIS Services
General public can check the information of a domain name through port 43. The daemon is proven of handling millions of WHOIS queries daily for some of the ccTLD reference for RegistryASP SRS. WHOIS data watch and web based searchable WHOIS will be provided for subscribed users. The WHOIS services are highly scalable, capable of handling higher query loads and comply with RFC 3912.

- Registry Web Interface
The control panel is used by The Registry operational staff to administrate domain names, registrars and other domain name data. Key features include multi-users function control, flexible product configurations, business process configurations and event-triggered alerts.

- Registrar Web Interface
A registrar can perform daily operations, channel management and transaction accounting via the web control panel. Major functions include domain, contact and host management for domain names registered under the registrar, account balance and account top-up.

- EPP Services
A standard EPP server is used to provide flexibility for registrars to automate domain registration and management. The EPP server is configured with a SSL communications link that uses the EPP version 1.0 protocol comply with RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3735.

- Reporting Services
Standard reports are provided to registry and registrar staff to perform secondary check on transactions made, payment received, domain renewal and balance enquiries.

- Operational Testing and Evaluation (OT&E)
All newly accredited registrars shall reserve a time slot to access OT&E server and perform a technical test. This is to ensure that the registrar’s system is capable of registering and managing domain names in the production environment without unnecessary problems. Once a registrar passes the OT&E Test, the registrar will receive an account to access the production system to register and manage domain names.

- Security and Monitoring
The system has been proven to adhere to ISO27001 standards by Hong Kong government and compliance with Singapore government security guidelines. User access will be controlled through 3 tiers of authentication: Registrar SSL Certificate, Registrar IP Addresses and Registrar User Name⁄Password Combination. The communication link with registrar will be SSL encrypted.
Multiple firewalls will be in place to ensure multiple levels of security together with IP filtering and Intrusion Detection with Prevention. Multiple security monitoring systems will be setup within and outside of the network of The Registry System to monitor The Registry Services. Host based intruder detection system will be in place on top of hardware based intruder protection system. Multi Router Traffic Grapher (MRTG) will be installed to monitor traffic utilization in the network and each server of the registry system.

- Data Escrow
The data will be deposited into ICANN approved escrow agent based on escrow requirements to ensure business continuity and data recovery in the unlikely event of data loss.

- Call Centre
System support and maintenance to guarantee maximum uptime shall be provided through Email and Phone to registrars. 24⁄7 technical support hotline are available in multiple languages.

- Channel Management
Client Relation Management (CRM) software is in place to manage communications and contact with the registrars.

- Other Registry Services
The Registry will provide IDN domain names to the end users. The IDN will be deployed according to the IDN RFCs (5890, 5891, 5892, 5893) and the languages supported will be based on registered language tables in IANA.

Shared Regisration System (SRS) Performance: describe the plan for operation of a robust and reliable Shared Registration System. SRS is a critical registry function for enabling multiple registrars to provide domain name registration services in the TLD.

The registry is compliant to Specification 6 and Specification 10 in the Registry Agreement. The compliance table for Specification 6 is as attached.

SRS System Description

1. System Architecture
RegistryASP SRS application is designed with multiple control interfaces to allow access by different parties via defined user roles and matrixes. All components have been designed to be deployed in a distributed environment. A diagram of the system architecture is attached.

Core Component of Registry SRS

The Registry SRS is split into multiple components to improve scalability. The Core SRS Component consists of presentation layer, application security framework, application layer and database layer. It supports HTTP, HTTPS and EPP protocols.

The application layer is used to handle the business flow, audits, messages, processes and the daily tasks in the system. It has a data logger, which stores the details of all requests and responses from the application. The database layer deals with raw data management and utilizes relational databases.

2. SRS Data Flow Diagram
The system architecture of the SRS is designed to allow the EPP, WHOIS, registry web panel and registrar web panel to share the same set of business logics. In other words, the processing of the request will be the same regardless the request comes from which interfaces. A diagram of the SRS data flow is attached.

3. SRS System Features
Business Process Configuration:
• Administration module to configure business rules, policies and practices;
• Utilization of extensions in EPP to store additional information, e.g. language tag etc;
• Control panels to validate pending transactions and facilitate the submission of documents;
• Control panels for black and white list coupled with a pragmatic system to restrict sensitive names;
• Policy manager panels allow registry staff to control access to products and adjust policies;
• Feature access controller panels allow registry and registrar staff to customize functionalities available at various channels; and
• User access controller panel allows registry and registrar staff to customize access level of different users.

Channel Marketing (Registrar Support):
• Web-based multi-tier administrative control panel;
• Ability to brand email templates and extensive email tracking;
• Built-in marketing features such as volume discount and period discount tools;
• EPP connection Software Development Kit (SDK) and toolkits (in Java, PERL);
• Documentation, registrar technical training and change management.

Billing and Payment:
• Reminder notification with configurable alerts, content including other parameters; and
• Billing Manager to manage offline payments, fund alert, incentive rebate calculation and online invoice.

Report Management:
• Comprehensive statistical and transaction reporting system; and real-time reports for channel management (transaction, balance, renewal, announcements etc).
• Registrars detail and summary monthly statements; and
• Transaction tracking and action audit logs

Network Diagram
The attached diagram shows the network architecture and connectivity for all the components of the Registry SRS System. The Registry System infrastructure is located in 2 different data centers for redundancy and scalability purposes. The primary data center consists of the SRS, DNSSEC signing and Data Escrow. The secondary data center will be running the WHOIS services. The stealth and primary DNS are located in the primary data center. DNS Resolution Services are fully AnyCast enabled and dispersed geographically.

The primary data center has full redundancy up to the node level. The network is separated into 2 segments. The first network segment is IP restricted area for registrars to access the SRS which is the DMZ zone. The second segment is for internal access which consist of the database. All servers are protected by redundant firewall.

The Web and EPP services are load-balanced between multiple servers. This provides maximum reliability, and is highly extensible by adding more servers behind the load balancers. Each server has redundant components (Power supplies, hard disk RAID, fans, network interfaces). The presence of multiple servers, multiple facilities, and multiple network providers means that the services will be well protected against single points of failure.

All services are setup in the secondary data center for emergency recovery in case of melt down in the primary data center. The services in the secondary data center can be online within 2 hours from the activation. Each site has at least 2 different network connections to the Internet. Our data centre belongs to a tier 1 provider with has four backbones peering to other tier 1 provider.

The OTE server connects to the test database where the data resembles the production database. The Disaster Recovery Site (Secondary data center) is designed to replicate the primary site except the OTE environment. The OTE environment is not essential during a disaster. The DR site shall only be used to temporarily take over the registry operations while the primary site is being restored. A diagram of the network is attached.

Interconnectivity
The main components in the systems are SRS, Data Escrow, WHOIS, DNS, Reporting, Registrar Systems, Accounting System and System Monitoring. A diagram of the interconnectivity is attached which explains the interconnectivity between these components.

The system consists of a SRS system where the main database server resides. The interfaces in the SRS system are mainly web and EPP. The data are received from registrars through Web panel or automation from registrar system to the EPP server in real time. The central data will then be distributed to DNS, Accounting system and Data escrow agent through batch processing mode.

A secondary database cluster is configured using bidirectional geographical replication to replicate data from the main database in near real time. The secondary database will provide WHOIS query and data access for reports. The monitoring system will probe the services in the SRS in real time.

Synchronization Scheme
Interconnectivity between registry system components appear in 3 synchronization scheme:
1. Replication Synchronization (Only for database)
Source (SRS) to Destination (WHOIS)
- A secondary database cluster will be installed for providing the WHOIS response. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within mili seconds.

Source (SRS) to Destination (Reporting Services)
- A secondary database cluster will be installed for providing reports. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within mili seconds.

2. Batch Processing
Source (SRS) to Destination (Stealth DNS)
- A DNS reconciliation and generation program is in place to regenerate the zones in the interval of 2 hours.

Source (Stealth DNS) to Destination (Primary DNS)
- The zone is transfer to primary using notify = yes. Once records changed in stealth DNS, the primary will be notified to transfer the zone. The transfer takes less than 1 second.

Source (Primary DNS) to Destination (Secondary DNS)
- The zone is transfer to secondary using notify = yes. Once records changed in primary DNS, the secondary will be notified to transfer the zone. The transfer takes less than 1 second.

Source (SRS) to Destination (Data Escrow)
- A backend program will be running daily to deposit the data into Escrow agents SFTP server.

Source (SRS) to Destination (Accounting System)
- A backend program will be running daily to generate data file in the accounting system data import format.

3. Real Time Access
Source (Registrar System) to Destination (SRS)
- All transactions will be processed in real time and response will be returned immediately after processing.

Source (System Monitoring) to Destination (SRS)
- The monitoring software will be probing the services in near real time interval (every second).

Resource Plan
Qinetics will deploy the Registry Service of The registry using its existing system and infrastructure. During the implementation of The registry, new server hardware will be provisioned for SRS services. Our Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. On the other hand, the Database Administrator will create the required schemas. The assigned Software Developer will configure the rules and policies into the SRS system. Once done, our Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. Upon the testing is fully completed, the SRS system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The SRS setup shall be completed within a month.

The system will be in maintenance mode after the SRS is deployed. The SRS will be supported by general helpdesk support for enquiries. Any support issue related to SRS will be escalated to the Application Support Engineer for trouble shooting. System Administrator is tasked to monitor the SRS availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophe scenario at the highest severity.

Once a remedy is identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, the outsourcing party has committed 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. As part of on going policy changes, a team of software developer is available for any standards upgrade to the SRS and the changes will trigger the change request procedure in accordance to CMMI standards.

Service Level Agreement (SLA)
The registry is committed to provide SLA according to the parameters below in accordance to Specification 10:
DNS
- DNS service availability: 0 min downtime = 100% availability
- DNS name server availability: ≤ 432 min of downtime (≈99%)
- TCP DNS resolution RTT: ≤ 1500 ms, for at least 95% of the queries
- UDP DNS resolution RTT: ≤ 500 ms, for at least 95% of the queries
- DNS update time: ≤ 60 min, for at least 95% of the probes

RDDS (WHOIS)
- RDDS availability: ≤ 864 min of downtime (≈98%)
- RDDS query RTT: ≤ 2000 ms, for at least 95% of the queries
- RDDS update time: ≤ 60 min, for at least 95% of the probes

EPP
- EPP service availability: ≤ 864 min of downtime (≈98%)
- EPP session-command RTT: ≤ 4000 ms, for at least 90% of the commands
- EPP query-command RTT: ≤ 2000 ms, for at least 90% of the commands
- EPP transform-command RTT: ≤ 4000 ms, for at least 90% of the commands

Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with Extensible Provisioning Protocol in the relevant RFCs, including but not limited to: RFCs 3735, and 5730-5734. Provide the EPP templates and schemas that will be used. Include resourcing plans (number and description of personnel roles allocated to this area).

Qinetics deploys real time Interface between registry and registrar based on EPP implementation. EPP implements a thick model registry where WHOIS information is stored in registry main database as contact set. Every registration requires a set of contacts to be submitted to registry system. The EPP commands and responses are compliance to RFC 5730 to RFC 5734. The EPP supports all Login Commands (login, logout), Query Commands (check, info, poll, transfer) and Object Transform Commands (create, delete, renew, transfer, update). The supported commands in the system are:

Greeting, Hello, Login, Logout, Poll, Domain Check, Domain Info, Domain Create, Domain Update, Domain Delete, Domain Renew, Domain Transfer, Contact Check, Contact Info, Contact Create, Contact Update, Contact Delete, Contact Transfer, Host Check, Host Info, Host Create, Host Update, Host Delete 

The full set of commands and responses syntax are in a 30 pages document which can be furnished on demand. 

The system utilizes EPP statuses stated in the RFC as follows: 
Domain Action Statuses:
- clientDeleteProhibited: Requests to delete the object must be rejected. 
- serverDeleteProhibited: Requests to delete the object must be rejected. 
- clientHold: Delegation information must be withheld from publication in the objectʹs nominal zone. 
- serverHold: Delegation information must be withheld from publication in the objectʹs nominal zone. 
- clientRenewProhibited: Requests to renew the object must be rejected. 
- serverRenewProhibited: Requests to renew the object must be rejected. 
- clientTransferProhibited: Requests to transfer the object must be rejected. 
- serverTransferProhibited: Requests to transfer the object must be rejected. 
- clientUpdateProhibited: Requests to update the object (other than to remove this status) must be rejected. 
- serverUpdateProhibited: Requests to update the object (other than to remove this status) must be rejected.  

Domain State Statuses:
- ok: This is the nominal status value for a domain object at all times, whether or not the domain has prohibition of operation statuses. 
- Expired: This is the domain status when the domain fall into auto renew grace period
- RedemptionPeriod:  The domain has fall out of renewal grace period into redemption grace period
- pendingRestore: A restore request has been received for the object, and completion of the request is pending. 
- pendingDelete: A delete request has been received for the object, but the object has not yet been purged from the server database. 
- pendingTransfer: A transfer request has been received for the object, and completion of the request is pending. 

When the requested action has been completed, the pendingDelete, pendingTransfer, or pendingRestore status value are removed.  All clients involved in the transaction will  be notified using a service message (Poll Command) that the action has been completed and that the status of the object has changed.

Below are conditions where domain statuses cannot co exist:
-  ʺokʺ status cannot be combined with any other status.
- ʺpendingDeleteʺ status is cannot be combined with either ʺclientDeleteProhibitedʺ or ʺserverDeleteProhibitedʺ status.
-  ʺpendingTransferʺ status is cannot be combined with either ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status.

The pendingDelete, pendingTransfer, and pendingRestore status values cannot be combined with each other.

All Client statuses can be performed by registry or registrar, all server statuses can only be performed by registry.

Domain Transfer State Statuses:
Pending - The domain transfer request is initiated
clientApproved - Domain Transfer is approved by losing registrar
clientCancelled - Gaining registrar cancel domain transfer request
clientRejected - Losing registrar rejected the domain trainsfer request
serverApproved  - Domain Transfer is approved by system after transfer grace
serverCancelled - Domain transfer is cancelled by registry system

Registrar will be required to download the EPP SDK (bundled with documentation) to establish connection to EPP Server. Procedure of TCP connection:
a. Post SSL request
b. SSL Handshaking
c. SSL session established
d. Send Greeting command
e. Greeting acknowledgment
f. Send login information
g. Authentication process
h. TCP over SSL connection established
i. Send command for operation such as Domain check command
j. Send Poll command to keep connection alive
k. Session will be closed automatically after 20 minutes if Poll command is not issued
l. Send logout command
m. Session closed

XML parser will be used against request and response to ensure integrity of the data and detect corruption of data. Once data is found to be loss or corrupted, EPP command fail response will be sent to the requestor.

SSL
The EPP handshake requires exchange of certificates between the client and the server. Qinetics implementation accepts any certificates issued by authorized Certificate Authority (CA). The authorized CA list supported: Verisign, Thawte, GeoTrust, EnTrust, Comodo, GlobalTrust, DigiCert, USERTrust, CyberTrust, Microsoft

Qinetics provides a self signed certificate as optional to the registrar for better security. Registrars can file in a request through email for Qinetics generated certificate. 

Once SSL handshake is established, registrar shall send in a Login command with username and password to access the EPP services. The EPP services implements IP address check before responding to the client. 2 Tier IP check are implemented in firewall and the EPP services respectively to provide double protection.

Operation and Test Environment (OTE)
As part of the standard procedure, registrar will be given access to the OTE environment only. Registrar will have to download the OTE guideline and program according to the documentation.

Registrar will then send a request to start OTE test at a predefined time slot. Once the registrar pass the test, the production username and password will be sent to the registrar technical contact. 
 
Registration Tools
• EPP 1.0 client SDK and documentation; and
• Tools are downloadable from registrar interface.

EPP Extensions Schemas
The EPP shall not implement and extension except for DNSSEC according to RFC 5910 and IDN according to RFC 3735. The extensions are applied to the following commands only:
• Domain Info
• Domain Create
• Domain Update

The table detailing the XML for the EPP commands and responses are as follows:

Domain Info
- Request
〈?xml version=“1.0” encoding=“UTF-8”?〉 〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance  xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉   〈command〉     〈info〉       〈domain:info xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ  xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉         〈domain:name hosts=ʺallʺ〉example.com〈⁄domain:name〉       〈⁄domain:info〉     〈⁄info〉     〈clTRID〉ABC-12345〈⁄clTRID〉   〈⁄command〉 〈⁄epp〉

- Response
〈?xml version=“1.0” encoding=“UTF-8”?〉 〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”     xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈response〉        〈result code=ʺ1000ʺ〉          〈msg〉Command completed successfully〈⁄msg〉        〈⁄result〉        〈resData〉          〈domain:infData  Xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉 〈domain:name〉example.com〈⁄domain:name〉            〈domain:roid〉EXAMPLE1-EP〈⁄domain:roid〉            〈domain:status s=ʺokʺ⁄〉            〈domain:registrant〉jd1234〈⁄domain:registrant〉            〈domain:contact type=ʺadminʺ〉sh8013〈⁄domain:contact〉            〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉            〈domain:ns〉 〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉 〈domain:hostObj〉ns1.example.net〈⁄domain:hostObj〉            〈⁄domain:ns〉            〈domain:host〉ns1.example.com〈⁄domain:host〉            〈domain:host〉ns2.example.com〈⁄domain:host〉            〈domain:clID〉ClientX〈⁄domain:clID〉            〈domain:crID〉ClientY〈⁄domain:crID〉            〈domain:crDate〉1999-04-03T22:00:00.0Z〈⁄domain:crDate〉            〈domain:upID〉ClientX〈⁄domain:upID〉            〈domain:upDate〉1999-12-03T09:00:00.0Z〈⁄domain:upDate〉            〈domain:exDate〉2005-04-03T22:00:00.0Z〈⁄domain:exDate〉            〈domain:trDate〉2000-04-08T09:00:00.0Z〈⁄domain:trDate〉            〈domain:authInfo〉              〈domain:pw〉2fooBAR〈⁄domain:pw〉            〈⁄domain:authInfo〉          〈⁄domain:infData〉        〈⁄resData〉 〈extension〉      〈secDNS:infData xmlns:secDNS=ʺurn:ietf:params:xml:ns:secDNS-1.1ʺ〉 〈secDNS:dsData〉    〈secDNS:keyTag〉12345〈⁄secDNS:keyTag〉    〈secDNS:alg〉3〈⁄secDNS:alg〉    〈secDNS:digestType〉1〈⁄secDNS:digestType〉    〈secDNS:digest〉49FD46E6C4B45C55D4AC〈⁄secDNS:digest〉  (Below are optional)                    〈secDNS:keyData〉                〈secDNS:flags〉257〈⁄secDNS:flags〉                〈secDNS:protocol〉3〈⁄secDNS:protocol〉                〈secDNS:alg〉1〈⁄secDNS:alg〉               〈secDNS:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNS:pubKey〉                    〈⁄secDNS:keyData〉 〈⁄secDNS:dsData〉      〈⁄secDNS:infData〉  〈⁄extension〉        〈trID〉          〈clTRID〉ABC-12345〈⁄clTRID〉          〈svTRID〉54322-XYZ〈⁄svTRID〉        〈⁄trID〉      〈⁄response〉 〈⁄epp〉

Domain Create (IDN)
- Request
   〈?xml version=“1.0” encoding=“UTF-8”?〉    〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”        xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈command〉        〈create〉          〈domain:create  xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0” xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0  domain-1.0.xsdʺ〉            〈domain:name〉xn--asjeiu3h34jhew.com〈⁄domain:name〉            〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉            〈domain:ns〉 〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉 〈domain:hostObj〉ns1.example.net〈⁄domain:hostObj〉            〈⁄domain:ns〉            〈domain:registrant〉jd1234〈⁄domain:registrant〉            〈domain:contact type=ʺadminʺ〉sh8013〈⁄domain:contact〉            〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉            〈domain:authInfo〉              〈domain:pw〉2fooBAR〈⁄domain:pw〉            〈⁄domain:authInfo〉          〈⁄domain:create〉        〈⁄create〉 〈extension〉  〈ext:extension xmlns:ext=ʺurn:ietf:params:xml:ns:ext-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:ext-1.0 ext-1.0.xsdʺ〉        〈langtag〉CHI〈⁄langtag〉  〈⁄ext:extension〉  〈⁄extension〉         〈clTRID〉ABC-12345〈⁄clTRID〉      〈⁄command〉    〈⁄epp〉

- Response
 〈?xml version=“1.0” encoding=“UTF-8”?〉    〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈response〉        〈result code=ʺ1000ʺ〉          〈msg〉Command completed successfully〈⁄msg〉        〈⁄result〉        〈resData〉          〈domain:creData  xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0” xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0  domain-1.0.xsdʺ〉            〈domain:name〉 xn--asjeiu3h34jhew.com 〈⁄domain:name〉            〈domain:crDate〉1999-04-03T22:00:00.0Z〈⁄domain:crDate〉            〈domain:exDate〉2001-04-03T22:00:00.0Z〈⁄domain:exDate〉          〈⁄domain:creData〉        〈⁄resData〉        〈trID〉          〈clTRID〉ABC-12345〈⁄clTRID〉          〈svTRID〉54321-XYZ〈⁄svTRID〉        〈⁄trID〉      〈⁄response〉    〈⁄epp〉

Domain Create (DNSSEC)
-Request
   〈?xml version=“1.0” encoding=“UTF-8”?〉    〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”        xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈command〉        〈create〉          〈domain:create  xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0” xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0  domain-1.0.xsdʺ〉            〈domain:name〉example.com〈⁄domain:name〉            〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉            〈domain:ns〉 〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉 〈domain:hostObj〉ns1.example.net〈⁄domain:hostObj〉            〈⁄domain:ns〉            〈domain:registrant〉jd1234〈⁄domain:registrant〉            〈domain:contact type=ʺadminʺ〉sh8013〈⁄domain:contact〉            〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉            〈domain:authInfo〉              〈domain:pw〉2fooBAR〈⁄domain:pw〉            〈⁄domain:authInfo〉          〈⁄domain:create〉        〈⁄create〉 〈extension〉 〈secDNS:create xmlns:secDNS=ʺurn:ietf:params:xml:ns:secDNS-1.1ʺ〉    〈secDNS:maxSigLife〉604800〈⁄secDNS:maxSigLife〉    〈secDNS:dsData〉 〈secDNS:keyTag〉12345〈⁄secDNS:keyTag〉 〈secDNS:alg〉3〈⁄secDNS:alg〉 〈secDNS:digestType〉1〈⁄secDNS:digestType〉 〈secDNS:digest〉49FD46E6C4B45C55D4AC〈⁄secDNS:digest〉  (below are optional) 〈secDNS:keyData〉        〈secDNS:flags〉257〈⁄secDNS:flags〉        〈secDNS:protocol〉3〈⁄secDNS:protocol〉        〈secDNS:alg〉1〈⁄secDNS:alg〉        〈secDNS:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNS:pubKey〉 〈⁄secDNS:keyData〉 〈⁄secDNS:dsData〉 〈⁄secDNS:create〉 〈⁄extension〉        〈clTRID〉ABC-12345〈⁄clTRID〉      〈⁄command〉    〈⁄epp〉   

- Response
〈?xml version=“1.0” encoding=“UTF-8”?〉    〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈response〉        〈result code=ʺ1000ʺ〉          〈msg〉Command completed successfully〈⁄msg〉        〈⁄result〉        〈resData〉          〈domain:creData  xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0” xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0  domain-1.0.xsdʺ〉            〈domain:name〉example.com〈⁄domain:name〉            〈domain:crDate〉1999-04-03T22:00:00.0Z〈⁄domain:crDate〉            〈domain:exDate〉2001-04-03T22:00:00.0Z〈⁄domain:exDate〉          〈⁄domain:creData〉        〈⁄resData〉        〈trID〉          〈clTRID〉ABC-12345〈⁄clTRID〉          〈svTRID〉54321-XYZ〈⁄svTRID〉        〈⁄trID〉      〈⁄response〉    〈⁄epp〉

Domain Update
-Request
 〈?xml version=“1.0” encoding=“UTF-8”?〉    〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0”  xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”  xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈command〉        〈update〉          〈domain:update  xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0” xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉            〈domain:name〉example.com〈⁄domain:name〉            〈domain:add〉              〈domain:ns〉 〈domain:hostObj〉ns2.example.com〈⁄domain:hostObj〉              〈⁄domain:ns〉              〈domain:contact type=ʺtechʺ〉mak21〈⁄domain:contact〉              〈domain:status s=ʺclientHoldʺ               lang=ʺenʺ〉Payment overdue.〈⁄domain:status〉            〈⁄domain:add〉            〈domain:rem〉              〈domain:ns〉 〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉              〈⁄domain:ns〉              〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉              〈domain:status s=ʺclientUpdateProhibitedʺ⁄〉            〈⁄domain:rem〉            〈domain:chg〉 〈domain:registrant〉sh8013〈⁄domain:registrant〉              〈domain:authInfo〉                〈domain:pw〉2BARfoo〈⁄domain:pw〉              〈⁄domain:authInfo〉            〈⁄domain:chg〉            〈domain:add〉                 〈domain:status s=ʺclientHoldʺ⁄〉             〈⁄domain:add〉          〈⁄domain:update〉        〈⁄update〉     〈extension〉 〈secDNS:update xmlns:secDNS=ʺurn:ietf:params:xml:ns:secDNS-1.1ʺ〉      〈secDNS:rem〉          〈secDNS:dsData〉               〈secDNS:keyTag〉12345〈⁄secDNS:keyTag〉               〈secDNS:alg〉3〈⁄secDNS:alg〉               〈secDNS:digestType〉1〈⁄secDNS:digestType〉               〈secDNS:digest〉38EC35D5B3A34B33C99B〈⁄secDNS:digest〉          〈⁄secDNS:dsData〉      〈⁄secDNS:rem〉      〈secDNS:add〉          〈secDNS:dsData〉               〈secDNS:keyTag〉12346〈⁄secDNS:keyTag〉               〈secDNS:alg〉3〈⁄secDNS:alg〉               〈secDNS:digestType〉1〈⁄secDNS:digestType〉               〈secDNS:digest〉38EC35D5B3A34B44C39B〈⁄secDNS:digest〉  (below are optional) 〈secDNS:keyData〉        〈secDNS:flags〉257〈⁄secDNS:flags〉        〈secDNS:protocol〉3〈⁄secDNS:protocol〉        〈secDNS:alg〉1〈⁄secDNS:alg〉        〈secDNS:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNS:pubKey〉                 〈⁄secDNS:keyData〉          〈⁄secDNS:dsData〉       〈⁄secDNS:add〉 〈⁄secDNS:update〉     〈⁄extension〉     〈clTRID〉ABC-12345〈⁄clTRID〉     〈⁄command〉    〈⁄epp〉

-Response

〈?xml version=“1.0” encoding=“UTF-8”?〉    〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”  xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉      〈response〉        〈result code=ʺ1000ʺ〉          〈msg〉Command completed successfully〈⁄msg〉        〈⁄result〉        〈trID〉          〈clTRID〉ABC-12345〈⁄clTRID〉          〈svTRID〉54321-XYZ〈⁄svTRID〉        〈⁄trID〉      〈⁄response〉    〈⁄epp〉

Resource and Operation Plan
Qinetics will deploy the Registry Service of The registry using its existing system and infrastructure. During the implementation of The registry, new server hardware will be provisioned for EPP services. Our Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. The assigned Software Developer will configure the rules and policies into the EPP system. Once done, our Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. Upon the testing is fully completed, the EPP system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The EPP setup shall be completed within a month.

The system will be in maintenance mode after the System is deployed. The EPP will be supported by general helpdesk support for enquiries. Any support issue related to EPP will be escalated to the Application Support Engineer for trouble shooting. System Administrator is tasked to monitor the EPP availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophe scenario at the highest severity. 

Once a remedy is identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, the out sourcing party has committed 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. As part of on going policy changes, a team of software developer is available for any standards upgrade to the EPP and the changes will trigger the change request procedure in accordance to CMMI standards.

EPP Server Capacity Plan
System performance depends heavily on the application server capability and the processes required for completing a transaction.  As the transaction load increases, the system performance can be increased by tuning the application server, upgrade the hardware of the server or increase the number of servers and utilizing load balancers. A test has been carried out using the below hardware for the capacity planning:

- 1 x Dual Core CPU 1.6GHz
- 2G RAM

The test results recorded with a database of 180,000 names and 100 concurrent EPP connections for each commands (in parallel 1500 commands posting) in our test environment are as follows:

EPP Queries
- Average 1.5 seconds response time for query transactions
- Average 4 seconds response time after 90% line

EPP transactions
- Average 1.5 seconds response time for transactional commands
- Average 5 seconds response time after 90% line

The results are shown in the screen shot below. According to the result, more than 90% of online transactions take less than 2 seconds in average to response and the remaining of 10% (more time-consuming) transactions can also be completed in 5 seconds as per expectation.

Based on the proposed 2 EPP server hardware which is 4 times more powerful than the test server, the system can handle up to 500 concurrent connections easily. The number of servers will be increased based on the growth of number of registrars or change in the maximum number of connections allocated.

Shall the number of registrars increase, new servers will be provisioned into shared pool. Each registrar will have equal access to the shared pool of connections. The shared pool will serve registrars on First Come First Serve basis.

Whois: describe how the applicant will comply with ICANNʹs Registry Publicly Available Registration Data (Whois) specifications for data objects, bulk access, and lookups as defined in Specifications 4 and 6 to the registry agreement. Describe how the Applicantʹs Registry Publicly Available Registration Data (Whois) service will comply with RFC 3912. Describe resourcing plans (number and description of personnel roles allocated to this area).

WHOIS System Architecture
The WHOIS service contains data submitted by registrars during the domain name registration process. Any changes made to the data will be reflected in real-time, thus providing all interested parties with up-to-date information.
The WHOIS services to be provisioned include:
a. Port 43 command prompt WHOIS;
b. Searchable Port 80 web based WHOIS;
c. Configurable Port 43 rate limiter to prevent excessive request from the same IP;
d. Penalty for violation of query limit (e.g. barring access for the next 24 hours);
e. Ability to exclude certain IPs from normal rate limiting facilities;
f. Support multilingual WHOIS display;
g. Easy, scalable and reliable WHOIS service;
h. Ensure accuracy in the display of WHOIS data; and
i. Conforms to RFC 3912.

WHOIS Access Method
WHOIS service shall be accessed via:
Command line (port 43)
The command line WHOIS allow queries by domain name in compliance to RFC 3912. The information will be displayed in a standard format. The WHOIS client makes a text request to the WHOIS server, then the WHOIS server replies with text content. All requests are terminated with ASCII CR and then ASCII LF. The response might contain more than one line of text, so the presence of ASCII CR or ASCII LF characters does not indicate the end of the response. The WHOIS server closes its connection as soon as the output is finished. The closed TCP connection is the indication to the client that the response has been received.

Registry Public Web Site (port 80)
The web based WHOIS is a searchable WHOIS by domain name. The corresponding information will be displayed if a match is found.

Both web and command prompt WHOIS will be accessing a standard database connection pool before connecting to the database as shown below. The secondary database is configured to replicate the data from production database in real time. A interconnectivity diagram between the SRS and WHOIS service is attached.

DB Connection Thread Controller
The WHOIS system will connect directly to replicate secondary database using a connection pool which will limit the number of maximum connections that can be connected to the database at any given time. Once the maximum is reached, the remaining requests are queued until the current connections are released. If the connection(s) could not be released on time (until database timeout hits), the system will throw an error out stating that the system is currently busy.

Searchable WHOIS Service
The registry will offer searchable web-based WHOIS service on a subscription basis and reserves the rights to impose a fee. The searchable WHOIS will have partial match capabilities on the following fields:
• domain name
• registrant’s name
• registrant’s postal address
• all the sub-fields described in EPP (e.g., street, city, state or province, etc.).

The WHOIS will offer exact-match capabilities on the following fields:
• registrar id
• name server name
• name server’s IP address (only applies to glue records).

The searchable WHOIS will allow Boolean search capabilities supporting logical operators to join a set of search criteria: AND, OR, NOT. The search results will include domain names matching the search criteria.

A potential form of abuse for this feature is data-mining, which is already commonly seen in the domain name industry with many domain name registries implementing reviewing their public WHOIS display policies to mitigate the problem. For example, SGNIC (.SG Registry) has recently revamped their WHOIS display to remove the mailing address of the registrant and administrative contact, the mailing address and telephone number of the technical contact and all of the information of the billing contact. The formal announcement from SGNIC can be found at http:⁄⁄sgnic.sg⁄news⁄sgnic-sg-whois-changes-2-may-2012.

The subscribers can access the searchable WHOIS feature from The registry website. To access this feature, the subscriber would have to apply for access to the feature and sign an agreement with The registry. The registry reserves the right not to approve the application. Upon approval, the subscriber would be given an unique login to ensure non-abusive use of this feature. The search is also protected by Image Verification Check (IVC). The access to this service will be monitored by The registry. Any abuse detected by The registry will be severely dealt with and the access of the offending subscriber will be revoked immediately.

All subscribers will agree to abide by all applicable privacy laws and policies as stated in the Searchable WHOIS Subscription Agreement.

WHOIS Data Watch Service
The registry will provide a service for alerts on WHOIS information change. Any changes on the WHOIS data will be alerted to the previous and the new email address of the registrant contact. The registry shall provide the services for free but reserves the right to impose a fee on the service. This feature provides extra security to ensure accuracy of the WHOIS information.

WHOIS Query Control
The WHOIS service has the capability to perform query limit to avoid bulk access. The registry has the flexibility to amend the rate limit any time. To avoid further access to the registrant information, the search do not allow query on the registrant name. The search will return exact match results to avoid harvesting of related matching records.

WHOIS and Privacy
The registry shall provide access to registrant information to the extent compatible with applicable privacy laws and policies. The registry shall not use the WHOIS data to send any unsolicited email to registrants, to solicit registrants by telephone or to otherwise engage in unauthorized uses of their data. The registry shall not sell any WHOIS data to third party under any circumstances.

Registrars will agree to abide by all applicable privacy laws and policies as stated in the Registry Registrar Agreement. Registrars shall require customers to enter into an agreement prohibiting the customer from using the WHOIS database to send email, contact by phone or use it for other commercial purposes.

Registrars are required to post privacy policies that provide clear and complete notice to registrants of the type of data that will be collected, the use of such data in operating the registry service and correct data maintained by The registry. Such data are required for submission of domain registration.

System Network and Hardware:
For optimum effect of WHOIS server, minimum 2 WHOIS servers will be provisioned. 2 database servers are provisioned as replicated secondary database cluster from the production site. A backup WHOIS server is setup for disaster recovery purposes in the primary data center. The network diagram is attached.

Interconnectivity and Synchronization
A replicated secondary database cluster is configured to replicate data from the main database in the SRS system. The secondary database will provide WHOIS query and data access for reports. The replication will be done using MySQL bidirectional geographical replication feature which is near real time and providing active-active hot site. The monitoring system will probe the services in the SRS in real time.

Source (SRS) to Destination (WHOIS)
- A secondary database cluster will be installed for providing the WHOIS response. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within mili seconds.

WHOIS Output
The WHOIS server is based on a template system for both web interface and command line based WHOIS. The templates can be configured and changed in real time. The standard WHOIS output format is as below:

Sample WHOIS Output (Search By Domain):
Domain Name:EXAMPLE〈New gTLD String〉
Created On:18-Feb-1996 05:00:00 UTC
Last Updated On:26-Mar-2010 16:53:27 UTC
Expiration Date:19-Feb-2015 05:00:00 UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-VIP)
Status:DELETE PROHIBITED
Status:TRANSFER PROHIBITED
Status:UPDATE PROHIBITED
Registrant ID:VIP-0000012
Registrant Name:Registration Department
Registrant Organization:Domain Company.
Registrant Street1: 1511 Hayden Rd.
Registrant Street2:Ste 160, PMB 353
Registrant Street3:
Registrant City:Scottsdale
Registrant State⁄Province:Arizona
Registrant Postal Code:85260
Registrant Country:US
Registrant Phone:+1.4806242599
Registrant Phone Ext.:
Registrant FAX:+1.4806242598
Registrant FAX Ext.:
Registrant Email:admin@example.com
Admin ID:VIP-22131674
Admin Name:Registration Department
Admin Organization:Domain Company.
Admin Street1:1511 Hayden Rd.
Admin Street2:Ste 160, PMB 353
Admin Street3:
Admin City:Scottsdale
Admin State⁄Province:Arizona
Admin Postal Code:85260
Admin Country:US
Admin Phone:+1.4806242599
Admin Phone Ext.:
Admin FAX:+1.4806242598
Admin FAX Ext.:
Admin Email:admin@example.com
Tech ID:VIP-12131674
Tech Name:Registration Department
Tech Organization:Domain Company
Tech Street1:1511 Hayden Rd.
Tech Street2:Ste 160, PMB 353
Tech Street3:
Tech City:Scottsdale
Tech State⁄Province:Arizona
Tech Postal Code:85260
Tech Country:US
Tech Phone:+1.4806242599
Tech Phone Ext.:
Tech FAX:+1.4806242598
Tech FAX Ext.:
Tech Email:admin@example.com
Name Server:NS1.EXAMPLE〈New gTLD String〉
Name Server:NS2.EXAMPLE〈New gTLD String〉
DNSSEC:Signed
DS Created 1:26-Mar-2010 16:52:50 UTC
DS Maximum Signature Life 1:3456000 seconds
DS Key Tag 1:54135
Algorithm 1:5
Digest Type 1:1
Digest 1:225F055ACB65C8B60AD18B3640062E8C23A5FD89
DS Created 2:26-Mar-2010 16:53:27 UTC
DS Maximum Signature Life 2:3456000 seconds
DS Key Tag 2:54135
Algorithm 2:5
Digest Type 2:2
Digest 2:6CDE2DE97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F58B2831D

If the information does not exist, WHOIS will display a message e.g. “No Record Found”.
Sample WHOIS Output (Search By Host or Host IP: For Searchable WHOIS Subscribers Only):

Hostname: ns1.fivio.vip
Created On:18-Feb-1996 05:00:00 UTC
Last Updated On:26-Mar-2010 16:53:27 UTC
Expiration Date:19-Feb-2015 05:00:00 UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-VIP)
IP address: 202.11.11.90
IP address: 202.11.11.91

Sample WHOIS Output (Search By Registrar Name, Address, Phone etc: For Searchable WHOIS Subscribers Only):
Registrar Name: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State⁄Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
NEW GTLD AGREEMENT SPECIFICATIONS
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http:⁄⁄www. example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld

Sample WHOIS Output (Search By Registrant ID: For Searchable WHOIS Subscribers Only):
Registrant ID:VIP-0000012
Created On:18-Feb-1996 05:00:00 UTC
Last Updated On:26-Mar-2010 16:53:27 UTC
Expiration Date:19-Feb-2015 05:00:00 UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-VIP)
Registrant Name:Registration Department
Registrant Organization:Domain Company.
Registrant Street1: 1511 Hayden Rd.
Registrant Street2:Ste 160, PMB 353
Registrant Street3:
Registrant City:Scottsdale
Registrant State⁄Province:Arizona
Registrant Postal Code:85260
Registrant Country:US
Registrant Phone:+1.4806242599
Registrant Phone Ext.:
Registrant FAX:+1.4806242598
Registrant FAX Ext.:
Registrant Email:admin@example.com

Internationalized Domain Name (IDN)
The same templates that are used for the English version will be used for IDN display. Users will have to convert the domain name to xn—before executing the query.

IPv6 Address
Any hostname submitted with IPv6 AAAA record will be displayed.

Resource and Operation Plan
Qinetics will deploy the Registry Service of The registry using its existing system and infrastructure. During the implementation of The registry, new server hardware will be provisioned for WHOIS services. Our Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. On the other hand, the Database Administrator will ensure the database cluster work fine across geographically different data centers. The assigned Software Developer will configure the WHOIS display template into the WHOIS system. Once done, our Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. Upon the testing is fully completed, the WHOIS system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The WHOIS setup shall be completed within 2 weeks.

The system will be in maintenance mode after the System is deployed. The WHOIS will be supported by general helpdesk support for enquiries. Any support issue related to WHOIS will be escalated to the Application Support Engineer for trouble shooting. System Administrator is tasked to monitor the EPP availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophe scenario at the highest severity.

Once a remedy is identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, the out sourcing party has committed 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. As part of on going policy changes, a team of software developer is available for any standards upgrade to the WHOIS and the changes will trigger the change request procedure in accordance to CMMI standards.

Compliance Table (Specification 4)
The table showing our compliance to specification 4 is attached.

Registration (1 to 10 years)
A 〈New gTLD String〉 domain name can be registered for a span of 1 to 10 years.
1. Active Period
A 〈New gTLD String〉 domain name becomes ACTIVE immediately upon being registered, meaning that it is no longer available for registration. The WHOIS record of the newly registered domain is created upon registration. A 〈New gTLD String〉 domain name can be active for 1-10 years depending on the duration of the registration term selected by the registrant. A 〈New gTLD String〉 domain name can be transferred from one registrar to another while it is in ACTIVE state. The domain will have OK status.

2. Registry-Lock
This condition can only be set by the registry. A 〈New gTLD String〉 domain name with this status cannot be transferred, modified or deleted by its registrar. The domain can however be renewed. The domain will be resolvable as it is included in the registry zone files if the domain has been delegated to at least one name server. The domain will have serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited statuses.

3. Registry-Hold
This condition can only be set by the registry. A 〈New gTLD String〉 domain with this status cannot be transferred, modified or deleted by its registrar. The domain can however be renewed. The domain will not be resolvable as it is not included in the registry zone files. The domain will have serverHold Status.

Renewal
A 〈New gTLD String〉 domain name can be renewed up to a maximum period of 10 years. The following are the rules that govern the renewal of a domain name:
• The request to renew a domain name should contain the Period parameter to identify the number of years to be added to the registration. If not provided, the system provides a default one year renewal.
• The request to renew a domain name must contain the current expiration date. This is required to ensure that repeated attempts to retry this command do not result in multiple successful renewals.
• The system renews the domain name for the period specified by the registrar. If the domain name renewal is completed successfully, the system returns the new registration expiration date in the response.
• The number of years requested plus the time of the remaining registration period cannot exceed 10 years. Registration periods are capped at 10 years per the agreements between The registry and ICANN. Any attempt to create a registration period longer than 10 years will be rejected with an error response code. For example, if a registration has 18 months remaining until expiration and 9 years are requested for the renewal, the request would be rejected. The resulting period would be 10 years and 6 months - this is not allowed because it is greater than 10 years.

The state diagram of the 〈New gTLD String〉 domain life cycle is attached.

Grace periods are available for billable EPP commands to account for errors and support the auto-renewal model. The applicable grace period information is returned in the domain info EPP XML response.

Add Grace Period
The Add Grace Period is a specified number of calendar days following the initial registration of the domain. The proposed Add Grace Period is 5 calendar days. The domain could be in OK or prohibited statuses.

If a Delete, Renew, or Transfer operation occurs within the 5 calendar days, the following rules shall apply:
• Delete. If a domain name is deleted within the Add Grace Period, the sponsoring registrar will be refunded the amount of the registration fee. The domain name is immediately deleted from the registry database and available for registration by any registrar. If a domain name is deleted after the 5 calendar day grace period expires, it will be placed in the Redemption Period Status for 30 calendar days and then deleted via the system after going through a 5 calendar day Pending Delete Period.
• Renew. If a domain name is renewed within the Add Grace Period, there will be no grace period credit for the registration fee. In addition to the initial registration charge, the sponsoring registrar will be charged for the number of years the domain name is renewed up to a maximum resulting registration period of not more than 10 years.
• Transfer. A domain name may not be transferred within the Add Grace Period. Registrants are prohibited from changing registrars within the first 60 days of the initial registration of the domain name.

Add Grace Period Consensus Policy
If a domain is deleted within the Add Grace Period, the sponsoring registrar is credited for the amount of the registration fee. However, the Add Grace Period Consensus Policy limits the number of deletes within the grace period that are allowed per registrar. It is the intention of this Policy is to limit the behavior known as “domain tasting” through modifications to the Add Grace Period (AGP) process.

The Add Grace Period Consensus Policy can be found on the ICANN website at http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm

The registry will not offer any refund to an ICANN accredited registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new registrations (calculated as the total number of domain name registrations of one-year through ten-year registrations) in that month, or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted by the registry. The calculation will be done automatically by the system.

A registrar may seek an exemption from the registry from the application of such restrictions in a specific month under special circumstances. A report would have to be presented to the registry by the registrar requesting for the exemption stating the circumstances and that the registrar was unable to prevent the deletions from taking place. The acceptance of any exemption will be at the sole and reasonable discretion of the registry, however special circumstances which reoccur regularly for the same registrar will not be deemed acceptable and will be rejected as a reason.

Example:
If a registrar has 1,000 net new registrations, had its account with the registry auto-debited for US$5,000 (based on a price of US$5 per domain name registration), and had 250 AGP deletes, the Registrar would be entitled to a refund of US$500 for 100 AGP deletes (10% of 1,000 net new registrations at US$5 per domain name registration). The registrar would not be eligible for a refund of US$750 for the additional 150 deletes made.

Renew Grace Period
The Renew Grace Period is a specified number of calendar days following the renewal⁄extension of a domain name registration period. The proposed Renew Grace Period is 5 calendar days. The domain could be in OK or prohibited statuses.

If a Delete, Renew, or Transfer occurs within that 5 calendar days, the following rules apply:
• Delete: If a domain name is deleted within the Renew Grace Period, the sponsoring registrar will be refunded the renewal fee. The domain then enters the Redemption Grace Period unless the deletion occurs during the 5 day Add Grace Period.
• Renew A domain name can be renewed up to a total of 10 years. If a domain name is renewed within the Renew Grace Period, there will be no grace period credit for the renewal fee. The sponsoring registrar will be charged the renewal fee for each of the additional number of years the domain name is renewed.
• Transfer: If a domain name is transferred within the Renew Grace Period, the number of years that was renewed for the domain name will still be valid.

If a domain name is deleted and then restored or if a domain name transfer is approved or auto-approved [within the grace period], then the domain name is no longer considered to be in the renew grace period.

Transfer Grace Period
The Transfer Grace Period is a specified number of calendar days following the completion of a domain name transfer, The proposed Transfer Grace Period is 5 calendar days. The domain could be in OK or prohibited statuses.

If a Delete, Renew, or Transfer operation occurs within the 5 calendar days, the following rules apply:
• Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring registrar will be refunded the registration fee.
• Renew. If a domain is renewed within the Transfer Grace Period, there will be no grace period credit for the transfer fee. In addition to the transfer fee, the registrar will be charged for the number of years the registration is renewed resulting in a registration period of not more than 10 years.
• Transfer. A domain can be transferred to another registrar within the Transfer Grace Period. There will be no refund for the transfer fees. The gaining registrar will be charged for the transfer fee.

If a domain is deleted and then restored or if a domain transfer is approved or auto-approved [within the grace period], then it is considered no longer to be in the transfer grace period.

Auto-renew Grace Period
The Auto-Renew Grace Period is a specified number of calendar days following the completion of the auto-renewal (via batch process) of the domain name. The proposed Auto-Renew Grace Period is 45 calendar days. The domain will be in Expired status.

If the sponsoring registrar does not renew the domain name prior to its expiration date, the registry automatically renews the domain for 1 year. The renewal of the domain name is executed by the registry system the day prior to the expiration date via a batch process. The sponsoring registrar has 45 calendar days to delete the domain and receive a refund for the domain name renewal fee.

If a Delete, Renew, or Transfer operation occurs within the 45 calendar days, the following rules apply:
• Delete. If a domain name is deleted within the Auto-Renew Grace Period, the sponsoring registrar will be refunded the renewal fees.
• Renew. A domain name can be renewed up to a total of 10 years. If a domain name is renewed within the Auto-Renew Grace Period, there will be no grace period credit for the renewal fee.
• Transfer. If a domain name transfer is approved or auto-approved within the Auto-renewal Grace Period, the losing registrar is refunded the renewal fees..

Overlapping Grace Periods
If an operation is performed that falls into more than one grace period, the actions appropriate for each grace period apply as follows:
• If a domain is deleted within the Add Grace Period and the renew Grace Period, then the registrar is credited the registration and renew amounts, taking into account the number of years for which the registration and renewal were done.
• If several billable operations, including transfers, are performed on a domain and the domain is deleted within the grace periods of each of those operations, only those operations that were performed after the latest successful transfer, including the latest transfer, are credited to the current registrar.
• If a domain is deleted within one or several transfer Grace Periods, then only the current sponsoring registrar is credited for the last transfer amount. For example, if a domain is transferred from Registrar A to Registrar B, and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first, second, and third transfers, then only the last transfer is credited to Registrar C.

NOTE: There is no special logic for renewals within any grace period. For example, if a domain is renewed within the Transfer Grace Period, then the current registrar’s account is debited for the number of years the registration is renewed.

5. Pending Period
Pending Periods are defined as a specified number of calendar days following a specific operation during which certain operations are prohibited. The following subsections define the length of each pending period and the operations that are allowed within each pending period.

Types of Pending Periods
There are three Pending Periods - Redemption Period, Pending Restore, and Pending Delete.
NOTE: These three periods correspond to the following statuses in EPP – redemptionPeriod, pendingRestore, and pendingDelete.

When a delete domain request is successful, the domain is placed on redemptionPeriod status for 30 days. During this 30-day Redemption Period, the domain can be restored if the registrar submits a successful Restore request and Restore Report.

The successful restore request changes the domain to pendingRestore status and subsequently, the successful Restore Report replaces the pendingRestore status with the ok status

If a domain in pendingRestore status does not have a Restore Report successfully submitted within the 7 day pending period Pending Restore Period, then the domain is moved to the beginning of a new 30 day Redemption Period.

If the domain is not successfully restored within the 30 day Redemption Period, then the domain is changed to pendingDelete status. The domain remains in the Pending Delete Period for 5 days before it is purged and made immediately available for registration.

Redemption Period
The proposed Redemption Period is 30 calendar days. When a domain name is deleted outside of the Add Grace period, it is placed on redemptionPeriod status for 30 days.

The Redemption Period status does NOT apply to domain names deleted within the 5 day Add Grace Period. If a domain name is deleted within the 5 day Add Grace Period, it is immediately purged from the registry, and immediately made available for registration.

The Redemption Period is designed to help registrars defend against inadvertent deletions. By placing the domain name on Redemption Period status for 30 days, the registrar has a sufficient time to realise the deletion and restore it, and not worry about the domain name being purged from the registry.

Pending Restore Period
The proposed Pending Restore Period is 7 calendar days. A domain stays in the redemptionPeriod status for 30 days OR until a successful RESTORE command places the domain on pendingRestore status.

The domain name stays in pendingRestore status for 7 calendar days or until a Restore Report is received from the Registrar and verified to be complete.

If a domain in pendingRestore status does not have a Restore Report successfully submitted within the 7 day pending period, then the domain is moved to the beginning of a new 30 day Redemption Period.

Pending Delete Period
The proposed Pending Delete Period is 5 calendar days. A domain name that is deleted outside of the Add Grace Period, and does not have a RESTORE command issued during the 30 day Redemption Period is placed into the Pending Delete Period.

Once a domain enters the Pending Delete Period, it cannot be restored. The domain stays in pendingDelete status for 5 days and then it is purged from the system at the end of the 5 days. It should be noted that no EPP operations can be performed on domains with the pendingDelete status.

Pending Transfer Period
The proposed Pending Transfer Period is 5 calendar days. A successful TRANSFER REQUEST command will place the domain on pendingTransfer status for 5 days or until the transfer is explicitly approved, rejected, cancelled, or auto-approved.

The sponsoring registrar (also referred to as the losing registrar) has 5 calendar days to approve or reject the request. If the potential winning registrar receives an approve response, then the domain is automatically transferred. If the potential gaining registrar receives a reject response, then the pendingTransfer status is removed. If the potential gaining registrar does not receive any response by the end of 5 calendar days, then the request is automatically approved.

Resource and Operations Plan
Qinetics will deploy the Registry Service of The registry using its existing system and infrastructure. The assigned Software Developer will configure the domain life cycle into the system. Once done, our Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. Upon the testing is fully completed, the configurations shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the domain life cycle of the system. The domain life cycle setup shall be completed within 2 weeks.
The system will be in maintenance mode after the System is deployed. The domain life cycle will be supported by general helpdesk support for enquiries. Any support issue related to domain life cycle will be escalated to the Application Support Engineer for trouble shooting. Whenever there is a support ticket, Application Support Engineer will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophe scenario at the highest severity.

Once a remedy is identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, the out sourcing party has committed 4 resources for the 24 x 7 helpdesk, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. As part of on going policy changes, a team of software developer is available for any standards upgrade to the domain life cycle and the changes will trigger the change request procedure in accordance to CMMI standards.

The registry shall allocate resources from its Operation team to the following finance and billing activities:
- Refund and billing activities with the registrars;
- Discrepancies on billing with the registrars;
- Reconcile the billing on the accounts and the systems

The registry relies on the automated system for calculation of billing and refund activities based on the logics of the Registration Life Cycle as described in this section. Operation Manager will lead the management and administration for the finance and billing function.

The Registry recognizes that the abusive uses of domain names, such as phishing, spamming and distribution of malware, are growing problem across the Internet. These behaviors are increasingly perpetrated by professional criminals who use technically and socially sophisticated means to victimize the public and misuse Internet resources.

The Registry will adopt an anti-abuse use policy that is designed to benefit registrants, registrars and end-users of the domain names across the Internet. It will define the abusive practices with respect to the domain names and outline the prevention and mitigation effort towards these practices.

Implementation Plan
1. Single Abuse Point of Contact

The Registry will establish an Implementation Plan for handling complaints about abuse, as following:
• Registry will prominently publish abuse contact information on its website;
• The abuse contact will prominently displayed on its webpage, and a uniform naming convention will be utilized to facilitate discovery of the website;
• The abuse contact information shall consist of telephone and email address. The email address may be an alias, not a specific person’s name, to manage operational efficiency;
• Request submitted by verified law enforcement agencies to this contact will receive an acknowledgement of receipt from the registry within 24 hours; and
• The contact at the registry will be empowered to act in response to a well-founded report of illegal, criminal or malicious activity involving the domain name registration.

Policies for Handling Complaints regarding Abuse
1. Scope of Jurisdiction
The Registry’s area of jurisdiction for handling complaints is only limited to matters related to the domain names. It does not have the authority to handle complaints related to other Top Level Domains (TLDs), web hosting, email services and objectionable website content.

2. Anti-Abuse Use Policy
a. Registrar
The Registry intends to incorporate Anti Abuse Use Policy into the The Registry Registrar Agreement (RRA). Registrars should not tolerate abusive use related to the domain names for which they act as sponsoring registrars.

Under the provision of the Registry Registrar Agreement (RRA), Registrar shall promptly investigate complaints alleging any such abusive practices, and shall take all appropriate actions based upon such investigations. Registrar shall use commercially reasonable effort to resolve the complaints, as request or recommended by the registry or any legal authority.

Registrar’s failure to comply with the policy shall constitute a material breach of the RRA, and shall give rise to the rights and remedies available to the registry under the RRA.

b. Registry
Pursuant to the RRA, The Registry reserve the right to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock or hold, in its discretion, with the aim to:
• Protect the security and stability of the DNS;
• Comply with any applicable court order, laws, government rules and requests of law enforcement;
• Comply with any dispute resolution process;
• Comply with the terms of Registration Agreement;
• Avoid any liability, civil or criminal, on the part of the registry, as well as its affiliates, subsidiaries, officers, directors and employees;
• Correct mistakes of the registry or any registrars with regards to the domain registration.

The Registry reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.

Glue Records
The Registry does not allow orphan glue records. Glue records are removed when (or required to be removed before) the delegation point NS record is removed. Other domain names that need the glue record for correct DNS operation may become unreachable or less reachable depending on their settings of DNS service.

Resource Plan
Anti-Abuse Desk
The Registry will have a management staff (i.e. Operations Manager) to spearhead the setting up of an anti-abuse desk, dedicated to handle all matters with regards to abuse. An Administrative Executive will be hired to assist the Operations Manager for the handling of abuse complaints, shall the workload increase.

The Registry will intend to engage external providers to resolve the abuse complaints, such as:
• Uniform Rapid Suspension (URS), as drafted by ICANN;
• Rapid Takedown, as similar service engaged by ICM Registry (the operator of .XXX TLD); or⁄and
• Legal professional to deal with any legal matters arise.

The budget for the engagement of the legal professional is provisioned in the projection forecast in Template 1. The fees for the URS and Rapid Takedown would be borne by the complainant.

Joining Working Groups
To keep up with knowledge in dealing with anti-abuse issues and mitigation practises, The Registry intends to participate in Anti-Phishing Working Group (APWG). The APWG is the global pan-industrial and law enforcement association focused on eliminating fraud and identity theft that result from phishing, pharming, and email spoofing of all types. The APWG also focuses on policy-related issues associated with the DNS to examine abuses of the DNS that may require remediation.

The Registry may also tap into the forum of Registry Internet Safety Group (RISG). The purpose of RiSG is to facilitate dialogue, affect change, and promulgate best practices to combat domain name abuse, Internet identity theft in all its forms and malware distribution. The member registry operators are examining anti-abuse best practices and use cases for registries, and opportunities for data sharing.

WHOIS Accuracy
The Registry intends to outline measures to promote WHOIS accuracy that to be undertaken by the registry directly or by the registrars via the requirements in the The Registry-Registrar Agreement (RRA).

The Registry intends to incorporate the WHOIS Accuracy policy into the RRA where Registrars are required to regularly monitor registration data for accuracy and completeness.

Registrar shall use commercially reasonable effort to monitor and check on the registration data, as requested or recommended by the registry.

Registrar’s failure to comply with the policy shall constitute a material breach of the RRA, and shall give rise to the rights and remedies available to the registry under the RRA.

Authentication of registrant information
The domain name is for open registration and generic use TLD. The Registry (via its registrars) will perform authentication of the registrant information as complete and accurate during Sunrise registration.

Regular Monitoring of Registration Data for Accuracy and Completeness
The Registry will randomly sample WHOIS data from the registry database daily, and will check on the registration data for accuracy and completeness. Any WHOIS irregularities or inaccuracies found during the sampling will be forwarded to the sponsoring registrars for their subsequent remedies.

Any failure to remedy the situation in a timely fashion may result the domain name to be treated as violation of Registration Agreement, where anti-abuse domain use policy shall be enforced.

The Registry will rely on the WHOIS Data Reminder Policy (WDRP) set down by ICANN for the accredited registrars to ensure the WHOIS data of all the domain names are at least reviewed once a year for accuracy.

The Registry provides a Data Watch service which will will email the new and old registrant contact address when there is a change in contact information for the domain. This mechanism works as a counter check measurement to ensure that the registrant validates that the information. The registrant can contact The Registry through the anti-abuse helpdesk.

Policies and Procedures that define malicious or abusive behavior
1. Definition of Abuse
The Registry does not tolerate the abusive use of its domain name, which causes security and stability issues for the registry, registrars and the general Internet community. The Registry defines abusive use as the wrong use of power, position or ability and includes but is not limited to the following:
- Illegal or fraudulent actions;
- Any form of spam i.e. email spam, messaging spam etc;
- Phishing which involves the use of bogus websites to obtain personal information;
- Pharming which involves redirecting unknowing users to fraudulent websites to obtain personal information;
- Willful dissemination of malware;
- Fast-flux hosting which involves the use of DNS to frequently change the location of a website to hide its location or host illegal activities; and
- Botnet command and control.

Establishing Service Level Requirement for resolution
2. Participating in Uniform Rapid Suspension (URS)
The Registry will cooperate with ICANN for the implementation of URS, shall the policies and procedures are finalized. The involvement of the registry for the scope of URS shall include the followings:
• Upon completion of the Administrative Review, the URS Provider will immediately notify the registry (via email) (“Notice of Compliant”) after the Compliant has deemed compliant with the filing requirements. Within 24 hours of receipt of the Notice of Complaint from the URS Provider, the registry shall “lock” the domain name, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The registry will notify the URS provider immediately upon locking the domain name (“Notice of Lock”).
• If after the Examination in Default case, the Examiner rules in favor of the Registrant, the URS provider shall notify the registry. Upon receiving the official notice from the URS provider, the registry will unblock the name and return full control of the domain name registration to the Registrant.
• If the Determination is in favor of the Complainant, upon receiving the official decision from the URS provider, the registry will suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be re-directed to an informational web page provided by the USR Provider.
• The Registry will incorporate URS into the Registration policies, as a takedown measures and procedures to minimize abusive registration.

3. Alternative use of Rapid Takedown Dispute Resolution Policies
In the absence of URS, The Registry may provide a Rapid Takedown process through engagement with a dispute resolution provider that consists of a response team of qualified expert (qualified UDRP panelist).

The Registry agrees that majority of cases that go through the Uniform Dispute Resolution Process (UDRP) are mainly obvious variant of well-known marks. As such, it would be a waste of time or resources for the most obvious cases of infringement to go through the UDRP filings. The Registry may provide a rapid takedown process where a response team of qualified experts (qualified UDRP panellists) will be involved to determine within 48 hours of receipt of a short and simple claim of involving a well-known mark or otherwise inherently distinctive mark and a domain name where no conceivable good faith basis exists. The results may result in an immediate termination of the domain name, but will not prejudice either party’s election to pursue other dispute mechanisms.

4. Service Level for responding to law enforcement requests
In responding to law enforcement requests, The Registry will use the provision within the Anti-Abuse Domain Use policy to act quickly to take down sites that are harboring malware, launching phishing attacks, or otherwise being used to launch attacks across the Internet.

5. Disqualification of Registrant
Traditionally, speculative abusive domain registrations have always attracted a small group of individuals and organizations specializing in high volume registrations due to the profitability of abusive registrations. The Registry may disqualify any registrants that have been found to be making abusive registrations and their agents or any parties determined to be acting in cahoots will also be disqualified from maintaining any registrations or making future registrations in the TLD.

Control for proper access to domain function
The Registry intends to outline measures to promote access control to domain functions by the registrars. The measures to be outlined in the RRA shall include:
• Requiring strong passwords from registrants to process update, transfers and deletion requests;
• Requiring the notification of multiple, unique points of contact when a domain has been updated, transferred or deleted.

The Registry shall implement and adhere to any Rights Protection Mechanisms (RPMs) that may be mandated by ICANN from time to time. Additional RPMs as further described below may also be developed and implemented by The Registry to discourage and prevent abusive domain name registrations. All RPMs mandated by ICANN and independently developed by The Registry will be included in the The Registry registry-registrar agreement.

Compliance with RPM mandated by ICANN
Trademark Clearinghouse
The Registry will use Trademark Clearinghouse to support its pre-launch or initial launch period rights protection mechanism (RPMs). These RPMs, at minimum, will consist of a Trademark Claim service and a Sunrise process.

The Registry agrees to adhere to the Clause 6 ‘Mandatory Rights Protection Mechanisms’ and Clause 7 ‘Protection for Marks in Clearinghouse’ of the Trademark Clearinghouse attachment to the DAG.

The Registry shall also take reference to the Trademark Notice as attached in the same document.

The Registry has allocated budget as cost of sales to pay Trademark Clearinghouse for the Trademark Claims and Sunrise service.

Uniform Rapid Suspension System (“URS”)
The Registry will cooperate with ICANN for the implementation of URS, shall the policies and procedures are finalized. The involvement of the registry for the scope of URS shall include the followings:
• Upon completion of the Administrative Review, the URS Provider will immediately notify the registry (via email) (“Notice of Compliant”) after the Compliant has deemed compliant with the filing requirements. Within 24 hours of receipt of the Notice of Complaint from the URS Provider, the registry shall “lock” the domain name, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The registry will notify the URS provider immediately upon locking the domain name (“Notice of Lock”).
• If after the Examination in Default case, the Examiner rules in favor of the Registrant, the URS provider shall notify the registry. Upon receiving the official notice from the URS provider, the registry will unblock the name and return full control of the domain name registration to the Registrant.
• If the Determination is in favor of the Complainant, upon receiving the official decision from the URS provider, the registry will suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be re-directed to an informational web page provided by the USR Provider.
• The Registry will incorporate URS into the Registration policies, as a takedown measures and procedures to minimize abusive registration.

Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP)
As part of the intended Registry Agreement, The Registry agrees to participate in all post delegation procedures and be bound by the resulting Determinations.

Registry Restriction Dispute Resolution Procedure (RRDRP)
The TLD is a generic use TLD and there is no intention to set out any registration restriction in the Registry Agreement. At such, it is unclear if the RRDRP would apply with The Registry.

Uniform Dispute Resolution Policy (UDRP)
The Registry will adopt UDRP within the Registration Agreement and also be adopted by the registrars. Essentially, the UDRP is a policy between a registrar and its customer and is included in registration agreements for all ICANN-accredited registrars.

Transfer Dispute Resolution Policy (TDRP)
The Transfer Dispute Resolution Policy (TDRP) applies to transactions in which a domain-name holder transfers or attempts to transfer a domain name to a new registrar. The TDRP concerns registrar disputes under the Inter-Registrar Transfer Policy.

The Registry will support the TDRP, and the proceedings may be filed with an independent dispute resolution provider (i.e. HKIRC).

Additional Measures Specific to Rights Protection
Sunrise Program for Registrant Pre-Verification
The Registry intends to adopt a Sunrise Program that has the following details:
RPMs
- Sunrise with three phases:
Phase 1: Sunrise for Governments
Phase 2: Sunrise for registered trade marks
Phase 3: Sunrise for company names

- Schedule ⁄ Length of Sunrise
Phase 1: 4 weeks
Phase 2: 4 weeks
Phase 3: 4 weeks
Landrush: 2 weeks
General Availability

- Term of Registration
Sunrise: Two years minimum
Open registration: One year minimum, ten year maximum

- Submission Process
a) Via The Registry accredited registrars.
b) All applications under each Sunrise phase deemed to have arrived at the same time. Electronic auctions held between eligible competing applicants for the same term.
c) English auction format selected with highest bidder winning.
d) Auction will be carried out by outsourcing provider.

- Policies Key term
Comply with terms in Trademark Clearing House

- Character strings
Comply with terms in Trademark Clearing House

- Authentication
All application validated by third party Verification Agent, namely Trademark Clearinghouse appointed by ICANN.

- Amendments & Reconsiderations
a) Verification Agent could request an Amendment Clarification from applicant to correct a typographical mistake. No additional fee charged.
b) Applicant could apply for Reconsideration within seven days of a rejection on the basis of original application or with the provision of further information.

- Supporting information
Proof of eligibility such as Certified copy of trade mark certificate could be requested by Verification Agent. Certified translations of such document into English could also be requested.

- Challenge Mechanism
a) Sunrise Registration Challenge Policy administered by TCH or Hong Kong International Arbitration Center (HKIAC)
b) During domain auction, an invited bidder who disputed the entitlement of a competing bidder must notify The Registry and initiate a dispute prior to the commencement of the auction.
c) HKIAC will administer the Challenge Process for Pioneer Names.

- Disputes
All registrants agree to be bound by the UDRP.

- Dispute provider
Hong Kong International Arbitration Centre (HKIAC)

- Auction
a) Selecting auctions between competing applicants rather than First Come First Served.
b) Pre-validation offer by Validation agent. Pre-validation applications were to assign a code with which permitted instant approval following submission to the registry.

- Pioneer Program
Pioneer Program allocates desirable names to applicant who competed via a provision of Business Plans stating why they deserved a term. Applications accompanied by a deposit, and shall return to winning applicant when they showed receipts for marketing to the value of the deposit.

Sunrise Challenge Policy
The Sunrise Challenge Policy shall be applied only during the sunrise period for the TLD. The challenges under the Sunrise Challenge Policy shall be administered by the Hong Kong International Arbitration Centre (the “Centre”).

A third-party (the “Challenger”) is required to submit to a mandatory administrative proceeding to seek cancellation, transfer or other changes to a domain name registration, in compliance with the rules that:
• Phase 1: Sunrise for Governments
The corresponding government body objects to the right the applicant claims or fails to acknowledge the application.
•Phase 2: Sunrise for registered trade marks
o The applicant is not the owner, co-owner or assignee of the corresponding registered mark.
o The registered mark was not registered in full force and effect at the time of application of the domain name.
o The applied-for domain names is not a exact match or acceptable match to the textual or word elements of the registered mark which the application of the domain name is based on.
o The registered mark was not registered with a trademark office or trademark registry that corresponds to one of the states or other entities set out in the WIPO Standard ST.3 code.
• Phase 3: Sunrise for company names
o The applied-for domain name does not correspond with the name of the registered entity.
o The applied-for domain name is not an exact match or acceptable match to the textual or word elements of the name of the registered entity which the application of the domain name is based on.

All challenges under this Policy must be submitted to the Centre no later than 120 days after the conclusion of the proposed Sunrise Period. The first challenge to be filed will be granted priority by the Centre if there are multiple challenges for the same domain name. The Centre’s challenge is of an administrative nature and shall be final. The Centre shall not be required to state reasons for its decision.

The fees for the submission of a challenge and its response shall be decided by the Centre prior to the start of the Sunrise Period.

The Registry shall not participate in the administration or conduct of any proceeding before the Centre under this Policy. The Registry shall also not be liable as a result of any decisions rendered by the Centre.

The Centre shall notify the challenger and The Registry of all its decision made under this Policy. If the Centre rules in favor of the challenger and the domain name is to be transferred to the new registrant, the Centre shall provide an authorization code provided by the Registry to transfer the domain name to its preferred registrar and update all the WHOIS information within 30 days that the authorization code is provided.

Abusive Use Policy
The Registry does not tolerate the abusive use of its domain name, which causes security and stability issues for the registry, registrars and the general Internet community. The Registry defines abusive use as the wrong use of power, position or ability and includes but is not limited to the following:
- Illegal or fraudulent actions;
- Any form of spam i.e. email spam, messaging spam etc;
- Phishing which involves the use of bogus websites to obtain personal information;
- Pharming which involves redirecting unknowing users to fraudulent websites to obtain personal information;
- Wilful dissemination of malware;
- Fast-flux hosting which involves the use of DNS to frequently change the location of a website to hide its location or host illegal activities; and
- Botnet command and control.

In regards to abusive use as defined above, The Registry reserves the right to deny, cancel or transfer any registration and lock or place any domain name(s) on hold that it deems necessary in its discretion to protect the integrity and stability of the registry and comply with any applicable laws, government rules, requests of law enforcement, or any dispute resolution process.

Resource Plan
The Registry will have a management staff (i.e. Operations Manager) to spearhead the compliance to ICANN policy matters, and enforce our policies for RPMs are adhered by the Registrars and Registrants. An Administrative Executive will be hired to assist the Operational Manager for the policy matters, shall the workload increase.

During the Sunrise periods, the RPM mechanisms are outsourced to the respective outsourcing partners, namely Trademark Clearing House, URS provider, PDDRP provider, and UDRP providers, Registry backend service provider and legal professionals. Our internal resources are deployed for the following areas:
- Coordination with the providers;
- Liaison with ICANN for the compliance issues;
- Communication with registrars and registrants (where necessary);
- Public relation; and
- Development of new policies.

During the implementation phase, the software developer of Qinetics shall configure the reserve words based on input by the operations manager and ICANN default reserve list. The developer shall perform the configuration of the sunrise, landrush and general availability phases into the SRS between sunrise cooling periods.

Upon the completion of the implementation phase, the Test Engineer of Qinetics will perform rigorous testing procedures to ensure that the system performs according to specifications. Once the testing phase is completed, the configuration shall be hand-over to System Administrator to be deployed to the production environment. A Project Manager is assigned to perform project management and overall control during the implementation phase. The Project Manager will conduct training for the registry users on the sunrise, landrush and general availability handling in the system. The setup shall be completed in stages according to the sunrise process. The configuration in each stage shall be completed in 2 weeks.

The system will be in maintenance mode after the System is deployed. The Operation Manager and the Administrative Executive of The Registry will monitor the registration and WHOIS data daily for any potential trademark issues. They will process the trademark cases and complaints according to policy set by the operations manager. The Operation Team of The Registry shall participate in various workgroups to be updated on any new trademark infringement scenarios and best practices. They shall perform policy review and refinement from time to time so that the rights protection policy can cover as many cases as possible. The application support engineer of Qinetics is tasked to maintain the reserve list according to instructions given by the Operation Team of The Registry.

Summary of Security Policies
The registry adopts standard registration policies without any specific services related to e.g. financial services. As such Criterion 5 is not applicable to The registry. The registry outsource the technical backend registry service to Qinetics. The registry will deploy Security Policy and Security Measures as adopted by Qinetics.

The policies established provides a comprehensive approach as highlight below, to identify and prevent unauthorized access, intrusion, loss of information and software error. Qinetics has wide experience on security implementation with successful implementation of ISO27001 in .HK registry system.

• Physical Security
Physical security is provided by data center. Only authorized personnel are allowed to enter the premises of the data center. Below are standard policies set:
o Data Center Access Policy
o Equipment Policy
o Site Visits Policy

• Network Security
This layer protects all equipment in the network from hacker or malicious attack. Another layer of sniffer (IPS) is put in place as second layer of screening. Security alarm will be triggered if there are abnormal activities in the network. Standard policies applied:
o Firewall Policy
o Denial of Services Policy
o System Monitoring Policy

• Host Security
At the server level, governance policy is required to establish control over access to the servers and movement of servers. Below are the standard policies to achieve control over these parameters:
o Server Access Policy

• Application Security
Security is built within the applications running on the servers. The applications are built using the well known Open Web Application Security Project (OWASP) security policy

• General
Other that the above policies, general policies below applied across the network, server, application and data center to ensure system and registrants are well protected:
o Password Policy
o Data Integrity Policy
o System audit Policy
o Security Patch Policy
o Security Response Policy
o Acceptable Use Policy

Security Assessment
Qinetics has engaged independent 3rd party auditor to perform product assessment which is inclusive of security assessment as 1 of the core assessment. The Malaysia MSC Product Assessment & Rating Standard was developed by TUV Rheinland Malaysia Sdn. Bhd., in collaboration with Macrofirm Technology Sdn. Bhd., under the commissioning of the Multimedia Development Corporation (MDeC). TUV Rheinland Malaysia is a member of TÜV Rheinland Group, a global leader in independent testing and assessment services. The TÜV Rheinland Group was established in 1872, and has offices located in over 490 locations in 61 countries on all five continents.

Existing software quality evaluation standards were used as the basis for the development and endorsement of the software quality criteria and sub-criteria to be assessed in MSC Malaysia Software Product Assessment and Rating Standard. This is also referred to as the “As-is Situation”. The standards used as the basis for development of this assessment standard are as follows:
• CMMI (Capability Maturity Model Integration) Ver. 1.3 Dev
• ISO⁄IEC 9126 (Software Engineering – Product Quality)
• ISO⁄IEC 14598 (Information technology - Software product evaluation)
• Common Criteria (CC)

In the product assessment, a total of 13 main requirements or criteria, divided into 6 process-related criteria (criteria in which the process of development of the software product is assessed) and 7 product-related criteria (criteria in which the developer’s methods to manage and ensure the actual performance of their software product is assessed), were identified for inclusion in the Standard. These criteria in turn were divided into a further 44 process-related sub-criteria and 32 product-related sub-criteria to make a total of 76 sub-criteria.

Evaluation Report
This evaluation report is based on the findings of the MSC Malaysia Product Assessment & Rating on-site product evaluation. As a supplement to the awarded rating, this report provides recommendations to improve the company’s methods of ensuring product quality.

The MSC Malaysia Product Assessment & Rating rates the product on 13 main criteria which are divided into:
1) Six (6) Process-related criteria, ie. criteria in which the process of development of the software product is assessed.
2) Seven (7) Product-related criteria, ie. criteria in which the developer’s methods to manage and ensure the actual performance of their software product itself is assessed.

Results of the evaluation are as below:
Overall % Compliance 97%
Process-Related Requirements:
- Requirements Management 95%
- Technical Solution 100%
- Product Integration 100%
- Validation 98%
- Verification 100%
- Support 100%

Product-Related Requirements:
- Functionality 100%
- Reliability 100%
- Security 91%
- Usability 92%
- Maintainability 100%
- Portability 96%
- Architectural Principles 97%

A copy of the Product Assessment Evaluation and Rating Report and Product Assessment Certificate is attached.

Aleksander Vyacheslavovich Dunaev - Александр Вячеславович Дунаев	Board of Director
Alexander Olegovich Gurko - Александр Олегович Гурко	Board of Director & General Director
Alexander Valerievich Ampilov - Александр Валерьевич Ампилов	Deputy General Director
Andrey Evgenievich Buravin - Андрей Евгеньевич Буравин	Board of Director
Anton Vladimirovich Abugov - Антон Владимирович Абугов	Board of Director
Ekaterina Vladimirovna Cherednichenko - Екатерина Владимировна Чередниченко	Deputy General Director
Evgeny Nikolaevich Shmelev - Евгений Николаевич Шмелев	Board of Director - Independent Director
Evgeny Sergeevich Moskvichev - Евгений Сергеевич Москвичев	Board of Director - Independent Director
Gennadiy Zakharovich Golant - Геннадий Захарович Голант	Deputy General Director
Igor Marsovich Grushelevsky - Игорь Марсович Грушелевский	Board of Director
Igor Yurievich Temirov - Игорь Юрьевич Темиров	Board of Director
Ioannis Moissidis	Board of Director - Independent Director
Ludmila Valentinovna Yurasova - Людмила Валентиновна Юрасова	Deputy General Director
Sergey Fedotovich Boyev - Сергей Федотович Боев	Board of Director
Vladimir Viktorovich Vozhzhov - Владимир Викторович Вожжов	Deputy General Director
Vladimir Vladimirovich Gvozdev - Владимир Владимирович Гвоздев	Board of Director
Yevgeny Maksimovich Primakov - Евгений Максимович Примаков	Chairman of the Board of Directors
Yuri Matevich Urlichich - Юрий Матэвич Урличич	Board of Director

Joint Stock Company «Russian Space Systems» - Открытое акционерное общество «Российская корпорация ракетно-космического приборостроения и информационных систем» or ОАО «Российские космические системы»	Not Applicable
Joint-Stock Financial Corporation Open Joint-Stock Company «Sistema»	Not Applicable

New gTLD Application Submitted to ICANN by: Joint Stock Company ʺNavigation-information systemsʺ

String: gdn

Originally Posted: 13 June 2012

Application ID: 1-1866-26783

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.