Dear LD PDP WG, Congratulations on completing the worksheet of EPDP-IDNS Phase 1 today! Attached below are the decisions, action items, and notes for the two working sessions today at ICANN83. Outcomes, Action Items, and Notes LD PDP Working Session #1 ICANN83<https://icann-community.atlassian.net/wiki/x/AQBmD> on Wednesday, 11 June 2025 [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQOU...> of relevant recommendations and wrote the consensus in the decision tab [ACTION ITEMS] 1. None [NOTES] Working Session #1 ICANN83 Slides<https://icann-community.atlassian.net/wiki/download/attachments/208011265/ic...> 1. Welcome and SOIs 2. Background and Progress Update of LD PDP * Michael gave background and updates on the progress of the WG to date. 3. Key Achievements a. Mark gave an overview of the successes and the fast pace of this PDP as a credit to all in the WG and staff 4. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/policy...> a. Continue with the Review of EPDP-IDNs P1 & P2 Outputs (Worksheet<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHaG...> to Leverage Outputs) * 7.11 Comment that this is true unless some of them are terminated and there is a process and it could happen. Possible to be undelegated or frozen. Covered at some other recommendation within EPDP IDN * Do we need this/want this for our PDP as well? Except for the unlikely case mentioned this should be the case. This is reasonable due to same entity principle * Q: Would this also apply to 7.12 and 7.13? A: 7.12 escrow is a different argument they could be escrowed. Agreement this should also be the case for our TLDs * 7.13 Separate files? Agree and copy that policy * 7.14 Concern about the language where there could be new restrictions. Both for the case applied for at the same time, or existing and a variant is added. All of these cases it should apply. * Generally the principle should apply, but could be orange instead of green. We cannot say at this time whether the same contractual agreements will apply even though it may be likely * 7.14 The word allocatable variant is a bit confusing as it means potentially different than its initial meaning. Spirit could be right, but the wording could bring us in the wrong direction. ORANGE cannot copy exactly and rework when we do our recommendations for allocatable variants will have to be rephrased in our context for ALL recommendations * 8.1 comment that this recommendation this was not for management per se, but for security of the whole system. That concern of security will be equally applicable here. PDP may make a decision based on this. * Situation is a bit different here whether we have 1 or 2 diacritics and one could apply for many diacritics we don’t need a restriction here and use a similar approach as IDN EPDP * IDN part was considered because of SSAC report that asks for a limited number of variant TLDs we have not even reached there and there is no SSAC note on this, but likely the principle applies, but we will have to revisit. * Key difference here, is we have deferred discussion on fees and will need to be revisited later * Agreement to revisit this later * 8.2 explanation of meaning that so far there has not been any experience with variant TLDs on user experience and how registrants work with this. ICANN should create some guidelines to check whether variants become active are used in a way that is predictable for user experience * 8.3 Not applicable for our PDP is consensus * 8.4 perhaps nice to have but not necessary, some disagreement here. We do not know yet how the application will work. Whether it will be single application or separate application. Makes sense to postpone this discussion when we have decided the application process. * 8.5 completely does not apply as there is no concept for primary or not. But base ASCII always has to exist. Base ASCII is similar to primary but not the same concept. Which is the base? * Irrelevant whether one is delegated first or not. Not critical in any sense, just the delegation. The rule should be in launch open to public registration, but user confusion could exist. Irrelevant * 8.5 Mark summarized: This is largely not relevant to us. * We may not be able to imagine what question may come tomorrow when we are going. Defer to have more thought on this, how to handle this particular situation. That should be given from ICANN to the registry. Not decide on this, but defer it for later. * The requirement exists for ASCII version only during the application process, but you can delegate later on within 6 months * Mark proposed Framework for this: A) There is no preference or priority between ASCII and IDN; B) The registry is free to decide of their own accord. * 8.5 determined to be not applicable, but perhaps possible to revisit if necessary * 8.6 perhaps could have impact, but not applicable in that it is irrelevant and is already dealt with through the IDN processes. Out of scope or not applicable. We don’t deal with variant relationships and single TLDs * We don’t have to deal with these cases but some TLDs with diacritics may have variants, but it is out of scope for us * However, we may have a similar situation with a unicode situation if then ø is changed in unicode could have a similar impact. What to do with this concrete situation? It could be possible to be a diacritic of an existing TLD. * That is an interesting point given that our rules depend on unicode diacritics. It is possible to make such a change. Additions to this as our cases would remain the same as we would not need to grandfather anything. Outcomes, Action Items, and Notes LD PDP Working Session #2 ICANN83<https://icann-community.atlassian.net/wiki/x/AQBoD> on Wednesday, 11 June 2025 [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQOU...> of relevant recommendations and wrote the consensus in the decision tab 2. 8.10 agreement on the requirement to retain the base ASCII if you have more than one diacritic 3. 9.1-9.4 specific state labels will not be needed for this PDP 4. EPDP-IDN Phase 1 is completed [ACTION ITEMS] 1. Leadership team to discuss on how best to approach the legal team for the path forward 2. Leadership team to discuss whether to continue with a 25 June meeting due to IGF conflict [NOTES] Working Session #2 ICANN83 Slides<https://icann-community.atlassian.net/wiki/download/attachments/208142337/ic...> 1. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/policy...> a. Continue with the Review of EPDP-IDNs P1 & P2 Outputs (Worksheet<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHaG...> to Leverage Outputs) * 8.7 RZ-LGR are not part of this PDP, this is not relevant to us * The GP and IP should look into the impact of the diacritics as well because there are those cases that are not variants, but cases are possible to be in variant relationship and there could be some grandfathering work to consider. Makes sense to have Latin GP and IP to look into this and ensure how they could affect our cases. * 8.8 There needs to be a mechanism to apply for IDNs so they do not get challenged in the future. There are circumstances where it was approved and correct, so therefore it cannot be revoked. * 8.7 and 8.8 are applicable that TLDs using our policies can ensure to keep using it even in the case if the RZ-LGR were to change * 8.9 applicable * 8.10 here there are lots of concerns from the idea of security and what is a base TLD and variants. Here they are not variants in the technical sense, but we are trying to prevent user-confusion. * Agreement with that position the word MUST prevents owner from exercising ownership, and right could be curtailed * Does not apply for us and would exclude * Sarmad gave some background on 8.10 if primary is taken out there is no mechanism to define the variants, there is some dependency of variants on primary. The basic point to consider whether we consider the second string to have a dependence on the first or if they are on equal footing. In this case if they are independent then they can be independently defined and that constraint would be no longer applicable * If there is any dependence, even if it is not purely independent, it is not the relationship for variants so it should not apply * There is a case where we do need a similar requirement where we have one ASCII and two diacritic versions. If you remove the ASCII and remove enough diacritic versions. Technically this is possible, but not really necessary. If the base ASCII always has to be there * Original impetus was ASCII and diacritic, do we want to revisit that question? This is an edge case and question as to why one would be required to maintain the base ASCII. In IDNs it was needed, but in this case it was just in the Charter. It could be worth revisiting as we dive deeper to park this question and readjust the charter for such an edge case where a set could be without the ASCII * Already agreed to keep the scope narrow in this case and not deviate from this charger and decided that base ASCII would remain there. Ultimately, we stay within this charter to have the base ASCII requirement. We should not revisit this. We do need a recommendation here that base ASCII cannot be deleted unless only a single diacritic version remains * Just diacritic TLDs might be sensible, but it should be kept out of this PDP to not extend the scope * Steve, scope was made intentionally narrow. This is an exceptions procedure. The more you erode it the more you can increase end user confusion. * 8.10 Edge cases to apply for base ASCII and two diacritics and then delete the base ASCII. Would be appropriate to say you cannot delete the base ASCII unless you only have one diacritic remaining * 8.11 See above * Sarmad: case with base ASCII and diacritized version, where you have one ASCII and two diacritics, you should be able to delete a diacritized version so it must apply. * If you have more than two diacritic, you are free to delete one of the diacritic versions but not the ASCII * 8.12 applicable and translation plan wise * 8.13 this applies if it were the same registry, if there is a breach of the agreement then this applies to the whole set. Technical question as to whether this is a variant or not. It remains whether we have a single registry agreement or multiple. Should be postponed. * Sarmad: thoughts on same agreement it is on the primary and agreement. When you sign an agreement it starts with a string as a primary and then other strings are added as an addition. If we have strings added to the same agreement then they will in some cases potentially secondary. Something that the legal team can look at. There is then if we go into a single agreement there is then a potential primary agreement * WE DID AGREE to use a single registry agreement, we did not go into detail about how this would be legally in detail * Steve: when we talk about revocation the single agreement is based on the primary string and if we don't have a unified primary string. If you remove the ASCII or diacritic, you don’t always know the driving string for the primary. The single agreement capturing the relevant strings may not work. * For us to have a single agreement they would have to be all equal to each other * Two aspects: legal it can be a single agreement or different depending on the timings. ASCII TLD in 2026 and diacritic in 2027. Process of approving applications has to go through in both cases. But the same entity principle remains the same. In case of a breach of one agreement it may or may not be applicable to a second application. Technical: we have to see whether there is a dependency on ASCII or diacritic to recheck with SSR issues. Proposal for more deliberations on this particular topic in the future * Breach of a contract applies to one string because you cannot remove base ASCII if there are multiple diacritic versions. * Contracts have many interdependencies, but we should not throw away this idea yet and get the implementation side as to whether or not this is doable * Proposal to bring legal to have a discussion or dialogue. Steve proposed putting specific questions to legal. Could walk through recommendations and see which ones need legal input and get that into a single request to legal * 9.1 Sarmad would be to look at the strings which are being proposed for the IDNs and variants and see which are applicable in this case. Worth looking at this for the SSR panel * Rejected is not a property of the label as such. Blocked is a variant specific term, none of our cases can happen in our cases since we have the same entity principle. * Delegated and Allocated are the terms that would apply to our labels as this is a standard process for any TLD if it is applied for * Sarmad: IDN EPDP there is a policy when someone applies for a variant they have to justify why they need it. It is an exclusive right of someone so they have to argue why it is needed since there is an SSAC advisory where the number of variants need to be minimized. To manage that conservative outlook, it has to be justified that it serves a community etc. There are four questions for each variant that needs to be delegated. Whether those questions will be applicable for similarity cases as well. This is an exceptions process * Saewon in chat: We did actually discuss the RA case in Final Rec 7.1 in the Leadership Meeting/also updating the WG (please see cell F41) where the legal details at this point would not be needed - but this will be further discussed via leadership meeting. This is referenced in final rec 3.5 * Variants have some kind of ontological relationship. Even if it is rejected for any reason related to confusingly similar. If it is the same entity and it is rejected. * Rejected due to applicant not providing enough justification or background as to why they should have that label in the set * These strings are not connected to each other in any legal way, it does not mean that any other entity could apply for that label. * 9.1 not necessary for us to use these label states because these states denotes that it is a property that sticks to the label * Do we need some specific states like they exist in the variant world or whether they make no sense for our case because the labels are not connected to each other anyway. This does not put a sticky state to this label, any other entity could try again. * EPDP-IDNs Phase 1 is completed 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>