NOTES | ccPDP4 IDN Confusing Similarity | 10 May 2022 (13 UTC) 1 Welcome and roll call Welcome by Chair Anil Kumar Jain (.in) 2 Administrative Items a. IDN EPDP Update House is divided. Subgroups will discuss the various cases of confusing similarity. Level 1, 2, 3. What are the precautions that need to be taken? Single level of evaluation? More? Today is deadline to apply for the subgroups. b. Sessions at ICANN74 Tuesday, 14 June 2022 • ccNSO: Policy Update | 11:15-12:30 UTC See also ICANN71. VM-group makes considerable progress, this group as well. The DS-group concluded. Opportunity to seek feedback from the community on the results today. Sessions lasts 1h and 15 min. 35 to 40 min for ccPDP4. ccPDP3-RM needs to discuss matters too. • ccPDP4 IDN Meeting | 14:30-15:30 UTC Full WG meeting. With respect to participation, same type of experience, whether you attend remotely or in person. Focus will be on stress-testing. It is not a heavy discussion, rather about being creative. See 31 may meeting, when we prep. Anil invites all to attend the session. 3. Basics Confusing Similarity Review - document Anil refers to the items discussed last time. 3.1. 2nd reading need for review See slides where we introduced the CS review. Bart started to write down some questions. Base for comparison? What should be in/out of the base?

...

...

section 1

Revisit as a 2nd reading. Taken from a doc that was developed in 2013. It captures the arguments from the slides nicely. Latin and cyrillic. Therefor EU biased. Captures the need for the CS-review and the rationale. Any questions to the text of section 1? None Are you in favour of the text? No red marks Agreement on CS review need, and the reason why 3.2. 2nd reading approval standard of review See text in slides. From the intro on EPSRP. Definition is in bold, starting with “if the visual appearance ….” That is the principle standard for evaluation. Reference to common fonts. That delineated and limits the scope of the review. Gives direction of what could be expected from a reasonable internet user. Also pixel size. Observation to illustrate what is meant. Questions or comments on the definition? None Questions or comments using the observations and/or illustrations? Sarmad: should we add that other string could also be in upper/lower case? Bart: revisit when we start the base for comparison? Going back to the standard for evaluation itself Bart: other comments? Jaap: off terminology. Size of pixel. Pixels that define the picture. Bart: number of pixels? Jaap: yes Bart: should we add this for clarification? This is not about the text. Does it make sense to add the clarifications? No red ticks Bart: we will add this to the text Bart: do you agree with the addition suggested by Sarmad? Do you agree with the proposed text? Adding upper/lower case. Friendly amendment. Questions? None Do you agree with the text? No red marks 3.3. Introduction of Base for comparison Describing base for comparison. Under FTP and the 2013 policy, there was a limitation on the CS, the scope of the CS, and the combination of letters a-z, existing TLDs (IDN ccTLDs, gTLDS, and reserved names. And proposed TLDs under string evaluation). Was excluded in 2013. But you do not want CS with an IDN gTLD either. That is why it is included. Original base of comparison, without variants. There are at least 4 relevant categories with respect to the number of variants. Full set of variants: blocked and allocatable. The blocked ones are excluded from use as TLD from the RZ-LGR. Largest set of variants. Allocatable variants. Sets permissible under the RZ-LGR for a certain script. Limit the number of variant tld string. Also take into account the criteria for IDN TLDs. delegatable or activatable. VM-group discussed that if there is a delegatable variant, it is not necessary that the variant will be delegated. Not an automated procedure. A delegatable variant needs to be requested at the time when the IDN ccTLD string is requested for validation. Only after verification and when documentation is provided, they are verified, and then they can request it to be delegated. Slight deviation from the discussions under the EPDP. more levels. Ariel confirmed Discussion more refined to date. The base for comparison is any combination of the 2 iso. Reasonable starting point as the base for comparison? Green ticks. What we need to decide: with this foundation, think which variants should be included in the comparison. And understand the consequences. We tried to understand what it means to include the various kinds of variants. Delegatable, ending with the blocked variants. See staff paper January 2019. 2 examples: Abu Dhabi in Arabic script, Pakistan in Arabic script. Understanding of meaningful representations, and its impact. 80 variants, of which 78 are blocked. One is valid, one is allocatable. If we would expand this to include all the blocked variants, that would increase the assessment. If you look at the Pakistan example: using the same numbers and what is included in the staff paper. The number of variants from blocked to requested-delegatable. Pakistan in arabic script is a better illustration of the scaling issue. Any questions on using the numbers? None If you need to do a statistical relevant review, you need to have a considerable number of volunteers, who will look at the various comparable strings, to determine whether there is a significant reason for CS. basis used by EPSRP. There is a scaling issue. Additional issue: if the base for comparison is not properly delineated, there might be some unforeseen results and side-effects, taking these issues into account: we now should focus on discussing the scope of the base for comparison. Limited to delegatable variants for instance? See discussion in next step. Focus on sets for comparison. All possible 2-letter codes, the tld strings. That is the basis for comparison What should be the result of the review in the following cases? * Bullet 1 * Bullet 2 * Bullet 3 See doc displayed in zoom. Jaap: political matter. Everything should be taken as a string. Whether it is a variant of another string does not matter. Bart: The starting point is the fact that an idn cctld string is selected. If the selected string is confusingly similar, should the others go through? Assuming it meets the criteria, it could go through, if the only issue with the selected one is confusingly similar. But it has to be a requested delegatable variant (meaningful representation of the name of the territory) Third question. Based on Jaap’s comments, it does not matter. As soon as it is a delegated tld string, the CS should be taken into account, at least for the selected idn string. The confusingly similar string should be terminated. Fair consequence of bullet 1 and 2? Proposal Bart: Revisit this text again and present it in another format at the next meeting? Anil: if members want this, yes. But similar discussions happen also in EPDP. Ai-Chin: verify something. First question. What is the IDN delegatable variant? We have RZ-LGR. We have a package. Bart: understands from discussion at VM, this is about the limitation of the number of variants. Variant needs to be a meaningful representation too Do people want this to be delegated? To ensure we look at a limited set, t should be requested at the start of the process Ai-Chin: clear. First one is confusing. Variant needs to be terminated. Bart: by including blocked variants. Other end of spectrum Are you in favour of including blocked variants in the CS-review? Kenny: can be included Bart: but taking into account the scaling issues, and the weird side effects? Hadia: why does Kenny think they should be included? Kenny: variant has a correlated string. Idn string should be considered Bart: but they will never be delegated Mirjana: blocked variants not to be included Anil: need to drop off Bart: meeting will end in a few minutes Will clarify better next time. Then go to the other 2 cases. 4. AOB None 5. Next meetings * 17 May VM SG | 14:00 UTC * 24 May CS SG | 13:00 UTC * 31 May Full Group Prep/discussion ICANN74 (subgroups invited to attend) | 13:00 UTC * 7 June – Prep ICANN74 (TBD) 6. Closure Thank you all. Bye Joke Braeken joke.braeken@icann.org