ICANN New gTLD Application

The .新闻TLD aims to become a platform for dispatching news and other forms of mass communications such as personal or business broadcasts on the Internet. The .新闻 TLD aspires to attract both traditional news establishments and non-traditional news establishments including brands and individuals to utilize the TLD to broadcast to the world their news.

Traditional and Non-traditional News Establishments

Newspapers and other print media were once the go to source for news. With the availability of the around the clock television and news channels along with the rise of the World Wide Web, print circulations, particularly that of news prints, have been on a steady decline since the late 1990. Today, it has become imperative for all news establishments to be online, including mobile or electronic reading device channels, to stay relevant in the current mass media landscape.

Ad revenues, life line of traditional print publications, are drying up fast and shifting to virtual platforms. According to TechCrunch, online ad spending is expected to soar to 36 billion in 2012, while offline spending continue to nosedive. (http:⁄⁄techcrunch.com⁄2011⁄06⁄08⁄online-ad-spending-31-billion⁄) In fact a number of recent publications started in the late 1990s and 2000s choose to stay online exclusively, such as the popular technology web publication Techcruch itself; the current affairs news site Huffington post; and UK’s first online only regional paper, the Southport Reporter. Even veteran publications like the US News & World Report and the Seattle Post-Intelligencer are abandoning print altogether.

Most important of all, many of the news establishments and agencies take pride in their work beyond “commercial” interests. Therefore a home on the Internet that is not labelled “.com” (commerce) would allow them to better express their identity. As a Chinese IDN TLD, “.新闻” aims to be the home for traditional as well as non-traditional news establishments not only in China but also the Chinese community around the world.

New Generation of News Consumers

ComScore reported that today’s younger news consumers are more likely to get their news online. Jack Flanagan, vice president of comScore notes “the Internet represents a significant opportunity to extend – and even improve upon – existing news brands and reach out to new consumers with living, breathing real-time content. Just because print circulations are declining does not mean there are fewer news consumers. In fact, just the opposite is true.” (http:⁄⁄www.comscore.com⁄Press_Events⁄Press_Releases⁄2008⁄03⁄Younger_News_Consumers_Less_Likely_to_Read_Print_Newspapers)

If printed news circulation ⁄ readership is down, and online news consumption is climbing, where are readers accessing their news today? According to comScore’s 2009 report, although readership for printed news publications is down 9% from the past year ( -9.7 million people), the number of visitors to the online newspaper category is up only 5% (+3.2 million people) during the same period. At first glance, the rise in online readership does not make up for the decline. However, what was also observed by comScore, was that the number of readers of news content online has increased by 8.6 million people. Together, these data indicate that while some print newspaper readers now choose to read newspapers online, more people are simply switching to reading news online at non-traditional news sites. (Reference: http:⁄⁄blog.comscore.com⁄2009⁄07⁄print_newspapers_decline.html)

The “.新闻” TLD believes in being the home and platform where news readers would turn to for traditional as well as non-traditional news.

Business and Personal Broadcasts

Brands may use “品牌.新闻”and “产品.新闻” to convey the company’s latest press release or product offerings, to upkeep investor relations or to launch market awareness campaigns. By doing so the brand will be able to better retain customers, obtain comments, feedback and suggestions, and improve customer relations through their own “.新闻” platform rather than depend on other proprietary platforms.

Individuals may find the .新闻 TLD attractive for communicating personal announcements such as prenuptials, baby announcements, personal achievements, new-found hobbies or advancing careers.

The vision of the .新闻 TLD is that through the development of an open generic IDN namespace supporting the delivery of current and relevant news events online locally, nationally, regionally and globally from media outlets as well as non-media establishments, it could become a nucleus for news and mass communication activities, and a driver of economic and social value for news establishments and news consumers around the world.

The mission and purposes of the .新闻 TLD are:

1. To develop a namespace dedicated to the broadcasting of news online, and a platform that is meaningful to the news profession as well as governments, businesses, consumers and pro-sumers of news;

2. To foster and encourage an online space for contemporary mass communications and dialogue for news distribution, aggregation, syndication as well as personal broadcasts and more;

3. To operate a secure, stable, trusted and socially responsible IDN gTLD with a reputation as a reliable online destination for news on the Internet; and,

4. To serve the media community, including the traditional news establishments, non-traditional news establishments as well as other entities and individuals to convey new information and ideas to the world.

Based on the generic nature of the .新闻 IDN TLD, the Registry aspires to become the IDN of choice for news establishments (i.e. 时代. 新闻), broadcasting groups (i.e. BBC.新聞), businesses and individuals developing websites delivering currently new events, public announcements or sharing personal news (i.e. 微软.新闻 & 甄子丹.新聞).

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

As a keyword, generic IDN gTLD, .新闻 aspires to be the domain of choice for mass media corporations, broadcasting groups, online news magazine, entertainment establishments, sports publications as well as brands and individuals.

While it is anticipated that a number of proposed new TLDs will enhance competition by targeting existing domain registrations and penetrating into the existing marketplace with aims to switch away from or add to their existing domains. The Registry will position itself not only as an alternative to existing TLDs such as “.com”, “.asia” or “.mo”, but as a premier domain exploring new adoption, promoting innovation and usage of domain names in the marketplace. For example, the Registry believes in the prevalence search engine optimization value of providing registrants a larger footprint on the Internet that is relevant to the target market they serve. As such, the Registry believes in exploring new market segments rather than replicating existing zones. Nevertheless, as a financially prudent approach, our financial projections and plans, are conservatively based on existing market indicators.

B. Enhance Consumer Trust

Based on expert studies, Internet users have more trust for domain names that exactly matches what they are looking for This improves the relevance of services and content produced under the TLD and serves to enhance consumer trust.

The value of the TLD name in itself is therefore a core part of the value and of building consumer trust. News establishments can utilize a .新闻 domain to deliver local, regional or global news, on domains such as “亚洲.新闻”; while businesses can establish their own dedicated domain for news and press releases or keep investors updated on domains such as “IBM.新聞” instead of long URLs such as: http:⁄⁄www.ibm.com⁄news

1. Goals of the TLD

As a generic, keyword IDN TLD, .新闻 will be made generally available to all registrants (except in the Sunrise period). The domains can be used for dispatching news and other forms of mass communications such as personal or business broadcasts on the Internet by traditional news establishments and non-traditional news establishments as well as brands and individuals. The Registry does not intend to implement content or use restrictions for the registration of domain names under this TLD (except of course for illegal, abusive, infringing or otherwise materials threatening the stability and security of the Internet as described further in Questions 28 and 29).

The Registry aims to position the .新闻 TLD to be known as the ‘goto’ TLD for news, current events and public or private annoucements on the Internet by engaing in marketing and branding building with traditional and non-traditional news groups, businesses, and brands, as well as outreach and marketing support to registrars to establish .新闻 in the minds of the consumers, especially in relevant markets. This TLD will be designed to be user friendly, easy to use, engaging, and topic relevant.

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 initiative that is economically viable, sensitive to the cultural aspects of the community it serves, and one which participates 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. The .新闻 TLD opens up category specific options for startup online news media; new spaces for brands to cultivate and manage it’s own news and for individuals to make personal announcements, vis-a-vis a personal blog page, which is expected to be updated regularly and frequently.

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

One of the primary benefits to registrants of participation in the .新闻 TLD is that they can build keyword specific, memorable and easily accessible identities that will facilitate traffic and clientele to be more likely to find the information or announcements they are seeking. According to a recent report by comSore consumers of news data are more likely to go directly to a “news” specific platform for news than to run a news search from search engines. (Reference: http:⁄⁄blog.comscore.com⁄2012⁄04⁄)

The .新闻 TLD builds on this observed user behaviour to further improve user experience. More specifically, since users trust and seek news platforms rather than search for specific news, for a business, utilizing a .新闻 TLD (e.g. 联想.新闻) clearly signals to users that the website is a news platform for news about your services and products, which in turn means that users would be more willing to visit or click directly to the .新闻 site.

4. Registration Policies Supporting the Goals to Drive User Benefits

.新闻 is intended to be an open TLD, generally available to all registrants (except in the Sunrise period).

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 news establishment community to encourage their participation and also to drive the awareness of the TLD in the community that it intends to serve.

5. Privacy and Confidentiality Protection

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

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

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

In response to the question specifically:

1. Mechanisms for Resolving Multiple Applications to a Domain

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

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

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

2. Cost Benefits for Registrants

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

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 offering 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 by the Registry, the applicant believes that prudent operations as an economically viable and socially responsible TLD operator 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.

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.

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

More specifically, the Registry commits to:

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

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

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

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

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

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

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

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

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

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

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

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

23.1. Registry Services

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

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

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

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

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

23.1.1. Service Level

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

23.1.2. Security

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

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

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

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

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

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

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

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

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

23.1.3. Stability

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

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

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

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

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

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

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

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

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

23.2.1. Service Level

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

23.2.2. Security

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

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

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

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

23.2.3. Stability

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

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

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

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

23.3. Information Publication

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

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

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

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

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

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

23.5. Dissemination of TLD Zone Files

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

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

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

23.5.1. Service Level

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

23.5.2. Security

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

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

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

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

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

23.5.2.1. Data Transfer Security

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

23.5.3. Stability

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

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

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

23.6. Operations of the Registry Zone Servers

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

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

23.6.1. Security

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

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

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

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

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

23.6.2. Stability

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

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

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

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

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

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

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

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

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

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

23.7.1. Service Level

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

23.7.2. Security

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

23.7.3. Stability

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

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

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

23.8. Internationalized Domain Name (IDN) Service

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

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

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

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

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

23.8.1. Security

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

23.8.2. Stability

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

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

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

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

23.9. DNSSEC

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

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

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

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

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

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

23.9.1. Security

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

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

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

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

23.9.2. Stability

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

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

24.1. Overview

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

24.1.1. System Architecture

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

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

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

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

c) Registry Business Support System

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

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

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

d) Zone File Synchronization Service

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

e) Databases

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

24.1.2. Physical Architecture

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

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

24.1.3. Equipment List

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

24.2. Operations Plan

24.2.1. Availability

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

Specifically, SRS ensures high availability in the following aspects:

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

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

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

24.2.2. Performance

Based on the projections, the Registry expects around 7,182 domain names within 3 years. When the registration volume reaches such target point, the Registry needs to handle about 21,598 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 near real time.

24.2.6. Operations and Maintenance

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

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

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

24.3. Compatibility

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

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

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

24.4. Resourcing Plan

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

25.1. Overview

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

25.2. Introduction to EPP

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

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

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

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

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

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

25.3. APIs Provided for Registrars via EPP

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

a) Session Management

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

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

b) Query

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

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

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

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

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

c) Object Change

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

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

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

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

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

d) Miscellaneous

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

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

25.4. Compatibility

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

25.4.1. Compliance with RFCs

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

a) Compliance with RFC 5730

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

b) Compliance with RFC 5731

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

c) Compliance with RFC 5732

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

d) Compliance with RFC 5733

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

e) Compliance with RFC 5734

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

f) Compliance with RFC 5735

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

25.4.2. Specification Related to Redemption Period (RFC 3915)

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

25.4.3. Specification Related to DNSSEC (RFC 5910)

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

25.5. Consistency

25.5.1. Consistency with Technical Plan

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

25.6. Resourcing Plan

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

26.1. Overview

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

26.1.1. Software Architecture

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

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

a) Full-text Search System

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

b) Database

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

26.1.2. Physical Architecture

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

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

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

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

26.1.3. Equipment List

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

26.2. Operations Plan

26.2.1. Availability

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

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

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

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

26.2.2. Performance

It is estimated that 7,182 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 21,598 queries a day . KSRP is designed to scale to handle 30 million domains. The performance test results shows that KSRPʹs Whois system is capable of handling 5000 queries per second or about 430 million queries a day with the maximum response time not exceeding 1150ms.

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

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

26.2.3. Scalability

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

26.2.4. Data Synchronization

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

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

26.2.5. Searchable Whois

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

How to Prevent Abuse:

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

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

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

26.3. Compliance with Relevant Specifications

26.3.1. Compliance with RFC 3912

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

26.3.2. Compliance with Specification 4 of the Registry Agreement

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

a) Whois Query

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

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

b) Zone File Access

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

c) Bulk Registration Data Access

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

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

26.4. Resourcing Plan

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

27.1. Overview

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

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

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

27.2. Registration Life Cycle and Status

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

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

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

27.2.1. Transition of Registration Status

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

a) Update Operation

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

b) Renewal Operation

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

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

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

c) Transfer Operation

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

d) Restore Operation

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

27.2.2. Description of Status Transition

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27.3. Compliance with RFCs

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

27.4. Consistency

27.4.1. Commitment to Registrant

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

27.4.2. Technical Plan

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

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

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

27.5. Resourcing Plan

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

The Registry follows ICANNʹs Applicant Guidebook to implement the domain registration management framework and minimizes the risks of domain abuse according to guidelines in the Draft Final Report of Registration Abuse Policies Working Group (RAPWG). As a partner of the Registry, DotAsia (through Namesphere) participates actively in the GNSO policy development processes and advises the Registry on implementation of appropriate Abuse Prevention & Mitigation mechanisms.

28.1. Implementation Plan

The Registry adheres to the ICANN Applicant Guidebook requirements and will release policies to handle domain abuse policies on its website. It will also establish an online domain abuse complaint system for the filing and prompt handling of abuse complaints. The filing party may use this system to submit relevant information of a complaint, such as the domain name in question, abuse behaviors and consequences as well as filing partyʹs contact information, such as name, Email, telephone number and fax number (optional).

The Registry also provides three ways for abuse complaints: fixed telephone, fax and Email. The information will be published on a prominent location on the Registryʹs website as well as provided to all Registrars for their dissemination to end users.

A dedicated hotline is already established by KNET at:
Fixed phone: +8610-58959009
Fax: +8610-57656837
Email: abuse@dot.新闻 (to be confirmed and created upon the delegation of the TLD)

28.2. Policies for Handling Complaints Regarding Abuse

28.2.1. Domain Name Abuse Behaviours

Domain name abuse includes the abuse behaviours happening at domain registration and those abuses in utilization of the domain names. The former abuse includes cybersquatting, gripe sites, deceptive and⁄or offensive domain names, domain tasting, etc., while the latter one includes phishing, spam, and malware⁄Botnet command-and-control.

28.2.2. Abuse Policies

In the policies for handling complaints regarding abuse, it is strictly forbidden for registrants to abuse domain names, and the corresponding penalties are also stipulated in the policies. At the same time, registrants are asked to make commitments when they submit the applications. The registrars should be asked to make the similar commitments. In addition, measures for promote Whois accuracy are provided to prevent and mitigate the potential domain name abuse.

Furthermore, based on the suggestion and advise from DotAsia, we will continue to explore the possibility of implementing a rapid suspension process targeted against phishing. A sample of a draft suspension process is included in the attachments to #30b.

28.2.2.1. Registry Policies

KNET and DotAsia are experienced with managing and mitigating against abuse for TLD registries. A dedicated team at KNET will proactively monitor for any suspicious activities at the registry and respond to abuse complaints.

Following the process included in the .ASIA Registry-Registrar agreement (http:⁄⁄dot.asia⁄accreditationdocs⁄DotAsia-RRA-2010-02-01.pdf), the Registry will also include in its Registry-Registrar agreement 2 key provisions to allow for the Registry to act promptly against any abusive behaviours:

1. Clause to specify that all registrations are to submit to proceedings for expedited suspension processes of domain names:

(3.9.11) Submit to proceedings commenced under other dispute policies as set forth by [DotAsia] from time to time in the Registry Policies, including but not limited to expedited processes for suspension of a domain name by claims sought by intellectual property right holders, Internet engineering and security experts or other competent claimants in the purpose of upholding the stability, security and integrity of the [.ASIA Registry].

2. Clause to reserve the right to cancel registrations that threaten the integrity, security and stability of the registry:

(6.5) Reservation of Rights. [DotAsia] reserves the right to deny, cancel or transfer any registration or transaction that it deems necessary, in its discretion (i) to protect the integrity, security and stability of the registry; (ii) to comply with any applicable laws, government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process; (iii) to avoid any liability, civil or criminal, on the part of DotAsia, as well as its affiliates, subsidiaries, officers, directors, and employees; (iv) for violations of this Agreement and its Exhibits; or (v) to correct mistakes made by the DotAsia, the Registry Services Provider or any Registrar in connection with a domain name registration. DotAsia also reserves the right to freeze a Registered Name such as placing a domain name on hold, lock, or other status during the resolution of a dispute.

These clauses ensure that the Registry can act promptly to suspend or cancel abusive domain registrations. The Registry also believes in due process to avoid false positive suspensions and an overly aggressive approach to cancelling domain registrations. The joint experience and knowledge from KNET and DotAsia will provide sound direction to the Registry to mitigate against abuses with a balanced approach.

28.2.2.2. Commitment of Registrant

In registrant agreements, registrars should include clauses for registrants to declare and uphold that they will not not abuse domain names such as utilize it for phishing or spam when they submit the registration application. For the detected domain name abuse behaviours, the registries have rights to suspend the resolution of registered domain names or cancel the domain name.

28.2.2.3. Commitment of Registrar

In addition to ICANN Accreditation agreements and ICANN consensus policies, the Registry will require registrars to uphold that they will not knowingly participate, encourage or acquiesce in domain name abuse behaviours.

The Registry will proactively monitor registrar system behaviours to avoid any domain name abuse activities.

28.2.2.4. Measures Intended to Promote Whois Accuracy

28.2.2.4.1. Measures for Registrants

The Registrant must accept the Registration Agreement when registering a domain name. The Registrant shall ensure that all the submitted registration information is authentic, accurate and complete. If any registration information changes, the registrant shall inform the registrars of the registration information update within 30 days.

28.2.2.4.2. Measures for Registrars

A Registrar must be accredited by ICANN before becoming a Registrar of the Registry.

In the Registry Registrar Agreement, the Registrar is required to take necessary measures to increase the Whois accuracy which is considered as an important indicator for the Registrar assessment. Other requirements intended to avoid and mitigate domain name abuse are stipulated in this agreement as well.

28.2.2.4.3. Additional measures from the Registry

Being a Registry based in China, in compliance with the local requirements as well as additional measures to ensure Whois accuracy, for users of Mainland China: If the Registrant is a real person, he⁄she must submit the following information: real name, email, fixed telephone, mobile phone, ID card number, and the valid ID card (two sides) in the form of electronic file (without any manual modification) or the passport (the first page) in the form of electronic file (without any manual modification). If the Registrant is an organization, it must submit the following additional information: valid enterprise business license or other valid qualification certificates in the form of digital photo file (without any manual modification), company address, and the ID card (two sides) or other valid certificates of company’s legal representative or contact in the form of electronic file (without any manual modification).

Any Registrant information updated by the Registrant shall undergo the same auditing procedures before taking effect. These measures ensures a high level of Whois accuracy.

28.2.3. Procedures for Handling Complaints Regarding Abuse

The Registry, through KNET, has an abuse complaints disposal working group composed of technical and legal professionals to handle complaints about domain name abuse and build linkage mechanism with CADNA (Coalition Against Domain Name Abuse) to effectively handle the domain name abuse complaints.

The team at the Registry will adopt the definition on the abuse by the Registration Abuse Policy Working Group (RAPWG).

The team would automatically send confirmation mail to the complaint filing party upon receiving an abuse complaint. Generally the team will arbitrate the abuse complaint within 5 working days. Under any circumstances, the period of handling complaints cannot exceed 10 working days.

For domain abuses that need to be resolved by dispute resolution mechanism, the complaint filing party will be informed of the specific domain dispute resolution institutions and processes. For any domain name that has been confirmed to be abused, the Registry may either suspend its resolution or cancel its registration according to the domain name abuse management policies. If a Registrant disagrees with the penalty, he⁄she may apply to the Registry for re-arbitration. However, the implementation of the penalty will not be suspended during the re-arbitration period. The Registry will not take any punitive actions on those domain names that have not been confirmed to be abused.

After the arbitration is made, an email containing the arbitration result will be sent to the complainant filing party, the Registrant and the Registrar of the domain name under the complaint.

28.2.4. Collaboration with other parties

Externally, the Registry will work with other parties to prevent and mitigate the abuses on its domain names. The procedures or mechanisms of the cooperation will be described as follows:

With ICANN

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

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

With LEAs and other security providers

KNET and DotAsia works closely with CERTs (Computer Emergency Response Team) in China and around Asia. APCERT is also a member of DotAsia. The Registry will establish a contact window with CNCERT⁄CC, LEAs, APWG, CERTs around Asia and other security providers to take down domain name abuse incidents concerning domain names registered under the TLD.

The Registry will work closely with Registrars nn the implementation of suspension and takedown of domain name abuse incidents. The collaboration mechanism is as follows:

1) The Applicant will instruct the sponsoring registrar to send email notification the registrant (administrative contact, technical contact or billing contact) concerned to respond to the domain abuse complaints upon receipt of the takedown notice from the LEAs, CERT⁄CC; the notification requires the registrant to respond within an expressed time period; in the meanwhile, the domain name in question will be put in “lock” status;

2) Should there be no response from the registrant, the Applicant will instruct the sponsoring registrar to put the domain name in suspension take down and a notice of takedown will be sent to the email address of the registrant.

28.3. Disposal of Orphan Glue Records

KSRP automatically marks the resulting orphan glue records of a domain and dates them when suspending the domain resolution and deleting the domain. At the same time when the orphan glue records are generated, KSRP automatically sends an email notification to the registration management contact, technical contact and Registrar of the affected domain names to update their systems within the 30-day grace period.

The orphan glue records scanning and cleaning system will perform a scheduled scanning on the platform system on a daily basis to delete those orphan glue records that are no longer used and those that are still being used but have exceeded the 30-day grace period. An email notification will be sent to the registration management contact, technical contact and Registrar of the domain name that still uses the orphan glue records for resolution.

If there is any written evidence indicating that an orphan glue record is related to any malicious conducts, the domain name management procedures will be followed to directly delete such records via the back-stage management operations.

28.3.1. Reasonable Access Control

Registrars may remotely log into the online domain management system which is encrypted via HTTPS and pass the high-security password authentication and Captcha prior to performing operations such as updating Registrant information, transferring, renewing and deleting domain name.
The Registrars must obtain the domain name transfer password before performing the transfer operation. The user submits the transferred domain and transfer password to the Domain Management System of the target Registrar. The target Registrar submits relevant information to the registration system of Registry, who will complete the transition after verifying the transfer password.

The Registry will recommend that Registrant should change its password in the Domain Management System of Registrars once within at least three months on a regular basis.

When the domain name is updated, transferred or deleted, the registration system of .新闻 Registry will automatically send a mail notice to the original and new Registrants.

28.4. Meeting Evaluation Criteria

28.4.1 Adequate description of abuse prevention and mitigation policies

A thorough and tested abuse and complaint handling process is put in place by the Registry through KNET as its Registry Back-End Services Provider. A clear set of policies will be put in place and published on the Registry website to both deter against potential abusers as well as to provide a clear process for resolving and suspending abusive domains.

28.4.2 Well-developed abuse policies and procedures

Together with KNET and DotAsia, the Registry will put in place policies and procedures, including appropriate additions to the Registry-Registrar Agreement with Accredited Registrars. This ensures that the Registry can enforce and deliver on its commitments on abuse prevention and mitigation.

28.4.3 Plans consistent with technical, operational and financial approach

As the Registry Back-End Services provider KNET is fully equipped with the capabilities and manpower to implement the technical and operational aspects of the abuse prevention and mitigation policies. KNET costs are largely variable based, therefore highly scalable, and incorporated into the financial models discussed in #46-50.

28.4.4 Adequate level of resources committed

The Registry, through KNET, will have a designated team for abuse management as well as for auditors (two auditors at least will be included, one for the initial audit and one to re-audit) for Whois accuracy compliance. The abuse management team will form an abuse complaint disposal group (three auditors are advised: two auditors and one legal professional) to handle the anticipated increase in complaints in proportion to the total number of registered domains under the TLD.

28.4.5 Measures to promote Whois accuracy

Besides registry, registrar and registrant agreement and enforcement of Whois accuracy, additional Whois accuracy measures are put in place, especially for mainland China registrations. Because a majority of registrations are expected to come from China, the Registry expects that this measure would significantly enhance Whois accuracy for the Registry.

28.4.6 Additional Measures for Abuse Prevention and Mitigation

Both the additional Whois accuracy measure as well as the additional rapid suspension policy being put in place against Phishing are additional measures for abuse prevention and mitigation. Based on the joint experience from KNET and DotAsia, it is also important that the Registry clearly position itself as being proactive and diligent in mitigating against registration abuses, which these additional measures signify.

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

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 (Dispute Resolution) 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 (Dispute Resolution) 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. As part of the requirement of Specification 7 of the new gTLD Registry Agreement, An SDRP will be adopted to allow any party to raise a challenge on at least the four grounds identified in the Applicant Guidebook at TMCH s6.2.4. The remedy will be cancellation or deletion of a successfully challenged domain name. All registrants will be required to submit to proceedings under the SDRP, which will specify that SDRP claims may be raised after registration of a sunrise domain and will require that complaints clearly identify the challenger, the challenged domain, and the ground⁄s on which the complaint is based.

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). Together with the Pioneer Domains Program, a Pioneer Domains Challenge Process will be put in place (http:⁄⁄pioneer.domains.asia⁄ascii⁄challenge.html).

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.

The registry operator will implement decisions rendered under the URS on an ongoing basis. Per the URS policy posted on ICANN’s Web site as of this writing, the registry operator will receive notice of URS actions from the ICANN-approved URS providers. These emails will be directed immediately to the registry operator’s support staff, which is on duty 24x7. The support staff will be responsible for creating a ticket for each case, and for executing the directives from the URS provider. All support staff will receive pertinent training.

As per ICANN’s URS guidelines, within 24 hours of receipt of the notice of complaint from the URS provider, the registry operator shall “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will remain in the TLD DNS zone file and will thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:
• ServerUpdateProhibited, with an EPP reason code of “URS”
• ServerDeleteProhibited, with an EPP reason code of “URS”
• ServerTransferProhibited, with an EPP reason code of “URS”
• The registry operator’s support staff will then notify the URS provider immediately upon locking the domain name, via email.

The registry operator’s support staff will retain all copies of emails from the URS providers, assign them a tracking or ticket number, and will track the status of each opened URS case through to resolution via spreadsheet or database.

The registry operator’s support staff will execute further operations upon notice from the URS providers. The URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the complainant, and the registrar.

As per the URS guidelines, if the complainant prevails, the “registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”

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.2.5 2 Resourcing Plan

At least two auditors will be assigned in the the Registry to perform the verification of domain name registration applications.

At least three employees will be assigned to be responsible for formulating and implementing relevant dispute policies.

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

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;

Ding Sha	Director
Yang Chunnan	President
Yang Ningning	Officer

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

String: 新闻

Originally Posted: 13 June 2012

Application ID: 1-1309-40591

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.