[ALAC] Meeting in LA to discuss TM protection issues

Tue Nov 13 08:31:42 UTC 2012

*Dear Hong,*
*- just to let you know: yes, your message dated 13 November reached us.*
*- On substance: Hong +1.*
*Best regards,*
*Jean-Jacques.
*
2012/11/13 Hong Xue <hongxueipr at gmail.com>

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