[discuss] hens and foxes

Tue Apr 1 23:48:03 UTC 2014

Each stakeholder group would probably nominate itself for chicken, and ICANN and/or another stakeholder group as fox.

I think the multi-equal, bottom-up, consensus-driven multistakeholder model is the right starting point for Internet governance.  Turning any model  (MS or not) into reality has to deal with all kinds of issues of checks and balances, constraints, conflicts of interest, etc.

I lost track of who the hens, chickens, foxes and cross-dressing animals were supposed to be standing for in the metaphor....

As to the specific statement:

"If you don't trust a body composed of all the registries in the world with the small but potent power to hold ICANN to a narrow (non-content regulating) mission, subject to their need to convince a judiciary that those constitutional bounds have been overstepped, then you need to think harder about how to give real power to the hens themselves."

I don't find this to be statement I can support on a number of levels.

I will say first, I don't trust a "body composed of all the registries in the world" to do anything other than represent the interests of registries.  (I certainly would not expect them to be some sort of benevolent proxy for the end-user hens -- and I say that with respect and affection for the registry representatives I have known.)

I have tried to imagine an ICANN run solely by the registries (some might say I don't have to try very hard); other than the fact that all the new gTLDs would have been delegated years ago and thus behind us, I don't like what I imagined all that much.  (The same could probably be said of an ICANN run by any one stakeholder group....)   Any group that has the power (and powers tend not to stay small) to hold ICANN to its mission (which I would not categorize as narrow) should be a multistakeholder group.  Also, I tend to think of Internet Governance as a form of self-regulation; the suggestion that litigation would be an essential piece of the regulatory puzzle is a little alarming.  (Of course, litigation is always an option, regardless of the regulatory set-up, and regardless of whether one creates additional litigants or not.)  I don’t think that most of the potentially mission-violative activity of ICANN would be an issue of constitutional magnitude or relevance.  If it ever is, I'm sure we can find litigants without creating them.

Giving end-users more power in the system is an issue with a great number of dimensions.  In Singapore, there were discussions of giving more power to both commercial and non-commercial end-users in the developing world, and more power to end-users with accessibility issues, and more power to would-be end-users who have no Internet access at all.  Education, outreach, engagement and support are all part of bringing in more stakeholder voices.  Nonetheless, in the end I still come back to the MS model (well-implemented) as the right setting for that power, as well as those of other stakeholders.

Greg Shatan

-----Original Message-----
From: DAVID JOHNSON [mailto:davidr.johnson at verizon.net]
Sent: Tuesday, April 01, 2014 5:41 PM
To: Brian E Carpenter; discuss at 1net.org List
Cc: Shatan, Gregory S.
Subject: hens and foxes

It would seem that the hens (us chickens) are the end users (or at least domain name registrants).
But who is playing (or might play) the fox?

It would seem that one thing we know about the netizenry is that they do not like the idea of having their internet identities taken away for copyright infringement (much less "violation of any applicable law") Yet that is exactly where the current drift of the new gTLD contracts is taking us.

If ICANN had a membership composed mostly of end users, that would not happen.
If there were *any* entity that had a binding promise from ICANN not to regulate content on the net, and if that entity had the means and general incentive to enforce the contract, then such content regulation would be much less likely, no matter what pressures came from the GAC.
Such a contract would not put the new entity (putative "fox") "in charge" of ICANN -- it would merely prevent ICANN from becoming a potential "fox".

Governments claim to be the exclusive spokesmen for the hens.
Those who believe in the multi-stakeholder model believe there are lots of different types of hens and many can speak for themselves (individually in groups).
We do need to protect the henhouse from a potential fox.
But simply trusting the leading hens not to transform, some day, under pressure from governments, into foxes in hens clothing is not a sufficiently stable solution.
Separation of powers assumes real, and constrained, powers on both sides of the equation.
If you don't trust a body composed of all the registries in the world with the small but potent power to hold ICANN to a narrow (non-content regulating) mission, subject to their need to convince a judiciary that those constitutional bounds have been overstepped, then you need to think harder about how to give real power to the hens themselves.

                                                                * * *

This E-mail, along with any attachments, is considered
confidential and may well be legally privileged. If you have received it in
error, you are on notice of its status. Please notify us immediately by reply
e-mail and then delete this message from your system. Please do not copy it or
use it for any purposes, or disclose its contents to any other
person. Thank you for your cooperation.

                                                                * * *

To ensure compliance with Treasury Department regulations, we
inform you that, unless otherwise indicated in writing, any U.S. Federal tax
advice contained in this communication  (including any attachments) is not
intended or written to be used, and cannot be used, for the purpose of (1)
avoiding penalties under the Internal Revenue Code or applicable state
and local provisions or (2) promoting, marketing or recommending to another
party any tax-related matters addressed herein.
                                                                        Disclaimer Version RS.US.20.10.00