ccPDP4 Confusing Similarities (#10) | 8 Nov 2022 (14:00 UTC) 1. Welcome Welcome by chair Kenny 2. Admin items, if any a. Action Items None, meeting from 2 weeks ago was canceled due to low attendance b. Meeting GNSO EPDP Bart: we scheduled a joint meeting on 29 Nov. GNSO update in terms of CS. timely for this group as well. Share the basic criteria, base for comparison, and the procedural updates from this end. Good to exchange views c. Progress Full group Kenny: full group one week ago. Bart gave an update for Review Mechanism from ccPDP3. What can be copied? Anything that needs to be amended? Bart: will re-circulate an updated version of the doc used a week ago. Looking fwd to discussion next week 3. Review of CS Document (attached) a. Intro section Bart: basic items from previous doc. Basic questions. Base for comparison We did not go over the proposed changes. There was a discussion regarding the use of py in cyrillic/latin. Example was cut-paste from IDN Fast Track proposal. Overtaken by time, due to the work by the latin script LGR. Mirjana raised this point. Also included in the text. Pitinan suggested another example. See redline. Does this address the concern raised during the previous call? Pitinan: need to check. Looks like it is capitalised. Needs to be lower case. Бе Will re-send via e-mail, calibri font Base for comparison needs to be reviewed at a later stage, see comments by Mirjana. b. Overview process Extensive part. Line 10-37 Any questions? None Line 41 Validation is the general description. Evaluation is the 1st phase, and review the 2nd phase. Line 45 to 2 FTP has currently 3 steps with respect to CS: * Step 1: DNS Stability panel (now/future: Similarity Evaluation Panel) * Step 2: EPRSP (now/future: Similarity Review Panel) * Risk mitigation (now/future: Risk Mitigation Panel) Anil: 1st review panel after evaluation. Once a panel made a report to ICANN staff. If icann staff wish it to be reviewed by the same panel. If the requester is not happy with decision of the delegation Bart: The 1st one will always happen. This is an independent panel. If a requester submits an IDN ccTLD string, the Similarity Evaluation Panel will evaluate whether it is not confusingly similar to another string. If that is the case, it will inform ICANN staff. Staff will inform the requester. It is up to the requester whether they want a review by the 2nd panel, the similarity review panel. Anil: All clear. Bart: see line 4. Requested by the requestor. All strings that are requested are submitted to the similarity evaluation panel Hadia: Does SRP always happen? Is it by choice? Bart: see also Anil’s question. Only if requested by the requestor. By choice. Logic approach? No red marks Hadia: in both cases it needs to be an independent panel. Can it be the same panel? Bart: it is in the text it is a different one, because it uses a different method This simply sets the basic structure for the 2 panels. See whether it is clear by the end of the meeting Bart: changes needed. What is currently the Extended Process, is going forward called the similarity evaluation. Discussion around Review mechanisms and CS. there was a potential that a RM which will be proposed to the community and developed under PDP3 may not be suited for similarity. RM is focusing on IFO decisions. PTI. These decisions are ICANN org decisions. Either you need to force IFO to do this, or the ccPDP3 policy needs to be adjusted. Both are a bridge too far. IFO is not equipped to do this. Even more important: all decisions from IFO related to (re)delegation require knowledge, skill, experience. Completely different than looking at CS of strings. CS is a cognitive science approach. Especially in the 2nd round. See footnote above. The 2nd panel is using a method based on findings of these groups. Do you support general logic for text in line 9 to 29? No red marks Hadia: each panel with different output. What is meant by combining the process? Bart: that is line item 30. Let’s come back to this later. Basic structure of string validation procedure. No questions or comments. Bart: suggestion to treat similarity review as a very specific review mechanism around similarity review. Do you agree? No red marks We will revisit in 2 weeks time. It will have impact on other things as well Line 30-32 Bart: this was combined under FTP Hadia: could be same organisation/people Bart: yes. To make process more efficient. Perhaps add in the notes and observations. As long as these 2 functions are covered. Notes and observations are not part of the policy itself Bart: one question still open. Introduce a review mechanism on technical validation? Currently not in place, not in the FTP. if you miss out on the technical requirements, there is the possibility to adjust and to contact icann staff before you submit a request. If you do not meet the basic technical requirements, the IDNA suite etc, then it is questionable whether you should introduce a RM. raise the question later on. Anil: regarding 1st question previous paragraph. When we talk about combining tech evaluation and CS evaluation under same panel, we cover both review together. But at the same time we talk about CS evaluation, it is a review, and a third review. Bart: only the technical review Line 26-45 Questions or comments? None Do you support the text? No red marks Anil: can we rephrase as Risk evaluation Panel? Creates confusion. Bart: reason for this. The requestor will propose to the panel how it wants to handle the risk treatment. The panel will appraise this. We could also call it the Risk Appraisal Panel. But then there is confusion on whether you talk about the process or the panel? Bart: let’s leave it for the time being. Suggestions for panel names are welcome Line 10-29 Questions? Anil: what is the experience. Is 30 days sufficient? Bart: there has never been an issue with this. Line 32-44. Section B2.2 Questions or comments? None Do you support? No red marks Line 1-26 Current language from FTP Line 28-35 Additional language. If there is an issue, then the requestor can go either to the similarity review, or the risk mitigation appraisal process. What if the requested string is confusingly similar, but one of the variants is not? Is there a hierarchy between the requested string, or the variants? Note that the variants need to be meaningful representations of the name of the territory. To think about. Anil: 1st question. Variants are defined as variant of the main string. If the main string is confusingly similar, and we consider to allocate the variant instead, then the basic principle of variants is under question. Once a principal string is declared as CS string, the string and its variants should be blocked. When the principal variant is valid, but some are not, those specific variants may not be delegated. First reaction. We can further discuss. Hadia: different perspective. What if we change our principal? See what the tool generates if you use the variant. When comparing with other strings, the output would be different. Answer to question depends on how the comparison is done, and the output. Needs to think more about. Bart: note that we talk about “requested variants”. 2 characters: * Has to be allocatable * Has to be a meaningful representation of the name of the territory Similarity review Rewrite of the 2013 basic doc and the FTP. this used to be called the EPSRP Line 12 -45 Do you support? No red marks Bart: still need to include the guideline which is currently used. Panel description and its role is new text. Let’s start with line 5-12 Any questions or comments? None Line 14-25 Questions or comments? Do you support line 5-25? No red marks Criteria to appraise risk mitigation panels: Small ccNSO and SSAC developed this. Copy-paste from that guideline doc. Necessary to include that in the policy Anil: a bit of discussion around proportionate risk. Definition about adequate. More clarification needed. Whoever is the requester, this is a stage where they received a negative evaluation from icann. When he applies, he needs to be aware what criteria need to be met. Bart: feasible to provide this? Not sure. But will be taken into consideration. To be detailed in implementation. Requester indeed needs to understand what the ccTLD manager needs to do to mitigate the risk. Combination of measures at the registry level. To be assessed by the panel. Needs to be proportionate. Not allowing the IDN ccTLD would be disproportionate. Check at the next meeting. Should be a point for detail? Reference to case study under the FTP Anil: thanks. B4.4. Detailing procedure itself. Copy and paste from current guideline. To document in policy itself how the procedure works Anil: possibility for (notes missing)? Bart: possibility that RTAP and requestor meet. Possibility for exchange of info. 9 and 10 Anil: but RTAP gives its report to requestor. Additional info or doc needed. But nowhere written that the requester can have a talk with RTAP. This is the final chance for the requestor Bart: face to face meeting? Anil: yes please. Bart: ok. Let’s discuss at the next meeting Anybody else have an opinion on Anil’s suggestion? None B4.5 2 options. String valid or invalid. Line 24-39 No questions or comments c. Review of Process sections (first reading) 1st reading was intense. 4. Next meetings a. Full Group | 15 November @14:00 UTC b. CS Subgroup | 22 November @14:00 UTC c. Full Group | 29 November @14:00 UTC – with GNSO EPDP Anil: 22 nov. meeting. postpone, as close to holiday? Joint meeting: 2 groups are aligned with respect to VM. focus on CS. Bart: since we meet on the 29th, suggestion is to meet also on 22nd. Any issues, Kim? Kim: none. 5. AOB None 6. Adjourn Thank you all. Joke Braeken joke.braeken@icann.org