ICANN New gTLD Application

Guangzhou Yuwei Technology Co. Ltd (“The Applicant”) was incorporated in China on February 27th of 2012 with a registered capital of RMB 50 million. It is officially appointed and endorsed by the Guangdong provincial government with mission and purpose of applying for the relevant geographic gTLDs upon the launch of the ICANN new gTLD program and subsequently operating and managing these geographic gTLDs.
The vision for the Applicant is to become of the first few stakeholders in the China Internet space, and also the global Internet space to manage and operate geographic TLD and through the TLD, serve the general Chinese public’s interests and promote the culture and brand of the Guangdong region via the Internet.
Guangdong province is the most populous province in China, registering about 104 million residents. Its gross domestic product (GDP) in 2011 reached about RMB 5300 billion (USD 841 billion), an increase of 10% from last year. This is the highest among all provinces of China. The province contributes approximately 12% of China’s national economic output and is home to the production facilities and offices of a wide-ranging set of multinational and Chinese corporations.
The Applicant has chosen Zodiac Holdings Limited (“Zodiac”) as its partner to run the business operations of the registry. Zodiac Holdings Limited (“Zodiac”) was founded and incorporated in Cayman Islands by James Seng in 2008 in anticipation of the launch of the ICANN new gTLD program. Currently, it is headquartered in Hong Kong and has an operation center in Beijing, China. The team consists of experienced veterans in the global and China domain name industry like James Seng and former China Network Information Center (CNNIC) employees such as Eugene Li.
James Seng is one of the Internet pioneers in Singapore and is widely recognized as an international expert in numerous Internet areas. He is well known as the inventor of IDN and has co-chaired the IDN Working Group in IETF from 1999 to 2004, leading to the standardization of IDN.
Eugene Li, is the former Vice President of China Network Information Center (CNNIC). During his 7 years tenure at CNNIC, Eugene has launched initiatives that doubled domain name registrations and helped CNNIC become the no. 1 ccTLD and no. 2 TLD by volume. At the time when Eugene left to join Zodiac, CNNIC has over 13 million domain name registrations.
With respect to the technical operations of the registry, the Applicant has chosen to partner with CNNIC (“Back-End Service Provider”). CNNIC is a trusted third party provider of registry of domain name services which has operated “.CN” ccTLD for over 15 years. In addition, CNNIC is also a trusted partner for IDN services as it has successfully operated ʺ中国ʺ Chinese IDN ccTLD since 2010 and developed standards of Chinese IDN like RFC 3743, RFC 4713, which have been recognized by the industry.
Together, the Applicant can realize its vision and bring to the market, Chinese IDN domain name services via CNNIC’s technological innovation, proven channel management expertise and delivery of the world’s most advanced domain name registry services.
For this application, the Applicant is applying for the IDN gTLD “.广东”, pronounced as “guangdong”. To make it easier for non-Chinese reader, “广东” will be referred to as “STRING” in the remaining part of this application.
The Applicant’s vision for “.STRING” is to be a flag bearer of IDN geographic city gTLDs in China’s Internet space. Because of the special conditions governing geographical TLDs application under ICANN, and China (province and country level approval required), the introduction of “.STRING” will be heavily supported and valued by the China government.
Because of Guangdong’s name, “.STRING” becomes a term that easily sticks in the minds of the Chinese Internet user. To the citizens of the Guangdong province, “.STRING” becomes a string that they can associate and associate with. To the many private enterprises in the region, “.STRING” helps to create a name space that the enterprises and their customers can collaborate in. To the multinationals with branch offices situated across the various cities in the region, “.STRING” also helps to provide a geographical identity.
One of “.STRING” objectives is to make it easier for the Chinese Internet population to access and use the Internet. Today, as fewer and fewer premium domain names are available, companies and individuals have to come up with longer and less intuitive domain names in “.com” or other related TLDs. To the Chinese, where English is a second language, remembering long domain names is very tedious.
Furthermore, there are many methods to type Chinese characters today. An IDN gTLD will make it easier for the Chinese Internet population to not have to switch input methods when typing the full domain name.
On a global scale, the introduction of “.STRING” geographic gTLD allows any Chinese Internet user (not just limited to China) to have an online identity that he can bear with pride. It also helps to promote Chinese culture to the rest of the non-Chinese Internet population.
In the latest data released by CNNIC, at the end of 2011, there are about 1.4 million domain names attributed to the Guangdong region. This is the initial target audience for the “.STRING” where the emergence of the IDN domain names will become a mainstream way for the Chinese users to input and use. Guangdong government also released data that there were about 1 million small and medium enterprises and about 3.38 million sole proprietors as of the end of 2011. These businesses are the potential extended market audience for “.STRING” when it is introduced.
The Applicant expects “.STRING” to initially reach about 20,047 in the 1st year, and grow to 28,639 and 40,094 by the 2nd and 3rd year respectively.
The projection is based on a conservative estimate taking the following into consideration:
* total number of domain names registered in China across all TLDs
* proportion of total number of domain names registered in China that are in Chinese
* ICANN benchmarking of registry operations, Feb. 2010
* price point for “.STRING” and how the China market would react based on the team’s experience in China
* initial growth of existing gTLDs in China
The pricing for “.STRING” is intentionally set at a price relative to the IDN ccTLD of China (.中国) because the Applicant believes that “.STRING” has intrinsic value by virtue of its geographical significance compared to other gTLDs.
The Applicant will have Sunrise process prior to opening the general registration to ensure that the relevant rights owners have their first rights to their names. Landrush period will also be introduced to cater for the ardent aspirant registrants. The Applicant will also adopt the Trademark Clearing House to reduce cybersquatting and other intellectual property rights infringements. Furthermore, the Applicant will have additional protection for geographic names. Details are described in the answers to Question 22, 28 and 29.

The applied-for TLD—“.STRING” is a geographic name, it refers to the Guangdong Province of China. As a geographic gTLD, the Applicant intends to bring the following benefits to the registrants, Internet users and others.

First of all, the applied-for TLD will serve as a specialized and dedicated space on the Internet for Guangdong people and Guangdong businesses. The applied-for TLD may help to reinforce the visibility of Guangdong by putting it firmly on the online map and becoming the ʺofficialʺ Internet resource for citizens and visitors. It will become a high-profile virtual space to discuss ideas, conduct transactions, support diverse ethnic and cultural groups, and enable citizens to interact with civic departments, public officials, and elected representatives.

On the service levels, the applied-for TLD will strive to enhanced security and trust. As the steward of the Applied-for TLD, the city government will have the authority to set registration requirements for the domain names. By restricting registration of these names to vetted, legitimate registrants the stewards of Geographic gTLDs may help improve trust and confidence.

Technically, the Applicant has selected CNNIC as the back-end service provider for its business and technical expertise in the Chinese domain name registry industry. The CNNIC Back-End Registry Service Platform is designed, implemented and operated to provide high availability, secure, robust and scalable registry services. The Registry Service Platform shall fully conform to, and exceed the Registry Performance Specifications (Specification 10 of the gTLD Registry Agreement). Please refer to answer to Question 30 for more details of the technical specifications.

On the reputation, a trusted location established through the development of appropriate policy will construct a trusted and secured space for Guangdong province. With the endorsement by the Central and provincial government, this space will provide with a safe, secure and authoritative namespace for citizens and local business to operate and access information. This long term asset will also develop and evolve in line with community requirements.

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

First of all, The Applied-for TLD, the “.STRING” will be used as a dedicated space for Guangdong province. This virtual space will help to reinforce the visibility of Guangdong province by putting it on the online map and becoming the ʺofficialʺ Internet resource for citizens and visitors. Anyone who visits the domain name with the “.STRING” will be aware of the distinct characteristics of the TLD with other gTLD domain names.

The “.STRING” TLD will be used as a platform on the Internet to foster innovation and creation. Guangdong has long been famous for its international trading ever since 1840s. And with the launch and operation of the TLD, the business can be conducted via this dedicated space and more innovated use of the TLD or the Internet could be conceived to boost current communication and business model.

In terms of competition, the “.STRING” TLD does not pursue to compete with other generic TLDs as its main mission and purpose is to meet the demand of local people. However, considering the addition of the “.STRING” TLD will be used to serve local community, the demand of other generic TLDs will be facing a pressure to lower the price and to enhance the service to gain the attraction.

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

Intuitive and Precise:
Since it is a Chinese TLD, A “.STRING” domain name is intuitive for Chinese Internet users. And since it is a new gTLD, registrant can choose a precise and elegant domain name to demonstrate the message to others, be it a brand, a product or a service. Internet users can easily capture the meaning and intention of the domain name and hence can correctly relate the domain name with corresponding Internet services, which will greatly facilitate the adoption and utilization of the domain name and boost communications online.

Location based Services:
More importantly, the “.STRING” TLD will be used to promote location based services in Guangdong province due to its attribution as a geographic name. Services and products that are linked to the location can be easily remembered and used. In addition to that, with the introduction of the TLD, more ingenious location based services could be implemented with the combination with the TLD.

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

Registrant Eligibility Requirement

Prospective registrant of “.STRING” domain names will be required to demonstrate a local presence in the STRING area.

String Policy

Valid IDN characters are able to register at the sub-level. Please refer to answer to Question 15 for the applicable IDN characters in the IDN table. More registration requirements on IDNs please refer to the answer to Question 44.

In addition, ASCII characters can also be registered as a sub-level Domain name. allowed ASCII characters are the English-language letters A through Z, the digits 0 through 9 and hyphens (LDH -- Letters, Digits, Hyphens).

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

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

WHOIS Policy

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

The Applicant shall abide with any relevant ICANN Whois Policy.

Others

* Right Protection Mechanisms, such as Sunrise and Landrush process, Trademark PDDRP, PPDRP, URS and UDRP as described in the answer to Question 29
* Anti-abuse mechanisms, such as abuse prevention mechanism and abuse mitigation mechanisms as described in the answer to Question 28
* Geographic name restriction as described in answer to Question 22
* Domain Name Lifecycle as describe in answer to Question 27
* Data Privacy as describe in Question 18(c) below
* Reserved and Blacklist label as describe in the answer to Question 22 and 29

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

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

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

In general, 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 back-end 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.

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

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

During the application, the Applicant will reach out to the registrars located in China and Guangdong Province to seek their support. Additionally, the Applicant will also seek out other domain name registrars and resellers to participate in the “.STRING” marketing.

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

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

Following the “.STRING” sunrise, the Applicant shall organize a Landrush ceremony, inviting partners (e.g. registrars) as well as media representatives to promote the awareness among potential registrants. The Applicant will also begin the extensive marketing, including online and offline advertising. The Landrush marketing effort will also last another 60 days.

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

23. Registry Services

The registry services complying with the requirements of ICANN, which are provided by the Back-End Service Provider for ʺ.STRINGʺ TLD mainly include Shared Registration System (SRS), Domain Name Service (DNS), Whois, Internationalized Domain Name (IDN) and DNS Security Extensions (DNSSEC). With full consideration having been given to specific problems related to security and stability, all the above services are customary registry services which meet corresponding Request for Comments (RFC) standards, so there will be no security and stability problems.

The applicant selects the Back-End Service Provider to be the provider of technology and operation services for ʺ.STRINGʺ registry. Through the self-deployed ʺBack-End Registry Service Platformʺ, the Back-End Service Provider provides the entrusted services for ʺ.STRINGʺ TLD. ʺBack-End Registry Service Platformʺ is deployed and operated by CNNIC to support services for all new gTLD registries who have the entrusted requirements such as ʺ.STRINGʺ. The platform is designed to support at least 2 million domain names. ʺBack-End Registry Service Platformʺ that is deployed, maintained and operated by the technicians from the Back-End Service Provider, provides registry with all information systems required for five critical functions (including resources such as IDC, software, hardware and bandwidth etc.).

The technology platform concerning ʺ.STRINGʺ registry services is consigned by the applicant to a third party—the Back-End Service Provider which will provide the platform and be in charge of its regular technical operation and maintenance management; the applicant will designate specialists to carry out technical coordination, supervise the work of the Back-End Service Provider, manage the keys concerning the above service, and authorize CNNIC to be responsible for the key administration and use of keys associated with the above services.

The Back-End Service Provider has set up information security management system (ISMS) for ccTLD and Chinese domain names in compliant with ISO27001. ISMS is viewed to be suitable for the information security management work for ʺ.STRINGʺ to provide sound security strategies and security guarantees for ʺ.STRINGʺ registry services in the aspects of physical equipment, network, system, application, data and audit. Please refer to the answer to Question 30 for more information.
23.1 SRS

23.1.1 Service Description

SRS performs the following functions：
(1) Receiving Registration Data Related to Domain Names and Name Servers from the Registrar
To support the registry-registrar separation mode adopted by ʺ.STRINGʺ; and to receive relevant registration data submitted to the applicant by registrars by providing registrars with data interfaces that meet the requirements of RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734.
(2) Management Functions Related to Registration Data:
To be specific, these functions include management of sessions, asynchronous messages, contacts, hosts, domain names, reserved name lists, registrars and status of the registry; performing automate⁄timed tasks; generating operation logs; performing financial operations, registration verifications; as well as bulk registration data access.
(3) Providing Interactive Interfaces for Other Related Services

(a) Providing with interfaces for DNS service to read registration data to enable it to generate the ʺ.STRINGʺ zone file.

(b) Providing with interfaces for Whois service to read registration data to enable it to respond to queries about registration information of ʺ.STRINGʺ.

(c) Providing with interfaces for the data escrow system to read registration data to enable it to process registration data into deposit files on a regular basis and submit them to the escrow agent.

(d) Providing with interfaces for the monitoring system to enable it to monitor the SRS in a real-time manner.
(e) Providing with the function of access to bulk data for ICANN in accordance with Specification 4 of the Registry Agreement.

(f) Connecting SRS to the Trade Mark Clearing House to search information of trade mark owners and decide whether to approve the registration application for a specific domain name based on the search result.

(g) Analyzing SRS log through monitoring system to provide data report function to generate monthly report required by ICANN.

23.1.2 Security Analysis

SRS adopts the following security mechanisms to ensure that there will be no unauthorized disclosure, alteration, insertion or destruction of registry data related to ʺ.STRINGʺ.
23.1.2.1 Physical Security Policy

7*24 operation and maintenance team monitors SRS in a real-time manner through the monitoring system. Host machine is placed in the lightening-proof, fire proof anti-theft and anti-static machine room with the video monitoring system. Fingerprint identification and access card reading devices are adopted to control the visit.
23.1.2.2 Network Security Policy

SRS adopts redundant system design. Each server adopts the Intranet IP address defined in RFC 1918, which is deployed in the service network. SRS registration database adopts Intranet IP addresses to prevent Internet users from accessing these servers.
23.1.2.3 System Security Policy

SRS system host periodically updates the operation system and application system. Remote operation to the system needs to be performed through bastion servers. Monitoring system monitors the use of host resources and service operations in a real-time manner, and once an abnormity is detected, gives off an alarm.
23.1.2.4 Application Security Policy
Application Security Strategy involves the following aspects:

(1) The login password of each registrar in the SRS is limited to 6-32 digits and the password is stored in an encrypted form.

(2) SRS connection between registrar and registry shall adopt SSL encryption mode. Each registrar is further required to adopt a different key.

(3) SRS restricts the login IP address of the registrar and only authorized IP addresses can be connected. Certificate of registrar will be verified the effectiveness.

(4) Connection will be automatically closed by the SRS if there is no operation within a specified period of time after the registrar successfully logs in.

(5) Bulk registration data access function is open to ICANN, whom we consult with the security mechanism and adopt measures such as IP restriction and security of data transmission.

23.1.2.5 Data Security Policy

(1) SRS related registration data is stored in registration database, read and write access of which is strictly restricted. DNS service, Whois service and data escrow system only has read access to SRS registration database.

(2) SRS registration database will be stored in local tape library for backup. Meanwhile data is also backed up into the local and remote secondary operation centers.

23.1.2.6 Auditing Security Policy

All operation records of SRS will be logged, and then analyzed and audited by the monitoring system.

23.1.3 Stability Analysis

(1) Analysis of Compliance with Relevant Standards

The implementation of SRS strictly complies with RFC 5730, RFC 5731, RFC 5732, RFC 5733, RFC 5734 and RFC 5910. In addition, the registration life cycle supported by SRS is in line with RFC 3915.
Considering the characteristics of IDN and ʺ.STRINGʺ’s nature of business, the applicant and the Back-End Service Provider made the following two extensions on the basis of EPP in accordance with the guidance of RFC 3735.
(a) Completely compliant with RFC 3735, made the extension of RFC 5731. In details, submitted the associated draft to make extension of the variants of Chinese domain names in support of bundle registration of variants.

(b) Completely compliant with RFC 3735, made the extension of RFC 5910. In details, submitted the associated draft to make extension of DNSSEC in support of the DS bulk registration for variants of Chinese domain names.

(2) Analysis of the Impact of SRS on Related Internet Servers or End Systems

(a) Impact on the Other Systems of ʺ.STRINGʺ Registry Services

By adopting a redundant backup architecture (refer to the answer to Question 24), SRS guarantees its stability and reliability to meet the requirements of DNS service, Whois service, the monitoring system, bulk registration data access and the data escrow system for accessing SRS registration database.
(b) Impact on the Registrar’s Registration System of ʺ.STRINGʺ

SRS service fully satisfies SLR prescribed in Specification 10 of the Registry Agreement to ensure that the registrar of ʺ.STRINGʺ can normally submit registration data.
23.2 DNS Service

23.2.1 Service Description

DNS service mainly includes management of DNS zone files and resolution of DNS.
(1) DNS Zone File Management Performs the Following Functions:

(a) Generation of TLD zone files of ʺ.STRINGʺ

The authoritative master servers of DNS obtain the original resource records from the SRS registration database to generate original zone files and provide them to DNS service after the files are signed through DNSSEC.
(b) Update of TLD zone files of ʺ.STRINGʺ

The zone files are updated in a level-by-level manner between the authoritative master servers of DNS and the name servers at all levels, which enables these name servers to obtain the latest TLD zone files of ʺ.STRINGʺ within the time limit specified in the SLA.
(c) Access to TLD zone files of ʺ.STRINGʺ

Access by authorized third-party organizations or Internet users to TLD zone files of ʺ.STRINGʺ is made available.
(2) DNS Resolution Performs the Following Functions:

To provide resolution service for the domain name of ʺ.STRINGʺ, a TLD solution service platform is established whose name servers are distributed among multiple geographic locations and which supports IPv6 and DNSSEC by adopting Anycast and Unicast.
23.2.2 Security Analysis

DNS adopts the following security mechanisms to ensure that there will be no unauthorized disclosure, alteration, insertion or destruction of resolution data related to ʺ.STRINGʺ.
23.2.2.1 Physical Security Policy

DNS is deployed in a service subnet. Specialized DOS⁄DDOS defense instrument is adopted to detect intrusion with Intrusion detection system (IDS). When suspicious Internet attack is detected, competent security specialists will be notified to handle the problem. ACL is configured in the egress router for controlling access to DNS name servers. Only DNS service ports and relevant management ports are opened; other service ports are closed.
23.2.2.3 System Security Policy

DNS system host periodically updates the operation system and application system. Remote operation to the system needs to be performed through bastion servers. Monitoring system monitors the use of host resources and service operations in a real-time manner, and once an abnormity is detected, gives off an alarm.
23.2.2.4 Application Security Policy

Application Security Strategy involves the following aspects:
(1) Setting up DNS primary masters which are not connected to the Internet and do not provide resolution service to ensure the security of original zone files of ʺ.STRINGʺ.

(2) The update of zone files between different levels of name servers is accomplished through IPsec encrypted communication, to ensure secure transmission of TLD zone files of ʺ.STRINGʺ.

(3) Establishing a monitoring system to ensure the integrity and consistency of data in zone file generation and transmission.

(4) Authenticating the identification of Internet users who attempt to access TLD zone files of ʺ.STRINGʺ and reject accessing these files who failed authentication or violate the terms and conditions on data use (refer to 2.1.5 of Specification 4, Registry Agreement).

23.2.2.5 Data Security Policy

Periodically backup zonefile and check the integrity of updated zonefile through technical means. Data is backed up into the local tape library periodically as well as into the local and remote secondary data center.

23.2.2.6 Audit Security Report

Monitoring system will collect and analyze DNS server log, and provide auditing reports.

23.2.3 Stability Analysis

(1) Analysis of compliance with relevant standards

DNS adopts the stable versions of BIND and NSD, two mainstream DNS software systems, and relevant security patches are timely updated.
The design and deployment of DNS meet relevant RFC provisions (including RFC 1034, RFC 1035, RFC 1982, RFC 2181, RFC 2182, RFC 2671, RFC 3226, RFC 3596, RFC 3597, RFC 3901, RFC 4343, RFC 4472 and RFC 5966) and the technical requirements of IANA.
(2) Analysis of the impact of DNS on related Internet servers or end systems. The stability and reliability of DNS service are guaranteed through the adoption of a redundant backup architecture design(refer to the answer to Question 35) so that relevant SLR in Specification 10 of the Registry Agreement is fully satisfied and Internet users are able to resolve domain names of ʺ.STRINGʺ normally.

23.3 Whois Service

23.3.1 Service Description

Whois service performs the following functions:

(1) Providing Services in Response to Queries about Domain Registration Information

Whois service gives response to queries about the information of registrars, hosts and domain names. Through Whois system (WhoisD and Whois Web), Internet users can know whether a domain name has been registered and its detailed information.
(2) Providing an Authorized Third Party with the Function of Bulk Access

Whois service provides authorized third parties with the function of bulk access, allowing bulk access to Whois data in a specific period of time.
(3) Providing Searchable Whois Service

Using a domain name, contacts and registrant’s name, postal address, registrar ID, name server name and name server’s IP address as key words, an authorized Internet user can perform searches based on a random combination of the key words through the AND⁄OR⁄NOT Boolean function.
23.3.2 Security Analysis

Whois service adopts the following security mechanisms to ensure that there will be no unauthorized disclosure, alteration, insertion or destruction of registry data related to ʺ.STRINGʺ.
23.3.2.1 Physical Security Policy

Whois system is deployed in service subnet. Access of WhoisD system is open via Port 43 while access of Whois Web is open via Port 80.
23.3.2.3 System Security Policy

Whois system host periodically updates the operation system and application system. Remote operation to the system needs to be performed through bastion servers. Monitoring system monitors the use of host resources and service operations in a real-time manner, and once an abnormity is detected, gives off an alarm.
23.3.2.4 Application Security Policy

Application Security Policy mainly involves the following points:
(1) Whois Web servers are only used to transform Whois Web requests into WhoisD query requests and transmit such requests to WhoisD servers through load balancers. Then WhoisD servers are connected to Whois database to complete the response to Whois queries.

(2) For searchable Whois service, abuses of Whois information are prevented by adopting user access control and other preventive measures.

(3) Whois only permits Internet users’ queries and no alteration is permitted.

23.3.2.5 Data Security Policy

Whois database is created by replicating SRS registration database, and therefore, no operation of the Whois database will affect the core registration data of ʺ.STRINGʺ.

23.3.2.6 Audit Security Report

Monitoring system will collect and analyze DNS server log, and provide and issue auditing report.

23.3.3 Stability Analysis

(1) Analysis of Compliance with Relevant Standards

Strictly conforming to the Whois protocol in the RFC 3912, the Whois system uses TCP on port 43 for the communication between the client and Whois servers and, in strict accordance with RFC 3912 Protocol Model, uses ASCII CR and ASCII LF as the message separator.
(2) Analysis of Impact on Relevant Internet Servers and End Systems

By adopting a redundant backup architecture design (refer to the answer to Question 26), Whois guarantees its stability and reliability so that relevant SLR in Specification 10 of the Registry Agreement is fully satisfied.
The following restrictive measures are taken to further guarantee the availability and quality of Whois service.
(a) To restrict the number of online users (configurable) of Whois service;

(b) If the user does not make any query within a specified time limit (configurable), the connection will be automatically terminated;

(c) To prevent a user from over-frequently making queries, thus delaying the response to the queries of others, the frequency (configurable) of a user to access Whois data is restricted;

(d) The Whois database for Whois bulk access is created by replicating the SRS registration database, so Whois bulk access will not affect the stability of routine Whois service;

(e) Whois database for searchable Whois service is created by replicating the SRS registration database, so searchable Whois service will not affect the stability of routine Whois service.

23.4 Internationalized Domain Names (IDN)

23.4.1 Service Description

IDN service includes:
(1) Developing, releasing and maintaining Chinese IDN tables corresponding to ʺ.STRINGʺ.

(2) Formulating corresponding policies for registration of variants according to the characteristics of IDN variants.

(3) Extending relevant service systems of ʺ.STRINGʺ registry to support IDN.

(a) Shared Registration System (SRS)

SRS implements the registration extension of Chinese domain name variants based on EPP in accordance with RFC 3735 so that it supports the bundle registration of variants.
(b) DNS service

Following RFC 3743 and RFC 4713, the DNS service is capable of resolving domain names in the form of traditional, simplified and variant Chinese.
(c) Whois Service

Whois service of ʺ.STRINGʺ adopts the UTF-8 encoding format and supports both English and Chinese display of response information as well as display of activated variant Chinese domain names.
(d) DNSSEC

SRS implements DNSSEC extension of Chinese domain name variants based on EPP in accordance with RFC 3735 to support DS bulk registration of variants.
23.4.2 Security Analysis

To address the problem of phishing due to similarity of internationalized domain names, an IDN anti-phishing detection system provided by the Back-End Service Provider is adopted, through which phishing domain names related to ʺ.STRINGʺ can be detected and then corresponding measures can be taken.
To address the problem of cybersquatting related to ʺ.STRINGʺ variant domain names, the applicant, in accordance with RFC 4713, has worked out policies for coping with variant domain names. When a registrant registers its original ʺ.STRINGʺ domain name for the first time, the applicant gives it full simplified and full traditional Chinese domain names on a free-of-charge basis and reserve all the variant domain names for the registrant. Registrants with special needs can activate all the variants to prevent others from cybersquatting.
23.4.3 Stability Analysis

(1) Analysis of Compliance with Relevant Standards

The Chinese IDN tables adopted by ʺ.STRINGʺ will be submitted to IANA in a standard format.
The registry services related to ʺ.STRINGʺ fully satisfy IDNA standards formulated by IETF, such as RFC 3743, RFC 4713, RFC 5890, RFC 5891, RFC 5892, RFC 5893 and RFC 5894, and are in strict accordance with IDN guidelines by ICANN.
(2) Analysis of Impact on Relevant Internet Servers and End Systems

(a) Shared Registration System (SRS)

The problem of variants of Chinese domain names may lead to occupation of more SRS resources, thus affecting the stability of SRS. To avoid such problems, ʺ.STRINGʺ extended the registration of traditional, simplified and variant Chinese domain names based on EPP in accordance with RFC 3735, to support bundle registration of variant Chinese domain names and to enable the domains in the same bundle to have the same registration attributes. As a result, the impact of the problem of variant Chinese domain names on the stability of SRS is reduced.
(b) DNS service

In designing the capacity and performance of the DNS service system, full consideration was given to the expansion of zone files of ʺ.STRINGʺ TLD due to the existence of variant Chinese domain names. Servers with sufficient memory are used to avoid the impact of such expansion on the stability of DNS service.
(c) Whois Service

Whois data is kept consistent with SRS registration data, so IDN will not affect the stability of Whois service.
(d) DNSSEC

In designing the deployment of DNSSEC, full consideration was given to the expansion of zone files of ʺ.STRINGʺ TLD due to the existence of variant Chinese domain names. DNSSEC zone files are signed through hardware security Module (HSM) to avoid the impact of such expansion on the stability of DNSSEC.
23.5 Domain Name System Security Extensions (DNSSEC)

23.5.1 Service Description

The main purpose of DNSSEC service is to provide source verification for DNS data obtained by recursive servers so as to ensure that data are from the right authoritative servers and that no alteration is made to the data.
DNSSEC includes the following:
(1) Shared Registration System (SRS)

(a) According to RFC 5910, the extension of SRS supports DNSSEC registration.

(b) SRS implements DNSSEC extension of Chinese domain name variants based on EPP in accordance with RFC 3735 to support DS bulk registration of variants.

(2) DNS service

(a) Management of key generation and update of ʺ.STRINGʺ TLD.

(b) Signing zone files of ʺ.STRINGʺ TLD.

(3) Whois Service

In compliance with Specification 4 of the Registry Agreement, the query results of Whois service contain information about whether zone files have been duly signed through DNSSEC.
(4) Policies

Formulating, releasing and maintaining DNSSEC Practice Statements (DPS) for implementing DNSSEC of ʺ.STRINGʺ TLD.

23.5.2 Security Analysis

The following security mechanisms are adopted for DNSSEC implementation to ensure that there will be no unauthorized disclosure, alteration, insertion or destruction of registry data related to ʺ.STRINGʺ.
23.5.2.1 Physical security policy

The HSM used for KSK signing is installed in a locked electro-magnetic shielding cabinet which can effectively prevent the interference of electro-magnetic signals from the outside. Furthermore, both the HSM and the cabinet are placed in a separate room with access control measures and only authorized persons may get access to the cabinet.
23.5.2.2 Network Security Policy

HSM is deployed in the sole subnet. Only specific server can access it to prevent Internet users from accessing these servers.
23.5.2.3 System Security Policy

Monitoring system is adopted to monitor operation situation of monitored devices in a real-time manner. When equipment is put out of use or eliminated, a demagnetizer would be used to delete all information so that no important information is leaked.
23.5.2.4 Application Security Policy

As one of the important measures for overcoming the security defects in the DNS system, DNSSEC uses public-key cryptography to add digital signatures to each RRset in zone files to further improve the security level of the DNS.
The security of DNSSEC depends on the proper management of the keys. Keys of ʺ.STRINGʺ TLD are divided into KSK and ZSK. KSK is only used to sign ZSK. All signature operations are completed in the HSM. ZSK is used to sign zone files and key rollovers should be finished within ZSK’s security life cycle.
NSEC3 is adopted in DNSSEC to avoid traverse of zone files of ʺ.STRINGʺ TLD.
23.5.2.5 Data Security Policy

All pairs of key (ZSK and KSK) are generated and directly saved in HSM. Private key is prohibited to access and read in any plain text, but is admitted to store and back up in an encrypted form in external storage media.
23.5.2.6 Audit Security Report

Monitoring system will collect resolution system file and log file of HSM, and present an auditing report after analyzing and auditing them.
23.5.3 Stability Analysis

(1) Analysis of Compliance with Relevant Standards

The design and deployment of DNSSEC of ʺ.STRINGʺ meet all relevant RFC standards including RFC 4034, RFC 4035, RFC 5901, RFC 4641, RFC 5074 and RFC 5155, and follow the best practices described in RFC 4641 and its successors.
(2) Analysis of Impact on Relevant Internet Servers and End Systems

(a) Shared Registration System (SRS)

As far as SRS service is concerned, the implementation of DNSSEC only requires that SRS support the registration of DS records; therefore, the stability of SRS will not be affected.
(b) DNS service

In deploying the DNS service system of ʺ.STRINGʺ, full consideration has been given to the increase of load brought about by DNSSEC. By testing and analyzing the performance of DNSSEC, the hardware configuration of DNS servers has been improved and the network bandwidth has been increased (refer to the answer to Question 35), to ensure that the deployment of DNSSEC will not have any impact on DNS service of ʺ.STRINGʺ.
(c) Whois Service

So far as Whois is concerned, the implementation of DNSSEC only requires that the query results of Whois service contain information about whether zone files have been duly signed through DNSSEC. So, the implementation of DNSSEC will not have any impact on the performance of Whois service.

24. SRS
The Applicant provides a Shared Registration System (SRS) that meet the requirements of Section 1.2, Specification 6 of the Registry Agreement to ʺ.STRINGʺ TLD. The SRS supports the registry-registrar seperation model adopted by ʺ.STRINGʺ and, by providing the registrar with an Extensible Provisioning Protocol (EPP) based data interface, enables the registrar to submit ʺ.STRINGʺ-related registration data to the Applicant.
The SRS of ʺ.STRINGʺ meets EPP1.0 data interface specifications defined by RFC 5730, and manages the database by using Oracle so that the reliability and stability of data storage and data access are guaranteed and registration operations can be accomplished properly and efficiently. At the same time, by adopting real-time monitoring and redundant system design and by taking such measures as 7*24 on-site operation and maintenance, SRS ensures the proper and reliable operations of SRS under the precondition of meeting SLR of Specification 10 of the Registry Agreement.
The Applicant selects the Back-End Service Provider to be the provider of technology and operation services for ʺ.STRINGʺ registry.
All human resources, funds and equipment necessary for implementing and maintaining SRS have been put in place by the applicant and the Back-End Service Provider seperately.
24.1 Implementation of SRS
24.1.1 An Overview of SRS
The SRS of ʺ.STRINGʺ consists of two parts: the core registration system and the Business Operation Support System (BOSS).
24.1.2 System Interfaces
SRS is connected to EPPClient, DNS service, the data escrow system, Whois service, the monitoring system and the TMCH. The interfaces between SRS and the above-mentioned systems are shown as follows.
Please see Figure 1 in the attachment of Q24_Attachment_Figure.
24.1.2.1 The Interface between SRS and EPPClient
Via an EPP1.0-compliant interface between EPPclient and SRS,ʺ.STRINGʺ provides registration services for registrars. In line with RFC 5734, the above interface is achieved based on Secure Sockets Layer (SSL) and TCP⁄IP. The functions of the interface include establishment of sessions, domain names, hosts and contacts with the registry of ʺ.STRINGʺ TLD (see the figure below).
Please see Figure 2 in the attachment of Q24_Attachment_Figure.
24.1.2.2 The Interface between SRS and DNS Service
The data needed for generating or updating zone files in DNS service comes from SRS registration database, as shown below.
Please see Figure 3 in the attachment of Q24_Attachment_Figure.
DNS service supports Authoritative Zone Transfer (AXFR) and Incremental Zone Transfer (IXFR).
The interface between AXFR and SRS is shown as follows:
Please see Figure 4 in the attachment of Q24_Attachment_Figure.
The interface between IXFR and SRS is shown as follows:
Please see Figure 5 in the attachment of Q24_Attachment_Figure.
24.1.2.3 The Interface between SRS and Data Escrow System
Data escrow system accesses the registration database via the interface, processes registration data, in accordance with Specification 2 of the Registry Agreement, and regularly upload them to the data escrow agent.
24.1.2.4 The Interface between SRS and Whois System
Whois system replicates the SRS registration database as Whois database and provides Internet users with Whois service. Whois system mainly uses the following 4 tables in the registration database.
Please see Figure 6 in the attachment of Q24_Attachment_Figure.
24.1.2.5 The Interface between SRS and the Monitoring System
There are three interfaces between SRS and the monitoring system. One is between EPPServer and the monitoring system; the other is between the registration database and the monitoring system; the third one is between BOSS and monitoring system.
24.1.2.6 The Interface between SRS and TMCH
BOSS is connected to TMCH, inquires about information of trade mark owners and decides whether to approve a specific domain name registration application according to the inquiry results.
24.1.3 Functions of SRS
The functions of SRS are divided into core registration function and business operation supporting function.
24.1.3.1 Core Registration Function
(1) Session Management
In accordance with RFC 5730, SRS implements commands of login, logout, hello and greeting. SRS supports the SSL-based connection with registrars over IPv6. Each registrar uses a different certificate.
(2) Asynchronous Message Management
After sending the poll command, SRS processes all pending actions and information related to the business auditing of ʺ.STRINGʺ.
(3) Management of Contacts
In accordance with RFC 5733, SRS implements commands of check, info, transfer, create, delete and update about contacts. Accredited registrars have the full authority to perform all the above commands about the contact of their domain names.
(4) Management of Hosts
In accordance with RFC 5732, SRS implements commands of check, info, create, delete and update about hosts.
(a) SRS supports management of IPv6 hosts.
(b) All accredited registrars have the full authority to perform all the above commands about hosts.
(5) Management of Domain Names
According to RFC 5731, SRS implements all commands for domain management, including check, info, create, delete, renew, transfer and update.
In accordance with RFC 3735, ʺ.STRINGʺ achieves EPP extension for traditional, simplified and variant Chinese domain names to support bundle registration of variant Chinese domain names. Moreover, EPP extension for DNSSEC is also implemented to support bulk registration of DS records. Refer to the answer to Question 25.
According to the definitions in RFC 3915 and RFC 5731, SRS saves and maintains the status of EPP and RGP.
(6) Operation Logs
SRS records, in the form of operation logs, all business operations performed by the registrar without any impact on SRS performance. The rollback file size and the number of backup files are preset for the log file of each registrar. Operation log will be pushed to the backup system periodically, please refer to the answer of Question 37. The monitoring system extracts the log for the use of data required by real-time business usability and monthly report.
(7) Automatic⁄Timed Tasks
SRS supports the following automatic⁄timed tasks:
(a) According to lifecycle requirements, SRS supports auto-renew function.
(b) SRS automatically permits transfer operations that exceed 5 days.
(c) In accordance with lifecycle requirements, SRS supports the function of automatically deleting expired domain names.
(d) When grace period expires, domain name status will be deleted automatically.
24.1.3.2 Business Operation Supporting Function
(1) Financial and Verification Function
The core registration system records operations about registration fees without settling the account. The BOSS financial module performs settlement of accounts according to the price offered by the registrar and informs the core registration system of the financial status of each registrar.
(2) Management of Reserved Name Lists
Boss provides the function of managing reserved name lists and maintains the reserved domain names and words in the registration database. Domain names and words that appear in the list are not permitted to register.
(3) Management of Registry Status
Due to specific reasons (legal arbitration for example), BOSS provides the function of creating or deleting Server status for the domain names, hosts and contacts stored in the registration database. Relevant operations must be approved before they are carried out.
(4) Management of Registrars
BOSS can insert, delete and update the information of registrars stored in the registration database, as well as allocate and manage registrar connections.
(5) Automatic⁄Timed Tasks
(a) In accordance with lifecycle requirements, BOSS supports the function of automatically updating the status of domain names and contacts.
(b) BOSS calculates registrarsʹ expenses on a daily basis.
(c) BOSS daily backs up the log into backup system.
(6) Bulk Registration Data Access
BOSS provides the function of bulk registration data access.
(a) Periodic Access to Light Registration Data
The Applicant entrusts the Back-End Service Provider to submit to ICANN, on a weekly basis, the up-to-date registration data, which include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
In line with the requirement of Specification 2 on data contents, the Back-End Service Provider provides the following data for all registered domain names. The data files will be compressed and encrypted to be available for download via SFTP.
(b) Exceptional Access to Heavy Registration Data
BOSS is capable of submitting to ICANN domain-related data by registrars in accordance with the requirement of Specification 2 on format. In case of registrar failure, de-accreditation, court order, etc, that prompts the temporary or definitive transfer of its domain names to another registrar, the Back-End Service Provider may submit to ICANN all the registered domain information of the losing registrar. The files containing the information are made available for download by SFTP.
(7) Sending a Query to TMCH
BOSS is connected to TMCH, inquireing about information of trade mark owners and decides whether to approve a specific domain name registration application according to the inquiry results. Some related functions will be improved according to the regulations of the global TMCH.
(8) Monthly Report Function
BOSS generates the monthly report compliant with Specification 3. The monitoring system collects the log of SRS system to analyze the data of the log to generate data required by Pre-Registrar Transactions Monthly Report and Registry Functions Activity Report. BOSS generates monthly reports and submits them periodically.
24.1.4 System Deployment
Please see Figure 7 in the attachment of Q24_Attachment_Figure.
(1) Internet Access
SRS service addresses broadcast SRS service addresses via Border Gateway Protocol (BGP). A registrar may access SRS service through a number of Internet Service Providers (ISPs).
(2) Load Balancer
Registrars access the virtual IP configured in the layer 4 load balancers to perform registration operations.
(3) SRS Servers
SRS servers are responsible for core registration and BOSS functions.
The core registration system and BOSS consist of 4 high-performance blade servers respectively. In addition, the core registration system and BOSS are equipped with a cold standby server respectively.
(4) Registration Database
The registration database is used to store registration data and respond to the access requests of the core registration system, BOSS, Whois, DNS service, data escrow and the access request for ICANN bulk registration data.
(5) BOSS Database
The BOSS database is used to store financial and verification data.
(6) Storage
The data in the registration database is stored in a storage device.
24.2 A Plan for Operating Robust and Reliable SRS
24.2.1 Redundant System Design
To improve reliability, a redundant design is adopted for designing the SRS architecture including network devices, load balancers, registration servers and registration databases, so as to ensure there is no single point of failure. In addition, cold-standby servers are always ready to take over the work of other servers.
Furthermore, both local and remote secondary operation centers adopt the same SRS deployment, to ensure that a swift switch over can be made when the primary operation center fails. Please refer to the answer to Question 37.
24.2.2 Registration Data Synchronization
A storage device is connected to the registration database to store registration data. The replication between the primary operation center and the local secondary operation center are through optic fibers and uses synchronous replication to ensure data consistency. The storage devices of the primary operation center and the remote secondary operation center use asynchronous replication with a synchronization frequency of once every minute. For details, please refer to the answer to the Question 37.
24.2.3 Failure Monitoring and Handling
The monitoring system monitors the operations of SRS and the database. ʺ.STRINGʺ will be equiped with a special 7*24 team for system operation and maintenance, who monitors the SRS on 7*24 basis in a real-time manner. Once a problem is detected, the monitoring system will lose no time to give off an alarm and notify the 7*24 maintenance team to shoot and remove the trouble. Please refer to the answers to Questions 39 and 42 for information about the classification of and response to SRS failures.
24.3 Compliance Analysis
24.3.1 Compliance with Specification 6
(1) In accordance with RFC 5910, RFC 5730-5734, provisioning and management of domain names are achieved by using the EPP
ʺ.STRINGʺ achieves the extension of EPP for DNSSEC by extending RFC 5910. DS or DNSKEY records can be added to a designated domain name when it is updated and created, and relevant DS or DNSKEY data are contained in the response message of info command.
SRS fully meets the requirements of RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734. Refer to the answer to Question 25 for more details.
(2) Full compliance with the Registry Grace Period specified in RFC 3915
SRS strictly complies with the Registry Grace Period specified in RFC 3915. The RGP status of domain names is stored in the SRS registration database.
(3) Extension is made and the draft is submitted in accordance with RFC 3735
RFC 5731 has been extended in accordance with RFC 3735.
RFC 5910 has been extended in accordance with RFC 3735, which means the extension of DNSSEC, to support the bulk registration of DS and DNSKEY records.
Refer to the answer to Question 25.
24.3.2 Compliance with Specification 10
SRS service level requirements are specified in Specification 10 as follows:
Please see Table 1 in the attachment of Q24_Attachment_Table.
(1) Service Availability
It is estimated that based on 16 million registration volume, the ordinary peak Transactions Per Minute (TPM) is less than 15,000 (8,000 TPM for 95% cases), while it is less than 20,000 in the situation of cybersquatting (16,000 TPM for 95% cases). The Back-End Service Provider has tested single SRS server for 3*24 hours of which average TPM may reach 30,696.
(2) Session-command RTT
As shown in the following table for SRS testing for data volume of tens of millions, average Round-Trip Time (RTT) of each type of command is in compliance with Specification 10.
Please see Table 2 in the attachment of Q24_Attachment_Table.
(3) Query-command RTT
As shown in the following table for SRS testing for data volume of tens of millions, average RTT of EPP〈check〉 command is 9.06ms, and 16ms for 95% of this command.
Please see Table 3 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈info〉 command among query commands of ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 4 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈poll〉 command among query commands of ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 5 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈transfer〉 query command among query commands for ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 6 in the attachment of Q24_Attachment_Table.
(4) Transform-command RTT
System testing results of EPP〈create〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 7 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈delete〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 8 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈renew〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 9 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈transfer〉 command among transform commands are illustrated as below; as we can see, we respectively tested RTT for request, cancel, approve, reject commands as the ‘op’ value, which is compliant with Specification 10.
Please see Table 10 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈update〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 11 in the attachment of Q24_Attachment_Table.
24.4 Resource Allocation
24.4.1 Human Resources
To fulfill the service commitments concerning SRS of ʺ.STRINGʺ, the human resources provided by ʺ.STRINGʺ are as follows:
ʺ.STRINGʺ TLD registry adopts the human resources, which equips with 6 software engineers who are responsible for software optimization and maintenance, and 6 system administrators who are responsible for 7*24 monitoring. The Applicant will designate 2 technical personnel to communicate the technological issues of SRS with the Back-End Service Provider, and monitor the work of the Back-End Service Provider. Refer to the answer to Question 31.
24.4.2 Software and Hardware
ʺ.STRINGʺ registry adopts the software and hardware recources that are for ʺBack-End Registry Service Platformʺ use. Hardware and software resources deployed are as following:
Hardware in the 3 operation centers includes 30 high-performance blade servers, 12 high-performance database servers and 3 high-level storage devices.
Software includes SRS, database, database cluster and storage management software. The number of lines of effective codes of the SRS software is 60,816 with C++ output ratio of 1.19 (thousand code lines man-months). The number of lines of effective codes of the BOSS is 107,881 (java) with java output ratio of 2.18 (thousand code lines man-months). The total workload will be 101 man-months. So far development and testing of the software have been completed and the system is now in trial operation.
In addition, customization scope of SRS software covers core registration system and BOSS which supports financial and auditing, searching the trade mark clearing house (TMCH) and monthly report function, as well as the interface with EPPClient, DNS service, data escrow system, Whois system, monitoring system and TMCH; meanwhile it satisfies the SLA requirements. Software customization development is carried out according to the initiation of R&D, program plan, outline design, specific design, construction stage, trail stage and issue and summarization procedures. Development procedure is compliant with regulations of Level 3 of Capability Maturity Model Integration (CMMI3).
Refer to the answer to Question 32 for more details about the software and hardware.
24.4.3 Funds
To fulfill the service commitments on SRS of ʺ.STRINGʺ, the funds of human resources and outsourcing funds for technical platform of the Applicant have been put in place.Refer to the answer to Question 46 for the sources and uses of these funds. Funds for human resources, equipment procurement and maintenance of the Back-End Service Provider, the Applicantʹs entrusted party of technology and operation, have been put in place.

25. Extensible Provisioning Protocol (EPP)

The applicant provides the ʺ.STRINGʺ TLD with a business interface that meets the requirements of ICANN. This interface complies with RFC 3735, RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734 and has extended simplified, traditional and variant Chinese domain names, and DNS Security Extensions (DNSSEC function) in accordance with RFC 3735. Relevant drafts have also been submitted. 

The Back-End Service Provider to be the provider of technology and operation services for ʺ.STRINGʺ registry. Through the self-deployed ʺBack-End Registry Service Platformʺ, the Back-End Service Provider provides the entrusted services for ʺ.STRINGʺ TLD. 

ʺBack-End Registry Service Platformʺ is deployed and operated by the Back-End Service Provider to support services for all new gTLD registries who have the entrusted requirements such as ʺ.STRINGʺ. The platform is designed to support at least 2 million domain names. ʺBack-End Registry Service Platformʺ that is deployed, maintained and operated by the technicians from the Back-End Service Provider, provides registry with all information systems required for five critical functions (including resources such as IDC, software, hardware and bandwidth etc.).

The applicant will designate specialists to carry out technical coordination, and supervise the work of the Back-End Service Provider. By far, all human resources, funds and equipment necessary for implementing and maintaining  have been put in place by the applicant and the Back-End Service Provider respectively.

25.1 Business Interface Between the Back-End Service Provider and Registrars

Based on Extensible Provisioning Protocol (EPP), ʺ.STRINGʺ provides registrars with a business interface for managing sessions, domain names, hosts, contacts and asynchronous messages. Via the above business interface, a registrar can perform not only complete business operation functions but also their own business workflow.
　　
All the EPP commands given by ʺ.STRINGʺ for registrars are listed in the following table.
　　
Please see Table 1 and Table 2 in the attachment of Q25_Attachment_Table.
　　
All the above commands for the registration and management of domain names, hosts and contacts meet the requirements of EPP. According to RFC 3735 and the business demand of ʺ.STRINGʺ, the applicant and the Back-End Service Provider have jointly agreed to extend the parameters of some of the above commands.
　　
25.2 Compliance with RFC

25.2.1 Compliance with RFC 5730

In accordance with the requirements of RFC 5730, ʺ.STRINGʺ has realized session login, logout and hello commands, etc., as well as poll command for asynchronous message reception and confirmation. Meanwhile, the formal syntax of EPP, result code, date format and international support satisfy RFC 5730.  
　　
25.2.2 Compliance with RFC 5731

In accordance with the requirements of RFC 5731, the business interface provide by ʺ.STRINGʺ to the registrar  has supported commands including check, info, create, delete, renew, transfer and update for domain names. 
　　
25.2.3 Compliance with RFC 5732

In accordance with the requirements of RFC 5732, the business interface provide by ʺ.STRINGʺ to the registrar has implemented commands including check, info, create, delete and update for hosts. The host of a particular domain name will be automatically transferred as the domain name is transferred. The IP of the host may be either IPv4 or IPv6.　
　
25.2.4 Compliance with RFC 5733

In accordance with the requirements of RFC 5733, the business interface provide by ʺ.STRINGʺ to the registrar has supported commands including check, info, create, delete, renew, transfer and update for contacts.  
　　
25.2.5 Compliance with RFC 5734

In accordance with RFC 5734,  the business interface provide by ʺ.STRINGʺ to the registrar has supported EPP mapping and deployed the SSL protocol, both of which are based on TCP. The EPP message format, the TCP connection session, the communication sequence of the client and the server, as well as the monitoring port meet the requirement of RFC 5734.
　　
25.3 Proprietary EPP Extension

Due to the uniqueness of ʺ.STRINGʺʹs business, the applicant and the Back-End Service Provider have jointly agreed to realize some function extensions beyond the standard EPP. These extensions, which meet the requirement of RFC 3735 on extension of functions, are implemented based on the command-response mode. To be specific, these extensions include the extension of traditional, simplified and variant Chinese domain names, and DNSSEC function extensions. 
　　
25.3.1 Extension of Traditional, Simplified and Variant Chinese Domain Names

25.3.1.1 Overview

According to the characteristics of Chinese domain names, the applicant has formulated for ʺ.STRINGʺ relevant policies for variant registration (refer to the answer to Question 44). To facilitate the implementation of these policies, the applicant and the Back-End Service Provider, in accordance with RFC 3735, have agreed to extend EPP for traditional, simplified and variant Chinese domain names, facilitating bundle registration of variant Chinese domain names.
　　
25.3.1.2 Explanation of Extensions

In accordance with the business requirements of ʺ.STRINGʺ, the response messages for the commands about the domain names mentioned in RFC 5731, including info, transfer, delete and renew as well as the commands and response messages of update and create in the EPP have been extended.  Chinese characters in use have at least two forms, traditional and simplified Chinese characters. Therefore, in creating a domain name, a full traditional and a full simplified domain name will be generated according to the one the registrar submits to the applicant and will be stored in the database. Afterwards, users are allowed to activate other variant forms of domain names. 
　　
When executing the info command, ʺ.STRINGʺ feed the traditional, simplified and variant Chinese domain names and the corresponding A-Label record back to the client. 
　　
After the command is extended, the feedback message is as follows:
　　
  S:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
  S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
  S:  〈response〉
  S:    〈result code=ʺ1000ʺ〉
  S:      〈msg〉Command completed successfully〈⁄msg〉
  S:    〈⁄result〉
  S:    〈resData〉
  S:      〈domain:infData
  S:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
  S:        〈domain:name〉ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
  S:        〈domain:roid〉58812678-domain〈⁄domain:roid〉
  S:        〈domain:status s=ʺokʺ⁄〉
  S:        〈domain:registrant〉123〈⁄domain:registrant〉
  S:        〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
  S:        〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
  S:        〈domain:ns〉
  S:          〈domain:hostObj〉ns1.example.cn〈⁄domain:hostObj〉
  S:        〈⁄domain:ns〉
  S:        〈domain:clID〉ClientX〈⁄domain:clID〉
  S:        〈domain:crID〉ClientY〈⁄domain:crID〉
  S:        〈domain:crDate〉2011-04-03T22:00:00.0Z〈⁄domain:crDate〉
  S:        〈domain:exDate〉2012-04-03T22:00:00.0Z〈⁄domain:exDate〉
  S:        〈domain:authInfo〉
  S:          〈domain:pw〉2fooBAR〈⁄domain:pw〉
  S:        〈⁄domain:authInfo〉
  S:      〈⁄domain:infData〉
  S:    〈⁄resData〉
  S:    〈extension〉
  S:      〈cdn:infData xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ〉
  S:        〈cdn:OCDNPunycode〉 xn--fsq270a.xn--xhq521b〈⁄domain:name〉
  S:        〈cdn:SCDN〉ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
  S:        〈cdn:SCDNPunycode〉 xn--fsq270a.xn--xhq521b〈⁄domain:name〉
  S:        〈cdn:TCDN〉ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
  S:        〈cdn:TCDNPunycode〉 xn--fsqz41a.xn--xhq521b〈⁄domain:name〉
  S:        〈cdn:VCDNList〉
  S:              〈cdn:VCDN〉ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:VCDN〉
  S:              〈cdn:VCDNPunycode〉 xn--fsqz41a.xn--xhq521b
  S:              〈⁄cdn:VCDNPunycode〉
  S:        〈⁄cdn:VCDNList〉
  S:      〈⁄cdn:infData〉
  S:    〈⁄extension〉
  S:    〈trID〉
  S:      〈clTRID〉ABC-12345〈⁄clTRID〉
  S:      〈svTRID〉54322-XYZ〈⁄svTRID〉
  S:    〈⁄trID〉
  S:  〈⁄response〉
  S:〈⁄epp〉

The fed-back message for transfer, delete and renew include the content of the operated domain names:  
　　
   S:    〈extension〉
   S:      〈cdn:xxxData
   S:       xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ〉
   S:        〈cdn:SCDN〉
   S:         ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:SCDN〉
   S:        〈cdn:TCDN〉
   S:         ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:TCDN〉
   S:        〈cdn:VCDNList〉
   S:              〈cdn:VCDN〉
   S:       ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:VCDN〉
   S:        〈⁄cdn:VCDNList〉
   S:      〈⁄cdn:XXXData〉
   S:    〈⁄extension〉

When a domain name is being created, registrants are allowed to submit a variant domain name:
　　
   C:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
   C:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
   C:  〈command〉
   C:    〈create〉
   C:      〈domain:create
   C:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
   C:        〈domain:name〉
   C:         ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
   C:        〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉
   C:        〈domain:registrant〉123〈⁄domain:registrant〉
   C:        〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
   C:        〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
   C:        〈domain:authInfo〉
   C:          〈domain:pw〉2fooBAR〈⁄domain:pw〉
   C:        〈⁄domain:authInfo〉
   C:      〈⁄domain:create〉
   C:    〈⁄create〉
   C:    〈extension:
   C:      〈cdn:create
   C:       xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ〉
   C:        〈cdn:VCDNList〉
   C:             〈cdn:VCDN〉
   C:          ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:VCDN〉
   C:        〈⁄cdn:VCDNList〉
   C:      〈⁄cdn:create〉
   C:    〈⁄extension〉
   C:    〈clTRID〉ABC-12345〈⁄clTRID〉
   C:  〈⁄command〉
   C:〈⁄epp〉

Registrants are permitted to add or remove a variant domain name when executing the update command:
　　
  C:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
  C:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
  C:  〈command〉
  C:    〈update〉
  C:      〈domain:update
  C:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
  C:        〈domain:name〉 ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
  C:        〈domain:add〉
  C:          〈domain:ns〉
  C:            〈domain:hostObj〉ns2.example.cn〈⁄domain:hostObj〉
  C:          〈⁄domain:ns〉
  C:          〈domain:contact type=ʺtechʺ〉234〈⁄domain:contact〉
  C:          〈domain:status s=ʺclientHoldʺ
  C:           lang=ʺenʺ〉Payment overdue.〈⁄domain:status〉
  C:        〈⁄domain:add〉
  C:        〈domain:rem〉
  C:          〈domain:ns〉
  C:            〈domain:hostObj〉ns1.example.cn〈⁄domain:hostObj〉
  C:          〈⁄domain:ns〉
  C:          〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
  C:          〈domain:status s=ʺclientUpdateProhibitedʺ⁄〉
  C:        〈⁄domain:rem〉
  C:        〈domain:chg〉
  C:          〈domain:registrant〉234〈⁄domain:registrant〉
  C:          〈domain:authInfo〉
  C:            〈domain:pw〉2BARfoo〈⁄domain:pw〉
  C:          〈⁄domain:authInfo〉
  C:        〈⁄domain:chg〉
  C:      〈⁄domain:update〉
  C:    〈⁄update〉
  C:    〈extension〉
  C:      〈cdn:update
  C:       xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ〉
  C:         〈cdn:add〉
  C:           〈cdn:VCDN〉
  C:            ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:VCDN〉
  C:         〈⁄cdn:add〉
  C:         〈cdn:rem〉
  C:           〈cdn:VCDN〉
  C:            ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄cdn:VCDN〉
  C:         〈⁄cdn:rem〉
  C:      〈⁄cdn:update〉
  C:    〈⁄extension〉
  C:    〈clTRID〉ABC-12345〈⁄clTRID〉
  C:  〈⁄command〉
  C:〈⁄epp〉

For details, please refer to the link: http:⁄⁄tools.ietf.org⁄html⁄draft-kong-epp-cdn-mapping-00.

25.3.2 DNSSEC Extension

25.3.2.1 Overview

According to the registration polices for Chinese domain names, the registrant will obtain a full traditional, a full simplified and related variant Chinese domain names when applying for domain name registration.  To allow the registrant to apply for DS records for multiple variant Chinese domain names, the applicant and the Back-End Service Provider, in accordance with RFC 3735, have jointly agreed to implement EPP extension for DNSSEC to support bulk registration of DS records.
　　
25.3.2.2 Explanation of Extensions 

In accordance with the business requirements of ʺ.STRINGʺ,  the RFC 5910 in the EPP has been extended. DS records can be added to a designated domain name when it is created and updated, and relevant DS data are contained in the response message of info command. 
　　
Create message：
　　
   C:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
   C:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
   C:  〈command〉
   C:    〈create〉
   C:      〈domain:create
   C:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
   C:        〈domain:name〉
   C:          ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
   C:        〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉
   C:        〈domain:registrant〉123〈⁄domain:registrant〉
   C:        〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
   C:        〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
   C:        〈domain:authInfo〉
   C:          〈domain:pw〉2fooBAR〈⁄domain:pw〉
   C:        〈⁄domain:authInfo〉
   C:      〈⁄domain:create〉
   C:    〈⁄create〉
   C:    〈extension〉
   C:      〈secCDNC:create
   C:       xmlnC:secCDNS=ʺurn:ietf:paramC:xml:nC:secCDNS-1.0ʺ〉
   C:           〈secCDNS:maxSigLife〉604800〈⁄secCDNS:maxSigLife〉
   C:        〈secCDNC:DS〉
   C:             〈secCDNS:CDN〉
   C:            ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄secCDNS:CDN〉
   C:          〈secCDNC:dsData〉
   C:            〈secDNC:keyTag〉12345〈⁄secDNC:keyTag〉
   C:            〈secDNC:alg〉3〈⁄secDNC:alg〉
   C:            〈secDNC:digestType〉1〈⁄secDNC:digestType〉
   C:            〈secDNC:digest〉49FD46E6C4B45C55D4AC〈⁄secDNC:digest〉
   C:          〈⁄secCDNC:dsData〉
   C:        〈⁄secCDNC:DS〉
   C:      〈⁄secCDNC:create〉
   C:    〈⁄extension〉
   C:    〈trID〉
   C:      〈clTRID〉ABC-12345〈⁄clTRID〉
   C:      〈svTRID〉54322-XYZ〈⁄svTRID〉
   C:    〈⁄trID〉
   C:  〈⁄response〉
   C:〈⁄epp〉
   
or：
   
   C:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
   C:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
   C:  〈command〉
   C:    〈create〉
   C:      〈domain:create
   C:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
   C:        〈domain:name〉
   C:          ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
   C:        〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉
   C:        〈domain:registrant〉123〈⁄domain:registrant〉
   C:        〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
   C:        〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
   C:        〈domain:authInfo〉
   C:          〈domain:pw〉2fooBAR〈⁄domain:pw〉
   C:        〈⁄domain:authInfo〉
   C:      〈⁄domain:create〉
   C:    〈⁄create〉
   C:    〈extension〉
   C:      〈secCDNC:create
   C:       xmlnC:secCDNS=ʺurn:ietf:paramC:xml:nC:secCDNS-1.0ʺ〉
   C:           〈secCDNS:maxSigLife〉604800〈⁄secCDNS:maxSigLife〉
   C:        〈secCDNC:KEY type=ʺallʺ〉
   C:          〈secCDNC:keyData〉
   C:            〈secDNC:flags 〉257〈⁄secDNC:flags〉
   C:            〈secDNC:protocol〉3〈⁄secDNC:protocol〉
   C:            〈secDNC:alg〉1〈⁄secDNC:alg〉
   C:            〈secDNC:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNC:pubKey〉
   C:          〈⁄secCDNC:keyData〉
   C:        〈⁄secCDNC:KEY〉
   C:      〈⁄secCDNC:create〉
   C:    〈⁄extension〉
   C:    〈trID〉
   C:      〈clTRID〉ABC-12345〈⁄clTRID〉
   C:      〈svTRID〉54322-XYZ〈⁄svTRID〉
   C:    〈⁄trID〉
   C:  〈⁄response〉
   C:〈⁄epp〉
   
Update message：
　　
   C:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
   C:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
   C:     xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ〉
   C:  〈command〉
   C:    〈update〉
   C:      〈domain:update
   C:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
   C:        〈domain:name〉 ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
   C:      〈⁄domain:update〉
   C:    〈⁄update〉
   C:    〈extension〉
   C:      〈secCDNS:update
   C:       xmlns:secCDNS=ʺurn:ietf:params:xml:ns:secCDNS-1.0ʺ〉
   C:        〈secCDNS:rem〉
   C:          〈secCDNS:DS〉
   C:            〈secCDNS:SCDN〉xn--fsq270a.xn--xhq521b〈⁄secCDNS:SCDN〉
   C:            〈secCDNS:dsData〉
   C:              〈secCDNS:keyTag〉12345〈⁄secCDNS:keyTag〉
   C:              〈secCDNS:alg〉3〈⁄secCDNS:alg〉
   C:              〈secCDNS:digestType〉1〈⁄secCDNS:digestType〉
   C:              〈secCDNS:digest〉38EC35D5B3A34B33C99B〈⁄secCDNS:digest〉
   C:            〈⁄secCDNS:dsData〉
   C:          〈secCDNS:DS〉
   C:        〈⁄secCDNS:rem〉
   C:        〈secCDNS:add〉
   C:          〈secCDNS:DS〉
   C:            〈secCDNS:SCDN〉xn--fsq270a.xn--xhq521b〈⁄secCDNS:SCDN〉
   C:            〈secCDNS:dsData〉
   C:              〈secCDNS:keyTag〉34723〈⁄secCDNS:keyTag〉
   C:              〈secCDNS:alg〉3〈⁄secCDNS:alg〉
   C:              〈secCDNS:digestType〉1〈⁄secCDNS:digestType〉
   C:              〈secCDNS:digest〉FYUGCFIUACVH〈⁄secCDNS:digest〉
   C:            〈⁄secCDNS:dsData〉
   C:          〈secCDNS:DS〉
   C:        〈⁄secCDNS:add〉
   C:      〈⁄secCDNS:update〉
   C:    〈⁄extension〉
   C:    〈clTRID〉ABC-12345〈⁄clTRID〉
   C:  〈⁄command〉
   C:〈⁄epp〉

Info message：
　　
   C:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
   C:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
   C:  〈command〉
   C:    〈create〉
   C:      〈domain:create
   C:       xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
   C:        〈domain:name〉 ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄domain:name〉
   C:        〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉
   C:        〈domain:registrant〉123〈⁄domain:registrant〉
   C:        〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
   C:        〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
   C:        〈domain:authInfo〉
   C:          〈domain:pw〉2fooBAR〈⁄domain:pw〉
   C:        〈⁄domain:authInfo〉
   C:      〈⁄domain:create〉
   C:    〈⁄create〉
   C:    〈extension〉
   C:      〈secCDNC:create
   C:       xmlnC:secCDNS=ʺurn:ietf:paramC:xml:nC:secCDNS-1.0ʺ〉
   C:        〈secCDNC:DS〉
   C:	       〈secCDNC:SCDN〉ʺU+5B9EʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄secCDNC:domain〉
   C:          〈secCDNC:dsData〉
   C:            〈secCDNC:keyTag〉12345〈⁄secCDNC:keyTag〉
   C:            〈secCDNC:alg〉3〈⁄secCDNC:alg〉
   C:            〈secCDNC:digestType〉1〈⁄secCDNC:digestType〉
   C:            〈secCDNC:digest〉49FD46E6C4B45C55D4AC〈⁄secCDNC:digest〉
   C:          〈⁄secCDNC:dsData〉
   C:        〈⁄secCDNC:DS〉
   C:        〈secCDNC:DS〉
   C:	       〈secCDNC:TCDN〉ʺU+5BE6ʺʺU+4F8Bʺ.ʺU+5E7FʺʺU+4E1Cʺ〈⁄secCDNC:domain〉
   C:          〈secCDNC:dsData〉
   C:            〈secCDNC:keyTag〉2765〈⁄secCDNC:keyTag〉
   C:            〈secCDNC:alg〉3〈⁄secCDNC:alg〉
   C:            〈secCDNC:digestType〉1〈⁄secCDNC:digestType〉
   C:            〈secCDNC:digest〉ABCTFAGFHKLOGI34〈⁄secCDNC:digest〉
   C:          〈⁄secCDNC:dsData〉
   C:          〈secCDNC:dsData〉
   C:            〈secCDNC:keyTag〉23789〈⁄secCDNC:keyTag〉
   C:            〈secCDNC:alg〉3〈⁄secCDNC:alg〉
   C:            〈secCDNC:digestType〉1〈⁄secCDNC:digestType〉
   C:            〈secCDNC:digest〉VHGKAUGYAIUGUIAGU〈⁄secCDNC:digest〉
   C:          〈⁄secCDNC:dsData〉
   C:        〈⁄secCDNC:DS〉
   C:      〈⁄secCDNC:infData〉
   C:    〈⁄extension〉
   C:    〈trID〉
   C:      〈clTRID〉ABC-12345〈⁄clTRID〉
   C:      〈svTRID〉54322-XYZ〈⁄svTRID〉
   C:    〈⁄trID〉
   C:  〈⁄response〉
   C:〈⁄epp〉

For details, please refer to the link: http:⁄⁄tools.ietf.org⁄html⁄draft-kong-epp-cdn-dnssec-mapping-00.

25.4 The EPP SCHEMA of Business Interface

The EPP Schema used by ʺ.STRINGʺ includes two parts; one is the EPP XML Schema defined by RFC and the other is the EPP XML Schema of customized extension.
　　
25.4.1 The EPP XML Schema Defined by RFC

	(1) urn:ietf:params:xml:ns:eppcom-1.0 (Refer to RFC 5730)

	(2) urn:ietf:params:xml:ns:epp-1.0 (Refer to RFC 5730)

	(3) urn:ietf:params:xml:ns:domain-1.0 (Refer to RFC 5731)

	(4) urn:ietf:params:xml:ns:host-1.0 (Refer to RFC 5732)

	(5) urn:ietf:params:xml:ns:contact-1.0 (Refer to RFC 5733)

	(6) urn:ietf:params:xml:ns:rgp-1.0 (Refer to RFC 3915)

25.4.2 The EPP XML Schema of Customized Extension

	(1) urn:ietf:params:xml:ns:cdn-1.0 (Refer to draft-kong-epp-cdn-mapping-00)

	(2) urn:ietf:params:xml:ns:secCDNS-1.0 (Refer to draft-kong-epp-cdn-dnssec-mapping-00)

25.5 Resource Allocation

25.5.1 Human Resources

To fulfill the service commitments concerning EPP of ʺ.STRINGʺ, the human resources provided by ʺ.STRINGʺ are as follows: ʺ.STRINGʺ TLD registry adopts the human resources that are for ʺBack-End Registry Service Platformʺ use, which equips with 2 software engineers who are responsible for EPP consistency analysis and for extending EPP in accordance with RFC 3735. The applicant will designate 2 technical personnel to communicate technical issues with the Back-End Service Provider and supervise the work of the Back-End Service Provider. Refer to the answer to Question 31. 

25.5.2 Funds

To fulfill the service commitments concerning EPP of ʺ.STRINGʺ,  funds for human resources and outsourcing funds of technical platform of the applicant have been put in place. Refer to the answer to Question 46 for the sources and uses of these funds; Funds for human resources, equipment procurement and maintenance of the Back-End Service Provider, the applicantʹs entrusted party of technology  and operation, have been put in place.

26. Registration data directory services (Whois)

Based on RFC 3912, the applicant provides the ʺ.STRINGʺ TLD with data objects, bulk access, lookups and searchable Registration data directory services (Whois) service which are defined in Specification 4 and which meet the Service Level Requirements (SLR) of Specification 10. Appropriate precaution measures have been taken to prevent abuse of Whois information.

26.1 Realization of Whois System

The Whois system is used to check the detailed information of registered domain names and whether a particular domain name has been registered. In addition, ʺ.STRINGʺ will support searchable Whois service which has a Web search function with domain names, registrant names, postal addresses, contact names, registrar IDs and Internet Protocol addresses as key words and which also supports the Boolean search function.
26.1.1 System Architecture

The architecture of the Whois system is illustrated as follows:
Please see Figure 1 in the attachment of Q26_Attachment_Figure.
Data in the Whois database is created by advanced replication of the Shared Registration System (SRS) registration database. The Whois system consists of the WhoisD system which is accessible by command lines via Port 43, and the Web-based Whois Web system. Whois Web requests are converted into WhoisD requests and the WhoisD system is connected to the Whois database to return query results to the user. The searchable Whois system provides searchable services by accessing Whois database index files. By advanced replication of the SRS registration database, a bulk access Whois database is generated which provides bulk access function for authorized registrars or third-party users.
26.1.2 System Functions

By default, the Whois system listens on TCP Port 43, receives and responds to query requests. The system provides WhoisD and Whois Web queries. In general, the Whois system receives 3 types of information queries, i.e., queries about domain names, registrars and name servers.
26.1.2.1 Queries about Domain Names

Registrars and registrants may send requests to the Whois system to query about a particular domain name. The Whois system will return the following information in accordance with Specification 4 of the Registry Agreement:
26.1.2.2 Queries about Registrars

Registrars and registrants may send requests to the Whois system whois ʺregistrar Example Registrar, Inc.ʺ to query about a particular registrar. The Whois system will return the following information in accordance with Specification 4 of the Registry Agreement:
(1) Information about the registrar, including name, street, city, state⁄province, postal cod, country, phone number, fax number and Email.

(2) Whois server and referral URL.

(3) Information about the admin contact, including phone number, fax number and Email.

(4) Information about the technical contact, including phone number, fax number and Email.

26.1.2.3 Queries on Name Servers

Registrars and registrants may send requests to the Whois system whois ʺNS1.EXAMPLE.TLDʺ or whois ʺnameserver (IP Address)ʺ to query about a particular name server. The Whois system will return the following information in accordance with Specification 4 of the Registry Agreement.

26.1.2.4 Internationalized Domain Name (IDN) Support

The Whois system supports two ways of domain name query, i.e., U-label and A-label, and adopts UTF-8 encoding format to enable the Whois system to display information in both English and Chinese. Furthermore, the Whois system also supports displays of U-label, A-label and variant domain names of the queried domain.
26.1.2.5 IP Black List

The Whois system supports the IP black list function. After connection with a user has been established, if the userʹs IP is found to be in the black list, then the Whois system will immediately terminate the connection.
26.1.2.6 Restriction on the Number of Online Users

Considering the load of the server and the response time of the Whois system, the number of online users is restricted. (The number is configurable.)
26.1.2.7 Connection Timeout

After a connection is established, if there is no immediate query, the resource of connection will be occupied and wasted. When there are a lot of such connections, the operation of other users will be hampered. Therefore, the Whois system has a timeout function. If a user does not perform any query operation within a specified time limit (configurable), the system will automatically terminate the connection.
26.1.2.8 Restrictions on the Interval of Query Time

For a user whose IP is not in the white list, their interval of query time (configurable) should be restricted to prevent highly frequent queries from hampering the response to other usersʹ queries. If the query time interval is shorter than the configured interval, the Whois system will return the message ʺQueried interval is too short.ʺ and terminate connection.
26.1.2.9 Searchable Whois Service and Prevention of Information Abuse

Searchable Whois service has the following functions:

(1) For domain names, contacts, registrantʹs name, contact and registrantʹs postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.), partial match capabilities are available.

(2) For registrar ID, name server name and name server IP address, exact match capabilities are available.

(3) Boolean search capabilities are available which meet the search criteria of AND ⁄OR⁄NOT for multiple fields.

(4) All query results contain domain name-related information, including domain name, domain ID, updated date, creation date, registry expiry date and domain name status, etc.

ʺ.STRINGʺ adopts the following measures to prevent information abuse:

(1) A registrar or registrant may only login the searchable Whois system using their own ID and password, and may only search information related to their own domain names.

(2) If a registrar, registrant or a third-party user wants to search othersʹ information, they need to explain the reasonable purposes, commit to protect privacy and security, and sign an agreement with the applicant at first.

26.1.2.10 Bulk Access

Whois service provides bulk access capabilities for authorized registrars and third-party users. To reduce the impact of bulk access on the load of core Whois database, the data related to the capabilities are provided by a separate Whois database for bulk access.
To guarantee the quality of bulk access service, the Whois system, by identifying the userʹs IP address, provides its service only for authorized registrars and third-party users.
26.1.3 System Deployment

Please see Figure 2 in the attachment of Q26_Attachment_Figure.

(1) Internet Access

(2) Load Balancer

(3) Whois Web Servers

(4) WhoisD Servers

(5) Searchable Whois Servers

(6) Bulk-access Whois Servers

(7) Searchable Whois Index Servers

(8) Whois Database

(9) Bulk-access Whois Database

The two database servers achieve dual-machine hot standby by adopting the VCS technology. Once a problem is detected on the working database, the standby database will immediately take over the service.
26.2 A Plan for Operating Robust and Reliable Whois

26.2.1 Redundant System Design

To improve reliability, redundant design is adopted for the Whois system including network devices, load balancers, Whois-related servers and databases, so as to ensure there is no single point of failure. In addition, cold-standby servers are provided which are always ready for deployment and service.
Furthermore, both local and remote secondary operation centers adopt the identical Whois system deployment, to ensure that a swift switch can be made when the primary operation center fails.
26.2.2 Whois Data Synchronization

Whois data are obtained by advanced replication of the SRS core registration database with a replication interval of 5 minutes. Bulk-access Whois data are obtained by advanced replication of the SRS core registration database with a replication interval of 5 minutes. Searchable Whois index data are obtained by generating searchable Whois index files through the Whois database, with an update interval of 5 minutes.
Whois-related databases of the local secondary operation center are created by replication of the SRS registration database thereof. Because the SRS core registration databases in the primary operation center and the local secondary operation center adopt synchronous replication, their Whois data are basically the same.
Whois-related databases of the remote secondary operation center are also created by replication of the SRS registration database thereof. Because the SRS core registration databases in the primary operation center and the remote secondary operation center adopt asynchronous replication, the Whois data of the latter slightly lag behind those of the former.
26.2.3 Failure Monitoring

ʺ.STRINGʺ adopts a monitoring system and a special 7*24 team for ʺ.STRINGʺsystem operation and maintenance that monitor the Whois system in a real-time manner. What are monitored include Whois-related CPU, hard disk, memory, service process and ports. Once any abnormity is detected in the Whois system, the monitoring system will promptly notify the system administrator.
26.2.4 Failure Handling

The above redundant system design and real-time monitoring effectively ensure the stable and reliable operation of the Whois system. Once a problem is detected, the 7*24 team will immediately notify the system administrator to handle it. If the problem is related to software, it will be removed by Whois system development and maintenance specialists. If it is related to hardware, standby load balancers, Whois-related servers or databases can be used to replace the failing equipment because of sufficient system redundancy. Furthermore, the Whois system of the local and remote secondary operation centers can also provide timely support.
26.3 Compliance Analysis

26.3.1 Compliance with RFC 3912

Strictly conforming to the Whois protocol defined in the RFC 3912, the applicant and the Back-End Service Provider have jointly agreed that the Whois system needs to achieve the function of communication between the client and Whois servers by using TCP connection on Port 43 and, in strict accordance with RFC 3912 Protocol Model, uses ASCII CR and ASCII LF to separate one message from another.
26.3.2 Compliance with Specification 4

(1) The format of Whois command response strictly complies with the format defined in Specification 4 of the Registry Agreement, followed by a blank line and a legal disclaimer.

(2) Each data object is represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
(3) Fields where more than one value exists are represented multiple key⁄value pairs with the same key.

(4) The format of response to queries about domain names, registrars and name servers meets Specification 4 of the Registry Agreement. It includes at least the display fields and formats as specified therein.

(5) The format of the following data fields: domain status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, Email addresses, date and time conform to the mappings specified in EPP RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734.

(6) Searchable Whois service is provided in accordance with Specification 4 of the Registry Agreement, and measures are taken to prevent abuse of Whois information.

26.3.3 Compliance with Specification 10

For Whois (Registration Data Directory Services, RDDS) service level, Specification 10 of the Registry Agreement sets forth the following requirements:
Please see Table 1 in the attachment of Q26_Attachment_Table.
(1) Availability
The Back-End Service Provider, the applicantʹs entrusted party of technology and operation, has tested the Whois system used by ʺ.STRINGʺ, and the results are as follows:
For a million-level aggregate registration volume (without index), 2136 transactions are successfully submitted per second. For a 10-million-level aggregate registration volume (with index), 2010 transactions are successfully submitted per second.

Under normal conditions, one server is capable of undertaking WhoisD service. Considering system redundancy, 4 servers and 1 cold-standby server should be provided and another 4 servers are enough to undertake Whois web service.

Whois bulk access is open only to authorized registrars and third-party users and 4 Whois bulk access servers are provided for this purpose.
In case registration volume increases sharply due to attacks, more back-end servers could be added under load balancers for extension.
So, the Whois system design adopted by ʺ.STRINGʺcan surely guarantee that the availability of Whois service can be kept above 98%.
(2) Query Round-Trip Time (RTT)

The average query RTT is 23.65ms. 95% of queries for WhoisD, Whois Web and Whois bulk access can be finished within 1000ms to meet Specification 10 of the Registry Agreement.
(3) Update Time

The update time of Whois database and Whois bulk access database is 5 minutes to meet Specification 10 of the Registry Agreement.
26.3.4 Laws and Policies on Privacy Protection that Searchable Services must Abide by

26.3.4.1 Registration-related Privacy

As prescribed in Article 4 of Rules on Technical Protective Measures for Internet Security of Peopleʹs Republic of China (Directive 82 of the Ministry of Public Security), ʺInternet service providers and Internet application organizations shall establish relevant management systems to ensure that no registration information will be disclosed or leaked without prior consent of the registrant unless otherwise specified by laws and regulations of the state. Internet service providers and users shall use technical protective measures for Internet security in accordance with the law. They shall not use such measures to infringe upon Internet end-usersʹ communication freedom and privacy. The public information network security supervision department of public security organs performs, in accordance with the law, the duty of supervising the implementation of technical protective measures for Internet security. All technical protective measures for Internet security shall meet relevant national standards. Where there is no applicable national standard, they shall meet relevant industrial technical standards on public security.ʺ

26.3.4.2 Query-related Privacy

As prescribed in Section 2, Article 18 of the Implementation Rules for the Provisional Regulations on Management of International Networking of Computer Information Networks of the Peopleʹs Republic of China, Internet users shall be subject to the management of Internet service providers (ISPs) and abide by their regulations; users shall not access any computer system without permission or alter the information of others; they shall not viciously spread information of others or spread any information in the name of another person via the network; and they shall not infringe upon other peopleʹs privacy.

As an entity established and registered in Peopleʹs Republic of China, the applicant must comply with Chinaʹs laws and regulations and policies. Therefore, the applicant will, in compliance with the above legal provisions, take the following measures to regulate usersʹ behavior in using Whois:
(1) The applicant provides searchable services for fuzzy and accurate queries about limited fields that meet the requirements of ICANN. For non-existing domain names, a negative response will be given and no suggestions on related domain names will be provided in any form.

(2) For typical searchable services, users need to pass username and password authentications before accessing the searchable Whois system and they can only make queries about their own information.

(3) Searchable services for all other types of information may be opened to some of the users who have passed authentication. Such users shall inform the applicant of the purpose of their queries and their contact information. If there is any violation of privacy, such as massively spreading other peopleʹs private information or sending large amounts of junk mail using Whois information, the applicant will mete out punishment on the infringer in accordance with relevant laws and regulations on privacy protection and if the case is serious enough, it will be reported to relevant judicial organs.

26.4 Resource Allocation

26.4.1 Human Resources

To fulfill the service commitments concerning Whois of ʺ.STRINGʺ, the human resources provided by ʺ.STRINGʺare as follows: ʺ.STRINGʺ TLD registry adopts the human resources that are for ʺBack-End Registry Service Platformʺ use, which equips with 4 software engineers who are responsible for software optimization and maintenance, 6 system administrators who are responsible for 7*24 monitoring of the Whois system; the applicant will designate 2 technical personnel to communicate and coordinate such technical issues with the Back-End Service Provider and supervise the work of the Back-End Service Provider. Refer to the answer to Question 31.
26.4.2 Software and Hardware

The Applicant adopts the software and hardware resources that are for ʺBack-End Registry Service Platformʺ use. Hardware and software resources deployed by the Back-End Service Provider are as following:

Hardware in the 3 operation centers includes 60 high-performance blade servers and 12 high-performance database servers.
Software includes Whois software, database software, database cluster software and storage management software. WhoisD has 5100 lines of effective codes and 1200 lines of codes related to the stored procedure of the database while 8,670 for searchable Whois and 6,690 for Whois Web. The total work load is 17 man-months. So far development and testing of the software have been completed and the system is now in trial operation.
In addition, customization scope of Whois system software covers Whois system based on Port 43 and Whois Web system, Whois bulk access function and searchable Whois function; meanwhile it satisfies the SLA requirements. Software customization development is carried out according to the initiation of R&D, program plan, outline design, specific design, construction stage, trial stage and issue and summarization procedures. Development procedure is compliant with regulations of Level 3 of Capability Maturity Model Integration (CMMI3).
Refer to the answer to Question 32 for more details about the software and hardware.
26.4.3 Funds

To fulfill the service commitments concerning Whois of ʺ.STRINGʺ, funds for human resources and outsourcing funds of and technical platform have been put in place.Refer to the answer to Question 46 for the sources and uses of these funds; Funds for human resources, equipment procurement and maintenance of the Back-End Service Provider, the applicantʹs entrusted party of technology and operation, have been put in place.

27. Registration Lifecycle

In accordance with the status of Redemption Grace Period (RGP) and Extensible Provisioning Protocol (EPP) defined in RFC 3915 and RFC 5731 and considering the characteristics of ʺ.STRINGʺ business, the applicant has defined the registration lifecycle and the procedure of status transfer for ʺ.STRINGʺ TLD.

ʺBack-End Registry Service Platformʺ is deployed and operated by the Back-End Service Provider to support services for all new gTLD registries who have the entrusted requirements such as ʺ.STRINGʺ. The platform is designed to support at least 2 million domain names. ʺBack-End Registry Service Platformʺ that is deployed, maintained and operated by the technicians from the Back-End Service Provider, provides registry with all information systems required for five critical functions (including resources such as IDC, software, hardware and bandwidth etc.).

The applicant will designate specialists to carry out technical coordination, and supervise the work of the Back-End Service Provider. Meanwhile they will be in duty to manage key associated with services described above and authorize the Back-End Service Provider to arrange personnel to manage use of the key. By far, all human resources, funds and equipment necessary for implementing and maintaining registration lifecycle have been put in place by the applicant and the Back-End Service Provider respectively.

27.1 Domain Name Registration Lifecycle

ʺ.STRINGʺ domain name registration lifecycle includes the following 9 main periods: verification period, add grace period, transfer restriction period, normal period, auto renew grace period, redemption grace period and pending delete period, transfer grace period and renew grace period.

Registration lifecycle is illustrated as follows:

Please see Figure 1 in the attachment of Q27_Attachment_Figure.

Each period of registration lifecycle is detailed in the following table:

Please see Table 1 in the attachment of Q27_Attachment_Table.

27.2 Registration Status and Change Procedures

27.2.1 Registration Status

According to RFC 3915, the registration lifecycle of ʺ.STRINGʺ includes the following 7 statuses of RGP:

(1) addPeriod

(2) autoRenewPeriod

(3) transferPeriod

(4) renewPeriod

(5) redemptionPeriod

(6) pendingDelete

(7) pendingRestore

According to RFC 5731, the EPP status includes the following 11 statuses:

(1) OK

(2) inactive

(3) pendingCreate

(4) pendingDelete

(5) pendingUpdate

(6) pendingTransfer

(7) serverHold

(8) serverTransferProhibited

(9) serverRenewProhibited

(10) serverUpdateProhibited

(11) serverDeleteProhibited
The above RGP and EPP statuses are set by the registry, in which serverTransferProhibited, serverRenewProhibited, serverUpdateProhibited and serverDeleteProhibited are set and managed by BOSS of the SRS system according to the specific needs. What are discussed here are only the statuses and change procedures set by the registry but do not involve the following 5 statuses set by the registrar: clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited and clientUpdateProhibited.
PendingRenew is not available in our SRS: the applicant judges whether renewal is successful according to the financial balance without wait.
Various registration statuses in the domain name registration lifecycle may be changed in accordance with certain standards. Change procedures are illustrated as follows: please see Figure 2 in the attachment of Q27_Attachment_Table.

27.2.2 Registration Status Change Procedures

27.2.2.1 Verification Period and Add Grace Period

After the registrar files an application to the applicant, the domain name enters into a 5-day verification and add grace period, during which update, renew, and delete operations can be performed by the registrar.

Listed in the following table are events that are likely to happen in the verification and add grace period as well as changes of EPP and RGP statuses resulting from such events.

Please see Table 2 in the attachment of Q27_Attachment_Table.

27.2.2.2 Transfer Restriction Period

There is an overlap of 5 days between the transfer restriction period and the verification and add grace period. During the transfer restriction period, transfer operations are prohibited while update, delete and renew operations are permitted.

Listed in the following table are events that are likely to happen in the transfer restriction period as well as changes of EPP and RGP statuses resulting from such events.

Please see Table 3 in the attachment of Q27_Attachment_Table.
27.2.2.3 Normal Period

The normal period starts from the 61st day after the registration date and ends on the expiry date, during which transfer, update, delete and renew operations are permitted.

Listed in the following table are events that are likely to happen in the normal period as well as changes of EPP and RGP statuses resulting from such events.

Please see Table 4 in the attachment of Q27_Attachment_Table.

27.2.2.4 Auto Renew Grace Period

When a domain name expires, it will enter into a 45-day auto renew period. If there is sufficient remaining deposit, there will be an automatic renewal of one more year, during which transfer, update, renew and delete operations are permitted.

Listed in the following table are events that are likely to happen in the auto renew grace period as well as changes of EPP and RGP statuses resulting from such events.

Please see Table 5 in the attachment of Q27_Attachment_Table.

27.2.2.5 Redemption Grace Period

Redemption grace period is 15 days, during which restore operations can be carried out to redeem a domain name.

Listed in the following table are events that are likely to happen in the redemption grace period as well as changes of EPP and RGP statuses resulting from such events.

Please see Table 6 in the attachment of Q27_Attachment_Table.

27.2.2.6 Pending Delete Period

The pending delete period is 5 days, during which all requests from the registrar for domain name operations will be rejected.

Listed in the following table are events that are likely to happen in the pending delete period as well as changes of EPP and RGP statuses resulting from such events.

Please see Table 7 in the attachment of Q27_Attachment_Table.

27.2.2.7 Change of Status Resulting from Abuse of a Domain Name or Fraudulent Activities

Within the transfer restriction period, the normal period or the auto renew grace period, if there is any abuse of domain names or any fraudulent activity, the serverHold status will be set for such domain names.

Please see Table 8 in the attachment of Q27_Attachment_Table.

27.3 Resource Allocation

27.3.1 Human Resources

To fulfill the service commitments concerning registration lifecycle of ʺ.STRINGʺ, the human resources provided by ʺ.STRINGʺ are as follows: ʺ.STRINGʺ TLD registry adopts the human resources that are for ʺBack-End Registry Service Platformʺ use, which equips with 2 software engineers who are responsible for the formulation and modification of registration lifecycle; the applicant will designate 2 technical personnel to communicate such technical issues with the Back-End Service Provider and supervise the work of the Back-End Service Provider. Refer to the answer to Question 31 for more details.

27.3.2 Funds

To fulfill the service commitments concerning registration lifecycle of ʺ.STRINGʺ, funds for human resources and outsourcing funds of technical platform of the applicant have been put in place.Refer to the answer to Question 46 for the sources and uses of these funds; Funds for human resources, equipment procurement and maintenance of the Back-End Service Provider, the applicantʹs entrusted party of technology and operation, have been put in place.

28 Abuse Prevention and Mitigation

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

28.1.1 Abuse Analysis

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

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

The RAPWG defines two types of domain name abuses:

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

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

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

28.1.2 Anti-abuse Policies

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

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

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

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

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

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

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

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

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

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

28.1.3 Point of Contact for Anti-abuse

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

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

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

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

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

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

28.2.1 Reserved lists

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

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

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

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

Release of reserved names

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

Release of reserved names for registry operation

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

Release of geographic names

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

28.2.2 Startup Abuse Prevention Mechanism

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

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

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

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

28.2.3 WHOIS accuracy Requirement

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

Compliance Requirement for the Registrants

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

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

Compliance Requirement for Registrars

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

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

1) Complete WHOIS information of the registrant;

2) Verified Email Address of the registrant.

3) A signed copy of the registration agreement.

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

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

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

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

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

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

Compliance Requirement for the Registry Service Provider

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

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

Compliance Requirement by the Applicant

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

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

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

28.2.4 Access Control

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

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

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

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

28.2.5 Policy on Orphan Glue Records

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

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

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

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

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

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

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

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

28.3.1 Registration abuse mitigation mechanism

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

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

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

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

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

28.3.2 Use abuse mitigation mechanism

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

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

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

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

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

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

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

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

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

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

28.3.3 Domain names dispute resolution mechanism

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

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

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

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

The Trademark PDDRP and RRDRP

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

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

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

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

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

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

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

Uniform Dispute Resolution Procedure

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

To invoke the policy, a trademark owner should either:

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

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

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

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

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

With ICANN

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

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

With LEAs and other security providers

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

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

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

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

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

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

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

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

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

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

29、Rights Protection Mechanisms:

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

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

Sunrise Service:

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

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

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

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

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

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

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

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

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

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

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

Landrush Service:

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

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

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

There are two types of bidding:

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

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

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

Trademark Claims Service:

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

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

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

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

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

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

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

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

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

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

The Trademark PDDRP and RRDRP

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

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

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

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

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

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

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

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

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

Uniform Dispute Resolution Procedure

To invoke the policy, a trademark owner should either:

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

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

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

29.5 Resourcing Plan

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

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

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

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

ʺ.STRINGʺ deploys exclusive database auditing system to audit with the database orders, bastion hosts system to audit the server management operation and in addition, the specified centralized log collection and auditing system (legendsec) to collect the logs of all network devices, servers and application system, uniformlly collecting and centralizing the logs to make the records.

 Auditors use the database auditing system, bastion hosts and log collection auditing system to audit at each level and produce corresponding reports on a regular basis. 

30(a).1.2 Management security policy

30(a).1.2.1 Security management organization

The applicant and the Back-End Service Provider  are jointly responsible for relevant security management and emergency response of ʺ.STRINGʺ registry services. the Back-End Service Provider has established a security management center. the applicant arranges special technical personnel as security contacts, who are responsible for coordinating the regular security affairs with the Back-End Service Providerʹs  security management center, as well as supervising the work of the Back-End Service Provider. 

The Back-End Service Provider, to strength its information security management system (ISMS), has also established, on, a ʺvirtualʺ information security management organization which consists of three tiers: the decision-making tier, the execution tier and the auditing tier.

30(a).1.2.2 Security management personnel

An investigation must be conducted on the background of the personnel responsible for security management related to ʺ.STRINGʺ registry services to make sure that they are reliable enough in terms of educational level, work experiences, credibility, etc. The investigation should be carried out by corresponding Personnel Department.  

30(a).1.2.3 Security management standards

 The applicant and the Back-End Service Provider will put the security management measures of the registry into place in accordance with the ccTLD provided by the Back-End Service Provider and the Information Security Management System (ISMS) of Chinese domain names.They consist of 4 tiers of documents: information security management manual; management specifications⁄measures⁄procedures⁄standards; implementation rules⁄operation guidelines⁄work guidance; and records⁄logs. See the figure below:

Please see Figure 1 in the attachment of Q30a_Attachment_Figure.

	(1) The information security management manual is the guiding document for ʺ.STRINGʺ information security management work. The manual contains such contents as information security policy, overall objective and control measures that are mentioned in the statement of applicability (SOA) and that have been implemented. Documents of the second and third tiers, such as management specifications and implementation rules can be regarded as documents supporting the information security management manual.

	(2) Management specifications, measures, procedures and standards clearly define various management systems and technical control measures. Documents of the second tier provide methods and guidance for implementation of the information security management system and for assignment of duties. Lower-tier documents should also be referred to in implementing ISMS. 

	(3) Implementation rules, operation guidelines and work guidance are documents that give a detailed description of the processes mentioned in the second-tier documents.  Consisting of work guidance, tables & lists, workflow charts, service standards and system manuals, documents of this tier give a detailed description of specific work and activities.

	(4) Records and logs are used to keep record of various activities, serving as evidence that these activities meet the requirements of upper-tier documents.  During the implementation of ISMS, a series of record tables and reports need to be kept to serve as the evidence that relevant preventive and corrective measures have been carried out.

30(a).2 Security Capability Assessment

30(a).2.1	Security assessment report

ʺ.STRINGʺ will put the security and safeguarding measures concerning the implementation of registry services into place in accordance with the ʺ.CNʺ ccTLD provided by the Back-End Service Provider and the Information Security Management System (ISMS) of Chinese domain names. The Back-End Service Provider-established ISMS was built in compliance with ISO 27001(GB⁄T 22080) security standards and was certified on March 9, 2011 by China Information Security Certification Center (ISCCC) accredited by China National Accreditation Service for Conformity Assessment (CNAS). With relevant ISCCC certificates, ISMS conforms to ISO 27001:2005 and the statement of applicability (SOA) thereof.

Please see Figure2 in the attachment of Q30a_Attachment_Figure.

30(a).2.2	Security capability test and assessment

ʺ.STRINGʺ carries out a security risk assessment at least once a year which covers classification and categorization of information assets; identification and assessment of risks; risk treatment plan and implementation thereof; continuous improvement of risk assessment, etc.  The assessment results will serve as the basis for ʺ.STRINGʺ to make decisions on overall risk management, assist the applicant in identifying overall risks  facing ʺ.STRINGʺ, and  formulate or adjust risk treatment measures and plans together with the Back-End Service Provider.

Meanwhile, ʺ.STRINGʺ invites a third-party security service organization to conduct security inspection and assessment every year, the result of which will be used as an important basis for carrying out security-related work.

30(a).3 Security Level Commitment                             

30(a).3.1	Introduction to Classified Protection Standard

ʺ.STRINGʺ registry services perform effective security management by adopting classified information security protection system. Relevant security level determination conforms to state classified protection standard, and the applicant promises to the public to achieve the security requirements of corresponding levels. 

According to the classified protection standard, information system is classified into five Classes from low to high depending on the importance to the state security, economic construction, social life, and the damage extent to the state security, social order, public interests, legal rights of citizen, legal person and other organs. ʺGB⁄T 22239-2008 Information Security Technology--Baseline for Classified Protection of Information System Securityʺ clarifies the security requirements which the information system of different levels shall achieve as below:

Class I: prevent the system from malicious attacks from individual-level threats with very little resources, ordinary natural disaster, and vital resources damage caused by other threats with corresponding damage extent. The system can be recovered for partial functions after it is damaged.

Class II: prevent the system from the malicious attack from small-organization-level threats with little resources, common natural disaster, and important resources damage caused by other threats with corresponding damage extent. The important security bugs and incidents can be detected. Partial functions can be recovered within a specific period of time after the system is damaged.

Class III: prevent the system from the malicious attack from organization-level threats with relatively abundant resources, relatively serious natural disaster, and the major resources damage caused by other threats with corresponding damage extent. Most functions can be recovered relatively quickly after the system is damaged.

Class IV: under the unified security strategy, prevent the system from the malicious attack from the state-level threats with abundant resources, serious natural disaster, and the resources damage caused by other threats with corresponding damage extent. All functions can be recovered promptly after the system is damaged.

Class V: (yet to be defined)

ʺInformation Security Technology—Baseline for Classified Protection of Information System Security (GB⁄T 22239-2008)ʺ defines the security requirements for information system with different levels. Based on this, ʺSecurity Protection Requirements for the Domain Name System (YD⁄T 2052-2009)ʺ and ʺSecurity Protection Requirements for the Domain Name Registration System (YD⁄T 2245-2011)ʺ further define the security requirements to domain name system and domain name registration system with different security levels. These security requirements are classified into the basic technical requirements and basic management requirements. Technical security requirements are related to the technology and security mechanism provided by the information system and achieved mainly through deployment of the software and hardware and the proper configuration of the security functions. Management security requirements are related to the activities various roles participate in and achieved by mainly controlling the activities of various roles from the angles of policy, regulations, procedures and records and so on.   
 
30(a).3.2	Security Level Commitment

ʺ.STRINGʺ undertakes the following security commitments to registrants: 

	(1) The DNS ⁄DNSSEC service system provides global Internet users with ʺ.STRINGʺ domain name resolution services. Class-4 protection is used for the primary operation centers and Class-3 protection for nameserver data centers (all name server data centers as one unit). 

	(2) With Class-3 protection, SRS service provides global users with ʺ.STRINGʺ domain name registration service through registry.

	(3) With Class-3 protection, Whois service provides global users with ʺ.STRINGʺ domain name query service.

The applicant and the BESP have jointly agreed to set up  corresponding security policy with the reference to the security requirements to information systems of different levels, deploy  security assurance measures,  satisfy each requirement in the standards and accept the examination of the third-party, in a view to guaranteeing ʺ.STRINGʺʹs fulfillment of its security-level commitments.

New gTLD Application Submitted to ICANN by: Guangzhou YU Wei Information Technology Co., Ltd.

String: 广东

Originally Posted: 13 June 2012

Application ID: 1-1121-17301

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.