Skip to main content
Resources

Preliminary Report | Regular Meeting of the ICANN Board

Formal Minutes are still to be approved by the ICANN Board.

Note: This has not been approved by the Board and does not constitute minutes but does provide a preliminary attempt setting forth the unapproved reporting of the resolutions from that meeting. Details on voting and abstentions will be provided in the Minutes, when approved at a future meeting.

NOTE ON ADDITIONAL INFORMATION INCLUDED WITHIN PRELIMINARY REPORT – ON RATIONALES – Where available, a draft Rationale for each of the Board's actions is presented under the associated Resolution. A draft Rationale is not final until approved with the minutes of the Board meeting.

A Regular Meeting of the ICANN Board of Directors was held in Abu Dhabi, United Arab Emirates on 29 October 2017 at 09:00 local time.

Steve Crocker, Chair, promptly called the meeting to order.

In addition to the Chair, the following Directors participated in all or part of the meeting: Rinalia Abdul Rahim, Maarten Botterman, Becky Burr, Cherine Chalaby (Vice Chair), Ron da Silva, Chris Disspain, Asha Hemrajani, Rafael Lito Ibarra, Khaled Koubaa, Markus Kummer, Akinori Maemura, Göran Marby (President and CEO), George Sadowsky, Mike Silber, and Lousewies van der Laan.

The following Board Liaisons sent their apologies: Thomas Schneider (GAC Liaison).

The following Board Liaisons participated in all or part of the meeting: Ram Mohan (SSAC Liaison), Kaveh Ranjbar (RSSAC Liaison), and Jonne Soininen (IETF Liaison).

Observing: Sarah Deutsch, Avri Doria, León Sanchez, and Matthew Shears.

Secretary: John Jeffrey (General Counsel and Secretary).

The following ICANN Executives and Staff participated in all or part of the meeting: Akram Atallah (President, Global Domains Division) Susanna Bennett (Chief Operating Officer), Duncan Burns (Senior Vice President, Global Communications), David Conrad (Senior Vice President and Chief Technology Officer), Samantha Eisner (Deputy General Counsel), Jamie Hedlund (Senior Vice President, Contractual Compliance & Consumer Safeguards), John Jeffrey (General Counsel and Secretary), Tarek Kamel (Sr Advisor To President & SVP, Government And IGO Engagement), Vinciane Koenigsfeld (Board Operations Content Manager), Elizabeth Le (Associate General Counsel), Cyrus Namazi (Vice President, Domain Name Services & Industry Engagement, Global Domains Division), David Olive (Senior Vice President, Policy Development Support), Wendy Profit (Board Operations Specialist), Erika Randall (Associate General Counsel), Ashwin Rangan (SVP Engineering & Chief Information Officer), Lisa Saulino (Board Operations Senior Coordinator), Diane Schroeder (SVP of Global Human Resources), and Amy Stathos (Deputy General Counsel.

  1. Consent Agenda:
    1. Consideration of Reconsideration Request 17-4
  2. Main Agenda:
    1. Request for New or Additional Information from the Governmental Advisory Committee re: Advice on Amazon Applications
    2. Request to Defer Compliance Enforcement of Thick WHOIS Consensus Policy for 180 Days
    3. Refinement of string similarity review in IDN ccTLD Fast Track Process

 

  1. Consent Agenda:

    The Chair provided a brief overview of the item on the Consent Agenda, and then called for a vote. The Board took the following action:

      Resolved, the following resolutions in this Consent Agenda are approved:

    1. Consideration of Reconsideration Request 17-4

      Whereas, dotgay LLC and DotMusic Limited (the Requestors) filed Reconsideration Request 17-4 (Request 17-4) challenging ICANN organization's response to the Requestors' request for documents pursuant to ICANN's Documentary Information Disclosure Policy relating to the Community Priority Evaluation (CPE) process review.

      Whereas, the Board Accountability Mechanisms Committee (BAMC) previously determined that Request 17-4 is sufficiently stated and sent the Request to the Ombudsman for review and consideration in accordance with Article 4, Sections 4.2(j) and (k) of the ICANN Bylaws.

      Whereas, the Ombudsman recused himself from this matter pursuant to Article 4, Section 4.2(l)(iii) of the Bylaws.

      Whereas, the BAMC has considered the merits of Request 17-4 and all relevant materials, and has recommended that Request 17-4 be denied on the basis that Request 17-4 does not set forth a proper basis for reconsideration, and the Board agrees.

      Whereas, the Board has also considered the Requestors' rebuttal to the BAMC's Recommendation on Request 17-4 and concludes that the rebuttal provides no additional argument or evidence to support reconsideration.

      Resolved (2017.10.29.01), the Board adopts the BAMC Recommendation on Request 17-4 [PDF, 273 KB].

      All members of the Board present voted in favor of Resolution 2017.10.29.01. One member of the Board was unavailable to vote on the Resolution. The Resolution carried.

      Rationale for Resolution 2017.10.29.01

      1. Brief Summary

        The Requestors dotgay LLC (dotgay) and DotMusic Limited (DotMusic) submitted community-based applications for .GAY and .MUSIC, respectively; both applications participated in CPE and neither prevailed. In October 2015, dotgay sought reconsideration of the CPE outcome (Request 15-21),1 which the Board Governance Committee (BGC)2 denied.3 In February 2016, dotgay sought reconsideration of the BGC's denial of Request 15-21 (see Request 16-3).4 In February 2016, DotMusic sought reconsideration of the CPE determination and approval of DotMusic's application (Request 16-5).5

        Subsequently, the ICANN Board directed the President and CEO, or his designee(s), to undertake a review of the process by which ICANN organization interacted with the CPE provider (CPE Process Review). The BGC later decided that the CPE Process Review should also include the reference materials relied upon by the CPE provider for the evaluations, which are the subject of pending Requests for Reconsideration concerning CPE. The BGC placed the eight pending reconsideration requests relating to CPE on hold, including Requests 16-3 and 16-5, pending completion of the CPE Process Review.

        On 10 June 2017, the Requestors submitted a Joint DIDP Request seeking documents and information relating to the CPE Process Review, some of which the Requestors had sought in prior DIDP requests. (See Joint DIDP Request, attached as Attachment E to the Reference Materials.) ICANN organization's response (Response to Joint DIDP Request, attached as Attachment F to the Reference Materials) explained that, except for certain documents that were subject to DIDP Defined Conditions for Nondisclosure (Nondisclosure Conditions), all other responsive documents had been published and identified in response to the Requestors' prior DIDP requests.6 (See id.) The Response to Joint DIDP Request provided hyperlinks to the responses to the prior DIDP requests, which in turn identified and provided hyperlinks to publicly available responsive documents. (See id. at Pg. 2.) The Response to Joint DIDP Request further explained that two items (Item Nos. 2 and 4) did not seek documentary information in existence within ICANN. (See id.) Additionally, the Response to Joint DIDP Request explained that ICANN organization evaluated responsive documents subject to Nondisclosure Conditions to determine if the public interest in disclosing them outweighed the harm of disclosure, and determined that there were no circumstances for which the public interest in disclosing the information outweighed the potential harm of disclosing the documents. (See id. at Pg. 3.)

        The Requestors then filed Reconsideration Request 17-4 (Request 17-4) challenging the Response to Joint DIDP Request. (See Request 17-4, attached as Attachment A to the Reference Materials.) The Requestors suggest that reconsideration of the Response to Joint DIDP Request is warranted because ICANN organization violated ICANN's Core Values, established DIDP policies and the Bylaws concerning non-discriminatory treatment, transparency, and accountability. (See id. at §8, Pg. 21.)

        The BAMC considered Request 17-4 and all relevant materials and recommended that the Board deny Request 17-4 because it does not set forth a proper basis for reconsideration for the reasons set forth in the BAMC Recommendation on Reconsideration Request 17-4 (the BAMC Recommendation), which Recommendation has been considered and is incorporated here. (See BAMC Recommendation [PDF, 273 KB], attached as Attachment D to the Reference Materials.)

        On 26 October 2017, the Requestors submitted a rebuttal to the BAMC's Recommendation (Rebuttal), pursuant to Article 4, Section 4.2(q) of ICANN's Bylaws. (See Rebuttal, attached as Attachment G to the Reference Materials.) The Requestors suggest that: (1) Request 17-4 was within the scope of the reconsideration process because "[t]he reconsideration process permits review of an action or inaction—not just the process used to take the action"; (2) "[t]he DIDP relates to ICANN [organization's] Commitments and Core Values, which require transparency"; and (3) ICANN organization violated its commitments to transparency, accountability, and fairness in the Response to Joint DIDP Request. (See id.)

      2. Facts and Recommendation

        The full factual background is set forth in the BAMC Recommendation [PDF, 273 KB], which the Board has reviewed and considered, and which is incorporated here.

        On 11 October 2017, the BAMC recommended that Request 17-4 be denied on the basis that Request 17-4 does not set forth a proper basis for reconsideration for the reasons set forth in the BAMC Recommendation [PDF, 273 KB], which the Board has considered and which are incorporated here.

        On 26 October 2017, the Requestors submitted a rebuttal to the BAMC's Recommendation, pursuant to Article 4, Section 4.2(q) of ICANN organization's Bylaws, which the Board has also considered.

      3. Issues

        The issues for reconsideration are7:

        • Whether ICANN organization complied with established ICANN policies in responding to the Joint DIDP Request.
        • Whether ICANN organization complied with its Core Values, Mission, and Commitments in responding to the Joint DIDP Request.
      4. The Relevant Standards for Evaluating Reconsideration Requests

        Article 4, Sections 4.2(a) and (c) of ICANN's Bylaws provide in relevant part that any entity may submit a request "for reconsideration or review of an ICANN action or inaction to the extent that it has been adversely affected by:

        1. One or more Board or Staff actions or inactions that contradict ICANN's Mission, Commitments, Core Values and/or established ICANN policy(ies);
        2. One or more actions or inactions of the Board or Staff that have been taken or refused to be taken without consideration of material information, except where the Requestor could have submitted, but did not submit, the information for the Board's or Staff's consideration at the time of action or refusal to act; or
        3. One or more actions or inactions of the Board or Staff that are taken as a result of the Board's or staff's reliance on false or inaccurate relevant information.

        (ICANN Bylaws, 22 July 2017, Art. 4, §§ 4.2(a), (c).) Pursuant to Article 4, Section 4.2(k) of the Bylaws, if the BAMC determines that the Request is sufficiently stated, the Request is sent to the Ombudsman for review and consideration. (See id. at § 4.2(l).) If the Ombudsman recuses himself from the matter, the BAMC reviews the Request without involvement by the Ombudsman, and provides a recommendation to the Board. (See id. at § 4.2(l)(iii).) The Requestor may file a rebuttal to the BAMC's recommendation, provided that the rebuttal is: (i) "limited to rebutting or contradicting the issues raised in the BAMC's recommendation; and (ii) not offer new evidence to support an argument made in the Requestor's original Reconsideration Request that the Requestor could have provided when the Requestor initially submitted the Reconsideration Request." (See id. at § 4.2(q).) Denial of a request for reconsideration of ICANN action or inaction is appropriate if the BAMC recommends and the Board determines that the requesting party has not satisfied the reconsideration criteria set forth in the Bylaws. (See id. at § 4.2(e)(vi), (q), (r).)

      5. Analysis and Rationale

        The Board has reviewed and thoroughly considered Request 17-4 and all relevant materials, including the BAMC Recommendation. The Board finds the analysis set forth in the BAMC Recommendation [PDF, 273 KB], which is incorporated here, to be sound. The Board has also considered the Requestors' Rebuttal to the BAMC Recommendation. The Board finds that the Rebuttal does not raise arguments or facts that support reconsideration.

        1. ICANN Organization Adhered To Established Policies And Procedures In Responding To The Joint DIDP Request.

          The BAMC concluded and the Board agrees that the Response to Joint DIDP Request complied with applicable policies and procedures. (BAMC Recommendation [PDF, 273 KB], Pgs. 16-27.) In responding to a request for documents submitted pursuant to the DIDP, ICANN organization adheres to the "Process For Responding To ICANN's Documentary Information Disclosure Policy (DIDP) Requests" (DIDP Response Process). (See DIDP Response Process [PDF, 59 KB].) The DIDP Response Process provides that "[u]pon receipt of a DIDP Request, ICANN staff performs a review of the Request and identifies what documentary information is requested . . ., interviews . . . the relevant staff member(s) and performs a thorough search for documents responsive to the DIDP Request." (Id.) Once the documents collected are reviewed for responsiveness, a review is conducted to determine if the documents identified as responsive to the Request are subject to any of the Nondisclosure Conditions set forth on the DIDP web page at https://www.icann.org/resources/pages/didp-2012-02-25-en. If so, a further review is conducted to determine whether, under the particular circumstances, the public interest in disclosing the documentary information outweighs the harm that may be caused by such disclosure. (See DIDP Response Process [PDF, 59 KB].)

          Consistent with the DIDP Response Process, the Response to Joint DIDP Request explained that, except for certain documents that were subject to Nondisclosure Conditions, all other responsive documents had been published and identified in response to the Requestors' prior DIDP requests. (See Response to Joint DIDP Request [PDF, 214 KB], Pg. 2.) For Item Nos. 1 and 3, ICANN organization determined that all of the responsive documentary information already had been published on ICANN's website, and provided to the Requestors in response to prior DIDP requests. (See id. at 2.) The DIDP responses to those requests identified and provided the hyperlinks to 21 publicly available documents and websites compiling documents that contain information responsive to Item Nos. 1 and 3. (See id.) The Response to Joint DIDP Request further explained that two Items (Items No. 2 and 4) did not seek documentary information in existence within ICANN. (See id.) Notwithstanding this requirement, ICANN organization provided significant information responsive to Item Nos. 2 and 4 in the Status Update and in an earlier CPE Process Review update, and provided hyperlinks to those updates. (See id. at 2-3.) Additionally, the Response to Joint DIDP Request explained that some of the documents responsive to Item Nos. 2 and 4 were subject to certain identified Nondisclosure Conditions. (See id.) The Response to Joint DIDP Request further explained that ICANN organization evaluated responsive documents subject to Nondisclosure Conditions, as required, and determined that there were no circumstances for which the public interest in disclosing the information outweighed the potential harm of disclosing the documents. (See id. at 3.)

          The Requestors suggest that reconsideration is warranted because ICANN organization violated ICANN's Core Values and policies established in the DIDP and Bylaws concerning non-discriminatory treatment, transparency, and accountability in its response to Items No. 1 through 4. (See Request 17-4, § 8, Pg. 21.) Additionally, the Requestors suggest that the ICANN organization's determinations as to the applicability of the specified Nondisclosure Conditions in response to Items No. 2 and 4 warrant reconsideration because it "is in the public's interest to disclose" those documents. (Id. at § 8, Pg. 22.)

          The BAMC determined, and the Board agrees, that Requestors' position is not supported because ICANN organization did adhere to established policies and procedures in responding to the DIDP Request. (See BAMC Recommendation [PDF, 273 KB], Pgs. 16-27.) The Requestors do not claim that the Response to Joint DIDP Request is contrary to the DIDP Response Process, nor do the Requestors provide any information to show how ICANN organization's Response to Joint DIDP Request violates ICANN's Mission, Commitments, or Core Values. (See id.) The BAMC further concluded, and the Board agrees, that ICANN organization complied with the DIDP Process in evaluating the responsive documents subject to Nondisclosure Conditions, as required, and determined that there were no circumstances for which the public interest in disclosing the information outweighed the potential harm of disclosing the documents. (See id. at 21-26.) While the Requestors might believe that ICANN organization should have exercised its discretion differently, that is not a basis for reconsideration.

        2. The Requestors' Unsupported References to ICANN Commitments and Core Values Do Not Support Reconsideration of the Response to Joint DIDP Request.

          The Requestors suggest that ICANN organization violated the following Commitments and Core Values in the Response to Joint DIDP Request: Article 1, Sections 1.2(a), 1.2(a)(v), 1.2(a)(vi) and Article 3, Section 3.1 of the ICANN Bylaws. (See Request 17-4, § 6, Pgs. 5-7.) However, as the BAMC concluded, and the Board agrees, the Requestors provide no explanation for how these Commitments and Core Values relate to the Response to Joint DIDP Request at issue in Request 17-4 or how ICANN organization might have violated these Commitments and Core Values. (See BAMC Recommendation [PDF, 273 KB], Pgs. 26-27.) As such, the Requestors have not established grounds for reconsideration through its list of Commitments and Core Values.

        3. The Rebuttal Does Not Raise Arguments or Facts That Support Reconsideration.

          The Board has considered the Requestors' Rebuttal and finds that the Requestors have not provided any additional arguments or facts supporting reconsideration.

          The Rebuttal claims that: (1) Request 17-4 was within the scope of the reconsideration process because "[t]he reconsideration process permits review of an action or inaction—not just the process used to take the action"; (2) "[t]he DIDP relates to ICANN [organization's] Commitments and Core Values, which require transparency"; and (3) ICANN organization violated its commitments to transparency, accountability, and fairness in the Response to Joint DIDP Request. (See Rebuttal.)

          With respect to the first claim, the Board has considered Request 17-4 and all relevant materials, the BAMC's Recommendation, and the Rebuttal, and finds that reconsideration is not warranted. The Reconsideration Request process provides a vehicle for requestors to seek reconsideration of ICANN organization's "action or inaction to the extent that the requestor has been adversely affected by … [o]ne of more Board or Staff actions or inactions that contradict ICANN's Mission, Commitments, Core Values, and/or established ICANN policy(ies)." (ICANN Bylaws, Art. 4, Section 4.2(c)(i).) Reconsideration is appropriate if the Requestor demonstrates that the action or inaction contradicts "ICANN's Mission, Commitments, Core Values and/or established ICANN policy(ies)." (Id.; see also, e.g., Board Determination on Request 17-3, https://www.icann.org/resources/board-material/resolutions-2017-09-23-en#2.b; Board Determination on Request 17-1, https://www.icann.org/resources/board-material/resolutions-2017-06-24-en#2.d.)8 A Reconsideration Request that challenges the outcome of ICANN organization's action or inaction without any supporting evidence beyond the requestor's dissatisfaction with that outcome does not meet the standard for reconsideration. Similarly, a Reconsideration Request that does not explain how the challenged action or inaction contradicted ICANN organization's Mission, Commitments, Core Values, and/or established ICANN policy(ies), without more, cannot justify reconsideration.

          The Requestors state that "reconsideration requests provide an opportunity to re-examine an action or inaction." (Rebuttal, Pg. 3.) That is precisely what occurred here. Indeed, notwithstanding the Requestors' failure to demonstrate that ICANN organization's actions or inaction violated its Mission, Commitments, Core Values, and/or established ICANN policy(ies), the BAMC evaluated the Response to Joint DIDP Request to determine if such a violation did occur. The BAMC concluded, and the Board agrees, that ICANN organization's action in the Response was consistent with its Mission, Commitments, Core Values, and established policies. (BAMC Recommendation, Pgs. 16-27.)

          Second, the Requestors argue that "ICANN must comply with its Commitments and Core Values during the DIDP," because "[t]he DIDP is clearly related to these Commitments and Core Values." (Rebuttal, Pgs. 4-5.) However, the Response to Joint DIDP Request did comply with ICANN organization's Commitments and Core Values. The DIDP implements ICANN's Commitments and Core Values supporting transparency and accountability by setting forth a procedure through which documents concerning ICANN organization's operations and within ICANN's organization's possession, custody, or control are made available to the public unless there is a compelling reason for confidentiality. (See DIDP, https://www.icann.org/resources/pages/didp-2012-02-25-en) But neither the DIDP nor ICANN organization's Commitments and Core Values supporting transparency and accountability obligates ICANN organization to make public every document in ICANN organization's possession. As the Panel in the Amazon EU S.A.R.L. v. ICANN Independent Review Process Panel noted earlier this year:

          [N]otwithstanding ICANN's transparency commitment, both ICANN's By-Laws and its Publication Practices recognize that there are situations where non-public information, e.g., internal staff communications relevant to the deliberative processes of ICANN . . . may contain information that is appropriately protected against disclosure.

          (Amazon EU S.A.R.L. v. ICANN, ICDR Case No. 01-16-000-7056, Procedural Order (7 June 2017), at Pg. 3.) ICANN organization's Bylaws address the need to balance competing interests such as transparency and privacy, noting that "in any situation where one Core Value must be balanced with another, potentially competing Core Value, the result of the balancing test must serve a policy developed through the bottom-up multistakeholder process or otherwise best serve ICANN's Mission." (ICANN Bylaws, Art. I, Section 1.2(c).) The DIDP sets forth a test for balancing privacy concerns, such as privilege and protecting the deliberative process, which support ICANN organization's Core Values of operating with efficiency and excellence and "striving to achieve a reasonable balance between the interests of different stakeholders while also avoiding capture", against the Core Value of transparency. (Id. at Sections 1.2(b)(v) and 1.2(b)(vii).) Accordingly, ICANN organization may appropriately exercise its discretion, pursuant to the DIDP, in determining that certain documents are not appropriate for disclosure without contravening its commitment to transparency.

          Third, the Requestors claim that the Response to Joint DIDP Request contradicted ICANN's Commitments and Core Values supporting transparency, fairness, and accountability. (Rebuttal, Pgs. 9-10.) The Board finds that these arguments are not supported.

          With respect to ICANN's commitment to transparency, the Requestors suggest that ICANN organization should have disclosed all requested documents, or at least "identif[ied] the documents subject to [Nondisclosure] Conditions and explain[ed] how the Nondisclosure Conditions apply." (Id. at Pg. 6.) As discussed above, ICANN organization adhered to established policies and procedures, including ICANN's commitment to transparency, in finding certain of the requested documents subject to DIDP Nondisclosure Conditions. Further, the Board finds that the Response to Joint DIDP Request Process does not require ICANN organization to identify the Nondisclosure Condition applicable to each individual document withheld; indeed, such a requirement could place an undue burden on ICANN. Here, the BAMC sufficiently explained how the Nondisclosure Conditions applied to the documents that ICANN organization determined were not appropriate for disclosure. Specifically, consistent with the Response to Joint DIDP Request Process, the BAMC explained that the requested materials contained internal drafts, materials that could compromise the integrity of the deliberative and decision-making process with respect to the CPE Process Review, and materials subject to the attorney-client or other privileges. (BAMC Recommendation, Pgs. 23-24.) Ultimately, the Requestors have not shown that ICANN organization failed to follow the DIDP or that the Response to Joint DIDP Request contradicted ICANN's Commitments and Core Values supporting transparency, fairness, and accountability.

          The Requestors also suggest that ICANN's Commitments and Core Values supporting transparency and fairness required ICANN organization to disclose the requested materials even if certain Nondisclosure Conditions apply, because the CPE Review Process is "significant to Requestors" and others, because "[t]he public is clearly interested" in the requested documents, and because the Requestors suspect "there is little harm in disclosure of [the] documents." (Rebuttal, Pgs. 6-8.) "Public interest" is not determined by whether any entity is "interested" in a matter, but whether an action was in the overall "public interest." Further, the DIDP gives ICANN organization the discretion to decide if, "under the particular circumstances, . . . the public interest in disclosing the information outweighs the harm that may be caused by such disclosure." (DIDP webpage, https://www.icann.org/resources/pages/didp-2012-02-25-en.)

          As explained in the Response to Joint DIDP Request, ICANN organization evaluated the documents that were subject to Nondisclosure Conditions to determine if the public interest (including transparency and fairness concerns) in disclosing them outweighed the harm that may be caused by such disclosure, and concluded that the public interest did not warrant the harm that would be caused by disclosure under these circumstances. (See Response to Joint DIDP Request, Pg. 2-3.) As noted above, the Requestors believe that ICANN organization should have exercised its discretion differently, but that is not a basis for reconsideration because the Requestors have not shown that ICANN organization contravened the DIDP in any way.

          The Requestors also suggest that ICANN "has closed-off the possibility of obtaining additional information [about the CPE Process Review] in clear contradiction of its own stated Commitment to and Core Value of transparency. (Rebuttal, Pg. 7.) Similarly, the Requestors suggest that ICANN organization "has restricted . . . access to information regarding the [CPE Process Review] in a blatantly unfair decision that keeps affected uninformed and raises several red flags regarding the integrity of the independent review itself," and that "ICANN has prohibited informed participation in the [CPE Process Review] by the Internet Community." (Id. at Pgs. 9-10.) The Board notes that the BGC and ICANN organization have provided several updates concerning the CPE Process Review, including one on 1 September 2017. (https://www.icann.org/news/announcement-2017-09-01-en.) Additionally, and as noted in the 1 September 2017 update, the CPE Process Review is still ongoing. When the CPE Process Review is complete, additional information will be made available to the ICANN community, including to the Requestors.

          This action is within ICANN's Mission and is in the public interest as it is important to ensure that, in carrying out its Mission, ICANN is accountable to the community for operating within the Articles of Incorporation, Bylaws, and other established procedures, by having a process in place by which a person or entity materially affected by an action of the ICANN Board or Staff may request reconsideration of that action or inaction by the Board.

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

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

  2. Main Agenda:

    1. Request for New or Additional Information from the Governmental Advisory Committee re: Advice on Amazon Applications

      The Chair of the Board Accountability Mechanisms Committee introduced the agenda item. Becky Burr noted potential conflicts of interest and abstained from voting. Staff provided a summary of the background concerning the Governmental Advisory Committee (GAC) advice about the New gTLD Program applications for .AMAZON and equivalent gTLDs in Chinse and Japanese. As part of the background briefing, staff highlighted the Amazon EU S.à.r.l. v. ICANN Independent Review Process (IRP). Staff also noted previous consideration by the Board and the BAMC of the IRP Final Declaration.

      The Board considered the recommendation from the BAMC to ask the GAC if it has any other new or additional information to provide to the Board regarding the GAC's advice that the Amazon applications should not proceed. After discussion, the Board took the following action:

      Whereas, the Final Declaration in the Amazon EU S.à.r.l. (Amazon) v. ICANN Independent Review Process (IRP) was issued on 11 July 2017.

      Whereas, in the Final Declaration, the Panel recommended that the Board "promptly re-evaluate Amazon's applications" and "make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon's applications." (Final Declaration at ¶ 125.)

      Whereas, in accordance with Article IV, section 3.21 of the applicable version on the Bylaws, the Board considered the Final Declaration at its 23 September 2017 meeting and determined that further consideration was needed regarding the Panel's non-binding recommendation that the Board "promptly re-evaluate Amazon's applications" and "make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon's applications."

      Whereas, the Board asked the Board Accountability Mechanisms Committee (BAMC) to review and consider the Panel's recommendation that the Board "promptly re-evaluate Amazon's applications" and "make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon's applications," and to provide options for the Board to consider in addressing the Panel's recommendation.

      Whereas, the BAMC has recommended that the Board ask the Governmental Advisory Committee (GAC) if it has: (i) any information to provide to the Board as it relates to the "merits-based public policy reasons," regarding the GAC's advice that the Amazon applications should not proceed; or (ii) any other new or additional information to provide to the Board regarding the GAC's advice that the Amazon applications should not proceed.

      Resolved (2017.10.29.02), the Board asks the GAC if it has: (i) any information to provide to the Board as it relates to the "merits-based public policy reasons," regarding the GAC's advice that the Amazon applications should not proceed; or (ii) any other new or additional information to provide to the Board regarding the GAC's advice that the Amazon applications should not proceed.

      Resolved (2017.10.29.03), the Board asks the GAC that if it has any new or additional information (as requested above) to provide to the Board, it does so by the conclusion of the ICANN61 meeting scheduled to take place from 10-15 March 2018, in order to assist the Board's appropriate and prompt consideration.

      All members of the Board present voted in favor of Resolutions 2017.10.29.02 – 2017.10.29.03. One member of the Board was unavailable to vote on the Resolutions. One member of the Board abstained from voting on the Resolutions. The Resolutions carried.

      Rationale for Resolutions 2017.10.29.02 – 2017.10.29.03

      Amazon EU S.à.r.l. (Amazon) initiated Independent Review Process (IRP) proceedings challenging the New gTLD Program Committee's (NGPC's) 14 May 2014 decision to accept the Governmental Advisory Committee (GAC) consensus advice that three Amazon applications should not proceed. (Resolution 2014.05.14.NG03, available at https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)

      Amazon applied for .AMAZON and its Chinese and Japanese character equivalents (Amazon Applications), which passed Initial Evaluation (see https://newgtlds.icann.org/sites/default/files/ier/bqe3so7p3lu2ia8ouwp7eph9/ie-1-1315-58086-en.pdf [PDF, 46 KB]). In response to the Amazon Applications, the governments of Brazil and Peru, with the endorsement of Bolivia, Ecuador and Guyana, submitted an Early Warning through the GAC, in accordance with the Applicant Guidebook, in which the concerned governments stated that: "[g]ranting exclusive rights to this specific gTLD to a private company would prevent the use of this domain for the purposes of public interest related to the protection, promotion and awareness raising on issues related to the Amazon biome. It would also hinder the possibility of use of this domain to congregate web pages related to the population inhabiting that geographical region." (Early Warning, available at https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB].)

      After indicating in the Beijing Communiqué (April 2013) that the Amazon Applications required further GAC consideration, the GAC provided consensus advice (GAC Advice) to the ICANN Board in the Durban Communiqué (18 July 2013) that the Amazon Applications should not proceed (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).

      On 14 May 2014, the Board (acting through the NGPC) accepted the GAC Advice and directed ICANN not to proceed with the Amazon Applications. (Resolution 2014.05.14.NG03, available at https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.) The NGPC's decision was without prejudice to the continuing efforts by Amazon and members of the GAC to pursue dialogue on the relevant issues.

      In March 2016, Amazon initiated an independent review of ICANN Board Resolution 2014.05.14.NG03 directing that the Amazon Applications should not proceed.

      On 11 July 2017, the IRP Panel (Panel) issued its Final Declaration in the Amazon IRP (https://www.icann.org/en/system/files/files/irp-amazon-final-declaration-11jul17-en.pdf [PDF, 294 KB]). The Panel's findings and recommendation are summarized below, and available in full at https://www.icann.org/resources/pages/irp-amazon-v-icann-2016-03-04-en.

      In a 2-1 decision, the Panel declared Amazon to be the prevailing party, and declared that the "Board, acting through the NGPC, acted in a manner inconsistent with its Articles, Bylaws and Applicant Guidebook because, […] by giving complete deference to the consensus advice of the [GAC] regarding whether there was a well-founded public policy reason for its advice, the NGPC failed in its duty to independently evaluate and determine whether valid and merits-based public policy interests existed supporting the GAC's consensus advice." (Final Declaration at ¶ 2.) The Panel further declared that "ICANN shall bear the costs of this IRP as well as the cost of the IRP provider," and "shall reimburse Amazon the sum of $163,045.51." (Final Declaration at ¶ 126.)

      In addition, the Panel recommended that the Board "promptly re-evaluate Amazon's applications" and "make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon's applications." If the Board determines that the Amazon Applications should not proceed, the Panel indicated that "the Board should explain its reasons supporting that decision"; the "GAC consensus advice, standing alone, cannot supplant the Board's independent and objective decision with a reasoned analysis." (Final Declaration at ¶ 125.) In the alternative, if the Board determines that the Amazon Applications should proceed, the Panel recommended that ICANN conduct its "'meet and confer' with the GAC" "within sixty (60) days of the issuance of this Final Declaration." (Final Declaration at ¶ 125.) In coming to its conclusions, the Panel stated that "under the facts of this IRP, the procedural fairness obligation applicable to the GAC, at a minimum, required that the GAC allow a written statement or comment from a potentially adversely affected party, before it decided whether to issue consensus advice objecting to an application[; and the] Board's obligation was to see that the GAC, as a constituent body of ICANN, had such a procedure and that it followed it." (Final Declaration at ¶ 94.)

      The Panel further concluded that "GAC consensus advice, although no reasons or rationale need be given, nonetheless must be based on a well-founded public interest concern and this public interest basis must be ascertained or ascertainable from the entirety of the record before the NGPC." (Final Declaration at ¶ 103.) According to the Panel, "the NGPC deferred to the consensus GAC advice regarding the existence of a valid public policy concern and by so doing, it abandoned its obligation under ICANN governance documents to make an independent, merits-based and objective decision whether or not to allow the applications to proceed." The Panel further noted that, "[b]y failing to independently evaluate and articulate the existence of a well-founded public policy reason for the GAC advice, the NGPC, in effect, created a conclusive or irrebuttable presumption for the GAC consensus advice." (Final Declaration at ¶ 116.)

      In accordance with Article IV, section 3.21 of the applicable version on the Bylaws, the Board considered the Final Declaration at its meeting on 23 September 2017 and determined, among other things, that further consideration was needed regarding the Panel's non-binding recommendation that the Board "promptly re-evaluate Amazon's applications" and "make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon's applications." The Board asked the BAMC to review and consider the Panel's recommendation, and to provide options for the Board to consider in addressing the Panel's recommendation.

      After reviewing and considering the Final Declaration, the Panel's recommendation, and all relevant materials, the Board Accountability Mechanisms Committee (BAMC) concluded that it would be beneficial to receive any new or additional information that the GAC might choose to offer regarding its advice that the Amazon Applications should not proceed. The Board believes that any such new or additional information would assist the Board in conducting a comprehensive re-evaluation of the Amazon Applications in accordance with the Panel's recommendation. The BAMC therefore has recommended that the Board ask the GAC if it has any new or additional information to provide to the Board regarding the GAC's advice that the Amazon Applications should not proceed.

      The Board recognizes the importance of this decision and wants to make clear that it takes the results of all ICANN accountability mechanisms very seriously, which is further evidenced by the creation of the new BAMC and why the Panel's recommendation was referred to the BAMC.

      Taking this decision is within ICANN's Mission and in furtherance of the public interest as the ultimate result of ICANN's consideration of this matter is a key aspect of coordinating the allocation and assignment of names in the root zone of the domain name system (DNS). Further, the Board's decision is in the public interest, taking into consideration and balancing the goals of resolving outstanding gTLD disputes, respecting ICANN's accountability mechanisms and advisory committees, and abiding by the policies and procedures set forth in the Applicant Guidebook, which were developed through a bottom-up consensus-based multistakeholder process over numerous years of community efforts and input.

      Taking this decision is not expected to have any direct financial impact on the ICANN Organization. This action will not have any impact on the security, stability or resiliency of the domain name system.

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

    2. Request to Defer Compliance Enforcement of Thick WHOIS Consensus Policy for 180 Days

      The Board was provided a briefing about the Thick Whois consensus policy, which included an overview about the deadlines for migrating existing gTLD registrations from "thin" Whois to "thick" Whois. The briefing to the Board included discussion about a letter from the Registrar Stakeholder Group to the Board requesting an extension of the timelines for implementing the Thick Whois policy due to uncertainty about compliance with the European Union General Data Protection Regulation (GDPR) and the need for registrars and Verisign, Inc. to continue negotiations on proposed amendments to the registry-registrar agreements needed to implement the policy.

      The Board considered the proposed resolution to defer compliance enforcement of the Thick Whois policy. It was noted that the Board's proposed action would not change the policy, but instead, it would provide additional time for registrars to make system changes needed to implement the policy. The Board discussed whether deferring compliance enforcement for 180 days was sufficient, and it was noted that the new deadlines would coincide with the effective date for the GDPR.

      After discussion, the Board took the following action:

      Whereas, the Thick Whois Consensus Policy requires that all new domain name registrations must be submitted to the registry as "thick" starting on 1 May 2018 at the latest, and all relevant registration data for existing domain names must be migrated from "thin" to "thick" by 1 February 2019.

      Whereas, the migration from thin to thick registry model will require Registrars to modify the systems through which they submit registration data to registrars.

      Whereas, the Registrar Stakeholder Group expressed concerns about undertaking such modifications pending resolution of issues relating to the European Union's General Data Protection Regulation (GDPR), which may require further system modifications.

      Whereas, in preparation to complete the deployment to accept thick Whois data, Verisign, Inc. proposed amendments to the registry-registrar agreements for .COM and .NET in order to have the legal framework necessary for Verisign to begin accepting registrar transmission of thick data to the registry.

      Whereas, ICANN organization has been facilitating discussions between Verisign and the Registrar Stakeholder Group to reach agreement on the proposed amendments to the registry-registrar agreements to implement the Thick Whois Consensus Policy.

      Whereas, Verisign and the Registrar Stakeholder Group need additional time to reach agreement on the proposed amendments to the applicable registry-registrar agreements to implement the Thick Whois Consensus Policy.

      Whereas, additional time is required to resolve questions regarding application of the GDPR to Whois data.

      Resolved (2017.10.29.04), the President and CEO, or his designee(s), is authorized to defer compliance enforcement of the Thick Whois Consensus Policy for 180 days to allow additional time for the registrars and Verisign to reach agreement on amendments needed to applicable registry-registrar agreements to implement the Policy and for Registrars to undertake system modifications required to enable the thin to thick migration and additional modifications, if any, required for GDPR compliance.

      All members of the Board present voted in favor of Resolution 2017.10.29.04. The Resolutions carried.

      Rationale for Resolution 2017.10.29.04

      The Thick Whois Consensus Policy requires registrars to submit thick registration data to the .COM, .NET, and .JOBS registries for all new domain name registrations starting on 1 May 2018 at the latest. The Policy also requires migration of all existing domain registration data from thin to thick by 1 February 2019. In preparation to complete the deployment to accept thick Whois data, Verisign, the registry operator for .COM and .NET and the back-end registry services provider for .JOBS, proposed amendments to the registry-registrar agreements for .COM and .NET in order to have the legal framework necessary for Verisign to begin accepting registrar transmission of thick data to the registry.

      The ICANN organization followed its published Registry-Registrar Agreement amendment procedure and forwarded the proposed amendments to the Registrar Stakeholder Group for review. The Registrar Stakeholder Group expressed concerns about agreeing to the proposed amendments based on issues relating to the European Union's General Data Protection Regulation (GDPR), which takes effect on 25 May 2018. As such, the next step outlined in the procedure is for ICANN organization to consult with the registry operator and the Registrar Stakeholder Group to resolve these concerns.

      Over the past several months, ICANN organization has been facilitating discussions between Verisign and the Registrar Stakeholder Group to reach agreement on the proposed amendments to the registry-registrar agreements, but the parties have not yet reached agreement. Additionally, ICANN organization is investigating whether there are potential compliance issues under its agreements with registries and registrars because of the General Data Protection Regulation. ICANN organization is working with registries, registrars and various stakeholders to understand these potential compliance issues. Based on initial reviews and communications, including with some data protection agencies, ICANN organization understand that compliance with GDPR will have an impact on the WHOIS system.

      On 29 June 2017, ICANN organization approved Verisign's request for an extension to an optional milestone date in the Policy for registrars to begin voluntarily submitting thick data to the registry. This extension was granted to provide Verisign, ICANN, and the Registrar Stakeholder Group with more time to continue discussions in hopes of achieving a resolution, while still taking reasonable steps to comply with the Policy. This optional 1 August 2017 milestone date was extended to 29 November 2017.

      To allow additional time for the registrars and Verisign to reach agreement on amendments needed to the registry-registrar agreements to implement the Policy, the Board is taking action at this time to authorize the ICANN President and CEO to defer compliance enforcement of the Thick Whois Policy for 180 days. This deferred enforcement period will also allow the ICANN organization to continue to engage with the European community (including the European Union Article 29 Working Party), data protection agencies, contracted parties, and other pertinent stakeholders to gain a better understanding of the relevant aspects of GDPR and how it relates to ICANN organization's work, policies and contracts with registries and registrars, including the Thick Whois Policy.

      As a result of the Board's action, ICANN organization will begin compliance enforcement of the Policy requirement for registrars to submit all new domain name registrations to the registry as thick starting on 28 October 2018 at the latest, and all relevant registration data for existing domain names must be migrated from thin to thick by 31 July 2019. The optional milestone date for registrars to begin voluntarily submitting thick data to the registry will be 28 May 2018.

      During this period of deferred compliance enforcement, ICANN organization will continue to work with Verisign and the Registrar Stakeholder Group to facilitate discussions on the proposed amendments. ICANN organization will also provide updates to the community on the progress to come into compliance with the Thick Whois Policy. During this extension period, the Registrar Stakeholder Group has indicated [PDF, 43 KB] that it will "continue to engage with ICANN and Verisign regarding the RRA changes, ICANN's role under the GDPR, and steps needed to implement the Thick WHOIS transition."

      The Board's deliberation on this matter included, but is not limited to, the following significant materials:

      This action is in the public interest as it helps to ensure consistent and coordinated implementation of policies in gTLDs, and it is within ICANN's Mission to coordinate the development and implementation of policies.

      The Board's action is not anticipated to have a fiscal impact on ICANN that is not already anticipated in the current budget, and will not negatively impact the security, stability and resiliency of the domain name system.

      This is an Organizational Administrative Function for which no public comment is required.

    3. Refinement of string similarity review in IDN ccTLD Fast Track Process

      The Board was provided a briefing on proposed amendments to the Final Implementation Plan for IDN ccTLD Fast Track Process as suggested in a joint response from the ccNSO and SSAC submitted to the Board on 19 September 2017. The joint response was in request from the Board to the ccNSO (in consultation with other stakeholders) to provide additional guidance on and refinement of the methodology of second string similarity review process. The briefing to the Board included background about the IDN ccTLD Fast Track application for European Union (in Greek) to serve as an example of the particular issue giving rise to the request from the Board about the second string similarity review process. The Board noted the good work and collaboration of all of the relevant stakeholders on the proposed amendments. After discussion, the Board took the following action:

      Whereas, the ICANN Board of Directors approved the Final Implementation Plan for IDN ccTLD Fast Track Process on 30 October 2009 (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2).

      Whereas, as part of a review and update to the Implementation Plan, the ccNSO Council, following the development of the IDN ccTLD String Selection recommendations, requested the ICANN Board to include a two-panel process for string similarity evaluation (http://ccnso.icann.org/node/38787).

      Whereas, the ICANN Board of Directors approved the Update to the IDN ccTLD Fast Track Implementation in order to implement the two-panel process for string similarity review. The Extended Process Similarity Review Panel (EPSRP) was approved for inclusion in the IDN ccTLD Fast Track process on 27 June 2013, and ICANN organization was directed to develop the relevant Guidelines and update the Final Implementation Plan accordingly (https://www.icann.org/resources/board-material/resolutions-2013-06-27-en#2.a).

      Whereas, following the 2013 update, and upon the request of the relevant applicants, the pending IDN ccTLD strings under the Fast Track process were evaluated through the EPSRP process, and the EPSRP reports for the three applications were published with evaluation results on the ICANN website on 14 October 2014 (https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en). One application received a split result, based on evaluations of potential confusion in both lowercase and uppercase representations of the applied-for string.

      Whereas, public feedback was received during the third annual review of the IDN ccTLD Fast Track process on issues related to the experimental methodology and results reported by the EPSRP, including the interpretation of the EPSRP's split recommendations on confusing similarity in regards to uppercase and lowercase forms of the applied-for string (https://www.icann.org/public-comments/idn-cctld-fast-track-2015-01-15-en).

      Whereas, following the public comment for the third annual review, on 25 June 2015 the ICANN Board resolved to ask the ccNSO, in consultation with other stakeholders, including GAC and SSAC, to provide further guidance on and refinement of the methodology of second string similarity review process (https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.a).

      Whereas, in response to a letter from the Board seeking additional clarifications the ccNSO and SSAC provided a joint response on 19 September 2017, proposing changes to the Final Implementation Plan for the IDN ccTLD Fast Track Process.

      Resolved (2017.10.29.05), the Board thanks the ccNSO, GAC and SSAC for collaborating to address the issue related to string similarity review and for developing the "Joint ccNSO SSAC Response to ICANN Board on EPSRP".

      Resolved (2017.10.29.06), the Board approves amending the Final Implementation Plan for IDN ccTLD Fast Track Process as suggested in the Joint ccNSO SSAC Response. The President and CEO, or his Designee(s), is directed to incorporate the amendment into the Implementation Plan previously adopted by the Board on 30 October 2009 (and amended on 5 November 2013) and implement the amendment as soon as practicable.

      All members of the Board present voted in favor of Resolutions 2017.10.29.05 – 2017.10.29.06. The Resolutions carried.

      Rationale for Resolutions 2017.10.29.05 – 2017.10.29.06

      Why the Board is addressing the issue?

      On 5 November 2013, ICANN organization published an updated Final Implementation Plan for the IDN ccTLD Fast Track Process [PDF, 851 KB] including the Guidelines [PDF, 86 KB] for the Extended Process Similarity Review Panel (EPSRP), implementing the two-panel string similarity review, as per the resolution by the Board on 27 June 2013. Following the update, three eligible IDN ccTLD Fast Track applicants, for Bulgaria (in Cyrillic), European Union (in Greek) and Greece (in Greek), exercised their option to undergo the second similarity review. The EPSRP completed the review and ICANN organization published these reports on 14 October 2014.

      For each application, the EPSRP documented its findings with respect to the applied-for string. The reports each included a detailed description of the methodology and results of the experiments for string similarity. The EPSRP did not aggregate its findings for a string based on experiments conducted on uppercase and lowercase forms of the string. The EPSRP concluded that from a visual similarity point of view, uppercase and lowercase characters are distinct entities. And given that there is no scientific or policy basis as to how to combine results of uppercase and lowercase similarity found for IDN ccTLDs, the EPSRP could only provide separate recommendations for each of these forms. Therefore, where the findings of the EPSRP are split based on different findings for confusing similarity for uppercase and lowercase forms of a string, there is no mechanism to deduce single aggregated recommendation of the second string similarity review done by EPSRP.

      Based on this experience of the EPSRP analysis, during the third review of the IDN ccTLD Fast Track Process, the community provided public comments raising issues regarding the methodology of the EPSRP, including the assessment of split recommendations (e.g., confusing similarity in uppercase but not in lowercase).

      To address these comments, the Board (through resolution 2015.06.25.16) asked the ccNSO, in consultation with other stakeholders, including GAC and SSAC, to provide further guidance on and refinement of the methodology of second string similarity review process, including the interpretation of split recommendations, to be applied to the relevant current and subsequent cases in the IDN ccTLD Fast Track Process as well as to inform the proposed policy for the selection of the IDN ccTLD strings.

      The relevant working group of the ccNSO, in collaboration with GAC members, published its report [PDF, 274 KB] for a public comment before finalization. SSAC submitted an alternative view in SAC 084 [PDF, 218 KB] and then in SAC 088 [PDF, 72 KB] and SAC 089 [PDF, 128 KB]. At the request of the Board the ccNSO and SSAC worked together to reach a solution, which ccNSO and SSAC chairpersons provided as a joint response [PDF, 215 KB] to the Board on 19 September 2017.

      With this resolution, the Board now concludes the 2015 review of the Fast Track program and moves forward with the update to the Final Implementation Plan for the IDN ccTLD Fast Track Process as suggested in the joint ccNSO and SSAC response. Addressing this issue is aligned with ICANN's Mission as stated at Section 1.1(a)(i) of the ICANN Bylaws: "Coordinates the allocation and assignment of names in the root zone of the Domain Name System." With this outstanding issue cleared, the review cycle for the Implementation Plan can now commence.

      What concerns or issues were raised by the community?

      SSAC provided initial input in SAC 084 [PDF, 218 KB] and further clarified in SAC 088 [PDF, 72 KB] and SAC 089 [PDF, 128 KB] that in case of a split recommendation "the default finding should be to reject the label if confusability exists in either form", maintaining that the use of principles of conservatism, inclusion and stability following RFC 6912 be applied to processes like EPSRP. However, the ccNSO Council noted the Unicode Technical Report # 36: Unicode Security Considerations states that the "use of visually confusable characters in spoofing is often overstated … [which] account for a small proportion of phishing problems" which may be mitigated by measures suggested in the Unicode report. In joint response, the ccNSO and the SSAC agree on a process to address the concerns raised by SSAC by allowing the requester to propose measures to be reviewed by experts to determine if confusable similarity is effectively mitigated.

      What significant materials did the Board review?

      The Board has reviewed various materials and factors in its deliberations and in taking its action today. The relevant and significant materials include, but are not limited to, the following:

      What factors did the Board find to be significant?

      The Board has noted that the ccNSO and the SSAC members have worked together to converge on an effective mechanism, which addresses the competing concerns raised during the process. IDN ccTLD requestor should propose effective risk mitigation measures to address the security concerns earlier raised by the SSAC.

      Are there positive or negative community impacts?

      This decision has a positive impact because it clarifies the ambiguity in the second similarity review guidelines, in case of a split recommendation, allowing IDN ccTLD string evaluations to proceed so long as effective risk mitigation measures can be determined and implemented. This decision also supports the public interest through expanding the potential availability of IDN ccTLDs to additional countries and territories in support of local Internet users.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      Upon implementation, there are fiscal impacts because ICANN organization must engage relevant experts to review the mitigation strategies proposed by the requestor.

      Are there any security, stability or resiliency issues? What concerns or issues were raised by the community?

      The joint response from the SSAC and ccNSO explains that there are four ways uppercase and lowercase forms of the applied-for string can be found confusingly similar. In the first case where neither is found confusingly similar, the string should pass the evaluation. In the second and third cases where the lower case is found confusingly similar, whether uppercase is found confusingly similar or not, the associated risks are too high and difficult to mitigate, so the string should not pass. In the fourth case, where lowercase is not similar but uppercase is confusingly similar, SSAC notes a cautionary approach is appropriate. The joint response notes that SSAC's view is that risk is a continuum and in this fourth case cautionary approach could be for the IDN ccTLD requestor to propose mitigation measures, which are deemed sufficient to reduce the risks to an acceptable level by relevant experts. Only then the string can pass the string similarity evaluation.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      The update suggested by ccNSO was already subject to required public comment after the initial report was drafted. The comments included a response from the GAC in support of the findings and a response from SSAC through SSAC 084 with further responses in SAC 088 and SAC 089 suggesting an alternative approach. To overcome the diverging views that manifested following the public comment, ccNSO and SSAC have worked together to clarify their positions and find common ground, which is presented in their joint response to the Board. Further public comment is not needed to incorporate the adjustment suggested in Final Implementation Plan for the IDN ccTLD Fast Track Process by the joint ccNSO and SSAC response. This is an Organizational Administrative Function for which no public comment is required.

    The Chair called the meeting to a close.

Published on 7 November 2017


1 BGC Determination on Request 15-21, at Pg. 1, https://www.icann.org/en/system/files/files/reconsideration-15-21-dotgay-bgc-determination-01feb16-en.pdf [PDF, 272 KB].

2 Prior to 22 July 2017, the BGC was tasked with reviewing reconsideration requests. See ICANN Bylaws, 1 October 2016, Art. 4, § 4.2(e), https://www.icann.org/resources/pages/bylaws-2016-09-30-en#article4. Following 22 July 2017, the Board Accountability Mechanisms Committee (BAMC) is tasked with reviewing and making recommendations to the Board on reconsideration requests. See ICANN Bylaws, 22 July 2017, Art. 4, § 4.2(e), https://www.icann.org/resources/pages/governance/bylaws-en/#article4.

3 BGC Determination on Request 15-21, at Pg. 1.

4 Request 16-3, https://www.icann.org/en/system/files/files/reconsideration-16-3-dotgay-request-17feb16-en.pdf [PDF, 728 KB].

5 Request 16-5, https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-request-redacted-24feb16-en.pdf [PDF, 1.06 MB].

6 ICANN Responses to DIDP Requests No. 20170505-1 (DotMusic Ltd.), and 20170518-1 (dotgay LLC), incorporated by reference in ICANN's Response to DIDP Request No. 20170610-1 at Pg. 2.

7 As the BAMC noted, the Requestors indicated (by checking the corresponding box on the Reconsideration Request Form) that Request 17-4 seeks reconsideration of staff and Board action or inaction. However, but for a passing reference to Article 4, Section 4.2(o) of ICANN's Bylaws, which states that the BAMC "shall . . . provide[] to the Requestor" any information "collected by ICANN from third parties" that is relevant to the Reconsideration Request", the Requestors make no further arguments concerning the BAMC's actions or inactions. The Requestors also do not ask ICANN organization to take any action concerning this issue. Rather, the Requestors focus on ICANN organization's Response to Joint DIDP Request. Accordingly, the BAMC interpreted Request 17-4 to seek reconsideration of ICANN organization's response to the Joint DIDP Request, and not reconsideration of BAMC action or inaction, and the Board agrees. (See BAMC Recommendation [PDF, 273 KB], Pgs. 12-13.)

8 Reconsideration also is appropriate if the requestor shows that it was adversely affected by Board or Staff action or inaction taken without consideration of material information, or taken as a result of reliance on false or inaccurate relevant information. (ICANN Bylaws, Art. 4, Section 4.2(c)(ii), (iii).)

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