Hi team, as discussed last Wednesday, we still had to introduce some new policy to deal with the exempted cases. In particular, how the exemption process is finished and what the consequences are. In general, we want the choice to stop the exemption process with the Registry operator and not forced upon them. After all, they may need to change their RSP in order to be able to run an ASCII/LD TLD set. This must remain their own decision. We discussed this with the leadership team and came up with the following Recommendation to be added to our final recs: *Final Recommendation Y (most probably to follow Rec.6)*: /The exemption of gTLDs may result in one of the following circumstances: Y.1 if only a single gTLD remains, and all others have ceased to exist among the exempted ASCII gTLD and all its corresponding Latin diacritic gTLDs; or Y.2 if all gTLDs among the exempted ASCII gTLD and all its corresponding Latin diacritic gTLDs belong to the same gTLD registry operator and are operated by the same Registry Service Provider (RSP), and the gTLD registry operator elects to convert the existing stand-alone gTLDs into an ASCII/Latin Diacritic gTLD set. In consideration of circumstance Y.1, where only a single gTLD remains, the gTLD registry operator wishing to apply for a new corresponding ASCII gTLD or Latin diacritic gTLD(s) of its remaining gTLD must submit an application during an application round in accordance with Final Recommendations 3 and 4. In consideration of circumstance Y.2, where an ASCII gTLD and its corresponding Latin diacritic gTLD(s) belong to the same gTLD registry operator and are operated by the same RSP, the gTLD registry operator may elect to convert all existing stand-alone gTLD(s) into an ASCII/Latin Diacritic gTLD set by submitting a contractual change request to ICANN org outside of any application rounds, provided that no new gTLD is added at the same time and/or a part of the same request. When such conversion is undertaken, the request must include all stand-alone corresponding ASCII/Latin Diacritic gTLD strings that constitute the set. A partial conversion to an ASCII/Latin Diacritic gTLD set is not permitted./ Then, in addition to this new Recommendation, we need to deal with the case that if two existing (exempted TLDs) are merged into an ASCII/Latin Diacritic gTLD set, there can be second level domains, which need to be exempted. If we start with the separate TLDs .cafe and .café, and in both TLD the domain example.cafe and example.café exist, then after the set creation, those two registrations must be exempted from the same entity principle (just like in the IDN EPDP). For this, we adjusted Recommendation 42 as follows (the new part is in red). *Preliminary Recommendation 42 (Final Rec.# TBD):* /Generally consistent with Final Recommendation 3 from the EPDP-IDNs Phase 2 Final Report, immediately prior to the policy effective date of the “same entity” principle as set out in Preliminary Recommendation 40 (Final Rec.# TBD), the existing variant domain names that do not conform to the “same entity” principle must be exempted. Furthermore, where the exempted ASCII and its corresponding Latin diacritic gTLD(s) are converted into an ASCII/Latin Diacritic gTLD set in accordance with Final Recommendation Y, any existing second-level domain names that do not conform to the “same entity” principle must be exempted. This means that there will be no change to the contractual or allocation status of such existing domain names. The requirement of having the same registrant and the same sponsoring registrar will not be applied retroactively. The gTLD registries operating an ASCII/Latin Diacritic gTLD set must determine ASCII/Latin Diacritic Domain Sets for each exempted label and protect from registration all labels in all such ASCII/Latin Diacritic Domain Sets, as appropriate. /Please take a look at these changes and let us know, if you are ok with them or if there need to be any changes. In case you have any questions, please let us know. Please review and provide any comments by the end of this week, i.e., Friday, 10 July 2026, at 23:59 UTC. Then we can finalise the Final Output and send it to you for review. Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP:Michael.Bauland@knipp.de Software-Entwicklung E-Mail:Michael.Bauland@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp Zertifiziert nach DIN ISO/IEC 27001:2017