Skip to main content
Resources

Board Governance Committee (BGC) Meeting Minutes

BGC Attendees: Cherine Chalaby, Chris Disspain, Ray Plzak, and Bruce Tonkin – Chair.

Staff Attendees: John Jeffrey – General Counsel and Secretary, Megan Bishop, Michelle Bright, Samantha Eisner, Elizabeth Le, Karine Perset, and Amy Stathos

BGC Apologies: Bertrand de La Chapelle and Ram Mohan


The following is a summary of discussion, actions taken, and actions identified:

  1. Reconsideration Request 13-8 – Staff briefed the BGC regarding Reconsideration Request 13-8 ("Request 13-8") submitted by Merck KGaA ("Requester"). Request 13-8 seeks reconsideration of the 13 July 2013 resolution (the "Resolution") of the New gTLD Program Committee ("NGPC") that permitted and encouraged dispute resolution panels to use discretion in enforcing the deadlines set forth in the Applicant Guidebook. Specifically, Request 13-8 challenges the Resolution as it relates to the community objection against Requester's application for .MERCK. The community objection was initially rejected for being filed after the published closing deadline. Requester claims that the NGPC failed to consider material information because the Resolution was based on "incomplete and improperly compiled" reports by the ICANN Ombudsman. Requester also claims that the NGPC lacks the jurisdiction to "oversee, appeal or challenge" the procedural decision of Dispute Resolution Service Providers ("DRSPs") and that the NGPC's actions constitute breaches of ICANN's Core Values. After discussion and consideration of the Request, the BGC concluded that Requester failed to state the proper grounds for reconsideration. The BGC found that the Ombudsman's reports that the NGPC considered did not address, nor were they intended to address, the rejection of the objection to .MERCK. The BGC also found that Requester's jurisdictional challenge was without merit because Article 23(a) of the New gTLD Dispute Resolution Procedure clearly provides ICANN with the jurisdiction to modify the procedures governing the dispute resolution process. Additionally, the BGC concluded that there is no support for Requester's claim that the NGPC's actions were somehow inconsistent with ICANN's Core Values. The BGC approved a recommendation to the NGPC that Request 13-8 be denied.

    • Action: Staff to submit the propose recommendation to the NGPC for consideration.
  2. Reconsideration Request 13-9 – Staff briefed the BGC regarding Reconsideration Request 13-9 ("Request 13-9") submitted by Amazon EU S.a.r.l. ("Amazon"). Request 13-9 seeks reconsideration of the Expert Determination sustaining Commercial Connect LLC's ("Commercial Connect") objection to Amazon's new gTLD application for the Japanese characters that translate into "online shopping" ("Amazon's Applied-for String") as being confusingly similar to Commercial Connect's application for .SHOP ("Commercial Connect's Applied-for String"). Amazon claims that Commercial Connect failed to provide Amazon with a copy of the objection as required by Article 7(b) of the New gTLD Dispute Resolution Procedures (the "Procedure") and that this failure is a deficiency that cannot be rectified. Amazon further claims that Commercial Connect's Objection should have been dismissed pursuant to Article 9(d) of the Procedures. Amazon also claims that the ICDR applied the wrong standard in evaluating Commercial Connect's Objection. After discussion and consideration of the Request, the BGC concluded that Amazon has not stated proper grounds for reconsideration. The BGC concluded that the dispute resolution provder complied with its obligations under the Procedure and that the acceptance of Commercial Connect's Objection did not violate any policy or process. The BGC also found that Amazon's reliance on another expert determination lacks merit. Although there are no grounds for reconsideration presented in this matter, following additional discussion of the matter, the BGC recommended that staff provide a report to the NGPC setting out options for dealing with the situation raised within this Request and Request 13-10. In addition, the BGC suggested that the strings affected by Requests 13-9 and 13-10 not proceed to contracting prior to staff's report being produced and considered by the NGPC. The BGC approved a recommendation to the NGPC that Request 13-9 be denied.

    • Actions:

      • Staff to submit the propose recommendation to the NGPC for consideration.
      • Staff to provide a report within thirty (30) days to the NGPC setting out options for dealing with the situation raised within this Request, namely the differing outcomes of the String Confusion Objection Dispute Resolution process in similar disputes involving Amazon's Applied-for String and TLDH's Applied-for String.
  3. Reconsideration 13-10 – Staff briefed the BGC regarding Reconsideration Request 13-10 ("Request 13-10") submitted by Commercial Connect, LLC ("Commercial Connect") seeking reconsideration of ICANN staff's acceptance of what Commercial Connect suggested were two inconsistent expert determinations. Specifically, Request 13-10 challenges the staff's acceptance of the Expert Determination dismissing Commercial Connect's objection to Top Level Domain Holdings Limited's ("TLDH") new gTLD application for the Chinese characters that translate into "shop" ("TLDH's Applied-for String") in light of the Expert Determination sustaining Commercial Connect's objection to Amazon EU S.a.r.l.'s ("Amazon") new gTLD application for the Japanese characters that translate into "online shopping" ("Amazon's Applied-for String"). Commercial Connect claims that the "inconsistencies" between the two expert determinations demonstrate a policy or process violation. Commercial Connect further claims that ICANN failed to provide clear and well-defined standards to the Panels, and failed to ensure that the Panels complied with the guidelines. After discussion and consideration of the Request, the BGC concluded that Commercial Connect has not identified an actual policy or process that either Panel failed to follow. The BGC found that the fact that two different Panels came to different conclusions does not mean that they inconsistently applied the standard for evaluating string confusion objections, nor does it establish a policy or process violation. With respect to the claim that ICANN failed to provide guidance to the Panels, the BGC concluded that Commercial Connect does not identify any established policy or process that required ICANN to take such action. The BGC also found that ICANN's acceptance of the determinations as advice to ICANN is also in accordance with the established process. Although there are no grounds for reconsideration presented in this matter, the BGC recommended that staff provide a report to the NGPC setting out options for dealing with the situation raised within this Request and Request 13-9. In addition, the BGC suggested that the strings affected by Requests 13-9 and 13-10 not proceed to contracting prior to staff's report being produced and considered by the NGPC. The BGC approved a recommendation to the NGPC that Request 13-10 be denied.

    • Actions:

      • Staff to submit the proposed recommendation to the NGPC for consideration.
      • Staff to provide a report within thirty (30) days to the NGPC setting out options for dealing with the situation raised within this Request regarding the differing outcomes of the String Confusion Objection Dispute Resolution process in similar disputes involving Amazon's Applied-for String and TLDH's Applied-for String.

Published on 6 December 2013

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