NOTES | ccPDP4 - Confusing Similarity subgroup | Tuesday, 29 March 2022 (13 UTC) 1. Welcome & roll call Welcome by Kenny Huang (.tw) Next time Anil will chair Slides and background material can also be found on the wiki: https://community.icann.org/x/ehgiCw 2. Admin matters Anil as Chair, Svitlana as Vice Chair Kenny mentioned that if she is not available, he can assist 3. Brief tour de table Let’s skip this, since we all know eachother 4. Introducing Confusing Similarity Bart speaks to some slides. This was the most contentious topic or issue, with respect to the Fast Track Process. It is also the area which has evolved most. No right or wrong: some solutions are better, some are less good. There is no “best” solution. Trade off between various interests that need to be taken into account. Subgroup needs to suggest a way forward to the full WG, to be included in the basis doc. 2 docs were shared. * Board doc * What is currently included in the FTP itself and the related guidelines.
Fast Track Confusing similar ccTLD cases to date
See icann website. 3 cases (there are 4) which have caused confusing similarity issues, which have been the drivers of the Fast Track Process (FTP). led to EPSRP. Extended Process Similarity Review Panel. Requestor was deleted. The request from Bulgaria and Greece was a government-related entity. In the case of the EU, the European Commission played an important role. EURid was the requestor, in consultation with the EC. Contentious matter.
Criteria confusing similarity
See definition on slides, from the FTP, refined with introduction of EPSRP. Confusing will arise in the mind of an average internet user It is not exact. Lots of judgment involved. * Proportionate * Adequate * Self-contained * Global impact
Board Report 2013 Proposal
Developed in 2012. Dealt with issues identified in the 2nd review of the FTP. Was considered a test bed for policy proposals. One of the concerns was that the CS-review was unclear (black box approach): methodology, there was no comparison with one or more similar cases, or at character level. Moreover, it was unknown who was conducting the review. 1 person? More? Board report included the need for more transparency. If necessary, a more extensive panel could do the review. Unclear if and when. Review of the original evaluation? The EPSRP was introduced. As a result, you will see procedural changes in the Board Report. Since 2013, also included in the FTP. triggered by the 2nd review.
Current FT confusing similarity procedures (since 2019)
Summary where we are now. * DNS Stability Evaluation. Same panel also checks the technical requirements. (since 2009) * EPSRP (since 2013). 2nd and final CS assessment, at the request of the entity that submits the selected string for validation. * Risk Mitigation Evaluation (since 2019) One of EU related IDN ccTLDs (.eu in Greek) was still considered to be confusingly similar by EPSRP. This came back in the 3rd review of the FTP. There was an intense discussion between ccNSO and SSAC regarding the next steps. The result was the introduction of a Risk Mitigation approach. Judgmental. This was perceived as a Risk Mitigation exercise. Anil: When the EPSRP goes for the 2nd and final evaluation, does it also take into account tech evaluation? Bart: no Anil: why need third step? Bart: goes back to the eu-case. Let’s talk about this in the next slide. It assumes that a string is confusingly similar. By the time the idn cctld becomes operational, mitigation measures need to be in place. They are assessed against the original criteria. If they do not meet the criteria, the string is considered to be not valid. Sarmad: The Risk Mitigation Assessment does not apply to all cases. There are some pre-conditions. In case the string is still considered similar under EPSRP. For instance here the reasoning was that the confusion was not in the lower case, but in the upper case. Bart: quite extensive and contentious
Panels FTP (since 2019)
Already in the Board Report in 2013, you saw 3 panels listed: * (1) Technical panel. See discussion in basic doc. Meets IDNA protocol etc. in future, allocatable under RZ-LGR. Fairly straightforward. (e.g. character lengths). No IDN ccTLD has been declined because of issues in that limited sense. Sarmad: aware of at least one case. Cannot share string because of confidentiality. * (2) Similarity Review Panel Same panel (1 and 2) for the FTP, but different panels for gTLDs. If we would separate the 2 panels, the EPSRP builds on second panel. They use a different framework, for conducting the similarity process. Costly and time-consuming, hence not suited for an initial review * (3) EPSRP * (4) Risk Treatment Appraisal Process Panel (RTAP) Risk Mitigation builds on 2nd confusing similarity. Allows the requestors to mitigate the risks associated with the CS that is the result of the EPSRP. Anil: more clarity will probably come later. EPSRP is on the request. Bart: correction “at the request” Anil: Risk Mitigation Evaluation is also made by requestor. Bart: Voluntary next step for requestor Anil: but important to evaluate that the system does not become unstable in future. DNS Abuse. Bart: if an idn ccTLD string is found to be CS, it is not valid, and will not go through the process, and will not be delegated. If it is considered confusingly similar, it will never be delegated. Starting point: “not valid”. If the requestor does not request the EPSRP or does not suggest Risk Mitigation Process, that ends the request itself. 5. Next steps Bart: there are some questions this group should answer. * Confirm that CS is still relevant. Is the evaluation still needed? Potential of abuse, and the risk around CS, probably gives us an answer. * Which criteria does the group use? Look at the Board report, FTP, etc. Are there additions or amendments needed? * Methodology: How detailed does it need to be? Leave details to implementation? * How many panels? What type if basic mechanism? CS review, and a review of that, and then a risk mitigation? Strike one or 2 panels? Strike the risk mitigation? We can use materials from Board Report and FTP for a proposal for the full WG. Anil: important steps. 2 additions * Before starting the process, we should understand some examples. Where we have rejected a requested string. 2nd example: CS at the technical evaluation level, but them mitigated and delegated * Panels that are required. The group should discuss whether it should remain a request by the requestor, or whether it should be mandatory, considering the stability of the DNS. Bart: see initial cases. We can run through the documented cases. They are publicly available. See next call. Cases were first rejected by the stability panel and then accepted by the EPSRP. Final one was accepted by first panel, rejected by EPSRP, and then went through risk mitigation. Greek, latin, cyrillic. Same story could apply elsewhere. What we want to avoid, is to go through of the various methods of the EPSRP. Very different way. Is SWORD still used? Sarmad: not used by the stability panel. Not in FTP according to Bart. Bart: methodology was unknown. SWORD as a tool is not used anymore. 6. Next meetings 5 April | 14 UTC (ccPDP4 VM) 12 April | 13 UTC (ccPDP4 CS) 19 April | 14 UTC (ccPDP4 VM) 26 April | 13 UTC (ccPDP4 CS) Kenny invites all to review the documents ahead of the next meeting 7. AOB Sarmad: Bart suggested the exisyting examples are from the latin/cyrillic/greek set. The different script communities looked at RZ-LGR. In some cases they had to look at similarities. As a by-product, they included some examples of similar characters in appendix. See https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en Not a normative doc, just informational, could be of use. 8. Closure Thank you all. Bye. Joke Braeken joke.braeken@icann.org