[ALAC] Meeting in LA to discuss TM protection issues

Hong Xue hongxueipr at gmail.com
Tue Nov 13 08:05:52 UTC 2012


Thanks, Alan, for your detailed message. I noted IPC/BC's proposal at
IGF week and had a sense that they were making substantive demands to
expand the RMPs that have been written down. Your message actually
confirmed my guessing.

I agree we separate "implementation" from "policy-making" and subject
the latter to PDP rather a shortcut at such late stage. But I also
concern that "implementation" can be used to shield substantive
decisions on policies, with limited/restricted community involvement
and in very short period of time. Except 5-6 (7 is indeed
imcomprehensible), all involves substantive policy choices or even new
policy decisions. To me, it should all be subject to PDP or deserve at
least a decent period for cross-community inputs. Had the Brussels one
been announced? And had at-large been able to involve in it?

My Internet is hardly working so I don't know if my message can be out
at all. Anyway I trust our community can make thoughtful judgment on
this issue.

Hong




On Tue, Nov 13, 2012 at 2:42 AM, Alan Greenberg
<alan.greenberg at mcgill.ca> wrote:
> NOTE: THIS MESSAGE IS LONG, BUT WE ONLY HAVE A FEW DAYS IN WHICH TO ACT.
>
> In Toronto, The IPC and BC presented a list of suggested rights
> protection mechanisms to ICANN. The document can be found at
> http://www.icann.org/en/news/correspondence/metalitz-to-pritz-17oct12-en.pdf.
>
> The substance was the following 8 points.
>
> 1. Extend Sunrise Launch Period from 30 to 60 days with a standardized process.
> 2. Extend the TMCH and Claims Notices for an indefinite period;
> ensure the process is easy to use, secure, and stable.
> 3. Complete the URS as a low cost alternative and improve its
> usefulness - if necessary, ICANN could underwrite for an initial period.
> 4. Implement a mechanism for trademark owners to prevent second-level
> registration of their marks (exact matches, plus character strings
> previously determined to have been abusively registered or used)
> across all registries, upon payment of a reasonable fee, with
> appropriate safeguards for registrants with a legitimate right or interest.
> 5. Validate contact information for registrants in WHOIS.
> 6. All registrars active in new gTLD registrations must adhere to an
> amended RAA for all gTLD registrations they sponsor.
> 7. Enforce compliance of all registry commitments for Standard applications.
> 8. Expand TM Claims service to cover at least strings previously
> found to have been abusively registered or used.
>
> Note that these statements are rather vague in some cases, but no
> further details have been provided.
>
> A meeting to iron out differences and clarify issues on the TMCH was
> held in Brussels about 2 weeks ago. The outcomes can be found at
> http://blog.icann.org/2012/11/building-a-secure-and-reliable-trademark-clearinghouse/.
>
> There will be a follow-up meeting in Los Angeles to discuss, (perhaps
> among other things), the BBC/IPC proposals. My understanding is that
> I an likely Evan will be invited to participate (remotely since no
> travel funding is being provided).
>
> Following discussions with Evan and Olivier as well as Kathy Kleiman
> and Robin gross from NCUC, here is what I believe the current
> positions to be supported by ALAC to be.
>
> IF YOU FEEL THAT ANY OF THIS SHOULD BE CHANGED, PLEASE SPEAK UP QUICKLY.
>
> ==========================
> Our overall position is that we would prefer to not make any
> substantive changes at this late date, and particularly not ones that
> can reasonably be considered policy. This is said with the full
> understanding that throughout the new gTLD process, parts of the
> community have often considered things that they want changed to be
> "implementation", and things that they do not want changed to be
> "policy". In fact, the entire STI discussion
> (http://gnso.icann.org/issues/sti/sti-wt-recommendations-11dec09-en.pdf)
> was deemed to be one of implementation and investigating the "policy
> implications" of the TMCH and URS.  Note that some of the proposals
> are clearly not "Policy" from a GNSO point of view.
>
> That being said, it is possible that change will occur based on the
> issues raised by the BC/IPC, and the ALAC needs to consider the
> specific issues.
>
> 1. Extend Sunrise Launch Period from 30 to 60 days with a standardized process.
>
> ALAC has no strong feelings on this.My understanding is that it may
> already have been resolved during the Brussels meeting.
>
>
> 2. Extend the TMCH and Claims Notices for an indefinite period;
> ensure the process is easy to use, secure, and stable.
>
> A TM Claim sends a notice to a potential registrant that the name
> they are registering possible overlaps with a TM's term. It does not
> stop the registration, but asks that the registrant confirm that
> their use is legitimate and does not violate TM rights (since TM
> rights are specific to the type of service/product offered and a
> geographic local, this is quite possible). The STI report said that
> Post-Launch Claims are not required. The AG says that at a minimum,
> Claims must be used for 60 days following general registration
> availability. Since neither of these terms are fully defined, it is
> not clear if these two requirements conflict or are both
> simultaneously possible. One of the outcomes of the Brussels meeting
> is to firm up some definitions, so perhaps this will become clear.
> That notwithstanding, the ALAC issued a minority report to the STI
> saying that with some specific reservations, we supported ongoing TM
> Claims. So we are basically supportive of the request.
>
>
> 3. Complete the URS as a low cost alternative and improve its
> usefulness - if necessary, ICANN could underwrite for an initial period.
>
> This seems like a motherhood statement and as such ALAC has not
> problem with it. The only reservation is to the exact meaning of
> "increase its usefulness". If this is implying substantive change, we
> do need to consider it on its merits. That being said, the ALAC in
> its minority statement had supported the concept of allowing a URS
> claimant who was successful to have the domain transferred to them
> similar to what is allowed following a successful UDRP.
>
> The concept of ICANN underwriting the URS for some period of time was
> originally suggested by me, so I support it in concept. The ALAC has
> never discussed it. At this point, it looks like there will be one or
> more URS providers who can do it for the required fee without subsidization.
>
>
> 4. Implement a mechanism for trademark owners to prevent second-level
> registration of their marks (exact matches, plus character strings
> previously determined to have been abusively registered or used)
> across all registries, upon payment of a reasonable fee, with
> appropriate safeguards for registrants with a legitimate right or interest.
>
> The ALAC in its minority statement did support allowing strings to be
> registered in the TMCH which included its TM term in conjunction with
> terms related to its service/products (ie Ford-Trucks). So we *might*
> be supportive of that part of the request. However, the term
> "prevent" is onerous, even with "appropriate safeguards".
>
> We would suggest a position that this is a substantive change and
> should not be done at this time, but rather considered as in a future
> policy process. Furthermore, it is something whose value will not be
> significantly lower if it is somewhat delayed.
>
>
> 5. Validate contact information for registrants in WHOIS.
>
> The ALAC certainly supports this concept and our presumption has been
> that this will be included in the next RAA. To the extent that this
> BC/IPC request increases the pressue on ICANN to ensure that this
> happens, we support it.
>
>
> 6. All registrars active in new gTLD registrations must adhere to an
> amended RAA for all gTLD registrations they sponsor.
>
> This is already being discussed in the context of the new RAA. In
> particular, registrars believe that they should not be at a
> competitive disadvantage because some registrars stay on the old RAA
> and thus have lower costs (such as those associated with
> verification). From an ICANN point of view, there will certainly be
> sufficient compliance issues associated with new gTLDs that having
> all registrars who market them on the current RAA can only be viewed
> as good. ALAC strongly supports this.
>
>
> 7. Enforce compliance of all registry commitments for Standard applications.
>
> It is unclear exactly what this one means. Certainly ALAC supports
> any position that strengthens compliance enforcement. The reference
> to "Standard applications" is unclear. It *may* mean that like
> Community TLDs, standard (ie non-Community) TLDs should be required
> to honour the use of the TLD described in the application (currently
> there is no such requirement - they can apply for a TLD string for
> one purpose and change that purpose completely on implementation).
>
> ALAC has generally advocated such a requirement, although it seems
> like it is a bit late to impose it on applicants who have applied
> under the current rules.
>
>
> 8. Expand TM Claims service to cover at least strings previously
> found to have been abusively registered or used.
>
> This is a possibly interesting new TM protection mechanism, and is a
> probably a subset of the "TM along with related terms" statement that
> we made in our minority report. Nevertheless, it is a substantive
> change, and like item 4, should be the subject of a policy process
> prior to implementation.
>
> Alan (and Evan)
>
> _______________________________________________
> 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