ICANN’s Governmental Advisory Committee seems to be trying yet again to resurrect the government right of veto over controversial new top-level domain applications.
The GAC has proposed changes to the new gTLDs Applicant Guidebook that – at least on the face of it – would remove ICANN’s power to overrule GAC objections.
The changes would also make it much more likely that a gTLD application could be killed off due to the objections of a single nation.
If adopted, they would also make the already unpredictable process of anticipating the result of GAC objections considerably more ambiguous.
The supposedly “complete” Guidebook published by ICANN last month currently includes a warning that the GAC is working on its objecting rules, and that these will be included in future.
The GAC Communique (pdf) issued at the ICANN meeting in Dakar on Friday includes these proposed rules as an annex, and they’re not great if you’re a likely new gTLD applicant.
If the GAC issues a consensus objection to an application, the Guidebook currently states that a “strong presumption” would be created that the application should fail.
But ICANN’s board would be able to overrule it with a so-called “Bylaws consultation”, the same process it used to approve .xxx earlier this year.
In its proposed revisions, the GAC inexplicably wants to delete the references to the Bylaws consultation.
My understanding is that the GAC is not proposing a change to the Bylaws, so the right of the board to initiate a consultation and overrule a GAC objection would still exist.
But the GAC seems to be asking for applicants to be given far less information about that process than they need, making its own powers appear greater than they are.
This could raise the psychological barrier to initiating a Bylaws consultation and create the perception that a consensus GAC objection always kills an application, which may not be the case.
The Dakar communique defines GAC consensus as “the practice of adopting decisions by general agreement in the absence of any formal objection”, which creates its own set of worries.
A much bigger change is proposed to the way ICANN handles GAC “concerns” about an application.
This is GAC code for a non-consensus objection, where one or more governments has a problem with an application but the GAC as a whole cannot agree to object.
This is the objection mechanism that will very likely capture applications for gTLDs such as .gay, but it could basically cover any string for any reason.
Using the Guidebook’s current wording, there would be no presumption that this kind of application should be rejected. It would be in ICANN’s discretion to initiate a Bylaws consultation.
But the GAC wants something that sounds rather a lot like a Bylaws consultation made mandatory.
“The ICANN Board is expected to enter into dialogue with the GAC to understand the scope of concerns,” it says. “The ICANN Board is also expected to provide a rationale for its decision.”
This basically means that an application for .gay that was objected to by just two or three governments would have to undergo the pretty much the same level of scrutiny as .xxx did.
The political pressure on ICANN to kill the application would be much more intense than it would under the Guidebook’s current rules.
Here’s a table of the GAC’s proposed changes.
|Applicant Guidebook||GAC Proposed Text|
|I. The GAC advises ICANN that it is the consensus of the GAC that a particular application should not proceed. This will create a strong presumption for ICANN that the application should not be approved. In the event that the ICANN Board determines to approve an application despite the consensus advice of the GAC,|
pursuant to the ICANN Bylaws, the GAC and the ICANN Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. In the event the Board determines not to accept the GAC Advice, the Board will provide a rationale for its decision.
|l. The GAC advises ICANN that it is the consensus of the GAC that a particular application should not proceed. This will create a strong presumption for the ICANN Board that the application should not be approved.|
|II. The GAC provides advice that indicates that some governments are concerned about a particular application. Such advice will be passed on to the applicant but will not create the presumption that the application should be denied, and such advice would not require the Board to undertake the process for attempting to find a mutually acceptable solution with the GAC should the application be approved. Note that in any case, that the Board will take seriously any other advice that GAC might provide and will consider|
entering into dialogue with the GAC to understand the
scope of the concerns expressed.
|ll. The GAC advises ICANN that there are concerns about a particular application "dot-example". The ICANN Board is expected to enter into dialogue with the GAC to understand the scope of concerns. The ICANN Board is also expected to provide a rationale for its decision.|
|II. The GAC advises ICANN that an application should not proceed unless remediated. This will raise a strong presumption for the Board that the application should not proceed. If there is a remediation method available in the Guidebook (such as securing government approval), that action may be taken. However, material amendments to applications are generally prohibited and if there is no remediation method available, the application will not go forward and the applicant can re-apply in the second round.||lll. The GAC advises ICANN that a particular application should not proceed unless remediated. This will raise a strong presumption for the Board that the application should not proceed unless there is a remediation method available in the Guidebook (such as securing one or more government’s approval) that is implemented by the applicant.|
In summary, the GAC wants to give more weight to fringe objections and to make the whole process potentially much more confusing for applicants.
I can’t see ICANN sensibly adding the GAC’s text to the Guidebook without at the very least some edits for clarity.