[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DNSO / ICANN Funding Model Paper, Version 0.1
- Date: Sun, 15 Nov 1998 02:12:50 -0600
- From: Glenn Kowack <firstname.lastname@example.org>
- Subject: DNSO / ICANN Funding Model Paper, Version 0.1
Kent Crispin, Javier Sola and I wrote the attached draft to help guide the DNSO/ICANN funding model discussions at the upcoming Monterrey meeting. We believe it will provide useful input on how to collect funds, as required, in support of ICANN.
This is a working document which focuses on structure and background, and provides a rough draft funding model that requires further development. Comments welcome.
The document is in MSWord Windows 95/6.0 format. I have also postpended the text of the file below in case you have any difficultly opening the file.
Considerations for a Funding Model for the Domain Name Supporting Organization
Challenges, Criteria, and Structures
The sixth and most recent draft of the IANA Bylaws, dated 6 November 1998, initially calls for the creation of three Supporting 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 Supporting Organizations.
During the first Domain Names 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 factors which interacted in subtle and complex ways, and that many of the participants had not had a chance to investigate these ideas in depth nor to develop a common approach to the issue.
The Approach Taken by this Paper
Our primary goal in writing this paper is 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 differing 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 do not pretend to have come up with anything close to a final proposal - much more discussion and review, and input from ICANN, will be required before we will be ready for that. Specific values indicated below are intended to be place-holders which show possibilities and orders of magnitude.
We first review ICANN principles and relevant sections from the ICANN Bylaws. We next review some useful concepts, clarify some important often-used terms. We follow that with a list of criteria which will guide the DNSOs choice of funding models. Using these sections as a guide, we then survey the costs to be incurred by ICANN, and consider for which of these fees might be charged. In the final section we review values enabled by ICANN, and consider possible fees for the allocation of those values.
We hope to discuss this subject and this document at length in Monterrey. This is a working document and we seek broad input.
Principles Identified in the 6th Iteration of the Bylaws
The Bylaws specify principles to be followed by 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.
Relevant Sections from the 6th Draft of the ICANN Bylaws
The following text, from the 6th Draft, refer directly to fees, budgeting, and related items.
ARTICLE IV: POWERS
Section 2. FEES AND CHARGES
The Board shall set fees and charges for the services, rights and benefits provided by the Corporation to the Supporting Organizations and others, with the goal of fully recovering the reasonable costs of the operation of the Corporation and establishing reasonable reserves for future expenses and contingencies reasonably related to the legitimate activities of the Corporation. Such fees and charges shall be fair and non-discriminatory, and shall be published on the Web Site in a sufficiently detailed manner so as to be readily accessible.
ARTICLE V: STRUCTURE OF THE BOARD OF DIRECTORS
Section 25. ANNUAL BUDGET
The Board shall prepare an annual budget, which shall be published on the Web Site.
ARTICLE VI: SUPPORTING ORGANIZATIONS
Section 3. DESCRIPTION AND QUALIFICATIONS
(b) The Board shall review an application for recognition as one of the Supporting Organizations referred to in Section 3(a) of this Article VI.... The application shall include, but not be limited to, a description of the following in form and substance acceptable to the Board (and a commitment to implement the matters described in the application):... (vi) methods for funding the Supporting Organization and providing funding for the Corporation (consistent with Article IV, Section 2 of these Bylaws).
Useful Concepts and Clarification of Terms
ICANN and Cost-Recovery
There is broad agreement in the Internet community that 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 (this does not apply to the accumulation of a substantial legal defense fund - see below). Rather than find a way to distribute any accumulating surplus, it is preferable to modfy fees so as to not exceed a reasonable surplus.
Cost vs. Price
One often finds the terms 'cost' and 'price' used interchangeably; a practice we don't follow. 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 a provider to create and deliver to a customer a particular item. Price, on the other hand, is whatever a customer pays to the provider 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.
Cost-Pricing vs. Value-Pricing
Pricing is guided 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).
General Fees vs Use Fees
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. 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 collected are inherently flexible: as the number of transactions (and use of resources) goes up, the amount of money collected usually rises.
The DNSO will likely require both general and use fees.
ICANN Budget Requirements, DNSO Responsibilities
ICANN has not yet published a budget. We assume $US 3 million per year for the first three years, based on input from a variety of participants. 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 be 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 has been some discussion regarding purchase of an insurance policy. Because this sort of insurance does not appear to be practically available, we assume that ICANN will require an actual cash fund.
There will probably also be short-term funding requirements as ICANN starts up. Since these have not yet been announced, and may come from other sources, we do not address them at length in this paper.
We assume that each of the Supporting Organizations will be responsible for 1/3 of the budget, or $1 million per year. For the legal fund, we assume that the majority of litigation will be oriented around names. We thus assume that somewhat over one half of the legal defense fund will be specified by the DNSO. We pick the relatively arbitrary value of $6,000,000. We also assume that this fund will be accumulated over three years ($2,000,000 per year).
Given expectations of the enormous size of emerging Internet commerce, measured in the billions of US dollars, this is not a large amount of money. Whatever difficulties arise in its collection will have little to do with the total amount required by ICANN.
Criteria for Domain Name -Related Funds Collection
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. The DNSO will need to find an appropriate balance between these criteria.
Enough funds must be collected to meet the operating requirements of ICANN. ICANN should not need to repeatedly return to the Supporting Organizations for additional funds.
Adaptability and Mutability
The ICANN budget will certainly change over time. For example, the collection of the legal defense fund 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.
No Price Distortion
Fees charged by ICANN to its Supporting 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 determining 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.
No Imbalance of Influence
It is critical that there be a diversity of funding so that ICANN will not be disproportionately influenced by one or more constituencies.
Low Transaction Costs
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. 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. The DNSO should be careful to preclude undue transaction costs.
Simplicity results in reduced costs and a greater ease in comprehension by consumers and the public.
Visibility and Accountability
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.
A Review of ICANN Internal Cost Structure
This section reviews the costs that will be incurred by ICANN. We briefly investigate if there are services directly related to these costs. Taking both of these into account, we ask if there are any obvious ways to charge for these services. Most of the details below regard the DNSO; we cite non-DNSO related areas primary to establish context.
We deliberately over-describe some of the following items in order to ensure that this section is as complete as possible. We foresee the following cost centers.
ICANN Overhead Costs
Central Administration Expenses (non-operational)
General Overhead (not associated with any particular SO)
- equipment (general and administrative), including leases,
- research and development,
- public awareness and education,
- staff salaries and expenses (e.g., travel)
- costs related to Board of Directors and Directors expenses
- office expenses (facilities, materials)
- general and administrative (management, accounting,
The vast majority of these activities will not result in specific services to any of the SOs and there will be no point of consumption at which fees could easily be charged. It will thus be necessary to collect funds to support general overhead by other means.
Supporting Organization-Specific Activities within ICANN
Some overhead costs occurring within ICANN may be attributable to specific Supporting Organizations. For example, there may be one liaison staffer per SO within ICANN. In this case it may be possible to have explicit charges to one SO or another. We need to know more about ICANN plans in this area. It may be possible and desirable to keep things simple and aggregate these costs and have a general fee to which each of the SOs will specify some other means of funds collection.
Supporting Organizations Internal Expenses
Each of the three SOs will generate some internal expenses. These costs will for example include the cost of meetings and secretariat functions. The separation of these costs from ICANN into the SOs depends upon whether or not the SOs will be financially and administratively separate from ICANN. This remains to be determined. These should probably be approached in the same manner as supporting-organization-specific activities within ICANN above.
- Legal overhead,
- Costs related to possible disputes regarding,
- IP addresses, and
- Domain Names, including:
- control of the domain system, and
- operation of the root server.
It might be possible for ICANN to charge the SOs directly for the cost of legal defenses again suits related to their respective areas. However, little is known about how about legal activities are eventually going to occur. We suspect that it will be most practical to view the vast majority of the above overheads as part of a general account, with fixed proportions associated with each of the SOs. Further investigation of this area needs to be done.
ICANN Operational Costs
ICANN operational costs will include:
- Administration of protocol-related documents,
- Administration of IP addresses, and
- Name-Related operations:
- Administration of the root zone,
- Operation of one or more root servers under direct ICANN administration,
- Coordination of other root servers, and
- Administration of escrowed registry data.
The Root Server System
The Root Server System (RSS) maintains the association between domain names and addresses. It primarily translates names into IP addresses, which may be then used to access desired resources. Secondarily, "reverse look up" translates IP addresses into domain names, and is most often used to ensure that a machine that originates a message is genuine. Reverse lookups may comprise 10-20% of all references.
There are four separate cost areas within the RSS:
- Cost of communications to update the RSS. This is negligible.
- Cost of storage and maintenance of the information stored in the RSS, including facilities overheads. This is on the order of $200,000 per year or less.
- Cost of communications for users to access the RSS, for both regular and reverse lookups. We guess that this will require at least multiple T3/E3 connections to start. This is significant and may be many hundreds of thousands of dollars.
- Facilties costs include conditioned space for computing equipment with security infrastructure, plus power, light, fire protection equipment.
At present, most of the root servers are run on a voluntary basis by a variety of organizations. It is not clear how root servers costs will be managed in the future. In this paper, only the costs of the servers that are directly run by ICANN (assigned to ICANN or temporarily in ICANN) or under contract with ICANN are taken into account.
ICANN may have a very interesting opportunity to save expenses for RSS connectivity. Having one of several duplicate root servers on their premises could be a major value to ISPs and facilities providers. If so, they may be willing to provide facilities and bandwidth without charge. In the extreme case it might even be possible to charge the ISP for locating a Root Server on their premises. If something like this is done, it will need to go out for competitive bid. This deserves further investigation.
If the root servers were referenced every time a name-number association was requested, it might be possible to have a related transaction fee. However, this does not occur because IP addresses are cached by name servers on individual networks. Hence the load on the RSS is not proportional to the number of times that a domain is sought; there is no clear linkage between use of names and load on the RSS. As a result, it will be exceedingly difficult to levy an economically sensible transaction fee for each lookup. It might be possible to develop technology to track such transactions in the future, but this is not available in the foreseeable future and it does not appear practical in general.
Values Created by ICANN and Possible Fees
In the previous section we determined a broad range of ICANN costs, but were not able to determine any services for which a charge could be levied per transaction. In this section we consider the major values enabled by ICANN and how they could be used to collect funds. There are at least two such values:
- Registry Delegations, and the resulting
- Domain Name Allocations.
In each of these, we do not consider the role of the Registrars. At this time we believe most Registrar-related issues can be initiated by the Registries.
ICANN delegates to each TLD Registry the right to add SLDs to its database, and to permit other parties to enter additional Third-Level Domains to their databases and so on. Each Registry is able to register names which overall represent a large amount of potential commerce.
Each Registry could be charged some fixed amount which would go toward paying for ICANN and SO costs. At present there are about 200 TLDs. If each were charged, for example, $10,000, that would total $2million per year. It would be up to each TLD registry to determine how they wish to collect these funds. ICANN, recognizing that some TLD registries may just be starting up, or may be in countries with very difficult economic circumstances, may wish to have a "developing countries" fund, which would permit them to temporarily reduce the amount charged particular Registries.
Significant further discussion on this subject is in order. The DNSO may wish to have the Registries collectively agree on a model for collecting some total amount of funds, subject to some to-be-determined set of constraints.
Domain Name Allocation
The other values enabled by ICANN are the N-ary domain names: second-level, third-level, fourth-level, and so on. It may be possible for there to be an annual fee for each domain name in the registry. Since there are on the very roughly three million second-level domain names, even a small annual fee of $1 per name per year, could yield a considerable sum. Since it is expected that the global number of domain names will continue to rise, the cost per domain name could go down steadily each year.
Unfortunately, this is not a completely straightforward issue.
Some registries, such as in the UK, register a very small number of Second-Level Domain names, using the SLDs a major sector indicators and using the third-level domain names as the primary 'retail' level. In other cases, some registries might choose to register a large number of SLDs, and to also develop relations with distributors. These distributors could register Third-Level Domain names into some set of Second-Level domains.
This may be solved by requiring a payment of an annual fee for all domain names which are allocated at the 'retail' level. This could take care of both the UK and the 'distributor' models. There are certainly possible problems with this approach.
A Quick Calculation of Sums
Using our very rough examples above, ICANN could collect $2 million from the per-registry fee, and $3 million (in 1999) in domain name fees, for an overall total of $5 million. This would readily cover the DNSO-designated share of funding ($2 million), and leave $3 million available as a sizable first-year contribution to the ICANN legal fund.
Each of these name-related fees could be collected by the registries, would be easily calculated from existing data on-hand in the registries, and should have reasonably low associated accounting and payment costs. Considerable additional discussion of alternatives, and further development of the details of this approach are required before the DNSO will be able to make a recommendation to the ICANN Board.