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 person on 13 May 2018 in Vancouver, Canada at 17:00 local time.

Cherine Chalaby, Chair, promptly called the meeting to order.

In addition to the Chair, the following Directors participated in all or part of the meeting: Maarten Botterman, Becky Burr, Ron da Silva, Sarah Deutsch, Chris Disspain (Vice Chair), Avri Doria, Rafael Lito Ibarra, Khaled Koubaa, Akinori Maemura, Göran Marby (President and CEO), George Sadowsky, León Felipe Sanchez Ambia, Matthew Shears, Mike Silber, and Lousewies van der Laan.

The following Board Liaisons participated in all or part of the meeting: Manal Ismail (GAC Liaison), and Jonne Soininen (IETF Liaison).

The following Board Liaisons sent their Apologies: Ram Mohan (SSAC Liaison) and Kaveh Ranjbar (RSSAC Liaison).

Secretary: John Jeffrey (General Counsel and Secretary).

This is a Preliminary Report of the Regular Meeting of the ICANN Board, which was held in person on 13 May 2018 in Vancouver, Canada.

  1. Consent Agenda:
    1. Approval of Board Meeting Minutes
    2. Appointment of Andrey Kolesnikov to the Security and Stability Advisory Committee
    3. Approval of GNSO Noncommercial Users Constituency Bylaws Amendments
    4. New GNSO Voting Thresholds to address post-transition roles and responsibilities of the GNSO as a Decisional Participant in the Empowered Community - Proposed Changes to ICANN Bylaws
    5. Deferral of transition to Thick WHOIS Policy Implementation
    6. Registrar Data Escrow Agent Contract Approval
    7. Getting Additional Input on New KSK Roll Plan
  2. Main Agenda:
    1. Options for Addressing Registries Stakeholder Group's (RySG) Request for Refund of TMCH Registry RPM Access Fee
    2. Consideration of the Temporary Specification for gTLD Registration Data (Implementation of GDPR Interim Compliance Model)
    3. Consideration of Reconsideration Request 17-5
    4. AOB
  1. Consent Agenda:

    The Chair introduced the items on the Consent Agenda. George Sadowsky proposed and Lousewies van der Laan seconded. The Chair then called for a vote and the Board took the following action:

    1. Approval of Board Meeting Minutes

      Resolved (2018.05.13.01), the Board approves the minutes of the 15 March 2018 Regular Meeting of the ICANN Board.

    2. Appointment of Andrey Kolesnikov to the Security and Stability Advisory Committee

      Whereas, the Security and Stability Advisory Committee (SSAC) reviews its membership and makes adjustments from time-to-time.

      Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board appoint Andrey Kolesnikov to the SSAC for a term beginning immediately upon approval of the Board and ending on 31 December 2020.

      Resolved (2018.05.13.02), the Board appoints Andrey Kolesnikov to the SSAC for a term beginning immediately upon approval of the Board and ending on 31 December 2020.

      Rationale for Resolution 2018.05.13.02

      The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfil its charter and execute its mission. Since its inception, the SSAC has invited individuals with deep knowledge and experience in technical and security areas that are critical to the security and stability of the Internet's naming and address allocation systems.

      The SSAC's continued operation as a competent body is dependent on the accumulation of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission.

      Andrey has been active in ICANN for some years and is known to a number of SSAC members through his work as CEO of the Coordination Centre for Russian Federation Top Level Domains and more recently his involvement in IoT technologies, standards and protocols. He brings expertise in ccTLD operations, Internationalized Domain Names and IoT and a well-developed ability to network in multicultural and multilingual environments.

      The SSAC believes Andrey Kolesnikov would be a significant contributing member of the SSAC.

      This resolution is an organizational administrative function for which no public comment is required. The appointment of SSAC members is in the public interest and in furtherance of ICANN's mission as it contributes to the commitment of the ICANN to strengthen the security, stability, and resiliency of the DNS.

    3. Approval of GNSO Noncommercial Users Constituency Bylaws Amendments

      Whereas, the ICANN Bylaws (Article 11, Section 11.5 c) state, "Each Stakeholder Group identified in Section 11.3(a) and each of its associated Constituencies, where applicable, shall maintain recognition with the ICANN Board";

      Whereas, the Board has established a Process For Amending GNSO Stakeholder Group and Constituency Charters (hereinafter "Process");

      Whereas, the GNSO Noncommercial Users Constituency (NCUC), ICANN organization, and the Organizational Effectiveness Committee (OEC) have completed all steps identified in the Process to date, including a determination that the proposed changes will not raise any fiscal or liability concerns for the ICANN organization, and the OEC has recommended that the Board approve the proposed changes.

      Resolved (2018.05.13.03), the ICANN Board approves the NCUC Charter Amendments as documented in this paper and attachments.

      Resolved (2018.05.13.04), the Board directs the ICANN President and CEO, or his designee(s), to communicate this resolution with the leadership of the NCUC, and the NCUC and the ICANN President and CEO, or his designee(s), is directed to provide access to the updated NCUC Charter on the appropriate ICANN and NCUC web pages.

      Rationale for Resolutions 2018.05.13.03 - 2018.05.13.04

      Why is the Board addressing this issue now?

      The ICANN Bylaws (Article 11, Section 11.5 c) state, "Each Stakeholder Group identified in Section 11.3(a) and each of its associated Constituencies, where applicable, shall maintain recognition with the ICANN Board." The ICANN Board follows a process through which it formally approves any GNSO Stakeholder Group and/or Constituency Charter amendments in order to support the maintenance of recognition.

      In September 2013, the Board established a Process For Amending GNSO Stakeholder Group and Constituency Charters ("Process") to provide a streamlined methodology for compliance with the Bylaws requirement.

      In May 2017, the Noncommercial Users Constituency (NCUC) of the GNSO approved amendments to its governing documents and availed itself of the Process.

      What are the proposals being considered?

      The NCUC has substantially amended its existing Charter document to adjust to an evolving composition of membership and to enable it to more effectively undertake its policy development responsibilities. Among a number of amendments, the most substantial charter changes are in the following areas:

      1. Align various provisions with the charter of the Non-Commercial Stakeholders Group;
      2. Addition of a complete new chapter that thoroughly details new mechanisms to help the NCUC fulfill its obligations as part of the new ICANN empowered community;
      3. Clarified areas of NCUC membership eligibility – particularly the definition of eligible membership organizations and matters regarding non-eligible organizations;
      4. Expanded provisions obliging NCUC members to disclose instances of support from ICANN or specific parts of the ICANN community;
      5. Expanded details on NCUC Executive Committee including: added details on the duties and expectations for regional representatives on the NCUC Executive Committee; expanded provisions for the removal of NCUC officers; creation of a new Vice Chair role – replacing the Secretary-Treasurer role; and additional details provided about the role of the NCUC Treasurer.

      What stakeholders or others were consulted?

      In addition to extensive community deliberations within the NCUC, the proposed amendments were subjected to a 41-day Public Comment period (24 August – 3 October 2017). When the period was completed, ICANN org produced a Summary Report for community and Board OEC review on 4 October 2017.

      What significant materials did the Board review?

      Board members reviewed of the proposed charter amendments, a copy of the red-lined version of the proposed charter amendments following the initial staff review prior to the public comment proceeding, and a copy of the Staff Summary Report summarizing community comments.

      What factors did the Board find to be significant?

      The NCUC , ICANN organization, and the Organizational Effectiveness Committee (OEC) completed all steps identified in the Process including a determination that the proposed charter amendments will not raise any fiscal or liability concerns for the ICANN organization and publication of the amendments for community review and comment. The OEC has recommended to the Board that the NCUC Charter amendments be approved.

      Are there Positive or Negative Community Impacts?

      The NCUC has amended its existing Charter document to adjust to an evolving composition of membership and to enable it to more effectively undertake its policy development responsibilities.

      Are there fiscal impacts/ramifications on ICANN organization (Strategic Plan, Operating Plan, Budget); the community; and/or the public?

      There are no anticipated fiscal impact/ramifications on ICANN organization or individual community members within the amendments supplied. The amendments supplied align with ICANN's mission and meet the public interest by way of updating the fundamental governance document for one of the ICANN Board-recognized constituency groups.

      Are there any Security, Stability or Resiliency issues relating to the DNS?

      There is no anticipated impact from this decision on the security, stability and resiliency of the domain name system as a result of this decision.

      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 proposed amendments were subjected to a 41-day Public Comment period (24 August to 3 October 2017).

    4. New GNSO Voting Thresholds to address post-transition roles and responsibilities of the GNSO as a Decisional Participant in the Empowered Community - Proposed Changes to ICANN Bylaws

      Whereas, during its meeting on 30 January 2018, the GNSO Council resolved to recommend that the ICANN Board of Directors adopt the proposed changes to Section 11.3.i of the ICANN Bylaws to reflect new GNSO voting thresholds which are different from the current threshold of a simple majority vote of each House (see https://www.icann.org/en/system/files/files/proposed-revisions-bylaws-article-11-gnso-redline-19jun17-en.pdf [PDF, 39 KB]).

      Whereas, the addition of voting thresholds to Section 11.3.i of the ICANN Bylaws as proposed by the GNSO constitutes a "Standard Bylaw Amendment" under Section 25.1 of the Bylaws.

      Whereas, the ICANN Bylaws require that Standard Bylaw Amendments be published for public comment prior to the approval by the Board, and on 15 March 2018 the ICANN Board of Directors directed these proposed amendments to be posted for public comment.

      Whereas, the public comment was opened on 26 March 2018 and closed on 05 May 2018.

      Whereas, after taking public comments into account, the Board considered the proposed amendment for adoption.

      Resolved (2018.05.13.05), the ICANN Board of Directors approves the amendment of the ICANN Bylaws [PDF, 106 KB] to include the proposed changes to section 11.3.i of the ICANN Bylaws, including the rewording for clarity proposed by the Registries Stakeholder Group, to reflect additional GNSO voting thresholds which are different from the current threshold of a simple majority vote of each House to address all the new or additional rights and responsibilities in relation to participation of the GNSO as a Decisional Participant in the Empowered Community.

      Rationale for Resolution 2018.05.13.05

      The action being approved today is the amendment of the ICANN Bylaws to include the proposed changes to section 11.3.i of the ICANN Bylaws to reflect additional GNSO voting thresholds which are different from the current threshold of a simple majority vote of each House (see https://www.icann.org/en/system/files/files/proposed-revisions-bylaws-article-11-gnso-redline-19jun17-en.pdf [PDF, 39 KB]). These additional voting thresholds are intended to address all the new or additional rights and responsibilities in relation to participation of the GNSO as a Decisional Participant in the Empowered Community to fully implement these new or additional rights and responsibilities as they appear in the revised GNSO Operating Procedures published on 30 January 2018 (see https://gnso.icann.org/en/council/op-procedures-30jan18-en.pdf [PDF, 1.68 MB]). Per Article 2 of Annex D of the ICANN Bylaws, Standard Bylaw Amendments, the Board approval of these amendments then provides the Empowered Community an opportunity to consider if it will initiate a Rejection Action.

      These Bylaw amendments are the result of a process that was initiated when on 27 May 2016 the ICANN Board adopted a set of new ICANN Bylaws that reflect changes needed to implement the IANA Stewardship Transition Proposal. Following the completion of the transition, the GNSO Council recognized that changes may need to be made to the GNSO's current Operating Procedures and related mechanisms, as well as to the ICANN Bylaws. The goal was to give effect to the new roles and obligations of the GNSO under the new ICANN Bylaws, including but not limited to the GNSO's participation in the Empowered Community.

      The GNSO Council tasked the GNSO Rights & Obligations Under Revised Bylaws Drafting Team to put forward recommendations for changes to ICANN Bylaws and GNSO Operating Procedures to enable effective GNSO participation in ICANN activities. The GNSO Council accepted the Drafting Team's recommendations, which were translated into changes in the GNSO Operating Procedures and additional voting thresholds in section 11.3.i of the ICANN Bylaws. During its meeting on 30 January 2018, the GNSO Council resolved unanimously (https://community.icann.org/display/gnsocouncilmeetings/Motions+30+January+2018) to recommend that the ICANN Board of Directors adopt the proposed amendments to the ICANN Bylaws.

      On 15 March 2018, the Board directed ICANN organization to post for public comment for a period of at least 40 days the Standard Bylaw Amendment reflecting proposed additions to section 11.3.i of the ICANN Bylaws to establish additional GNSO voting thresholds (see https://features.icann.org/new-gnso-voting-thresholds-address-post-transition-roles-and-responsibilities-gnso-decisional.)

      ICANN Organization opened a public forum on 26 March 2018. At the close of the public comment period on 05 May 2018, per the ICANN organization's Report [PDF, 364 KB] on Public Comments, there were five comments received. Of these comments, the Registries Stakeholder Group (RySG), the Registrar Stakeholder Group (RrSG), the Non-Commercial Stakeholder Group (NCSG), the Business Constituency (BC), and the Intellectual Property Constituency (IPC) supported the proposed additions to section II.3.i. Although BC restated its position that "GNSO Council is not the appropriate vehicle for GNSO to exercise Empowered Community rights and responsibilities", and the IPC noted a reservation with regards to application of the voting threshold outside the scope of the policy development process, the BC states that it "supports the recommended voting thresholds and changes to Bylaws" and the IPC states that it "is in favor of the GNSO Council's resolution to make needed changes to Section 11.3.i of the ICANN Bylaws, and urges for this proposal's adoption by the ICANN Board." The RySG also suggested a minor rewording of section II.3.i to improve clarity.

      With the public comment completed, the Board is now considering the proposed amendment for adoption. In taking this action, the Board has considered the amendment to the ICANN Bylaws as forwarded by the GNSO Council, the public comments, and the ICANN Organization's public comment report.

      There is no anticipated fiscal impact from adopting the proposed changes to the Bylaws. Approval of the resolution will not impact the security, stability and resiliency of the domain name. This action is consistent with ICANN's mission and serves the public interest by supporting the effectiveness and ongoing improvement of ICANN's accountability and governance structures.

    5. Deferral of transition to Thick WHOIS Policy Implementation

      Whereas, the Thick WHOIS Consensus Policy requires that Verisign is to begin accepting "Thick" registration data from registrars starting 28 May 2018, all new domain name registrations must be submitted 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.

      Whereas, in preparation to complete the deployment to accept Thick WHOIS data, Verisign proposed amendments to the registry-registrar agreements for .COM and .NET.

      Whereas, the Registrar Stakeholder Group and Verisign expressed concerns about agreeing to Verisign's proposed amendments based on issues relating to the European Union's General Data Protection Regulation.

      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 are at an impasse and need additional time to reach agreement on the proposed amendments to the applicable registry-registrar agreements to implement the Thick WHOIS Consensus Policy.

      Whereas, the deferred enforcement period will allow the ICANN organization to continue to engage with the relevant European authorities 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's work and the organization's policies and contracts with registries and registrars, including the Thick WHOIS Consensus Policy.

      Resolved (2018.05.13.06), the President and CEO, or his designee(s), is authorized to defer compliance enforcement of the Thick WHOIS Consensus Policy for six months to 30 November 2018, 30 April 2019 and 31 January 2020, respectively, to allow additional time for the registrars and Verisign to reach agreement on amendments needed to applicable registry-registrar agreements to implement the Policy.

      Rationale for Resolution 2018.05.13.06

      The Thick WHOIS Consensus Policy requires Verisign to begin accepting "Thick" registration data from registrars starting 28 May 2018, registrars to submit Thick registration data to the .COM, .NET, and .JOBS registries for all new domain name registrations starting on 28 October 2018, and the migration of all existing domain registration data from Thin to Thick by 31 July 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. While the Thick WHOIS Consensus Policy also applies to the .JOBS TLD, the registry operator for .JOBS, Employ Media, did not require changes to the Registry-Registrar Agreement to begin accepting Thick registration data and registrars have already started submitting Thick registration data as per the Policy to Employ Media.

      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 the ICANN organization to consult with the registry operator and the Registrar Stakeholder Group to resolve these concerns.

      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, the ICANN organization is investigating whether there are potential compliance issues under its agreements with registries and registrars because of the European Union's General Data Protection Regulation ("GDPR"). The 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 understands 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 later 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 six months. This deferred enforcement period will also allow the ICANN organization to continue to engage with the relevant European authorities 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's work and the organization's policies and contracts with registries and registrars, including the Thick WHOIS Consensus 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 30 April 2019, and all relevant registration data for existing domain names must be migrated from Thin to Thick by 31 January 2020. The optional milestone date for registrars to begin voluntarily submitting Thick data to the registry will be 30 November 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 Consensus 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:

      The Board's action is not anticipated to have a fiscal impact on ICANN beyond what is already anticipated in the current budget. This resolution is an organizational administrative function for which no public comment is required. This action is in the public interest as it helps to ensure a consistent and coordinated implementation of policies in gTLDs, which is also aligned with ICANN's mission.

    6. Registrar Data Escrow Agent Contract Approval

      Whereas, members of the registrar community have expressed a need for an additional ICANN-designated Registrar Data Escrow agent with regional support capability in the European Union.

      Whereas, the ICANN Global Domains Division intends to provide an additional ICANN-designated Registrar Data Escrow agent with regional support in the European Union and an understanding of the European Union General Data Protection Regulation (GDPR).

      Whereas, ICANN organization has published a Request For Proposal to identify an additional Registrar Data Escrow Agent.

      Whereas, the ICANN org has completed the Request For Proposal and determined that DENIC eG has demonstrated its capability to support registrar data escrow services and is the preferred provider.

      Resolved (2018.05.13.07), the Board authorizes the President and CEO, or his designee(s), to enter into, and make disbursements in furtherance of, a new DENIC eG contract for a term of 36 months with total cost not to exceed US$[REDACTED].

      Resolved (2018.05.13.08), specific items within this resolution shall remain confidential for negotiation purposes pursuant to Article 3, Section 3.5(b) and (d) of the ICANN Bylaws until the President and CEO determines that the confidential information may be released.

      Rationale for Resolutions 2018.05.13.07 – 2018.05.13.08

      The ICANN organization understands, based upon feedback from the registrar community, the need to enhance the RDE Program and provide an additional ICANN-designated RDE agent with regional support in the European Union.

      ICANN org posted a request for proposal on 17 August 2017 to to identify one or more additional ICANN-designated RDE agents with the capability to offer broad global or multiregional support. During this process the ICANN org identified service areas that could be enhanced with an additional ICANN-designated RDE agent and considered those in the RFP evaluation.

      As a result, ICANN org identified DENIC eG to have a clear understanding of the needs of the registrar community and the capability to perform at the appropriate service levels. In addition, DENIC eG has broad understanding of the current industry and of the ICANN's multistakeholder model.

      Taking this step towards contracting is in the fulfilment of ICANN's mission and in the public interest to ensure that ICANN org is utilizing the right third party providers, and to ensure that it is maximizing available resources in a cost-efficient and effective manner. This action will benefit ICANN's mission to ensure the security, stability and resiliency of the domain name system.

      This action will have a fiscal impact on the organization, as each additional ICANN-designated RDE agent results in additional fixed cost, but it will provide ICANN org with ICANN-designated RDE agents that enhance diversity and competition.

    7. Getting Additional Input on New KSK Roll Plan

      Whereas, ICANN organization has updated the full plan documents in response to suggestions from the community and created "Updated Plan for Continuing the Root KSK Rollover" (published at <https://www.icann.org/resources/pages/ksk-rollover-operational-plans>) ;

      Whereas, the Board often requests advice from the Root Server System Advisory Committee (RSSAC) on matters that relate to the stability of the root zone, and often requests advice from the Security and Stability Advisory Committee (SSAC) on matters that relate to the security and stability of the Domain Name System (DNS) and often requests advice from the Root Zone Evolution Review Committee (RZERC) on architectural changes to the content of the DNS root zone

      Resolved (2018.05.13.09), that the Board requests RSSAC, SSAC and RZERC to provide the Board advices on "Updated Plan for Continuing the Root KSK Rollover" and associated plan documents, and report back to the Board by 10 August 2018 if possible.

      Rationale for Resolution 2018.05.13.09

      The plan to roll the DNS root KSK was temporarily paused on 27 September 2017 due to unexpected input that caused the community to question how ready validating resolvers were for the roll that was coming just a few weeks later. For months after that, ICANN org analyzed the data that became available that caused the temporary pause and found that continuing the process of the root KSK roll would be warranted.

      Based on that research, ICANN org asked the technical community to recommend a plan of action. The suggestion from that community was that ICANN should proceed with the KSK roll procedure in an orderly fashion.

      With that input, ICANN org created a summary plan, titled "Plan for Continuing the Root KSK Rollover", to roll the root KSK on 11 October 2018. ICANN org published the summary plan for community review on 1 February 2018 (see <https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en>). The time allowed for comments was extended beyond the normal 45 days to allow presentations about the plan at ICANN 61 in San Juan and IETF 101 in London and to request more community input at those fora.

      The community response received by 2 April 2018 was strongly in favor of the published plan (with some suggestions of additional outreach that ICANN org could do before October 2018). Based on the community response, ICANN org created the "Updated Plan for Continuing the Root KSK Rollover" and also revised the original KSK roll plan documents to show which steps had already been taken, and which steps still needed to be taken using the revised dates. These plan document are available at <https://www.icann.org/resources/pages/ksk-rollover-operational-plans>.

      The community input on the proposed plan came from a variety of Advisory Committees, Stakeholder Groups, organizations, and individuals, but comments were not received from either RSSAC or SSAC. RSSAC is a respected advisor on stability of the root zone, and SSAC is a respected advisor on matters that relate to the security and stability of the DNS. The Board is taking action at this time to request input from the RSSAC and the SSAC about the Updated Plan for Continuing the Root KSK Rollover so that this input may be taken into account as part of the Board's deliberations on whether or not to approve the Updated Plan.

      The request for input from the RSSAC and SSAC is not anticipated to have any fiscal impact on the ICANN organization beyond that which has already been accounted for in the budgeted resources necessary for ongoing support of the RSSAC and SSAC.

      This decision is in the public interest and within ICANN's mission, as it supports ICANN org's work to ensure the stable and secure operation of the Internet's unique identifier systems.

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

      All members of the Board present voted in favor of Resolutions 2018.05.15.01, 2018.05.13.02, 2018.05.13.03, 2018.05.13.04, 2018.05.13.05, 2018.05.13.06, 2018.05.13.07, 2018.05.13.08, and 2018.05.13.09. The Resolutions carried.

  2. Main Agenda:

    1. Options for Addressing Registries Stakeholder Group's (RySG) Request for Refund of TMCH Registry RPM Access Fee

      Ron da Silva, Chair of the Board Risk Committee, introduced the agenda item. Ron explained that this resolution relates to a request from the Registries Stakeholder Group to refund the $5,000 trademark clearinghouse one-time registry rights protection mechanism access fee.

      Christine Willett, VP of gTLD Operations, provided additional background information relevant to the resolution. The registry operators were required to pay a one-time US $5,000 fee for connectivity and access to the trademark clearinghouse to support sunrise and claims operations. The $5,000 was only specified in the registry agreement whereas the Applicant Guidebook generally referenced a fee to connect, but did not specify a specific amount. The $5,000 fee was paid by over 1200 contracted and delegated registry operators. The fees were passed along to the administrator of the trademark database. This request is to refund those fees from the unspent portion of the New gTLD Program application fees, and would amount to a total of $6.2 million. At present, it is anticipated that this would only be refunded to those operators who have actually paid the fees. Following this resolution, ICANN organization will cease charging a $5,000 fee to any further operators who become contracted and delegated under the program.

      Ron da Silva moved and León Sanchez seconded. The Chair then called for a disclosure of conflicts of interest. One Board member noted that she was abstaining from participating in the discussion and vote due to potential conflicts. The Chair called for a vote and the Board then took the following action:

      Whereas, the Trademark Clearinghouse (TMCH) is a global repository for trademark data established by ICANN org in March 2013.

      Whereas, the need for the TMCH was foreseen during the development of the New gTLD Program and the Applicant Guidebook (AGB).

      Whereas, the TMCH fees for registries are defined in Section 6.4 of the Registry Agreement (RA), which states that a registry is to pay a one-time rights protection mechanism (RPM) access fee of $5,000 and also a $0.25 transactional fee per Sunrise Registration and Claims registrations.

      Whereas, in October 2017, the RySG requested a refund of the one-time RPM access fee of $5,000 for each registry that accessed the TMCH from remaining New gTLD Program funds.

      Whereas, the ICANN Board has determined that while the concept for the TMCH was foreseen in the AGB, the pricing and fees were not. The $5,000 fee was first defined in the 2013 version of the RA, and was not specified in the RA version included with the AGB or the version made available prior to the application period.

      Whereas, the New gTLD Program is nearly complete, and there is more clarity surrounding the availability of the remaining New gTLD Program funds, but it could take several additional years before all risks and liabilities are fully known and quantified.

      Resolved (2018.05.13.10), the ICANN Board directs the President and CEO or his designee(s) to take all steps necessary to provide a refund of $5,000, as soon as practicable, to the contracted registries or registry operators (including those that have terminated their contracts or whose TLD delegation has been revoked) that have paid to ICANN the one-time RPM access fee as defined in Section 6.4 of the RA.

      Fifteen Board members voted in favor of Resolution 2018.05.13.10. One Board member abstained. The Resolution carried.

      Rationale for Resolution 2018.05.13.10

      Why is the Board addressing the issue now?

      In October 2017, the Registries Stakeholder Group (RySG) requested a refund of the one-time RPM access fee of $5,000 for each registry. The RySG contends that "[a]ll other systems and programs related to the New gTLD Program were funded from application fees. The TMCH should have been no different and there was no reason to "double-charge" registries for this one piece of the program." The RySG also contends that the one-time RPM access fee was not provided for in the AGB [as published prior to the opening of the application window] and that "ICANN added [the fee] on its own after all applications were accepted and without community input".1 Based on this, the RySG requests refunding of the "overcharge" from the remaining New gTLD Program funds.2

      What are the options being considered? What factors did the Board find significant?

      In considering the RySG request, the Board contemplated a range of options, including maintaining the status quo (no refund), refunding now, or deferring consideration of the request until the end of the New gTLD Program. In weighing these options, the Board considered a number of factors, including: Is providing a refund consistent with the AGB or RA? Is it consistent with other New gTLD Program Funding Approaches? Does providing a refund now allow ICANN org to account for other risks/costs?

      With regard to not providing a refund, the Board considered that the TMCH fee provision seeks to cover costs associated with providing TMCH services. Indeed, the primary argument in favor of this approach is that the concept for the TMCH was foreseen in the AGB, and the RA—agreed to by the registries—contains provisions for the TMCH fees.

      However, the Board also considered that, while the concept for the TMCH was foreseen in the AGB, the pricing and fees were not. The $5,000 fee was first defined in the 2013 version of the RA, and was not specified in the RA version included with the AGB or the version made available prior to the application period. Additionally, funding the TMCH by collecting pass-through fees from registry operators is not consistent with the approach used to fund other operational services in support of the New gTLD program operations. Other aspects of the program were paid for directly out of application fees.

      As such, the Board considered the option of providing the refund, and whether that could be done now or should be done at the close of the New gTLD Program. The Board considered that it may be prudent to wait to consider this request until the close of the New gTLD Program. This option allows for completion of the risk assessment and quantification effort currently underway, prior to providing the refund to the registries. If—at the close of the New gTLD Program—it has been determined that all risks and other costs have been accounted for, then the Board could consider at that time to provide a refund of the $5,000 RPM access fee to all registries. The Board also considered that many requests for refunding or offsetting fees have been and/or will be received and that other aspects of ICANN org's New gTLD Program operations that may require additional funding over the next few years.

      However, the Board also considered that the New gTLD Program is largely complete, and there is already more clarity surrounding the availability of New gTLD Program funds and that it could require several additional years before all risks and liabilities are fully known and quantified. The Board also weighed, as noted above, that the fees were first defined in the 2013 version of the RA, and not in the RA version included with the AGB or made available prior to the application period. Additionally, refunding the fees is also consistent with the approach used to fund other operational services in support in the New gTLD Program, as it would be using application fees to cover the cost of the TMCH for registries. For these reasons, the Board has determined that the option to refund the fee to the registries is the most reasonable.

      What significant materials did the Board review?

      In adopting this resolution, the Board has reviewed, in addition to the options provided by ICANN org, various materials, including, but not limited to:

      Are there fiscal impacts or ramifications on ICANN?

      The Board's action will have a fiscal impact on ICANN. The funding of the refund is expected to come from the unspent portion of the New gTLD program application fees. The estimated amount of these new gTLD program funds remaining available to cover for "hard-to-predict" costs (including risks), in addition to the evaluation expenses remaining to be incurred, is expected to be $81,609,000, resulting from the most recent projections produced as part of the Draft FY19 Operating Plan and Budget. The total refund amount of $6,210,000 would come to reduce by as much the estimated amount of funds remaining available to cover for "hard-to-predict" costs.

      Are there positive or negative community impacts?

      Taking this action will help support ICANN's mission to ensure the stable and secure operation of the Internet's unique identifier systems. This action benefits the ICANN community as it provides transparency regarding use of the New gTLD Program remaining funds.

    2. Consideration of the Temporary Specification for gTLD Registration Data (Implementation of GDPR Interim Compliance Model)

      Becky Burr introduced the agenda item. Becky explained that ICANN has been working for over a year with the community stakeholders and users of WHOIS, governments, and data protection authorities, to ensure that we have a path for GDPR compliance on the 25th of May when the General Data Protection Regulation (GDPR), comes into full force and effect. Consistent with that, ICANN published a proposed interim compliance model known as the Calzone Model, which would provide access to certain non-personal data in a public setting and then access to non-public registration data containing personal information for legitimate purposes. Before publishing the Calzone Model, ICANN solicited and received comments from affected stakeholders and members of the community, contracted parties, the Governmental Advisory Committee, and also consulted with the Article 29 Working Party on issues of implementation and adoption that model.

      On 11 May 2018, ICANN org presented a draft temporary specification to the Board and community for consideration in order to implement necessary changes to ensure that contracted parties continue to collect and make available WHOIS data as permitted by the GDPR.

      Becky noted that the Board spent most of its past two days in very detailed conversation discussing not only the specific provisions of the proposed temporary specification, but also discussing potential alternatives to a temporary specification, the implications of adopting a temporary specification, and future steps towards adoption. The Board has provided significant input to ICANN org on the proposed temporary specification.

      While the Board does not feel ready to adopt a temporary specification at this point as its discussions are ongoing, the Board does intend to consider adoption of that on or about 17 May 2018.

      The Board asked ICANN org to revise the proposed temporary specification and publish it so that the community has the benefit of being able to view an updated document and discuss prior to Board action. Additionally, the Board wants to have the time to make sure that ICANN org has carefully included the Board's inputs as well as to understand how ICANN org reviewed, considered, and included as appropriate other items raised by the ICANN community.

      Becky thanked ICANN org for the enormous amount of work that has gone into producing the proposed resolution at hand.

      The Chair echoed Becky's sentiments.

      The Chair then called for a vote and the Board took the following action:

      Whereas, the European Union's General Data Protection Regulation (GDPR) is a set of rules adopted by the European Parliament, the European Council and the European Commission that imposes new obligations on all companies and organizations that collect and maintain any "personal data" of residents of the European Union, as defined under EU data protection law. The GDPR will take full effect on 25 May 2018.

      Whereas, the GDPR has given new prominence and urgency to the long-standing debate about WHOIS and data protection and privacy.

      Whereas, over the past several months ICANN org has consulted with community stakeholders, contracted parties, European data protection authorities, legal experts, and interested governments to understand the potential impact of the GDPR to personal data that participants in the gTLD domain name ecosystem collect, display and process (including registries and registrars) pursuant to ICANN contracts and policies. ICANN's policies are set by the ICANN community.

      Whereas, through an iterative process and with feedback from the community, ICANN org developed a proposed interim model for how ICANN and gTLD registries and registrars could continue to comply with ICANN contractual requirements and community-developed policies in relation to the GDPR (the "Proposed Interim Compliance Model").

      Whereas, ICANN org requested and has received guidance from the Article 29 Working Party concerning the Proposed Interim Compliance Model, including areas where ICANN has received governmental advice and input reflecting differing views.

      Whereas, the GAC provided advice to the Board in its San Juan Communiqué (15 March 2018) concerning the Proposed Interim Compliance Model. The advice was the subject of an exchange between the Board and the GAC to clarify the Board's understanding of the advice.

      Whereas, ICANN org communicated with European data protection authorities and requested adequate time for gTLD registries and registrars to implement the Proposed Interim Compliance Model once additional clarification from the data protection authorities was incorporated into the Proposed Interim Compliance Model.

      Whereas, ICANN is continuing to discuss with the ICANN community proposed accreditation models.

      Whereas, to cause compliance with the Proposed Interim Compliance Model, ICANN org drafted a temporary specification utilizing the procedure for Temporary Policies established in the Registry Agreement and the Registrar Accreditation Agreement (the "Temporary Specification for gTLD Registration Data" or "Temporary Specification"). A proposed Temporary Specification was shared with the Board and community on 11 May 2018.

      Whereas, adopting a Temporary Specification can contribute to the Board's upholding the global public interest. Without a unified policy solution in place at the time that the GDPR goes into full effect, there is a real risk of fragmentation in the collection, processing, and availability of gTLD Registration Data as Registry Operators and Registrars take different paths to bring themselves into compliance with the law. A Temporary Specification instead sets out the unified manner through which Registry Operators and Registrars are expected to collect, process, display and provide access to this data. ICANN org can then enforce compliance against its contracts in case these requirements were not met. A fragmented system would be counter to current WHOIS practice and may cause harm.

      Whereas, the Board, at its Vancouver workshop, has engaged in a substantial and robust review over two days regarding a proposed Temporary Specification, including identification of questions and potential improvements, and wants to share with the community the updates to a proposed Temporary Specification generated as a result of the Board's review to date.

      Whereas, during May 2018, the Board has received multiple letters from parts of the ICANN community regarding the contents of a draft Temporary Specification.

      Whereas, the Board has communicated to the GAC that the Board made a preliminary determination that its approach in a proposed Temporary Specification is inconsistent or could be viewed as inconsistent with certain items of GAC advice in the San Juan Communiqué. The Board provided a scorecard to reflect items of the GAC's advice that the Board may reject because of this.

      Whereas, ICANN org continues to engage with the Article 29 Working Party to seek clarity on guidance provided by the Article 29 Working Party about the Proposed Interim Compliance Model.

      Resolved (2018.05.13.11), the Board intends to move to a decision on the adoption of a proposed Temporary Specification on gTLD Registration Data (pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement concerning the establishment of temporary policies) on or about 17 May 2018. The Board intends to use this additional time to confirm that appropriate modifications are incorporated into a proposed Temporary Specification prior to considering adoption. Upon adoption, a proposed Temporary Specification would be effective for a 90-day period beginning 25 May 2018, and the Board would reaffirm its temporary adoption every 90 calendar days for a total period not to exceed one year.

      Resolved (2018.05.13.12), the Board's initial considerations of a proposed Temporary Specification are focused on the following elements:

      1. Whether the modifications in a proposed Temporary Specification to existing requirements concerning the processing of personal data in registration data are justified and an immediate establishment of a proposed Temporary Specification is necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      2. Whether a proposed Temporary Specification is as narrowly tailored as feasible to achieve the objective to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.

      Resolved (2018.05.13.13), the global public interest is served by the implementation of a unified policy governing aspects of the gTLD Registration Data when the GDPR goes into full effect.

      Resolved (2018.05.13.14) the Board directs the ICANN President and CEO, or his designee(s), to continue to support the Board in discussion across the ICANN community regarding the refinements made prior to the Board's consideration of a proposed Temporary Specification for adoption. The ICANN President and CEO, or his designee(s), are directed to share with the ICANN community the updates to a proposed Temporary Specification generated as a result of the Board's review to date.

      All members of the Board present voted in favor of Resolutions 2018.05.13.11, 2018.05.13.12, 2018.05.13.13, and 2018.05.13.14. The Resolution carried.

      Rationale for Resolutions 2018.05.13.11 – 2018.05.13.14

      The European Union's General Data Protection Regulation (GDPR) will go into effect on 25 May 2018. The GDPR is a set of rules adopted by the European Parliament, the European Council and the European Commission that will impose new obligations on all companies and organizations that collect and maintain any "personal data" of residents of the European Union, as defined under EU data protection law. The GDPR impacts how personal data is collected, displayed and processed among participants in the gTLD domain name ecosystem (including registries and registrars) pursuant to ICANN contracts and policies. Modifications need to be made prior to 25 May to allow ICANN and gTLD registries and registrars could continue to comply with ICANN contractual requirements and community-developed policies in relation to the GDPR. Though there has been significant work across the ICANN community to reach a compliance model, ICANN-adopted policies need to be updated to allow compliance with the GDPR. A full community-developed consensus policy is not yet available. Without a unified applicable policy in place, there will be fragmentation in how ICANN's contracted parties implement their own compliance programs in relation to gTLD Registration Data. As such, a unified applicable policy is needed in place prior to 25 May 2018, and doing so is in the public interest. The public interest is not served if the ICANN Board fails to take action on this critical issue.

      ICANN org's agreements with registries and registrars require compliance with Board-adopted temporary policies or specifications. To develop a temporary policy or specification, at least two-thirds of the Board must vote to approve the temporary specification, and the changes in the specification must be justified and "necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet." The temporary policy or specification must be as narrowly tailored as feasible to achieve those objectives.

      ICANN org, in consultation with the Board, has been exploring the possibility of a temporary policy or specification as a mechanism to implement the Interim GDPR Compliance Model. A draft of a proposed Temporary Specification for gTLD Registration Data ("Temporary Specification") was released to the Board and the community on 11 May 2018. That proposed Temporary Specification is drafted to establish temporary requirements for how ICANN and gTLD registries and registrars will continue to comply with existing ICANN contractual requirements and community-developed policies in relation to the GDPR.

      The Board has been in workshop since 11 May 2018, and has used the time since the publication of a proposed Temporary Specification to engage in substantial discussion with ICANN organization, which has resulted in additional proposed changes. Also since the 11 May 2018 publication, the ICANN Board has received letters from multiple parts of the ICANN community, regarding the contents of the draft Temporary Specification.

      The Board has identified that because of the significance of the Board approving a Temporary Specification, it is appropriate for the Board to take additional time prior to adoption, both for the Board's review and to have opportunities to discuss with the ICANN community on the contents of a proposed Temporary Specification. The Board has also identified that taking action on a Temporary Specification is within the public interest, because of the need for a uniformly applicable policy drafted to achieve compliance with the GDPR. It is important that a Temporary Specification be adopted so that it can be in force on 25 May 2018.

      The work towards development of a Temporary Specification is consistent with ICANN's mission "[…] to ensure the stable and secure operation of the Internet's unique identifier systems […]". As one of ICANN's primary roles is to be responsible for the administration of the topmost levels of the Internet's identifiers, facilitating the ability to identify the holders of those identifiers is a core function of ICANN.

      ICANN's mission to ensure the security and stability of the operation of the Internet's system of unique identifiers has led to the obligations associated with providing WHOIS that are in ICANN consensus policies and contracts that ICANN has with registries and registrars. These policies and contractual obligations govern the collection, retention, escrow, transfer, and display of WHOIS registration data, which includes contact information of natural and legal persons as well as technical information associated with a domain name. Through these policies and contracts, ICANN sets the minimum requirements for WHOIS, ensuring the availability of WHOIS information to mitigate attacks that threaten the stable and secure operation of the Internet and to serve the public service uses above.

      WHOIS is not a single, centrally managed database. Rather, registration data is held in disparate locations and administered by multiple registries and registrars. They each set their own conventions for the WHOIS service, consistent with the minimum requirements established in their contracts with ICANN.

      Many gTLD registries and registrars are concerned about whether ICANN policies and contracts requiring them to collect, create, retain, escrow, and publish a variety of data elements related to registry/registrar operations, domain name registrations, and registrants are in conflict with the GDPR.

      To ensure continued availability of WHOIS to the greatest extent possible and other processing of gTLD registration data while complying with the GDPR and avoid fragmentation of the WHOIS, a proposed Temporary Specification will provide a single, uniform interim model to ensure a common framework for registration data directory services. To continue this public service and maintain the security and stability of the Internet, a proposed Temporary Specification will allow for continued provision of WHOIS services via ICANN's contracts with domain name registries and accredited registrars.

      As required when a temporary policy or specification is adopted, upon adoption, the Board will also take action to implement the consensus policy development process. The Board will consult with the GNSO Council on potential paths forward (e.g. Expedited Policy Development Process) for considering a proposed Temporary Specification in a consensus policy development process which must be concluded in a one year time period.

      The Board is aware that some parts of the ICANN community has begun work to define an Accreditation Model for access to personal data in Registration Data. The Board encourages the community to continue this work, taking into account any advice and guidance that Article 29 Working Party or European Data Protection Board might provide on the topic.

      The Board is also taking action today to confirm that Board will continue to move forward with the Bylaws Consultation meeting between the GAC and the Board to address elements of a proposed Temporary Specification that are inconsistent or could be viewed as inconsistent with items of the GAC advice in the San Juan Communiqué. Article 12, Section 12.2(a)(ix) of the ICANN Bylaws permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. Any GAC advice approved by a full consensus of the GAC (as defined in the Bylaws) may only be rejected by a vote of no less than 60% of the Board, and the GAC and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. Taking steps to move forward with the Board-GAC Bylaws Consultation process will have a positive impact on the community because it will assist with resolving the advice from the GAC concerning ICANN's approach for enforcing compliance with agreements with registries and registrars in relation to the GDPR.

      The Board's action today is intended to support the continued security, stability or resiliency of the DNS, as it provides some certainty to the ICANN community that a Temporary Specification will be in place prior to 25 May 2018. Upon adoption, a proposed Temporary Specification will assist in maintaining WHOIS to the greatest extent possible while the community works to develop a consensus policy. While not initiated by today's decision, the expected initiation of focused consensus policy development work to consider a proposed Temporary Specification is anticipated to have an impact on financial resources as the research and work progresses. If the resource needs are greater than the amounts currently budgeted to perform work on WHOIS- and GDPR-related issues, the President and CEO will bring any additional resource needs to the Board Finance Committee for consideration, in line with existing fund request practices.

      This is an Organizational Administrative Function of the Board for which public comment is not required, however the proposed Interim Compliance Model proposed to be implemented through a proposed Temporary Specification has been the subject of comments from the community over the past several months (https://www.icann.org/resources/pages/gdpr-legal-analysis-2017-11-17-en). The Board actions approved today help serve the public interest and further the requirement in ICANN's Bylaws to "assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data." [Bylaws Sec. 4.6(e)(ii)]

    3. Consideration of Reconsideration Request 17-5

      Chris Disspain, Chair of the Board Accountability Mechanisms Committee (BAMC), introduced the agenda item. Chris provided a summary of Reconsideration Request 17-5, which was filed by community applicant DotKids Foundation challenging ICANN organization's decision to take the Requestor's .KIDS community generic top-level domain (gTLD) application off hold before the Community Priority Evaluation (CPE) Process Review was completed. The BAMC has considered Request 17-5 and recommended that reconsideration be denied on the basis that that the Requestor has received the relief requested and therefore Request 17-5 is moot as the CPE Process Review has been completed.

      One Board member abstained from consideration of this matter noting potential conflicts.

      The Chair then called for a vote and the Board took the following action:

      Whereas, DotKids Foundation (the Requestor) filed Reconsideration Request 17-5 (Request 17-5) challenging ICANN organization's decision to take the Requestor's .KIDS community generic top-level domain (gTLD) application off hold before the Community Priority Evaluation (CPE) Process Review was completed.3

      Whereas, the Board previously directed the President and CEO or his designees to undertake a review of the "process by which ICANN [organization] interacted with the [Community Priority Evaluation (CPE)] Provider, both generally and specifically with respect to the CPE reports issued by the CPE Provider". (See https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a.)

      Whereas, the Board Governance Committee (BGC) determined that the review should also include: (i) an evaluation of whether the CPE criteria were applied consistently throughout each CPE report; and (ii) a compilation of the research relied upon by the CPE Provider to the extent such research exists for the evaluations that are the subject of pending Reconsideration Requests relating to the CPE process (collectively, the CPE Process Review). (See https://www.icann.org/resources/board-material/minutes-bgc-2016-10-18-en.)

      Whereas, the BGC determined that the pending Reconsideration Requests relating the CPE process would be on hold until the CPE Process Review was completed. (See https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf [PDF, 405 KB].)

      Whereas, the Requestor did not have a pending accountability mechanism regarding the CPE process during the CPE Process Review and therefore, its application and the .KID/.KIDS contention set were free proceed through the application and contention resolution process as called for in the Applicant Guidebook.

      Whereas, on 15 March 2018, in Resolutions 2018.03.15.08 through 2018.03.15.11, the Board: acknowledged and accepted the findings set forth in the CPE Process Review Reports; declared that the CPE Process Review was complete; concluded that, as a result of the findings in the CPE Process Review Reports there would be no overhaul or change to the CPE process for this current round of the New gTLD Program; and directed the Board Accountability Mechanisms Committee (BAMC) to move forward with consideration of the remaining Reconsideration Requests relating to the CPE process that were placed on hold pending completion of the CPE Process Review.

      Whereas, the BAMC previously determined that Request 17-5 is sufficiently stated and sent the Request to the Ombudsman for review and consideration in accordance with Article 4, Section 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 carefully considered the merits of Request 17-5 and all relevant materials and recommended that Request 17-5 be denied on the basis that that the Requestor has received the relief requested and therefore Request 17-5 is moot as the CPE Process Review has been completed; and that the Requestor's claims are unsupported because ICANN organization adhered to established policies and procedures when it took the .KID/.KIDS contention set off hold after the resolution of all accountability mechanisms affecting the contention set. The Board agrees.

      Whereas, the Requestor did not file a rebuttal to the BAMC Recommendation on Request 17-5 within the allotted time under Article 4, Section 4.2(q) of the Bylaws.

      Resolved (2018.05.13.15), the Board adopts the BAMC Recommendation on Request 17-5 [PDF, 146 KB].

      Fifteen Board members voted in favor of Resolution 2018.05.13.15. One Board member abstained. The Resolution carried.

      Rationale for Resolution 2018.05.13.15

      1. Brief Summary

        The Requestor submitted a community-based application for .KIDS (.KIDS Application), which was placed in a contention set with one other .KIDS application and an application for .KID (the .KID/.KIDS contention set).4 The Requestor participated in CPE, but did not prevail. The Requestor previously challenged the CPE Provider's evaluation of its community application in Reconsideration Request 16-6 (Request 16-6). The filing of Request 16-6 impacted the status of the .KID/.KIDS contention set, which was placed on hold pending resolution of Request 16-6.5 ICANN's Board Governance Committee (BGC) issued a final determination denying Request 16-6 on 21 July 2016,6 after which the .KID/.KIDS contention set was taken off hold.7

        The Board previously directed the President and CEO or his designees to undertake a review of the "process by which ICANN [organization] interacted with the [Community Priority Evaluation] CPE Provider, both generally and specifically with respect to the CPE reports issued by the CPE Provider" as part of the Board's oversight of the New gTLD Program (Scope 1).8 The Board's action was part of the ongoing discussions regarding various aspects of the CPE process.

        Thereafter, the BGC determined that the review should also include: (i) an evaluation of whether the CPE criteria were applied consistently throughout each CPE report (Scope 2); and (ii) a compilation of the research relied upon by the CPE Provider to the extent such research exists for the evaluations that are the subject of pending Reconsideration Requests relating to the CPE process (Scope 3).9 Scopes 1, 2, and 3 are collectively referred to as the CPE Process Review. The BGC determined that the following pending Reconsideration Requests would be on hold until the CPE Process Review was completed: 14-30 (.LLC),10 14-32 (.INC),11 14-3312 (.LLP), 16-3 (.GAY), 16-5 (.MUSIC), 16-8 (.CPA), 16-11 (.HOTEL), and 16-12 (.MERCK).13 The Requestor did not have a pending reconsideration request regarding the CPE process when the CPE Process Review began and therefore, its application and the .KID/.KIDS contention set proceeded through the application process and nothing was placed on hold.

        On 2 October 2017, ICANN organization invited the Requestor to an ICANN Auction for the .KID/.KIDS contention set.14 Between October and December 2017, ICANN organization sent the Requestor several reminders to submit certain requested information by an 8 December 2017 deadline in order to participate in the ICANN-facilitated Auction.

        On 6 December 2017, two days before the deadline to submit information for the ICANN Auction, the Requestor filed Reconsideration Request 17-5 (Request 17-5) challenging ICANN organization's decision to take the Requestor's .KIDS gTLD application off hold before the CPE Process Review was completed.15 The filing of Request 17-5 impacted the status of the .KID/.KIDS contention set, which was placed on hold pending resolution of Request 17-5, and which resulted in the cancellation of the ICANN Auction of the .KID/.KIDS contention set.16

        On 13 December 2017, ICANN organization published the three reports on the CPE Process Review.17

        On 15 March 2018, the Board acknowledged and accepted the findings set forth in the CPE Process Review Reports, declared that the CPE Process Review was complete, concluded that, as a result of the findings in the CPE Process Review Reports there would be no overhaul or change to the CPE process for this current round of the New gTLD Program, and directed the Board Accountability Mechanisms Committee (BAMC) to move forward with consideration of the remaining Reconsideration Requests relating to the CPE process that were placed on hold pending completion of the CPE Process Review.18

        On 5 April 2018, the BAMC evaluated Request 17-5 and all relevant materials and recommended the Board deny Request 17-5 because: (1) the Requestor has received the relief requested and therefore Request 17-5 is moot as the CPE Process Review has been completed; and (2) ICANN organization complied with established policy(ies) when it took the .KID/.KIDS contention set off hold after the resolution of all accountability mechanisms affecting the contention set. (See BAMC Recommendation [PDF, 146 KB], attached as Attachment C to the Reference Materials.)

      2. Facts and Recommendation

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

        On 5 April 2018, the BAMC recommended that Request 17-5 be denied on the basis that: (1) the Requestor has received the relief requested and therefore Request 17-5 is moot as the CPE Process Review has been completed; and (2) ICANN organization complied with established policy(ies) when it took the .KID/.KIDS contention set off hold after the resolution of all accountability mechanisms affecting the contention set and therefore Request 17-5 does not set forth a proper basis for reconsideration for the reasons set forth in the BAMC Recommendation [PDF, 146 KB], which are incorporated here.

      3. Issues

        The issues for reconsideration are:

        • Whether Request 17-5 is moot because the CPE Process Review reports are complete and published; and
        • Whether ICANN organization complied with applicable Commitments, Core Values, and established policies when it took the .KID/.KIDS contention set off "Hold" status and resumed processing the contention set in accordance with the New gTLD Program by scheduling an ICANN Auction after the Requester's Reconsideration Request 16-6 was denied in July 2016.
      4. The Relevant Standards for Evaluating Reconsideration Requests

        Article 4, Section 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. (Bylaws 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. (Bylawsat § 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." (Bylaws 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. (Bylaws at § 4.2(e)(vi), (q), (r).)

      5. Analysis and Rationale

        The Board has reviewed and thoroughly considered Request 17-5 and all relevant materials, including the BAMC Recommendation [PDF, 146 KB]. The Board finds the analysis set forth in the BAMC Recommendation [PDF, 146 KB], which is incorporated here, to be sound.

        1. The Requestor has Received the Relief Requested, and Therefore Request 17-5 is Moot.

          The BAMC concluded and the Board agrees that the Requestor has received the relief requested in Request 17-5, which renders Request 17-5 moot and reconsideration unnecessary. (BAMC Recommendation [PDF, 146 KB], Pgs. 13-14.)

          The Requestor asked ICANN organization to "place the [.KIDS] application on hold until the CPE review reports are complete and published."19 This is precisely what ICANN organization has done. Immediately following ICANN organization's receipt of Request 17-5, ICANN organization cancelled the .KID/.KIDS contention set Auction, and placed the .KID/.KIDS contention set on hold, because string contention sets are only eligible to enter into an Auction if, among other things, there is no pending ICANN Accountability Mechanism relevant to the string.20

          On 13 December 2017, while the .KID/.KIDS contention set was on hold pending resolution of Request 17-5, ICANN organization published three reports in connection with the CPE Process Review.21 On 15 March 2018, the ICANN Board acknowledged and accepted the findings set forth in the three CPE Process Review reports, and declared that the CPE Process Review was complete.22 Accordingly, the relief requested in Request 17-5 has been rendered moot by virtue of the Board's Resolution 2018.03.15.10 declaring that the CPE Process Review has been completed.

        2. ICANN Complied with Its Commitments When it Moved Forward with Processing the .KID/.KIDS Contention Set By Scheduling an Auction.

          The Requestor suggested that other community applicants "not explicitly identified in the CPE process review (e.g., the .SPA CEP/IRP by Donuts) have been put on hold we believe due to the ongoing CPE process review," such that the Requestor asserts that taking its application and the .KID/.KIDS contention set off hold before the CPE Process Review is complete "is therefore counter to the established processes."23 As discussed in detail in the the BAMC Recommendation [PDF, 146 KB], which is incorporated herein, the Requestor's position conflates multiple issues and relies on inaccurate facts. Further, the Requestor does not indicate which "established processes" it believes ICANN organization violated by taking the .KID/.KIDS contention off hold following the resolution of Request 16-6 in July 2016,24 nor does the Requestor provide any evidence of such a process violation, because none exists.

          Contrary to the Requestor's claims and consistent with its commitment to "[m]ake decisions by applying documented policies consistently, neutrally, objectively, and fairly,"25 ICANN organization treated the Requester's .KIDS Application and the .KID/.KIDS contention set the same way it treated other gTLD applications and contention sets that had no pending Accountability Mechanism when the CPE Process Review started. Finally, the Requestor suggests that it did not receive notice from ICANN organization indicating that the .KID/.KIDS contention set had been taken off hold until 2 October 2017.26 While the Requestor does not specifically assert that reconsideration is warranted on these grounds, the BAMC addressed the Requestor's claims in the BAMC's Recommendation [PDF, 146 KB], as the Requestor is mistaken, and the Board agrees. The Board finds the analysis set forth in the BAMC Recommendation [PDF, 146 KB], which is incorporated here, to be sound. (See BAMC's Recommendation [PDF, 146 KB], Pgs. 17-18.)

          Ultimately, the Requestor has not identified any element of ICANN's Mission, Commitments, Core Values, or established ICANN policy(ies) violated by ICANN organization's correspondence with the Requestor, as none were violated. Accordingly, reconsideration is not warranted.

          Pursuant to Article 4, Section 4.2(q), the Requestor has 15 days from the receipt of the BAMC's Recommendation on Request 17-5 to submit a rebuttal, which expired on 20 April 2018. On 16 April 2017, the Requestor indicated that it intended to file a rebuttal. (See Attachment D to the Reference Materials.) However, no rebuttal was filed by the 20 April 2018 deadline, and none has been filed to date.

          While the Bylaws specify that Board's final decision shall be made within 135 days of initial receipt of the Reconsideration Request by the BAMC, in this instance, the 135 days expired on same day at the deadline for the Requestor to submit a rebuttal. The Board previously expected to to consider Request 17-5 at a meeting on on 17 April 2017, before the 135-day deadline. However, as the Requestor indicated that he intended to submit a rebuttal, the Board did not take up this item on 17 April 2018 meeting, as it was important to issue a final determination on a full and complete record and allow the Requestor the opportunity to submit its rebuttal. As such, this is the first practical opportunity that the Board has to consider this matter.

          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.

    4. AOB

      The President and CEO provided an updated on the status of engagement efforts between the Amazon Cooperation Treaty Organization's member states and the Amazon corporation related to the .AMAZON generic top-level domain application, as committed in response to GAC Advice in its Abu Dhabi Communiqué.

      No resolution taken.

    The Chair then called the meeting to a close.

Published on 22 May 2018


1 For the draft January 2012 version of the AGB, see: https://newgtlds.icann.org/en/applicants/agb/guidebook-full-11jan12-en.pdf [PDF, 3.8 MB].

2 See: https://www.icann.org/en/system/files/correspondence/diaz-to-atallah-03oct17-en.pdf [PDF, 127 KB].

3 Request 17-5, § 2, at Pg. 2.

4 https://gtldresult.icann.org/application-result/applicationstatus/stringcontentionstatus:viewcontentionsetimage/215?_csrf=2fa3a5b7-ca97-4722-bb10-02acbf6ac234.

5 Update on Application Status and Contention Sets, available at https://newgtlds.icann.org/en/applicants/advisories/application-contention-set-14mar14-en.

6 Prior to 22 July 2017, the BGC was designated by the ICANN Board to review and consider Reconsideration Requests pursuant to Article 4, Section 4.2 of the Bylaws. See ICANN Bylaws, 1 October 2016, Art. 4, § 4.2(e), available at https://www.icann.org/resources/pages/bylaws-2016-09-30-en#article4.

7 Attachment 1, at Pg. 1-3.

8 https://www.icann.org/resources/board-material/resolutions-2016-09-17-en#1.a.

9 https://www.icann.org/resources/board-material/minutes-bgc-2016-10-18-en.

10 Reconsideration Request 14-30 was withdrawn on 7 December 2017. See https://www.icann.org/en/system/files/files/reconsideration-14-30-dotregistry-request-redacted-07dec17-en.pdf [PDF, 600 KB].

11 Reconsideration Request 14-32 was withdrawn on 11 December 2017. See https://www.icann.org/en/system/files/files/reconsideration-14-32-dotregistry-request-redacted-11dec17-en.pdf [PDF, 626 KB].

12 Reconsideration Request 14-33 was withdrawn on 15 February 2018. See https://www.icann.org/en/system/files/files/reconsideration-14-33-dotregistry-request-redacted-15feb18-en.pdf [PDF, 42 KB].

13 Id.

14 Attachment 1, at Pg. 3.

15 Request 17-5, § 2, at Pg. 2.

16 Update on Application Status and Contention Sets, available at https://newgtlds.icann.org/en/applicants/advisories/application-contention-set-14mar14-en.

17 See https://www.icann.org/news/announcement-2017-12-13-en.

18 https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a.

19 Request 17-5, § 8, at Pg. 6.

20 See Application Details, "Application Status," available at https://gtldresult.icann.org/applicationstatus/applicationdetails/161; see also http://newgtlds.icann.org/en/applicants/auctions.

21 See https://www.icann.org/news/announcement-2017-12-13-en.

22 https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a.

23 Request 17-5, § 7, at Pg. 6.

24 See id.

25 ICANN Bylaws, 22 July 2017, Art. 1, § 1.2(a)(v).

26 Request 17-5, § 4, at Pg. 2.

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