Applicant Information

Does or will the RSP implement the IDN Guidelines 4.1?

Yes

Describe how this RSP’s implementation will comply with the following: For second-level variant labels that arise from a registration based on a second-level IDN table, all allocatable variant labels in the set must only be allocated to the same entity or withheld for possible allocation only to that entity (e.g., all allocatable second-level labels {s1, s1v1, …} under all allocated variant TLD labels {t1, t1v1, …}).

We ensure all allocatable IDN variants are controlled by a single entity, adapting our enforcement method to the TLD's specific model. We operate a Unified Shared Registry System (SRS). The primary TLD and all variant TLDs in a TLD set reside on the same application platform and share the same relational database backend. Because they share a common datastore, there is no need to synchronize independent systems. The "variant set" uniqueness constraint acts as a global lock across the entire TLD set, ensuring immediate transactional consistency for all variants. The thin or thick models are policies configured per TLD (all TLDs within the same variant set have the same policy). Enforcing Same Entity in the Full Registration Data Model: Our registry system technically enforces this. When a domain:create command is received for a variant label: The system checks if there is any domain registered from the same variant set. If existing domains are found, the system compares the registrar ID of the registered variant with the ID of the requesting registrar AND compares the Registrant ID provided in the incoming EPP command against the Registrant ID of the existing domain(s). If the registrar IDs or Registrant IDs do not match exactly, the transaction is rejected with an EPP error (2201 response code), preventing the creation of a variant under a different entity. Enforcing Same Entity in the Thin Registration Data Model: In a "Thin" model where Registrant data is not stored in the Registry, the "Same Entity" policy is enforced contractually through the Registrar. The system performs the same variant lookup as described for full registration data model. It compares the registrar ID of the incoming request against the Sponsoring Registrar of the existing domain(s). If they do not match, the request is rejected (2201 response code). Consequently, all variants in a set must reside with the same Registrar. The obligation for that Registrar to ensure the Registrant is also the same is enforced contractually via the Registry-Registrar Agreement (RRA). Our registry system allows independent host objects for allocated variant labels. While the entity (Registrant/Registrar) must be synchronized across the variant set to prevent user confusion and legal disputes, the technical configuration (Nameservers/Host Objects, DS Records) is managed at the individual domain object level. This allows registrants the flexibility to configure variants differently (e.g., redirecting one variant to a specific site or localized landing page) if desired.