[ALAC] BGC decision of NCSG reconsideration request on TM+50

Hong Xue hongxueipr at gmail.com
Tue May 21 06:32:50 UTC 2013


[Alan]  the line between policy and implementation for any given issue,
MOVES over time. On a completely different issue, that of the new desired
right of ICANN to change registry agreements without the concurrence
of the registries
(and outside of Consensus Policy) seems to validate my conclusion. One of
the arguments that registries have made is that this option was already
discussed several years ago and was discarded at that time, SO IT SHOULD
NOT BE RAISED AGAIN. In effect, the elimination of that option several
years ago enshrined NOT doing it in effective policy.

[Hong] These are all interesting and valid points. The "moving" or blurring
line between policy and implementation reminds me my comments on PIC-DRP,
which is below, although it was not finally accepted in ALAC statement.

[Hong] PIC DRP, which modeled on the PDDRP for trademarks, is a flawed
system, in which ICANN struggled between its dual roles as the TLD
regulator and at the meantime the contractual party with the TLD operators.
Although, understandably, ICANN has no regulatory authority except through
the contractual relationship with TLD operators, it is not a fix to mix
both rules up. As a contractual party, ICANN should enforce the contract
without relying the third party's complaint. As a regulator, ICANN should
be able to judge whether a breach of commitment occurs without outsourcing
the assessment to a DRP proceeding, which is both costly and with high
bars. We can only hope that the compliance against new gTLDs' PIC would not
be diluted by this new DRP proceedings.

[Hong] ICANN's claim for "unilateral" right to amend the RA and our
colleague's recent paper calling for embracing inner regulator all show
that ICANN is kind of suffering from Multiple Personality Disorder (MPD).
Does ICANN has any other "legal means", except contractual relation, to
rein the other stakeholders? But a contract is supposed concluded between
two equal parties. Once ICANN exercise its "regulatory power" in name of
implementation or whatever else, it becomes more equal than the other
parties. It seems that ICANN needs to choose which way to pursue
further--contractual party or regulator? ICANN would face more conflicts
and disputes by playing the dual roles simultaneously.

Hong



On Tue, May 21, 2013 at 12:40 PM, Alan Greenberg
<alan.greenberg at mcgill.ca>wrote:

>
> http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-ncsg-16may13-en.pdf
>
> To cut to the result, the BCG rejected the request to overturn the
> inclusion of TM+50 into the TMCH.
>
> Part of the decision was based on the fact that the original TMCH
> implementation itself, a result of the STI effort, was deemed (by the
> GNSO and all of us) to be part of the IMPLEMENTATION of
> Recommendation 3 of the GNSO new gTLD PDP:
>
> >Strings must not infringe the existing legal rights of others that
> >are recognized or enforceable under generally accepted and
> >internationally recognized principles of law. Examples of these
> >legal rights that are internationally recognized include, but are
> >not limited to, rights defined in the Paris Convention for the
> >Protection of Industry Property (in particular trademark rights),
> >the Universal Declaration of Human Rights (UDHR) and the
> >International Covenant on Civil and Political Rights (ICCPR) (in
> >particular freedom of expression rights).
>
> As such, can a change or refinement to this "implementation" be
> anything other than still just implementation? This is to some extent
> supported by the minority position that the ALAC took on the STI
> report, specifically that the ALAC supported some level of TM +
> service/product being in the TMCH. We also supported common law
> trademarks in addition to registered trademarks. *IF* the STI had
> bowed to our wisdom on these issues, both of these would have been in
> the TMCH design.
>
> But the STI did not overall agree, and they did not end up in the design.
>
> Similarly, if the TM+50 had been raised during the STI and had won
> (not very likely in my opinion, just as our pet issues above did not
> win), then this too would have been part of the default implementation.
>
> Which of course now raises an interesting question.
>
> Why would these "features" have simply been part of the
> "implementation" of the TMCH is we had won the arguments in late
> 2009, but when we considered the TM+50 earlier this year, we
> forcefully felt that this was clearly policy?
>
> The answer is not obvious, and yet it seems to be at the core of the
> visceral reaction that many of us have on the question of policy vs
> implementation.
>
> I won't pretend that I have the answer to this. But I think that part
> of understanding it is to recognize that virtually all policy in the
> gTLD realm leads to implementation. Recent PDPs (and the new PDP
> process in the Bylaws) allow for an implementation team that helps
> ensure that the staff designed implementation follows both the word
> AND the intent of the policy. Indeed, one can consider that all of
> ICANN spent several years being the "implementation team" supporting
> the design of the New gTLD process and the AG.
>
> I am starting to suspect that as policy takes on a concrete form
> during implementation, in peoples minds, the arrived at
> implementation and the original policy became meld together and
> become inseparable. It is a bit of a scary conclusion, because it
> means that, in our minds, the line between policy and implementation
> for any given issue, MOVES over time.
>
> On a completely different issue, that of the new desired right of
> ICANN to change registry agreements without the concurrence of the
> registries (and outside of Consensus Policy) seems to validate my
> conclusion. One of the arguments that registries have made is that
> this option was already discussed several years ago and was discarded
> at that time, SO IT SHOULD NOT BE RAISED AGAIN. In effect, the
> elimination of that option several years ago enshrined NOT doing it
> in effective policy.
>
> I admit that much of what I have written here is really
> stream-of-consciousness (and it is a bit past midnight now!), and I
> have not fully thought it through, but I felt it important to capture
> it and I look forward to comments.
>
> Alan
>
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>



-- 
Professor Dr. Hong Xue
Director of Institute for the Internet Policy & Law (IIPL)
Beijing Normal University
http://www.iipl.org.cn/
19 Xin Jie Kou Wai Street
Beijing 100875 China



More information about the ALAC mailing list