Skip to main content

Minutes | Board Accountability Mechanisms Committee (BAMC) Meeting

Board Accountability Mechanisms Committee (BAMC) Attendees: Becky Burr, Sarah Deutsch, Chris Disspain (Chair), Nigel Roberts, and León Sanchez

Other Board Member Attendees: Tripti Sinha

ICANN Organization Attendees: Michelle Bright (Director, Board Operations), Franco Carrasco (Board Operations Specialist), John Jeffrey (General Counsel and Secretary), Vinciane Koenigsfeld (Director, Board Operations), Elizabeth Le (Associate General Counsel), Cyrus Namazi (VP, Domain Name Services & Industry Engagement, Global Domains Division), Wendy Profit (Senior Manager, Board Operations), Lisa Saulino (Board Operations Senior Coordinator), and Amy Stathos (Deputy General Counsel)

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

  1. Reconsideration Request 16-12 – The Committee received a briefing on Reconsideration Request 16-12, which was submitted by Merck KGaA (Requestor). Request 16-12 seeks reconsideration of the Community Priority Evaluation (CPE) report (CPE Report) of its community-based application for the .MERCK generic top-level domain (gTLD), and ICANN organization's acceptance of that Report. The Requestor claims that the independent provider that conducted the CPE (CPE Provider) violated established CPE procedures by misapplying CPE Criterion 2 (Nexus between Proposed String and Community) in its evaluation of the Requestor's application. Criterion 2 evaluates "the relevance of the string to the specific community that it claims to represent." (Applicant Guidebook, Module 4, § 4.2.3 at Pg. 4-13). The Requestor claims that the CPE Provider erred in finding that the applied-for string did not match the name of the community as defined in the application; nor that is it a well-known short-form or abbreviation of the community; nor did it identify the community as defined in the application. The Requestor further challenges the CPE Provider's conclusion that the applied-for string is "'over-reaching substantially beyond the community'…it defines because the applied-for string also identifies a substantial entity—Merck in the US and Canada—that is not part of the community defined by the applicant." (CPE Report, at Pgs. 3-4.) Upon discussion, the BAMC determined that while the Requestor disagrees with the CPE Provider's conclusions, it has not identified any policy or procedure that the CPE Provider violated in its determination or that ICANN org violated in accepting the CPE Report. The BAMC noted that the Requestor does not deny that the U.S.-based entity is connected to the Requestor's community as defined in its application. The BAMC concluded that the Requestor's substantive disagreement with the CPE Provider's conclusion is not grounds for reconsideration. Similarly, the BAMC found that the Requestor failed to show any policy or procedure violation in connection with the CPE Provider's determination that the Requestor's application does not satisfy Criterion 2.

    With respect to the Requestor's challenges of the CPE Process Review Reports, the BAMC determined that the claims do not support reconsideration as the Requestor has not provided any evidence of any established procedures were violated or that the Board failed to consider material information or relied on false or inaccurate information in adopting the CPE Process Review Reports.

    Accordingly, the BAMC approved a recommendation to the Board that Request 16-12 be denied.

    • Action(s): ICANN org to prepare materials for Board consideration.
  2. Reconsideration Request 16-8 – Becky Burr abstained from consideration of this item, noting potential conflicts. The Committee received a briefing on Reconsideration Request 16-8, which was submitted by CPA Australia seeking reconsideration of the CPE of its community-based application for the .CPA gTLD, and ICANN org's acceptance of the CPE Report. The Requestor claims that the CPE Provider violated established CPE procedures by misapplying CPE Criterion 2 (Nexus between Proposed String and Community) in connection with the Requestor's application. Upon discussion, the BAMC noted that Request 16-8 is untimely. According to Request 16-8, the Requestor became aware of the challenged action on 4 September 2015, but did not file the Request until 10 months later on 15 July 2016. For this reason alonem the BAMC discussed that Request 16-8 could be denied, but the BAMC proceeded, in this instance, to consider the claims of the Request.

    With respect to the claims set forth in Request 16-8, the BAMC determined that the CPE Provider did not violate any established policy or procedure when it concluded that the Requestor's application failed to satisfy sub-criterion 2-A-Nexus. The CPE Provider determined that the applied-for string (.CPA) did not "identify or match the name of the community as defined in the application, nor is it a well-known short-form or abbreviation of the community" because the string overreaches substantially beyond the community. The CPE Provider noted that the term "CPA" in the context of accounting is often used to mean Certified Public Accountant and to identify an individual who has passed a CPA exam, often in reference to the Uniform CPA Examination used in the US and elsewhere and therefore not necessarily identified as a member of the CPA Australia Community. The BAMC concluded that the CPE did not violate any process or procedure when it concluded, contrary to the argument of the Requestor, that the letter of endorsement of the Requestor's application from the American Institute of Certified Public Accountants did not change the community definition set forth in the Application, which did not include US CPAs. The Requestor cites no policy or procedure mandating that the CPE Provider accept revisions of the defined community based on third party submissions. As the CPE Report noted, it lacked authority to credit the letter in any way other than as support for the Requestor under Criterion 4: Support and Opposition. Accordingly, the BAMC approved a recommendation to the Board that Request 16-8 be denied.

    • Action: ICANN org to prepare relevant materials for Board consideration.
  3. Litigation UpdateThe BAMC received a litigation update.
  4. Any Other Business – The BAMC discussed the succession plan for the BAMC Chair.

Published on 14 January 2019

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"""" is not an IDN."