Michael Froomkin
University of Miami School of Law

[Summary by Harish Bhatt, CPSR]

Mr. Froomkin began his opening remarks by observing that there were two stories that could be told about global Internet administration.  The "classic" story dealt with issues such as chokepoints, taxes, and controls.  The "real" story, however, had to deal with chaos and adhocracy.  He noted that the real story was a problem in its own right, and that it also made it impossible to disprove the classic story.

Commenting on the notion of the "root" as an Internet "chokepoint" he stated that if your TLD was not in the root, then you were -- for all practical purposes -- invisible to the world.  He stated that the current architecture was marked by network effects, inertia, and change being controlled by someone else who was upsteram from you.  He noted that all this could, and probably would, change in the future.

Given the importance of the root, Mr. Froomkin suggested that it could be abused in terms of flow-down terms of service, and also by legal claims of ownership in names, or the right to list TLDs or SLDs.  The impact of any such abuse would determine who gets to be seen on the public and global Internet, the enforcement of anti-cybersquatting and anti-spam rules, privacy rules, and content controls (possibly via filters).

The importance of the root also made the question of who actually controlled the root an issue of very significant interest to people from all over the world.  He noted that at the present time, the root was controlled by the U.S. Department of Commerce.  He stated that while there were still some [unresolved] issues as to legal authority, there were not many issues as to power, and that Network Solutions, Inc. accepted that the U.S. Department of Commerce controlled entry in the root and the entry of new TLDs.  He observed that the U.S. Department of Commerce was in dispute with NSI as to "ownership" of data relating to registrations of domain names.

Mr. Froomkin noted that it was in the context of the situation -- [briefly] described above -- that ICAAN was born.  He stressed, however, that at the present time ICANN did not control the root.  The U.S. Department of Commerce had retained control of the root.  While the U.S. Department of Commerce had indicated that it intended to [eventually] cede control of the root to ICANN, it was not actually required to do so.  Despite the fact that ICANN did not control the root at the present time, he commented that ICANN acted as if it was already in control of the root.

What if ICANN did control the root?  What would be the impact on global Internet administration?  Mr. Froomkin suggested that the impact would depend a lot on which of the two main cultures  -- Engineers or Lawyers -- that took an interest in the activity of global Internet administration, would turn out to be the dominant culture within the ICANN organization.  He noted that engineers tended to focus on results.  An engineer might look at a boat and ask "Does it float?"  On the other hand, lawyers tended to favor Holmes' "bad man" approach, and preferred not to ask what was likely, but instead what was possible.  For example, a lawyer might look at the same boat and ask "How easily does it get out of control?"  Mr. Froomkin stated that lawyers cared about process and tended to be nasty suspicious people.  This made them ideally suited for such activities as drafting a  constitution.

Mr. Froomkin suggested that there was widespread interest in the nature of the organization that controlled the root, because people were concerned about the possibility of "bad things" being done by any entity that wielded so much power over a global resource like the public Internet.  Since ICANN might [one day] become that organization, people were very interested in the type of organization that ICANN was today, and could turn into at some point in the future.  What were these bad things that people were so concerned about?  One major concern was the imposition of "taxes" on domain names and IP address allocations.  Another was putting conditions on the use of resources -- in this context Mr. Froomkin noted that the contractual model adopted by ICANN was troubling because it is highly insulated from independent review.  He noted that while ICANN could come up with some great rules, some of its rules might be problematic.  He stated that in situations where trust had not yet been established, it was very important to have well-defined processes to serve as a guide.

Mr. Froomkin suggested that the real danger lay in the adoption [by ICANN] of a "really lousy" governance model.  He noted that governments are a product of a long evolutionary process.  They have rules on representation (feedback control) which provided guidance in areas such as notice and voting, rules on self-dealing (data corruption), rules on procedure (protocols), and rules on  external checks (boundry conditions) to serve as a guide for due process and even lawsuits.

Given the above concerns, Mr. Froomkin suggested that the current ICANN structure was seriously defective.  He noted the comment made by a prominent member of the ICANN Board at one of their meetings:  “With all due respect … we are less interested in complaints about process" and more interested in "doing real work and moving forward.”  Mr. Froomkin noted that the procedure IS the real work at this stage.  He commented that the situation was analogous to software development, where if you started with a bad architecture, you ended up paying for it downstream.

Mr. Froomkin provided the following examples as being indicative of ICANN's structural defects:

1. Byzantine structure
2. Legitimation crisis
• Creation, Funding, Spending
• Expectation / outcome mis-match
• Flawed representational structures
• That manipulable “consensus”

Mr. Froomkin stated that ICANN's record [so far] in the area of rulemaking, was indicative of an "adhoc-racy."  By way of example he pointed to the following issues:

1. Notice, formality, regularity, consensus issues
2. Timing
3. Role of working groups
4. Voting rules
5. Bylaws conflicts

Considering the extent of Internet participation in ICANN's processes, Mr. Froomkin stated that there wasn't much at all.  He noted that physical attendance at ICANN meetings appeared to be critical.  The Internet itself as a medium had not been used well, and with the honorable exception of Esther Dyson, (Interim Chair, ICANN), the ICANN Board remained essentially invisible.  Mr. Froomkin noted that if you participate virtually, with delays, written rules are ever-more important.

Mr. Froomkin asked how one could one go about making participation meaningful?  He noted that participation was a good in itself -- more input may help make better decisions, and it was the right thing to do.  He observed that participation was also an instrumental good -- it created visible legitimacy, and protected decisions against third party challenges.

Having established that participation was a "good thing," Mr. Froomkin asked where we should be looking for answers?  He noted that if the problem at hand was a political problem then it required a political solution -- and we would look toward players like Vice President Gore, Mr. Daley, Mr. Bush, or Mr. Bradley for answers.  On the other hand, if it was a technical problem, then it needed a technical solution.  But what kind of technical solution?  Mr. Froomkin suggested that the technical solution would be unlike a standards debate (in that it is much harder to drive the market by making a better proprietary standard), yet like a standards debate (in that a new technology could make old standards irrelevant).

In concluding his opening remarks, Mr. Froomkin returned to his original question of how one could one go about making participation meaningful?  He suggested that there were two models we could consider.  In the first model -- Retrofit Model -- we could work on drafting the equivalent of a Bill of Rights, obtain entrenched promises [from ICANN] not to do some things, and specifically address many/most "root of evil" concerns.  In the second model -- Reboot Model -- we could treat ICANN as a first iteration (as the equivalent of the Articles of Confederation, so to speak) and learn from the whole experience, we could start with a better requirements document in the next iteration, and ensure that the role of the end-user was put at the forefront of the ensuing dialog.