NOTES | ccPDP4 IDN Confusing Similarities Subgroup | 19 July 2022 (13:00 UTC) 1. Welcome Welcome by Anil 2. Admins matters, including action items, review The Hague sessions PDP4 WG meeting | 18 Sept 7-8 UTC; Joint session with GAC, 20 Sept 515-630 UTC. 75 min duration Bart refers to a joint meeting with the GAC taking place at the next public ICANN meeting (ICANN75), where ccPDP4 will be participating in. Also the ccPDP3-RM will need some time At ICANN75 there will be a ccNSO session on Universal Acceptance. Idea is to understand if there is a need for action from the ccNSO with respect with UA, in conjunction with what ccTLDs and RO’s already do regionally and locally. Is there a role for the ccNSO? If so, what should that role be? Kenny in his role as Chair of the WG will receive a copy of a letter on the scope of the independent review process. ccPDP3 encountered an issue. The retirement policy (issues in 5.2 and revocation) should be carved out from the Independent Review Process (IRP) and the reconsideration. This WG will be asked to share their views on this. To be added to the policy in the end. It is an additional work item for this group. Will be raised again at the next meeting by this group on 26th July meeting. Council will vote on the letter at its 21 July meeting. It is an important issue for the full WG, so it is a good idea to raise it on the 26th, during the joint meeting. 3. What was discussed to date: Criteria & Base for comparison Anil: question (notes missing) Sarmad: within the smaller subgroup the current thinking is that there are 2 sides: * Applied for string * What it needs to be compared with Group is converging to the applied for string and its allocatable variants. Compared to allocatable variants and its blocked variants. First the subgroup needs to discuss, and then present its proposal to the full group. Still some steps to be taken. Bart: what is the reasoning? Why include blocked variants in the comparison? Sarmad: suppose there is a ccTLD manager that has a string, and which has a variant which is blocked. The community thinks that the blocked string is similar to the existing string. Would the ccTLD manager want someone else to apply for a string which is considered similar to a blocked string? This group needs to answer that question Sarmad: SSAC refers to 2 failure modes. Second is called “miss connection”, first one is “denial of service”. The modes are not equal. DOS is bad, but misconnection is worse. It could potentially cause harm. Bart: see discussions 2 weeks ago. Follows the arguments of the paper we have been discussing the last 2 or 3 meetings. Some unforeseen side-effects. Scale of the review. In 2 to 5 years, CS reviews need to be manual. Depending on the methodology. Resource intensive. Duration: approx 1 month to 6 months. Depending on whether there is EPSRP or not. If you expand the base for comparison including all the variants, the scaling is impacted. Sarmad: if a string has 1000 variants, not all of them will be confusing. The 1st panel could be requested to give a shortlist of which strings they think are confusable. EPSRP to look only at this limited set, could be a proposal to address the scaling. Bart: you may end up with issues of scaling, depending on the base of comparison. Ai-Chin: Do you think it is possible to take two stages? The first stage can use a system and the second stage uses the manual process. Bart: unforeseen side effects? It could take too long. Impact on the purpose of the CS is also important. For discussion now. Will address Ai-Chin’s question later. Sarmad: Normally there is a level of automation in the EPSRP stage, even though it is experimental. Bart: what risk does CS address? Misconnection or DOS? See SAC060 Bart continues to talk to slides in zoom Purpose CS Review. When looking at the risks, is there harm done? Does CS address both risks? Either one of them? Jaap: distinguish between the 2. That is the recommendation. Icann wants to build in safeguards. Not part of the CS discussion at all. Bart: policy developing bodies are setting the policies around CS. important distinction. What do you want to receive? Base for comparison: request side Ongoing nature. Some available for connection. No connection for non-requested variants Inclusion of variants: what needs to be included in request side? Extending base for comparison: * Version 1 (most limited one). Anil: existing TLDs. all TLDs? ccTLDs, IDN TLDs, gTLDs? Bart: yes. * Version 2 * Version 3 Questions regarding 3 slides? None 4. Review of CS procedures and is there a need for update? * Proposed 2013 process and Methodology (Similarity review and EPSRP) * Fast Track Process and Methodology (DSNA Stability review, EPSRP, Risk Mitigation Measure Evaluation)
Questions
1. What is the purpose of the CS review? DOS or Misconnection? Anil: both. However, the risk of misconnection is higher for user than DOS. but we should take both into consideration when we make a policy Bart: why both? If you look at SAC 060, DOS is a nuisance, but no harm Hadia: harm from misconnection mainly affecting registries, not so much users. Do we need zero-tolerance for misconnection? What tolerance are we aiming? Bart: SSAC60 report believes that misconnection is really an issue. Not controlled by the registry. But done by registrants. Hadia: looking at probability. Bart: combination of probability and harm? Does that matter Hadia: no major harm from misconnection Bart: spoofing. Deliberately luring to a website Hadia: blocked domain names. Domain name will never be delegetaed. Looking at misconnection linked to blocked domain names Bart: going back to question. Why do we deal with CS? Kenny: matter of probability. Bart: do you want to include the probability of harm too? Kenny: yes, critical 2. What should be base for comparison? Anil: all Bart: remember meaningful representation Anil: requested and allocatable variants only Ai-Chin: why do we need to divide into request side and comparison side? If someone requests a string. From the request side or comparison side, we should include all variants because when we build an IDN variant table, we include all variants under the same set. That will raise the CS issues. To avoid this situation Bart: compare all variants with all variants? Ai-Chin: yes 3. Comparison side Anil: only delegatable variants. Variants which will be used in the DNS are the delegated ones. Reduce the scope of the CS process. Taking into consideration time and process. Bart suggest to revisit this. Base for this SG. if there are divergent views, we should spend more time to discuss 5. Next meetings Anil refers to the joint meeting with GNSO on 26 July at 14 UTC Full WG and subgroups are invited. 2 August | CS (TBD) 9 August | Full (TBD) 16 August | CS (TBD) Bart: I will be on vacation 2, 9 and 16 August. Return on 16 August Anil: Bart should be there in my view Kenny: we can keep the same schedule for 2 and 16 August Anil: let’s complete the work with entire group, including you 6. AOB none 7. Closure Thank you all. See you on 26 July at 14 UTC Joke Braeken joke.braeken@icann.org