I’ll go first. Thanks for this work Lars.

I think Paul’s choice of words below is “interesting."

If our goal is to prevent user confusion, then our approaches to user confusion due to visual similarity and user confusion due to singular/plural should be the same. Why would we place a hurdle in the form of a community objection for one form of user confusion and not the other, since delegation of both visually similar and singular/plural TLDs have the same detrimental outcomes?

The fact that the singular/plural identification is objective ("ICANN would simply look up the relevant dictionary …  if the two strings are similar/plural…”) makes it even less necessary to have a person weigh in. If any sort of confusion would require an objection, it seems it would be the largely subjective string similarity review. (But I am not advocating for that either.)

Put another way, ICANN will look the other way on applications resulting in string confusion if no one objects. That does not seem consonant with our goal of preventing string confusion. It is ICANN’s responsibility to prevent user confusion, especially those users who are not participating in our processes or those who are yet to come. 

In addition to the poor policy outcomes, there are other complexities with an objection process. Is the objector required to use a specific mechanism or can s/he merely write a note to someone on staff or Board? Is anonymity allowed? Different implementation decisions might affect which confusing sets of string are or are not delegated. 

User confusion resulting from the delegation of singular/plurals was recognised by the SubPro WG and others as a short-coming in the previous round and there was community unanimity that it should be fixed. 

Apologies if my note seems conclusory. It is meant to be a conversation starter as I understand there are implications that I don’t understand. 

Regards,

Kurt

On 17 Apr 2024, at 6:53 am, Paul McGrady via council <council@gnso.icann.org> wrote:

Thanks Steve.  Interesting stuff.
 
Best,
Paul
 
 
From: council <council-bounces@gnso.icann.org> On Behalf Of Steve Chan via council
Sent: Tuesday, April 16, 2024 11:35 AM
To: council@gnso.icann.org
Subject: [council] High-Level Overview of Singular/Plural Compromise
 
Dear Councilors, 
 
In my email to you all on 12 April, I indicated that my colleagues were working on a high-level overview of a possible approach for singular/plurals. Please see the message below from Lars Hoffmann, which also includes that high-level overview at the end of his message.
 
Best,
Steve
 
 
Dear Councilors, 
 
I hope this finds you well. I am reaching out about the supplemental recommendation 24.3 (singular/plurals). Following the Board non-adoption of the SubPro PDP’s recommendation, the Small Team Plus has proposed a supplemental recommendation. While I cannot speak on behalf of the Caucus nor the Board, I can share that the Caucus has asked us (staff) to look at possible alternative solutions that achieve the goal of the recommendation, without some of the concerns that the Board has previously expressed around recommendation 24.3.
 
Therefore, we put on our thinking hats and drew up a very high-level proposal that was well received by the Caucus. This morning (LA time, which was extremely late in Australia), we discussed this approach with the IRT Council liaisons (Susan and Anne), the former PDP WG co-chairs (Cheryl and Jeff), and Greg in his role of Council chair. Steve Chan also attended the call. I think I am correct in saying that after a good discussion with a lot of excellent questions from everyone, there is a general feeling in that group that the compromise should work and would generally achieve the same outcome that the supplemental rec 24.3 is aiming for but with lower costs and doing so more quickly, too. Below you will find a high-level outline of the approach. I would be happy to provide more details on this week’s Council call or at any other opportunity that suits the Council.
 
I would kindly ask you to read the high-level summary with an open mind and if you have any questions, I will be happy to answer any preliminary ones on-list and, of course, during Thursday’s call, if the Council thinks there would be a benefit for me to dial in. 
 
If the Council believes this proposal ‘has legs’, the Council may want to consider deferring a vote on 24.3 only (the other supplemental recs could move forward as planned) and then, in the interest of time, staff could prepare in the coming days some more detailed strawperson language for the Small Team Plus and the Council Liaisons and/or staff to discuss. And, a final note, as the staff lead for the IRT, I believe that if the Small Team Plus continues it work as efficiently as it has done in the past, and if they collaborate with the Council liaisons and/or staff, there will be no impact on the overall implementation timeline of the next round if the Council withdrew the current 24.3 and voted on a new version no later than its meeting in July. 
 
Thank you so much and I am looking forward to working together on this complex but important issue.
 
Best wishes,
Lars
 
  
The Singular/Plural Compromise: High-Level Overview
 
  1. String Similarity review will remain a review solely based on visual similarity - assessing whether the two or more strings are visually confusingly similar.
  2. ICANN org and IRT will discuss during implementation what measures - if any (based on recommendations) could be put into place to increase consistency of reviews compared to the 2012 round. But it will remain a visually-confusing test only.
  3. Policy would provide that singular/plurals in the same language of any word will be put into contention, if so requested by “anyone”. If one of these strings is already delegated, then the applied-for string cannot proceed, if so requested by “anyone”
  4. This means that singular and plurals of the same word in the same language COULD be delegated. 
  5. It puts the onus of reviewing applied for and existing strings on the applicants and the community members (i.e., “anyone”) to make a request to ICANN, based on such policy, to verify that two strings are singular/plural of each other in a specific language (to be specified by the ‘requestor).
  6. ICANN would simply look up the relevant dictionary - in the language that the requestor specified - and if the two strings are similar/plural of reach other would act accordingly (put them into contention or inform one applicant that their application cannot proceed if it is the singular/plural in the same language of an existing string).
  7. The period of ‘requesting’ such action from ICANN could stretch from reveal day until the contention sets are finalized - bearing in mind that subject to the outcome of string similarity, other strings may join a singular/plural contention set. For example, .bank and .banks may be joined by .banh. Please note again: if no one requests that .bank and .banks will be in contention and they are not caught in string similarity, and there is no .banh, then both .bank and .banks could be delegated. 
 
 
 
 
 
 
Steven Chan
VP, Policy Development Support & GNSO Relations
 
Internet Corporation for Assigned Names and Numbers (ICANN) 
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
                                                                  
Skype: steve.chan55
Mobile: +1.310.339.4410
 
Find out more about the GNSO by visiting: https://learn.icann.org/
Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO
Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar 
_______________________________________________
council mailing list
council@gnso.icann.org
https://mm.icann.org/mailman/listinfo/council

_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.