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.

We will roll the KSK with a double-signing scheme as described in RFC 4641, section 4.2.1.2. New KSKs will be fully coordinated between ourselves and the DNS/DNSSEC RSP as outlined in detail in MAIN.3.4 and illustrated in the diagram MAIN.3.4_B.jpg (also attached to this question for the reference). New KSKs are generated by our DNSSEC RSP when needed, according to the schedule in the mentioned RFC. The operations team at our RSP and the DNS/DNSSEC RSP are on the telephone from the start to completion of the process. The KSKs are generated and kept in the DNSSEC RSP’s hardware security modules. The corresponding DS records will be communicated from the DNSSEC RSP to our MAIN RSP over secure channels, and our MAIN RSP staff will use the regular IANA TLD portal to update the DS records in the TLD database, and where appropriate or required, the DNSSEC Policy Statement will be updated as well. The emergency procedure for KSK rollovers is very close to the above, but has a few expedited steps in the beginning. It is described in RFC 4641, section 4.3.1.1. It will be prompted by direct phone calls between our respective 24x7 operations centers, who will remain in close contact through the entire procedure. We also append the relevant DPS (att. MAIN.1.16_A) from our DNSSEC RSP (Netnod) for more information.

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

The following EPP extensions, registered in the IANA EPP extensions registry (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml), are used: - RFC3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC8748 - Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Hereby we attest that all EPP extensions to be used are registered with the IANA as per RFC 7451.

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 RSP will use RDAP extensions. Our base will be icann_rdap_response_profile_0, RFC 8521 and RFC 9537. After August 21, 2025, icann_rdap_response_profile_1 will supercede icann_rdap_response_profile_0. rdap_objectTag (RFC 8521) — this extension describes a best practice for structuring entity identifiers to enable query bootstrapping. redacted (RFC 9537) — this extension identifies the redacted fields in an RDAP. response.icann_rdap_response_profile_0 (https://www.icann.org/gtld-rdap-profile) — after August 21, 2025, will be replaced by icann_rdap_response_profile_1 (https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf). We will implement profiles based upon icann_rdap_technical_implementation_guide_0 (https://www.icann.org/gtld-rdap-profile) — after August 21, 2025, will be replaced by icann_rdap_technical_implementation_guide_1 (https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-21feb24-en.pdf). For graduated access we will implement the following for authenticated, logged-in users: - farv1 (RFC9560) — this extension describes version 1 of a federated authentication method for RDAP using OAuth 2.0 and OpenID Connect. - paging (RFC8977) — this extension describes a best practice for result set paging. - reverse_search (RFC9536) — this extension identifier is used for both URI path segments and response extensions related to the reverse search in RDAP. - sorting (RFC8977) — this extension describes a best practice for result set sorting. - subsetting (RFC8982) — this extension describes best practice for partial response provisioning. We are able to implement other RDAP profiles as they are requested by TLD Registry Operators or as defined by future consensus policies. Such extensions will be submitted to the IANA as appropriate.

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.

EPP status values are client-set by registrars or server-set by registries (which take precedence) and appear in RDAP lookups. DNS abuse, defined as malware, botnets, phishing, pharming, and spam (as it relates to these 4) is mitigated by registrars placing domains on clientHold or deleting them, or by registries applying serverHold or deletion, depending on the abuse severity and potential collateral damage. In the case of abusive registrations, the primary means of mitigation available to a registrar or registry is to place the domain name(s) on "hold'. The EPP status values (and corresponding RDAP status values) that would be set for abusive domain registrations would be ClientHold (RDAP — client hold) or ServerHold (RDAP — server hold). Optional EPP status values (and their corresponding RDAP status values) depending on the nature of abuse or less common circumstances of mitigation, such as court order or LEA takedown or preservation requests: - serverDeleteProhibited (RDAP — server delete prohibited), clientDeleteProhibited (RDAP — client delete prohibited) - serverRenewProhibited (RDAP — server renew prohibited), clientRenewProhibited (RDAP — renew prohibited) - serverTransferProhibited (RDAP — server transfer prohibited, clientTransferProhibited (RDAP — client transfer prohibited) - serverUpdateProhibited (RDAP — server update prohibited), clientUpdateProhibited (RDAP — client update prohibited) Non-abusive registrations EPP status values (and corresponding RDAP status values): - addPeriod (RDAP: add period). This grace period is provided after the initial registration of a domain name. If the registrar deletes the domain name during this period, the registry may provide credit to the registrar for the cost of the registration. - autoRenewPeriod (RDAP: auto renew period). This grace period follows domain expiry and auto-renewal. If the registrar deletes the domain during this time, a renewal credit is issued. - inactive (RDAP: inactive). This status value indicates that delegation information (name servers) has not been associated with the domain. The domain is not activated in the DNS and will not resolve. - ok (RDAP: active). This is the standard status for a domain, meaning it has no pending operations or prohibitions. - pendingDelete (RDAP: pending delete). This status value may be mixed with redemptionPeriod or pendingRestore. If not restored in 30 days, domain enters pendingDelete and will soon be purged and dropped from the registry. Once deletion occurs, the domain is available for re-registration in accordance with the registry's policies. - pendingRestore. This status value indicates that registrar has asked the registry to restore the domain that was in redemptionPeriod status. The pendingRestore status is returned in the EPP response but not assigned to the domain object (and the corresponding RDAP status value is not applicable). - pendingTransfer (RDAP: pending transfer). This status value indicates that a request to transfer the domain to a new registrar has been received and is being processed. - redemptionPeriod (RDAP: redemption period). Registrar requested deletion. Domain stays in this status for 30 days, then is purged 5 days after redemptionPeriod and becomes available. - renewPeriod (RDAP: renew period). This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal.

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

The Universal Rapid Suspension (URS) is a required component of the rights protection mechanisms (RPMs). This is supported on our system. Three states are possible when URS is in play with one or more domain name: URS Lock, URS Suspension, or Non-State / URS Rollback. "URS LOCK" "URS Lock" holds the domain name in a frozen, but active, state, where no changes to it can occur during the review of the domain name by the URS Provider. There is not technically a "URS Lock" status within EPP. To perform the effect described for "URS Lock", there are three statuses that are set in order to lock a domain for URS when the URS Provider directs the Registry Operator (RO) (or the Back End Registry Operator (BERO) on their behalf) ("The Registry") to do so. The following EPP status values (and their corresponding RDAP status values, which we will put in parenthesis) will apply to "URS Locked" and "URS Suspended" domains (as defined in https://newgtlds.icann.org/sites/default/files/tech-requirements-21feb24-en.pdf): - serverDeleteProhibited (RDAP — server delete prohibited), - serverTransferProhibited (RDAP — server transfer prohibited), - serverUpdateProhibited (RDAP — server update prohibited). Upon notice to The Registry (per section 4 of the URS Rules updated February 21, 2024) from the URS Provider to "URS Lock" a domain, three EPP statuses will be set. These statuses will show in the RDAP results when the domain name is queried, and are public information, though there is not any specific verbiage that the domain name is locked for URS displayed in the RDAP results. Domain(s) will have these statuses present until the domain name is either suspended or the decision is made that the 'URS Lock' is rolled back. "URS Suspension" URS Suspension is a scenario where domain name(s) is/are suspended and redirected to a webpage indicating suspension because of a URS Complaint (as defined in the URS Rules). This may mean updating the DNS Servers and dsData/keyData information, potentially removing existing old DS records for the domain(s) "URS Rollback" URS Rollback is where the domain name is not under either "URS Lock" or "URS Suspension", and the domain name(s) get restored to their state prior to undergoing the URS process, noting that this could mean simply removing the three server statuses constituting the URS Lock, but may also include reverting the domain(s) DNS and DS records to their state prior to the URS initiation. Special considerations for URS interplay with Domain Lifecycle, specifically Expiration, are required. Domains with the serverDeleteProhibited (RDAP — server delete prohibited) status value will have that value removed once the disputed domain expires. This is to allow for it to be deleted through its natural course as defined in the Domain Lifecycle. As the domain name progresses through the lifecycle states of expiring, it is possible for the URS Complainant to renew the domain name. https://newgtlds.icann.org/sites/default/files/tech-requirements-21feb24-en.pdf, the URS Provider issues URS Rollback request, the three status values will be removed and instead the status value OK (RDAP — active) will be applied. Once the serverDeleteProhibited EPP status value (with the corresponding RDAP status value — server delete prohibited) is removed upon domain expiration, the EPP status values may change to autoRenewPeriod (RDAP — auto renew period), redemptionPeriod (RDAP — redemption period), pendingDelete (RDAP — pending delete), pendingRestore (RDAP — pending restore). If the URS disputed domain is explicitly renewed, then pendingRenew and renewPeriod EPP status values (with the respective RDAP status values “pending renew” and “renew period”) will also be applied.

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 lifecycle management process (described in detail in att. MAIN.10.1_A with a visual representation in att. MAIN.10.1_B) ensures rigorous compliance with industry standards, including: - EPP RFCs (5730–5734) - Grace period handling as per RFC 3915 - DNS consistency and restoration capabilities - Secure and accurate management of registrar transfers, renewals, deletions, and restorations. The system supports operational stability, fairness between registrars, and predictability for registrants while providing mechanisms for error correction, fraud mitigation, and security incident recovery.

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

The lifecycle of a domain name includes several stages, from registration to deletion, with various status values set by the EPP and RDAP protocols. Domain Available for Registration: The domain is not present in the registry and can be created (registered) by any registrar. EPP and RDAP status values are absent. 1. Active State: The domain is registered, delegation information (NS records) is specified, and there are no locks preventing its delegation. The domain can be used for websites, email, and other internet services. - EPP status value: ok - RDAP status value: active 2. Inactive State: The domain is registered, but delegation information is not specified, or statuses are set that limit delegation. DNS information about the domain is absent. - EPP status value: inactive - RDAP status value: inactive 3. Locked: Domain usage is prohibited. The domain is in an inactive state. - EPP status value: clientHold, serverHold - RDAP Status value: locked 4. Domain in Deletion Process: The domain was deleted either automatically upon expiration or by the registrar's command. - EPP Status value: pendingDelete - RDAP Status value: pending delete 5. Domain Deleted: After the deletion process is complete, the domain no longer exists in the registry and can be registered by any registrar (essentially returns to #1 above). 6. Domain in Transfer Process: A transfer request for the domain has been created, awaiting confirmation or rejection. - EPP status value: pendingTransfer - RDAP status value: pending transfer While the domain exists in the registry and is not undergoing deletion, it may have additional statuses that prohibit certain operations: 1. Deletion Prohibited: The domain cannot be deleted by the registrar's command. If automatically deleted upon expiration, it cannot be deleted only if it has the EPP status value serverDeleteProhibited. - EPP status value: clientDeleteProhibited, serverDeleteProhibited - RDAP status value: delete prohibited 2. Renewal Prohibited: The domain cannot be renewed neither by the registrar's command nor automatically upon expiration. - EPP status value: clientRenewProhibited, serverRenewProhibited - RDAP status value: renew prohibited 3. Update Prohibited: The domain cannot be modified. If only the EPP status value clientUpdateProhibited prohibits changes, the registrar can remove this status with an update command and then modify the domain with subsequent commands. - EPP status values: clientUpdateProhibited, serverUpdateProhibited - RDAP Status value: update prohibited 4. Transfer Prohibited: The domain cannot be transferred to another registrar. - EPP Status value: clientTransferProhibited, serverTransferProhibited - RDAP Status value: transfer prohibited RGP statuses (addPeriod, autoRenewPeriod, renewPeriod, transferPeriod, redemptionPeriod, pendingRestore) are not included as they have no equivalents in RDAP and are not strictly EPP statuses. EPP status values pendingCreate, pendingRenew, pendingUpdate also have been excluded as they are not used for registrars — if an operation is performed, it is completed immediately before sending a response, or it is rejected. We leave these statuses in for completeness, and have them for future use in importing an already functional registry to our RSP.

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.

Host objects are created for a registry instance level (that may include several TLDs), i.e if a registrar working in that instance creates a host object, other registrars also working in that instance can use it. Before using an NS server name in the domain:hostObj elements of the domain:create and domain:update EPP commands, it is necessary to check the existence of a host object with the required name in the registry and, if it does not exist, create it. The check is performed using the host:check EPP command. A response with avail="0" means that a host with that name has already been created in the registry and can be used. Creating a host is performed using the host:create EPP command. The hosts are created instantly, thus the pendingCreate EPP status (RDAP — pending create) is not used. Hosts are categorized into internal and external. Internal hosts are those that are subdomains of a TLD managed in the same registry instance, where the host is located. External hosts are all others. An internal host can only be created as a subordinate host (subdomain) of a domain existing in the registry which does not have a status set that would block the action, and only by the sponsoring registrar of that domain. IP addresses can be specified for an internal host. Corresponding DNS records will be created for these addresses. Statuses of a parent domain name that would block the creation of an internal host are inactive (RDAP inactive), pendingDelete EPP status (RDAP — pending delete), or client/server versions of Hold or UpdateProhibited statuses. The sponsoring registrar that created the host can change its EPP statuses to clientDeleteProhibited (RDAP — client delete prohibited) and clientUpdateProhibited (RDAP — client update prohibited). If the host is not linked to any domain, its sponsoring registrar can delete the host (using the host:delete EPP command) and also change its name and IP addresses (using the host:update EPP command; such updates happen instantly, hence the pendingUpdate EPP status (RDAP — pending update) is not used). The serverDeleteProhibited (RDAP — server delete prohibited) and serverUpdateProhibited (RDAP — server update prohibited) EPP statuses are set and removed by the registry operator of the respective TLD. The linked EPP status (RDAP — associated) is automatically set when the host is linked to a domain. It is automatically removed when the link between the host and the domain is deleted, if there are no links to other domains. The ok EPP status (RDAP — active) is automatically set when the host is created and when any status is removed if, after that, the host has no other statuses except linked (RDAP — associated). It is removed when any EPP status other than linked (RDAP — associated) is added to the host. When the parent domain is deleted, its internal hosts are deleted, except cases when an internal host is linked to any domain other than its parent (then, the parent domain is assigned the serverDeleteProhibited EPP status (RDAP — server delete prohibited) and cannot be deleted by its sponsoring registrar, i.e. upon expiration, it is automatically renewed at the sponsoring registrar’s expense). If an internal host is to be deleted along with its corresponding parent domain, that host is assigned the pendingDelete EPP status (RDAP — pending delete). When the parent domain is transferred, its internal hosts are also automatically transferred. Once such transfer is initiated, and until its completion, the host is assigned the pendingTransfer EPP status (RDAP — pending transfer). The registry monitors, where possible, for changes to external hosts and their changes on a periodic frequency, to determine where stale glue or other problematic scenarios, and monitors emerging threats, adapting policy to ensure the safest possible handling of Nameserver Registration while best servicing the Registry Operator, Registrars and Registrants.

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 registry system methodology follows IETF STD-69 EPP - most notably the EPP Extensions for Contact management that is documented in RFC 5733, and RDAP follows the conventions in RFC7483. The contact lifecycle includes the crucial Contact object operations: - Creation of a Contact record - Linking a Contact object to one or more Domain(s) - Updating a Contact object - Cloning a Contact object for the purposes of domain transfer - Deletion of a Contact object Registrars can create one or more contacts using their secure session and EPP commands, or via their secure web-based registras dashboard session. When creating a contact, a unique identifier (UUID) is generated. This identifier is unique across the entire registry and follow RFC5733. If a registrar has multiple contacts, one of them can be designated as the default contact. This default contact will be assigned to all domains of the registrar created through the dashboard. When creating a domain using the EPP command, indicating the value for the Registrant contact type is mandatory. A contact is linked to domains using EPP commands or in the registrar's dashboard when creating or modifying a domain. A contact can be linked to multiple domains and as different types of contacts (registrant, admin, tech, billing). Contacts are deleted using the EPP command or in the registrar's dashboard. If a contact is linked to at least one domain, its deletion is not possible. Automatic deletion of orphaned contacts is not provided. Contact transfers are not supported. When transferring a domain, copies of the contacts linked to that domain are created for the gaining registrar, and the domain is linked to this newly created contacts. Contact statuses: Registrars can set and remove the EPP status values clientDeleteProhibited (corresponding RDAP status value — client delete prohibited) and clientUpdateProhibited (corresponding RDAP status value — client update prohibited) using EPP commands or in the dashboard, which respectively prohibit the deletion and modification of the contact. Registry system administrators can set and remove the EPP status serverDeleteProhibited (corresponding RDAP status value — server deleted prohibited) and serverUpdateProhibited (corresponding RDAP status value — server deleted prohibited).

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.

To comply with the standards established in Specification 2 of the ICANN Registry Agreement (version 2024), the RSP will facilitate the means for the Registry Operator (RO) to perform their responsibilities in full compliance with the requirements of the registry agreements with respect to registry data escrow. Recognizing that the RO must perform this important activity, we have the following methodology. 1. Provider Selection In reviewing the approved providers published by ICANN [https://www.icann.org/resources/data-escrow-services-en], we have selected, and will initially contract with DENIC Services GmbH & Co. KG (DENIC) as an ICANN-approved data escrow agent and ensuring we are meeting technical requirements for the transmission of registry data to this agent. DENIC shall be our default integration. Although we do not anticipate it, should an alternative provider from ICANN's approved provider list be identified by the RO, we shall work with the RO and provider to address the necessary integration requirements for equivalent service connections and put in place the required generation, transmission, monitoring and other integrations and processes to ensure compliance with requirements. 2. Data Transmission Data transmission will be completed no later than 23:59 UTC. A "full deposit" of the registry state will be transmitted every Sunday. On other days, a "differential deposit" containing changes not included in previously transmitted deposits will be sent. At the request of the registry operator and in agreement with the escrow agent, a daily transmission of a "full deposit" will be possible. Deposit files will be generated in accordance with the requirements of RFC 8909 and RFC 9022 (attached herein), using UTF-8 encoding. Schema extensions will not be used. File names will be generated in accordance with section 5 of Specification 2 of the ICANN Registry Agreement (version 2024). The prepared files will be collected into a single tar archive before transmission, compressed using the zip algorithm, and encrypted as specified in RFC 4880. After this, the file may be split into parts if its size exceeds the limit set by the escrow agent. Electronic signatures will be generated for the resulting files using the registry operator's private key and transmitted to the escrow agent along with the files. The RSP will also provide registry operators with the functionality for the transmission of written statements to ICANN in accordance with section 7 of Specification 2 of the ICANN Registry Agreement (version 2024). The statements will be transmitted by sending a message to the /report/registry-escrow-report/<tld>/<id> API endpoint of the ICANN server, where is <tld> is the corresponding TLD and <id> is the deposit identifier with which the data was transmitted to escrow. The PUT HTTP method will be used. The request body will contain an object <rdeReport:report> in XML format, as described in sections 1.4.2, 2.1, and 7.2 of the draft-lozano-icann-registry-interfaces-23 document. 3. Data Integrity Data integrity is important for all parties, and we take this very seriously. In addition to our careful attention to generation of the information in the appropriate deposit formats, we closely monitor for other anomalies such as significant reduction in line numbers or file sizes prior to transmittal as a proactive method of ensuring full delivery will occur. We also carefully monitor transmission of the data during our submissions, and then subsequently, after transmission, we monitor closely for alerts from the data escrow provider and their integrity and verification of the payloads.

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

At the time of application, this RSP does not currently serve any gTLDs. Rather than respond with "Not Applicable", we wanted to highlight the subdomain registry that we are operating, as our operation of a successful STD-69 EPP SRS system means that there are contextually relevant aspects of our service that currently offers subdomain registration at the third level within the popular IT.COM namespace. This service launched in 2023, and has been in successful operation since (with more than 45,000 .it.com domains under management as of mid-May 2025, and daily registrations at around several hundred names), servicing major global registrars such as GoDaddy, NameCheap, Dynadot, GNAME, CentralNic Reseller, GMO and others with a robust SRS / EPP and Whois/RDAP that meet or exceed the requirements of the RSP program as defined in Specification 10 of the ICANN 2024 Registry Agreement.