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 signing process including all KSK rollovers (both planned and emergency) are handled by the DNSSEC RSP. The MAIN RSP is not involved in the signing of the TLD therefore no additional coordination between those two are necessary. See MAIN 3.4, which explains in detail the mechanism the DNSSEC RSP notifies the MAIN RSP about a change in the signed zone file and thus triggers a republication of the zone to the DNS. The only communication necessary is between the DNSSEC RSP and the Registry contacts (technical and administrative) as they will need to accept those DS changes submitted to IANA. These contacts may be with the Main RSP, but they may also be completely independent contacts. The communication is ensured by calling those contacts via phone and raising awareness that IANA notifications will be received and must be approved. Depending on whether the DNSSEC RSP is operated by the same organisation as the MAIN RSP or not, the communication differs. 1. DNSSEC RSP is operated by MAIN RSP The SRS Backend regularly sends a SOAP request to the Signing Engine to check whether there are any changes in the signed zone. This is required to ensure that signatures are renewed in time, even if there are no changes on the unsigned zone. This check is executed every 10 seconds. The same mechanism is used, when a KSK rollover takes place. The SRS backend is notified about the change via its regular polling. Even in case of an emergency KSK rollover, the change is noticed at most 10 seconds after it became active. Therefore no manually intervention is necessary on the SRS side. There could be a situation in which both the MAIN RSP and the DNSSEC RSP want to tell the other part that there are changes in the zone file (e.g., changes in the SRS and a KSK rollover) at the same time. This causes no problems, because the SRS has a pipeline for any changes and only sends a new unsigned zone to the Signer, when it knows that the signing process is finished and idle. 2. DNSSEC RSP is operated by a different entity. As described in MAIN 3.4, the communication between MAIN and DNSSEC RSP is done via standard AXFR/IXFR zone transfers. This is bidirectional as both the MAIN as well as the DNSSEC RSP could notify the other part about changes in the zone file. Whenever the DNSSEC RSP applies changes to the unsigned zone (i.e., either refreshes some signatures or rolling a KSK or ZSK), a DNS NOTIFY is sent to the MAIN RSP. The SRS backend will then initiate an AXFR/IXFR zone transfer to obtain the newly signed zone. Whether the DNSSEC RSP initiates a standard or emergency KSK rollover makes no difference from the MAIN RSP's point of view. Whenever it receives a NOTIFY, it obtains and publishes the new zone file. Again, there could be a situation in which both the MAIN RSP and the DNSSEC RSP want to tell the other part that there are changes in the zone file (e.g., changes in the SRS and a KSK rollover) at the same time. This also causes no problems, because the SRS can receive NOTIFYs and pull zones in parallel (the DNSSEC RSP is expected to also be able to cope with such a situation, but that's out of scope of this question). The SRS would simply already publish the received new signed version, while it transmits the new unsigned version to the signer, expecting to receive a new signed version some time later.

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

Depending on the registry's requirements, the TANGO Registration System will use the following generic extensions registered in the IANA EPP extensions registry as per RFC 7451: * Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP), RFC 3915 (https://www.iana.org/go/rfc3915) * Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP), RFC 5910: (https://www.iana.org/go/rfc5910) * Launch Phase Mapping for the Extensible Provisioning Protocol (EPP), RFC 8334 (https://www.iana.org/go/rfc8334) * Allocation Token Extension for the Extensible Provisioning Protocol (EPP), RFC 8495 (https://www.iana.org/go/rfc8495) * Change Poll Extension for the Extensible Provisioning Protocol (EPP), RFC 8590 (https://www.iana.org/go/rfc8590) * Registry Fee Extension for the Extensible Provisioning Protocol (EPP), RFC 8748 (https://www.iana.org/go/rfc8748) * Extensible Provisioning Protocol (EPP) Unhandled Namespaces, RFC 9038 (https://www.iana.org/go/rfc9038) * Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP), RFC 9167 (https://www.iana.org/go/rfc9167) In addition, the TANGO Registration System implements these custom EPP extensions, most of which are only used to cover very specific needs of TLDs currently run by the TANGO REGISTRY SERVICES®: * Extension for Auction Information (for specifying auction bids); XML Namespace URI: http://xmlns.tango-rs.net/epp/auction-1.0 * Extension for Language Information (for specifying language/script tags and IDN variants); XML Namespace URI: http://xmlns.tango-rs.net/epp/idn-1.0 * Extension for Domain-Based Privacy (for specifying contact data disclosure on a per-domain basis); XML Namespace URI: http://xmlns.tango-rs.net/epp/privacy-1.0 * Extension for Promotion Codes (for specifying promotion codes to obtain domains at reduced rates); XML Namespace URI: http://xmlns.tango-rs.net/epp/promotion-1.0 * EPP Command for Obtaining Information about Promotion Codes (to check promotion codes for validity and applicability); XML Namespace URI: http://xmlns.tango-rs.net/epp/promotion-info-1.0 * Extension for Domain Name Eligibility (for specifying data demonstrating registrant eligibility in a domain object); XML Namespace URI: http://xmlns.tango-rs.net/epp/eligibility-1.0 * Extension for Contact Eligibility (for specifying data demonstrating registrant eligibility in a contact object); XML Namespace URI: http://xmlns.tango-rs.net/epp/contact-eligibility-1.1 * XML Mark Data Extension (for specifying augmented trademark information during Launch Phases); XML Namespace URI: http://xmlns.tango-rs.net/epp/mark-ext-1.0 It is hereby attested that all EPP extensions to be used are (or will be) registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”); EPP extensions not yet registered with the IANA at the time of writing will be registered prior to deployment. Also, if standardized, IANA-registered EPP extensions should emerge for tasks currently only covered by custom extensions (such as the extension for language information), the TANGO REGISTRY SERVICES® will be adjusted to use the standardized extension instead. Addendum: * Since the original response was written, we've added XML Namespace URIs to all custom extensions listed above. * Also, all custom EPP extensions listed above have been registered in the IANA EPP Extension Registry, as well as in the IANA/IETF registries for XML schema namespace URIs and XML schemas.

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.

1. RDAP Extensions The TANGO REGISTRY SERVICES® uses the following RDAP extensions: * 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 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.

When the staff of a registry operated using the TANGO Registration System learns about about a case of domain abuse (either via the system's connected abuse monitoring system or other sources), they have – after reviewing and confirming the abuse case – various options to deal with the situation, some of which involve setting specific EPP status values, which in turn are mapped to specific RDAP status values in accordance with RFC 8056 ("Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping"). * They can delete the domain in question altogether. The TANGO Registration System allows such a special deletion by registry personnel to happen without the usual Redemption Grace Period (RFC 3915) being applied to the domain. The registry may also put the name on a block list to prevent immediate re-registration. In this scenario, the domain is virtually instantaneously removed from the SRS database, the TLD zone and the registry's Whois/RDAP servers. As a result, the domain no longer shows up in EPP inquiries or RDAP responses, thus it has no status values. Note that a normal deletion with a Redemption Grace Period doesn't make much sense in this situation, as the registrar could just restore it to resume the abuse. * They can set certain "server" states on the domain, which can only be set by registry staff and cannot be removed or overridden by the registrar. The concrete status values set depend on the circumstances of the case. The possible status values are: ** EPP "serverHold" / RDAP "server hold": prevents the domain from being published in the TLD zone; this is most useful to prevent further abuse as soon as the applicable DNS TTLs expire ** EPP "serverUpdateProhibited" / RDAP "server update prohibited": prevents the domain from being updated by the registrar; might be useful to freeze the domain's data (even though the system's historical data will always allow determining the data of any domain at any given time in the not-too-distant past) ** EPP "serverDeleteProhibited" / RDAP "server delete prohibited": prevents the domain from being deleted by the registrar ** EPP "serverRenewProbibited" / RDAP "server renew prohibited": prevents the domain from being explicitly renewed by the registrar ** EPP "serverTransferProhibited" / RDAP "server transfer prohibited": prevents the domain from being transferred to another registrar

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

Upon receipt of an authenticated Notice of Complaint from a URS Provider, the registry will, in accordance with the URS procedures, instruct the TANGO Registration System to lock the affected domain, blocking all changes to the registration data, including transfer and deletion of the domain name (while retaining the domain name in the TLD zone, i.e. the name will continue to resolve). This "URS lock" involves the following domain status values: * EPP "serverUpdateProhibited" / RDAP "server update prohibited": prevents the domain from being updated by the registrar * EPP "serverDeleteProhibited" / RDAP "server delete prohibited": prevents the domain from being deleted by the registrar * EPP "serverTransferProhibited" / RDAP "server transfer prohibited": prevents the domain from being transferred to another registrar It also involves the following status value on all contacts linked to the locked domain: * EPP "serverUpdateProhibited" / RDAP "server update prohibited": prevents the contact from being updated by the registrar Once the complaint was decided upon, the following steps will be taken: * If the registrant was relieved, the registry will use the TANGO Registration System to unlock the domain and return full control to the registrant. This involves removing the status values mentioned above from the domain and its linked contacts. * In case of a determination in favour of the complainant, the registry will, in accordance with the URS rulings, immediately use the TANGO Registration System to suspend the domain name and keep it suspended for the remainder of its registration period; this means that the domain will remain locked and that the domain's name servers are redirected to an information web page supplied by the URS provider. This redirection of the name servers does not involve additional EPP/RDAP status values being added. The entire process is aided by the TANGO REGISTRY SERVICES®, which is capable of automatically * receiving e-mails from URS providers * verifying the authenticity of such e-mails, using ICANN's URS provider public PGP key repository * creating tickets in the internal issue system, providing a workflow for the URS case * (un-)suspending domains based on the steps reached in the URL case workflow * informing the affected registrar and the URS provider about the measures taken

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 attached state diagrams depict the typical life cycle of a domain. In the following, the triggers, states and transitions involved in the life cycle (denoted by capital letters in parentheses) are described in detail. Blue boxes denote domain states, yellow boxes denote actions caused by registrar commands, grey boxes denote automatic actions by the system, white boxes denote timed conditions reached at some point in the life cycle. Domain Creation [A] With a valid "create domain" command, a corresponding domain object is created. Its expiration date is set according to the period specified in the command. The domain enters the 5-day Add Grace Period (AGP). [B] The domain is registered. If at least two name servers are present and the domain has no "hold" status, it is published in the TLD zone. Domain Update [C] With an "update domain" command, the domain is modified in the repository. The domain remains in the registered state [B]. Should the update cause a "hold" status (or remove all name servers), the domain is no longer published in the TLD zone. Domain Renewal [D] If a domain reaches its expiration date, the automatic renew process is initiated. [E] With reaching its expiration date, the domain enters the 45-day "Auto Renew Grace Period" (ARGP). [F] If the end of the ARGP is reached before the domain is deleted, the registrar is charged for the renewal. [G] After renewal, the domain's expiration date is increased. [H] If the registrar sends an explicit "renew domain" command, the domain's expiration date is increased accordingly. The registrar is charged accordingly. The domain's 5-day "Renew Grace Period" starts. Domain Deletion [I] With a "delete domain" command, the deletion of the domain is initiated. [J] If the domain is in its AGP when the delete command is received, it is released immediately. [K] The domain is available for re-registration. This marks the end of the domain's life cycle. If the domain was in any grace period upon deletion, the related charges are refunded. Domain Restoration [L] If the domain is not in its AGP upon deletion, it enters the 30-day Redemption Grace Period (RGP). [M] The domain is in the RGP, during which it is not published in the TLD zone. [N] If the domain is not restored by the registrar before the end of the RGP, the domain is scheduled for release. [O] The domain is no longer restorable by the registrar and due for release. It will remain in this state for random period (1-5 days) to make the release unpredictable for domain snipers. Afterwards, the domain is released and put into the final state [K]. [P] If the registrar restores the domain within the RGP and also sends the RGP restore report within 5 days, the domain is put back into the registered state [B]. If the restore report is not received, the domain goes back into state [M]. Domain Transfer [Q] A "gaining" registrar (GR) requests to transfer a domain from a "losing" registrar (LR). After receiving such a request, the GR is charged with the transfer fee (1-year domain renewal). [R] The transfer is pending. The system waits for either the 5-day time-out, or for the reception of an approval, rejection or cancellation before the time-out. The LR may approve or reject the transfer; likewise, the GR may cancel the transfer. [S] The transfer was completed successfully. The domain is assigned to the GR and renewed by 1 year. The domain returns to status [B]. A successful transfer starts the domain's 5-day "Transfer Grace Period" (TGP) during which the GR may delete the domain for a refund of the transfer fee. [T] The transfer was unsuccessful, i.e. it was rejected by the LR or cancelled by the GR. The transfer fee previously charged to the GR is refunded.

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

The state diagrams attached to answer 10.1 depict the life cycle. Domain Creation [A] With a "create domain" command, the domain enters the Add Grace Period (AGP). The EPP Grace Period (GP) status (RFC 3915) is set to "addPeriod" (RDAP: "add period") (removed after the end of the AGP). [B] The domain is registered. If no other status values are present, it gets the EPP "ok" status (RDAP: "active"). If no name servers are associated with the domain, it gets the EPP status "inactive" (RDAP: "inactive") instead. While registered, it may also carry these client- or server-assigned status values (EPP / RDAP): * "clientDeleteProhibited" / "client delete prohibited" * "clientHold" / "client hold" * "clientRenewProhibited" / "client renew prohibited" * "clientTransferProhibited" / "client transfer prohibited" * "clientUpdateProhibited" / "client update prohibited" * "serverDeleteProhibited" / "server delete prohibited" * "serverHold" / "server hold" * "serverRenewProhibited" / "server renew prohibited" * "serverUpdateProhibited" / "server update prohibited" * "serverTransferProhibited" / "server transfer prohibited" (also set for 60 days after creation or transfer) Domain Update [C] After an "update domain" command, the domain remains in state [B]. Status values as listed in [B] may be added/removed. Domain Renewal [D] A domain reaching its expiration date (ED) is automatically renewed (even in EPP status "clientRenewProhibited" or "serverRenewProhibited", which only prohibit explicit renewals by the registrar). [E] The domain enters the 45-day "Auto Renew Grace Period" (ARGP), during which it carries the EPP GP "autoRenewPeriod" status (RDAP: "auto renew period"). [F] At the end of the ARGP, the "autoRenewPeriod" EPP GP status (RDAP: "auto renew period") is removed. [G] The ED is increased. [H] With an explicit renewal, the 5-day "Renew Grace Period" starts, indicated by the "renewPeriod" EPP GP status (RDAP: "renew period"), which is removed when the period ends. Domain Deletion [I] With a "delete domain" command, the domain's deletion is initiated. [J] If the domain is in its AGP when the delete command is received, it is released immediately and removed from the RDAP server. [K] The domain is available for re-registration. This marks the end of the domain's life cycle. Domain Restoration [L] If the domain is not in its AGP upon deletion, it enters the 30-day Redemption Grace Period (RGP). [M] The domain is in the RGP, indicated by the EPP status "pendingDelete" (RDAP: "pending delete") and the RGP status "redemptionPeriod" (RDAP: "redemption period"). [N] If the domain is not restored before the RGP ends, it is scheduled for release. [O] The domain is no longer restorable by the registrar. Its EPP status "pendingDelete" (RDAP: "pending delete") is retained, the RGP status is now "pendingDelete" (also "pending delete" in RDAP). [P] If the registrar restores the domain in time, its RGP status is set to "pendingRestore" (RDAP: "pending restore"). If the restore report is also sent in time, the "pendingDelete" (RDAP: "pending delete") and "pendingRestore" (RDAP: "pending restore") status values are removed and the domain goes back into state [B]; otherwise, the domain goes back into state [M]. Domain Transfer [Q] A registrar requests to transfer a domain from another registrar. [R] The transfer is pending. The domain carries a "pendingTransfer" EPP status value (RDAP: "pending transfer"). [S] The transfer was completed successfully. The "pendingTransfer" EPP status value (RDAP: "pending transfer") is removed. The domain returns to status [B]. Its 5-day "Transfer Grace Period" (TGP) starts, indicated by the "transferPeriod" EPP GP status (RDAP: "transfer period"). [T] The transfer was unsuccessful. The "pendingTransfer" EPP status value (RDAP: "pending transfer") is removed, the domain returns to status [B].

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.

The TANGO Registration System supports host objects according to the "Extensible Provisioning Protocol (EPP) Host Mapping" (RFC 5732). It does not use the "hosts as domain attributes" approach, but rather requires proper host objects to represent the name servers used by all domains in the system. In the following, the lifecycle of a host object in the system is described. 1) Host Creation Hosts are created with a "create host" command, received either via EPP or the Control Panel. The command must specify the name of the host to create. Two types of host objects are distinguished: in-zone hosts and external hosts. In-zone hosts are hosts whose name is a subdomain of one of the apex domains managed by the system. External hosts are hosts for which this is not the case. When in-zone hosts are created or updated, the system requires them to carry at least one IPv4 or IPv6 address, as these may be needed for the creation of glue records if the host is used as a name server for the registered domain to which their name is subordinate (its so-called "parent domain"). Conversely, external hosts must not carry IP addresses. While registered, hosts may also carry these client- or server-assigned status values (EPP / RDAP): * "clientDeleteProhibited" / "client delete prohibited" * "clientUpdateProhibited" / "client update prohibited" * "serverDeleteProhibited" / "server delete prohibited" * "serverUpdateProhibited" / "server update prohibited" If no other status values are set in the command, a host carries the EPP "ok" status (RDAP: "active"). 2) Host Update With an "update host" command, the host's IP address (in case of in-zone hosts) may be updated. Also, status values as listed in 1) may be added/removed. Updates to a host are rejected if it carries one of the "update prohibited" status values mentioned above. The TANGO Registration System also supports changing the name of a host under certain conditions, see below for details. 3) Host Transfer When domains are transferred from one registrar to another, the transferred domain may be the parent domain of one or more hosts in the system. Since all in-zone hosts must invariably be sponsored by the same registrar as their parent domain, such subordinate host objects are automatically transferred to the new registrar along with the domain. While the transfer is pending, the hosts whose parent domain is being transferred carry the EPP "pendingTransfer" status value (RDAP: "pending transfer"). 4) Host Deletion With a "delete host" command, the host object is removed from the system, as long as certain conditions are met (see below) and the host does not carry one of the "delete prohibited" status values mentioned above. Relationship between Domains and Hosts Domain and host objects are closely interrelated in the system. If a host is used as a name server in any domain, the host carries the synthetic EPP status value "linked" (RDAP: "associated"). This status may appear in conjunction with other states, including the EPP "ok" status (RDAP: "active"). The relationship between domains and hosts also establishes additional rules regarding their lifecycle. In particular, the following conditions apply: * In-zone hosts may only be created if the domain to which their name is subordinate exists and is sponsored by the same registrar as the host to create. * A host referenced by domains sponsored by other registrars may not be renamed. Also, when renaming a host from an in-zone host to an external host (or vice versa), IP addresses must be removed or added, respectively. If the resulting host is an in-zone host, its parent domain must exist and belong to the same registrar as the host. * Deleting any host is only allowed if it is no longer linked to any active domains in the system. * Deleting any domain is only allowed if it no longer has subordinate hosts in the system.

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

The TANGO Registration System supports contact objects according to the "Extensible Provisioning Protocol (EPP) Contact Mapping" (RFC 5733). Note that this is optional; if a registry decides on a policy that does not require contact information from registrars ("Minimum Data Set model"), support for contact objects and their association with domains can be configured to be disabled entirely. Also note that the transfer of contact objects from one registrar to another is not supported. In the following, the lifecycle of a contact object in the system is described. 1) Contact Creation Contacts are created with a "create contact" command, received either via EPP or the Control Panel, supporting the full set of data described in RFC 5733. While registered, contacts may also carry these client- or server-assigned status values (EPP / RDAP): * "clientDeleteProhibited" / "client delete prohibited" * "clientUpdateProhibited" / "client update prohibited" * "serverDeleteProhibited" / "server delete prohibited" * "serverUpdateProhibited" / "server update prohibited" If no other status values are set in the command, a contact carries the EPP "ok" status (RDAP: "active"). 2) Contact Update With an "update contact" command, the contact's data (as described in RFC 5733) may be updated. Also, status values as listed in 1) may be added/removed. Updates to a contact are rejected if it carries one of the "update prohibited" status values mentioned above. 3) Contact Deletion With a "delete contact" command, the contact object is removed from the system, as long as certain conditions are met (see below) and the contact does not carry one of the "delete prohibited" status values mentioned above. Relationship between Hosts and Contacts There is no relationship between host and contact objects in the system, they exist independently from each other. Relationship between Domains and Contacts Domain and contact objects are closely interrelated in the system. Each contact object may be referenced in one or more domains in a particular role. Possible roles are "registrant", "administrative", "tech" or "billing". The TANGO Registration System allows registry operators to configure which contact roles are required, optional or prohibited in a domain. If a contact is referenced in any role in any domain, the contact carries the synthetic EPP status value "linked" (RDAP: "associated"). This status may appear in conjunction with other states, including the EPP "ok" status (RDAP: "active"). The relationship between domains and contacts also establishes additional rules regarding their lifecycle. In particular, deleting a contact is only allowed if it is no longer referenced in any role in any active domains in the system. Deletion of Orphaned Contacts Generally, for auditing purposes, the TANGO Registration System retains all historical data of registered objects (i.e., all current and previous versions of contacts, hosts and domains). However, mechanisms (described below) are in place which automatically remove obsolete data, including orphaned contacts. Deletion of Old, Orphaned Contacts All non-deleted contacts which have not been modified for more than one year and have also not been referenced in any domains for more than one year are deleted from the system. Registrars are informed about this unsolicited deletion via poll messages according to RFC 8590, "Change Poll Extension". Removal of Deleted Contacts All deleted contacts which were deleted more than two years ago are automatically removed from the system, along with all their versions which existed before their deletion. Removal of Old Contact Versions All old contact versions whose validity range (time period during which they contained "current data") ended more than two years ago are automatically removed from the system. Affected active contacts remain fully usable, but their version history is truncated.

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.

The TANGO Registration System provides a comprehensive escrow module to create full deposits of the registry data that existed in the repository at any given point in time. The system's database is designed to store historical data of all objects, allowing access to an object's state at the reference date and time of the escrow (the "watermark date"). Likewise, the module can generate differential deposits containing the differences between the registry repository states at the watermark date and a base date. When operating a "thick" registry, the deposits include, in addition to information about registrars, domains and name servers, the data of all the contacts stored in the registry repository, along with their associations with domains in specific roles. The escrow module collects the data based on the specified escrow type (full or differential), watermark and base date, and emits the collected data as XML. The module includes a scheduling mechanism that facilitates the fully automated creation, post-processing and transfer of full and differential deposits in configurable intervals. The mechanism is designed to ensure a reliable data transmission to the target (e.g. the Escrow Agent) and is able to retry/repeat submissions should they fail for any reason (such as a temporary outage of the receiving system). Deposit Schedule The escrow module as described above is used to create full and differential deposits as required by Specification 2 of the ICANN Registry Agreement. Registry data sets are created as described above and transmitted to the designated Escrow Agent in a secure way on a weekly and daily basis as follows: * The SRS deposits a complete set of registry data into escrow on a weekly basis, each Sunday. The snapshot captures the state of the registrar's data in the repository as of 00:00 UTC on each Sunday. * The SRS deposits differential registry data into escrow on a daily basis, on each day except Sunday. Each daily differential deposit contains transactions that have been committed between the last full or differential deposit and 00:00 UTC on the day the deposit relates to. Deposit Creation and Transfer According to the schedule described above, the escrow module prepares and transfers the escrow data deposit files as follows. Compression, encryption and signing during the process are done according to the OpenPGP specification (RFC 4880), using Public PGP keys previously exchanged between the registry operator, the Escrow Agent and ICANN. 1) The XML file representing the full/differential deposit is created according to the XML data format defined by RFCs 8909 and 9022 and file naming conventions in Specification 2. 2) The resulting deposit file aggregated in a tarball. 3) The tarball is compressed and encrypted using the Escrow Agent's public PGP key, using one of the encryption methods and algorithms suggested in Specification 2. 4) If the resulting file exceeds the file size limit imposed by the Escrow Agent, the deposit file is split accordingly. 5) A digital signature file is created for each resulting file, using one of the signature methods and algorithms suggested in Specification 2. 6) The resulting escrow/signature files are transferred to the Escrow Agent through a secure mechanism. 7) Along with each deposit, a report is created in accordance with the "draft-lozano-icann-registry-interfaces" specification. and submitted via ICANN's "Registry Operator Reporting" API. Escrow Extensions If required, the TANGO Registration System can include extension data required for providing additional registry services in its escrow deposits. The inclusion of such extension data will be done using the XML "extension schema" mechanisms specified by RFC 9022 and implemented in close collaboration with ICANN before rollout. At the time of writing, no such extensions exist.

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

* bauhaus * bayern * gmx * ifm * man * nrw * sap * tel * whoswho There have not been any service level agreement violations in the last 6 months.