Governing the Internet, A Functional Approach

Author: Karl Auerbach, former North American publicly elected Director, ICANN

This paper is based on my previous submission to this workshop, a paper
entitled Deconstructing Internet Governance. In that paper I suggested that we
may find it useful to consider governance of the internet not as a single
undifferentiated issue, but rather as a collection of distinct and separate
functions amenable to different treatment according to the particular
circumstances of each.

I would like to suggest that we approach the question of
internet governance by adopting two proven rules of successful design:

The first of these rules comes from Louis Sullivan, one of the great
architects of the 19th century. Sullivan articulated the
principle that "form follows function."

The second of these rules comes from Niklaus Wirth.
Wirth brought to the art of computer programming the concept of
information hiding and modularity. Wirth articulated the idea that
to be a well designed program each module must cleanly encapsulate its
mechanisms and its data; and the relationships and interactions between
modules must be precisely identified. In addition, the whole
structure must be organized to minimize the information and control flows
between modules.

The thesis of this paper is that an appropriate way to structure
internet governance is to create distinct bodies that each deal only with a
single administrative or policymaking task.

This paper begins by looking at those aspects of the internet
that require governance. Those aspects are examined to ascertain which
functions are structured and have little need for the exercise of discretion and
which functions require greater freedom of decision and action. From this
a modular structure of governance bodies is articulated.

Pitfalls and Myths

Our first experiment in internet governance, ICANN, has shown us
that we need to clearly comprehend the nature of what we are trying to do.
In this section I list a few lessons that we have learned from ICANN.

First caveat: It is worthwhile to take note of the
problems that have occurred within ICANN as a result of the concepts of
"consensus" and "stakeholder". Both of these are very
vague terms and readily lead to situations in which power struggles occur not
through reasoned debate but through manipulation and selection. Any new
structures of governance that are created ought to use counted systems of votes
rather than "consensus" and should allow participants to freely
associate with points of view rather than be pre-classified as members of this
or that group of "stakeholders".

Second caveat: If there is anything that we have learned
from ICANN it is that electronic communications undiluted by face-to-face
meetings are poor vehicles for debate and discussion. Without adequate
face-to-face contact the kind of mutual respect of participants for one-another
does not mature, thus making it far too easy for participants to be dismissive or
rude. Moreover the nature of electronic communications amplifies small
differences and makes compromise difficult. Occasional face-to-face
interaction is time consuming and expensive, but necessary. I am of the
firm belief that we must not base internet governance exclusively on electronic
communications. Real gatherings in real places are required.
Otherwise we may see yet another round of failed attempts at internet
governance.

Third caveat: The phrase "public private
partnership" has often been used in conjunction with internet governance.
I have strong personal reservations about this concept because it implies the
transfer of governmental powers (often ultra vires powers) into the hands of private actors without
simultaneously imposing the obligations of due process, oversight, and accountability that are
hallmarks of modern governments. In addition, no matter whether a
governance body is private, public, or a blend, its role must be carefully
defined and constrained lest it be captured by those it purports to oversee or
by others who find the body to be a means to promote a private agenda. We
have seen all of these problems arise within ICANN.

Fourth caveat: There is a myth that ICANN engages only in
technical matters. In actuality, ICANN does nearly nothing that can claim
to have more than the most tenuous relationship to technical issues. ICANN
has spent its existence promoting the agenda of certain selected commercial
interests, primarily interests found in the United States and Europe, and has
avoided engaging in matters that actually deal with, much less promote, the
technical stability of the internet. There are those who say that ICANN
"administers, coordinates, and allocates IP addresses". ICANN
does not do this. There are those who say that ICANN "administers and
coordinates the root server system." ICANN does not do this.
There are those who claim that ICANN's job of "promoting competition within
the generic top-level domain space" is a matter of technical
coordination. As a technologist I find that disingenuous. And
ICANN's creation of a worldwide domain name dispute policy has no technical
component whatsoever and represents a clear case of supranational lawmaking on
matters of economic and business policy.

Fifth caveat: Governance of the internet does, in
fact, require us to deal with matters that go beyond the merely technical.
This is to say that governance of the internet is governance in the whole
meaning of that word. Governance is an exercise in plenary power. We
should not delude ourselves to believe that the presence of the word
"internet" in any way reduces or eliminates the risks and dangers of
such power. It is critical that the power of internet governance be
limited and constrained in exactly the same ways that any other governmental
power are limited and constrained. Governance should be structured to
divide power, not concentrate it. Tensions must be built into the system
so that ambition counters ambition. Internet governance structures must be
subject to oversight and review; they must be open to all who feel affected by
the matters being governed. Internet governance structures must be built
upon and be responsible to the community of internet users with no more than one
level of representation between the members of that community and those who have
been entrusted with using these powers of governance.

Sixth caveat: The issues that face the internet and the
world today reflect a change in the concept of national sovereignty. We
are observing the development of a system, the internet, that erodes national sovereignty.
Those lost powers do not disappear; they are flowing into private hands, into
Quasi Non-Governmental Organizations (Quangos), and into institutions of
internet governance. We have much to learn. We will make many
mistakes. We may find it useful at this time to encourage local and
national experimentation in order to learn what works and what does not before
we try to create new worldwide institutions based on untried assumptions and
untried mechanisms.

A disclaimer: This paper does not directly address
the always present, but rarely asked question: Who is watching the
watchman? By this I mean, in whom or in what is the ultimate power over
the internet vested? My own personal feeling is that this power should be
vested in the community of internet users as individual persons. There are
others who believe that the community of internet users is best represented via
their respective governments. And there are yet others who argue that only
"stakeholders" (whatever that might mean) ought to have
authority. In this paper I deal with those matters of the internet that
require oversight and with the nature of the body that could exercise that
oversight. In this paper I am not directly dealing with the question of
who or what will populate those oversight bodies or to whom those bodies may be
called to make an account of their actions and behavior. Although I am not
dealing with this question in this paper, I believe that this question is a
significant one that should be squarely addressed.

Tailoring the Mode of Governance To The Matter Needing To Be
Governed

This paper emphasizes the distinction between functions that
involve the exercise of discretion and those that do not. Functions that
involve only limited or constrained exercises of discretion will require
relatively simple oversight and governance Functions that involve
significant amounts of discretionary freedom will require more complex
mechanisms of oversight and governance.

For those functions in which discretion is extremely limited and
the consequences of abuse of that discretion are limited, oversight might be
achieved simply by a publish-then-challenge system. Notice of
actions would be published after the fact. For some period after publication
those who feel that the decision is wrong could come forth and challenge that
decision.

For those functions in which discretion does exist but its scope
is limited, a notice-and-comment system might be appropriate.
Notice of a proposed decision would be published to the public in a well known
and readily accessible place (for example, on the world-wide-web), comments
would be invited, after a reasonable interval those comments would be
considered, then a final decision based on those comments would be
published. Notice and comment systems usually have some means of external
oversight and review mechanisms to handle those extraordinary situations in
which the exercise of discretion is arbitrary or capricious, or in which the
discretion is exercised without adherence to proper procedures.

In both publish-then-challenge and notice-and-comment it is
necessary that challenges and comments be considered without prejudice and the decision maker
must be able to demonstrate that such submissions have actually been
reviewed and considered.

For those functions that require a greater exercise of
discretion or where the public impact is significant, more intricate systems of
governance would be required. For example, the creation of policy
regarding the Domain Name system requires that all potentially affected parties
have the right to participate in the debate and policy decision as peers with
other parties.

What Are The Aspects of the Internet That Require Governance?

In my prior paper I described five aspects of the internet that might be
subjects of governance:

A system of IP address allocation that meshes well with the IP packet
routing systems. (Note: in this paper, I am referring only to unicast
IP addresses. There are other forms of IP addresses, such as multicast IP addresses, that are outside the scope of this paper.)

A system of inter-carrier/inter-ISP traffic exchange in which end users
can obtain usable assurances that designated traffic flows will achieve
specified levels of service. (Note that I am using the word
"assurance". I use this word to mean something less than a
hard "guarantee.")

A system of allocation of protocol numbers and other similar identifiers.

The responsible and accountable oversight of a suite of Domain Name
System ( DNS) root servers.

The management of the DNS root zone file, including the clerical task of
preparing the root zone file for distribution to the root servers and the task of developing and applying policies to determine which
new top-level domains will be allowed entry into the root zone.

Defining Specific Functions That Require Governance

In this section I examine the five aspects mentioned above and
dissect them to reveal the specific functions or tasks that need to be
performed. For each of these functions I will examine the degree of
discretion that is required and suggest how that function might best be
supervised.

IP Address Allocation

Formulation of policies for IP
address allocation

Evaluation: This is a job that appears at first glance to
be highly arcane and technical. However, the decisions that are made
have broad impact not only in a technical sense but also in an economic
sense. In many regards, countries and institutions that can obtain IP
address allocations have a stronger competitive position vis-à-vis other
countries and institutions that can not obtain such allocations. Many of the decisions regarding IP address
allocation are made today with only implicit assumptions about the impact of
those decisions, and that impact is often measured only with regard to its
effects on ISPs and vendors of packet routing equipment rather than on the
general community of internet users.

It is likely that if all
ramifications were considered the cumulative
effect of IP address allocation policies could dwarf those of policies
regarding the domain name system.

As I mentioned in my prior paper,
the matter of policy for IP address allocation is unlikely to remain
insulated from debate over allocation policies. It is likely that the
creation of IP address allocation policies may require more governance
oversight in the future than they require today.

Although the
creation of IP address policy has many social and economic side effects, it
is likely that few apart from ISPs, large consumers of IP address
space, or router manufacturers would take the time and effort to be
involved. Consequently, the policymaking apparatus presently used by
the Regional IP Address Registries (RIRs such as APNIC, ARIN, RIPE, LACNIC)
could be continued and left undisturbed until such time as difficulties
arise. Such an approach, however, implies that this matter would have
to be reviewed periodically by some body in order to ascertain whether such difficulties have in-fact occurred and that some
more intricate system of governance
is required.

Costs: Today the cost of
policymaking by the RIRs is covered through fees charged by those to whom IP
addresses are allocated.

Conclusion: Leave this function governed by the
existing RIR mechanisms but come back and review the situation periodically
(e.g. yearly or bi-yearly.)

Allocation of large IPv4 and
IPv6 address blocks

Evaluation: This is the
mechanical job of putting IP address allocation policies into effect.
Today there is a multi-tier system. At the top is IANA which makes
very large allocations to the Regional IP Address Registries (RIRs).
The RIRs, in turn, allocate to large users (ISPs, countries, educational
bodies, corporations). Further levels of allocation occur as
necessary. Occasionally some allocations are made directly by IANA
without going through the RIR hierarchy (for example, ICANN has allocated
address space to itself without going through the RIR system.)

Depending on
the specificity of the overall IP allocation policies, the task of
administering those policies can be
relatively predictable with only a low degree of administrative
discretion. Because of the scope of impact of address decisions it
might be tempting to adopt a notice-and-comment system. However,
address allocation is often a matter in which time is of the essence and for
that reason a publish-then-challenge system might be most appropriate.

Costs: Today the cost of
allocations by the RIRs is covered through fees charged by those to whom IP
addresses are allocated.

Conclusion: Leave this function governed by the
existing RIR mechanisms.

Maintenance of the top level of the in-addr.arpa (and
it's IPv6 equivalent) DNS zone

Evaluation: In-addr.arpa is used for
address-to-name mapping. At every tier in the hierarchy of IP address
allocation it is necessary to build appropriate entries into the in-addr.arpa
DNS hierarchy. This job is usually done by the body or person who is
doing the address delegation. At the upper levels this is done by the
RIRs and at the lower levels by the entities or people to whom address
blocks have been delegated.

This task is essentially clerical.
A publish-then-challenge system would be appropriate for allocations
by the RIRs. No governance system ought to be imposed upon the lower
tiers.

Because this this task is entwined with the allocation of
address blocks by the RIRs it may be convenient to bundle this task with that of address
allocation by the RIRs.

Costs: Today the cost of
maintaining the upper tier of in-addr.arpa is borne by the RIRs through the
fees charged to whom IP addresses are allocated.

Conclusion: Leave this function governed by the
existing RIR mechanisms.

Availability of Usable End-to-End Routing and Levels of Service

This is an area that has not been widely discussed. As I
mentioned in my previous paper the internet is composed of carriers and ISPs who
are often jealous and suspicious of one another. It is to be expected that
ISPs and carriers will oppose any attempt to impose governance on the matters of packet routing, packet
filtering, and inter-carrier recognition of end-to-end level-of-service
obligations.

Because this is a new area, and one that is
likely to cause a strong reaction from carriers and ISPs I will not try to give
more detailed descriptions of the tasks to be performed. However, it is
clear to me that there will be areas that involve significant exercise of
discretion and require the balancing of many competing technical and economic
and social issues. In addition, the impact of these balances will be broad
and could easily determine the fate of entire industries, such as
Voice-over-IP. For this reason, I anticipate that the governance
structures that will be required here will need to be particularly intricate and
could end up resembling the structure that supervises the
connectivity and end-to-end quality of the world's voice telephone networks.

Allocation of Protocol Numbers and Other Similar Identifiers

Assign and record protocol numbers and other such values
as specified by standards bodies

Evaluation: For standards issued by the IETF,
performance of this job
requires a loose coordination with the IETF in order to properly process the
"IANA Considerations" of those RFCs that contain them and to
handle those situations in which such RFC guidance is absent. Similar
coordination is to be expected with regard to documents issued by other
standards bodies.

This function is essentially clerical and
performed on behalf of standards bodies, mainly the IETF. The review
systems that are intrinsic to standards organizations are an appropriate
mode of governance.

Costs: The total cost of
this function is very low - it cumulates to at most a job for a single
person. The costs of this system ought to be borne
by those standards bodies that use it, most notably the IETF.

Conclusion: The IETF and other standards bodies
should subsume this task at their own expense.

Responsible and Accountable Oversight of DNS Root Servers

Oversight of Root Server
operations

Body Title: Root Services
Oversight Board

Evaluation: In many
respects we should honor the cliché "if it isn't broken, don't fix
it". The root server system runs very well today and, if we were
looking only at today, it clearly is not broken. The problem, however,
is not today but tomorrow. The issue, as I see it, is how to create a
layer of oversight that gives the community of
internet users firm confidence in the future while otherwise having minimal
impact on a system that already works.

DNS root servers must be operated with care and
skill. A kind of mysticism has grown up around the root server
operators that they are possessed of a unique wizardry and could not be
replaced. In truth, however, it is not a job that is significantly
different in quality or kind from that of operating any high-availability
worldwide database service. Expertise is required, but that
expertise is not unique. There are many people and groups around
the world who would be competent to run DNS root servers and who would be
both willing and able to enter into stringent operations contracts in return for a reasonable
operations fee.

Today the DNS root servers are coordinated via the loose federation of entities and individuals
listed at http://root-servers.org/.
These entities and individuals have done a superlative job.

RFC 2870[1]
sets out a reasonable set of operational requirements for DNS root
servers. But that RFC is neither binding nor complete.

Today there is
an oversight vacuum. There is no body that is establishing standards
of operation. Nor is there any body that can require adherence to such
standards were such standards to exist. The only oversight that does
exist is through local corporate boards, university trustees, and the United
States military. These local oversight bodies are subject to competing
goals, changeable priorities, and shifting resources. Few of these
bodies are obligated to continue to offer DNS root server services;
few of these bodies are obligated to offer such services on a fair and
impartial basis. None of these bodies is in any way accountable to the
community of internet users or the governments that represent them.
This vacuum suggests that it will be necessary to
create an oversight body or to invest that function into an existing body.

ICANN has explicitly disclaimed
that it has or desires such an
oversight role.

The Root Services Oversight Board
proposed here would fill that vacuum. The Board would enter into contracts
with those who actually operate root servers. Such contracts would
specify technical standards, service levels, and other obligations
regarding security, physical infrastructure, and disaster recovery
plans. I would anticipate such a contract would for the most part
reify and extend RFC2870.

There are real
costs that the root server operators incur. There is no easily
available accounting to
indicate the level of these costs.[2] However
those costs cumulate
into the millions of dollars (USD) per year. Any system of governance
ought to consider how these costs are to be borne. The stability of
this critical part of internet infrastructure should not depend on voluntary
donations of time, equipment, offices, connectivity, money, or people.

As for the type of governance
that should be exercised by that Root Services Oversight Board: There is a
fair degree of discretion regarding the establishment of the service levels
that the root operators must meet. However, the issues are largely
technical. A notice-and-comment system would be appropriate.

Costs: The Root Services
Oversight Board would incur meeting costs while it established operating
standards. However, once those standards have been established, the
ongoing costs would be relatively small. However, somewhere, either
via the Board or via the root server operators themselves, the cost of
actual operations will have to be recognized and handled.

Conclusion: A supervisory body, what I call the
Root Services Oversight Board, must be created or designated. This
body should not simply be a reincarnation of ICANN's Root Server Advisory
Committee; it should instead contain elements not affiliated with incumbent
operators that fully represent the interest of the community in the stable
provision of root server services into the future.

This Root Services Oversight Board must create operations standards and enter into
clearly binding legal agreements, not "Memorandums of Understanding" of
questionable enforceability, with the operators of root servers. The
creation of operations standards can be controlled through a notice-and-comment
system. This supervisory body must itself be accountable to
governments and the community of internet users so that it may itself be
compelled to take its oversight duties and powers seriously.

DNS Root Zone Management

DNS root zone management consists of a number of distinct
tasks. Many of these are clerical tasks in which instructions received
from other bodies are processed according to predefined procedures. I have
structured this section to distinguish between those tasks that are clerical and
those that involve the balancing of equities. My conception is that the
latter give instructions to the former.

In this section I posit the existence of several entities or
roles:

A DNS Root Zone Administrator to oversee the periodic
preparation and dissemination of a DNS root zone file.

A ccTLD Policy Organization to promulgate appropriate
procedures, perhaps derived from those in RFC1591, for the DNS Root Zone Administrator with respect to
ccTLDs. This ccTLD Policy Organization would issue directives to the Root Administrator to create or remove
ccTLDs.

A gTLD Policy Organization to promulgate procedures for the
DNS Root Zone Administrator with respect to gTLDs. This gTLD Policy Organization
would issue directives to the Root Administrator to create or remove gTLDs.

Maintain and publish the zone
file that defines the contents of the DNS root

Body Title: Root Zone
Administrator

Evaluation: The root zone
file is a relatively small text file that lists the names of each top level
domain as well as the IP addresses of the name servers for each of those
domains.

Root Zone Administration primarily involves maintenance in that file of the Name Server (NS) records that indicate which DNS servers
handle a particular top level domain (TLD). This is essentially a clerical
job to be performed according to instructions from
the entity or person who has the authority over each TLD.

The Root Zone Administer will
receive instruction from the various TLD Policy Organizations regarding who
or what is the entity or person who has the authority over each TLD.

On occasion an entirely new TLD
would be added. (It is possible that an old TLD might be removed, but that has
never occurred.) This is also a clerical job that would be performed
according to instructions from the particular Policy Organization that has
the duty of deciding such things.

The
root zone file affects the entire internet. Preparation of that file, while not a complex task and not one
involving large amounts of data, is one that does require care and a large
amount of double and cross checking to protect against human, procedural, or
technical errors.

The data in the root zone file is
a highly focused point of control over the internet. For example, a
small change could cause an entire country to disappear from the internet or
its internet presence be transferred. This sensitivity requires that
the clerical job be well protected from manipulation and be made immune to
political or economic pressures.

At the present time this job is
done daily by Verisign. ICANN has indicated it would like to take over
this job.

The Root Zone Administrator
performs what is essentially
a highly sensitive clerical task. The governance that is required for this task is that
of ensuring that it is performed by competent people and to performed
according to well defined and appropriate procedures. Those procedures should be published so that
those who wish to suggest improvements may do so.

It could make sense to let
Verisign continue this job as they have proven competence in this
regard. Or ICANN, which has never itself had such an operational role,
could take it over. Or the job could be moved to some other
body. In any case, the question remains: What is to be the entity that
actually selects and appoints the Root Zone Administrator and pays the costs. To date this has
been handled via Memorandums of Understanding, Cooperative Agreements, and
simple purchase orders from the United States Department of
Commerce. Because of the latent power that is implicit in this
relationship, there is a legitimate concern among nations that this system
gives the United States unwarranted control.

Costs: The root zone file
contains roughly 250 names. The name server data associated with each
of these names is updated occasionally - once per year is a reasonable
metric. The rate at which new TLDs are added is virtually nil
(although I hope this situation changes.) The amount of effort to handle these updates aggregates to no
more than a few hours per week, plus whatever overhead is required to ensure
that the entity requesting the change is, in fact, who it purports to
be. Software tools exist to do much of the content and form checking.

Conclusion: Some internationally accepted body
must be charged to establish and fund a Root Zone Administrator. This
job is largely clerical and lacks discretionary authority; errors of
malfeasance would be noticed fairly quickly by the internet community.
For this reason, there is no need to include a large public presence in the
oversight body. A publish-then-contest type of process would be
appropriate.

To define and apply the rules to
establish, remove, or transfer ccTLDs

Body Title: ccTLD Policy
Organization

The ccTLD PO focuses on the needs and issues of concern to those
who provide and use ccTLDs.

Under ICANN this has proven to be
a troublesome area. There is a degree of uncertainty regarding the
nature of ccTLDs: are they aspects of a sovereign country or are they simply
database keys that coincidentally reflect (somewhat inaccurately) the existence
of countries?

The approach taken here is to
establish a governance body that will wrestle with the conception of ccTLDs.
This body will define the rules to be used to recognize the appropriate
administrator for a ccTLD as well as other rules regarding the maintenance
and transfer of ccTLDs. Because it is anticipated that the application
of these rules will require a special degree of sensitivity, this body will also
administer its own rules.

The output of this body will be
instructions to the Root Zone Administrator that identify who or what is the
entity that has control of a each ccTLD.

This Policy Organization will be responsible for the creation of
policies to decide when new ccTLDs should be created, old ones removed, and how
transfers of control of ccTLDs should be accomplished.

Costs: It is to be
anticipated that during the first years of existence that this policy body
will have to meet frequently. However, after the major policies have
been adopted, the ongoing costs will probably be quite low.

Evaluation: ICANN's
ccNSO might be an
appropriate body to assume this role.

Conclusion: A ccTLD Policy Organization should
be designated. ICANN's existing ccNSO could be considered.
Because ccTLDs are so closely tied to the existence of sovereign countries
it is likely that the primary interest in ccTLD issues will come from
national representatives and from those who operate ccTLDs. However,
allowance should be made to include those representing the views of the
internet community to be part of these decisions. This body will
require a relatively complex decision making process in which there is
adequate time for all points of view to be raised, discussed, and
considered. ICANN's ccNSO may already be evolving appropriate
mechanisms in this regard.

To define and apply the rules to
establish, remove, or transfer gTLDs

Body Title: gTLD Policy
Organization

Evaluation: ICANN has tried to perform this
task. However, even after 5 years it has created no coherent policy in
these matters beyond the creation of extraordinary rules that reflect two, non-technical policy choices:
1) A strong bias in favor of intellectual property protection over other uses
of names. 2) The protection of incumbent gTLD operators by making it
virtually impossible for newcomers to join the club.

Although it is possible to make the creation of new gTLDs a
rather mechanical function[3], this issue has become one filled with emotion and is
quite contentious. Consequently, this plan places the responsibility for
decisions regarding gTLD creation into the gTLD Policy Organization, which will
issue directives to the DNS Root Zone Administrator so that the latter may make those
directives manifest in the root zone.

I would, however, like to point out that from a technical
point of view the root zone has a lot of room available for growth.
Today that zone contains less than 300 TLDs total, of which only a few are
gTLDs. It could easily accommodate hundreds of thousands, and perhaps
even millions of TLDs.[4] The impact of
this growth would not so much be on the servers themselves as on the human
procedures and the time required to transfer and load updates. Because
of the tremendous gap between the numbers of TLDs found today and the
numbers of TLDs that are possible, we ought to drop the pretense that TLDs
are a scarce and precious resource that must to be stewarded so carefully
that the rate of increase under ICANN's administration has amounted to only
about one per year. Under the existing regime, the policies regarding
new gTLDs are based not on technical concerns but rather with business and
economic positions designed to preserve the status quo of the few incumbents
and to protect one industry at the expense of other interests. We must
be careful that revised or new governance structures serve the broader
public interest and not merely the goals of a few.

Note that I have identified this task as a separate item from
that of defining the registration rules within a gTLD once that gTLD is
established.

ICANN gTLD policies and ICANN's
gTLD body (GNSO) have ossified over the years into a Byzantine maze that protects incumbents and intellectual property. It is unlikely
that ICANN's gTLD structures can be rewoven by any means less subtle than
the Alexandrian approach to the Gordian Knot, in other words, radical
restructuring.

Costs: ICANN has
incurred enormous "costs" in this area. The "cost"
of evaluating the 47 applications in year 2000 amounted to in excess of
$2,300,000(USD). However, this "cost" was largely for items
that are utterly irrelevant to the question of technical competency to run a
TLD. In other words, ICANN's experience is of no use in ascertaining
what the real cost of developing and applying gTLD selection policies would
be if those policies were be concerned with technical competence rather than
used as
vehicles to protect selected business interests.

Conclusion: A new entity should be created for
this task. ICANN's GNSO and ICANN itself are too heavily burdened with past
errors to be recycled.

This new entity must be driven by the interest of the
community of internet users, not by selected business interests and incumbent
DNS providers.

To define rules pertaining to the registration of domain
names within gTLDs

Body Title: Registration Policy
Organization

Evaluation: It is the belief of the author of this note that
internet governance of DNS
ought not to include things that are more properly within the sphere of
established legislative and judicial bodies. For that reason I would argue
that matters that involve the creation of supra-national laws, such as the UDRP
and the quasi-judicial system that accompanies it, are not appropriately
within the scope of the kinds of internet governance bodies we are
discussing here.

Because DNS is an easy means for certain interests to
exercise a great deal of worldwide control for a relatively tiny expense
there will be great pressure for this Policy Organization to
engage in policy making about things that go beyond how the DNS root zone should be managed.

It is recommended here that the Registration Policy
Organization have explicit limitations in its organic documents. This
may help constrain the degree to which it may engage in what amounts to
internet lawmaking. Its ability to adopt policies regarding business
practices should be similarly constrained except for those needed to ensure
that any failed DNS registrar or registry maintains enough recoverable
assets and information so that a successor may pick up the pieces and resume
services to the customers of the failed entity.

Areas that are appropriate for this body to consider would
be the measures to protect registrants in the face of registry or registrar
failures, the degree of privacy protection to be afforded to the data
disclosed by those who acquire a domain name, policies regarding grace periods
to recover a name should there be an inadvertent failure to renew the
name, policies regarding transfers of names, etc. Many of these
policies have been discussed under ICANN's GNSO and its predecessor the DNSO,
for that reason, it may be possible to construct the Registration Policy
Organization using parts of ICANN's GNSO. However, as was mentioned
previously, that organization may be too burdened and compromised by its
past.

Costs: The best
estimate that can be made regarding costs is to examine some of the more
recent "Policy Development Processes" that have been undertaken
within ICANN. Because much of the cost is borne by the individual
participants it is not possible to make meaningful estimates.

Conclusion: A Registration Policy Organization
should be established. It may make sense to build upon the policy
development apparatus of ICANN's GNSO. However, that apparatus would
require significant overhaul to eliminate the structural biases created
through the excessive use of "consensus" and "stakeholder"
concepts as
building blocks. In addition, representatives of the internet
community ought to have at least a parity seat at the decision-making
table.

To define the rules to establish,
remove, transfer, and maintain infrastructure TLDs (such as .arpa or .int.):

Body Title: Infrastructure
TLD Policy Body

Evaluation: There are
infrastructure TLDs. The most widely used is .arpa (usually in
the form of in-addr.arpa for address-to-name lookups). The .int
infrastructure TLD also exists and has been put to various uses.

Infrastructure uses are usually
tied to internet standards and operations - it is unlikely that any
matter would be contentious. Businesses and members of the internet
community of internet users are chiefly concerned that the internet is
managed competently. For that reason it may be easiest to simply join
this task with the previously discussed task of assigning and recording protocol
numbers specified by standards bodies.

There has been discussion of
reusing the .int TLD for use by international bodies. This
paper takes no position on that question.

Costs: This should be
a relatively low cost task.

Conclusion: There is
no reason to agonize about the details of how this function is to be
handled, particularly if the IETF and other standards bodies are willing to
allow this to be subsumed into the task of assigning and recording protocol
numbers.

Legal Structures, Degrees of Separation, Open Communications

To the greatest extent reasonable, each governance body
described above ought to be entirely distinct and separate. Each such body
ought to be embedded in a distinct legal structure. There ought to be no shared
trustees, directors, managers, employees, or funding.

All communications within and between governance bodies must be in writing and be
posted for public viewing on the internet at or before the time the
communication is made.

[2] While I was on the Board of Directors of ICANN
I tried to isolate the costs associated with the operation of the IANA root
server. The accounting records were, unfortunately, inadequately
detailed. It was clear, however, that the total aggregated to a
non-trivial amount and, because ICANN was establishing a more powerful system at
a physically better location, the cost was rising.

[4] Two or three years ago I participated in an
ad hoc experiment to see what would happen if a root server were to contain
several millions of TLDs. We took the then available .com zone and
elevated it so that nearly every .com name became a TLD. We then ran a
synthetic query load. This was done on equipment that would be considered
grossly underpowered by today's standards. And, after we added enough
memory to the computer, it worked. These were, of course, laboratory
conditions, not subject to the rigors that a real root server would have to endure.
And we only measured response times and not the increased administrative
burden. The conclusion I would like to suggest is threefold: First:
There is not some clear hard upper boundary on the number of TLDs, but rather a
soft area in which administrative concerns may provide back pressure against
TLD growth, not intrinsic software or hardware limits. Second: The
limit, wherever it is, is not sufficient to grant a TLD to everyone who might
possibly ask; it is clear that some system of allocation of new TLDs is
necessary. Third: even if we were to create 10 new TLDs per day, it is
unlikely that even after 100 years that we would reach a number of TLDs that was
administratively problematic, even on today's hardware.