NOTES | ccPDP4 Confusing Similarities SG #15 | Tuesday, 24 January 2023 (14:00 UTC)
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:
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:
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_qEqGZEKXYP5TAuBtjZGwVGJut02fNNg/edit?usp=sharing [docs.google.com]
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:
a. Action
Items
b. Meeting
GNSO EPDP
c. Progress
Full group (Review Mechanisms is completed)
a.
Updates of doc after 20 December meeting
Please find the call details below:
Join Zoom Meeting
https://icann.zoom.us/j/97250338439?pwd=OW1qbVhEaUFYeHAzcVZrcExYVDdHQT09
[icann.zoom.us]
Meeting ID: 972 5033 8439
Passcode: PDP4CS-124
Wiki:
https://community.icann.org/x/wgGBDQ