Chuck Gomes
Vice President, Customer Programs
Network Solutions, Inc.
January 12, 1999
NSI Views regarding formation and ICANN recognition of a
Domain Name Supporting Organization
Some general principles should be kept in mind as we develop
and evaluate an application for recognition of a DNSO.
The Basics
* DNSO is not an operational entity. It only recommends
policies. (Note: DNSO will not operate the root servers. It
has no need to enter into contracts. It will instead serve
as a forum for discussion and debate among those with a
stake in domain name policy.)
* DNSO does not decide on policies -- it makes a record.
Insofar as the ICANN board is (and should be) looking for
help in determining where there is substantial consensus on
proposed policies and standards, then the job of the DNSO is
to seek to facilitate and report on such instances of
consensus.
* The DNSO is required to be open to all interested parties
and to avoid capture. In this context, zero-sum gaming and
jockeying for seats on a decision-making DNSO board (or Name
Council) makes no sense.
* Enforcement of ICANN policies must come from the
registries. Even if the ICANN board decided to adopt
recommendations coming from the DNSO, those "policies" would
have operational effect only by means of contractual
commitments between ICANN and the registries. It follows
that policies recommended by the DNSO should be supported by
most registries.
Major consequences of these basic principles for the DNSO
organizational effort:
1. Consensus and Reporting, not top-down majority voting by
representatives.
Any organizational document should make clear that the Name
Council has the task of (1) facilitating a consensus
building process and (2) reporting fully on the discussions
of any particular policy proposal, forwarding to ICANN only
those proposals that have achieved substantial consensus
support from the membership as a whole (rather than simply
deciding on policy recommendations by majority vote within
the Council).
As long as recommendations are considered to come from the
Name Council, rather than from the members of the DNSO as a
whole, there will be intense pressure from various
constituencies to gain (or indirectly control) a maximum
number of seats on the NC. There may be some need for
central facilitation of a consensus-building process, but
there is no need to create a Name Council that itself
decides what to recommend to ICANN. It could, instead, frame
questions and schedule hearings and administer the delivery
to ICANN of the records of these deliberations among
members. It could assist ICANN by highlighting areas of
agreement and explaining areas of disagreement or
alternative options. Once the Names Council is considered to
be an administrative and coordinating function, it no longer
needs to achieve a perfect "balance" of constantly shifting
constituencies -- it needs only to be adequately diverse and
responsive to the needs of the members who are deliberating
to find a policy consensus.
2. The Need for a Pre-Recommendation Enforceability Review.
Recommended policies cannot be enforced broadly or equitably
unless registries that contract with ICANN will agree to be
bound by these policies (and to pass such obligations down
by contract to registrars and registrants where
appropriate). To avoid wasted effort, the organizing
document should create a pre-proposal enforceability review
process. That process would determine whether a substantial
plurality (3/4ths) of those who would be required to
implement a proposed policy (e.g., all registries, in most
cases, and all registrars, in some cases) will contractually
commit to do so. To avoid wheel spinning and
counterproductive confrontation, the organizing documents
should provide that the DNSO will not forward to ICANN
policies that do not meet this condition.
This procedure will allow ICANN to negotiate contracts with
registries providing that the registries will in fact
enforce proposals that have been accepted by at least 3/4ths
of the other registries for TLDs listed in the authoritative
root. (Alternatively, this measure could refer to registries
for 3/4ths of the registrations in such TLDs.)
It is unlikely that most registries will contractually
commit to comply with every and any policy that ICANN may
promulgate. ICANN will not have any governmental authority
for force such compliance. And use of control over the root
to pressure registries to do so would increase the perceived
need of registries to have substantial influence over the
DNSO and ICANN board.
In contrast, however, all registries should be willing to
agree to implement policies that are acceptable to most
competing registries (and the same goes, one level down the
contract chain, for registrars). Such a structure in effect
gives veto power to "substantial minorities" of two types --
the impacted stakeholder community (because DNSO may not
recommend a non-consensus policy) and the implementing
registry/registrar community -- just what we should want in
a process designed to generate voluntary consensus
standards.
3. Organizational Status.
DNSO should be a procedural subcomponent of ICANN, not a
separate corporate entity. The bylaws and resolutions of
ICANN, not a contract between ICANN and DNSO, should set
forth the DNSO organizational structure. ICANN should
administer DNSO funds. DNSO members should automatically be
considered a special class of ICANN members.
The White Paper calls for "separate name and number
councils…formed within a single organization." If the DNSO
were a separate corporate entity, then it would have to be
governed by an elected board that makes final decisions for
it -- producing the counterproductive pressures for zero-sum
seat claiming described above. There would be a serious risk
that the DNSO would develop interests conflicting with those
of ICANN -- something the ICANN bylaws prohibit. It is
extremely troubling to establish a corporate structure in
which one corporation names board members of another, in
which the other corporation purports to have a right to
approve the membership criteria of the first, and in which
duplicative staff and potentially conflicting duties
complicate an already unduly complex process.
The ICANN Board appears to have called in its December 22,
1998, statement for creation of a DNSO with a "separate
organizational identity from that of ICANN", with a
relationship established by contract. This appears
inconsistent with the White Paper and with ICANN's own
bylaws, since a DNSO that can contract with ICANN and others
would not be one that "shall serve as [an] advisory body to
the Board and … have such powers and duties as may be
prescribed by the [ICANN] Board and [the ICANN] Bylaws." How
could the DNSO interpret its contractual obligations with a
view to its own interests? Could the DNSO decide to
terminate its contract with ICANN? Could ICANN realistically
terminate its contract with a membership body designed to
provide an avenue for policy recommendations by an open
membership?
If a consensus among registrant stakeholders and those who
must implement name policies (registries and registrars)
supports creation of the DNSO as a process internal to
ICANN, rather than as a separate corporate entity, then the
ICANN Board should surely accept such an application. If
there is disagreement on this issue, and DNSO is established
as a separate corporate entity despite such disagreement,
ICANN will be faced with the receipt of policy
recommendations from an entity that cannot claim to
represent all stakeholders, that is not necessarily bound by
the protective provisions of the ICANN articles and bylaws,
and that might at some point have contractual or other
disputes with ICANN itself. It is not (or should not be)
too late to change the mind of the ICANN Board on this
critical issue.
4. Open and Diverse Membership, rather than establishment of
differently privileged classes.
While differing classes of members might be defined for
purposes of setting fees to pay for DNSO functions, it is
fundamentally destructive of the consensus-building mission
of DNSO to empower different classes of members to exercise
(through specified numbers of representatives), differing
degrees of influence on selection of ICANN board members or
on recommendations regarding domain name policy.
Some provision should be made to assure that there is at
least some representation of each category of stakeholder on
the Name Council. And some provision should be made to
assure adequate geographic diversity among those who serve
by providing administrative coordination through the Name
Council. (This can be accomplished by means of the
nomination of qualified, i.e., adequately diverse, slates of
candidates, as more fully discussed below.) But, aside from
such distributional requirements, different classes should
not vote for separate subsets of the NC. Any such allocation
will freeze power relationships and reinforce a zero-sum,
horse-trading model of top down decision-making.
Membership should be open to all registrants (Second
Level -- or first retail level if the TLD is sub-divided --
Domain holders in TLDs included in the authoritative root),
registries and registrars -- and modest fees, possibly
differing among these categories, may be set to pay the
costs of operating the DNSO. There may be some
"stakeholders" with an interest in the domain name policy
issues who do not themselves have domain name
registrations -- but these will be very few in number and
hard to define. In contrast, establishing separate
categories for stakeholders who are in different types or
sizes of businesses, or who operate associations or
organizations interested in particular intellectual property
issues, will lead to costly and counterproductive
credentials battles.
All members should vote for representatives to the ICANN
board. Institutional members with particularly intense
interests in particular issues will be able to marshal
support by persuasion and the collection of proxies. If a
substantial number of members vote in favor of particular
slates or policies, the results will be able to be defended
as representative of the consensus view of those who
actually use (and contract to access and supply) the system
in question.
5. Funding
Funds provided to ICANN, over and above those needed to
cover costs of DNSO operations, should be raised directly
under contracts between ICANN and the registries. This will
greatly reduce the need to provide for separate handling of
funds by the DNSO. It will also assure that ICANN funding is
supplied by those who must have contractual relationships
with ICANN.
Drafting Consequences -- The Major structural points
described above lead to various additional detailed drafting
requirements for the application and organizational
documents, which of course apply differently to the
different drafts that have been proposed, as follows:
Points particularly pertinent to the ORSC Draft (which
appears to be the best starting point, insofar as it
recognizes the primacy of a consensus-generating process
rather than top down governance by representatives elected
by different constituencies).
* Registries and registrars, as well as registrants, should
be eligible to become members of the DNSO (as required by
the ICANN bylaws).
* ICANN board members should be elected by the membership,
not appointed by the Council, from the outset.
* The Names Council members, considered as staff for the
DNSO charged with creating a consensus-building process,
should receive compensation.
* The Names Council should include no more than a stated
number of members from each geographic and functional
constituency. To accomplish this goal, nominations should
take the form of qualifying slates. An initial
membership/procedures committee should be created on a
consensus basis to oversee the first election and membership
registration process.
* The DNSO should not have separate officers or employees or
counsel. ICANN should provide or contract for staff
assistance or other services of third parties, using funds
within the approved budget for DNSO operations (collected as
fees from DNSO members for this purpose).
* The DNSO should not have separate committees with
delegated powers to take decisions on behalf of the NC or
DNSO. Instead, the NC should establish a series of
policy-specific proceedings, open to all DNSO members, to
compile recommendations and associated records for
transmission to the ICANN board. The NC may specify the
topic and timetables of such proceedings.
* Fair Hearing Panels should be redesigned to serve as an
investigative and reporting process, rather than as a
distinct means of reviewing and/or overturning policy
decisions. Policy-making should remain within the DNSO
consensus-building and enforceability-testing fora. Fair
Hearings Panels should, in contrast, be charged with
developing neutral evaluations of specific, disputed factual
issues -- to compile records for use by all members, as
appropriate, in the policy-making process.
* Standing proxies (for all issues and all meetings, valid
until revocation) should be allowed.
* Members should not be allowed to be expelled "for conduct
prejudicial to the best interests of the DNSO". Procedural
rules for particular meetings or processes may provide for
limitation on participation (but not voting) by disruptive
parties, by 3/4ths vote of other participants.
* The DNSO should not have the power to enter into binding
contracts.
* ICANN should indemnify NC members and others working as
agents of the DNSO.
* ICANN should adopt the organizational documents for the
DNSO as part of its bylaws and board resolutions, subject to
a condition that such provisions may not be amended unless
3/4ths of the DNSO membership (participating in such vote)
approves the change.
Points particularly pertinent to the INTA and Monterrey
Drafts (many of the preceding drafting points also apply).
* The DNSO should make recommendations (not "make policy"),
and policy recommendations should come from the membership.
The NC function should be redescribed as one of coordination
and administration of a policy formulation process.
* Businesses that are not registrants of domain names (or
registries or registrars) should not be members of the DNSO.
* Dues should be approved by the membership.
* Membership in the NC should be distributed (via election
by the entire membership of qualifying slates), but not
apportioned numerically to particular categories of members.
* The membership should elect ICANN board members.
* The DNSO should not have officers or employees.
* The DNSO should not have committees with delegated powers.
* The DNSO should not enter contracts or provide
indemnification.
* The DNSO should not be a separate corporate entity.