Hearing:
    Internet Corporation Assigned Names and Numbers (ICANN)
    Communications Hearing
    Thursday, July 31 2003 - 2:30 PM - SR-253

Submitted By:
    Karl Auerbach
    Former North American Elected Director to the Board of Directors of
    the Internet Corporation for Assigned Names and Numbers (ICANN)

Executive Summary:

I am the only person from North America who will ever be elected by the public to ICANN's Board of Directors.

I served on ICANN's board for roughly 2 1/2 years.

During that time ICANN authorized not a single new top level domain (TLD).  During that time the domain name business became something that would embarrass even the most hardened used car salesman.  During that time wholesale domain name prices fell to precisely the arbitrary level set by ICANN, and no lower, clearly indicating that ICANN regulation, not competition is a determining price factor in the domain name industry.

During that time ICANN failed to exercise control over the operation of the domain name root servers - the most obvious single point of failure (and attack) for the the internet.  During that time ICANN failed to exercise control of the IP address allocation system, a system with long term economic effects far greater than that of the domain name system.

During that time September 11 occurred.  Yet since that date ICANN has done nothing more than establish a committee to study the security of the domain name system.  That committee has yet to awaken and do anything.

During that time ICANN increased the already Byzantine complexity of its structure and erected a multi-layered barrier between itself and the public.

It is imperative that ICANN immediately abandon its failed method of allocating, or rather of not allocating, new top level domains.  ICANN must adopt a system of allocation that looks solely to technical competency, that is not a subjective beauty contest between applicants, and that is efficient, inexpensive, speedy, and fair.  It is my belief that the proper approach would be a system of auctions and lotteries, as suggested by several academic observers, that incorporate lessons learned from experiences from radio frequency allocation and that equitably balance the needs, and ability to pay, of commercial and non-commercial interests.

My conclusion is that ICANN has fallen far short of its obligations, has discouraged rather than encouraged true competition in the domain name business, has failed to serve the public interest, and has reshaped its own structure to be virtually unaccountable to public opinion.  The Department of Commerce has repeatedly given ICANN time to solve these problems.  Although ICANN's new management is vastly improved over what it has been, in my opinion it is unlikely that grants of additional time will result in improvement.

Full Text:

To the members of the Communications Subcommittee of the United States Senate Committee on Commerce, Science & Transportation:

Please accept this as my submission to the hearings on the Internet Corporation for Assigned Names and Numbers (ICANN) scheduled for July 31, 2003.

Mr. Chairman and distinguished Senators.  Thank you for giving me the opportunity to submit this material.

Today I would like to write on the topic of ICANN reform.

I was elected to the Board of Directors of ICANN in the year 2000 through an open election process covering much of North America.  My term ended once month ago.

I am the only person ever to serve on ICANN's Board of Directors who obtained his seat through an election open to the internet community of North America.

And, unless ICANN radically changes, I will be the last person ever elected by the public to ICANN's Board of Directors by the internet community of North America.

I appeared before this subcommittee on two prior occasions, once in year 2001 and then again in year 2001.

My 2001 testimony is online at: http://www.cavebear.com/archive/cavebear/growl/issue_6.htm  My 2002 testimony is online at: http://www.cavebear.com/archive/rw/senate-june-12-2002.htm

I am sad to say that nothing in ICANN has substantially changed.  The testimony I gave in 2001 and 2002 is still largely valid.

I would like to take this opportunity to pose, and answer, a short list of questions regarding ICANN.

• Has ICANN successfully lived up to its obligations?

• Has ICANN increased competition in the Domain Name marketplace?

• Has ICANN done anything about the security of the Domain Name System since September 11, 2001?

• ICANN is obligated under a Cooperative Research and Development Agreement (CRADA).  Has that report been delivered and is it adequate?

• Has ICANN's "reform" made ICANN more responsive and accountable to the public and the public interest?

• Is ICANN being run with due care and adherence to reasonable principles of corporate governance?

• What is the purpose of ICANN?

• What is IANA and how is it different from ICANN?

• What do you suggest that the US Senate or the US Department of Commerce do?

Q: Has ICANN successfully lived up to its obligations?

Let me answer that question by restating ICANN's three functional areas:

• IP Address allocation
• IP protocol parameter allocation
• Administration of the root zone of the primary Domain Name System (DNS)

ICANN has effectively disengaged from IP address allocation.  ICANN has abrogated its responsibility in this area to the four regional IP address registries (RIRs), APNIC, ARIN, LACNIC, and RIPE.  For several years, ICANN and these RIRs have been dancing around one another like a pair of nervous porcupines - one wonders whether they will ever actually make contact.  In my opinion, both ICANN and the RIRs desire the appearance of the continuing dance - it gives them a plausible story to cover the increasingly obvious reality that ICANN and the RIRs have reached an implicit understanding that they intend to remain, permanently, separate and apart.  On this basis one must conclude that ICANN has not successfully lived up to its obligation to oversee IP address allocation policy.

(I would hasten to add that the RIRs have become quite professional organizations and are doing the IP allocation job quite well without any help or guidance from ICANN.)

As for the second of these functions, IP protocol parameter allocation, this is essentially a non-discretionary clerical function performed by ICANN at ICANN's expense on behalf of, and essentially under the direction of, the Internet Engineering Task Force (IETF).   By my own calculations, this job ought to require approximately one quarter to one third of the time of a clerical employee.  ICANN appears to be handling this job well.  However, one must ask whether it takes a bureaucracy of the size and cost of ICANN to do this small clerical job.

As for administration of the DNS root zone - ICANN has done very little during its entire existence that can even hope to be called "technical".  The one obvious exception has been ICANN's handling of internationalized names in DNS.  In that area, and unfortunately only in that area, ICANN has served as a catalyst bringing together the technical and domain name business communities, and allowing those groups to define the policies.

ICANN has waved the flag of "security" for most of the 22 months since September 11, 2001.  As I will mention in more detail later, that waving of the flag has not been translated into action.  Similarly, ICANN has been obligated for several years under a Cooperative Research and Development Agreement (CRADA) with the Department of Commerce to create a new architecture for the DNS root servers.  The result was announced this spring with a fanfare, but as I will describe later, the reality of what was delivered is far below what it ought to have been.

The operators of the root servers have refused to enter even into a loose "memorandum of understanding with ICANN", much less an enforceable contract that establishes obligations and service levels.  Indeed, the root server operators have acted quite independently of ICANN.  Several root server operators, on their own initiative and at their own expensive, have adopted significant technological innovations, allowing geographically dispersed mirrored servers, without even bothering to inform ICANN of their intention to do so.

I am forced to conclude that ICANN has, with the exception of internationalized domain names, failed to to successfully meet its obligation to administer the root zone of the DNS.

On the other hand, ICANN has a most excellent record of doing that which it ought not to be doing.  With a budget approaching $10,000,000 per year and a staff going beyond 30, ICANN has more than enough hands to do many things.  And those hands are not idle.

ICANN has spent most of its existence acting as an unelected legislature enacting economic, business, and intellectual property rules that are, as a practical matter, supranational laws, superseding the laws of any individual nation.  It could be amusing, if it were not so frightening, to realize that ICANN is in a position to create obligatory rules of trademark and domain names that go beyond what could be created by even by the two houses of the Congress of the United States.

As a practical matter, ICANN is acting as a worldwide legislature.

Several business groups have recognized this fact.  These groups have recognized that it is much easier to convince a half dozen ICANN staffers or Board members and have ICANN promulgate a worldwide rule governing business practices or intellectual property than it is to convince the national legislatures of the more than two hundred sovereign governments around the world.

This has created a situation in which legislation desired by small, but well organized and financed business and intellectual property groups, mainly located in the US, is exported to the nations of the world without the consent of those nations.  This has engendered a significant amount of government-level hostility against both ICANN and the United States.

In an attempt to explain this role, ICANN and the US Department of Commerce have pointed to terms in the various contractual documents that exist between ICANN and various agencies of the US Department of Commerce.  Those terms require ICANN to undertake to increase competition in the Domain Name Registry marketplace and to deal with the conflict between trademarks and domain names.

I have yet to see how the US Department of Commerce has the authority to require ICANN to engage in those activities when the US Department of Commerce itself has no such legislative or administrative authority.  The reports from the General Accounting Office on ICANN have underlined the issue of the lack of such authority by the Department of Commerce.

It is my strong belief that the integrity of our system of Constitutional government in the United States depends on the fundamental policy that power and authority exist in governmental bodies only to the extent that that power and authority is properly delegated.  I am extremely concerned that we are observing in this situation a kind of growth of unauthorized and un-delegated administrative power and authority in the Department of Commerce.  Our system of limited governmental powers would be shaken to its foundations if an administrative agency, such as the US Department of Commerce, can reach beyond its delegated powers simply by contracting with an arguably private body, such as ICANN.

Let me move out of the issue of the powers of administrative agencies and return to ICANN:

Let's assume for the moment that we do want ICANN to be a new kind of legislature.  If that is the case, how well has ICANN met its goals?  The next few questions will address that issue.

Q: Has ICANN increased competition in the Domain Name marketplace?

There are, it is true, more players in the domain name business than there used to be and the cost to end consumers for domain names is lower than it was several years ago.  This is where the analysis of ICANN's supporters stops.  However, there is more to the story.

The behavior of the marketplace created by ICANN is such that it would embarrass even the most unethical of used car salesmen.  The domain name marketplace created by ICANN is rife with sharp practices, disputes and, consumer deception.

And if one examines the pricing system created under ICANN it can be seen that although prices are in fact lower, they are still much higher than they would be if ICANN did not have artificial price props and arbitrary contract terms that guarantee a never ending, unearned cash flow from the pockets of the public into the coffers of Network Solutions, Afilias, and NeuLevel.

In my opinion ICANN, has created a highly contrived and biased regulatory system that has destroyed, rather than increased, real competition, the kind of competition that gives consumers real choices in terms of price and service, in the domain name marketplace.

Q: How well is ICANN handling the creation of new top level domains (TLDs)?

In its entire term of existence ICANN has created a mere seven new top level domains (TLDs).  At this rate the existing space of TLDs will double in approximately 107 years.  At this rate another ice age will have come and gone before we hit any technical limitations in the domain name system.

Of the seven TLDs that ICANN has created, most are of value only to small interests.  There has been no cognizable benefit to the public.

ICANN's glacial, and extremely expensive, processes have not only failed to meet even the smallest portion of the demand for new TLDs, but it appears that even the opportunity to apply for new TLDs, or to be the database operator (registry) underlying those TLDs, has become limited to a very few favored insiders.

ICANN has claimed that the initial seven TLDs were a test bed.   But it was a test bed lacking even the most rudimentary elements needed to evaluate success or failure.  ICANN is in no way more knowledgeable about the issues of deploying new TLDs than it was in year 2000.

My conclusion is that ICANN's foray into TLD allocation has been an nothing less than an unmitigated disaster.  ICANN's behavior has wasted millions of dollars and hindered the progress of innovation on the Internet.

ICANN should immediately drop all of the arcane, and useless, business regulations and microscopic distinctions that it has imposed on the allocation of new top level domains (TLDs) and simply look at the technical competency of the applicant.

It is my suggestion that ICANN adopt an allocation system following the suggestions of Professors Mueller and McKnight (see The Post-COM Internet: A Five-Step Process for Top Level Domain Additions - online at URL: http://dcc.syr.edu/miscarticles/NewTLDs-MM-LM.pdf) and of Professors Solum and Manheim (see An Economic Analysis of Domain Name Policy - online at URL: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=410640).

Such a system would combine auction and lottery methods, learning from experiences with the allocation of radio frequency spectrum, into a method that allows both the free play of economic forces with a reserve for those groups who contribute to the riches of our society in ways not easily reduced to cash.

Q: Has ICANN done anything about the security of the Domain Name System since September 11, 2001?

If forming a committee of worthies is doing something, then ICANN has indeed done something about the security of the Domain Name System.  If, however, one looks to concrete acts or even concrete proposals, then ICANN has not done anything about the security of the domain name system.

As far as I know, my own paper of October 2001 - Protecting the Internet's Domain Name System (available online at URL: http://www.cavebear.com/archive/rw/steps-to-protect-dns.htm ) - is the sole and exclusive concrete output of any person associated with ICANN on this critical matter.

I know that ICANN's security committee is composed of excellent people and is capable of impressive work.  But like a huge and powerful rocket, it isn't going anywhere because somebody seems not to have put a match to the fuse.

Q: ICANN is obligated under Cooperative Research and Development Agreement (CRADA) CN-1634 Between the Internet Corporation for Assigned Names and Numbers and the United States Department of Commerce to deliver a report regarding "enhanced architecture" for the Domain Name root servers.  Has that report been delivered and is it adequate?

It is my opinion that ICANN has not come even close to fulfilling its obligations under the CRADA.  I have written on this matter.  I am attaching that material below.  That material is also available online at URL: http://www.cavebear.com/old_cbblog/000007.html

Q: Has ICANN's "reform" made ICANN more responsive and accountable to the public and the public interest?

ICANN has built a thick barrier of walls, moats, and thickets of thorns between itself and the public.  A person who is interested in affecting ICANN's decision-making must begin by joining an ICANN approved "structure" that itself must join an ICANN approved "regional organization", which itself may send delegates to an ICANN created "at large committee" that may then send delegates to yet another ICANN created committee which finally names the members of ICANN's Board of Directors.

The United States banned company unions nearly 70 years ago.  ICANN, however, has, without using that term, revived that concept.  ICANN forces internet users into ICANN-approved structures so far removed from the centers of ICANN power as to be essentially meaningless.

The fact of this disempowered role has not been lost on the internet community.  Back in year 2000, when there were real elections, more than 160,000 people signed up to vote, a significant number given the obstacles that had to be overcome in order to sign up and the short time available.  Yet today, despite ICANN-sponsored events, ICANN-paid press-release majorettes, and even ICANN-paid travel, the public response to ICANN's "at large" structures has been underwhelming.  In fact it is essentially non-existent.

It is my opinion that ICANN is offering the internet public too little.  I believe that only a very few members of the internet community will bother to join ICANN's membership structures.  Most will decide that the effort is too great and the benefits too illusory.

Q: Is ICANN being run with due care and adherence to reasonable principles of corporate governance?

The public interest is represented through ICANN's Board of Directors.  If that Board is weak, inattentive, or overwhelmed by ICANN's "staff" then the public interested is served only by occasional good luck.

When evaluating ICANN's adherence to reasonable principles of corporate governance, it does not bode well that during the last year I, a sitting member of ICANN's Board of Directors, had to bring a (successful) legal action against ICANN simply to exercise my rights as a Director to inspect ICANN's financial records.

ICANN's structure is one that was initially crafted to mute ICANN's accountability to the public.  ICANN's "reform" to a large degree did not increase, but actually decreased ICANN's accountability to the public through the creation of layer upon layer of Byzantine structures.  That structural hostility towards the public interest is accentuated by a Board of Directors that is largely unable, and often unwilling, to exercise the kind of oversight that is required in a body that governs the fundamental assets of the Internet.

I made several recommendations to ICANN in my final report to ICANN.  I have attached a "public" version of that report below.  That document is also available online at URL: http://www.cavebear.com/archive/icann-board/icann-evaluation-public-version.pdf 

Q: What is the purpose of ICANN?

ICANN's purpose is to maintain the technical stability of the Internet in the areas of  IP Address allocation, IP protocol parameter allocation, and administration of the root zone of the primary Domain Name System (DNS).

I would like to underscore the presence of the word "technical".

Let me take a moment to examine what "technical stability" might mean.

I suggest that the term "internet" ought to be defined as the open system that carries IP packets from source IP addresses to destination IP addresses.  And the term "technical stability of the internet" ought to be defined as a mode of operation of the internet such that flows of IP packets may occur in a predicable manner and that the upper level of the domain name hierarchy operates so that domain name query packets are quickly and accurately translated in to domain name response packets.

There is, of course, an interplay between technology and matters of business and economic policy.  The question is how to draw a line so that one can say what is, and what is not, properly within ICANN's purpose.

For several years I have suggested that when asking whether a given item is within ICANN's purpose the proper measure is the strength of the connection between that matter and the stable technical operation of the internet.  In other words, it is my belief that matters that do not directly and clearly affect the technical stability of the internet are not within ICANN's proper scope.

By that measure, there are serious questions whether much of what ICANN does is properly within its sphere.  The link between trademarks and the stable technical operation is so tenuous as to be imaginary.  And the intricate and expensive rituals that ICANN has created around the selection and introduction of new TLDs bear no relation to technical stability.

Because of ICANN's inability to define its sphere of competency, the technical community of the Internet has come to look upon ICANN as a bad joke.

Q. What is IANA and how is it different from ICANN?

IANA is the Internet Assigned Numbers Authority - the best way to think of this is the job of maintaining the internet's "big book of numbers".  In the early days of the net the IANA person interacted with network technologists.  However, today the task is largely simply looking up the prior number that was assigned, adding one, and writing down the result.  There is one other task that is performed under the IANA banner that is not so easy and simple - deciding who in a nation gets the franchise to operate that nation's country code top level domain.  This has placed ICANN in the difficult role of deciding who is the legitimate government of a nation.  I am fearful that IANA could be, if it has not already been, manipulated by political factions competing for the right to operate, and thus control, a country's name on the internet.

ICANN performs the IANA function under a purchase order from the Department of Commerce.  The cost to the US government is zero dollars.  In other words, ICANN absorbs the cost of this function by transferring revenues derived from its other jobs in order to provide a "freebie" to the United States.  This relationship has always struck me as exceedingly odd.

ICANN commingles its identity with IANA.  This has lead to situations in which ICANN has been accused of using its power to grant and withhold IANA services, often critical clerical services such as the timely update of "name server" records in DNS, in order to induce nations into entering into contracts with ICANN, contracts that are described by many in the internet community as "pay and obey".

When evaluating ICANN it is critically important to always know what is IANA and what is ICANN.

I have recommended several times that the IANA role be removed from ICANN.  I continue to hold that belief.

Q: What do you suggest that the US Senate or the US Department of Commerce do?

The source of some of the problems that I have described is not ICANN itself, but rather the way in which the US Department of Commerce has used ICANN as a means to delegate the exercise of governmental grade powers without governmental grade accountability to the public.

It is my suggestion that the US Congress enact a Public Powers Act.  Such an Act would define how and under what conditions the exercise of pubic and governmental powers may be delegated to private bodies and define the obligations of such private bodies when they are endowed with the ability to exercise these governmental powers.

Conclusion:

Thank you for the opportunity to submit these materials.  I would be happy to respond to any questions or comments that the members of the committee may have.

         --karl--
        Karl Auerbach
        Santa Cruz, California

Appendix A:

My Thoughts on ICANN's CRADA Report
Originally published on March 20, 2003
These comments are available online at URL: http://www.cavebear.com/old_cbblog/000007.html

Thoughts on ICANN's long overdue CRADA report

ICANN/IANA has issued its long overdue report to NTIA entitled Public Summary of Reports Provided Under Cooperative Research and Development Agreement CN-1634 Between the Internet Corporation for Assigned Names and Numbers and the United States Department of Commerce.  This report may be found at http://www.icann.org/general/crada-report-summary-14mar03.htm

I have asked to see the full reports, but so far ICANN's management has not been forthcoming.  So I have no information regarding the differences between the public and private versions of the report.  I hope that the only difference is the address of the location that ICANN has selected for its god-like master server.

UPDATE: (June 23, 2003) - ICANN's management agreed to let me inspect the full report and has placed no impediments in my path. However due to limits on my own time I have not had the opportunity to actually make that inspection. However, I have reasonable confidence that the only information that was elided from the public report was of such a nature that disclosure would not promote the public interest.

This report purports to describe "Improvements to Management of the Internet Root Server System", frequently referred to as the "enhanced architecture for root server security".  The report is the result of a multi-year "Research and Development Agreement" between ICANN and the US Government.

The report as issued addresses only three small issues:

• Establishment of a new computer to serve as a distribution point for the periodically generated master zone file image.
• Adding a security wrapper to the method that the root servers obtain that master zone file.
• Transferring the job of periodically generating the master zone file image from Verisign to ICANN.

Perhaps the best summary of this report was written over 2000 years ago by Horace: "parturiunt montes nascitur ridiculus mus" ("The mountain labored and brought forth a mouse.")

For truly, this report says little.  And what it does say amounts to only a few relatively minor changes to the status quo ante, hardly the kind of hoped-for hardened domain name system root that the users of the Internet deserve.

I have several questions:

1. The report calls for ICANN to take over preparation of the root zone file.  Might it not be more appropriate for this to be a job for IANA and not ICANN?  Yes, I realize that in the minds of many observers ICANN and IANA are one entity.  However, ICANN and IANA are distinct.  ICANN performs the IANA function only as the result of it winning a contract to do so.  There is no guarantee that in the future that the IANA contract will stay with ICANN.  And thus it seems important to be clear about whether it is ICANN or IANA that has the responsibility to prepare the root zone files.

2. Where is the agreement of the root server operators to this report?  Unless those operators agree, this report will be nothing but wasted paper.  There exists no formal relationship between ICANN (or IANA) and the root server operators; those operators are free to do what they will.  Indeed there is nothing to bind (pun intended) those operators to use any particular source of  master root zone files.  And given the recent positive and creative, but completely independent, work by the root server operators to deploy new servers (using a technique called anycast), it is not at all clear that the root server operators consider it beneficial to enter into any legally binding obligations with ICANN (or IANA.)

3. How does this report answer the concerns raised by the distributed denial of service (DDOS) attacks against the DNS roots and the network links leading to them?  And the recent report that as many as 98% of DNS packets flowing the roots are garbage packets indicates that the roots could be strongly and negatively affected by the deployment of badly written code in consumer products.  I see nothing in the report that improves the resiliency of the DNS roots against DDOS attacks and traffic floods from poorly built equipment.  In fact, because the report suggests a single god-like master server as the source of the ultimate root zone file, it seems as if the net is being made more, rather than less, vulnerable.

4. Another threat to DNS that has been discussed is that of affecting the routing of the net so that some or all of the root servers are left high-and-dry - operational but unable to communicate.  ISPs have built a healthy skepticism into the procedures they use when accepting routing information and as a consequence the net has a good resistance to bad routing information.  However, the routing system of the net is quite complex and there is no one who can guarantee that routing-based attacks will not occur.  In fact, with the root-server operators' adoption of anycast for the root servers, the door for such attacks may be more open than it has been in the past.  The report is silent on means to harden the net so that the DNS roots remain reachable.

5. The report fails to consider that there might be times, such as when there is a major natural event in the vicinity of ICANN's proposed god-like master server, when it is necessary to transport copies of the root zone file by physical means, such as a CDROM.  Why does the report adopt the naive point of view that the net will always be available?  The root zone file is quite small - when compressed it occupies fewer bits than the typical image of a button on a web page.  So it would be quite easy to move it by physical means should that be necessary, but the chances of successfully doing this are greatly reduced if procedures have not been thought out beforehand.

6. It has been considered prudent practice for operators of servers to maintain generational copies of data that has worked in the recent past.  This protects against creeping degradation of the data that may occur over several days and not be noticed until the contents of the most recent backups are themselves degraded.  A couple of years ago, when .com disappeared from the root zone, the speed at which the error propagated was constrained by the fact that the root-servers were not-time synchronized with one another with respect to the time when they updated their copies of the root zone.  The report inexplicably seems to fail to address operational procedures to deal with data rot and human errors.

7. It is also considered prudent practice for there to be a rich diversity of server software and operating systems used by root servers.  Fortunately, the root server operators themselves have adopted some diversity in operating systems and hardware.  And one operator, as I understand it, is using something other than BIND for the actual server software.  The report, however, is silent on this issue.

8. With regard to human errors - Verisign is rumored to have instituted a number of data quality checks on the zone files that it prepares.  This report does not indicate how, or even if, that expertise is to find its way into ICANN.  Nor does the report indicate the existence of any other accuracy checks that ICANN might apply to validate the correctness of the zone it prepares.

9. IPv6 is becoming a victim of the chicken-and-egg syndrome.  The report does not tell us how this "enhanced architecture" is going to accommodate IPv6.

10. Why is the report utterly silent on matters of physical security, procedures, and personnel?

11. A root server that goes out of service for any reason, whether the cause is natural or human, is a root server that needs to be swiftly repaired and restored to service.  That takes money.  The report does not speak to the sources of such funds and how they may be made available to root server operators who might need them.

12. The best protection is prevention.  The report does not address means through which a prospective attacker might be dissuaded from ill actions by the fear of being caught and prosecuted.  Where are the audit systems to note and log attempts to damage the root servers?  And where are the procedures to protect such information so that it is legally admissible in court should the perpetrator be found and brought to trial?

Appendix B

My Evaluation of ICANN
Originally submitted to ICANN on June 26, 2003.
This report is available online at URL: http://www.cavebear.com/archive/icann-board/icann-evaluation-public-version.pdf 

This is the public version of a document submitted to ICANN's Board of Directors. This public version is different in the following ways:

• Items that reflect on the performance of named employees have been elided.

• Typos and misspellings have been corrected.

As a Director one of my duties is to evaluate ICANN for the purpose of improving the corporation and helping it meet its obligations.

ICANN is an organization that is in many ways a much better organization than it was two years ago. This report necessarily focuses more on the negatives than on the positives; that focus is not intended to denigrate from the large body of constructive improvements that have occurred.

ICANN recently selected a new President. Most of the material and events upon which this report have been written date from before the new President's term. I have found the new President to be a person who brings a new positive attitude and approach to ICANN. It is my belief that he has already begun to correct, on his own authority and initiative, several of the flaws that I mention below.

My overall assessment of ICANN is:

• ICANN has diminished its role with regard to the technical stability of the internet and has, instead, become a body that gives too much emphasis to the regulation of business, economic, and social practices that have little relationship to the technical stability of the internet.

• ICANN primarily serves a few select business interests, most particularly that portion of the legal community that practices in the area of trade and service marks.

• ICANN has created a series of barriers between itself and the public. ICANN's decision-making processes are not really open to the public; its decisions are in the hands of a small body of insiders. ICANN's decision-making procedures are not transparent; the public may not truly observe how ICANN makes its decisions. Nor is ICANN accountable to the public; too many layers have been interposed between the public and ICANN's decision-making functions.

• ICANN has commingled its identity with that of IANA and thus has created a significant lack of clarity about whether an act is an act of ICANN or an act of IANA.

• ICANN has failed to gain the support of key elements of the internet technical community, most particularly the operators of the DNS root servers, the regional IP address registries (RIRs), and the technical standards communities (IETF, ITU, W3C, etc.)

• IANA, via ICANN, has been a weak steward of the DNS root. IANA, via ICANN, has not delivered sufficiently comprehensive plans for the secure creation of the DNS root zone or its dissemination to the root server operators. Neither ICANN nor IANA has proposed, much less put into effect, adequate measures to secure the upper layers of the internet's Domain Name System against intentional attack or natural disaster.

• ICANN has been a vehicle through which US trademark laws and (non) privacy policies have been exported onto other countries whether they want them or not.

• ICANN has done some things very well. ICANN's role regarding the issues of internationalized domain names (IDN) has been that of a capable manager who has done a good job harnessing, coordinating, and channeling the energies of other bodies.

An additional question is whether ICANN is in a position to adequately meet the obligations that are imposed upon ICANN by the various agreements between ICANN and the United States.  It is my conclusion that ICANN remains structurally unable to meet those obligations.

These questions are made all the more difficult by a lack of clarity between ICANN and IANA, the two are often intermingled in peoples' thoughts, which is quite understandable given that the tasks of ICANN and IANA are performed by exactly the same people working out of the same offices.  There appears to be a strong concern that ICANN qua IANA uses the power to withhold IANA services as a means to coerce unwilling entities, particularly ccTLDs, into entering into agreements with ICANN.  In addition, there is very little support among the technical community or the regional IP address registries (RIRs) for the present ICANN-IANA structure

Most people in ICANN and IANA work unbelievably hard to create a better internet.  Many of these people work behind the scenes and are frequently not known to the public.  These people are rarely, if ever, thanked for their work.  I would like to take this opportunity to mention a few of these people.  I do not know everyone within ICANN, so the list is necessarily incomplete.

For myself and on behalf of the community of internet users I would like to thank:

• <list elided from the public version>

There are many symptoms indicating that ICANN has structural problems:

• Recent events in which a DNS root server was moved and new root servers created, all without even notice to ICANN, indicate that the level of disdain for ICANN has reached the point where ICANN's technical role in DNS has, as a practical matter, ceased.

• The IP address allocation system has also, as a practical matter, disengaged from ICANN, with the fact of independence covered only by a few rather transparent veils.

• ICANN has little support from the rank and file of the internet technical community.

• The national governments in the GAC have given ICANN strong notice of their concerns.  The US Dept of Commerce has also put ICANN on short notice.

• The ccTLD community reacted strongly to ICANN's overreaching demands for data access (a practice that ICANN has since discontinued.) There is widespread belief that ICANN has abandoned RFC1591/ICU1 and used its ability to grant or withhold IANA services to coerce ccTLDs to sign ICANN contracts. The community of internet users has never given ICANN any real support.

• What was once a growing and internally vibrant public "at-large" community has withered due to frustration and a creeping eradication of the role of the public within ICANN commensurate with the roles accorded to other groups.

What are the causes?  One cause is that ICANN has a Board of Directors that directs weakly, leaving staff too much discretion. Another cause is that ICANN has adopted measures that are in opposition to the goal of being a body that is transparent, open, and accountable to the public. A third cause is that ICANN has strayed from the path of being a limited organization dealing with matters affecting the technical stability of the internet.

4.1  Is ICANN A Floor Wax Or A Dessert Topping?

ICANN clearly is having a difficult time deciding whether it is a technical coordination body or a social engineering and public-policy body. For example ICANN executives have made inconsistent claims - sometimes claiming that ICANN must avoid regulation of business practices because ICANN is limited to technical matters and sometimes claiming the opposite - that ICANN must become deeply engaged in the regulation of business practices even when there is no link to technical matters.

ICANN has a similar difficulty deciding whether its job is to protect consumers and users of the Internet or whether to leave that up to legislatures and other governmental bodies.

There is one thing that pretty much everyone agrees upon - ICANN's role is somehow supposed to be related to the stability of the internet. And ICANN's structure is premised on the notion that there are identifiable groups, called stakeholders.

But those words, "internet", "stability", and "stakeholder" are not defined.

It may seem petty to be concerned about definitions of words. Yet, often the resolution to thorny disagreements may be found by looking at the ways in which the disagreeing parties use words.

As will be discussed in the next section, it is my opinion and that of many of my constituents, that ICANN's role be balanced more towards the technical and away from social engineering, and that that the communities who are considered as having standing, i.e. "stakeholders" be read broadly rather than narrowly. Thus I suggest the following definitions for use when discussing ICANN and its role:

Recommendation: The term "internet" ought to be defined as the open system that carries IP packets from source IP addresses to destination IP addresses.

Recommendation: The term "stability of the internet" ought to be defined as a mode of operation of the internet such that flows of IP packets may occur in a predicable manner and that DNS queries are accurately and quickly transformed into DNS replies.

Recommendation: The term "stakeholder" ought to be defined as any person who is affected by the internet.

ICANN is not lazy.  When ICANN sees a job, it adds that job to its repertoire.  ICANN is, however, a poster child for the old adage that "a jack of all trades is a master of none".

ICANN's proper role can be easily rolled up into a few bullets:

• To coordinate the assignment of internet technical parameters as needed to maintain universal connectivity on the internet. To a large extent this is a clerical job occasionally augmented with the need to ask a question of a technical expert designated by the IETF.

• To coordinate the job of fairly assigning IP addresses so that the packet routing systems of the internet can work efficiently, accurately, and reliably and to avoid unreasonable inefficiencies in the use of assigned blocks of addresses. An additional aspect is to create and apply policies to determine under what conditions an application for IP address space is to be granted and when denied. To a large extent this job is already being well performed by the regional IP address registries (RIRs).

• To coordinate the daily creation of a DNS root zone definition (or root zone file) and operation of a suite of DNS root servers so that the resolution of top-level domain name labels is efficient, reliable, and accurate.  An additional aspect is to create and apply policies for determining the circumstances under which new top-level domains are added to the ICANN operated DNS root system.

ICANN has no other jobs, or rather, it ought to have no other jobs.  ICANN ought not be a legislature enacting trademark law.  ICANN ought not be a consumer protection agency.  And ICANN ought not be a regulatory agency that says what business structures are acceptable and what are not. Unfortunately ICANN has exceeded itself; ICANN has become all of these.

All technical decisions on a system as pervasive as the internet have social and economic implications. I use the following guideline to distinguish matters that are primarily technical from those that are social policy:

A matter is "technical coordination" of the internet if a decision on that matter has an immediate and direct impact on the ability of the internet to deliver its fundamental service, i.e. the end-to-end transport of IP packets or the timely and accurate transformation of DNS queries into DNS responses. Otherwise it is a policy matter.

As measured by that yardstick, ICANN has done very little in its four years of existence that can be unquestionably labeled "technical coordination" - the bright spot being ICANN's fine performance with regard to internationalized domain names. Otherwise, nearly every act of ICANN has, from its inception, been social engineering.

At the present time there really is no standard to judge whether ICANN is acting within its scope or not.

At the time of this writing, ICANN's staff is nearing 30 people (with the prospect of 40 on the visible horizon) and its budget could readily reach the $10,000,000(US) mark within a short time.

There has been little pressure to reduce this growth.  ICANN's cost-based budgeting technique does little to discourage an ever-increasing bureaucracy.  Those who provide the funds for this budget are principally those businesses that are able to pass those costs onto internet users who, in turn, bear the costs of ICANN as an involuntary tax imposed on their use of the internet.

Recommendation: ICANN must adopt a realistic statement of its job. That statement must contain sharply defined limits on ICANN's job.

Recommendation: ICANN must adopt a budget process that contains stringent caps on growth and that requires the positive and express consent of those from whom the money is ultimately derived, the users of the internet.

ICANN is not IANA.  IANA is not ICANN.  Yet ICANN is not careful to avoid commingling these two entities. Decisions are too frequently shuttled between ICANN and IANA.

ICANN performs the IANA function under a purchase order from the US Department of Commerce.  This IANA function includes the prompt performance of several duties, not the least of which is the handling of ccTLD redelegations and the maintenance of ccTLD NS records in the root zone of the DNS.

ICANN has a desire to enter into contractual arrangements with as many ccTLD operators as possible.

This creates a conflict. ICANN is suspected by many of manipulating the granting and withholding of IANA services in order to induce ccTLD operators into signing a contract with ICANN. It is important to break that link, even if that link exists only as a perception.

Another part of the IANA function is maintenance of "protocol parameters".

The IANA "protocol parameter" function is essentially a clerical function performed for the IETF.

A third part of IANA concerns the allocation of IP addresses.

The IANA IP address function is something with very large potential economic effects.

The technical aspects of IP allocation are esoteric and complex; it is hard, and perhaps impossible, to fully understand the ultimate effects of IP address policies. For the time being, experience has demonstrated that the Regional IP Address Registry (RIR) system is working acceptably well (and it appears, whether measured in terms of efficiency and justifiability of allocations or in terms of concern for non-technical issues, to be improving.) There is no reason to fix something that is not broken.

There has been a great deal of concern about how ICANN operates IANA by those who use IANA services

Recommendation: ICANN should not continue to provide the IANA function pertaining to IP address allocations and protocol parameters. Those functions should be transferred to the RIRs and the IETF respectively.

Recommendation: If ICANN does continue to provide the full range of IANA services, it should be done in a way that minimizes any discretionary aspects in the provision of those services.

A primary aspect of ICANN's contractual obligation is that it operate for the public benefit and be open, transparent, and accountable to the public. Unfortunately ICANN has since its formation structured itself with increasing efficiency to operate to a rather opposite purpose and is thus has diminished, rather than increased, its ability to meet these obligations.

ICANN has shed institutional features related to public accountability and has been captured by the industry groups that ICANN is intended to regulate. ICANN is unable to distinguish what matters are in the public interest, if for no other reason than that ICANN has expelled the public from its policy-making bodies.

ICANN has also been captured by its law firm and transformed into an engine that efficiently generates large legal fees flowing into that firm's coffers.

As for ICANN's obligations pertaining to DNS, IP address allocation, and "protocol parameters":

DNS - New Top Level Domains - ICANN has found it difficult to meaningfully increase the number of DNS top-level domains. Only seven have been added during ICANN's 4 ½ years of existence. Several of those new top-level domains have not in any cognizable way contributed to the public value or usefulness of the internet.

ICANN is losing the ability to use the claim that ICANN is studying the deployment of new TLDs as a reason to further delay further TLD allocation.

There are signs that ICANN's future path of TLD allocation will be even more limited in number and even more focused on benefiting tiny industry segments with no benefit accruing to the broad community of internet users.

Academic papers that have examined ICANN's TLD processes, past and present, have found them to contain many disconcerting similarities to radio frequency allocation methods that were tried and found severely wanting.

DNS - Competition - ICANN was supposed to introduce competition into DNS. While it is true that there are more players than there were in the past, it is arguable that there really is competition. Among other things, ICANN has created a contractual straitjacket that stifles many, perhaps most, avenues of competition.

In addition, ICANN has created a price floor of roughly $6. Some analyze this situation by comparing the typical customer price of names today - a number ranging from about $10/year to $35/year - to what it was pre-ICANN, about $35/year. However, that comparison fails to recognize that there is a strong likelihood that without ICANN and the price floor, prices could readily be an order of magnitude lower.

DNS - Customer Protection - ICANN's purpose to promote stability of the net has been restated on several occasions as justifying business regulation of DNS providers so that those who acquire domain names won't discover that those names have been lost or rendered unusable due to provider failure or error.

However, while ICANN has in fact built a highly intensive business regulatory structure, one of the most important components of value to the DNS name users is still weak. That part that is still incompletely fulfilled is the escrow of all DNS registration data so that the customer base of a failed of a DNS provider can be recovered, and service restored.

IP Address Allocation - The IP address allocation system is today exactly as it would have been had ICANN never existed. IP address allocation policy is made and administered by the regional IP address registries (RIRs). ICANN's only involvement is through an occasional grant of address space to the RIRs by IANA, not ICANN.

The RIRs themselves maintain a most tenuous linkage with ICANN. It is clear that ICANN is not actually overseeing IP address allocation policy.

Protocol Parameters - ICANN operates IANA. IANA has been doing a competent and adequate job of allocating numbers.

It is difficult to understate the complexity of this task. To a large extent the job consists of simply incrementing the previous number assignment and writing the result down in a ledger. ICANN has filled its periodic status reports to NTIA with lists upon lists of the numbers assigned but without revealing the clerical nature and nearly trivial work required to process the large majority of those events.

ICANN's organizational structure has always been Byzantine.  The "reform" has made ICANN rather more convoluted.

ICANN today is too complicated; there is enormous structural friction and little benefit from shared administration.

This highly ramified organization structure leaves ICANN open to manipulation by sophisticated industry advocates who have plenty of time and money and, at the same time, makes it nearly impossible for the public to penetrate beyond ICANN's outermost shell.

Recommendation: Split ICANN into separate organizations along technical functional lines: one for DNS, one for IP addresses, and one for Protocol Parameters.

ICANN's management provides the board with essential information.  However that information is often provided late, forcing the Board to make snap decisions without adequate consideration and without the time to consult with the public.

Recommendation: ICANN's management should make a monthly report to the board.  This report should be in standardized form to facilitate comparison of changes of position.  The report should contain standard financial reports as well as a list of all non-trivial financial and business transactions, including transactions pertaining to the acquisition and delivery of professional services.  Except for those parts dealing with employee matters, contract negotiations, litigation, or those that are subject to confidentiality imposed via written contracts, this report should be made available to the public.

The public depends on ICANN's Board of Directors to guide ICANN in the public interest. Yet, no matter how much that voice is reflected in the Board, that voice is muted because ICANN's Board of Directors leaves too much policymaking to ICANN's management.

ICANN's Board rarely challenges any act performed by management. The Board rarely requires management to provide the timely and complete information that the board needs to make informed decisions.

On many occasions I have heard board members excuse the board's lack of supervision on the grounds that the individual directors are not professional directors, that they are, in essence, contributing their time and energies.  There is validity in the fact that being a Director is an enormous burden that may have significant ancillary implications on one's personal finances and relationships.  However, rather than using that as means to excuse lack of supervision by the Board, ICANN ought to take steps to empower its non-professional directors to act more like professionals.

Recommendation: ICANN's Board of Directors should hire its own outside counsel to advise the Board on its rights and duties.  The choice of outside counsel should be in the hands of the non-management Directors.  This outside counsel must not be affiliated with any law firm used by ICANN management and this outside counsel must have clear and unambiguous responsibility to ICANN's Board of Directors as a collective body and not to any Director individually or to ICANN's management.  Any Director may raise questions for this outside counsel.

Recommendation: Every member of the Board should be given the opportunity to privately interact with the outside auditors.  ICANN's management should have no role in financial audits except to provide information to the board and to whomever the board selects as outside auditors.  No member of ICANN's management should sit on ICANN's Audit committee.

Recommendation: The membership of ICANN's committees should rotate yearly with at most one holdover.  No person who remains on a committee may chair that committee and no person may remain on a committee for more than two years.

Recommendation: ICANN should revise its organic documents to constrain the powers of the Executive Committee, limiting it only to exigent matters.  No member of ICANN's management should sit on the Executive Committee.

Recommendation: ICANN's directors should all be encouraged to take a course on the subject of corporate governance and the rights, duties, and liabilities of corporate directors, particularly in the context of a 501(c)(3) corporation.

Recommendation: ICANN's president should not have an ex-officio seat on ICANN's Board of Directors.  The President may be permitted the right to attend Board meetings as a non-voting observer.

Recommendation: All Directors of ICANN, with the exception of those who hold their seats through ex-officio mechanisms, ought to receive a yearly expense allowance with the expectation that that allowance will be used by each Director to improve his or her ability to oversee and supervise the corporation and its management.  It is recommended that this allowance be between $10,000(US) and $25,000(US) per year.

Too many of the discussions and meetings of ICANN's Board of Directors are closed to the public; the public learns about what transpired only by means of minutes.

It is important to both ICANN and the public that the workings of the board be more observable. ICANN will benefit by increased public confidence that the board is properly doing its job. The public will benefit by having a better sense of what changes should be made in ICANN so that ICANN more closely operates in accord with what the public perceives to be in its interest.

Recommendation: All meetings of the Board of Directors and of its committees should be audio-recorded and made available to the public.  No matter may be elided except after an on-record decision that a particular matter should be discussed off the audio recording.  Only matters pertaining to personnel matters, litigation (or potential litigation), and contract negotiations may be discussed off the audio record.

ICANN has been too slow when creating and establishing rules and procedures for employees.

Until as late as September 2002, nearly three years after ICANN's formation, ICANN had no cohesive collection of employee rules and procedures.  Indeed, it appears that the eventual creation of what exists now was partially a response to my inquiries for more than 18 months whether such rules and procedures even existed.

I have reviewed ICANN's employee polices and, in general find that those that do exist are competent and well done.  However, as compared to other such collections of employee policies, ICANN's have less breadth than I have seen among technical companies in California.

ICANN appears to have paid a considerable amount of money to ICANN's law firm over a period of roughly two years for the creation of those policies that do exist.  At the current rate and expense, an employee handbook of normal scope will cost ICANN quite a bit more money in legal fees and may not be in place for another year or longer.

I have personally used some software packages to generate employee handbooks - these packages cost on the order of a few hundred dollars and take about a day to use.  The results have been quite good, to my mind the specific policies are at least on par with those that ICANN has in place today and the overall scope of coverage of the policies considerably broader than that which ICANN has in place.

ICANN's employee count is already on the order of 30 people and is likely to climb to nearly 40 people within the next year.  ICANN has probably passed the employee count that triggers increased employee obligations such as those imposed by the Americans with Disabilities Act (ADA) and the Family and Medical Leave Act (FMLA).  I saw no materials in ICANN's employee materials regarding ICANN's obligations and policies under these laws.

Recommendation: ICANN's management should take steps to increase the breadth of its employee policies.  This process may be made more efficient through the use of readily available software packages that generate employee handbooks.

Recommendation: ICANN should undertake an immediate review of its personnel policies to ensure compliance with all applicable laws such as the Americans with Disabilities Act and the Family and Medical Leave Act.

I have examined selected travel records of ICANN employees and contractors.  There are too many people traveling to too many places.  For example, one ICANN employee, when measured on an annualized basis, traveled around the world several times visiting nearly 50 non-US venues a year.  And one meeting in Africa was attended at least four members of ICANN's staff despite the presence of an ICANN Director.

In addition, invoices from some of ICANN's contractors, particularly its law firm, indicate travel expenses that, on average, are well in excess of $1000 per day.

Recommendation: Except for the public meetings of the Board or when special circumstances can be clearly articulated and documented in advance, ICANN should avoid sending more than a single staff member to any meeting.

Recommendation: Contractor travel expenses should be subject to explicit limitations.

ICANN's financial controls could be improved.

After looking at many vague expense reports and invoices that ICANN has paid, it is clear to me that ICANN's ledgers are partially un-auditable.  The paper trails have too many gaps and too little detailed information.  For example, as of October 2000, ICANN's primary creditor, Jones Day, switched from detailed billing to summary billing.  For the last two years, ICANN has paid millions of dollars on JDRP invoices that contain little more than names of attorneys and total hours billed without any indication of what work was done during those hours.  In fact, there is apparently no engagement letter between ICANN and JDRP that establishes the bounds of JDRP's job or sets the billing rates (which is particularly important in light of the "discounts" that JDRP purports to be giving ICANN.)  There are expense reports from people I have never heard of and without any written links to indicate why ICANN is obligated to pay that money or how (or even if) the payment was in fact made.   In some cases it is hard to determine who incurred the expenses or who approved them.

ICANN's finances are sufficiently complicated that a person trained and experience in the field of accounting, particularly in the context of a 501(c)(3) organization, ought to be performing the CFO function.

Recommendation: ICANN should fill the CFO position with a person who has strong accounting experience and credentials.  ICANN's CFO should not be asked to perform additional jobs.

Recommendation: ICANN's CFO should establish standardized forms for expenses that require clear identification of who is incurring the expenses and why ICANN is obligated to pay them.  There should be clear approvals with more than an undecipherable set of initials to identify who is making the approval.  No person should be allowed to approve his or her own expenses or expenses they submit on behalf of a third party.  And there should be a clear linkage to entries in the financial ledgers showing how and when those expenses were paid.

Recommendation: ICANN's CFO should not permit summary invoices. Instead ICANN should require that all invoices, including those from professional service providers, give detailed information on what work was done and show all applicable rates and discounts.  No invoice should be paid without a written agreement between ICANN and the provider.  In addition, ICANN's CFO should require JDRP to provide ICANN with detailed statements for the period beginning approximately October 2000.

In recent years Microsoft and other companies have used consultants and contractors in lieu of employees.  However, in many cases these non-employees had duties and schedules that were not sufficiently different from those of the true employees.  This caused several problems both for the companies and for the non-employees.

ICANN is understandably and reasonably concerned about the cost of employees and the long-term obligations that arise from an employment relationship.  The use of consultants and contractors is a reasonable business tactic for ICANN to use.

However, I have examined certain of the consulting contracts that ICANN has entered into and find them to have characteristics that could cause the IRS or others to re-construe them as employment contracts and thus trigger all of the obligations and expenses that ICANN is trying to avoid.

Recommendation: ICANN should take steps to amend existing consulting and contractor agreements to ensure that they are clearly not employment contracts.  For example, ICANN ought to avoid using contractors or consultants for more than 16 or 20 hours per week for more than a few weeks.  Nor should contractors or consultants have supervisory roles over actual ICANN or IANA employees or other contractors or consultants. Contractors and consultants should only have limited access to ICANN facilities and documents.  Contractors and consultants should be required to clearly identify themselves as not being ICANN employees or officers in public communications.

Jones Day (JDRP) is ICANN's law firm.  This has been the case ever since before ICANN was formed.

It is standard professional practice for the relationship between a client and its law firm to be governed by an "engagement letter" that sets for the terms and conditions of the relationship, establishes billing rates, and clarifies any conflicts of interest.

There was an engagement letter between JDRP and ICANN that set forth a pro-bono arrangement.  However, an examination of the billing records indicates that this arrangement lasted only for approximately 6 weeks after the time of ICANN's formation.

From a time beginning a few weeks after ICANN's formation until at least last fall there has been no engagement letter in place that sets forth the present arrangements.  Despite this lack, ICANN has paid JDRP several millions of dollars in legal fees.

ICANN's law firm has never provided ICANN with any statement of its conflicts of interest, yet it is quite clear that such conflicts exist.  For example, AOL is an accredited DNS registrar, yet that law firm represents both ICANN and AOL.  There is no shame or wrong in the existence of conflicts if such are properly disclosed and knowingly waived by the client, ICANN.  However, there is much that is wrong if the law firm fails to disclose or fails to obtain from the client, ICANN, a knowing, written waiver of those conflicts.

I have observed several aspects of the work product coming out of JDRP.  It is my opinion that this work has on occasion been below acceptable professional standards.

(I should note, however, that JDRP has also done much work of exceptional quality, meeting the highest of professional standards.)

In addition, certain JDRP personnel have engaged in what I believe are unprofessional actions that give rise for significant claims by ICANN against JDRP.

Recommendation: ICANN should establish a current engagement letter with JDRP setting forth the terms of the relationship of ICANN and JDRP.

Recommendation: ICANN should require Jones Day to make the necessary disclosures and take other steps to bring its practice into conformance with applicable laws and professional standards.  ICANN should make a dispassionate review of these disclosures and consider whether the integrity of any of ICANN's acts have been compromised as a result and consider whether to seek compensation. The Austin-Sidley letter reviewing the work of certain JDRP personnel should be disregarded because it was based on inaccurate information provided to Austin-Sidley by ICANN management.

Recommendation: ICANN should refuse to pay invoices for substandard legal work.

Recommendation: ICANN should require JDRP to provide detailed invoices in the future and should obtain detail information from JDRP for the nearly three years that ICANN has been receiving summary invoices.

Recommendation: ICANN's Board should inquire whether ICANN would be better served by a different law firm.