The fifth and most recent Draft of the IANA Bylaws, dated 28 September 1998, calls initially for the creation of three Support Organizations (SOs), one each for Internet Protocols, Numbers, and Names. Each organization has been tasked with defining how funds should be collected to pay for ICANN operations. It is not yet known whether ICANN or the SOs will be the agent for the collection of these. In any event, it appears that the majority of funds will be collected using models defined by the SOs and approved by the Board.

How funds are collected, the distribution of responsibility for collection among the different constituencies within the DNSO, and development and maintenance of a consensus on this issue are critical to the success of ICANN and the Support Organizations.

During the first Domain Names Support Organization (DNSO) organizing meeting, on 16-18 October in Barcelona, Spain, we briefly discussed this subject. It was immediately obvious that there were many relevant subtle factors which interacted in complex ways, and that many of the participants had not had a chance to investigate these ideas at depth nor to develop a common approach to the issue.

Our primary goal in writing this paper has been to provide a common framework for the discussion, and thus to contribute to the creation of a sound funding model. We hope that, in spite of different perspectives which may be held by the participants, this framework will focus the discussion, improve the quality of the debate, and provide a basis for further development.

We first review key concepts and working assumptions, and clarify some important terms. We follow that with a list of criteria which will guide our choice of funding models. Using these sections as a guide, we then review the services provided by ICANN, for which fees could be charged. We evaluate this approach and list major alternatives for funding models. The alternatives are reviewed against the criteria, and one particular model is advanced. We offer this as a "straw dog" model, and hope to see much critical review. We believe that significant additional discussion and debate are required before the best solution will be found.

We encourage the reader provide their input at the upcoming DNSO organizing meeting in Monterrey, Mexico. Comments before that meeting are welcome and should be sent to the DNSO list.

The Bylaws specify principles to be followed ICANN in Article III, Sections 1, 2, and 3. The Supporting Organizations should also expect to satisfy these criteria. They include:

• open and transparent operation,
• regular reporting, and
• provisions for notice and comment.

[comment: fiscal accountability?]

The following text, taken from the 5^th Draft, refer directly to fees, budgeting, and related items.

There has been broad agreement in the Internet community that the ICANN should be a not-for profit organization, and a related consensus that ICANN funding will be cost-recovery oriented. That is, ICANN should not charge fees greater than those required for it to support its day-to-day business funding requirements. Additionally, administration of ICANN should be cost-conscious and conservative: it should mirror cost levels found in similar organizations. There is a corresponding requirement that an undue surplus should not be accumulated. Rather than find a way to distribute any accumulating surplus, it is preferable to find a way to vary fees in accordance with maintenance of a reasonable surplus.

One often finds the terms ‘cost’ and ‘price’ used interchangeably, a practice we don’t follow. In this paper, we use ‘cost’ to mean the economic requirements for development, deployment, and delivery of a product or service. That is, the amount of money required by the vendor to create and deliver to a customer a particular item. Price, on the other hand, is whatever is paid by a consumer to the vendor of a product or service. Although one usually assumes that the price of a given service is more than its cost, this is not necessarily the case.

Determining costs can be complex and subtle. For example, what is the cost of allocation of a domain name? These complexities usually have to do with the size of the ‘production envelope’. That is, the scope of activities which contribute to the creation, and hence the cost, of a given service. These activities can variously range across part or all of an organization, and additionally across different periods of time.

In this paper, we consider nearly all of the activities of the ICANN to be within the scope of cost of allocation of a given domain name. Although in principle, more weighting should be given to names-specific activities with ICANN, that may not be possible in practice. Consequently, rough approximations will likely be required to determine ICANN name-related costs.

Pricing is driven by two opposing approaches: cost-based versus value-based pricing. Under a cost-based pricing model, the price charged the consumer is directly related to the producer’s cost. Value-based pricing, on the other hand, is related to the value which that product or service brings to the user. By and large, for-profit organizations seek to value-price their goods; not-for-profit organizations tend in the other direction: to charge for their services on a cost-recovery basis (as is often required by law).

Fees may be divided into two groups: general fees and use fees.

General fees include membership fees, and licenses. They typically act as a general-purpose price-of-entry charge and are often only weakly related to the amount of resources consumed. Use fees, on the other hand, are levied whenever some sort of specific interaction or exchange occurs.

[Use fees] Examples of use fees include postage stamps or charges to make a telephone call. Use fees tend to be a bit easier to pass on to the consumer than are general fees. Additionally, as distinct from general fees which tend to be fixed, use fees are inherently flexible: as the number of transactions (and use of resources) goes up, the amount of money collected rises.

The DNSO will likely require both general and use fees. We suspect that the advantages of use fees will lead to their being the source of the majority of funds collected.

Although ICANN has not yet published a budget, based on discussions with a variety of participants, we assume $US 3 million per year for the first three years. We assume that this will meet all requirements, including capital expenditures, with one exception: accumulation of a legal defense fund. We assume that this will about $US 10 million. This amount should be collected within the first three years, and maintained at that level thereafter. This implies some uncertainty in how much will need to be collected from the SOs, as the level of legal cost may vary significantly each year.

There will probably also be short-term funding requirements as ICANN starts up. Since these have not yet been announced, we do not address them at length in this paper.

We assume that each of the SOs will pay 1/3, or $1 million per year. For the legal fund, we assume that the majority of litigation will be oriented around names. Because of this, we assume that 2/3 of the legal defense fund, or approximately $6,750,000 will be specified by the DNSO. We also assume that this fund will be accumulated over three years (roughly $2,280,000 per year). Note: it is not clear if this fund will need to be created explicitly, or if it may be possible to purchase some form of insurance policy.

The following criteria should be used to evaluate any proposed funding model. They are not strictly disjoint; some will likely conflict with each other in some cases.

Enough funds must be collected to meet the operating requirements of ICANN. ICANN should not need to repeatedly return to the Support Organizations for additional funds.

The ICANN budget will certainly change over time. For example, the collection of the surplus will not need to continue once a certain level (per above) has been reached. Additionally, the size of the participants in the DNSO, and the amount of activity they engage in, will certainly change over time. Each of these factors will require that the funding model adapt to these changes. There must be change mechanisms built in from the start. Agreement on a change should not require either years of debate nor a near-revolution.

Fees charged by ICANN to its Support Organizations will in turn be charged to their members. Members will charge their customers, who will in turn charge their customers, and so on. Whatever fees are charged should, as much as possible, correlate closely with actual costs.

Internet users are still in a period of discovery regarding services and costs: they are still learning the economic impact of various choices. If the DNSO creates a funding model that significantly masks or distorts the economic signals received by users, it could cause users to make non-economic choices. This could distort or slow the evolution of the Internet. Fortunately, the costs, imposed by ICANN, and the potential for distortion, will probably be small. This nevertheless remains a wise principle to follow.

We use fairness here only to mean that there is a direct correlation between the amount contributed and the ability to pay (e.g., wealthy entities should pay more than poor ones). Fairness is an especially tricky concept which can conflict with the "no price distortion" criterion above. Finding a balance between these two criteria is a key mission of the DNSO.

It is critical that there be a diversity of funding so that ICANN will not be inappropriately influenced by one or more constituencies.

Transaction costs are related to the processing of fees and do not add value; they are pure overhead. They should be kept as low as possible without compromising quality. This is an especially sensitive area. All costs will eventually be borne by the users and end consumers of name services. Since companies in the names business can simply pass these costs on to their users, there may be limited feedback for keeping transaction costs low.

Simplicity results in reduced costs and a greater ease in comprehension by consumers and the public.

The funding model must be clear and available for public review; both key components of any open process. It must be organized in a way so that the details of cost, collection, and administration may be readily understood by external reviewers and the public.

Registries and Registrars will be operating as businesses which require long-term stability. It is critical that fees change in a smooth and predictable manner. Although this may appear to conflict with the "Able to Evolve" criterion above, this is not the case. Rather, changes are entirely acceptable as long as they are made in a smooth manner with reasonable prior announcement.

This section reviews the costs that will be incurred by ICANN and considers how their support should be distributed among the three present Supporting Organizations (SOs).

We deliberately "over-engineered" the cost centers below; some of them may be non-existent. We have listed them to ensure that this section is as complete as possible. We foresee the following cost centers:

- Overhead

- Costs related to the administration of Protocols.

- Costs related to the administration of the Domain system.

- Costs related to the administration of the IP address system.

- Costs related to the administration of the Root server system.

- Overhead.

- Equipment.

- Operation of the root

- Operation of the root servers under the direct control of ICANN

- Coordination with other root servers

- Distribution and control of IP addresses.

- Editing and management of [the RFCs and] protocol related documents. [RFC editor functions are explictly remaining within IETF, as I understand it]

- Research

- Domain Names Supporting Organization (DNSO).

- IP Address Supporting Organization (ASO).

- Protocols Supporting Organization (PSO).

- Legal costs related to the control of the domain system.

- Legal costs related to operation of root server

- Costs related to possible IP address disputes.

- Legal Overhead

Of all these, we find that the most controversial ones are the costs related to the Root Server System, Legal costs and Administration and Operational Overheads, including equipment. We review those in detail.

The Root Server System (RSS) does the basic conversion between domain names and addresses. Its basic function to assure that, when domain names are used to access resources of the Internet, these names are translated into IP address which may be then used by the Internet routing system to find and access the desired resources.

It has a secondary function, called "reverse look up": finding a domain name when the IP address of a server is known. This function is being used more and more by security systems to ensure that the machine that originates a message is who it claims it is.

The central RSS is not used every time a domain is used to find a resource in the Internet. IP addresses of resources recently used are "cached" (remembered) by local ISPs. If a user connected to that ISP wants to access a resource, the ISP will first look into its page of "recently used domains". If it does not find the desired address, it will access the RSS to look it up, otherwise it will do the translation locally.

A follow up of this is that resources (web pages, as an example) that are used very frequently do not generate a proportional use of the RSS, as the address will probably be "cached" by many ISPs.

We can see three separate costs in the RSS:

- Cost of communications to update the RSS.

- Cost of storage and maintenance of the information stored in the

RSS.

- Cost of communications for users to access the RSS.

- Cost of updating the RSS for TLDs.

- Costs related to "reverse look up".

The first two are related to the number of domains stored. Presently, the RSS includes not only the "root zone", which points at the computers that store the tables for TLDs, but they also include the tables for three generic top level domains: ".com", ".org" and ".net". Plans are underway to separate these two functions.

The amount of date stored in the basic "root zone" is very small, one entry per TLD. The data stored in the table for the three TLDs has over two million entries. Unless the structure of the system is changed, the space and communications used by the root zone is well under 1/1000 of the ones used by the three TLDs.

The cost of communications related to access follows a different scheme. The root zone receives a much higher number of "hits", as any IP address in the Internet that is not cached must asked from them RSS.

[Remove this -- it probably won't be true for ICANN--

Addresses that are associated to any of the three gTLDs use twice as much of the resource, as the question has to be asked twice from the RSS:

The conclusion is that the use of the RSS communications is not proportional to the number of times that a domain is asked for by a user, but by the number of "hits" received for a given TLD, and that "hits" for the three gTLDs named use twice as many resources.

]

The number of hits that each TLD receives is known (may be known) by the RSS administrators.

Costs related to "reverse look up" are still part of the domain system. They are used by security mechanisms strongly related to domains, and should therefore be also related to the user communication’s costs and considered as "direct look up" (the usual way).

Most of the root servers are presently run on a voluntary basis by different organizations that do not charge or intend to charge ICANN for running the servers. Only the costs of the [server] servers that are directly run by ICANN (assigned to ICANN or temporarily in ICANN) or under contract with ICANN should be considered as costs incurred.

It seems clear that operational costs related to each one of the areas should be assigned to the corresponding organization. However, we don’t know what these costs actually are.

The most controversial may be the protocol administration [and RFC editing] functions, as it has traditionally been founded in different ways. ICANN could assign a part of the cost to each one of the other two Supporting Organizations. The rational behind this last idea is that the final "clients" of ICANN functions are the users. Fees are collected from the users through the Names and Address SOs, but it is not possible to collect them through protocols, so funds should be routed from the users through these two SOs.

It is our opinion that each SO should be maintained by all members of that organization, independently of where the resources to run ICANN raised by that organization come from.

As an example, the administrative and overhead costs for running the Domain Name SO should be paid by all its members, independently of their role in the support of ICANN, which will come, we assume, from the domain and IP address users through the TLD registries, who collect them from the users.

We see two major sources of legal costs. The first is the legal overhead, related to the day-to-day operations of IANA. The second, unfortunately much more significant, is the cost of defending the ICANN from challenges to the control of the domain name system.

[Most challenges are likely to come from organizations who will want to have their own private TLDs included in the root as generic TLDs.]

This cost is clearly related to the management of the domain system, as it would not be incurred if such system did not exist.

[The goal of the legal defense is to protect the integrity and rationality of the domain name system, as well as avoiding monopolistic interests of the challenging parties that could end up in harm to final users.]

It seems that the costs should be considered as costs related to domains, and therefore assigned to the DNSO. The policy of considering them an overhead cost could also be considered.

The overhead includes salary of directors, administration equipment, travel, rentals and all costs that are related to the every day work of ICANN. It should also include equipment and personnel that is not specifically assigned to one of the functions, including accounting, auditing, etc.

The 5^th Draft Bylaws calls for charges to made for the "……services, rights and benefits provided by the Corporation to the Supporting Organizations……" . These may be arranged into three layers:

THIS SECTION IN PROGRESS……….

• DNSO member franchises

In a conveniently-structured world, there would be clear relationship between the costs incurred by ICANN, and the services provided by each of the Support Organizations. Unfortunately, this is not the case. There is very little correlation between the costs of creation of a given TLD and the number of names which may be sold. Consequently, a fee linked to each name allocated, while possible related to the