May 2022 - CCPDP4-CS-SG - lists.icann.org

NOTES | ccPDP4 IDN Confusing Similarity Subgroup (#5) | 24 May 2022 at 13:00 UTC.
by Joke Braeken May 24, 2022

May 24, 2022

NOTES | ccPDP4 IDN Confusing Similarity Subgroup (#5) | 24 May 2022 at 13:00 UTC. 1 Welcome and roll call Welcome by Kenny Apology by Anil 2 Administrative Items a. IDN EPDP Update Bart: last week they dealt with the base for comparison. What is the scope of a CS review? They have additional issues: other kinds of similarity. They work through the issues with smaller WGs. Could someone please confirm or correct what I said? Pitinan: correct. String similarity in smaller group to discuss the examples. Scope being discussed in 3 levels: applied for string, applied for and allocatable set, blocked variants and allocatable variants. The main group talks about the next charter question, which is the objection process. Bart: objection process is not in ccPDP4 b. Sessions at ICANN74 Tuesday, 14 June 2022 • ccNSO: Policy Update | 11:15-12:30 UTC • ccPDP4 IDN Meeting | 14:30-15:30 UTC The ccNSO is planning a policy session for ICANN74 to showcase its work. Two ccNSO PDP (ccPDP) working groups will provide updates on their progress and seek input. Both working groups will also hold their respective sessions during ICANN74. * Third ccPDP on the Retirement of ccTLDs (ccPDP3) | The ccPDP3 working group has identified which decisions related to the retirement of a country code top-level domain (ccTLD) that should be subject to consideration by the group and explored requirements for the review mechanism. The working group is considering various requirements for approval, including the bindingness of the review mechanism. The working group charter, work plan, and other relevant documents are available on its website<https://ccnso.icann.org/en/workinggroups/pdp-retirement.htm> and workspace<https://community.icann.org/display/ccnsowkspc/Policy+Development+Process+%…>. * Fourth ccPDP Working Group on the (de)selection of Internationalized Domain Name (IDN) ccTLD strings (ccPDP4) | The ccPDP4 working group completed its review and discussion of the 2013 policy proposals for the IDN ccTLD string selection process. The ccPDP4 consists of three subgroups: the variant management subgroup, the confusing similarity review subgroup, and the de-selection subgroup. By ICANN74, all subgroups will have completed their initial proposals, or will be in the final phases of doing so. During ICANN74, the working group will hold a session to start the stress-testing of its draft policy recommendations. The working group charter, work plan, and other relevant documents are available on its website<https://ccnso.icann.org/en/workinggroups/idn-cctld-strings.htmups/pdp-retir…> and workspace<https://community.icann.org/x/ZoBIC>. Bart: check full policy, once completed against scenarios. Do the results make sense, against the original intentions? >>>> Definition of Stress Testing Stress Testing is defined as: * Test the process as developed by applying the process to “corner case” situations and understand whether such a case results in an unwanted outcome or side effects. * If the outcome of that situation results in an unwanted outcome or side effects adjust Policy/Process as needed. After completion of the draft process the Stress Testing was conducted through answering the following questions: * What is the outcome of this situation when the process is invoked? * Is the outcome of that situation/the result unwanted or are side effects unwanted/unacceptable? * Does the Policy/Process need to be adjusted/refined? Bart: Shall I prepare draft slides for the 31 meeting? Kenny: Yes, please. Lets also circulate with the WG members before we present it at ICANN74 Hadia: do you want to know more about string similarity review small teams? Meeting last wednesday. Pragmatic group. Avoid edge cases. Question if there is a chance to appeal decisions on string similarity. Out of scope. Limited appeals process. Edmun presented an edge SBC case. Strings that look alike, but are not variants. Group meets again on Wednesday. No examples that address the presented cases. 3 levels Bart: The idea is that the groups stay informed about each other's process, and there is alignment between the 2. Some aspects do not apply to ccTLDs. 3. Basics Confusing Similarity Review – document v3 Discussion section 3. Base for comparison Sarmad: question about conditions at top of the page. 3rd bullet. Are we also comparing them with gTLDs? Bart: both ccTLDs and gTLDs? Hence TLDs. at this stage. Bart: all delegated TLDs are different delegations. Therefore, all need to be included in the base for comparison. The discussion on allocatable or blocked is secondary for delegated TLDs. Questions or comments ? we are at page 2 now. Ai-Chin: think one of the reasons for submitting the IDN table is to avoid CS. maybe a CS problem in future. Example. We do not need to submit the table, if we just check or review the delegatable variant. That is easy. We just provide 2 requested strings. That is why we submit the IDN variant label. Blocked and delegated variant cause confusion. Perhaps also include the blocked and allocatable variants? Please consider Bart: idn table is not submitted anymore for TLDs. determined by the RZ-LGR Ai-Chin: we prepared a CGK. that is the variant table. We already considered blocked variants, that will cause CS with the requested idn ccTLD string. Maybe not now, but later. Bart: other comments or questions? Sarmad: as a background. Shares that the reference point for this comes from SSAC16 report. 2 kinds of problems: * If both of the DNs are delegated, it causes a blocked connection * Causes a denial of service. SSAC thinks is not a good solution. Try from an end-user perspective, the solution does not cause misconnection. Bart: where does it stop? Blocked variants? Or allocatable? Moreover, we talk about delegatable. When a string is requested, we need to ensure about CS. probability needed. But where do you draw the line with respect to risk? Needs to be probable, not just possible. Sarmad: string that is highly probably confusable with a blocked string of another variant. Case: potentially highly probable. That is what we try to solve. EPDP looks at some scenarios. Try to understand the problem better. Bart: what is already delegated as a starting point. Why do we do this? 1. Scaling. Understanding the numbers. See discussion 2 weeks ago. Examples from the staff report on IDN variants 2. Unwanted side-effects Section 4: defining the base for comparison, taking into account arguments listed above. Hadia: what would be the benefit of comparing the original label, in addition to the allocatable, and the blocked, if any? Why included the blocked as well Bart: see what Sarmad said Sarmad: quick summary. Basically possible to generate some confusion through transitive relationship. If you have a TLD string A, and it has a variant blocked (B). A and B are considered the same. Separate TLD (C ). Compare A and C: are they similar? Should we also compare B with C, given that B is not applied for. B is a variant. And is the same as A, that is the definition of a variant. If C is highly probably confusable with B, there is a high confusing connection between A and C. that is what we try to solve here Hadia: 1/ we cannot put blocked variants with allocatable but not requested. Blocked variants will never be allocated. Unless LGR changes. Highly improbable 2/ what do we mean by the same? Only visually? Or also the same in meaning? Sarmad: in variants, “same” could be anything. Defined by the script community. Same could be based on meaning. Concrete example. Simplified chinese label. Which has a blocked traditional chinese label. Another applicant applies for a traditional chinese label, which is very similar to the blocked variant for the simplified, 1st application. Visually similar to the traditional chinese blocked label. There is a potential for misconnection indirectly. Hadia: i do not see it happening. Indirect connection Ai-Chin: That's why we have RZ-LGR IDN vaiant table. Sarmad: agrees. Extensive work done by script communities. Lots of visually closed cases have been pulled into the variant sets. There may be some which are on the borderline. The more obvious cases have been pulled into variants sets. Problem is now smaller Bart: leave it as it is for the time being. Revisit next time. Arguments need to sink in Need to avoid unwanted side-effects Questions regarding section 4 Ai-Chin: for the CS issues, it will be operated by a program. Not by a human. So the number of variants is not important. Why do we need to limit? Bart: to date not automated. Manually. That is the real issue. Hadia: if you include more labels of strings in the comparison, that will not affect the space, you limit the possibility of the existence of a label that is not existing, since it was compared to an irrelevant label Bart: yes, second reason: unwanted side-effects. This was 1st reading. Positive vibe to this type of definition? Hadia: scalability void if automated in future Bart: both. Scalability, and unforeseen side-effects. Will update section 1 and 2 based on what Sarmad said 2 weeks ago. We will revisit again in 2 weeks time. This sets the base for the next steps. The base for comparison has been the most complicated part. 4. AOB none 5. Next meetings 31 May Full Group Prep/discussion ICANN74 | 13:00 UTC (first hour) · VM SG 14:00 UTC | Second hour 7 June – Prep ICANN74 (TBD) Bart: When does this group re-convene? Either 2 or 3 weeks after ICANN74. 28 june, 5 july? Kenny: tentatively propose 28 June. same time 6. Closure Thank you all. Joke Braeken joke.braeken(a)icann.org

1 0

REMINDER: ccPDP4 IDN Confusing Similarity Subgroup (#5) | 24 May at 13:00 UTC.
by Kimberly Carlson May 24, 2022

May 24, 2022

Dear all, As a reminder, the next ccPDP4 IDN Confusing Similarity Subgroup (#5) teleconference is scheduled for 24 May at 13:00 UTC. Agenda: 1 Welcome and roll call 2 Administrative Items a. IDN EPDP Update b. Sessions at ICANN74 Tuesday, 14 June 2022 • ccNSO: Policy Update | 11:15-12:30 UTC • ccPDP4 IDN Meeting | 14:30-15:30 UTC 3. Basics Confusing Similarity Review – document v3 Discussion section 3. Base for comparison 4. AOB 5. Next meetings • 31 May Full Group Prep/discussion ICANN74 | 13:00 UTC (first hour) · VM SG 14:00 UTC | Second hour • 7 June – Prep ICANN74 (TBD) 6. Closure Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/98844946499?pwd=VXpDb3hVS2cxZUJ3OUZDc2lhbmlBdz09 Meeting ID: 988 4494 6499 Passcode: ccPDP4-CS# Wiki: https://community.icann.org/x/4gvCCw

2 1

ccPDP4 IDN Confusing Similarity Subgroup (#5) teleconference | 24 May at 13:00 UTC
by Kimberly Carlson May 24, 2022

May 24, 2022

***STARTING IN ONE HOUR*** Dear all, The next ccPDP4 IDN Confusing Similarity Subgroup (#5) teleconference is scheduled for 24 May at 13:00 UTC. An agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/98844946499?pwd=VXpDb3hVS2cxZUJ3OUZDc2lhbmlBdz09 Meeting ID: 988 4494 6499 Passcode: ccPDP4-CS# Wiki: https://community.icann.org/x/4gvCCw

1 0

ccPDP4 IDN Confusing Similarity Subgroup (#5) teleconference | 24 May at 13:00 UTC
by Kimberly Carlson May 17, 2022

May 17, 2022

Dear all, The next ccPDP4 IDN Confusing Similarity Subgroup (#5) teleconference is scheduled for 24 May at 13:00 UTC. An agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/98844946499?pwd=VXpDb3hVS2cxZUJ3OUZDc2lhbmlBdz09 Meeting ID: 988 4494 6499 Passcode: ccPDP4-CS# Wiki: https://community.icann.org/x/4gvCCw

1 0

NOTES | ccPDP4 IDN Confusing Similarity | 10 May 2022 (13 UTC)
by Joke Braeken May 10, 2022

May 10, 2022

NOTES | ccPDP4 IDN Confusing Similarity | 10 May 2022 (13 UTC) 1 Welcome and roll call Welcome by Chair Anil Kumar Jain (.in) 2 Administrative Items a. IDN EPDP Update House is divided. Subgroups will discuss the various cases of confusing similarity. Level 1, 2, 3. What are the precautions that need to be taken? Single level of evaluation? More? Today is deadline to apply for the subgroups. b. Sessions at ICANN74 Tuesday, 14 June 2022 • ccNSO: Policy Update | 11:15-12:30 UTC See also ICANN71. VM-group makes considerable progress, this group as well. The DS-group concluded. Opportunity to seek feedback from the community on the results today. Sessions lasts 1h and 15 min. 35 to 40 min for ccPDP4. ccPDP3-RM needs to discuss matters too. • ccPDP4 IDN Meeting | 14:30-15:30 UTC Full WG meeting. With respect to participation, same type of experience, whether you attend remotely or in person. Focus will be on stress-testing. It is not a heavy discussion, rather about being creative. See 31 may meeting, when we prep. Anil invites all to attend the session. 3. Basics Confusing Similarity Review - document Anil refers to the items discussed last time. 3.1. 2nd reading need for review See slides where we introduced the CS review. Bart started to write down some questions. Base for comparison? What should be in/out of the base? >>> section 1 Revisit as a 2nd reading. Taken from a doc that was developed in 2013. It captures the arguments from the slides nicely. Latin and cyrillic. Therefor EU biased. Captures the need for the CS-review and the rationale. Any questions to the text of section 1? None Are you in favour of the text? No red marks Agreement on CS review need, and the reason why 3.2. 2nd reading approval standard of review See text in slides. From the intro on EPSRP. Definition is in bold, starting with “if the visual appearance ….” That is the principle standard for evaluation. Reference to common fonts. That delineated and limits the scope of the review. Gives direction of what could be expected from a reasonable internet user. Also pixel size. Observation to illustrate what is meant. Questions or comments on the definition? None Questions or comments using the observations and/or illustrations? Sarmad: should we add that other string could also be in upper/lower case? Bart: revisit when we start the base for comparison? Going back to the standard for evaluation itself Bart: other comments? Jaap: off terminology. Size of pixel. Pixels that define the picture. Bart: number of pixels? Jaap: yes Bart: should we add this for clarification? This is not about the text. Does it make sense to add the clarifications? No red ticks Bart: we will add this to the text Bart: do you agree with the addition suggested by Sarmad? Do you agree with the proposed text? Adding upper/lower case. Friendly amendment. Questions? None Do you agree with the text? No red marks 3.3. Introduction of Base for comparison Describing base for comparison. Under FTP and the 2013 policy, there was a limitation on the CS, the scope of the CS, and the combination of letters a-z, existing TLDs (IDN ccTLDs, gTLDS, and reserved names. And proposed TLDs under string evaluation). Was excluded in 2013. But you do not want CS with an IDN gTLD either. That is why it is included. Original base of comparison, without variants. There are at least 4 relevant categories with respect to the number of variants. Full set of variants: blocked and allocatable. The blocked ones are excluded from use as TLD from the RZ-LGR. Largest set of variants. Allocatable variants. Sets permissible under the RZ-LGR for a certain script. Limit the number of variant tld string. Also take into account the criteria for IDN TLDs. delegatable or activatable. VM-group discussed that if there is a delegatable variant, it is not necessary that the variant will be delegated. Not an automated procedure. A delegatable variant needs to be requested at the time when the IDN ccTLD string is requested for validation. Only after verification and when documentation is provided, they are verified, and then they can request it to be delegated. Slight deviation from the discussions under the EPDP. more levels. Ariel confirmed Discussion more refined to date. The base for comparison is any combination of the 2 iso. Reasonable starting point as the base for comparison? Green ticks. What we need to decide: with this foundation, think which variants should be included in the comparison. And understand the consequences. We tried to understand what it means to include the various kinds of variants. Delegatable, ending with the blocked variants. See staff paper January 2019. 2 examples: Abu Dhabi in Arabic script, Pakistan in Arabic script. Understanding of meaningful representations, and its impact. 80 variants, of which 78 are blocked. One is valid, one is allocatable. If we would expand this to include all the blocked variants, that would increase the assessment. If you look at the Pakistan example: using the same numbers and what is included in the staff paper. The number of variants from blocked to requested-delegatable. Pakistan in arabic script is a better illustration of the scaling issue. Any questions on using the numbers? None If you need to do a statistical relevant review, you need to have a considerable number of volunteers, who will look at the various comparable strings, to determine whether there is a significant reason for CS. basis used by EPSRP. There is a scaling issue. Additional issue: if the base for comparison is not properly delineated, there might be some unforeseen results and side-effects, taking these issues into account: we now should focus on discussing the scope of the base for comparison. Limited to delegatable variants for instance? See discussion in next step. Focus on sets for comparison. All possible 2-letter codes, the tld strings. That is the basis for comparison What should be the result of the review in the following cases? * Bullet 1 * Bullet 2 * Bullet 3 See doc displayed in zoom. Jaap: political matter. Everything should be taken as a string. Whether it is a variant of another string does not matter. Bart: The starting point is the fact that an idn cctld string is selected. If the selected string is confusingly similar, should the others go through? Assuming it meets the criteria, it could go through, if the only issue with the selected one is confusingly similar. But it has to be a requested delegatable variant (meaningful representation of the name of the territory) Third question. Based on Jaap’s comments, it does not matter. As soon as it is a delegated tld string, the CS should be taken into account, at least for the selected idn string. The confusingly similar string should be terminated. Fair consequence of bullet 1 and 2? Proposal Bart: Revisit this text again and present it in another format at the next meeting? Anil: if members want this, yes. But similar discussions happen also in EPDP. Ai-Chin: verify something. First question. What is the IDN delegatable variant? We have RZ-LGR. We have a package. Bart: understands from discussion at VM, this is about the limitation of the number of variants. Variant needs to be a meaningful representation too Do people want this to be delegated? To ensure we look at a limited set, t should be requested at the start of the process Ai-Chin: clear. First one is confusing. Variant needs to be terminated. Bart: by including blocked variants. Other end of spectrum Are you in favour of including blocked variants in the CS-review? Kenny: can be included Bart: but taking into account the scaling issues, and the weird side effects? Hadia: why does Kenny think they should be included? Kenny: variant has a correlated string. Idn string should be considered Bart: but they will never be delegated Mirjana: blocked variants not to be included Anil: need to drop off Bart: meeting will end in a few minutes Will clarify better next time. Then go to the other 2 cases. 4. AOB None 5. Next meetings * 17 May VM SG | 14:00 UTC * 24 May CS SG | 13:00 UTC * 31 May Full Group Prep/discussion ICANN74 (subgroups invited to attend) | 13:00 UTC * 7 June – Prep ICANN74 (TBD) 6. Closure Thank you all. Bye Joke Braeken joke.braeken(a)icann.org

1 0

REMINDER: ccPDP4 IDN Confusing Similarity Subgroup (#4) teleconference | 10 May at 13:00 UTC
by Kimberly Carlson May 10, 2022

May 10, 2022

Dear all, As a reminder, the next ccPDP4 IDN Confusing Similarity Subgroup (#4) teleconference is scheduled for 10 May at 13:00 UTC. Item #3 document will be circulated prior to the call. Agenda: 1 Welcome and roll call 2 Administrative Items a. IDN EPDP Update b. Sessions at ICANN74 Tuesday, 14 June 2022 • ccNSO: Policy Update | 11:15-12:30 UTC • ccPDP4 IDN Meeting | 14:30-15:30 UTC 3. Basics Confusing Similarity Review - document 3.1. 2nd reading need for review 3.2. 2nd reading approval standard of review 3.3. Introduction of Base for comparison 4. AOB 5. Next meetings * 17 May VM SG | 14:00 UTC * 24 May CS SG | 13:00 UTC * 31 May Full Group Prep/discussion ICANN74 (subgroups invited to attend) | 13:00 UTC * 7 June – Prep ICANN74 (TBD) 6. Closure Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/98269533215?pwd=SkphcndVNjRicmw1bnJQcitubjFsdz09 Meeting ID: 982 6953 3215 Passcode: ccPDP4-CS# Wiki: https://community.icann.org/x/-wx1Cw

3 2

ccPDP4 IDN Confusing Similarity Subgroup (#4) teleconference is scheduled for 10 May at 13:00 UTC
by Kimberly Carlson May 10, 2022

May 10, 2022

***STARTING IN ONE HOUR*** Dear all, The next ccPDP4 IDN Confusing Similarity Subgroup (#4) teleconference is scheduled for 10 May at 13:00 UTC. An agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/98269533215?pwd=SkphcndVNjRicmw1bnJQcitubjFsdz09 Meeting ID: 982 6953 3215 Passcode: ccPDP4-CS# Wiki: https://community.icann.org/x/-wx1Cw

1 0

ccPDP4 IDN Confusing Similarity Subgroup (#4) teleconference is scheduled for 10 May at 13:00 UTC
by Kimberly Carlson May 2, 2022

May 2, 2022

Dear all, The next ccPDP4 IDN Confusing Similarity Subgroup (#4) teleconference is scheduled for 10 May at 13:00 UTC. An agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/98269533215?pwd=SkphcndVNjRicmw1bnJQcitubjFsdz09 Meeting ID: 982 6953 3215 Passcode: ccPDP4-CS# Wiki: https://community.icann.org/x/-wx1Cw

1 0