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

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.)
  3. 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.

  4. 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?
  5. 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.

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

  8. 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).



Points particularly pertinent to the INTA and Monterrey Drafts (many of the preceding drafting points also apply).