Skip to main content
Resources

Minutes | Board Governance Committee (BGC) Meeting

BGC Attendees:  Cherine Chalaby, Chris Disspain – Chair, Mike Silber, Suzanne Woolf, Gonzalo Navarro, and Bruce Tonkin

BGC Member Apologies: Erika Mann

Other Board Member Attendees:  Steve Crocker

Executive and Staff Attendees: John Jeffrey (General Counsel and Secretary), Megan Bishop (Board Support Coordinator), Michelle Bright (Board Support Manager), Liz Le (Senior Counsel), and Amy Stathos (Deputy General Counsel)


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

  1. Minutes – The BGC approved the minutes from the meeting on 18 November 2014.
  2. Reconsideration Request 14-41 – Suzanne Woolf abstained from participation in this matter noting potential conflicts; Suzanne indicated that she provides consulting services for Donuts, Inc., the parent company of Tin Dale, LLC.  Staff briefed the BGC regarding the request submitted by Afilias Limited, BRS Media Inc., and Tin Dale, LLC ("Requesters") seeking reconsideration of:  (i) the Community Priority Evaluation ("CPE") Panel's Report, and ICANN's acceptance of that report, finding that the European Broadcasting Union's ("EBU's") application for .RADIO prevailed in CPE; and (ii) ICANN staff's response to the Requesters' request pursuant to ICANN's Document Information Disclosure Policy ("DIDP") for documents relating to the CPE Panel's Report.  Requesters submitted the Request on 25 September 2014, and submitted a revised Request on 10 November 2014.  After discussion and consideration of the Reconsideration Request, the BGC concluded that the Requester has not demonstrated that the CPE Panel or ICANN acted in contravention of established policy or procedure and, therefore, determined that Request 14-41 be denied.  The Bylaws authorize the BGC to make a final determination on Reconsideration Requests brought regarding staff action or inaction and the BGC concluded that its determination on Request 14-41 is final; no consideration by the NGPC is warranted.
  3. Reconsideration Request 14-44 – Staff briefed the BGC regarding .gay LLC's ("Requester's") request seeking reconsideration of:  (i) the CPE Panel's Report, and ICANN's acceptance of that report, finding that the Requester's application for .GAY did not prevail in CPE; and (ii) ICANN staff's response to the Requesters' request pursuant to ICANN's DIDP for documents relating to the CPE Panel's Report.  Requester submitted the Request on 22 October 2014, and submitted a revised Request on 29 November 2014.  After discussion and consideration of the Reconsideration Request, the BGC concluded that, upon investigation of the Requester's claims, the CPE Panel inadvertently failed to verify 54 letters of support for the Application and that this failure contradicts an established procedure.  Specifically, the BGC discussed that the 54 letters of support were included as one piece of correspondence sent by the Requester and when the EIU inadvertently failed to verify the Requester's letter, it also inadvertently failed to verify the 53 letters that were attached to the bundle.  The BGC concluded that the CPE Panel's failure to comply with this established CPE procedure warrants reconsideration.  Accordingly, the BGC determined that the CPE Panel Report shall be set aside, and that the EIU shall identify two different evaluators to perform a new CPE for the Application.  Further, the BGC recommended that the EIU include new members of the core team that assesses the evaluation results.  The BGC asked if the EIU has since checked the other CPEs that it has conducted to confirm that the EIU attempted to verify all correspondence submitted in support or opposition of applications and staff confirmed that the EIU has conducted such a review and that no other similar situations have been identified.  With respect to the Requester's other arguments, the BGC finds that the Requester has not stated a sufficient basis for reconsideration.  The Bylaws authorize the BGC to make a final determination on Reconsideration Requests brought regarding staff action or inaction and the BGC concluded that its determination on Request 14-44 is final; no consideration by the NGPC is warranted.  See Attachment 1 for a voting statement by Mike Silber.  
  4. ATRT2 Recommendations Update – The BGC received an update on the status of the ATRT2 recommendations. 
  5. Updates – The BGC received updates on housekeeping matters including an update on the community session that the BGC will conduct at ICANN 52 on the Reconsideration and Ombudsman processes.
  6. Ombudsman's "Own Motion" Investigation – The BGC discussed and considered the ICANN Ombudsman's request for authorization to undertake his "own motion" investigation on the New gTLD Program's Community Priority Evaluation ("CPE") process.  Consideration of, and authorization for, Ombudsman's "own motion" investigations is within the BGC's scope of responsibilities under its Charter.  The Ombudsman has advised that he has received a number of different complaints about the CPE process.  Because the filing of an Ombudsman complaint triggers a stay on the status of other applications in the same contention set, the Ombudsman has suggested that it would be appropriate for him to undertake his "own motion" investigation into the issues raised in these complaints as well as the overall CPE process, rather than continue investigations on individual complaints, so as to limit interference with individual applications.  The BGC voted to authorize the Ombudsman to proceed with the "own motion" investigation he has proposed on the New gTLD Program's CPE process.

Attachment 1
Mike Silber voting Statement re: Reconsideration Request 14-44

I have read and reviewed reconsideration request 14-44, as well as the materials prepared by counsel.

I am in agreement that reconsideration is warranted in respect of the CPE Panel's failure to adhere to procedures governing the verification of support letters.

However, I am not convinced that the balance of the grounds for reconsideration are unfounded and should be rejected. Rather than vote against the reconsideration, or abstain (being, in essence a vote against) I determined to vote for the reconsideration on the ground determined and submit this voting statement with regard to the other grounds.

At the outset, I note that the reconsideration mechanism is an important accountability mechanism, which is designed to offer an important opportunity for checks and balances and review (but unlikely redress) for board and staff action (or inaction) and its judicious use can help increase (or decrease) institutional confidence.

Given that my colleagues have rejected the other grounds for reconsideration asserted by the requester, I am of the view there is little value in me analyzing each of those grounds in detail. However, as a general principle I am of the view that it would be better practice to not opine on additional matters when reconsideration has already been granted on one ground. The fact that it has been done appears to be an attempt to block any further request for reconsideration on the same issues. In addition, it should be noted that the CPE process was designed for applicants such as the requester, and the initial panel's failure to grant CPE to the requester should be carefully analyzed to assess what improvements are required for subsequent rounds.

Finally, I concur with the recommendations regarding the DIDP request, which is also at issue in reconsideration request 14-44. However, I note again that certain documents requested have been structured such that confidential information in one part prevents the disclosure of other parts, which may not be confidential. I encourage staff to proactively review the way in which contracts and other materials are drafted, such that the maximum amount of information be available for scrutiny by affected parties and that confidential information (such as financial terms) be described, be stipulated as not over-riding any other term of the document and reserved to a confidential schedule. That way the bulk of the document can be made available and affected parties can be assured that confidential schedules only contain material warranting confidentiality and nothing else. As an organization we should be moving to a situation that everything can be shared, either publically or with affected parties and only a very limited set of material should be confidential.

Published on 2 March 2015

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