First, let me commend ICANN for finally coming out with a substantive statement on the deplorable antisemitic comments made by Talal Abu Ghazaleh, founder and chairman of the Jordan-based organization, Talal Abu-Ghalzaleh Organization (TAG-Org). In its response, ICANN acknowledged that such hate speech "has no place in ICANN's multistakeholder process," and that these comments violate ICANN's Expected Standards of Behavior." ICANN has also apparently reached out directly to inform TAG-Org of the violation and have referred this matter to the Office of the Ombudsperson to investigate and make further recommendations.
ICANN's response then points out, what was already known (more on this below), that TAG-Org was not just hosting an instance of the L-Root, but is also a dispute provider, domain name registrar, and an ICANN community member. And in lumping all of these roles together, ICANN punted the issue back to the community by posing the question "What role, if any, should ICANN have in addressing egregious conduct that violates the Expected standards of Behavior to the extent that is could cause significant reputational harm to ICANN and the multistakeholder model if left unaddressed? This is an area for which there is currently no policy or community guidance."
To sum it up, ICANN condemned the hate speech (good), but then engaged in over-analysis paralysis to unnecessarily complicate the issues and to justify its unwillingness to take any additional affirmative action. And, as most people in the community predicted, ICANN pushed the issue back to the community. Here is why I believe this is the wrong approach.
1. ICANN Alone Must Decide TAG Org's Fate in Hosting Instance of L-Root
Yes, ICANN, I knew that TAG-Org has more roles than just being the operator of an instance of ICANN's L-Root. I knew they were also a registrar, dispute provider and a community member.
But there is a reason that I only asked ICANN to take action against TAG-Org in its role in hosting the instance of ICANN's L-Root. Unlike the other (more complicated roles), hosting an instance of ICANN's L-Root is NOT a community-based function. It never has been. ICANN's decision on who hosts instances of the L-Root is made solely by ICANN Org without any input from the community. ICANN Org alone sets the criteria for selecting (or not selecting) a particular party to host an instance of the L-Root through its procurement processes. In this role, TAG-Org is strictly a vendor of ICANN Org.....no different than who ICANN selects to provide its vending machines for its offices, who it chooses to host its own web servers, or who provides the organization with hardware for its data servers.
In fact, of the 195 L-Root instances that exist, the vast majority of them were selected by ICANN Org engineering staff without any input from even its own Board of Directors. But in the rare instances that the ICANN Board has been involved, the Board Minutes clearly point out that the selection of who gets to host instances of the L-Root and the terms and conditions of such hosting "is an Organizational Administrative function that does not require public comment." See https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-11-2019-en#1.e for an example of ICANN approving an IMRS server cluster in Singapore (2019). In other words, the selection or de-selection of who hosts instances of the L-Root is an internal ICANN Organization matter. My question now to ICANN is: "If the community is not involved in how ICANN selects its internal vendors, why would the issue of removing the instance of the L-Root require community feedback or the development of policies?"
The short answer is that ICANN does NOT need community feedback in removing the instance from the L-Root from a vendor it alone chose. There are no community policies needed to be developed for rogue ICANN vendors. I realize that ICANN does not want to make these tough decisions alone, but that's the way it is. If ICANN alone makes the decision on who hosts the L-Root, and it alone decides the criteria upon which their vendors are chosen, then it is inappropriate for ICANN to punt this back to the community to decide what to do when your vendor goes off the rails and engages in conduct that violates ICANN's expected standards of behavior and RSSAC 037.
2. TAG Org's Other Roles should not be lumped in with its role as an ICANN Vendor
By combining all of the TAG's roles into one response, ICANN has intentionally convoluted and comingled the issues to: (a) make the issues so complicated that it is paralyzed to act, (b) delay any action until a later time; (c) declare that there are no policies to cover the new issues; (d) push the burden of resolving these issues onto others - in this case - the community, and (e) justify why it is unable to take any real decisive action. Its the old slight of hand.
For most of the ICANN community, this is a very common tactic used by ICANN Org over the years to avoid making decisions on controversial issues. Whether it is by overcomplicating the start of the next round of new gTLDs by focusing on unlikely edge cases, or like here, comingling every issue together into one bucket to avoid taking action, this tactic been par for the course of ICANN.
For the record, I agree with ICANN's response that any action against TAG Org as a registrar, dispute provider, and/or community member, is more complicated than as a vendor of ICANN with the L-Root. It is the primary reason why I did not include those other roles in my letters. Unlike the determination of criteria for, and the selection of, a vendor hosting an instance of the L-Root, the criteria for selecting an entity as a registry or registrar is determined by policy processes through the multistakeholder model.
Whether TAG Org's conduct violates the registrar accreditation agreement is a contractual matter. And if there are no grounds to terminate a registrar for the comments made by that registrar in the current agreement, then whether to include something like that in future agreements are good issues for the community to discuss. This is where free speech issues should be considered along with the development of new policies
But let me be very clear. This analyzing TAG Org's roles as a registrar, dispute provider and/or community member, are NOT the same analyses as the issue of what action should be taken in response to a rogue vendor hosting an instance of the ICANN L-Root (see above). As much as I am disgusted by the comments of TAG Org, its a matter of policy as to whether TAG should be terminated as a registrar, dispute provider or community member. But it is not a matter of policy, or for community discussion, as to whether TAG Org should be terminated in hosting an instance of the L-Root.
Conclusion
If ICANN is truly taking this issues of hate speech and antisemitism seriously, and it is committed to giving this matter the attention it deserves, there must be actual real consequences for violations of expected standards of behavior. ICANN must consider TAG Org's comments separately for each role TAG Org plays in the community, including its role as purely an ICANN vendor hosting an instance of the L-Root. Lumping it all together makes the issues much more convoluted and unnecessarily complex.
And where ICANN Org alone is charged with taking action, as it is for those entities hosting instances of the L-Root, it must act swiftly and decisively.
Otherwise, ICANN's condemnation of TAG Org's comments, is just meaningless words on a page.