Dear LD PDP WG,

Please see attached the Outcomes, Action Items, and Notes from Meeting #22 on Wednesday, 8 October 2025.

[OUTCOMES]

The blocking of a TLD removed from the root zone should only be in case it is applied for by a different entity. If it is to the existing set then there doesn’t need to be a waiting period. In case a different entity applies for it then we need some rules
Suggestion to create a special reserve name category for subsequent rounds to block or not allow those strings like other categories. Not reserved fully, only if outside of the set.

[ACTION ITEMS]

Staff to add language indicating that there need not be a waiting period of the same entity applies for the TLD and treats it as a set
Staff to discuss with LT language to create a special reserve name category to block dropped names outside of the set if not the same registry operator

[NOTES]

Welcome and SOIs
Recap of Meeting #21

Reviewed the slides and discussed how action items were resolved
PR 35-38 continued discussion
Two major points to discuss: 1) how and if LD applicants can voluntarily remove one or multiple TLDs (conditions for that) and 2) what provisions are necessary to remove them?
Reviewed EPDP-IDNs P1 Recs 8.10-8.13 for reference and discussed the implications for the LD PDP
If we remove the base ASCII likely all other IDN diacritic TLDs would have to be removed from the root zone
Trying to solve something that is already solved in the agreement. Upon termination there is transition. Normal case the TLDs will be transitioned to another operator, and if not possible then it could go to EBERO in exceptional circumstances. Against having a new exception in this case.
We are not trying to make additional rules to retire a TLD, make additional restrictions to remove a root TLD zone, to make the rules if for some reason some of these TLDs get removed from the root zone what are the consequences for the set.
Joseph, ICANN org, this is in the RA that ICANN can look to the public interest and look at usage at the 2nd level to determine whether the TLD will be transitioned to a new TLD operator, EBERO, or terminated. This applies to all TLDs not just .brand.
There is a possibility to remove the ASCII and retain one of the diacritic TLDs is one of our options. IDN EPDP solution is that the whole set needs to be removed and they have a different base because all the variants depend on the primary one. Our case the TLDs are more or less independent and put in a set
We need additional rules or policies when one or more TLDs get removed from the root zone for any reason. Due to the structure of the set, we are making those recommendations to make it harder to remove TLDs with consistency of the set
Discussed difference between EPDP-IDNs and LD PDP
Reviewed the slides that if the set is dissolved as a total the TLDs are independent and no relation needs to be upheld
We can look at the ccPDP4 (10 years) or the RA for .BRAND for those provisions (2 years following expiration date). Two situations these policies we could use for our case when a TLD within the set is removed so a TLD applied for outside of the set again.
Sarmad, ICANN org, pointed out key differences with our TLDs in both of these cases the recommendations are generally talking about a TLD which when it goes away and potentially comes back there is no possible confusing TLD that is delegated at the same time. In our case, if one remains and one is dropped, then they will be two competing TLDs that can confuse the end users. Second, in some ways even though they are joined by base ASCII these strings are not .BRAND and not ccTLDs.
Trying to find a solution where one TLD is removed from the set, should that be directly available or some rule that blocks it for some period of time?
As a part of ccTLD and IDN EPDP where decisions were taken in both working groups were a different situation. In LD PDP it is possible to delegate LD and diacritic to separate registry operators. Practically there is a likelihood of user confusion. That is what mainly the deselection and string sim panel is looking at. If either ASCII or diacritic is removed for any reason. We might be delegating to a registry operator for a period of time and we have to restrict it for some time for confusingly similar issues
Discussion TLDs should not ever be delegated ever to this removal. If we can’t say forever 10 years
If one of those TLDs gets removed even with PDP active different entities could apply for it, but it will likely get rejected due to string sim review panel. Suggestion for a long as we can afford.
This blocking should only be in case it is applied for by a different entity. If it is to the existing set then there doesn’t need to be a waiting period. In case a different entity applies for it then we need some rules
Discussed how to deal with this through three options in the slides
35 and 36 can be applicable at the same time. They are not mutually exclusive. 35 is about the removal of the ASCII gTLD and 36 is about the LD label. In the IDN-EPDP that would be the primary and variant
The option that allows for keeping 1 of the TLDs and retains some additional rules for keeping some rules for the same registry.
This is extremely unlikely case if there are lots of registrations then it is unlikely to be dropped.
Option 2 gaining consensus, but have some rationale of making it 2 years vs. 10 years. Unless we understand the rationale it would be hard for us to choose either way. Would need a number of years here
Restriction not meant for the same registry operator wanting the TLD again. It would be for any entity outside of the set, even though it would be likely they would be rejected from the string sim panel, but we cannot be certain. This TLD is safe from being used outside the set when it has been used in the set before
Unlikely this would happen because it is expensive and a lot of work.
There could be some kind of rule that would ensure that it would be caught in string sim eval rather than x number of years
Sarmad, suggestion to create a special reserve name category for subsequent rounds to block or not allow those strings like other categories. Not reserved fully, only if outside of the set.

3. Review of Preliminary Draft Recommendations

4. Preparation for ICANN84

5. Next Steps

6. AOB

John R. Emery, Ph.D.

Policy Development Support Senior Specialist

Generic Names Supporting Organization (GNSO)

Internet Corporation for Assigned Names and Numbers (ICANN)