Hello Justine,
First, thank you for doing the best job possible given the current restraints you find yourself in. As I am often reminded over my 25-plus years of involvement with ICANN, no good deed goes unpunished. Keep
up the great work that you are doing.
Hello Roberto,
Thank you for artfully reminding us of two of the more significant flaws of ICANN and its policy development process: the inability to Keep It Simple, Stupid (KISS) and the need to always reinvent the wheel.
One of the biggest disappointments I have had with ICANN Org and the Board recently is its overly expansive interpretation of how the bylaws prevent it from doing anything that might touch on content. The fact that the ICANN Board cited it in declining to
accept (aka rejecting) one of the previous proposals is disappointing. While I think there is almost universal agreement within the ICANN community that it is clearly outside of ICANN’s mission to attempt to regulate content on the internet, the inconvenient
truth is ICANN has seemed to have forgotten that there are sometimes that content is inextricably intertwined to advancing its core mission and must be considered. As I have publicly discussed with Becky Burr in past ICANN meetings, the UDRP (one of ICANN’s
most successful consensus policies) relies upon a third-party dispute provider analyzing the use of a domain name (i.e. content appearing on a website) to decide if the registration and use of a domain name is in bad faith or a fair use. Sadly, under the current
Board view regarding the ICANN bylaws' content provision, I wonder if the ICANN Board would approve the UDRP if it was presented to them today for adoption.
Hello Alan, Bill and Justine,
I want to weigh in on this thread a little more articulately than I did on last week’s CPWG call.
My BIGGEST concern was a comment that Justine made at the end of her presentation in response to Alan's question about her personal opinion on the issue. Justine responded , and I am paraphrasing here, that
this was the best compromise she thought the ICANN Board could live with. ICANN is supposed to be a bottom-up consensus-building organization. Multiple times, the community recommended a proposed solution to the Board, which they did not accept. The Board
stating directly/indirectly that this is the best we can accept is de facto top-down policy making. I understand that there are times when the fiduciary obligations of the Board may require it to take a different policy position as advanced by the community,
but singular and plurals are not one of them, in my opinion.
I actually think the Council small team had it right when they stated that there should be a reputable presumption against having singular and plural TLDs. As I tried to articulate in the .TV and .TVS example
from the 2012 round, you can have two TLDs exist, one being the plural of the other, without confusion. Bill just stated in a separate response on the CPWG list, making determinations between singular and plural is hard especially in some non-Latin languages.
However, a faithful trustee of a global resource should be able to make these determinations instead of looking for the easiest solution to mitigate any burden on ICANN legal and compliance – with great power comes great responsibility.
Best regards,
Michael
From: Justine Chew via CPWG <cpwg@icann.org>
Sent: Saturday, August 31, 2024 1:28 AM
To: Carlton Samuels <carlton.samuels@gmail.com>; Bill Jouris <b_jouris@yahoo.com>; Roberto Gaetano <roberto_gaetano@hotmail.com>
Cc: CPWG <cpwg@icann.org>
Subject: [CPWG] Re: Singular/Plural Strings and End User Confusion
Dear Carlton,
I mentioned at the call that mitigating risk of end-user confusion remains one of the core goals of the At-Large/ALAC as supported by existing ALAC positions. Apart from this discussed prohibition of singular-plurals versions of the same word in the same language
being delegated, I can think of another occasion where At-Large input was instrumental towards maintaining this goal - the conservative approach to introduction of allocatable variant gTLD labels.
While I agree that the ICANN community could do a better job of taking a consistent overarching approach to policies which govern what ICANN can govern, the fact remains that we are constrained by a combination of factors - ICANN remit per Bylaws, scope in
gTLD policy-making per the charter of each PDP process, active monitoring of and timely participation in each PDP, differences in opinion/positions held by various groups impacting the ability to arrive at (some level of) consensus during the PDP, etc etc
etc.
We have arrived at this juncture because the Board declined to adopt the original consensus-generated GNSO policy recommendation with STRICT regards to this issue of singular/plural words causing consumer confusion from the 2012 round - which as I said, was
identified as an issue needing policy intervention. The SubPro PDP had discussed closely related aspects (if memory serves me correctly, including feminine/masculine words, acronyms) but did not come to consensus on those. Which is why the present issue is
on "singular-plurals versions of the same word in the same language".
Given all the factors that I mentioned above, if we are to have a say in this STRICT issue, then what I discussed at the call is it.
Sure, we can consider how to approach what we, as a group, decide is best to address "consumer protection, identity verification, avoiding brand and trademark conflicts, preventing domain name collisions, combating cybersquatting, and maintaining the integrity,
stability, and predictability of the namespace" but there are other policies for driving those goals, even some which are still in the making.
However, as your GNSO Liaison, I can only bring what is being discussed currently and narrowly for input in order to determine if we, as a group, want to have a say in this STRICT issue.
Dear Bill,
The proposed position being discussed is to support a ban, and with no exceptions. However, the Board has made it clear that it would be unworkable for ICANN org to be responsible for a blanket ban, which is why the approach proposed is a crowd-source one,
i.e. anyone can notify ICANN org of the 2 instances that I discussed:
1- where a singular or plural version of an existing gTLD (or Blocked Name per Annex A) has been applied-for; or
2- where two (or more) applied-for strings are singular and plural versions of each other.
In both situations, reference to a dictionary supporting the claim must be provided to facilitate verification. We can exercise further thought on the definition of 'dictionary' in implementation as we have been discouraged from being too prescriptive at this
point.
And the crowd-sourcing approach means that if no one notifies ICANN org or is unable to substantiate their claim by reference to a dictionary (likely per the satisfaction of a panel empowered by ICANN) then the impacted application (in scenario 1) or applications
(in scenario 2) can proceed to the next steps of evaluation (which they still need to pass to succeed in getting the string)
Dear Roberto,
While I appreciate your remarks about "confusingly similar", I have to again stress that we are limited at this juncture to only the issue of singular/plural of the same word in the same language. I also appreciate
it's not the best response to your input but it's the only one I have to offer.
Respectfully,
Justine
On Fri, 30 Aug 2024 at 15:19, Wolfgang Kleinwächter via CPWG <cpwg@icann.org> wrote: