AT-LARGE GATEWAY
At-Large Regional Policy Engagement Program (ARPEP)
ALAC Liaisons and Representatives
At-Large Review Implementation Plan Development
Page History
History:
- Originally prepared November 20 by Evan Leibovitch, Chair of the At-Large gTLD Working Group, at the request of ALAC
- Revised November 23 based on input from a community meeting
- Minor changes made afterwards, based on input of community members
- Adopted unanimously, with a minor modification, by the At-Large Advisory Committee on December 7
----------------------------
The At-Large Advisory Committee (ALAC) is extremely very disappointed by the latest release of the Proposed Final Applicant Guidebook of November 12, 2010 (PAG). In significant ways its changes reflect a deliberate step backwards in some areas, away from transparency and accountability , and towards secrecy and arbitrary action. Even more importantly, the new guidebook fails at any more than cosmetic accommodation of critical, Board-mandated policy work undertaken by ICANN's grass-roots community.
The PAG contains many elements that cause concern. However the At-Large Community, in this response, has chosen to focus on the three most substantive and regressive issues which requite require our greatest attention.;
- Dispute Resolution
- Applicant Support
- The Independent Objector
After the PAG was released, based on Board and community response, stakeholders collaborated to provide feedback necessary input on two important issues:
- assistance to applicants for generic Top-Level Domains (gTLDs) in developing economies, and
- changing the process of dealing with TLD strings that might be considered obscene or objectionable (the so-called "Morality and Public Order" category of objection).
Both these issues were immediately taken up by cross-community working groups, which in unprecedented manner produced specific and concrete changes to the application process that would be consistent with existing mandates while addressing community concerns about these two important issues. In both cases, public comment has been essentially ignored.
Dispute "Resolution" (Attachment to Module 3, Article 3)
A substantial part of At-Large's long-time opposition to the Morality and Public Order objection (Module 3, Section 3.1.2.3) has been with the "Dispute Resolution Service Provider" ("DRSP"), a process that At-Large has held to be unethical, opaque, and cumbersome. The current implementation requires applicants and objectors to spend vast amounts of money on a needlessly litigious process, opening wide opportunities for gaming while forcing ICANN to make (or subcontract) judgements of comparative morality. This process provides substantial barriers to legitimate objectors while encouraging frivolous objections from well-funded parties.
In the past few months At-Large has worked intensively, together with members of the GNSO and GAC, to provide a community-wide consensus alternative process to the DRSP that would eliminate our objections. The Cross-Community Working Group ("CWG") was explicit in charting a path that is simpler and less expensive, while ensuring that objections are properly and independently evaluated well in advance of any necessary Board action. The CWG recommendations fully implement GNSO Guideline H while achieving full community consensus , and without requiring the DRSP. Critically, the CWG's consensus and "strong support" recommendations change the fundamental nature of string evaluation from a subjective comparison of morality to an objective analysis of objections against international law. Yet, with a sweeping comment of "we disagree" in its explanatory notes, ICANN has essentially shrugged off the community consensus and the fundamentally inappropriate DRSP concept remains essentially untouched in the PAG.
We believe that it is the role of support staff is to implement policy , not to agree or disagree reached by consensus whilst steering well clear of “agreeing” or “disagreeing” with interpretations. Consequently, members of At-Large who have been active participants in this process have substantial and justifiable concerns that the CWG details have been inadequately and insufficiently presented to the Board, and as a result its recommendations have not received appropriate consideration.
Applicant Support (Module 1, Section 1.2.10)
Another cross-community GNSO/ALAC effort -- to determine ways to reduce barriers to would-be applicants from developing and emerging economies -- would help demonstrate ICANN's global relevance and eagerness to expand Internet access worldwide, while closing the technology gap between rich and poor. This "Joint Applicant Support" ("JAS") working group also achieved significant consensus on many important issues and is under approval processes at both the GNSO and ALAC. Given the difficulties of properly bringing forward the CWG recommendations, we urge the Board to ensure that its briefings on this matter fully and fairly consider the working group's recommendations.
The Independent Objector (Module 3, Section 3.1.5)
On the matter of the Independent Objector ("IO"), critical safeguards of the public interest have either been removed or left out. Rather than a mechanism to prevent applicants and objectors to affect outcomes merely by out-spending their opponents, the IO has been re-architected as a tool to allow the introduction of anonymous, unaccountable, opaque objections. Upon analysing the issue ALAC the At-Large Community is now strongly of the opinion that role of the Independent Objector IO must be eliminated. While we understand its reason for creation, the potential for misuse has been made clear; any benefit it might provide will be far outweighed by its invitation for gaming and bullying. The accessibility issues that the IO was designed to address can be fulfilled if the CWG recommendations (not related to the IO) are implemented. Should the ICANN Board and staff insist -- against the public good -- to implement the IO, they must at least implement all necessary safeguards to prevent the dangers inherent in the current design.
We also note that if the IO is abolished , the significant cost savings possible can and should be achieved, and considered in the cost-recovery analysis of the gTLDs program.
Conclusions
It is unfortunate disappointing that the DAG PAG has regressed rather than progressed since its last iterationprevious version. Rather than incorporate incorporating important and clear cross-community direction, Board and Staff have dismissed it this critical input as inconvenient or , and as too much of a change from inertia that is in the wrong directionthe PAG's current dangerous inertia. According to the "explanatory memo" providing ICANN response to its community initiative, "risk managementmitigation" now appears to be a primary policy goal of ICANN -- and, conveniently, a primary obstacle to change.
Regrettably, we feel the need to be reminded remind the community of the "Plan for Organization of ICANN Staff" (May 22, 2003) which states clearly that the role of Staff is to "execute the settled policy" -- not to agree or disagree with it, or indeed affect it at all. Given that the PAG ignores or repudiates almost all of the significant cross-community consensus presented since the last revision, the At-Large Community has serious concerns about the sincerity of ICANN assertions of being a truly bottom-up process. In ICANN's being judged by actions rather than words, the PAG discredits ICANN claims of increasing accountability and transparency -- a very dangerous path indeed.
The At-Large Community remains committed to maximising benefit and minimising confusion in the creation of new gTLDs. We believe that significant gTLD growth is necessary to enhance end-user choice and healthy competition in the Internet namespace. Because of this, it is with deep regret that we must regretfully but categorically state that we consider the current PAG to be unacceptable as presented, and against the best interest of Internet end-users. We ask that these issues of concern to Internet end-users be addressed quickly so to minimize delays in the availability of new domains. Most of all, we request that the Board and staff implement ICANN's community process rather than be an obstacle to it.