ICANN New gTLD Application

18.2 Benefit to Registrants, Internet Users and Others
18.2.1 Goals of “.政务” TLD in Terms of Areas of Specialty, Service Level and Reputation
The “.政务” TLD seeks to provide the Chinese government organization community with naming spaces in a specific Chinese TLD. By strengthening the influence and attraction of “.政务” TLD, it is expected to cover 75% of nearly 400,000 government organizations before the year 2015, and thus improve the transparency and accountability of Chinese government organizations, and increase their availability and usefulness to citizens.

The “.政务” TLD will offer an authentic and authoritative TLD for Chinese government organization community, to guarantee the safety and stability of “.政务” TLD with the support of a skillful technical team, and to provide registry services that meet ICANN’s requirements. “.政务” domain name abuses will be minimized by the adoption of by adoption of effective policies and technical measures.

CONAC hopes to develop the TLD the most authoritative Chinese gTLD with the fewest disputes, and to eventually make it one of the most influential IDN gTLDs worldwide.

18.2.2 The Competition, Differentiation and Innovation Added to the Current Space
“.政务” TLD will enrich the IDN name space, increase consumer choices and facilitate domain name market competition in an orderly way. The distinct Chinese domain accurately identifies Chinese government organizations in cyberspace, which matches Chinese Internet users’ language preference and facilitates their extensive involvement in government affairs.

18.2.3 Goals of “.政务” TLD in Terms of User Experience
The goals of the “.政务” TLD in terms of user experience are:
To ensure the authority and reliability of Chinese government websites;
To ensure stable, secure and reliable DNS services;
To ensure fast and accurate response to WHOIS queries;
To ensure the Naming Conventions meet user’s preference;
To provide personalized and responsive customer services, to ensure a high degree of user’s satisfaction.

18.2.4 Registration Policies in Support of the Goals Listed Above
In Section 2.18 of the new gTLD Registry Agreement (draft), a Registry Operator for community-based TLD is required to establish registration policies in conformity with the application submitted with respect to the TLD. CONAC had developed “Implementing Rules for ‘政务’Domain Name Registration” (which had been taken effect since Feb.1, 2009) and “Dispute Resolution Policy for ‘政务’ Domain Name” for the use of “.政务.cn” domain names (CONAC will post the draft version on its official website at http:⁄⁄www.conac.cn before the TLD delegation) In anticipation of the application for “.政务” TLD, CONAC have updated and modified these documents to comply with the requirements found in the gTLD Applicant Guide Book published in January, 2012 and supplementary notes posted on ICANN’s website. Key points are as follows.

18.2.4.1 Eligibility
“.政务”domain names are only available to Chinese government organizations, including central and local committees at all levels and basic organizations of the Communist Party of China; the National People’s Congress, all local Peopleʹs Congresses and their Standing Committees at or above the county level; the central government, local governments at all levels, and their departments and agencies at or above the county level; the Supreme Peopleʹs Court, local people’s courts and special people’s courts; the Supreme People’s Procuratorates, local people’s procuatorates and special people’s procuratorates; the National Committee of the Chinese Peopleʹs Political Consultative Conference and local committees at all levels; central and local committees of democratic parties; and also other organizations that carry out administrative functions.

When applying for a domain name under “.政务” TLD, the applicant shall submit proof of official certification (such as Organization Code Certificate, Certificate of legal person, etc.) issued by relevant authorities and fill in “application form for ‘.政务’ domain name”. CONAC requires all registrars to strictly review the authenticity, effectiveness, accuracy and integrity of the information and certificate submitted by applicants. CONAC will also impose an additional level of review after the registrar examination.

18.2.4.2 Name Selection
1. All applied-for domain names shall contain at least one Chinese character, but digital numbers (0~9) and hyphen (-) are also allowed to use combined with Chinese characters. Each level is separated by “.” or Chinese full stop “。”.

2. The applied-for domain name can be the full name, the official abbreviation, the habitual abbreviation or other names of an organization, when using the full name or the official abbreviation of an organization, the domain name shall be consistent to the name approved by relevant authorities; when using the habitual abbreviation of an organization, the domain name shall be consistent to the name that is widely used. In principle, such“.政务” domain names shall contain names of relevant administrative divisions (such as province, city, county and township, etc.)

When using other names, the domain name shall be consistent to the functions and business scope of the organization that are approved by its governing authority.

3. If the applied-for domain name contains an administrative division name that is visually or aurally same to other division names，the domain name shall be preceded by a province name.

4. Proposed domain names that engage in the following contents and⁄or activities will be denied for registration:
1) Those that are against the basic principles prescribed in China’s Constitution;
2) Those that jeopardize national security, reveal national secrets, overturn national administrative authority and undermine state integrity;
3) Those that harm national honor and interests, infringe public interests;
4) Those that instigate ethnic hatred, ethnic discrimination; those that undermine national unity;
5) Those that breach the national religion policies, promote cults and superstition;
6) Those that spread rumors，disturb social order or undermine social stability;
7) Those that spread obscenity, pornography, gambling, violence, homicide, terror or instigate crimes; 
8) Those that are insulting and libelous infringe and violate citizens’ legitimate rights and interests;
9) Other contents that are prohibited by laws, administrative regulations of China;
10) Those that violate ethics and public orders that are recognized by general principles of international law.

18.2.4.3 Restriction on Registration⁄ Use
1. When applying for a domain name that contains a restricted or reserved name, or a trademark, the applicant shall guarantee that the domain name does not infringe on the legal rights of any third party.

2. When applying for a domain name containing the following characters of “中国”(China), “中华”(China), “国家”(Nation),“全国”(Nationwide) or “中央” (Central), the applicant shall submit necessary approval documents. When applying for a domain name that contains full name, official⁄habitual abbreviation of administrative divisions at any level, the applicant shall submit the approval document of relevant authority.

3. The following names will be restricted and protected, and only the appropriate government agencies can register the names.
1) Chinese geographic names of provinces, cities and counties of China;
2) Other geographic names reserved in accordance with CONAC registration policies that are developed with inputs form the community. 
3) Other important names related to the state interests and public interests of China.

18.2.4.4 Restrictions on Use of Domain Names
The domain name holder is not allowed to use the  “.政务” domain name beyond a scope that matches its role and objectives; the domain name holder is not allowed to use the “.政务” domain name for commercial purposes or in violation of registration policies.

18.2.4.5 Reservation and Protection of Names
The following names will be reserved and not be used
1) All names formed with the labels listed in the Specification 5 of the Registry Agreement.
2) Abbreviations of country⁄region names listed in ISO 3166-1 (Chinese and English) as update from time to time;
3) Other names that are requested for reservation by International treaties or relevant organizations.

18.2.4.6 Enforcement, Appeal Mechanism to Registrants
1. Enforcement
1) All“.政务” domain name holders shall carry out functions and activities by using domain names that meet name selection criteria.
2) No “.政务” domain name shall be transferred without the permission of CONAC.
3) CONAC develops strict “.政务” domain name registration policies, and supervisory mechanisms for use of domain names. CONAC sets up and perfects technical systems for the security of networks and information, taking measures to ensure the secure operation of registrants’ domain names with the global Internet community.
4) With the service quality supervision and complaint system, CONAC collects complaints from telephone calls, emails, and makes prompt replies and guarantees service quality.
5) Any of the following behaviors may result in a warning, requiring corrections within a time limit, or even suspension or deletion of the domain name by CONAC:
(1) Register names with fake information;
(2) Lease, lend or unauthorized transfer of domain name;
(3) Fail to comply with regulations in regard to annual review, change or deletion of domain names;
(4) Other delinquent registration and use of domain names.

6) Any of the following behaviors shall be investigated for legal liabilities:
(1) Steal or infringe on“.政务” domain name to seek for illegal gains;
(2) Steal or infringe on“.政务” domain name to spread false information and disturb the social order;
(3) Steal or infringe on“.政务” domain name to undertake fraud.
(4) Malicious destruction of a “.政务” domain name, thus lead to resolution failures or fault resolutions.

7) Any CONAC staff that abuses his power, neglects his duty, engages in malpractice for personal gain shall be investigated for legal liabilities.

2. Appeal Mechanism to Registrants
1) If disputes arise from the processes like registration, use, change of domain names, CONAC will abide by policies related to right protection mechanism, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension system (URS), the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP), and will implement the final decision made by relevant dispute resolution service providers.

During a dispute resolution process, all registered information and DNS services to the domain name remain unchanged; when the dispute is resolved, CONAC will execute the decision accordingly.

2) CONAC’s Community Based Dispute Resolution Procedures
In accordance with Section 2.18 of the Registry Agreement, CONAC has developed the resolution procedures for disputes concerning compliance with TLD registration policies, and regulated the procedures in the Dispute Resolution Policies for “.政务” Domain Names,　(the draft will be available at http:⁄⁄www.conac.cn before the TLD delegation). The policy regulates the following:

For disputes concerning compliance with TLD registration policies, the parties concerned may seek settlement through negotiation, or submit the case to the Domain Name Dispute Resolution Organization accredited by CONAC. This organization may institute legal proceedings with a competent people’s court in China, or submit the dispute for arbitration to an arbitral organization in China. 

If a party refuses to accept the decision of the Domain Name Dispute Resolution Organization accredited by CONAC, he shall have the right to institute legal proceedings with a competent people’s court in China, or submit the dispute for arbitration to an arbitral organ in China within 15 days since the receiving date of the decision. CONAC will implement the decision rendered by the court or arbitral organization.

18.2.5 Measures for Protecting the Privacy and Confidential Information of Registrants and Users
CONAC will abide by laws and regulations regarding national security, business secrets and individual privacy, and will develop policies to protect private and confidential information of registrants and users.

In line with ICANN’s registry agreement requirements, the main contents of the CONAC policy include but are not limited to:

CONAC strict Pre-registration Qualification Procedures (PQP) and Continuous Compliance Mechanism (CCM) (See Section 28.5.1 for details), according to which the registrars require registrants to show their Organization Code Certificate, Certificate of legal entity and provide information regarding the functions, objectives and business scopes of the applicant organization when registering, changing and deleting a “.政务” domain name. The additional information will not be displayed in WHOIS. CONAC enforces strict administrative and technical measures to protect private and confidential information, and guarantees that the registrant information will not be disclosed or used illegally.

CONAC follows strict internal specifications and requires the registrar to take reasonable measures to prevent private and⁄or confidential information of registrants from unauthorized disclosure, loss, abusive use, tampering or destruction.

CONAC will require that registrars seek approval from registrants before gathering and using the personal data and legal entity data in the registration information.

CONAC will only use or give authorization to use the personal data and legal entity data in line with the previous policy in a way that is compatible with its policies and any notice provided to the registrars.

Additionally, CONAC will implement practical policies to encourage “.政务” domain name holders to effectively safeguard personal data of their website visitors (including ID number, telephone number, bank account, permanent address, etc.), and to extensively mitigate the risks of illegal disclosure and use of privacy information.

To ensure the confidentiality of data hold, CONAC has established security management regulations, created a dedicated position in information security and strengthened its internal control mechanisms. In accordance with ICANN regulations, CONAC will not disclose any private and⁄or confidential information to a third party unless get approved by the registrant. CONAC will protect private and⁄or confidential information from wrongful appropriation by deploying security measures on the registry system, especially the core database.

CONAC currently implements a “Thick WHOIS”, and abides by ICANN’s WHOIS policies. CONAC has developed processes to ensure legitimate access to the WHOIS database and to prevent data mining of registrant details and confidential information. CONAC deploys technical measures to prevent illegal use of registrant information. For example, CONAC adopts verification codes to prevent automated bulk WHOIS queries.

18.2.6 Outreach and Communication to Achieve the Benefits
CONAC constantly communicates with the global Internet community, registries and other professional organizations to illustrate the significance of adding “.政务” Chinese TLD to the root zone.

CONAC raises public awareness of “.政务” TLD through various of media: press, radio⁄TV and the Internet to introduce the mission, registration policies, registration scope and application process of the TLD. In addition, CONAC has already held a series of communication campaigns to expand the influence and attraction of “.政务” TLD in China.

23. Registry Services
CONAC will provide registry services in compliance with the requirements in section 2.1 of Specification 6 attached to the Registry Agreement.

CONAC offers customary services such as the receipt of data from registrars concerning registration of domain names and name servers, dissemination of TLD zone files, dissemination of contact and other information concerning domain name registrations (WHOIS service), data escrow, Internationalized Domain Names (IDN) and DNS Security Extensions (DNSSEC). CONAC also has a Business Operation Support System (BOSS) to ensure the normal operation of the registry system.

CONAC conducts systematical risk assessments of the critical functions, identifies the security goals and requirements, develops the corresponding security strategies, security management regulations and plans, and takes effective measures from the perspective of management, technology and operation and maintenance to ensure system security. CONAC curbs the risk in unauthorized disclosure, alternation, insertion or destruction of registry data. Authentication and access control are also introduced to effectively improve business monitoring and auditing, detect abnormal behaviors and misuse and prevent unauthorized access.

CONAC pays close attention to the performance of all the services, and seeks feedback from the stakeholders. CONAC will respond in a timely manner to stakeholder requests on adding new registry services or modifying existing services. Any additional proposed registry services or services to be modified will be forwarded to ICANN for approval pursuant to the Registry Service Evaluation Policy at http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄rsep.html.

The WHOIS system is developed independently by CONAC R&D Department which holds ISO27001 and ISO9001 certificates and has a strong capability for software development. CONAC develops software in strict compliance with Software Development Life Cycle (SDLC), reviews and audits software products and development activities on basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC defines development scope, schedule, and cost. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA). During software designing, programming and software testing, CONAC reviews and audits the software products and development activities to ensure the quality of the software. The outcomes of the project including the design document, source code, testing report and user guide and so on shall be submitted to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems, then deploys the software that passes the tests in the production environment for operation, and continues to provide maintenance and technical supports.

Shared Registration System (SRS), Extensible Provisioning Protocol (EPP) interface, DNS, DNSSEC, data escrow system and BOSS are developed by highly experienced third-party software developers. CONAC selects the third-party developers based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developers develop software in strict compliance with SDLC, review and audit software products and development activities on basis of SQA to ensure all software meet relevant standards. During the planning phase, CONAC signs agreements with the third-party developers, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on SLA to the third-party developers. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developers shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developers.

23.1 Receipt of Data from Registrars Concerning Registration of Domain Names and Name Servers
23.1.1 Service Description
CONAC adopts a business model of registry-registrar separation. Therefore, CONAC does not directly accept registrations from registrants, but accredits registrars to process registrants’ application for “.政务” domain names.

In the architecture of registry, registrar and registrant, CONAC, as a registry, is primarily responsible for the establishment, operation and maintenance of SRS and the core database. Registrants can register domain names and complete domain name information management via any registrar accredited by CONAC.

CONAC receives information about registration of domain names and name servers from registrars via SRS. CONAC uses the EPP interface to receive registration information such as domain name, contact person, life cycle and so on, from registrars, and stores the information in the primary operations center. To ensure that only eligible members of the Chinese government organization community are able to register domain names in the “.政务” TLD, CONAC will implement a verification process named Pre-registration Qualification Procedures (PQP) including pre-verification and re-verification. Registrars conduct pre-verification which requires prospective registrants to submit documentation certifying they are legitimate members of the community. CONAC will conduct re-verification via the BOSS system. Only when the registrant and the applied-for domain name have passed pre-verification and re-verification, can the domain name be valid. For a more detailed description of the PQP, please refer to section 29.2.1 of the responses to Question 29.

23.1.2 Service Level
CONAC strictly complies with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Monthly service performance parameters include EPP service availability≤864 min of downtime, EPP session-command Round-Trip Time (RTT)≤4000 ms for at least 90% of the commands, EPP query-command RTT≤2000 ms for at least 90% of the commands, EPP transform-command RTT≤4000 ms for at least 90% of the commands. If the EPP reaches the emergency threshold of 24-hour downtime⁄week, it will cause the emergency transition of the critical function.

23.1.3 Service Interface
CONAC SRS provides the EPP interface to facilitate the communication between CONAC and registrars.

CONAC provides accredited registrars with an EPP client Software Development Kit (SDK) and a complete guidebook, which can help registrars develop registrant-oriented registration service systems by themselves.

As a provider of domain name registration service system, CONAC can provide the registrar who does not have a registration service system with a general version of the registration service software, so as to assist registrars completing their registration management.

23.1.4 Security of the Registry Service
CONAC takes the following measures to guarantee the security of this service.
1. CONAC deploys security protection equipment and a security monitoring system to reinforce system security. For instance, CONAC deploys firewalls to enhance the security of the core database, and a monitoring system to monitor SRS performance and alert intrusions and attacks, so as to ensure continued service.

2. CONAC adopts a security strategy at the application level including limiting the number of sessions connected by TCP and the idle time, password verification for EPP sessions, implementing transport layer security (TLS) protocols, and registrar IP address verification.

3. CONAC sets up the backup operations center with the similar scale as the primary operations center. In the event that a fatal incident occurs and the primary operations center is shut down, the system can be switched to the backup operations center in a timely manner. After failure elimination, the system will be switched back.

These mechanisms will sufficiently ensure the security of operation data, and stability and continuity of the service.

23.1.5 Stability of the Registry Service
SRS and the EPP interface are developed pursuant to RFC3735, RFC5730, RFC5731, RFC5732, RFC5733, RFC5734 and RFC5910. Also, in accordance with RFC 3915, domain name grace period policy is supported in SRS and the EPP interface. SRS is an independent system, in which the application servers and database servers are deployed separately. The application servers are deployed using load balancing. With such a design, SRS does not directly affect or disturb the normal operations of other systems during the operation.

23.2 Dissemination of TLD Zone Files
23.2.1 Service Description
DNS resolution system is accountable for the dissemination of “.政务” TLD zone file. DNS resolution system implements distributed deployment by using anycast and unicast technology. Anycast sites are located in Beijing, Shanghai, Guangzhou, Chengdu, Hong Kong and USA, and cover many Internet Service Providers (ISP) including China Mobile, China Telecom, China Unicom, Hong Kong PCCW Limited, China Science and Technology Network (CSTN), and USA AT&T. All ISPs support IPv4, and CSTN and AT&T also support IPv6. Unicast site is located in the primary operations center in Beijing, and the backup unicast site is located in the backup operations center in Chengdu. Unicast sites use a different AS number from anycast sites. With the technical plan, CONAC realizes the geographic diversity deployment with multi-site distribution, and the reachability of IPv4 and IPv6. For the distribution of DNS resolution sites, please refer to Figure 1 of Q23_attachment.

There are two steps in “.政务” TLD zone file dissemination. The first step is for SRS to generate a zone file to the primary DNS server in the primary operations center. The second step is to synchronize zone file from the primary DNS server to the secondary DNS servers in each site using transmission and update notification mechanism.

To ensure the security of the service, dissemination of “.政务” TLD zone file also includes data synchronization from the primary operations center to the backup operations center. The first is quasi-real time data synchronization between the core database of the primary operations center and the core database of the backup operations center through Oracle Dataguard. The second is data update from SRS to the primary DNS server in the backup operations center.

CONAC permits the authorized third parties who comply with the Zone File Access Agreement (see section 2.1.1 of Specification 4 of Registry Agreement) to access the designated Internet host server, download zone file data, and transmit TLD zone file, associated cryptographic checksum files and a copy of the TLD zone file, no more than once per 24-hour period. The format of the zone file complies with the requirement of section 2.1 in Specification 4 attached to the Registry Agreement.

23.2.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Monthly service performance parameters include DNS service availability 0 minute downtime (100% availability), DNS name server availability≤ 432 min of downtime, TCP DNS resolution RTT≤1500 ms for at least 95% of the queries, UDP DNS resolution RTT≤500 ms for at least 95% of the queries, DNS update time ≤60 min for at least 95% of the probes. In the unlikely event that DNS service across all servers reaches the emergency threshold of 4 hours downtime per week, this will trigger the emergency transition of the critical function.

CONAC provides 7X24X365 file transfer protocol (FTP) service.

23.2.3 Service Interface
Data updates from SRS to the primary DNS server of the primary operations center and data updates from the primary DNS server to the secondary DNS servers are all in strict compliance with RFC1034, RFC2181, RFC3901, and RFC4472.

The third party access to the zone file is realized via a zone file FTP service provided by CONAC.

23.2.4 Security of the Registry Service
CONAC will take the following measures to ensure the performance, availability and attack resistance ability of the DNS resolution service.
1. Primary DNS servers in the primary⁄backup operations center are in shadow, and do not provide resolution service, for the sake of the security of the primary DNS servers.
2. DNS resolution system adopts anycast and unicast technology. CONAC deploys 8 DNS sites in the aforementioned 6 cities.
3. Management and communication between servers in the resolution sites and primary DNS server is secured through a transmission channel that supports Internet Protocol Security (IPSec) Virtual Private Network (VPN). Thus, secure encrypted transmission can be realized, and data security can be ensured.
4. Each resolution site has diverse hardware and software configurations which are monitored in real time. Real-time monitoring can detect the abnormal behavior of the software or the hardware, and inform the management team enabling prompt response and resolution.
5. As for Internet users’ access, each user is required to provide information that can sufficiently identify and locate the user. Zone file access and download are only available to users who are authorized and in compliance with Zone File Access Agreement.
6. CONAC will implement various measures for security through the use of Intrusion Detection System⁄Intrusion Prevention System (IDS⁄IPS), traffic cleansing, and real time monitoring.
7. CONAC has well defined policies and procedures for ensuring a secure registry environment. See the response to Question 30a and 30b for details.

23.2.5 Stability of the Service
CONAC’s DNS resolution system uses the most widely used DNS resolution software in the root server, namely, BIND and NSD. The DNS resolution system is an independent system using load balancing. Therefore, it will not directly affect nor interfere the normal operations of other systems.

CONAC’s DNS resolution system complies with RFC1034, RFC1035, RFC1982, RFC2181, RFC2182, RFC2671, RFC3226, RFC3596, RFC3597, RFC4343 and RFC5966. The interface that updates resolution data from SRS to the primary DNS server meets the standard of RFC2136 and RFC2137.

Zone file updates from the primary DNS server to the secondary DNS servers in the 8 resolution sites comply with RFC1996 and RFC2845. Incremental updates are adopted as the basic zone file transmission mechanism to relieve network bandwidth pressure. In the unlikely event that failure occurs to incremental updates, full updates provide a backup.

The primary operations center and the backup operations center are connected with a 10 Mb dedicated connection for incremental updates to relieve pressure on the network. In case of special occasions, the bandwidth can be temporarily upgraded from 10Mb to 100Mb according to emergency response procedures to meet the demands of system services.

23.3 Dissemination of Contact and Other Information Concerning Domain Name Registrations (WHOIS Service)
23.3.1 Service Description
WHOIS is accountable for the dissemination of contact and other information concerning domain name registrations. For the “.政务” domain name information query service, CONAC WHOIS provides the public with Port-43 WHOIS queries, web-based WHOIS queries. In consideration of the special needs of ICANN and the public, bulk WHOIS queries and searchable WHOIS queries are also offered. CONAC will also support RESTful WHOIS, once provided in the final standardized form agreed in the IETF.

Port-43 WHOIS queries and web-based WHOIS queries support exact-match query, thick model WHOIS, as well as queries for domain name data, registrar data and name-server data. Query format and response format comply with the requirements on domain name data, registrar data, and name-server data in section 1.4, 1.5, and 1.6 of Specification 4 attached to the Registry Agreement. In domain name query, the query response format complies with the format in Specification 4, except that Punycode form of the domain name will be displayed behind the domain name. In addition, after ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the domain name will be displayed in two different rows.

Bulk WHOIS queries meet requirements in section 3 Bulk Registration Data Access to ICANN of Specification 4 attached to the Registry Agreement.

Searchable WHOIS queries support queries for domain name data. Query conditions meet searching field match requirements in section 1.8.2 and 1.8.3 and Boolean search in section 1.8.4 of the Specification 4. The response format is consistent with corresponding requirements in the Specification 4 for domain name query, except that Punycode form of the domain name will be displayed behind the domain name. In addition, after ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the domain name will be displayed in two different rows.

CONAC WHOIS queries service provides associated security measures to prevent abusive conducts.

23.3.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Service performance parameters on a monthly basis include Registration Data Directory Services (RDDS) availability≤ 864 min of downtime, RDDS query RTT≤2000 ms for at least 95% of the queries, and RDDS update time ≤60 min for at least 95% of the probes. In the unlikely event that WHOIS service reaches the emergency threshold of 24-hour⁄week, this will trigger the emergency transition of the critical function.

Except for Port-43 WHOIS queries and web-based WHOIS queries, bulk WHOIS queries and searchable WHOIS queries are supported by independent WHOIS servers, and thus service performance of Port-43 WHOIS queries and web-based WHOIS queries will not be affected. CONAC will provide RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.3.3 Service Interface
In Port-43 WHOIS queries, a registrar initiates a socket connection through the WHOIS client. WHOIS server accepts the connection and the registrar’s WHOIS queries at Port 43. When information is retrieved in the system, the result will be sent to WHOIS client. When all the query data is returned to the client, the socket connection will be automatically closed and the WHOIS query process is ended. If the query information cannot be retrieved by the WHOIS server, a result code and a human-readable description of the result code are returned before the query process is ended.

In a web-based WHOIS query, query for domain name, registrar and name server is supported. Internet users can enter WHOIS queries in the Web page for WHOIS. The query is submitted to the system in the form of tables. WHOIS will respond to the query, and display the results in HTML page.

The searchable WHOIS query can also be realized through web. Bulk WHOIS query is realized via Secure File Transfer Protocol (SFTP) services.

CONAC will provide a RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.3.4 Security of the Registry Service
This service highlights the protection of national secrets, commercial secrets and privacy. In consideration of requirements on secret and privacy protection in China as well as ICANN requirements in this regard, SRS duplicates relevant domain name data into WHOIS instances in core database and WHOIS mirror database via its WHOIS data synchronization interface function, and relevant domain name data exclude sensitive data. As there is no sensitive data in WHOIS relevant database, the leakage of sensitive information through WHOIS can be avoided.

CONAC implements the following mechanism to ensure the security of WHOIS services.
1. Security devices and monitoring system are deployed to reinforce the security capability of the system. For instance, firewalls are placed in front of WHOIS. There is also security strategy configuration to prevent malicious attacks and ensure the continuity of the service.

2. Security strategy is implemented at the application level. For instance, idle time and numbers of sessions connected by each transmission control protocol (TCP) are limited. Web-based WHOIS queries use picture based code technology for security, and Port-43 WHOIS queries limit the visiting times of one IP address in unit time to prevent the frequent and malicious visit. In addition, CONAC will implement abuse prevention policies to ensure the security of the WHOIS service. More details can be found in section 26.4 of the response to Question 26.

3. Redundant back-up and load balancing are implemented to ensure the security of WHOIS architecture. The backup operations center is set up, which is of the similar scale as the primary operations center. When a fatal failure occurs to the primary operations center, the system can be switched to the backup operations center in a timely manner. After trouble shooting and resolution of the failure, it will be switched back to the primary operations center.

23.3.5 Stability of the Registry Service
WHOIS is developed in strict compliance with RFC3912, Specification 4 and Specification 10 of the Registry Agreement. WHOIS query format and response format are in compliance with the requirements in Specification 4 of Registry Agreement. The performance of the WHOIS will be tested so as to meet the requirements in section 2 Service Level Agreement Matrix of Specification10 of Registry Agreement.

The registration service system and the EPP interface are in strict compliance with RFC3735, RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734, which ensures the stability of the system and data security.

WHOIS is an independent system deployed using load balancing, so it will not directly affect nor interfere the normal operations of other systems.

23.4 Internationalized Domain Names Service
23.4.1 Service Description
“.政务” TLD is a Chinese top level domain. Registration and resolution for simplified Chinese domain name (ASCII included) under “.政务” TLD are supported. CONAC selects “.CN Chinese IDN table” registered and released in IANA website (available at http:⁄⁄www.iana.org⁄domains⁄idn-tables⁄tables⁄cn_zh-cn_4.0.html) as the IDN table used by “.政务” TLD. After ICANN’ s delegation of “.政務” TLD(the variant of the applied for “.政务” TLD) to CONAC, on the basis of the IDN table, all variants corresponding to the registered “.政务” domain name are taken out and reserved except for the variant domain name which is provided to registrants free of charge, so that the registrant’s interests are protected. IDN services are as follows.

1. CONAC accepts registrars’ registration application for simplified Chinese domain name (ASCII included) under “.政务” TLD. CONAC uses “.CN Chinese IDN Table” which is registered and published on the IANA website and CONAC’s website, so that the expected IDN registrants easily access to the information. Since resolution to variant management has not been decided by ICANN yet, CONAC will pay close attention to the development of variant policy. CONAC believes that it is in the best interest of IDN Internet users to have the reserved variant allocated to the TLD registry for the relevant string. Initially, CONAC only accepts the domain name registration in simplified Chinese. Once ICANN finally determines the variant policy and “.政務” TLD(the variant of the applied for “.政务” TLD) is delegated to CONAC, CONAC will accept registration for simplified Chinese domain name or traditional Chinese domain name. The mixture of simplified Chinese and traditional Chinese is forbidden. CONAC will implement the registration policy that the registrant applying for a simplified Chinese domain name will be given the traditional counterpart of the domain name free of charge, provided the traditional counterpart submitted by the registrant is in accordance with Chinese IDN table and passes registrar’s and CONAC’s verification. Other forms of variants of the registered domain name, if any, will be reserved and prohibited from new registration. Likewise, the registrant applying for a traditional Chinese domain name will be given the simplified counterpart of the domain name free of charge. Simplified Chinese domain name and traditional Chinese domain name are parallelly provisioned in zone files. This policy will provide the global internet users who use simplified Chinese or traditional Chinese with service of the same quality. The data in the core database for domain name registration are stored in the Unicode format. Unicode of the registered domain name is supported by and can be directly submitted to SRS and EPP interface.

2. CONAC supports the resolution for “.政务” Chinese domain name. When DNS system generates zone file, it can directly read the Punycode strings stored in the database, and add “xn--” before the strings.

3. CONAC supports Chinese WHOIS queries for “.政务” TLD. In Port-43 WHOIS and web-based WHOIS, Internet users can choose to input simplified Chinese, traditional Chinese, the combination of the simplified Chinese and ASCII, the combination of the traditional Chinese and ASCII, or Punycode for registration data query. In searchable WHOIS query, Internet users can choose to input simplified Chinese, traditional Chinese, the combination of the simplified Chinese and ASCII, the combination of the traditional Chinese and ASCII, or Punycode for registration data query, and the response formats meet Specification 4 requirements. In domain name query, the query response format complies with the format in Specification 4, except that Punycode form of the domain name will be displayed behind the domain name. In addition, after ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the domain name will be displayed in two different rows. CONAC will provide a RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.4.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. The introduction of Chinese domain name will not impair the service level of DNS, RDDS and EPP.

23.4.3 Service Interface
1. SRS and EPP interface. The SRS interface is designed to accept Unicode characters.
2. DNS system. The zone file of DNS system only stores the domain names in the format of Punycode. Therefore, there is no need for change to DNS architecture to support the resolution of “.政务” domain name.
3. WHOIS system. In designing WHOIS system, support to Chinese IDN has been taken into full consideration.

23.4.4 Security of the Registry Service
To prevent malicious registration for similar domain names, spoofing and attacks, CONAC requires registrars to pre-verify the eligibility of registrants and the compliance of the domain name according to Implementing Rules for “.政务” Domain Name Registration (including registrars, registration application and verification, registration fee, domain name disputes, and user complaints) available at http:⁄⁄www.conac.cn. CONAC will re-verify the registration application submitted by registrars in accordance with the same criteria as that of the pre-verification. CONAC has also developed effective policies against variant abuse and for anti-abuse protection.

23.4.5 Stability of the Service
This service complies with RFC5890, RFC5891, RFC5892, RFC5893 and RFC5894. Thus SRS⁄EPP, DNS, WHOIS can effectively support the registration and management of “.政务” TLD. By having a policy that limits domain names to simplified Chinese or traditional Chinese and forbids the mixture of the two after ICANN’ s delegation of “.政務” TLD(the variant of the applied for “.政务” TLD) to CONAC, the equivalence of simplified Chinese and traditional Chinese is addressed. As a result of implementing the equivalence policy, the volume for registered domain names will at most double (DNSSEC impacts considered). But it does not negatively impact on the stability of the system, as the designed system storage capability exceeds the projected maximum registration volumes, system storage devices can be further extended, and the designed peak transaction processing capability is no less than 3 times the estimated volumes.

23.5 DNS Security Extensions (DNSSEC)
23.5.1 Service Description
In compliance with relevant RFCs concerning DNSSEC, CONAC has established a registry system that can support DNSSEC. EPP interface can support DNSSEC, and CONAC is capable of accepting public key materials (DS records) from registrants through registrars via EPP interface. As DNSSEC is taken into account in designing the registry system, relevant fields are reserved to support the storage of four resource records, namely, Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS) and Next Secure3 (NSEC3). Public Key Infrastructure- Certification Authority (PKI-CA) key management system, policies and procedures for key generation, exchange and storage are properly established. At the time of launching DNSSEC, CONAC can ensure that zone files of “.政务” TLD are signed, DS records from child domains are verified and accepted.

DNSSEC services for “.政务” TLD includes the following three aspects.
1. Data origin authentication. It is to verify that the data come from the right name server.
2. Assurance of data integrity. It is to verify that nothing is changed in data transmission.
3. Authenticated denial of existence. It allows a security-aware resolver to authenticate authoritative DNS error indications.

The above information is released to the public in a DNSSEC Policy Statement (DPS) in the response to Question 43.

23.5.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. After the deployment of DNSSEC, our service performance will meet and be superior to ICANN’s service level requirements. In the unlikely event that DNSSEC proper resolution reaches the emergency threshold of 4-hour downtime per week, it will cause the emergency transition of the critical function.

23.5.3 Service Interface
CONAC will provide a DNSSEC interface that will comply with ICANN requirements.
1. Generating Zone-Signing Key (ZSK), Key-Signing Key (KSK) public⁄private key pairs;
2. Generating zone files with DNSSEC records including public key;
3. Incrementally signing the authorized zone files;
4. Submitting KSK-corresponding DS record to root zone;
5. Receiving public key materials (DS records) of “.政务” sub-domain;
6. Signing DS record of the sub-domain.

23.5.4 Security of the Registry Service
DNSSEC is one of the critical measures to address the security defect of DNS system. With robust key management system, CONAC will use Public Key Infrastructure (PKI) to add a digital signature for each resource record so as to improve domain name system security.

DNSSEC establishes two kinds of keys, KSK and ZSK to realize the security of “.政务” TLD zone. KSK is used to sign the DNSKEY resource records. ZSK is used to generate signatures for all the resource records in the zone. Both ZSK’s private key and KSK’s private key are forbidden from unauthorized access, and offline storage should be ensured. A regular update system is established for key management, in which the usage period of KSK is 2 years, and the usage period of ZSK is 3 months (90 days).

23.5.5 Stability of the Registry Service
As COANC’s registry system complies with RFC4033, RFC4034, RFC4035, RFC4310, RFC4509, RFC4641, RFC5155 to support DNSSEC, origin authentication of DNS data, data integrity authentication and authenticated denial of existence will be realized. While implementing DNSSEC, SRS⁄EPP, WHOIS and DNS system need to be modified accordingly.

As a result of large volume of data request for DNSSEC signature, not only the network load of DNS will be increased, but also signature generation and authentication take up more time of CPU and I⁄O. Therefore, disk space taken by signature and key will be around 10 times as large as that before DNSSEC deployment. Accordingly, network bandwidth, server performance, and storage capability in management system need to be increased or upgraded, but as CONAC takes full account of the impact brought by DNSSEC deployment in designing the system, the impact is negligibly minor.

24 Shared Registration System (SRS) Performance
24.1 SRS Summary
SRS is one of the five critical functions. In full compliance with requirements in Specification 6 and Specification 10 of the Registry Agreement, CONAC’s SRS system fulfills the following functions. It receives data from registrars concerning domain name and name server registrations through Extensible Provisioning Protocol (EPP), which ensures that the registrars are capable of providing services to the public for “.政务” domain names. It provides registrars with status information relating to domain names. It supports data synchronization to the WHOIS mirror database and WHOIS database through data synchronization interface, and enables WHOIS function. It provides DNS resolution system with zone files through DNS update application. It provides zone file data for the third party’s access through download interface. It provides bulk registration data access to ICANN through ICANN registration data interface. It also provides data to data escrow application through data escrow interface.

SRS is developed by a highly experienced third-party software developer. CONAC selects the third-party developer based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developer develop software in strict compliance with Software Development Life Cycle (SDLC), review and audit software products and development activities on the basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC signs an agreement with the third-party developer, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA) to the third-party developer. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developer shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developer.

CONAC’s SRS system can be divided into the core database, the core function zone, the extended function zone, internal and external interfaces, and a system administration zone. The core database implements registration data storage via Storage Area Network (SAN) equipments. The core function zone fulfills domain name registrations. The extended function zone extends domain name registration functions, and responds to future requirements. External interfaces connect SRS with the external applications. Internal interfaces assist the implementation of core functions. System administration zone performs the function of authorization and system log management.

24.1.1 The Core Function Zone
The core function zone mainly performs the following functions.

Domain name registration operation: It fulfills domain object operations like check, info, create, update, delete, renew and transfer. The system supports the registration of simplified Chinese domain names and traditional Chinese domain names.

Host operation: It fulfills host object operations like check, info, create, update and delete.

Contact operation: It fulfills contact object operations like check, info, create, update, delete and transfer.

Domain name lifecycle management: It defines and manages the domain name lifecycle, and triggers domain name state transitions.

Registrar management: It adds, modifies or deletes registrars.

24.1.2 The Extended Function Zone
Rapid suspension module: It quickly locks the domain name in question, and cancels its resolution. For details, please refer to the response to Question 28.

Orphan glue records processing module: It detects the orphan glue records in the core database, alerts the monitoring system if orphan glue records are found, and enables the system to remove them.

24.1.3 Internal and External Interfaces
Internal Interfaces:
EPP interface: Through the interface, CONAC communicates with registrars about operations to domain name, contact and host including create, delete, update, check, renew and transfer and so on, on the basis of section 1.2 of Specification 6 of Registry Agreement. CONAC provides registrars with an EPP client SDK (Software Development Kit) so that the registrars can use the Application Programming Interface (API) to enable EPP client-server communication. The EPP client SDK and EPP server are developed pursuant to RFC3735, RFC3915, RFC5910, RFC5730, RFC5731, RFC5732, RFC5733, and RFC5734. For details, please refer to Question 25. The EPP interface supports the domain name grace period policy in accordance with CONAC registration lifecycle policy and RFC3915.

Billing interface: Through the interface, registrars may recharge their account, either online or offline.

Notification interface: Through the interface, CONAC notifies registrars of low account balance or other billing issues by emails or telephones.

Web query interface: SRS provides registrars with a web-based query interface, where the registrars can conveniently query a balance of their account and access reports of domain name registration operations.

External Interfaces:
Interface for the data escrow agent: The interface exports the domain name registration data and other associated data from the core database, in the format prescribed in Specification 2 of the Registry Agreement. For details, please refer to Question 38.

Zone file download interface: The interface generates zone file data from the SRS database in the format prescribed in section 2.1.4 of Specification 4 of the Registry Agreement, and sends it to the directory managed by SFTP that provides zone file download function to third parties.

Interface for registration data access to ICANN: The interface extracts up-to-date registration data from SRS database in accordance with section 3 of Specification 4 attached to the Registry Agreement, sends it to the directory managed by SFTP that provides registration data download function to ICANN.

Reporting interface: In compliance with Specification 3 of the Registry Agreement, the reporting interface generates a Per-registrar Transactions Report and a Registry Functions Activity Report, and sends the reports to ICANN monthly.

WHOIS data synchronization interface: According to section 1.8 of Specification 4 of the Registry Agreement, the interface extracts WHOIS data from SRS database, and provides the data to WHOIS instances in the core database and WHOIS instances in WHOIS mirror database.

24.1.4 System Administration Zone
Authorization module: It defines and administers system users, their roles and access permission. Each user can assume many roles, with a particular role mapping to a set of access permissions. To prevent unauthorized operations, the system has tools to administrate users’ access and specify administrators’ operation permissions.

System log module: The system log mainly records the key operations to SRS, including users’ log-in operations, operations automatically triggered by other systems, and interactions with registrars. The system administrators use the system log for review and auditing.

24.2 SRS Network Architecture
SRS is deployed in the primary operations center and the backup operations center, a hot standby of the primary operations center. The primary operations center and the backup operations center can provide registrars with IPv4⁄IPv6 based SRS services, meeting the service levels prescribed in Specification 10 of the Registry Agreement.

24.2.1 Deployment Structure of SRS in the Primary Operations Center
SRS system is deployed using a redundancy and load balancing strategy, with the purpose to improve EPP response time and EPP service availability. In the application service area of the primary operations center, 4 SRS servers are deployed to provide SRS service at the same time, and load balancing is also implemented using load balancing equipments. Each SRS server accesses the core database located in core data area for registration data. Using an Oracle database, the core database deploys 2 database servers with Real Application Clusters (RAC) to provide data service to SRS servers in application service area. Data of the core database are stored in the disk array. The application service area and the core data area are separated by firewalls and switches. The deployment structure of SRS in the primary operations center is shown in Figure 1 of Q24_attachment. For detailed network architecture, please refer to Figure 3 of Q32_attachment in attachment to Question 32.

The primary operations center is separated into functional zones of different tiers by routers, switches and firewalls. All these network devices have redundant connections. Such a deployment structure can ensure the availability of SRS services in case of SRS single point of failure, and supports horizontal scaling of SRS servers for heavy processing loads.

24.2.2 SRS Deployment in the Backup Operations Center
SRS in the backup operations center is basically identical to that in the primary operations center. The backup operations center has 2 SRS servers (instead of 4 SRS servers in the primary operations center) implementing load balancing and 2 database servers using RAC, and its database data are stored in the disk array. Data are synchronized between the primary operations center and the backup operations center in a quasi-real time manner.

24.2.3 SRS Security Measures
CONAC adopts the following strategies to ensure the security of SRS operations pursuant to RFC5734.

1. SRS is implemented using Transmission Control Protocols (TCP). SRS servers in the production environment listen at port 700. SRS servers in the test environment listen at port 3121. Server connections are initiated by clients.

2. SRS server limits one TCP connection corresponding to one session. The idle time for a session is no longer than 5 minutes. Only two connections are allocated to each registrar. The system does not respond to connections beyond the time limit.

3. EPP session uses a text password for authentication. The server limits the number of login attempts for each session to no more than 3 attempts.

4. Transport Layer Security Protocol is adopted. Both CONAC and registrars are required to check the validity of the certificates, including the validity periods and digital signatures. Connection is allowed only if all the verifications are successful.

5. In response to attacks over the Internet like DDoS, firewalls are deployed between tiers to monitor and mitigate attack to the greatest extent.

6. Registrar IP verification. Only client requests from specified IP addresses are responded to.

24.3 The Number of Servers and System Performance
24.3.1 The Number of Servers
4 SRS servers are deployed using load balancing in the primary operations center to provide services to the users. 2 rack-mount Oracle database servers constitute RAC.

2 SRS servers are deployed using load balancing in the backup operations center to provide services to the users. 2 rack-mount Oracle database servers constitute RAC.

As required, SRS is designed to be horizontally scalable. Additional servers can be added to support growth.

24.3.2 System Performance
CONAC’s SRS system can support at least 30 registrars. CONAC is committed to provide continued SRS service within less than 864 min downtime per month. Furthermore, CONAC has developed a continuity plan, and proposed China Internet Network Information Center (CNNIC) as our backup registry operations provider. An annual continuity test plan has also been worked out.

CONAC has implemented multiple measures to improve SRS availability and performance. As to hardware deployment, redundancy and load balancing are used for EPP servers, RAC deployment is used for the core database, and the backup operations center is built to take over the primary operations center if necessary. As to software, high-performance connection pool technology is adopted in database access, and efficient multi-threads technology is used in EPP server Daemon. As to database storage, according to the recommendation of Oracle DBA, table space is planned, by which index and data are stored separately; Oracle system parameters are adjusted based on the real operations; statistical reports are generated regularly to reduce and control massive statistical queries to the core database; and up to 1 year worth of data are put into archives.

4 EPP servers are deployed using load balancing in the primary operations center, to provide EPP service. Even if two of the four servers fail, the other two still have the capacity to meet the demand at the registration peak. CONAC has conducted operational tests of the SRS performance.

Test Condition: 30 EPP Clients
Numbers of commands of login, logout, create, update, delete, renew and transfer are 500,000 respectively. Numbers of query commands of check, info, poll and transfer are 500,000 respectively.

The test results for one EPP server are 566 ms for query-command RTT, 118 ms for session-command RTT, and 1029 ms for transform-command RTT.

The test results for two EPP servers are 430 ms for query-command RTT, 69 ms for session-command RTT, and 782 ms for transform-command RTT.

The test results indicate that the performance of EPP service can meet the requirements in section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement.

With the deployment of DNSSEC, the communication between the EPP client and EPP server will carry information relevant to public key of a child zone. In comparison with the amount of information transmitted before DNSSEC deployment, the amount of newly added information is small. Therefore, the impact of DNSSEC deployment on the performance of EPP server is limited.

24.4 Interconnectivity and Synchronization with Other Registry Systems
24.4.1 Interconnection to WHOIS System
Within the primary operations center, SRS connects to WHOIS system through an internal network, and provides data to the WHOIS system for WHOIS query through data synchronization interface. Once registration is valid, SRS updates data to WHOIS database within 15 minutes, which completely complies with the Registration Data Directory Services (RDDS) update time requirements in section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. The update process can ensure data completeness and accuracy.

24.4.2 Interconnection to DNS
Within the primary operations center, SRS connects to the server generating DNS zone file through an internal network. The DNS incremental update servers constantly read newly updated data from the SRS database, and update the zone file of the shadow incremental update primary DNS servers every 5 minutes. The shadow incremental update primary DNS servers synchronize the data to each resolution site to provide resolution service to users. The implementation completely complies with the DNS update time requirements in section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. In addition, the system provides a full update as a backup to the incremental update. The DNS full update server regularly (twice a day) reads full data from SRS, generates a full DNS zone file, and updates to the shadow full update primary DNS server.

24.4.3 Interconnection with Data Escrow System
Within the primary operations center, SRS connects to the server for data escrow through an internal network. SRS data are deposited from the data escrow server to the data escrow agent through a data escrow interface.

24.5 Synchronization among Servers
Within the primary operations center, once a registration is valid, the new registration data in SRS are synchronized in a timely manner to the WHOIS mirror database and DNS system as incremental update. The system also provides DNS full update as a backup for the incremental update. The server for data escrow obtains differential data and full data from SRS through independently developed interface, and deposits it to the data escrow agent. The backup operations center is connected to the primary operations center by a 10 Mb dedicated line. Oracle DataGuard is used for data synchronization from SRS in the primary operations center to SRS in the backup operations center. There are also backup systems in the primary operations center, which backs up the SRS and core data as the cold backup. For detailed backup strategies, please refer to Question 37.

24.6 Synchronization Frequency among Servers
Once a registration is valid, the new registration data in SRS are synchronized to the WHOIS mirror database in 15 minutes. The DNS incremental update server synchronizes the incremental data to DNS system every 5 minutes. DNS full update server synchronizes full DNS data to the DNS system twice a day. The data escrow server extracts differential data from SRS and makes deposits to data escrow agent once a day, and extracts full deposit data from SRS and deposits to data escrow agent once a week. SRS data are remotely synchronized between the primary operations center and the backup operations center in a quasi-real time manner. The interconnection of systems within the backup operations center and their synchronization frequency mirror those in the primary operations center, except that the backup operations center does not provide services to the public in normal situation.

24.7 Resourcing Plan
To maintain the stable and reliable operation of SRS, CONAC allocates 13 staff in terms of technology, marketing, and customer support to this area. They provide 7X24X365 operational service and system monitoring services. Detailed human resource allocation is as follow.
2 software engineers (software engineer role A: 2 staff), responsible for software development and maintenance;
1 system engineer (system engineer role A: 1 staff), responsible for system monitoring;
1 Database Administrator (DBA) (DBA role A: 1 staff), responsible for managing database operation;
1 system administrator, responsible for planning and managing system equipments;
2 financial staff (financial staff role B: 1 staff, financial staff role C: 1 staff), responsible for accounting and fund management;
1 marketing staff (marketing staff role A: 1 staff), responsible for communication and outreach for “.政务” TLD;
2 legal affairs staff (legal affair staff role A: 1 staff, legal affair staff role B: 1 staff), responsible for arbitration and litigation;
2 customer support staff (customer support role A: 2 staff), responsible for answering phones and clients’ questions;
1 registration manager (registration management role A: 1 staff), responsible for managing registration and registrars.

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in the response to Question 31.

CONAC uses 6 servers to provide SRS application services, 4 servers in the primary operations center and 2 servers in the backup operations center. Details for software and hardware can be found in the response to Question 32. These resources are sufficient for the initial implementation and ongoing maintenance.

Costs of resources allocation are detailed in costs and capital expenditure of Question 47a and 47b.

25 Extensible Provisioning Protocol (EPP)
CONAC has selected Extensible Provisioning Protocol (EPP) 1.0 as the communication protocol between CONAC and registrars. EPP 1.0 has standardized formats and scalability, and can meet CONAC’s business requirements.

25.1 EPP Packet
EPP Packet is the implementation of EPP interface. It is a software package developed pursuant to RFCs and actual business demands, and it is responsible for the interaction and communication between registrars and CONAC. Description for EPP-based communication between CONAC and registrars can be found in Figure1of Q25_attachment.

The EPP Packet is developed by a highly experienced third-party software developer. CONAC selects the third-party developer based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developer develop software in strict compliance with Software Development Life Cycle (SDLC), review and audit software products and development activities on the basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC signs an agreement with the third-party developer, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA) to the third-party developer. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developer shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developer. CONAC has already developed EPP Packet which passed SRS joint testing.

EPP Packet includes the server software (EppServer) and client software (EppClient). EppServer runs on CONAC side, while EppClient is on registrar side. Registrars send operation commands relating to domain name to CONAC EppServer via EppClient, and EppServer completes each operation.

EPPserver Packet is developed with C++ language and related technologies. EppServer supports high concurrent access.

25.2 Interfaces with Registrars
Based on the EPP protocol, CONAC provides a registration management interface with registrars in the EPP Packet. The interface establishes sessions with CONAC, registers and manages objects of domain, host, and contact, and receives and confirms asynchronous message (as shown in Figure 2 of Q25_attachment). On the basis of the interface provided by CONAC, registrars can realize complete business operations and functions, as well as their proprietary business processes.

The registration and management commands of each object are the commands defined in EPP protocols. Some commands are in full compliance with parameters required in EPP protocols, while others extend command parameters in compliance with RFC3735 to meet CONAC business demands. CONAC provides registrars with all EPP commands relating to domain, host and contact operations, including check, info, create, update, delete, transfer and renew. CONAC also provides registrars with EPP commands relating to establishing session with CONAC and sending message, including login, logout, hello⁄greeting and poll.

25.3 Compliance with EPP-Related RFCs
EPP Packet complies with RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734, which are the latest descriptions of EPP 1.0. CONAC uses these RFC documents as the main reference while developing EPP Packet. Besides, EPP Packet also complies with RFC3915 and RFC5910 to realize EPP function extensions. RFC3735 is the guiding specification for EPP extensions. In the case that standard protocol cannot meet any CONAC business demands, CONAC will extend the protocol with RFC3735 as the guidance, and the extension is primarily at command-response level.

25.3.1 Compliance with RFC5730
As per RFC5730, EPP Packet implements session login⁄logout, hello command, the receipt of asynchronous message and command confirmation. Additionally, the format, response code, date format and internationalization support of EPP Packet also comply with RFC5730.

25.3.2 Compliance with RFC5731
As per RFC5731, EPP Packet implements the domain object commands of create, update, delete, check, info, renew and transfer. To support Chinese IDN, all domain operation commands support Chinese IDN input directly. According to CONAC Chinese IDN policy, after ICANN’ s delegation of “.政務” TLD(the variant of the applied for “.政务”TLD) to CONAC, the registrant applying for a simplified Chinese domain name will be given the traditional counterpart of the domain name free of charge, and vice versa. In response to the policy, the simultaneous application for simplified Chinese domain name and traditional Chinese domain name are supported. The correlation of the simplified Chinese domain name and traditional Chinese domain name is managed in SRS.

25.3.3 Compliance with RFC5732
As per RFC5732, EPP Packet implements the host object commands of create, update, delete, check, and info. The host object subordinate to a domain object will be transferred automatically along with the transfer of the domain object. The host IP can be either IPv4 or IPv6.

25.3.4 Compliance with RFC5733
As per RFC5733, EPP Packet implements the contact object commands of create, update, delete, check, info and transfer. CONAC contact information supports Chinese and ASCII, but disclose attribute is not supported for the moment.

25.3.5 Compliance with RFC5734
As per RFC5734, EPP mapping based on TCP (Transmission Control Protocol) transport layer is realized, and Secure Sockets Layer (SSL) protocol is utilized on TCP. The format of EPP Packet, the relationship between the session and TCP connection, the communication sequence between the client and the server, as well as the listening port all comply with the requirements of RFC5734.

25.3.6 Compliance with RFC3735
As a result of the specificity of CONAC business, CONAC extends several functions in addition to the standard EPP functions. These extensions are command-response, and consistent with RFC3735. The specific extensions include providing Punycode for Chinese IDN domain names in the response to domain object command of info. For XML Schema of EPP extension, please refer to Appendix: EPP Domain Name Mapping Extension for Chinese Domain Names.

25.3.7 Compliance with RFC3915
As per RFC3915, CONAC implements domain name redemption grace period policy.

25.3.8 DNS Security Extensions (DNSSEC)
While implementing EPP Packet, CONAC has realized function extension to support DNSSEC. EPP Packet is implemented in accordance with RFC5910 (obsolete RFC4310). EPP Packet extends commands in the domain object operations, and supports the transmission of Delegation Signer (DS) information during the communication between the registrars and CONAC.

25.4 EPP Schema of Interface with Registrars
EPP schema used by CONAC includes EPP XML schema defined in RFCs and EPP XML schema in response to proprietary extensions.

25.4.1 EPP XML Schema Defined in RFCs
urn:ietf:params:xml:ns:eppcom-1.0 (Refer to RFC5730)
urn:ietf:params:xml:ns:epp-1.0 (Refer to RFC5730)
urn:ietf:params:xml:ns:domain-1.0 (Refer to RFC5731)
urn:ietf:params:xml:ns:host-1.0 (Refer to RFC5732)
urn:ietf:params:xml:ns:contact-1.0 (Refer to RFC5733)
urn:ietf:params:xml:ns:rgp-1.0 (Refer to RFC3915)
urn:ietf:params:xml:ns:secDNS-1.1 (Refer to RFC5910)

25.4.2 EPP XML Schema of CONAC’s Proprietary Extensions
As per RFC5731, CONAC provides Chinese domain name (CDN) extension to info command. For details, please refer to Appendix: EPP Domain Name Mapping Extension for Chinese Domain Names.

25.5 Resourcing Plan
To support the stable and reliable operation of EPP, CONAC allocates 7 staff in terms of technology, and customer support to this area. Detailed human resource allocation is as follow.

1 software engineer (software engineer role B: 1 staff), responsible for the software maintenance;
3 system engineers (software engineer role A: 3 staff), responsible for the system monitoring;
1 network engineer (network engineer role B: 1 staff) responsible for system network maintenance;
1 marketing staff (marketing staff role A: 1 staff), responsible for communication and outreach for “.政务” TLD;
1 customer support staff (customer support role B: 1 staff), responsible for answering client questions and addressing problems detected in EPP system operation for users.

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in response to Question 31.

CONAC uses 6 servers to provide EPP services, 4 servers in the primary operations center and 2 servers in the backup operations center. These servers also provide SRS services. Details for software and hardware can be found in the response to Question 32.

These resources are sufficient for the initial implementation and ongoing maintenance.

Costs of resources allocation are detailed in costs and capital expenditures of Question 47a and 47b.

Appendix: EPP Domain Name Mapping Extension for Chinese Domain Names

Internet Engineering Task Force Z. Wang
Internet-Draft CONAC
Intended status: Informational February 21, 2012
Expires: January 5, 2013

Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for
Chinese Domain Names
draft-wang-epp-cdn-mapping-00

Abstract

This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of Chinese Domain Names (CDNs). Specified in XML, this extended mapping is applied to provide additional features required by CDNs Registration.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).
Note that other groups may also distribute working documents as Internet-Drafts.
The list of current Internet-Drafts is at http:⁄⁄datatracker.ietf.org⁄drafts⁄current⁄.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ʺwork in progress.ʺ

This Internet-Draft will expire on January 5, 2013.

This document is subject to BCP 78 and the IETF Trustʹs Legal Provisions Relating to IETF Documents (http:⁄⁄trustee.ietf.org⁄license-info) in effect on the date of publication of this document.

Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008.

The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1. Introduction
2. Terminology
3. Object Attributes
4. EPP Command Mapping
4.1. EPP Query Commands
4.1.1. EPP 〈check〉 Command
4.1.2. EPP 〈info〉 Command
4.1.3. EPP 〈transfer〉 Query Command
4.2. EPP Transform Commands
4.2.1. EPP 〈create〉 Command
4.2.2. EPP 〈delete〉 Command
4.2.3. EPP 〈renew〉 Command
4.2.4. EPP 〈transfer〉 Command
4.2.5. EPP 〈update〉 Command
5. Formal Syntax
6. Internationalization Considerations
7. IANA Considerations
8. Security considerations
9. References
Author’s Address

1. Introduction
Many Chinese characters in common use have variants in Simplified Chinese (SC) form, Traditional Chinese (TC) form or other variant forms.

For example, the Chinese character ʺU+5B81ʺ has 5 variants:
ʺU+5B81ʺ (SC form), ʺU+5BE7ʺ (TC form), ʺU+21A34ʺ , ʺU+5BDCʺ and ʺU+5BCDʺ (other variant forms).

For Chinese users, the variants of a Chinese character in SC form, TC form and other variant forms are regarded as the same.

To simplify the EPP implementations with supprt for CDN, Chinese Domain Names (CDNs) containing different variant forms (SC form, TC form, and other variant forms) are regarded as seperated ones in this extension, whereas the association between variant forms are ensured by registration management which is out of scope of this specification.

In order to meet above requirements of the CDNs registration, this document describes an extension of the Extensible Provisioning Protocol (EPP) domain name mapping [RFC5731] for the provisioning and management of CDNs.

This document is specified using the Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].

The EPP core protocol specification [RFC5730] provides a complete description of EPP command and response structures.

A thorough understanding of the base protocol specification is necessary to understand the extension of mapping described in this document.

2. Terminology
The key words ʺMUSTʺ, ʺMUST NOTʺ, ʺREQUIREDʺ, ʺSHALLʺ, ʺSHALL NOTʺ, ʺSHOULDʺ, ʺSHOULD NOTʺ, ʺRECOMMENDEDʺ, ʺMAYʺ, and ʺOPTIONALʺ in this document are to be interpreted as described in [RFC2119].

ʺcdn-1.0ʺ in this document is used as an abbreviation for urn:ietf:params:xml:ns:cdn-1.0.

In examples, ʺC:ʺ represents lines sent by a protocol client and ʺS:ʺ represents lines returned by a protocol server.

Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this specification.

XML is case sensitive.

Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.

3. Object Attributes
This extension defines one additional element to the EPP domain name mapping [RFC5731]. It can be got from 〈domain:info〉 command.

The CDN Punycode domain name is a domain name in Punycode [RFC3492] which is converted from the corresponding CDN.

In this document, its corresponding element is 〈cdn:CDNPunycode〉.

4. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730].

The command mappings described here are specifically for use in provisioning and managing CDNs via EPP.

4.1. EPP Query Commands
EPP provides three commands to retrieve domain information: 〈check〉 to determine if a domain object can be provisioned within a repository, 〈info〉 to retrieve detailed information associated with a domain object, and 〈transfer〉 to retrieve domain-object transfer status information.

4.1.1. EPP 〈check〉 Command
This extension does not add any element to the EPP 〈check〉 command or 〈check〉 response described in the EPP domain name mapping [RFC5731].

When a domain name has not been registered, but the domain which the user submitted for check is in the CDN list of a registered domain name, 〈check〉 response must contain explanation in the reason field to tell the user that this domain name is a CDN of a registered domain name, and can be activitated by the registrant by 〈create〉 command.

4.1.2. EPP 〈info〉 Command
This extension does not add any element to the EPP 〈info〉 command described in the EPP domain mapping [RFC5731]. However, additional elements are defined for the 〈info〉 response.

When an 〈info〉 command has been processed successfully, the EPP 〈resData〉 element MUST contain child elements as described in the EPP domain mapping [RFC5731].

In addition, the EPP 〈extension〉 element SHOULD contain a child 〈cdn:infData〉 element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy.

The 〈cdn:infData〉 element contains one child element:

o An OPTIONAL 〈cdn:CDNPunycode〉 element that contains the Punycode of the CDN.

Example 〈info〉 Response for an authorized client:

S:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
S: 〈response〉
S: 〈result code=ʺ1000ʺ〉
S: 〈msg〉Command completed successfully〈⁄msg〉
S: 〈⁄result〉
S: 〈resData〉
S: 〈domain:infData
S: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
S: 〈domain:name〉
S: ʺU+5B9EʺʺU+4f8bʺ.ʺU+4E2DʺʺU+56FDʺ〈⁄domain:name〉
S: 〈domain:roid〉58812678-domain〈⁄domain:roid〉
S: 〈domain:status s=ʺokʺ⁄〉
S: 〈domain:registrant〉123〈⁄domain:registrant〉
S: 〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
S: 〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
S: 〈domain:ns〉
S: 〈domain:hostObj〉ns1.example.cn〈⁄domain:hostObj〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉ClientX〈⁄domain:clID〉
S: 〈domain:crID〉ClientY〈⁄domain:crID〉
S: 〈domain:crDate〉2011-04-03T22:00:00.0Z〈⁄domain:crDate〉
S: 〈domain:exDate〉2012-04-03T22:00:00.0Z〈⁄domain:exDate〉
S: 〈domain:authInfo〉
S: 〈domain:pw〉2fooBAR〈⁄domain:pw〉
S: 〈⁄domain:authInfo〉
S: 〈⁄domain:infData〉
S: 〈⁄resData〉
S: 〈extension〉
S: 〈cdn:infData
S: xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ〉
S: 〈cdn:CDNPunycode〉
S: xn--fsq270a.xn--fiqs8s〈⁄cdn:CDNPunycode〉
S: 〈⁄cdn:infData〉
S: 〈⁄extension〉
S: 〈trID〉
S: 〈clTRID〉ABC-12345〈⁄clTRID〉
S: 〈svTRID〉54322-XYZ〈⁄svTRID〉
S: 〈⁄trID〉
S: 〈⁄response〉
S:〈⁄epp〉

〈info〉 Response for the unauthorized client has not been changed,see [RFC5731] for detail.

An EPP error response MUST be returned if an 〈info〉 command cannot be processed for any reason.

4.1.3. EPP 〈transfer〉 Query Command
This extension does not add any element to the EPP 〈transfer〉 command described in the EPP domain mapping [RFC5731].

4.2. EPP Transform Commands
EPP provides five commands to transform domain objects: 〈create〉 to create an instance of a domain object, 〈delete〉 to delete an instance of a domain object, 〈renew〉 to extend the validity period of a domain object, 〈transfer〉 to manage domain object sponsorship changes, and 〈update〉 to change information associated with a domain object.

4.2.1. EPP 〈create〉 Command
This extension defines additional elements to extend the EPP 〈create〉 command described in the EPP domain name mapping [RFC5731] for CDN registration.

4.2.2. EPP 〈delete〉 Command
This extension does not add any element to the EPP 〈delete〉 command described in the EPP domain mapping [RFC5731].

4.2.3. EPP 〈renew〉 Command
This extension does not add any element to the EPP 〈renew〉 command described in the EPP domain mapping [RFC5731].

4.2.4. EPP 〈transfer〉 Command
This extension does not add any element to the EPP 〈transfer〉 command described in the EPP domain mapping [RFC5731].

4.2.5. EPP 〈update〉 Command
This extension does not add any element to the EPP 〈update〉 command described in the EPP domain mapping [RFC5731].

5. Formal Syntax
An EPP object name mapping extension for CDN is specified in XML Schema notation.

The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances.

The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.

BEGIN
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ
xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ
xmlns:epp=ʺurn:iana:xml:ns:epp-1.0ʺ
xmlns:eppcom=ʺurn:iana:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:iana:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉
〈import namespace=ʺurn:iana:xml:ns:epp-1.0ʺ
schemaLocation=ʺepp-1.0.xsdʺ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
CONAC Domain Extension Schema v1.0
〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺinfDataʺ type=ʺcdn:infDataTypeʺ⁄〉

〈!--
Child elements of the 〈cdn:infData〉 command
All elements must be present at time of creation
--〉
〈complexType name=ʺinfDataTypeʺ〉
〈sequence〉
〈element name=ʺCDNPunycodeʺ type=ʺeppcom:labelTypeʺ
minOccurs=ʺ0ʺ ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!--
End of schema.
--〉
〈⁄schema〉
END

6. Internationalization Considerations
EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8.

Conformant XML processors recognize both UTF-8 and UTF-16.

Though XML includes provisions to identify and use other character encodings through use of an ʺencodingʺ attribute in an 〈?xml?〉 declaration, use of UTF-8 is RECOMMENDED.

As an extension of the EPP domain name mapping, the elements, element content described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension.

7. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688].

IANA is requested to assignment the following two URI.

Registration request for the CDN namespace:

o URI: urn:ietf:params:xml:ns:cdn-1.0

o Registrant Contact: See the ʺAuthorʹs Addressʺ section of this document.

o XML: None.
Namespace URI does not represent an XML specification.

Registration request for the CDN XML schema:

o URI: urn:ietf:params:xml:schema:cdn-1.0

o Registrant Contact: See the ʺAuthorʹs Addressʺ section of this document.

o XML: See the ʺFormal Syntaxʺ section of this document.

8. Security considerations
The object mapping extension described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC5730] or those caused by the protocol layers used by EPP.

9. References
[RFC2119] Bradner, S., ʺKey words for use in RFCs to Indicate
Requirement Levelsʺ, BCP 14, RFC 2119, March 1997.

[RFC3492] Costello, A., ʺPunycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)ʺ, RFC 3492, March 2003.

[RFC3688] Mealling, M., ʺThe IETF XML Registryʺ, BCP 81, RFC 3688,
January 2004.

[RFC5730] Hollenbeck, S., ʺExtensible Provisioning Protocol (EPP)ʺ,
STD 69, RFC 5730, August 2009.

[RFC5731] Hollenbeck, S., ʺExtensible Provisioning Protocol (EPP)
Domain Name Mappingʺ, STD 69, RFC 5731, August 2009.

[RFC5890] Klensin, J., ʺInternationalized Domain Names for
Applications (IDNA): Definitions and Document Frameworkʺ,
RFC 5890, August 2010.

[RFC5891] Klensin, J., ʺInternationalized Domain Names in
Applications (IDNA): Protocolʺ, RFC 5891, August 2010.

[RFC5892] Faltstrom, P., ʺThe Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)ʺ,
RFC 5892, August 2010.

[W3C.REC-xml-20040204]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, ʺʺExtensible Markup Language (XML) 1.0 (Third
Edition)ʺ, World Wide Web Consortium FirstEdition REC-
xml-20040204ʺ, February 2004,
〈http:⁄⁄www.w3.org⁄TR⁄2004⁄REC-xml-20040204〉.

[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
ʺʺXML Schema Part 1: Structures Second Editionʺ, World
Wide Web Consortium Recommendation REC-xmlschema-1-
20041028ʺ, October 2004,
〈http:⁄⁄www.w3.org⁄TR⁄2004⁄REC-xmlschema-1-20041028〉.

[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, ʺʺXML Schema Part 2: Datatypes
Second Editionʺ, World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028ʺ, October 2004,
〈http:⁄⁄www.w3.org⁄TR⁄2004⁄REC-xmlschema-2-20041028〉.

Authorʹs Address

Zheng Wang
CONAC
JIA 31, North Guangximen, Xibahe, Chaoyang District
Beijing, Beijing 100028
China

Phone: +86 10 5203 5185
Email: wangzheng@conac.cn

26. WHOIS
26.1 Description of CONAC WHOIS System
CONAC’s WHOIS service complies with Request for Comments (RFC) 3912 and WHOIS standards in Specifications 4 and 10 of the Registry Agreement published by ICANN. CONAC provides Port-43 WHOIS, Web-based WHOIS, bulk access WHOIS and searchable WHOIS. In addition, the WHOIS system supports queries in full simplified Chinese, full traditional Chinese, simplified Chinese with ASCII, traditional Chinese with ASCII and PunyCode. CONAC will provide a RESTful WHOIS service once available in its final standardized form agreed by the IETF.

CONAC fully understands the requirements of queries and network traffic. On basis of the requirements, CONAC establishes the construction of the current WHOIS system consistent with its business model and domain name registration volume.

26.1.1 Port-43 WHOIS
The Port-43 WHOIS system is designed and implemented in accordance with RFC 3912.

The Port-43 WHOIS system receives and responds to the query information via Port-43.The format of responses follows a free text format, followed by a blank line and a legal disclaimer specifying the rights of CONAC, and of the user accessing the database. Each data object is represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value. For fields where more than one value exists, multiple key⁄value pairs with the same key are allowed. The first key⁄value pair after a blank line is considered the start of a new record, and is considered as identifying that record, and is used to group data together. In addition, all formats of responses including domain status, individual and organization names, address, street, city, state⁄province, postal code, country⁄region, telephone⁄fax numbers, email addresses, date and times conform to the mappings specified in EPP RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734.

If no match is found for the query, the WHOIS system will provide users with a friendly message on the response page before ending the WHOIS search.

The Port-43 WHOIS supports inquiring information about corresponding domain names, registrar and nameserver. All response formats abide by Specification 4 of the Registry Agreement. In addition, a domain name value is shown with its PunyCode form displayed behind. (See Table 1 of Q26_attachement for the response format)

26.1.2 Bulk Access WHOIS
CONAC provides bulk query services to meet the requirement of “Bulk Registration Data Access to ICANN” set out in Section 3 of Specification 4 of the Registry Agreement. A WHOIS data storage file will be generated one (1) day before the checking date designated by ICANN and will be made available for download by SFTP (or through other means requested by ICANN in the future). The data will be provided in the format specified in Specification 2 of the Registry Agreement. CONAC will provide ICANN with SFTP URL as well as a user name and pass code. For “Exceptional Access to Thick Registration Data” mentioned in Section 3.2 of Specification 4 of the Registry Agreement, CONAC will provide the data within two (2) business days as required.

26.1.3 Web-based WHOIS
CONAC’s Web-based WHOIS supports queries in terms of domain name, registrar and nameserver, all response formats abide by Specification 4 of the Registry Agreement. In addition, a domain name value is shown with its PunyCode form displayed behind. (See Table1 of Q26_attachement for the response format)

See Figure1 of Q26_attachement for the standard query interface of the WEB-Based WHOIS.

26.1.4 RESTful WHOIS
CONAC will provide a RESTful WHOIS service once available in its final standardized form agreed by the IETF.

26.1.5 Searchable WHOIS
CONAC offers searchable WHOIS with the searchability on the web-based Directory Service, which meets the requirement of “searchable” set in Section 1.8 of Specification 4 of the Registry Agreement.

CONAC offers partial match capabilities, at least, on domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.);

CONAC offers exact-match capabilities, at least, on registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records).

CONAC offers Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT.

A response list with each domain name that matches the search criteria will be displayed. (See Figure2 of Q26_attachment) A page with detailed information of a domain name can be shown by clicking the “view” links at the end of each record. Such detailed information is listed in a format that complies with Specification 4 of the Registry Agreement. In addition, a domain name value is shown with its PunyCode form displayed behind. (See Table1 of Q26_attachement for response format)

Please refer to Figure3 of Q26_attachment for the Query Interface of the Searchable WHOIS.

26.2 Structure of CONAC’s WHOIS System and Topological Graph
CONAC’s WHOIS system supports IPv4 and IPv6 networks, adopts distributed deployment, raises performance by load balancing, and the structure of the WHOIS system has a feature of multi-level redundancy. (See Figure 4 of Q26_attachement for the structure of WHOIS system and topological graph)

CONAC deploys the WHOIS system into two operations centers, the primary operations center (Beijing site) and backup operations center (Chengdu site). Each site has dual-link exports and connects with IPv4⁄IPv6 networks respectively; therefore, each of the sites is capable of providing WHOIS services to all Internet users in IPv4⁄IPv6.

CONAC’s deployment of WHOIS system adopts a layered architecture. A clustered deployment has been adopted by facilities of each layer. From the dual Internet export connections to the dual redundant facilities of routers, firewalls, switches, load balancer and all elements meet the requirement of continuous operation of the WHOIS system. Currently, 2 servers (Port-43 WHOIS server and Web-based WHOIS server) have been deployed into the primary operations center. Using load balancing equipments, all ordinary WHOIS queries are balanced in the two servers. The strategy of load balancing deployment has guarantees high performance and high reliability of CONAC’s WHOIS services. The firewall has quarantined abnormal flows from the WHOIS system. In addition, two redundant WHOIS servers are available. One server is deployed with the WHOIS mirror database system (periodically synchronized with core database) and the other server is deployed with the bulk accesses and searchable WHOIS system. The server with bulk WHOIS access and searchable WHOIS system deployed is quarantined from ordinary WHOIS servers to guarantee the stable operation of the Port-43 WHOIS system and Web-based WHOIS system, and eliminate hidden troubles on system performance, which is required by ICANN regarding SLA of WHOIS service.

It should be highlighted that the bulk access WHOIS system and the searchable WHOIS system use WHOIS mirror database, for the purpose of avoiding negative effects they may bring to the performance of Port-43 WHOIS and the Web-based WHOIS that use WHOIS instances in the core database.

26.2.1 Interconnectivity to Other Registry Systems
The WHOIS system has interconnectivity only to the Shared Registration System (SRS), and does not connect to others in the registry system. SRS duplicates relevant domain name data to WHOIS instances in the core database and WHOIS mirror databases via its WHOIS data synchronization interface function.

26.2.2 Frequency of Synchronization between Servers
SRS performs the above data duplications in every 15 minutes, and ensures that each duplication takes no more than 15 minutes.

26.3 Laws and Policies to Protect Sensitive WHOIS Information
CONAC will abide by laws and regulations regarding national security, business secrets and individual privacy, and will develop policies to protect private and confidential information of registrants and users. In line with ICANN’s registry agreement requirements, the main contents of the CONAC policy include but are not limited to:

CONAC strict Pre-registration Qualification Procedures (PQP) and Continuous Compliance Mechanism (CCM) (See Section 28.5.1 for details), according to which the registrars require registrants to show their Organization Code Certificate, Certificate of legal entity and provide information regarding the functions, objectives and business scopes of the applicant organization when registering, changing and deleting a “.政务” domain name. The additional information will not be displayed in WHOIS. CONAC enforces strict administrative and technical measures to protect private and confidential information, and guarantees that the registrant information will not be disclosed or used illegally.

CONAC follows strict internal specifications and requires the registrar to take reasonable measures to prevent private and⁄or confidential information of registrants from unauthorized disclosure, loss, abusive use, tampering or destruction.

CONAC will require that registrars seek approval from registrants before gathering and using the personal data and legal entity data in the registration information.

CONAC will only use or give authorization to use the personal data and legal entity data in line with the previous policy in a way that is compatible with its policies and any notice provided to the registrars.

Additionally, CONAC will implement practical policies to encourage “.政务” domain name holders in China to effectively safeguard personal data of their website visitors (including ID number, telephone number, bank account, permanent address, etc.), and to extensively mitigate the risks of illegal disclosure and use of privacy information.

To ensure the confidentiality of data hold, CONAC has established security management regulations, created a dedicated position in information security and strengthened its internal control mechanisms. In accordance with ICANN regulations, CONAC will not disclose any private and⁄or confidential information to a third party without the permission of the registrant. CONAC will protect private and⁄or confidential information from wrongful appropriation by deploying security measures on the registry system, especially the core database.

CONAC currently implements a “Thick WHOIS”, and abides by ICANN’s WHOIS policies. CONAC has developed processes to ensure legitimate access to the WHOIS database and to prevent data mining of registrant details and confidential information. CONAC deploys technical measures to prevent illegal use of registrant information. For example, CONAC adopts verification codes to prevent automated bulk WHOIS queries.

26.4 Abuse Prevention
CONAC defines the forms of potential WHOIS abuses to include: 1. users conducting improper and frequent access of the WHOIS system, decreasing the efficiency of WHOIS queries of the majority of users; 2. some users illegally make use of the large amount of data obtained from the WHOIS database.

To prevent abusive use of the WHOIS, CONAC performs the following preventive actions:

1. For frequent accesses of the WHOIS system
1) To limit query frequency of a single IP address
For Port-43 WHOIS, the system limits the number of single-IP-queries per unit time, e.g. 5 times per minute.

2) To prevent malicious Web access
For a standard query to the Web based WHOIS, the primary solution to malicious access prevention includes adding a verification code image on the query page.

3) To give authorization to access mass WHOIS data
Considering the requirements of users who have reasonable requirements to access CONAC’s WHOIS system with single IP address, and to use CONAC’s searchable WHOIS, CONAC will offer higher authorities to users who have reasonable requirements through a certification procedure.

The authority has two types:

(1) Permission to access SFTP. CONAC will offer SFTP, permitting WHOIS bulk accesses.
(2) Permitting the use of advanced search services of Searchable WHOIS, CONAC sets permissions for unlimited queries within a limited time frame.

CONAC regulate the Delegation of Permissions⁄Authorities as follows:
(1) All applications shall be submitted by filing out the application form online. The application process is open to the public. A specification of application procedure and the application form are available at CONAC’s official website (http:⁄⁄www.conac.cn).
(2) All applicants shall promise not to use the data for marketing purposes, spam or other improper or illegal uses.
(3) For those users who apply for authorities to access the search functions of the searchable WHOIS, the pass-codes will be delivered to the approved applicants through e-mails or facsimiles.
(4) For those authorized users who will have time limitation associated with their access to the search functions of the searchable WHOIS, CONAC will set the time limitation to one month, and can re-issue the authorization pass-code after expiration.
(5) In order to the limitation on single IP accessing times, CONAC requires a mutual agreement signed by the two parties. All applicants may download the agreement (http:⁄⁄www.conac.cn), and send the original signed copies to CONAC. The authority will be given after CONAC’s confirmation of the receipt of the agreement and relevant fees.

2. Terms of Use of Mass WHOIS Data
CONAC posts the Terms of Use of WHOIS Data (clarifying the rights of the registry and database users) to prevent abuses from a legal and policy perspective.

26.5 Specifications for Software Development
The WHOIS system is developed independently by CONAC R&D Department which holds ISO27001 and ISO9001 the certificates of, and has a strong capability for software development. CONAC develops software in strict compliance with Software Development Life Cycle (SDLC), reviews and audits software products and development activities on basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC defines development scope, schedule, and cost. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA). During software designing, programming and software testing, CONAC reviews and audits the software products and development activities to ensure the quality of the software. The outcomes of the project including the design document, source code, testing report and user guide and so on shall be submitted to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems, then deploys the software that passes the tests in the production environment for operation, and continues to provide maintenance and technical supports.

The WHOIS system has been completely constructed by CONAC and has passed internal acceptance tests. The testing statistics show that the WHOIS system meets the requirements including 98% availability, less than 2000 ms of RTT in 95% of all WHOIS queries, and guarantee processing of at least 530,000 queries per day (4.63 queries per second). CONAC has invited a third party that complies with ISO17025 to evaluate the WHOIS system.

The WHOIS system contains the function of searchable WHOIS.

26.6 Resourcing Plan
26.6.1 Allocation of Human Resources
CONAC allocates 16 staff in terms of marketing, customer support, engineering, general affairs and administrations to this area.

1 CTO, responsible for proposing WHOIS software requirement, system designs, project management, as well as the acceptance test, deployment and ongoing operations of the WHOIS system;

1 CFO, responsible for financial planning and reviewing relating to WHOIS software development;

1 COO, responsible for administrations relating to WHOIS operations;

4 software engineers (software engineer role A: 2 staff, role B: 1 staff, role C: 1 staff), responsible for WHOIS software design, programming, system test, document drafting related to project management, system deployment and ongoing system operations and upgrades;

1 system engineers (system engineer role B: 1 staff), responsible for system monitoring;

1 system administrator, responsible for device planning and management;

2 financial auditors (finance role B: 1 staff, role C: 1 staff), responsible for financial activities relating to giving access authorizations of the WHOIS system;

1 marketing staff (marketing staff role B: 1 staff), responsible for introducing procedures, policies and regulations regarding WHOIS services, promoting brand values and expending market share.

1 legal staff (legal staff role B: 1 staff), responsible for dealing with legal disputes relating to operations of the WHOIS system;

2 customer support staff (customer support role C: 2 staff), responsible for complaints management and customer services;

1 international relations staff (international relations role A: 1 staff), responsible for assisting the system engineer to communicate with ICANN, and helping to provide customer support to overseas users;

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in the response to Question 31.

CONAC continuously monitors WHOIS workload, and more people will be added if the human resources are found insufficient.

26.6.2 Cost of the Resource Allocation
The construction of the WHOIS system requires 8 servers, necessary network devices, broadband connections and relevant software, etc.. Please refer to the response to Question 32 for details.

Costs of resources allocation are detailed in costs and capital expenditure of Question 46, 47a and 47b. CONAC regularly monitors the change of WHOIS business scale, if the WHOIS workload reaches 50% of the system capacity, CONAC will deploy additional facilities as necessary.

27. Registration Life Cycle
The “.政务” TLD supports all Extensible Provisioning Protocol (EPP) statuses. To fully protect registrants’ rights, Redemption Grace Period (RGP) statuses are also supported. In consideration of the uniqueness of the community serving by the “.政务” TLD, namely, the Chinese government organization community, a verification process named Pre-registration Qualification Procedures (PQP) is introduced in the registration lifecycle. PQP requires registrars to pre-verify the registration application and CONAC to re-verify the registration application submitted by registrars. For details about pre-verification and re-verification, please refer to section 29.2.1 of Question 29. Only after passing PQP, can a registration be valid.

In the Registry-Registrar Agreement signed with registrars, CONAC will commit to managing domain names in strict compliance with the domain name registration lifecycle policy. Additionally, CONAC has released a registration and management manual for “.政务” TLD as well as an implementing rule at http:⁄⁄www.conac.cn. The domain name registration states and procedures prescribed in these documents are consistent with what is stated here.

27.1 Domain Name Registration States, and Criteria and Procedures for State Changes
“.政务” domain name registration lifecycle will be extended with the extension of EPP statuses. At present, a “.政务” domain name has 12 EPP statuses, namely, ok, pendingDelete, pendingUpdate, pendingTransfer, pendingRenew, serverHold, serverTransferProhibited, serverRenewProhibited, serverUpdateProhibited, serverDeleteProhibited, pendingCreate, and inActive. Besides, there are 5 registrar statuses, namely, clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited. As per RFC 3915, a “.政务” domain name has 7 RGP statuses，namely, addPeriod, autoRenewPeriod, renewPeriod, transferPeriod, redemptionPeriod, pendingDelete and pendingRestore. After ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the changes to domain name states not only apply to the domain name itself, but also its corresponding variant.

State diagram for “.政务” TLD registration lifecycle is shown in Figure 1 of Q27_attachment.

27.1.1 OK Status
Status Description
A domain name in this status can be updated, renewed, deleted or transferred, and can be resolved. The status is never shown alongside any other status. If other status appears, ok status is removed.

Criteria and Procedures for State Changes
1. Upon a registrar’s update request, EPP status changes to pendingUpdate. The update is completed within 3 days. When the update is completed, EPP status returns to ok or what it was prior to the processing.

2. Upon the transfer request from a gaining registrar, EPP status changes to pendingTransfer. When the transfer is completed, EPP status returns to ok or what it was prior to the processing. RGP status is set to transferPeriod.

3. Upon the delete request from a registrar, EPP status changes to pendingDelete, and RGP status is redemptionPeriod.

4. Upon the receipt of Notice of Complaint from Uniform Rapid Suspension (URS) provider or during CONAC’s handling of domain name abuse, CONAC sets EPP status to serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited.

5. 15 days before the expiration of a domain name, EPP status changes to serverTransferProhibited.

27.1.2 pendingDelete Status
Status Description
1. If the domain name in pendingDelete status is in Redemption Period, the domain name cannot be updated, deleted or transferred, but can be restored. The domain name cannot be resolved. For redemption, the registrar needs to pay a higher price than the usual renewal price.

2. If the domain name in pendingDelete status is in Pending Delete Period, the domain name cannot be resolved, and all the requests from registrars on domain name operations will be denied.

Criteria and Procedures for State Changes
If the domain name in pendingDelete status is in Redemption Period, RGP status is redemptionPeriod.

1. If the registrar proposes a restore request within 30 days, RGP status changes to pendingRestore.

2. If the registrar provides a formal restore report within 7 days, EPP status changes to ok or what it was prior to the processing, and RGP status is removed.

3. If the registrar fails to provide a formal restore report within 7 days, RGP status returns to redemptionPeriod.

4. If the registrar fails to propose any restore request to CONAC within 30 days, RGP status changes to pendingDelete.

If the domain name in pendingDelete status is in Pending Delete Period, RGP status is pendingDelete. The domain name will remain in the pendingDelete status for 5 days, after which time the domain name is purged, and available for any new registration.

27.1.3 pendingUpdate Status
Status Description
The update request is received, and the domain name can be resolved.

Criteria and Procedures for State Changes
Upon a registrar’s update request, CONAC shall complete the update within 2 days. Once the update is completed, the domain name returns to its previous status.

27.1.4 pendingTransfer Status
Status Description
The transfer request is received, and the domain name update, renewal, and delete are denied. The domain name can be resolved.

Criteria and Procedures for State Changes
Upon a registrar’s transfer request, RGP status changes to transferPeriod. CONAC shall complete the transfer within 3 days, after which EPP status reverts to ok or what it was prior to the processing, and RGP status is removed.

27.1.5 pendingRenew Status
Status Description
The domain name renew request is accepted, and the domain name cannot be updated nor transferred.

Criteria and Procedures for State Changes
Upon a registrar’s renew request, RGP status is set to renewPeriod. CONAC shall complete the renewal within 30 days. After renewal, EPP status changes to ok or what it was prior to the processing, and RGP status is cancelled.

27.1.6 serverHold Status
Status Description
The domain name in this status can not be resolved.

Criteria and Procedures for State Changes
If the domain name in serverHold status is suspended and enters Pending Delete Period, CONAC changes EPP status to pendingDelete.

27.1.7 serverTransferProhibited Status
Status Description
The domain name can be updated, renewed, or deleted.

Criteria and Procedures for State Changes
1. In Add Grace Period, EPP status is serverTransferProhibited, and RGP status is addPeriod. Upon a registrar’s delete request, EPP status changes to pendingDelete and RGP status is set to pendingDelete. When the Add Grace Period elapses, EPP status remains, and RGP status is removed.

2. Within the first 60 days of the Registered Period, EPP status is serverTransferProhibited. Upon the delete request from the registrar, EPP status changes to pendingDelete, and RGP is set to redemptionPeriod. When the 60 days elapse, EPP status changes to ok or what it was prior to the processing.

3. If the registrant prevails in abuse arbitration or the relief request from the complainant is denied in URS, CONAC changes EPP status to ok or what it was prior to the processing.

4. 15 days before the expiration of a domain name, EPP status is serverTransferProhibited. Upon the registrar’s delete request, EPP status changes to pendingDelete and RGP status is set to redemptionPeriod. When the domain name is expired, EPP status changes to serverTransferProhibited and serverUpdateProhibited.

5. In Renew Grace Period, EPP status is serverTransferProhibited and serverUpdateProhibited, and RGP status is autoRenewPeriod or renewPeroid. If RGP status is autoRenewPeriod, and the registrar does not delete the domain name at the end of 30 days, EPP status changes to ok or what prior to the processing, and RGP status is removed. If RGP status is renewPeriod, EPP status changes to ok or what prior to the processing, only upon receiving the registrar’s renew request, and then RGP status is removed. The registrar can delete the domain name, then EPP status changes to pendingDelete, and RGP is set to redemptionPeriod. If the registrar does not renew the domain name within 30 days, EPP status changes to pendingDelete, and RGP status is set to redemptionPeriod.

27.1.8 serverRenewProhibited Status
Status Description
The domain name can be updated, transferred, or deleted.

Criteria and Procedures for State Changes
In Registered Period, upon the receipt of registrars’ request to remove the prohibition of renewal, CONAC will remove EPP status of serverRenewProhibited.

27.1.9 serverUpdateProhibited Status
Status Description
The domain name can be renewed, transferred or deleted.

Criteria and Procedures for State Changes
1. If the registrant prevails in abuse arbitration or the relief request from complainant is denied in URS, CONAC changes EPP status to ok or what it was prior to the processing.

2. In Renew Grace Period, EPP statuses of serverUpdateProhibited and serverTransferProhibited are in co-existence, and RGP statue is autoRenewPeriod. For detailed criteria and procedures for state transitions, please refer to step 5 of 27.1.7.

27.1.10 serverDeleteProhibited Status
Status Description
The domain name in this status can be updated, renewed or transferred.

Criteria and Procedures for State Changes
If the registrant prevails in abuse arbitration or the relief request from complainant is denied in URS, CONAC changes EPP status to ok or what it was prior to the processing.

27.1.11 pendingCreate Status
Status Description
The registration application is received, but still under PQP, and the domain name cannot be resolved.

Criteria and Procedures for State Changes
The domain name is under PQP Period, and its EPP status is pendingCreate. If the domain name passes PQP, EPP status changes to ok. If the domain name does not pass PQP, EPP status changes to pendingDelete, and RGP status is pendingDelete.

27.1.12 inactive Status
Status Description
The domain name is not associated to hosts, nor deployed in the DNS server.

Criteria and Procedures for State Changes
1. For domain names that are pending for delete operation, EPP status is pendingDelete, and RGP status is pendingDelete.

2. For domain names that are pending for update operation, EPP status is ok or what it was prior to the processing.

27.2 Description of the Typical Lifecycle of a “.政务” Domain Name
The typical lifecycle of a “.政务” domain name includes 6 periods, Available Period, Pre-registration Qualification Procedures (PQP) Period, Registered Period (Add Grace Period included), Renew Grace Period, Redemption Period, and Pending Delete Period. The registration lifecycle complies with RFC3915, RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734, and is developed on basis of EPP. After ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the registration lifecycle not only applies to the domain name itself, but also its corresponding variant.

The typical registration lifecycle for a “.政务” domain name is illustrated in Figure 2 of Q27_attachment.

27.2.1 Procedures for Domain Name Creation
The procedures involve in Available Period, PQP Period, and Registered Period.

1. At receipt of the application, the registrar pre-verifies documentation provided by the prospective registrant. The pre-verification shall be completed within 3 working days. If the documentation provided by the prospective registrant fails to meet the registration criteria, the registration process is terminated.

2. Once the registration passes pre-verification, the registrar will notify CONAC through EPP interface. CONAC will re-verify the application within 2 working days, and deduct registration fees, after which time the domain name enters Add Grace Period, and CONAC sets EPP status to serverTransferProhibited and serverUpdateProhibited. If the domain name does not pass the re-verification, the registration process is terminated.

3. The registrar may propose to delete the registered domain name within a 5-day add grace period, in which case CONAC will refund the registrar and delete the domain name.

27.2.2 Procedures for Domain Name Update
The procedures involve in Registered Period.

1. Upon receipt of an update request, the registrar will verify the update request and relevant documentation provided by the registrants within 3 working days.

2. The registrar will send the registrant’s update request to CONAC through EPP interface. CONAC will verify whether the to-be-updated domain name has EPP status of serverUpdateProhibited or clientUpdateProhibited. If it has, CONAC will deny the update request. Otherwise, CONAC will set EPP status to pendingUpdate to show that the registrar’s request is received by CONAC.

3. CONAC’s re-verification is completed within 2 working days, after which the domain name may be allowed or disallowed for update.

27.2.3 Procedures for Domain Name Delete
A domain name may be deleted in Add Grace Period or Pending Delete Period.

27.2.3.1 Procedures for Domain Name Delete during the Add Grace Period
1. During Add Grace Period, a registrant requires a registrar deleting a domain name.

2. The registrar notifies CONAC of the registrant’s delete request through EPP interface. CONAC will verify whether the to-be-deleted domain name has EPP status serverDeleteProhibited or clientDeleteProhibited. If it has, CONAC will deny the delete request. Otherwise, CONAC will delete the domain name, and refund the registrar.

27.2.3.2 Procedures for Domain Name Delete during Pending Delete Period
1. A domain name in Pending Delete Period will be removed from CONAC registration system within 5 days.

2. After the deletion, the domain name is available for any new registration.

27.2.4 Procedures for Domain Name Expiration
The procedures involve in Registered Period, Renew Grace Period and Redemption Period.

Expiration procedures for the domain name in the Renew Grace Period are as follow.
1. CONAC requires the registrar to notify the registrant of the expiration 60 days prior to the domain name expiration date and 30 days prior to the domain name expiration date.

2. At the expiration date, the domain name enters Renew Grace Period, and RGP status is autoRenewPeriod or renewPeriod. Whatever the RGP status is, CONAC will verify whether the to-be-expired domain name has EPP status of serverRenewProhibited or clientRenewProhibited. If it has, CONAC will deny the renew request, and the domain name enters 30-day Redemption Period. Otherwise, EPP status changes to pendingRenew.

If RGP status is autoRenewPeriod, CONAC will deduct the renewal fees, and the domain name enters Registered Period after 30-day grace period, during which if the registrar requires deletion of the domain name, CONAC will refund the registration fees, and the domain name enters Redemption Period.

If RGP status is renewPeriod, at the receipt of renew request from the registrar, CONAC will deduct the renewal fees and sets EPP status to ok after the 30-day grace period, during which if the registrar requires deletion of the domain names, CONAC will refund the registration fees, and the domain name enters Redemption Period. If CONAC does not receive renew request from the registrar, the domain name enters Redemption Period 30 days later.

Expiration procedures for the domain name in Redemption Grace Period are as follow.
1. If the registrar fails to renew a domain name in Renew Grace Period, CONAC sets EPP status to pendingDelete, and RGP status to redemptionPeriod.

2. If the registrant wishes to restore the domain name in this period, it costs the registrant 50% extra of the usual renew price. If the registrar sends a restore command, CONAC sets RGP status to pendingRestore. At receipt of restore report within 7 days, CONAC restores the domain name to Registered Period. If CONAC does not receive the restore report within 7-day valid period and the domain name is still in Redemption Grace Period, CONAC will set RGP status to redemptionPeriod. When Redemption Grace Period elapses, the domain name enters Pending Delete Period. If the restore report from the registrar is not received within 7-day valid period, and the Redemption Grace Period for the domain name elapse, the domain name enters Pending Delete Period.

27.2.5 Procedures for Domain Name Transfer
1. The registrant requires transferring the management of a domain name from registrar A to registrar B.

2. Registrar A determines whether the transfer is allowed based on Registration Agreement signed between registrars and registrants.

3. Upon the registrar’s transfer request, CONAC will verify whether the to-be-transferred domain name has EPP status of serverTransferProhibited or clientTransferProhibited. If it has, CONAC will deny the transfer request. Otherwise, CONAC sets EPP status to pendingTransfer. CONAC also transfers the registrant’s domain name and name server from registrar A to registrar B, which is completed within 5 days.

27.2.6 Procedures for Locking Domain Name
1. Upon the receipt of Notice of Compliant from URS provider or during CONAC handling of domain name abuse, CONAC sets EPP status to serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited, but the domain name will continue to be resolved normally.

2. If the complainant prevails in URS, CONAC will suspend the domain name upon the receipt of Determination from URS provider. CONAC will not resolve the domain name to the original web site but redirect the name server to an informational website provided by the URS provider about the URS. EPP status of the domain name will remain unchanged. If the relief request from complainant is denied, EPP status returns to the status before the receipt of Notice of Compliant from the URS provider.

3. If domain name abuses are confirmed via a relevant verification process, CONAC will suspend the domain name, and add an EPP status of serverHold to the domain name.

4. After ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the locking procedure not only applies to the domain name itself, but also its corresponding variant.

27.3 Resource Allocation
27.3.1 Human Resource Allocation
To support registration lifecycle, CONAC allocates 6 staff in terms of marketing and customer support to this area. The resource is sufficient for the initial implementation and ongoing maintenance, as is shown below.

1 marketing staff: (marketing staff role B: 1 staff), responsible for communication and outreach with end-users and registrars for CONAC registration lifecycle.

1 legal affairs staff: (legal affairs role B: 1 staff), responsible for settling legal disputes in domain name registration lifecycle.

2 customer support staff: (customer support role C: 2 staff), responsible for domain name registration, handling the complaints from registrars and registrants, and relevant domain name operations.

2 registration managers (registration management role B: 2 staff), responsible for the implementation of domain name registration policy in registration lifecycle, such as re-verification.

Detailed skillset requirements on the staff can be found in section 31.3.3 in the response to Question 31. All the aforementioned staff are currently in place.

CONAC will constantly monitor CONAC’s domain name registration scale. If there is any shortage in human resources, additional staff will be added well in advance.

27.3.2 Costs of Resources Allocation
Costs of resources allocation and capital expenditure are detailed in the response to Question 47a and 47b.

28. Abuse Prevention and Mitigation

The “.政务” TLD has a very low risk of abuse given its strict registration policy and Pre-registration Qualification Procedure (PQP) and the nature of the eligible registrants which are members of the Chinese government organization community. CONAC enforces a zero tolerance policy against domain abuse in the “.政务” TLD，and implement anti-abuse policies at three distinct levels.

1. CONAC has two types of measures to prevent and handle domain abuses. Measures to prevent abuses include PQP, Continuous Compliance Mechanism (CCM), raising WHOIS accuracy, controlling WHOIS access authority and processing orphan glue records, these processes are described in this section. Measures to handle abuses include normal and rapid handling process with specific work flows and time limits.

2. CONAC has classified all kinds of abusive behaviors with clear definitions and specific processing measures, (see Section 28.5.2) which ensures effective solutions to abuse problems.

3. CONAC has set up an Anti-Abuse Working Group (AAWG) to deal with abuse complaints and solve abuse problems. CONAC also maintains close interactions with partners including ICANN, Anti-Phishing Alliance of China (APAC), China Internet Network Information Center (CNNIC) and China National Computer Emergency Response Team CNCERT, and shares information with the anti-abuse communities.

Additionally, CONAC requires registrars and registrants not to conduct any abuse through its RRA and the Registration Agreement (to be supplied from time to time by registrar, but the terms of prohibiting abuse of registrant must be included) with terms of abuse prohibition and specifications included. The agreements also stipulate that CONAC conducts a monthly random compliance check to prevent and mitigate abuses.

28.1 Implementation Plans (Establishment of a Single Point of Contact)
CONAC will post the telephone number, postal address and e-mail address for receiving abuse complaints (about all “.政务” domain names, all registrars and resellers) as well as primary contact person on CONAC’s official website (http:⁄⁄www.conac.cn) and inform ICANN about the above contact information. CONAC also requires all registrars to post such information on their websites. CONAC will keep ICANN and all relevant registrars updated if any of the information changes.

Contact person for abuse complaints: Ms. Lili Wang, Manager of Abuse Mitigation
Telephone Number: +86-10-5202 8203
Postal Address: Jia 31, Guangximen Beili, Xibahe, Chaoyang District, Beijing 100028, China
E-mail: complain@conac.cn

The telephone and the email box will operate 7x24x365 to receive complaints regarding abusive domain names registered in “.政务” TLD. Besides a description of the abused domain name, the abusive behavior and the consequence every complainant is required to provide their personal contact information including telephone⁄fax number, email address so they can be promptly notified of the outcomes of the complaint. CONAC will confirm with the complainant the receipt of a complaint with in one (1) business day, and AAWG will then inform the complainant whether the complaint is accepted within five (5) business days. The complaints require immediate attention due to their seriousness will be prompt forwarded to the CONAC Anti-Abuse Working Group via a rapid process.

CONAC handles the received complaints. Any confirmed abusive behavior may result in the takedown and suspension of relevant domain name(s) under certain circumstances. Any registrar involved in abusive behavior will be punished by CONAC in accordance with the RRA, including termination of RRA. In accordance with relevant regulations and procedures, CONAC will notify the complainant of the final decision of the dispute resolution.

28.2 Policies to Handle Abuse Complaints
CONAC has a strong commitment to preventing all kinds of abuses. The abuse prohibition terms have been included in the RRA (the draft will be posted on CONAC’s website, which is http:⁄⁄www.conac.cn, before ICANN pre-delegation check phase), regulating that registrars shall not conduct abusive behavior. If a registrar breaches this provision, CONAC will take action and may cease its registration services of “.政务” domain names and terminate the RRA. CONAC requires the registrars to incorporate abuse prohibition terms in the Registration Agreement and all registrants must sign a letter of commitment before registering a “.政务” domain name.

28.2.1 The Complaint Handling Institution and Its Responsibility
CONAC has set up an Anti-Abuse Working Group (AAWG). The working group is composed of 2 CONAC staff and 3 invited experts who are versed in the fields of computer network security, cryptography, intellectual property and community management. All working group members have deep understanding of the Internet and related laws, and have strong professional ethics and are able to independently and neutrally judge the abuse complaint. The working group holds meetings regularly, or Ad-Hoc Meetings if necessary.

The main tasks of the working group include:

1. To accept and handle abuse complaints;
2. To track the latest anti-abuse research outcomes and research on anti-abuse issues in the global domain name communities;
3. To identify and define abuse types that are related to “.政务” domain names;
4. To analyze abusive behavior and develop anti-abuse policies;
5. To establish a coordination and linkage mechanism for anti-abuse community with ICANN, China Internet Network Information Center (CNNIC) and National Computer network Emergency Response technical Team (CNCERT).

28.2.2 Process for Handling Abuse Complaints
CONAC foresees being alerted to suspected abuses through three channels: the first is by receiving complaints from affected stakeholders, the second is by alarms given by the monitoring system deployed according to the characteristics of abuses, and the third is by the information reflected by anti-abuse communities. All suspected abuses will be submitted to the Anti-Abuse Working Group for evaluation and appropriate action.

CONAC Anti-Abuse Working Group will stay well informed of ICANN’s polices concerning abuse and correspondingly determine methods of identifying abuses. CONAC will identify various abuses of domain name registration and domain name use in accordance with abuse characteristics defined by the Registration Abuse Policies Working Group (RAPWG). Please refer to 28.5.2 for details.

An abuse complaint may be solved by the complainant and the respondents (collectively referred to as the parties) through consultations, be submitted to the Anti-Abuse working group established by CONAC for settlement, or be submitted as a legal action to a competent people’s court in China.

If any party disagrees with the decision concerning on the abuse complaint by the CONAC’s Anti-Abuse Working Group, it is entitled to lodge a lawsuit to a competent people’s court in China within 15 days as of the date of the AAWG’s decision. CONAC shall execute the verdict given by the court.

Pursuant to related ICANN policies and related Chinese laws, CONAC has developed a set of anti-abuse complaint resolution processes (see Figure 1 of Q28_attachment). The process for handling the complaints has seven steps, which are described in detail below:

Step 1: Complaint
The complainant files a complaint with CONAC’s Anti-Abuse Working Group. The complainant shall provide complaint materials in written form setting out the reasons for the complaint and the impact on legitimate rights as a result of an abuse. CONAC does not impose restrictions on the number of complainant, respondent and domain names complained against.

Step 2: Complaint Acceptance
The Anti-Abuse Working Group decides whether to accept the complaint within five (5) business days after receiving the complaint: if the AAWG believes that the case does not constitute an abuse, it will not accept the complaint; if the complaint is within the scope of the UDRP, the AAWG will inform the complainant to ask for help from UDRP service providers; in case the complaint is accepted by the AAWG, the domain name will be locked (pending the AAWG’s decision). The domain name remains resolvable but is untransferable, and all of the domain name information is unchangeable. Such locking process shall apply to both the domain name and its preferred variant. The complainant shall provide a written complaint application and evidence materials. The complaint application shall include the following:

1) Name, email and other contact information of the complainant and its agent (if any);
2) Name, email and other contact information of the respondent (if any);
3) Domain name relevant to the abuse complaint and its registrar;
4) Name, logo, trademark or other legal rights (if any) of the domain name with abuse complaint;
5) Request and reasons for the abuse complaint;
6) Related evidence proving the abuse of domain name by the respondent.

Step 3: Rapid Handling
In case the AAWG finds that the abuse has clear facts and irrefutable evidence and cause serious consequences, it will activate the rapid handling process, see Section 28.5.3. In case the complaint fails to meet the conditions for the rapid handling process, then proceed to Step 4.

Step 4: Investigation and Evidence Collection
The Anti-Abuse Working Group will investigate and collect evidence regarding the abuse complaint by leveraging its Internet technologies and knowledge on related laws, including working with the registrars to obtain and keep related evidence so as to determine the existence of the abuse. The AAWG will request that the respondent provide related technical evidence and materials to refute the allegation of abuse. When necessary, the AAWG will coordinate with the domain name holder and anti-abuse joint action community to investigate the related evidence of the abuse, and confirm whether other domain names of the registrant are abused. In case the AAWG believes that the abuse involves a criminal offense, it will notify the proper authorities to investigate and collect evidence in relation to the offense.

Step 5: Decision
CONAC Anti-Abuse Working Group shall render its decision in relation to the abuse complaint within 15 business days after it has accepted the abuse complaint. The decision will be taken in accordance with ICANN’s related policies, the evidence and materials provided by the complainant, respondent, domain name holder and anti-abuse community as well as China’s other laws and regulations concerned. The decision should set out whether the abuse is confirmed and the type(s) of abuse, the responsible person and handler of the abuse, as well as the severity level and handling level (normal handling or rapid handling) of the abuse. An abuse involving a suspected crime will be referred to the judicial authority concerned.

Step 6: Notice to Related Stakeholders
CONAC Anti-Abuse Working Group will notify the complainant, respondent, domain name holder, registrar and anti-abuse joint action community about the decision on the abuse complaint within three (3) business days after the decision was taken. For phishing, the working group will also contact the holder of the counterfeited domain name.

Step 7: Execution of the Decision of the Anti-Abuse Working Group or the Verdict of the Court
When the complainant and the respondent agree with the decision of the Anti-Abuse Working Group, CONAC (or⁄and the domain name holder, registrar or other stakeholders) will execute the decision. The domain name with judged abuse will be taken down. After CONAC is delegated with “政務” TLD, such a take-down process shall apply to both the domain name and its preferred variant.

When the complainant or the respondent disagrees with the decision given by CONAC Anti-Abuse Working Group, it may lodge a lawsuit to a competent people’s court in China within 15 calendar days after the decision was delivered. CONAC will finally execute the verdict of the court.

When the abuse badly influences the key functions and operation of the system, CONAC will quickly activate back-up system, and inform ICANN and report to the Ministry of Industry and Information Technology of China.

In case the registrar or its reseller gets involved in the abuse, such as Fake Renewal Notices and Cross-TLD Registration Scam, the registrar or its distributor is requested to pay liquidated damages or other measures are adopted to facilitate rectification.

28.3 Measures for Removal of Orphan Glue Records
The policy for registration restrictions on name servers of delegated subzones is implemented through PQP. CONAC and the registrars will execute verification on registration information of each registrant through PQP to ensure compliance with CONAC’s registration policies.

When provided with evidence in written form that the glue record is present in connection with malicious conduct, CONAC will promptly remove the orphan glue record from the DNS system. To facilitate effective removals, CONAC will establish an orphan domain name table in the database, which lists orphan domain names and their generating time. A glue record with be removed after a grace period of thirty (30) calendar days.

28.3.1 Management of Orphan Glue Records after Deletion of Domain Names
CONAC will use the following domain name deletion processes.

Phase 1: To delete all NS records and A records of the domain name and note down current time point as “curTime”.

Phase 2: Traverse the “政务” TLD zone to find any NS records pointing to the same name servers as the RNAME of the A records to be deleted. If no such NS record is found, proceed with the deletion of the A records. Otherwise, the A records remain in the zone to ensure the resolution of the domains associated with them. The sub domain name and the curTime shall be placed into the Orphan domain name table. Meanwhile, CONAC will send emails to contact persons of the domains affected by the upcoming deletion of A records, notifying them that their domain names are about to be removed and need to be re-directed.

CONAC will move on to the next sub domain name after the procedure mentioned above is completed.

Phase 3: To send out a warning message if any orphan glue record is found, calling it to the attention of the system administrator.

28.3.2 Periodical Scan and Removal of Orphan Glue Records in the System
CONAC executes a daily routine scan of orphan domain name table, starting at 16:00 UTC

Phase 1: Note down the current system time as “curTime”;

Phase 2: For each record in the Orphans form (note as “recordA”), compare the elements in its Orphan column (note as “sOrphan”) and time column (note as “tTime”). If curTime – tTime 〉= 30 days, or no sOrphan domain name stands as the RDATA of NS record, then delete record A and corresponding A record of the Orphan. Meanwhile a warning message will be sent to the system administrator, and then the process moves on to the next record in the Orphans form.

The SRS will check whether the intended RDATA of a NS record is listed in the Orphans form for any NS change attempt. If so, a warning message will be triggered, and the change is denied.

28.4 Measures to Promote WHOIS Accuracy
CONAC and the registrars are responsible for raising the WHOIS accuracy.

Generally, CONAC requires the registrar to publish the complete registration information in the WHOIS, this will ensure the accuracy of WHOIS records. For specific information that is requested not be disclosed by the registrants, the registrar information will be presented as a Proxy instead. Upon CONAC’s request for complete information concerning any registrant, the registrar must fulfill the request. As previously described, CONAC will include the relevant terms to the RRA and Registration Agreement with the purpose of protecting WHOIS information from being abused.

28.4.1 Measures to Verify the Accuracy and Integrity of Registrant Information
In Addition to the PQP Verification Process mentioned in Section 28.5.1,CONAC will require that the following terms are included in the Registration Agreement signed between registrars and registrants: all information provided by the registrant must be real, accurate and complete. The necessary information provided by the registrant organization includes: name and certificate of legal establishment, registrant contact, administrative contact and technical contact. The registrant must sign a letter of commitment to promise not to conduct any abusive behavior before applying for registering a “.政务” domain name. If any of the registration information is inaccessible, CONAC will require the registrar to verify such information. If the inaccessibility remains unchanged for over 3 months, CONAC will suspend the domain name. Such suspension processes shall apply to both the domain name and its preferred variant.

In terms of domain name transfers, all application material shall be initially reviewed by the registrar and then be submitted to CONAC for further reviews.

28.4.2 Regularly Monitor Registration Data to Ensure Its Accuracy and Completeness
The monitoring system deployed by CONAC performs a monthly scan of entire WHOIS database for the accuracy and completeness of registration data.

The specific methods are as follows: the first method is an analysis of data completeness. CONAC checks some WHOIS data at random semimonthly and adopts corresponding algorithms to selects matching data in accordance with various patterns of previously incomplete data. The second method is an analysis of data accuracy. CONAC establishes interfaces with the authoritative databases owned by the registration authorities of Chinese government organization community members to make comparisons between agency information in CONAC’s domain name database and that in the authoritative databases. This will enable discovery of inaccurate data or no corresponding data in the authoritative databases. The third method is random sampling analysis. The data not drawn as sample data in the past three years is sampled and the proportion of random sampling will be determined in accordance with the domain name registrations of CONAC.

In addition to summarizing the data obtained through the aforementioned three channels and by accepting complaints, as well as using the data provided by the anti-abuse community, CONAC customer service staff will have a baseline for checking and verifying data accuracy for domain name holder and contact person by phone or email. When there is any incomplete or inaccurate data, CONAC will establish an internal tracking standing book of incomplete information. At the same time, CONAC will urge the registrar to request the domain name holders to provide the missing information, and will request that the registrar verify the information provided. In case the registrar fails to provide the necessary information in time, the system will give a notice to the registrar and determine the necessary action in accordance with situation.

28.4.3 Measures to Promote WHOIS Accuracy by the Registrars
CONAC requires registrars who wish to provide “.政务” domain name registration services to sign the Registry-Registrar Agreement containing following terms:

1. Being accredited by ICANN;

2. Never participating in, encouraging and acquiescing in domain name abuses;

3. Promising not to conduct any abusive behavior, having in place concrete mechanisms to prevent registrants from conducting domain name abuses in accordance with relevant policies set by ICANN and CONAC;

4. notifying domain name applicants of domain name abuse prohibition policies; reporting to CONAC any domain name abuse complains in a timely manner; performing rapid handling process for abusive domain names in response to CONAC’s requirement; posting CONAC’s complaint contact information including email address, physical address, contact person and telephone number conspicuously on their websites, business forms and in their place of business; verifying the accuracy and integrity of registration information.

Any registrar conducting abusive behavior will be notified of the problem and appropriate action will be taken by CONAC. Any registrar who conducts one (1) intentional or three (3) negligent abuses will face to termination of the RRA and the registrar shall be subject to legal liabilities.

CONAC will require all the registrars to attend an annual training program to share experience in mitigating malicious behaviors, and enhance their technical capability to combat malware and abuse, cyber squatting etc. (conference call, face to face meeting, webinar). CONAC will continually evaluate the registrars’ performance in WHOIS accuracy and integrity in accordance with WHOIS monitoring data. Those registrars who score low in the WHOIS performance evaluation will be required to make specific plans for improvement. CONAC will also check the implementation of the plans afterwards.

28.5 The Definition of Abusive Behavior and Policies for Resolution and Prevention
General policies and work procedures for dealing with abuse complaints have been described in Section 28.2. This section focuses on abuse prevention and mitigation policies, definitions and resolutions of abuses, rapid takedown and suspension procedures, sharing information with anti-abuse communities and measures to prevent WHOIS abuse.

28.5.1 Implementing PQP and CCM to Prevent and Mitigate Potential Abuses
1. Pre-registration Qualification Procedure (PQP)
1) Pre-verification by Registrars
The PQP requires the registrars to pre-verify the eligibility of each registrant via registrant information and certificates provided. The PQP is designed to verify the following items:

That the registrant information is complete, true and accurate, and the Application Form has an official stamp of the registrant; that the registrant is legally established; that the contact information is true; that the applicant represents the organization whose name matches the applied-for domain name; and that the applied for domain name complies with CONAC’s registration policies. The applied-for domain name can pass the registrar’s pre-verification only when all the above information meets CONAC’s requirement, otherwise, the registrar shall reject the application with reasons for the rejection given and “.政务” domain name registration policy attached. Any registrar that violates the above term will be liable for breach of the agreement.

2) Re-verification by CONAC
CONAC re-verifies the registration information submitted by the registrars with the same criteria as the pre-verification. A domain name can go live after passing registrar’s pre-verification and CONAC’s re-verification. CONAC has built up communication mechanisms with approval authorities that decide the structure of government organizations in China.

In terms of domain name transfers, all application material shall be initially reviewed by the registrar and then be submitted to CONAC for further reviews. Domain names that pass CONAC’s further review can be transferred.

CONAC implements a Staff Performance Appraisal Systems for rewarding and disciplining staff in the re-verification positions to ensure good quality in the procedure.

See Figure2 of Q28_attachment for the registration procedure.

2. Continuous Compliance Mechanism (CCM)
After the domain name registration becomes effective, the registrar shall conduct a continuous review on the qualification of domain name registrant and the usage of the domain name in accordance with CONAC’s measures for domain name review: 1) regularly request the domain name holder to provide relevant written materials, such as registration certificates; 2) request the domain name holder to provide relevant written materials when the domain name holder presents a request to change the information in relation to the domain name. The registrar shall check that the registrant is the qualified holder of the domain name, and that the information is authentic and complete. When the check is successfully completed, the domain name may pass the CCM.

Follow-up handling measures include: 1) the domain name which has passed CCM will be continuously used; 2) in case of inconformity between the domain name holder and the registration information, the registrar shall request that the domain name holder submit valid documentary evidence within five (5) business days, otherwise the domain name will be suspended; 3) when the domain name holder requests to change domain name information, the same procedures of the PQP are applicable to the new information provided by the domain name holder so as to ensure that the changed domain name accords with CONAC’s registration policies.

Since the gTLD that CONAC applies for is not for commercial use, and because the PQP, CCM and other rights protection mechanism (such as sunrise services, trademark claim services, etc.) are effectively implemented, CONAC is capable of preventing and mitigating abuses including Cyber squatting, Front‐running, Gripe sites, deceptive and⁄or offensive domain names, Name spinning, Pay‐per‐click, Traffic diversion, False affiliation and Domain kiting ⁄ tasting to the greatest extent.

28.5.2 The Definition of and Resolutions of Abuses
According to the definition given by Registration Abuse Policies Working Group (RAPWG), the abusive behavior refers to “An action that causes actual and substantial harm, or is a material predicate of such harm, and is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.”
The main types of registration abuses include Cyber squatting, Front-Running, Gripe Sites, Deceptive and⁄or Offensive Domain Names, Fake Renewal Notices, Cross-TLD Registration Scam, Name Spinning, Pay-per-Click, Traffic Diversion, False Affiliation, Domain Kiting⁄Tasting, fast‐flux, spamming, malware distribution, online child pornography phishing, botnet command and‐control and trademark abuse. The definitions and solutions of the abuses are described in details below.

Given that the community TLD is only available to registrants from the government organizations community, it is highly unlikely that any of the types of abuses identified above will occur.

1. Cyber squatting
Provisions 4(a) and 4(b) of the UDRP are a sound definition of cyber squatting.

Theoretically, cyber squatting is avoidable, since only eligible organizations can register their corresponding domain names with the strict implementation of PQP. CONAC relies on the UDRP as reviewed from time to time, as the long-standing mechanism for addressing cyber squatting.

2. Front-running
Front-running is when a party obtains some form of insider information regarding an Internet user’s preference for registering a domain name and uses this opportunity to preemptively register that domain name. In this scenario, ʺinsider informationʺ is information gathered from the monitoring of one or more attempts by an Internet user to check the availability of a domain name.

As stated above, CONAC implements strict Preregistration Qualification Procedures (PQP), all “.政务” domain names must pass PQP, no “.政务” domain name can be reserved by any registrars.

CONAC also takes the following measures to prevent or mitigate such practices:

1) CONAC seeks to promote the registrarsʹ efforts to better educate registrants about the existence of after-markets and how these affect registrants.

2) CONAC encourages registrars to eliminate the use of industry jargon wherever possible when presenting information to consumers and non-technical Internet users.

3) CONAC encourages registrars to consider ways to eliminate Internet usersʹ misconception that domain name back ordering services offer a guarantee that they will register the name when the current registration expires and is not renewed.

4) CONAC believes it is necessary to increase the awareness among the prospective domain name registrants about registration abuse. Prospective registrants should recognize that (a) querying the availability of a domain name demonstrates an interest or ascribes a value on that name and (b) if interest in and competition for domain names is intense, and these factors increases the probability that multiple parties will show interest in the same name. Thus, prospective registrants may wish to prepare in advance and to register a domain name at the time when they query the availability of a domain name of interest. Registrants should maintain records of domain name availability checks and registration attempts.

5) Registrars are required by CONAC to provide clear notice to Internet users regarding how they treat information submitted during an availability check.

3. Gripe Sites; Deceptive, and⁄or Offensive Domain Names
Examples of such abuse includes:

1) Pornographic⁄Offensive Sites: Websites that contain adult or pornographic content and use a brand holder’s trademark in the domain name (e.g. brandporn.com).

2) Offensive strings: Registration of stand-alone offensive words within a domain name (with or without brand names).

3) Registration of deceptive domain names: Registration of domain names that direct unsuspecting consumers to obscenity or direct minors to harmful content—sometimes referred to as a form of “mousetrapping.”

4) Gripe⁄Complaint Sites a.k.a. “Sucks Sites”: Websites that complain about a company’s or entity’s products or services and use a company’s trademark in the domain name (e.g. companysucks.com). Note: since these sites may be considered an expression of “freedom of speech” in some countries, the AAWG will make decisions in accordance with situation.

The PQP and regular naming conventions that implemented by CONAC concurrently regulate registrants’ eligibilities and their applied for domain names. In addition, there are community usage requirements in place. Therefore, abuses associated with Gripe Sites; Deceptive, and⁄or Offensive Domain Names can be avoided.

4. Fake Renewal Notices
Fake renewal notices are misleading correspondence sent to registrants from an individual or organization claiming to be or to represent the current registrar.

Such abuses are an issue of trade practices and are, more often than not, handled by law enforcement and court cases, governments and consumer protection agencies. CONAC provides aid for such lawsuits whenever necessary in a bid to protect registrantsʹ rights. If the perpetrator is a registrar, CONAC’s policy applies through the RAA (Registrar-Accreditation Agreement). If the perpetrator is not a registrar, CONAC’s role lies in its efforts to defend against domain name hijacking or WHOIS abuse.

Additionally, CONAC takes the following measures to avoid Fake renewal notices:
1) To require the registrars to send domain name expiration notifications to registrants thirty (30) days and sixty (60) days in advance.
2) To list all domain names that will expire in sixth (60) days on CONAC’s website;
3) To provide information in the WHOIS, including domain name expiring date.

5. Cross-TLD Registration Scam
“Cross-TLD Registration Scam” is a deceptive sales practice where an existing registrant is sent a notice that another party is interested in or is attempting to register the registrant’s domain string in another TLD. The registrant is therefore pushed to make additional registrations via the party who sent the notice – often a reseller who would profit from the additional registrations, and is offering the new domain at a higher-than-average market price.

This deceptive practice could or should be dealt with via legal, regulatory, or consumer protection mechanisms offered by governments. Nevertheless, CONAC safeguards its WHOIS service from being involved in such abuse by noting the use of a list of registrants for the purposes of spamming could be a violation of WHOIS policies. CONAC regulates the registrars by entering RRAs, in which the terms of abuse prohibition are stipulated. Any cross-TLD registration scam detected will result in termination of the RRA with CONAC.

6. Name Spinning
This is the practice of using automated tools to create permutations of a given domain name string. Registrars often use such tools to suggest alternate strings to potential registrants when the string that the person queries is not available for registration.

Automatic bulk registration of domain names is not supported by the PQP, which means that the name spinning can be avoided.

7. Pay-per-Click
Pay per click (PPC) is an Internet advertising model used on Websites, in which the advertiser pays the host only when their ad is clicked. The concern raised is the use of a trademark in a domain name to draw traffic to a site containing paid placement advertising.

Pay-per-click advertising is not in and of itself a registration abuse, and bad-faith use of trademarks in domain names is a Cyber squatting issue that can be addressed under the UDRP. Theoretically, the Pay-per-Click is avoidable for non-commercial TLDs. With PQP and strict registration policy in hand, CONAC may eliminate such abuse in “.政务” TLD .

8. Traffic Diversion
Use of brand names in HTML visible text, hidden text, meta tags, or Web page title to manipulate search engine rankings and divert traffic.

This is a Website use issue with no inherent relation to a domain name or registration process.
If CONAC receives complaints through telephone calls and e-mails, it will submit the case to the Anti-Abuse Working Group for resolution.

9. False Affiliation
Website that is falsely purporting to be an affiliate of a brand owner.

10. Domain Kiting ⁄ Tasting
Registrants may abuse the Add Grace Period (AGP) through continual registration, deletion, and re-registration of the same names in order to avoid paying the registration fees. This practice is referred to as “domain kiting.” Domain tasting is a different practice, in which a registrant measures the monetization potential of a domain during the Add Grace Period, and deletes it in AGP if the domain is not worth keeping.

As there is no clear evidence of this activity and the PQP makes it highly unlikely to occur, CONAC will continually monitor the issue and consider next steps if conditions warrant.

11. Phishing
Phishing is when a Website fraudulently presenting itself as a trusted site (often a bank) in order to deceive Internet users into divulging sensitive information (e.g. online banking credentials, email passwords). The goal of phishing is usually the theft of funds or other valuable assets.

CONAC’s observations and analysis show that phishing is generally a domain name use issue. Those cases that involve misleading use of brand names in the domain string may be treated as cases of cyber squatting.

CONAC identifies the fact that the great majority of domains used for phishing are compromised or hacked by phishers, and the registrants are not responsible for the phishing. Such domains are neither registered for bad purposes nor associated with the inherent registration issue, and therefore call for careful mitigation efforts by CONAC.

If CONAC receives complaints through telephone calls and e-mails, it will submit the case to the Anti-Abuse Working Group for resolution. For emergency phishing cases, CONAC will enforce measures like rapid suspension of the domain name.

12. Spam
Spam is generally defined as bulk unsolicited e-mail. Spam may be sent from domains, and be used to advertise Websites.

CONAC’s observations and analysis show that spam is generally a domain name use issue. Those cases that involve misleading use of brand names in the domain string may be treated as cases of cyber squatting.

If CONAC receives complaints through telephone calls and e-mails, it will submit the case to the Anti-Abuse Working Group for resolution.

13. Malware ⁄ Botnet Command-and-Control
Malware authors sometimes use domain names as a way to control and update botnets. Botnets are composed of thousands to millions of infected computers under the common control of a criminal. Botnets can be used to perpetrate many kinds of malicious activity, including distributed denial-of-service attacks (DDoS), spam, and fast-flux hosting of phishing sites.

Relevant malware (including that associated with Srizbi, Torpig, and Conficker) on these infected machines attempts to contact domains included on some sort of pre-determined list or generated via an algorithm. If the botnetʹs master has deposited instructions at one of these valid domains, the botnet nodes will download those instructions and carry out the specified malicious activity, or update themselves with improved code.

The Anti-Abuse Working Group will work on the relevant complaints, and will interact with CNCERT, share information and handle the abuse promptly, and delete the domain name if the abuse is confirmed.

14. Fast-flux
Fast flux refers to rapid and repeated changes to an Internet host (A) and⁄or name server (NS) resource record in a DNS zone, which have the effect of rapidly changing the location (IP address) to which the domain name of an A or NS resolves. Although some legitimate uses for this technique are known, it has within the past few years become a favorite tool of phishers and other cybercriminals who use it to evade detection by anticrime, antimalware and anti-phishing investigators.

CONAC will monitor and control fast-flux domain names, maintain effective interactions with CNCERT and other Internet security organizations, share abuse information and will submit shared information to the Anti-Abuse Working Group for resolution in a timely manner.

15. Online child pornography
Online child pornography refers to images or films and, in some cases, writings depicting sexually explicit activities involving a child and spread on the Internet.

CONAC will actively cooperate with the State Council Information Office of the People’s Republic of China, the authority for administrating Internet content in China to ensure the legitimacy of content on the websites of the government affairs community, and ensure no child pornography exists in the TLD.

16. Pharming
Pharming is an Internet scam that involves misdirecting a user to a fraudulent Website or proxy server by exploiting weaknesses in DNS server software and hijacking transactions, or by changing certain files in the client software on a victimʹs computer. Pharming is technically sneakier than phishing because it can be done without any active mistake on the part of the victim.

So first of all, CONAC will play an active role in education and awareness raising, and ensure that all parties including registrants and registrars are aware of the pharming risks and the mitigation measures. As pharming threats, especially those initiated from the DNS cache poison, can be largely alleviated by the deployment of DNSSEC, CONAC will promote the adoption of DNSSEC in the “.政务” sub domains. Additionally, CONAC will advocate and establish an emergency procedure to flush the spoofed domain or poisoned DNS cache and recover from the pharming attacks in cooperation with the Internet community upon the receipt of complaints of pharming attacks. If CONAC receives complaints through telephone calls and e-mails, it will submit the case to the Anti-Abuse Working Group for resolution. The domain names with abuse confirmed will be deleted.

17. Trademark Abuse

The trademark abuse is that registrants’ domain name is identical or confusingly similar to a trademark or service mark in which the trademark holder has rights; and the registrant has no rights or legitimate interests in respect of the domain name; and the domain name has been registered and is being used in bad faith.
CONAC provides the sunrise services and trademark claim services, and abides by the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) and Trademark Post-Delegation Dispute Resolution Procedure(PDDRP). CONAC will protect the legitimate rights and interests of the trademark owner, and will assign dedicated personnel to execute the decision made in accordance with UDRP, URS and PDDRP.
Further details are provided in the response to Question 29.

28.5.3 Handling Level
CONAC Anti-Abuse Working Group assesses the severity level of the abuse and determines the corresponding level and process in accordance with the acquisition way of, people affected by and actual loss and damage brought about by the abuse. At the same time, acceptance time limit and handling time are specified and a rapid handing process is set in CONAC’s abuse complaint processes. In case the AAWG finds that the abuse has clear facts and irrefutable evidence and cause serious consequences, especially the abuse identified by URS and Anti-Phishing Alliance of China (APAC) or a complaint concerning criminal acts, the AAWG will activate the rapid handling process and will suspend the domain name within 48 hours (See Section 28.5.4 for details). When the working group receives a request from a judicial authority or law enforcement, it will launch a rapid handling process and rapidly suspend the domain name concerned within 48 hours. Any abuse involving crime will be reported to judicial authority in a timely manner.

CONAC will notify the stakeholders, including complainant, respondent, domain name holder, registrar and anti-abuse joint action community about the decision within three (3) business days after the suspension.

The domain name holder may lodge a complaint in three (3) business days after receiving the notice. CONAC will make a decision on the complaint within 15 business days. If the evidence provided by the domain name holder is sufficient enough, the domain name holder may succeed in the claim with the domain name restored in 48 hours by CONAC; if the domain name holder does not respond to the claim or fails to prove the claim, CONAC will take down the domain name in 48 hours after the claim expiring date or the failure date (See Section 28.5.4 for details)

When CONAC is delegated with “.政務”, such suspension⁄takedown processes shall apply to both the domain name and its preferred variant.

28.5.4 Rapid Suspension ⁄Takedown of Certain Domain Names
CONAC offers the functions of “Suspend” and “Takedown” in the SRS to suspend and takedown certain domain names.

The “Suspend” function enables CONAC to suspend a domain name by setting the EPP status to “serverHold”. Then the domain name cannot be resolved and transferred, until CONAC activates “Restore” in the SRS. CONAC will notify the registrar to synchronize the changes. If the domain name exists in the resolution system, the system will notify certain interfaces to delete the domain name (including its variant form) from primary DNS of the resolution system, and the primary DNS will immediately notify corresponding secondary DNS sites.

If CONAC receives an effective judgment or notification from law enforcement entities, stating the requirement of takedown of a domain name, CONAC will skip the “suspension” and directly delete the domain name by activating “Takedown” function in the SRS. Then the system will delete the domain name (including its variant form) from the primary DNS. The primary DNS will immediately notify corresponding secondary DNS sites to proceed with the updates. The “.政务” TLD can be completely updated in 24 hours.

28.5.5 Share Information with Domain Name Anti-Abuse Communities
CONAC will adopt common information sharing means with the domain name anti-abuse community to blacklist domain name registrants with three or more malicious abuses and share its blacklist with the domain name anti-abuse community.

1. Interactive mechanisms with ICANN
CONAC defines and adjusts from time to time its abuses and anti-abuse policies applicable to the “.政务” community in accordance with the definitions and related polices concerning abuse types published by the authoritative organs of ICANN as well as the actual conditions of “.政务” communities, such as the Memorandum on Definitions and Interpretations of Abuse designated by ICANN Anti-Abuse Working Group, related guiding documents on abuse promulgated by the Security and Stability Advisory Committee, the documents of the anti-phishing working group as well as the documents concerning anti-abuse measures of Registry Internet Safety Group (RISG) and Computer Incident Response Community (FIRST⁄CERTs).
In addition, pursuant to the Expedited Registry Security Request Process (ERSR) formulated by ICANN, CONAC shall report to ICANN any of following sudden events:
1) Malicious activity involving the DNS of a scale and severity that threatens systematically the security, stability and resiliency of a TLD or the DNS.
2) Unauthorized disclosure, alteration, insertion or destruction of registry data, or the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.
3) An incident with the potential to cause a temporary or long-term failure of one or more of the critical functions of a gTLD registry as defined in ICANN’s gTLD Registry Continuity Plan. When an incident occurs, CONAC will fill in an ERSR form designated by ICANN and submit the form to ICANN. CONAC will describe the detailed information of the incident, measures adopted and time needed to solve the incident. The ERSR form will be automatically reported to the Security Response Advisory Group of ICANN. CONAC have specially-assigned persons to communicate with the Security Response Advisory Group and coordinate with ICANN staff to complete the investigation, record and solve the sudden event.

2. Joint Action Mechanism with CNNIC’s Anti-Abuse Team
China Internet Network Information Center (CNNIC) is an administration and service organ established with the permission of national competent authorities to function as the national Internet network information center and administer ccTLD “.cn”, IDN ccTLD “.中国” and “.中國”.

CONAC requires registrar to adopt pre-verification of PQP, generally there is no cyber-squatting under “.政务” TLD. However, in order to effectively guarantee the interests of the government affair communities, CONAC will cooperate with CNNIC and request CNNIC to keep a close watch on suspected government affair domain names registered under “.cn” and “.中国”. The interaction mechanism between CONAC and CNNIC focuses on two aspects: 1) anti-cyber-squatting. CNNIC keeps a close watch on cyber-squatting of government organization names under “.cn” and “.中国” but not under “. 政务.cn”. CNNIC will provide timely notification to CONAC when a cyber-squatting is found, and CONAC will cooperate with CNNIC to review the qualification of the applicant. 2) Anti-phishing. Although some measures are adopted to prevent cyber-squatting, it is still inevitable that some registrants use the words similar with the names of “政务”community members to register “.cn” and “.中国” domain names. For phishing websites using such domain names, CNNIC’s Anti-Abuse Working Group will notify CONAC immediately after it receives complaints so as to conduct a joint anti-phishing investigation.

3. Joint Action Mechanism with CNCERT
Directly led by the Internet Emergency Response Coordination Office under the Ministry of Information Industry, China National Computer Emergency Response Team⁄Coordination Center (CNCERT⁄CC) coordinates China’s Computer Emergency Response Teams (CERTs) to jointly handle security emergencies on the national public Internet, provides computer network safety monitoring, early warning, emergency response, prevention and other security services and technical supports for national public Internet, main national network information application systems and key departments, timely collects, verifies, summarizes and publishes authoritative information concerning Internet security, and organizes domestic computer network emergency response institutions to conduct international cooperation and exchanges. At the same time, CNCERT⁄CC also serves as a bridge for exchanges and contacts with international CERT organizations. CNCERT is a full member of the Forum of Incident Response and Security Teams (FIRST), an authoritative international organization. CNCERT⁄CC participates in the establishment of the Asia-Pacific Computer Incident Response Team (APCERT) and is a member of APCERT Steering Committee. CNCERT⁄CC has conditions to timely have exchanges and cooperation with foreign emergency response teams and other related organizations, and serves as a window to the outside world for China to handle network security incidents.

The interaction between CONAC and CNCERT mainly covers the following aspects: 1) CONAC regularly tracks the system bugs, early virus warnings and MALWARE reports concerning DNS system that are released by CNCERT. For example, CONAC Anti-Abuse Working Group timely patches the bugs discovered concerning open source software BIND, and turns to CNCERT for assistance when necessary. The Anti-Abuse Working Group leverages CNCERT’s role as a bridge for exchanges with international CERT organizations to timely track the evolution of virus varieties concerning DNS and observe the participation of “.政务” domain names in virus transmission. 2) CONAC employs CNCERT experts to evaluate system construction and independently developed software, takes part in security evaluation, and employs experts to give assistance in developing service level SLA and solve technical problems concerning security. 3) CONAC will review these reports to improve its abuse policies (CNCERT publishes weekly reports on network security information) CNCERT keeps close contacts with international security expert organizations and thus boasts a strong knowledge base. CONAC leverages the knowledge base to alter abuse handling processes. 4) CONAC assists CNCERT to conduct survey on sudden network events, collect statistics on and monitor spread trends of Botnet and malware on China’s Internet.

28.5.6 Prevent Abuse on WHOIS Functions
CONAC conducts monitoring over the WHOIS system to prevent abuses. CONAC does not allow a single user to send frequent queries to the WHOIS system (such as using data mining software to access the WHOIS system) and prohibits searching the WHOIS with wildcard. The system may restrict accesses from certain IP address in a short period of time by configuration when any negative effect of certain operation to the system is detected.

28.6 Adequate Controls to Ensure the Proper Access of Domain Names
Registrars undertake the following controls via requirements in the Registry-Registrar Agreement (RAA).

28.6.1 Multi-factor Authentication
CONAC secures user accounts by multi-factor authentication. User account access is secured through password, token and one-time password, or the combination of at least two of them. A strong password must contain at least 10 digits with letters, numbers and special characters. Tokens are generated randomly in the USB-Keys distributed offline. One-time password is generated pseudo-randomly by synchronized password cards held by CONAC and the registrant.

The user can change, transfer and delete domain names only after log on to the system. Additionally, CONAC as a registrar system provider may offer universal edition of registrar service software to the registrars that have no registrar systems ready for operation to assist them in deploying multi-factor authentication. (see responses to Question 23) The multi-factor authentication is also adopted in the universal edition of the registrar service software.

28.6.2 Contact to Request and⁄or Approve Update, Transfer and Delete Requests
CONAC requires registrars to implement a process, in which all update, transfer and delete requests shall be firstly confirmed by at least two points of contact, including registrant, administrative contact and technical contact, before proceeding with relevant requests.

28.6.3 Notification of Contact
CONAC requires registrars to notify the registrant, administrative contact and technical contact when a domain name is successful updated, transferred and deleted.

28.7 Resourcing Plan
CONAC will allocate 10 people in the positions of marketing, customer support and technical support, 3 invited experts are included. These resources are sufficient for the initial implementation and ongoing maintenance.

3 Customer Support Staff Role D: responsible for accepting complaints from the website, email box and telephone calls, submitting cases to the Anti-Abuse Working Group, replying customers with results, and supervising the implementation of measures taken by CONAC and the registrars on raising the WHOIS accuracy.

2 Registration managers Role B: responsible for registry re-verification and CCM

The Anti-Abuse Working Group is consisted of 2 CONAC staff and 3 invited experts.

1 Legal Staff Role A: responsible for tracking abuse situation, researching on and develop anti-abuse policies, participating in abuse resolution procedures and decision making process;

1 Security Engineer Role B: responsible for technically monitoring the abuse situation, dealing with the abuses in accordance with decisions from the Anti-Abuse Working Group;

3 Invited Experts: responsible for handling abuse complaints.

The single point of contact mentioned in Section 28.1 is available on CONAC’s website. The relevant operations of suspension and takedown are developed in the SRS. See responses in Question 24 (SRS) for relevant resource allocations.

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in the response to Question 31.

CONAC will give adequate considerations to the changes of business scale and allocate more human resources if necessary.

Costs of resources allocation are detailed in costs and capital expenditure of Question 47a and 47b.

29 Rights Protection Mechanism
CONAC identifies rights protection as a core objective. CONAC not only establishes mechanisms for providing effective protections that meet ICANN’s minimum requirements, but also adopts additional measures that exceed minimum requirements of ICANN to protect registrants’ rights.

CONAC’s registration policy, with its Pre-registration Qualification Procedures (PQP) which includes pre-verification and re-verification of eligible registrants ensures a very high level of rights protection. Eligible registrants are made up of the government affairs community, thus the risk of abuse is inherently low as these organizations fulfill public duties and have an incentive to provide authoritative information to users.

CONAC, registrars and registrants shall abide by the following rights protection mechanisms to guarantee interests of relevant parties:

1. The Rights Protection Mechanisms that CONAC shall follow include: safeguards against allowing unqualified registrations, PDDRP, RRDRP, measures for reducing phishing, pharming or other malicious behavior, trademark claims service and sunrise service, URS, preventing abusive use policies, takedown procedures, re-verification of PQP, periodic registration data monitoring, information sharing with anti-abuse community and annual registrar trainings.

2. Rights Protection Mechanisms that the registrars shall follow include: UDRP, Pre-verification of PQP, Continuous Compliance Mechanism, joining CONAC annual registrar training and Registry Registrar Agreement (RRA).

3. Rights Protection Mechanisms that registrants shall follow include: Registration Policies and Registration Agreement.

29.1 Minimum Protections of Rights
CONAC will implement rights protection mechanisms that comply with the minimum requirements in Specification 7 of the Registry Agreement and are consistent with the technical, operational, and financial approach of the registry. CONAC will comply with all current rights protection mechanisms and dispute resolution mechanisms. For those ICANN accredited registrars that enter into the RRA with CONAC, their compliance with the above rights protection mechanism is a compulsory requirement.

29.1.1 Safeguards against Allowing Unqualified Registrations and Other Rights Protection Mechanisms
CONAC’s registration policies, in particular the PQP and the naming conventions, will effectively mitigate domain name disputes. CONAC abides by ICANN mechanisms and has developed specific measures to effectively implement registration policies, and to prevent violations of the registration qualification and regulations.

29.1.1.1 Registration Policies
CONAC has formulated a set of naming conventions, registration restrictions, reserved names and registration prohibitions to prohibit unqualified registrations (including eligibility requirements, which will be described in detail in Section 29.2.1).

In CONAC’s naming conventions, it is regulated that all applied-for domain names shall contain at least one Chinese character, digital numbers (0~9) and hyphen (-) are also allowed to use combined with Chinese characters; each level is separated by “.” or Chinese full stop “。”; the applied-for domain name can be the full name, the official abbreviation, the habitual abbreviation or other names of an organization. When using the full name or the official abbreviation of an organization, the domain name shall be consistent to the name approved by relevant authorities; when using the habitual abbreviation of an organization, the domain name shall be consistent to the name that is widely used. In principle, such “.政务” domain names shall contain names of relevant administrative divisions (such as province, city, county and township, etc.). When using other names, the domain name shall be consistent to the functions and business scope of the organization as approved by its governing authority. If the applied-for domain name contains an administrative division name that is visually or aurally same to other division names，the domain name shall be preceded by a province name.

In CONAC’s restricted registration policies, it is regulated that if an applied for domain names containing the characters of “中国”(China), “中华”(China), “国家”(Nation),“全国”(Nationwide) or “中央” (Central), the applicant shall submit necessary approval documents; CONAC complies with Specification 5 of the Registry Agreement, and reserves names formed with the listed labels from initial registration within the TLD.

CONAC also prohibits domain name registrations under ten circumstances, including registrations that are against the basic principles prescribed in China’s Constitution. See responses to Question 18 (Section 18.2.4) for details about CONAC’s registration policies. See “Implementing Rules for ‘政务’ Domain Name Registration” for more details (http:⁄⁄www.conac.cn).

29.1.1.2 Measures to Guarantee the Compliance with the Registration Policies
To guarantee compliance with the registration policies, CONAC requires the registrars to pre-verify all registration information received, and then submit the verified information to CONAC for re-verification.
1. Pre-verification by the Registrars
CONAC requires all registrars to initially review the policy compliance of all applied for domain names, items include:
1) the compliance with CONAC’s registration policy;
2) the compliance with the IDN table (.CN Chinese); and
3) the completeness of the submitted information.
Only a domain name that complies with CONAC’s registration policy, with character strings listed in the .cn IDN table and with complete registration information can pass the pre-verification by the registrars, otherwise, the registrar shall reject the unqualified application with reasons for the rejection given and “.政务” domain name registration policy attached.

The above terms will be included in the RRA (the draft will be posted on CONAC’s website, which is http:⁄⁄www.conac.cn, before ICANN pre-delegation check phase). Any registrar that violates the above terms will be liable for breach of the agreement.

2. Re-verification by CONAC
CONAC re-verifies the registration information submitted by the registrars with the same criteria as the pre-verification. A domain name can go live after passing registrar’s pre-verification and CONAC’s re-verification.

29.1.1.3 CONAC Complies with PDDRP and RRDRP
In accordance with the Application Guidebook (AGB), the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) is intended to cover Trademark post-delegation dispute resolution proceedings generally. The parties to the dispute could be a trademark holder or a gTLD registry operator. The Registration Restriction Dispute Resolution Procedure (RRDRP) is intended to cover dispute resolution proceedings generally. The parties to the dispute could be a harmed established institution and a gTLD registry operator. The mandatory administrative proceeding will commence when a third-party complainant (“Complainant”) has filed a Complaint with a Provider asserting that the Complainant is a harmed established institution as a result of the community-based gTLD registry operator not complying with the registration restrictions set out in the Registry Agreement. Since “.政务” is a community based TLD, a harmed established institution may initiate administrative proceedings in accordance with RRDRP.

CONAC will comply with decisions made by the PDDRP⁄RRDRP expert panel, and adhere to and be bound by reasonable remedies ICANN imposes. CONAC will designate a legal staff to be responsible for PDDRP and RRDRP liaising, and for coordinating CONAC and the registrars to implement the panel’s decisions. Upon receiving the decision and (recommended) remedy from the PDDRP⁄RRDRP expert panel, if the party does not seek a de novo appeal or challenges the remedy, CONAC will implement the decision in three (3) business days after the end of appeal period and will notify the registrar of the status in three (3) business days. If a party appeals or challenges the remedy, CONAC will implement the final effective decision. In the RRA, CONAC will regulate that the registrars shall implement the related expert decisions, remedies or court verdicts. Any registrar that violates the term will be liable for breach of the RRA.

29.1.1.4 CONAC Complies with the Uniform Domain Name Dispute Resolution Policy (UDRP)
CONAC will specify in the RRA that registrars must implement the UDRP policy. The registrars will be liable for breach of the requirements in the RRA.

The UDRP will be incorporated into the registrants’ Registration Agreement, and set forth the terms and conditions in connection with a dispute between the registrar and any party other than the registrar over the registration and use of an Internet domain name registered by the registrar. CONAC has good collaboration with Beijing Office of the Asian Domain Name Dispute Resolution Centre (ADNDRC), and receives prompt information regarding domain name complaints.

29.1.2 Measures for Reducing Network Phishing, Pharming and Other Malicious Behaviors
Malicious behaviors such as phishing and pharming are big threats to the domain name system’s security. In accordance with the definitions given by the Registration Abuse Policies Working Group (RAPWG), CONAC has established a set of mechanism to prevent, detect and resolve phishing, pharming and other malicious behaviors. These mechanisms are described as following. Further details can be found in the response to Question 28. Eligible registrants are made up of the government affairs community, thus the risk of phishing, pharming and other malicious behaviors is inherently low as these organizations fulfill public duties and have an incentive to provide authorities to users.

29.1.2.1 Protection Measures
CONAC will play an active role in education, and ensure that all parties including registrants and registrars are aware of the phishing and pharming risks and other malicious acts. CONAC enforces registrant PQP, authentication procedures and relevant technical measures to prevent malicious behaviors including phishing and pharming. For example, as pharming threats, especially those initiated from the DNS cache poison, can be largely alleviated by the deployment of DNSSEC, CONAC will promote the adoption of DNSSEC in the “.政务” subdomains. Additionally, CONAC will advocate and establish an emergency procedure to flush the spoofed domain or poisoned DNS cache and recover from the pharming attacks in cooperation with the Internet community upon the receipt of complaints of pharming attacks.

CONAC has added the abuse prohibition terms into the RRA, stipulating that registrars shall not conduct abusive behavior. Breaches of the RRA may inter alia result in CONAC ceasing the registration services of “.政务” domain names and terminating the RRA. CONAC requires the registrars incorporate abuse prohibition terms in the registrant’s Registration Agreement and all registrants must sign a letter of commitment before registering a “.政务” domain name.

29.1.2.2 Detection Measures
CONAC foresees being alerted to suspected abuses through three channels: the first is by receiving complaints from affected parties, the second is by alarms given by the monitoring system deployed according to the characteristics of abuses, and the third is by the information reflected by anti-abuse communities.

The single point of contact’s hotline number, email box and postal address are posted on CONAC’s website (http:⁄⁄www.conac.cn) and complaints regarding abusive domain names registered in “.政务” TLD will be received 7x24x365.

CONAC requires all registrars to post the hotline number, postal address, email address and contact person on their websites. CONAC will keep ICANN and all relevant registrars updated if the information changes.

29.1.2.3 Resolution Procedures
1. The Complaint Handling Institution and Its Responsibility
CONAC has set up an Anti-Abuse Working Group (AAWG). The working group is composed of 2 CONAC staff and 3 invited experts who are versed in the fields of computer network security, cryptography, intellectual property and community management. All working group members have deep understanding of the Internet and related laws, and have strong professional ethics and are able to independently and neutrally judge the abuse complaint. The working group holds meetings regularly, or Ad-Hoc Meetings if necessary.

The main tasks of the working group include:
1) To accept and handle abuse complaints;
2) To track the latest anti-abuse research outcomes and research on anti-abuse issues in the global domain name communities;
3) To identify and define abuse types that are related to “.政务” domain names;
4) To analyze abusive behavior and develop anti-abuse policies;
5) To establish a coordination and linkage mechanism for anti-abuse community with ICANN, China Internet Network Information Center (CNNIC) and National Computer network Emergency Response technical Team (CNCERT).

2. Measures for Handling Malicious Behaviors
A complaint regarding phishing, pharming and other malicious behaviors may be solved by the complainant and the respondents (collectively referred to as the parties) through consultations, be submitted to the AAWG established by CONAC for settlement, or be submitted as a legal action to a competent people’s court in China. CONAC will confirm with the complainant the receipt of a complaint with in one (1) business day, and AAWG will then inform the complainant whether the complaint is accepted within five (5) business days.

3. The Consequences of Handling Malicious Behaviors
CONAC Anti-Abuse Working Group will stay well informed of ICANN’s polices concerning abuse and correspondingly determine methods of identifying abuses, and implements normal⁄rapid handling process. (See Section 28.5.2, 28.2.2, 28.5.3 and 28.5.4 for details). In case the AAWG decides that the abuse has clear facts and irrefutable evidences and cause serious consequences, the AAWG will activate the rapid handling process and will suspend the domain name within 48 hours (See Section 28.5.4 for details). When the working group receives a request from a judicial authority, it will provide timely response and rapidly suspend the domain name concerned. Any abuse involving a crime will be referred to the judicial authority. If any party disagrees with the decision for abuse complaint by the AAWG, it is entitled to lodge a lawsuit with a competent people’s court in China within 15 days as of the date of the delivery of the decision. CONAC shall execute the verdict given by the court.

29.1.3 Trademark Claims Service and Sunrise Service
As the Trademark Clearing House is still in development, CONAC commits to comply with the policies and procedures when they are finalized. CONAC will utilize the Trademark Clearing House and implement a Trademark Claims service and Sunrise service in conjunction with the Trademark Clearing House. Given the community nature and the eligibility criteria of the “.政务” TLD, it is likely the number of trade mark claims will be limited.

In accordance with ICANN’s requirements, CONAC will provide the Trademark Claims service for marks contained in the Trademark Clearinghouse for the first 60 days that registration is open for registration. The Trademark Claims Notice will provide the prospective registrant a warning that the applied for domain name matches a trademark contained in the Trademark Clearinghouse Database. A similar notice will be sent to the Trademark owner notifying them that a person has registered a domain name that matches their trademark.

CONAC provides a sixty (60) calendar days’ sunrise service, it doubles ICANN’s minimum requirement. CONAC will offer sunrise registration service during the sunrise period and a notice will be provided to all trademark holders in the Clearinghouse if someone is seeking a sunrise registration. During the sunrise process, the holders of eligible trademarks can apply for their corresponding domain name(s) directly under the “.政务” TLD before registration is open to the community. The fees associated with the sunrise services will be determined by the costs that CONAC will pay to the Trademark Clearing House Service Provider and reasonable profits.

In addition, CONAC will advertise our trademark claims services and sunrise services via popular Chinese TV channels, internet and magazines from the day “.政务” TLD is delegated until it pre-launches. CONAC will also explore establishing a hotline for sunrise service to ensure that trademark owners are aware of the sunrise period.

29.1.4 CONAC Complies with the Uniform Rapid Suspension system (URS)
Trademark holders can initiate a complaint by the Uniform Rapid Suspension system (URS) when their trademark rights are infringed. CONAC will comply with the URS, and implement decisions rendered under the URS on an ongoing basis. For the domain name involved in the dispute, CONAC establishes the following process flow below for responding to URS decisions. CONAC will also designate a legal staff in charge of contacting the URS provider, and feedback the results of the implementation of the decision to the URS provider and all parties. As the implementer of the URS provider’s decision, CONAC will follow the guidance given by the URS provider.

29.1.4.1Notice and locking of domain names
CONAC will “lock” the domain name within 24 hours upon receipt of the Notice of Complaint from the URS provider, meaning that the updating, transfer and deletion of the domain name will be prohibited, but the domain name will continue to resolve. CONAC will notify the URS provider via email that this domain name has been locked.

29.1.4.2 Upon receiving the decision notice
Upon receiving the decision notice from the URS provider, if the complainant wins the dispute, CONAC will immediately suspend this domain name for the remaining registration period, and the domain name will not be resolved to the original website. The domain name server shall redirect it to URS information prompt page provided by the URS provider. WHOIS data for the domain name will continue displaying all information of the original registrant, but not display the redirection of the name server. In addition, WHOIS will indicate that this domain name must not be transferred, deleted or modified in the current registration period. If the complainant loses the decision, the locked status of this domain name will be removed.

29.2 Additional Measures for Rights Protections that Exceed Minimum Requirements of ICANN
Besides measures that meet ICANN’s minimum requirements, CONAC takes additional measures to protect rights of the registrants and other obliges seriously.

29.2.1 The Pre-registration Qualification Procedures (PQP)
29.2.1.1 Content of PQP
The PQP developed by CONAC extends the concept of the ordinary “pre-verification” procedure.

The PQP covers all content stated in Section 29.1.1.2 (registrar pre-verification and CONAC re-verification). Additionally, the PQP also verify the eligibility of the domain name applicant to ensure all registrants are eligible for registering the domain name. The strict PQP mechanism is determined by the special community of “.政务” domain name registrants. The eligible government organizations register corresponding“.政务”domain names which may improve the public trust of the TLD, thus guarantee the interest of internet users and Chinese government organizations.

29.2.1.2 Detailed Steps of the PQP
1. Pre-verification by Registrars
CONAC requires all registrars to stipulate the term of pre-verification in their registration agreement signed with registrants. The PQP requires the registrars to pre-verify the eligibility of each registrant via registrant information and certificates provided. The PQP is designed to verify the following items:
That the registrant information is complete, true and accurate, and the Application Form has an official stamp of the registrant; that the registrant is legally established; that the contact information is true; that the applicant represents the organization whose name matches the applied-for domain name; and all content stated in Section 29.1.1.2.The applied-for domain name can pass the registrar’s pre-verification only when all the above information meets CONAC’s requirement, otherwise, the registrar shall reject the application with reasons for the rejection given and “.政务” domain name registration policy attached. The above terms will be included in the RRA. Any registrar that violates the above term will be liable for breach of the agreement.

The necessary information provided by the registrant organization includes: name and certificate of legal establishment, registrant contact, administrative contact and technical contact. If any of the registration information is inaccessible, CONAC will require the registrar to verify such information. If the inaccessibility remains unchanged for more than 3 months, the domain name cannot be registered.

CONAC has built up communication mechanisms with approval authorities that decide the structure of government organizations in China.

CONAC implements a Staff Performance Appraisal Systems for rewarding and disciplining staff in the re-verification positions to ensure good quality in the procedure.

29.2.2 Authentication Procedures
29.2.2.1 Content of Identity Authentication
The identity authentication is designed to ensure the domain name applicant has official representativeness of the entity that matches the domain name. CONAC authenticates applicants’ identities through registration data verification. The requirements for registration data include that: (1) the email address submitted must be working and responsive; (2) the organization address and name must correlate; and (3) true registration contact information must be provided. The applicant can pass the identity authentication only when all information above meets CONAC’s requirements.

29.2.2.2 Procedure for Authentication
1. Measures Taken by CONAC
The deployed monitoring system performs a monthly scan of the entire registration database for the accuracy and completeness of registration data. The specific methods are as follows: the first method is an analysis of data completeness. CONAC checks some registration data at random semimonthly and adopts corresponding algorithms to select matching data in accordance with various patterns of previously incomplete data. The second method is an analysis of data accuracy. CONAC establishes interfaces with the authoritative databases owned by the registration authorities of the community members to make comparison between agency information in CONAC’s domain name database and that in the authoritative databases, in a bid to discover inaccurate data or no corresponding data in the authoritative databases. The third method is random sampling analysis. The data not drawn as sample data in the past three years is sampled and the proportion of random sampling will be determined in accordance with the domain name registrations of CONAC.

CONAC customer service staff will check and verify data accuracy for domain name holders and contact persons by phone or email. If there is any incomplete or inaccurate data, CONAC will establish an internal tracking list of incomplete information. At the same time, CONAC will urge the registrar to request the domain name holders to provide the missing information, and will request the registrar verify the information provided. In case the registrar fails to provide necessary information in time, the system will regularly give a notice to the registrar and determine the punishment in accordance with the implementation situation.

2. Measures Taken by Registrars
After the domain name registration becomes effective, the registrar shall conduct continuous review on the qualification of domain name applicant and the use condition of domain name in accordance with CONAC’s measures for domain name review. The registrar shall check that the registrant is the qualified holder of the domain name, and that the information is authentic and complete. When the check is successfully completed, the domain name may pass the CCM.

Follow-up handling measures include: 1) the domain name reviewed to be qualified will be continuously used; 2) in case of inconformity between the domain name holder and registration information, the registrar shall request that the domain name holder to submit valid documentary evidences within five (5) working days, otherwise the domain name will be suspended; 3) when the domain name holder requests to change domain name information, the same procedures of the PQP are applicable to the new information provided by the domain name holder so as to ensure that the changed domain name accords with CONAC’s registration policies.

29.2.3 Abuse Prevention Policies
CONAC will prevent and prohibit abuses to the greatest extent possible and to handle the abuse in a timely manner.

29.2.3.1 Measures to Prevent Abuses
1. PQP and Authentication Procedures
CONAC enforces PQP and authentication procedures to prevent abuses. Theoretically, by executing PQP and authentication procedures, CONAC is capable of preventing the abuses including cyber squatting, Front‐running, Gripe sites, deceptive and⁄or offensive domain names, Name spinning to the greatest extend. See Section 29.2.1 and 29.2.2 for more details of PQP and authentication procedures.

2. Notifications before Expiration
To prevent Fake renewal notices, CONAC requires the registrars to send domain name expiration notifications to registrants thirty (30) days and sixty (60) days in advance, to list all domain names that will expire in sixth (60) days on CONAC’s website, and to provide information in the WHOIS, including domain name expiring date.

3. Information Sharing with Anti-Abuse Communities
CONAC will coordinate closely with the anti-abuse communities to stay abreast of the latest trends in registration abuse, domain name abuse behavior and registrant protection measures, in a bid to protect legal rights of registrants. CONAC also shares anti-abuse information with registrars. See 28.5.5 for more details.

4. Annual Training
CONAC requires all registrars to participate in annual training courses, sharing experiences of anti-malicious behaviors, and improve registrars’ capability of fighting abuses. When submitting a domain name application, the registrars are required by CONAC to verify the identity of the registrant through PQP to mitigate abuses and protect the interests of the registrant.

29.2.3.2 Measures to Handle Abuses
CONAC has established a complete set of mechanisms to handle abuses, which cover regulating channels to detect abuses, establishing the AAWG, defining its role and working mechanism, specifying procedures and results for abuse handling. Since phishing, pharming and other malicious behavior belong to abuses, the working mechanism of the AAWG is applicable to phishing, pharming and other malicious behaviors as well as abusive behaviors. Please refer to 29.1.2.2 and 29.1.2.3 for detailed implementation measures.

In accordance with definitions of main types of abuses given by the Registration Abuse Policies Working Group (RAPWG), CONAC has developed specific measures and procedures to handle abuses in either a rapid or a normal handling process, See 28.5.2, 28.2.2, 28.5.3 and 28.5.4 for details.

The AAWG assesses the severity level of the abuse and decides whether the issue should proceed to the rapid or the normal handling process. This decision will be based on the way in which people are affected by the abuse and actual loss and damage brought about by the abuse. CONAC has regulated time limit for complaint acceptance and handling.

1. Ordinary Handling Process
CONAC’s abuse complaint process for normal cases sets out that the AAWG will notify the complainant whether the complaint is accepted within five (5) business days, and will handle the process to reach a decision within fifteen (15) business days.

When the complainant and the respondent agree with the decision of the Anti-Abuse Working Group, CONAC (or⁄and the domain name holder, registrar or other stakeholders) will execute the decision. The domain name with judged abuse will be taken down. After CONAC is delegated with”政務” TLD, such a take-down process shall apply to both the domain name and its preferred variant.

2. Rapid Handling Process

In case the AAWG finds that the abuse has clear facts and irrefutable evidence and cause serious consequences, especially the abuse identified by URS and Anti-Phishing Alliance of China (APAC) or a complaint concerning criminal acts, the AAWG will activate the rapid handling process and will deliver a decision within 48 hours.

The AAWG will activate the rapid handling process and will suspend the domain name within 48 hours (See Section 28.5.4 for details). When the working group receives a request from a judicial authority or law enforcement, it will launch a rapid handling process and give timely response and rapidly suspend the domain name concerned within 48 hours. Any abuse involving crime will be reported to judicial authority in a timely manner.

When CONAC is delegated with “.政務”, such suspension⁄takedown processes shall apply to both the domain name and its preferred variant.

29.2.4 Initiate Takedown Procedures
29.2.4.1 Conditions for takedown
CONAC initiates domain name takedown procedures in the following circumstances:
1) In accordance with PDDRP and RRDRP, ICANN imposes the remedies to delete registrations (when registrants have been shown to be officers, directors, agents, employees, or entities under common control with CONAC), and the party does not challenge the remedy or fails in challenging the remedy.
2) When a CONAC accredited dispute resolution institution affirms that a domain name registrations should be canceled, and the party does not lodge a complaint or initiate an arbitration, or loses a lawsuit⁄arbitration, or a final decision of cancelling domain name registration is made by court⁄arbitration institution.
3) When a domain name suspension is decided by the AAWG, with no appeal being lodged before the end of appeal period or appeal failure or a domain name abuse is finally affirmed by courts through judicial process.

29.2.4.2 Working Procedures for Takedown
CONAC offers “Takedown” in the SRS to takedown certain domain names. The domain name will be immediately removed from the “.政务” zone file. CONAC will notify the registrant according to the contact information included in the content registration form. The Registrar of record (as listed in the WHOIS) will be copied on this correspondence.

29.2.5 Dispute resolution Process for Complaints Concerning Compliance with Community Registration Policies
In accordance with Section 2.18 of the Registry Agreement, CONAC has developed the resolution procedures for disputes concerning compliance with TLD registration policies, and regulated the procedures in “the Dispute Resolution Policies for政务 Domain Names”, (the draft will be available at http:⁄⁄www.conac.cn before the TLD delegation). The procedures are listed below:

For disputes concerning compliance with TLD registration policies, the parties concerned may seek settlement through negotiation, or submit the case to the Domain Name Dispute Resolution Organization accredited by CONAC. This organization may institute legal proceedings with a competent people’s court in China, or submit the dispute for arbitration to an arbitral organization in China, if the parties have had an arbitration clause in the contract or have subsequently reached a written arbitration agreement.

If a party refuses to accept the decision of the Domain Name Dispute Resolution Organization accredited by CONAC, he shall have the right to institute legal proceedings with a competent people’s court in China, or submit the dispute for arbitration to an arbitral organ in China (if the parties have had an arbitration clause in the contract or have subsequently reached a written arbitration agreement) within 15 days since the receiving date of the decision. CONAC will implement the decision rendered by the court or arbitral organization.

If a decision made by a CONAC accredited Domain Name Dispute Resolution Organization is to delete or transfer domain name registrations, CONAC shall not implement the decision until 15 days after the receiving date of the decision. If a party against whom the enforcement is sought presents evidence which proves that the arbitral organ or the competent people’s court accept the case, CONAC shall rule to suspend the enforcement of the decision.

If the decision needs to be implemented by registrar, CONAC will also notify the registrar, and this will be specified in the Registry Registrar Agreement. CONAC will also designate a legal staff in charge of contacting with the relevant parties, and feedback the results of the implement to the relevant parties.

29.3 Resourcing Plan

In addition to the resource identified in the response to Question 28, CONAC will allocate 4 people in the positions of marketing and customer support. The resource is sufficient for the initial implementation and ongoing maintains. The detailed resource allocations are as follows:

1 Legal Affairs Staff (Legal Affairs role B: 1 Staff), responsible for communicating with service providers of PDDRP, RRDRP,URS as well as dispute resolution institutions accredited by CONAC, notifying the outcomes to relevant parties; and responding disputes regarding “.政务” domain names.

3 Customer Support Staff (Customer Support role D: 3 Staff), including the following three distinct positions:
1 staff is responsible for notifications regarding trademark claim services and sunrise services;
1 staff is responsible for initiating takedown procedure;
1 staff is responsible for distributing shared information to the anti-abuse community and carries out annual registrar trainings.

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in the response to Question 31.

Costs of resources allocation are detailed in costs and capital expenditure of Question 47a and 47b.

30 (a) Security Policy
Giving particular attention to the security of information and information systems, CONAC has developed comprehensive information security policy which is the guideline for secure operations of “.政务” TLD. CONAC’s security policies will be updated and improved to meet emerging security threats and changing conditions.

30.1 Independent Assessment Report of Security Performance
CONAC has established the quality and security management system in accordance with ISO 9001:2008 and ISO⁄IEC 27001:2005, and has obtained corresponding international certifications, which may be found at Table 1 of Q30(a)_attachment. CONAC internally assesses, and also engages third party risk assessment organization to assess the risks of “.政务” TLD registry system on a regular basis.

30.2 Security Level Commensurate with the Nature of the Applied-for gTLD String
30.2.1 Standard Compliance
CONAC commits to complying with the following standards.

1. International Standard for Quality Management
ISO 9001:2008 Quality management systems – Requirements

2. International Standards for Information Technology Service Management
ISO⁄IEC 20000-2:2005 Information technology - Service Management - Part 2: Code of practice
ISO⁄IEC TR 20000-3:2009 Information technology - Service Management - Part 3: Guidance on scope definition and applicability of ISO⁄IEC 20000-1
ISO⁄IEC TR 20000-5:2010 Information technology - Service management - Part 5: Exemplar implementation plan for ISO⁄IEC 20000-1

3. International Standards for Information Security Management Systems
ISO⁄IEC 27001:2005 Information technology - Information security management systems - Requirements
ISO⁄IEC 27002:2005 Information technology - Security techniques - Code of practice for information security management
ISO⁄IEC 27003:2010 Information technology - Security techniques - Information security management system implementation guidance
ISO⁄IEC 27004:2009 Information technology - Security techniques - Information security management – Measurement
ISO⁄IEC 27005:2008 Information technology - Security techniques - Information security risk management

4. National Standards or Specifications of the People’s Republic of China for the Classification of Security Protection Level of Computer Information System, Requirements on Each Security Level and Implementation Guides for Security Protection Level Related
GB 17859-1999 Classified criteria for security protection of computer information system
GB⁄T 22239-2008 Information security technology – Baseline for classified protection of information system security
GB⁄T 20269-2006 Information security technology - Information system security management requirements
GB⁄T 20270-2006 Information security technology - Basis security techniques requirement for network
GB⁄T 20271-2006 Information security technology - Common security techniques requirement for information system
GB⁄T 22240-2008 Information security technology - Information security technology - Classification guide for classified protection of information system security
GB⁄T 24363-2009 Information security technology - Specifications of emergency response plan for information security
GB⁄T 25058-2010 Information security technology - Implementation guide for classified protection of information system
GB⁄T 21052-2007 Information security technology - Physical security technical requirement for information system
GB⁄T 20984-2007 Information security technology - Risk assessment specification for information security
GB⁄Z 20985-2007 Information technology - Security techniques - Information security incident management guide
GB⁄Z 20986-2007 Information security technology - Guidelines for the category and classification of information security incidents

5. International Standards or National Standards of the People’s Republic of China for Security Protection of Domain Name System
IETF RFC6168 Requirements for management of name servers for the DNS
YD⁄T 2052-2009 Communication industry standard of the People’s Republic of China - Security protection requirements for the domain name system

6. Reference Website of the aforementioned Standards and Specifications
ISO series: http:⁄⁄www.iso.org;
National standard of the People’s Republic of China series: http:⁄⁄www.spc.net.cn;
Request for Comments (RFC): http:⁄⁄www.ietf.org;
Communication industry standard of the People’s Republic of China series and Guiding Technical Document for National Standard of the People’s Republic of China series: http:⁄⁄www.ccsa.org.cn

30.2.2 Description of the Standards Applied
CONAC mainly adopts two national standards, GB⁄T 22240-2008 and GB⁄T 22239-2008 for the classification of security protection levels of information and information system, and requirements on each security level. GB⁄T 22240-2008 stipulates that the security protection levels of the information system shall be classified on the basis of the degree of harm caused if the information system is damaged. There are five levels, Level 1 User Discretionary Security Protection, Level 2 System Auditing Protection, Level 3 Label Security Protection, Level 4 Structured Protection, and Level 5 Access Verification Security Protection. GB⁄T 22239-2008 stipulates a baseline for information system security commensurate with classified security protection levels. Until now, specific security requirements on Level 5 have not yet been released. Therefore, Level 4 is the highest level for information system security in actual use.

30.2.3 Security Demand of “.政务” TLD and Corresponding Security Levels
The applied for gTLD, “.政务” represents the Chinese Government Organization Community. All members of the community are established by the Chinese Constitution, organizational laws or governmental documents and carry out public powers. As a dedicated domain for the Chinese Government Organization Community, the “.政务” TLD will provide fast, reliable and round-the-clock E-government services to over 500 million current Chinese Internet users and more future users who have difficulty reading English. For details, please refer to the response to Question 20.

In light of the characteristics of the Chinese Government Organization Community, CONAC believes that, after identifying and analyzing security risks, if the registry system of “.政务” TLD is sabotaged, the social order and public interest will be gravely damaged, or national network security may be impaired. If the core data area of “.政务” TLD is sabotaged, the social order and public interest will be severely damaged, or even the national network security will be greatly impaired. Therefore, the security level for the whole registry system of “.政务” TLD is set to level 3 as defined in GB⁄T 22240-2008, and meets Basic Security Requirements on Level 3 as defined in GB⁄T 22239-2008; the security level for core data area of “.政务” TLD is set to level 4 as defined in GB⁄T 22240-2008, and meets Basic Security Requirements on Level 4 as defined in GB⁄T 22239-2008.

30.2.4 Security Benchmark Evaluation
CONAC actively carries out risk analysis and assessment, on the basis of the security protection level, security risk assessment, as well as disaster backup and recovery defined in international standards or national standards of the People’s Republic of China of information technology security. 

30.2.4.1 Risk Measurement Benchmark
The risk measurement is based on GB⁄T 20984-2007, ISO⁄IEC 27004:2009 and ISO⁄IEC27002:2005.

1. Confidentiality:
The financial value of confidentiality of one dataset is calculated by
(financial consequences due to loss of confidentiality in a typical incident)⁄( duration of a typical incident(in hours))

2. Availability:
The financial value of availability for one hour is calculated by
(financial consequences due to loss of availability in a typical incident)⁄( duration of a typical incident (in hours))

3. Integrity:
The financial value of integrity of one dataset is calculated by
(financial consequences due to loss of integrity in a typical incident)⁄( duration of a typical incident (in hours))

30.2.4.2 Definition of Vulnerability
As per the definition and requirements of vulnerability in GB⁄T 20984-2007 as well as vulnerability assessment methods defined in ISO⁄IEC 27005:2008, CONAC rates vulnerability levels as very high, high, medium, low and very low. Following international norm, vulnerability levels are rated on the basis of scanning results of Nessus software.

30.2.4.3 Risk Level Rating
As per the definition of risks and related requirements in GB⁄T 20984-2007, CONAC rates the risk level of the equipments. Equipment is distributed in the primary operations center, the backup operations center, Network Operations Center (NOC) and other resolution sites. The risk levels of the equipment are rated as very high, high, medium, low and very low on the basis of the loss caused by a failure and whether there is a backup. 

The overall rating is determined by summing up the risk level and vulnerability level. The overall rating is provided to the chief responsible person for the equipment. The chief responsible person will provide the correction response, further develop specific access control policy, preventative measures, monitoring and a continuous improvement plan, and provide guidance on daily operation and maintenance.

30.3 Security Level Commitments
Overall “.政务” registry system complies with Basic Security Requirement on Level 3 defined in GB⁄T 22239-2008, and the core data area complies with Basic Security Requirement on Level 4 defined in GB⁄T 22239-2008.

CONAC has issued the basic commitment of security level, Statement of Applicability (SOA), during which the applicability of all security controls is listed. For details about SOA, please refer to CONAC website www.conac.cn.

30.4 Security Capability
To meet ICANN requirements on security, CONAC has obtained ISO 9001:2008 and ISO⁄IEC 27001:2005 certification and established an information security protection system suitable for CONAC.

30.4.1 Information Security Management System 
As per GB⁄T 20269-2006 and ISO⁄IEC 27001:2005, CONAC puts in place its own Information Security Management System (ISMS) by establishing CONAC Overall Strategy for Quality and Security Management as well as CONAC Information and Technology Management Mechanism, which cover 11 aspects such as the security policy, information security organization, asset management, human resources security, physical and environmental security, communications and operations management, access control, information system acquisition, development and maintenance, information security incident management, business continuity management and compliance. In compliance with Plan-Do-Check-Act (PDCA) model, CONAC has established a series of regulations, specifications and processes for information security risk management to ensure the constant improvement of the information security management system. For details about PDCA, please refer to Figure 1 of Q30(a)_attachment.

30.4.2 Information Security Technology System
CONAC utilizes a “defense-in-depth model” to build a comprehensive information security technology system at physical, network, server, data, application and business service levels. See Figure 2 of Q30(a)_attachment for the in-depth defense hierarchy. CONAC takes appropriate defense measures at each level. Details are as follow.

1. At the physical level, CONAC takes the following measures.
1) Geographical diversity of IDC rooms;
2) Security requirements for IDC rooms, including (1) access card, and (2) fingerprint identification;
3) Security management for IDC rooms, including managing the entry and exit of equipment and visitors;
4) Power supply including (1) redundant power access, (2) providing Uninterrupted Power Supply (UPS), and (3) provision of electric generator.

2. At the network level, CONAC takes the following preventive measures.
1) Link redundancy and equipment redundancy;
2) Using firewall for access control;
3) DDoS prevention and traffic cleansing;
4) Configuring Intrusion Detection System ⁄Intrusion Prevention System (IDS) ⁄ (IPS);
5) Auditing the operation log of network devices;
6) Reasonable division of security zone;
7) Distributed deployment of multiple resolution sites;
8) Data are synchronized via VPN and monitoring information is transmitted via VPN;
9) Binding of IP address and media access control (MAC) at the network border of DNS;
10) Idle port disabled.

To detect problems, CONAC uses intrusion prevention and security auditing.

3. At the server level, CONAC takes the following preventive measures.
1) Servers use load balancing;
2) Anti-viruses;
3) Scanning for security loopholes of the servers;
4) Reinforcing the security configuration of the servers;
5) Identity authentication and access control;
6) Malicious code resistance;
7) Asset control including (1) asset management, (2) configuration management, (3) status record, and (4) archived file for equipment configuration;
8) Magnetic tape eraser is used to remove all information in the disused critical equipments so as to prevent vital information from disclose.

To detect problems, CONAC uses intrusion prevention and security auditing.

4. At data level, disaster recovery data backup is used, and anomalous traffic is monitored. 

5. At the application level, preventive security measures are adopted from the following aspects.
1) Secure management of application system development;
2) Deployment of firewalls at application layer;
3) Application security gateway;
4) Security of application code;
5) Security auditing;
6) Resolution sites are connected by dedicated line or VPN;
7) Resolution application uses F5 or Open Shortest Path First (OSPF) for load balancing;
8) Limiting concurrent connection number and maximum connection number;
9) Access control.

To detect problems, CONAC monitors application availability, Trojan horse, and application security.

6. At a business services level, business operation is standardized, and problems can be detected through continuous business monitoring and a business risk warning system.

7. From a human resources perspective, CONAC takes the following preventive measures.
1) Signing Employee Confidentiality Agreement and conducting background check prior to an employee starting work.
2) Leaving and transferring: special flows and record sheet will be used to ensure that related permissions are cancelled if the employee leaves or transfers from the current role.

8. From a security training perspective, CONAC takes the following measures.
1) Conducting annual information security awareness training;
2) ISO⁄IEC 27001:2005 training for the information security officer of each department (i.e. internal auditor);
3) Security technology training for security engineers by security service providers;
4) Security programming training to software engineers by security service providers;
5) Training on security device usage and basic security technology to software engineers by security engineers.

All security controls including security plans, security baselines and operation regulations are established in accordance with the characteristics of SRS, WHOIS, DNS, DNSSEC, data escrow, monitoring system, network and network management system, in a bid to guarantee the registry system of “.政务” TLD has security prevention capability, security monitoring capability, security response capability and security recovery capability.

1. Prevention capability
During the development of the security technology system, CONAC reinforces the development of technical capability and strategies for the access control protection, on the basis of the requirements on the access control strategy defined in GB⁄T 20270-2006. CONAC not only adopts security access control technologies, but also develops a series of access control regulations, processes and specifications. The access controls mainly include physical access control, network access control, operating system access control, application access control, user access control and external personnel access control.

2. Monitoring capability
At the security incident monitoring level, CONAC establishes the Network Operations Center (NOC), develops detailed monitoring and failure processing procedures, and has sound security monitoring system, on the basis of the requirements on detecting and reporting security incidents defined in GB⁄Z 20985-2007. CONAC monitoring system utilizes advanced network management software to provide 7X24X365 monitoring to SRS, WHOIS, DNS, DNSSEC, data escrow and other business systems so as to detect the failure and manage the failure in a timely manner. For details, please refer to section 42.2 of Question 42.

3. Incident response capability
On the basis of the requirements on security incident response defined in GB⁄Z 20985-2007, CONAC develops security incident reporting and handling management mechanisms, which specify the management responsibility of the security incident in the process of onsite handling, incident reporting and post recovery, identify the level of the computer security incidents according to the effect of the incident in the system, define the security incident reporting and response procedures, and determine the incident reporting flow, response and handling scope, extent and method. For details, please refer to section 42.3 of Question 42.

4. Emergency recovery capability
As per requirements on emergency plans for security defined in GB⁄T 24363-2009, CONAC develops a uniform framework under which the emergency response plans are made for different incidents. The framework for emergency response plan includes the condition of triggering the emergency plan, emergency response procedures, system recovery procedures, lessons drawn from the emergency, training, and regular walkthroughs.

In order to ensure the recovery of data and the entire system in a timely manner, in case of the failure of registry system, data loss or regional disasters (earthquake, fire, flood, war, etc.), CONAC establishes a series of backup and recovery management mechanisms, specifications and procedures, and requires to regularly execute the recovery procedure, checks and tests the effectiveness of the backup media to ensure the backup recovery can be completed in the time length specified by the recovery procedure. For details, please refer to the response to Question 39.

30.4.3 Information Security System for Operation and Maintenance
For system operation and maintenance, CONAC defines a series of secure operation and maintenance specifications including management in 5 major areas, IDC room, assets, network, systems and security, in accordance with GB⁄T 20269-2006, ISO⁄IEC TR 20000-5:2010 and ISO⁄IEC 27001:2005. The IDC room management includes the environment management and infrastructure management. The asset management includes the asset and medium management. The network management includes the network performance monitoring and security management. The system management includes the system performance monitoring and backup and recovery management. The security management includes the log auditing and analysis, malicious code prevention, security incident management and emergency response plan management. For the classification, associated mechanism, operation procedures, forms and records, and reports for operation and maintenance IDC room, asset, network, system and security management, please refer to Figure 3 of Q30(a)_attachment.

Baoguo Xie	Board Member
Hang Ruan	Board Member
Hong Xue	Board Member
Hualin Qian	Board Member
Ning Fu	Chairman of the Board
Qing Song	Vice-Chairman of the Board
Ran Zuo	Vice-Chairman of the Board
Rongmei Zhang	Board Member
Xiao Lin	Board Member
Ying Cui	Board Member
Yongge Sun	Board Member
Youkang Shi	Board Member
Zhi Xu	Board Member

Qing Song	CEO
Qiushi Ni	CTO
Rui Wang	COO
Xianqiang Tang	CFO

New gTLD Application Submitted to ICANN by: China Organizational Name Administration Center

String: 政务

Originally Posted: 13 June 2012

Application ID: 1-922-56316

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.