IDN.2.4.Same Entity Allocation
Describe how compliance will be achieved for second-level variant labels that arise from a registration based on a second-level IDN table where 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 the TLD.
Response
Second-level IDN variant compliance uses a rule-driven, entity-bound lifecycle management framework per ICANN’s IDN Implementation Guidelines, IDNA2008, and the Second Level Reference LGR with Full Variants. The core rule — all allocatable variants in a set are assigned to the same entity or reserved exclusively for them — is enforced via three layers:
1. Pre-Registration: Label Set Definition & Validation. Formalize a complete, immutable set of allocatable variant labels from the second-level IDN table (Unicode normalization, script, or transliteration variants of core label s1). Validate against the IDN table’s rules to prevent omissions or errors. Verify the applicant’s legal identity and confirm they are the sole eligible entity for the entire set; no partial allocation to third parties is permitted.
2. Registration: Entity Binding & Technical Locking. Upon s1 registration, automatically associate all allocatable variants (s1v1, s1v2, …) with the same registrant. Variants are activated immediately with the same DNS records for only the original registrant. The EPP system is configured to reject registration requests for variant labels from any entity other than the s1 holder. WHOIS/DNSSEC records are synchronized to reflect the same registrant for all active variants in the set.
3. Post-Registration: Enforcement & Lifecycle Sync. All variants inherit the lifecycle state of s1 (renewal, transfer, deletion). If s1 is transferred, all variants are transferred to the new entity; if s1 is deleted, variants are deleted. Quarterly audits verify variant ownership consistency and ensure no variant is allocated to a third party. Disputes are handled via UDRP, with a presumption that unauthorized variant use constitutes cybersquatting.
The above framework assumes the registry has access to registrant data. Under a minimal data set model where the registry does not directly hold such data, the same outcome is achieved through supplementary measures that shift compliance obligations to the registrar via contractual mechanisms and audit rights:
Additional Mitigations for Registries Operating Under a Minimal Data Set Model
1. Contractual Obligations in the RRA: The Registry-Registrar Agreement will explicitly require the registrar to guarantee that the primary domain and all allocatable variants are assigned to the same registrant entity. Any allocation to different registrants, by mistake or intent, is a material breach, subject to domain deletion, financial penalties, and possible suspension or termination of the registrar’s accreditation.
