Back

24 Shared Registration System (SRS) Performance

gTLDFull Legal NameE-mail suffixDetail
.广东Guangzhou YU Wei Information Technology Co., Ltd.zodiac-corp.comView
24. SRS
The Applicant provides a Shared Registration System (SRS) that meet the requirements of Section 1.2, Specification 6 of the Registry Agreement to ʺ.STRINGʺ TLD. The SRS supports the registry-registrar seperation model adopted by ʺ.STRINGʺ and, by providing the registrar with an Extensible Provisioning Protocol (EPP) based data interface, enables the registrar to submit ʺ.STRINGʺ-related registration data to the Applicant.
The SRS of ʺ.STRINGʺ meets EPP1.0 data interface specifications defined by RFC 5730, and manages the database by using Oracle so that the reliability and stability of data storage and data access are guaranteed and registration operations can be accomplished properly and efficiently. At the same time, by adopting real-time monitoring and redundant system design and by taking such measures as 7*24 on-site operation and maintenance, SRS ensures the proper and reliable operations of SRS under the precondition of meeting SLR of Specification 10 of the Registry Agreement.
The Applicant selects the Back-End Service Provider to be the provider of technology and operation services for ʺ.STRINGʺ registry.
All human resources, funds and equipment necessary for implementing and maintaining SRS have been put in place by the applicant and the Back-End Service Provider seperately.
24.1 Implementation of SRS
24.1.1 An Overview of SRS
The SRS of ʺ.STRINGʺ consists of two parts: the core registration system and the Business Operation Support System (BOSS).
24.1.2 System Interfaces
SRS is connected to EPPClient, DNS service, the data escrow system, Whois service, the monitoring system and the TMCH. The interfaces between SRS and the above-mentioned systems are shown as follows.
Please see Figure 1 in the attachment of Q24_Attachment_Figure.
24.1.2.1 The Interface between SRS and EPPClient
Via an EPP1.0-compliant interface between EPPclient and SRS,ʺ.STRINGʺ provides registration services for registrars. In line with RFC 5734, the above interface is achieved based on Secure Sockets Layer (SSL) and TCP⁄IP. The functions of the interface include establishment of sessions, domain names, hosts and contacts with the registry of ʺ.STRINGʺ TLD (see the figure below).
Please see Figure 2 in the attachment of Q24_Attachment_Figure.
24.1.2.2 The Interface between SRS and DNS Service
The data needed for generating or updating zone files in DNS service comes from SRS registration database, as shown below.
Please see Figure 3 in the attachment of Q24_Attachment_Figure.
DNS service supports Authoritative Zone Transfer (AXFR) and Incremental Zone Transfer (IXFR).
The interface between AXFR and SRS is shown as follows:
Please see Figure 4 in the attachment of Q24_Attachment_Figure.
The interface between IXFR and SRS is shown as follows:
Please see Figure 5 in the attachment of Q24_Attachment_Figure.
24.1.2.3 The Interface between SRS and Data Escrow System
Data escrow system accesses the registration database via the interface, processes registration data, in accordance with Specification 2 of the Registry Agreement, and regularly upload them to the data escrow agent.
24.1.2.4 The Interface between SRS and Whois System
Whois system replicates the SRS registration database as Whois database and provides Internet users with Whois service. Whois system mainly uses the following 4 tables in the registration database.
Please see Figure 6 in the attachment of Q24_Attachment_Figure.
24.1.2.5 The Interface between SRS and the Monitoring System
There are three interfaces between SRS and the monitoring system. One is between EPPServer and the monitoring system; the other is between the registration database and the monitoring system; the third one is between BOSS and monitoring system.
24.1.2.6 The Interface between SRS and TMCH
BOSS is connected to TMCH, inquires about information of trade mark owners and decides whether to approve a specific domain name registration application according to the inquiry results.
24.1.3 Functions of SRS
The functions of SRS are divided into core registration function and business operation supporting function.
24.1.3.1 Core Registration Function
(1) Session Management
In accordance with RFC 5730, SRS implements commands of login, logout, hello and greeting. SRS supports the SSL-based connection with registrars over IPv6. Each registrar uses a different certificate.
(2) Asynchronous Message Management
After sending the poll command, SRS processes all pending actions and information related to the business auditing of ʺ.STRINGʺ.
(3) Management of Contacts
In accordance with RFC 5733, SRS implements commands of check, info, transfer, create, delete and update about contacts. Accredited registrars have the full authority to perform all the above commands about the contact of their domain names.
(4) Management of Hosts
In accordance with RFC 5732, SRS implements commands of check, info, create, delete and update about hosts.
(a) SRS supports management of IPv6 hosts.
(b) All accredited registrars have the full authority to perform all the above commands about hosts.
(5) Management of Domain Names
According to RFC 5731, SRS implements all commands for domain management, including check, info, create, delete, renew, transfer and update.
In accordance with RFC 3735, ʺ.STRINGʺ achieves EPP extension for traditional, simplified and variant Chinese domain names to support bundle registration of variant Chinese domain names. Moreover, EPP extension for DNSSEC is also implemented to support bulk registration of DS records. Refer to the answer to Question 25.
According to the definitions in RFC 3915 and RFC 5731, SRS saves and maintains the status of EPP and RGP.
(6) Operation Logs
SRS records, in the form of operation logs, all business operations performed by the registrar without any impact on SRS performance. The rollback file size and the number of backup files are preset for the log file of each registrar. Operation log will be pushed to the backup system periodically, please refer to the answer of Question 37. The monitoring system extracts the log for the use of data required by real-time business usability and monthly report.
(7) Automatic⁄Timed Tasks
SRS supports the following automatic⁄timed tasks:
(a) According to lifecycle requirements, SRS supports auto-renew function.
(b) SRS automatically permits transfer operations that exceed 5 days.
(c) In accordance with lifecycle requirements, SRS supports the function of automatically deleting expired domain names.
(d) When grace period expires, domain name status will be deleted automatically.
24.1.3.2 Business Operation Supporting Function
(1) Financial and Verification Function
The core registration system records operations about registration fees without settling the account. The BOSS financial module performs settlement of accounts according to the price offered by the registrar and informs the core registration system of the financial status of each registrar.
(2) Management of Reserved Name Lists
Boss provides the function of managing reserved name lists and maintains the reserved domain names and words in the registration database. Domain names and words that appear in the list are not permitted to register.
(3) Management of Registry Status
Due to specific reasons (legal arbitration for example), BOSS provides the function of creating or deleting Server status for the domain names, hosts and contacts stored in the registration database. Relevant operations must be approved before they are carried out.
(4) Management of Registrars
BOSS can insert, delete and update the information of registrars stored in the registration database, as well as allocate and manage registrar connections.
(5) Automatic⁄Timed Tasks
(a) In accordance with lifecycle requirements, BOSS supports the function of automatically updating the status of domain names and contacts.
(b) BOSS calculates registrarsʹ expenses on a daily basis.
(c) BOSS daily backs up the log into backup system.
(6) Bulk Registration Data Access
BOSS provides the function of bulk registration data access.
(a) Periodic Access to Light Registration Data
The Applicant entrusts the Back-End Service Provider to submit to ICANN, on a weekly basis, the up-to-date registration data, which include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
In line with the requirement of Specification 2 on data contents, the Back-End Service Provider provides the following data for all registered domain names. The data files will be compressed and encrypted to be available for download via SFTP.
(b) Exceptional Access to Heavy Registration Data
BOSS is capable of submitting to ICANN domain-related data by registrars in accordance with the requirement of Specification 2 on format. In case of registrar failure, de-accreditation, court order, etc, that prompts the temporary or definitive transfer of its domain names to another registrar, the Back-End Service Provider may submit to ICANN all the registered domain information of the losing registrar. The files containing the information are made available for download by SFTP.
(7) Sending a Query to TMCH
BOSS is connected to TMCH, inquireing about information of trade mark owners and decides whether to approve a specific domain name registration application according to the inquiry results. Some related functions will be improved according to the regulations of the global TMCH.
(8) Monthly Report Function
BOSS generates the monthly report compliant with Specification 3. The monitoring system collects the log of SRS system to analyze the data of the log to generate data required by Pre-Registrar Transactions Monthly Report and Registry Functions Activity Report. BOSS generates monthly reports and submits them periodically.
24.1.4 System Deployment
Please see Figure 7 in the attachment of Q24_Attachment_Figure.
(1) Internet Access
SRS service addresses broadcast SRS service addresses via Border Gateway Protocol (BGP). A registrar may access SRS service through a number of Internet Service Providers (ISPs).
(2) Load Balancer
Registrars access the virtual IP configured in the layer 4 load balancers to perform registration operations.
(3) SRS Servers
SRS servers are responsible for core registration and BOSS functions.
The core registration system and BOSS consist of 4 high-performance blade servers respectively. In addition, the core registration system and BOSS are equipped with a cold standby server respectively.
(4) Registration Database
The registration database is used to store registration data and respond to the access requests of the core registration system, BOSS, Whois, DNS service, data escrow and the access request for ICANN bulk registration data.
(5) BOSS Database
The BOSS database is used to store financial and verification data.
(6) Storage
The data in the registration database is stored in a storage device.
24.2 A Plan for Operating Robust and Reliable SRS
24.2.1 Redundant System Design
To improve reliability, a redundant design is adopted for designing the SRS architecture including network devices, load balancers, registration servers and registration databases, so as to ensure there is no single point of failure. In addition, cold-standby servers are always ready to take over the work of other servers.
Furthermore, both local and remote secondary operation centers adopt the same SRS deployment, to ensure that a swift switch over can be made when the primary operation center fails. Please refer to the answer to Question 37.  
24.2.2 Registration Data Synchronization
A storage device is connected to the registration database to store registration data. The replication between the primary operation center and the local secondary operation center are through optic fibers and uses synchronous replication to ensure data consistency. The storage devices of the primary operation center and the remote secondary operation center use asynchronous replication with a synchronization frequency of once every minute. For details, please refer to the answer to the Question 37.
24.2.3 Failure Monitoring and Handling
The monitoring system monitors the operations of SRS and the database. ʺ.STRINGʺ will be equiped with a special 7*24 team for system operation and maintenance, who monitors the SRS on 7*24 basis in a real-time manner. Once a problem is detected, the monitoring system will lose no time to give off an alarm and notify the 7*24 maintenance team to shoot and remove the trouble. Please refer to the answers to Questions 39 and 42 for information about the classification of and response to SRS failures.
24.3 Compliance Analysis
24.3.1 Compliance with Specification 6
(1) In accordance with RFC 5910, RFC 5730-5734, provisioning and management of domain names are achieved by using the EPP
ʺ.STRINGʺ achieves the extension of EPP for DNSSEC by extending RFC 5910. DS or DNSKEY records can be added to a designated domain name when it is updated and created, and relevant DS or DNSKEY data are contained in the response message of info command.
SRS fully meets the requirements of RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734. Refer to the answer to Question 25 for more details.
(2) Full compliance with the Registry Grace Period specified in RFC 3915
SRS strictly complies with the Registry Grace Period specified in RFC 3915. The RGP status of domain names is stored in the SRS registration database.
(3) Extension is made and the draft is submitted in accordance with RFC 3735
RFC 5731 has been extended in accordance with RFC 3735.
RFC 5910 has been extended in accordance with RFC 3735, which means the extension of DNSSEC, to support the bulk registration of DS and DNSKEY records.
Refer to the answer to Question 25.
24.3.2 Compliance with Specification 10
SRS service level requirements are specified in Specification 10 as follows:
Please see Table 1 in the attachment of Q24_Attachment_Table.
(1) Service Availability
It is estimated that based on 16 million registration volume, the ordinary peak Transactions Per Minute (TPM) is less than 15,000 (8,000 TPM for 95% cases), while it is less than 20,000 in the situation of cybersquatting (16,000 TPM for 95% cases). The Back-End Service Provider has tested single SRS server for 3*24 hours of which average TPM may reach 30,696.
(2) Session-command RTT
As shown in the following table for SRS testing for data volume of tens of millions, average Round-Trip Time (RTT) of each type of command is in compliance with Specification 10.
Please see Table 2 in the attachment of Q24_Attachment_Table.
(3) Query-command RTT
As shown in the following table for SRS testing for data volume of tens of millions, average RTT of EPP〈check〉 command is 9.06ms, and 16ms for 95% of this command.
Please see Table 3 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈info〉 command among query commands of ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 4 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈poll〉 command among query commands of ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 5 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈transfer〉 query command among query commands for ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 6 in the attachment of Q24_Attachment_Table.
(4) Transform-command RTT
System testing results of EPP〈create〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 7 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈delete〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 8 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈renew〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 9 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈transfer〉 command among transform commands are illustrated as below; as we can see, we respectively tested RTT for request, cancel, approve, reject commands as the ‘op’ value, which is compliant with Specification 10.
Please see Table 10 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈update〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 11 in the attachment of Q24_Attachment_Table.
24.4 Resource Allocation
24.4.1 Human Resources
To fulfill the service commitments concerning SRS of ʺ.STRINGʺ, the human resources provided by ʺ.STRINGʺ are as follows:
ʺ.STRINGʺ TLD registry adopts the human resources, which equips with 6 software engineers who are responsible for software optimization and maintenance, and 6 system administrators who are responsible for 7*24 monitoring. The Applicant will designate 2 technical personnel to communicate the technological issues of SRS with the Back-End Service Provider, and monitor the work of the Back-End Service Provider. Refer to the answer to Question 31.
24.4.2 Software and Hardware
ʺ.STRINGʺ registry adopts the software and hardware recources that are for ʺBack-End Registry Service Platformʺ use. Hardware and software resources deployed are as following:
Hardware in the 3 operation centers includes 30 high-performance blade servers, 12 high-performance database servers and 3 high-level storage devices.
Software includes SRS, database, database cluster and storage management software. The number of lines of effective codes of the SRS software is 60,816 with C++ output ratio of 1.19 (thousand code lines man-months). The number of lines of effective codes of the BOSS is 107,881 (java) with java output ratio of 2.18 (thousand code lines man-months). The total workload will be 101 man-months. So far development and testing of the software have been completed and the system is now in trial operation.
In addition, customization scope of SRS software covers core registration system and BOSS which supports financial and auditing, searching the trade mark clearing house (TMCH) and monthly report function, as well as the interface with EPPClient, DNS service, data escrow system, Whois system, monitoring system and TMCH; meanwhile it satisfies the SLA requirements. Software customization development is carried out according to the initiation of R&D, program plan, outline design, specific design, construction stage, trail stage and issue and summarization procedures. Development procedure is compliant with regulations of Level 3 of Capability Maturity Model Integration (CMMI3).
Refer to the answer to Question 32 for more details about the software and hardware.
24.4.3 Funds
To fulfill the service commitments on SRS of ʺ.STRINGʺ, the funds of human resources and outsourcing funds for technical platform of the Applicant have been put in place.Refer to the answer to Question 46 for the sources and uses of these funds. Funds for human resources, equipment procurement and maintenance of the Back-End Service Provider, the Applicantʹs entrusted party of technology and operation, have been put in place.

gTLDFull Legal NameE-mail suffixDetail
.广州Guangzhou YU Wei Information Technology Co., Ltd.zodiac-corp.comView
24. SRS
The Applicant provides a Shared Registration System (SRS) that meet the requirements of Section 1.2, Specification 6 of the Registry Agreement to ʺ.STRINGʺ TLD. The SRS supports the registry-registrar seperation model adopted by ʺ.STRINGʺ and, by providing the registrar with an Extensible Provisioning Protocol (EPP) based data interface, enables the registrar to submit ʺ.STRINGʺ-related registration data to the Applicant.
The SRS of ʺ.STRINGʺ meets EPP1.0 data interface specifications defined by RFC 5730, and manages the database by using Oracle so that the reliability and stability of data storage and data access are guaranteed and registration operations can be accomplished properly and efficiently. At the same time, by adopting real-time monitoring and redundant system design and by taking such measures as 7*24 on-site operation and maintenance, SRS ensures the proper and reliable operations of SRS under the precondition of meeting SLR of Specification 10 of the Registry Agreement.
The Applicant selects the Back-End Service Provider to be the provider of technology and operation services for ʺ.STRINGʺ registry.
All human resources, funds and equipment necessary for implementing and maintaining SRS have been put in place by the applicant and the Back-End Service Provider seperately.
24.1 Implementation of SRS
24.1.1 An Overview of SRS
The SRS of ʺ.STRINGʺ consists of two parts: the core registration system and the Business Operation Support System (BOSS).
24.1.2 System Interfaces
SRS is connected to EPPClient, DNS service, the data escrow system, Whois service, the monitoring system and the TMCH. The interfaces between SRS and the above-mentioned systems are shown as follows.
Please see Figure 1 in the attachment of Q24_Attachment_Figure.
24.1.2.1 The Interface between SRS and EPPClient
Via an EPP1.0-compliant interface between EPPclient and SRS,ʺ.STRINGʺ provides registration services for registrars. In line with RFC 5734, the above interface is achieved based on Secure Sockets Layer (SSL) and TCP⁄IP. The functions of the interface include establishment of sessions, domain names, hosts and contacts with the registry of ʺ.STRINGʺ TLD (see the figure below).
Please see Figure 2 in the attachment of Q24_Attachment_Figure.
24.1.2.2 The Interface between SRS and DNS Service
The data needed for generating or updating zone files in DNS service comes from SRS registration database, as shown below.
Please see Figure 3 in the attachment of Q24_Attachment_Figure.
DNS service supports Authoritative Zone Transfer (AXFR) and Incremental Zone Transfer (IXFR).
The interface between AXFR and SRS is shown as follows:
Please see Figure 4 in the attachment of Q24_Attachment_Figure.
The interface between IXFR and SRS is shown as follows:
Please see Figure 5 in the attachment of Q24_Attachment_Figure.
24.1.2.3 The Interface between SRS and Data Escrow System
Data escrow system accesses the registration database via the interface, processes registration data, in accordance with Specification 2 of the Registry Agreement, and regularly upload them to the data escrow agent.
24.1.2.4 The Interface between SRS and Whois System
Whois system replicates the SRS registration database as Whois database and provides Internet users with Whois service. Whois system mainly uses the following 4 tables in the registration database.
Please see Figure 6 in the attachment of Q24_Attachment_Figure.
24.1.2.5 The Interface between SRS and the Monitoring System
There are three interfaces between SRS and the monitoring system. One is between EPPServer and the monitoring system; the other is between the registration database and the monitoring system; the third one is between BOSS and monitoring system.
24.1.2.6 The Interface between SRS and TMCH
BOSS is connected to TMCH, inquires about information of trade mark owners and decides whether to approve a specific domain name registration application according to the inquiry results.
24.1.3 Functions of SRS
The functions of SRS are divided into core registration function and business operation supporting function.
24.1.3.1 Core Registration Function
(1) Session Management
In accordance with RFC 5730, SRS implements commands of login, logout, hello and greeting. SRS supports the SSL-based connection with registrars over IPv6. Each registrar uses a different certificate.
(2) Asynchronous Message Management
After sending the poll command, SRS processes all pending actions and information related to the business auditing of ʺ.STRINGʺ.
(3) Management of Contacts
In accordance with RFC 5733, SRS implements commands of check, info, transfer, create, delete and update about contacts. Accredited registrars have the full authority to perform all the above commands about the contact of their domain names.
(4) Management of Hosts
In accordance with RFC 5732, SRS implements commands of check, info, create, delete and update about hosts.
(a) SRS supports management of IPv6 hosts.
(b) All accredited registrars have the full authority to perform all the above commands about hosts.
(5) Management of Domain Names
According to RFC 5731, SRS implements all commands for domain management, including check, info, create, delete, renew, transfer and update.
In accordance with RFC 3735, ʺ.STRINGʺ achieves EPP extension for traditional, simplified and variant Chinese domain names to support bundle registration of variant Chinese domain names. Moreover, EPP extension for DNSSEC is also implemented to support bulk registration of DS records. Refer to the answer to Question 25.
According to the definitions in RFC 3915 and RFC 5731, SRS saves and maintains the status of EPP and RGP.
(6) Operation Logs
SRS records, in the form of operation logs, all business operations performed by the registrar without any impact on SRS performance. The rollback file size and the number of backup files are preset for the log file of each registrar. Operation log will be pushed to the backup system periodically, please refer to the answer of Question 37. The monitoring system extracts the log for the use of data required by real-time business usability and monthly report.
(7) Automatic⁄Timed Tasks
SRS supports the following automatic⁄timed tasks:
(a) According to lifecycle requirements, SRS supports auto-renew function.
(b) SRS automatically permits transfer operations that exceed 5 days.
(c) In accordance with lifecycle requirements, SRS supports the function of automatically deleting expired domain names.
(d) When grace period expires, domain name status will be deleted automatically.
24.1.3.2 Business Operation Supporting Function
(1) Financial and Verification Function
The core registration system records operations about registration fees without settling the account. The BOSS financial module performs settlement of accounts according to the price offered by the registrar and informs the core registration system of the financial status of each registrar.
(2) Management of Reserved Name Lists
Boss provides the function of managing reserved name lists and maintains the reserved domain names and words in the registration database. Domain names and words that appear in the list are not permitted to register.
(3) Management of Registry Status
Due to specific reasons (legal arbitration for example), BOSS provides the function of creating or deleting Server status for the domain names, hosts and contacts stored in the registration database. Relevant operations must be approved before they are carried out.
(4) Management of Registrars
BOSS can insert, delete and update the information of registrars stored in the registration database, as well as allocate and manage registrar connections.
(5) Automatic⁄Timed Tasks
(a) In accordance with lifecycle requirements, BOSS supports the function of automatically updating the status of domain names and contacts.
(b) BOSS calculates registrarsʹ expenses on a daily basis.
(c) BOSS daily backs up the log into backup system.
(6) Bulk Registration Data Access
BOSS provides the function of bulk registration data access.
(a) Periodic Access to Light Registration Data
The Applicant entrusts the Back-End Service Provider to submit to ICANN, on a weekly basis, the up-to-date registration data, which include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
In line with the requirement of Specification 2 on data contents, the Back-End Service Provider provides the following data for all registered domain names. The data files will be compressed and encrypted to be available for download via SFTP.
(b) Exceptional Access to Heavy Registration Data
BOSS is capable of submitting to ICANN domain-related data by registrars in accordance with the requirement of Specification 2 on format. In case of registrar failure, de-accreditation, court order, etc, that prompts the temporary or definitive transfer of its domain names to another registrar, the Back-End Service Provider may submit to ICANN all the registered domain information of the losing registrar. The files containing the information are made available for download by SFTP.
(7) Sending a Query to TMCH
BOSS is connected to TMCH, inquireing about information of trade mark owners and decides whether to approve a specific domain name registration application according to the inquiry results. Some related functions will be improved according to the regulations of the global TMCH.
(8) Monthly Report Function
BOSS generates the monthly report compliant with Specification 3. The monitoring system collects the log of SRS system to analyze the data of the log to generate data required by Pre-Registrar Transactions Monthly Report and Registry Functions Activity Report. BOSS generates monthly reports and submits them periodically.
24.1.4 System Deployment
Please see Figure 7 in the attachment of Q24_Attachment_Figure.
(1) Internet Access
SRS service addresses broadcast SRS service addresses via Border Gateway Protocol (BGP). A registrar may access SRS service through a number of Internet Service Providers (ISPs).
(2) Load Balancer
Registrars access the virtual IP configured in the layer 4 load balancers to perform registration operations.
(3) SRS Servers
SRS servers are responsible for core registration and BOSS functions.
The core registration system and BOSS consist of 4 high-performance blade servers respectively. In addition, the core registration system and BOSS are equipped with a cold standby server respectively.
(4) Registration Database
The registration database is used to store registration data and respond to the access requests of the core registration system, BOSS, Whois, DNS service, data escrow and the access request for ICANN bulk registration data.
(5) BOSS Database
The BOSS database is used to store financial and verification data.
(6) Storage
The data in the registration database is stored in a storage device.
24.2 A Plan for Operating Robust and Reliable SRS
24.2.1 Redundant System Design
To improve reliability, a redundant design is adopted for designing the SRS architecture including network devices, load balancers, registration servers and registration databases, so as to ensure there is no single point of failure. In addition, cold-standby servers are always ready to take over the work of other servers.
Furthermore, both local and remote secondary operation centers adopt the same SRS deployment, to ensure that a swift switch over can be made when the primary operation center fails. Please refer to the answer to Question 37.  
24.2.2 Registration Data Synchronization
A storage device is connected to the registration database to store registration data. The replication between the primary operation center and the local secondary operation center are through optic fibers and uses synchronous replication to ensure data consistency. The storage devices of the primary operation center and the remote secondary operation center use asynchronous replication with a synchronization frequency of once every minute. For details, please refer to the answer to the Question 37.
24.2.3 Failure Monitoring and Handling
The monitoring system monitors the operations of SRS and the database. ʺ.STRINGʺ will be equiped with a special 7*24 team for system operation and maintenance, who monitors the SRS on 7*24 basis in a real-time manner. Once a problem is detected, the monitoring system will lose no time to give off an alarm and notify the 7*24 maintenance team to shoot and remove the trouble. Please refer to the answers to Questions 39 and 42 for information about the classification of and response to SRS failures.
24.3 Compliance Analysis
24.3.1 Compliance with Specification 6
(1) In accordance with RFC 5910, RFC 5730-5734, provisioning and management of domain names are achieved by using the EPP
ʺ.STRINGʺ achieves the extension of EPP for DNSSEC by extending RFC 5910. DS or DNSKEY records can be added to a designated domain name when it is updated and created, and relevant DS or DNSKEY data are contained in the response message of info command.
SRS fully meets the requirements of RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 5734. Refer to the answer to Question 25 for more details.
(2) Full compliance with the Registry Grace Period specified in RFC 3915
SRS strictly complies with the Registry Grace Period specified in RFC 3915. The RGP status of domain names is stored in the SRS registration database.
(3) Extension is made and the draft is submitted in accordance with RFC 3735
RFC 5731 has been extended in accordance with RFC 3735.
RFC 5910 has been extended in accordance with RFC 3735, which means the extension of DNSSEC, to support the bulk registration of DS and DNSKEY records.
Refer to the answer to Question 25.
24.3.2 Compliance with Specification 10
SRS service level requirements are specified in Specification 10 as follows:
Please see Table 1 in the attachment of Q24_Attachment_Table.
(1) Service Availability
It is estimated that based on 16 million registration volume, the ordinary peak Transactions Per Minute (TPM) is less than 15,000 (8,000 TPM for 95% cases), while it is less than 20,000 in the situation of cybersquatting (16,000 TPM for 95% cases). The Back-End Service Provider has tested single SRS server for 3*24 hours of which average TPM may reach 30,696.
(2) Session-command RTT
As shown in the following table for SRS testing for data volume of tens of millions, average Round-Trip Time (RTT) of each type of command is in compliance with Specification 10.
Please see Table 2 in the attachment of Q24_Attachment_Table.
(3) Query-command RTT
As shown in the following table for SRS testing for data volume of tens of millions, average RTT of EPP〈check〉 command is 9.06ms, and 16ms for 95% of this command.
Please see Table 3 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈info〉 command among query commands of ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 4 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈poll〉 command among query commands of ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 5 in the attachment of Q24_Attachment_Table.
System testing result of EPP〈transfer〉 query command among query commands for ten million level data volume is illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 6 in the attachment of Q24_Attachment_Table.
(4) Transform-command RTT
System testing results of EPP〈create〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 7 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈delete〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 8 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈renew〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 9 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈transfer〉 command among transform commands are illustrated as below; as we can see, we respectively tested RTT for request, cancel, approve, reject commands as the ‘op’ value, which is compliant with Specification 10.
Please see Table 10 in the attachment of Q24_Attachment_Table.
System testing results of EPP〈update〉 command among transform commands are illustrated as below; as we can see, RTT is compliant with Specification 10.
Please see Table 11 in the attachment of Q24_Attachment_Table.
24.4 Resource Allocation
24.4.1 Human Resources
To fulfill the service commitments concerning SRS of ʺ.STRINGʺ, the human resources provided by ʺ.STRINGʺ are as follows:
ʺ.STRINGʺ TLD registry adopts the human resources, which equips with 6 software engineers who are responsible for software optimization and maintenance, and 6 system administrators who are responsible for 7*24 monitoring. The Applicant will designate 2 technical personnel to communicate the technological issues of SRS with the Back-End Service Provider, and monitor the work of the Back-End Service Provider. Refer to the answer to Question 31.
24.4.2 Software and Hardware
ʺ.STRINGʺ registry adopts the software and hardware recources that are for ʺBack-End Registry Service Platformʺ use. Hardware and software resources deployed are as following:
Hardware in the 3 operation centers includes 30 high-performance blade servers, 12 high-performance database servers and 3 high-level storage devices.
Software includes SRS, database, database cluster and storage management software. The number of lines of effective codes of the SRS software is 60,816 with C++ output ratio of 1.19 (thousand code lines man-months). The number of lines of effective codes of the BOSS is 107,881 (java) with java output ratio of 2.18 (thousand code lines man-months). The total workload will be 101 man-months. So far development and testing of the software have been completed and the system is now in trial operation.
In addition, customization scope of SRS software covers core registration system and BOSS which supports financial and auditing, searching the trade mark clearing house (TMCH) and monthly report function, as well as the interface with EPPClient, DNS service, data escrow system, Whois system, monitoring system and TMCH; meanwhile it satisfies the SLA requirements. Software customization development is carried out according to the initiation of R&D, program plan, outline design, specific design, construction stage, trail stage and issue and summarization procedures. Development procedure is compliant with regulations of Level 3 of Capability Maturity Model Integration (CMMI3).
Refer to the answer to Question 32 for more details about the software and hardware.
24.4.3 Funds
To fulfill the service commitments on SRS of ʺ.STRINGʺ, the funds of human resources and outsourcing funds for technical platform of the Applicant have been put in place.Refer to the answer to Question 46 for the sources and uses of these funds. Funds for human resources, equipment procurement and maintenance of the Back-End Service Provider, the Applicantʹs entrusted party of technology and operation, have been put in place.