[ALAC] Meeting in LA to discuss TM protection issues

Alan Greenberg alan.greenberg at mcgill.ca
Tue Nov 13 14:31:43 UTC 2012


Thanks Olivier.

To reiterate, over the last several years, the 
distinction between policy and implementation is 
often in the mind of those who want or do not 
want a change. Nothing that we can do about that, 
as it seems to have become a formal institutionalized policy.

On a more substantive issue, it is now two days 
before the meeting and I have still not received 
any formal notification of the meeting nor information on how to participate.

Alan

At 13/11/2012 03:35 AM, Olivier MJ Crepin-Leblond wrote:
>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