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, …}).

Definitions : LGR_variants(t) = the set of allocatable second‑level variant labels computed by applying the LGR applicable to TLD t to the source label s₁ (RFC 7940). This set includes the source label itself and all variant labels permitted by the LGR's variant rules. Different TLDs t may be governed by different LGRs; the system loads the appropriate LGR for each TLD independently. T = the set of all allocated variant TLD labels, comprising the primary TLD t₁ and all TLD‑level variants t₁ᵥ₁, t₁ᵥ₂, … that have been delegated to the same registry operator. Our implementation enforces the "same entity" requirement via a rule-driven, entity-bound framework aligned with ICANN's IDN Guidelines, IDNA2008, and the Second‑Level Reference LGR. The core principle—all allocatable variants across second‑level labels and variant TLDs (e.g., {s1, s1v1, …} under {t1, t1v1, …}) belong to the same entity or withheld exclusively for that entity—is enforced in three stages: 1. Pre‑Registration – Set Definition & Validation The full Allocatable Set is the Cartesian product: Allocatable Set = { (s_variant, t) | s_variant ∈ LGR_variants(t), t ∈ T }. All combinations validated against IDN table rules; applicant's identity verified as sole eligible entity for the whole cross‑TLD set – no partial allocation permitted. 2. Registration – Entity Binding & Technical Locking Upon registration of global primary key (e.g., s1.t1), we associate all variants with same registrant and pre‑reserve all corresponding second‑level labels under every variant TLD. All FQDNs in the Super Bundle activated with identical DNS delegations (NS records) for original registrant. EPP rejects any registration request for any variant under any variant TLD from an entity other than the s1.t1 holder. Registration data (registrant, contacts, NS delegations, statuses) synchronises across all variants. Each variant is an independent registry object; primary updates propagate to all variants in bundle. For DNSSEC, each activated variant is an independent DNS delegation with its own DS record set. System supports both RFC 5910 interfaces (dsData/keyData) and recommends keyData – registrars submit same DNSKEY across variants, registry generates appropriate DS record per FQDN. EPP <update> on primary does not auto‑propagate DNSSEC to variants; each variant's DNSSEC managed independently via variant‑specific extensions. 3. Post‑Registration – Enforcement & Lifecycle Sync All variants inherit lifecycle of global primary key (s1.t1). Renewal, transfer, or deletion of s1.t1 simultaneously applies to all cross‑TLD variants. Quarterly audits verify ownership consistency across Super Bundle; any variant under any variant TLD allocated to third party is a violation, handled via UDRP, with unauthorised variant use presumed as cybersquatting. For registries operating under a minimal data set model (where registrant data is not directly held), we supplement with: - RRA Contractual Obligations – Registrars contractually guarantee the primary and all variants belong to the same registrant entity. Breach constitutes material non‑compliance, leading to domain deletion, penalties, or registrar suspension. - Compliance Audits & Automated Checks – Quarterly audits require registrars to attest entity identity consistency. Internal scripts periodically scan the Super Bundle table for registrant ID mismatches across variant TLDs, triggering alerts and freezing affected domains. - Lifecycle Locking as a Safeguard – All variants across all allocated TLD variants are technically locked to s1.t1's lifecycle, ensuring any transfer or deletion affects the entire cross‑TLD set. This bundling, combined with RRA obligations, provides robust enforcement even without direct access to registrant personal data. These measures collectively enforce the "same entity" principle across all allocated variant TLD labels, without requiring the registry to store registrant personal data.