ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Xinhua News Agency Guangdong Branch 新华通讯社广东分社

String: 广东

Originally Posted: 13 June 2012

Application ID: 1-1309-35206


Applicant Information


1. Full legal name

Xinhua News Agency Guangdong Branch 新华通讯社广东分社

2. Address of the principal place of business

No.158 Lianxin Road, Yuexiu District
Guangzhou City Guangdong Province CN
CN

3. Phone number

+86 20 83330567

4. Fax number

+86 20 83317977

5. If applicable, website or URL

http:⁄⁄www.gd.xinhua.org

Primary Contact


6(a). Name

Mr. Edmon Chung

6(b). Title

Director Representative

6(c). Address


6(d). Phone Number

+852 3520 2635

6(e). Fax Number


6(f). Email Address

info@tld.asia

Secondary Contact


7(a). Name

Ms. Rebecca Chan

7(b). Title

Company Secretary

7(c). Address


7(d). Phone Number

+852 3520 2635

7(e). Fax Number


7(f). Email Address

rebecca@dot.asia

Proof of Legal Establishment


8(a). Legal form of the Applicant

Institutional Organization

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

Guangdong Province of China

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

Attachments are not displayed on this form.

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


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

Xinhua News Agency

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


Applicant Background


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


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


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


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

Ding ShaDirector
Yang ChunnanPresident
Yang NingningOfficer

Applied-for gTLD string


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

广东

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

xn--xhq521b

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

Guangdong

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

Chinese

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

ZH

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

Han (Hanzi, Kanji, Hanja) [Han (Simplified variant)]

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

Hani 500 [Hans (501)]

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

U+5E7F;U+4E1C

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

Attachments are not displayed on this form.

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

The IDN tables included for the applied for TLD are based on the CDNC IDN Language tables from CNNIC (zh-CN: http:⁄⁄www.iana.org⁄domains⁄idn-tables⁄tables⁄cn_zh-cn_4.0.html) and TWNIC (zh-TW: http:⁄⁄www.iana.org⁄domains⁄idn-tables⁄tables⁄tw_zh-tw_4.0.1.html) respectively.

The implementation of the two IDN tables is based on the .ASIA ZH IDN Language Policies for gTLDs and IDN related issues for this TLD have been developed with assistance from DotAsia Organisation.  The language table is developed for the implementation of Chinese IDN registrations at a gTLD in coordination with the CDNC (Chinese Domain Name Consortium), based on 

The source references for these tables include:
a)	Unicode Tables Version 3.2
b)	A Complete Set of Simplified Chinese Characters 
c)	Chinese Variants Collation Table 
d)	Chinese Big Dictionary 
e)	Chinese Relationship Table for Unihan Project 
f)	Chinese Standard GB2312 
g)	General Table for Modern Chinese 
h)	International Chinese Standard Big Dictionary 
i)	Unihan Database Reference
j)	Big5 character encoding standard

The Registry understands the importance of maintaining the integrity of Chinese IDN registrations through appropriate implementation of character variants for Simplified Chinese (SC) and Traditional Chinese (TC). Unlike in the case of ccTLDs (e.g. for .CN or .TW) where one form of the Chinese characters is predominantly used, a gTLD is inherently global and requires the consideration of an environment where some of the users will be using SC (e.g. in Mainland China, Singapore, etc.), while others may be using TC (e.g. in Hong Kong, Macau, Taipei, etc.).

Therefore, the implementation incorporates both the zh-CN and zh-TW tables.  More specifically, when generating IDN Variants, the Preferred Variants from both tables will be generated: one corresponding to the zh-CN Preferred Variant column, i.e. Preferred Simplified Variant; and the other correspodning to the zh-TW Preferred Variant column, i.e. Preferred Traditional Variant.

The tables are compliant with the RFC3743-defined format, and is in compliance with CDNC policies, and the ICANN Guidelines for IDN registration and for publication in the IANA Repository of IDN Practices.

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

In accordance with the submitted table in 15(a), there is one preferred variant for the applied for gTLD string:

Extracting from the IDN Language Table:
Base Char	Preferred Variant (zh-CN)	Preferred Variant (zh-TW)	 Character Variant(s)
U+5E7F 广	U+5E7F 广			U+5EE3 廣			U+5E83 広
U+4E1C 东	U+4E1C 东			U+6771 東

With the primary string: “广东” therefore, the Preferred IDN Variant that should be included in the DNS is:
U-Label:	廣東
A-Label:	xn--nzt73q
Unicode:	U+5EE3;U+6771
Language:	Chinese
ISO639-1:	ZH
Script:		Han (Hanzi, Kanji, Hanja) [Han (Traditional variant)]
ISO15924:	Hani 500 [Hant (502)]

By permutation utilizing the CDNC IDN language table as provided in 15a above, four (4) other IDN Variants that should be reserved are:
“广東” (A-Label: xn--swt02r)
“広东” (A-Label: xn--xhqs31b)
“広東” (A-Label: xn--wwts2r)
“廣东” (A-Label: xn--xhqv22b)

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

The Registry anticipates the introduction of this TLD without operational or rendering problems other than general Universal TLD Acceptance issues. 

The Registry worked closely with KNET, the subsidiary of CNNIC, the IDN operator of .China, and DotAsia Organisation in the assessment of operational and⁄or rendering issues pertaining this TLD. Both KNET and DotAsia are experienced with IDN technologies and policy implementation for TLDs. Based on historical records of CNNIC, there have not been operational and rendering problems for IDN TLDs.

The TLD was reviewed and tested to determine that no additional operational, rendering or other general usability issues exist. Furthermore, the IDN tables and variant handling mechanisms have been time tested with the decade long implementation of Chinese IDN in China.  The string was also tested utilizing the string similarity assessment methodologies against any existing TLDs, ISO3166 strings as well as IDN ccTLDs.  The Registry, along with its partners believes that the TLD string will be a trusted and secure extension for Internet addresses.

Understanding the nature of the protocol implementation for IDNs, some known operational, usability and rendering problems are to be expected:

1. Application Support: While IDN resolves properly, not all applications are IDN-aware and some applications (e.g. browsers) consider A-Label leakage as a feature rather than a bug. Users may find it confusing when the A-Label is presented.  Other applications, such as online forms, databases, spam filters, etc. may not accept U-Label strings.  DotAsia and KNET is committed to support the work in reaching out to application providers for their full compliance on IDN to mitigate against these issues.

2. Universal Acceptance of TLDs: Certain applications and network devices contain TLD filters that may refer to set lists or restrictive algorithms causing new TLDs to be regarded as mal-formed domains.  DotAsia and KNET participates in the community wide initiatives to promote Universal Acceptance.

3. IDN in Email Addresses: The EAI (Email Address Internationalization) efforts are ongoing and not all email software providers have implemented support for IDN TLDs.

In addition to known presentation⁄display and application compliance issues, Chinese characters are often typed utilizing multiple keystrokes on a standard ASCII based keyboard. The following includes the keystrokes for 3 of the most common input methods for Chinese:

Pinyin: guangdong

Cangjie (倉頡): XIKD (ITMCDW)
XI: 广 (ITMC: 廣)
KD: 东 (DW: 東)

Wubizixing (五笔字型输入法): OYGTAII (OAMWSJD)
OYGT: 广 (OAMW: 廣)
AII: 东 (SJD: 東)

None of the input methods (for either the applied for TLD or the IDN Variant TLD) or the A-Label (xn--xhq521b) of the applied for the string combine to form a string coinciding with any meaningful string (except “guangdong” which is the romanized representation of “广东”).

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

广东 | Pinyin: guǎng dōng | Bopomofo: 	ㄍㄨㄤˇ ㄉㄨㄥ | IPA: ⁄kuɑ̃ŋ tuŋ⁄

Mission/Purpose


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

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


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

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.

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

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.

Community-based Designation


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

Yes

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

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.

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

The Registry intends to remain independent to serve the community.  However, the Registry will work closely with community organizations and will invite community organizations in its policy development processes.  Furthermore, the Applicant is official government agency of the Guangdong province.


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

Please refer to sections 18(a) and (b) above.

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

The TLD string matches perfectly the name of the community and has no other significant meaning beyond identifying the community.

1. Name

The Chinese name “广东” is the name by which the community is predominantly known by others.  A modern abbreviation 粤⁄粵 (Yue) is sometimes used.  The English name “Guangdong” is popularized after the introduction of the Hanyu Pinyin.  The region has been associated with “Canton” or “Kwangtung” previously as well.

Nevertheless, the chosen TLD string “.广东” is the most appropriate name for the community.

2. Identity

The TLD string “.广东” closely describes the community and the community members and do not reach beyond the community.

3. Nexus

The applied for string is commonly known by others as the identification of the community.  The Chinese name “广东” is almost the only name used by others as the name of the community. “Guangdong” is the only English name (in Pinyin) currently used by others as the name of the community within the geographic region.  Both of which represents a noun that the typical community member would naturally be called in the context.

4. Uniqueness

The TLD string “.广东” has no other meaning beyond the identification of the geographic region and the community.


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

Above and beyond the requirements set out in Specification 7 of the new gTLD registry agreement, special Sunrise and startup policies will be developed to provide priority registration opportunities for community members.  Furthermore, the feasibility of additional dispute resolution processes in addition to (and not in replacement of) the basic UDRP and URS processes, that takes into consideration the nature of the TLD in relation to the community it serves will be studied.

Upon normal registry operations after GoLive, the registry intends to maintain an open platform allowing individuals and companies from around the world meeting basic eligibility requirements as required by ICANN to register and utilize the TLD (e.g. must provide contact information, must provide 2 name servers for activation in DNS, etc.), and the TLD Charter Eligibility Requirement further description below.

A. Eligibility

The Registry will be working closely with DotAsia (through Namesphere) to put in place appropriate Charter Eligibility Requirements for the TLD. The requirements can be expected to be based on the successfully implemented .ASIA Charter Eligibility Requirements Policy (http:⁄⁄dot.asia⁄policies⁄DotAsia-Charter-Eligibility--COMPLETE-2010-09-01.pdf).  Conceptually, one of the contacts of the domain registration must reside in the community.

Special Sunrise phases will be introduced to provide priority registration opportunities for community members in addition to the standard Sunrise, TMCH and Trademark Claims processes according to Specification 7 of the new gTLD registry agreement.  See response to #29 for further details.

Through Sunrise, Landrush and Go Live, registrants must meet the Charter Eligibility Requirements to register a domain name under the TLD.  Nevertheless, part of the vision of the Registry is to promote Guangdong into a global high tech community, therefore, the requirements are put in place to ensure the stability and orderly introduction of the TLD without trying to be overly restrictive for the fulfilment of its purpose of being an open platform globally.  Therefore, any individual or organisation can be a registrant provided that they fulfil the eligibility requirement is met.

B. Name Selection

The utilization of the TLD itself already identifies the registrant’s relationship with the community.  Therefore, the use of the TLD by a registrant fulfills the community-based purpose and registrants are free to choose the second level domain for registration under the TLD.

During Sunrise, name selection is restricted to those corresponding to their registered prior rights.

C. Content and Use

Registrants are encouraged to 

Abusive content or infringing content are addressed by Abuse Prevention and Mitigation measures (#28) and Rights Protection Mechanisms (#29) that will be put in place by the Registry.

D. Enforcement

The Registry will randomly sample registrations to request for substantiation of Charter eligibility declaration based on the TLD Charter Eligibility Policies.  Furthermore, the CEDRP (Charter Eligibility Dispute Resolution Policy: http:⁄⁄www.icann.org⁄en⁄help⁄dndr⁄cedrp) will be utilized to further remedy any violations.

For registrants from Mainland China, further whois accuracy requirements (#28) ensure the enforcement of the policies as well.

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

Attachments are not displayed on this form.

Geographic Names


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

Yes

Protection of Geographic Names


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

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.

Registry Services


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

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.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

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. Extensible Provisioning Protocol (EPP)

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

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. Registration Life Cycle

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.

28. Abuse Prevention and Mitigation

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 an update request, the EPP status changes to pendingUpdate; it will change back to ok after the update operation is complete within 3 working days.

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.

29. Rights Protection Mechanisms

The Registry is committed to a comprehensive strategy on Rights Protection Mechanisms (RPM).  The Registry works closely with DotAsia Organisation (through Namesphere) and draws from the successful experience and knowledge of the RPM measures implemented for the .ASIA, especially in its acclaimed Sunrise process and its contributions to rapid suspension policies.

29.1 Sunrise and Startup Processes

A comprehensive Sunrise and startup process is the key to successful RPMs. A successful Sunrise program not only provides priority to rights holders, but also sends a clear message to the market that the TLD is serious about RPMs, thereby further deterring abusive registrations.

The Sunrise process provides for the introduction of the TLD in an orderly and equitable manner. Its purpose is to give reasonable protection and priority to stakeholders and certain prior rights holders, as well as to deter abusive and bad faith registrations. The Sunrise policies are also designed to facilitate reliability for ICANN Accredited Registrars and fair competition amongst registrants. It is intended to create a stable and effective launch and registration process for the benefit of various stakeholders and the Internet community at large.

Learning from the successful experience of the .ASIA sunrise, which achieved 0 disputes and also 100% satisfaction (satisfied or very satisfied) in an online poll of Intellectual Property Rights (IPR) practitioners, the Registry will implement a thorough and multi-phased Sunrise and startup process similar to that of the .ASIA registry.

A comprehensive set of Sunrise policies will be put in place in addition to the standard Sunrise and Trademark Claims services as specified in SPECIFICATION 7: MINIMUM REQUIREMENTS FOR RIGHTS PROTECTION MECHANISMS, of the New gTLD Registry Agreement. The Sunrise policies will follow a similar framework of the .ASIA Sunrise Policies (http:⁄⁄dot.asia⁄policies⁄DotAsia-Sunrise-Policies--COMPLETE-2007-08-10.pdf also included as attached).

29.1.1 Standard Sunrise and Trademark Claims Services

As a basic commitment, the Registry will implement the requirements from Specification 7 of the New gTLD Registry Agreement, and in accordance to the relevant Trademark Clearing House (TMCH) Sunrise and Trademark Claims services.

The Registry believes that these form only the very basic layer of RPM and will therefore add significant measures on top of the standard process to ensure that prior rights of others are not abused.

In terms of Sunrise, Specification 7 and the TMCH descriptions only provide a basic framework for Trademark holders to protect names that are identical to their trademark. The Registry believes that additional protection is important and can be efficiently and effectively put in place with a multi-phased Sunrise program. Further discussion about this is included in 29.1.4 below.

29.1.2 Auction Process

An important part of the success of the .ASIA Sunrise program is the use of auction in the resolution of contention. It is known that many Trademarks are similar or identical because of the different jurisdictions and different classes. Therefore, it is inevitable that there would be some competition among rights holders to certain names. A complete Sunrise program requires a contention resolution mechanism that works to reduce the tension of competition and resolve the issue in a stable and orderly manner.

When the .ASIA Sunrise Auction process was first introduced, the community was worried about possible high prices in the auctions making it costly for trademark holders. The results of the process demonstrate however the original intent prevailed. If a pure first-come-first-served model is used, the tension at the opening of the registry at the Sunrise period would be extremely high. Also, because of the competition, the so-called FCFS approach essentially becomes a lottery and one that favours registrars with systems in closer proximity to the registry servers. The tension and the inherent unjust of the process caused thousands of disputes and litigation in previous launches of TLDs utilizing such an approach.

In the .ASIA Sunrise process, a total of about 30,000 applications were received. Out of which less than 2% ended up in an auction. Furthermore, only about 40% ended up in a contested auction (i.e. that there was more than 1 bid in the auction). What that means is that, while it demonstrated clearly that there is certainly competition among trademark holders, it only represents a very small portion. Also, when there was more than one verified applicant for a Sunrise domain and an auction is setup, many trademark holders elect not to bid for the name. Based on the understanding from DotAsia, it is found that many trademark holders do know that their mark is “shared” by other companies, perhaps in different jurisdiction or in different categories. Their motivation to participate in the Sunrise is to avoid abuse of their mark by other parties. Because in the Sunrise process, before an auction is held, each of the verified applicants will be given the information of the other verified applicants in the auction ahead of time. They therefore know who else is bidding for the name and can evaluate whether the other party may in fact abuse their mark. Knowing that the other party is another legitimate trademark holder who may not be abusing their mark, many of the trademark holders elected not to bid and let the other party win the auction with a nominal bid at $10.

What this illustrates is that the auction process is a very successful tool in reducing the stress of the people and the systems in the launch of a registry. Overall, the average winning price of the auctions in the .ASIA startup process was less than US$200. That represents a significant cost benefit for rights holders in comparison to possible litigation or alternative dispute resolution proceedings.

29.1.3 Sunrise Challenge Process

Besides a contention resolution process, an important part of any Sunrise process is a well developed Sunrise Challenge Process to ensure the integrity of the Sunrise program. The Sunrise Challenge Process is important such that after the allocation of a Sunrise name, there is a period of time where legitimate rights owners can challenge the legitimacy and eligibility of a registrant based on the Sunrise policies to a domain name.

Following again the .ASIA experience, a comprehensive Sunrise Challenge Process will be put in place and a dispute resolution provider will be selected to arbitrate disputes. A sample of the .ASIA Sunrise Challenge Process is included in the Attached.

29.1.4 Additional Protection Mechanisms for Sunrise

In addition to the basic “identical” match of a Trademark to a domain name applied for during the Sunrise period, the Registry intends to follow the successful example of .ASIA to include additional types of matches, for example:
- Exceptions for registered mark (tm, sm, etc.) type or entity type (ltd, inc, etc.) identifiers
- Exceptions for the TLD string (i.e. allowing marks containing the TLD string to omit that substring)
- Considerations for commonly used short forms and omission of locality indications
- Acceptance of standard Romanization and Transliterations for Company Names
- Extended protection for trademarks + the class of the trademark (e.g. “BRAND Shoes” or “BRAND Computers”, etc.)

These considerations allow trademark holders priority registration opportunity to protect names that are important and related to them.

The Registry will also develop specialized phases targeted to provide priority registration periods for the community that the Registry will be primarily serving. For example, in the .ASIA Sunrise, Asian businesses and registered companies are allowed to participate in one of the phases of the Sunrise program ahead of the general availability of the domain. This allowed many Asian businesses who may not have a registered trademark to make use of the Sunrise process to protect their name.

Besides the multitude of provisions for rights holders to participate in the Sunrise process, another important feature of the success of the .ASIA Sunrise program is the inclusion of a built-in reconsideration process. Because of the many applications a trademark holder may need to be filing, especially considering in the future the many new gTLD launches, it is possible that clerical mistakes and errors could be made in the Sunrise application. The .ASIA Sunrise process included a built-in reconsideration and amendment process that was critical to the overall success of the program. The success rate of the .ASIA Sunrise applications was over 90% as compared to other previous Sunrise launches where the success rate may be closer to 50-60%.

This explains the high approval rating of the .ASIA Sunrise program and also the rationale for the Registry to learn from and follow the good example set by .ASIA in the development of its comprehensive Sunrise policies.

29.1.5 Proactive Outreach and Specialized Programs

Furthermore, on top of the Sunrise program, a Pioneer Domains Program will be put in place to provide even further protection for prior rights holders while maintaining a strong balance against users’ rights.

Two features of the Pioneer programs for rights holders include: 1) the ability to apply for typo or other variant forms of their trademark to improve protection; 2) the use of the Pioneer Domains Challenge process to protect against abuse.

Again, following from the success of the .ASIA startup processes, the Registry intends to put in place a Pioneer Domains Program similar to the .ASIA Pioneer Domains Program (http:⁄⁄pioneer.domains.asia⁄ascii⁄policies.html also Attached for reference). Together with the Pioneer Domains Program, a Pioneer Domains Challenge Process will be put in place (http:⁄⁄pioneer.domains.asia⁄ascii⁄challenge.html also Attached for reference).

In short, the Pioneer Domains Program invites potential registrants to submit proposals, explaining how they would use and promote the domain name. Each proposal will require an application fee and prior acknowledgment and acceptance of relevant terms and conditions. Evaluation criteria will take into account the applicantʹs business plan, marketing expertise, and the manner and purposes for which the proposed site would be operated. For Trademark applicants, the evaluation criteria is based on the trademarks filed and the rights holder can also apply for variations relevant to their mark.

29.2 UDRP, URS and other Suspension Processes

While the Startup process, including the multi-phased Sunrise program provides a proactive process for prior rights holders to protect their names under the TLD in a priority registration process, RPMs after the allocation and delegation of a second level domain under the TLD is equally important.

29.2.1 UDRP Implementation

The Registry will comply with and put in place mechanisms to ensure the enforcement of UDRP decisions. These include provisions within the Registry-Registrar Agreements (RRA) with Accredited Registrars to ensure that they have adequate provisions in their Registration agreement with registrants to submit to UDRP proceedings, as well as to work closely with Accredited registrars in the implementation of UDRP decisions and required actions through the URS process.

29.2.2 URS Implementation

The Registry will comply with and put in place mechanisms to ensure the enforcement of URS decisions. These include provisions within the Registry-Registrar Agreements (RRA) with Accredited Registrars to ensure that they have adequate provisions in their Registration agreement with registrants to submit to URS proceedings, as well as to work closely with Accredited registrars in the implementation of URS decisions and required actions through the URS process.

29.2.3 Other Suspension Programs

In addition to the basic dispute and suspension programs, the Abuse Prevention Mechanisms as described in #28 as well as the geographical names reservation processes described in #22, the Registry, following the footsteps of the .ASIA Registry as well, will explore appropriate suspension mechanisms and challenge processes to further improve the protection to prior rights holders.

For example, .ASIA has completed an MoU with the International Federation Against Copyrights Theft Greater China (IFACT-GC), and has explored extensively and works closely with the Anti-Phishing Working Group on possible alternative rapid suspension processes against gross copyright infringement and phishing sites. These discussions also helped inform some of the discussions that lead to the development of the URS.

Given the focus of the TLD, the Registry will also consider and explore adopting other relevant forums for domain dispute resolution. For example, the Registry may explore the adoption of relevant ccTLD dispute resolution processes or any other industry arbitration processes relevant to the use to broaden the protection of the legitimate prior rights of others in the registration of domain names in the TLD. These measures will be put in place in addition to and definitely not in replacement of the basic requirements of submitting to UDRP, URS and other ICANN policies.

29.2.4 Post-Delegation Dispute Resolution Process (PDDRP)

While the Registry is confident that its processes and policies will be effective in curbing abusive registrations, and that it has the knowledge and capabilities to implement and enforce such measures, the Registry is fully prepared to work with ICANN should a PDDRP be initiated.

The Registry fully submits to the process and, along with its Backend Registry Services Provider as well as Front End Registry Services Provider, will comply with all ICANN requirements through a PDDRP.

29.3 Meeting & Exceeding Requirements

29.3.1 Capabilities and Knowledge

The Registry is supported by Namesphere as the Front-End Services provider, and works closely with DotAsia Organisation (through Namesphere) to develop the Sunrise and Startup processes as well as agreements and other administrative proceedings to ensure effective, efficient and implementable enforcement of such policies and processes.

DotAsia has significant knowledge and expertise in the development and successful implementation of Sunrise and RPM policies, as demonstrated by the successful launch of the .ASIA TLD. A dedicated team comprised of DotAsia, the Registry and our Registry Back-End Services Provider KNET will be convened to ensure that policy as well as technical capabilities are in place to support the RPMs.

29.3.2 Compliance with Specification 7

The Registry is committed to comply with Specification 7 of the New gTLD Registry Agreement, and plans to implement additional RPM on top of the basic requirements of Specification 7.

29.3.3 Plans for Meeting Compliance with Contractual Requirements

The Registry, along with its Front-End Services Provider and Back-End Services Provider will work to ensure that contractual compliance is met. Besides the basic requirements in Specification 7, the Registry intends to consult with ICANN through the process as additional RPMs are put in place to ensure that they also comply with contractual requirements. With the strong experience from our partners, especially from DotAsia, the Registry can be assured that it will meet and comply with all the ICANN contractual requirements.

29.3.4 Consistency with Technical, Operational and Financial Approach

The use of pendingCreate along with other registry system features ensure that Sunrise and other startup processes could be processed in a standards based manner. In addition, DotAsia has helped to work out an open EPP extension for the implementation of Sunrise applications:

These EPP Extensions include:
• An 〈ipr:name〉 element that indicates the name of Registered Mark.
• An 〈ipr:number〉 element that indicates the registration number of the IPR.
• An 〈ipr:ccLocality〉 element that indicates the origin for which the IPR is established (a national or international trademark registry).
• An 〈ipr:entitlement〉 element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
• An 〈ipr:appDate〉 element that indicates the date the Registered Mark was applied for.
• An 〈ipr:regDate〉 element that indicates the date the Registered Mark was issued and registered.
• An 〈ipr:class〉 element that indicates the class of the registered mark.
• An 〈ipr:type〉 element that indicates the Sunrise phase the application applies for.

Note that some of these extensions might be subject to change based on ICANN-developed requirements for the Trademark Clearinghouse and also specific implementation of the Sunrise process at the Registry.

29.3.5 Committed Resource to Carry out plans

Both KNET and Namesphere as the Registry Back-End and Registry Front-End Services provider respectively have teams prepared and dedicated with capacity and capability to implement a comprehensive Sunrise and Startup process as well as the additional RPM measures that the Registry intends to put in place.

29.3.6 Rights Protection as A Core Objective

Based on the in depth discussion and commitment to the multitude of RPM features as well as a multi-phased startup process to ensure the stable and orderly introduction of the TLD, the Registry believes that it has demonstrated its commitment to rights protection as a core objective.

Beyond RPMs, the comprehensive geographical names protection program as explained in #22 further demonstrates the dedication of the Registry towards the protection of the prior rights of others.

29.3.7 Effective Mechanisms in Addition to Requirements in Registry Agreement

The policies and processes proposed by the Registry are proven and time tested to be effective in curbing abusive registrations. The .ASIA sunrise processes were highly regarded by the industry and yielded 100% satisfaction rating from an online poll of Intellectual Property Rights practitioners.

Much of the approach has been tested and proven successful through the launch of the .ASIA TLD. The success of the process can be observed by the imitation or following of the processes, including the multi-phased startup, the auction based contention resolution, as well as the Pioneer Domains Program (i.e. an Request for proposal -- RFP -- type process) are now commonly used processes when a TLD is launched or certain section of names are released by a TLD (e.g. 1 and 2 character names in existing gTLDs).


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

30A.	Security Policy

The Registry has selected KNET as the back-end service platform. To ensure security, KNET has implemented the KSRP system in accordance to the internationally accepted ISO 27000, with full consideration of the security aspects of services and data as required by ICANN.

30A.1. Description of Information Security Policies

KSRP is built to achieve the following goals in accordance with ISO 27000:

a) Ensure that the information system supporting critical businesses is free from any outage resulted from failure, virus or attacks. The service level meets the committed SLA;

b) Safely and effectively protect the user information so that it will not be leaked, missing, falsified and unavailable;

c) Be able to rapidly, effectively and properly recover the system platform from any disaster.

To meet these goals, KNET has implemented the information security management policies in accordance with ISO 27000 in the following 12 aspects:
a) Assets security management
b) Human resources security
c) Physical and environmental security
d) Operation regulations
e) Storage media management
f) Backup of data and services
g) Network infrastructure security
h) Network security events monitoring
i) Access control
j) Application services security
k) Information security events management
l) Management of business continuity

The ISO 27000 series that are followed by KSRP include:
a) ISO 27001: Information Security Management System
b) ISO 27002: Code of Practice for Information Security Management
c) ISO 27004: Information Security Management Measurement
d) ISO 27035: Information Security Incident Management Classification

30A.2. Overview of Information Security System Framework

KSRP is designed and built in the following information security measures to mitigate security risks caused by mistakes occurred in day to day work.

30A.2.1. Assets Management

KSRP recognizes and classifies the assets of the data centers and DNS nodes as follows:
a) Data: databases and database manuals;
b) Services: telecommunication services as well as other public utilities and their contracts;
c) Hardware resources: network equipment, host brand, model, configuration parameters and operating manuals or instructions;
d) Software resources: SRS server software, DNS software, Whois software, Registrar business support system, Registry business support system, mail server software, applicable website software and respective installation manuals and configuration files.

In order to effectively protect information resources above, KNET classifies the platform assets by both importance and sensitivity. Please refer to Table 30A-1 in Q30_attachment.

30A.2.2. Human Resources Management

a) Establish definite posts with clearly defined duties to ensure people can really understand the nature of that post he⁄she applies for;

b) For crucial posts (posts above the director level, DBA and security specialist), KNET will carefully evaluate the applicantsʹ background to ensure that they are qualified for such posts. The background information under evaluation may include a) personal profile; b) resume; c) academic level and professional qualifications; d) identity; e) other details;

c) The New Employee On-board Procedures clearly stipulate that the new employee sign a confidentiality agreement with the company shall his⁄her post require;

d) The Human Resources Department will regularly conduct training sessions for new employees to ensure all staff members are fully aware of the serious consequences of information security threats;

e) The security commissioner regularly performs inspections on employeesʹ work to ensure that they perform their jobs in a way conforming to the security policies;

f) The Employee Exit Procedures shall stipulate that work handover be done well before an employee leaves the company. The Human Resources Department shall not handle the exit procedures until the employeeʹs manager confirms that his⁄her authority to access the internal systems has been revoked.

30A.2.3. Physical Environment Security

a) KSRP has established two enclosed and controlled physical work environment: one is a peripheral work environment called the Office Zone; the other is an internal environment called the Monitoring Center.

b) The company staff enters the the Office Zone with an access card. Non-company personnel are not allowed to enter the zone without permission.

c) Any visiting guest must always be escorted by a staff member.

d) The Monitoring Center is protected by stricter security measures. Only staff members received a higher security clearance are allowed to enter.

e) In order to ensure the secure operation of the system and identify any failings in regular work, we have applied video monitoring to the office zone and so we can provide the subsequent security auditing work with some evidence.

f) KSRP employs identity card and fingerprint authentication for access control. It combines physical security access with other security protection measures to build a secure working environment.

g) To ensure timely response to emergency, KSRP has deployed dual-backup support for communication services and utility facilities in the data center, including Internet access lines, telephone lines, electricity, power supplies, and air conditioning.

30A.2.4. Operation Regulations

KSRP has established strict procedures for managing changes to the online services which include Software Testing Procedures, Services Deployment Procedures, and Services Change⁄Upgrade Procedures. The following provisions are stipulated:

a) Before changes are made to the online services, the new software shall be strictly tested and pass the security validation scanning performed by the security specialist;

b) Operation personnel shall obtain the approved change request before deploying the changes in production;

c) Operations personnel shall back up software and data in production before rolling out changes to ensure that they can roll back the changes in case of deployment failures;

d) Operations personnel shall strictly follow the instructions stated in Service Deployment Practice Manual when rolling out changes to services in production;

e) After changes are made to the services in production, Operations personnel shall submit the services installation and maintenance documents to the O&M Department.

f) After changes are made to the services in production, the system administrator will perform an all-round monitoring on them.

30A.2.5. Storage Media Management

Except for system administrators, other staff members are not allowed to copy data between the production environment and the external media. Only the system administrators are authorized to perform data upload⁄download operations and all these actions are logged by KSRP for auditing.
The system administrator backs up a variety of data and application services logs from production to tapes as required every day. KSRP designates special personnel to keep these tapes in a safe place and rotate them for reuse once the data retention periods expire.

30A.2.6. Backup of Data and Services

KSRP backs up data and services with two objectives:
a) The services can be recovered as soon as possible in case of any disaster⁄failure;
b) The business can be audited at any time if needed;

To achieve these two goals, KSRP backs up the following assets:
a) Data in the databases;
b) Software resources (including binary code and relevant source code, configuration files and design documents) and operation log;
c) The standard operating system and third-party services software;
d) All equipment, models, specifications and other documents to the installation, operations and maintenance of the service environment.

Assets backup shall be done by the person in charge, and inspected by the security specialist on a periodic basis. Any identified issues shall be fixed as required.

The backup and inspection patterns vary by the natures of the assets. Different equipment, models, specifications as well as the installation and maintenance manuals, services and relevant documents shall be backed up and inspected when they are created and⁄or altered; the software resources and operation logs shall be backed up daily and inspected on an periodic basis; the data in the databases shall be backed up and inspected daily.

There are three daily data backup copies for KSRP data, one stored in the primary data center, one stored in the backup data center, and one copy stored on a tape as offline backup. This ensures that the system services can be recovered properly in case any man-made⁄natural accident occurs.

30A.2.7. Security of Network Environment

The KSRP network infrastructure is divided into two zones by firewalls: internal protection zone and the DMZ. The database platform is placed in the internal protection zone protected by a database firewall in front of all the front ends; the operating network environment is placed in the DMZ for providing services to the outside.

As the services provided by KSRP are Internet-based, the whole network infrastructure is very important for the platform. In order to maintain a robust and secure network environment, dedicated network professionals are assigned as the principal for all the network equipment assets to ensure the whole network is secure, smooth and fault-tolerant.

The duties of the network professionals include:
a) Design of the network topology;
b) Ensuring all network equipment are working normally;
c) Ensuring equipment are reachable between each other over the network;
d) Maintain passwords for all network equipment to keep unauthorized people from accessing these equipment;
e) Keep the network equipment highly available; timely back up all network routing policies and firewall control policies in order to ensure timely recovery from any failure;
f) Audit network security events to timely identify any potential threats.

30A.2.8. Network Security Events Monitoring

In addition to assisting the network professionals to maintain a secure, smooth and robust network environment, system administrators have another important role of monitoring various events occurred over the network.

KSRP is equipped with management functions to perform comprehensive monitoring over network equipment, servers and applications. A system administrator carries out the following daily tasks to manage network and services events with the monitoring platform:

a) The system administrator inspects various network and services events from the network management equipment, IDS equipment and the monitoring platform;

b) The system administrator follows the Services and Maintenance Manual to handle any identified network events;

c) The system administrator follows the Evens Response Procedures for any identified events that require communications.

30A.2.9. Access Control

In order to ensure only authorized users are allowed to access the services provided in the operating environment, KNET has enforced the following operation rules as part of the assets management requirements:

30A.2.9.1. Passwords Management

a) The identity authentication is based on user name⁄password; the password must be strong;

b) If the user tries to login with a wrong password 3 times in a row, the account is locked for at least one hour in order to prevent any malicious login attempts.

30A.2.9.2. Identity Authentication and Authorization:

a) Before accessing any system serving specific users, the user shall pass the identity authentication;

b) The user authority shall only be assigned by the system administrator.

30A.2.9.3. Routing Policies:

a) KSRP blocks remote access to the network via Internet for management purposes ;

b) For any privileged user logging on to any application system, the source IP address of the userʹs machine shall be qualified;

c) Any session that stays idle for over 30 minutes shall be disconnected;

d) For services only open to specific IP addresses, routing qualifications shall be provisioned for such IP addresses on the firewall.

30A.2.9.4. Host Restrictions:

a) Logging on to the operating system of a host shall be done via SSH;

b) Any operations done on the host after login shall be logged for auditing purpose.

c) The ROOT account of the host can only be accessed by the administrator; the ROOT account shall not be used unless it is absolutely necessary.

d) The host password shall be changed regularly.

30A.2.9.5. Firewall Protection:

a) All application services (except for DNS services) shall be placed behind the firewall for security purpose;

b) Only the ports used by these application services shall be open via the router and firewall; all other ports shall be closed.

c) The maximum number of connections shall be capped for all application services to mitigate risks of large-scale malicious attacks.

30A.2.9.6. Data Encryption:

a) Any confidential business data shall be transferred via HTTPS;

b) Any data files shall be transferred via VPN.

30A.2.9.7. Security Auditing:

a) The user list and user access authority shall be reviewed on a regular basis to ensure the authority is up-to-date and invalid accounts are timely removed;

b) The network access log of the user shall be audited by the security specialist on a regular basis.

30A.2.10. Security of Application Services

KSRP ensures security of the application services in two aspects: 1) security of the operating system; 2) security of the application programs.

Security of the operating system is guaranteed by the following measures:
a) Uniformly install the operating system and security-related patches;
b) Turn on the firewall and only open the ports required by the application services;
c) Regularly check the operating system users and system files to ensure the important system files are not compromised.

Security of the application programs is guaranteed by the following measures:
a) For the application services provided to specific users, those users shall pass the identity authentication (certificate authentication or password authentication). If password is used, the password strength shall comply with the security policies;
b) If a specific user performs any operation on data via the application system, the system shall check the userʹs identity and rejects the operation if it is unauthorized. A detailed log shall be created for any authorized change for auditing;
c) The Measures of Administration of Source Code Security prohibits anyone from disclosing the source code to any third party;
d) Before any application services being put online, the security specialist shall perform a security scan on the software to identify any potential security threats;
e) The system administrator shall use the configuration administration tools to ensure the version of the service software in the operating environment complies with that of the software provided by the R&D Department;
f) The Security Management Procedures of Application Service requires that the security specialist track any defects of the third-party software disclosed by the company and timely upgrade the software;
g) The security specialist shall carry out reinforcement on the firewall and operating system in order to reduce the risks caused by any malicious intrusion to the application services.

30A.2.11. Information Security Events Management

On KSRP, information security events are managed by the information security professionals who are in charge of collection and analysis of all information security events as well as formulation and implementation of the remedial solutions.

The information security specialist collects security events through two channels: the network monitoring log of the system, and authoritative websites disclosing security vulnerabilities.
The information security specialist works out a platform improvement plan after collecting and analyzing applicable security events. The plan will be submitted to the corporate management for approval before execution.

30A.2.12. Security Management of Business Continuity

Information systems of KSRP are classified by their importance as below:
a) Critical information systems: DNS services;
b) Important information systems: SRS services, Whois query, Registrar business support platform, Registry business support platform;
c) General information systems: websites, mail system, etc.

One of the following two cases constitutes an outage of an information system: 1) the system fails to provide services to the public; 2) the services level fails to meet the SLA. If the outage lasts for a while, it is considered as an event. The longer the event lasts, the bigger the loss is.

In addition, if user data of KSRP is leaked, missing or falsified, these occurrences are also considered as events. The bigger the ratio of affected data, the greater the loss caused by the event.

For the classification of events occurred on KSRP, please refer to Table 30A-2 in Q30_attachment:
In order to address the above-mentioned circumstances, KSRP has designed a series of services backup & restore procedures to ensure service continuity.

30A.3. Security Commitment to Registrants

KSRP provides the following security commitments to Registrants:
a) The availability of the DNS services is 100% monthly;
b) The availability of the SRS services is 99.9% monthly;
c) The availability of the Whois services is 99.9% monthly;
d) Service outage to the primary data center caused by disasters such as earthquake and flood, shall not last for more than 1 hour and with almost no data loss.
e) Any data related to the Registrants will not be leaked;





© Internet Corporation For Assigned Names and Numbers.