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.