[ALAC] [APAC-Discuss] [IDN-WG] Draft Statement on TMCH and Variants

Wed Apr 24 15:27:59 UTC 2013

What Alan says is my understanding of the topology and configuration. What
I don't know is if the proposed embraces Hong's vision for variants.

I stand to be educated but if I follow Hong's objections, it seems variants
would be part of the solution only to the extent that such marks are
considered common data items and stored in the common database.

-Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================

On Tue, Apr 23, 2013 at 7:46 PM, Alan Greenberg <alan.greenberg at mcgill.ca>wrote:

> Note that the TMCH has two separate components.
> The backend and the interface with registries is,
> I believe, a single database and is being run
> under contract to ICANN by IBM. The interface to
> TM holders and the validation service is
> contracted to Deloitte. The design explicitly
> allows for distributed user interfaces and
> validation services to ensure proper handling of
> different languages, scripts and TM law.
>
> Alan
>
> At 23/04/2013 07:17 PM, Dev Anand Teelucksingh wrote:
> >Also agree with Yaovi on removing the word "centralized"
> >And thanks to Hong and Rinala for the work done on this statement.
> >
> >Dev Anand
> >
> >On Tue, Apr 23, 2013 at 2:53 PM, Evan Leibovitch <evan at telly.org> wrote:
> > > +1
> > >
> > > In any case, the opening of offices in Turkey and Singapore makes it
> hard
> > > to argue that ICANN isn't at least making an attempt to decentralize.
> > >
> > > (Please don't see my relative silence as lack of interest, but rather
> lack
> > > of depth in the issue)
> > >
> > > - Evan
> > >
> > >
> > > On 23 April 2013 14:19, Yaovi Atohoun <yaovito at yahoo.fr> wrote:
> > >
> > >> Hi all,
> > >>
> > >> In the statement we can read :
> > >> "... we strongly urge ICANN to move away from a model that is
> centralized,
> > >> inflexible and unfriendly to variants. "
> > >>
> > >> My question : Is is not possible to have a model that is centralized
> and
> > >> taking into account IDN variant issues?
> > >> If so my recommendation is to remove the word "Centralized" in the
> > >> sentence above.
> > >>
> > >>
> > >> Yaovi
> > >>
> > >>
> > >>
> > >> ________________________________
> > >>  De : JJS <jjs.global at gmail.com>
> > >> À : Rinalia Abdul Rahim <rinalia.abdulrahim at gmail.com>
> > >> Cc : apralo <apac-discuss at atlarge-lists.icann.org>; No name <
> > >> idn-wg at atlarge-lists.icann.org>; ALAC Working List <
> > >> alac at atlarge-lists.icann.org>
> > >> Envoyé le : Dimanche 21 avril 2013 4h11
> > >> Objet : Re: [ALAC] [IDN-WG] Draft Statement on TMCH and Variants
> > >>
> > >>
> > >> *Dear Rinalia,*
> > >> *
> > >> *
> > >> *you've done a very thorough job, thank you. *
> > >> *Below, my **suggested modifications in red.*
> > >> *
> > >> *
> > >> *ALAC Advice to the ICANN Board on Trademark
> > Clearinghouse and IDN Variants
> > >> *
> > >>
> > >> The At-Large Advisory Committee (ALAC) is deeply concerned by the
> > >> implementation model outlined in the “Trademark Clearinghouse: Rights
> > >> Protection Mechanism Requirements” published
> > on April 6, 2013.  We view the
> > >> model to be deficient in that it overlooks the critical issue of IDN
> > >> variants; thus implemented, the model would clearly run against the
> public
> > >> interest in the pertinent
> > >> user communities.*
> > >> *
> > >>
> > >> *(1) Domain Name Matching*
> > >>
> > >> Language communities have requested that TMCH services factor
> IDN-script
> > >> trademarks involving variants and that ICANN consider adopting
> > >> community-based solutions to address this issue since October 2011.
> > >> Despite
> > >> concerns raised by language community experts in the TMCH
> Implementation
> > >> Assistance Group (IAG), the domain name matching requirements of the
> TMCH
> > >> still does not take into account trademarks in IDN scripts involving
> > >> variants.  Variant matching is critical in certain languages and
> > >> particularly in Chinese.  To illustrate, when a trademark
> > >> holder registers a simplified Chinese word-mark and not its
> traditional
> > >> equivalent, the TMCH will accordingly generate only one trademark
> record.
> > >> The
> > >> new gTLD registries are obliged to offer sunrise services and
> trademark
> > >> claims for trademarks recorded in the TMCH.  Without variant matching
> > >> requirements in place, only that registered simplified word-mark will
> be
> > >> eligible for trademark protection.  This leaves the traditional
> word-mark
> > >> equivalent open for cybersquatting.  Given that both simplified and
> > >> traditional writings of the word-mark are deemed identical by Chinese
> > >> communities worldwide (and by norm few trademarks are registered in
> both
> > >> writings),
> > >> ruling out the un-registered writing by not
> > allowing variant matching would
> > >> make the TMCH completely useless to Chinese
> > trademarks, and would result in
> > >> an unfair penalty against users of Chinese.
> > >>
> > >> *A More Open and Flexible TMCH Model*
> > >>
> > >> Trademarks have a very important function in safeguarding the public
> > >> interest by
> > >> identifying the source of goods and services.
> > >>
> > >> *The rest seems fine.*
> > >> *
> > >> *
> > >> *Best regards,*
> > >> *Jean-Jacques.*
> > >>
> > >>
> > >> 2013/4/20 Rinalia Abdul Rahim <rinalia.abdulrahim at gmail.com>
> > >>
> > >> > Dear Members of the IDN WG, APRALO and ALAC Colleagues,
> > >> >
> > >> > I have revised the proposed " *ALAC Advice to the ICANN Board on
> > >> Trademark
> > >> > Clearinghouse and IDN Variants*" based on Hong's draft,  input
> received
> > >> in
> > >> > Beijing and my own consultation with IDN Variant experts.
> > >> >
> > >> > Please review and comment on the draft on
> > the wiki for tracking purposes.
> > >> > The wiki page for the draft is here -
> > >> >
> > >> >
> > >>
> >
> https://community.icann.org/display/alacpolicydev/ALAC+Advice+to+the+ICANN+Board+on+Trademark+Clearinghouse+and+IDN+Variants
> > >> >
> > >> > Once the text is deemed satisfactory, it will be forwarded to the
> ALAC
> > >> for
> > >> > a vote.  Please try your best to respond with comments by Friday
> April
> > >> > 26th.
> > >> >
> > >> > Text pasted below for rapid review.  The final version will be
> proofread
> > >> > and
> > >> > a summary of recommendations will be produced as part of the final
> > >> version
> > >> > (as per our norm in giving advice to the Board).
> > >> >
> > >> > Best regards,
> > >> >
> > >> > Rinalia
> > >> >
> > >> >  *ALAC Advice to the ICANN Board on Trademark Clearinghouse and IDN
> > >> > Variants
> > >> > *
> > >> >
> > >> > The At-Large Advisory Committee (ALAC) is deeply concerned by the
> > >> > implementation model outlined in the “Trademark Clearinghouse:
> Rights
> > >> > Protection Mechanism Requirements” published on April 6, 2013.  We
> view
> > >> the
> > >> > model to be deficient in that it overlooks the critical issue of IDN
> > >> > variants, which would seriously impact the public interest in the
> > >> pertinent
> > >> > user communities.
> > >> >
> > >> > We wish to highlight two areas of particular concern in the
> Trademark
> > >> > Clearinghouse (TMCH) requirements:
> > >> >
> > >> >
> > >> >
> > >> > *(1) Domain Name Matching*
> > >> >
> > >> > Language communities have requested that TMCH services factor
> IDN-script
> > >> > trademarks involving variants and that ICANN consider adopting
> > >> > community-based solutions to address this issue since October 2011.
> > >> >  Despite
> > >> > concerns raised by language community experts in the TMCH
> Implementation
> > >> > Assistance Group (IAG), the domain name
> > matching requirements of the TMCH
> > >> > still does not take into account trademarks in IDN scripts involving
> > >> > variants.  Variant matching is critical for certain languages and
> > >> > particularly for the Chinese language.  To illustrate, when a
> trademark
> > >> > holder registers a simplified Chinese word-mark and not its
> traditional
> > >> > equivalent, the TMCH will accordingly
> > generate only one trademark record.
> > >> >  The
> > >> > new gTLD registries are obliged to offer sunrise services and
> trademark
> > >> > claims for trademarks recorded in the TMCH.  Without variant
> matching
> > >> > requirements in place, only that registered simplified word-mark
> will be
> > >> > eligible for trademark protection.  This
> > leaves the traditional word-mark
> > >> > equivalent open for cybersquatting.  Given that both simplified and
> > >> > traditional writings of the word-mark are
> > deemed identical by the Chinese
> > >> > community (and by norm few trademarks are registered in both
> writings),
> > >> > ruling out the un-registered writing by not allowing variant
> matching
> > >> would
> > >> > make the TMCH completely useless to Chinese trademarks.
> > >> >
> > >> >
> > >> > *(2) Domain Name Bundling*
> > >> >
> > >> > The TMCH requirements specifically prohibit any registry from
> > >> implementing
> > >> > “variant or bundling rules” and allocating domain names under such
> > >> “variant
> > >> > or bundling rules” prior to the conclusion
> > of the Sunrise Period.  Such a
> > >> > restriction would exclude the accommodation of any solution for IDN
> > >> > trademarks involving variants during the
> > sunrise period at the TLD level,
> > >> > even though registries may be willing to address the variants
> through
> > >> their
> > >> > own registration management and at their own expense.
> > >> >
> > >> >  *A More Open and Flexible TMCH Model*
> > >> >
> > >> > Trademarks have a very important function of safeguarding the public
> > >> > interest by
> > >> > identifying the source of goods and services.  If left unaddressed,
> the
> > >> > deficiencies of the TMCH model design may likely cause serious
> public
> > >> > confusion and result in market chaos.  In principle, the At-Large
> > >> community
> > >> > does not support over-extensive trademark protection measures.
>  However,
> > >> we
> > >> > do strongly believe that ICANN should treat all trademarks equally,
> > >> > irrespective of the characters of the
> > trademarks, and that users from all
> > >> > language communities should be protected from confusion equally.
> > >> >
> > >> >
> > >> >
> > >> > In September 2012, the ALAC statement on
> > the TMCH called for a “more open
> > >> > and flexible model” that can address our community’s concerns
> regarding
> > >> the
> > >> > limitations of a uniform model, which would be applied to all gTLD
> > >> > registries irrespective of their differences and competencies.  We
> > >> believe
> > >> > that new gTLD registries require a more open and flexible TMCH
> model to
> > >> be
> > >> > successful and we strongly urge ICANN to move away from a model
> that is
> > >> > centralized, inflexible and unfriendly to variants.
> > >> >
> > >> >
> > >> >
> > >> > In light of the considerations above, the ALAC urges the ICANN
> Board to
> > >> > call for a more open and flexible TMCH model.  Towards this end, we
> urge
> > >> > the Board to support a community-based, bottom-up solution for TMCH
> > >> > implementation and to ensure that the IDN variant issue is addressed
> > >> before
> > >> > the TMCH begin providing services to the new gTLD registries.
> > >> >
> > >> >
> > >> >
> > >> > We understand that addressing the IDN Variant issue in a holistic
> way
> > >> > requires the development of Label Generation Rules (LGR) for the
> Root
> > >> Zone,
> > >> > which experts and Staff have projected to
> > require a minimum of 12 months.
> > >> >  We
> > >> > appreciate that the LGR development requires conscientious effort to
> > >> > maintain the security and stability of the Internet, but we are also
> > >> > mindful that the business and practical requirements of new gTLD
> > >> > applicants, especially from developing economies, call for urgent
> > >> > implementation.
> > >> >
> > >> >
> > >> >
> > >> > To expedite the development of appropriate
> > solutions, the ALAC recommends
> > >> > that the Board request from the ICANN CEO an interim mechanism that
> can
> > >> > yield such solutions efficiently and on an urgent basis.  This may
> > >> require
> > >> > additional Staff with the appropriate linguistic capabilities
> working in
> > >> > tandem with community members with relevant expertise.  It may also
> > >> require
> > >> > a consideration of expediting the LGR process for the Han script.
>  We
> > >> > understand that in the general case, the handling of variants is a
> > >> complex
> > >> > issue. However, for variant cases that are well defined and
> understood,
> > >> > such as the case of the Han script, ICANN should proceed on a
> fast-track
> > >> > basis to include variant support in the TMCH in time to accommodate
> the
> > >> > delegation of the appropriate TLDs.
> > >> >
> > >> > END
> > >> > _______________________________________________
> > >> > IDN-WG mailing list
> > >> > IDN-WG at atlarge-lists.icann.org
> > >> > https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
> > >> >
> > >> > IDN WG Wiki:
> > >> > https://community.icann.org/display/atlarge/At-Large+IDN+Policy
> > >> >
> > >> _______________________________________________
> > >> 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)
> > >> _______________________________________________
> > >> 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)
> > >>
> > >
> > >
> > >
> > > --
> > > Evan Leibovitch
> > > Toronto Canada
> > >
> > > Em: evan at telly dot org
> > > Sk: evanleibovitch
> > > Tw: el56
> > > _______________________________________________
> > > 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)
> >
> >_______________________________________________
> >APAC-Discuss mailing list
> >APAC-Discuss at atlarge-lists.icann.org
> >https://atlarge-lists.icann.org/mailman/listinfo/apac-discuss
> >
> >Homepage for the region: http://www.apralo.org
>
>
> _______________________________________________
> 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)
>