NOTES | ccPDP4 Confusing Similarities SG #15 | Tuesday, 24 January 2023 (14:00 UTC) 1. Welcome Welcome by Kenny and Anil 2. Admin items, if any a. Action Items none b. Meeting GNSO EPDP Anil: have we invited the EPDP WG? Bart: ICANN staff and Dennis confirmed they would invite the other group Kim: I forwarded the invite to Ariel Anil: i will also mention it during the upcoming EPDP session on Thursday c. Progress Full group (Review Mechanisms is completed) The full group completed its work on the review mechanism a week ago. Next work item: stress testing by the full group. They will continue until completed. Idea is to invite the EPDP group to the next full group meeting, next Tuesday. They will participate in the stress testing. The full wG will focus on stress testing, in parallel with the CS-subgroup. Highlights: * The RM as proposed by ccPDP3-RM will apply to decisions regarding the de-selection of IDN ccTLDs. * The group also completed its discussion whether or not the validation checks by icann org should be subject to the RM. They agreed that none of the validations should be subject to review. They are very factual, the impact is low, and there is an opportunity to discuss. * The 2nd panel (risk mitigation CS) is subject to (notes missing) * General statement: the icann independent review process and reconsideration process are not applicable. The selection procedure for this policy is excluded from the IRP and reconsideration. 3. Review of CS Document a. Updates of doc after 20 December meeting 1. Section 4.1 page 26-32 Now includes Description of base of comparison now includes the text from the originally agreed working document from August 2022, to provide more context to the choices made at the time. 2 risk categories: * No connection * Misconnection Bart: Do you agree that we go back to the text, agreed upon in August last year? Anil: What do members think? Open the floor to all Bart: what was discussed with Mirjana needs to be separated out. We will revisit that Bart: see docs on wiki. If you agree to go back to August, please use green zoom marks No red, some green. Bart: Any concerns regarding this text? Just to make sure the subgroup supports the approach Sarmad: This is slightly different from the solution by the GNSO. That is ok, but needs to be pointed out. In the request from the board there was a request for consistency. The WG may want to explain, or discuss with GNSO. Bart: this was raised during the last joint meeting as well. It was clear that with respect to this part of the CS, there are some differences. Alo in terms of process and procedures. Type of process, scope of policy, specifics from around IDN ccTLD strings. Need to be delegatable etc. to be included, once the doc will be published. This was an issue. Agreed to explain, along the lines just sketched. Remains to be seen whether this is sufficient to the Board. Jiankang: can Sarmad give a summary of the main differences between ccNSO and GNSO policy recommendations? Sarmad: scope of comparison for gTLDs is the string and its allocatable variants. That is a slightly larger set than the delegatable variants. When it is compared, the comparison is with string and allocatable variants on the one hand, and on the other hand the string, allocatable variants and the blocked ones. L2 on one side, level 3 on the other side. 2. Discussion impact of confusing similarity Requested variant Case B and C (page 43- 44) In green: what was discussed on 6 December meeting Agreement by group Yellow sections Do you agree? Few green marks, no red Sarmad: suppose there is an application. All meaningful labels. One is found CS. whole set then gets rejected. Re-application with the same set. Primary is changed to one of the delegatable variants. Only one is rejected (originally the primary) and the others get passed. 2 different outcomes, with the same set of strings. Bart: appreciate the point. But it is what it is. Applicant could foresee this upfront. Mirjana: when we applied for our IDN, we were not sure whether it was going to be accepted. Icann staff advised us to ask for 2 strings. Bart: is it is a concern whether it is string A or B? End-result is a delegatable variant Suggests to include Sarmad’s observation, alerting to the example Mirjana raised. Anil: agree Bart: selected string has passed. The primary core string is considered invalid? Then there is the opportunity for review, since it is the selected string. Should a review be allowed in case a delegatable variant is considered to be invalid, by the first panel Sarmad: primary string and delegatable string could be similar to each other, but not to other strings Bart: thar is dealt with. Variants always need to be delegated to the same entity If it is delegatable or confusingly similar to another TLD operated by the same entity (ascii and IDN), it should pass. To be noted. Sarmad: to be mentioned explicitly. Bart: agrees. Refer to the specific section in the similarity review process. 3. For 2nd reading: Inclusion of expansion of the SEP, page 40 See comment by Jiankang Expert with familiarity of the script Anil: should we call it ESEP? Sarmad: clarifications from process point of view. To be done before the evaluation? Bart: should be done before the evaluation. Before the final evaluation result is done. c. Discussion scope base for comparison Mirjana’s note (page 28-32) Mirjana: see note Bart: concerns regarding misconnection? Mirjana: indeed. No connection is no harm Bart: how does the misconnection work? The blocked variant cannot be included in the DNS Mirjana: correct. Bart: assumption the misconnection will only happen if the string is included in the DNS. there might be confusion, but more along the lines of typos. Sarmad: in the case of Mirjana, A1 may not be visually similar, but same for other reasons. Looking at Mirjana’s example, the 2 strings are variants potentially of eachother, but the 3rd one is not. If someone applies for the 2nd string on the screen, and someone else applies for the 3rd string, the panel might consider them similar. If someone applies for string 1 and someone else for string 3, they are not considered similar. Both can get delegated and added to the root zone. If someone is just looking at string 3, they may think it is something like string 2, and therefor think it is the same as string 1. Jaap: not up to the rule makers. If there is a blocked variant, they look the same in this case. Bart: procedural approach, allow the panel to come up with a rationale Jaap: that would work Mirjana: still do not see how the panelists would handle this They must have a script specialist. Sarmad: IDN pdpd group is coming to a similar conclusion. Panel to see in which blocked cases become relevant Bart: we come from different directions. Interesting. 4. First reading consolidated document 5. Next meetings o Full Group | 31 January 2023 @ 14.00 UTC o CS Subgroup | 07 February 2023 @ 14.00 UTC Anil and Bart thank all for the lively discussion. Bye all. Joke Braeken joke.braeken@icann.org From: CCPDP4-CS-SG <ccpdp4-cs-sg-bounces@icann.org> on behalf of Joke Braeken <joke.braeken@icann.org> Date: Tuesday, 24 January 2023 at 15:13 To: Kimberly Carlson <kimberly.carlson@icann.org>, "ccpdp4-cs-sg@icann.org" <ccpdp4-cs-sg@icann.org> Subject: Re: [CCPDP4-CS-SG] ccPDP4 Confusing Similarities SG teleconference (15) | 23 January at 14:00 UTC Hello All. To follow the live notes during today’s ccPDP4-CS subgroup meeting, go to https://docs.google.com/document/d/1Ct_ev0vMijD_qEqGZEKXYP5TAuBtjZGwVGJut02f... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Ct_ev0vMijD_q...> Best regards, Joke Braeken joke.braeken@icann.org From: CCPDP4-CS-SG <ccpdp4-cs-sg-bounces@icann.org> on behalf of Kimberly Carlson <kimberly.carlson@icann.org> Date: Monday, 23 January 2023 at 12:55 To: "ccpdp4-cs-sg@icann.org" <ccpdp4-cs-sg@icann.org> Subject: [CCPDP4-CS-SG] ccPDP4 Confusing Similarities SG teleconference (15) | 23 January at 14:00 UTC Dear all, As a reminder, the ccPDP4 Confusing Similarities SG teleconference (15) will be 23 January at 14:00 UTC. Agenda: 1. Welcome 2. Admin items, if any a. Action Items b. Meeting GNSO EPDP c. Progress Full group (Review Mechanisms is completed) 1. Review of CS Document a. Updates of doc after 20 December meeting * Section 4,1 page 26-32 Now includes Description of base of comparison now includes the text from the originally agreed working document from August 2022, to provide more context to the choices made at the time. * Discussion impact of confusing similarity Requested variant Case B and C (page 43- 44) * For 2nd reading: Inclusion of expansion of the SEP, page 40 * Discussion scope base for comparison Mirjana’s note (page 28-32) 1. First reading consolidated document 2. Next meetings * Full Group | 31 January 2023 @ 14.00 UTC * CS Subgroup | 07 February 2023 @ 14.00 UTC Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/97250338439?pwd=OW1qbVhEaUFYeHAzcVZrcExYVDdHQT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/97250338439?pwd=OW1qbVhEa...> Meeting ID: 972 5033 8439 Passcode: PDP4CS-124 Wiki: https://community.icann.org/x/wgGBDQ