Applicant Information

Does or will this RSP have a publicly verifiable, third-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

Describe the processes and procedures to be used to practice and ensure a successful KSK rollover for both emergency and non-emergency situations, including coordination with the DNSSEC RSP and IANA.

(I) KSK Rotation Process in Non-emergency Situations 1.Pre-planning and Preparation 2.New KSK Generation 3.Coordination with DNSSEC RSP 4.Coordination with IANA 5.Zone Signature Update 6.Key Distribution and Propagation 7.Monitoring and Verification (II) KSK Rotation Procedures in Emergency Situations 1.Emergency Response Activation 2.Rapid Key Generation and Preparation 3.Emergency Coordination with DNSSEC RSP 4.Emergency Coordination with IANA 5.Emergency Zone Signature Update and Propagation 6.Emergency Monitoring and Recovery Please find the details in the supporting document below.

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 have on-site backups of registration data?

Yes

Does or will this RSP have off-site backups of registration data?

Yes

Does or will this RSP practice data retention policies with regard to backups of registration data?

Yes

Does or will this RSP practice documented standards regarding media and data backups for registration data?

Yes

Does or will this RSP practice regularly scheduled validation of registration data backups, separately from recovery practices?

Yes

Does or will this RSP practice regularly scheduled recovery of registration data backups?

Yes

Does or will this RSP forbid the use of production data in testing and/or development environments?

Yes

Does or will this RSP encrypt registration data at-rest in the data store?

Yes

Does or will this RSP encrypt registration data in-transit to and from the data store?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP use modern and known-secure cryptographic algorithms for the encryption of registration data at-rest and in-transit with regard to the data store?

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

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

Yes

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

Yes

Does or will this RSP forbid access to contacts via EPP to registrars other than the sponsoring registrar?

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 2024)?

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”)? Note: while RFC 9325 covers TLS and DTLS, EPP only uses TLS.

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 meet 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 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all currently operated gTLDs?

Yes

Does this RSP plan to continue to implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all gTLDs operated in the future?

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 RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all currently operated gTLDs?

Yes

Will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all gTLDs operated in the future?

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 5.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 specified 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

Will this RSP provide tools and mechanisms to Registry Operators for the purposes of automated processing and identification of abusive domain registrations.

Yes

Describe the EPP and RDAP status values as they relate to domain name registrations considered to be abusive registrations and those not considered to be abusive registrations.

I. EPP (I) EPP Status Fields Unrelated to Abuse ok inactive: The registration process has been completed, but the domain name has not been officially activated. linked: Generally means that this object is referenced by other objects. addPeriod: Applicable only to domain names, usually a fixed number of days after the completion of registration. autoRenewPeriod: The phase during which automatic renewal is executed according to preset rules before the domain name expires. pendingCreate: The registration request has been submitted, but the entire review or system processing process has not been completed. pendingDelete: The deletion process has been triggered, and the domain name is in the "deletion countdown" phase. pendingRenew: The domain name renewal request has been submitted, but the payment or system confirmation has not been completed. pendingTransfer: The domain name transfer request has been submitted and is in the process of waiting for confirmation. pendingUpdate: The registration information modification request has been submitted, but the review or system synchronization has not been completed. redemptionPeriod: The exclusive phase after the domain name is deleted but not yet purged, during which the original registrant is allowed to "redeem" the right to use it. renewPeriod: The specified time period after the domain name is renewed. transferPeriod: The statutory or agreed time period required for the domain name to complete the transfer between registrars/registry operators. pendingRestore: The domain name is in the process of being restored. (II) EPP Status Fields Related to Abuse clientHold: A suspended state set by the registrar. It is usually caused by unverified WHOIS information, unpaid fees, or disputes, etc. The domain name is temporarily locked, and some operations are restricted. serverHold: A suspended state set by the registry. It is often caused by legal disputes, violations of policies, etc., and restricts the use and management of the domain name. clientDeleteProhibited: A protection state that prohibits deletion. It can prevent the domain name from being deleted by mistake without affecting other operations on the domain name, providing a certain level of security protection for the domain name. clientRenewProhibited: A restriction set by the registrar that prohibits the user from performing the "renewal" operation on the domain name. It is commonly used in scenarios where the domain name is penalized for violations or the user actively applies to suspend renewal. serverRenewProhibited: A restriction set by the registry operator that prohibits any entity from renewing the domain name. It is usually used in scenarios where the domain name is "forcibly deactivated and phased out" due to serious violations. serverDeleteProhibited: A deletion-prohibited state set by the registry operator. clientTransferProhibited: A common locked state set by the registrar to prevent unauthorized domain name transfers. The transfer operation can be performed after the lock is lifted. serverTransferProhibited: A transfer-prohibited state set by the registry operator. clientUpdateProhibited: Prohibits modification of domain name information, protecting the domain name from unauthorized modifications and maintaining the accuracy and security of the information. serverUpdateProhibited: An update-prohibited state set by the registry operator. II. RDAP (I) RDAP Status Fields Unrelated to Abuse Active Inactive Associated add period auto renew period pending create pending delete pending renew pending transfer pending update redemption period renew period transfer period pending restore server delete prohibited (II) RDAP Status Fields Related to Domain Name Abuse client hold server hold client delete prohibited client renew prohibited server renew prohibited client transfer prohibited server transfer prohibited client update prohibited server update prohibited Please see details attached.

Describe the EPP and RDAP status values and their applicability to Uniform Rapid Suspension (URS).

In the URS (Uniform Rapid Suspension System) process, the complainant may request the dispute resolution service provider to place restrictive status on infringing domain names in order to quickly curb abusive activities. I.URS Lock：A combination of statuses that prevents a domain name from being updated, transferred or deleted. 1.EPP statuses when a domain name is in URS Lock: 1)serverUpdateProhibited 2)serverTransferProhibited 3)serverDeleteProhibited 2. RDAP statuses when a domain name is in URS Lock: 1)server delete prohibited 2)server transfer prohibited 3)server update prohibited II.URS Suspension：A domain name MAY be suspended as part of the final decision of a URS Complaint. We will redirect a URS Suspended domain name to a webpage that mentions that the domain name has been suspended because of a URS Complaint. III.URS Rollback:This is the state of a domain name that is not under either URS Lock or URS Suspension. if the URS Provider requests that the domain name be transitioned to a Non-URS State,we will restore the original information of the domain name.

Does or will this RSP implement the Registry Operator-related elements of RFC9361

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 be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

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