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:

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:

Anil: existing TLDs. all TLDs? ccTLDs, IDN TLDs, gTLDs?

Bart: yes. 

Questions regarding 3 slides? None

 

4. Review of CS procedures and is there a need for update?



 

>>> 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