ICANN New gTLD Application

“Guangdong is a province on the South China Sea coast of the Peopleʹs Republic of China. The province was previously often written with the alternative English name Kwangtung Province. It surpassed Henan and Sichuan to become the most populous province in China in January 2005, registering 79 million permanent residents and 31 million migrants who lived in the province for at least six months of the year. The provincial capital Guangzhou and economic hub Shenzhen are amongst the most populous and important cities in China.

Since 1989 Guangdong has topped the total GDP rankings among all provincial-level divisions, with Jiangsu and Shandong second and third in rank. According to provincial annual preliminary statistics Guangdongʹs GDP in 2010 reached CNY 4,550 billion, or USD 689.02 billion, making its economy roughly the same size as that of Turkey or Indonesia. Guangdong has the fourth highest GDP per capita among all provinces of mainland China, after Jiangsu, Zhejiang and Liaoning. The province contributes approximately 12% of the PRCʹs national economic output, and is home to the production facilities and offices of a wide-ranging set of multinational and Chinese corporations. Guangdong also hosts the largest Import and Export Fair in China called the Canton Fair in Guangdongʹs capital city Guangzhou.”

“Guangdongʹs economic boom began with the early 1990s and has since spread to neighboring provinces, and also pulled their populations inward. The economic growth of Guangdong province owes much to the low-value added manufacturing which characterized (and in many ways still defines) the provinceʹs economy following Deng Xiaopingʹs reforms. Guangdong is not only Chinaʹs largest exporter of goods, it is the countryʹs largest importer as well.

The province is now one of the richest in the nation, with the most billionaires in mainland China, the highest GDP among all the provinces, although wage growth has only recently begun to rise due to a large influx of migrant workers from neighboring provinces. In 2011, Guangdongʹs aggregate nominal GDP reached 5.30 trillion RMB (US$838.60 billion) with a per capita GDP of 47,689 RMB. By 2015, the local government of Guangdong hopes that the service industry will account for more than 50% of the provinces GDP and high-tech manufacturing another 20%.”

(http:⁄⁄en.wikipedia.org⁄wiki⁄Guangdong)

It is with the vision of transforming Guangdong from an industrial economy to a knowledge economy based on service and high-tech industry that the premise of the .广东 TLD is built on.

The mission and purposes of the Registry are:

1. To operate the .广东 TLD Registry as a global namespace with the interests of the Guangdong community at heart;

2. To promote the adoption and development of advanced Internet technologies to complement the development and growth of the Guangdong province;

3. To develop the .广东 TLD Registry into an economically viable initiative with capabilities to contribute back to the local community; and,

4. To enhance the awareness and foster an elevated sense of identity and ownership of the Guangdong people in the development of a global internet resource dedicated to their interests, and in turn encourage the participation from Guangdong in the global Internet Governance discourse.

While the Registry understands that as simply a gTLD operator, it may not be able to significantly influence the advancement of the region, the Registry aspires to be a nucleus and breeding ground for innovation and development, especially in the leveraging of the power of the Internet to improve the social well being of the community.

In addition, to its mission and vision, as a new gTLD, the Registry believes in its responsibility as a responsible industry participant to advance competition, enhance consumer trust and promote consumer choice with the development of the TLD:

A. Advance Constructive Competition

The “.广东” TLD aspires to be the domain of choice for initiatives and entities coming from Guangdong as well as providing services for the Guangdong market. As a dedicated TLD for the Guangdong people, the Registry will position itself not only as an alternative to existing TLDs such as “.com”, “.asia” or “.中国” but as a premier domain exploring new markets and new adoption promoting innovation and usage of domain names in the marketplace. For example, while there has been recent reports downplaying the effect of search engine optimization in the use of TLDs, the Registry believes in the prevalence value providing registrants a larger footprint on the Internet that is relevant to the target market they serve. As such, the Registry, also reflected in our financial projections and plans, even though conservatively based on existing market, believe in exploring new market segments rather than replicating existing zones.

B. Enhance Consumer Trust

Based on expert research, users’ confidence and trust of a website is increased if the domain name matches with what they are searching for online. What that illustrates is the value of the name string itself in promoting Consumer Trust. The introduction of the “.广东” TLD would allow individuals and companies from Guangdong to express their offline identity online, as well as allow foreign companies interested to target their audience in Guangdong with a matching and friendly name. This improves the relevance of services and content produced under the TLD and serves to enhance consumer trust.

Furthermore the strong commitments of the Registry on abuse prevention and mitigation (#28), rights protection mechanisms (#29) and reserved names (especially geographical and governmental reserved names -- #22), is a clear indication of the dedication of the Registry to build a trustworthy environment for development. The technically sound implementation of that solidifies the security and stability of the registry further establishes its reliability and consumer trust to transact online.

Finally, social aspects of the TLD registry is also an important element to enhance consumer trust. The Registry believes that with the launching of the TLD, it is possible to better engage the local community and raise their awareness about Internet governance issues. This in turn encourages more from the community to participate in the global Internet governance discussions, including at ICANN, which ultimately enhances consumer trust in the system by making consumers aware that they themselves can participate in the development and establishment of global internet policies.

C. Promote Consumer Choice

The introduction of the TLD itself promotes consumer choice, allowing registrants to choose a name that best fits their need and to best reflect their offline identity online. The Registry intends to offer the TLD in an open global platform for anyone interested to invest into the Guangdong community. At the same time, this is balanced with a strong set of abuse prevention and rights protection mechanisms to ensure that the promotion of consumer choice does not compromise the security and stability of the Internet.

The Registry aspires to develop a cyberspace that the Guangdong community can call home on the Internet. With Guangdong being one of the most advanced communities in Mainland China in terms of economy, technology and social development, the Registry aims to develop the TLD with the benefits of the Guangdong people at heart, while being a globally open platform to the world.

1. Goals of the TLD

The introduction of the “.广东” TLD as an IDN TLD is a novelty feature of gTLDs, and the Registry believes in developing this novelty into an area of specialty.

The Registry, through the support from its Registry Back-End Services Provider, KNET, which is a spin-off of CNNIC, the national ccTLD operator in China (.cn), aims to set a high standard in delivering on services of high quality, high performance, high scalability and high availability.

The Registry, through the support from its Registry Front-End Services Provider, Namesphere, which is a spin-off of the DotAsia Organisation, sets a noble goal in building itself as a reputable community initiative that is economically viable, sensitive to the cultural aspects of the community it serves, and one which contributes back to its community while participating in the global community as a responsible netizen, upholding a high level of integrity and respecting the rights of others.

2. Differentiation and Innovation

The Registry will focus on differentiating itself with the scope and its name. The Registry believes that a name makes a difference. Furthermore, the introduction of “.广东” as an IDN TLD will be a differentiation factor.

The Registry believes in operating a secure and stable platform for which innovations could take root and prosper from. As a TLD registry, the Registry will focus its efforts on innovations that improve the security, stability and user experience of Internet users by providing high availability and seamless advancement of technologies. The Registry considers itself successful if users are oblivious of its operations.

3. Improving User Experience

In line with the spirit of Deng Xiaoping’s open door policy which radically changed the economic destiny of the Guangdong province from an economic backwater to a national front runner, the Registry believes in a socially responsible development based on an open global platform.

The introduction of a TLD that reflects the identity of the Guangdong people provides an improved user experience for registrants to be able to utilize a domain name that reflects their identity, as well as for Internet users accessing the domain names to appreciate the relevance of the domain to what they may be looking for.

4. Registration Policies Supporting the Goals to Drive User Benefits

The Registry will accept Chinese IDN registrations under “.广东” TLD based on the time tested CDNC IDN Variant policies.

Comprehensive Sunrise and Startup (#29) policies and abuse prevention mechanisms (#28) will be put in place to build the reputation of the registry as a trusted platform respecting the rights of others and intellectual property rights online. At the same time, the utilization of the Pioneer Domains Program (#29) that balances the interests of rights holders with entrepreneurs and innovators without compromising the orderly and stable launch of the TLD, and encouraging the usage of the domain, further establishes the reputation of the TLD as an open global platform that is socially responsible.

Furthermore, special Sunrise phases will be put in place for entities in the Guangdong community to encourage their participation and also to drive the awareness of the TLD in the community that it intends to serve.

5. Privacy and Confidentiality Protection

As a socially responsible operator, the Registry is dedicated to ensuring that the privacy users and confidentiality of information is protected. The Registry, leveraging the infrastructure supported by its Registry Back-End Services provider, KNET, maintains a highly secure environment physically and technically to ensure that confidential information are not leaked. The Registry is also committed to developing and implementing policies that complies with privacy laws in the locality it operates out of and can be compatible with privacy laws of registrars and registrants of the registry. The Registry understands that there is no guarantee of compatibility of such laws especially given the global nature of the DNS and of the Internet at large, and is committed to dedicate itself, especially through its partner DotAsia (through Namesphere, as the Registry Front-End Services Provider for the Registry), to participate in the global Internet Governance discourse on the subject.

The Registry is committed to introducing the .广东 TLD in an orderly manner to minimize the social costs and maximize the social value of the TLD. Following the successful launch of the .ASIA TLD, and leveraging the experience and knowledge from the DotAsia (through Namesphere), the Registry is committed to developing and implementing a comprehensive startup process that would include, besides Sunrise and Landrush processes, a Multi-Category Pioneer Domains Program.

The Pioneer Domains Program will be designed to curb abusive registrations, whereby reducing social costs, as well as to promote the adoption of the TLD, to maximize the social value of the TLD. An important goal of the program is to allow for the introduction of showcase domains under the TLD in a well structured manner, while ensuring that the protection of the rights of others are maintained. The implementation of showcase domains support the development of positive foundation of usage of the TLD. More detailed explanation of the overall startup process is included in #29.

In response to the question specifically:

1. Mechanisms for Resolving Multiple Applications to a Domain

A comprehensive Sunrise and Landrush program will be put in place at the launch of the TLD. As an important stakeholder of the Registry, DotAsia (through Namesphere) will be lending its experience and knowledge in the development of an appropriate Sunrise and Landrush program that includes mechanisms for resolving multiple applications to a domain when the TLD is first launched. More detailed explanation of the approach is included in #29. In short, during the Sunrise and Landrush processes, a first come first served model will not be used as previous launches has demonstrated that such mechanism creates undue tension, chaos and frustration in the process. Applications for domains will be received within a designated time period and all applications received within such period will be considered to be received at the same time. All applicants will be verified first for their eligibility against the Sunrise and Landrush policies respectively. If there is only one successfully verified application for a particular domain, then it will be allocated directly. If there is more than one successfully verified application an auction will be held to resolve the contention.

During regular operations of the registry (upon GoLive and after Sunrise and Landrush), domain registrations will be accepted on a first-come-first-served basis. In cases of contention, the Registry will not prohibit the use of secondary market mechanisms for interested registrants to resolve the contention. Registrant transfers will be administered by accredited registrars without intervention by the Registry. In the cases of contention against abusive registrations, the Registry will adhere to the UDRP and URS procedures.

When a domain name registration is deleted and after completing the lifecycle according to ICANN requirements, the domain name will be re-released to the available pool and registrations will be accepted on a first-come-first-served basis. If activities to snatch names from this “dropzone” becomes contentious, the Registry is prepared to work closely with the community to provide better mechanisms to resolve contentions where appropriate.

2. Cost Benefits for Registrants

The registry intends to implement periodic cost reduction programs to encourage the adoption of the TLD by registrants. Such cost reduction programs can also be targeted towards key segments of the market in relation to the mission and vision of the Registry explained above. Based on the experience of DotAsia (through Namesphere), rebate programs that essentially lower the costs for registrants are one of the most effective ways to drive the adoption of a new TLD. Cost reduction oriented programs are included in the financial projections provided for #45-50.

Introductory programs will be important to drive awareness and interest in the TLD as well. These should include not only broad price discounts but also targeted programs. Based on DotAsia’s past experience, targeted programs, such as Home Market Growth programs are effective in raising the awareness for targeted segments. Such programs can also come in the form of special price reduction promos or rebate type programs.

Besides price reduction programs, other cost benefits can also be introduced to registrants. For example, DotAsia also pioneered the offering of free gift redemption programs to spark interest from registrants as well as to drive the cost benefits for adoption of the TLD.

3. Contractual Commitments to Registrants

The Registry will abide by the ICANN Registry Agreement requirements as well as ICANN Consensus Policies, including to offer domain registrations for periods of one to ten years at the discretion of the registrar upon GoLive (when normal first-come-first-served registrations begin). During Sunrise and Landrush the Registry will request multi-year initial registrations. The Registry does not plan to implement contractual commitments to registrars regarding the magnitude of price escalation, but is committed to providing a stable environment for registrations, including a stable pricing for registrars.

Besides policies and rules implemented, the Registry believes that prudent operations as an economically viable and socially responsible TLD operator in itself is an important mitigation of increased social costs as a new gTLD is being introduced. The Registry will leverage the knowledge and expertise from its technology provider and DotAsia to ensure that a substantial portion of the costs for operating the registry is managed in variable costs leveraging the economies of scale from already established operations and focus on delivering value to registrants and consumers with the introduction of the .广东 TLD and its mission and features.

Measures to curb abusive registrations will also be put in place to avoid costs from the community caused by such activities. Further details are included in the response to #28. Furthermore, security measures explained in #30 and #31 help reinforce a robust registry system to guard against DDOS and other malicious attacks which have implications to social costs. As explained above, above and beyond the compliance with the Trademark Clearing House (TMCH) requirements, startup policies will be put in place to address issues around reserved names (#22) as well as trademark, copyright and intellectual property concerns (#29).

Other Operating Rules Which Eliminate Or Minimise Social Costs

Abusive registrations will be prevented through having in place and enforcing a robust anti-abuse policy; this policy is described in detail in the response to Question 28. KNET, as provider of back-end registry services, has robust preventative and responsive mechanisms to address DDOS attacks, spamming, phishing, data theft, and similar nefarious activity. In addition to compliance with Trademark Clearing House (TMCH) requirements, policy will include processes to address issues involving trademark, copyright and intellectual property.

Members of the 广东 (Guangdong) Community
- Individuals, businesses and organisations residing in Guangdong.

The community is well organized and represented by a multitude of community based organizations. 
The community is clearly delineated from the general internet users at large.  Many of the community organisations are well established such as the Guangdong Youth Federation (http:⁄⁄www.gdqinglian.org), Guangdong Students Union, Children’s Palace Guangdong, etc.

Other related entities that is not primarily a part of the Guangdong community but has a nexus with the community:

- Individuals and businesses from the Cantonese language community: Cantonese is one of the main languages of the Guangdong province.  In fact, the Chinese name for “Cantonese” is “Guang Dong Dialect (广东话)”.  The Cantonese community is very active around the world, and associates with “Guangdong” (primarily in its Chinese form “广东”.  This is evidenced by the popular culture especially Kung Fu movies from Hong Kong.

- Individuals and businesses expanding into the Guangdong market: as one of the first areas to undergo economic reform in China, Guangdong represents a gateway to the China market for the world.  Many businesses around the world has established beachheads in Guangdong and remains closely connected to the area.

With a population of over 100 million, a GDP of over US$800 Billion, and established since AD 226, the community is sizable and has considerable longevity. 

1. Community

The Guangdong community represents cohesion in geography, language and culture.  There is a clear awareness and recognition of the Guangdong community among the members of the community as well as an association from those having a nexus.

2. Delineation

There is a clear delineation of the members of the community from the Internet community at large.  The members of the Guangdong Community are businesses, organizations and individuals who reside in Guangdong.

3. Pre-Existing

“‘Guang’ itself means ʺexpanseʺ or ʺvastʺ, and has been associated with the region since the creation of Guang Prefecture in AD 226. ʺGuangdongʺ and neighbouring Guangxi literally mean ʺexpanse eastʺ and ʺexpanse westʺ. Together, Guangdong and Guangxi are called the ʺDual-Guangsʺ (兩廣 liăng guăng).” (Wikipedia)

4. Organized

Guangdong is not only a thriving geographic region, the community is well organized with a multitude of organisations.  The following are just some of the organisations that the Registry intends to reach out to and serve:

广东省工商业联合会（总商会） (www.gdgcc.com⁄)
广东省商业联合会 (www.ggcc.org.cn⁄)
广东省青年联合会
广东狮子会为联会办公室
广东省学联
广州基督教青年会
广州基督教女青年会
广东省青年科学家协会
广东省青年企业家协会
广东省青年乡镇企业家协会
广东省青年摄影家协会
广东省青少年研究协会
广东省青少年事业发展基金会
广东省青年志愿者协会
广东省青少年宫协会
广东省青年星火带头人协会
广东省少先队工作学会
广东省企业共青团工作研究会
广东省留学回国青年创业促进
广东省潮人海外联谊会
广东省台办
广东省侨联 (www.gdql.org⁄)
广东省侨联青年委员会 (www.gdqq.org⁄)
广东省发展和改革委员会 (www.gddpc.gov.cn)
广东省旅游局 (www.visitgd.com⁄)
广东省工商局 (www.gdgs.gov.cn⁄)
广东省教育厅 (www.gdhed.edu.cn⁄)
广东省国土资源厅网站 (www.gdlr.gov.cn)
广东省民政厅 (www.gdmz.gov.cn⁄)
广东省人力资源和社会保障厅 (www.gdrst.gov.cn⁄)
广东省地方税务局 (www.gdltax.gov.cn)
广东环境保护公众网 (www.gdepb.gov.cn⁄)
广东省博物馆 (www.gdmuseum.com⁄)
广东省对外贸易经济合作厅 (www.gddoftec.gov.cn)
广东省体育局 (www.gdsports.net⁄)
广东省教育考试院 (www.eeagd.edu.cn⁄)
广东省食品药品监督管理局 (www.gdda.gov.cn)
广东省知识产权局 (www.gdipo.gov.cn⁄)
广东省人事考试局 (www.gdkszx.com.cn⁄)
广东省国家税务局 (www.gd-n-tax.gov.cn⁄)
廣東省連南縣共青團
共青团广东省委
广东省科学技术厅 (www.gdstc.gov.cn⁄)
广东人大网 (www.rd.gd.cn)
广东省社会科学院 (www.gdass.gov.cn⁄)
广东省社会保险基金管理局 (www.gdsi.gov.cn⁄)
广东省安全生产监督管理局 (www.gdsafety.gov.cn)
广东省海洋与渔业局 (www.gdofa.gov.cn⁄)

廣東省林產工業公司 (www.gdfpi.com⁄aboutus.htm)
广东省中医院 (www.gdhtcm.com)
广东省摄影家协会 (www.gdphoto.cn⁄)
广东省立中山图书馆 (www.zslib.com.cn⁄)
广东女性E家园网站 (www.gdwomen.org.cn)

廣東省海外聯誼會 (http:⁄⁄www.a-zip.com)
香港廣東客屬社團聯合總會 (http:⁄⁄www.hkhakka.com⁄ksst.html)
香港廣東社團總會
香港廣東外商公會
香港廣東客屬社團聯合總會 (www.hkhakka.com⁄hwbd_02.htm)

5. Extension

The primary community resides in the geographical location of Guangdong.  Many others associate closely with the community by spoken language and by their nexus relationship.

6. Size

“Guangdong officially became the most populous province in January 2005.Official statistics had traditionally placed Guangdong as the 4th most populous province of China with about 80 million people (also, Sichuan, traditionally the most populous province, was divided into Sichuan and Chongqing in 1997) but recently released information suggests that there are an additional 30 million migrants who reside in Guangdong for at least six months every year, making it the most populous province with a population of more than 110 million.[21] The massive influx of migrants from other provinces, dubbed the ʺfloating populationʺ, is due to Guangdongʹs booming economy and high demand for labor.

Guangdong is also the ancestral home of large numbers of overseas Chinese. Most of the railroad laborers in Canada, Western United States and Panama in the 19th century came from Guangdong. Many people from the region also travelled to the US ⁄ California during the gold rush of 1849, and also to Australia during its gold rush a decade or so later. Emigration in recent years has slowed with economic prosperity, but this province is still a major source of immigrants to North America and elsewhere in the world.” (Wikipedia)

7. Longevity

The community has been associated with the name since AD 226 and is a long lasting and non-transient nature.

The Registry is committed to following the GAC advice and Specification 5 of the New gTLD Agreement in the protection of geographic names for registrations under the TLD.

More specifically, the Registry commits to:

a) Adopt, before the new gTLD is introduced, appropriate procedures for blocking, at no cost and upon demand of governments, public authorities or IGOs, names with national or geographic significance at the second level of the TLD.

b) Ensure procedures to allow governments, public authorities or IGOs to challenge abuses of names with national or geographic significance at the second level of the TLD 

Building on the experience from .INFO and .ASIA in their handling of country and government related names, the Registry will develop and establish policies for:

1) obtaining and maintaining a list of names with national or geographic significance to be reserved (at no cost to governments) upon the demand of governments, public authorities or IGOs; 

2) process for registrants to apply for and for the Registry to obtain consent from the respective government, public authorities or IGOs in the releasing of such reserved geographic names; and

The procedures may be similar to the management of governmental reserved names for .ASIA (Section 3.4 of http:⁄⁄dot.asia⁄policies⁄DotAsia-Reserved-Names--COMPLETE-2007-08-10.pdf -- also attached for reference).  In summary:

I) The Registry will adhere to the New gTLD Registry Agreement Specification 5 requirements regarding 2. Two-Character Labels as well as 5. Country and Territory Names;

II) Before the launch of the TLD, the Registry will also proactively reach out to governments around the world, especially through GAC members (and ccTLD managers where appropriate), to solicit from them their demand for reserving any names with national or geographic significance at the second level of the TLD;

III) The Registry will develop mechanisms and maintain a list of governmental reference contacts, especially through correspondence with GAC members and ccTLD managers where appropriate.  The corresponding reference contact(s) will be contacted in case a registration request is received for a governmental reserved name.  If the consent from the governmental contact is received, the registration request will be approved.  The domain will nevertheless remain in the reserved names list so that in case the registration lapses, the domain will not be released into the available pool, but will require the same approval process to be registered.

IV) The Registry will maintain an ongoing process for adding and updating governmental reserved names as they are demanded by governments, public authorities or IGOs.
In accordance with Specification 5 of the New gTLD Registry Agreement, the registry operator must initially reserve all geographic names at the second level, and at all other levels within the TLD at which the registry operator provides for registrations. 
In accordance with Specification 5 of the New gTLD Registry Agreement, the registry operator will initially reserve all qualified geographic names at the second level, and at all other levels within the TLD at which the registry operator provides for registrations.  The Registry will compile and establish a comprehensive master list of all qualified geographic names and place them into the Reserved Names list.  Names on this reserved list will not be accepted for general registrations from the registry system.

The following explains the system behaviour for reserved names:
- regular domain create commands to reserved names will be rejected
- domain check commands will also return as unavailable for registration
- Whois queries for reserved names that are not activated will receive responses indicated that they are reserved
- Whois queries for reserved names that are activated will receive responses similar to other registered domains
- reserved names that are not activated will not appear in the DNS
- reserved names that are activated will be delegated in the DNS

Furthermore, the Registry will actively participate in the development of appropriate process and policies for governments, public authorities or IGOs to challenge abuses of names with national or geographic significance.  As an important stakeholder in the Registry, DotAsia Organisation (through Namesphere) will be supporting the efforts as well.  DotAsia has been a pioneer of protective measures for new gTLDs, especially in its handling of governmental reserved names and its engagement with different stakeholders to develop rapid suspension policies, which provided part of the genesis of what is now standardized for new gTLDs as the URS (Uniform Rapid Suspension) process.  Similar administrative processes may be explored and developed for supporting challenge processes for abuses of names with national or geographic significance.

23.1. Registry Services

The Registry is committed to provide all the core services as specified in Specification 6, section 2.1 (a) and (b) in ICANNʹs Applicant Guidebook as well as those as specified in Appendix A. The Registry will also refrain from the use of wildcard per requirements specified in Specification 6, section 2.2.

The Registry is committed to providing other necessary services in accordance with the Consensus Policy of Specification 1.

The services provided by the Registry will abide by the requirements of ICANN and IANA and shall comply to the technical standards as specified in Specification 6, Section 1 of the ICANN’s Application Guidebook. The Registry will implement support for IDN, DNSSEC and IPv6.

The Registry will outsource the registry technical Back-End operations to KNET (“Back-End Service Provider”) while the registry Front-End services will be outsourced to Namesphere (in turn supported by the DotAsia Organisation who is the registry operator for the existing “.Asia” gTLD, “Front-End Service Provider”). The KNET Shared Registry Platform (“KSRP”) is a proven platform built by engineers supporting the .CN TLD, and is designed and implemented to provide a secure, stable, robust and highly available registry services.

Note: The Specifications stated in this document refer to the Specifications in ICANNʹs gTLD Applicant Guidebook.

23.1.1. Service Level

KSRP conforms to the requirements in Specification 10 of ICANNʹs Applicant Guidebook. For the summary of the service level agreement, please refer to Table 23-1 in Q23_attachment for the summary table of the services level agreement. For detailed information, please refer to corresponding sections.

23.1.2. Security

KRSP conforms to the ISO27000 standard in its design, implementation and operations. KSRP institutes the following security measures:

a) A set of operations policies and procedures that shall be strictly followed by service operations personnel.

b) A set of security policies that shall be strictly followed for service management and engineering activities.

c) A monitoring center that is only accessible by authorized staff members. Any management operation is performed on a bastion host only after an authorized staff member successfully logs in to the bastion host with a correct password; comprehensive logging and auditing are enforced for all activities for the entire process;

d) All equipment and services are being monitored on a 7×24 basis by a technical team. In case of emergency, risks will be assessed and mitigated with minimum delay.

e) Firewalls, IDS and network traffic monitoring system are deployed in to provide network layer security and protection against attacks;

f) Databases, applications, source code, documents, system logs and other business data of all services are backed up offsite and offline on a regular basis so that they can be restored quickly in case of a failure;

g) Critical data are transferred via a secure channel, such as VPN, HTTPS, and TSIG with data validation to ensure security and integrity.

Additional measures specific to a subsystem will be documented in the section of that subsystem..

23.1.3. Stability

The Registry adopts the following measures to ensure the stability of its services. Additional measures specific to a subsystem will be documented in the section of that subsystem.

a) A primary data center and a geo-dispersed backup data center are deployed in an active-standby manner; when the primary data center is not available, the backup data center is activated to continue the services; high availability of the services are guaranteed by measures such as database hot standby and server clustering via load balancing;

b) The services provided by the Registry fully comply with relevant RFCs and other widely accepted industry technical standards. The system will undergo a series of sustained stress testing before the service is open to the public;

c) All equipment, power supplies, network interfaces and network connectivity are deployed in a redundant way so that no single point of failure would result in service interruption;

d) During the daily operation of the services, the operating team closely monitors the system in terms of equipment load, network bandwidth and response performance to ensure capacity sufficiency and redundancy during peak business hours;

e) The SLAs of all registry services are actively monitored and maintained pursuant to ICANN requirements (Specification 10 of gTLD Application Guide book).

In addition, the DotAsia team (through Namesphere) will be supporting the Front-End operations and ensuring that policies and procedures are in place to ensure an orderly, stable and secure implementation of the TLD into the technical as well as social fabric of the Internet.

23.2. The Receipt of Data from Registrars Concerning Registrations of Domain Names and Name Servers

The Registry receives the data from Registrars concerning registrations of domain names and name servers via standard EPP commands. The Registry will operate the SRS service according to and beyond the basic requirements specified by ICANN. Registrars collect the data from end users relating to registration contacts, domain names and name servers and submit them to the Registry via EPP to the SRS system; the Registry can also provide add-on auxiliary services for Registrars to submit other business-related data as required by future Registry services whether created as part of Consensus Policies or through the RSEP process;

23.2.1. Service Level

The service levels of the SRS meets the requirements specified in Specification 10 of ICANNʹs Applicant Guidebook. Please refer to the answer to Q24 Share Registration System (24.2.2) for details.

23.2.2. Security

Only ICANN accredited Registrars are considered to be candidate Registrars for the Registry.

To connect to the SRS platform of the Registry, a Registrar must provide a set of fixed static IP addresses to the Registry beforehand. The SRS service only opens specified service ports to those static IP addresses provided by the Registrar. Dynamic IP addresses are not accepted.

The SRS system employs a combination of Registrar ID, high-security password authentication, Registrar certificate authentication and encryption protocol to ensure the connection between the Registry and a Registrar is secure and robust for data transfer.

To mitigate the risk of malicious cybersquatting, the SRS system enforces a cap on the maximum number of sessions between the Registry and a Registrar, and the maximum number of transactions in unit time from a Registrar.

23.2.3. Stability

The SRS service provided by the Registry fully complies with the relevant policy requirements of ICANN.

It conforms with the EPP1.0 and other relevant RFCs including RFCs 5730-5734, RFC 3735 and RFC 3915

The Registry will provide Registrars with the adequately tested EPP Client SDK and manual.

The SRS service puts a cap on the number of connections and the transaction volume in unit time for each Registrar. System capacity for peak business hours is ensured by hardware redundancy and load balancing.

23.3. Information Publication

The Registry will build its official website to make the following information available:
a) Registration policies (including Sunrise, Landrush, Abuse prevention and other general registry policies);
b) Hotline and Email address for complaints⁄reporting;
c) Public key for DNSSEC;
d) Incident report;
e) Advanced notice of planned outage (due to system upgrade, etc.)
f) SLA report;
g) Whois service.

The Registry will also release necessary information on these topics via Email to relevant parties including ICANN, IANA, Registrars, Registrants etc.

23.4. Provision of Status Information Relating to the Zone Servers for the TLD

When a Registrar requests for any information such as the status of zone servers, Registry will provide such information to the Registrar via Email or by telephone following the pre-defined procedures.

In case there is a change made or planned to be made to the zone servers, such as adjustment of volume of nodes and status transition, affected Registrars will be informed in accordance with the pre-defined procedures.

For security and stability concerns, the service is only made available to those accredited Registrars according to the pre-defined procedures.

23.5. Dissemination of TLD Zone Files

The dissemination of TLD zone files from the central database to DNS service nodes is done by the zone file generation program, dissemination program and the hierarchically and globally distributed DNS system.

All changes in DNS records generated by the data centers are first updated to the primary DNS node; these updates are then disseminated by the master⁄slave update mechanisms to all other DNS nodes.

The Registry will also provide zone file access services according to the requirements in Specification 4
Specification for registration data publication services.

23.5.1. Service Level

The SRS service level provided by the Applicant meets the Specification 10 of the ICANNʹs Applicant Guidebook. Please refer to the answer to Q35 DNS Service (35.3) for details.

23.5.2. Security

In addition to those described in 23.1.1, the following security measures are also adopted .
The data source of zone files is stored in the domain name database deployed behind the internal firewall with the top-level network security policies. The zone files generation program and the SRS system are located in the DMZ.

The zone files dissemination program supports two modes: full update and incremental update. The incremental update is invoked periodically while the full update is triggered only by unusual circumstances to ensure service ability.

a) Full update. The zone files generation program reads the data in the domain name database to generate the complete zone files. The database connection used by the generation program is read-only. The generated zone files will undergo a series of checks in terms of integrity, syntax and data change rate before invoking the subsequent dissemination procedures.

The data change rate check inspects whether the number of lines in the zone files and⁄or their sizes have changed significantly. If the change is over 5% since the last backup, alarm will be triggered..
Once the zone files are generated and pass the validations, they will be first transferred to the hidden master DNS server. When the system invokes full update, they will be distributed to the global authoritative DNS nodes through the master⁄slave update mechanism of DNS.

b) Incremental update. This program monitors any zone-file-related data changes occurred in the SRS database. When such changes occur, the changed data will be sent to the hidden primary DNS on a periodic basis, and then disseminated to the global authoritative DNS nodes by the master⁄slave update mechanism of DNS. The system automatically checks incremental update data and confirms that each update is properly performed. If any abnormal changes are detected, the system automatically generates an alarm and aborts the update.

23.5.2.1. Data Transfer Security

a) The data transfer between the hidden primary DNS and the global distributed resolution nodes is done via VPN;
b) Digital signature is added using TSIG;
c) Some specified test is performed to check the consistency of the DNS data.

23.5.3. Stability

In addition to those described in 23.1.2, the following stability measures apply to zone file dissemination:

a) The interfaces between the SRS and the hidden master DNS server conforms to RFC 2136 and RFC 2137;

b) Zone files of the hidden master DNS are transferred to the global distributed DNS nodes via incremental zone files using the TSIG per RFC 1995, RFC 1996 and RFC 2845.

23.6. Operations of the Registry Zone Servers

KNET is in charge of the operation of the zone servers as part of the KSRP. KNET has many years of experiences in developing and operating domain name system in China.

The operations of the zone servers mainly involve synchronization of resolution data, response to DNS queries, statistics monitoring and reporting, and continuous improvement of security, stability and performance. The goal is to provide correct, reliable and fast DNS services to the global Internet users for the Registry.

23.6.1. Security

In addition to those described in 23.1.2, there are also the following security measures for zone server operations.

KNET has deployed global production zone servers based on RFC 2870, such that:
a) The capacity exceeds 3 times of the peak traffic volume;
b) Recursive queries and other services such as remote Internet protocols including HTTP, TELNET, RLOGIN and FTP are strictly forbidden;
c) Hidden primary DNS servers are deployed in the system for zone file updates;

KNET has established the primary⁄backup data centers and globally distributed DNS nodes with access to the Internet from more than one ISP in each location to ensure uninterrupted DNS services against natural and⁄or human-caused disasters.

Zone file transfer is secured by ACL policies of routers⁄switches⁄IPtables, restriction of IP address in zone files such as allow-notify and allow-transfer, as well as TSIG.

The primary and backup data centers use VPN to ensure network layer security of data transfer.
KSRP employs sophisticated automated monitoring system to timely detect any failures of zone servers as well as other software and⁄or hardware failures, and resolve traffic anomalies. It performs real-time monitoring and analyses to detect potential attacks and to take necessary actions against them.
In addition, KNET is developing domain security software to further enhance KSRPʹs abilities to handle more sophisticated security threads. The new capabilities will be gradually applied to the shared TLD production once it is fully developed and tested.

23.6.2. Stability

In addition to those described in 23.1.3, the following stability measures apply to DNS zone servers.

a) KNET uses the latest stable version of ISC BIND and NSD to ensure that DNS software deployed for KSRP are most updated against known security vulnerabilities.

b) The primary and backup data centers use VPN for secure and stable data transfer.

c) KNET has provisioned additional network bandwidth in each of the data centers hosting the DNS zone servers to handle unexpected high volume domain name queries to DNS servers. Refer to specific sections for details.

d) KNET uses BGP+Anycast technologies to build the global distributed domain name resolution service platform where polices can be adjusted to schedule and limit traffic in any unusual circumstances (especially in the case of DDoS attacks).

23.7. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations in the TLD

The Registry provides the domain name query, contact query and name server query services according to the data contents and formats requirements stated in Specification 4 of ICANNʹs Applicant Guidebook.
The Registry provides the Web Whois and Whois Server services and disseminates contact and other information concerning TLD server registration according to the Registryʹs protocols.

The Registry provides two types of Whois query service: general queries and searchable queries.

The Registry provides ICANN and other authorized third parties access to the TLD zone files.

The Registry provides ICANN with bulk registration data through the interfaces specified by ICANN.

23.7.1. Service Level

The service level provided by the Registry meets Specification 10 specified in the Applicant Guidebook. Please refer to the answer to Q26 Whois System (26.2.2) for details.

23.7.2. Security

In addition to those described in 23.1.2, the following security measures apply to services in section 23.7.
a) No sensitive data are stored in Whois database.
b) The Web Whois service uses CAPTCHA technologies to reduce automated malicious queries.
c) Both Web Whois and Whois Server services impose a cap on the maximum number of queries in unit time from the same IP address to reduce the query volume from automated programs.

23.7.3. Stability

In addition to those described in 23.1.3, the following stability measures apply to services in section 23.7.

a) The Whois service follows RFC 3912, meeting the requirements specified in Specifications 4, 6 and 10 of the ICANNʹs gTLD Applicant Guidebook.

b) The Whois service runs on redundant server clusters that are load balanced; an offsite backup data center is established to address disastrous emergencies.

23.8. Internationalized Domain Name (IDN) Service

The TLD applied in this application is an IDN. KNET and DotAsia worked together to formulate the IDN policies for the Registry based on the latest IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄implementation-guidelines.htm).

The IDN registrations in Registry follow the Chinese IDN Table included in #15 and KSRPʹs IDN support complies with the IETF protocols (RFC 3454) and IDNA2008 (RFC 5890, 5891, 5892, 5893 and 5894).

KSRP accepts IDN registration requests and performs registration for the original applied IDN. Any newly registered domain names must go through pre-auditing by the auditing system of the Registry business support platform. The audit system will generate a group of IDNs from those variant characters of the new domain name based on RFC 3743 and display those in the group that are already registered. An automated auditor will perform the pre-auditing on these variants using a set of predefined examination rules. The auditor may reject the registration of the new domain name if the set of IDN Variant labels conflict or overlap with another already registered IDN.

The query function of the Whois system accepts domain names in both UTF8 and ASCII formats. The Registry understands that the question of whether Whois systems should accept IDN queries in UTF8 form is still in discussion and is prepared to configure the system should ICANN believe that UTF8 queries should not be responded to. Nevertheless, the Registry is prepared to work with ICANN to support a better IDN user experience by allowing Whois queries in native form.

The zone file generation program directly reads the domain name Punycode strings and other relevant data stored in the database to generate zone files. KSRPʹs zone file dissemination subsystem described in 23.5 supports zone data in Punycode format.

23.8.1. Security

With many years of experiences in operating .CN (supporting IDN) and .中国⁄.中國. KNET is confident that registration of the IDNs through above-mentioned technical business system is free from any security risk.

23.8.2. Stability

With many years of experiences in operating .CN (supporting IDN) and .中国⁄.中國, KNET is confident that the performance of the IDN business following the above-mentioned technical business system is free from any stability risk.

Theoretically, creating IDN domain names takes longer time in KRSP because of additional computational overhead incurred by the existence of IDN variants. However, such computations have a very small impact on the performance. In order to improve the performance of DNS data dissemination, the SRS system stores the corresponding Punycode character strings for the registered IDNs, consequently eliminating additional computation brought by zone files generation. Moreover, since only the original character string within the group of variants is allowed to be submitted by the user, storage capacity for IDN is not increased.

Meanwhile, compared with ASCII-based domain names, IDNs do exhibit a common display problem. However, the display of Chinese characters currently has matured and the Registry services provided have very good support to displaying Chinese domain names.

In summary, the KSRP systems were developed with IDNs in mind and the introduction of IDNs in the Registry shall have negligible impact on the performance of its Registry services.

23.9. DNSSEC

KSRP is designed to fully support DNSSEC. The Registry provides the following DNSSEC services:
a) Authentication and distribution of public keys of KSKs;
b) DNSSEC-based DNS services;
c) Data protection during zone files transfer.

The Registry deems DNSSEC as critical for its registry services. KNET plans to actively drive adoption of DNSSEC in KSRP in 3 stages:

a) Stage 1: Operations Setup Stage. At this stage, KNET intends to build an internal test-bed on which the technical tracking, verification and testing will be performed; the DNSSEC chain of trust will be built on a small set of selected second and lower level domains under the applied TLD; the DNSSEC Operational Practices (RFC 4641) will be followed and exercised. The goal is to complete the technical verification of DNSSEC;

b) Stage 2: Pre-Launch Stage. At this stage, the chain of trust will be built on domain names that are registered for trial based on the best practice developed at the first stage, and the DNSSEC policies will be verified based on the trial results;

c) Stage 3: Production Stage. At this stage, the DNSSEC will be put into use officially according to the achievements of the previous two stages. The implementation of DNSSEC will be applied to the TLD and all of its sub domains in production KSRP.

After implementation of DNSSEC, the performance indicators of relevant services will be affected to some extent, such as increase in storage capacity, in CPU load and memory of the resolution system and in network bandwidth for resolution services. However, such implementation has only negligible impact on resolution query performance and QPS. Through vertical extension, horizontal extension and bandwidth upgrade, KSRP will still be able to sufficiently meet and exceed the service levels required by ICANN stated in this application.

23.9.1. Security

DNSSEC is an important measure against the security defect of DNS system. The public key infrastructure (PKI) is used to add a digital signature to each resource record set to improve the security level of domain system.

There are two kinds of keys, KSK (Key-signing Key) and ZSK (Zone-signing Key), created for DNSSEC. The former is used to sign DNSKEY resource record sets while the latter is used to generate signatures for all resource records within the zone, including KSK record sets.

KSRP uses hardware encryption equipment HSM (complying with FIPS 142-2 level 3) to generate keys; the keys stored in an HSM cannot be exported; they are automatically synchronized among the HSMs. Unauthorized access to private keys of KSK and ZSK is strictly forbidden, and offline storage is achieved with best possible efforts.

A periodic key update system is established, in which the KSK lifetime is 1 year and the ZSK lifetime is 1 month.

23.9.2. Stability

The DNSSEC deployment in KSRP is compliant with RFCs 4033~4035, RFC 4310, RFC 4509, RFC 4641, RFC 5155, RFC 5910 for DNS data origin authentication, data integrity verification and authenticated denial of existence.

KSRP is designed to fully support DNSSEC, by reserving interfaces for SRS, Whois and DNS systems.
As DNSSEC signature involves significant computation and data volume, generation and verification these signatures will result in much more CPU time; the disk space incurred by signatures and keys storage will be 10 times or more of that without DNSSEC.

24.1. Overview

The Registry provides Registrars with a registration interface through KSRP provided by KNET. The SRS provided by KSRP complies with the requirements of ICANN and IANA as well as relevant RFCs and other technical standards. It is designed and implemented to provide highly available, secure, scalable and high performance services.

24.1.1. System Architecture

The SRS consists of the domain registration system (EPP server) and other subsystems for domain name registration. Please refer to Figure 24-1 in Q24_attachment for the system architecture of SRS. Below is the detailed description.

a) EPP Server
The EPP server provides Registrars with domain registry services such as the creation, modification, deletion and other key functions of domain, contact and host objects. It also provides support for the redemption grace period and DNSSEC as specified in relevant RFCs.

b) Registrar Business Support System
The registrar business support system provides supporting functions to Registrars concerning domain registration. Upon successful authentication, a Registrar may perform a real-time check of account balance, monthly bill report, and domain operation records. It may also check its payment and usage details within a year. The Registrar can also use the system to report any problem to online customer support staff for solutions. In addition, Registrars may retrieve specifications, FAQs and other technical documents concerning domain name registration in the knowledge base.

Registrars may also access the business support system via FTP to download historical data such as domain operation records and billing reports upon successful authentication.

c) Registry Business Support System

Please refer to Figure 24-2 in Q24_attachment for the system architecture of the Registrar business support system.

The Registry business support system provides business staff of the Registry with the support services concerning domain registration, including auditing of newly registered domains, recharging of registrarsʹ accounts, and locking⁄unlocking of domains.

The registry business support system will regularly compile the registered domain data and zone file into a data file with specified type and formatting of content as described in ICANNʹs Registry Agreement, and uploads the data file on specified SFTP for ICANN and its designee to access and download.
In addition, the registry business support system will regularly generate a data file with specified type and formatting of content as described in ICANNʹs Escrow Agreement, and uploads the data on specified SFTP of the escrow service provider NCC Group for its service provision.

d) Zone File Synchronization Service

The zone file synchronization service is responsible for synchronizing changes made to the SRS database to the master DNS nodes, and through which all global DNS nodes are subsequently updated.

e) Databases

The SRS database is the master database that stores information about domains, contacts and hosts submitted by the EPP server. It is replicated to the Whois database using the Oracle Advanced Replication. The Registrar & Registry (hereafter referred to as R&R) business support database stores the data relating to the support business, such as billing reports, and historical auditing records, etc..

24.1.2. Physical Architecture

Please refer to Figure 24-3 in Q24_attachment for physical architecture of SRS.

The SRS system and the R&R business support system are deployed in multiple servers that are clustered and load balanced via F5s; both the SRS master database and R&R business support database achieve high availability via Oracle Veritas. A disk array is deployed at the back-end for data storage redundancy and for high throughput database access.

24.1.3. Equipment List

Please refer to Table 24-1 in Q24_attachment for a list of equipment of the SRS (excluding any hardware shown in the topological diagram of the primary data center, such as routers or firewall).

24.2. Operations Plan

24.2.1. Availability

The SRS of the KSRP is able to provide 99.9% availability, ensuring the monthly down time not exceeding 43.2 minutes, therefore fully meeting the 98% availability requirement specified in ICANNʹs Specification 10. In addition, the SRS is also redundantly deployed at the backup data center. If the primary data center goes off-line, registry services are switched over to the backup data center within 30 minutes to ensure high availability of the services.

Specifically, SRS ensures high availability in the following aspects:

a) The SRS software has been built via rigorous engineering disciplines such as code review, unit testing and daily builds. Any SRS build must pass the thorough integration testing, system testing and acceptance testing prior to deployment in production.

b) Both the hardware and software systems are redundantly deployed. Load balancers (F5) are deployed to distribute requests to server clusters to mitigate unplanned server hardware and software failures. For example, the EPP server is deployed on multiple servers as a cluster behind the load balancer so that even if one of the servers goes down, F5 will automatically distribute the requests to the rest of functioning servers, to ensure the registry services continuity.

c) The database of the SRS achieves high availability via Oracle Veritas to prevent any unplanned outages of the database backend.

24.2.2. Performance

Based on the projections, the Registry expects around 5,000 domain names within 3 years. When the registration volume reaches such target point, the Registry needs to handle about 3000 transactions per day. The KSRP is designed to scale up to 30 million domains, and the performance test result shows that it is able to handle 3000 transactions per second. Hence KSRP is able not only to meet the current needs of the Registry, but also to scale for future demand of the Registry as the business grows.

Comparison with SLR Indicators

Please refer to the Table 24-2 in Q24_attachment for the contrast between the test results of the SRS and the SLR indicators specified in Specification 10.

24.2.3. Scalability

The SRS is developed and deployed using distributed technology that is able to scale both vertically and horizontally as follows:
a) Support vertical scalability by upgrading the hardware of online servers;
b) Support horizontal scalability by deploying server hardware and software systems in a cluster;
c) When the system load reaches the maximum capacity of the SRS system, it can be upgraded by adding more servers and bandwidth to meet the performance and throughput capacity needs

24.2.4. Security

In order to ensure the security of the SRS, the KSRP has taken the following measures:

a) SSL⁄TLS protocol is used for connection between the SRS and the clients. When connecting the SRS, a Registrar is required to be authenticated with SRS using its user name, password, IP address and the digital certificate authorized by the KSRP; if the Registrar fails the ID authentication 3 times, it has to wait for 30 minutes before another attempt;

b) SRS has put a strict restriction on the number of connections created by Registrars as well as the idle time in TCP;

c) SRS is deployed in the DMZ in order to prevent unauthorized network access to the backend database.

24.2.5. Data Synchronization

Data synchronization between the master database of SRS and the Whois database is realized via Oracle Advanced Replication at an interval of 5 minutes.

Data synchronization between the primary and the backup data center is realized via Oracle Dataguard at an interval of 5 minutes.

24.2.6. Operations and Maintenance

The following operations and maintenance measures have been established to guarantee the quality of services.

a) SRS is being monitored and protected on a 7×24 basis. With the monitoring system, KSRP keeps track of the performance of the whole system so that it can take timely measures to address any emergency;

b) The Registry and KSRP have established a thorough emergency response mechanism to effectively handle emergency situations. The mechanism provides handling and upgrading procedures for different types of failures based on pre-classified severity levels.

24.3. Compatibility

The SRS fully complies with EPP and supports RFCs mentioned in Specification 6, including RFCs 5730～5734, RFC 3735 and RFC 3915.

KSRP supports IDN based on IETF RFC 3454 and RFCs 5890～5892. When the user registers a domain name under the TLD, the SRS will store the domain data and its corresponding Punycode into the SRS database.

Regarding support for DNSSEC, KSRP has designed its interfaces according to RFC 5910. A plan is in place for smooth transition to DNSSEC in KSRP once DNSSEC-related tests are completed on the platform.
KNET has dedicated R&D personnel who closely follow the DNSSEC work in IETF and the industry, so that the platform can be timely upgraded to meet the requirements of ICANN in case there are changes in the future.

24.4. Resourcing Plan

The development and test work for SRS has been completed. Please refer to section 31.12.2 for the overall human resource planning of KSRP. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.

25.1. Overview

The Registry provides services to the public through KSRP provided by KNET. KSRP provides Registrars with a registry service interface over EPP 1.0. KNET has years of experiences in implementation and maintenance of the EPP1.0 interface for the .cn Registry.

25.2. Introduction to EPP

EPP is an xml-based protocol. It is widely used as a standard protocol for domain name registration provisioning between Registry and Registrar.

The EPP protocol suite consists of RFCs 5730～5734, RFC 3735, RFC 3915 and other relevant RFCs. The core of EPP is specified in RFC 5730, which defined the EPP commands, request-response mechanism, message format, result code and other basic protocol elements. RFCs 5731～5733 define the mapping of domain name, contact and host objects on EPP respectively. RFC 5734 explains how to safely implement EPP over TCP. RFC 3735 provides guidelines on how to extend EPP. RFC 3915 extends EPP to handle different redemption grace periods in registration life cycle. RFC 5910 describes how to support DNSSEC based on EPP. The aforementioned RFCs cover all functions, procedures and expansion mechanisms required by domain registry services.

EPP provides four basic service elements: service discovery, commands, response and an extension framework.

The EPP commands are divided into session management commands, query commands and object transform commands. The first category is used to establish and close connections between a client and the server; the second category is used to query information such as domain name, contact and host from server; the last category is used to manage the domain name, contact and host objects.

The responses to EPP commands must include a result code and a detailed description of the code. The result code is a 4-digit number. The first digit represents success or failure of command execution (1 for success, 2 for failure); the second digit represents the classification of responses (6 categories in total); the last 2 digits represent the explicit description of the result code in each category of response. For example, an result code for an EPP command is 1000, where 1 stands for success of command execution, the second digit 0 implies this EPP command is ʺProtocol Syntaxʺ (one category of responses), and the final two digits imply the description of the result code is ʺCommand completed successfullyʺ.

KSRP implements EPP based on TCP (refer to RFC 5734). The server listens on port 700. The client issues EPP commands to the server after both sides have passed the two-way certificate authentication and have successfully completed the execution of the Login command. The EPP server executes the received commands in order. Upon completion of processing an EPP command, the server packages the results into an EPP response to be returned to the client. Both sides repeat the request-response cycle until either the client requests the server to close the connection (via the Logout command) or the execution of a command requires that the server terminate the connection after the command execution (according to RFC 5730, the result codes 2500~ 2502 demand that the server proactively close the connection).

25.3. APIs Provided for Registrars via EPP

KSRP implements registration APIs for Registrars based on EPP1.0. These APIs cover all functions required by domain registry services, including opening and closing of connections, and processing of commands such as query, creation, modification, transfer and deletion of domain, contact and host objects.

a) Session Management

APIs provide Login command and Logout command to Registrars. By using these commands, Registrars can interact with KSRP, such as executing ID authentication (via Login command) or closing connections (via Logout command).

A Registrar sends the Login command to request ID authentication and session establishment with the EPP server; Upon successful authentication and session establishment with the EPP server; upon successful authentication and session establishment, Registrars begin to send other EPP commands. Each of the subsequent commands from shall contain the authentication token and the Registrarʹs password. When the Registrar completes the session, it may send a Logout command to the EPP server to close the connection.

b) Query

APIs provide the query commands such as Check command, Info command and Transfer command to Registrars. Registrars may use these APIs to query information or status about domains, contacts and host objects. (Please refer to Table 25-1 in Q25_attachment)

The Check command is used by Registrars to check the existence of the queried data objects (domain names, contacts or hosts).

The Info command is used by Registrars to retrieve the detailed information about domain names, contacts or hosts that exist in the Registry.

The Transfer command is used by Registrars to check the current transfer status of domain names and contacts.

In addition to the above-mentioned commands, Registrars may also use the Poll command to query and retrieve the asynchronously queued service messages from the EPP server.

c) Object Change

APIs provide several object change commands to Registrars. Through these commands, Registrars may create, modify, delete and perform other operations on domain names, contacts or hosts. (Please refer to Table 25-2 in Q25_attachment)

The Create, Update and Delete commands are used by Registrars to perform basic management functions on domain names, contacts and hosts.

The Renew command is used by Registrars to renew a domain name.

The Transfer command is used by Registrars to transfer domain names or contacts.

The Restore command is closely related to the redemption grace period. When a domain name is deleted, its EPP status is ʺpendingDeleteʺ and the RGP status is ʺredemptionPeriodʺ. Registrars are allowed to restore the deleted domain names to the normal state via the Restore command (Restore is not an EPP command in fact; it is implemented by the extended Update command).

d) Miscellaneous

KSRP ensures that all the APIs comply with RFC 3915 and RFC 5910 to support not only redemption grace period operation such as registry grace period and renew grace period but also DNSSEC.
During the add, renew, or transfer grace period, if a Registrars deletes a domain name, the cost incurred will be refunded to the Registrar by the Registry.

If a domain name expires, the Registry will determine whether to auto-renew a Registrarʹs account and enter the auto-renew grace period based on its account balance. If the Registrar deletes the domain name during the period, the renewal fee incurred will be refunded by the Registry.
Regarding the support for DNSSEC, Registrars may submit the information of Delegation Signer to the Registry over EPP and perform modification and deletion operations.

25.4. Compatibility

The interfaces of KSRP for Registrars comply with EPP1.0 as defined by IETF RFCs and support DNSSEC and redemption period functions.

25.4.1. Compliance with RFCs

The interfaces for Registrars mainly follow the RFCs 5730～5734 and RFC 3915. If the standard EPP canʹt meet certain specific business requirements, extensions will be made to KSRP based on RFC 3735.

a) Compliance with RFC 5730

RFC 5730 is an overall description of the EPP, mainly defining the EPP message format, result code and date format. KSRP strictly follows the RFC as the basis for its EPP implementation.

b) Compliance with RFC 5731

KSRP complies with RFC 5731 in implementing the domain-related command, such as Create, Modify, Delete, Check, Transfer and Info.

c) Compliance with RFC 5732

KSRP complies with RFC 5732 in implementing the host-related commands, such as Create, Update, Delete, Check, and Info.

d) Compliance with RFC 5733

KSRP complies with RFC 5733 in implementing the contact-related commands, such as Create, Update, Delete, Check, and Info.

e) Compliance with RFC 5734

KSRP complies with RFC 5734 in implementing TCP-based EPP and performs certificate-based authentication via TLS to ensure the data security.

f) Compliance with RFC 5735

Depending on the TMCH (Trademark Clearing House) and corresponding Sunrise requirements, KSRP will strictly follow the RFC 5735 and the requirements specified in the agreement and specifications in ICANNʹs Registry Agreement to produce an implementation to support TMCH and Sunrise EPP transactions.

25.4.2. Specification Related to Redemption Period (RFC 3915)

KSRP complies with the RFC 3915 in implementing the registration life cycle policy, including add grace period, renew grace period, transfer grace period and auto-renew grace period, as well as the corresponding statuses.

25.4.3. Specification Related to DNSSEC (RFC 5910)

KSRP complies with RFC 5910 and RFCs 4033～4035 in implementing support for DNSSEC and enabling Registrars to submit their DS record to the Registry and to perform the modification and deletion operations.

25.5. Consistency

25.5.1. Consistency with Technical Plan

The SRS of KSRP fully implements EPP1.0, covering all functionalities required by the domain name registry services. Moreover, it provides Registrars with the fully tested EPP client and detailed documentation of its APIs.

25.6. Resourcing Plan

The development and test work for the SRS has been completed. In addition, the OT&E (Operational Testing and Evaluation) environment is also made available at ote.tld.knet.cn via port 3121. Please refer to Table 25-3 in Q25_attachment for the resourcing plan.

26.1. Overview

The Registry provides Whois services to the public through KSRP by KNET. The Whois system of KSRP is implemented in accordance with RFC 3912 and other requirements specified in Specification 4 of the Registry Agreement. It meets the SLR indicators specified in Specification 10 in terms of performance and availability, and provides scalability for growth.

26.1.1. Software Architecture

For the diagram of software architecture of Whois, please refer to Figure 26-1 in Q26_attachment. Below is the detailed description.

The Whois system consists of the Whois server and the Whois web server, which can be accessed from either command-line or web. The command line query requests directly access the Whois server while the web-based query requests access the web page on the Whois web server.

a) Full-text Search System

The full-text search system provides the searchable Whois functions via the Apache Solr. It scans the Whois database every 10 minutes. If there are any data changes, the search system will update the search indices accordingly.

b) Database

The SRS master database synchronizes only the data fields required by the Whois system to the Whois database via Oracle Advanced Replication. Any sensitive data that may leak privacy information of Registrants or Registrars or are prohibited by local laws and regulations are not replicated.

26.1.2. Physical Architecture

For the physical architecture of Whois, please refer to Figure 26-2 in Q26_attachment. Below is the detailed description.

The Whois server and Whois web server are redundantly deployed on multiple servers that are load balanced behind the F5s.

The full-text search service is deployed on master and slave servers. The master server synchronizes data and changes indices with the Whois database. It then synchronizes the changed indices and data to several slave servers. These slave servers are clustered behind the load balancer (F5) to provide searchable Whois services.

There are multiple Whois servers that are behind the load balancer (F5) to achieve load balancing and high availability.

26.1.3. Equipment List

See the Table 26-1 in Q26_attachment for a list of equipment of the Whois system (excluding any hardware equipment appeared in the network topological diagram of the primary data center):

26.2. Operations Plan

26.2.1. Availability

The KSRP has adopted the following measures to ensure high availability of the Whois system.

a) The hardware equipment and software systems used for the Whois system are redundantly deployed as server clusters that are load balanced behind the F5s.

b) The Whois system is redundantly deployed at the backup data center. In case of any unexpected disasters, KSRP can be switched over the backup data center within 30 minutes to continue its Whois services.

KSRP ensures that the downtime due to outages will not exceed 43.2 minutes monthly, with a high service availability of 99.9%, exceeding the SLA indicator (98%) specified in Specification 10 of the Registry Agreement.

26.2.2. Performance

It is estimated that 10,000 domain names will be delegated under the ʺ.顶级域名ʺ TLD within 3 years after its launch and when the registration volume reaches such target point, there will be 20,000 queries a day . KSRP is designed to scale to handle 30 million domains. The performance test results shows that KSRPʹs Whois system is capable of handling 5000 queries per second or about 430 million queries a day with the maximum response time not exceeding 1150ms.

As a result, KSRP exceeds the performance indicator of the Whois system specified by ICANN and is scalable for future demands.

See the Table 26-2 in Q26_attachment for the contrast between the test data of the Whois system and the SLR indicators specified in Specification 10.

26.2.3. Scalability

The Whois system supports both vertical and horizontal scalability. When KSRP reaches its maximum domain name capacity, the performance and throughput capacity of the Whois system can be expanded by upgrading production server hardware (vertical scalability) and⁄or adding more servers and bandwidth (horizontal scalability).

26.2.4. Data Synchronization

Data in the SRS database are synchronized to the Whois database via Oracle Advanced Replication at an interval of 5 minutes; the changed data of Whois database are synchronized to the full-text search system at an interval of 10 minutes.

Given the above data synchronization intervals, the command-line query requests and the web-based query requests have a latency of about 5 minutes, and the searchable query has a latency of about 20 minutes. Both latencies fully meet the Whois data update time (a latency of 60 minutes) specified in Specification 10.

26.2.5. Searchable Whois

KSRP implements the searchable Whois function via the full-text search technology of Apache Solr. The user logs on to the page specified by the Whois Web Server after passing the ID authentication, and inputs the query criteria as required in Specification 4; the Whois Web Server will forward the query request to the full-text search system which searches and returns the qualified results to the result page of the Whois Web Server.

How to Prevent Abuse:

The searchable Whois function may be abused by malicious users to send spam to the Registrants or Registrars by harvesting email addresses from the query result. Such abuses may cause negative impacts on the Registrants and Registrars that may violate local laws and policies.

The Registry will take the following measures to prevent the searchable Whois function from abuses without violating local laws and policies:
a) The user must input the correct CAPTCHA before submitting each searchable Whois query request.
b) Only those insensitive contents meeting Specification 4 are allowed to be displayed in query results.
c) No more than 20 results are allowed to return for each searchable Whois query.
d) Impose a cap on the maximum number of queries in unit time from the same IP address.

Furthermore, clear disclaimers and warning notifications will be included in Whois responses to deter users from abusing the information.

26.3. Compliance with Relevant Specifications

26.3.1. Compliance with RFC 3912

The Whois system complies with RFC 3912 and listens to port 43.The client interacts with the Whois Server via TCP to complete the request-response process: the Client submits a text-based request to the Whois server; the Whois server then returns the query result in a text-based response to the Client.

26.3.2. Compliance with Specification 4 of the Registry Agreement

KSRP fully complies with Specification 4 of the Registry Agreement in terms of Whois query, zone file access and bulk registration data access.

a) Whois Query

The Whois system fully meets the relevant requirements specified in Specification 4 in terms of data objects (domain name, Registrar and name server), contents, queries and response format.

The Whois system provides two query methods: command line query and web-based query. The former is implemented according to RFC 3912 where the client interacts with the Whois Server in a request-response pattern. The latter is implemented as follows: the user accesses a specified page, inputs the query contents, selects query criteria (domain name, Registrar, name server), types in a CAPTCHA and then submit the query request. After receiving the request, the Whois Web Server will check the CAPTCHA. If the code matches, the Whois Web Server will retrieve the query result from the Whois Server and show the response content to the users in the resulting page.

b) Zone File Access

The Registry allows third-party entities who enter into an agreement with the Registry to access the zone file through KSRP according to Specification 4 of the New gTLD Registry Agreement. It also provides ICANN or other ICANN designated partners with bulk access to authoritative zone files in the format and manner as specified in Specification 4.

c) Bulk Registration Data Access

The Registry will provide ICANN with registration data at specified times through KSRP. The content and format of provided data completely comply with the applicable requirements in Specification 4.

Moreover, when a Registrar is no longer able to provide the domain registry services, the Registry will submit all domain name data owned by that Registrar to ICANN within the specified period. The content and format of provided data completely complies with ICANN requirements.

26.4. Resourcing Plan

The development and test work for the Whois system of the KSRP has been completed. See section 31.12.2 for the overall human resource planning of KSRP. For the resourcing plan of this system, please refer to Table 26-3 in Q26_attachment and the above 26.1.3 for equipment resource planning.

27.1. Overview

The Registry defines the life cycle of the domain names under based on IETF RFCs required by ICANN, the general ICANN gTLD lifecycle (http:⁄⁄archive.icann.org⁄en⁄registrars⁄gtld-lifecycle.jpg) and its own business needs. The life cycle consists of 6 periods: Available, Pre-audit, Registered, Autorenew Period, Redemption Grace Period and Pending Delete.

Pre-audit is a new period added by the Registry to ensure that domain name registration complies with local policies and laws as well as to support Sunrise processes and the activation of Reserved Names, especially in relation to #22. A domain name first enters the Pre-audit period upon creation (the EPP status is pendingCreate, and the RGP status is N⁄A). After manually examined by the Registry, the domain name officially takes effect and enters the Registered period (the EPP status is serverTransferProhibited for the first 60 days, afterwards, it changes to ok; the RGP status is addPeriod for the first 5 days and then changes to N⁄A ). It takes no more than 3 days for a domain to be manually examined after creation.

Please refer to Figure 27-1 in Q27_attachment for the full life cycle of a domain name, covering the periods such as creation, taking effect, expiry and final deletion.

27.2. Registration Life Cycle and Status

There are totally 18 registration statuses defined for EPP in RFCs 5730～5734 and for RGP in RFC 3915, excluding those that can be set by Registrars, such as:
clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited).

The EPP statuses include:
OK, inactive, pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate, serverHold, serverDeleteProhibited, serverRenewProhibited, serverTransferProhibited, and serverUpdateProhibited.

The RGP statuses defined in RFC 3915 include:
addPeriod, autoRenewPeriod, renewPeriod, redemptionPeriod, transferPeriod, pendingRestore, and pendingDelete.

27.2.1. Transition of Registration Status

During the whole registration life cycle, the registration status of the domain name evolves as a result of the life cycle period changes and the operations performed. Please refer to Figure 27-2 in Q27_attachment for the registration status transition in creation and deletion period of life cycle.
Other operations may affect registration status transition in the life cycle as follows:

a) Update Operation

The Update operation may only be performed on a domain name that is in the Registered period. After the operation, the RGP status remains unchanged; the EPP status is either added with pendingUpdate (for the first 60 days) or is changed to pendingUpdate. After the operation Update is done, the pendingUpdate status will be removed and the EPP status changes back to the previous one.

b) Renewal Operation

The Renewal operation may be performed on a domain name that is in either the Registered or the Auto-renew period.

When a domain name enters the Registered period, the EPP status is changed to pendingRenew (the previous status is ok) or is added with pendingRenew. After the operation Renewal is done, the EPP status changes back to the previous one. The RGP status changes to renewPeriod; it will change back to its previous status 5 days later.

When a domain name enters the Auto-renew period, the EPP status changes to ok, and the RGP status changes to renewPeriod; it changes back to ʺN⁄Aʺ 5 days later.

c) Transfer Operation

The operation Transfer may only be performed on a domain name that is in the Registered period and has been registered for more than 60 days. After the operation is performed, the EPP status changes to pendingTransfer; it will change back to its previous status once the transfer is complete. Thereupon RGP status changes to transferPeriod; it will change back to its previous status 5 days later.

d) Restore Operation

The operation Restore may only be performed on a domain name that is in the Redemption Grace Period. Once the Registrar submits a restore request, the RGP status of the domain name changes to pendingRestore; if a formal restoration report is submitted within 7 days, the domain name changes back to its normal registration status (EPP: ok; RGP: N⁄A), otherwise, the registration status of the domain name changes back to the previous one.

27.2.2. Description of Status Transition

For each life cycle period of a domain name, the registration status transition is listed as below:

a) serverHold: all operations on a domain name are forbidden and the domain name canʹt be normally resolved.

In the Registered Period, if the Registry receives any complaint about that domain name, it will set the domain nameʹs EPP status to serverHold. If relevant competent authority confirms that the domain name is being abused or engaged in fraud, the domain nameʹs EPP and RGP statuses will be set to pendingDelete and the domain name will be transitioned to the Pending Delete period. Otherwise, the Registry will restore the domain nameʹs EPP status to ok and reset the RGP status to ʺN⁄Aʺ.

b) serverTransferProhibited: the domain name may be renewed, modified or deleted but not transferred.

When a domain name is in the Registered period, the EPP status for the first 60 days is serverTransferProhibited. If the Registrar submits any Update request, pendingUpdate is added to the EPP status. When the Update is complete, the EPP status changes back to serverTransferProhibited. If the Registrar renews this domain name, its EPP status remains unchanged and the RGP status is added with renewPeriod which will be cancelled 5 days later. If the Registrar deletes the domain name, both the EPP status and the RGP status change to pendingDelete.

When a domain name is in Autorenew Period, the EPP status is OK, and the RGP status is autoRenewPeriod. After 45 days, if the Registrar doesnʹt make a deletion request, the EPP status changes to ok and the RGP status is cancelled; if the Registrar does make a deletion request within the 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod and will be cancelled 5 days later.

c) serverUpdateProhibied: a domain name may be renewed, transferred or deleted but not updated.

When a domain name is in the Autorenew Period, the EPP status is serverUpdateProhibited and serverTransferProhibited, and the RGP status is autoRenewPeriod. If the Registrar doesnʹt make a deletion request within 45 days, the EPP status changes to ok and the RGP status is cancelled. If the Registrar does make a deletion request within 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod, which will be cancelled after 5 days.

d) serverRenewProhibited: a domain name may be updated, transferred or deleted but not renewed.

e) ok: a domain name may be updated, renewed, transferred and deleted.

If the Registrar makes a transfer request, the EPP status changes to pendingTransfer,; it will change back to ok after the transfer operation is complete. The RGP status is set to transferPeriod that will last for 5 days.

If the Registrar makes a deletion request, the EPP status changes to pendingDelete and the RGP status is set to pendingDelete.

If there is any complaint about the improper use of the domain name, the EPP status changes to serverHold. If the domain name is confirmed to be free from any abuse or fraud, the EPP status changes back to ok; otherwise, both EPP and RGP statuses change to pendingDelete.

f) inactive: within this status, the domain name is not associated with a host and thus canʹt be resolved.

If the Registrar submits a deletion request, the EPP status changes to pendingDelete and the RGP status changes to pendingDelete. The domain name will be deleted after 5 days.

If the Registrar submits an update request to associate the domain name with a host, the EPP status changes to ok.

g) pendingDelete: with this status, the domain name can neither be resolved, nor can it be updated or transferred.

If a domain name is in the Pre-audit or Registered period or its EPP status is inactive or serverHold when the deletion operation is being performed, the EPP status changes to pendingDelete. The RGP status is set to pendingDelete. The domain name will be deleted after 5 days.

If a domain name is in the Autorenew Period when the deletion operation is being performed, the EPP status changes to pendingDelete, and the RGP status is set to redemptionPeriod.

h) pendingTransfer: this status indicates that the domain transfer request has been accepted.

With this status, no update, renew, or delete operation can be performed on the domain name although the domain name is resolvable in DNS. After the transfer is complete, the EPP status changes back to its previous status. The RGP status is set to transferPeriod, which will be cancelled after 5 days.

i) addPeriod: the RGP status is set to addPeriod for the first 5 days after a domain name enters the Registered period. After 5 days, the RGP status is cancelled. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.

j) renewPeriod: when a domain renewal request is submitted, the RGP status changes to renewPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.

k) transferPeriod: when a domain name transfer request is submitted, the RGP status changes to transferPeriod of 5 days.

After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, fees resulting from transfer will be refunded.

l) autoRenewPeriod: the RGP status of a domain name when it is in the Autorenew period.

If the Registrarʹs account has enough money for renewal after the domain expires, the RGP status changes to autoRenewPeriod and the domain name will be automatically renewed for 1 year. The Autorenew period lasts for 45 days. If the Registrar doesnʹt delete the domain name or does perform the renewal operation after 45 days, the domain name returns to the Registered period and the RGP status is cancelled; otherwise the RGP status changes to redemptionPeriod.

m) redemptionPeriod: the RGP status of a domain when it is in the Redemption period.

If the Registrar submits a restore request, the RGP status changes to pendingRestore, otherwise, it changes to pendingDelete after 30 days.

n) pendingRestore: an intermediate status only applicable to domain names in the Redemption period of a domain name.

When a domain name is in the Redemption period, if the Registrar submits a restore request to the Registry within 30 days, the RGP status changes to pendingRestore. If the Registrar submits a formal restore request report to the Registry within the subsequent 7 days, the EPP status changes to ok and the RGP status is cancelled; otherwise the RGP status changes back to redemptionPeriod. If the Registrar doesnʹt perform any restore and⁄or renewal operations within 30 days, the RGP status changes to pendingDelete.

o) pendingCreate: With this status, a domain name cannot be resolved; nor can any operation be performed on it.

After the registration request of a domain name is submitted, the domain name enters the Pre-audit period with the EPP status being pendingCreate and the RGP status being N⁄A. After the registration request passes auditing, the domain enters the Registered period; the EPP status changes to serverTransferProhibited and the RGP status is set to addPeriod. If the request doesnʹt pass auditing, the Registry rejects the application and deletes the domain registration. In this case, the domain name changes back to the Available period.

p) pendingRenew, pendingUpdate: these two statuses are not applicable. The Registry intends to deploy an auto-renewal approach according to the ICANN policies and updates are performed in real time, so there is no manual review or the third partyʹs verification.

27.3. Compliance with RFCs

Taking the local policies and laws as well as Sunrise, TMCH, activation of reserved names and its own businesses needs into account, the Registry makes some extension for the registration life cycle of the domain name based on RFCs 5730～5734 and RFC 3915.

27.4. Consistency

27.4.1. Commitment to Registrant

The Registry Operator signs agreements with Registrants via the Registrars. These agreements strictly follow the policies of registration life cycle and provide management functions for domain names as directed by ICANNʹs requirements, agreements and regulations.

27.4.2. Technical Plan

For SRS, the EPP status can be used to determine whether a domain name can be updated, renewed, transferred or deleted, etc. The SRS fully supports redemption grace period operations defined in the RFC 3915 using the RGP status;

For DNS, the EPP status of a domain name is needed to determine whether the domain name is deployed in the root DNS zone file. It is also used to decide whether DNS service will be provided to the domain name.

For Whois, the EPP and RGP statuses of a domain name will be shown to the user in the query results.

27.5. Resourcing Plan

Please refer to Table 27-1 in Q27_attachment for the resourcing plan.