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