Reports will, inevitably, be written by Working Groups,
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.
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
the report that accompanied the proposed UDRP reflected an extensive series
of discussions among those who would be impacted by the proposal.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.
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.
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.
Model Working Group Report
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.
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
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.