[ALAC] Meeting in LA to discuss TM protection issues

Tue Nov 13 14:49:00 UTC 2012

<<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.>>

So who is responsible for that?

--------------------------------------------------
From: "Alan Greenberg" <alan.greenberg at mcgill.ca>
Sent: Tuesday, November 13, 2012 9:31 AM
To: "Olivier MJ Crepin-Leblond" <ocl at gih.com>
Cc: "ICANN GTLD WG list" <gtld-wg at atlarge-lists.icann.org>; "ALAC Working 
List" <alac at atlarge-lists.icann.org>
Subject: Re: [ALAC] Meeting in LA to discuss TM protection issues

> 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
>
>
> _______________________________________________
> 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)
> 