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?
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
6. Closure
Thank you all. Bye
Joke Braeken
joke.braeken@icann.org