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

Our Variant Bundle architecture supports the "Same Entity" policy through: 1. Technical Safeguards: At variant allocation/transfer, our system validates registrant consistency using a registry-side fingerprint ( <contact:id> combined with PII information), rejecting mismatched requests with EPP 2306. Subsequent registrant updates remain under registrar authority, with optional policy flags to enforce bundle-wide synchronization. 2. Contractual Recommendations: We advise Registry Operators to include explicit RRA provisions requiring identical registrant id across Variant Bundles, with defined corrective actions for non-compliance. Template language is available upon request. 3. Operational Monitoring: Periodic audits detect registrant divergence; a standardized workflow (notify registrar → 15-day cure period → escalation) ensures timely resolution. This layered approach respects registrar authority while providing practical safeguards for "Same Entity" compliance. Regarding the Data model and Implementation of the "Same Entity" Binding 1. Operational Data Model: Our registry system actually operates under the Thick model. We require registrars to transmit the registrant's contact information (PII, such as email addresses) to the Registry via standard EPP commands. Therefore, we do not operate under a Minimal Data Set (Thin) model, and we strictly do not use any non-EPP communication channels to receive registrant contact information. 2. Fingerprint Calculation Logic: Because we operate in a Thick model and receive all necessary data via standard EPP, our system calculates the fingerprint for "Same Entity Allocation" using the following logic: • Primary Identifier (<contact:id>): When the registrar provides a <contact:id> (Registrant ID) in the EPP command, our system directly uses this <contact:id> string as the primary fingerprint to bind and manage the variant set for the same entity. • PII-based Fingerprint (Supplementary): To ensure robust and precise identification of the underlying entity, our system also utilizes the registrant's contact information (PII) received via the EPP payload to calculate a cryptographic hash This PII-based fingerprint serves as a supplementary mechanism to accurately confirm the identity of the registrant and enforce the "Same Entity" policy in case of the missing <contact:id>. In summary, by operating in a Thick model, we possess both the <contact:id> and the underlying PII data via standard EPP. This allows us to effectively enforce the "Same Entity Allocation" policy without relying on any custom EPP extensions or external communication channels.