Because SOs will be making recommendations to ICANN, it seems like there
would be a possible conflict of interest if the SOs were also funding ICANN.
Chuck Gomes
> -----Original Message-----
> From: Glenn Kowack [SMTP:gkowack@well.com]
> Sent: Sunday, November 15, 1998 3:13 AM
> To: DNSO
> Subject: DNSO / ICANN Funding Model Paper, Version 0.1
>
> DNSO,
> 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.
>
> -Glenn Kowack
>
>
> _______
>
>
>
>
>
>
>
> Considerations for a Funding Model for the Domain Name Supporting
> Organization
>
> Challenges, Criteria, and Structures
>
> Version 0.1
>
> Glenn Kowack
> Javier Sola
> Kent Crispin
>
>
>
>
> General Background
>
> 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 VISSS..S.. 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):SSS..SS. (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.
>
> Sufficiency
> 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
> 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.
>
> Consistency
> 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,
> secretarial).
>
> 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 Expenses
> - Legal overhead,
> - Costs related to possible disputes regarding,
> - Protocols,
> - 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.
>
> Registry Delegation
>
> 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.
>
> General Considerations
>
> 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.
>
>
> __end << File: DNSOFundingV01.doc >>