Hello LD PDP WG Members, Please find the attached outcomes, action items, and notes from Meeting #38 on 24 June 2026. [OUTCOMES] * No objections from the WG to discard Recommendation 18 and 19 * PR14 agreement on path forward. [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE...> and the proposed draft after each WG Meeting and provide input, if any. * Leadership and Staff to discuss IG40 with Sarmad to revise based on discussion. * Leadership and Staff to return to Rec X based on discussion. [NOTES] 1. Welcome and SOI Updates 2. Recap of LD PDP Working Session at ICANN86 a. Key Outcomes and Action Items * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQAwR> and shared updated wording for PR39. How is 39.3 implementable? This would be solved by IG40 would be new that 39.3 would be allocatable variants. LGR should be developed for a second level. * IG40 discussed, the idea to broaden this is that not every registry operator has to create a second-level LGR, rather to have ICANN develop one to have more consistency there. * Sarmad commented ICANN can be directed to do this. Had a question about designing reference LGRs. It would be closely worked with the script community to design them. The definition of variants and which is allocatable vs. blocked. Making them all allocatable would be another layer. Why all could/should be variants if there is a possibility to consult with the community in the process would improve the process. A practical solution would be for script experts to debate amongst the parameters. Should be a discussion on what should/could be allocatable. * Meaning of this for the diacritic variants may not be undefined as not being variants. Good suggestion to include the script communities. * IG40 discussed in-depth and the purpose here is to establish protection for user-confusion for variants. Does this work actually need to be done. All variants here should in principle should be allocatable unless there is a strong reason for doing so. * The reduced character set is meant with the second part allowing for adaptation to each registry needs. They can drop some characters from their repertoires. IG41 would have registries to set an upper limit. * IG40 there was skepticism of having a community to generate a huge group of variants on this topic like the Latin Generation Panel * At the top-level there cannot be diacritics as variants. But at the 2nd level diacritics can be defined as variants and many like .cat already do this. It should really be variants in this IG40. If they don’t have to take care of variants and diacritic sets, only with LGRs and variants, both technically and policy wise. * “Minimum variant relationships” question. How does one ensure that the relationships are retained and not removed? Minimum variant relationships could be updated. The idea is that all diacritic characters are considered variants. Registries may change the latin script diacritic LGR may change it because they don’t want to use the whole set of latin characters. The intent is to say the registry can change the LGR, but not drop the variant relationship between diacritic characters. * Should emphasize that none of this changes the RZ-LGR, this is only at the second-level. Recommendations should just task ICANN org to come up with something workable and registries could choose to adopt it and customize it for their own needs. * Sarmad: when everything is allocatable variant apart from being not very conservative as LGR design has a conservatism principle. This is in some ways going in the other direction. There can be very significant amount of corner cases for a large set of diacritics. Starting with the cases clearly not possible and still allocatable seems like something it is normally not designed for. This is why giving an overall allocation, the script community could look at it to make a usable set, but not make an unlimited allocatable set. * Sarmad: When something is blocked it is easier to make it allocatable, which is why the conservatism principle as this will be a reference LGR. It can be changed per the registry requirements, that is flexible. Making things slightly more conservative does not close doors for a different solution. * Michael: Intention of the LGR to have the same entity set to be upheld and the disposition value of blocked or allocatable. Could instead say something like the reference LGR created by ICANN makes all these variants blocked per default, but registry is free to make them allocatable if their language or use case requires this. * IG41 agreed upon previously and summarized in the slide * Recommendation X overview given in the slides<https://icann-community.atlassian.net/wiki/x/AQAwR> reminding the WG of PR3. * Rec X proposed language clarifies that one can add to existing TLDs. * There could be a similar ruling for variants belonging to separate entities and could be exempted from the rules, but no new cases could be granted. * Sarmad: sharing with string sim panel currently, there is not a clear mechanism to take this message to SSR panel. Their work is dependent on policy from SubPro and IDN-EPDP Phase 1. * Recommendation X would be discussed again next week based on Sarmad’s input. * PR18 and PR19 discussed based on the Board input provided at ICANN86 summarized on slide<https://icann-community.atlassian.net/wiki/x/AQAwR> 13 and the Board email sent via LD PDP mailing list on 24 June. * The WG tried to follow IDN-EPDP and they were copied and follow the same recommendations. So this was indeed a precedent following that. * Application fee is a cost recovery principle and that was fine. Operational cost is a different topic. IDN PDP was to incentivize adoption of IDNs and variants to make it easier to apply for these. The mandate for the LD PDP is the opposite, it is an exception process. * The Board feels that this is a precedent, the fact of saying how much the fees should be is something that is in ICANN org’s discretion. This is not in the remit of the PDP. Even if the WG believes it has reached the right conclusion, it is not worth hitting a wall with the Board and should not delay the whole thing because of these recommendations. Proposed deleting these recommendations. * How strongly does the WG feel about this? Is it worth delaying the whole PDP? Proposal to change language to should and could be at the implementation decision level. * Path forward: Discard recommendations 18 and 19 as they are not necessary for the policy to work. * Suggestion to change the language of 18 and 19 for alternate language to get to the intent of the WG to increase likelihood of acceptance by the Board. Suggestions to change the language from must to should * Prices are not in the remit of the PDP. * Changing must to should would not have much of an effect. The Board is saying please don’t make the recommendations. Policy development groups cannot set ICANN fees period. Proposal to simply take away these recommendations. Can explain in the final report that this was debated, but it is not within the remit of the WG. * Whether it is suggested in should or must, that is not allowed for the WG to discuss. * Steve: concern exists on the number of applicants or operational support needs at the time of implementation. He emphasized the concerns of Amadeau, that it is not within the remit. * WG did not object to discard recommendations 18 and 19 3. Review of LD PDP Initial Report Public Comment * Reviewed the slides<https://icann-community.atlassian.net/wiki/x/AQAwR> for the HRIA<https://docs.google.com/spreadsheets/d/1LkcqfulRQiNEM4tjFzCeiISbU1p5x5UuE_Hv...> public comment. The Public Comment is mostly geared towards future PDPs from Public Comment review as there are no actions for this. * PR 14 was updated to the group for the proposed path forward. 14.3 and .BRAND. Clarified on slide<https://icann-community.atlassian.net/wiki/x/AQAwR> 18 for a stricter rule than trademark law as determined by the EPDP-IDNs. * PR14 resolved 4. Next Steps 5. AOB Thank you, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>