[IDN-WG] Fwd: Response to the ALAC Statement on TMCH and IDN Variants

Tue Jul 9 02:11:20 UTC 2013

I fully agree with all the observations of Edmon.

Edmon: [For the Sunrise process, it would be optimal but not critical for
the TMCH to also implement IDN Variants, and it could be as simple as
including them into the SMD, again based on a very simple algorithm that
needs to be implemented by the TMCH.]

Hong: for sunrise process, if ICANN resists to any technical adjustment to
TMCH, it should, at least, allow the relevant IDN registries to either
delegate or reserve the IDN domain name variants (e.g. "example" in TMCH
record should be able to link up to the variants "EXAMPLE" although it is
not in TMCH records). Otherwise, those registries would have to have a
second-round sunrise for the same strings. The current Requiments even
deprive the registries' discretion in sunrise registration, which is not
consistent with the reply that "relying on registries to handle variant
issues". How can they handle with tied hands?

It is even worse with trademark claims. Under the current interpretation,
if only "example" is in the TMCH record, anyone applies for domain names in
its IDN variant forms like "EXAMPLE", "exaMPle", "eXample" would not be
notified and the TM holder won't be notified either, which would completely
fail the whole purpose of trademak claims. Why should the TM holders submit
to a useless database and registries pay to a useless service? Of course,
the final harm would be done to the IDN users/consumers who are confused by
the counterfeit or pirate sites at the IDN variants domain names of a
trademark that should have been protected under the TMCH design.

The gaps ICANN asked us to identify are huge. But if ICANN wishes to listen
to the pertienent language community, the solution would be widely
available. For example, it has been proposed at the Chinese community to
develop a simple but efficient "Chinese Interface" attached to the TMCH
database to enable the registries that "handle" the variant characters to
use. It would not only fix the gaps but enhance the IDN registeries'
choice.

In any case, refusing to change or adjustment cannot be the solution.

P.s. the IDN WG meeting normally conflicts with ccNSO council meeting in
the afternoon. I hope another time slot be found.

Hong

On Tue, Jul 9, 2013 at 8:53 AM, Edmon <edmon at isoc.hk> wrote:

> Thanks Olivier for the note and the arrangements.  We will remain flexible
> for both.
>
> In terms of preparing for the discussion, below are some thoughts I have
> on the topic.  Others on the WG please provide your thoughts as well as we
> prepare for the meeting.
>
>
> 1. "rely on registries to handle variant issues"... the issue will more
> likely be at registrars especially the inconsistency it will have
> interfacing with the TMCH and the Registry if IDN Variants are implemented
> at the registry and not the TMCH.  This ultimately leads to confusion of
> the registrant, which negatively impacts consumer trust.
>
> 2. The GNSO has deliberated on the issue of IDN and RPM (Rights Protection
> Mechanisms) and believe they should be included in the same processes.  In
> addition the GNSO IDN WG has indicated " Agreement that measures must be
> taken to limit confusion and collisions due to variants"
>
> 3. All IDN Variant implementation and tables from registries MUST have
> been submitted (to TAS) as part of their application.  ICANN already has
> all the information necessary to provide the TMCH for implementation.
>
> 4. "There is no widely accepted definition of what constitutes a “variant”
> to a trademark." This is an irrelevant statement because we are not talking
> about a "variant" to a "trademark" but an IDN Variant to an intended domain.
>
> 5. " Given that marks from all jurisdictions can coexist in the TMCH, the
> TMCH cannot “block” submission of a record based on an existing TMCH
> record." That is correct and it is not the intent to ask for "blocking" any
> submissions, the example was provided to demonstrate the importance and the
> prevalence of such undertaking in the context of TM.  What is being asked
> is that the TMCH be technically aware of IDN Variants, not to "block"
> submissions based on IDN Variants (which the TMCH is not tasked to do
> anyway as correctly identified).
>
> 6.  " Domain Name Matching Rules", in the example it is clearly indicated
> that "EXAMPLE" matches "example" in a strict "matching", they would NOT
> match (one is in Capital letters and one in small letters) the reason they
> match is because some additional "mapping" is applied.  That is the case
> for English and Latin based marks.  I presume similar handling is provided
> for accented characters or even for Greek/Cyrillic?... The question
> therefore is why is the same not implemented for Chinese and other IDN
> languages for which IDN Variants are required.
>
> 7. " This was also generally considered to be unworkable, as it
> essentially would mean multiple customized versions of the services, which
> would reduce efficiencies and drive up cost." This statement is unfounded.
>  One implementation is sufficient which could take multiple tables.  And
> for Chinese, I believe simple study of the applications would show
> identical tables across applicants.  Such studies can easily be done, but
> have not been done and premature conclusions drawn from misunderstanding.
>
> 8. An IDN Variant is NOT "registered" as a separate domain.  That is
> perhaps the biggest misunderstanding about IDN Variants.  They are
> considered atomic to the applied for domain.  No transaction is being
> conducted.  Again, a simple study of the applications ICANN already has
> would I believe reveal that it is much less complex than what some claim
> the IDN Variants handling to be.
>
>
> All the TMCH has to implement is a simple algorithm (connected to IDN
> Tables submitted already) in its process for responding to registry
> requests for the claims process.
> For the Sunrise process, it would be optimal but not critical for the TMCH
> to also implement IDN Variants, and it could be as simple as including them
> into the SMD, again based on a very simple algorithm that needs to be
> implemented by the TMCH.
>
> The situation it seems right now (at least from my vantage point) is there
> is resistance from the TMCH to make any technical adjustments even when
> they are in reality relatively simple ones and we are forced with "work
> around" solution as described, which are wasteful of Internet resources.
>  That is not "doing it right" in my view.
>
> Edmon
>
>
>
>
>
>
> > -----Original Message-----
> > From: idn-wg-bounces at atlarge-lists.icann.org [mailto:
> idn-wg-bounces at atlarge-
> > lists.icann.org] On Behalf Of Olivier MJ Crepin-Leblond
> > Sent: Tuesday, July 9, 2013 5:53 AM
> > To: idn-wg at atlarge-lists.icann.org
> > Subject: [IDN-WG] Fwd: Response to the ALAC Statement on TMCH and IDN
> > Variants
> >
> > Dear IDN WG members,
> >
> > please be so kind to find the Board New gTLD Program Committee's reply
> > regarding the ALAC Statement on the Trademark Clearinghouse and IDN
> Variants
> > which we submitted at the end of May.
> >
> > I note that the response suggests that a small group meets with select
> Board
> > members. I have suggested that those Board members come to the A-Large
> IDN
> > WG meeting on Wednesday afternoon. Failing that, I have asked that
> Gisella & her
> > counterpart on Board Support would look for a suitable slot for a
> meeting.
> >
> > Kind regards,
> >
> > Olivier
> >
> >
> > -------- Original Message --------
> > Subject:      Response to the ALAC Statement on TMCH and IDN Variants
> > Date:         Mon, 8 Jul 2013 11:01:08 -0700
> > From:         Cherine Chalaby <cherine.chalaby at icann.org>
> > To:   Olivier MJ Crepin-Leblond <ocl at gih.com>
> >
> >
> >
> > Dear Olivier,
> >
> >
> >
> > On behalf of the New gTLD Program Committee (NGPC), I thank you for
> providing
> > the ALAC Statement on the Trademark Clearinghouse (TMCH) and
> > IDN Variants, dated 30 May 2013.   The NGPC appreciates the attention
> > the ALAC has given to this topic and has reviewed the statement
> > carefully.
> >
> > Variants are a complex topic, and the current approach with variants in
> TMCH is to
> > leave variants out of TMCH itself, and rely on registries to handle
> variant issues.
> > There are good reasons for taking such an approach and the NGPC believes
> that
> > the current direction is appropriate.
> >
> >
> >
> > Registries have their own policies for variants (whether to reserve,
> > allocate, etc.).   If, however, there are any specific gaps in behavior
> > with respect to trademarks, variants, and TMCH, it would be helpful to
> identify them
> > and raise them in the appropriate venues .  We encourage ALAC to
> identify any
> > such issues.
> >
> >
> >
> > To encourage discussion and explore specific potential gaps in more
> detail, it may
> > be helpful to have a small group of interested parties (from ALAC,
> staff, and
> > selected board members) meet in Durban. The goal of such a meeting would
> be to
> > identify specific gaps in the area of trademarks and IDN variant names
> where
> > additional work might be appropriate.
> >
> >
> > Please find attached the full response of the NGPC to the ALAC Statement.
> >
> > All the best,
> >
> > Cherine
> >
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2013.0.3345 / Virus Database: 3204/6473 - Release Date: 07/08/13
>
> _______________________________________________
> 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

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