RE: DNSO / ICANN Funding Model Paper, Version 0.1

["Gomes, Chuck" <cgomes@internic.net>]

Why should SOs be concerned with ICANN funding?  SOs should be concerned
with self-funding their own activities while ICANN should be concerned with
funding its activities.  It seems to me that ICANN will enter into
contractual relationships with registries (name and number) and will
establish funding through those relationships.

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 >>