Working Paper on the Policy-Development Process
Posted: 7 May 2002

Committee on ICANN Evolution and Reform
Working Paper on the Policy-Development Process

This is one of a series of papers in which we offer thoughts for further discussion. As is the case for the other papers, these are not conclusions, so these thoughts may or may not actually form the basis of specific recommendations to the Board or the community as a whole. We hope they will provide a focus for more detailed discussion by the community in the next few weeks. The most useful comments will be those received by 17 May 2002.

Introduction

While we have previously stated that we take the Stuart Lynn reform proposal as the starting point for which it was intended, the Lynn proposal does not address the issue of policy development in any detail, other than to emphasize strongly the need for a streamlined mechanism for decision-making and proposing a structure to accomplish this. This is indeed one strong motivation for reformed Board and Council structures, but there is more that is relevant to this subject.

Discussion of the policy-development process involves two separate but interrelated components: substantive decisional standards and the procedures for reaching a decision.

I. Substantive Standards

ICANN was conceived as an environment where the various members of the Internet community could come together, debate and discuss technical coordination and other policy issues related to the domain names and address allocation systems, and (optimally) reach consensus positions that would be binding on all. This approach was seen as a more desirable alternative than a multinational governmental treaty organization, which because of the Internet's global character was seen as the only other practical option. The private-sector consensus-development approach was thought likely to be quicker, more responsive to changing conditions, and more suitable to the development of effective global policies than a governmental organization would be.

The results to date are mixed. ICANN has been very effective in some areas, notably the introduction of competition at the registrar level, establishment of new TLDs, and the creation of an efficient, non-binding dispute resolution process. But in other areas ICANN has been less effective. In particular, ICANN has not always demonstrated the ability to come to decisions on issues of interest to some or all of its constituents, with the result that the consequence is often no action – by default rather than through a conscious choice of the Internet community.

The reason for this is the apparent operating assumption that ICANN can (or, in the view of some, should) only take action when that is supported by a clear consensus across the ICANN community. While there are few if any advocates that "consensus" is synonymous with "unanimous," some strongly believe that consensus is incompatible with strongly held rational disagreements, and that where such disagreements are present a "consensus policy development" body such as ICANN cannot legitimately act. Others would argue that allowing those with particular economic or other interests to, in effect, have a veto over policy development just by refusing to compromise is not acceptable, and that "consensus" in this context must admit the possibility of strongly held opposing views. Still others would say that ICANN must be able to act when necessary to preserve the stability and interoperability of the global DNS, but that it could only act outside that boundary when there was consensus support for those other actions.

Of course, whatever the conceptual view, the exact meaning of the words is critical. What is the proper definition of consensus? What does "necessary to preserve" mean – unless the action is taken the DNS will fail, or simply that it will likely work better if the action is taken? And if the latter, what is the definition of "better?" By whose standards?

This debate, and how these questions are resolved, is critical to the effective operation of ICANN. This paper provides some background and analysis, in an effort to advance the debate, and asks for comments on specific questions related to this issue.

A. History

The notion that ICANN would operate by consensus does not find its origin in the US Government's White Paper. Indeed, the only mention of consensus in that document makes it clear that the authors of the White Paper assumed that consensus would not be the normal method of decision-making in the private-sector organization it contemplated:

"Typically this means that decision-making processes should be sound and transparent; the basis for corporate decisions should be recorded and made publicly available. Super-majority or even consensus requirements may be useful to protect against capture by a self-interested faction."

Nor does the Memorandum of Understanding between the US Government and ICANN (that officially recognized ICANN as the private-sector entity with which the US would work to transition management of the DNS from governmental control) ever mention consensus decision-making. Neither the original ICANN bylaws submitted to the US Government, nor the amended bylaws in effect at the time the US Government recognized ICANN, ever mention consensus. In those latter documents, the only supermajority requirements deal with the creation of new Supporting Organizations or the amendment of the bylaws, each of which requires a two-thirds majority of the Board.

So how did ICANN come to be perceived as an entity that should (or can) only operate by consensus? Perhaps it was a natural result of the emphasis on "bottom-up" policy development, which is a concept that is frequently referenced in the White Paper and subsequent documents, although that notion – bottom-up policy development – is also fully consistent with a general process that encourages community acquiescence in individual initiatives generally. But most likely, this notion originates with the 31 March 1999 revision of ICANN's bylaws that inserted provisions establishing with the Domain Name Supporting Organization. In particular, the following language is the first language in any official ICANN document that uses the word "consensus:"

(d) If two-thirds (2/3) of the members of the NC determine that the DNSO process has produced a community consensus, that consensus position shall be forwarded to the Board as a consensus recommendation, along with all materials or other information that could reasonably be relevant to the Board's review of that determination, including (but not limited to) the dissenting statement(s) of any member(s) of the NC. If more than one-half (1/2) but less than two-thirds (2/3) of the members of the NC determine that the DNSO process has produced a community consensus, that position may be forwarded to the Board as a NC recommendation, along with statements of majority and minority views, and any separate or dissenting statement(s) of any member(s) of the NC. Any proposed recommendation that is not supported by an affirmative vote of one-half (1/2) of the members of the NC may be returned to the body from which it originated, or may be assigned to a new body, for further work. In such a case, the NC may report to the board the lack of a consensus and the steps, if any, it plans to take from this point forward with respect to this particular recommendation. The NC is responsible for ensuring that the Board is informed of any significant implementation or operational concerns expressed by any responsible party.

As is clear from this language, there is no mandate that only "consensus" recommendations be forwarded to the Board, and the only logical inference is that the Board could act on recommendations that were not (at least by the test set forth here of a two-thirds vote of the Names Council) the result of community consensus. This conclusion is also supported by the language that has been in the ICANN bylaws from the time they were first submitted to the US government – that "[n]othing in [these bylaws] is intended to limit the general powers of the Board or the Corporation to act on matters not within the scope of a Supporting Organization or that the Board finds are necessary or appropriate to further the purposes of the Corporation." Since this language clearly permits the Board to act without or even contrary to a recommendation from a Supporting Organization, and sets no supermajority voting requirements, it is clear that the ICANN Board is not legally limited to taking actions that are demonstrably (or even arguably) "consensus" positions, whatever the exact meaning of that word.

The other (and today more important) source of ICANN's consensus mentality is the original NSI registry agreements, where NSI negotiated limitations on NSI's obligations to comply with ICANN policies to only those that qualified as "consensus policies." Those limitations have been replicated in contracts since that time, and were defined as follows:

(a) "Consensus Policies" are those adopted based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (1) the adoption of the policy by the ICANN Board of Directors, (2) a recommendation that the policy should be adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, and (3) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy.

Similar language now exists in all the gTLD registry agreements. The implication of this is that registry operators are not in general bound by those contracts to comply with ICANN policies that do not meet the contractual definition of "consensus policies" quoted above.

Even without these legal motivations, over time the natural tendency of an organization such as ICANN would be to seek consensus wherever possible, and to act without demonstrable consensus support only when absolutely necessary. This is a logical and appropriate approach for an entity that depends on the voluntary cooperation of a wide variety of participants, and is in any event most consistent with the successful past history of Internet development. But this tendency should not be confused with the notion that there is some requirement that legitimate actions can only rest on a demonstration of consensus (however defined). The fact is that there is no such requirement. ICANN's efforts to reach "consensus" reflect a community preference, not a fundamental mandate from ICANN's founding.

B. The Realities of Making Decisions

[We focus in the discussion that follows on the names area. Consensus-based, bottom up policy development has largely been effective in the area of addressing policy. A major reason is that the ASO, unlike the DNSO, is composed of relatively homogenous organizations, which have evolved to become more alike in their thinking and policy deliberations than they are different. The RIRs have long histories of operation and cooperation, well-defined and active memberships, and well-developed cultures emphasizing the resolution of issues through discussion and consensus. These are not features of the DNSO, and thus the consensus policy-development effort has been considerably more difficult in the names area.]

ICANN is a complex organization. It encompasses private providers of DNS services and the customers who buy those services; private, for-profit organizations and non-commercial private and public organizations; governmental and private-sector bodies; corporations and individuals; academics and technicians; standards-setting bodies and companies with market power. It would be optimistic indeed to expect that this varied collection of interests and resources would come to a uniform position on almost any issue, much less on all issues related to the technical coordination of the DNS.

And in fact they frequently do not. The issues where ICANN has been most effective have been where no such consensus was required, for various reasons. For example, ICANN has been able to act effectively where mandated to do so by the terms of its agreements with the US Government, and with the support that implies. As a result, the organization (NSI) that could have opposed the introduction of registrar competition was precluded by contract from doing so, and required by contract to cooperate in the creation of the Shared Registry System needed to make that competition a reality. Similarly, contractual provisions impelled the use and acceptance of the Uniform Dispute Resolution Policy by all registrars and registries. Where there have been no such overriding factors, however, the development of consensus positions with respect to name policy has been almost impossible. Whois policies, deletion policies, issues relating to marketing practices, and the addition of new registry services are all issues that have not been resolved in significant part because of the absence of consensus – in many cases created by the determined opposition of one or a small number of parties with significant commercial interests – and the reluctance of ICANN to act in the absence of a consensus.

Thus, what too often emerges is either nothing or a lowest common denominator consensus (in the form of very general principles), rather than useful and productive advice for the Board. In these circumstances, the Board has occasionally had to take the initiative itself and fill in the details that preferably would be the province (at least in the first instance) of the subsidiary policy-development bodies. This should not be too surprising. It would be unusual if matters where there were significant and inconsistent commercial or strongly held philosophical views would commonly result, after discussion or debate, in universally acceptable common positions. Both economic game theory and the study of human nature provide persuasive evidence of this fact.

Of course, to those who believe that ICANN, having no governmental mandate, should never act in the absence of consensus, this lack of ability to act is a feature, not a bug. If there is no consensus, they would argue, the "market" should be allowed to function freely without ICANN interference. Only in this way, they argue, will the tendency toward over-regulation be avoided. In addition, they argue that it is simply inappropriate for a non-governmental body to, in effect, claim "regulatory" jurisdiction over a private enterprise on the basis of the views of third parties, and over the opposition of that enterprise. Absent some form of governmental action, they argue, or the consent of the affected party or parties, there is no basis for ICANN – by definition a private, non-governmental body – to force compliance with anything, no matter how desirable it may be from the perspective of others in the ICANN community.

This argument has merit. No rational person wants to see ICANN become the "regulator" of the Internet. On the other hand, this begs the hard question: if consensus is required for any action, doesn't that create perverse incentives for those with narrow commercial interests to veto any consensus that is not immediately in their interest? We believe that it can be persuasively argued that a properly structured and functioning ICANN is the ideal mechanism for resolving such debates, even if (and maybe especially if) the parties with direct commercial interests cannot come to a consensus view. Assuming it is properly structured and functioning (and those are obviously critical assumptions), ICANN is both a desirable and potentially an effective vehicle for global resolution of issues relating to the DNS where today there is no global alternative.

The fact is that the Internet, and its component part the Domain Name System, is a global resource. It is not amenable to multiple national regulatory approaches – at least if the goal is to allow the Internet to continue to provide ever more opportunities to ever more people at a relatively low cost. And in any event national regulation, given the nature of the resource, is likely to be ineffective. Thus, the options are some form of global governmental body, or a global private-sector body. There do not appear to be any other workable alternatives.

A reasonable argument can be made that, given the nature of the Internet and the DNS – both their global character and the critical role of interoperability and stability to their continuing function – a global, private-sector organization like ICANN is the ideal vehicle for balancing the legitimate private interests of individuals, groups, and entities, on the one hand, and the enormous public interest in the continued effective operation of the Internet on the other. We understand and accept that this could only be the case if we assume (1) the proper structure and operation of ICANN, including critically the proper limitation of the scope of its activities to those that are reasonably necessary to maintain, promote, or improve the continued effective operation (stability, interoperability, and utility) of the DNS, (2) the ability of all interested parties to discuss and debate in an open and transparent way, (3) the ability to have ICANN's decisions produced through another open and transparent process, and (4) that such a resolution would be effective (i.e. is enforceable) throughout the global resource that is the Internet. But if we assume those conditions, such an ICANN, it seems to us, would have great value to many (if not most) of the members of the global Internet community, even if the resolution of any particular issue may not be all to their liking.

C. A Practical Approach

ICANN is and always should be an organization focused on policy development by consensus whenever possible. This is the most consistent practice with the successes of the past, and the most likely to generate broad support and compliance throughout the global Internet community in the future.

On the other hand, there is a growing sentiment that the desire for consensus should not be allowed to create veto rights in community members with private or very limited objectives that are inconsistent with the needs or desires of the rest of the Internet community. The optimal system, in our view, would recognize the enormous desirability of consensus whenever attainable, but also accept the need in some circumstances to reach decisions over the isolated and determined opposition of one or a few members of the community.

Thus, a reasonable solution would be to have ICANN seek consensus whenever possible in developing policies, through processes and procedures that insure that all views of those affected are heard and that are open and transparent, and then to allow the ICANN Board to decide the issue based on its educated perception of the best interests of the whole community. To ensure that the ICANN Board did not lightly disregard any policy recommendation from a constituent entity, ICANN's bylaws could require only a simple majority to accept a properly documented consensus recommendation from such an entity, and a supermajority (two-thirds?) to take action that was significantly inconsistent with such a recommendation.

This would preserve the incentive of all parties to work toward consensus solutions, but allow the Board (assuming a Board selection process that produces a broadly representative Board) to exercise its good judgment. If a supermajority provision was included in the bylaws, and if an independent review process or some similar mechanism existed, there would be a review to ensure that standard was met.

II. PROCEDURES

A major problem in the policy-development process to date has been the lack of an adequate policy-making structure. The Domain Name Supporting Organization has been left to make up its own processes and schedules, with no practical oversight or limits, and generally without dedicated staff support. With entirely volunteer participants, the result has been at best uneven, with the predominant outcomes slow or exceedingly general or both. There have been only a few outcomes that could be called consensus policies generated in the almost four years of ICANN's existence.

Dedicated staff focused on the policy-development effort, as suggested by the Lynn proposal, is one critical way to help this problem. But in addition to this, there is the need to develop a standard set of principles and procedures for the development of those policies that are appropriately related to ICANN's mission. [For an effort to generally describe ICANN's mission, see the working paper on ICANN's mission and core values recently released by the Committee.]

These principles and procedures should mandate outreach, ensure the opportunity for input by all interested parties, require the development of records that document both the input and the analysis that leads to the recommendation, and set clear time periods for at least the production of status reports. They should also leave the Board free to insist on recommendations by a time certain where necessary or appropriate, and give the Board the freedom to reach outside the existing institutional framework for advice if necessary or desirable on a particular issue.

Such procedures could look something like this:

• ICANN should continue to operate as a bottom-up policy-development organization. This means that, as a general matter, it is preferable for policy issues to be discussed and recommendations originated from the community through the ICANN bodies established to manage such processes, or in the case of policy initiatives coming from the staff or Board of Trustees, for those initiatives to be referred for evaluation and recommendation to such ICANN bodies prior to decision by the Board.

• Those policy-development bodies should be charged with undertaking an appropriate process of collecting community input, evaluating that input and developing recommendations that are either consistent with that input or clearly explain any inconsistencies. That process could involve working groups, task forces, public comments or some mixture of these devices, looking toward the production of a draft report and recommendation to the ICANN Board. This process should have a set time period, probably no longer than 30-45 days.

• Any such draft report should clearly state (1) the basis for any recommendations, (2) the steps taken to generate community input and the nature of that input, (3) the identity of and rationale for any dissents, and (4) any special time considerations relevant to the recommendations presented.

• Any such draft reports should be posted for review and comment by the public and/or any other ICANN entities for no less than thirty days, after which the policy body should have no more than fifteen days to finalize its report and recommendations and transmit them to the Board. The Board could then either take an action, or seek further input, either from the ICANN community or from outside consultants or bodies with particular expertise in the area.

• Once the Board has reached a tentative decision, it would publish a tentative decision and explanation, and allow a reasonable period of comment on that tentative decision, after which it would finalize and promptly publish both its decision and any appropriate explanation.

Strict time limits for the development of any report and recommendation by an ICANN policy body, regardless of how the issue was initiated, are critical in our view. In the absence of urgent conditions (in which case the Board could establish time periods consistent with the nature of the urgency), consideration of a particular policy initiative should be limited to a total of ninety days after initiation or referral, at which time a report to the Board would be required describing either (1) a recommendation for Board action with appropriate documentation or (2) the reason why more time is needed to produce such a recommendation. In the latter case, the Board could establish some later date for a recommendation, as it saw appropriate. In the absence of a recommendation by the required date, the Board would be free to take any action it thought appropriate without regard for the lack of a recommendation.

The Board would be free to deviate from any recommendation, but for a properly documented consensus recommendation from an ICANN policy-development body, forwarded with the support of two-thirds of the appropriate Steering Committee and on which there was no opposition from another ICANN policy-development body, such deviation would require a two-thirds vote of those Board members voting on the matter. In all other cases, the Board could act by a majority of those Board members voting.

In our tentative view, these or similar procedures would encourage consensus policy development, but not allow it to be captured or impeded by determined opposition. They would allow the Board to make an independent decision, but only to reject a clear consensus recommendation by a super-majority vote. And they would insure that decisions could be made in a timely way.

Conclusion

The Committee offers these thoughts in an effort to encourage more detailed community discussion of these issues. These may appear to be basic nuts and bolts issues, but in our view they are important elements of ICANN evolution and reform. To be effective, ICANN must have a policy-development process that both invites and permits all interested parties to participate, but also is designed to actually produce decisions in a timely way. The Committee invites comments on this general approach to policy development.

Committee on ICANN Reform and Evolution
7 May 2002

Page Updated 20-Aug-2003
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.