Dear Mike, The concept of the Statement of Interest (SOI) has undergone a significant transformation since ICANN’s founding. Originally, the organization operated with a high degree of informality, relying on the close-knit nature of the early technical community. However, as ICANN’s influence over the global DNS grew, so did the necessity for formal transparency. The requirement we recognize today largely crystallized during the GNSO Improvements process between 2008 and 2010. This era marked a shift from voluntary disclosure to a mandated protocol designed to prevent capture by undisclosed commercial or political interests. Following the GNSO’s lead, the At-Large Advisory Committee (ALAC) and various Regional At-Large Organizations (RALOs) adopted their own SOI requirements. While this signaled a community-wide commitment to transparency, it inadvertently birthed a fragmented ecosystem. Today, participants active in multiple corners of ICANN find themselves caught in a silo trap: they must maintain separate SOIs for the GNSO, the ALAC, and even specific projects like the Universal Acceptance Steering Group (UASG). This fragmentation is more than a mere administrative pipe; it represents a technical error. In a technical environment, maintaining multiple versions of the same data is considered not correct because it destroys the ability to have a single document serving multiple channels. There is a historical hesitation among different constituencies to allow their members' data to be managed by a different staff group. This protective stance, however, ignores the reality of the modern multi-stakeholder model, where individuals frequently cross-pollinate between different working groups and advisory committees. To resolve these inconsistencies, ICANN should move toward a Unified SOI Framework hosted at a central landing page, such as SOI.icann.org. (It brings the ICANN Wiki website to mind). This (SOI.icann.org) would serve as a single, authenticated repository where a participant enters their professional and financial disclosures once. Through the use of contextual tags, this single profile could be displayed across the GNSO, ALAC, and UASG directories simultaneously. This sub-domain model ensures that an update in one place reflects across the entire ecosystem, reducing the burden on volunteers and increasing data accuracy. To address concerns regarding ownership, this repository should be governed by a cross-constituency authority (or any befitting proposal). By placing the management of the SOI tool under a body representing all Supporting Organizations and Advisory Committees, ICANN can bypass the sovereignty issues that have previously stalled progress. This body would ensure that the rules for disclosure are consistent and that no single group holds undue power over the participation data of another. Furthermore, transparency must be a company-wide instrument that applies to all who influence the ecosystem. This means extending SOI requirements to ICANN’s own contractors, consultants, and lobbyists. If these individuals are impacting policy—whether in formal working groups or the hallways of ICANN meetings—their interests should be as public as those of the volunteer community. Practicing what is preached would involve a mandatory public disclosure mechanism for any third party under contract with ICANN Org that engages in policy-adjacent work. Finally, the system must move away from static oversight. A unified portal allows for automated triggers, such as quarterly prompts for users to "Confirm or Update" their status. By flagging profiles that haven't been reviewed in a certain timeframe (suggesting three [3] years), the community can easily distinguish between active, transparent participants and those whose disclosures have gone stale. This transition from fragmented silos to a centralized, universal framework is the only way to ensure that ICANN’s transparency keeps pace with its operational complexity. Regards. Adebunmi Akinbo On Thu, May 7, 2026, 2:30 PM mike palage.com via OFB-WG <ofb-wg@icann.org> wrote:
Hello Roberto,
I hope that teaming up with you can bring about constructive change, just like old times 😊
If people access the ICANN Portal and go to the "ICANN Join” page, ICANN community members can list the top three SOIs. As you can see from my screenshot below, I have provided two SOIs, one for GNSO and one for ALAC.
[image: Screenshot 2026-05-07 at 8.48.41 AM.png]
I understand that maintaining multiple SOIs may be a burden to some, but I personally believe that it is important. I have participated in the RySG as a consultant to one or more Registry Operators over the last 20 years. In addition to having no voting rights, I am careful to avoid voicing personal opinions that do not align with my client's. However, in the ALAC, I can express my personal opinions without such limitations.
I believe your concern about maintaining multiple SOIs has been somewhat addressed by the features ICANN has provided on the ICANN Join page above. Although I think we should ask Sally or Patrick for ICANN Org could hop on an ALAC call and explain what functionality is available via the ICANN portal and how our suggestions for enhancements could lead to greater ICANN community membership engagement.
A full session devoted to proper SOI hygiene at ICANN86 would have perhaps been a better plenary session than another UA session. While I appreciate that UA is important, as I have been professionally dealing with it since 2001 when .INFO was added to the root, much of this issue is outside of our control. I really like us devoting time to things that we can control. Perhaps a special ALAC/CPWG standalone call where ALAC can set the gold standard for SOI best practices in ICANN?
Keep up the constructive discussion and I would encourage everyone to keep up to date with SOIs.
Best regards,
Michael
P.S. ICANN Org, I think I have gotten most of this right; however, if I have missed anything, please provide clarification or correction where necessary.
*From: *Roberto Gaetano <roberto_gaetano@hotmail.com> *Date: *Thursday, May 7, 2026 at 5:25 AM *To: *mike palage.com <mike@palage.com> *Cc: *CPWG <cpwg@icann.org>; ICANN At-Large Staff via OFB-WG < ofb-wg@icann.org> *Subject: *Re: [CPWG] Statement of Interest - Public Service Annoucement & Call to Action
Hi Mike
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.
Best regards, Roberto
PS: not being a member of “OFB-WG” this message will not reach them, sorry
On 06.05.2026, at 20:22, mike palage.com via CPWG <cpwg@icann.org> wrote:
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/Mic...
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.
_______________________________________________ OFB-WG mailing list -- ofb-wg@icann.org To unsubscribe send an email to ofb-wg-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.
