[discuss] ICANN governance structure

[Mike Roberts]

John - 

Thanks for your elaboration.  I think that steps and missteps by the ICANN Directors in the early days can be instructive as we attempt to fashion a broader, more inclusive global base for Internet governance.

The Board obviously found that the initial Bylaws did not fit the reality of what was going on in the DNS and what the community wanted, which, of course, was a multitude of voices. They have been revised on numerous occasions. With a changing IG environment, how firm vs how flexible should the bylaws be?  

The transition from a research agency/academic partnership based on collaboration and cooperation to a legalistic environment with antagonistic lawyers around every corner resulted in a lot of tough decisions based on legal gray areas. E.g., the importing into ICANN policy circles of ongoing struggles over copyrights and trademarks.  In today’s environment, the Board seldom makes a significant move without a lot of legal advice.  Is this the way it just has to be?  

The Board discovered almost immediately that Jon’s dream of decision making “outside” of ICANN had no legal basis.  The Directors were on the hook for decisions.  Of course, given ICANN’s mission, it needs a lot of advice, much of it complex and technical.  What is the best approach to structuring advice and taking it?  The lawyers thinking of suing have their views, but how do we provide for the Directors doing the right thing, with consensus, when the outcome is overturned in litigation. The law requires “diligence” by the Directors in taking advice.  Is there a way to reduce that to norms that the community can endorse?

Lawyers will tell you that ICANN and its Directors are accountable to the public interest through the functioning of the California corporate statute and its remedies for behavior that is found to be unlawful.  Many find this unsatisfying.  Is there a better way, still grounded in the rule of law, to accomplish the aim of mission appropriate behavior?

I don’t want to belabor the issue. The above points, a non-exhaustive list, suggest the complexity of what we are about, and the difficulty of reducing theory to workable practice.

- Mike


On Mar 18, 2014, at 4:37 PM, John Curran <jcurran at istaff.org> wrote:

> On Mar 18, 2014, at 11:15 PM, Mike Roberts <mmr at darwin.ptvy.ca.us> wrote:
> 
>> Perhaps a little background would help on this item.
> 
> Sure...  I was there, but would love to hear your perspective.
> 
>> In the summer of 1998, there was an effort to socialize - globally - the White Paper recommendations about a new non-profit entity to become the home for functions previously managed by federal research agencies.  The signal to noise ratio of these meetings was not good, for obvious reasons.  Jon Postel and his IETF colleagues were alarmed by the prospect of an ICANN Board doing wholesale damage to Internet infrastructure as a result of ignorance, malevolence, or both.  Joe Sims, Jon’s lawyer (pro bono by the way), created a variation on the standard corporate committee structure in which considerable autonomy was ceded to three “Supporting Organizations,” covering the three responsibility areas of protocols (PSO), numbers (ASO) and names (DNSO).  The Bylaws provided that these SO’s would be self-created by a community process with experts in those areas and would be prima facie the voice of authority on policy, subject to the Board’s final approval.  Most of the year 1999 was consumed in the process of populating the SO’s.
> 
> Fine so far.
> 
>> We’ll never know whether Jon’s plan would have succeeded because he didn’t get to preside over it.  In his absence, the two technical pieces, PSO and ASO, felt a lot of discomfort about their implied subservience to the USG through ICANN.  Especially since their membership and functions had long since become global.  They moved to the “distant” but cooperative relationship with ICANN that exists today.
> 
> Umm... Actually, we went into ICANN Singapore meeting (this was March 1999) with 
> both ASO and PSO principals on-board with the formation of ICANN.  ICANN had 
> even issued a call for DNSO applicants, and the initial Board had reviewed two 
> applications for recognition as the ICANN Domain Name Supporting Organization.  
> At the public meeting, the Board indicated that it would not adopt either of 
> the two, indicating that the community deserved "the best DNSO possible" (to 
> the best of my recollection) and instead outlined some concepts and a structure 
> (with constituencies) on which a Domain Name Supporting Organization advisory 
> group _within ICANN_ would be based.  When I pointed out that this was contrary
> to initial ICANN Bylaws, the Board took that under advice and in the end decided 
> to change the Bylaws to align with the chosen direction.  For reference (or to jog 
> the memory of those who were there), feel free to review the "Summary of Actions 
> Taken by the ICANN Initial Board of Directors at its Meeting in Singapore" - 
> <http://archive.icann.org/en/meetings/singapore/singapore-statement.htm>
> 
> So, perhaps it would be best to say we don't know whether Jon's plan would
> have succeeded, not because he didn't get to preside over it, but because 
> it underwent substantial change during implementation.  As a result of this
> change, ICANN added DNS policy development _within ICANN_ (terminology per the 
> ICANN Board's own statement above) in addition to its overall coordination 
> duties and its IANA implementation duties.  Additionally, it meant the DNS 
> service provider community lost an opportunity for self-organization with an
> independent voice and finances of its own, i.e. distinct from that gained by
> participation in the Internet names and numbers coordination organization.
> 
> Given that the original blueprint was to have structural separation for 
> policy development (as you put it above, "considerable autonomy ceded")
> from ICANN proper, the decision to bring the DNSO within ICANN meant that
> the Board approved the actual process for DNS policy development, approved
> the policy outputs of the development process, led the implementation of 
> the DNS policies including approval of individual DNS requests... pretty 
> much everything except actual insertion of DNS entries into the root zone, 
> and all of this in addition to its original mission of coordination and 
> oversight across the entire Internet identifier ecosystem (much as Jon
> et al had done as "the IANA".)  The departure from the original plan made
> it challenging to see how an organization doing all things DNS was also 
> going to provide oversight for itself, not to mention creating some
> significant long-term organizational repercussions for ICANN given the
> the growth of DNS policy development compared to its original tasking.
> 
>> The DNSO/GNSO relationship has seen many adjustments over the years, and it is fair to say that substantial numbers of its constituents aren’t all that happy about the way it functions. There are disparate views on whether ICANN’s SO’s, as such, have been a success or not.  Careful scrutiny will be required on constituent structures in any new arrangements.
>> 
>> In that context, Barry’s hub and spoke idea has merit and ought to be explored.
> 
> Indeed.  It might be good to seek common understanding of what principles
> regarding accountability are desirable, and then consider what strengthening
> and restructuring of ICANN's existing mechanisms are best suited to satisfy.
> 
> FYI,
> /John
> 
> Disclaimers: My views alone, particularly regarding historical events. Note, however, 
>             that I am the CEO of ARIN, and ARIN's performance of its mission for the 
>             community is predicated upon a stable and secure environment in which to 
>             operate (including protection the community-based multi-stakeholder policy 
>             development model); this obviously drives some of my underlying concern 
>             in making sure that ICANN has foundational strength sufficient to succeed 
>             for decades to come, including in circumstances sans NTIA oversight.
> 
> 
> 
>