Hello All, It was great seeing many of you here at ICANN84, please find the attached outcomes, action items, and notes from our two sessions at ICANN84 [OUTCOMES] * Updated and resolved comments from the Draft Preliminary Recommendations<https://urldefense.com/v3/__https:/docs.google.com/document/d/10PiKG0grWcN2Q...> and finalized the review of the preliminary recommendations. * Edge Case Study 1 is adequately handled in our current recommendations. * Edge Case Study 2 is adequately handled in our current recommendations with the same entity principle with a single application. * Edge Case Study 3 is adequately handed in our current recommendations. * Recommendation 39 updated based on input raised by Sarmad and footnotes added for context. * Edge Case Study 4 is adequately handed in our current recommendations as the resolution is out of scope of our PDP. [ACTION ITEMS] * Leadership and Staff work to rewrite preliminary recommendation 45 especially related to the source domain name and integrate the footnote. * Leadership and Staff work to add an example in the rationale for Preliminary Recommendation 45. * Leadership and Staff to shift recommendations in PR54 to Rec IG49 and IG15 and add footnotes to these to more clearly link them. * WG to think through Edge Case Study 6 and come up with recommendations to account for this. [NOTES] 1. Welcome and SOIs SESSION 1/2 * Overview of the LD PDP for the audience in the slides<https://icann-community.atlassian.net/wiki/x/AYPzGQ> * Ariel queried on the publication time of Initial Report and answer was ideally before the ICANN holiday season so that ICANN org can provide a comment 2. Recap of Meeting #23 a. Key Outcomes and Action Items * Summary on slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> pg. 8 * PR 39.1 and 39.2 reference to second-level labels and was added as a footnote and rationale in the PR Document<https://docs.google.com/document/d/10PiKG0grWcN2Q2UKKjz0WpuElJ3gLb9tY4JYgduN...> 3. Continue Review of Draft Preliminary Recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10PiKG0grWcN2Q...> * PR45 discussion of the use of “variant” * Would it be possible to have a top level under IDNs and second level for LD? That is a stress test example that we have in a later stress test * Sarmad clarified that the source domain for each TLD could be different, not requiring it to be the same in the TLD set? * The LD set is defined on one second-level label, which creates variants in each of the TLDs. Can’t have a different source domain name in a different TLD. It is defined on the one label that is created first. * Sarmad, when you register 2nd level under a TLD set it creates a variant set of all the TLDs in the whole set because of the IDN tables associated and harmonized. The question is, are we requiring a single source domain? One possibility where the primary domain registered in the first LD TLD may not be valid in the other TLD in that set, therefore the registrant could register a different source. Language unclear whether it allows that flexibility or not? * Michael’s Answer: Unlike IDNs we don’t have a relationship across TLDs since they are not variants of each other. For that reason, you can’t just start with any other domain in the 2nd level, but have to have the same label here. But the point here in example.ldtld would not be a valid label as the code points are not part of the LGR table. That we have not thought about that yet. * Sarmad: in IDN discussion under the variant TLDs since they don’t have to be the same, as long as the variant sets are harmonized, the same source requirements are not needed. * A: But in the IDN EPDP the difference was in regards to disposition value. Then the variant sent is already defined, you just don’t know the disposition values in other TLDs. * Sarmad: would assume that would be the same here. What is not identified is the starting point in each of those TLDs. * We may need to adjust this in the edge case discussion after lunch today. * PR46 variant is correct here for the calculation of the variant set to know which labels are allocatable and blocked, you need a primary/source domain name and that then defines the variant set. For the LD set, the source domain name is not required as it is the same label and the variant, so we need the source to calculate the variant set, which is part of the LD set * PR47 “together” should remain as it is written in IDNs even if it is badly phrased. We want to demonstrate that it avoids confusion if we keep our recommendation aligned with those * IG49 being unaware of the variants that may exist, ICANN needs to reach out and educate that these sets exist. When a case is created there is a possibility that IDN EPDP variant sets that exist and diacritic sets that exist, and use mechanisms available to find out what is in the set and allocated and would be visible in RDAP and include all existing domains or just part of them. * Susan: If there is a tricky implementation issue and guidance would be helpful, how the complainant would have any idea that there would be other potential diacritics in the set, unless there is a mechanism. Whatever is helpful for implementation would be extremely helpful. * IDN EPDP Phase 2: “Final Recommendation 13: ICANN org must conduct outreach to dispute resolution providers, registries, registrars, registrants, and mark owners to enhance their understanding of gTLD variant labels and variant domain names, in particular, their potential impact on dispute resolution proceedings.” This aligns with PR54 of the LD PDP. * Sarmad also IG15 in IDN-EPDP P2 in line with Susan’s comment * IG51 All of phase 2 is adopted, but we still want to be consistent as it is technically the same topic. Suggested changes in the language, but should be in line with IDN EPDP to ensure that there are no alterations of the IDN, if we change it, people may assume the policy is changed * Mark shared https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml to be added to the footnotes. 4. Stress Test * Began stress test on slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> pg. 19. Understanding an open question of what could possibly happen and is it covered in our policies as well defined? Or do we have situations that the policy may need to be adjusted to cover this * Sarmad: argument on each side. Keeping it: Even if a country changes their standard writing, that does not take away the history of its use from a community, the two versions will remain confusable for many years. Eliminating it: Do we keep those four variant justification requirements to LD TLDs as well if those variant requirements are extended and it is no longer applicable, should that TLD continue given that is not fulfilling the application arguments presented * Single language changes do not change LGRs or Unicode tables and definition of tables depends on unicode tables. * Objective of LD PDP is to ensure that we bring the ASCII and LD TLD together as a group to avoid confusability. In this case when a language gets changed by a country, the grouping of two TLDs ASCII/LD may change and there may be no similarities where there may be major changes. This is a possible case that has been seen as countries adopt new languages. PR 1, 32, 33 and IG 34 open to discussion. * Case of unicode table changing as well…both the unicode and LGR might change and that is covered in recommendations that existing TLDs must be backward compatible and those recs on slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> 21. * Foundational blocks are Unicode and LGR, there could be changes, but to respond that short notice to changes would be difficult. Unless there are substantive changes we will just have to bear with the transition period when there is confusability. Our policy should not try to be doing much in that case. Likely we will just have to live with it for some time * Consensus that Edge Case 1 is handled in our recommendations * Edge Case Study 2: conflicts with same entity principle? They are going in as different applications and they can actually do that but that String Sim review will likely not get the TLD. They can apply separately but risk that string sim review may block this. Not possible to use this PDP as there is not the same entity requirement. So this would not be possible within the scope of our PDP. * Possible that second applicant may not be able to prove the ownership of the brand, but has taken permission from the owner. Possible that we may accept two applications, but likely String Sim review would find it visually confusingly similar. Also, it may not be similar. In case of no string similarity, better for us to accept this possibility for looking at SSR issues in the root zone. * Single applications do not change any rules in our LD PDP, but in ours it is only involving a single application, otherwise it is out of scop * Edge Case Study 3 slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> 24: the situation is when we are talking about the ASCII and LD TLD they look similar, in that situation in case it is a banned TLD then this case is sold to some other owner or it is stopped by the authorities of some legal issues with the brand owner. Since the owner no longer has this brand. What treatment should be given to the TLD? The brand is given to someone else, then if the owner desires then it can be transferred to the new brand. Or the second owner should be reserved. * Having the ™ and the TLD can be separated. You can remove Spec 13 from your RA. If you lose your rights to the ™ because you stop using, you may open up the TLD and remove spec 13. * All TLDs in the set have to have the same rule. Cannot lose the brand because it has to be for all. Otherwise, they can keep it even if they don’t own the brand anymore. * Covered by transferring the whole set. * What about where a brand splits up? They have to sort it out themselves, as it is required to be kept together. SESSION 2/2 * Continuing Case Study 3: all TLDs within the set have the same rules and option to remove one or multiple TLDs if they are not used anymore. Agreement that it is covered by the existing recommendations. * Revisit Sarmad topic raised definition of the ASCII/LD TLD set, it is defined as such as one domain and includes all variants. Then include the same label in all other TLDs, which might be different because the other TLDs may have a different LGR that needs to be harmonized. Sarmad said there might be cases where there is 1 not intended or 2 not possible as different LGRs and TLDs and that example.ldtld is not a valid code point. Then we could not calculate a variant set. * Example Text: .cafe and .café and then registers straße.café that creates a variant set under the café an allocatable variant for strasse.café. The domain straße.cafe does not exist as there are only ASCII domains, there are no variants possible. Strasse.cafe needs to be blocked or available for the same entity as we have to start with the same label in all the TLDs and generate the label. * We want this to be the case, but we will have to adjust the recommendation accordingly. * We now saw that we want ALL labels that are in the variant set also in the other TLD if they exist as updated in slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> 13 and 14. * Leave it up to the registrant which domain they would like to start with as a source domain name and it generates the other two as a variant. * Sarmad: This is how it is suggested as a solution for IDN-EPDP P2. * PR45 Discussion of source domain name in the TLD, if it should be included in the recommendation rather than a footnote, it could be helpful. * IG or Rationale for PR45 useful to have an example here whether in a footnote or rationale. Consensus to update PR45 and the accompanying footnotes and rationales. * Separate discussion raised on the ability of the registrant to comprehend these highly technical issues to the average end user. * Suggestion to offer a suggestion of how registries ought to do it even if we cannot make it a requirement. This would likely be out of our scope for how to run their TLD. * Less concern about the CPH side, but bigger for those that would come up with a TLD and people need to be aware that this is done for human communication to chip in and have some outreach to inform the community of what is happening. * It makes sense to do outreach and communications, but weary of putting in suggestions on how registries should run this. Perhaps giving an example could be helpful for the registries. This has to be explained and some guidelines, but not strict prescriptions would be helpful here * Case Study 4 on slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> 29: whichever application wins all others will be rejected. For the case that for some reason they are not considered visually confusingly similar, then there are different situations that could exist. * Dropping should be the same rules as those that have been allocated as there is no real primary here. If they stay with a set and remain with two, one must be an ASCII * Contention resolution is a black box that is beyond our scope. * Similar cases exist without our policies and they will have to resolve them just as they do now * Case Study 5 on slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> 31: in Latin LGR the straße and strasse * Is it possible for someone to apply for straße without a diacritic. If you have a diacritic and want to add a variant, that is not possible. You need to have * Case Study 6 on slide<https://icann-community.atlassian.net/wiki/x/AYPzGQ> 33 is more relevant to this discussion. * Sarmad: if there is an allocatable variant, then through IDN EPDP P1 and SubPro applicant has all the rights to apply for it, this policy should not try to block that. 2) When your variant set of rules apply and if you’re LD TLD then those rules apply and their policies apply. If for some reason there may be an overlap at some place (though they are non-overlapping spaces. WG could consider if an overlap that the variant policy takes precedent over LD policy etc. * In the LD set must have an ASCII in variant set must have a primary and we have different rules if the TLD is dropped when you drop one of the variants would it need to drop the whole LD set or just part of it? * We should work through this Case Study 6 and we should work to resolve it. * Charter discusses when the exceptions procedure is layered on. Maybe these exception procedures should not apply based on the layout of the charter. Look only at no variants of visually confusingly similar. * We do not want the nested situation where one goes into another. Could be more complex and something that the WG needs to think through and tackle this rather than leaving it open. * There could be an overlap, the principles have to remain very clear, we have cherry picked some case studies that may not be exhaustive, they are just some samples. This may not cover all situations think through other similar cases. 5. Continue with Charter Topic Deliberations a. Charter Question 4 b. GPI/HR Impact Assessment 7. Table of Contents for Initial Report 8. Next Steps 9. 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>