NOTES | ccPDP4 Confusing Similarities SG teleconference (13) 6 December 2022 at 14:00 UTC. 1. Welcome Welcome by full WG Chair Kenny 2. Admin items, if any a. Action Items Bart: all completed b. Meeting GNSO EPDP Kenny: most likely another joint meeting before ICANN76. Once a proposal is in a more final state. Bart: question by Donna, whether the members of the EPDP could participate in the full group scenario testing. c. Progress Full group Chair Anil takes over from Kenny Met 2 weeks ago. Add the work of the subgroups, and also the work by ccPDP3-RM. To be completed by ICANN76. Bart: regarding RM, some sections need a 2nd reading. Check also whether there are decisions that should be subject to a review Anil: RM is important. All, please join the full WG meeting on 13 December 3. Review of CS Document a. Updates of doc after 2nd reading 1. Comment inclusion of reference to SAC089, page 3 Bart: response to SSAC84. FTP, EPSR ccNSO suggested a change, which went through public comment. SSAC084 as response to public comment. Official way at the time, only way the SSAC could submit a public comment. Intense discussions between SSAC and ccNSO following that. Original proposal was rescinded as a result of these discussions. Both formed a joint working party which developed the risk mitigation appraisal procedure. Relevant sections in SAAC089. But overtaken in time. Unwise to overtake one remark from a document. Given the specific context and the proposed changes to the FTP, suggested is not to include a reference to SAC089. Sarmad: I suggested this pointer. Please allow me to explain why. From chat: “Confusability is a Security Concern Confusability cannot be considered in isolation from other issues related to security. Phishing and other social engineering attacks based on domain name confusion are a security problem for end users.2 As such, adding a label to the root zone that is potentially confusable violates the Inclusion Principle’s requirement that a TLD label be known to be ‘safe’.” Good reference point to share why string similarity and confusability are so important as part of the process. Add more support to it. Jaap: Sarmad cited from SAC088. That is where it comes from. Does not make sense to add it Bart: do you wish to add a reference to SAC089? 3 red marks, 1 green (by Anil) Anil: SAC089 is being used, and related to the stability of the DNS. Does not feel strong about inclusion Bart: let’s leave it open for the time being, and bring it to the full WG. keep the reference for the time being. Explain there is a mild preference by some, opposition by others. Kenny and Anil agree 2. Comment re use of word ‘VALID” in the text, page 6 Bart: used in FTP, and checked various dictionaries. Suggest to keep the language Green marks in zoom, no red marks

...

...

page 9 No concerns raised. No red marks

Sarmad: see 2nd question. Clarification. What is suggested that is the primary label is not found confusing, and one of its variants is found confusing with another TLD (more likely gTLD) Bart: why more likely? By definition country names are excluded. Meaningful representation. Has to be the name of the country Sarmad: in case it is found confusingly similar - taken it is a rare scenario - assuming there is a population that think that those 2 variants (ccTLD primary string and the confusingly similar string), are similar enough to be almost the same. Also, there is a community which thinks the variant of the primary is the same. Bart: I am confused. Why requesting a string, by requesting a delegatable variant, you may cause that your primary or selected string is not delegated or not valid. Sarmad: recommendation in the staff report is based on the allocatable variants. Bart: it has a lot of implications by limiting the number to allocatable variants. Sarmad: we do not want a situation with 2 TLDs delegated, which are considered similar by a population of users. It will hurt both the existing and the new TLD. phishing risk. Bart: do you still support scenario 2 as proposed? 2 red marks Mirjana: scenario could be mentioned somewhere in our doc. We need to think how to resolve this loop. Kenny: need more time 3. Inclusion of expansion of the SEP, page 13,14 Bart: see suggestion by Jiankang. Evaluation panel Sarmad: as part of the 1st step, a separate panel is being created. Or 3 people to extend the panel? Bart: slight adjustment of the language in FTP. at least 3 member panel. DNS stability panel. Sarmad: 3 plus 3? Bart: no. if there is more people, ensure there is at least one person with knowledge of the script Extended panel will include at least 1 person with deep knowledge Anil: fundamental question. Requester has any option for suggesting a name in the panel? Or is it icann org? Bart: icann org contracts the panel. Has to be independent. Appointed by ICANN. External panelists. No matter the size, at least one person with knowledge. Bart: do you agree with the proposed way of handling? Sarmad: panel may suggest the same, even if the requester does not ask Bart: yes. Line 3 and 4 on page 14 Sarmad: ok Bart: do you agree (not with language), with the approach? No red marks Bart: before stability panel has reached its conclusion. Bart summarises: revisit 2nd scenario on CS. Revisit the panel bit. Full group to revisit SAC089 b. Review of Open issues around invalid variants (second reading),page 8 4. Introduction Basic with inclusion of CS (to be circulated closer to the meeting) Bart: no real change in language. Wants to show how it is included. Main section is section 4. Page 25. Still to discuss whether or not to include blocked variants in the comparison Bart asks Mirjana to explain why it needs to be included, in the next few weeks. Mirjana: likes the proposal discussed with GNSO group. Yes, gives live example in written soon. Bart: do you like the structure of the doc? No concerns by the group 5. Next meetings CS Subgroup | 20 December 2022 @14:00 UTC Full Group| 13 December 2020 @14.00 UTC 5. AOB none 6. Adjourn Thank you all. bye Joke Braeken joke.braeken@icann.org