Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Comment Close
Date
Statement
Name 

Status

Assignee(s) and
RALO(s)

Call for
Comments
Call for
Comments
Close 
Vote
Announcement 
Vote OpenVote
Reminder
Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
27.08.2013Rights Protection Mechanism (RPM) RequirementsCommentingAdopted
13Y, 0N, 0A 
26.08.201302.09.201304.09.2013
00:01 UTC 
04.09.2013
00:01 UTC
09.09.201310.09.201311.09.2013Karen Lentz
karen.lentz@icann.orgTBC
AL-ALAC-ST-0913-03-01-EN
Comment / Reply Periods (*)
Comment Open Date: 
6 August 2013
Comment Close Date: 
27 August 2013 - 23:59 UTC
Reply Open Date: 
28 August 2013
Reply Close Date: 
18 September 2013 - 23:59 UTC

...

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download  a copy of the PDF below.

PDF
nameAL-ALAC-ST-0913-03-01-EN.pdf
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The At-Large community appreciates the improvements made by ICANN in the revised Rights Protection Mechanism Requirements (RPM) released on 6 August 2013

Under the revised Requirements for the Sunrise Registration, a new gTLD Registry Operator that “has implemented IDN variant registration policies for the TLD” MAY register the IDN variant(s) as far as the corresponding trademark data has been generated by the Trademark Clearinghouse.  This revision reflects the IDN user community’s persistent request on removal of the unreasonable restriction on the registration of the IDN variant(s) of a valid trademark data over the Sunrise Period. 

The ALAC has emphasized in its previous advice that the At-Large Community firmly believes that “ICANN's Rights Protection Measures should treat the trademarks in any language or character set equally, the principle being that Internet users in any language community should be equally protected against confusion.”  The variant support of the Rights Protection Mechanism must thus have universal applicability and yield a consistent user experience for all users. 

Noting the SSAC opinion that “centralizing variant generation and checking would bring consistency to the variants generated," we hereby advise ICANN to require the Trademark Clearinghouse to implement IDN variant policies itself to ensure the integrity and consistency of user experience across new gTLDs and across scripts.   

The option of relying on the TLD Registry Operator’s “IDN variant policies” has the disadvantage of resulting in differentiating IDN variant treatment for the same trademark across TLDs, which will cause inconsistent user experience as well as user confusion.  Furthermore, the revised requirements for Trademark Claims as they are currently formulated will serve only part of the global IDN user community (see Annex A for elaboration).

Annex A: Why the Trademark Claims Requirement Serves Only Part of the Global IDN User Community

Under the revised Requirements for Trademark Claims, a Registry Operator that has established IDN variant policies for allocation of domain names in the TLD “must check all labels in a variant set against the Domain Name Label List for Trademark Claims before any domain names in the set are registered.”  This requirement serves the needs of only part of the global IDN community.  For example, it serves the needs of the Chinese script community, but not the needs of the Arabic script community.  [Note: For the purpose of this elaboration, an example focusing on the Arabic script is provided below to serve as an illustration of a script that is shared across multiple languages where there is no cohesion in IDN Tables among them. This case is applicable to other scripts in a similar situation such as Latin, Cyrillic, etcetera.]

When a Registry Operator is obliged to ensure “all labels in a variant set against the Domain Name Label List” be availed for Trademark purposes, in the case of the Chinese language, the variant set generated will be the full variant set.  In the case of the Arabic script, the variant set generated may only be a sub-set of possible variants of a label.  The reason for the difference is that the Han script has cohesive IDN Tables or Label Generation Rules across registries and levels whereas the Arabic script does not.  [Note:  The Han script that is used by the Chinese language has the distinction of being the only script with cohesive IDN Tables at the present time].  The use of different IDN Tables (such as in the case of the Arabic script) can cause user confusion as well as “security, stability, or resiliency concerns or result in squatting and other issues” (see SAC 060). 

Requiring the Arabic script community to develop cohesive IDN Tables or Label Generation Rules (LGR) is not a realistic option in the short term.  The Arabic script is the second most widely used alphabetic writing system in the world after the Latin script.  It is used not only for the Arabic language, but also for non-Arabic languages such as Malay, Farsi, Urdu, Sindhi, Pashto, Punjabi, and more.  The diversity of the global Arabic Script community is such that it will require time for them to agree on cohesive IDN Tables or Label Generation Rules (and agreement is not guaranteed).  As a basis for comparison, it should be noted that the Han script community, which comprises the Chinese, Korean and Japanese languages communities, required more than a year to agree on cohesive IDN Tables and Label Generation Rules.  The implementation of the Trademark Clearinghouse cannot wait for this longer-term solution as it is uncertain how long it would take to resolve the linguistic differences.  Nevertheless, all script communities should still be encouraged to develop cohesive IDN Tables and Label Generation Rules to address issues that will arise beyond the Trademark Claims period.

Relying on the TLD Registry Operator’s “IDN variant policies” for the Arabic script in a situation where IDN Tables or Label Generation Rules are not cohesive will require an amendment to the revised Requirements.  Registry Operators must be required to generate a variant set against each label applied for during the sunrise period and to check against the entire variant set applicable for the script (i.e., variant superset and not just a possible sub-set of the variant labels).  Moreover, where there is a match with a single label in the variant set, the relevant process should be triggered for the complete set of variants generated (i.e., if the rights claim is accepted, it should be accepted for the whole set, and if the rights claim is rejected, it should be rejected for the whole variant set en bloc).  The operational challenge with this reliance on Registry Operators is Registry compliance.  Non-compliance on the part of Registries and / or lack of enforcement by ICANN will result in user confusion and affect the consistency of user experience across TLDs for the implicated script.    The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

FIRST DRAFT SUBMITTED

The At-Large community supports the improvements made by ICANN in the revised Rights Protection Mechanism Requirements (RPM), released on 6 Aug 2013, in response to the IDN user community’s persistent requests to take action in order to prevent user confusion through the appropriate management of the IDN variants that are involved in the trademark measures.

...