[ALAC] GAC Communiqué from Toronto
alan.greenberg at mcgill.ca
Mon Oct 22 17:47:08 UTC 2012
Ron, I tend to agree with your point, although it
could be argued that they initially raised the
point because clearly ICANN had not acted on what
they believe to be clear instructions in the form
of "international instruments and national laws".
So their original request was a "wake-up" call and nothing else is reguired.
There is another aspect that I raised on the GNSO
Council list (slightly revised to make it
understandable out of the context of the thread there).
>The GAC position is that the names cannot be used.
>As Jeff Neuman has repeatedly said, the USE of
>these names may be forbidden but there is no
>requirement that registries not register them.
>There is ample precedent that registries are not
>held responsible for what people do with the
>names they register. Certain countries forbid
>the use of certain words, but that does not
>automatically put them on a reserved names list.
>If we expect all registries to deny
>registrations of these names, they must be explicitly listed in the contracts.
>Historically the reserved names list has been
>changed without the benefit of a PDP - compare:
>I am not sure if these changes were all the
>result of Board action, or simply staff action.
>In any case, we need to NOT say that a PDP is
>required for any change of that list. History
>says otherwise. And in my mind, there is no
>reason to believe that this is still not the case.
>However, given the likelihood (already
>experienced) of others saying "me too", a formal
>PDP is warranted. The fact that the GAC is
>willing to create a specific list (something I
>suggested a while ago and was told the GAC would
>*never* agree to do such operational work) makes
>it implementable if the PDP should decide that reservation is warranted.
At 22/10/2012 01:18 PM, Ron Sherwood wrote:
>Good morning, Carlton and Alan:
>It seems to me that there is conflicted
>reasoning in the GAC Communiqué from Toronto.
>"> - The GAC is questioning the need to have a
>PDP to protect the RC/IOC names since in their
>mind, the international instruments and national laws should be sufficient."
> If: "the international instruments
> and national laws should be sufficient."...
>Then: Why the specific request for
>protection of these two entities in the first place?
>Best regards, Ron
>On Mon, Oct 22, 2012 at 11:38 AM, Carlton
>Samuels <<mailto:carlton.samuels at gmail.com>carlton.samuels at gmail.com> wrote:
>Thanks for circulating this , Alan.
>It makes sense the list of those IGO for
>automatic protection begin with those eligible
>for .int registration. That may even have a few competing for acronyms.
>Given the method of developing the list, we need
>to keep a sharp eye on the extended list for protection.
>The argument regarding IOC/ROC needs further
>study since these may not enjoy the same rights
>and/or duties and/or responsibilities in the law
>of the several jurisdictions. This is where I
>think a PDP might be useful to ferret out those facts.
>Carlton A Samuels
>*Strategy, Planning, Governance, Assessment & Turnaround*
>On Sat, Oct 20, 2012 at 8:36 PM, Alan Greenberg
><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca>wrote:
> attached for your convenience.
> > Several things of particular note:
> > - The GAC is insisting that for ALL new gTLDs
> andnot just Community TLDs, the commitments
> made in their applications must be incorporated
> into their contracts and subject to compliance oversight.
> > - The GAC has added IGOs to the list of
> organizations to be protected prior to the
> delegation of the first new TLD, and that this
> protection be given to those IGOs who are
> eligible for registration under .int. They have
> committed, however, to develop a list of names
> and acronyms that should be protected (since
> registries cannot work from the .int criteria themselves).
> > - The GAC is questioning the need to have a
> PDP to protect the RC/IOC names since in their
> mind, the international instruments and national laws should be sufficient.
> > Alan
More information about the ALAC