Applicant Information

Does or will this RSP have a publicly verifiable, 3rd party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Does or will this RSP implement BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance’s Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies?

Yes

Does or will this RSP implement RFC 5730 (“Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP implement RFC 5731 (“Extensible Provisioning Protocol (EPP) Domain Name Mapping”)?

Yes

Does or will this RSP implement RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)?

Yes

Does or will this RSP implement RFC 5910 (“Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 5732 (“Extensible Provisioning Protocol (EPP) Host Mapping”)?

Yes

If applicable, does or will this RSP implement RFC 5733 (“Extensible Provisioning Protocol (EPP) Contact Mapping”)?

Yes

If applicable, does or will this RSP implement RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”) is not applicable to this RSP, describe the mechanism to support sunrise and claims in EPP. Please answer with “Not Applicable” or “N/A” if this RSP does or will implement RFC 8334.

N/A

If applicable, does or will this RSP implement RFC 8748 (“Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”)?

Yes

Provide a list of all EPP extensions to be used that are registered in the IANA EPP extensions registry, and an attestation that all EPP extensions to be used are registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”).

EPP Extensions: The EPP system has implemented multiple extensions registered in the IANA EPP Extensions Registry. The following is a list of EPP extensions used and their registration information: 1.DNS Security Extensions Mapping (DNSSEC) Registered Name: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) Reference Document: RFC 5910 Status: Active Registration Status: Officially registered with IANA Purpose: We use this extension to implement management of domain name DNSSEC security records, supporting creation and management of DS records and key data. 2.Domain Registry Grace Period Mapping (RGP) Registered Name: Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) Reference Document: RFC 3915 Status: Active Registration Status: Officially registered with IANA Purpose: Provides a grace period function after domain name deletion, allowing registrars to restore deleted domain names within a specific time. 3. Registry Fee Extension (Fee) Registration Name: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Reference Document: RFC 8748 Status: Active Registration Status: IANA Officially Registered Purpose: Allows registrars to query relevant fee information before domain name operations, especially for premium domain names and special operation fee notifications. 4.Launch Phase Mapping (Launch Phase) Registration Name: Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Reference Document: RFC 8334 Status: Active Registration Status: IANA Officially Registered Purpose: Supports special registration process management for new top-level domains (TLDs) during different launch phases (e.g., Sunrise and Declaration Periods). 5.Verification Code Extension (VerificationCode) Registration Name: Verification Code Extension for the Extensible Provisioning Protocol (EPP) Reference Document: draft-ietf-regext-verificationcode-06 Status: Active Registration Status: IANA Officially Registered Purpose: Implements a verification code management mechanism for domain name and registrant identity verification. 6.IDN Language Tag Extension (IDN Language Tag) Registration Name: IDN Language Tag for the Extensible Provisioning Protocol (EPP) Status: Active Registration Status: IANA Officially Registered Purpose: This extension enables the language tag function for Internationalized Domain Names (IDN), allowing the specification of corresponding language codes for multilingual domain names to ensure correct display and processing. It is particularly important for supporting non-ASCII character domains like Chinese domain names, correctly handling domain name representation conversion and validation, including Unicode to Punycode conversion, and ensuring domain names comply with registration rules and policies of respective languages. All EPP extensions used by us are officially registered with IANA in accordance with RFC 7451 ("Extensible Provisioning Protocol Extension Registry"). These extensions fully comply with the EPP protocol specification (RFC 5730) and EPP extension guidelines (RFC 3735). Our EPP implementation strictly adheres to these standard extensions, ensuring maximum compatibility with standard EPP clients while providing registrars with rich enhanced functions, including DNSSEC security support, fee transparency, domain name lifecycle management, and special requirements for TLD launch phases. As a registry service provider, we are committed to using standardized and interoperable EPP extensions to ensure registrars can manage domain names in a consistent and predictable manner.

Does or will this RSP forgo the use of any EPP extensions which are not registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”)?

Yes

Does or will this RSP implement and operate EPP according to the performance requirements defined in the standards established in Specification 10 of the ICANN Registry Agreement (version)?

Yes

Does or will this RSP have controls to prevent EPP misuse and ensure all registrars have fair and equal access to EPP per the standards established in Specification 9 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) notwithstanding RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure EPP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure EPP communication in accordance with industry best common practices?

Yes

Does or will this RSP the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to EPP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the EPP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to EPP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP implement RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 7481 (“Security Services for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 9082 (“Registration Data Access Protocol (RDAP) Query Format”)?

Yes

Does or will this RSP implement RFC 9083 (“JSON Responses for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Technical Implementation Guide?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Response Profile?

Yes

Provide a list of all RDAP extensions to be used.

The extended list used by our company's RDAP service is as follows: 1.Reverse Query of RFC 9536: RDAP itself does not have a query function to find associated domain names through entity information. The reverse search extension defined in RFC 9536 allows servers to provide reverse search functionality based on the relationships between object classes in RDAP. For example, it can find the list of relevant domain names based on contacts or name servers. 2.RDAP Extension for RFC 9537: Specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. 3.RDAP Response Profile released by ICANN in 2024: icann_rdap_response_profile_1 4.RDAP Technical Implementation Guide released by ICANN in 2024: icann_rdap_technical_implementation_guide_1 Object Tag Extension defined in RFC 8521: The extension identifier is "rdap_object_tag", which describes a best practice for constructing entity identifiers to achieve query guidance.

Does or will this RSP forgo the use of any RDAP extensions which are not registered with the IANA as per RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements defined in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP?

Yes

Does or will this RSP implement methods to prevent mining of registration data via RDAP?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) with respect to RDAP?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure RDAP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure RDAP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to RDAP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the RDAP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to RDAP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv6?

Yes

Will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv6 if requested by a registrar?

Yes

Describe all potential registration lifecycle(s) of domain names supported in the system.

The domain name registration lifecycle refers to the complete process from domain name registration, management, to expiration or deletion, with different stages corresponding to various statuses and operations. Below are the potential domain name registration lifecycle stages supported by the system and related descriptions: 1.Pre-Registration: Users submit registration applications before a domain name is officially open for registration (e.g., for domains approaching expiration or newly opened for registration). It supports "cybersquatting‘’or "reservation"mechanisms. The system processes applications according to rules (such as first-come-first-served or auction). Status value: Pending Pre-Registration: Application submitted, waiting for registry processing. 2.Registration Application: After a domain name is officially open for registration, users submit registration requests, and the system initiates real-time applications to the registry. This requires completing domain name information (WHOIS), real-name authentication, and payment. Status values: PendingCreate: Registration request submitted, waiting for registry confirmation. ServerCreateProhibited: Registry rejects creation (e.g., policy violation). 3.Registration Success (Active): The domain name is successfully registered and in an effective status, with users holding domain control. DNS configuration, resolution management, adding subdomains, etc., can be performed. Status value: Active: Normal active status, domain name available. 4.Registration Management: Daily maintenance during domain name registration, including information changes, status adjustments, permission management, etc. Related status values: ServerTransferProhibited: Registrar prohibits transfer (needs restriction release). ClientTransferProhibited: User account prohibits transfer (e.g., due to arrears, unvalidated). Locked/Unlocked: Domain name lock/unlock status (prevents unauthorized modification or transfer). 5. Renewal: When a domain name approaches expiration, users need to renew to extend validity. The auto-renewal function avoids domain expiration due to forgetfulness. Status values: PendingRenew: Renewal request submitted, waiting for registry confirmation. Auto-Renew Prohibited: Auto-renewal function disabled (needs manual activation). 6. Expiration and Redemption: 6.1 Grace Period: After domain expiration, it enters the grace period (typically 30 days), during which renewal can still restore use. Status value: Expired: Domain name expired but still in grace period. 6.2 Redemption Period: After the grace period ends, the domain name enters the redemption period (typically 30 days), requiring a higher redemption fee for restoration. Status value: Redemption Period: Domain name in redemption period, only restorable via redemption. 6.3 Pending Delete: After the redemption period ends, the domain name enters the deletion queue, waiting for registry release. Status value: Pending Delete: Domain name will be deleted, non-restorable. 7. Registration Deletion (Deleted): The domain name is permanently deleted from the registration database and released for public reregistration. It can be reapplied for through a cyber squatting mechanism (depending on registry rules). Status value: Deleted: Domain name deleted, status non-restorable. 8. Special Statuses: 8.1 Suspended: The domain name is suspended from resolution by the registry or registrar due to violations (e.g., abuse, infringement) or policy reasons. Status values: ServerHold: Registry suspends the domain (e.g., incomplete real-name authentication). ClientHold: Registrar suspends the domain (user violation or arrears). 8.2 Dispute Handling: The domain name enters arbitration or legal proceedings due to intellectual property disputes. Status value: Pending Legal: Domain name in legal dispute status, operations restricted.

Describe the registration lifecycle(s) of domain names with respect to EPP status values and RDAP status values.

I. EPP Status Values Related to the Domain Name Lifecycle 1.Pre-Registration and Registration Application Phase addPeriod: The initial phase after the successful registration of a domain name, usually a short period of time after registration, which does not affect normal use. pendingCreate: The domain name registration request has been submitted, but the entire registration process has not been completed. inactive: The domain name is newly registered but has not been officially activated. 2.Successful Registration and Usage Phase ok: The domain name can be used normally and can undergo operations such as update, renewal, deletion, and transfer. 3.Registration Management and Change Phase pendingTransfer: The domain name transfer request has been submitted and is awaiting review and processing by the original registrar, new registrar, or registry. ServerTransferProhibited, clientTransferProhibited: Prohibit domain name transfer, usually used during dispute handling or compliance review phases. ServerDeleteProhibited, clientDeleteProhibited: Prohibit domain name deletion, usually used as a protective measure when there are disputes or violations related to the domain name. serverRenewProhibited, clientRenewProhibited: Prohibit the renewal operation of the domain name, which may be caused by domain name violations or legal issues. ServerUpdateProhibited, clientUpdateProhibited: Prohibit modification of domain name information, which may be caused by abnormalities in the domain name or unapproved review. pendingUpdate: The request for modifying domain name information (such as contact person, DNS, etc.) has been submitted and is awaiting processing. transferPeriod: The statutory or agreed time period required for the domain name to complete the transfer between registrars/registry operators. 4.Renewal and Expiration Phase autoRenewPeriod: The phase during which the domain name enters the automatic renewal process, usually before or after expiration, when the registrar will automatically renew the domain name. pendingRenew: The domain name renewal request has been submitted, but the renewal process has not been completed. renewPeriod: The normal renewal window before and after the domain name expires, during which the domain name ownership can be extended through the regular renewal process. 5.Special Status and Dispute Handling Phase ServerHold, clientHold: A status set by the registrar or registry, which renders the domain name unable to be resolved normally. It is usually used as a mandatory measure when the domain name violates regulations, fails to complete filing, or due to legal requirements. 6.Deletion and Release Phase pendingDelete: The domain name deletion request has been submitted and is in the phase of waiting for final deletion. pendingRestore: The owner has submitted a restoration request, which is awaiting processing for restoration. redemptionPeriod: A recovery period from the deletion of the domain name to its complete cancellation, during which the owner can pay a redemption fee to restore the domain name. II. RDAP Status Values Related to the Domain Name Lifecycle 1.Pre-Registration and Registration Application Phase add period pending create inactive 2.Successful Registration and Usage Phase active 3.Registration Management and Change Phase pending transfer server transfer prohibited, client transfer prohibited server delete prohibited, client delete prohibited server renew prohibited, client renew prohibited server update prohibited, client update prohibited pending update transfer period 4.Renewal and Expiration Phase auto renew period pending renew renew period 5.Special Status and Dispute Handling Phase server hold, client hold 6.Deletion and Release Phase pending delete pending restore redemption period Please find the details attached.

Describe the nameserver host lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names. This should include a description of nameservers as either attributes of domains or as host objects.

I. The Lifecycle of a Name Server (NS) The lifecycle of a Name Server includes the creation, update, transfer, and deletion phases. The EPP and RDAP status values related to the NS lifecycle are as follows: 1. Creation Phase EPP status values: pendingCreate, ok RDAP status values: pending create, active 2. Update Phase EPP status values: pendingUpdate, linked, clientDeleteProhibited, serverDeleteProhibited, clientUpdateProhibited, serverUpdateProhibited RDAP status values: pending update, associated, client delete prohibited, server delete prohibited, client update prohibited, server update prohibited 3. Transfer Phase EPP status value: pendingTransfer RDAP status value: pending transfer 4. Deletion Phase EPP status value: pendingDelete RDAP status value: pending delete II. NS Roles in Our System Based on the relationship between hosts and the registry, they are classified into internal hosts and external hosts. Within our system, Name Servers (NS) are supported as independently operating host objects. A host operated by a registrar that has configuration permissions for a Top-Level Domain (TLD) is defined as an internal host; those that do not meet this criterion are external hosts. When creating an internal host, it must include the host's IP addresses, supporting both IPv4 and IPv6 formats. Additionally, the parent domain of the internal host cannot be in any pending state during creation. Upon successful creation, the host status is set to ok, and users are allowed to modify the host's client-side status. A host can be deleted if it is not referenced by any domain and has no status restrictions. When a domain is deleted, all internal hosts using that domain as their parent domain must be deleted concurrently. The host status is displayed in RDDS (Registry Data Distribution Service) host queries. Key Rules for Host Status Prefixes: 1. For host statuses set by the client-side, the prefix "client:" must be added before the status value (e.g., client:hold). 2. For host statuses set by the server-side, the prefix "server:" must be added before the status value (e.g., server:locked). 3. If no prefix is specified for a status value, it is deemed managed by the server-side, and the client cannot directly modify it via the Update command. Modification Permissions: - Statuses set by the server-side cannot be modified by the client. - Statuses set by the client-side can be modified by both the server and the client in accordance with relevant policy constraints. The coexistence and mutual exclusion relationships of each host status value are as follows: ★ The "ok" status can only coexist with the "linked" status. ★ "pendingDelete" is mutually exclusive with "clientDeleteProhibited" and "serverDeleteProhibited". ★ "pendingUpdate" is mutually exclusive with "clientUpdateProhibited" and "serverUpdateProhibited". ★ All pending statuses are mutually exclusive (pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate).

If applicable, describe the contact lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names and nameservers. Include a description of the deletion of orphaned contacts.

The updated response to this issue is as follows: EPP and RDAP Status Values Related to the Contact Lifecycle 1.Creation Phase: Contact information is first entered into the registrar's system or the registry's database. EPP Status: May be pendingCreate, ok, indicating that it is being created or is valid and available. RDAP Status: May be pending create, active, indicating that it is being created or is valid and available. 2.Update Phase: When contact information is changed, a modification request is submitted through the registrar/registry. The registrar/registry sets prohibited statuses according to business needs. EPP Status: May be pendingUpdate, linked, clientDeleteProhibited, serverDeleteProhibited, clientTransferProhibited, serverTransferProhibited, clientUpdateProhibited, serverUpdateProhibited. RDAP Status: May be pending update, associated, client delete prohibited, server delete prohibited, client transfer prohibited, server transfer prohibited, client update prohibited, server update prohibited. 3.Transfer Phase: The contact is transferred to another registrar. EPP Status: May be pendingTransfer. RDAP Status: May be pending transfer. 4.Deletion Phase 4.1 Normal Deletion: If the contact is no longer associated with any domain name or name server, and there are no restrictions on the deletion operation, the contact can be deleted. EPP Status: May be pendingDelete. RDAP Status: May become pending delete. 4.2 Deletion of Orphaned Contacts: Orphaned contacts refer to those contacts that are no longer associated with any domain name. Since contact information is closely related to domain names, orphaned contacts may be generated after a domain name is deleted or transferred to another registrar. For the deletion of orphaned contacts, registrars usually have certain policies (such as prohibiting the deletion of certain contacts). EPP Status: May be clientDeleteProhibited, serverDeleteProhibited, pendingDelete. RDAP Status: May be client delete prohibited, server delete prohibited, pending delete.

Does or will this RSP be capable of removing orphaned glue in accordance with the standards established in Specification 6 of the ICANN Registry Agreement (version 2024)?

Yes

Describe how this RSP will meet the standards established in Specification 2 of the ICANN Registry Agreement (version 2024), and describe any other data escrow processes. This includes escrow extensions for data related additional registry services.

ICANN Registry Agreement (2024 Edition) Specification 2 mainly relates to data escrow requirements. Below are the ways the RSP meets this specification's standards, along with related data escrow processes and escrow extensions: I. Methods to Meet Specification 2 Standards 1.Select ICANN-Approved Data Escrow Agent (DEA): The RSP must choose a partner from ICANN's approved DEA list to ensure data escrow services comply with ICANN's legal, technical, and security guarantees. 2.Data Receipt and Transmission: The RSP must submit full escrow data to the DEA before 23:59 (UTC) every Sunday and differential escrow data before 23:59 (UTC) from Monday to Saturday. Data can be uploaded via SFTP, SCP, HTTPS, or delivered physically via CD-ROM, DVD-ROM, or USB storage devices with ICANN authorization. 3.Data Verification and Storage: The DEA verifies received escrow data within 24 hours and submits a verification report copy to ICANN. For unvalidated files, the DEA notifies the RSP within 24 hours of receipt. The DEA is responsible for storing validated data files and retaining and protecting each escrow data for one year. 4.Data Transfer: When receiving notifications from ICANN or the RSP, the DEA must provide electronic download methods for escrow data to ICANN or specified third parties within 24 hours (unless otherwise required), and the data receiving system must verify data correctness and integrity through scripts provided by ICANN. II. Other Data Escrow Processes 1.DEA Change Process: If the RSP wishes to change DEA, it must select an incoming DEA from ICANN's approved list, submit a completed change request form to ICANN, and contact the incoming DEA to implement the Registry Data Escrow Agreement (RDEA). After the first successful full data escrow to the incoming DEA, notify ICANN. Upon ICANN confirmation, send a handover notice to all relevant parties and stop escrowing data to the original DEA. III. Escrow Extensions for Other Registry Services Related to Data 1.Registration Data Access Protocol (RDAP) Services: As required, the RSP may need to cooperate in implementing RDAP services, including formulating RDAP overviews, Service Level Agreements (SLAs), and registry reporting regulations, to provide more standardized registration data access services, ensuring accurate and timely querying and use of registration data. 2.Data Security and Privacy Protection Extensions: With increasing data security and privacy protection requirements, the RSP may need to adopt more security measures during data escrow, such as strengthening data encryption, access control, security auditing, etc., to protect registration data security and privacy, preventing data leakage and abuse. It may also need to follow stricter privacy policies and regulations to standardize personal data processing and use. 3.Data Backup and Recovery Extensions: To address potential data loss, corruption, or other disasters, the RSP may extend data backup and recovery services, including establishing regular backup strategies, backing up data to multiple different storage locations, and ensuring fast and effective data recovery in emergencies to guarantee registry service continuity and stability.

Does or will this RSP regularly exercise registry continuity actions?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the Registry Agreement (version 2024).

According to the definition in ICANN Registry Agreement (2024 Edition) Specification 10, service disruptions typically refer to unavailability of critical functions provided by the registry (e.g., DNS resolution, registration data access, DNSSEC management, etc.). Below is organized information on gTLD service disruptions: 1.Functions Currently Provided by gTLDs: Registries (e.g., Verisign, Donuts, etc.) provide the following core functions for gTLDs: DNS resolution services: Ensure global domain name resolution. Registration data management: Maintain WHOIS/RDAP data for public querying. DNSSEC support: Provide Domain Name System Security Extensions. EPP (Registrar Protocol) services: Support domain name registration, renewal, transfer, etc. Data escrow: Regularly back up registration data to independent third parties as required by Specification 2. 2.No service disruption records in the past six months.