ICANN New gTLD Application

Describe the mission⁄purpose of your proposed gTLD

The information gathered in response to Question 18 is intended to inform the postlaunch review of the New gTLD Program, from the perspective of assessing the relative costs and benefits achieved in the expanded gTLD space.

For the application to be considered complete, answers to this section must be fulsome and sufficiently quantitative and detailed to inform future study on plans vs. results.

The New gTLD Program will be reviewed, as specified in section 9.3 of the Affirmation of Commitments. This will include consideration of the extent to which the introduction or expansion of gTLDs has promoted competition, consumer trust and consumer choice, as well as effectiveness of
(a) the application and evaluation process, and (b) safeguards put in place to mitigate issues involved in the introduction or expansion.

The information gathered in this section will be one source of input to help inform this review. This information is not used as part of the evaluation or scoring of the application, except to the extent that the information may overlap with questions or evaluation areas that are scored.

An applicant wishing to designate this application as community-based should ensure that these responses are consistent with its responses for question 20 below.

Jiangsu Bang Ning Technology Co., Ltd (“the Applicant”) was founded in 2008 with the mission of providing high technology Internet solutions and value added services for the governments, companies and individual customers.

Currently, it is at the forefront of data storage and product development with respect to the Cloud services. By the end of 2011, its cloud data storage technology quality is ranged number 1 in the Eastern China district, number 4 in China and has progressively expanded internationally.

As of 2010, the Applicant’s revenue is RMB 10,260,592 on 22% gross margin. The Applicant has about 10 patents granted and has 20 patent pending expected to be granted in the next 2 years. Registrar service is one of the Applicant’s core business, with it operating the website www.bizxun.com and www.55hl.com. The Applicant obtained ICANN accreditation, and received award from CNNIC as the Golden Registrar.

The Applicant is applying for the top level domain name “.top”. For ease of reading, “top” will be referred to as “STRING” in the remaining part of this application.

The vision for “.STRING” is to be connected namespace for all companies and individuals that want to attract and serve selective groups of the Chinese internet population and help promote innovation, participation and collaboration among them.
.
To the Chinese user, “top” with its literal meaning is synonymous to the Chinese characters “排行榜” (which means “ranking” in English). It is used commonly in daily conversations when discussing about ranking of things like industries, entertainment and cities etc. The average Chinese user has a craze for rankings and competitions and one can almost find a reason to compete and rank for any type of thing or phenomenon. Each quarter or year, various rankings will be released to commemorate the best players in various industry sectors.

For example, Baidu, the most popular search engine in China, via the link http:⁄⁄top.baidu.com , displays the various rankings that it tracks. In total, there are about 90+ different categories. Sina online, the most popular online portal in China also uses a similar named link http:⁄⁄top.sina.com.cn to rank online games. Tudou.com, one of the leading online video sharing website, ranks it most popular videos via the link http:⁄⁄www.tudou.com⁄top.

“.STRING” objective is to make it easier for the Chinese Internet population to access and use the Internet to brand themselves and be associated with a premium domain name, Using the proposed “.STRING”, registrants would be privileged to using a “.TOP” domain name for the purpose of promotion and outreach.

Another objective for “.STRING” is to add variety to the current available offering of TLDs. “.STRING” is meant to serve the Chinese Internet population as just how “.com” is serving the English Internet population. Having a specific target audience in mind also helps individuals, companies and organizations that want to service this group to better able tailor their services and products. Even returns on marketing will be higher due to the presence of such a useful “.STRING” gTLD.

On a global scale, the introduction of “.STRING” gTLD allows any Chinese Internet user (not just limited to China) to have an online identity that he⁄she can be more familiar and can associate with. It also helps to promote Chinese culture to the rest of the non-Chinese Internet population.

“.STRING” is meant to target a niche market, with a value proposition similar to those smaller TLDs, branding with high price. As the average Chinese user has a craze for rankings, it is naturally to expect these users to also crave for the opportunity to brand themselves with “.STRING”, either individually or as a company decision. As such, the initial target audience will be the top 100 players of each industry in China, as these players can realize the value proposition of “.STRING”.

The Applicant’s conservative expectation for a high price “.STRING” for the first three years is that, it will initially reach about 4,900 in the 1st year, and grow to 7,420 and 9,800 in the 2nd and 3rd year respectively.

The projection is based on a conservative estimate taking the following into consideration:
* the total number of domain names registered in China across all TLDs
* the proportion of the total number of domain names registered in China that are in Chinese
* ICANN new gTLD study (ICANN benchmarking of registry operations, Feb. 2010)
* the pricing point for “.STRING” and how the China market would react based on the team’s experience in China
* the initial growth of existing gTLDs in China

The pricing for “.STRING” is intentionally set at higher price point to other generic TLDs as the Applicant envisions “.STRING” to be widely adopted as the generic TLD of choice for a selective group of the Chinese Internet community.

The Applicant will have Sunrise process prior to opening the general registration to ensure that the relevant rights owners have their first rights to their names. Landrush period will also introduced to cater for the ardent aspirant registrants. The Applicant will also adopt the Trademark Clearing House to reduce cybersquatting and other intellectual property rights infringements. Furthermore, the Applicant will have additional protection for geographic names. Details of these protections are described in the answer to Question 22, 28 and 29.

18 (b) How do you expect that your proposed gTLD will benefit registrants, Internet users, and others? What is the goal of your proposed TLD in terms of areas of specialty, service levels, or reputation?

As mentioned in Question 18(a), the applied-for “.STRING”, with its literal meaning “TOP” will be used as a specialized space for ranking and publicizing purposes. Chinese society has a rage for competitions and rankings. Each year, each industry would like to produce a top list to commemorate the best players in the industry. And the rankings in turn will boost the performance of the players. Using the proposed “.STRING”, registrants would be privileged to using a “.TOP” domain name for the purpose of promotion and outreach.

In line with its specialty, the Applicant has selected KNET as the back-end service provider due to its business and technical expertise in the Chinese domain name registry industry.

The KNET Shared Registry Platform (“KSRP”) is designed, implemented and operated to provide high availability, secure, robust and scalable registry services. KSRP shall fully conform to, and exceed the Registry Performance Specifications (Specification 10 of the gTLD Registry Agreement).

When it comes to the reputation of the “.STRING” TLD, the Applicant would strive to make the “.STRING” domain names as a premium space reserved for top-listed players.

What do you anticipate your proposed TLD will add to the current space, in terms of competition, differentiation, or innovation?

Competition:
The proposed TLD will add up variety and competition to the current space. Adding up “.STRING” and hundreds of new TLDs in this virtually unlimited space will give consumers more choices to label their distinct identity or multiple identities on the Internet. Furthermore, adding up more generic TLDs will greatly stimulate the competition in this market. The registrants and Internet users enjoy better services with more favorable price. Internet users, registrant will be able to compare “.STRING” TLD with other generic TLDs in terms of retail price, registry services and reputations to pick up its preferred TLD.

Differentiation:
How to survive in this competitive environment? The key lies in differentiation and innovation. The “.STRING” will form a specialized area to attract interested registrants. This differentiated service will give registrants, Internet users and others more choices when it comes to choosing an appropriate domain name to meet their specific demands.

What goals your proposed gTLD have in terms of user experience?

The Applicant believes that “.STRING” as a gTLD will achieve the following goal in terms of user experience:

A specialized space for rankings
The “.STRING”, with its literal meaning “TOP” will be used as a specialized space for ranking and other competition purposes. By using the proposed “.STRING”, registrants would be privileged to using a “.TOP” domain name for the purpose of promotion and outreach. Internet users accordingly, would know the domain names indicating the top players, hence can have a trust when visiting the domain names.

Trust and Secure:
When interacting with “.STRING” domain names, Internet users will be sure that the registered domain names are managed by the top players thus is trustworthy. Naturally Internet users will also have faith in the services using the “.STRING” domain names.

Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

In summary, the registration policy for “.STRING” TLD will be designed as such to reflect the mission and purpose of this specialized domain:

Registrant eligibility Requirement

“.STRING” can be registered by prospective registrant who is listed on the official ranking list of the industry or who is the producer or publisher of a ranking list.

String Policy

Domain names can contain the English-language letters A through Z, the digits 0 through 9 and hyphens (LDH -- Letters, Digits, Hyphens).

a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 -

Hyphens however cannot be used for the first or last character of the second level domain name. Spaces and special characters (such as !, $, &, é, and so on) are not currently acceptable. The maximum number of LDH characters accepted for a second level domain is 63.

Furthermore, Chinese IDN characters are also allowed to register at the sub-level. Please refer to answer to Question 44 for the applicable IDN characters and its registration policies.

WHOIS Policy

“.STRING” shall operate as a ʺthickʺ registry, in which all of the information associated with registered entities, including both technical information and social information is stored within a central registry repository.

The Applicant shall abide with any relevant ICANN WHOIS Policy.

Others

* UDRP and URS as described in the answer to Question 29
* Sunrise and Landrush process as describe in the answer to Question 29
* Geographic name restriction as described in answer to Question 22
* Trademark protection as describe in answer to Question 29
* Domain Name Lifecycle as describe in answer to Question 27
* Data Privacy as describe in Question 18(c) below
* Reserved and Blacklist label as describe in the answer to Question 22 and 29

Will your proposed TLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.

The Applicant will adopt appropriate policies to protect the privacy of registrants and its domain name users in line with the policies by ICANN as well as the privacy regulation of China which the Applicant is incorporated.

As such policy and regulation may be modified in the future; the Applicant will also amend its privacy policy accordingly.

Specifically, The Applicant is subjected to China’s《信息安全技术个人信息保护指南》(“Information Security Technology -- Guide of Personal Information Protection”). In brief, the Applicant shall inform the registrants at the Registration Agreement that
* The purpose of any personal information collected and scope of use
* The period in which these personal information will be stored
* The security measure and information protection policy to safeguard the personal information
* The rights of the registrants on the personal information
* The registrant responsibility for accuracy of the personal information

In general, the Applicant stipulates how the personal information will be collected and used and how the WHOIS information will be displayed. Any information other than the WHOIS shall not be collected and used. No personal information will be collected without the consent of the registrants and the registrants shall have the Rights to Confidential, Rights to Knowledge, Rights to Opt-out⁄Change Data⁄Prohibit Use.

The information submitted by the registrants shall be regarded as classified information and shall be processed by specially designated personnel. Without the written consent of registrants, the information collected cannot be used in the way other than WHOIS purpose.

The back-end service provider shall deploy security measures to protect the integrity of the database against potential stealth or unintended leakage. Please refer to the answer to Question 30 for more information in this regard.

Describe whether and in what ways outreach and communication will help to achieve your projected benefits.

During the application, the Applicant will reach out to the registrars serving the Chinese community (particularly in China) to seek their support. There are only small numbers of ICANN accredited registrars in the region and the Applicant will have private meetings with these registrars. Additionally, the Applicant will also seek out other domain name resellers and encourage them to become ICANN accredited registrars so as to be eligible to participate in the launch of “.STRING”.

Prior to the successful application of “.STRING”, the Applicant shall begin early communication via press releases and media interviews within the Chinese media to ensure companies and individuals would be well-informed of the pending launch of “.STRING”. The Applicant may take pre-registration to gauge the demand but will not accept any advance payment.

After the Applicant has signed the registry agreement with ICANN, the Applicant will embark on a 30 days targeted Sunrise campaign to ensure companies and trademark owners participate in the “.STRING” Sunrise. The Applicant shall provide a code of conduct to its marketing partners to prevent any spam abuse or misrepresentation of “.STRING” sunrise.

Following the “.STRING” sunrise, the Applicant shall organize a Landrush ceremony in China and⁄or Hong Kong, inviting partners (e.g. registrars) as well as media representatives. The Applicant will also begin the extensive marketing, including online and offline advertising. The Landrush marketing effort will also last another 60 days.

After the launch of “.STRING”, the Applicant, from time to time, will embark on marketing and communication campaign to promote the utilization and adoption of “.STRING”. The Applicant will also actively seek out ingenious usage of “.STRING” and to work with them to promote the awareness and positive use of “.STRING”.

23. Registry Services
23.1. Registry Services
The Applicant is the Registry Operator of ʺ.STRINGʺ.
The Applicant will be responsible for providing the services as specified in Specification 6 section 2.1(a) and (b) and Appendix A in the ICANN’s Applicant Guidebook as well as those as specified in Appendix A. In particular, The Applicant shall prohibit the use of wildcard per requirements specified in Specification 6, section 2.2.
The Applicant provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the Applicant will abide with the requirements of ICANN and IANA and shall comply to the technical standards as specified in Specification 6, Section 1 of the ICANN’s Application Guidebook. The Applicant shall also implement support for IDN, DNSSEC and IPv6.
The Applicant will outsource the technical operation to KNET (“Back-End Service Provider”) while the remaining operation will be handled by Zodiac Holdings Limited.
The KNET Shared Registry Platform (“KSRP”) is designed and implemented to provide robust and highly available registry services.
Zodiac Holdings Limited, ie the Business Registry Operator (“BRO”) will have a combined business registry operation team for all its TLD Registry operation. The Business Operation Provider shall provide an effective business operation team that guarantee the highest performance to ensure business continuity as well as reducing domain name abuses.
Note: The Specifications stated in this document refer to the Specifications in ICANNʹs gTLD Applicant Guidebook.
23.1.1. Service Level
KSRP conforms to the requirements in Specification 10 of ICANNʹs Applicant Guidebook. For the summary of the service level agreement, please refer to Table 23-1 (attached in Q23 answer).
23.1.2. Security
KSRP conforms to the ISO27000 standard in its design, implementation and operations. KSRP institutes the following security measures:
a) A set of operation policies and procedures that shall be strictly followed by service operations personnel.
b) A set of security policies that shall be strictly followed for service management and engineering activities.
c) A monitoring center that is only accessible by authorized staff members. Any management operation is performed on a bastion host only after an authorized staff member successfully logs in to the bastion host with a correct password; comprehensive logging and auditing are enforced for all activities for the entire process;
d) All equipment and services are being monitored on a 7×24 basis by a technical team. In case of emergency, risks will be assessed and mitigated with minimum delay.
e) The firewalls, IDS and network traffic monitoring system are deployed in to provide network layer security and protection against attacks;
f) The databases, applications, source code, documents, system logs and other business data of all services are backed up offsite and offline on a regular basis so that they can be restored quickly in case of a failure;
g) Critical data are transferred via a secure channel, such as VPN, HTTPS, and TSIG with data validation to ensure security and integrity.
Additional measures specific to a subsystem will be documented in the section of that subsystem.
23.1.3. Stability
The Applicant adopts the following measures to ensure the stability of its services. Additional measures specific to a subsystem will be documented in the section of that subsystem.
a) A primary data center and a geo-dispersed backup data center are deployed in an active⁄standby manner; when the primary data center is not available, the backup data center is activated to continue the services; high availability of the services are guaranteed by measures such as database hot standby and server clustering via load balancing;
b) The services provided by the Applicant fully comply with relevant RFCs and other widely accepted industry technical standards. The system will undergo a series of sustained stress testing before the service is open to the public;
c) All equipment, power supplies, network interfaces and network connectivity are deployed in a redundant way so that no single point of failure would result in service interruption;
d) During the daily operation of the services, the operating team closely monitors the system in terms of equipment load, network bandwidth and response performance to ensure capacity sufficiency and redundancy during peak business hours;
e) The SLAs of all registry services are actively monitored and maintained pursuant to ICANN requirements (Specification 10 of gTLD Application Guide book).
23.2. The Receipt of Data from Registrars Concerning Registrations of Domain Names and Name Servers
The Applicant receives the data from Registrars concerning registrations of domain names and name servers.
The Applicant provides the SRS service. Registrars collect the data from end users related to registration contacts, domain names and name servers and submit them to the Applicant via the SRS system; the Applicant also provides add-on auxiliary services for Registrars to submit other business-related data as required by the Applicant;
23.2.1. Service Level
The service level of the SRS provided by the Applicant meets the requirements specified in Specification 10 of ICANNʹs Applicant Guidebook. Please refer to the answer to Q24 Share Registration System (24.2.2) for details.
23.2.2. Security
Only ICANN accredited Registrars are considered to be candidate Registrars for the Applicant.
To connect to the SRS platform of the Applicant, a Registrar must provide a set of fixed static IP addresses to the Applicant beforehand. The SRS service only opens specified service ports to those static IP addresses provided by the Registrar. Dynamic IP addresses are not accepted.
The SRS system employs a combination of Registrar ID, high-security password authentication, Registrar certificate authentication and encryption protocol to ensure the connection between the Registry and a Registrar is secure and robust for data transfer.
To mitigate the risk of malicious cybersquatting, the SRS system enforces a cap on the maximum number of sessions between the Registry and a Registrar, and the maximum number of transactions in unit time from a Registrar.
23.2.3. Stability
The SRS service provided by the Applicant complies with the relevant policy requirements of ICANN. It conforms with the EPP1.0 and other relevant RFCs including RFCs 5730-5734, RFC 3735 and RFC 3915.
The Applicant provides Registrars with the adequately tested EPP Client SDK and manual.
The SRS service puts a cap on the number of connections and the transaction volume in unit time for each Registrar System capacity for peak business hours is ensured by hardware redundancy and load balancing.
23.3. Information Publication
The Applicant will build its official website to make the following information available:
a) Registration management policies;
b) Hotline and Email address for complaints⁄reporting;
c) Public key for DNSSEC;
d) Incident report;
e) Advanced notice of planned outage (due to system upgrade, etc.)
f) SLA report;
g) Whois service.
The Applicant will also release necessary information on these topics via Email to relevant parties including ICANN,IANA,Registrars,Registrants etc.
23.4. Provision of Status Information Relating to the Zone Servers for the TLD
When a Registrar requests for any information such as the status of zone servers, the Applicant will provide such information to the Registrar via Email or by telephone following the pre-defined procedures.
In case there is a change made or planned to be made to the zone servers, such as adjustment of volume of nodes and status transition, affected Registrars will be informed in accordance with the pre-defined procedures.
For security and stability concerns, the service is only made available to those accredited Registrars according to the pre-defined procedures.
23.5. Dissemination of TLD Zone Files
The dissemination of TLD zone files from the central database to DNS service nodes is done by the zone file generation program, dissemination program and the hierarchically and globally distributed DNS system.
All changes in DNS records generated by the data centers are first updated to the primary DNS node; these updates are then disseminated by the master⁄slave update mechanisms to all other DNS nodes.
23.5.1. Service Level
The SRS service level provided by the Applicant meets the Specification 10 of the ICANNʹs Applicant Guidebook. Please refer to the answer to Q35 DNS Service (35.3) for details.
23.5.2. Security
In addition to those described in 23.1.1, the following security measures are also adopted.
The data source of zone files is stored in the domain name database deployed behind the internal firewall with the top-level network security policies. The zone files generation program and the SRS system are located in the DMZ.
The zone files dissemination program supports two modes: full update and incremental update. The incremental update is invoked periodically while the full update is triggered only by unusual circumstances to ensure service ability.
a) Full update. The zone files generation program reads the data in the domain name database to generate the complete zone files. The database connection used by the generation program is read-only. The generated zone files will undergo a series of checks in terms of integrity, syntax and data change rate before invoking the subsequent dissemination procedures.
The data change rate check inspects whether the number of lines in the zone files and⁄or their sizes have changed significantly. If the change is over 5% since the last backup, alarm will be triggered.
Once the zone files are generated and pass the validations, they will be first transferred to the hidden master DNS server. When the system invokes full update, they will be distributed to the global authoritative DNS nodes through the master⁄slave update mechanism of DNS.
b) Incremental update. This program monitors any zone-file-related data changes occurred in the SRS database. When such changes occur, the changed data will be sent to the hidden primary DNS on a periodic basis, and then disseminated to the global authoritative DNS nodes by the master⁄slave update mechanism of DNS. The system automatically checks incremental update data and confirms that each update is properly performed. If any abnormal changes are detected, the system automatically generates an alarm and aborts the update.
23.5.2.1. Data Transfer Security
a) The data transfer between the hidden primary DNS and the global distributed resolution nodes is done via VPN;
b) Digital signature is added using TSIG;
c) Some specified test is performed to check the consistency of the DNS data.
23.5.3. Stability
In addition to those described in 23.1.2, the following stability measures apply to zone file dissemination:
a) The interfaces between the SRS and the hidden master DNS server conforms to RFC 2136 and RFC 2137;
b) Zone files of the hidden master DNS are transferred to the global distributed DNS nodes via incremental zone files using the TSIG per RFC 1995, RFC 1996 and RFC 2845.
23.6. Operations of the Registry Zone Servers
The Back-End Service Provider is in charge of the operation of the zone servers as part of the KSRP. It has many years of experiences in developing and operating domain name system in China.
The operations of the zone servers mainly involve synchronization of resolution data, response to DNS queries, statistics monitoring and reporting, and continuous improvement of security, stability and performance. The goal is to provide correct, reliable and fast DNS services to the global Internet users for the Applicant.
23.6.1. Security
In addition to those described in 23.1.2, there are also the following security measures for zone server operations.
The Back-End Service Provider has deployed global production zone servers based on RFC 2870, such that:
a) The capacity exceeds 3 times of the peak traffic volume;
b) Recursive queries and other services such as remote Internet protocols including HTTP, TELNET, RLOGIN and FTP are strictly forbidden;
c) Hidden primary DNS servers are deployed in the system for zone file updates;
The Back-End Service Provider has established the primary⁄backup data centers and globally distributed DNS nodes with access to the Internet from more than one ISP in each location to ensure uninterrupted DNS services against natural and⁄or human-caused disasters.
Zone file transfer is secured by ACL policies of routers⁄switches⁄IPtables, restriction of IP address in zone files such as allow-notify and allow-transfer, as well as TSIG.
The primary and backup data centers use VPN to ensure network layer security of data transfer.
KSRP employs sophisticated automated monitoring system to timely detect any failures of zone servers as well as other software and⁄or hardware failures, and resolve traffic anomalies. It performs real-time monitoring and analyses to detect potential attacks and to take necessary actions against them.
In addition, The Back-End Service Provider is developing a domain security software to further enhance KSRPʹs abilities to handle more sophisticated security threads. The new capabilities will be gradually applied to the shared TLD production once it is fully developed and tested.
23.6.2. Stability
In addition to those described in 23.1.3, the following stability measures apply to DNS zone servers.
a) The Back-End Service Provider uses the latest stable version of ISC BIND and NSD to ensure that DNS software deployed for KSRP are most updated against known security vulnerabilities.
b) The primary and backup data centers use VPN for secure and stable data transfer.
c) The Back-End Service Provider has provisioned additional network bandwidth in each of the data centers hosting the DNS zone servers to handle unexpected high volume domain name queries to DNS servers. Refer to specific sections for details.
d) The Back-End Service Provider uses BGP+Anycast technologies to build the global distributed domain name resolution service platform where polices can be adjusted to schedule and limit traffic in any unusual circumstances (especially in the case of DDoS attacks).
23.7. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations in the TLD
The Applicant provides the domain name query, contact query and name server query services according to the data contents and formats requirements stated in Specification 4 of ICANNʹs Applicant Guidebook.
The Applicant provides the Web Whois and Whois Server services and disseminates contact and other information concerning TLD server registration according to the Registryʹs protocols.
The Applicant provides two types of Whois query service: general queries and searchable queries.
The Applicant provides ICANN and other authorized third parties access to the “.STRING” zone files.
The Applicant provides ICANN with bulk registration data through the interfaces specified by ICANN.
23.7.1. Service Level
The service level provided by the Applicant meets Specification 10 specified in the Applicant Guidebook. Please refer to the answer to Q26 Whois System (26.2.2) for details.
23.7.2. Security
In addition to those described in 23.1.2, the following security measures apply to services in section 23.7.
a) No sensitive data are stored in Whois database.
b) The Web Whois service uses the CAPTCHA to reduce automated malicious queries.
c) Both Web Whois and Whois Server services impose a cap on the maximum number of queries in unit time from the same IP address to reduce the query volume from automated programs.
23.7.3. Stability
In addition to those described in 23.1.3, the following stability measures apply to services in section 23.7.
a) The Whois service follows RFC 3912, meeting the requirements specified in Specifications 4, 6 and 10 of the ICANNʹs gTLD Applicant Guidebook.
b) The Whois service runs on redundant server clusters that are load balanced; an offsite backup data center is established to address disastrous emergencies.
23.8. Internationalized Domain Name Service
The TLD applied in this application is an internationalized domain name. The Back-End Service Provider formulated the IDN policies for ʺ.STRINGʺ TLD and developed KSRP based on the latest IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄implementation-guidelines.htm).
The IDN labels in the Applicant follow the .CN Chinese IDN Table and KSRPʹs IDN support complies with the IETF protocols (RFC 3454, 3490, 3491 and 3492) and IDNA2008 (RFC 5890, 5891, 5892, 5893 and 5894).
KSRP accepts IDN registration requests and performs registration for the original applied IDN. Any newly registered domain names must go through pre-auditing by the auditing system of the Registry business support platform. The audit system will generate a group of IDNs from those variant characters of the new domain name based on RFC 3743 and display those in the group that are already registered. An auditor will perform the pre-auditing on these variants using a set of predefined examination rules. The auditor may reject the registration of the new domain name if it is deemed to cause confusion due to visual similarity.
The query function of the Whois system accepts domain names in both UTF8 and ASCII formats.
The zone file generation program directly reads the domain name Punycode strings and other relevant data stored in the database to generate zone files. KSRPʹs zone file dissemination subsystem described in 23.5 supports zone data in Punycode format.
23.8.1. Security
With many years of experiences in operating.CN (supporting IDN) and .中国⁄.中國. The Back-End Service Provider is confident that registration of the IDNs through the above-mentioned technical business system is free from any security risk.
23.8.2. Stability
With many years of experiences in operating.CN (supporting IDN) and .中国⁄.中國, The Back-End Service Provider is confident that the performance of the IDN business following the above-mentioned technical business system is free from any stability risk.
Theoretically, creating IDN domain names takes longer in KSRP due to additional computational overhead incurred by the existence of IDN variants. However, such simple computations have a very small impact on the performance. In order to improve the performance of DNS data dissemination, the SRS system stores the corresponding Punycode character strings for the registered IDNs, consequently eliminating additional computation brought by zone files generation. Moreover, since only the original character string within the group of variants is allowed to be submitted by the user, storage capacity for IDN is not increased.
Meanwhile, compared with ASCII-based domain names, IDNs do exhibit a common display problem. However, the display of Chinese characters currently has matured and the Registry services provided for ʺ.STRINGʺ have very good support for displaying Chinese domain names.
In summary, the introduction of IDNs in ʺ.STRINGʺ Registry shall have negligible impact on the performance of its Registry services.
23.9. DNSSEC
KSRP is designed to fully support DNSSEC. The Applicant provides the following DNSSEC services:
a) Authentication and distribution of public keys of KSKs;
b) DNSSEC-based DNS services;
c) Data protection during zone files transfer.
The Applicant deems DNSSEC as critical for its registry services. The Back-End Service Provider plans to actively drive adoption of DNSSEC in KSRP in 3 stages:
a) Stage 1: Test-Bed. At this stage, The Back-End Service Provider intends to build an internal test-bed on which the technical tracking, verification and testing will be performed; the DNSSEC chain of trust will be built on a small set of selected second and lower level domains under the applied TLD; the DNSSEC Operational Practices (RFC 4641) will be followed and exercised. The goal is to complete the technical verification of DNSSEC and to develop best practice documentations based on the lessons learned. This stage is estimated to last for 6 months;
b) Stage 2: Public Trial. At this stage, the chain of trust will be built on domain names that are registered for trial based on the best practice developed at the first stage, and the DNSSEC policies will be verified or adjusted based on the trial results. This stage is estimated to last for 6 months;
c) Stage 3: Production. At this stage, the DNSSEC will be put into use officially according to the achievements of the previous two stages. The implementation of DNSSEC will be applied to the TLD and all of its sub domains in production KSRP.
After implementation of DNSSEC, the performance indicators of relevant services will be affected to some extent, such as increase in storage capacity, in CPU load and memory of the resolution system and in network bandwidth for resolution services. However, such implementation has only negligible impact on resolution query performance and QPS. Through vertical extension, horizontal extension and bandwidth upgrade, KSRP will still be able to sufficiently meet and exceed the service levels required by ICANN stated in this application.
23.9.1. Security
DNSSEC is one of the important measures against the security defect of DNS system. The public key infrastructure (PKI) is used to add a digital signature to each resource record set to improve the security level of domain system.
There are two kinds of keys, KSK (Key-signing Key) and ZSK (Zone-signing Key), created for DNSSEC. The former is used to sign DNSKEY resource record sets while the latter is used to generate signatures for all resource records within the zone, including KSK record sets.
KSRP uses hardware encryption equipment HSM (complying with FIPS 142-2 level 3) to generate keys; the keys stored in an HSM cannot be exported; they are automatically synchronized among the HSMs. Unauthorized access to private keys of KSK and ZSK is strictly forbidden, and offline storage is achieved with best possible efforts.
A periodic key update system is established, in which the KSK lifetime is 1 year and the ZSK lifetime is 1 month.
23.9.2. Stability
The DNSSEC deployment in KSRP is compliant with RFCs 4033~4035, RFC 4310, RFC 4509, RFC 4641, RFC 5155, RFC 5910 for DNS data origin authentication, data integrity verification and authenticated denial of existence.
KSRP is designed to fully support DNSSEC, by reserving interfaces for SRS, Whois and DNS systems.
As DNSSEC signature involves significant computation and data volume, generation and verification these signatures will result in much more CPU time; the disk space incurred by signatures and keys storage will be 10 times or more of that without DNSSEC.
Before DNSSEC is fully deployed for the Applicant, The Back-End Service Provider will upgrade KSRP capacity in database backend servers, disk space, network bandwidth, DNSSEC signing device, other supporting systems and equipment to ensure operation stability and redundancy.

24. Shared Registration System（SRS）
24.1. Overview
The Applicant provides Registrars with a registration interface for the domain “.STRING” through KSRP provided by the Back-End Service Provider. The SRS provided by KSRP complies with the requirements of ICANN and IANA as well as relevant RFCs and other technical standards. It is designed and implemented to provide highly available, secure, scalable and high performance services.
24.1.1. System Architecture
The SRS consists of the domain registration system (EPP server) and other subsystems for domain name registration. Please refer to Figure 24-1 in Q24_attachment for the system architecture of SRS. Below is the detailed description.
a) EPP Server
The EPP server provides Registrars with domain registry services such as the creation, modification, deletion and other key functions of domain, contact and host objects. It also provides support for the redemption grace period and DNSSEC as specified in relevant RFCs.
b) Registrar Business Support System
The registrar business support system provides supporting functions to Registrars concerning domain registration. Upon successful authentication, a Registrar may perform a real-time check of account balance, monthly bill report, and domain operation records. It may also check its payment and usage details within a year. The Registrar can also use the system to report any problem to online customer support staff for solutions. In addition, Registrars may retrieve specifications, FAQs and other technical documents concerning ʺ.STRINGʺ TLD domain name registration in the knowledge base.
Registrars may also access the business support system via FTP to download historical data such as domain operation records and billing reports upon successful authentication.
c) Registry Business Support System

Please refer to Figure 24-2 in Q24_attachment for the system architecture of the Registrar business support system.
The Registry business support system provides business staff of the Applicant with the support services concerning domain registration, including auditing of newly registered domains, recharging of registrarsʹ accounts, and locking⁄unlocking of domains.
The registry business support system will regularly compile the registered domain data and zone file into a data file with specified type and formatting of content as described in ICANNʹs Registry Agreement, and uploads the data file on specified SFTP for ICANN and its designee to access and download.
In addition, the registry business support system will regularly generate a data file with specified type and formatting of content as described in ICANNʹs Escrow Agreement, and uploads the data on specified SFTP of the escrow service provider NCC Group for its service provision.
d) Zone File Synchronization Service
The zone file synchronization service is responsible for synchronizing changes made to the SRS database to the master DNS nodes, and through which all global DNS nodes are subsequently updated.
e) Databases
The SRS database is the master database that stores information about domains, contacts and hosts submitted by the EPP server. It is replicated to the Whois database using the Oracle Advanced Replication. The Registrar & Registry (hereafter referred to as R&R) business support database stores the data relating to the support business, such as billing reports, and historical auditing records, etc..
24.1.2. Physical Architecture
Please refer to Figure 24-3 in Q24_attachment for physical architecture of SRS.
The SRS system and the R&R business support system are deployed in multiple servers that are clustered and load balanced via F5s; both the SRS master database and R&R business support database achieve high availability via Oracle Veritas. A disk array is deployed at the back-end for data storage redundancy and for high throughput database access.
24.1.3. Equipment List
Please refer to Table 24-1 in Q24_attachment for a list of equipment of the SRS (excluding any hardware shown in the topological diagram of the primary data center, such as routers or firewall).
24.2. Operations Plan
24.2.1. Availability
The SRS of the KSRP is able to provide 99.9% availability, ensuring the monthly down time not exceeding 43.2 minutes, therefore fully meets the 98% availability requirement specified in ICANNʹs Specification 10. In addition, the SRS is also redundantly deployed at the backup data center. If the primary data center goes off-line, registry services are switched over to the backup data center within 30 minutes to ensure high availability of the services.
Specifically, SRS ensures high availability in the following aspects:
a) The SRS software has been built via rigorous engineering disciplines such as code review, unit testing and daily builds. Any SRS build must pass the thorough integration testing, system testing and acceptance testing prior to deployment in production.
b) Both the hardware and software systems are redundantly deployed. Load balancers (F5) are deployed to distribute requests to server clusters to mitigate unplanned server hardware and software failures. For example, the EPP server is deployed on multiple servers as a cluster behind the load balancer so that even if one of the servers goes down, F5 will automatically distribute the requests to the rest of functioning servers, to ensure the registry services continuity.
c) The database of the SRS achieves high availability via Oracle Veritas to prevent any unplanned outages of the database backend.
24.2.2. Performance
The KSRP is designed to scale up to 30 million domains, and the performance test result shows that it is able to handle 3000 transactions per second. Hence KSRP is able not only to meet the current needs of the Applicant, but also to scale for future demand of the Applicant as the business grows.
Comparison with SLR Indicators
Please refer to the Table 24-2 in Q24_attachment for the contrast between the test results of the SRS and the SLR indicators specified in Specification 10.
24.2.3. Scalability
SRS is developed and deployed using distributed technology that is able to scale both vertically and horizontally as follows:
a) Support vertical scalability by upgrading the hardware of online servers;
b) Support horizontal scalability by deploying server hardware and software systems in a cluster;
c) When the system load reaches the maximum capacity of the SRS system, it can be upgraded by adding more servers and bandwidth to meet the performance and throughput capacity needs
24.2.4. Security
In order to ensure the security of the SRS, the KSRP has taken the following measures:
a) SSL⁄TLS protocol is used for connection between the SRS and the clients. When connecting the SRS, a Registrar is required to be authenticated with SRS using its user name, password, IP address and the digital certificate authorized by the KSRP; if the Registrar fails the ID authentication 3 times, it has to wait for 30 minutes before another attempt;
b) SRS has put a strict restriction on the number of connections created by Registrars as well as the idle time in TCP;
c) SRS is deployed in the DMZ in order to prevent unauthorized network access to the backend database.
24.2.5. Data Synchronization
Data synchronization between the master database of SRS and the Whois database is realized via Oracle Advanced Replication at an interval of 5 minutes.
Data synchronization between the primary and the backup data center is realized via Oracle Dataguard at an interval of 5 minutes.
24.2.6. Operations and Maintenance
The following operations and maintenance measures have been established to guarantee the quality of services.
a) SRS is being monitored and protected on a 7×24 basis. With the monitoring system, KSRP keeps track of the performance of the whole system so that it can take timely measures to address any emergency;
b) The Applicant and KSRP have established a thorough emergency response mechanism to effectively handle emergency situations. The mechanism provides handling and upgrading procedures for different types of failures based on pre-classified severity levels.
24.3. Compatibility
SRS fully complies with EPP and supports RFCs mentioned in Specification 6, including RFCs 5730～5734, RFC 3735 and RFC 3915.
KSRP supports IDN based on IETF RFC 3454 and RFCs 5890～5892. When the user registers a domain name under ʺSTRINGʺ, SRS will store the domain data and its corresponding Punycode into the SRS database.
Regarding support for DNSSEC, KSRP has designed its interfaces according to RFC 5910. A plan is in place for smooth transition to DNSSEC in KSRP once DNSSEC-related tests are completed on the platform.
The Back-End Service Provider has dedicated R&D personnel who closely follow the DNSSEC work in IETF and the industry, so that the platform can be timely upgraded to meet the requirements of ICANN in case there are changes in the future.
24.4. Resourcing Plan
The development and test work for SRS has been completed. See Table 31-11 in Q31_attachment for the overall human resource planning of KSRP. The human resource in Table 31-11 can be allocated for other systems at the same time. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.

25. EPP (Extensible Provisioning Protocol)
25.1. Overview
The Applicant provides services to the public through KSRP provided by the Back-End Service Provider. KSRP provides Registrars with a registry service interface for the domain name .STRINGʺ over EPP 1.0. The Back-End Service Provider has years of experiences in implementation and maintenance of the EPP1.0 interface for the .cn Registry.

25.2. Introduction to EPP
EPP is an xml-based text protocol. It is widely used as a standard protocol for domain name registration between Registry and Registrar.
The EPP protocol suite consists of RFCs 5730～5734, RFC 3735, RFC 3915 and other relevant RFCs. The core of EPP is specified in RFC 5730, which defined the EPP commands, request-response mechanism, message format, result code and other basic protocol elements. RFCs 5731～5733 define the mapping of domain name, contact and host objects on EPP respectively. RFC 5734 explains how to safely implement EPP over TCP. RFC 3735 provides guidelines on how to extend EPP. RFC 3915 extends EPP to handle different redemption grace periods in registration life cycle. RFC 5910 describes how to support DNSSEC based on EPP. The aforementioned RFCs cover all functions, procedures and expansion mechanisms required by domain registry services.
EPP provides four basic service elements: service discovery, commands, response and an extension framework.
The EPP commands are divided into session management commands, query commands and object transform commands. The first category is used to establish and close connections between a client and the server; the second category is used to query information such as domain name, contact and host from server; the last category is used to manage the domain name, contact and host objects.
The responses to EPP commands must include a result code and a detailed description of the code. The result code is a 4-digit number. The first digit represents success or failure of command execution (1 for success, 2 for failure); the second digit represents the classification of responses (6 categories in total); the last 2 digits represent the explicit description of the result code in each category of response. For example, an result code for an EPP command is 1000, where 1 stands for success of command execution, the second digit 0 implies this EPP command is ʺProtocol Syntaxʺ (one category of responses), and the final two digits imply the description of the result code is ʺCommand completed successfullyʺ.
KSRP implements EPP based on TCP (refer to RFC 5734). The server listens on port 700. The client issues EPP commands to the server after both sides have passed the two-way certificate authentication and have successfully completed the execution of the Login command. The EPP server executes the received commands in order. Upon completion of processing an EPP command, the server packages the results into an EPP response to be returned to the client. Both sides repeat the request-response cycle until either the client requests the server to close the connection (via the Logout command) or the execution of a command requires that the server terminate the connection after the command execution (according to RFC 5730, the result codes 2500~ 2502 demand that the server proactively close the connection).
25.3. APIs Provided for Registrars via EPP
KSRP implements registration APIs for Registrars based on EPP1.0. These APIs cover all functions required by domain registry services, including opening and closing of connections, and processing of commands such as query, creation, modification, transfer and deletion of domain, contact and host objects.
a) Session Management
APIs provide Login command and Logout command to Registrars. By using these commands, Registrars can interact with KSRP, such as executing ID authentication (via Login command) or closing connections (via Logout command).
A Registrar sends the Login command to request ID authentication and session establishment with the EPP server; Upon successful authentication and session establishment, Registrars begin to send other EPP commands. Each of the subsequent commands shall contain the authentication token and the Registrarʹs password. When the Registrar completes the session, it may send a Logout command to the EPP server to close the connection.
b) Query
APIs provide the query commands such as Check command, Info command and Transfer command to Registrars. Registrars may use these APIs to query information or status about domain, contact and host objects. (Please refer to Table 25-1 in Q25_attachment)

The Check command is used by Registrars to check the existence of the queried data objects (domain names, contacts or hosts).
The Info command is used by Registrars to retrieve the detailed information about domain names, contacts or hosts that exist in the Registry.
The Transfer command is used by Registrars to check the current transfer status of domain names and contacts.
In addition to the above-mentioned commands, Registrars may also use the Poll command to query and retrieve the asynchronously queued service messages from the EPP server.
c) Object Change
APIs provide several object change commands to Registrars. Through these commands, Registrars may create, modify, delete and perform other operations on domain names, contacts or hosts. (Please refer to Table 25-2 in Q25_attachment)

The Create, Update and Delete commands are used by Registrars to perform basic management functions on domain names, contacts and hosts.
The Renew command is used by Registrars to renew a domain name.
The Transfer command is used by Registrars to transfer domain names or contacts.
The Restore command is closely related to the redemption grace period. When a domain name is deleted, its EPP status is ʺpendingDeleteʺ and the RGP status is ʺredemptionPeriodʺ. Registrars are allowed to restore the deleted domain names to the normal state via the Restore command (Restore is not an EPP command in fact; it is implemented by the extended Update command).
d) Miscellaneous
KSRP ensures that all the APIs comply with RFC 3915 and RFC 5910 to support not only redemption grace period operation such as registry grace period and renew grace period but also DNSSEC.
During the add, renew, or transfer grace period, if a Registrar deletes a domain name, the cost incurred will be refunded to the Registrar by the Registry.
If a domain name expires, the Registry will determine whether to auto-renew a Registrarʹs account and enter the auto-renew grace period based on its account balance. If the Registrar deletes the domain name during the period, the renewal fee incurred will be refunded by the Registry.
Regarding the support for DNSSEC, Registrars may submit the information of Delegation Signer to the Registry over EPP and perform modification and deletion operations.
25.4. Compatibility
The interfaces of KSRP for Registrars comply with EPP1.0 as defined by IETF RFCs and support DNSSEC and redemption period functions.
25.4.1. Compliance with RFCs
The interfaces for Registrars mainly follow the RFCs 5730～5734 and RFC 3915. If the standard EPP canʹt meet certain specific business requirements, extensions will be made to KSRP based on RFC 3735.
a) Compliance with RFC 5730
RFC 5730 is an overall description of the EPP, mainly defining the EPP message format, result code and date format. KSRP strictly follows the RFC as the basis for its EPP implementation.
b) Compliance with RFC 5731
KSRP complies with RFC 5731 in implementing the domain-related command, such as Create, Modify, Delete, Check, Transfer and Info.
c) Compliance with RFC 5732
KSRP complies with RFC 5732 in implementing the host-related commands, such as Create, Update, Delete, Check, and Info.
d) Compliance with RFC 5733
KSRP complies with RFC 5733 in implementing the contact-related commands, such as Create, Update, Delete, Check, and Info.
e) Compliance with RFC 5734
KSRP complies with RFC 5734 in implementing TCP-based EPP and performs certificate–based authentication via TLS to ensure the data security.
f) Compliance with RFC 5735
KSRP has not yet used RFC 5735 to extend EPP protocol. However, if the Applicant’s business requires functional expansion to be made to the standard EPP, KSRP will strictly follow the RFC 5735 and the requirements specified in the agreement and specifications in ICANNʹs Registry Agreement.
25.4.2. Specification Related to Redemption Period (RFC 3915)
KSRP complies with the RFC 3915 in implementing the registration life cycle policy, including add grace period, renew grace period, transfer grace period and auto-renew grace period, as well as the corresponding statuses.
25.4.3. Specification Related to DNSSEC (RFC 5910)
KSRP complies with RFC 5910 and RFCs 4033～4035 in implementing support for DNSSEC and enabling Registrars to submit their DS record to the Registry and to perform the modification and deletion operations.
25.5. Consistency
25.5.1. Consistency with Technical Plan
The SRS of KSRP fully implements EPP1.0, covering all functions required by the domain name registry services. Moreover, it provides Registrars with the fully tested EPP client and detailed documentation of its APIs.
25.6. Resourcing Plan
The development and test work for the SRS has been completed. In addition, the OT&E (Operational Testing and Evaluation) environment is also made available at ote.tld.knet.cn via port 3121. Please refer to Table 25-3 in Q25_attachment for the resourcing plan.

26. Whois System
26.1. Overview
The Applicant provides Whois services to the public through KSRP. The Whois system of KSRP is implemented in accordance with RFC 3912 and other requirements specified in Specification 4 of the Registry Agreement. It meets the SLR indicators specified in Specification 10 in terms of performance and availability, and provides scalability for growth.
26.1.1. Software Architecture
For the diagram of software architecture of Whois, please refer to Figure 26-1 in Q26_attachment. Below is the detailed description.
The Whois system consists of the Whois server and the Whois web server, which can be accessed from either command-line or web. The command line query requests directly access the Whois server while the web-based query requests access the web page on the Whois web server .
a) Full-text Search System
The full-text search system provides the searchable Whois functions via the Apache Solr. It scans the Whois database every 10 minutes. If there are any data changes, the search system will update the search indices accordingly.
b) Database
The SRS master database synchronizes only the data fields required by the Whois system to the Whois database via Oracle Advanced Replication. Any sensitive data that may leak privacy information of Registrants or Registrars or are prohibited by local laws and regulations are not replicated.
26.1.2. Physical Architecture
For the physical architecture of Whois, please refer to Figure 26-2 in Q26_attachment. Below is the detailed description.
The Whois server and Whois web server are redundantly deployed on multiple servers that are load balanced behind the F5s.
The full-text search service is deployed on master and slave servers. The master server synchronizes data and changes indices with the Whois database. It then synchronizes the changed indices and data to several slave servers. These slave servers are clustered behind the load balancer (F5) to provide searchable Whois services.
There are multiple Whois servers that are behind the load balancer (F5) to achieve load balancing and high availability.
26.1.3. Equipment List
See the Table 26-1 in Q26_attachment for a list of equipment of the Whois system (excluding any hardware equipment appeared in the network topological diagram of the primary data center):

26.2. Operation Plan
26.2.1. Availability
The KSRP has adopted the following measures to ensure high availability of the Whois system.
a) The hardware equipment and software systems used for the Whois system are redundantly deployed as server clusters that are load balanced behind the F5s.
b) The Whois system is redundantly deployed at the backup data center. In case of any unexpected disasters, KSRP can be switched over the backup data center within 30 minutes to continue its Whois services.
KSRP ensures that the downtime due to outages will not exceed 43.2 minutes monthly, with a high service availability of 99.9%, exceeding the SLA indicator (98%) specified in Specification 10 of the Registry Agreement.
26.2.2. Performance
KSRP is designed to scale to handle 30 million domains. The performance test results shows that KSRPʹs Whois system is capable of handling 5000 queries per second or about 430 million queries a day with the maximum response time not exceeding 1150ms.
As a result, KSRP exceeds the performance indicator of the Whois system specified by ICANN and is scalable for future demands.
Comparison with SLR Indicators
See the Table 26-2 in Q26_attachment for the contrast between the test data of the Whois system and the SLR indicators specified in Specification 10.
26.2.3. Scalability
The Whois system supports both vertical and horizontal scalability. When KSRP reaches its maximum domain name capacity, the performance and throughput capacity of the Whois system can be expanded by upgrading production server hardware (vertical scalability) and⁄or adding more servers and bandwidth (horizontal scalability).
26.2.4. Data Synchronization
Data in the SRS database are synchronized to the Whois database via Oracle Advanced Replication at an interval of 5 minutes; the changed data of Whois database are synchronized to the full-text search system at an interval of 10 minutes.
Given the above data synchronization intervals, the command-line query requests and the web-based query requests have a latency of about 5 minutes, and the searchable query has a latency of about 20 minutes. Both latencies fully meet the Whois data update time (a latency of 60 minutes) specified in Specification 10.
26.2.5. Searchable Whois
KSRP implements the searchable Whois function via the full-text search technology of Apache Solr. The user logs on to the page specified by the Whois Web Server after passing the ID authentication, and inputs the query criteria as required in Specification 4; the Whois Web Server will forward the query request to the full-text search system which searches and returns the qualified results to the result page of the Whois Web Server.
How to Prevent Abuse
The searchable Whois function may be abused by malicious users to send spams to the Registrants or Registrars by harvesting email addresses from the query result. Such abuses may cause negative impacts on the Registrants and Registrars that may violate local laws and policies.
The Applicant will take the following measures to prevent the searchable Whois function from abuses without violating local laws and policies:
a) The user must input the correct CAPTCHA before submitting each searchable Whois query request.
b) Only those insensitive contents meeting Specification 4 are allowed to be displayed in query results.
c) No more than 20 results are allowed to return for each searchable Whois query.
d) Impose a cap on the maximum number of queries in unit time from the same IP address.
26.3. Compliance with Relevant Specifications
26.3.1. Compliance with RFC 3912
The Whois system complies with RFC 3912 and listens to port 43.The client interacts with the Whois Server via TCP to complete the request-response process: the Client submits a text-based request to the Whois server; the Whois server then returns the query result in a text-based response to the Client.
26.3.2. Compliance with Specification 4 of the Registry Agreement
KSRP fully complies with Specification 4 of the Registry Agreement in terms of Whois query, zone file access and bulk registration data access.
a) Whois Query
The Whois system fully meets the relevant requirements specified in Specification 4 in terms of data objects (domain name, Registrar and name server), contents, queries and response format.
The Whois system provides two query methods: command line query and web-based query. The former is implemented according to RFC 3912 where the client interacts with the Whois Server in a request-response pattern. The latter is implemented as follows: the user accesses a specified page, inputs the query contents, selects query criteria (domain name, Registrar, name server), types in a CAPTCHA and then submit the query request. After receiving the request, the Whois Web Server will check the CAPTCHA. If the code matches, the Whois Web Server will retrieve the query result from the Whois Server and show the response content to the users in the resulting page.
b) Zone File Access
The Applicant allows third-party entities who enter into an agreement with the Registry to access the zone file through KSRP according to Specification 4. It also provides ICANN or other ICANN designated partners with bulk access to authoritative zone files in the format and manner as specified in Specification 4.
c) Bulk Registration Data Access
The Applicant will provide ICANN with registration data at specified time through KSRP. The content and format of provided data completely comply with the applicable requirements in Specification 4.
Moreover, when a Registrar is no longer able to provide the domain registry services, the Applicant will submit all domain name data owned by that Registrar to the ICANN within the specified period. The content and format of provided data completely comply with ICANNʹs requirements.
26.4. Resourcing Plan
The development and test work for the Whois system of the KSRP has been completed. See Table 31-11 in Q31_attachment for the overall human resource planning of KSRP. For the resourcing plan of this system, please refer to Table 26-3 in Q26_attachment and the above 26.1.3 for equipment resource planning.

27. Registration Life Cycle
27.1. Overview
The Applicant defines the life cycle of the domain names under ʺ.STRINGʺ based on IETF RFCs required by ICANN and its own business needs. The life cycle consists of 6 periods: Available, Registered, Autorenew Period, Redemption Grace Period and Pending Delete.
A domain name upon creation officially takes effect and enters the Registered period (the EPP status is serverTransferProhibited for the first 60 days, afterwards, it changes to ok; the RGP status is addPeriod for the first 5 days and then changes to N⁄A ). It takes no more than 3 days for a domain to be manually examined after creation.
Please refer to Figure 27-1 in Q27_attachment for the full life cycle of a domain name, covering the periods such as creation, taking effect, expiry and final deletion.
27.2. Registration Life Cycle and Status
There are totally 18 registration statuses defined for EPP in RFCs 5730～5734 and for RGP in RFC 3915, excluding those that can be set by Registrars, such as clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited).
The EPP statuses include OK, inactive, pendingCreate, pendingDelete, pendingRenew, pendingTransfer, -serverHold, serverDeleteProhibited, serverRenewProhibited, serverTransferProhibited, and serverUpdateProhibited.
The RGP statuses defined in RFC 3915 include addPeriod, autoRenewPeriod, renewPeriod, redemptionPeriod, transferPeriod, pendingRestore, and pendingDelete.
27.2.1. Transition of Registration Status
During the whole registration life cycle, the registration status of the domain name evolves as a result of the life cycle period changes and the operations performed. Please refer to Figure 27-2 in Q27_attachmentfor the registration status transition in creation and deletion period of life cycle.
Other operations may affect registration status transition in the life cycle as follows:
a) Update Operation
The Update operation may only be performed on a domain name that is in the Registered period. After the operation, the RGP and EPP status remains unchanged.

b) Renewal Operation
The Renewal operation may be performed on a domain name that is in either the Registered or the Auto-renew period.
When a domain name enters the Registered period, the EPP status is changed to pendingRenew (the previous status is ok) or is added with pendingRenew. After the operation Renewal is done, the EPP status changes back to the previous one. The RGP status changes to renewPeriod; it will change back to its previous status 5 days later.
When a domain name enters the Auto-renew period, the EPP status changes to ok, and the RGP status changes to autoRenewPeriod; it will changes back to ʺN⁄Aʺ 5 days later.
c) Transfer Operation
The operation Transfer may only be performed on a domain name that is in the Registered period and has been registered for more than 60 days. After the operation is performed, the EPP status changes to pendingTransfer; it will change back to its previous status once the transfer is complete. The RGP status changes to transferPeriod; it will changes back to its previous status 5 days later.
d) Restore Operation
The operation Restore may only be performed on a domain name that is in the Redemption Grace Period. Once the Registrar submits a restore request, the RGP status of the domain name changes to pendingRestore; if a formal restoration report is submitted within 7 days, the domain name changes back to its normal registration status (EPP: ok; RGP: N⁄A), otherwise, the registration status of the domain name changes back to the previous one.
27.2.2. Description of Status Transition
For each life cycle period of a domain name, the registration status transition is listed as below:
a) serverHold: all operations on a domain name are forbidden and the domain name canʹt be normally resolved.
In the Registered Period, if the Registry receives any complaint about that domain name, it will set the domain nameʹs EPP status to serverHold. If relevant competent authority confirms that the domain name is being abused or engaged in fraud, the domain nameʹs EPP and RGP statuses will be set to pendingDelete and the domain name will be transitioned to the Pending Delete period. Otherwise, the Registry will restore the domain nameʹs EPP status to ok and reset the RGP status to ʺN⁄Aʺ.
b) serverTransferProhibited: the domain name may be renewed, modified or deleted but not transferred.
When a domain name is in the Registered period, the EPP status for the first 60 days is serverTransferProhibited. If the Registrar renews this domain name, its EPP status remains unchanged and the RGP status is added with renewPeriod which will be cancelled 5 days later. If the Registrar deletes the domain name, both the EPP status and the RGP status change to pendingDelete.
When a domain name is in Autorenew Period, the EPP status is serverTransferProhibited and serverUpdateProhibited, and the RGP status is autoRenewPeriod. After 45 days, if the Registrar doesnʹt make a deletion request, the EPP status changes to ok and the RGP status is cancelled; if the Registrar does make a deletion request within the 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod and will be cancelled 5 days later.
c) serverUpdateProhibied: a domain name may be renewed, transferred or deleted but not updated.
When a domain name is in the Autorenew Period, the EPP status is serverUpdateProhibited and serverTransferProhibited, and the RGP status is autoRenewPeriod. If the Registrar doesnʹt make a deletion request within 45 days, the EPP status changes to ok and the RGP status is cancelled. If the Registrar does make a deletion request within 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod, which will be cancelled after 5 days.
d) serverRenewProhibited: a domain name may be updated, transferred or deleted but not renewed.
e) ok: a domain name may be updated, renewed, transferred and deleted.
If the Registrar makes a transfer request, the EPP status changes to pendingTransfer,; it will change back to ok after the transfer operation is complete. The RGP status is set to transferPeriod that will last for 5 days.
If the Registrar makes a deletion request, the EPP status changes to pendingDelete and the RGP status is set to pendingDelete.
If there is any complaint about the improper use of the domain name, the EPP status changes to serverHold. If the domain name is confirmed to be free from any abuse or fraud, the EPP status changes back to ok; otherwise, both EPP and RGP statuses change to pendingDelete.
f) inactive: within this status, the domain name is not associated with a host and thus canʹt be resolved.
If the Registrar submits a deletion request, the EPP status changes to pendingDelete and the RGP status changes to pendingDelete.
If the Registrar submits an update request to associate the domain name with a host, the EPP status changes to ok.
g) pendingDelete: with this status, the domain name can neither be resolved, nor can it be updated or transferred.
If a domain name is in the Registered period or its EPP status is inactive or serverHold when the deletion operation is being performed, the EPP status changes to pendingDelete. The RGP status is set to pendingDelete. The domain name will be deleted after 5 days.
If a domain name is in the Autorenew Period when the deletion operation is being performed, the EPP status changes to pendingDelete, and the RGP status is set to redemptionPeriod.
h) pendingTransfer: this status indicates that the domain transfer request has been accepted. With this status, no update, renew, or delete operation can be performed on the domain name although the domain name is resolvable in DNS. After the transfer is complete, the EPP status changes back to its previous status. The RGP status is set to transferPeriod, which will be cancelled after 5 days.
i) addPeriod: the RGP status is set to addPeriod for the first 5 days after a domain name enters the Registered period. After 5 days, the RGP status is cancelled. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.
j) renewPeriod: when a domain renewal request is submitted, the RGP status changes to renewPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.
k) transferPeriod: when a domain name transfer request is submitted, the RGP status changes to transferPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, fees resulting from transfer will be refunded.
l) autoRenewPeriod: the RGP status of a domain name when it is in the Autorenew period. If the Registrarʹs account has enough money for renewal after the domain expires, the RGP status changes to autoRenewPeriod and the domain name will be automatically renewed for 1 year. The Autorenew period lasts for 45 days. If the Registrar doesnʹt delete the domain name or does perform the renewal operation after 45 days, the domain name returns to the Registered period and the RGP status is cancelled; otherwise the RGP status changes to redemptionPeriod.
m) redemptionPeriod: the RGP status of a domain when it is in the Redemption period. If the Registrar submits a restore request, the RGP status changes to pendingRestore, otherwise, it changes to pendingDelete after 30 days.
n) pendingRestore: an intermediate status only applicable to domain names in the Redemption period of a domain name. When a domain name is in the Redemption period, if the Registrar submits a restore request to the Registry within 30 days, the RGP status changes to pendingRestore. If the Registrar submits a formal restore request report to the Registry within the subsequent 7 days, the EPP status changes to ok and the RGP status is cancelled; otherwise the RGP status changes back to redemptionPeriod. If the Registrar doesnʹt perform any restore and⁄or renewal operations within 30 days, the RGP status changes to pendingDelete.
o) pendingRenew, pendingUpdate: these two statuses are not applicable. The renewal and update of ʺ.STRINGʺ are performed in real time, so there is no manual review or the third partyʹs verification.
27.3. Compliance with RFCs
Taking the local policies and laws as well as its own businesses needs into account, the Applicant makes some extension for the registration life cycle of the domain name based on RFCs 5730～5734 and RFC 3915.
27.4. Consistency
27.4.1. Commitment to Registrant
The Registry Operator signs agreements with Registrants via the Registrars. These agreements strictly follow the policies of registration life cycle and provide management functions for domain names as directed by ICANNʹs requirements, agreements and regulations.
27.4.2. Technical Plan
For SRS, the EPP status can be used to determine whether a domain name can be updated, renewed, transferred or deleted, etc. The SRS fully supports redemption grace period operations defined in the RFC 3915 using the RGP status;
For DNS, the EPP status of a domain name is needed to determine whether the domain name is deployed in the root DNS zone file. It is also used to decide whether DNS service will be provided to the domain name.
For Whois, the EPP and RGP statuses of a domain name will be shown to the user in the query results.
27.5. Resourcing Plan
Please refer to Table 27-1 in Q27_attachment for the resourcing plan.

28 Abuse Prevention and Mitigation

The Applicant will not tolerate any abuse of the domain names under its management. Described below are the proposed policies and procedures to prevent abusive registrations and minimize other activities that have a negative impact on registrants and Internet users.
28.1 Implementation Plan

28.1.1 Abuse Analysis

With reference to the final Report of the Registration Abuse Policy Working Group (RAPWG), the domain name abuse is an action that:

a) causes actual and substantial harm, or is a material predicate of such harm, and
b) is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.

The RAPWG defines two types of domain name abuses:

Registration abuses are related to the core domain name-related activities performed by registrars and registries. These generally include (but are not limited–to) the allocation of registered names; the maintenance of and access to registration (WHOIS) information; the transfer, deletion, and reallocation of domain names.

Domain name use abuses concern what a registrant does with his or her domain name after the domain is created—the purpose the registrant puts the domain to, and⁄or the services that the registrant operates on it. These abuses are often independent of or do not involve any registration issues.

The Applicant understands that there are differences between registration and use abuses and hence requires different process to minimize these abuses.

28.1.2 Anti-abuse Policies

The Applicant states in its registration policies that it reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on suspension, takedown or similar status, that it deems necessary, in its discretion to prevent and mitigate domain name abuses. The Applicant also reserves the right to place registry suspension, takedown or similar status on a domain name during resolution of a dispute. Abusive uses, as defined above, undertaken with respect to “.STRING” domain names shall give rise to the right of the Applicant to take such actions.

The Applicant will stipulate in the prospective Registry-Registrar Agreement that the Accredited Registrar shall “acknowledge and agree that the Registry reserves the right to immediately deny, cancel, terminate, suspend, lock, or transfer any Reservation Request or Registration Request and any resulting Reservations or Registrations that it deems necessary, in its discretion:

1) to enforce Registry Policies and ICANN Requirements, as amended from time to time;

2) to protect the integrity and stability of the Registry, its operations, and the TLD;

3) to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the Registry or you;

4) to establish, assert, or defend the legal rights of the Registry or a third party, or to avoid any liability, civil or criminal, on the part of the Registry as well as its affiliates, subsidiaries, owners, officers, directors, representatives, employees, contractors, and stockholders;

5) to correct mistakes made by the Registry or any Registrar in connection with a Registration or Reservation; or as otherwise provided herein.”

The prospective Registration Agreement will also require the registrant to “represent, warrant, and agree that the registrant hold the necessary rights t or permit to use any item, word, or term submitted through the DNR Services, and that such use shall not in any way to the best of your knowledge and belief:

(i) violate or potentially violate any right of any third party, including infringement or misappropriation of any copyright, patent, trademark, trade secret, or other proprietary right;
(ii) constitute or potentially constitute violations, such as, without limitation, false advertisement, unfair competition, defamation, invasion of privacy, invasion of rights, and discrimination;
(iii) cause or potentially cause a business dispute, personal dispute, or any other dispute;
(iv) be or potentially be unlawful, harmful, fraudulent, libelous, slanderous, threatening, abusive, harassing, defamatory, vulgar, obscene, profane, hateful, or otherwise offensive;
(v) be or potentially be racially, ethnically, or ethically objectionable; or
(vi) constitute a criminal offense, give rise to civil liability, or otherwise violate any applicable law, including local, provincial, state, national, international, or other laws. ”

With these two contractual instruments, the Applicant will be well positioned to prevent and mitigate domain name abuses.

28.1.3 Point of Contact for Anti-abuse

The anti-abuse policies will be published on the website of the Applicant. The Applicant will establish an abuse point of contact for filing and handling of domain name abuse complaints. The contact information will include at least fixed telephone number, fax number and email address.

The single point of contact will be composed of at least a primary contact person who will be responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller.

The Applicant will form a team to work along with the primary contact person to take steps to investigate and respond to any reports of malicious conduct from law enforcement agencies, governmental and quasi-governmental agencies. Below sections will elaborate on the processes to address the abuses of varying nature. Resourcing plan in the below section will describe in detail the members of the anti-abuse team and their respective roles.

Likewise, all the accredited registrars and resellers of the TLD will be required to set up a contact to liaise with the registry for abuse mitigation. A link to the abuse complaint page of the Registry (the Applicant) will be required to be shown on the website of the registrars.

The Applicant will publish any changes of the contact information on its website, and notify registrars and ICANN in a timely manner.

28.2 Abuse Prevention Mechanisms
Pursuant to the policies adopted in the section above, the Applicant will take necessary actions to prevent and mitigate abuses concerning the .STRING” TLD within the scope of its power.

28.2.1 Reserved lists

In order to ensure the stability and scalability of the domain name system and protect the public interest, pursuant to the Specification 5 of Registry Agreement, certain names will be reserved.

1. ICANN Reserved Names – names reserved based on the Registry Agreement with ICANN; they are:
-The label “example”;
-Two-character labels;
-Tagged domain names;
-Second-Level Reservations for Registry Operations;
-Country and Territory Names.

2. Geographic names (please refer to Q.22 for more information on the geographic names protection mechanism);

3. Government Reserved Names both in English and in Chinese, include but are not limited to the names of the ministries, the names of the national institutions and the names of the national defense;
4. Offensive words or words of hatred, both in English and in Chinese;
5. ICANN related names and IANA related names;

Release of reserved names

Most of the reserved names are prohibited from registration. However, some reserved names may be released to the extent that the registrant demonstrates its legal right on the name and intend to register the name under “.STRING” TLD. In this case,the procedures below will follow.

Release of reserved names for registry operation

Activations of reserved names will generally be provisioned via ICANN Accredited Registrars. The Reserved Names for registry operation will be directly procured from an accredited registrar and locked at the registry.

Release of geographic names

Please refer to the answer to Question 22 for details of the release operation. In summary, the prospective registrant will have to present a supporting letter from the applicable government office to be eligible for registration.

28.2.2 Startup Abuse Prevention Mechanism

Before the launch of the ”.STRING” TLD, the Applicant will mainly focus on Rights Protection Mechanism to safeguard that the pre-registered domain names will not infringe the rights of third parties.

The Applicant will launch a minimum 30 days Sunrise Preregistration Period pursuant to the requirement of the Applicant Guidebook.

After that, a minimum 60 days Landrush Pre-registration Period will be launched to protect the rights of premium domain names.

At the open registration period, the Applicant will also initiate a minimum 60 days Trademark Claims Service to protect trademarks on the startup of the ”.STRING”. For details of the protection mechanism please refer to the answer to Question 29.

28.2.3 WHOIS accuracy Requirement

The Applicant believes that the accuracy and genuineness of WHOIS information are essential to the proper uses of domain names and are vital in tackling the abuses of the domain names. The applicant hence requires the registrants to provide accurate and genuine WHOIS information when registering a domain name, and the Registry and registrars to perform necessary verification to ensure the WHOIS accuracy.

Compliance Requirement for the Registrants

When registering a “.STRING” domain name, the Registrant must consent to the clause on WHOIS requirement in the Registration Agreement, and ensure that the submitted registration information is authentic, accurate and complete. The registrant must also acknowledge that should there be any changes on the WHOIS information in the future, it will update the registration information within 30 days.

The registrants must also agree that they are responsible for the accuracy of the WHOIS information of the domain name. Failure to adhere to the accuracy requirement will cause suspension or termination of the registration.

Compliance Requirement for Registrars

Accreditation of the registrar requires it to be responsible for auditing and verifying the WHOIS information submitted by the “.STRING” domain name registrant.

In the proposed RRA agreement, the Registrar is required to take necessary measures to verify the authenticity, accuracy and completeness of the registrant information upon the domain names registration. First of all, the registrar has to check the completeness of the registration documentation before registration. Incomplete information will result in rejection. Complete registration documentation includes:

1) Complete WHOIS information of the registrant;

2) Verified Email Address of the registrant.

3) A signed copy of the registration agreement.

Additional identification material of the registrant, for example, electronic copy of the ID card or passport for individual or business certification or other legal documentation of the establishment for corporate is required for further verification if necessary.

After registration, pursuant to Registrar Accreditation Agreement, the registrar is required to verify the accuracy and authenticity of the WHOIS information of the domain name during 5 day Add Grace Period. The process for the WHOIS verification will be as follows:

1. The Registrar will send out emails to the administrative contact requesting for confirmation of the contact information;

2. The administrative contact will reply per the instructions to confirm within the five day Add Grace Period;

3. The registrar will suspend the domain name should there be no confirmation, and a notice of WHOIS update will be sent to the technical and billing contact in the WHOIS. It is expected that the WHOIS information will be updated within 5 days upon receipt of the notice;

4. Once the update is made, the domain name will be active again. If there is no update within five days, the domain name registration will be cancelled with no refund.

Compliance Requirement for the Registry Service Provider

The Applicant requires the Registry Service Provider to carry out random inspections on WHOIS information of the domain name registered on the SRS on a daily basis. KSRP is designed to send out email each email address of the registered domain name to ask for verification. The verification process is similar to that of the registrars. Any inaccurate WHOIS information will be reported to the Applicant.

The Applicant will request the registrar concerned to update the registrant information within 10 working days. Failure to do so may result in domain name suspension or takedown if the Applicant is unable to contact registrant.

Compliance Requirement by the Applicant

The Applicant will set up an annual evaluation process for the Registrars on their performance on the WHOIS verification. The Evaluation is based on the complaints received and results of the WHOIS inspection performed by the Registry Provider based on the RRA.

An accuracy ratio of 90% of the WHOIS is qualified and higher accuracy will be awarded and honored. The accuracy ratio lowers than 90% will lead to warning or financial penalty pursuant to RRA. Lower than 80% is deemed a breach of RRA .

With the WHOIS Verification Mechanism, a considerable portion of the domain name abuses could be effectively prevented in the registration stage.

28.2.4 Access Control

The Applicant will place a tiered access control mechanism for the registrant to prevent and mitigate potential domain name abuses.

The Applicant will require accredited registrars to set up an online platform for registrants to manage its portfolios of the domain names. The management functions include WHOIS data update and transfer, renewal or deletion of domain names. This platform will provide SSL-based services. Strong passwords of the registrants are mandatory to access the platform. And the password will be requested to change every three months. Each access to the platform will require CAPTCHA verification. In addition to that, each operation of the domain name, such as update of registrant information, setting of the NS record will require verification before activation.

In the event of domain name transfer, the Auth-code which is used to verify the domain name transfer between registrars will be sent to the email address of the administrative contact of the registrant by the losing registrar. Meanwhile, the losing registrar is required to send transfer notice to the administrative contact, technical contact and billing contact of the registrant before initiating transfer operation. Likewise, the gaining registrar is also required to notify the administrative contact, technical contact and billing contact of the registrant after the transfer operation.

In the event of the domain name deletion, the registrant will be required to verify the operation either via emails or via written notices. Meanwhile, the administrative contact, technical contact and billing contact of the registrant will all be informed of the operation.

28.2.5 Policy on Orphan Glue Records

By definition of SSAC, a glue record becomes an ʺorphanʺ when the delegation point NS record referencing it is removed without also removing the corresponding glue record. The Applicant will adopt the management policy of disallowing orphan records.

KSRP automatically marks the orphan glue records generated and the date of generation when suspending the resolution of a domain name or deleting a domain name. At the time that an orphan glue record is generated, the system will automatically send an email notice to the administrative contacts, technical contacts of the domain name and its sponsoring Registrars, informing that the orphan glue record should be deleted within a 30-day grace period.

Moreover, the registry system will carry out scanning and cleansing program on orphan glue records on a daily basis. The orphan glue records that are no longer used as well as those that exceed the 30-day grace period will be deleted.

When provided with evidence that the glue is indeed present to abet malicious conduct, the Applicant will take the following action:

Upon receipt of the complaint, the Applicant will give an immediate deletion order to the Back-End Service Provider to remove the orphan glue record in question;

The Back-End Service Provider will delete the record within 8 hours upon receipt of the order and feedback to the Applicant;

The Applicant shall inform the complainants on the results within 8 hours.

28.3 Abuse Mitigation Mechanism
The Applicant will set up anti-abuse mechanisms to act swiftly to mitigate any abuse and take down any infringing “.STRING” domain names. Based on the nature of the abuses mentioned above, the Applicant shall act in three levels to defend against potential registration abuses and domain use abuses:

28.3.1 Registration abuse mitigation mechanism

The Applicant will adopt such rules in the Registration Agreement to prevent infringement on the right of third parties or violation on applicable laws and regulations. The Registry-Registrar Agreement (RRA) also states that the Registrar is responsible for the WHOIS accuracy of the domain names. Any inaccurate WHOIS information could lead to domain name cancellation or rejection.

Upon receipt of complaints on domain registration abuses, the Applicant will follow the procedures described below:

The Applicant will first put the domain name in question on registry lock, then

The Applicant will determine the nature of the complaints, if it fits the description of registration abuses, the Applicant will take down the domain name pursuant to the RRA or the Registration Agreement immediately; a notice of breach will also be sent to the registrant and the sponsoring registrar.

Should the abuse be use related, the Applicant will follow the procedure that is described in the following section.

28.3.2 Use abuse mitigation mechanism

With regard to abusive uses of “.STRING” domain names, including phishing, pharming, malware downloading, etc., the Applicant will rely on the registrars, the interested parties or the Internet users to detect the abuse. It will tackle such abusive uses in collaboration with other third party security vendors or Law Enforcement Agencies.

A typical process to tackle the abusive uses is as such:

1) Any complaints to the domain names shall be sent to the abovementioned contact via telephone, fax or email;

2) Upon receipt of the complaints, the Applicant will put the domain name in question at “Registry lock” status and will identify the abuse incidents involving the domain names; If the abuse is filed by Law Enforcement Agencies (LEAs) and CERT⁄CC and the abuse is deemed that its existence will lead to further losses of Internet users, such as phishing and pharming, the Applicant will suspend the domain name in the SRS system and the EPP status will be changed into “serverHold”, so that the domain name will not be able to resolve or be transferred.

3) Once the abuse is identified with the help of third party security vendors or Law Enforcement Agencies (LEAs) if necessary, a notice of breach will be sent to the domain name registrant, registrar and any party concerned to request for immediate actions;

4) Should the Applicant receive no response from the registrant or the registrar within four hours, pursuant to the RRA, the Applicant will suspend or take down the domain name depending on the nature of the abuse; the Applicant shall also notify the administrative and technical contacts of the registrant and the sponsoring registrar;

5) After the abuses involved the domain name are cleansed and the evidences are presented to the Applicant, the domain name will be reactivated within 4 hours. A notice of reinstatement will also be sent to the administrative and technical contacts of the registrant and the sponsoring registrar.

Take down Procedure
Upon receipt of the takedown notice from the LEAs, CERT⁄CC , the Applicant will check whether the domain name meets the criteria for taking down action;

If so, the Applicant will instruct the sponsoring registrar to take down the domain name and send email notification to the registrant (administrative contact, technical contact or billing contact);

Should the registrant think the Applicant domain name is suspended by mistake, registrant can appeal to the Applicant with evidence.

28.3.3 Domain names dispute resolution mechanism

Pursuant to the Specification 7 of the Registry Agreement, the Applicant will comply with the following domain names disputes resolution mechanisms that may be revised from time to time:

a. the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP) and the Registry Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN.; and

b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN, including the implementation of determinations issued by URS examiners.

c. the Uniform Domain Name Dispute Resolution Policy adopted by ICANN as Consensus Policies.

The Trademark PDDRP and RRDRP

In the Registry Agreement, the Applicant agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Registry Agreement) following a determination by any PDDRP or RRDRP panel and to be bound by any such determination.

Details of the resolution mechanisms, please refer to the Trademark PDDRP and RRDRP, which is listed in the Applicant Guidebook.

The URS Procedure
The URS does not concern the Applicant as the gTLD Registry Operator. However, in the event of the Uniform Rapid Suspension dispute, the Applicant will fulfill the obligations as follows:

The Applicant will “lock” the domain name in question within 24 hours upon receipt of the “Notice of Complaint”, restricting all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to be resolved.

After the “lock” operation, the Applicant will notify the URS Provider immediately (Notice of Lock).

Immediately upon receipt of the Determination order from the URS Provider, the Applicant shall suspend the domain name, which shall remain suspended for the rest of the registration period and would not resolve to the original web site. The name servers will also be redirected to an informational web page provided by the URS Provider about the URS. The Whois for the domain name shall continue to display all of the information of the original Registrant except for the redirection of the name servers. In addition, it shall be reflected on the Whois that the domain name will not be able to be transferred, deleted or modified for the life of the registration.

The successful Complainant may also be allowed by the Applicant to extend the registration period for one additional year at commercial rates.

Uniform Dispute Resolution Procedure

The UDRP requires all registrars to follow the Uniform Domain-Name Dispute-Resolution Policy (UDRP). Under the policy, most types of trademark-based domain-name disputes must be resolved by agreement, court action, or arbitration before a registrar cancels, suspends, or transfers a domain name. Disputes alleged to arise from abusive registrations of domain names (for example, cybersquatting) may be addressed by expedited administrative proceedings initiated by the owner of the trademark by filing a complaint with an approved dispute-resolution service provider.

To invoke the policy, a trademark owner should either:

(a) File a complaint in a court of proper jurisdiction against the domain-name holder (or where appropriate an in rem action concerning the domain name) or

(b) In cases of abusive registration, submit a complaint to an approved dispute-resolution service provider.

Details of the UDRP are available for review at http:⁄⁄www.icann.org⁄dndr⁄udrp⁄policy.htm. The Applicant recommends that Complaints under the UDRP be submitted to Asian Domain Name Dispute Resolution Center or any desired dispute-resolution service provider by the complaints. The listed providers can be visited at http:⁄⁄www.icann.org⁄dndr⁄udrp⁄approved-providers.htm.

The Applicant as the Registry Operator will also monitor the compliance of the registrars on the implementation of UDRP decisions.

28.3.4 Anti-abuse Collaboration with Partners
Externally, the Applicant will work with other parties to prevent and mitigate abuses on its domain names. The procedures or mechanisms of the cooperation will be described as follows:

With ICANN

With contractual relationship with ICANN, the Applicant must fulfill the legal obligations described on the Registry Agreement. The Applicant also consent to the Consensus policies and temporary policies specification described in the Specification 1 of the Registry Agreement. Details of the consensus policies can be found at: http:⁄⁄www.icann.org⁄en⁄general⁄consensus-policies.htm.

With regard to Temporary Policies, the Applicant shall comply with and implement all specifications or policies established by the ICANN Board on a temporary basis. The Applicant pledges that the Temporary Policies will be implemented within a month upon the notice of the policies. In the event of a conflict between Registry Services and Consensus Policies or any Temporary Policies, the Consensus Polices or Temporary Policy shall control.

With LEAs and other security providers

On one hand, the Applicant will establish a contact window with CERT⁄CC, LEAs and other security providers to take down domain name abuse incidents concerning “.STRING” domain names. On the other hand, the Applicant will rely on them to identify domain name abuse incidents. The collaboration mechanism is as follows:

1) Upon receipt of the takedown notice from the LEAs, CERT⁄CC , the Applicant will check whether the domain name meets the criteria for taking down action;

2) If so, the Applicant will instruct the sponsoring registrar to take down the domain name and send email notification to the registrant (administrative contact, technical contact or billing contact);

3) Should the registrant think the domain name is suspended mistakenly, it can appeal to the Applicant with evidence;

The Applicant will direct the evidence to the LEAs or CERT⁄CC for review. If the evidence is approved valid, the Applicant will restore the domain name within 8 hours, a notice of restoration will be sent to the administrative and technical contacts of the registrant and the sponsoring registrar.
28.4 Resourcing Plan
28.4.1 Human resource plan
Based on the estimated registration volume of “.STRING” TLD, two staffs will be furnished to carry out the duty. One will be tasked to be the anti-abuse contact of the Registry to handle complaints. The other will be in charge of the compliance of the registrars and WHOIS verification matters. A legal counsel will be tasked to take care of the anti-abuse activities and to determine the actions on domain name abuses.

Aside from that, registrar supporting executive and technical staff will also help with the execution of the anti-abuse activities.

On the Back-End Service Provider side, a team will be allocated to take swift and effective action to respond to the actions to address the abuses.

Review and Monitoring Staff
The Back-End Service Provider currently has 20 members to review the Whois accuracy. As all required staff members are expected to be on duty starting from the start-up period, additional recruitment must meet the needs of the peak registration season.

Emergency response team
The team will operate in accordance to the orders by the Registry Operator on a 24*7 basis. Currently, the Back-End service provider has employed 10 employees to fulfill the duty. In addition to that, a coordination specialist will be tasked to cooperate with third parties.

28.4.2 Funding plan
Details of the funding plan for the anti-abuse mechanisms please refer to the answer to question 47.

29. Rights Protection Mechanisms:

As described on Specification 7 of the Registry Agreement, “Registry Operator shall implement and adhere to any rights protection mechanisms (“RPMs”) that may be mandated from time to time by ICANN”.

Bearing this in mind, the Applicant will implement a proper Right Protection Mechanism (RPM) to safeguard trademark, geographic names and other naming rights based on the RPMs mandated by the Registry Agreement. At the startup stage, the Applicant will implement the Sunrise Period and Trademark Claims Service to honor the right of trademark owners. When the open registration begins, the Applicant will implement the reserved name policy to prohibit the registration of certain names. Likewise, in line with RAA, the Applicant would like its accredited registrars to perform registration verification to ensure the accuracy of the WHOIS information. This serves as an effective deterrence to potential abusive registrants, and the naming right of others can be properly protected. In the event of rights dispute, the Applicant will implement Uniform Rapid Suspension mechanism and instruct all domain name holders to observe Uniform Dispute Resolution Policy in settling their domain name dispute. The Applicant believes that along with the anti-abuse mechanisms described in the answer to Question 28, the RPM shall effectively protect the legal right holders and mitigate potential infringement.
29.1 Start-up rights protection measures
As required in the Applicant Guidebook, the Applicant will implement three start-up right protection mechanisms: the Sunrise Period, Landrush Period and Trademark Claims service.

Sunrise Service:

The Sunrise Service will be implemented as required by the Applicant Guidebook. The Applicant will implement a 30-day Sunrise service period for eligible trademark holders to register or reserve its names at the second-level of the “.STRING” TLD at the pre-launch period.

Before the Sunrise period, the Applicant will carry out a communication plan to promote the Sunrise Service. The Applicant will put up the Sunrise policies on its website.

Any registration request at the Sunrise Period will be screened by the Applicant to meet the Sunrise Eligibility requirements (SERs). The SERs requires the prospective registrant to demonstrate the following when registering a trademark name at the Sunrise Period:
(i) ownership of a mark;
(ii) representation that all provided information is true and correct; and
(iii) provision of data sufficient to document rights in the trademark.

Such materials submitted to the Applicant will be verified in the Trademark Clearinghouse. The Applicant will also send notice to holders of marks in the Clearinghouse that are Identical Matches to the name to be registered during Sunrise.

Should dispute arise in this period, the Applicant will implement a Sunrise Dispute Resolution Policy (SDRP). The policy allows challenges based on at least the following four grounds:

(i) At the time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty;

(ii) The domain name is not identical to the mark on which the registrant based its Sunrise registration;

(iii) The trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or

(iv) The trademark registration on which the domain name registrant based its Sunrise registration has not been issued on or before the effective date of the Registry Agreement and has not been applied for on or before ICANN acknowledged the receipt of the applications.

The Applicant will resort to its dispute resolution provider to settle the dispute. If the prospective registrant wins, the registrant will continue its Sunrise registration. If the prospective registrant loses, the Sunrise registration will be canceled.

If multiple applications for the same domain pass the verification, all successfully verified applicants will be invited to bid for that domain in an auction. Notification of the auction along with information about competing bidders will be made available to all bidders before the auction commences.

Landrush Service:

The Applicant intends to launch a sixty-day Landrush service shortly after the Sunrise Period.

Landrush service is the first opportunity for the public to register a “.STRING” domain. If a domain name is requested by more than one party, the domain will be subject to an auction in which all interested parties will be able to bid on the domain. If there is only one requester, the domain name will be registered to the requester at the end of the Landrush period.

English auctions will be adopted, which means that the highest bidder will receive the domain name.

There are two types of bidding:

1) Manual Bidding
In manual bidding, bidders need to closely follow the auction. Bidders will be notified of new higher bids and given 24 hours to submit a new bid.

2) Automated Bidding (Proxied Bidding)
The bidder can alternatively choose automated bidding. The system will automatically place a bid for the bidder with the set increment amount. The system will stop to place new bids if a bid ceiling set by the bidder is reached.

Multiple applicants for the same domain name at the Sunrise Period have equal opportunities to bid for preferred name.

Trademark Claims Service:

The Applicant will commit itself to offering the Trademark Claims Service at the initial open registration phase for 60 days pursuant to the requirement of the Applicant Guidebook.

The Applicant requires its accredited registrars to check every domain name registration against the Trademark Clearinghouse (through an interface with the Clearinghouse) during the Trademark Claims Service period.

If the domain name matches a name registered in the Clearinghouse, the registrar is required to send a Trademark Claims Notice (as described in the attachment to the Trademark Clearinghouse in the Applicant Guidebook) to the prospective registrant.

The Trademark Claims Notice to the prospective registrant warrants that: 1) the prospective registrant has received the notification that the mark(s) is included in the Clearinghouse; 2) the prospective registrant has received and understood the notice; and 3) to the best of the prospective registrant’s knowledge, the registration and use of the requested domain name will not infringe on the rights that are the subject of the notice.

The Trademark Claims Notice will provide the prospective registrant access to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance understanding of the Trademark rights being claimed by the trademark holder. These links (or other sources) shall be provided in real time without cost to the prospective registrant.

After receiving the signed copy of the Trademark Claims Notice, the registrar will process the registration request. By the time the domain name is registered, the registrar (again through an interface with the Clearinghouse) will promptly notify the mark holders(s) of the registration after it is effectuated.

29.2 Post-launch right protection measures
Pursuant to the Specification 7 of the Registry Agreement, the Applicant will comply with the following right protection mechanisms that may be revised from time to time:

a. the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP) and the Registry Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN.; and

b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN, including the implementation of determinations issued by URS examiners.

c. the Uniform Domain Name Dispute Resolution Policy adopted by ICANN as Consensus Policies.

The Trademark PDDRP and RRDRP

In the event of the Trademark PDDRP and RRDRP, the Applicant as a gTLD Registry Operator will be acting as the respondent to complaints filed against itself.

In case of a complaint filed by a third-party claiming that its trademarks (registered or unregistered) have been infringed by the Applicant’s operations on the gTLD, the administrative proceeding will commence. If the Threshold Review Panel determines that the Complainant has standing and satisfied the criteria then the Provider will continue the proceeding on the merits.

The Applicant will file a Response to each Complaint within forty-five (45) days after the date of the Threshold Review Panel Declaration.

The Response will be filed with the Provider and the Provider must serve it upon the Complainant in electronic form with a hard-copy notice that it has been served.

If the Dispute Resolution Provider determines that the Applicant is liable under this Trademark PDDRP, the Dispute Resolution Provider may recommend a variety of graduated enforcement tools. ICANN shall have the authority to impose remedies at its discretion.

The Applicant will follow similar procedures to respond to the Provider of RRDRP and observe its determination.

After the “lock” operation, the Applicant will notify the URS Provider immediately.(Notice of Lock).

Immediately upon receipt of the Determination order from the URS Provider, the Applicant shall suspend the domain name, which shall remain suspended for the rest of the registration period and would not resolve to the original web site. The name servers will also be redirected to an informational web page provided by the URS Provider about the URS. The Whois for the domain name shall continue to display all of the information of the original Registrant except for the redirection of the name servers. In addition, the Whois shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.

The successful Complainant may also be allowed by the Applicant to extend the registration period for one additional year at commercial rates.

Uniform Dispute Resolution Procedure

To invoke the policy, a trademark owner should either:

(a) File a complaint in a court of proper jurisdiction against the domain-name holder (or where appropriate an in rem action concerning the domain name) or

(b) In cases of abusive registration submit a complaint to an approved dispute-resolution service provider.

The Applicant as the Registry Operator will also monitor the compliance of the registrars on the implementation of UDRP decisions.

29.5 Resourcing Plan

Given its close connection with the anti-abuse mechanisms, the Applicant would like to extend the resourcing plan placed in the answer to Question 28 will also be employed in the RPMs.

In summary, the Applicant will employ two staffs to handle complaints. A legal counsel will be tasked to take care of the anti-abuse activities and to determine the actions on domain name abuses.

The Back-End service provider will have a 20-staff Review and monitor team to audit the Whois accuracy; a 10-staff Emergency response team will be allocated to take swift and effective action to address the abuses. Details of the technical resourcing plan can be seen at answer to Question 42.

In terms of funding, please refer to the answer to question 47 for more details.

30A. Security Policy
According to ICANNʹs New gTLD Applicant Guidebook, the Applicant has selected KSRP as the back-end service platform. To ensure security, KSRP is implemented in accordance with the internationally accepted ISO 27000, with full consideration of the security aspects of services and data as required by ICANN.
30A.1. Description of Information Security Policies
KSRP is built to achieve the following goals in accordance with ISO 27000:
a) Ensure that the information system supporting critical businesses is free from any outage resulted from failure, virus or attacks. The service level meets the committed SLA;
b) Safely and effectively protect the user information so that it will not be leaked, missing, falsified and unavailable;
c) Be able to rapidly, effectively and properly recover the system platform from any disaster.
To meet these goals, the Back-End Service Provider has implemented the information security management policies in accordance with ISO 27000 in the following 12 aspects:
a) Assets security management
b) Human resources security
c) Physical and environmental security
d) Operation regulations
e) Storage media management
f) Backup of data and services
g) Network infrastructure security
h) Network security events monitoring
i) Access control
j) Application services security
k) Information security events management
l) Management of business continuity
The ISO 27000 series that are followed by KSRP include:
a) ISO 27001: Information Security Management System
b) ISO 27002: Code of Practice for Information Security Management
c) ISO 27004: Information Security Management Measurement
d) ISO 27035: Information Security Incident Management Classification
30A.2. Overview of Information Security System Framework
KSRP is designed and built in the following information security measures to mitigate security risks caused by mistakes occurred in day to day work.
30A.2.1. Assets Management
KSRP recognizes and classifies the assets of the data centers and DNS nodes as follows:
a) Data: databases and database manuals;
b) Services: telecommunication services as well as other public utilities and their contracts;
c) Hardware resources: network equipment, host brand, model, configuration parameters and operating manuals or instructions;
d) Software resources: SRS server software, DNS software, Whois software, Registrar business support system, Registry business support system, mail server software, applicable website software and respective installation manuals and configuration files.
In order to effectively protect information resources above, The Back-End Service Provider classifies the platform assets by both importance and sensitivity. Please refer to Table 30A-1 in Q30_attachment.

30A.2.2. Human Resources Management
a) Establish definite posts with clearly defined duties to ensure people can really understand the nature of that post he⁄she applies for;
b) For crucial posts (posts above the director level, DBA and security specialist), The Back-End Service Provider will carefully evaluate the applicantsʹ background to ensure that they are qualified for such posts. The background information under evaluation may include a) personal profile; b) resume; c) academic level and professional qualifications; d) identity; e) other details;
c) The New Employee On-board Procedures clearly stipulate that the new employee sign a confidentiality agreement with the company shall his⁄her post require;
d) The Human Resources Department will regularly conduct training sessions for new employees to ensure all staff members are full aware of the serious consequences of information security threats;
e) The security commissioner regularly performs inspections on employeesʹ work to ensure that they perform their jobs in a way conforming to the security policies;
f) The Employee Exit Procedures shall stipulate that work handover be done well before an employee leaves the company. The Human Resources Department shall not handle the exit procedures until the employeeʹs manager confirms that his⁄her authority to access the internal systems has been revoked.
30A.2.3. Physical Environment Security
a) KSRP has established two enclosed and controlled physical work environment: one is a peripheral work environment called the Office Zone; the other is an internal environment called the Monitoring Center.
b) The company staff enters the the Office Zone with an access card. Non-company personnel are not allowed to enter the zone without permission.
c) Any visiting guest must always be escorted by a staff member.
d) The Monitoring Center is protected by stricter security measures. Only staff members received a higher security clearance are allowed to enter.
e) In order to ensure the secure operation of the system and identify any failings in regular work, we have applied video monitoring to the office zone and so we can provide the subsequent security auditing work with some evidence.
f) KSRP employs identity card and fingerprint authentication for access control. It combines physical security access with other security protection measures to build a secure working environment.
g) To ensure timely response to emergency, KSRP has deployed dual-backup support for communication services and utility facilities in the data center, including Internet access lines, telephone lines, electricity, power supplies, and air conditioning.
30A.2.4. Operation Regulations
KSRP has established strict procedures for managing changes to the online services which include Software Testing Procedures, Services Deployment Procedures, and Services Change⁄Upgrade Procedures. The following provisions are stipulated:
a) Before changes are made to the online services, the new software shall be strictly tested and pass the security validation scanning performed by the security specialist;
b) Operation personnel shall obtain the approved change request before deploying the changes in production;
c) Operation personnel shall back up software and data in production before rolling out changes to ensure that they can roll back the changes in case of deployment failures;
d) Operation personnel shall strictly follow the instructions stated in Service Deployment Practice Manual when rolling out changes to services in production;
e) After changes are made to the services in production, Operations personnel shall submit the services installation and maintenance documents to the O&M Department.
f) After changes are made to the services in production, the system administrator will perform an all-round monitoring on them.
30A.2.5. Storage Media Management
Except for system administrators, other staff members are not allowed to copy data between the production environment and the external media. Only the system administrators are authorized to perform data upload⁄download operations and all these actions are logged by KSRP for auditing.
The system administrator backs up a variety of data and application services logs from production to tapes as required every day. KSRP designates special personnel to keep these tapes in a safe place and rotate them for reuse once the data retention periods expire.
30A.2.6. Backup of Data and Services
KSRP backs up data and services with two objectives:
a) The services can be recovered as soon as possible in case of any disaster⁄failure;
b) The business can be audited at any time if needed;
To achieve these two goals, KSRP backs up the following assets:
a) Data in the databases;
b) Software resources (including binary code and relevant source code, configuration files and design documents) and operation log;
c) The standard operating system and third-party services software;
d) All equipment, models, specifications and other documents to the installation, operations and maintenance of the service environment.
Assets backup shall be done by the person in charge, and inspected by the security specialist on a periodic basis. Any identified issues shall be fixed as required.
The backup and inspection patterns vary by the natures of the assets. Different equipment, models, specifications as well as the installation and maintenance manuals, services and relevant documents shall be backed up and inspected when they are created and⁄or altered; the software resources and operation logs shall be backed up daily and inspected on a periodic basis; the data in the databases shall be backed up and inspected daily.
There are three daily data backup copies for KSRP data, one stored in the primary data center, one stored in the backup data center, and one copy stored on a tape as offline backup. This ensures that the system services can be recovered properly in case any man-made⁄natural accident occurs.
30A.2.7. Security of Network Environment
The KSRP network infrastructure is divided into two zones by firewalls: internal protection zone and the DMZ. The database platform is placed in the internal protection zone protected by a database firewall in front of all the front ends; the operating network environment is placed in the DMZ for providing services to the outside.
As the services provided by KSRP are Internet-based, the whole network infrastructure is very important for the platform. In order to maintain a robust and secure network environment, dedicated network professionals are assigned as the principal for all the network equipment assets to ensure the whole network is secure, smooth and fault-tolerant.
The duties of the network professionals include:
a) Design the network topology;
b) Ensure all network equipment are working normally;
c) Ensure these equipment are reachable to each other over the network;
d) Maintain passwords for all network equipment to keep unauthorized people from accessing these equipment;
e) Keep the network equipment highly available; timely back up all network routing policies and firewall control policies in order to ensure timely recovery from any failure;
f) Audit network security events to timely identify any potential threats.
30A.2.8. Network Security Events Monitoring
In addition to assisting the network professionals to maintain a secure, smooth and robust network environment, system administrators have another important role of monitoring various events occurred over the network.
KSRP is equipped with management functions to perform comprehensive monitoring over network equipment, servers and applications. A system administrator carries out the following daily tasks to manage network and services events with the monitoring platform:
a) The system administrator inspects various network and services events from the network management equipment, IDS equipment and the monitoring platform;
b) The system administrator follows the Services and Maintenance Manual to handle any identified network events;
c) The system administrator follows the Events Response Procedures for any identified events that require communications.
30A.2.9. Access Control
In order to ensure only authorized users are allowed to access the services provided in the operating environment, the Back-End Service Provider has enforced the following operation rules as part of the assets management requirements:
30A.2.9.1. Passwords Management
a) The identity authentication is based on user name⁄password; the password must be strong;
b) If the user tries to login with a wrong password 3 times in a row, the account is locked for at least one hour in order to prevent any malicious login attempts.
30A.2.9.2. Identity Authentication and Authorization:
a) Before accessing any system serving specific users, the user shall pass the identity authentication;
b) The user authority shall only be assigned by the system administrator.
30A.2.9.3. Routing Policies:
a) KSRP blocks remote access to the network via Internet for management purposes ;
b) For any privileged user logging on to any application system, the source IP address of the userʹs machine shall be qualified;
c) Any session that stays idle for over 30 minutes shall be disconnected;
d) For services only open to specific IP addresses, routing qualifications shall be provisioned for such IP addresses on the firewall.
30A.2.9.4. Host Restrictions:
1. Logging on to the operating system of a host shall be done via SSH;
2. Any operations done on the host after login shall be logged for auditing purpose.
3. The ROOT account of the host can only be accessed by the administrator; the ROOT account shall not be used unless it is absolutely necessary.
4. The host password shall be changed regularly.
30A.2.9.5. Firewall Protection:
a) All application services (except for DNS services) shall be placed behind the firewall for security purpose;
b) Only the ports used by these application services shall be open via the router and firewall; all other ports shall be closed.
c) The maximum number of connections shall be capped for all application services to mitigate risks of large-scale malicious attacks.
30A.2.9.6. Data Encryption:
a) Any confidential business data shall be transferred via HTTPS;
b) Any data files shall be transferred via VPN.
30A.2.9.7. Security Auditing:
a) The user list and user access authority shall be reviewed on a regular basis to ensure the authority is up-to-date and invalid accounts are timely removed;
b) The network access log of the user shall be audited by the security specialist on a regular basis.
30A.2.10. Security of Application Services
KSRP ensures security of the application services in two aspects: 1) security of the operating system; 2) security of the application programs.
Security of the operating system is guaranteed by the following measures:
a) Uniformly install the operating system and security-related patches;
b) Turn on the firewall and only open the ports required by the application services;
c) Regularly check the operating system users and system files to ensure the important system files are not compromised.
Security of the application programs is guaranteed by the following measures:
a) For the application services provided to specific users, those users shall pass the identity authentication (certificate authentication or password authentication). If password is used, the password strength shall comply with the security policies;
b) If a specific user performs any operation on data via the application system, the system shall check the userʹs identity and rejects the operation if it is unauthorized. A detailed log shall be created for any authorized change for auditing;
c) The Measures of Administration of Source Code Security prohibits anyone from disclosing the source code to any third party;
d) Before any application services being put online, the security specialist shall perform a security scan on the software to identify any potential security threats;
e) The system administrator shall use the configuration administration tools to ensure the version of the service software in the operating environment complies with that of the software provided by the R&D Department;
f) The Security Management Procedures of Application Service requires that the security specialist track any defects of the third-party software disclosed by the company and timely upgrade the software;
g) The security specialist shall carry out reinforcement on the firewall and operating system in order to reduce the risks caused by any malicious intrusion to the application services.
30A.2.11. Information Security Events Management
On KSRP，information security events are managed by the information security professionals who are in charge of collection and analysis of all information security events as well as formulation and implementation of the remedial solutions.
The information security specialist collects security events through two channels: the network monitoring log of the system, and authoritative websites disclosing security vulnerabilities.
The information security specialist works out a platform improvement plan after collecting and analyzing applicable security events. The plan will be submitted to the corporate management for approval before execution.
30A.2.12. Security Management of Business Continuity
Information systems of KSRP are classified by their importance as below:
a) Critical information systems: DNS services;
b) Important information systems: SRS services, Whois query, Registrar business support platform, Registry business support platform;
c) General information systems: websites, mail system, etc.
One of the following two cases constitutes an outage of an information system: 1) the system fails to provide services to the public; 2) the services level fails to meet the SLA. If the outage lasts for a while, it is considered as an event. The longer the event lasts, the bigger the loss is.
In addition, if user data of KSRP is leaked, missing or falsified, these occurrences are also considered as events. The bigger the ratio of affected data, the greater the loss caused by the event.
For the classification of events occurred on KSRP, please refer toTable 30A-2 in Q30_attachment:
In order to address the above-mentioned circumstances, KSRP has designed a series of services backup & restore procedures to ensure service continuity.
30A.3. Security Commitment to Registrants
KSRP provides the following security commitments to Registrants:
a) The availability of the DNS services is 100% monthly;
b) The availability of the SRS services is 99.9% monthly;
c) The availability of the Whois services is 99.9% monthly;
d) Service outage to the primary data center caused by disasters such as earthquake and flood, shall not last for more than 1 hour with almost no data loss.
e) Any data related to the Registrants will not be leaked.

Song Yanchun	CFO
Xu Yiyun	CEO
Xu Yizheng	Chairman
Zhang Hong	CTO

Song Yanchun	CFO
Xu Yiyun	CEO
Xu Yizheng	Chairman
Zhang Hong	CTO

New gTLD Application Submitted to ICANN by: Jiangsu Bangning Science & Technology Co.,Ltd.

String: top

Originally Posted: 13 June 2012

Application ID: 1-1935-70970

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.