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.

This RSP implements RFC 8334.

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 we used are : urn:ietf:params:xml:ns:secDNS-1.1 urn:ietf:params:xml:ns:launch-1.0 urn:ietf:params:xml:ns:rgp-1.0 These URNs are registered EPP extensions that define protocol commands: "urn:ietf:params:xml:ns:secDNS-1.1": This is the EPP extension for DNS Security (DNSSEC). It defines the EPP commands and objects needed to manage DS (Delegation Signer) records for a domain, allowing registrars to add, remove, and view DNSSEC data. It is registered in the IANA EPP extensions registry as "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)"(RFC5910) "urn:ietf:params:xml:ns:launch-1.0": This is the Launch Phase Mapping extension. It provides the EPP commands for managing domain registrations during special launch phases (like Sunrise and Claims periods), which often require trademark validation. It is registered in the IANA EPP extensions registry as "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)"(RFC8334) "urn:ietf:params:xml:ns:rgp-1.0": This is the **Registry Grace Period (RGP)** extension. It defines the EPP commands and statuses related to the "Redemption Grace Period," allowing registrars to manage and restore domains that have been deleted. It is registered in the IANA EPP extensions registry as "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)"(RFC3915)

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.

icann_rdap_response_profile_1 icann_rdap_technical_implementation_guide_1 redacted

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 RSP supports the full domain lifecycle, including available, add grace period, registered/renewal period, auto-renew grace period, redemption grace period (RGP), pending delete period, These lifecycle states are implemented under the ICANN gTLD Registry Agreement and EPP standards, ensuring consistent domain behavior and policy compliance across supported TLDs.

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

The registry system supports a complete and standards-compliant domain name registration lifecycle, with each phase reflected through specific EPP status values and exposed to registrars and third parties via RDAP status values. The supported lifecycle states and their corresponding EPP/RDAP status indicators are as follows: 1. Available : The domain is not registered and can be registered by any eligible registrar. • EPP Status: Not applicable (no object exists yet). • RDAP Status: Not found / 404 response (object does not exist). 2. Add Grace Period ：A short window (typically 5–7 days) after registration during which the domain can be deleted with a refund. • EPP Status: addPeriod (automatically assigned by the registry) • RDAP Status: add Period 3. Registered / Renewal Period (including Transfer Grace Period) : The domain is active and in a registered state, or has been recently renewed or transferred. • EPP Status: ok (default if no restrictions apply)， clientTransferProhibited, serverTransferProhibited (if locked)，clientDeleteProhibited, serverDeleteProhibited (if protected) • RDAP Status: Reflects all EPP status values for transparency. Transfer Grace Period: If applicable, this is a sub-state under the registered phase. Although not shown as a distinct EPP status, the registry internally tracks it. The domain may still display ok, while eligible for refund upon deletion. 4. Auto-Renew Grace Period : After auto-renewal (on expiration), the domain enters a period (e.g., 45 days) where it can be deleted with refund of the renewal fee. • EPP Status: autoRenewPeriod • RDAP Status: auto Renew Period 5. Redemption Grace Period (RGP): After a domain is deleted, it enters RGP (usually 30 days), during which it can be restored. • EPP Status: pendingDelete，redemptionPeriod • RDAP Status: pending Delete, redemption Period 6. Pending Delete Period : After RGP, the domain enters a final 5-day period where it cannot be restored before being purged from the registry. • EPP Status: pendingDelete • RDAP Status: pending Delete The registry ensures all lifecycle transitions are recorded and reflected via the appropriate EPP status codes per [RFC 3915] and RDAP status fields per [RFC 7483], maintaining consistency and transparency for registrars, registrants, and ICANN compliance systems.

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.

This RSP supports both internal (in-bailiwick) and external (out-of-bailiwick) nameservers, with full compliance to the EPP protocol (RFC 5732) and RDAP standards. Nameservers are managed as host objects, which are referenced by domain objects to delegate DNS resolution. 1. Nameserver Representation Models There are two ways to represent nameservers in the registry: • As Host Objects (Discrete EPP objects) Created using the <host:create> command and managed independently. Example: ns1.example.net with its own IP(s) • As Domain Attributes (Attribute Values) Nameserver names and IPs are passed directly in the <domain:create> or <domain:update> without creating persistent host objects. 2. Host Object Lifecycle • Creation (<host:create>) Registrars may create nameserver host objects. These may be: In-bailiwick: Subdomains of the domain being managed (e.g., ns1.example.tld) Out-of-bailiwick: External to the domain (e.g., ns1.otherdomain.com) • Association with Domains Domains reference host objects as part of their delegation configuration. A domain may list 2–13 hosts as authoritative nameservers. • Update (<host:update>) IP addresses and status values of host objects can be updated via EPP commands. • Deletion (<host:delete>) Host objects can only be deleted if they are not referenced by any domain object. The registry enforces this through referential integrity constraints. 3. EPP and RDAP Status Values Common EPP status codes applied to host objects: • ok: Normal state; no restrictions • clientDeleteProhibited / serverDeleteProhibited: Prevent deletion • linked: Indicates that the host object is currently associated with at least one domain In RDAP, these status codes are mapped to the status field in the nameserver object response, allowing clients and registrars to see whether a nameserver is active, locked, or referenced. 4. Relationship to Domain Lifecycle • Nameservers (host objects) are essential to domain activation. A domain must have at least two valid nameservers to be published in DNS. • When a domain is created, it must reference existing host objects or create new ones. • When a domain is deleted, the host objects remain unless they become orphaned. • If a domain’s lifecycle ends (e.g., expiration, redemption, deletion), any in-bailiwick host objects may also be flagged for cleanup if they are no longer linked to any active domain. 5. Orphaned Host Cleanup (Optional) The RSP may implement a periodic scan to detect orphaned in-bailiwick host objects, i.e., host objects no longer referenced by any domain. These may be cleaned up automatically or flagged for registrar review. 6. Compliance and Logging All host object operations are logged and auditable. The system enforces referential integrity and complies with ICANN requirements for: • WHOIS/RDAP display of host objects • Status code transparency • Host-to-domain associations

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.

This RSP implements a lifecycle model for contact objects that aligns with the EPP specification (RFC 5733) and ICANN registry requirements. The lifecycle supports the creation, association, update, and deletion of contact objects, with safeguards in place to maintain data integrity and avoid orphaned references. 1. Contact Object Lifecycle • Creation (<contact:create>) A contact object is created by a registrar using the EPP <contact:create> command. At this point, it exists independently and is not yet associated with any domain or host object. • Association with Domain Names or Hosts Once created, contact objects can be referenced in domain objects as: • Registrant Contact • Administrative Contact • Technical Contact • Billing Contact (if supported) • Update (<contact:update>) The contact data (e.g., name, email, address) can be modified by the sponsoring registrar. Status values such as clientUpdateProhibited or serverUpdateProhibited may prevent modification under certain policies or dispute conditions. • Deletion (<contact:delete>) A contact object can be deleted only if it is not currently linked to any domain or host object. Attempts to delete an “in-use” contact will result in an error response per EPP protocol. 2. EPP and RDAP Status Values • Common EPP status values applied to contact objects include: • ok: Normal status, no restrictions • clientDeleteProhibited / serverDeleteProhibited: Prevent deletion • clientUpdateProhibited / serverUpdateProhibited: Prevent updates • RDAP represents these statuses in the status field of the contact object response, providing registrars and third parties visibility into the contact’s operational state. 3. Orphaned Contact Management • Definition: A contact object is considered orphaned if it is no longer referenced by any domain name or host object. • Automatic Cleanup Policy: This RSP implements a scheduled cleanup process to identify and delete orphaned contact objects after a defined retention period (e.g., 30 days of inactivity and no associations). • Safeguards: • All deletions are preceded by integrity checks to ensure no references remain. • Audit logs of contact deletions are retained for ICANN compliance review. • Registrar Notifications (if applicable): Registrars may be optionally notified prior to deletion of orphaned contacts, depending on registry policy. 4. Consistency and Compliance • The contact lifecycle is synchronized with the domain and host object lifecycles to maintain referential integrity. • All lifecycle transitions are logged and tracked for compliance with ICANN data retention and escrow requirements.

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.

This RSP meets all requirements under Specification 2 of the ICANN Registry Agreement (2024), Section 4. The following practices are implemented: Daily Full Deposit: A complete snapshot of registration data is generated daily at 00:00 UTC. • Escrow Format: Structured in CSV format, as specified in Section 4 of Specification 2. Encryption & Signing: • Encryption Algorithm: RSA (using escrow agent’s public key) • Signature Algorithm: SHA-256 Transport Protocol: Secure file delivery is performed over SFTP, with automatic retries and logging. • Automated Process: Data is extracted from PolarDB-X 2.0, serialized and verified by internal tooling (alirs-task), then securely transmitted. The system is fully automated, monitored, and auditable to ensure continuity and compliance with ICANN escrow obligations.

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

Currently, this RSP is a new one. We are not serving any TLD on our platform.