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) RequirementsAdopted
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.org
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
Important Information Links
Brief Overview
Originating Organization: 
ICANN
Categories/Tags: 
  • Contracted Party Agreements
  • Intellectual Property
  • Top-Level Domains
Purpose (Brief): 

The operational requirements for implementation of the Sunrise and Trademark Claims processes in new gTLDs, and a set of community-proposed revisions, are being posted for comment to give an opportunity for the community to review and provide feedback on these requirements.

Current Status: 

This revised version of the RPM Requirements reflects updates based on community consultations, and a set of proposals from the community are being posted to allow affected stakeholders to review and provide input.

Next Steps: 

Public comment will be analyzed and taken into account by ICANN.

Staff Contact: 
Karen Lentz
Detailed Information
Section I: Description, Explanation, and Purpose: 

ICANN has published both technical requirements and operational requirements for implementation of the Sunrise and Trademark Claims services required in the New gTLD Program. The operational requirements[PDF, 349 KB] were published in draft form on 6 April 2013. A variety of feedback and comment was provided on this draft, including an open consultation [PDF, 216 KB] for interested stakeholders to provide feedback.ICANN has considered the input received and has created a revised version of the RPM Requirements [PDF, 234 KB] that is being published for comment.

A group of community stakeholders including a number of applicants has also engaged with ICANN on some identified issues and has proposed a set of revisions [PDF, 83 KB] for inclusion in the RPM Requirements, to provide greater flexibility and support for certain business objectives.

Section II: Background: 

Certain trademark protections were built into the New gTLD Program in accordance with community discussions throughout the development of the program. As specified in the gTLD Applicant Guidebook, all newgTLD registries are required to offer a set of rights protection mechanisms, including a Sunrise period and a Trademark Claims service. These are minimum requirements, to support enhanced trademark protections in the new gTLD space.

The sunrise and trademark claims services have been implemented in accordance with the goal of providing protection for verified legal rights. Registry operators have discretion to implement their TLD startup phases in accordance with their individual business and operational models, so long as the minimum requirements are met.

Section III: Document and Resource Links: 
Section IV: Additional Information: 

None


(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

FINAL VERSION TO BE SUBMITTED IF RATIFIED

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

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.    

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.

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. At-Large community notes that the revision reflects the IDN user community’s request on removal of the unreasonable restriction on the registration of the IDN variant(s) of a valid trademark data over the Sunrise Period.

Under the revised Requirements for the 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. At-Large community hails the revision the most significant improvement to prevent the user confusion that may be caused by the IDN variants that are not available in the trademark data generated by the Trademark Clearinghouse. The Revision is completely consistent with the purpose of the Trademark Claims, i.e. provision of clear notice to the prospective domain name registrant of the scope of the Trademark Holder’s rights. Even without the informational support from the Trademark Clearinghouse, the Registry Operator are obliged to ensure “all labels in a variant set against the Domain Name Label List” be availed for Trademark Claims.

Notwithstanding all the important improvements that have been made, At-Large community finds that the implementation of the revisions regarding the IDN variants completely relies on the TLD Registry Operator’s “IDN variant policies”, which will result in differentiating treatment for the same trademark in the IDN characters involving variants across the TLDs. The complexity can still potentially cause the user confusion in the IDN community. At-Large therefore calls for the ICANN to encourage the Registry Operators to implement the coherent IDN variant policies in consultation with the corresponding IDN user community. 

  • No labels

9 Comments

  1. Dear Hong,

    This is an excellent draft.  I generally agree with the statement, but there is an issue with regard to paragraph 3.

    The requirement that registries "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" works perfectly for languages with scripts that have consistent IDN tables like the Han script for the Chinese language.  This is because the result of any check involving consistent IDN tables would yield the same results.  For the Arabic script (the second most widely used writing system in the world after the Latin script), the result would not be consistent because the IDN tables for Arabic are inconsistent and would result in risks/confusion for registrants, trademark holders as well as end users. 

    I think we need to draw from the SSAC Comment on Examining the User Experience Implications on Active Variant TLDs Report Recommendation 11 that states "When registries calculate variant sets for use in validation during registration, such calculations must be done against all of the implemented LGRs covering the scrit, which the label is applied for."  Note that the SSAC refers to LGRs and not IDN Tables because there is a distinction and we can explain what that distinction is and why it is important to make that distinction. 

    We should also make a recommendation on how to mitigate the problem faced by languages/scripts with inconsistent IDN Tables.  I would be happy to draft the sections that apply to this problem.

    Rinalia

      


     

     

  2. Anonymous

    Hong has drafted an excellent statement. I am in polite disagreement with Rinalia's suggested changes as they are already accounted for in Hong's draft. As this is a statement to the Board, it is more than sufficient that the statement remains clear without being ambiguous.

    The Board is in possession of all SSAC advices and have the technical expertise necessary to ensure that their advice is accounted for. 

    1. Don't we need to supply as much clear information as possible to the Board? If there are no clear IDN tables covering a script, it would be risky to use the word "must". Perhaps could Rinalia suggest the paragraphs and we see if these could be integrated? I am really for the removal of all ambiguities in any ALAC Statements.

  3. Would this

    "At-Large community finds that the implementation of the revisions regarding the IDN variants completely relies on the TLD Registry Operator’s “IDN variant policies”, which will result in differentiating treatment for the same trademark in the IDN characters involving variants across the TLDs. The complexity can still potentially cause the user confusion in the IDN community.

    not cover the instance[s] of concern for Rinalia?

    -Carlton

  4. Since paragraph 3 really just reiterates what is in the new TMCH draft document from staff, would suggest removing it and making the last paragraph tie in with the SSAC report which should give our previous statement as well as this statement more legs.  Also further shortened first 2 paragraphs as it seems to be a repeat.  Hopefully this addresses both Hong's thoughts and Rinalia's concern.

    So suggested revision:

    ==================================

    The At-Large community supports the improvements made by ICANN in the revised Rights Protection Mechanism Requirements (RPM), released on 6 Aug 2013 (http://newgtlds.icann.org/en/about/trademark-clearinghouse/draft-rpm-requirements-06aug13-en.pdf). 

     

    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. At-Large community notes that the 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.

     

    Notwithstanding the important improvements that have been made, At-Large community finds that the implementation of the revisions regarding the IDN variants completely relies on the TLD Registry Operator’s “IDN variant policies”, which goes against both the earlier advices from ALAC (http://atlarge.icann.org/correspondence/correspondence-21may13-en.htm) and the SSAC (http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf). 

     

    ALAC therefore re-emphasizes its advice to ICANN to require the TMCH to implement IDN variant policies to ensure the integrity and consistency of user experience across new gTLDs.

  5. Please find below my proposal for the ALAC Statement on the Revised RPM and do note the following:

    1. This revised version incorporates elements from Hong's original text.  It accepts Edmon's suggestion for the ALAC to advocate for a centralized solution and goes on to explain why. 
    2. The reference to the revised RPM "going against the ALAC's previous advice" is in brackets because it is not clear that this is the case.  If the case cannot be established/clarified, the text in bracket should be removed. 
    3. The reference to the SSAC advice is moved down to the last paragraph and relevant content is cited.  It should be noted that SAC060 does not advocate for any specific option.  It highlighted the two options (centralization vs. registry reliance) and identified the strengths and the weaknesses of both. 
    4. I have also provided an elaboration as to why the Trademark Claims requirements as they are currently formulated do not serve the needs of the global IDN user community and inserted the example of the Arabic script as an illustration - note that the Arabic example is theoretically applicable to all other scripts except for the Han script based on the evidence of IDN tables submitted by IDN new gTLD applicants.  To avoid having too long a statement, the example is presented via an annex.  The ICANN board has indicated to the ALAC Leadership Team in the past that it appreciates receiving more information/context/elaboration on the ALAC's advice.  The annex serves this purpose.

    Rinalia

    ALAC Statement on Revised Rights Protection Mechanism (RPM)

    The At-Large community appreciates the improvements made by ICANN in the revised Rights Protection Mechanism Requirements (RPM) released on 6 August 2013 (http://newgtlds.icann.org/en/about/trademark-clearinghouse/draft-rpm-requirements-06aug13-en.pdf). 

    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. 

    Notwithstanding the important improvements that have been made, the At-Large community finds that the implementation of the revisions regarding the IDN variants completely relies on the TLD Registry Operator’s “IDN variant policies” [, which goes against the ALAC’s earlier advice].

    Reliance 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 1 for elaboration).

    The ALAC has emphasized in its previous advice on this matter  (http://atlarge.icann.org/correspondence/correspondence-21may13-en.htm) 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” (http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf), 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. 

    ANNEX 1

    Why the Trademark Claims Requirement Serve 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 cohesive 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, Urdhu, 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 approximately 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.    

    END

     

     

     

  6. With regards to paragraph 3, that is the information within the square bracket makes the entire statement more convoluted especially if we have already used "notwithstanding". The basic idea is to communicate our ideas very directly without confusing the reader. If we confuse the reader, they are likely to ignore the substance of the points that we wish to communicate across. I would recommend stating our recommendation in the first paragraph and then using the rest of statement to build the "why" which has already been done by Hong, Rinalia, Edmon and Carlton".

    I would suggest moving Rinalia's draft conclusive paragraph re: SSAC advice as second sentence in first paragraph. So we are to the point.

  7. Thanks for the comment, Sala.  I hope the version below is clearer.

    Rinalia

    ALAC Statement on Revised Rights Protection Mechanism (RPM)

    The At-Large community appreciates the improvements made by ICANN in the revised Rights Protection Mechanism Requirements (RPM) released on 6 August 2013 (http://newgtlds.icann.org/en/about/trademark-clearinghouse/draft-rpm-requirements-06aug13-en.pdf). 

    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  (http://atlarge.icann.org/correspondence/correspondence-21may13-en.htm) 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” (http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf), 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 1 for elaboration).

     

    ANNEX 1

    Why the Trademark Claims Requirement Serve 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 cohesive 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, Urdhu, 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.    

    END

     

     

  8. Anonymous

    I must have overlooked the discussion here until I heard yesterday from Olivier's briefing at the APRALO's call. I'm very shocked that my draft was distorted so much. The "final" one not only completely cuts off the contents on the "claims" but also adds the irrelevant contents that cannot be resolved through RPMs, either via the centralized TMCH or via each registry. 

    I declare I disagree to add the annex.