[governance] Cities and Internet Governance

[Milton L Mueller]

> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com] 
> 
> This is also a slippery slope. Are we to have constituencies from
> every imaginable category of TLD?  There could be thousands
> (eventually).
> 
> City TLD folks are currently not limited in their "participation in
> Internet governance processes".  I don't see why they need a platform
> from which to do it now.


McTim:
You are half right, half wrong. 

ICANN's GNSO has always been flawed by the fact that prospective registries -- that is, businesses or nonprofits who intend to apply for a TLD but do not yet have one -- are completely disenfranchised by the GNSO Constituency structure. They are not eligible for the registry constituency because they are not under contract to ICANN and do not have a TLD in the root. At the same time they are not eligible for user constituencies, either commercial or noncommercial, because they are prospective suppliers, not users. So it is understandable that city TLDs (and other prospective registries) would want to form a new constituency. (That's the half-wrong part). 

On the half right side, you are correct that ICANN's current approach to the formation of new constituencies is deeply troubling. You are right that "every imaginable category" --  not just of TLDs, but of any and every category of users -- 
could form constituencies under this logic. You could have a privacy advocates constituency and an anti-privacy constituency, a "denizens of the Alsace-Lorraine" constituency, a "persons with red hair" constituency." 

This is not an intelligent basis for structuring representation in the GNSO. The problem is not that people can form little subgroups or factions of like-minded people. It is ok to have "thousands" of such groupings if people are interested in forming them on their own as SIGs. The problem is that ICANN's staff wants to link these "imaginable categories" to rigid, difficult to change voting structures in the GNSO. A constituency must be formally organized and formally recognized by the Board and, if ICANN's staff has its way, they will be assigned specific seats on the GNSO Council simply by virtue of the fact that they are a recognized "category" of user or supplier. 

This won't work. For example, the noncommercial stakeholders group gets 6 seats on the Council. How do you apportion these 6 seats when there are 60 constituencies? Staff has told us that they want a council of these constituencies to meet and decide, though some kind of political negotiation comparable to the carving up of Europe after World War 1, who gets how many seats. What a F***ing waste of time and what a recipe for political conflict. 

We Noncommercial Users have proposed a simple and elegant solution: don't assign seats to constituencies, let the members of the Stakeholder Group have an election - constituencies can nominate their favored candidates but if they can't win an election by attracting votes from lots of other members they don't get a seat. 

ICANN's staff doesn't like this idea. Why? in essence they are just being bureaucratic - they don't like it because they dont think it conforms to what the Board ordered them to do. But the Board did not ask them to create a Rube Goldberg constituency structure, it asked them to make it easier to participate in the GNSO and for the GNSO to reflect a broader range of views. Somehow, the staff has confused "adding new constituencies" with "making it easier to participate" and "reflecting a broader range of views."  


Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 ____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance