Thanks for raising the issue of SOI. Let me add some bits of history and a proposal.
In the past, I have commented multiple times about the SOI, but this has never moved things.
You mention that ALAC SOI and GNSO SOI are separate things. This indeed creates some problems for people who participate to both, and namely:
- either you have two SOIs, and therefore you must keep them both accurate and updated (this is something that is considered an heresy by each and every technical person)
- or you allow people to produce only one, and therefore if you want to check somebody’s SOI you must look in two different places.
When a couple of years ago - or even more - we wanted to review the rules for RALO Individual Members, we decided that, among other things, to fill in an SOI was a requirement for all applicants.
The reason is the same why you want that for GNSO: to declare potential conflict of interest. I cannot speak for other parts of the community, but I can state that all EURALO Individual Members have their own SOI. Whether it is up to date, is a different story,
though.
I have never really understood why ALAC SOIs were kept different from GNSO SOI, but my suspect is that to have them in one single place would have raised a sovereignty issue: who “owns” the SOIs?
Should ALAC lose its bit of power allowing the SOIs of its members be managed by GNSO Staff? The vice-versa would have been unthinkable anyway.
As more and more RALO Individual Members get involved in GNSO activities and in working groups (btw, it is called “multi-stakeholder model”, not a minor detail, but the way ICANN operates) the mess
increases in size.
But there is worse. At one point in time the UASG decided - and rightfully so - that SOIs were needed for all participants. For exactly the same reasons that guided GNSO and ALAC: to check potential
conflict of interest. Of course, there were already two sets of SOIs, so in doubt to which one to use the decision was to build a third one, under the complete control of the UASG. However, if you decide to reinvent the wheel, you cannot make it simply round
as the already invented ones, so the task was given to a contractor who came up with a different form: the "square wheel”. Some of us refused to fill in the new form, and we were treated with expulsion from UASG.
In a technical environment the solution to a similar problem would be to build a single repository, governed by some “cross-constituency” authority. The rationale is that the SOI is a company-wide
instrument to use some specific rules to which all participants in the ecosystem must comply. If we do this first step, I believe that the solution to the problems raised by Mike becomes simpler - at least we can avoid the checking being done by different
people using maybe different rules.
Hello All,
After today’s CPWG call, Avri and I were talking, and we were both inspired to review and update our ALAC SOIs. Just a friendly reminder to those of us who participate in the GNSO, that the ALAC SOI is separate and distinct from your GNSO SOI. While I regularly
update my GNSO SOI, I was surprised to find my ALAC SOI blank, as I genuinely recall completing it when I joined NARALO. However, in the interest of openness and transparency, I have now updated and published (that may have been the previous snafu) my ALAC
SOI, see
https://icann-community.atlassian.net/wiki/spaces/atlarge/pages/99734312/Michael+D.+Palage+SOI
While I still believe the revision to the SOI process is inherently gameable, it is an improvement, and we should all embrace it and put it into practice.
During last week’s Contracting Party Summit in Manchester, on the panel I moderated, I made a point of listing each panelist’s SOI; see screenshot below.
<Screenshot 2026-05-06 at 2.02.49 PM.png>
During the last several CPWG calls, I was unable to find SOIs for several participants. I think it would be good for ALAC leadership not only to ask for SOI updates at the beginning of calls, but also to remind ALAC community members to regularly update their
SOIs. I think ALAC should set the bar high and lead by example within the ICANN community.
On this issue of SOI compliance, please see the email communication that I sent to ICANN’ Board Chair and General Counsel in March regarding ICANN increasing openness and transparency in connection with the army of contractors, consultants, and lobbyists it
employs. Sadly, I have not heard back from any recipient, although, to be fair, things have been a little hectic with the launch of the new gTLD window.
I would really like to hear the view from ALAC about whether ICANN should have an obligation to publicly disclose their growing army of contractors, consultants and lobbyists in the letter and spirit of the SOI modifications? Two phrases keep reverberating
in my mind: 1) Practice what you preach and 2) What is good for the goose is good for the gander.
Just because these contractors, consultants, and lobbyists may not be actively participating in a policy work group does not mean that they are not impacting ICANN policy in the hallways of ICANN meetings or in other fora.
Best regards,
Michael
P.S. Given the policy and governance implications of this email, I have decided to cross-post to CPWG and OFB.
From: Michael Palage
Date: Thursday, March 26, 2026 at 3:36 PM
To: John Jeffrey ; Fiona Alexander; Tripti Sinha
Subject: ICANN Contractors and SOI Requirements
Hello John, Tripti and Fiona,
I am doing research in connection with an upcoming article on ICANN’s updated Statement of Interest policy. And I had some questions I was hoping that you all might be able to answer.
I believe the current SOI policy applies to ALL participants in the ICANN community, including ICANN contractors. Upon information and belief, I believe ICANN has/had a contractual relationship with Salt Point Strategies.
The current policy provides a non-exhaustive means for community members to make a disclosure. However, I don’t see a mechanism or repository for ICANN contractors and other non-GNSO/non-ccTLD/non-ALAC community members to declare their Statements of Interest.
During ICANN85, Fiona participated in a panel session. In the Zoom chat I recall making a statement about not seeing an SOIs from any of the panel participants other than Bruce Tonkin. I do not believe anyone, including ICANN staff, responded to my inquiry.
Question/Request to Tripti - If the Board is serious about enhancing SOI transparency within the ICANN community, no person should be listed as a speaker/panelist at an ICANN event unless they have posted a corresponding SOI, absent extraordinary circumstances
e.g. last-minute fill-in for another speaker. Do you think this is something that the ICANN Board could direct staff to implement?
Question to John - Could you work with ICANN Org to provide a fail-over SOI repository for those community members that do not neatly fall within the GNSO, ccNSO, or ALAC? If you agree with this recommendation, could you give a potential ETA on when
this might be available and where it would be located? Friendly suggestion, I would like to recommend
SOI.ICANN.ORG as a default landing page for all SOs, AC, and other community members. If you disagree with this recommendation, I think it would be helpful
to provide a public response to the ICANN Board explaining why staff chose not to implement it.
Question to Fiona - Fiona, I just wanted to make sure I didn't miss where you previously posted an ICANN SOI. If you have posted one, I would greatly appreciate it if you could point me to it. I also wanted to confirm the previous/existing relationship
between Salt Point Strategies and ICANN.
Thank you for your attention to this matter.
Best regards,
Michael
_______________________________________________
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.