[ALAC] Meeting in LA to discuss TM protection issues

Olivier MJ Crepin-Leblond ocl at gih.com
Tue Nov 13 08:35:11 UTC 2012


Dear Alan,

thank you for your message below and your thorough analysis.
As the ALAC alternate on the STI, I can confirm that the ALAC positions
which you describe below are indeed the positions which we took during
the work of the STI, positions which yielded the TMCH as a carefully
crafted equilibrium of input from all communities taking part in the
STI. Any disruption to the equilibrium is indeed likely to re-open
Pandora's box and get everyone to revert to some of their initial wishes
thus breaking consensus.
Marilyn Cade and I discussed the BC proposals in Baku. She assured me
that *all* of the BC proposals were solely implementation - at least the
BC viewed them all as implementation. I note that some may not be. I
also note that she did not appear to know much of the ALAC's position on
any of the amendments including the ones which we were not going to be
making noise about due to the ALAC's position already described in a
minority report. I am therefore concerned that if the BC who is making
the proposals are not aware of the ALAC's position, they may not have
done their homework well to know what our position has always been.
Therefore, it is fair to assume that none of the group that has met in
Brussels (F2F or online) has done their homework.
As a result, I would urge you to not fall shy to remind everyone on this
week's call/meeting of the historical facts and tag them as facts.
Selective & fading memory is something which we should fight against.

Kind regards,

Olivier


On 12/11/2012 19:42, Alan Greenberg 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)
>

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html





More information about the ALAC mailing list