ICANN New gTLD Application

The applicant—SOHU.com Limited—is a wholly owned subsidiary of SOHU.com Inc. (hereinafter referred to as SOHU). SOHU, established by Dr. Charles Zhang, one of Chinaʹs Internet pioneers, is in its sixteenth year of operation. It is Chinaʹs premier online brand and indispensable to the daily life of millions of Chinese, providing a network of web properties and community based⁄web 2.0 products which offer the vast SOHU user community a broad array of choices regarding information, entertainment and communication. SOHU has built one of the most comprehensive matrices of Chinese language web properties, covering all-around Internet services such as online media destination, interactive search engine, games information portal, top real estate website, online alumni club, wireless value-added services, leading online mapping services, and development and operation of online games.
In 2000, SOHU (NASDAQ:SOHU) formally listed on NASDAQ, becoming a famous international Internet brand. In 2008, as the only Internet content sponsor of Beijing 2008 Olympic Games, SOHU becomes the first choice of Internet users and wins the highest user satisfaction among the portals for its authoritative, fast, comprehensive and professional report. Now SOHU has become the most influential and trustworthy news center, as well as the most popular entertainment center, sports center and fashion center. By virtue of its unmatched media resources and prominent strengths, SOHU develops professional channels for four major industries—Auto, Real Estate, Finance and Economics, and IT, aiming to provide the most fast, real and authoritative information for the public and build a robust and all-around media platform. As of the end of 2011, SOHUʹs total operating income stood at USD 852 million, an increase of 39% year on year (YoY).
The following is the introduction of major services and products of SOHU.
Online Game Business: The Company’s online game business is conducted through SOHUʹs majority-owned subsidiary Changyou. Changyou.com (NASDAQ:CYOU) is a leading developer and operator of online games in China. It began operations in 2003 as SOHUʹs massively multi-player online games (MMORPG) business unit, before its carve-out as a separate, stand-alone company in Dec 2007 and subsequent listing on the NASDAQ Global Select Market in April 2009.
Sponsored Search Business: The companyʹs sponsored search business is conducted through SOHUʹs online search subsidiary Sogou through Sogou.com, an interactive search engine. By integrating three high-quality and popular Internet applications (Sponsored search service, Sogou Pinyin and Sogou Browser), SOHU has become the most promising enterprise in Chinese Internet industry.
Brand Advertising Business: The Company’s brand advertising business offers various products and services (such as free of charge premier content, interactive community and other Internet services) to its users, and provides advertising services to advertisers on its matrices of Chinese language Web properties consisting of sohu.com, a portal and online media destination; 17173.com, a game information portal; focus.cn, a real estate Website, and chinaren.com, an online alumni club.
SOHU properties consist of sophisticated Chinese language Web navigational capabilities, approximately 40 content channels, Web-based communication and community services. Its regional Websites have extensive reach across China. As of December 31, 2010, it had approximately 1,600 content partners, which enable the Company to provide a wide range of content offerings.
Currently, the domains in SOHU have three major applications: a) majority of domains are under the main domain .sohu.com, including the popular business of SOHU (e.g. micro blog, video, photo album); traditional channels (e.g. news, sports and auto) and regional portals(e.g. Guangzhou, shanghai), which are content and social network dominated; b)the search and software products are under the domain .sogou.com, including search portals, browser and input method; c)the functional portal brands have own channels under the .sohu.com as well as their independent domains.
SOHU found it difficult to manage its domain name portfolio and maintain a consistent and secure brand image which is currently scattered across several different TLDs, therefore, SOHU is applying for .sohu which is commonly known shorten Chinese name for SOHU to grasp the opportunity of new gTLD to promote its online brand. Through this gTLD, SOHU will be able to protect its brand and deliver the right impression and message to the end users, thus becoming the brand protection and brand building mechanism that the company deserves to have in this modern age of the internet. Furthermore, .sohu will have a multiplier effect on SOHUʹs efforts to expand and promote its range of business globally.
The .sohu is planned to be used for SOHUʹs internal business, mainly focuses on the subsidiaries and product lines of SOHU. At present, SOHU has 30 subsidiaries, and several important product lines, including SOHU, Sogou, Changyou, Focus, Chinaren, Go2map, 17173. The existing domains of these subsidiaries and product lines will be gradually integrated under .sohu, without affecting usersʹ usage habits. In addition to these main product lines, .sohu can be used for other purposes as follows: a) special reports for certain significant news or events made by SOHU, such as sars.sohu for the reports of SARS; b) large activities or projects held by SOHU, such as dream2009.sohu, cma.sohu (Chinese Music Award); c)communities about celebrities or superstars, including their archives, photos, news, works or fans club, such as dlj.sohu for the community of the famous singer Deng Lijun; d)the fist products or portals of SOHU, such as ldj.sohu for the MMORPG named Lu Ding Ji developed by Changyou; e) the sports events or competitions in certain place or year, such as 2012.sohu for the London 2012 Olympic Games.
According to the plan of .sohu, SOHU expects .sohu to have 2,000 domain names by the third year of operation at a price of $20 per domain per year. Three stages of domain registration are divided. In the first year of operation, domains of SOHUʹs subsidiaries, principal product lines and channels are planned to be registered, which will be about 1,000 domain registrations. In the second year, domains of SOHUʹs all product lines are planned to be registered and leads to 1,500 domain registrations. In the third year, all new-increased product lines are intended to be registered and result 2,000 domain registrations in total.
By consolidating all the domain names associated with SOHU and its subsidiaries, .sohu will unify all of the companyʹs online related business, reposition them and create a solid foundation for the future. By doing so, SOHU can further increase the scope and range of its online related business while consolidating its position in the market. SOHU will also explore the new operation model of online business.
Furthermore, .sohu will increase the level of trust from the users as problems like phishing, domain redirection and domain parking will be eliminated. Users know that they can depend on such gTLDs that are the brand personification of the actual entity. At the same time, it is so much easier for users to remember instantly and search for such famous companies.
With the rich and high quality gTLD resources, SOHU can redeploy the online business and IT infrastructure to improve the compatibility as well as exclusivity of online business and enhance the security and intelligence of IT infrastructure. To fulfill this mission, SOHU will invest heavily on upgrading and improving the security and intelligence of its information technology backbone and architecture.
In addition, with the leverage of .sohu, SOHU can help to promote healthy competition from the registrars by improving the level of service and providing more optimized choices of domains.

What is the goal of your proposed TLD in terms of areas of specialty, service levels, or reputation?
SOHU is one of Chinaʹs Internet pioneers. Applying and operating the .sohu gTLD can help SOHU to improve the overall competitiveness, and become the leading company within the industry. The successful operation of .sohu is the responsibility of SOHU in virtual world, which will be of great significance to the brand image of SOHU. SOHU makes commitment to provide high level of service to its registrants and users exceeding the SLA required by ICANN (Please refer to the answer to Question 23 for the detail of the SLA provided by SOHU).
The .sohu shall be known as the official online brand for SOHU, delivering secure and trusted services with .sohu domain name.

What do you anticipate your proposed TLD will add to the current space, in terms of competition, differentiation, or innovation?
Just as mentioned above, the websites of subsidiaries of SOHU and the product lines are currently scattered across several different TLDs, which is difficult for SOHU to manage. With the application and utilization of .sohu, SOHU will be able to conceive a uniform and secure brand image and differential services for its customers, Internet users and corporate internal users compared with the current internet space.
First of all, it is hard to solve the abuse of domains such as network phishing and cybersquatting within the current space of ʺ.comʺ or ʺ.netʺ. The .sohu can provide the TLD service to its registrants and users by making .sohu a secure space dedicated for SOHU and its customers. The users of .sohu will be confidential to the space service, which is different from services of other domain spaces.
Secondly, .sohu plans to provide innovative services based on social network. With the unified TLD .sohu, all product lines and branches of SOHU is integrated. Users can navigate SOHU under one TLD, and perform almost all operations. Compared with the current space, .sohu can provide more opportunities for internal cooperation and information sharing among different sectors and branches of SOHU. Cross sector or cross border collaboration or online education could rely on .sohu space to carry out in a secure and stable manner.
Of course, the addition of .sohu in the root will contribute to the competition on the domain name industry, offering more choices and service to SOHU and its customers, and better yet, offering a competitive environment for traditional TLDs to enhance their security and stability of their respective zone. This indirectly forces the existing gTLDs to provide more innovative or better services at a lower price.

What goals your proposed gTLD have in terms of user experience?
The goal of .sohu is to provide customized service and secure space for users.
Secure: .sohu will provide user with ongoing services on a 24x7 basis to ensure the security and availability of network. The registrants of the .sohu domain names can be confident that the registered domain names are managed and controlled by the SOHU with the highest security and availability. Cybersquatting, email fraud, phishing, spoof and other domain name abuses will not occur when using .sohu TLD.
Trust: For the internet users, .sohu domain names bear the brand of SOHU and can be naturally affiliated with its products and services. Internet users hence have the trust on the websites that are offering SOHU products or services without worrying whether or not it is a genuine link. At the same time, with the development of social network, users of .sohu will form a closer social relationship based on the social identity.
Convenient: With the short TLD .sohu, users donʹt need to input the long domains to search information. It will be easier for users to remember and spread the TLD. Users can have advanced and fresh using experience and enjoy a faster and secure internet. And also, the TLD .sohu can be selected conveniently by search engine due to its unique naming which is related closed with SOHU itslef, which is good to enhance usersʹ trust to the cyberspace service.

Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.
Restricted Registration
SOHU will place stringent registration policy for “.sohu” domain names. All application for domain names under “.sohu” TLD must have a supporting letter executed by SOHU’s legal department prior to any registration. In the supporting letter, it will clearly indicate
• the domain name under “.sohu” for which it is been approved
• the purpose of the domain name
• the administrative and technical contact for the domain name
Registrars should be notified that any domain name registration without the supporting letter will lead to rejection.
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
SOHU 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.
SOHU shall deploy ante-audit mechanism. The domain name will not be registered unless all registration materials as well as the real ID and contact information of the registrants or their purveyors to be verified by the Audit team of the accredited registrars.
SOHU 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 29.
Others
• Data Privacy as described in Question 18(b) below
• Geographic name restriction as described in answer to Question 22
• Domain Name Lifecycle as described in answer to Question 27
• Right protection mechanisms as described in answer to Question 29
• Reserved name list as described in the answer to Question 29
Will your proposed TLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.
SOHU 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, SOHU will also amend its privacy policy accordingly from time to time.
Specifically, SOHU is subjected to China’s (“Information Security Technology -- Guide of Personal Information Protection”). In brief, SOHU shall inform the registrants
• The purpose of any personal information collected and scope of use
• The period in which these personal information will be stored
• The security measure and information protection policy to safeguard the personal information
• The rights of the registrants on the personal information
• The registrant responsibility for accuracy of the personal information
In general, SOHU 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.
SOHU envisages the .sohu an integral part of its brand resource. The projected benefits such as consumer trust, recognition of .sohu online and competition will be achieved through a series of promotion and marketing activities.
1. SOHU will carry out advertising and promotion activities of .sohu TLD and the trademark of SOHU across the whole world. It will be held as integral part of the existing brand marketing of SOHU to enhance the relevancy between the gTLD and the trademark of SOHU.
2. At the application stage, outreaches will be given to the subsidiaries and product lines of SOHU to raise the awareness of the online presence of .sohu within the company. It will give the various sectors a precious opportunity to promote their products and services or even more innovative application of the .sohu through this dedicated cyberspace. Internal trainings shall be held in various sectors and branches to achieve the outreach purpose.
3. SOHU will print the logo of .sohu TLD on various kinds of marketing materials of the company to increase the awareness of .sohu in the internet users.
4. After that, outreach and promotion will go to the customers of SOHU. As the targeted users of the .sohu TLD, the customers shall benefit enormously through the secure and trusted online experience on the .sohu domain. Brochure and flyer illustrating the .sohu and its services will be presented at each and every sector and branch of SOHU.
5. The .sohu Registry will take Intellectual Property Rights (IPR) protection actions to safeguard its rights against the abuse of .sohu TLD. The IPR protection will be a long term work which needs ongoing investment.


To minimize any potential abuse of geographic names and to mitigate confusion and dispute, .sohu 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 .sohu 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, .sohu 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, .sohu 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, .sohu TLD will not allow for the release of geographic names. However, the reserved geographic names may be released to the extent that .sohu 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 .sohu Registry Operator.
C) .sohu 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 .sohu 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 .sohu Registry Operator. Under this circumstance, .sohu 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) .sohu 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 .sohu Registrar, using the authorization letter as their authority.

23. Registry Services
23.1. Registry Services
Sohu.com Limited is the Registry Operator of the TLD ʺ.sohuʺ (hereinafter referred to as ʺ.sohuʺ 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 ʺ.sohuʺ Registry prohibits the use of wildcard per requirements specified in Specification 6, section 2.2.
The ʺ.sohuʺ Registry provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the ʺ.sohuʺ Registry strictly follow the requirements of ICANN and IANA and are compliant to technical standards, such as those RFC series described in Specification 6, section 1, with good support to IDN, DNSSEC and IPv6.
The technical platform of the ʺ.sohuʺ Registry is entrusted to a third-party company. The Sohu.com Limited has selected KNET as its back-end registry service provider for its unparalleled business and technical expertise in the China domain name registry industry. The KNET Shared Registry Platform (hereafter referred to as KSRP) is designed, implemented, and operated to provide robust ʺ.sohuʺ Registry services, high availability, security, stability and performance that ensures business continuity and prevents domain name abuse.
Note: The Specifications stated in this document refer to the Specifications in ICANNʹs gTLD Applicant Guidebook.
23.1.1. Service Level
The service level provided by the ʺ.sohuʺ Registry fully conforms to the requirements stated in Specification 10 of ICANNʹs Applicant Guidebook. Please refer to Table 23-1 in Q23_attachment for the summary table of the services level agreement. For detailed information, please refer to corresponding sections.
23.1.2. Security
The ʺ.sohuʺ Registry strictly follows the ISO27000 series standards in its design, implementation and operations. The ʺ.sohuʺ Registry institutes the following overall security measures. Additional measures specific to a subsystem will be documented in the section of that subsystem.
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 log in 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 24×7 basis by a technical team. In case of emergency, risks will be accessed and mitigated with minimum delay.
e) The firewalls, IDS and network traffic monitoring system are deployed in the system 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) The critical data are transferred via a secure channel, such as VPN, HTTPS, and TSIG with data validation to ensure security and integrity.
23.1.3. Stability
The ʺ.sohuʺ 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 the measures such as database hot standby and server clustering via load balancing;
b) The services provided by the ʺ.sohuʺ Registry fully comply with relevant RFCs and other widely accepted industry technical standards. The system will undergo a series of sustained stress testing before officially opening service 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 health of the system in terms of equipment load, network bandwidth and response performance to ensure sufficient capacity 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 ʺ.sohuʺ Registry receives the data from Registrars concerning registrations of domain names and name servers.
The ʺ.sohuʺ 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 ʺ.sohuʺ Registry via the SRS system; the ʺ.sohuʺ Registry also provides add-on auxiliary services for Registrars to submit other business-related data as required by ʺ.sohuʺ Registry.
23.2.1. Service Level
The service level of the SRS provided by ʺ.sohuʺ Registry meets the requirements specified in Specification 10 of ICANNʹs Applicant Guidebook. Refer to Q24 Share Registration System (24.2.2) for details.
23.2.2. Security
Only those Registrars that have been accredited by ICANN are considered to be candidate Registrars for the ʺ.sohuʺ Registry.
To connect to the SRS platform of the ʺ.sohuʺ Registry, a Registrar must provide a set of fixed static IP addresses to the ʺ.sohuʺ 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 Registry 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 ʺ.sohuʺ Registry fully complies with the relevant policy requirements of ICANN. It uses the EPP1.0 and other relevant RFCs including RFC 5730-5734, RFC 3735 and RFC 3915.
The ʺ.sohuʺ Registry provides Registrars with the adequately tested EPP Client SDK and manual.
The SRS service puts a cap on the maximum 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 ʺ.sohuʺ Registry will build its official website（www.nic.sohu）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 ʺ.sohuʺ Registry will also communicate so of these topics release necessary information via Email with 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 any information such as the status of zone servers, ʺ.sohuʺ 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.
The service is only made available to those accredited Registrars according to the pre-defined procedures in order to prevent security and stability issues.
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 ʺ.sohuʺ Registry meets the Specification 10 of the ICANNʹs Applicant Guidebook. Refer to Q35 DNS Service (35.3) for details.
23.5.2. Security
In addition to those described in 23.1.1, there are also the following security measures.
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 has 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, say if 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 DNS 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 ʺ.sohuʺ 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;
b) Recursive queries and other services such as remote Internet protocols including http, telnet, rlogin, 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 for ensuring 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 those attacks.
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 ʺ.sohuʺ 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 ʺ.sohuʺ 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 ʺ.sohuʺ Registry provides two types of Whois query service: general queries and searchable queries.
The ʺ.sohuʺ Registry provides ICANN and other authorized third parties access to the ʺ.sohuʺ zone files.
The ʺ.sohuʺ Registry provides ICANN with bulk registration data through the interfaces specified by ICANN.
23.7.1. Service Level
The service level provided by ʺ.sohuʺ Registry meets Specification 10 specified in the Applicant Guidebook. Refer 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 disaster emergencies.

23.8. DNSSEC
KSRP is designed to fully support DNSSEC. The ʺ.sohuʺ 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.
ʺ.sohuʺ Registry deems DNSSEC as the core and 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 exerts 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 realized with best possible efforts.
A periodic key update system is established, in which the KSK lifetime is 12 months and the ZSK lifetime is 3 months.
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 amount and data volume, generating and checking 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 ʺ.sohuʺ Registry, KNET will upgrade KSRP capacity in database backend servers, disk space, network bandwidth, DNSSEC signing device, other supporting systems and equipment to ensure the steady operations and sufficient redundancy.

24. Shared Registration System（SRS）
24.1. Overview
ʺ.sohuʺ Registry provides Registrars with a registration interface for the domain ʺ.sohuʺ 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 ʺ.sohuʺ 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 ʺ.sohuʺ 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 ʺ.sohuʺ Registry plans to delegate 2,000 domain names within 3 years. When the registration volume reaches such target point, the ʺ.sohuʺ Registry needs to handle about 6012 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 ʺ.sohuʺ Registry, but also to scale for future demand of ʺ.sohuʺ Registry as the business grows.
Comparison with SLR Indicators
Please refer to the Table 24-2 in Q24_attachment for the contrast between the testing 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 ʺ.sohuʺ 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 ʺ.sohuʺ, 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. Please refer to section 31.12.2 for the overall human resource planning of KSRP. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.

25. EPP (Extensible Provisioning Protocol)
25.1. Overview
The ʺ.sohuʺ Registry provides services to the public through KSRP provided by KNET. KSRP provides Registrars with a registry service interface for the domain name ʺ.sohuʺ 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, 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 ʺ.sohuʺ 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 ʺ.sohuʺ 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 2,000 domain names will be delegated under the ʺ.sohuʺ TLD within 3 years after its launch and when the registration volume reaches such target point, there will be 884,152 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 ʺ.sohuʺ 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 ʺ.sohuʺ 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 ʺ.sohuʺ 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 ʺ.sohuʺ 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. Refer to section 31.12.2 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 ʺ.sohuʺ Registry defines the life cycle of the domain names under ʺ.sohuʺ based on IETF RFCs required by ICANN and its own business needs. The life cycle consists of 6 periods: Available, Registered, Autorenew Period, Redemption Grace Period and Pending Delete.
A domain name upon creation officially takes effect and enters the Registered period (the EPP status is serverTransferProhibited for the first 60 days, afterwards, it changes to ok; the RGP status is addPeriod for the first 5 days and then changes to N⁄A ). It takes no more than 3 days for a domain to be manually examined after creation.
Please refer to Figure 27-1 in Q27_attachment for the full life cycle of a domain name, covering the periods such as creation, taking effect, expiry and final deletion.
27.2. Registration Life Cycle and Status
There are totally 18 registration statuses defined for EPP in RFCs 5730～5734 and for RGP in RFC 3915, excluding those that can be set by Registrars, such as clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited).
The EPP statuses include OK, inactive, pendingCreate, pendingDelete, pendingRenew, pendingTransfer, serverHold, serverDeleteProhibited, serverRenewProhibited, serverTransferProhibited, and serverUpdateProhibited.
The RGP statuses defined in RFC 3915 include addPeriod, autoRenewPeriod, renewPeriod, redemptionPeriod, transferPeriod, pendingRestore, and pendingDelete.
27.2.1. Transition of Registration Status
During the whole registration life cycle, the registration status of the domain name evolves as a result of the life cycle period changes and the operations performed. Please refer to Figure 27-2 in Q27_attachmentfor the registration status transition in creation and deletion period of life cycle.
Other operations may affect registration status transition in the life cycle as follows:
a) Update Operation
The Update operation may only be performed on a domain name that is in the Registered period. After the operation, the RGP and EPP status remains unchanged.

b) Renewal Operation
The Renewal operation may be performed on a domain name that is in either the Registered or the Auto-renew period.
When a domain name enters the Registered period, the EPP status is changed to pendingRenew (the previous status is ok) or is added with pendingRenew. After the operation Renewal is done, the EPP status changes back to the previous one. The RGP status changes to renewPeriod; it will change back to its previous status 5 days later.
When a domain name enters the Auto-renew period, the EPP status changes to ok, and the RGP status changes to 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 serverTransferProhibited and serverUpdateProhibited, and the RGP status is autoRenewPeriod. After 45 days, if the Registrar doesnʹt make a deletion request, the EPP status changes to ok and the RGP status is cancelled; if the Registrar does make a deletion request within the 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod and will be cancelled 5 days later.
c) serverUpdateProhibied: a domain name may be renewed, transferred or deleted but not updated.
When a domain name is in the Autorenew Period, the EPP status is serverUpdateProhibited and serverTransferProhibited, and the RGP status is autoRenewPeriod. If the Registrar doesnʹt make a deletion request within 45 days, the EPP status changes to ok and the RGP status is cancelled. If the Registrar does make a deletion request within 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod, which will be cancelled after 5 days.
d) serverRenewProhibited: a domain name may be updated, transferred or deleted but not renewed.
e) ok: a domain name may be updated, renewed, transferred and deleted.
If the Registrar makes a transfer request, the EPP status changes to pendingTransfer,; it will change back to ok after the transfer operation is complete. The RGP status is set to transferPeriod that will last for 5 days.
If the Registrar makes a deletion request, the EPP status changes to pendingDelete and the RGP status is set to pendingDelete.
If there is any complaint about the improper use of the domain name, the EPP status changes to serverHold. If the domain name is confirmed to be free from any abuse or fraud, the EPP status changes back to ok; otherwise, both EPP and RGP statuses change to pendingDelete.
f) inactive: within this status, the domain name is not associated with a host and thus canʹt be resolved.
If the Registrar submits a deletion request, the EPP status changes to pendingDelete and the RGP status changes to pendingDelete.
If the Registrar submits an update request to associate the domain name with a host, the EPP status changes to ok.
g) pendingDelete: with this status, the domain name can neither be resolved, nor can it be updated or transferred.
If a domain name is in the Registered period or its EPP status is inactive or serverHold when the deletion operation is being performed, the EPP status changes to pendingDelete. The RGP status is set to pendingDelete. The domain name will be deleted after 5 days.
If a domain name is in the Autorenew Period when the deletion operation is being performed, the EPP status changes to pendingDelete, and the RGP status is set to redemptionPeriod.
h) pendingTransfer: this status indicates that the domain transfer request has been accepted. With this status, no update, renew, or delete operation can be performed on the domain name although the domain name is resolvable in DNS. After the transfer is complete, the EPP status changes back to its previous status. The RGP status is set to transferPeriod, which will be cancelled after 5 days.
i) addPeriod: the RGP status is set to addPeriod for the first 5 days after a domain name enters the Registered period. After 5 days, the RGP status is cancelled. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.
j) renewPeriod: when a domain renewal request is submitted, the RGP status changes to renewPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.
k) transferPeriod: when a domain name transfer request is submitted, the RGP status changes to transferPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, fees resulting from transfer will be refunded.
l) autoRenewPeriod: the RGP status of a domain name when it is in the Autorenew period. If the Registrarʹs account has enough money for renewal after the domain expires, the RGP status changes to autoRenewPeriod and the domain name will be automatically renewed for 1 year. The Autorenew period lasts for 45 days. If the Registrar doesnʹt delete the domain name or does perform the renewal operation after 45 days, the domain name returns to the Registered period and the RGP status is cancelled; otherwise the RGP status changes to redemptionPeriod.
m) redemptionPeriod: the RGP status of a domain when it is in the Redemption period. If the Registrar submits a restore request, the RGP status changes to pendingRestore, otherwise, it changes to pendingDelete after 30 days.
n) pendingRestore: an intermediate status only applicable to domain names in the Redemption period of a domain name. When a domain name is in the Redemption period, if the Registrar submits a restore request to the Registry within 30 days, the RGP status changes to pendingRestore. If the Registrar submits a formal restore request report to the Registry within the subsequent 7 days, the EPP status changes to ok and the RGP status is cancelled; otherwise the RGP status changes back to redemptionPeriod. If the Registrar doesnʹt perform any restore and⁄or renewal operations within 30 days, the RGP status changes to pendingDelete.
o) pendingRenew, pendingUpdate: these two statuses are not applicable. The renewal and update of ʺ.sohuʺ 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 ʺ.sohuʺ 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
As a Brand TLD, 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 .sohu 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 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. ”
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 .sohu 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.sohu), 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 telephone: +86-10-62728472, 62728889
Fax: +86-10-62702153
Email: abuse@nic.sohu
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 .sohu 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 .sohu domain name registrant.
In the proposed RRA agreement with .sohu 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 theirs performance on the WHOIS verification. The standard is 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 .sohu 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 .sohu TLD is to serve the interest of Sohu Group, the Applicant does not seek any commercial interests; 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.
In practice, The Applicant will require any domain name registration request to provide with a supporting letter to certify that its applied domain name is approved by Sohu.com Limited. 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 .sohu 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 .sohu 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 .sohu 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 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 .sohu 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 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 at least one auditor is furnished 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 protecting and promoting the brand of Sohu.com Limited online, 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 reckons 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, .sohu 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 provincess

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, the Applicant has set a restrictive qualification requirement for .sohu domain names. 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. ”

29.2.1.	Registrant pre-verification
The accredited Registrar of .sohu TLD must perform a pre-audit process on each domain name registration applications, requesting the registrant to submit the documentary evidence to verify that its applied domain name is approved by Sohu.com Limited.  -Registrars are also 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 would like 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 .sohu 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 a Sunrise service, Sunrise eligibility requirements (SERs) will be met as a minimum requirement, 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 the holder of the trademark 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 suggested to access the Trademark Clearinghouse Database to check the trademark right.  
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 right 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 are dissatisfied with the arbitration result. The Applicant shall observe any court order on 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 ʺ.sohuʺ 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 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 to Table 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;

Carol Yu	Equity Director
Charles Zhang	Equity Director

New gTLD Application Submitted to ICANN by: Sohu.com Limited

String: sohu

Originally Posted: 13 June 2012

Application ID: 1-933-39092

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.