What an ICANN Consensus Report Should Look Like

Such Consensus Reports will, inevitably, be written by Working Groups,[4] task forces, and ICANN staff (and counsel).The Names Council and the ICANN Board will need to rely on such reports to opine as to whether or not a particular policy is supported by a consensus among the impacted communities.But staff and Working Groups will do most of the work, and the goal of this article is to assist them in doing the hard labor of formulating concrete proposals, assessing reliable indicators of support and opposition, and recording the results of this potentially tedious process.
 

Currently, the Uniform Dispute Resolution Policy is the closest thing that ICANN has to a consensus policy.Its implementation documents were adopted in late October 1999, and for registrar/registry accreditation contracts dated after November 1999 it is deemed to be a consensus policy (absent change by further consensus) (see Registrar Accreditation Agreement Section I.B.5).Of course, the mere fact that the UDRP is contractually binding on registrars and registries does not demonstrate that the process used to create it would now satisfy the overall contractual test for consensus support.Nevertheless, the process leading up to the adoption of the UDRP represented a good first effort and can serve as a useful model for future development of consensus policies.
 

In particular, the report that accompanied the proposed UDRP reflected an extensive series of discussions among those who would be impacted by the proposal.[5]The report documented arguments for and against the proposal and provided related background information.The decision of the Board to adopt it was based on the fact that intense discussions among strong proponents of differing viewpoints had yielded a document that no substantially impacted party vigorously opposed.Some mistakes were made with respect to the resulting policy -- both substantive and procedural.At least one can say, however, that the UDRP came from the community itself and was not adopted until there was a widely shared and reasoned view that going forward with the proposal was better than not having a standardized policy on this issue.There was no strongly-held reasoned opposition from particular groups that would be substantially impacted in ways that were different from those applicable to the community as a whole.
 

A cautionary note:Although the UDRP precedent provides concrete evidence of what a consensus report might look like, the structure and development of the constituency system within the DNSO may cripple the work of task forces and other groups attempting to develop true community consensus along the lines followed by those who worked on the UDRP.When constituencies or working groups view themselves as "representatives" who must work to further the perceived goals of their constituents (whether they believe in these goals in the long run or not), the process of consensus-building is distorted.The constituency structure is leading to polarization and problems of over- and under-representation (because not all people fit neatly into one of the existing constituencies, some fit into more than one, and some voices are louder than they should be).The Consensus Report structure set forth in the registry/registrar contracts, with its requirements of analysis and outreach, should be viewed as a tool that will force staff and Working Groups to see themselves as the community's staff rather than as a group of self-appointed or non-representative representatives.In the end, however, the current constituency structure may need to be abandoned altogether.
 

The checklist that follows is an attempt to provide a roadmap for use by working group chairs as they assess the prospects of creating a report that demonstrates the presence of consensus within the meaning of ICANN’s charter and contracts.Supplied with such a report, the Names Council and ICANN’s Board could reasonably conclude that they have the power to adopt and enforce the corresponding policy. Without such a report ICANN is, quite literally, powerless.

1.Clear and concise statement of a specific proposal.

Much of the discussion about ICANN matters is carried out on electronic mailing lists or in working group meetings.This poses the risk that every comment might be understood by the poster (or others) to represent an effort to formulate an ICANN policy.Discussion at all levels needs to be focused on clearly specified proposals.Obviously, the early stages of a working group process may generate a number of competing formulations.A search for support and

endorsements will help to sort out those specific proposals (and combinations) most and least likely to lead to consensus.Ultimately, the report acted on by the Names Council and the Board will need precisely to state the formulation of what is claimed to have consensus support -- so that, among other things, in the event a registrar or registry disputes the presence of consensus that claim can be tested by the Independent Review Panel and the courts.For completeness, and to avoid later questions, the report should also document or cite to those organizational documents that show ICANN is competent to address the subject matter of the proposal.
 

2.Discussion of the goals sought to be achieved and the issues raised by the proposal.

A draft report claiming to provide evidence of consensus should explain why the proposal should take the form of a uniform policy adopted by ICANN's Board.Those who have not been deeply involved in the group working on the proposal should be enabled to evaluate the proposal against the background of a stated goal.Additionally, clarity as to the goals sought and the issues raised by the proposal may lead to suggestions as to better ways to reach the stated goals.

4.Description of any previous deliberations about the proposal. 

The report will need to discuss whether other non-ICANN processes have extensively considered various issues raised by a particular proposal.Prior deliberation does not necessarily support an artificial declaration of consensus, but an analysis of such deliberation can help to frame the issues and to put various statements of support and opposition into better perspective.

5.List of participants in the working group, along with their qualifications and affiliations. 

As discussed above, working groups should not be designed to “represent” a citizenry or only to reflect subject matter expertise (although some working groups may have more expertise than others with respect to a particular subject).There should, therefore, be no requirement of particular qualifications for membership in a task force or working group serving as the community's staff on a proposal, nor any disqualification based on affiliation or prior statements of position.Nonetheless, a listing of the members of any group working on a proposal will aid in the transparency and credibility of the process.Also, where experts participate in a working group or task force, a statement of their qualifications can help to put their views in context.These qualifications, however, should not give their views any dispositive weight, because proposals addressed to the ICANN Board will involve value judgments as well as technical expertise.

6.Analysis of all substantial impacts of the proposal. 

The greatest uncertainty about any proposal, from the perspective of those not intimately involved in its development, will be the extent and nature of its impacts. The group should devote much of its attention to analyzing the nature and extent of these possible impacts.This discussion will show that the proponents have extended their thinking to cover all points of view, and will help potential supporters and opponents to decide when to speak.Finally, this discussion will help future groups consider how best to develop alternative proposals that minimize negative impacts and maximize positive ones.

7.Description of outreach conducted to contact those potentially impacted by the proposal.

This is the heart of any Consensus Report.It is unrealistic to expect that any "working group" will include all of the parties that might be impacted by a proposal or whose views need, somehow, to be assessed.Thus, outreach -- and a clear and exhaustive description of this outreach -- will be absolutely essential.While proposals should be placed on the web for public comment, that step alone will likely only reach those already engaged in the process.A thoughtful working group will go out of its way to make an extensive record of its affirmative outreach efforts towards groups likely to be impacted by a proposed policy.

8.Summary of arguments for and against the proposal, attributed to particular sources.

Obviously, the substantive content of the discussion about the proposal must be summarized in a coherent and balanced way.This process will require the presence of a relatively fair, hardworking, and neutral working group chair -- the presence of whom will itself help to generate a trustworthy report.The key question posed in any consensus-based process is whether opposing views (of which there will always be some) are isolated, limited in intensity, shared only by those with low stakes in the process, or unreasoned.For this reason, it is critical that the report specifically analyze the substance of opposing views, point out the best answers to those views, or otherwise analyze why the opposition should not be entitled to great weight.

9.Analysis of distribution of support and opposition among impacted groups. 

It is not enough to focus on a substantive analysis of the arguments for and against the proposal.A consensus report must also analyze the distribution of views among differently impacted parties.Such an analysis will need to examine the affiliations between parties, the relationship between substantive views and stakeholder interests, and any patterns in coalitions that might shed light on where further improvements or compromises are most likely to be found.If a proposal imposes a disproportionate burden or implementation duty on particular types of parties, any opposition from such parties should be entitled to greater weight in evaluating the presence of consensus.It is all too easy for those who do not bear the costs of a proposal to support the imposition of those costs on others.

10.List of factual or background materials that would be useful to anyone analyzing the proposal.

A draft working group report should be designed to reach a broader public and to stand the test of time.It should, to the extent possible, be sufficiently self-contained so that those who have not been following the proposal process closely will be able to teach themselves with the aid of the report.

11.Analysis of reasons to believe that the proposal enjoys widespread support among impacted parties.

A key section of the report should expressly address the claim to consensus by listing and describing concrete reasons supporting a belief that affirmative support for the proposal is widespread.The report needs to stand in contrast to a mere claim that an internal working group vote has been taken and has produced a majority or even supermajority result in favor of the proposal.The legitimacy of ICANN will rest on demonstrations that its policies are supported in the real world, not just that its active, insider participants have agreed on some proposition.

12.Analysis of the reasons to believe opposition is limited, unreasoned, or arises only from those not impacted or implementing.

As a corollary to the need to address and support the claim to consensus, the report will also need to show that opposition to the proposal should be disregarded.The report will need to provide specific reasons supporting such a step by addressing the relatively low intensity of the opposition, the source of the opposition, and/or the unreasoned character of the opposition.
 
 

One problem with describing ICANN as a consensus-based institution is that ICANN has yet to develop any consensus policies (with the exception of the UDRP).We believe that if ICANN working groups and task forces have a shared understanding of what will be required to produce a Consensus Report, their productivity in this regard will increase.The checklist set forth above should help the chairs and task force leaders to assign specific tasks, and to challenge participants to come up with drafts for particular subsections of a final report.
 

The persuasiveness and credibility of the final report with respect to the question whether consensus exists among impacted stakeholders is the central issue.The details of the process leading to this draft report matter less than, by contrast, it matters that the procedural rules of an election or of a legislative body be followed.Consensus is not about “due process” or the absence of election fraud.Consensus, seen clearly, is about a testable state of the world:Do most of those impacted by a particular proposal support a centralized decision to adopt a policy; do some strongly and rationally oppose it; or does no one care?In either of these two latter cases, the conversation should continue and decentralized decision-making should prevail.
 

Like all open, transparent and emergent processes, developing and documenting a consensus-based policy will take a great deal of tedious effort.But the process used to get to that result should not be bogged down in arcane, rigid procedural rules.Consensus is the result of a rich, searching conversation with all concerned.Where consensus truly exists, it should be easy to document.Such conversations (even when they result in failure to reach consensus) are necessary to ICANN's continued credibility.