Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

  1. Consent Agenda
    1. Approval of Minutes
  2. Main Agenda
    1. GAC Advice Update
    2. Reconsideration Request 13-12, Tencent Holdings Limited
    3. Reconsideration Request 13-13, Christopher Barron/GOProud
    4. AOB
      1. Extension of Initial Protections of IGO Identifiers

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2014.01.09.NG01), the NGPC approves the minutes of the 16 November and 20 November 2013 New gTLD Program Committee Meetings.

  2. Main Agenda:

    1. GAC Advice Update

      No resolution taken.

    2. Reconsideration Request 13-12, Tencent Holdings Limited

      Whereas, Tencent Holdings Limited's ("Tencent") Reconsideration Request 13-12, sought reconsideration of the Expert Determinations on the objection of Sina Corporation ("Sina") to Tencent's applications for .微博 and .WEIBO.

      Whereas, Request 13-12 challenges the staff's acceptance of the 30 August 2013 Expert Determinations in favor of Sina's objection to Tencent's applications for .微博 and .WEIBO.

      Whereas, the Board of Governance Committee ("BGC") considered the issues raised in Request 13-12.

      Whereas, the BGC recommended that Request 13-12 be denied because Tencent has not stated proper grounds for reconsideration and the New gTLD Program Committee ("NGPC") agrees.

      Whereas, in addition to all of the materials submitted with the Request, the NGPC reviewed and considered the materials that were submitted by Tencent and Sina after the BGC issued its Recommendation on Request 13-12 and concluded that said material does not change the Recommendation of the BGC.

      Resolved (2014.01.09.NG02), the NGPC adopts the BGC Recommendation on Reconsideration Request 13-12, which can be found at http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-tencent-29oct13-en.pdf [PDF, 128 KB].

      Rationale for Resolution 2014.01.09.NG02

      1. Brief Summary

        Both the Requester Tencent and Sina applied for the same two strings .微博 (the Chinese characters for "microblogging") and .WEIBO. Sina won its Legal Rights Objection ("LRO") against Sina's applications for these two strings. The Requester claims: (i) that the LRO Panel applied a higher standard of review than what is set forth in the Applicant Guidebook, which Tencent suggests created an elevated standard of review; (ii) that ICANN's acceptance of the DRSP's decision is contrary to ICANN's mandate to act transparently and fairly; and (iii) that ICANN failed to provide guidance to the DRSP panels regarding the burden of proof. As a result, the Requester asks the Board (or here the NGPC) to reconsider ICANN's acceptance of the Expert Determinations in favor of Sina. In the alternative, Requester asks ICANN to "provide applicants of inconsistent and erroneous DRSP panel determinations, such as Tencent, with an avenue for redress that is consistent with ICANN's mandate to act with fairness." (Id.)

        The BGC concluded that: (i) there is no indication that the Expert Panel applied the wrong LRO standard; (ii) nothing supports the claim that ICANN acted in contradiction of its mandate to act transparently and fairly; and (iii) there is no identified policy or process requiring any further guidance to the DRSP panels on the burden of proof. In sum, there is no evidence to support the conclusion that ICANN's actions violated any established policy or process. Therefore, the BGC has Recommended that Request 13-13 be denied. The NGPC agrees.

      2. Facts

        1. Background Facts

          Request 13-12 involves ICANN's acceptance of an Expert Determination on two strings -- .微博 and .WEIBO. Both Sina and Tencent applied for the same two strings. Sina filed a legal rights objection (LRO) to Tencent's applications claiming that Tencent's applications violated Sina's legal rights. An expert panel deemed Sina the prevailing party, meaning that Sina "won" its objections, and Tencent "lost". Specifically, the Panel reviewed Sina's standing to object to Tencent's Applications and determined that Sina had a basis to object as the rights holder in the 微博 mark. Applying the standards for an LRO as defined in Section 3.5.2 of the Applicant Guidebook, the Panel concluded that Tencent's Applications unjustifiably impair the distinctive character of the Sina's微博mark.

          Tencent then filed Request 13-12, asking for reconsideration of the objection proceedings. Tencent is seeking reconsideration of staff's acceptance of the LRO Panel's determination, which ICANN has previously stated can be considered a staff action for the purposes of the Reconsideration process.

        2. Requester's Claims

          Tencent primarily based its Request on the argument that the LRO Panel should have applied (but did not apply) the general standard for LRO objections set forth in Section 3.5.2 of the Applicant Guidebook, which Tencent suggests created some sort of elevated standard for reviewing trademark-based objections.

      3. Issues

        The Request calls into consideration: (1) whether the Expert Panel failed to follow ICANN guidelines suggested in the Applicant Guidebook ("Guidebook") for determining an LRO (2) whether ICANN's acceptance of the LRO Panel's Determinations is contrary to ICANN's mandate to act transparently and fairly; and (3) whether ICANN's alleged failure to provide guidance to the Panel regarding burden of proof supports reconsideration.

      4. The Relevant Standards for Evaluating Reconsideration Requests

        ICANN's Bylaws call for the BGC to evaluate and make recommendations to the Board with respect to Reconsideration Requests. See Article IV, Section 2 of the Bylaws. The NGPC, bestowed with the powers of the Board in this instance, has reviewed and thoroughly considered the BGC Recommendation on Request 13-12 and finds the analysis sound.1 As noted in the BGC's Recommendation, the Reconsideration process should not ask the BGC, or the NGPC, to substantively review the LRO Panel's determination, but only to determine if any policy or process violation occurred in the consideration of the Objection.

      5. Analysis and Rationale

        The BGC found that none of the Requester's claims support reconsideration.

        First, the BGC concluded that the Requester failed to provide any evidence demonstrating that the Expert Panel failed to comply with the Guidebook. The BGC agreed with the Requester that Section 3.5.2 of the Guidebook sets out the following general standard for LRO objections:

        [A] DRSP panel of experts presiding over a legal rights objection will determine whether the potential use of the applied-for gTLD by the applicant takes unfair advantage of the distinctive character or the reputation of the objector's registered or unregistered trademark or service mark ("mark") or IGO name or acronym … or unjustifiably impairs the distinctive character or the reputation of the objector's mark or IGO name or acronym, or otherwise creates an impermissible likelihood of confusion between the applied-for gTLD and the objector's mark or IGO name or acronym.

        The BGC noted, however, that the Requester failed to recognize the remainder of the LRO standards set forth in the Guidebook that the Panel did evaluate. The Guidebook lists eight non-exclusive factors that an LRO panel should consider when determining whether an objector has satisfied the general Section 3.5.2 standard (i.e., whether an applied for gTLD "takes unfair advantage of," "unjustifiably impairs" or "creates an impermissible likelihood of confusion between" another's trademark).

        The BGC noted that the Panel did apply the eight non-exclusive factors to Sina's LRO and determined that the factors supported Sina's Objection. (Determination, Pages 5-8.) Therefore, the BGC determined that "Tencent has not established that the Panel 'failed to follow ICANN guidelines' for assessing LROs." As a result, no process violation was stated, and the BGC recommended that the Reconsideration be denied.

        Second, the BGC concluded that the Requester provides no evidence to support its claim that ICANN's acceptance of the LRO Panel determination is contrary to ICANN policy or process. The BGC noted that the requirement that ICANN accepts expert determinations as advice to ICANN was developed out of years of community discussion. If ICANN were to ignore the Expert Determination – particularly where there is no violation of policy or process – ICANN would be endorsing a violation of the Guidebook.

        Third, the BGC determined that the Requester failed to provide any factual support for its claim that ICANN "failed to explicitly define the Objector's burden of proof for the Expert panels, e.g., Preponderance of the Evidence, Clear and Convincing Evidence, etc." The Requester suggests this resulted in different panelists using different standards for the Objector's burden of proof. The BGC noted that the Requester also failed to identify the burden of proof used in its objection proceeding or what it claims the proper burden of proof should have been. Further, the Requester did not suggest that the processes set out for hearing LROs was not followed. In short, the Requester does not identify any established policy or process that required ICANN to take such action beyond what ICANN actually did – make clear in the Guidebook that the "objector bears the burden of proof in each case."

      6. Decision

        The NGPC had the opportunity to consider all of the materials submitted by or on behalf of the Requester that relate to Request 13-12, as well as materials submitted by or on behalf of the applicant. The NGPC also notes that on 26 December 2013 the Requester submitted a letter with attachments to the NGPC after the BGC issued its Recommendation. (See Attachment H to Reference Materials.) Sina also submitted a letter to the NGPC in response to Requester's 26 December 2013 letter. (See Attachment I to Reference Materials.) The letters and attachments have since been reviewed and the NGPC has determined that these materials do not alter the BGC's Recommendation or the rationale contained in that Recommendation.

        Following consideration of all relevant information provided, the NGPC reviewed and has adopted the BGC's Recommendation on Request 13-12, the full text of which can be found at http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-tencent-29oct13-en.pdf [PDF, 128 KB] and is attached to the Reference Materials to the NGPC Submission on this matter. The BGC's Recommendation on Reconsideration Request 13-12 shall also be deemed a part of this Rationale.

        In terms of timing of the BGC's Recommendation, we note that Section 2.16 of Article IV of the Bylaws provides that the BGC shall make a final determination or recommendation with respect to a Reconsideration Request within thirty days following receipt of the request, unless practical. See Article IV, Section 2.16 of the Bylaws. To satisfy the thirty-day deadline, the BGC would have to have acted by 14 October 2013. Due to the volume of Reconsideration Requests received within recent weeks, the first practical opportunity for the BGC to take action on this Request was on 29 October 2013; it was impractical for the BGC to consider the Request sooner. Upon making that determination, staff notified the requestor of the BGC's anticipated timing for the review of Request 13-12. Further, due to the volume of Reconsideration Requests and other pending issues before the NGPC, as well as scheduling conflicts due to the ICANN public meeting in Buenos Aires in November 2013 and the holiday schedule, the first practical opportunity for the NGPC to consider this Request was on 9 January 2014.

        Adopting the BGC's recommendation has no financial impact on ICANN and will not negatively impact the systemic security, stability and resiliency of the domain name system.

        This decision is an Organizational Administrative Function that does not require public comment.

    3. Reconsideration Request 13-13, Christopher Barron/GOProud

      No resolution taken.

    4. AOB

      1. Extension of Initial Protections of IGO Identifiers

        Whereas, the GAC advised the ICANN Board in the Buenos Aires Communiqué that it remained committed to continuing the dialogue with the NGPC on finalizing the modalities for permanent protection of IGO acronyms at the second level, and advised that initial protections for IGO acronyms should remain in place until the dialogue between the NGPC, the IGOs are completed.

        Whereas, the New gTLD Program Committee (NGPC) is responsible for considering the IGO GAC Advice pursuant to the authority granted to it by the Board on 10 April 2012, to exercise the ICANN Board's authority for any and all issues that may arise relating to the New gTLD Program.

        Whereas, on 17 July 2013, the NGPC approved Resolutions 2013.07.17.NG01- 2013.07.17.NG03 requiring registry operators to continue to implement temporary protections for the precise IGO names and acronyms on the "IGO List" posted as Annex 1 [PDF, 541 KB] to Resolution 2013.07.02NG03 – 2013.07.02.NG06 until the first meeting of the NGPC following the ICANN 48 Meeting in Buenos Aires or until the NGPC makes a further determination on the GAC Advice regarding IGO protections, whichever is earlier.

        Whereas, the GAC, NGPC, ICANN staff and community continue to actively work through outstanding implementation issues, the NGPC thinks it is prudent to further extend the initial protections for the IGO identifiers.

        Resolved (2014.01.09.NG03), the NGPC confirms that appropriate preventative initial protection for the IGO identifiers will continue to be provided as presented in the New gTLD Registry Agreement adopted on 2 July 2013 while the GAC, NGPC, ICANN staff and community continue to actively work through outstanding implementation issues.

        Resolved (2014.01.09.NG04), the NGPC determines that pursuant to Specification 5 in the New gTLD Registry Agreement adopted on 2 July 2013, registry operators will continue to implement temporary protections for the precise IGO names and acronyms on the "IGOList" posted as Annex 1 [PDF, 541 KB] to Resolution 2013.07.02NG03 – 2013.07.02.NG06 until the NGPC makes a further determination on the GAC advice regarding protections for IGO identifiers.

        Rationale for Resolution 2014.01.09.NG03 – 2014.01.09.NG04

        Article XI, Section 2.1 of the ICANN Bylaws http://www.icann.org/en/about/governance/bylaws#XI permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The GAC issued advice to the Board on the New gTLD Program through its Buenos Aires Communiqué dated 20 November 2013. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The Board and the GAC will then try in good faith to find a mutually acceptable solution. If no solution can be found, the Board will state in its final decision why the GAC advice was not followed.

        In the Buenos Aires Communiqué, the GAC issued additional advice regarding protections for IGO identifiers. The NGPC is being asked to consider extending the initial temporary protections afforded to IGOs in July 2013 as the parties continue to work through implementing the GAC advice.

        On 2 July 2013, the NGPC directed that temporary protections for the IGO names and acronyms previously identified by the GAC on its "IGO List dated 22/03/2013," which was attached as Annex 1 [PDF, 541 KB] the NGPC's 2 July 2013 resolutions, so that the GAC and the NGPC would have time to work out outstanding implementation issues. These initial protections were extended again on 17 July 2013 until the first meeting of the NGPC following the ICANN Meeting in Buenos Aires, Argentina, unless the NGPC and the GAC were able to resolve the issues and the NGPC passed a resolution on the GAC advice earlier than the ICANN Meeting in Buenos Aires. The NGPC agrees that it is important that those temporary protections remain in place as it continues to consider the GAC's advice on protections for IGOs as presented in the Buenos Aires Communiqué.

        The Resolution under consideration would extend the temporary protections for IGO identifiers as provided in the New gTLD Registry Agreement. As part of its consideration of this resolution, the NGPC takes note that on 29 April 2013, ICANN initiated a public comment forum to solicit input on the proposed final draft of the New gTLD Registry Agreement <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm>. The public comment forum closed on 11 June 2013. ICANN received several responses from the community during the course of the public comment forum on the proposed final draft of the New gTLD Registry Agreement; however, none of the responses specifically relates to the provisions in the New gTLD Registry Agreement to provide protections for IGO identifiers. <http://forum.icann.org/lists/comments-base-agreement-29apr13/>.

        Additionally, the NGPC takes note that the GNSO Policy Development Process Working Group tasked with addressing the issue of protecting the identifiers of certain IGOs and International Non-Governmental Organizations ("INGOs") delivered its Final Report [PDF, 645 KB] to the GNSO Council on 10 November 2013. The Working Group's consensus recommendations in the Final Report were adopted unanimously by the GNSO Council on 20 November 2013. As required by the ICANN Bylaws, public notice of the policies under consideration as well as an opportunity to comment on their adoption, prior to their consideration by the ICANN Board has been initiated. The public comment period is scheduled to close on 8 January 2014 <http://www.icann.org/en/news/public-comment/igo-ingo-recommendations-27nov13-en.htm>.

        As part of its deliberations on this issue, the NGPC reviewed the following significant materials and documents:

        The NGPC's response to the GAC advice will assist with resolving the GAC advice in manner that permits the New gTLD Program to continue to move forward, while being mindful of the ongoing efforts to work through the outstanding implementation issues.

        There are no foreseen fiscal impacts associated with the adoption of this resolution, and approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS. This is not a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment.

Published on 13 January 2014


1 Having a reconsideration process whereby the BGC reviews and, if it chooses, makes a recommendation to the Board/NGPC for approval positively affects ICANN's transparency and accountability. It provides an avenue for the community to ensure that staff and the Board are acting in accordance with ICANN's policies, Bylaws, and Articles of Incorporation.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."