Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

The  ALAC statement on the CWG Report

Second draftThird version, modified during the community consultation conference call and reflecting minor edit suggestions by Alan Greenberg (Oct 2122, 1816:00 UTC) This text was formally submitted to the public comments process collecting community feedback on the Rec6 WG report. It has also been submitted to the ALAC for formal endorsement as advice to the ICANN Board.

The At-Large Community urges the Board to fully implement the consensus recommendations of the Rec 6 Rec6 CWG. The work of this committee working group was the very example of the multi-stakeholder, bottom-up process that ICANN claims to be its foundation. We urge the The Board to must encourage the ongoing work of the Rec 6 CWG; we Rec6 CWG. We are confident that, given some reasonable extra time, outstanding issues that have not yet reached consensus may be resolved.

At-Large has always been generally against the very principle of gTLD string objections based on "morality and public order". However, we see the Rec 6 Rec6 CWG recommendations as an effective way to attend to the most pressing needs while addressing our concerns about the existing implementation. We wholeheartedly concur with the recommendations in the report that achieved Full Consensus or Consensus. Specifically, we wish to emphasize, as strongly as possible, our support for the CWG's consensus calls to:

  • Completely eliminate the term "morality and public order";
  • Replace the function of the Dispute Resolution Service Provider through the existing resolution dispute mechanism with processes defined by recommendations 3 and 4 from the CWG Report (review to correlate to Report)Report;
  • Limit objection criteria to specific principles of international law and treaty;
  • Deny national law as a sole criteria for objections based on these criteria;
  • Resolve disputes of this nature early in the application process;
  • Require individual government objections to be made either through the Community Objections Process or through one of the ALAC and the GAC;
  • Enable the GAC and ALAC to submit objections through the Independent Objector;
  • Uphold a gTLD creation process that encourages "the true diversity of ideas, cultures and views on the Internet".

We are also committed to achieving consensus on those issues in which no resolution has yet been made, and encourage the continuation of the the CWG in these efforts. We believe that additional time in cross-community discussions would resolve them. We strongly urge support of recommendation of 14.1, to create a "Rec6 6 Community Implementation Support Team" (Rec6 CIST) to provide input to ICANN Implementation Staff as they further refine implementation details.

It is rewarding and noteworthy that these recommendations, in the main, closely resemble statements on the gTLD application process that were part of the declaration Declaration of the At-Large Summit held during the ICANN meeting of March 2009, which stated:"

We emphatically call for the complete abolition of the class of objections based on morality and public order. We assert that ICANN has no business being in (or delegating) the role of comparing relative morality and conflicting human rights.

Abolishing the morality and public order class of objection will eliminate the risk to ICANN of bearing responsibility for delegating morality judgment to an inadequate DSRP.

Certain extreme forms of objectionable strings may be addressed through

...

minor modifications to the ''Community'' class of objection. While we fully appreciate the motivation behind this class of objection, we cannot envision any application of it that will result in fewer problems than its abolition.

...

In addition, we wish to explicitly call attention to an issue that received substantial support but not consensus: that a super-majority of the Board should be required to reject gTLD applications based on these criteria.

If any of the above recommendations are seen to be "inconsistent with existing process", that is a clear indication that the "existing process" contains fundamental flaws that have been identified and must be addressed. ICANN's community has spoken in an unprecedented and unambiguous manner, and the At-Large Advisory Committee is proud of our effort to help such divergent views together to produce clear and workable policy.

...

Cross Community Working Group report on GNSO gTLD Recommendation 6 :

Wiki Markup[http://gnso.icann.org/issues/new-gtlds/report-rec6-cwg-21sep10-en.pdf|http://gnso.icann.org/issues/new-gtlds/report-rec6-cwg-21sep10-en.pdf] \ [PDF, 1.06 MB\]

Public comment announcement:

...

There was another part of the gTLD motion that is very relevant - 2.7

2.7 Role of the Board

The Board intends to approve a standard process for staff to proceed to contract execution and delegation on applications for new gTLDs where certain parameters are met.

Examples of such parameters might include: (1) the application criteria were met, (2) no material exceptions to the form agreement terms, and (3) an independent confirmation that the process was followed.

The Board reserves the right under exceptional circumstances to individually consider an application for a new gTLD to determine whether approval would be in the best interest of the Internet community, for example, as a result of the use of an ICANN accountability mechanism. The Board approves the inclusion of a broad waiver and limitation of liability in the application terms and conditions.

This motion gives staff the responsibility to approve applications is certain (presumably common and not very controversial) cases, but even in such cases, the Board reserves the right to intervene. It is not clear whether it was deliberate or an oversight, but the motion does not give staff the right to refuse an application. If this motion stands, and is interpreted as I have, this means that all refusals must come from the Board - pretty much what many on the CWG were asking for.

I think that we need to explicitly support this notion so that if the Board later changes it, we have a history trail to point back to.

...