Application number: 1-889-24496 for BEIJING JINGDONG 360 DU E-COMMERCE LTD

BEIJING JINGDONG 360 DU E-COMMERCE LTD

16F，Tower A,North Star Century Center,8，Beichen West Road, Chaoyang District，Beijing，PRC
beijing 100101
CN

+861058959009

+861057656837

http:⁄⁄www.360buy.com

Ms. xiaoli zhai

Technical Engineer

+861058959009

+861057656837

jdtldreg@gmail.com

Ms. yan zhang

Intellectual Property Specialist

+861059317545

+861058955990

fwzhangyan@360buy.com

Corporation

P.R,China

Not Available

Liu Qiangdong
Chairman of the Board
Sun Jiaming
Member of the Board

Liu Qiangdong
CEO
Sun Jiaming
Vice President

Liu Qiangdong
CEO

shop

Not Available

The applied-for gTLD string in this application is in ASCII format. It fully complies with the technical requirements specified in section 2.2.1.3.2 of ICANNʹs gTLD Application Guidebook. The ASCII label of this string consists entirely of letters (alphabetic characters a-z). It adopts the same character set as TLDs such as .net, .com, etc. And it can work well with many existing operating systems such as windows, linux, and is supported by common Internet Browsers, such as Firefox, Internet Explorer, Safari, Netscape. After being tested by the test system, there is no operational or rendering problem concerning the applied-for gTLD string.

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

Mission Statement: To create a more unique, recognizable, trustworthy and stable e-commerce domain namespace for Internet users, meanwhile providing registrars and registrants an opportunity to expand their existing business or to explore new business models.
Business Model: .shop TLD is mainly targeting all existing e-commerce businesses, as well as trustworthy retail suppliers and service providers, who are intended to expand their businesses on the web.
E-commerce is the most advanced mean of utilizing modern information technology and network capacity to carry out business activities. The power of Web enablement is that geographical boundaries disappear for an enterprise. Thus, an E-commerce initiative can easily become a global E-commerce initiative. It becomes extremely critical for modern business enterprises to acquire continuous supply capacity, create growing consumer demands and strengthen market competitiveness so as to gain a foothold in globalized business environment. Thus, to survive in the 21st century, an enterprise should integrate its conventional business approaches with advanced e-commerce model to keep up with the global trends of development.
As far as the global e-commerce market is concerned, JPMorgan Chase & Co. expects e-commerce revenue will grow to USD 680 billion worldwide by the end of 2011, up 18.9 percent compared to 2010. The same source predicts that the global e-commerce market is likely to grow at a 19.4% compound average growth rate between 2010 and 2013, with e-commerce revenue hitting USD 963 billion by 2013. Moreover, In the United States, the population of online shopper has been increasing continuously; about 38% of them shop online at least once a month. The proportion of those who never shop online dropped from 20% in 2007 to 12% in 2010. Meanwhile, China, already home to the world’s largest online population, is currently the second biggest e-commerce market in the world and has ushered in its explosive growth period. According to Boston Consulting Group, the amount of online shoppers in China has already reached 145 million in 2011, with exponential growth expected that could bring the number to 329 million by 2015 and make the e-commerce market in China the worldʹs most valuable.
It all starts with a smart choice of domain name which can represents the e-merchants’ unique online identity. In addition to embodying its brand value, an excellent domain name itself is a hot commodity with immense value. Only a simple, easy-to-remember, and meaningful domain name can undertake the mission of corporate branding and be recognized by more internet users. Moreover, as a relatively new business model, network- and finance-based development is the key point while authentication and security issues are the prerequisite of e-commerce development.
 
It is obvious that the existing top level domains (TLDs) are not able to fully and effectively satisfy the demands of e-commerce development. We are in desperate needs of a designated domain namespace that can be reasonably classified based on its goals and purposes and instantly recognized by Internet users. The proposed .shop TLD serves this purpose almost perfectly. It is both a noun and a verb and one of the most recognizable shopping related words around the world. Businesses can obtain a .shop extension which can represent their unique e-shop identity to further expand their businesses online, thereby constructing an existing or brand new platform for the development of their online and offline products and services. 

Meanwhile, .shop will enhance Internet usersʹ trust as abuses like phishing, domain name parking and hijacking will be better resolved. Internet users can better rely on the new generic TLD (gTLD), which are the brand personification of the actual entity. They can also benefit from the uniqueness and high recognition of .shop to search and identify the reliable online merchants more effectively and enjoy a more secure and convenient shopping experience. To sum up, the successful registration and operation of the .shop gTLD will impulse a healthy development of global e-commerce industry and enhance the confidence of millions of consumers for online shopping.

As one of the largest online retail enterprises in China, JINGDONG 360 DU (hereinafter referred to as JINGDONG), plans to apply for this unique and influential TLD to promote the development of e-commerce business. 

For the .shop TLD application, JINGDONG has three prominent advantages. First, JINGDONG has innovative and pioneering spirits for online products as well as successful experience and capabilities for market development and expansion. It is currently the largest direct online retailer in China. Ever since it pioneered into the e-commerce field in 2004, it has maintained a fast growing momentum, with growth rate exceeding 200% for six consecutive years. In 2010, it became Chinaʹs first online retail enterprise with a sales volume of RMB 8.6 billion accounting for 37% in Chinaʹs B2C online business. It is also increasing its overseas procurement efforts to further promote its international strategy.

Second, JINGDONG is an expert in customer relationship management with a deep understanding of consumer needs. It always adheres to the pure e-commerce business model and tries every means to shorten intermediate links so as to provide consumers with quality products and satisfactory online and offline services. In addition, JINGDONG also leads the online retail market by continuously optimizing services and sets a benchmark for creditable operation in Chinaʹs e-commerce industry. 

Last but not least, JINGDONG has already established long-term cooperation with 6,000 global partners and suppliers, with a deep understanding of the demands of interested parties along e-commerce industrial chain on domain names. Moreover, JINGDONG’S mature online and offline marketing strategic planning and execution capability will contribute to the successful promotion of .shop awareness among target users. Currently, JINGDONG has 42 million registered users throughout China and covers over 11 categories of high quality products including household appliances, digital communications, computer, apparel, baby accessories and book ,est. ; it processes over 300,000 orders per day and the average daily page view (PV) of website exceeds 50 million.
 
JINGDONGʹs fast development and promising prospects have won the favor of well-known international venture capital funds. At the beginning of 2011, JINGDONG got the financing of USD1.5 billion from 6 funds including Russiaʹs Digital Sky Technologies (DST) and the Tiger Fund. This is so far the largest single amount of financing in Chinaʹs Internet market, indicating investorsʹ strong recognition and confidence in JINGDONGʹs successful business model and excellent performances.

To sum up, JINGDONGʹs advantages mentioned earlier will provide a solid and reliable foundation for successfully launching and operating .shop gTLD. JINGDONG strikes to become the most professional and innovative registry operator that can best serve the needs of the e-commerce industry development while providing benefiting the internet users. With the seamless integration of JINGDONG’s mature marketing solutions and its back-end service operator - KNET’s leading technology and services, the future .shop registry will attract all existing and upcoming e-commerce merchants worldwide as the loyal registrants of .shop. Meanwhile, JINGDONG will be committed to providing the best-of-class domain name services to help registrants utilize the unique values of .shop gTLD to the maximum extent after domain registration so as to contribute to a more convenient, efficient, and reliable online shopping experience and environment for the netizens.

18 (b) How do you expect that your proposed gTLD will benefit registrants, Internet users, and others? 
.shop gTLD will provide a new platform for registrants to establish, integrate or extend their online business and contribute more varieties to current internet namespace. As far as the .shop’s unique branding value in the process of e-commerce development concerned, such a customized TLD for e-commerce offer the registrant a great opportunity to maximize their return of investment.

Internet users will have a more unique and reliable top level domain than any other existing domains. With a fast paced modern life, it not only saves online shoppers’ time on internet surfing, ordering and paying, but also frees them from the unnecessary worries about the security and feasibility of online shopping so that they can fully enjoy the convenience and pleasure of online shopping. They might as well become the loyal online shoppers thanks to the positive experience.

We strongly believe that the online shopping will become more reliable and smoother because of the successful registration and operation of .shop TLD. It will consequently promote the fast and orderly development of e-commerce as well as the prosperous global trading and economy.

What is the goal of your proposed TLD in terms of areas of specialty, service levels, or reputation? 
.shop aims to become the most stable, reliable, and even-handed e-commerce gTLD that is trusted by registrants and Internet users. At the same time, JINGDONG commits to provide a high service level which meets and exceeds the SLA required by ICANN.


What do you anticipate your proposed TLD will add to the current space, in terms of competition, differentiation, or innovation?
Under the endorsement provided by .shop gTLD, a reliable domain name will enhance the competitiveness of an enterprise. Through the leverage of .shop gTLD, JINGDONG will provide potential registrants with unique market and brand values, competitive prices, and convenient and trustworthy domain name service choices, which will fully and indirectly drive the virtuous competition in the domain name market. To this end, JINGDONG will utilize its successful experiences in business operation, focus on OPEX control, select outsourcing partners with most state-of-the-art technologies, and provide quality and reliable before-sales and after-sales services. 

In addition, .shop is helpful for Search Engine Optimization (SEO) and can make the registrants stand out from the already crowded .com domain names. Innovation comes out of the practical needs. It is especially true for the .shop TLD. As a widely recognized English word with a variety of derivatives (for example, the Chinese word ʺXuepinʺ is the transliteration of ʺshoppingʺ) and applications, .shop is more likely to be searched as a keyword for Internet users. Take the worldʹs most popular search engine Google as an example; ʺshopʺ is searched as one of the key words by approximately 280 million times per month, far greater than its synonyms ʺstoreʺ and ʺbuyʺ (185 million and 151 million times per month respectively). With the birth of .shop gTLD, Internet users will be surprised with a unique user experience when they want to search for their intended businesses with the word of .shop.

What goals your proposed gTLD have in terms of user experience?
In terms of user experience, .shop aims to provide users with a secure, effective, and easy-to-remember domain namespace while facilitating the recording of search engines so as to enhance usersʹ trust on cyberspace and services on the .shop platform. In addition, .shop will provide 24x7 customer services to ensure network security and availability and protect users from domain name abuses such as malicious websites, spam, phishing websites, and others. At the same time, as the portal logo of e-commerce business, .shop could boost usersʹ trust in businesses searched on the .shop platform and thereby enhance their identification with online shopping as part of this modern while intelligent lifestyle.

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

Relevance Requirement for Registrants

When registering a .shop domain name, Registrants have to consent to Clause on Relevance requirement at the Registration Agreement, and ensure that Registrants have owned E-commerce business, or are intended to expand its businesses on the web.

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 !, $, &, e, and so on) are not currently acceptable. The maximum number of LDH characters accepted for a second level domain is 63. 

WHOIS Policy

The Applicant shall abide by current WHOIS policy and consensus policy adopted by ICANN.

The Applicant 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. 

WHOIS accuracy Requirement

The Applicant believes that an accurate and genuine WHOIS information requirement is essential to the proper use of the domain name and is vital in tackling the abuses of the domain names. The applicant hence require the registry, registrars and registrants to make sure the WHOIS information of the registrant is accurate and genuine, any update of the WHOIS information shall be done in a timely manner. 

Requirement for Registrants

When registering a .shop domain name, the Registrant has to consent to clause on WHOIS requirement at the Registration Agreement, and ensure that the submitted registration information is authentic, accurate and complete. The registrant has to consent that should there be any changes on the WHOIS information in the future, the registrant will update the registration information within 30 days upon occurrence of the changes.
The Registration Agreement states that the registrant must submit the following information: 
a) The complete and accurate WHOIS information of the domain name required by the Registry pursuant to the Specification 4 of the Registry Agreement;
b) Signed copy of the Registration agreement.
The registrants also consent that the registrant is 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. 

Requirement for Registrars

One of the requirements of the accreditation of the registrar is that the registrar is capable of auditing and verifying the WHOIS information submitted by the .shop domain name registrant. 
In the proposed RRA agreement with the .shop Registry Operator, the Registrar is required to take necessary measures to verify the authenticity, accuracy and completeness of the registrant information before domain names registration. The verification mechanisms include but not limited to emails, SMS, and phone call verification. The identification of the registrant will also be verified.
The process for the WHOIS verification will be carried out as follows:
(1) The registrar will check the completeness of the registration material and documentation;
(2) The registrar will verify the WHOIS information of the registrant. The registration system of the registrar is required to send out email or SMS to each email address or mobile phone number of the registered domain name to ask for verification of the receiver. No reply will be deemed inaccurate information. 
(3) The Identification material of the registrant is required. The individual registrant is required to submit the photocopy of the ID card or passport of the registrant, and the entity registrant is required to submit the photocopy of the Business Certificate or other legal documentation of the establishment of the entity.

Requirement for the Registry Operator 
The Registry Operator will set up an annual evaluation process for the Registrars on their performance on the WHOIS verification. The standard is based on the complaints received and the WHOIS inspection resulted performed by the Registry Operator based on the Registry-Registrar Agreement (RRA). The random inspection ratio is no less than 1%. If the proportion of qualified registrants in random inspection is lower than 90%, the Registrar is deemed unqualified. If the proportion of qualified registrants is 95% or higher, the Registrar are considered qualified. The unqualified registrar will be punished, and the qualified registrar will be awarded and honored pursuant to the Registry-Registrar Agreement (RRA)
Requirement for the Back-end Service Provider 

The applicant requires the Back-end Service Provider, KNET co., Ltd to carry out a random check on WHOIS information of the domain name registered on the SRS on a daily basis. KNET will verify the registrantʹs Identification via the authoritative database of the government offices to ensure their authenticity and accuracy. 

Any inaccurate WHOIS information will be sent back to the contact of the Applicant mentioned above. The Applicant will request the registrar concerned to update the registrant information within 5 working days. Failure to do so would result in domain name suspension or takedown and the registrar will be noted as breach of the Registry-Registrar Agreement (RRA) RRA.

The applicant also commits itself to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information. Details of the WHOIS policy can be found in answer to Question Q26 and Q28.

Others

1) Data Privacy as describe in Question 18(c) below
2) Geographic name restriction as described in answer to Question 22
3) The full Domain Name Lifecycle as describe in answer to Question 27
4) Right protection mechanisms as describe in answer to Question 29
5) Reserved Domain Names list as describe in the answer to Question 29

What measures will your proposed gTLD adopt to protect the privacy or confidential information of registrants or users? Please detail all these measures if any.

JINGDONG would adopt stringent policies to protect the privacy of registrants and its domain name users as per the ICANN WHOIS policy and China data protection regulation.

As such policy and regulation may be modified in the future, JINGDONG will also amend its privacy policy accordingly from time to time.

Specifically, JINGDONG is subjected to China’s (“Information Security Technology -- Guide of Personal Information Protection”). In brief, JINGDONG shall inform the registrants
1) The purpose of any personal information collected and scope of use
2) The period in which these personal information will be stored
3) The security measure and information protection policy to safeguard the personal information
4) The rights of the registrants on the personal information 
5) The registrant responsibility for accuracy of the personal information

In general, JINGDONG 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 registry service provider shall deploy security measures to protect the integrity of the database against potential stealth or unintended leakage. Please refer to 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.

JINGDONG will make full use of its years of successful marketing experiences and extremely effective execution to develop and perform a set of efficient and staged PR and marketing activities for .shop gTLD so as to make the potential registrants realize the enormous values and business opportunities that .shop will bring. After the start-up phase, JINGDONG will pay attention to both the attraction of new registrants as well as the renewal of registered merchants. From our years of experience in Customer Relationship Management (CRM), we have summarized the following methods: 
Online conferences, interactive meetings, media (TV, online media), and other promotion means
1 JINGDONG will promote .shop at the global scale in a coordinated manner. The start-up phase will mainly focus on media promotion such as press conferences as well as online and offline media campaigns to publicize the availability of .shop registration services, enhance its visibility, and strengthen its recognition so as to be distinguished from and compete against the most likely gTLDs such as .buy and .mall.
2 JINGDONG will launch branding activities of .shop in the Internet domain name industry and utilize print and video promotional materials as well as other means like discussion salons to further communicate the potential business models as well as accompanying unique values in the .shop era.
3 JINGDONG and its registrars and other industry partners will use network marketing means to introduce the .shop registration service and the accompanying unique values to target users by stages continuously. As a new TLD, .shop can only gain the permanent identification and support of registrants and Internet users after long-term and stable development.

18(c) 
Public domain name registration service follows the ʺfirst-come⁄first-servedʺ principle. Where an organization has disputes concerning the registered domain names, such disputes will be submitted to the dispute resolution institute authorized by .shop Registry subject to the Uniform Domain-Name Dispute-Resolution Policy (UDRP).

Explain any cost benefits for registrants you need to implement (e.g. advantageous pricing, introductory discounts, bulk registration discounts).

.shop will price by referring to the market price of certain comparable TLDs in the world while taking the acceptable price of potential users into full account. Users can enjoy certain discount at the introductory phase to facilitate the promotion of .shop. As to the specific discounts, it will be decided according to the market demands. For detailed assumption regarding price point and domain volumes, please refer the answer to Q48 Funding and Revenue

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

The magnitude of price increase per year will not be higher than 7% to ensure .shopʹs sustained operation and ability to provide high-quality services to registrars and users. JINGDONG shall inform of the price adjustment to its registrars through various channels of website announcements, news media, emails, etc.

No

Not Available

No

22． Describe proposed measures for protection of geographic names at the second level and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and⁄or release of such names.

To minimize any potential abuse of geographic names and to mitigate confusion and dispute, .shop Registry Operator would reserve the geographic names, and the reserved lists can be revised from time to time at the discretion of the Registry Operator. The reserved words and categories should be published on the website of .shop Registry Operator. In the event of release of such names, certain procedures will be observed to ensure the proper use of the geographic names. 

22.1 The reservation list
22.1.1 Reserved list as per AGB 

As per the Specification 5 of the Registry Agreement, .shop Registry Operator shall put the following geographic names on reservation. The reserved geographic names are:

Country and Territory Names - The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations: 
i) the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU〉; 
ii) the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and 
iii) the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; 

Regional or Continental Names - The names are listed as a UNESCO region on the UNESCO website (see http:⁄⁄www.unesco.org⁄new⁄en⁄unesco⁄worldwide⁄) or appearing on the “composition of macro geographical (continental) regions, geographical sub-regions, and selected economic and other groupings” (see http:⁄⁄unstats.un.org⁄unsd⁄methods⁄m49⁄m49regin.htm).

22.1.2 Reserved list of sub-divisional names of the countries and territories

In addition to the Country and Territory Names reservation, .shop Registry Operator will also reserve the names of subdivisions of the countries and territories as listed on ISO 3166-2⁄3. Also, the national geographic names of China in which the registry registered will also be put to reserve list. The names lists include:
i) the short form (both in English and in Chinese) of sub-divisional names of all country and territory names contained on the ISO 3166-2 list, as updated from time to time; the short form (both in English and in Chinese) of the country and territory names contained on the ISO 3166-3.
ii) The names (both in English and in Chinese) of the provinces and municipalities of China, including complete form and short form as well as unofficial abbreviation of the geographic names.
iii) The names (both in English and in Chinese) of the sub-regions of the provinces and the names of the cities and counties in China.

22.2. Procedures to release the Geographic Names
Normally, .shop TLD will not allow for the release of geographic names. However, the reserved geographic names may be released to the extent that .shop Registry Operator reaches agreement with the applicable government(s). The release of the geographic names shall follow the below described procedures.

22.2.1 The release of country and territory names
A) The Government or public authority concerned informs the GAC Secretariat of their request to register the name, and the designated beneficiary.
B) The GAC Secretariat authenticates the request and transfers it to the ICANN staff and to .shop Registry Operator.
C) .shop Registry Operator verifies the availability of the name and issues an authorization letter that is transmitted directly to the designated beneficiary in the country concerned.
D) The designated beneficiary (the Registrant) registers the name, with an accredited .shop Registrar, using the authorization letter as their authority.

22.2.2 The release of national geographic names
The reserved national geographic names could be released on the condition that the applicable government(s) support the acceptable use of the domain names and reaches agreement with .shop Registry Operator. Under this circumstance, .shop Registry Operator would apply the following mechanism:
A) The government concerned informs the Registry of their request to register the name, and the designated beneficiary.
B) .shop Registry Operator checks the availability of the name and issues an authorization letter that is transmitted directly to the designated beneficiary
C) The designated beneficiary (the Registrant) registers the name, with an accredited .shop Registrar, using the authorization letter as their authority.

23. Registry Services
23.1. Registry Services 
JINGDONG is the Registry Operator of the TLD ʺ.shopʺ (hereinafter referred to as ʺ.shopʺ Registry) that provides the services as specified in Specification 6, section 2.1 (a) and (b) in ICANNʹs Applicant Guidebook as well as those as specified in Appendix A. In particular, the ʺ.shopʺ Registry prohibit the use of wildcard per requirements specified in Specification 6, section 2.2. 
The ʺ.shopʺ Registry provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the ʺ.shopʺ Registry 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.
JINGDONGwill outsource the technical operation to KNET (“Back-End Service Provider”) while the remaining operation will be handled byJINGDONG (“Business Operation Provider”).The KNET Shared Registry Platform (“KSRP”) is designed and implemented to provide robust and highly available registry services.
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
KRSP conforms to the ISO27000 standard in its design, implementation and operations. KSRP institutes the following security measures:.
a) A set of operations 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 ʺ.shopʺ Registry 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 an 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 ʺ.shopʺ Registry 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 ʺ.shopʺ Registry receives the data from Registrars concerning registrations of domain names and name servers.
The ʺ.shopʺ Registry provides the SRS service. Registrars collect the data from end users relating to registration contacts, domain names and name servers and submit them to the ʺ.shopʺ Registry via the SRS system; the ʺ.shopʺ Registry also provides add-on auxiliary services for Registrars to submit other business-related data as required by ʺ.shopʺ Registry;
23.2.1. Service Level 
The service level of the SRS provided by the ʺ.shopʺ 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 ʺ.shopʺ Registry.
To connect to the SRS platform of the ʺ.shopʺ Registry, a Registrar must provide a set of fixed static IP addresses to the ʺ.shopʺ Registry 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 ʺ.shopʺ Registry fully 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 ʺ.shopʺ Registry 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 ʺ.shopʺ Registry will build its official website（www.nic.shop）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 ʺ.shopʺ Registry 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, ʺ.shopʺ Registry 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
KNET is in charge of the operation of the zone servers as part of the KSRP. KNET 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 ʺ.shopʺ Registry. 
23.6.1. Security
In addition to those described in 23.1.2, there are also the following security measures for zone server operations. 
KNET 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; 
KNET 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, KNET is developing 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) KNET 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) KNET 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) KNET 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 ʺ.shopʺ Registry 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 ʺ.shopʺ Registry 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 ʺ.shopʺ Registry provides two types of Whois query service: general queries and searchable queries.
The ʺ.shopʺ Registry provides ICANN and other authorized third parties access to the ʺ.shopʺ zone files.
The ʺ.shopʺ Registry provides ICANN with bulk registration data through the interfaces specified by ICANN.
23.7.1. Service Level 
The service level provided by ʺ.shopʺ Registry 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. DNSSEC
KSRP is designed to fully support DNSSEC. The ʺ.shopʺ Registry 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.
ʺ.shopʺ Registry deems DNSSEC as critical for its registry services. KNET plans to actively drive adoption of DNSSEC in KSRP in 3 stages:
a) Stage 1: Test-Bed. At this stage, KNET 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.8.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.8.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 ʺ.shopʺ Registry, KNET 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 
ʺ.shopʺ Registry provides Registrars with a registration interface for the domain ʺ.shopʺ through KSRP provided by KNET. 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 ʺ.shopʺ 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 ʺ.shopʺ Registry 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 meet 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 ʺ.shopʺ Registry plans to delegate 692,000 domain names within 3 years. When the registration volume reaches such target point, the ʺ.shopʺ Registry needs to handle about 2,080,152 transactions per day. 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 ʺ.shopʺ Registry, but also to scale for future demand of ʺ.shopʺ Registry 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 in almost real-time.
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 ʺ.shopʺ Registry 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 ʺ.shopʺ, 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.
KNET 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-11in 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 
ʺ.shopʺ Registry provides services to the public through KSRP provided by KNET. KSRP provides Registrars with a registry service interface for the domain name ʺ.shopʺ over EPP 1.0. KNET 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 with the EPP server, Registrars begin to send other EPP commands. Each of the subsequent commands from 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 domains, contacts 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 Registrars 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 ʺ.shopʺ Registry 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 functionalities 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 ʺ.shopʺ Registry provides Whois services to the public through KSRP by KNET. 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. Operations 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 
It is estimated that 692,000 domain names will be delegated under the ʺ.shopʺ TLD within 3 years after its launch and when the registration volume reaches such target point, there will be 818,866 queries a day . 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 ʺ.shopʺ Registry 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 ʺ.shopʺ Registry 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 ʺ.shopʺ Registry will provides 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 ʺ.shopʺ Registry 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-11in 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 ʺ.shopʺ Registry defines the life cycle of the domain names under ʺ.shopʺ based on IETF RFCs required by ICANN and its own business needs. The life cycle consists of 6 periods: Available, Pre-audit, Registered, Autorenew Period, Redemption Grace Period and Pending Delete. 
Pre-audit is a new period added by the ʺ.shopʺ Registry to ensure that domain name registration complies with local policies and laws. A domain name first enters the Pre-audit period upon creation (the EPP status is pendingCreate, and the RGP status is N⁄A). After manually examined by the ʺ.shopʺ Registry, the domain name 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_attachment for 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 renewPeriod; 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 OK, 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 Pre-audit or 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) pendingCreate: With this status, a domain name cannot be resolved; nor can any operation be performed on it. After the registration request of a domain name is submitted, the domain name enters the Preaudit period with the EPP status being pendingCreate and the RGP status being N⁄A. After the registration request passes auditing, the domain enters the Registered period; the EPP status changes to serverTransferProhibited and the RGP status is set to addPeriod. If the request doesnʹt pass auditing, the Registry directly deletes the domain name. In this case, the domain name changes back to the Available period. 
p) pendingRenew, pendingUpdate: these two statuses are not applicable. The renewal and update of ʺ..shopʺ 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 ʺ.shopʺ Registry 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 would not tolerate any abuse of the domain names under its management. In this section, the Applicant would describe 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 Domain Anti-Abuse Policies 
28.1.1 Categorization of the abuses

The Applicant would like to adopt the definition on the abuse by the Registration Abuse Policy Working Group (RAPWG), that the 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.
However, the RAPWG also finds out that the differences between registration issues and use issues have a very distinct impact to the TLD when it comes to the capacity to contain these two abuses.
Registration issues 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. 
In contrast, domain name use issues 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 use issues are often independent of or do not involve any registration issues. 
Pursuant to the classifications of the domain name abuses, the applicant would like to adopt the following policies and mechanisms to address the potential abuses concerning the “.shop” TLD.

28.1.2 Anti-abuse Policies
With reference to the final report of the RAPWG, the Applicant will adopt the following clauses in the Registration Agreement that the abusive use of domain names will result in registration cancellation, domain name suspension or take down action. 
The abuses are categorized as the following types:
I) registration abuse, includes but not limited to Cybersquatting; Front-running; Gripe sites; Deceptive and⁄or offensive domain names; Fake renewal notices; Name spinning; False affiliation; Cross-TLD Registration Scam; Domain kiting ⁄ tasting.
II) Abusive uses of domain names, includes but not limited to phishing, pharming, spoofing, malware⁄Botnet, Pay-per-click\Traffic diversion.
The Registration Agreement states that the registrant “represent, warrant, and agree that you hold the necessary rights to use 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. ”
Pursuant the Registration Policy published on the website of the Applicant, the Applicant 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; 
(1) to protect the integrity and stability of the registry; 
(2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process;
(3) to avoid any liability, civil or criminal, on the part of the Applicant, as well as its affiliates, subsidiaries, officers, directors, and employees; 
(4) per the terms of the registration agreement or 
(5) to correct mistakes made by the Applicant or any Registrar in connection with a domain name registration. 
The Applicant also reserves the right to place upon registry suspension, takedown or similar status a domain name during resolution of a dispute. Abusive uses, as defined above, undertaken with respect to “.shop” domain names shall give rise to the right of the Applicant to take such actions in its sole discretion.

28.2 Abuse prevention Mechanisms
28.2.1 Anti Abuse Contact Window
The Applicant will publish its domain name anti-abuse policies at the website (www.nic.shop), and also establish an online contact for handling of domain name abuse complaints. The contact information will include at least fixed telephone number, fax number and email address as listed below:
Fixed phone: +8610-58959009
Fax: +8610-57656837
Email: abuse@nic.shop(to be confirmed and created upon the delegation of the TLD)
A team will be assigned to handle the complaints. All accredited registrars of the TLD will be required to set up a contact to liaise with the registry on abuse mitigation purpose. The anti-abuse policy will also be shown on the website of the registrars. 
Any changes on the contact information will be published on the Registry Operator’s website, and will notify registrars and ICANN in a timely manner.
28.2.2 WHOIS accuracy Requirement
The Applicant believes that an accurate and genuine WHOIS information requirement is essential to the proper use of the domain name and is vital in tackling the abuses of the domain names. The applicant hence require the registry, registrars and registrants to make sure the WHOIS information of the registrant is accurate and genuine, any update of the WHOIS information shall be done in a timely manner. 
Requirement for Registrants
When registering a “.shop” domain name, the Registrant has to consent to clause on WHOIS requirement at the Registration Agreement, and ensure that the submitted registration information is authentic, accurate and complete. The registrant has to consent that should there be any changes on the WHOIS information in the future, the registrant will update the registration information within 30 days upon occurrence of the changes.
The Registration Agreement states that the registrant must submit the following information: 
a) The complete and accurate WHOIS information of the domain name required by the Registry pursuant to the Specification 4 of the Registry Agreement;
b) Signed copy of the Registration agreement.
The registrants also consent that the registrant is 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. 

Requirement for Registrars
One of the requirements of the accredited registrar is that the registrar is capable of verifying the WHOIS information submitted by the “.shop” domain name registrant. 
In the proposed RRA agreement with the “.shop” Registry Operator, the Registrar is required to take necessary measures to verify the authenticity, accuracy and completeness of the registrant information before domain names registration. The verification mechanisms include but not limited to emails, SMS, and phone call verification. The identification of the registrant will also be verified.
The process for the WHOIS verification will be carried out as follows:
(1) The registrar will check the completeness of the registration material and documentation;
(2) The registrar will verify the WHOIS information of the registrant. The registration system of the registrar is required to send out email or SMS to each email address or mobile phone number of the registered domain name to ask for verification of the receiver. No reply will be deemed inaccurate information. 
(3) The Identification material of the registrant is required. The individual registrant is required to submit the photocopy of the ID card or passport of the registrant, and the entity registrant is required to submit the photocopy of the Business Certificate or other legal documentation of the establishment of the entity.
Requirement for the Registry Operator 
The Registry Operator will set up an annual evaluation process for Registrars on their performance on the WHOIS verification. The standard is based on the complaints received and the WHOIS inspection resulted performed by the Registry Operator based on the Registry-Registrar Agreement (RRA). The random inspection ratio is no less than 1%. If the proportion of qualified registrants in random inspection is lower than 90%, the Registrar is deemed unqualified. If the proportion of qualified registrants is 95% or higher, the Registrar are considered qualified. The unqualified registrar will be punished and the qualified registrar will be awarded and honored pursuant to the Registry-Registrar Agreement (RRA)
Requirement for the Back-end Service Provider 
The applicant requires the Back-end Service Provider, KNET co., Ltd to carry out a random check on WHOIS information of the domain name registered on the SRS on a daily basis. KNET will verify the registrantʹs Identification via the authoritative database of the government offices to ensure their authenticity and accuracy. 
Any inaccurate WHOIS information will be sent back to the contact of the Applicant mentioned above. The Applicant will request the registrar concerned to update the registrant information within 5 working days. Failure to do so would result in domain name suspension or takedown and the registrar will be noted as breach of the Registry-Registrar Agreement (RRA).
28.2.3 Reasonable Access Control 
The registrar will provide with a secured online access to registrant to manage the domain names. This access may provide with a platform for domain name information update, domain name transfer request, renewal or deletion. The management system will be provided with SSL connection, reinforced password control and CAPTCHA verification. The system will send out notice to request the registrant change the password every three months. The registrant will be able to update registrant information, requesting domain name transfer Auth-code and domain name deletion. All these operations will require a verification process.
In the event of domain name transfer, the registrant will be required to obtain Auth-code at the losing registrar and give it to the gaining registrar. In addition to that, the losing registrar is required to send transfer notice to the administrative contacts and technical contacts of the registrant before transferring. The gaining registrar is required to notify the administrative contacts and technical contacts of the registrant after transferring. 
In the event of the domain name update and deletion, the registrant will be required to verify the operation either via email or via written notice. In the meanwhile, the administrative contacts, technical contacts and billing contact of the registrant will all be informed of the operation.
28.2.4 Disposal of 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 not allowing orphan record. 
KNET, the Back-end Service Provider, has designed the KNET Shared Registry Platform to automatically mark the generated orphan glue records and the date when suspending a domain name resolution or deleting a domain name. At the time that the 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 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. Those 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:
1) Upon reception of the complaint, the Applicant will coordinate with its back-end provider, KNET on the issue;
2) KNET will report back on the status of the orphaned glue record according to its daily scanning record within 24 hours;
3) The Applicant shall instruct an immediate deletion order to KNET to remove the orphan glue record and KNET will delete the record within 8 hours upon receipt of the order.

28.3 Abuse Mitigation Mechanism 
The Applicant will set up an anti-abuse mechanism to act swiftly to mitigate any abuse and take down any infringing “.shop” domain names. Based on the nature of the abuses mentioned above, the Applicant shall act in three levels to counteract to potential registration abuse and domain use abuse:
28.3.1 Registration abuse mitigation mechanism
Since the mission of “.shop” TLD is to serve the interest of the Electronic Commerce industry, the Applicant regards prudent and proper use of domain names higher than pure volume. 
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 also states that the Registrar is responsible for the WHOIS accuracy of the domain names.
When registering a “.shop” domain name, the Registrant has to consent to clause on relevance requirement at the Registration Agreement, and ensures that the registrant has owned E-commerce business, or is intended to expand its businesses on the web.
On top of that, the accurate WHOIS information of the domain name will be verified. Details of the WHOIS information verification mechanism can be seen on the above section. Any inaccurate WHOIS information could lead to domain name cancellation or rejection.
Through the strict requirement and audit process prior to registration, the “.shop” TLD shall avert or mitigate at least several registration abuses in question. Please refer to Table 28-1 in Q28_attachment
In the event of compliant on domain registration abuses, the applicant will follow the procedures as described below:
1) the Applicant will put the domain name in question on registry lock, then 
2) the Applicant will determine the nature of the complaints, if this falls within the ability of the Applicant, the Applicant will instruct the sponsoring registrar to take down the domain name pursuant to Registry-Registrar Agreement (RRA) or Registration Agreement; 
3) Should this complaint be beyond the ability of the Applicant, the Applicant will follow the procedure that is described in the following section. 
28.3.2 Abuse mitigation mechanism
With regard to abusive use of “.shop” domain names, which may concern phishing, pharming, malware downloading, etc., the Applicant will rely on the registrars, the interested parties or the Internet users to detect the abuse, and in collaboration with other third party security vendors or Law Enforcement Agencies, to tackle such abusive use of the “.shop” domain names.
A typical process to tackle the registration abuse 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 shall identify the abuse incidents involving the domain names with the help from other third party security vendors or Law Enforcement Agencies if necessary in five days;
3) Once the abuse is identified, a notice of breach will be sent to the domain name registrant, registrar and any party concerned and request immediate action to mitigate the abuse in 24 hours;
4) Should the Applicant receive no response from the registrant or the registrar, pursuant to the Registry-Registrar Agreement (RRA), the Operator shall notify the registrar to take a suspension action or takedown within 4 hours; the Applicant shall also notify the registrant on the action taken via the contact method contained in the WHOIS.
The registrant is also allowed to dispute the suspension or takedown action should the registrant if the domain name is suspended mistakenly. The procedure for the plea and process is as follow:
1) The registrant file the plead to the Applicant via the contact information published on the website with the evidence that the domain name is registered and used in accordance to the Registration Agreement;
2) The Applicant will direct the evidence to the party who is identify the complaints to review. If the evidence is approved and the restore order is issued, the Applicant will instruct the registrar to restore the domain name within five working days pursuant to Registration Agreement and Registry-Registrar Agreement (RRA).

28.3.3 Domain names dispute Mechanism
Sometimes the domain name abuse complaints will have to go through dispute resolution provider. When the domain name in question is in dispute or other legal proceedings, the Applicant will take the following actions to prevent abuse:
i) When the domain name dispute is filed via the Uniform Rapid Suspension Policy, 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 resolve. After the “lock” operation, the Applicant will notify the URS Provider immediately upon locking the domain name (Notice of Lock). The Applicant will also take action as per described by the URS Provider.
ii) Domain name disputes may also be filed under Uniform Dispute Resolution Procedure (UDRP). The Applicant shall monitor its accredited registrars to implement the arbitration result.
Details of the Dispute resolution mechanisms please refer to answer to Question 29.

28.3.4 Collaboration with other parties
Externally, the Applicant will work with other parties to prevent and mitigate the 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 is obliged to abide by 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 this address: 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 CNCERT⁄CC and other security providers
The Applicant will establish a contact window with CNCERT⁄CC, and other security providers to take down domain name abuse incidents concerning “.shop” 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) The Applicant will instruct the sponsoring registrar to send email notification the registrant (administrative contact, technical contact or billing contact) concerned to respond to the domain abuse complaints upon receipt of the takedown notice from the CNCERT⁄CC; the notification requires the registrant to respond within 5 days; in the meanwhile, the domain name in question will be put in “lock” status;
2) Should there be no response from the registrant, the Applicant will instruct the sponsoring registrar to put the domain name in suspension take down and a notice of takedown will be sent to the email address of the registrant.
28.4 Resourcing Plan 
It is advised that two auditors are furnished (one for auditing, the other for re-auditing）to carry out the registration accuracy audit, and a legal counsel is advised to address the abuse complaints.
On the technical side, the staff will be allocated to following area to ensure a swift and effective action to address the abuses.

29、Rights Protection Mechanisms:

Abusive use policies, takedown procedures, registrant pre-verification, authentication procedures

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”. 

As a TLD aiming at promoting Electronic Commerce in the world, the Applicant will implement a proper Right Protection Mechanism (RPM) to safeguard trade mark, geographic names and other naming rights based on the RPMs mandated by the Registry Agreement. The implemented RPM includes registration prevention mechanism, anti-abuse mechanism and dispute resolution mechanism. The Applicant believes that along with reinforced anti-abuse mechanisms deployed as in answer to Question 28, the RPM shall effectively protect the legal right holders and mitigate the infringement or encroachment on it. 
29.1. Reserved name list 
Pursuant to the Specification 5 of Registry Agreement, except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall reserve (i.e., Registry Operator shall not register, delegate, use or otherwise make available such labels to any third party, but may register such labels in its own name in order to withhold them from delegation or use) names formed with the following labels from initial (i.e. other than renewal) registration within the TLD:
1. Labels Reserved at All Levels. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations.
ICANN-related names:
• aso 
• gnso 
• icann 
• internic 
• ccnso 
IANA-related names:
• afrinic 
• apnic 
• arin 
• example 
• gtld-servers 
• iab 
• iana 
• iana-servers 
• iesg 
• ietf 
• irtf 
• istf 
• lacnic 
• latnic 
• rfc-editor 
• ripe 
• root-servers 

2. two-character labels. All two-character labels shall be initially reserved. The reservation of a two character label string may be released to the extent that Registry Operator reaches agreement with the government and country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes.
3. Tagged Domain Names. Labels may only include hyphens in the third and fourth position if they represent valid internationalized domain names in their ASCII encoding (for example ʺxn--ndk061nʺ).
4. Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the TLD. Registry Operator may use them, but upon conclusion of Registry Operatorʹs designation as operator of the registry for the TLD they shall be transferred as specified by ICANN: NIC, WWW, IRIS and WHOIS.
5. Country and Territory Names. The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:
5.1. the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union
〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-
1_decoding_table.htm#EU〉;
5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; 
5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; 
5.4. Reserved list of the names of countries and regions subdivisions
In addition to the reserved Country and Territory names, .shop registry operator shall reserve the names of countries and regions subdivisions which are listed in ISO 3166-2⁄3 table. The national geographic names in China where the registry is operating will also be included in the reserve name list:
1) the abbreviation of the countries and regional subdivision names(in both Chinese and English) which listed in ISO 3166-2⁄3, and the abbreviation of the countries and regional subdivision names (in both Chinese and English) which listed in ISO 3166-3；
 2) the full names and abbreviations (in both Chinese and English) of Chinese provinces and municipalities under direct jurisdiction of the central government, and the unofficial abbreviations of geographical names 
3) the full names and abbreviations of municipal administrative regions in China’s provinces

Provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.
29.2 Registrant pre-verification and Authentication 
As mentioned in answer to Question 18, Registrants must consent to the Clause on Relevancy requirement in the Registration Agreement, and ensure that Registrants have owned E-commerce business, or are intended to expand its businesses on the web. The registration application has to be audited by the registrars and should be audited by the Registry Operator before the domain name is activated and properly provisioned. 

The Registration Agreement states that the registrant “represent, warrant, and agree that you hold the necessary rights to use or permit to use any item, word, or term submitted through the Domain Name Registration 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. ”

Registrant Whois verification
The accredited Registrars of “.shop” TLD are required to perform WHOIS verification of the registrant. Details of the WHOIS verification mechanism can be found in answer to Question 28. Any breach on the abovementioned principles will result in the annulment of the registration. Any Registrar who violates the above stipulation will also be subject to penalties or even be disaccredited. 

The Applicant performs a random auditing on the registered domain names within five-day Grace Period. Any detection on Rights violation will result in rejection of the registration of the domain name. 

29.3. Start-up rights protection measures 

As required in Applicant Guidebook, the Applicant will implement 2 start-up right protection mechanisms: the Sunrise period and a Trademark Claims service. 

Sunrise Service: Although the Applicant plans to reserve or block any names in the TMCH, the Applicant will implement a 60-day Sunrise service period for eligible trademark holders to register or reserve its names at the second-level of the “.shop” TLD at the pre-launch period. However, the Applicant also reserve the right to deny any trademark name registration request at its sole discretion. 

Proposed Sunrise Registration Process
I) For the Sunrise service, Sunrise eligibility requirements (SERs) will be met as a minimum requirement, to be verified by Clearinghouse data, and supported by implementing a Sunrise Dispute Resolution Policy (SDRP).

If someone is seeking a Sunrise registration, the Registry Operator will provide a notice to holders of marks in the Clearinghouse that is an identical match to the name to be registered.

Sunrise eligibility requirements (SERs)
The proposed SERs include: (i) ownership of a mark (that satisfies the criteria in section 7.2 of TRADEMARK CLEARINGHOUSE in gTLD application Guidebook), (ii) optional registry elected requirements re: international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

Sunrise Dispute Resolution Policy (SDRP)
The proposed SDRP must allow challenges based on at least the following four grounds: (i) at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national 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 did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

Trademark Claims service: although it is highly unlikely that the Trademark names will be easily registered due to the stringent qualification requirement by the Applicant, the Applicants still would like commit itself to offering the Trademark Claims service at the initial open registration phase for 60 days. 

Proposed Trademark Claims service
i) At the first 60-day Trademark Claims Service, The registry operator will send a Trademark Claims Notice (as described in the attachment of the Trademark Clearinghouse) to the prospective registrant, with a link to the Trademark Clearinghouse Database.
ii) The prospective registrant is encouraged to access the Trademark Clearinghouse Database to check the trademark rights. 
iii) If the domain name is registered in the Clearinghouse, the registrar (again through an interface with the Clearinghouse) will promptly notify the mark holders(s) of the registration after it is effectuated;
iv) in the meantime, The Registry Operator will be reported by The Trademark Clearinghouse Database when registrants are attempting to register a domain name that is considered to contain the element of a trademark.

29.4. Dispute Resolution Mechanisms
If any institution or individual raises a dispute over any registered domain names, then such dispute will be settled via Uniform Dispute Resolution Procedure (UDRP) by the dispute resolution body either authorized by the Applicant or other Dispute resolution service provider accredited by ICANN.

Pursuant to the Specification 7 of the Registry Agreement, the Applicant will comply with the following dispute resolution mechanisms as they 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. 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; and 
b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN, including the implementation of determinations issued by URS examiners.

Furthermore, In the event of dispute among rights holders, the Applicant shall implement the following rules before applying the Uniform Domain Name Dispute Resolution Policy (UDRP).

Of course, the parties involved in the dispute can also take the dispute to court should they be dissatisfied with the arbitration result. The Applicant shall observe any court order resulting from the dispute.

29.5. Resourcing Plan 

Given the resource plans placed in the Abuse Prevention and Mitigation plan in answer to Question 28, it is advised that the legal counsel that is in charge of the abuse complaints will be sufficient to carry out the Right Protection Mechanisms described in this section. 

30A. Security Policy
According to ICANNʹs New gTLD Applicant Guidebook, the ʺ.shopʺ Registry 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, KNET 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, KNET 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), KNET 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) Operations 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) Operations 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 an 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 Evens 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, KNET 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;