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.

The answer is provided in the attached PDF file (more than 4,000 characters): Main 1.16.pdf

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

Afnic implements the following EPP extensions for gTLDs: 1. domain-1.0 2. contact-1.0 3. host-1.0 4. rgp-1.0 5. secDNS-1.1 6. launch-1.0 7. fee-1.0 The extension mentioned in the initial response only concerns ccTLDs operated by Afnic. These extensions are not used in any way in the context of gTLDs.

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.

AFNIC uses the following RDAP extensions: - redacted, [https://www.iana.org/go/rfc9537][RFC9537], IETF - icann_rdap_response_profile_0, [https://www.icann.org/gtld-rdap-profile][ICANN], COMMON - icann_rdap_response_profile_1, [https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf][ICANN], COMMON - icann_rdap_technical_implementation_guide_0, [https://www.icann.org/gtld-rdap-profile][ICANN], COMMON - icann_rdap_technical_implementation_guide_1, [https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-21feb24-en.pdf][ICANN], COMMON

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.

There is an important initial distinction to be made. Statuses that begin with "client" are set by the Registrar, while those that begin with "server" are set by the Registry. Therefore, it’s not accurate to claim that an abuse procedure is underway solely because a "client_xxx_xxx" status is present. For example, it’s quite common for some Registrars to apply the "clientTransferProhibited" status right after a domain name is created. Some Registrars may also use the "clientHold" status as a means of putting pressure on registrants during disputes related to outstanding payments. As mentioned earlier, "server" statuses are reserved for the Registry and are used to prevent modifications on various objects (such as contacts, domains, etc.). These statuses are applied in accordance with what is defined in abuse or dispute resolution procedures. Depending on the procedure and/or its specific steps, there may be a greater or lesser combination of these statuses. It is therefore quite likely that a domain name showing multiple such statuses is subject to an abuse procedure. However, two important caveats should be kept in mind: 1. These statuses may also indicate a Registry Lock, even though this is not yet widely implemented across all gTLDs. 2. These statuses can also be applied to contact objects, depending on the procedures that have been triggered. Our implementation strictly follows the status mapping table as specified in RFC 8056 (https://datatracker.ietf.org/doc/html/rfc8056), with particular reference to the section “EPP-to-RDAP Status Mapping” beginning on page 2. The resulting mapping after registering the new RDAP statuses is: addPeriod = add period autoRenewPeriod = auto renew period clientDeleteProhibited = client delete prohibited clientHold = client hold clientRenewProhibited = client renew prohibited clientTransferProhibited = client transfer prohibited clientUpdateProhibited = client update prohibited inactive = inactive linked = associated ok = active pendingCreate = pending create pendingDelete = pending delete pendingRenew = pending renew pendingRestore = pending restore pendingTransfer = pending transfer pendingUpdate = pending update redemptionPeriod = redemption period renewPeriod = renew period serverDeleteProhibited = server delete prohibited serverRenewProhibited = server renew prohibited serverTransferProhibited = server transfer prohibited serverUpdateProhibited = server update prohibited serverHold = server hold transferPeriod = transfer period

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

When Afnic receives a notification from the organization in charge of the procedure informing them of the initiation of a procedure. The action requested in the first notification is the modification of EPP statuses (URS LOCK) - 24H to apply. At this first stage, Afnic modifies the EPP statuses by adding: - SERVER_TRANSFER_PROHIBITED : prevent the domain name to be transferred to another Registrar - SERVER_DELETE_PROHIBITED : prevent the domain name to be deleted by the actual Registrar - SERVER_UPDATE_PROHIBITED : prevent any changes on the domain name such as the registration data, name servers…etc. Theses statuses will therefore restrict all changes to the registration data, including transfer and deletion of the domain name. When a URS suspended domain name has expired, Afnic deactives its serverDeleteProhibited EPP status. If a domain name transitions from URS SUSPENSION to URS LOCK, Afnic updates the domain name to set the name server (NS) and delegation signer (DS) information that was originally present in the domain name before the URS SUSPENSION. If glue records were removed when Afnic activated the URS SUSPENSION, Afnic restores the required glue records. A URS suspended domain name will be redirected to a webpage that explains the URS Complaint. In order to redirect to the suspension website, the URS Provider will specify the NS and dsData information to Afnic in the email that instructs Afnic to suspend the domain name. Once the EPP statuses are applied to the domain name, they will be displayed in the RDAP results. Please find below the mapping between EPP statuses and RDAP statuses for URS management: - SERVER_TRANSFER_PROHIBITED => serverTransferProhibited - SERVER_DELETE_PROHIBITED => serverDeleteProhibited - SERVER_UPDATE_PROHIBITED => serverUpdateProhibited If the URS Provider requests that the domain name be transitioned to a Non-URS State, Afnic restores the original information of the domain name. The operation is called an URS ROLLBACK.

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.

1. Creation A domain name is created (via EPP, API or the Registrar Website). Mandatory data includes contacts (registrant, administrative, technical and billing contacts) and an auth_info code. If nameservers are set: the domain becomes ACTIVE (published in the authoritative DNS servers). If not: the domain is REGISTERED but not active in the DNS. Creation is a real-time operation unless a technical issue causes a PENDING state. 2. Update Domain updates are of three types: 1. Technical Update: modify nameservers, IP addresses, or DNSSEC data. 2. Administrative Update: change administrative, technical, billing, or registrant contacts. 3. Context Update: change domain statuses (e.g., clientHold, clientTransferProhibited) or the auth_info code. Updates usually do not change the domain’s visibility unless statuses like clientHold/serverHold are modified. Operations are immediate unless they enter a PENDING state due to technical issues. 3. Deletion Only the sponsoring registrar can delete a domain. Upon deletion, the domain enters a Redemption Period (RGP) for 30 days: it remains registered but is removed from DNS. During RGP, the domain can be restored without data loss. After RGP and a pending delete period of 5 days, the domain is permanently destroyed and made available for new registration. Deletion affects visibility and ownership status significantly. 4. Renewal A domain can be explicitly renewed with the domain:renew command if it has less than 10 years of registration remaining. Upon reaching the expiration date without action, the registry auto-renews the domain for 1 year, entering an auto-renew grace period of 45 days, during which deletion can cancel the renewal without penalty. Renewals ensure continuity of ownership and DNS visibility. 5. Transfer A domain transfer must be initiated by the gaining Registrar and requires the auth_info code. The losing registrar can approve, reject (under ICANN rules), or ignore the request — in which case the transfer completes automatically after 5 days. If accepted, the transfer completes immediately. If rejected, it is canceled and both registrars are notified. Successful transfers are also confirmed via EPP notifications. Transfers are blocked for 60 days after registration or a previous transfer. The gaining registrar may cancel the request. A reverse transfer may be requested by the losing registrar under specific ICANN conditions. Disputes are handled under the ICANN TDRP (Transfer Dispute Resolution Policy). 6.Restoration When a domain enters the pendingDelete status, it is no longer active in DNS and appears as pending delete in RDAP. If restoration is requested during the 30-day Redemption Period, the process occurs in two distinct steps: Step 1 – Restore Request The registrar submits a domain:restore command. The domain moves from pendingDelete to pendingRestore in EPP and appears as pending restore in RDAP. It is not yet reactivated in DNS. Step 2 – Report and Confirmation The registrar provides supporting documentation. If approved, the domain returns to ok in EPP and becomes active or inactive in RDAP, depending on DNS configuration. The domain is now fully restored. In our back office platform, these steps are combined in a one operation, where the registrar provides all the information and, if there is no technical issue, the domain is immediately restored. Grace Periods The Grace Period mechanism refers to a specified period following an operation or change of status in which the operation may be reversed and a credit may be issued to the Registrar. There are 3 types of Grace periods of 5 days: Add Grace Period (post-creation), Renew Grace Period (post-renewal), Transfer Grace Period (post-transfer): allow deletion for refund. Key Domain States A domain can have one of the following state: - REGISTERED: Created but not active in DNS. - ACTIVE: Published in DNS. - LOCKED: Transfers or deletions are prohibited.

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

EPP Statuses (Protocol-level) These are operational flags at the registry: - ok: No restrictions - inactive: No DNS delegation - pendingCreate: Registration not finalized - pendingTransfer: Transfer requested - pendingDelete: Deletion pending - pendingRenew: Renewal pending - pendingRestore: Restore operation underway Server-side prohibitions: serverHold, serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited, serverRenewProhibited. Client-side prohibitions: clientHold, clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited, clientRenewProhibited. RDAP Statuses (Public Display) RDAP maps EPP statuses into human-readable flags: - Active: Domain registered and published in DNS - Inactive: Registered but not published (no nameservers or hold status) - Pending Transfer: Awaiting transfer approval - Pending Delete: Awaiting deletion - Pending Restore: Awaiting restoration during Redemption Grace Period The pending<statuses> should be seen by the "public" only if a technical issue has occured. Server Transfer/Delete/Renew Prohibited, etc.: Administrative locks. Client Transfer/Delete/Renew Prohibited, etc.: Registrar locks. Multiple RDAP statuses can be simultaneously active. Domain Status Mappings The domain's actual state results from its EPP status flags, visible externally through RDAP. When a domain is newly registered: - It has the EPP status ok with no nameservers. - The RDAP status displayed is inactive. When a domain is active and published in DNS: - It has the EPP status ok and valid nameservers configured. - The RDAP status displayed is active. When a domain is locked to prevent transfer: - It has the EPP status clientTransferProhibited or serverTransferProhibited. - The RDAP status is active combined with a Transfer Prohibited indication. When a domain is on hold and not published in DNS: - It has the EPP status clientHold or serverHold. - The RDAP status displayed is inactive. When a domain is undergoing a transfer: - It has the EPP status pendingTransfer. - The RDAP status displayed is pending transfer. When a domain has deletion requested: - It has the EPP status pendingDelete. - The RDAP status displayed is pending delete. When a domain is restored during Redemption Period: - It has the EPP status pendingRestore. - The RDAP status displayed is pending restore. Normal Lifecycle Transitions Domain Creation: - A domain begins with the EPP status pendingCreate. - Once created, it moves to ok in EPP. - If nameservers are set, RDAP shows the domain as active; otherwise, it remains inactive. Domain Management (Nameservers and Holds): - Adding nameservers to an inactive domain makes it active in RDAP. - Removing nameservers or applying clientHold/serverHold changes the RDAP status to inactive. Domain Transfer: - A valid transfer request moves the domain from ok to pendingTransfer in EPP. - After approval or timeout, it returns to ok. - RDAP reflects either active or inactive, depending on DNS status. Domain Deletion: - If explicitly deleted or expired, the domain shifts from ok to pendingDelete in EPP. - RDAP then shows pending delete. Domain Restoration (Redemption Period): - If restored, the domain goes from pendingDelete to pendingRestore in EPP. - Once confirmed, it returns to ok in EPP and shows as active or inactive in RDAP. Forbidden Transitions - pendingDelete → pendingTransfer: Transfers are blocked during deletion - pendingTransfer → pendingDelete: Cannot delete during transfer process - pendingCreate → pendingTransfer: Must complete creation first - pendingDelete → ok: Restoration must be performed first (pendingRestore) - client/server*Prohibited → Pending States: Operations blocked must first clear prohibitions Lifecycle Diagram (Summary) - Create → (pendingCreate) → ok → Active/Inactive - ok → pendingTransfer → ok - ok → pendingDelete → pendingRestore → ok - pendingDelete (no restore) → Domain Deleted

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.

1. Nameservers origins The Registry manages thick registry models, where nameservers are registered independently via the host:create EPP command. They are persistent objects linked to one or more domains and can be reused. 2. Host object lifecycle (EPP view) Host objects follow a simple lifecycle via EPP commands: - Creation (host:create): A nameserver object is created with a hostname and optional IP addresses (glue). It can later be linked to one or more domains. - Update (host:update): IPs can be modified. Hostnames cannot be changed; to rename a host, it must be deleted and recreated. - Deletion (host:delete): A host object can be deleted if it is no longer linked to any domain. Attempting deletion while still in use results in an error. EPP statuses of host objects include: - ok: Host is valid and usable. - linked: Host is actively used by at least one domain. - pendingDelete: Host is scheduled for deletion. - client/serverUpdateProhibited: Update operations are blocked. 3. Interaction with domain lifecycle A domain with no nameservers (host objects or attributes) is considered inactive in both EPP and RDAP. Adding nameservers during or after domain creation activates the domain: - EPP: Domain status changes from inactive to ok. - RDAP: Domain appears as active. Removing all nameservers reverts the domain to inactive. Nameservers also influence domain restoration: A restored domain becomes active in RDAP only if nameservers are still present or re-added. 4. RDAP exposure of host information RDAP presents nameserver data attached to a domain’s record. It includes: - Hostname (mandatory) - IP addresses (if glue is provided) - Status values (mirroring EPP statuses like linked, ok, etc.) RDAP does not show host objects separately unless queried directly via their handle.

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.

Contact objects are essential components in domain name management. They represent individuals or organizations responsible for domain administrative, technical, billing, or registrant roles. Their lifecycle and status are critical to maintaining proper registration data integrity and registry operations. 1. Contact roles in the domain lifecycle Each domain name typically references one or more contact objects: - Registrant Contact – Domain owner. - Administrative Contact – Handles policy or contractual issues. - Technical Contact – Manages DNS/technical operations. - Billing Contact – Manages payment and renewal matters. These contacts are linked at domain creation or later through update operations. Their presence is mandatory for domain registration. 2. Contact object lifecycle (EPP) Contact objects are created, updated, and deleted using specific EPP commands: - Creation (contact:create): The registrar defines contact details, including name, organization, postal address, phone, email. - Update (contact:update): Fields such as email, address, and roles can be updated unless prohibited. - Deletion (contact:delete): A contact can only be deleted if it is no longer linked to any domain or host object—this is known as orphaned contact deletion. If the contact is still referenced, deletion is denied. 3. EPP status values for ontacts Common EPP contact statuses include: - ok – No restrictions; fully manageable. - linked – Contact is currently associated with at least one domain. - clientUpdateProhibited / serverUpdateProhibited – Updates are blocked. - clientDeleteProhibited / serverDeleteProhibited – Deletion is blocked. - pendingDelete – Deletion requested, awaiting final removal. A contact in linked status cannot be deleted. 4. RDAP Representation (to be reviewed) In RDAP, contact data is shown as part of the domain record when available and permitted by privacy rules or policy. It includes: - Contact role (registrant, admin, etc.) - Name, organization, address - Email and phone (if not redacted) - Statuses (mirroring EPP statuses like linked, active, or prohibited) Note: in our system, unlike domains, contact objects are not queryable via RDAP. 5. Deletion of Orphaned Contacts (to be reviewed) A contact becomes orphaned when it is no longer linked to any domain or host object. When a domain is deleted (expired or transferred), and the contact is not used elsewhere, it becomes eligible for deletion. The registrar may then issue a contact:delete command, which will succeed if: - No EPP linked status is present. - No deletion prohibitions apply.

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.

For each TLD extension operated by the RSP, a copy of all data must be deposited daily with a data escrow provider approved by ICANN. Format of the deposit is compliant with Specification 2 of the Registry Agreement which includes * Dates and times: (creation dates, expiry dates): UTC * Country codes: ISO-3166-1 * Phone Numbers: ITU-E164 (as in EPP) * IP Addresses : RFC:791 for IPv4, RFC:4291 for IPv6 == Detailed description of the Data Escrow Process == Phase 1 - Production of the deposit Data This operation is carried out in 2 stages: - Extraction from the Registry Database of the required data into the Data Escrow Prep file; - Building of the relevant Deposit for that day by assembling the data contained in the DataEscrowPrep file. Afnic has decided to produce a full deposit every days of week. Phase 2 - Compliance and data integrity are performed on the deposit before transmission to the escrow agent. The procedure is as follows: - The signature of each file is checked; - If there are several parts, the overall file is restored; - The file is decrypted and decompressed; - The file format is compared with the specifications; - If required, the checks stipulated in the ICANN specifications are performed. Phase 3 - Deposit of the data to the Escrow Agent Transmission to the deposit agent is electronically secured by encrypting the records and will take place according to the following schedule : - Every day of the week before 10:00 am. This leaves sufficient time for recovery in case of non-validation of the deposit by the escrow agent. Details of the procedure: - ZIP file compression (RFC:4880). - File encryption with the OpenPGP public key of the escrow agent (Elgamal or RSA for asymmetric encryption and TripleDES, AES128 or CAST5 for symmetric encryption). - Partitioning of the file into several parts if its size exceeds the limit specified by the escrow agent. - OpenPGP signing of each part with the private key of the registry (DSA or RSA for the signature, SHA256 for hashing), the file containing the signature will neither be encrypted nor compressed. - Transmission of files (the various parts + the signature file) via SFTP / SCP / HTTPS as directed by the escrow agent. - Validation by the escrow agent of the successful completion of transfer . Phase 4 - Notification of deposit by the deposit agent The deposit manager receives the deposit notification approved by the escrow agent. Phase 5 - Validation by AFNIC of a successful Transfer on day N: end of the day's deposit This closes the deposit action for the day and is recorded in the day book. Notification of deposits by the Registry Operator to Escrow Agent and to ICANN is operated through written statement. This statement includes the Deposit's "id" and "resend" attributes (as described in Domain Name Data Escrow Specification: RFC 8909 and RFC 9022). Phase 6 - Takeover by AFNIC of the deposit process in case of failure This phase occurs after the notification of failure by the escrow agent. The escrow deposit manager resumes the procedure after the cause has been identified and corrective measures have been implemented. Supervision is ensured by special monitoring of the Data Escrow process integrated with the supervision system of the Registry. The supervision information is intended for the on-call team and the escrow manager. The management of escrow incidents falls within the scope of intervention of the on-call team in coordination with the escrow manager. A Data Escrow day book is used to record and track transactions carried out as part of the process. It is updated during each daily transaction involved in the Data Escrow process.

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

Over the last six months, AFNIC has not encountered any major technical issues affecting the services of the gTLDs it operates.