Dear Justine: Believe me when I tell you I understand the constraints on the At-Large in policy making and how far it can take us even with all of us voluntarily trooping in a WG or even at GNSO discussions. Your faithfulness to the task is remarkable and deserves accolades. As a serial volunteer for WGs and RTs, I have developed a political sensibility in these fora where I buy whatever is being sold for what its worth. But I can only sell it for what I think its worth. First, ICANN - the public benefit corporation under the laws of the Great State of California - has interests singularly connected and severed from what we call the ICANN community. The Board is the selected guardian and Jones Day is usually available to remind them what that is. Second, the by-law gives the ALAC a very wide surface area for mouthing advice to the Board but the area where that advice is impactful is, comparably, very small. When our stakes are as small as they are and the opinions are, as in this matter, as scattered as they are, my view is that it is best for the ALAC to sit on our collective hands. We have to conserve volunteer engagement cycles and learn when to fold. Respectfully, Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Sat, 31 Aug 2024 at 00:29, Justine Chew <justine.chew.icann@gmail.com> wrote:
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:
Wise words. Wolfgang
Roberto Gaetano via CPWG <cpwg@icann.org> hat am 29.08.2024 23:10 CEST geschrieben:
Hi all
Maybe my post will be off topic, but I feel the desire to explain why this discussion makes me uncomfortable.
“Confusingly similar” things exist also in the real world - sorry for considering the domain name system a virtual world, even if there are some very “real" features attached, including money changing hands. The problem, in the real world, is approached by educating people to identify differences, so that they are no longer - or at least less - “confused by similarities”. Bees are confusingly similar to wasps, and some edible mushrooms are confusingly similar to some poisonous ones. The difference between the real and the virtual world is that in the real world you cannot eliminate the “confusing differences”, so you are forced to educate people to learn the differences. Incidentally, these differences and varieties are exactly the things that make the real world so interning and stimulating, and not dull.
Back to the practical issue at hand, would it not be more effective - and less complicated - have educational campaigns instead than crafting different and complex rules that, moreover, have to take into account cultural differences that our current mainstream Internet world is by and large even unable to understand? Bill has quoted languages, but there are cultural differences that go even beyond language, and that are not immediately understandable to engineers that come from a different culture, leaving alone the possibility to engineer a solution that takes these differences into account. Disclaimer: I am an engineer.
This in not an uncommon problem - and here I am *really* going off topic. It falls in the broad category of “finding an engineering solution to a cultural problem”. All attempts of this type that I am aware of have failed. The problem is that At-Large has to play a role in the Internet community - again, from my very personal point of view - that addresses the wide cultural, economic, social, etc. differences within the At-Large community, not to fall in the trap of supporting one or the other engineering pseudo-solutions that do not solve the problem, but give the impression that “people endorse it”.
Cheers, Roberto
On 29.08.2024, at 19:24, Carlton Samuels via CPWG <cpwg@icann.org> wrote: Hi Bill: Responses in line
============================== *Carlton A Samuels*
*Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* =============================
On Wed, 28 Aug 2024 at 16:40, Bill Jouris via CPWG <cpwg@icann.org> wrote:
Hi Carlton,
I'm all in favor of making the strongest argument possible. But I think it's a mistake to say "Our brief, apparently, is to advocate for the barely attentive end user." "Barely attentive" assumes that the user would have any reason to suspect that the plural of something that he remembers as singular is something entirely different.
....even with a faultless memory, I would rather think at this point the user is committed to an action. Get it done and see the result. Then, respond as best as you can.
If I see plum.org, and the actual name is plums.org, will it occur to me that there's a difference?
presence of mind, maybe not! But one could look see....
I beg leave to doubt it. It's not that I can't see the difference (part of my job is proofreading, after all). It's just that there is no particular reason to think that the difference is important in this context. Users generally are simply not paranoid enough to be suspicious of these things.
..and we should not wish them to be! Ordinarily, I posit the journey of discovery could be a learning experience.
Bill Jouris
Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...>
On Wed, Aug 28, 2024 at 9:32 AM, Carlton Samuels via CPWG <cpwg@icann.org> wrote: _______________________________________________ CPWG mailing list -- cpwg@icann.org To unsubscribe send an email to cpwg-leave@icann.org
_______________________________________________ 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.
_______________________________________________ CPWG mailing list -- cpwg@icann.org To unsubscribe send an email to cpwg-leave@icann.org
_______________________________________________ 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.
_______________________________________________ CPWG mailing list -- cpwg@icann.org To unsubscribe send an email to cpwg-leave@icann.org
_______________________________________________ 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.
_______________________________________________ CPWG mailing list -- cpwg@icann.org To unsubscribe send an email to cpwg-leave@icann.org _______________________________________________ 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.
_______________________________________________ CPWG mailing list -- cpwg@icann.org To unsubscribe send an email to cpwg-leave@icann.org
_______________________________________________ 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.