Guest blog: ICANN needs to follow its own bylaws on UDRP review

Guest blog by Shawn Gunnarson

ICANN needs to follow its own bylaws. That it too often winks at its fundamental rules is illustrated by the Preliminary GNSO Issue Report on the Current State of the Uniform Dispute Resolution Policy (“UDRP Report”). Not only was the UDRP Report issued 98 days later than the deadline specified under the bylaws, but the completed report stacks the deck against commencing a Policy Development Process (PDP) rather than identifying support for it, as the bylaws require, and fails to answer the questions posed by the GNSO Council.

The UDRP Report originated with a GNSO Council resolution on February 3, 2011 requesting an issue report on the following: “How the UDRP has addressed the problem of cybersquatting to date, and any insufficiencies/inequalities associated with the process [and] [w]hether the definition of cybersquatting inherent within the existing UDRP language needs to be reviewed or updated.” The Council added that “[t]he Issue Report should include suggestions for how a possible PDP on this issue might be managed.”

Nearly four months later—on May 27, 2011—the UDRP Report was issued. Its main recommendation was “that a PDP on the UDRP not be initiated at this time.” As an alternative, staff recommended that “if the GNSO Council nonetheless believes that the UDRP should be reviewed … [it should convene] a small group of experts to produce recommendations to improve the process or implementation of the UDRP policy as an initial step.” Only if the Council still wanted “a more thorough review of the UDRP” after this group of experts has produced recommendations, did the staff recommend conducting “a more focused PDP.”

Its reason for avoiding a PDP was the staff’s assessment that “[t]he overwhelming sentiment from the UDRP Webinar is that although it is not perfect, the UDRP should be untouched.” This conclusion was based on the opinions expressed during a staff-organized Webinar and statements by UDRP providers in response to a staff questionnaire.

Despite this forceful recommendation against commencing a PDP, ICANN’s general counsel certified that doing so would be in scope for the GNSO Council.

Curiously, the UDRP Report reverses the staff’s own position. In 2008, staff recommended areas where the GNSO Council might wish to conduct further research, including whether “an initial review or analysis of the UDRP [is] required.” Following this recommendation, the GNSO Council chartered the Registration Abuse Policies Working Group (RAPWG) whose final report unanimously recommended initiating a PDP on the UDRP. The Registration Abuse Policies Implementation Drafting Team (RAP-IDT) was then organized, and it also unanimously supported a PDP, ranking it fourth on the list of RAPWG priorities in part because of the high degree of consensus around it.

So the GNSO Council’s sought the staff’s assistance in commencing a PDP on the UDRP based on the ICANN staff’s own recommendation to conduct research. Now—three years later—the staff opposes a PDP. It is difficult to understand how the staff can be so inconsistent, but in any event the GNSO’s time and resources should not subject to being turned on and off seemingly at a whim.

The UDRP Report was also delivered late—98 days late, to be exact. The bylaws specify a 15-day deadline for delivering an issue report, yet it was delivered 113 days after the GNSO Council’s resolution. Nowhere does the UDRP Report mention its untimeliness, much less explain it.

Untimeliness is particularly significant in this instance. Few of ICANN’s bylaws prescribe any deadline, leaving ICANN staff, officers, and directors generally free to complete projects in a “reasonable” time. An issue report is different. By design, the staff’s work is to be completed quickly after the GNSO Council resolves to consider commencing a PDP. That the UDRP Report was delivered more than three months late has imposed a delay in the policy-making process contrary to ICANN’s bylaws.

The UDRP Report is also substantively inconsistent with the bylaws by all but failing to identify “[s]upport for the issue to initiate the PDP.” Only a single expert, Professor Komaitis, is cited in support of a PDP while several other experts are cited in opposition to it. Stacking the deck against the proposal for a PDP is inconsistent with the bylaws.

Finally, the UDRP Report fails to answer the questions posed by the GNSO Council. It does not discuss how the current UDRP addresses cybersquatting. It says nothing about how cybersquatting is effectively defined under the existing UDRP language or about whether that definition ought to be reviewed or changed. And rather than offering suggestions about how to manage a PDP, the Report offers unsolicited advice about how to avoid conducting one.

At a basic level, the UDRP Report is untimely and unresponsive. It satisfies neither the timeline prescribed by the bylaws nor the substantive criteria of an issue report required by the bylaws. Rather than assisting the GNSO Council, the Report appears to dismiss the Council’s questions and concerns and presents a one-sided advocacy brief against conducting a PDP. This it does despite the barely acknowledged unanimous support for a PDP on the UDRP expressed by the Council, the RAPWG, and the RAP-IDT.

These process failures, distinct from the merits of reviewing the UDRP or of what the UDRP should be, are significant in themselves. Even as a preliminary work product, the UDRP Report illustrates ICANN’s tendency to wink at its own rules. Nothing in the bylaws authorizes the staff to substitute its judgment for the GNSO Council’s or to misstate the level of community support for a particular policy. The UDRP Report falls short and should be rejected as inconsistent with the bylaws and with the Council’s resolution.

Information from multiple reliable sources alleges that staff members were pressured to oppose a PDP. Such reports are disappointing if true. Applying personal pressure on the staff is an odious tactic in ICANN’s multi-stakeholder community, but giving into pressure only invites more of the same. The right answer instead is for the staff to cleave to the bylaws and to advise any concerned stakeholder of the fair, open, and public opportunities to advocate a policy. Any other response damages the multi-stakeholder process by empowering a single stakeholder to prevail over every other in private.

As more fully described in comments submitted to ICANN, the UDRP Report is too flawed to be usable. The GNSO Council should formally withdraw it as inconsistent with the ICANN bylaws and direct staff to produce a new report that fully complies with the bylaws and its instructions within 15 days.

It is worth this effort for ICANN to follow the rules.

Comments are closed.