ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: HU YI GLOBAL INFORMATION RESOURCES (HOLDING) COMPANY. HONGKONG LIMITED

String: 网址

Originally Posted: 13 June 2012

Application ID: 1-1159-3507


Applicant Information


1. Full legal name

HU YI GLOBAL INFORMATION RESOURCES (HOLDING) COMPANY. HONGKONG LIMITED

2. Address of the principal place of business

7⁄F Chinachem Century Tower, 178 Gloucester Road, Wan Chai
Hong Kong 852
HK

3. Phone number

+852 25319391

4. Fax number

+852 25251105

5. If applicable, website or URL

http:⁄⁄www.8hy.hk

Primary Contact


6(a). Name

Mr. XIANG LI

6(b). Title

Assistant to Chairman

6(c). Address


6(d). Phone Number

+86 15920318242

6(e). Fax Number

+86 20 22081083

6(f). Email Address

XIANG.LI3@HUYI.CN

Secondary Contact


7(a). Name

Ms. Yuk Chun Leung

7(b). Title

Accounting Manager

7(c). Address


7(d). Phone Number

+852 97743382

7(e). Fax Number

+852 25251105

7(f). Email Address

jennifer.leung@8hy.hk

Proof of Legal Establishment


8(a). Legal form of the Applicant

HU YI GLOBAL INFORMATION RESOURCES(HOLDING) COMPANY.HONGKONG LIMITED

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

Lawʹs of Hong Kong Special Administrative Region

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

Attachments are not displayed on this form.

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


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


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

HUANG XIONGWEIChairman

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

HE LIMINGChief Financial Officer
SHANG XIAOFENGChief Operating Officer
YU FANChief Executive Officer

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

HUANG XIONGWEIChairman

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

xn--ses554g

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.

Netaddress (network address, URL)

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

Chinese

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

ISO 639-1: ZH-CN

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

Han Simplified Script

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

ISO 15924: Hans

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

U+7f51 U+5740

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

Attachments are not displayed on this form.

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

The IDN table adopted by the Applicant is formulated according to the process specified by Chinese Domain Names Consortium(CDNC),  which is developed according to the guiding principles described in RFC 3743.
The IDN table formulation process, a described in RFC 3743,  is “an effort of the Joint Engineering Team (JET), a group composed of members of CNNIC, TWNIC, KRNIC, and JPNIC as well as other individual experts. It offers guidelines for zone administrators, including but not limited to registry operators and registrars and information for all domain names holders on the administration of domain names that contain characters drawn from Chinese, Japanese, and Korean scripts.” Details of the development process of the IDN table, please refer to RFC 3743 at: http:⁄⁄www.ietf.org⁄rfc⁄rfc3743.txt.

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

网址[U+7f51 U+5740] 网阯[U+7f51 U+962F] 網址[U+7DB2 U+5740] 網阯[U+7DB2 U+962F]


网址xn--ses554g 网阯xn--ur0a718b 網址xn--sesp80g 網阯xn--zf0an51c

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.

16.1 Internet Browser versions

Issue: the older versions of the Internet browsers do not support Chinese domain names, such as Opera (version below 9.2), Firefox (Version below 2.0), Internet Explorer (Version below 7), Safari (version below 3.1 ) and Netscape (version below 8.0).

Applicant’s effort: The Applicant would join with other Chinese gTLDs and Browser vendors to encourage the adoption of latest Internet browsers among Chinese Internet users so that to have a smooth browsing experience on IDNs.

16.2 The TLD white list issue

Issue: the TLD white list of Firefox currently does not include the applied-for string. 

Applicant’s effort: Once the TLD is approved and delegated, the Applicant will notify Firefox of this matter. Firefox shall insert the string into the TLD white list of the Firefox to enable the support of the string. The procedure to do so is described in http:⁄⁄www.mozilla.org⁄projects⁄security⁄tld-idn-policy-list.html.

16.3 Registration Data Directory Services (RDDS)

Issue: RFC 3912 only suggest ASCII encoding in Whois protocol, which is inadequate to support Chinese domain names in the RDDS.

Applicant’s effort: The entrusted Back-End Service Provider have adopted UTF-8 encoding format to support the query and display both in English and Chinese. The Applicant is fully aware that the ICANN is developing the policy Internationalized Registration Data along with the technical standardization work at IETF. The Applicant would work with the Back-End Service Provider to adopt the latest development at ICANN and IETF in this regard.

16.4 Variant Chinese domain names registration issues

Issue: The EPP Protocol does not support bundled registration for simplified, traditional Chinese characters and its variants to the same registrant.

Applicant’s effort: in line with RFC 3743 and RFC 4713, the Applicant and the Back-end Service Provider agreed on the registration policy as such: when registering the Chinese domain names, the registrant will be given a pure simplified Chinese form, a pure traditional Chinese form along with its original form in a bundle. Other variant form of the Chinese domain name will be reserved for the registrant.  The Applicant and the Back-end Service Provider as such have adapted the Extensible Provisioning protocol (EPP) in accordance with RFC 3735 to realize the above mentioned registration policy.

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

[wɑŋ] [tʂi]

Mission/Purpose


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

The mission of the .网址 (“网址” in simplified Chinese is the equivalent to the English term “web address”) gTLD Registry is to provide leading gTLD registry services to Chinese speaking Internet users worldwide through a Chinese IDN TLD that represents the most widely recognized term used to refer to web addresses in Chinese, therefore providing users the most convenient way to remember and navigate to websites in their native Chinese language.

There are over 500 million Chinese speaking Internet users worldwide. Among these Chinese speaking users and the general population, the term “网址” (“web address” in English) is the most recognized term referring to web addresses. For the majority of novice or new Chinese speaking Internet users, other web address terms such as “IP address,” “domain name,” or other terms are not known, but the term “网址” (“web address” in English) is commonly used when searching for web pages. Since many Chinese speaking Internet users have trouble remembering and spelling English and⁄or ASCII character domains such as “google.com,” they currently have no better choice than to rely on what are popularly referred to as “web address directories” or search engines to help them navigate to the web page(s) they want to visit. According to a comprehensive study on Chinese Internet user’s habits conducted by the China Internet Network Information Center (CNNIC), it was found that 94.45% of Chinese Internet users surveyed expressed a strong willingness to use native Chinese language IDNs to navigate to web pages. We hope that by introducing the “.网址” (“web address” in English) gTLD, we can enable Chinese speaking Internet users to conveniently use their native language to utilize the Internet.

The purpose of the .网址 (”web address” in English)gTLD is to provide an opportunity to register and use Chinese IDN gTLD to all individuals, businesses, non-profit organizations, community and government organizations, thereby allowing Chinese speaking Internet users worldwide to conveniently remember and navigate to such organization’s website’s addresses. In the Internet age, online and offline consistency of a brand or name is something that any business or organization looking to promote themselves must strongly consider. A significant and easy to remember “.网址” (“web address” in English) IDN domain is an eye-catching brand advertisement for any business operating in today’s Chinese speaking Internet environment, ultimately limiting opportunity costs associated with using English or ASCII domain names that Chinese users have difficulty with, and increasing organizations promotion and online marketing effectiveness and accuracy towards Chinese speaking Internet users.

About the Applicant: HU YI GLOBAL INFORMATION RESOURCES (HOLDING) COMPANY.HONGKONG LIMITED (Hu Yi Global)

Hu Yi Global, founded in 2001, has over 100,000 customers and is one of Hong Kong’s largest Internet Addressing and Intellectual Property Protection service providers.

Hu Yi Global provides Internet Addressing and Intellectual Property Protection services to businesses worldwide and aims to develop the best, most innovative, high productivity and convenient platform over a highly efficiency network together with an intellectual property rights protection automation system.

Hu Yi Global’s sister company, Guangdong Hu Yi Science Co. Ltd.(Guangdong Hu Yi) located in Guangzhou, China, also founded and majority owned by Mr. Xiongwei Huang, is a provider of Internet Addressing and Intellectual Property Protection services. Guangdong Hu Yi currently has over 30 subsidiaries around mainland China and over 2,000 employees including 1,800 sales persons. It is one of China’s largest Internet Addressing and Intellectual Property Protection services providers with close to 500,000 customers. Guangdong Hu Yi is CNNIC accredited for .CN domain registrations, and Chinese Domain Names. It is also accredited by KNET for Internet Keywords and Wireless Keywords. It’s primary service and product offerings include: Internet addressing resources such as domain names, Internet Keywords, Wireless Keywords, Intellectual Property Protection services such as trademark and copyright registration, and patent registration and protection. Guangdong Bangxin International Intellectual Property Co. Ltd., another subsidiary of Guangdong Hu Yi, is a specialized Intellectual Property Rights related service platform and is a member of the China Chapter of The International Association for the Protection of Intellectual Property (AIPPI), the International Trademark Association (INTA), the China Trademark Association and other industry organizations.

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

I.	Goal
The goal of the proposed “.网址” (“web address” in English) gTLD is to develop, deploy and operate a leading Chinese IDN gTLD of choice for registration and use among Chinese speaking individuals, businesses and organizations, and to make the “.网址” (“web address” in English) gTLD the primary domain of choice for online users searching for information in their native Chinese language. We are committed to having the “.网址” (“web address” in English) gTLD registry operate under and conform to the highest levels of service and quality attainable required by ICANN, the greater Internet governance community and end users, ultimately taking a place on a level equal to the existing legacy gTLDs. As the “.网址” (“web address” in English) gTLD registry, we will develop and implement strict trademark protection regulations, including real name (verifiable identification) registrations, to prevent domain squatting and methods of trademark infringement.

II. Competition, Differentiation and Innovation
As one of the world’s first Chinese IDN gTLDs, we believe that we will be ushering in a new age of Internet usage among Chinese speaking users worldwide which will invigorate and foster competition in the gTLD space and related industries. As we have witnessed with the introduction of IDNs “before the dot” in many TLDs, registries and registrars have opened up new areas of competition that ultimately lead to benefits for users and the greater global internet community.

We believe that the “.网址” (“web address” in English) gTLD differentiates itself from other gTLDs in several ways. First, it is a Chinese IDN. While there will likely be many IDNs introduced into the marketplace in the near future, we believe that there will be limited Chinese IDNs, most of which will be geared towards vertically focused industries. Therefore, we believe that “.网址” (“web address” in English) represents a truly generic TLD that will offer the greater Chinese speaking Internet user population with a viable option to English⁄ASCII gTLDs. Secondly, we believe that the “.网址” (“web address” in English) TLD will provide ubiquity within the Chinese speaking Internet environment due to the large acceptance of the term“网址” (“web address” in English) as the most commonly used term when referring to web addresses of any kind: “IP addresses,” “domain names,”urls,” etc.

We strongly believe that the “.网址” (“web address” in English) TLD will foster many new innovations in domain name value added technology and services at all levels of the registry, registrar and internet and online services provider ecosystem. An a leader in Chinese IDN gTLD registry services, we will both anticipate and strongly encourage companies to develop Chinese language specific innovations such as customized website and mobile application design & development, website content localization, Location Based Services (LBS) and other cutting edge technologies.

III. User Experience Goals
At the heart of the “.网址” (“web address” in English) gTLD registry is our desire and commitment towards improving and enhancing the overall Internet user experience for Chinese speaking users worldwide. We believe that the successful introduction of a Chinese IDN gTLD that is verifiably generic according to modern day linguistic and semantic standards in spoken and written Chinese will help achieve this goal. At the “.网址” (“web address” in English) gTLD registry technology infrastructure level, we will develop and implement the highest service level and quality EPP, DNS and registry related technology to ensure the fastest and most secure resolution of the entire “.网址” (“web address” in English) gTLD domain space and all of its registered domains. By requiring all domain registrants to adhere to strict registration requirements, we will be able to deliver only the most authentic information and content to users. Registrants will ultimately benefit from registry level information homogeneity, uniformity and accuracy that provide a reliable and robust platform for downstream businesses to innovate upon and provide services that consumers will benefit from.

IV. Strict and Enforceable Registration Policy
--Beginning of Registration Policy Description--
I. General Principles for the .网址 gTLD
1. The role of the .网址 registry
The .网址 gTLD is a Simplified Chinese language IDN generic Top Level Domain. The .网址 registry will develop and operate the domain registry and manage the .网址 domain in the interests of the public. The .网址 registry will work with relevant government and industry related organizations to develop, maintain and enforce domain management policies that help promote fair, consistent and efficient registration and usage of the .网址 gTLD.

Registration and usage of the .网址 gTLD is open to any individual, businesses, non-profit, community or government organization that has or plans to have a website presence on the Internet.

2. Registrar Role and Responsibilities
All registration of .网址 domains must be processed through an ICANN Accredited Registrar and such registrar must also be accredited with the .网址 registry. A list of .网址 Accredited Registrars will be made available on the future .网址 registry website.

A .网址 Registrar will provide customer support needed to receive, accept, and process
registrations from qualified entities and individuals desiring to become Registered Name Holders, and to receive, accept, and process orders for cancellation, deletion or transfer of Registered Names. Throughout the term of their registration, Registrar will provide Registered Name Holders reasonable customer service (including domain name record support) and billing and technical support. A Registered Name Holder will always contact the Sponsoring Registrar, not the .网址 Registry, regarding the registration and management of their domain name.

Registrars are the retail outlets for domain names. They are the main point of contact with Registrants (Registered Name Holder -- people or entities who buy and use domain names), and Registrars are responsible for customer service to their Registrants.

Each domain name is sponsored by a Registrar. Each domain resides in the Shared Registry System (SRS) account of its Sponsoring Registrar. Registry objects, such as domain, contact and nameserver objects, are also associated with a Registrar account. Registrars are responsible for maintaining their own domain objects. Reseller, agents and Registrants generally do not access the Registry system directly. Instead, a registrar sends their requests into the Registry SRS.

Registrars are responsible for their retail or wholesale operations and their informational
websites. While the .网址 Registry provides registration reports and billing statements, each Registrar is responsible for maintaining records regarding their customers and their domains under management. Registrars should therefore keep billing records related to their registrants, and should manage their domains appropriately. Domain management systems (online or offline registration systems for registrants, registrant billing and credit-card processing, etc.) are the sole responsibility of the Registrar. Registrars are responsible for all taxation matters.

3. The .网址 Registration Policy Structure
The .网址 gTLD registration policy will be structured to provide a framework for the registration of .网址domain names by eligible and qualified registrants. Each registrant must abide by the .网址 registration policies.

The .网址 registration policy set forth below defines the rules of eligibility and the .网址 domain name registration procedure for each registrant. It also sets forth dispute resolution procedures for the .网址 domain space.

4. The .网址Registration Process
The actual registration of a .网址 domain name will require the successful completion of a domain name registration.

Registration
Provided the registrant meets all the eligibility requirements, they will have the option and ability to register a .网址 domain name through any .网址 accredited registrar that offers .网址 domain registrations through the use of the .网址registry technology protocol provided to registrars.

II. Eligibility Requirements
1. Eligibility Requirements
Each registrant must attest to having, or has plans to have, a website presence on the Internet. A randomized eligibility verification check of 5% of all registrations will be carried out by the registry or designated third party on a regular basis and will make use of various sources to verify that registrants meet eligibility requirements.

III. Domain Naming Rules
1. Spelling Conventions and Valid Characters
.网址 domains can contain the English-language letters A through Z, simplified Chinese characters as defined by the IETF, and the digits 0 through 9 and hyphens (LDH -- Letters, Digits, Hyphens).

Hyphens however cannot be used for the first or last character of the second level domain name. Spaces and special characters (such as !, $, &, ë, and so on) are not currently acceptable. The minimum length allowed for a second level .网址 domain is effectively 3 characters after considering that all 2 Character and 1-Character domains are designated as reserved names based on the ICANN Reserved Names in the .网址 Reserved Names Policy. The maximum number of LDH characters accepted for a second level domain is 63 (i.e. excluding the ʺhttp:⁄⁄wwwʺ and ʺ.网址ʺ portions). Such a limitation is defined by the technical requirements defined by the IETF (Internet Engineering Task Force) for the Internet DNS.

Reserved Names
The registry will reserve and restrict certain names therefore making them unavailable for general registration. However, the registry may open certain names for registration to businesses or organizations in the future, who in the opinion of the registry will use the domain name in the best interests of the public.

Any party interested in registering any of the domain names reserved by the registry is required to submit a written proposal to the registry stating how they propose to use the name. The registry will be responsible for determining whether the applying registrant is suited towards utilizing the domain name in the best interests of the public.

Country names and names of geographical areas
Country names and geographical areas cannot be registered as second level domain names, unless expressly stated in the .网址 registry registration policy.
Provisions for future development
There may also be restrictions on registration of certain types of domain names in consideration of future development of newer addressing types.

3. Unregulated Second Level Domain Registrations
Registrations are available for all non-reserved domain names that follow the “domain name.网址”format and which adhere to the spelling conventions and valid characters rules described above. .网址 domain names are registered on a ʺFirst come, First servedʺ basis. If a domain name is already registered or pending application, then no other registrants may register that name unless the name is unsuccessfully in its registration or expires.

IV. Domain Name Registration Rules
1. Registration Period and Renewals for .网址
The registration and use of all .网址 domains are based on registration periods. The initial registration period for a .网址 domain name is one year. The right to use the .网址 domain name can be renewed at any time during the registration term, subject to the current terms and conditions. .网址 accredited registrars will attempt to contact the registrant prior to the expiration date based on their own terms and conditions, but the registrant is ultimately responsible to perform renewals.

2. Continuing Eligibility
If the registrant ceases to be an eligible registrant of a .网址 domain name as defined by the registration policies of the .网址 registry, then the registrant must cancel registration of any and all .网址 domain names registered under the original registrant entity within 14 days of ceasing to be eligible. The .网址 registry reserves the right to, and will occasionally, verify eligibility and if found to be ineligible, has the right to cancel a registration at any time.

3. Domain Transfers
.网址domains may be transferred only under the following circumstances:
a) the receiving transferee meets all .网址 registration policies; and
b) the transfer is carried out between two accredited .网址 registrars; and
c) when all applicable fees are paid in full

4. Cancellation and Revocation of a .网址Domain Name Registration and its usage
All registrants must agree to the terms set forth with regards to the .网址 registry in such that the registry may cancel and revoke the registration and usage of a .网址 domain name for any of the following reasons:

Change in Status
If the registrant ceases to be an eligible registrant as defined by the .网址 registration policies.

Fee Not Paid
If any portion of the required registration fee is not paid according to the .网址 registration policies.

Breach of Warranty
If a registrant is in breach of warranty as defined in the .网址 registration policies and terms of service.

Inaccurate, Invalid or Misleading Information
If a registrant provides inaccurate, invalid or misleading information including incomplete or incorrect information in any portion of a domain name application.

Failure to Comply with Policy
If the Registrant fails to comply with any requirement as outlined in the .网址 registration policy.

Court Ordered Decision
If a recognized court of law orders that a .网址 domain registration requires its cancellation and revocation.

Improper Use
If a .网址 domain name is used for purposes not related to, or in the best interests of, the public.

Registrant Instruction or Request
If a registrant of a .网址 domain name directly requests or provides instructions for the cancellation of a .网址 registration.

Registration Error
A .网址 domain name registration and usage may be cancelled and revoked if it was registered by mistake in violation of the .网址 registration policies.

V. Domain Contacts and WHOIS Policies
This section describes the requirements for Contact Objects associated with a Domain Object registered with the .网址Registry, as well as policies regarding WHOIS services.

1. “Thickʺ Registry Model
.网址is operated as a ʺthickʺ registry, in which all of the information associated with registered entities, including both technical information (information needed to produce the .网址Zone Files) and social information (i.e. information of associated contacts), is stored within a central registry repository. The registry-registrar protocol supported by .网址is the Extensible Provisioning Protocol (EPP).

2. Contact Information Requirements
Each domain registration must be accompanied by four (4) associated contacts, including:
1. Registrant Contact
2. Administrative Contact (Admin Contact)
3. Technical Contact (Tech Contact)
4. Billing Contact

The same person or organization (Contact Object) can be used to be associated to all 4 contact types. Each contact type must have a minimum of one associated contact. There can only be one (1) Registrant Contact associated with each domain registration. There may be up to a maximum of 10 Admin Contacts, 10 Tech Contacts and 10 Billing Contacts associated with one domain registration.

2.1 Contact Data Requirements

Informational fields and their respective requirements for each Contact Object are described in the table below:
Contact Data Field Requirement Restrictions
Contact Name Required 1-128 Characters
Contact Organization Optional 0-128 Characters
Contact Address 1 Required 1-64 Characters
Contact Address 2 Optional 0-64 Characters
Contact Address 3 Optional 0-64 Characters
Contact City Required 1-255 Characters
Contact State ⁄ Province Optional 0-255 Characters
Contact Postal Code Required 1-16 Characters
Contact Economy ⁄ Country Required 2-Character Country Codes (ISO 3166)
Contact Phone Required +nnn.nnnnnnnnnnnn (E.164 Standard)
Contact Phone Extension Optional nnnnnnnn
Contact Fax Required +nnn.nnnnnnnnnnnn (E.164 Standard)
Contact Fax Extension Optional nnnnnnnn

In accordance with the WHOIS technical standards, only the following characters are accepted in the contact information fields (such as Name, Address, etc.):
• a through z
• A through Z
• 0 through 9
• .,&#()-_ʹ~`!@$%^*+={ }[ ]|:;〈〉?⁄\ʺ〈⁄

More specifically, accented characters (e.g.: ö, è, Ø, Σ, etc.) or non-Latin based characters will not be allowed in registry database fields. Single and double quotes are included in the list of characters. The list is based on normalized string XML data type.

For Phone and Fax fields, as per EPP requirements, phone numbers should be formatted with a plus sign, followed by a one-to-three digit country code, followed by a dot, followed by the phone number including area code. Per “E.164” (The International Public Telecommunication Numbering Plan), the total number of digits allowed is 15, including the country code. An optional Extension field is also available for use for both phone and fax numbers.

For the Contact Country⁄Economy, the corresponding two-letter country codes, as per ISO 3166-1: http:⁄⁄www.iso.ch⁄iso⁄en⁄prods-services⁄iso3166ma⁄02iso-3166-code-lists⁄list-en1.html should be used. Please note that ISO codes do not always match IANA ccTLD country codes.

3. .网址WHOIS Service
The .网址Registry maintains a registry-level centralized WHOIS database that will contain information for every registered .网址second-level domain. The WHOIS service contains data submitted by registrars during the registration process. Any changes made to the data by a registrant will be submitted to the .网址Registry by the Sponsoring Registrar and will be reflected in the WHOIS in near real-time, thus providing all interested parties with up-to-date information for every .网址domain.

For details see technical requirements section of application.

VI. Dispute Resolution Policies
1. UDRP
All registrants of .网址domains, in agreeing to the .网址 registration policies and all terms and conditions are bound by the Uniform Domain Name Dispute Resolution Policy (ʺUDRPʺ). The UDRP applies to challenges to registered domain names on the grounds that domain name is identical or confusingly similar to a trademark in which the complainant has rights.

Full text of the UDRP is located at the following address: http:⁄⁄www.icann.org⁄dndr⁄udrp⁄policy.htm

2. Other Disputes
Pursuant to the Specification 7 of the Registry Agreement, the Applicant will comply with the dispute resolution mechanisms as they may be revised from time to time.

--End of Registration Policy Description--

V. Privacy and Confidential Information
With regards to private or confidential information collected and⁄or stored within our entire registry system, we will implement both technological and procedural measures to protect the privacy and confidential information of registrants and users. All private and confidential data will be stored in secure databases using encryption and leading safeguarding technology.

VI. Outreach and Communication
The “.网址” (“web address” in English) gTLD Registry plans to develop and execute a comprehensive outreach and communications marketing and promotion campaign that will begin well before the official launch of the gTLD and continuing on for the entirety of the gTLD’s operation. These efforts include, but are not limited to: Registry⁄Registrar outreach and business development; online marketing via publisher networks, social networks, and search engines; print advertising and marketing; tv and outdoor advertising; industry related convention sponsorships; scholastic and university outreach.

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

In line with our goal to provide the best user experience for consumers, we will develop and adopt a comprehensive system of operating rules to eliminate and minimize social costs. The “.网址” (“web address” in English) gTLD registry will adhere to strict technological, operational and legal protocols set forth by the industries and communities that the registry operates in.

i. Resolving Multiple Applications
We will institute a Sunrise application period. During the Sunrise application period, applicants with provable trademarks and that which fulfill all other registration requirements will be allowed to apply to register domain names. If there is more than one applicant for a single domain name that fulfills all registration requirements, the applicants will be allowed to participate in an auction in which the domain name registration will be awarded to the highest bidder. After the Sunrise application period, registrations will be on a first-come⁄first-serve basis.

ii. Cost Benefits
The “.网址” gTLD Registry will not implement any advantageous pricing, introductory discounts or bulk registration discounts during its initial launch period. It may, introduce and implement such benefits in the future through promotions to accredited registrars.

iii. In accordance with the Registry Agreement, the “.网址” gTLD Registry will offer registrars the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years.

Additionally, in accordance with the Registry Agreement the “.网址” gTLD Registry will provide registrars with advance written notice of price increases. The “.网址” gTLD Registry will make contractual commitments regarding the magnitude of price escalation as such:

For any 12 month period, the “.网址” gTLD Registry will not make price escalations to exceed 10% of the previous year’s price.

Community-based Designation


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

No

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

Attachments are not displayed on this form.

Geographic Names


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

No

Protection of Geographic Names


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

To minimize any potential abuse of geographic names and to mitigate confusion and dispute, .网址 Registry Operator would reserve the geographic names, and the reserved lists can be revised from time to time at the discretion of the Registry Operator. The reserved words and categories should be published on the website of .网址 Registry Operator. In the event of release of such names, certain procedures will be observed to ensure the proper use of the geographic names. 

22.1 The reservation list
22.1.1 Reserved list as per AGB

As per the Specification 5 of the Registry Agreement, .网址 Registry Operator shall put the following geographic names on reservation. The reserved geographic names are:
Country and Territory Names. The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:
 the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU〉;
 the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
 the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;

Regional or Continental Names. The names are listed as a UNESCO region on the UNESCO website (see http:⁄⁄www.unesco.org⁄new⁄en⁄unesco⁄worldwide⁄) or appearing on the “composition of macro geographical (continental) regions, geographical sub-regions, and selected economic and other groupings” (see http:⁄⁄unstats.un.org⁄unsd⁄methods⁄m49⁄m49regin.htm).

22.1.2 Reserved list of subdivisional names of the countries and territories

In addition to the Country and Territory Names reservation, .网址 Registry Operator will also reserve the names of subdivisions of the countries and territories as listed on ISO 3166-2⁄3. Also, the national geographic names of China in which the registry registered will also be put to reserve list. The names lists include:
 the short form (both in English and in Chinese) of subdivisional names of all country and territory names contained on the ISO 3166-2 list, as updated from time to time; the short form (both in English and in Chinese) of the country and territory names contained on the ISO 3166-3.
 The names (both in English and in Chinese) of the provinces and municipalities of China, including complete form and short form as well as unofficial abbreviation of the geographic names.
 The names (both in English and in Chinese) of the sub-regions of the provinces and the names of the cities and counties in China.

22.2. Procedures to release the Geographic Names
Normally, .网址 TLD will not allow for the release of geographic names. However, the reserved geographic names may be released to the extent that .网址 Registry Operator reaches agreement with the applicable government(s). The release of the geographic names shall follow the below described procedures.

22.2.1 The release of country and territory names
A) The Government or public authority concerned informs the GAC Secretariat of their request to register the name, and the designated beneficiary.
B)The GAC Secretariat authenticates the request and transfers it to the ICANN staff and to .网址 Registry Operator.
C) .网址 Registry Operator verifies the availability of the name and issues an authorization letter that is transmitted directly to the designated beneficiary in the country concerned.
D) The designated beneficiary (the Registrant) registers the name, with an accredited .网址 Registrar, using the authorization letter as their authority.

22.2.2 The release of national geographic names
The reserved national geographic names could be released on the condition that the applicable government(s) support the acceptable use of the domain names and reaches agreement with .网址 Registry Operator. Under this circumstance, .网址 Registry Operator would apply the following mechanism:
A) The government concerned informs the Registry of their request to register the name, and the designated beneficiary.
B) .网址 Registry Operator checks the availability of the name and issues an authorization letter that is transmitted directly to the designated beneficiary
C) The designated beneficiary (the Registrant) registers the name, with an accredited .网址 Registrar, using the authorization letter as their authority.

Registry Services


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

23.1.	Registry Services 
Hu Yi Global is the Registry Operator of the TLD ʺ.网址ʺ (hereinafter referred to as ʺ.网址ʺ Registry) that provides the services as specified in Specification 6, section 2.1 (a) and (b) in ICANNʹs Applicant Guidebook as well as those as specified in Appendix A. In particular, the ʺ.网址ʺ Registry prohibit the use of wildcard per requirements specified in Specification 6, section 2.2.
The ʺ.网址ʺ Registry provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the ʺ.网址ʺ Registry will abide with 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 Applicant shall also implement support for IDN, DNSSEC and IPv6.
Hu Yi Globalwill outsource the technical operation to KNET (“Back-End Service Provider”) while the remaining operation will be handled byHu Yi Global (“Business Operation Provider”).The KNET Shared Registry Platform (“KSRP”) is designed and implemented to provide 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 (attached in Q23 answer).
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) The firewalls, IDS and network traffic monitoring system are deployed in to provide network layer security and protection against attacks;
f) The databases, applications, source code, documents, system logs and other business data of all services are backed up offsite and offline on a regular basis so that they can be restored quickly in case of a failure;
g) 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 an geo-dispersed backup data center are deployed in an active-standby manner; when the primary data center is not available, the backup data center is activated to continue the services; high availability of the services are guaranteed by 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).
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.
The ʺ.网址ʺ Registry provides the SRS service. Registrars collect the data from end users relating to registration contacts, domain names and name servers and submit them to the ʺ.网址ʺ Registry via the SRS system; the ʺ.网址ʺ Registry also provides add-on auxiliary services for Registrars to submit other business-related data as required by ʺ.网址ʺ Registry;
23.2.1. Service Level
The service level of the SRS provided by the ʺ.网址ʺ 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 provides 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(www.nic.网址)to make the following information available:
a) Registration management policies;
b) Hotline and Email address for complaints⁄reporting;
c) Public key for DNSSEC;
d) Incident report;
e) Advanced notice of planned outage (due to system upgrade, etc.)
f) SLA report;
g) Whois service.
The ʺ.网址ʺ 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.
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 ʺ.网址ʺ 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 ʺ.网址ʺ 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 the CAPTCHA to reduce automated malicious queries.
c) Both Web Whois and Whois Server services impose a cap on the maximum number of queries in unit time from the same IP address to reduce the query volume from automated programs.
23.7.3. Stability
In addition to those described in 23.1.3, the following stability measures apply to services in section 23.7.
a) The Whois service follows RFC 3912, meeting the requirements specified in Specifications 4, 6 and 10 of the ICANNʹs gTLD Applicant Guidebook.
b) The Whois service runs on redundant server clusters that are load balanced; an offsite backup data center is established to address disastrous emergencies.
23.8. Internationalized Domain Name Service
The TLD applied in this application is an internationalized domain name. KNET formulated the IDN policies for ʺ.网址ʺ TLD and developed KSRP based on the latest IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄implementation-guidelines.htm).
The IDN labels in ʺ.网址ʺ Registry follow the .CN Chinese IDN Table 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 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 it is deemed to cause confusion due to visual similarity.
The query function of the Whois system accepts domain names in both UTF8 and ASCII formats.
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 .COM (supporting IDN), .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 .COM (supporting IDN), .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 simple 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 for ʺ.网址ʺ have very good support to displaying Chinese domain names.
In summary, the introduction of IDNs in ʺ.网址ʺ 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.
ʺ.网址ʺ 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: Test-Bed. At this stage, KNET intends to build an internal test-bed on which the technical tracking, verification and testing will be performed; the DNSSEC chain of trust will be built on a small set of selected second and lower level domains under the applied TLD; the DNSSEC Operational Practices (RFC 4641) will be followed and exercised. The goal is to complete the technical verification of DNSSEC and to develop best practice documentations based on the lessons learned. This stage is estimated to last for 6 months;
b) Stage 2: Public Trial. At this stage, the chain of trust will be built on domain names that are registered for trial based on the best practice developed at the first stage, and the DNSSEC policies will be verified or adjusted based on the trial results. This stage is estimated to last for 6 months;
c) Stage 3: Production. At this stage, the DNSSEC will be put into use officially according to the achievements of the previous two stages. The implementation of DNSSEC will be applied to the TLD and all of its sub domains in production KSRP.
After implementation of DNSSEC, the performance indicators of relevant services will be affected to some extent, such as increase in storage capacity, in CPU load and memory of the resolution system and in network bandwidth for resolution services. However, such implementation 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 one of the important measures against the security defect of DNS system. The public key infrastructure (PKI) is used to add a digital signature to each resource record set to improve the security level of domain system.
There are two kinds of keys, KSK (Key-signing Key) and ZSK (Zone-signing Key), created for DNSSEC. The former is used to sign DNSKEY resource record sets while the latter is used to generate signatures for all resource records within the zone, including KSK record sets.
KSRP uses hardware encryption equipment HSM (complying with FIPS 142-2 level 3) to generate keys; the keys stored in an HSM cannot be exported; they are automatically synchronized among the HSMs. Unauthorized access to private keys of KSK and ZSK is strictly forbidden, and offline storage is 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.
Before DNSSEC is fully deployed for the ʺ.网址ʺ Registry, KNET will upgrade KSRP capacity in database backend servers, disk space, network bandwidth, DNSSEC signing device, other supporting systems and equipment to ensure operation stability and redundancy.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

24.1.	Overview 
ʺ.网址ʺ Registry provides Registrars with a registration interface for the domain ʺ.网址ʺ 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 ʺ.网址ʺ TLD domain name registration in the knowledge base.
Registrars may also access the business support system via FTP to download historical data such as domain operation records and billing reports upon successful authentication.
c) Registry Business Support System

Please refer to Figure 24-2 in Q24_attachment for the system architecture of the Registrar business support system.
The Registry business support system provides business staff of ʺ.网址ʺ Registry with the support services concerning domain registration, including auditing of newly registered domains, recharging of registrarsʹ accounts, and locking⁄unlocking of domains.
The registry business support system will regularly compile the registered domain data and zone file into a data file with specified type and formatting of content as described in ICANNʹs Registry Agreement, and uploads the data file on specified SFTP for ICANN and its designee to access and download.
In addition, the registry business support system will regularly generate a data file with specified type and formatting of content as described in ICANNʹs Escrow Agreement, and uploads the data on specified SFTP of the escrow service provider NCC Group for its service provision.
d) Zone File Synchronization Service
The zone file synchronization service is responsible for synchronizing changes made to the SRS database to the master DNS nodes, and through which all global DNS nodes are subsequently updated.
e) Databases
The SRS database is the master database that stores information about domains, contacts and hosts submitted by the EPP server. It is replicated to the Whois database using the Oracle Advanced Replication. The Registrar & Registry (hereafter referred to as R&R) business support database stores the data relating to the support business, such as billing reports, and historical auditing records, etc..
24.1.2. Physical Architecture
Please refer to Figure 24-3 in Q24_attachment for physical architecture of SRS.
The SRS system and the R&R business support system are deployed in multiple servers that are clustered and load balanced via F5s; both the SRS master database and R&R business support database achieve high availability via Oracle Veritas. A disk array is deployed at the back-end for data storage redundancy and for high throughput database access.
24.1.3. Equipment List
Please refer to Table 24-1 in Q24_attachment for a list of equipment of the SRS (excluding any hardware shown in the topological diagram of the primary data center, such as routers or firewall).
24.2. Operations Plan
24.2.1. Availability
The SRS of the KSRP is able to provide 99.9% availability, ensuring the monthly down time not exceeding 43.2 minutes, therefore fully meet the 98% availability requirement specified in ICANNʹs Specification 10. In addition, the SRS is also redundantly deployed at the backup data center. If the primary data center goes off-line, registry services are switched over to the backup data center within 30 minutes to ensure high availability of the services.
Specifically, SRS ensures high availability in the following aspects:
a) The SRS software has been built via rigorous engineering disciplines such as code review, unit testing and daily builds. Any SRS build must pass the thorough integration testing, system testing and acceptance testing prior to deployment in production.
b) Both the hardware and software systems are redundantly deployed. Load balancers (F5) are deployed to distribute requests to server clusters to mitigate unplanned server hardware and software failures. For example, the EPP server is deployed on multiple servers as a cluster behind the load balancer so that even if one of the servers goes down, F5 will automatically distribute the requests to the rest of functioning servers, to ensure the registry services continuity.
c) The database of the SRS achieves high availability via Oracle Veritas to prevent any unplanned outages of the database backend.
24.2.2. Performance
The ʺ.网址ʺ Registry plans to be registered 49,100 domain names within 3 years. When the registration volume reaches such target point, the ʺ.网址ʺ Registry needs to handle about 147594.6 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 ʺ.网址ʺ Registry, but also to scale for future demand of ʺ.网址ʺ 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
SRS is developed and deployed using distributed technology that is able to scale both vertically and horizontally as follows:
a) Support vertical scalability by upgrading the hardware of online servers;
b) Support horizontal scalability by deploying server hardware and software systems in a cluster;
c) When the system load reaches the maximum capacity of the SRS system, it can be upgraded by adding more servers and bandwidth to meet the performance and throughput capacity needs
24.2.4. Security
In order to ensure the security of the SRS, the KSRP has taken the following measures:
a) SSL⁄TLS protocol is used for connection between the SRS and the clients. When connecting the SRS, a Registrar is required to be authenticated with SRS using its user name, password, IP address and the digital certificate authorized by the KSRP; if the Registrar fails the ID authentication 3 times, it has to wait for 30 minutes before another attempt;
b) SRS has put a strict restriction on the number of connections created by Registrars as well as the idle time in TCP;
c) SRS is deployed in the DMZ in order to prevent unauthorized network access to the backend database.
24.2.5. Data Synchronization
Data synchronization between the master database of SRS and the Whois database is realized via Oracle Advanced Replication at an interval of 5 minutes.
Data synchronization between the primary and the backup data center is realized via Oracle Dataguard at an interval of 5 minutes.
24.2.6. Operations and Maintenance
The following operations and maintenance measures have been established to guarantee the quality of services.
a) SRS is being monitored and protected on a 7×24 basis. With the monitoring system, KSRP keeps track of the performance of the whole system so that it can take timely measures to address any emergency;
b) The ʺ.网址ʺ Registry and KSRP have established a thorough emergency response mechanism to effectively handle emergency situations. The mechanism provides handling and upgrading procedures for different types of failures based on pre-classified severity levels.
24.3. Compatibility
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 ʺ.网址ʺ, 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. See Table 31-11in Q31_attachment for the overall human resource planning of KSRP. The human resource in Table 31-11 can be allocated for other systems at the same time. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.

25. Extensible Provisioning Protocol (EPP)

25.1.	Overview 
ʺ.网址ʺ Registry provides services to the public through KSRP provided by KNET. KSRP provides Registrars with a registry service interface for the domain name ʺ.网址ʺ over EPP 1.0. KNET has years of experiences in implementation and maintenance of the EPP1.0 interface for the .cn Registry.
25.2. Introduction to EPP
EPP is an xml-based text protocol. It is widely used as a standard protocol for domain name registration between Registry and Registrar.
The EPP protocol suite consists of RFCs 5730~5734, RFC 3735, RFC 3915 and other relevant RFCs. The core of EPP is specified in RFC 5730, which defined the EPP commands, request-response mechanism, message format, result code and other basic protocol elements. RFCs 5731~5733 define the mapping of domain name, contact and host objects on EPP respectively. RFC 5734 explains how to safely implement EPP over TCP. RFC 3735 provides guidelines on how to extend EPP. RFC 3915 extends EPP to handle different redemption grace periods in registration life cycle. RFC 5910 describes how to support DNSSEC based on EPP. The aforementioned RFCs cover all functions, procedures and expansion mechanisms required by domain registry services.
EPP provides four basic service elements: service discovery, commands, response and an extension framework.
The EPP commands are divided into session management commands, query commands and object transform commands. The first category is used to establish and close connections between a client and the server; the second category is used to query information such as domain name, contact and host from server; the last category is used to manage the domain name, contact and host objects.
The responses to EPP commands must include a result code and a detailed description of the code. The result code is a 4-digit number. The first digit represents success or failure of command execution (1 for success, 2 for failure); the second digit represents the classification of responses (6 categories in total); the last 2 digits represent the explicit description of the result code in each category of response. For example, an result code for an EPP command is 1000, where 1 stands for success of command execution, the second digit 0 implies this EPP command is ʺProtocol Syntaxʺ (one category of responses), and the final two digits imply the description of the result code is ʺCommand completed successfullyʺ.
KSRP implements EPP based on TCP (refer to RFC 5734). The server listens on port 700. The client issues EPP commands to the server after both sides have passed the two-way certificate authentication and have successfully completed the execution of the Login command. The EPP server executes the received commands in order. Upon completion of processing an EPP command, the server packages the results into an EPP response to be returned to the client. Both sides repeat the request-response cycle until either the client requests the server to close the connection (via the Logout command) or the execution of a command requires that the server terminate the connection after the command execution (according to RFC 5730, the result codes 2500~ 2502 demand that the server proactively close the connection).
25.3. APIs Provided for Registrars via EPP
KSRP implements registration APIs for Registrars based on EPP1.0. These APIs cover all functions required by domain registry services, including opening and closing of connections, and processing of commands such as query, creation, modification, transfer and deletion of domain, contact and host objects.
a) Session Management
APIs provide Login command and Logout command to Registrars. By using these commands, Registrars can interact with KSRP, such as executing ID authentication (via Login command) or closing connections (via Logout command).
A Registrar sends the Login command to request ID authentication and session establishment with the EPP server; Upon successful authentication and session establishment with the EPP server; upon successful authentication and session establishment, Registrars begin to send other EPP commands. Each of the subsequent commands from shall contain the authentication token and the Registrarʹs password. When the Registrar completes the session, it may send a Logout command to the EPP server to close the connection.
b) Query
APIs provide the query commands such as Check command, Info command and Transfer command to Registrars. Registrars may use these APIs to query information or status about domains, contacts and host objects. (Please refer to Table 25-1 in Q25_attachment)

The Check command is used by Registrars to check the existence of the queried data objects (domain names, contacts or hosts).
The Info command is used by Registrars to retrieve the detailed information about domain names, contacts or hosts that exist in the Registry.
The Transfer command is used by Registrars to check the current transfer status of domain names and contacts.
In addition to the above-mentioned commands, Registrars may also use the Poll command to query and retrieve the asynchronously queued service messages from the EPP server.
c) Object Change
APIs provide several object change commands to Registrars. Through these commands, Registrars may create, modify, delete and perform other operations on domain names, contacts or hosts. (Please refer to Table 25-2 in Q25_attachment)

The Create, Update and Delete commands are used by Registrars to perform basic management functions on domain names, contacts and hosts.
The Renew command is used by Registrars to renew a domain name.
The Transfer command is used by Registrars to transfer domain names or contacts.
The Restore command is closely related to the redemption grace period. When a domain name is deleted, its EPP status is ʺpendingDeleteʺ and the RGP status is ʺredemptionPeriodʺ. Registrars are allowed to restore the deleted domain names to the normal state via the Restore command (Restore is not an EPP command in fact; it is implemented by the extended Update command).
d) Miscellaneous
KSRP ensures that all the APIs comply with RFC 3915 and RFC 5910 to support not only redemption grace period operation such as registry grace period and renew grace period but also DNSSEC.
During the add, renew, or transfer grace period, if a Registrars deletes a domain name, the cost incurred will be refunded to the Registrar by the Registry.
If a domain name expires, the Registry will determine whether to auto-renew a Registrarʹs account and enter the auto-renew grace period based on its account balance. If the Registrar deletes the domain name during the period, the renewal fee incurred will be refunded by the Registry.
Regarding the support for DNSSEC, Registrars may submit the information of Delegation Signer to the Registry over EPP and perform modification and deletion operations.
25.4. Compatibility
The interfaces of KSRP for Registrars comply with EPP1.0 as defined by IETF RFCs and support DNSSEC and redemption period functions.
25.4.1. Compliance with RFCs
The interfaces for Registrars mainly follow the RFCs 5730~5734 and RFC 3915. If the standard EPP canʹt meet certain specific business requirements, extensions will be made to KSRP based on RFC 3735.
a) Compliance with RFC 5730
RFC 5730 is an overall description of the EPP, mainly defining the EPP message format, result code and date format. KSRP strictly follows the RFC as the basis for its EPP implementation.
b) Compliance with RFC 5731
KSRP complies with RFC 5731 in implementing the domain-related command, such as Create, Modify, Delete, Check, Transfer and Info.
c) Compliance with RFC 5732
KSRP complies with RFC 5732 in implementing the host-related commands, such as Create, Update, Delete, Check, and Info.
d) Compliance with RFC 5733
KSRP complies with RFC 5733 in implementing the contact-related commands, such as Create, Update, Delete, Check, and Info.
e) Compliance with RFC 5734
KSRP complies with RFC 5734 in implementing TCP-based EPP and performs certificate-based authentication via TLS to ensure the data security.
f) Compliance with RFC 5735
KSRP has not yet used RFC 5735 to extend EPP protocol. However, if the ʺ.网址ʺ Registry business requires functional expansion to be made to the standard EPP, KSRP will strictly follow the RFC 5735 and the requirements specified in the agreement and specifications in ICANNʹs Registry Agreement.
25.4.2. Specification Related to Redemption Period (RFC 3915)
KSRP complies with the RFC 3915 in implementing the registration life cycle policy, including add grace period, renew grace period, transfer grace period and auto-renew grace period, as well as the corresponding statuses.
25.4.3. Specification Related to DNSSEC (RFC 5910)
KSRP complies with RFC 5910 and RFCs 4033~4035 in implementing support for DNSSEC and enabling Registrars to submit their DS record to the Registry and to perform the modification and deletion operations.
25.5. Consistency
25.5.1. Consistency with Technical Plan
The SRS of KSRP fully implements EPP1.0, covering all functionalities required by the domain name registry services. Moreover, it provides Registrars with the fully tested EPP client and detailed documentation of its APIs.
25.6. Resourcing Plan
The development and test work for the SRS has been completed. In addition, the OT&E (Operational Testing and Evaluation) environment is also made available at ote.tld.knet.cn via port 3121. Please refer to Table 25-3 in Q25_attachment for the resourcing plan.

26. Whois

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 49,100 domain names will be registered under the ʺ.网址ʺ TLD within 3 years after its launch and when the registration volume reaches such target point, there will be 58101.66 queries a day . KSRP is designed to scale to handle 30 million domains. The performance test results shows that KSRPʹs Whois system is capable of handling 5000 queries per second or about 430 million queries a day with the maximum response time not exceeding 1150ms.
As a result, KSRP exceeds the performance indicator of the Whois system specified by ICANN and is scalable for future demands.
Comparison with SLR Indicators
See the Table 26-2 in Q26_attachment for the contrast between the test data of the Whois system and the SLR indicators specified in Specification 10.
26.2.3. Scalability
The Whois system supports both vertical and horizontal scalability. When KSRP reaches its maximum domain name capacity, the performance and throughput capacity of the Whois system can be expanded by upgrading production server hardware (vertical scalability) and⁄or adding more servers and bandwidth (horizontal scalability).
26.2.4. Data Synchronization
Data in the SRS database are synchronized to the Whois database via Oracle Advanced Replication at an interval of 5 minutes; the changed data of Whois database are synchronized to the full-text search system at an interval of 10 minutes.
Given the above data synchronization intervals, the command-line query requests and the web-based query requests have a latency of about 5 minutes, and the searchable query has a latency of about 20 minutes. Both latencies fully meet the Whois data update time (a latency of 60 minutes) specified in Specification 10.
26.2.5. Searchable Whois
KSRP implements the searchable Whois function via the full-text search technology of Apache Solr. The user logs on to the page specified by the Whois Web Server after passing the ID authentication, and inputs the query criteria as required in Specification 4; the Whois Web Server will forward the query request to the full-text search system which searches and returns the qualified results to the result page of the Whois Web Server.
How to Prevent Abuse
The searchable Whois function may be abused by malicious users to send spams to the Registrants or Registrars by harvesting email addresses from the query result. Such abuses may cause negative impacts on the Registrants and Registrars that may violate local laws and policies.
The ʺ.网址ʺ Registry will take the following measures to prevent the searchable Whois function from abuses without violating local laws and policies:
a) The user must input the correct CAPTCHA before submitting each searchable Whois query request.
b) Only those insensitive contents meeting Specification 4 are allowed to be displayed in query results.
c) No more than 20 results are allowed to return for each searchable Whois query.
d) Impose a cap on the maximum number of queries in unit time from the same IP address.
26.3. Compliance with Relevant Specifications
26.3.1. Compliance with RFC 3912
The Whois system complies with RFC 3912 and listens to port 43.The client interacts with the Whois Server via TCP to complete the request-response process: the Client submits a text-based request to the Whois server; the Whois server then returns the query result in a text-based response to the Client.
26.3.2. Compliance with Specification 4 of the Registry Agreement
KSRP fully complies with Specification 4 of the Registry Agreement in terms of Whois query, zone file access and bulk registration data access.
a) Whois Query
The Whois system fully meets the relevant requirements specified in Specification 4 in terms of data objects (domain name, Registrar and name server), contents, queries and response format.
The Whois system provides two query methods: command line query and web-based query. The former is implemented according to RFC 3912 where the client interacts with the Whois Server in a request-response pattern. The latter is implemented as follows: the user accesses a specified page, inputs the query contents, selects query criteria (domain name, Registrar, name server), types in a CAPTCHA and then submit the query request. After receiving the request, the Whois Web Server will check the CAPTCHA. If the code matches, the Whois Web Server will retrieve the query result from the Whois Server and show the response content to the users in the resulting page.
b) Zone File Access
The ʺ.网址ʺ Registry allows third-party entities who enter into an agreement with the Registry to access the zone file through KSRP according to Specification 4. It also provides ICANN or other ICANN designated partners with bulk access to authoritative zone files in the format and manner as specified in Specification 4.
c) Bulk Registration Data Access
The ʺ.网址ʺ Registry will provides ICANN with registration data at specified time through KSRP. The content and format of provided data completely comply with the applicable requirements in Specification 4.
Moreover, when a Registrar is no longer able to provide the domain registry services, the ʺ.网址ʺ Registry will submit all domain name data owned by that Registrar to the ICANN within the specified period. The content and format of provided data completely comply with ICANNʹs requirements.
26.4. Resourcing Plan
The development and test work for the Whois system of the KSRP has been completed. See Table 31-11in Q31_attachment for the overall human resource planning of KSRP. For the resourcing plan of this system, please refer to Table 26-3 in Q26_attachment and the above 26.1.3 for equipment resource planning.

27. Registration Life Cycle

27.1.	Overview 
The ʺ.网址ʺ Registry defines the life cycle of the domain names under ʺ.网址ʺ based on IETF RFCs required by ICANN and its own business needs. The life cycle consists of 6 periods: Available, Registered, Autorenew Period, Redemption Grace Period and Pending Delete.
A domain name upon creation officially takes effect and enters the Registered period (the EPP status is serverTransferProhibited for the first 60 days, afterwards, it changes to ok; the RGP status is addPeriod for the first 5 days and then changes to N⁄A ). It takes no more than 3 days for a domain to be manually examined after creation.
Please refer to Figure 27-1 in Q27_attachment for the full life cycle of a domain name, covering the periods such as creation, taking effect, expiry and final deletion.
27.2. Registration Life Cycle and Status
There are totally 18 registration statuses defined for EPP in RFCs 5730~5734 and for RGP in RFC 3915, excluding those that can be set by Registrars, such as clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited).
The EPP statuses include OK, inactive, pendingCreate, pendingDelete, pendingRenew, pendingTransfer, serverHold, serverDeleteProhibited, serverRenewProhibited, serverTransferProhibited, and serverUpdateProhibited.
The RGP statuses defined in RFC 3915 include addPeriod, autoRenewPeriod, renewPeriod, redemptionPeriod, transferPeriod, pendingRestore, and pendingDelete.
27.2.1. Transition of Registration Status
During the whole registration life cycle, the registration status of the domain name evolves as a result of the life cycle period changes and the operations performed. Please refer to Figure 27-2 in Q27_attachmentfor the registration status transition in creation and deletion period of life cycle.
Other operations may affect registration status transition in the life cycle as follows:
a) Update Operation
The Update operation may only be performed on a domain name that is in the Registered period. After the operation, the RGP and EPP status remains unchanged.
b) Renewal Operation
The Renewal operation may be performed on a domain name that is in either the Registered or the Auto-renew period.
When a domain name enters the Registered period, the EPP status is changed to pendingRenew (the previous status is ok) or is added with pendingRenew. After the operation Renewal is done, the EPP status changes back to the previous one. The RGP status changes to renewPeriod; it will change back to its previous status 5 days later.
When a domain name enters the Auto-renew period, the EPP status changes to ok, and the RGP status changes to renewPeriod; it will changes back to ʺN⁄Aʺ 5 days later.
c) Transfer Operation
The operation Transfer may only be performed on a domain name that is in the Registered period and has been registered for more than 60 days. After the operation is performed, the EPP status changes to pendingTransfer; it will change back to its previous status once the transfer is complete. The RGP status changes to transferPeriod; it will changes back to its previous status 5 days later.
d) Restore Operation
The operation Restore may only be performed on a domain name that is in the Redemption Grace Period. Once the Registrar submits a restore request, the RGP status of the domain name changes to pendingRestore; if a formal restoration report is submitted within 7 days, the domain name changes back to its normal registration status (EPP: ok; RGP: N⁄A), otherwise, the registration status of the domain name changes back to the previous one.
27.2.2. Description of Status Transition
For each life cycle period of a domain name, the registration status transition is listed as below:
a) serverHold: all operations on a domain name are forbidden and the domain name canʹt be normally resolved.
In the Registered Period, if the Registry receives any complaint about that domain name, it will set the domain nameʹs EPP status to serverHold. If relevant competent authority confirms that the domain name is being abused or engaged in fraud, the domain nameʹs EPP and RGP statuses will be set to pendingDelete and the domain name will be transitioned to the Pending Delete period. Otherwise, the Registry will restore the domain nameʹs EPP status to ok and reset the RGP status to ʺN⁄Aʺ.
b) serverTransferProhibited: the domain name may be renewed, modified or deleted but not transferred.
When a domain name is in the Registered period, the EPP status for the first 60 days is serverTransferProhibited. If the Registrar 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 serverTransferProhibited and serverUpdateProhibited, and the RGP status is autoRenewPeriod. After 45 days, if the Registrar doesnʹt make a deletion request, the EPP status changes to ok and the RGP status is cancelled; if the Registrar does make a deletion request within the 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod and will be cancelled 5 days later.
c) serverUpdateProhibied: a domain name may be renewed, transferred or deleted but not updated.
When a domain name is in the Autorenew Period, the EPP status is serverUpdateProhibited and serverTransferProhibited, and the RGP status is autoRenewPeriod. If the Registrar doesnʹt make a deletion request within 45 days, the EPP status changes to ok and the RGP status is cancelled. If the Registrar does make a deletion request within 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod, which will be cancelled after 5 days.
d) serverRenewProhibited: a domain name may be updated, transferred or deleted but not renewed.
e) ok: a domain name may be updated, renewed, transferred and deleted.
If the Registrar makes an update request, the EPP status changes to pendingUpdate; it will change back to ok after the update operation is complete within 3 working days.
If the Registrar makes a transfer request, the EPP status changes to pendingTransfer,; it will change back to ok after the transfer operation is complete. The RGP status is set to transferPeriod that will last for 5 days.
If the Registrar makes a deletion request, the EPP status changes to pendingDelete and the RGP status is set to pendingDelete.
If there is any complaint about the improper use of the domain name, the EPP status changes to serverHold. If the domain name is confirmed to be free from any abuse or fraud, the EPP status changes back to ok; otherwise, both EPP and RGP statuses change to pendingDelete.
f) inactive: within this status, the domain name is not associated with a host and thus canʹt be resolved.
If the Registrar submits a deletion request, the EPP status changes to pendingDelete and the RGP status changes to pendingDelete.
If the Registrar submits an update request to associate the domain name with a host, the EPP status changes to ok.
g) pendingDelete: with this status, the domain name can neither be resolved, nor can it be updated or transferred.
If a domain name is in the Registered period or its EPP status is inactive or serverHold when the deletion operation is being performed, the EPP status changes to pendingDelete. The RGP status is set to pendingDelete. The domain name will be deleted after 5 days.
If a domain name is in the Autorenew Period when the deletion operation is being performed, the EPP status changes to pendingDelete, and the RGP status is set to redemptionPeriod.
h) pendingTransfer: this status indicates that the domain transfer request has been accepted. With this status, no update, renew, or delete operation can be performed on the domain name although the domain name is resolvable in DNS. After the transfer is complete, the EPP status changes back to its previous status. The RGP status is set to transferPeriod, which will be cancelled after 5 days.
i) pendingUpdate: this status indicates that the domain name update request is being processed. The domain name can be normally resolved at that time; after completion of update, the pendingUpdate will be deleted from the EPP status which will changes back to its previous one.
j) 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.
k) 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.
l) 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.
m) 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.
n) 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.
o) 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.
p) pendingRenew, pendingUpdate: these two statuses are not applicable. The renewal and update of ʺ.sohuʺ are performed in real time, so there is no manual review or the third partyʹs verification.
27.3. Compliance with RFCs
Taking the local policies and laws as well as its own businesses needs into account, the ʺ.网址ʺ Registry makes some extension for the registration life cycle of the domain name based on RFCs 5730~5734 and RFC 3915.
27.4. Consistency
27.4.1. Commitment to Registrant
The Registry Operator signs agreements with Registrants via the Registrars. These agreements strictly follow the policies of registration life cycle and provide management functions for domain names as directed by ICANNʹs requirements, agreements and regulations.
27.4.2. Technical Plan
For SRS, the EPP status can be used to determine whether a domain name can be updated, renewed, transferred or deleted, etc. The SRS fully supports redemption grace period operations defined in the RFC 3915 using the RGP status;
For DNS, the EPP status of a domain name is needed to determine whether the domain name is deployed in the root DNS zone file. It is also used to decide whether DNS service will be provided to the domain name.
For Whois, the EPP and RGP statuses of a domain name will be shown to the user in the query results.
27.5. Resourcing Plan
Please refer to Table 27-1 in Q27_attachment for the resourcing plan.

28. Abuse Prevention and Mitigation

Abuse Prevention and Mitigation

The Applicant would not tolerate any abuse of the domain names under its management. In this section, the Applicant would describe the proposed policies and procedures to prevent abusive registrations and minimize other activities that have a negative impact on registrants and Internet users.
28.1 Domain Anti-Abuse Policies
28.1.1 Categorization of the abuses

The Applicant would like to adopt the definition on the abuse by the Registration Abuse Policy Working Group (RAPWG), that the abuse is an action that:
a. causes actual and substantial harm, or is a material predicate of such harm, and
b. is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.
However, the RAPWG also finds out that the differences between registration issues and use issues have a very distinct impact to the TLD when it comes to the capacity to contain these two abuses.
Registration issues are related to the core domain name-related activities performed by registrars and registries. These generally include (but are not limited) to the allocation of registered names; the maintenance of and access to registration (WHOIS) information; the transfer, deletion, and reallocation of domain names.
In contrast, domain name use issues concern what a registrant does with his or her domain name after the domain is created—the purpose the registrant puts the domain to, and⁄or the services that the registrant operates on it. These use issues are often independent of or do not involve any registration issues.
Pursuant to the classifications of the domain name abuses, the applicant would like to adopt the following policies and mechanisms to address the potential abuses concerning the “.网址” TLD.

28.1.2 Anti-abuse Policies
With reference to the final report of the RAPWG, the Applicant will adopt the following clauses in the Registration Agreement that the abusive use of domain names will result in registration cancellation, domain name suspension or take down action.
The abuses are categorized as the following types:
I) registration abuse, includes but not limited to Cybersquatting; Front-running; Gripe sites; Deceptive and⁄or offensive domain names; Fake renewal notices; Name spinning; False affiliation; Cross-TLD Registration Scam; Domain kiting ⁄ tasting.
II) Abusive uses of domain names, includes but not limited to phishing, pharming, spoofing, malware⁄Botnet, Pay-per-click\Traffic diversion.
The Registration Agreement states that the registrant “represent, warrant, and agree that you hold the necessary rights to use or permit to use any item, word, or term submitted through the DNR Services, and that such use shall not in any way to the best of your knowledge and belief:
(i) violate or potentially violate any right of any third party, including infringement or misappropriation of any copyright, patent, trademark, trade secret, or other proprietary right;
(ii) constitute or potentially constitute violations, such as, without limitation, false advertisement, unfair competition, defamation, invasion of privacy, invasion of rights, and discrimination;
(iii) cause or potentially cause a business dispute, personal dispute, or any other dispute;
(iv) be or potentially be unlawful, harmful, fraudulent, libelous, slanderous, threatening, abusive, harassing, defamatory, vulgar, obscene, profane, hateful, or otherwise offensive;
(v) be or potentially be racially, ethnically, or ethically objectionable; or
(vi) constitute a criminal offense, give rise to civil liability, or otherwise violate any applicable law, including local, provincial, state, national, international, or other laws. ”
Pursuant the Registration Policy published on the website of the Applicant, the Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on suspension, takedown or similar status, that it deems necessary, in its discretion;
(1) to protect the integrity and stability of the registry;
(2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process;
(3) to avoid any liability, civil or criminal, on the part of the Applicant, as well as its affiliates, subsidiaries, officers, directors, and employees;
(4) per the terms of the registration agreement or
(5) to correct mistakes made by the Applicant or any Registrar in connection with a domain name registration.
The Applicant also reserves the right to place upon registry suspension, takedown or similar status a domain name during resolution of a dispute. Abusive uses, as defined above, undertaken with respect to “.网址” domain names shall give rise to the right of the Applicant to take such actions in its sole discretion.

28.2 Abuse prevention Mechanisms
28.2.1 Anti Abuse Contact Window
The Applicant will publish its domain name anti-abuse policies at the website (www.nic.网址), and also establish an online contact for handling of domain name abuse complaints. The contact information will include at least fixed telephone number, fax number and email address as listed below:
Fixed phone: 852 2531 9399
Fax: 852 25251105
Email: abuse@nic.网址
A team will be assigned to handle the complaints. All accredited registrars of the TLD will be required to set up a contact to liaise with the registry on abuse mitigation purpose. The anti-abuse policy will also be shown on the website of the registrars.
Any changes on the contact information will be published on the Registry Operator’s website, and will notify registrars and ICANN in a timely manner.
28.2.2 WHOIS accuracy Requirement
The Applicant believes that an accurate and genuine WHOIS information requirement is essential to the proper use of the domain name and is vital in tackling the abuses of the domain names. The applicant hence require the registry, registrars and registrants to make sure the WHOIS information of the registrant is accurate and genuine, any update of the WHOIS information shall be done in a timely manner.

Requirement for Registrants
When registering a “.网址” domain name, the Registrant has to consent to clause on WHOIS requirement at the Registration Agreement, and ensure that the submitted registration information is authentic, accurate and complete. The registrant has to consent that should there be any changes on the WHOIS information in the future, the registrant will update the registration information within 30 days upon occurrence of the changes.
The Registration Agreement states that the registrant must submit the following information:
a) The complete and accurate WHOIS information of the domain name required by the Registry pursuant to the Specification 4 of the Registry Agreement;
b) Signed copy of the Registration agreement.
The registrants also consent that the registrant is responsible for the accuracy of the WHOIS information of the domain name. Failure to adhere to the accuracy requirement will cause suspension or termination of the registration.


Requirement for Registrars
One of the requirements of the accredited registrar is that the registrar is capable of verifying the WHOIS information submitted by the “.网址” domain name registrant.
In the proposed RRA agreement with the “.网址” Registry Operator, the Registrar is required to take necessary measures to verify the authenticity, accuracy and completeness of the registrant information before domain names registration. The verification mechanisms include but not limited to emails, SMS, and phone call verification. The identification of the registrant will also be verified.
The process for the WHOIS verification will be carried out as follows:
(1) The registrar will check the completeness of the registration material and documentation;
(2) The registrar will verify the WHOIS information of the registrant. The registration system of the registrar is required to send out email or SMS to each email address or mobile phone number of the registered domain name to ask for verification of the receiver. No reply will be deemed inaccurate information.
(3) The Identification material of the registrant is required. The individual registrant is required to submit the photocopy of the ID card or passport of the registrant, and the entity registrant is required to submit the photocopy of the Business Certificate or other legal documentation of the establishment of the entity.
Requirement for the Registry Operator
The Registry Operator will set up an annual evaluation process for Registrars on their performance on the WHOIS verification. The standard is based on the complaints received and the WHOIS inspection results performed by the Registry Operator based on the Registry-Registrar Agreement (RRA). The random inspection ratio is no less than 1%. If the proportion of qualified registrants in random inspection is lower than 90%, the Registrar will be deemed unqualified. If the proportion of qualified registrants is 95% or higher, the Registrar are considered qualified. The unqualified registrar will have restrictive actions taken upon them and the qualified registrar will be awarded pursuant to the Registry-Registrar Agreement (RRA)
Requirement for the Back-end Service Provider
The applicant requires the Back-end Service Provider, KNET co., Ltd to carry out a random check on WHOIS information of the domain name registered on the SRS on a daily basis. KNET will verify the registrantʹs Identification via the authoritative database of the government offices to ensure their authenticity and accuracy.
Any inaccurate WHOIS information will be sent back to the contact of the Applicant mentioned above. The Applicant will request the registrar concerned to update the registrant information within 5 working days. Failure to do so would result in domain name suspension or takedown and the registrar will be noted as breach of the Registry-Registrar Agreement (RRA).
28.2.3 Reasonable Access Control
The registrar will provide with a secured online access to registrant to manage the domain names. This access may provide with a platform for domain name information update, domain name transfer request, renewal or deletion. The management system will be provided with SSL connection, reinforced password control and CAPTCHA verification. The system will send out notice to request the registrant change the password every three months. The registrant will be able to update registrant information, requesting domain name transfer Auth-code and domain name deletion. All these operations will require a verification process.
In the event of domain name transfer, the registrant will be required to obtain Auth-code at the losing registrar and give it to the gaining registrar. In addition to that, the losing registrar is required to send transfer notice to the administrative contacts and technical contacts of the registrant before transferring. The gaining registrar is required to notify the administrative contacts and technical contacts of the registrant after transferring.
In the event of the domain name update and deletion, the registrant will be required to verify the operation either via email or via written notice. In the meanwhile, the administrative contacts, technical contacts and billing contact of the registrant will all be informed of the operation.
28.2.4 Disposal of Orphan Glue Records
By definition of SSAC, a glue record becomes an ʺorphanʺ when the delegation point NS record referencing it is removed without also removing the corresponding glue record. The Applicant will adopt the management policy of not allowing orphan record.
KNET, the Back-end Service Provider, has designed The KNET Shared Registry Platform to automatically mark the generated orphan glue records and the date when suspending a domain name resolution or deleting a domain name. At the time that the orphan glue record is generated, the system will automatically send an email notice to the administrative contacts, technical contacts of the domain name and its sponsoring Registrars, informing the orphan glue record should be deleted within a 30-day grace period.
Moreover, the registry system will carry out scanning and cleansing program on orphan glue records on a daily basis. Those orphan glue records that are no longer used as well as those that exceed the 30-day grace period will be deleted.
When provided with evidence that the glue is indeed present to abet malicious conduct, the Applicant will take the following action:
1) Upon reception of the complaint, the Applicant will coordinate with its back-end provider, KNET on the issue;
2) KNET will report back on the status of the orphaned glue record according to its daily scanning record within 24 hours;
3) The Applicant shall instruct an immediate deletion order to KNET to remove the orphan glue record and KNET will delete the record within 8 hours upon receipt of the order.

28.3 Abuse Mitigation Mechanism
The Applicant will set up an anti-abuse mechanism to act swiftly to mitigate any abuse and take down any infringing “.网址” domain names. Based on the nature of the abuses mentioned above, the Applicant shall act in three levels to counteract to potential registration abuse and domain use abuse:
28.3.1 Registration abuse mitigation mechanism
Since the mission of “.网址” TLD is to serve the interest of Internet users, the Applicant regards prudent and proper use of domain names higher than pure volume.
The Applicant will adopt such rules in the Registration Agreement to prevent infringement on the rights of third parties or violation on applicable laws and regulations. The Registry-Registrar Agreement also states that the Registrar is responsible for the WHOIS accuracy of the domain names.
When registering a “.网址” domain name, the Registrant has to consent to the clause on Relevancy required in the Registration Agreement, and ensures each registrant attests to having, or has plans to have, a website presence on the Internet.
On top of that, the accuracy of the WHOIS information of the domain name will be verified. Details of the WHOIS information verification mechanism can be seen in the above section. Any inaccurate WHOIS information could lead to domain name cancellation or rejection.
Through the strict requirement and audit process prior to registration, the “.网址” TLD shall avert or mitigate at least several registration abuses in question.
Refer to Table 28-1 in Q28_attachment for detail.















In the event of an abuse compliant towards a domain registration, the applicant will follow the procedures as described below:
1) the Applicant will put the domain name in question on registry lock, then
2) the Applicant will determine the nature of the complaints, if this falls within the ability of the Applicant, the Applicant will instruct the sponsoring registrar to take down the domain name pursuant to Registry-Registrar Agreement (RRA) or Registration Agreement;
3) Should resolution of this complaint be beyond the ability of the Applicant, the Applicant will follow the procedure that is described in the following section.
28.3.2 Abuse mitigation mechanism
With regards to abusive use of “.网址” domain names, which may include phishing, pharming, malware downloading, etc., the Applicant will rely on registrars, interested parties or Internet users to detect abuses, and in collaboration with other third party security vendors or Law Enforcement Agencies, to tackle such abusive use of the “.网址” domain names.
A typical process to tackle the registration abuse is as such:
1) Any complaints towarda domain name shall be sent to the abovementioned contact via telephone, fax or email;
2) Upon receipt of the complaints, the Applicant shall identify the abuse incidents involving the domain names with the help from other third party security vendors or Law Enforcement Agencies if necessary in five days;
3) Once the abuse is identified, a notice of breach of use will be sent to the domain name registrant, registrar and any party concerned, requesting immediate action to mitigate the abuse within 24 hours;
4) Should the Applicant receive no response from the registrant or the registrar, pursuant to the Registry-Registrar Agreement (RRA), the Operator shall notify the registrar to take a suspension action or takedown resolution within 4 hours; the Applicant shall also notify the registrant on the action taken via the contact method contained in the WHOIS.
The registrant is also allowed to dispute the suspension or takedown action should the registrant if the domain name is mistakenly suspended. The procedure for the plea and process is as follows:
1) The registrant must file the plea to the Applicant via the contact information published on the website with the evidence that the domain name is registered and used in accordance to the Registration Agreement;
2) The Applicant will forward the plea information to the party identified to review the complaints. If the plea is approved and a restore order is issued, the Applicant will instruct the registrar to restore the domain name within five working days pursuant to Registration Agreement and Registry-Registrar Agreement (RRA).

28.3.3 Domain names dispute Mechanism
Sometimes the domain name abuse complaints will have to go through dispute resolution provider. When the domain name in question is in dispute or other legal proceedings, the Applicant will take the following actions to prevent abuse:
i) When the domain name dispute is filed via the Uniform Rapid Suspension Policy, the Applicant will “lock” the domain name in question within 24 hours upon receipt of the “Notice of Complaint”, restricting all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. After the “lock” operation, the Applicant will notify the URS Provider immediately upon locking the domain name (Notice of Lock). The Applicant will also take action as per described by the URS Provider.
ii) Domain name disputes may also be filed under Uniform Dispute Resolution Procedure (UDRP). The Applicant shall monitor its accredited registrars to implement the arbitration result.
Details of the Dispute resolution mechanisms please refer to answer to Question 29.

28.3.4 Collaboration with other parties
Externally, the Applicant will work with other parties to prevent and mitigate the abuses on its domain names. The procedures or mechanisms of the cooperation will be described as follows:
With ICANN
With contractual relationship with ICANN, the Applicant is obliged to abide by the legal obligations described in the Registry Agreement. The Applicant also consents to the Consensus policies and temporary policies specifications described in the Specification 1 of the Registry Agreement. Details of the consensus policies can be found at this address: http:⁄⁄www.icann.org⁄en⁄general⁄consensus-policies.htm.
With regards to Temporary Policies, the Applicant shall comply with and implement all specifications or policies established by the ICANN Board on a temporary basis. The Applicant pledges that the Temporary Policies will be implemented within a month upon receiving 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 prevail.
With CNCERT⁄CC and other security providers
The Applicant will establish a contact window with CNCERT⁄CC, and other security providers to take down domain name abuse incidents concerning “.网址” domain names. On the other hand, the Applicant will rely on them to identify domain name abuse incidents. The collaboration mechanism is as follows:
1) The Applicant will instruct the sponsoring registrar to send email notification the registrant (administrative contact, technical contact or billing contact) concerned to respond to the domain abuse complaints upon receipt of the takedown notice from the CNCERT⁄CC; the notification requires the registrant to respond within 5 days; during which time, the domain name in question will be put in “lock” status;
2) Should there be no response from the registrant, the Applicant will instruct the sponsoring registrar to put the domain name in suspension take down and a notice of takedown will be sent to the email address of the registrant.
28.4 Resourcing Plan
it is advised that two auditors are furnished (one for auditing, the other for re-auditing)to carry out the registration accuracy audit, and a legal counsel is advised to address the abuse complaints.
On the technical side, the staff will be allocated to following area to ensure a swift and effective action to address the abuses.

29. Rights Protection Mechanisms

Rights Protection Mechanisms:

Abusive use policies, takedown procedures, registrant pre-verification, authentication procedures

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

As a TLD aiming at promoting its usage around the world, the Applicant will implement a proper Rights Protection Mechanism (RPM) to safeguard trade mark, geographic names and other naming rights based on the RPMs mandated by the Registry Agreement. The implemented RPM includes a registration prevention mechanism, anti-abuse mechanism and dispute resolution mechanism. The Applicant believes that along with reinforced anti-abuse mechanisms deployed as in answer to Question 28, the RPM shall effectively protect the legal right holders and mitigate the infringement or encroachment on it.
29.1. Reserved name list
Pursuant to the Specification 5 of Registry Agreement, except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall reserve (i.e., Registry Operator shall not register, delegate, use or otherwise make available such labels to any third party, but may register such labels in its own name in order to withhold them from delegation or use) names formed with the following labels from initial (i.e. other than renewal) registration within the TLD:
1. Labels Reserved at All Levels: Example. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations.
ICANN-related names:
• aso
• gnso
• icann
• internic
• ccnso
IANA-related names:
• afrinic
• apnic
• arin
• example
• gtld-servers
• iab
• iana
• iana-servers
• iesg
• ietf
• irtf
• istf
• lacnic
• latnic
• rfc-editor
• ripe
• root-servers

2. two-character labels. All two-character labels shall be initially reserved. The reservation of a two character label string may be released to the extent that Registry Operator reaches agreement with the government and country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes.
3. Tagged Domain Names. Labels may only include hyphens in the third and fourth position if they represent valid internationalized domain names in their ASCII encoding (for example ʺxn--ndk061nʺ).
4. Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the TLD. Registry Operator may use them, but upon conclusion of Registry Operatorʹs designation as operator of the registry for the TLD they shall be transferred as specified by ICANN: NIC, WWW, IRIS and WHOIS.
5. Country and Territory Names. The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:
5.1. the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union
〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-
1_decoding_table.htm#EU〉;
5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;
5.4. Reserved list of the names of countries and regions subdivisions
In addition to the reserved Country and Territory names, registry operator shall reserve the names of countries and regions subdivisions which are listed in ISO 3166-2⁄3 table. The national geographic names in China where the registry is operating will also be included in the reserve name list:
1) the abbreviation of the countries and regional subdivision names(in both Chinese and English) which listed in ISO 3166-2⁄3, and the abbreviation of the countries and regional subdivision names (in both Chinese and English) which listed in ISO 3166-3;
2) the full names and abbreviations (in both Chinese and English) of Chinese provinces and municipalities under direct jurisdiction of the central government, and the unofficial abbreviations of geographical names
3) the full names and abbreviations of municipal administrative regions in China’s provinces

Provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that NEW GTLD AGREEMENT SPECIFICATIONS Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.
29.2 Registrant pre-verification and Authentication
As mentioned in answer to Question 18, the Registrant must consent to the clause on Relevancy requirement in the Registration Agreement, and ensures each registrant attests to having, or has plans to have, a website presence on the Internet.. The registration application has to be verified by the registrars and will be checked at random by the Registry Operator on a yearly basis.

The Registration Agreement states that the registrant “represent, warrant, and agree that you hold the necessary rights to use or permit to use any item, word, or term submitted through the Domain Name Registration Services, and that such use shall not in any way to the best of your knowledge and belief:
(i) violate or potentially violate any right of any third party, including infringement or misappropriation of any copyright, patent, trademark, trade secret, or other proprietary right;
(ii) Constitute or potentially constitute violations, such as, without limitation, false advertisement, unfair competition, defamation, invasion of privacy, invasion of rights, and discrimination;
(iii) Cause or potentially cause a business dispute, personal dispute, or any other dispute;
(iv) Be or potentially be unlawful, harmful, fraudulent, libelous, slanderous, threatening, abusive, harassing, defamatory, vulgar, obscene, profane, hateful, or otherwise offensive;
(v) Be or potentially be racially, ethnically, or ethically objectionable; or
(vi) Constitute a criminal offense, give rise to civil liability, or otherwise violate any applicable law, including local, provincial, state, national, international, or other laws. ”

29.1.2. Registrant WHOIS verification
The accredited Registrar of “.网址” TLD is required to perform WHOIS verification of the registrant. Details of the WHOIS verification mechanism can be found in answer to Question 28. Any breach on the abovementioned principles will result in the annulment of the registration. Any Registrar who violates the above stipulation will also be subject to penalties or even be disaccredited.

The Applicant performs a random auditing on the registered domain names within five-day Grace Period. Any detection on Rights violation will result in rejection of the registration of the domain name.

29.3. Start-up rights protection measures

As required in Applicant Guidebook, the Applicant will implement 2 start-up rights protection mechanisms: the Sunrise period and a Trademark Claims service.

Sunrise Service: Although the Applicant plans to reserve or block any names in the TMCH, the Applicant will implement a 60-day Sunrise service period for eligible trademark holders to register or reserve its names at the second-level of the “.网址” TLD at the pre-launch period. However, the Applicant also reserves the right to deny any trademark name registration request at its sole discretion.

Proposed Sunrise Registration Process
I) For the Sunrise service, Sunrise eligibility requirements (SERs) will be set as minimum requirements, to be verified by Clearinghouse data, and supported by implementing a Sunrise Dispute Resolution Policy (SDRP).

If someone is seeking a Sunrise registration, the Registry Operator will provide a notice to holders of marks in the Clearinghouse that are an Identical Match to the name to be registered.

Sunrise eligibility requirements (SERs)
The proposed SERs include: (i) ownership of a mark (that satisfies the criteria in section 7.2 of TRADEMARK CLEARINGHOUSE in gTLD application Guidebook), (ii) optional registry elected requirements re: international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

Sunrise Dispute Resolution Policy (SDRP)
The proposed SDRP must allow challenges based on at least the following four grounds: (i) at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

Trademark Claims service: although it is highly unlikely that the Trademark names will be easily registered due to the stringent qualification requirement by the Applicant, the Applicants still would like commit itself to offering the Trademark Claims service at the initial open registration phase for 60 days.

Proposed Trademark Claims service

i) At the first 60-day Trademark Claims Service, The registry operator will send a Trademark Claims Notice (as described in the attachment of the Trademark Clearinghouse) to the prospective registrant, with a link to the Trademark Clearinghouse Database.
ii) The prospective registrant is encouraged to access the Trademark Clearinghouse Database to check the trademark rights.
iii) If the domain name is registered in the Clearinghouse, the registrar (again through an interface with the Clearinghouse) will promptly notify the mark holders(s) of the registration after it is effectuated;
iv) in the meantime, The Registry Operator will be reported by The Trademark Clearinghouse Database when registrants are attempting to register a domain name that is considered to contain the element of a trademark.

29.4. Dispute Resolution Mechanisms
If any institution or individual raises a dispute over any registered domain names, then such dispute will be settled via Uniform Dispute Resolution Procedure (UDRP) by the dispute resolution body either authorized by the Applicant or other Dispute resolution service provider accredited by ICANN.

Pursuant to the Specification 7 of the Registry Agreement, the Applicant will comply with the following dispute resolution mechanisms as they may be revised from time to time:
a. the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP) and the Registry Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN. the Applicant agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Registry Agreement) following a determination by any PDDRP or RRDRP panel and to be bound by any such determination; and
b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN, including the implementation of determinations issued by URS examiners.

Furthermore, In the event of dispute among rights holders, the Applicant shall implement the following rules before applying the Uniform Domain Name Dispute Resolution Policy (UDRP).

Of course, the parties involved in the dispute can also take the dispute to court should they be dissatisfied with the arbitration result. The Applicant shall observe any court order resulting from the dispute.

29.5. Resourcing Plan

Given the resource plans placed in the Abuse Prevention and Mitigation plan in answer to Question 28, it is advised that the legal counsel that is in charge of the abuse complaints will be sufficient to carry out the Right Protection Mechanisms described in this section.

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

30A.	Security Policy
According to ICANNʹs New gTLD Applicant Guidebook, the ʺ.网址ʺ Registry has selected KSRP as the back-end service platform. To ensure security, KSRP is implemented in accordance with the internationally accepted ISO 27000, with full consideration of the security aspects of services and data as required by ICANN.
30A.1. Description of Information Security Policies
KSRP is built to achieve the following goals in accordance with ISO 27000:
a) Ensure that the information system supporting critical businesses is free from any outage resulted from failure, virus or attacks. The service level meets the committed SLA;
b) Safely and effectively protect the user information so that it will not be leaked, missing, falsified and unavailable;
c) Be able to rapidly, effectively and properly recover the system platform from any disaster.
To meet these goals, KNET has implemented the information security management policies in accordance with ISO 27000 in the following 12 aspects:
a) Assets security management
b) Human resources security
c) Physical and environmental security
d) Operation regulations
e) Storage media management
f) Backup of data and services
g) Network infrastructure security
h) Network security events monitoring
i) Access control
j) Application services security
k) Information security events management
l) Management of business continuity
The ISO 27000 series that are followed by KSRP include:
a) ISO 27001: Information Security Management System
b) ISO 27002: Code of Practice for Information Security Management
c) ISO 27004: Information Security Management Measurement
d) ISO 27035: Information Security Incident Management Classification
30A.2. Overview of Information Security System Framework
KSRP is designed and built in the following information security measures to mitigate security risks caused by mistakes occurred in day to day work.
30A.2.1. Assets Management
KSRP recognizes and classifies the assets of the data centers and DNS nodes as follows:
a) Data: databases and database manuals;
b) Services: telecommunication services as well as other public utilities and their contracts;
c) Hardware resources: network equipment, host brand, model, configuration parameters and operating manuals or instructions;
d) Software resources: SRS server software, DNS software, Whois software, Registrar business support system, Registry business support system, mail server software, applicable website software and respective installation manuals and configuration files.
In order to effectively protect information resources above, KNET classifies the platform assets by both importance and sensitivity. Please refer to Table 30A-1 in Q30_attachment.

30A.2.2. Human Resources Management
a) Establish definite posts with clearly defined duties to ensure people can really understand the nature of that post he⁄she applies for;
b) For crucial posts (posts above the director level, DBA and security specialist), KNET will carefully evaluate the applicantsʹ background to ensure that they are qualified for such posts. The background information under evaluation may include a) personal profile; b) resume; c) academic level and professional qualifications; d) identity; e) other details;
c) The New Employee On-board Procedures clearly stipulate that the new employee sign a confidentiality agreement with the company shall his⁄her post require;
d) The Human Resources Department will regularly conduct training sessions for new employees to ensure all staff members are full aware of the serious consequences of information security threats;
e) The security commissioner regularly performs inspections on employeesʹ work to ensure that they perform their jobs in a way conforming to the security policies;
f) The Employee Exit Procedures shall stipulate that work handover be done well before an employee leaves the company. The Human Resources Department shall not handle the exit procedures until the employeeʹs manager confirms that his⁄her authority to access the internal systems has been revoked.
30A.2.3. Physical Environment Security
a) KSRP has established two enclosed and controlled physical work environment: one is a peripheral work environment called the Office Zone; the other is an internal environment called the Monitoring Center.
b) The company staff enters the the Office Zone with an access card. Non-company personnel are not allowed to enter the zone without permission.
c) Any visiting guest must always be escorted by a staff member.
d) The Monitoring Center is protected by stricter security measures. Only staff members received a higher security clearance are allowed to enter.
e) In order to ensure the secure operation of the system and identify any failings in regular work, we have applied video monitoring to the office zone and so we can provide the subsequent security auditing work with some evidence.
f) KSRP employs identity card and fingerprint authentication for access control. It combines physical security access with other security protection measures to build a secure working environment.
g) To ensure timely response to emergency, KSRP has deployed dual-backup support for communication services and utility facilities in the data center, including Internet access lines, telephone lines, electricity, power supplies, and air conditioning.
30A.2.4. Operation Regulations
KSRP has established strict procedures for managing changes to the online services which include Software Testing Procedures, Services Deployment Procedures, and Services Change⁄Upgrade Procedures. The following provisions are stipulated:
a) Before changes are made to the online services, the new software shall be strictly tested and pass the security validation scanning performed by the security specialist;
b) Operation personnel shall obtain the approved change request before deploying the changes in production;
c) Operations personnel shall back up software and data in production before rolling out changes to ensure that they can roll back the changes in case of deployment failures;
d) Operations personnel shall strictly follow the instructions stated in Service Deployment Practice Manual when rolling out changes to services in production;
e) After changes are made to the services in production, Operations personnel shall submit the services installation and maintenance documents to the O&M Department.
f) After changes are made to the services in production, the system administrator will perform an all-round monitoring on them.
30A.2.5. Storage Media Management
Except for system administrators, other staff members are not allowed to copy data between the production environment and the external media. Only the system administrators are authorized to perform data upload⁄download operations and all these actions are logged by KSRP for auditing.
The system administrator backs up a variety of data and application services logs from production to tapes as required every day. KSRP designates special personnel to keep these tapes in a safe place and rotate them for reuse once the data retention periods expire.
30A.2.6. Backup of Data and Services
KSRP backs up data and services with two objectives:
a) The services can be recovered as soon as possible in case of any disaster⁄failure;
b) The business can be audited at any time if needed;
To achieve these two goals, KSRP backs up the following assets:
a) Data in the databases;
b) Software resources (including binary code and relevant source code, configuration files and design documents) and operation log;
c) The standard operating system and third-party services software;
d) All equipment, models, specifications and other documents to the installation, operations and maintenance of the service environment.
Assets backup shall be done by the person in charge, and inspected by the security specialist on a periodic basis. Any identified issues shall be fixed as required.
The backup and inspection patterns vary by the natures of the assets. Different equipment, models, specifications as well as the installation and maintenance manuals, services and relevant documents shall be backed up and inspected when they are created and⁄or altered; the software resources and operation logs shall be backed up daily and inspected on an periodic basis; the data in the databases shall be backed up and inspected daily.
There are three daily data backup copies for KSRP data, one stored in the primary data center, one stored in the backup data center, and one copy stored on a tape as offline backup. This ensures that the system services can be recovered properly in case any man-made⁄natural accident occurs.
30A.2.7. Security of Network Environment
The KSRP network infrastructure is divided into two zones by firewalls: internal protection zone and the DMZ. The database platform is placed in the internal protection zone protected by a database firewall in front of all the front ends; the operating network environment is placed in the DMZ for providing services to the outside.
As the services provided by KSRP are Internet-based, the whole network infrastructure is very important for the platform. In order to maintain a robust and secure network environment, dedicated network professionals are assigned as the principal for all the network equipment assets to ensure the whole network is secure, smooth and fault-tolerant.
The duties of the network professionals include:
a) Design the network topology;
b) Ensure all network equipment are working normally;
c) Ensure these equipment are reachable to each other over the network;
d) Maintain passwords for all network equipment to keep unauthorized people from accessing these equipment;
e) Keep the network equipment highly available; timely back up all network routing policies and firewall control policies in order to ensure timely recovery from any failure;
f) Audit network security events to timely identify any potential threats.
30A.2.8. Network Security Events Monitoring
In addition to assisting the network professionals to maintain a secure, smooth and robust network environment, system administrators have another important role of monitoring various events occurred over the network.
KSRP is equipped with management functions to perform comprehensive monitoring over network equipment, servers and applications. A system administrator carries out the following daily tasks to manage network and services events with the monitoring platform:
a) The system administrator inspects various network and services events from the network management equipment, IDS equipment and the monitoring platform;
b) The system administrator follows the Services and Maintenance Manual to handle any identified network events;
c) The system administrator follows the Evens Response Procedures for any identified events that require communications.
30A.2.9. Access Control
In order to ensure only authorized users are allowed to access the services provided in the operating environment, KNET has enforced the following operation rules as part of the assets management requirements:
30A.2.9.1. Passwords Management
a) The identity authentication is based on user name⁄password; the password must be strong;
b) If the user tries to login with a wrong password 3 times in a row, the account is locked for at least one hour in order to prevent any malicious login attempts.
30A.2.9.2. Identity Authentication and Authorization:
a) Before accessing any system serving specific users, the user shall pass the identity authentication;
b) The user authority shall only be assigned by the system administrator.
30A.2.9.3. Routing Policies:
a) KSRP blocks remote access to the network via Internet for management purposes ;
b) For any privileged user logging on to any application system, the source IP address of the userʹs machine shall be qualified;
c) Any session that stays idle for over 30 minutes shall be disconnected;
d) For services only open to specific IP addresses, routing qualifications shall be provisioned for such IP addresses on the firewall.
30A.2.9.4. Host Restrictions:
1. Logging on to the operating system of a host shall be done via SSH;
2. Any operations done on the host after login shall be logged for auditing purpose.
3. The ROOT account of the host can only be accessed by the administrator; the ROOT account shall not be used unless it is absolutely necessary.
4. The host password shall be changed regularly.
30A.2.9.5. Firewall Protection:
a) All application services (except for DNS services) shall be placed behind the firewall for security purpose;
b) Only the ports used by these application services shall be open via the router and firewall; all other ports shall be closed.
c) The maximum number of connections shall be capped for all application services to mitigate risks of large-scale malicious attacks.
30A.2.9.6. Data Encryption:
a) Any confidential business data shall be transferred via HTTPS;
b) Any data files shall be transferred via VPN.
30A.2.9.7. Security Auditing:
a) The user list and user access authority shall be reviewed on a regular basis to ensure the authority is up-to-date and invalid accounts are timely removed;
b) The network access log of the user shall be audited by the security specialist on a regular basis.
30A.2.10. Security of Application Services
KSRP ensures security of the application services in two aspects: 1) security of the operating system; 2) security of the application programs.
Security of the operating system is guaranteed by the following measures:
a) Uniformly install the operating system and security-related patches;
b) Turn on the firewall and only open the ports required by the application services;
c) Regularly check the operating system users and system files to ensure the important system files are not compromised.
Security of the application programs is guaranteed by the following measures:
a) For the application services provided to specific users, those users shall pass the identity authentication (certificate authentication or password authentication). If password is used, the password strength shall comply with the security policies;
b) If a specific user performs any operation on data via the application system, the system shall check the userʹs identity and rejects the operation if it is unauthorized. A detailed log shall be created for any authorized change for auditing;
c) The Measures of Administration of Source Code Security prohibits anyone from disclosing the source code to any third party;
d) Before any application services being put online, the security specialist shall perform a security scan on the software to identify any potential security threats;
e) The system administrator shall use the configuration administration tools to ensure the version of the service software in the operating environment complies with that of the software provided by the R&D Department;
f) The Security Management Procedures of Application Service requires that the security specialist track any defects of the third-party software disclosed by the company and timely upgrade the software;
g) The security specialist shall carry out reinforcement on the firewall and operating system in order to reduce the risks caused by any malicious intrusion to the application services.
30A.2.11. Information Security Events Management
On KSRP,information security events are managed by the information security professionals who are in charge of collection and analysis of all information security events as well as formulation and implementation of the remedial solutions.
The information security specialist collects security events through two channels: the network monitoring log of the system, and authoritative websites disclosing security vulnerabilities.
The information security specialist works out a platform improvement plan after collecting and analyzing applicable security events. The plan will be submitted to the corporate management for approval before execution.
30A.2.12. Security Management of Business Continuity
Information systems of KSRP are classified by their importance as below:
a) Critical information systems: DNS services;
b) Important information systems: SRS services, Whois query, Registrar business support platform, Registry business support platform;
c) General information systems: websites, mail system, etc.
One of the following two cases constitutes an outage of an information system: 1) the system fails to provide services to the public; 2) the services level fails to meet the SLA. If the outage lasts for a while, it is considered as an event. The longer the event lasts, the bigger the loss is.
In addition, if user data of KSRP is leaked, missing or falsified, these occurrences are also considered as events. The bigger the ratio of affected data, the greater the loss caused by the event.
For the classification of events occurred on KSRP, please refer toTable 30A-2 in Q30_attachment:
In order to address the above-mentioned circumstances, KSRP has designed a series of services backup & restore procedures to ensure service continuity.
30A.3. Security Commitment to Registrants
KSRP provides the following security commitments to Registrants:
a) The availability of the DNS services is 100% monthly;
b) The availability of the SRS services is 99.9% monthly;
c) The availability of the Whois services is 99.9% monthly;
d) Service outage to the primary data center caused by disasters such as earthquake and flood, shall not last for more than 1 hour with almost no data loss.
e) Any data related to the Registrants will not be leaked;



© Internet Corporation For Assigned Names and Numbers.