Approved Board Resolutions | Regular Meeting of the ICANN Board 14 March 2019

  1. Consent Agenda:
    1. Approval of Minutes
    2. Approval of Amendment to Implement the Registry Service Request from Verisign to Authorize the Release for Registration of the Single-Character, Second-Level Domain, O.COM
    3. Deferral of Enforcement of Thick WHOIS Policy Implementation
    4. Appointment of the Independent Auditors for FY19
    5. Acceptance of Organizational Effectiveness Committee Charter Revisions
    6. Appointment of Root Server Operator Organization Representative to the RSSAC
    7. Approval of the Amendment to the IANA Naming Function Contract
    8. Thank You to Local Host of ICANN 64 Meeting
    9. Thank You to Sponsors of ICANN 64 Meeting
    10. Thank You to Interpreters, Staff, Event and Hotel Teams of ICANN 64 Meeting
  2. Main Agenda:
    1. Recommendations for Managing the IDN variant TLDs
    2. Preparation for implementation of subsequent procedures for new gTLDs
    3. Transfer of the .VU (Vanuatu) top-level domain to Telecommunications Radiocommunications and Broadcasting Regulator (TRBR)
    4. Consideration of Reconsideration Request 16-5: DotMusic Limited
    5. Consideration of .AMAZON
    6. Acceptance of the Second Organizational Review of the NomCom – Final Report and Recommendations
    7. Next Steps Regarding the Composition of the IANA Naming Function Review Team
    8. AOB
      1. Name Collision Analysis Project – First Study

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2019.03.14.01), the Board approves the minutes of the 16 January 2019 Special Meeting of the ICANN Board and the 27 January 2019 Regular Meeting of the ICANN Board.

    2. Approval of Amendment to Implement the Registry Service Request from Verisign to Authorize the Release for Registration of the Single-Character, Second-Level Domain, O.COM

      Whereas, ICANN organization has evaluated the proposed Amendment to the Verisign .COM Registry Agreement as a registry service pursuant to the requirements in Sections 3.1(d)(iii) and 3.1(d)(iv) of the .COM Registry Agreement and consistent with the Registry Services Evaluation Policy, ICANN org did not identify significant security or stability issues, and has posted the proposed Amendment for public comment.

      Whereas, ICANN org determined the proposed Registry Service might raise significant competition issues and referred the matter to the United States Department of Justice, and the Antitrust Division of the United States Department of Justice communicated to ICANN org that it did not intend to open an investigation on the matter.

      Whereas, ICANN org commenced a public comment period from 10 May 2018 through 20 June 2018 on the proposed Amendment to implement the approved registry service request from Verisign to release the single-character name, O.COM for registration, and a summary and analysis of the comments were provided to the Board.

      Whereas, the proposed release of the single-character domain, O.COM would be consistent with the recommendation of the GNSO Reserved Names Working Group.

      Whereas, the ICANN Board carefully considered the public comments received and the ICANN org summary and analysis of the comments.

      Whereas, the ICANN Board concludes that the proposed Amendment to allow the release of the single-character O.COM domain name is limited to the unique circumstances of this particular domain name, and the approval of the amendment does not establish a precedent that applies in other circumstances.

      Resolved (2019.03.14.02), the Amendment to the .COM Registry Agreement to release the single-character O.COM domain name in the .COM namespace is approved, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to implement the Amendment.

      Rationale for Resolution 2019.03.14.02

      Why is the Board addressing the issue now?

      In November 2017, Verisign submitted a registry service request to conduct a trial for release of one .COM domain name with a single-character label, O.COM, through an auction and to disburse the auction proceeds toward areas of public good for the Internet community, consistent with ICANN org's Single-Character Second-Level Domain Name (SCSLD) Allocation Framework.

      ICANN org conducted a review of the proposed Registry Service and did not identify significant security or stability issues. However, ICANN org did determine the proposed Registry Service might raise significant competition issues. On 7 December 2017, ICANN org referred the matter to the United States Department of Justice. On 14 December 2017, the Antitrust Division of the United States Department of Justice communicated to ICANN org that it did not intend to open an investigation on the matter.

      Following a preliminary determination of approval of the proposed registry service, ICANN org posted the proposed Amendment to the .COM Registry Agreement to enable the implementation of the service for public comment from 10 May 2018 to 20 June 2018.

      The proposed Amendment follows analysis and recommendations on single-character domain names from the GNSO's Reserved Names Working Group, the GNSO Council, and ICANN org, as well as the input from the community, and is consistent with the ICANN Board's approval of the release of single-characters names in other legacy generic top level domains (gTLDs). To date, the ICANN Board has approved the release of single-character names in many legacy gTLDs including .ORG, .BIZ, .INFO, .MOBI, and .PRO. Further, single-character names are not required to be reserved for gTLDs introduced as part of the New gTLD Program.

      ICANN org has taken the steps to evaluate and consider the proposed Amendment and the community's feedback, each of which have been made available for the ICANN Board to review and consider before making a determination.

      What is the proposal being considered?

      Under the proposed Amendment, the single-character domain name, O.COM, will be allocated through an auction process and managed by a third-party service provider. Verisign will not, directly or indirectly, receive any proceeds from the sale, allocation, transfer or renewal of O.COM and will only receive the standard registry fee for the registration of O.COM, or US$7.85. Proceeds derived from the auction of O.COM will be provided to one or more nonprofit organizations, or their successors, focused on areas of public good for the Internet community. None of the auction proceeds will directly or indirectly be used to benefit Verisign, its affiliates, or its directors, officers, or employees. Any potential registrant may participate in the auction process and select any ICANN-accredited registrar for the management of the registration for O.COM if awarded the name. No restrictions will be placed on how the registrant may select a .COM ICANN-accredited registrar.

      The winning registrant must: (i) submit the entire amount of the winning bid within fourteen (14) calendar days from the date on which it was determined to be the winner, and (ii) commit to submitting to the Trust five percent (5%) of the First Installment of the Winning Bid for each year that the domain name is renewed after expiration of the initial five (5) year registration period (each a "Subsequent Installment") up until, and including, the twenty-fifth (25th) year the winning registrant renews the single-character domain name. The Subsequent Installments are intended to encourage a continuous funding stream to the nonprofit organization(s) up until the expiration of the Subsequent Installment. By way of example, if the auction took place in 2020 and the winning bid was $10,000, the first installment of the winning bid for the single-character domain name would be $10,000 and be paid in 2020, and the Subsequent Installment for each year after the five (5) year initial term would be $500 and be paid in 2026 through 2045 (i.e., 5% of the first installment of the winning bid).

      Which stakeholders or others were consulted?

      ICANN org conducted a public comment period on the proposed amendment from 10 May 2018 to 20 June 2018. The proposal received twenty-nine (29) comments from twenty-four (24) separate entities.

      What concerns or issues were raised by the community?

      Comments submitted generally fall into the following categories, each of which is explained in more detail below:

      1. Expressing support for the proposed amendment to release O.COM.
      2. Concerns the release of O.COM may create security and stability issues.
      3. Concerns regarding the proposed "trial" requirements for the release of O.COM may set a precedent for the release of future single character .COM domain names or for the entire .COM namespace.
      4. Concerns that Verisign's proposed "Subsequent Installments" paid by the registrant to renew O.COM may be a vehicle for Verisign to increase renewal rates for the entire .COM namespace.
      5. Concerns regarding the proposed transfer restriction for the O.COM domain name imposed by Verisign once the name is allocated.
      6. Concerns over the lack of certain rights protection with the release of O.COM in the proposed Amendment.
      7. Concerns regarding the auction process and the pre-qualification requirements to be imposed by the auction provider as proposed by Verisign for the release of O.COM and the lack of transparency regarding the process.
      8. Suggestions regarding the proposed distribution of funds following the O.COM auction as proposed in the Amendment.

      Several commenters expressed positive feedback regarding the release of single-character .COM names and the proposed direction to use the auction proceeds to support the public good of the Internet and offered additional suggestions for how the proceeds could be used. A consistent theme from commenters was the need for transparency throughout the auction process from the choice of auction provider through the proposed process to manage the release of the domain name.

      Two commenters suggested that O.COM may create security and stability issues in the .COM namespace if released. Further, commenters expressed concerns with Verisign's proposed approach to auction and release of the O.COM domain name, and the proposed requirements for O.COM as inconsistent with the way current .COM domain names are registered and renewed, and the lack of certain rights protections with the release of O.COM.

      The security and stability concern raised during the public comment period focused on the potential "whole script confusability" with the release of the single-character "O.COM" domain name in the Latin Script given the Greek script and Cyrillic versions of "O.COM" already exist in the .COM namespace. Following an internal evaluation, it was determined the risk is no greater than other single-character domain names already released in other TLDs.

      Several comments expressed concerns that the proposed requirements for the release of O.COM may set a precedent for the release of single-character .COM domain names in the future or the entire .COM namespace. Specifically, commenters suggested Verisign's proposed "Subsequent Installment" paid by the registrant to renew O.COM is an opportunity for Verisign to introduce premium fees or premium renewal fees for other single-character domain names launched in the .COM namespace in the future or for all .COM domain names. ICANN org notes the RSEP proposed by Verisign, and the proposed Amendment to the .COM Registry Agreement, ensures that Verisign will only receive the standard registry fee for the initial registration of O.COM and all subsequent renewals, which shall be in compliance with registry fee pricing provisions under Section 7.3(d) of the .COM Registry Agreement. As of the submission date of the proposal, that registry fee, defined as the Maximum Price in the .COM Registry Agreement, is US$7.85. The only renewal fee Verisign will realize is the standard renewal fee at the time of renewal. The "subsequent installment" required of the winning registrant, is intended to "encourage a continuous funding stream to the nonprofit organization(s) up until the Expiration of the Subsequent Installment."

      Commenters also conveyed concerns regarding a proposed transfer restriction for the O.COM domain name proposed by Verisign once the name is allocated and suggested that this introduces unnecessary complications into the .COM namespace. Further, if this restriction is permitted, commenters worried that Verisign might extend the restriction to future single-character .COM domain names yet to be released. Commenters noted that based on the scarcity of single-character names in the valuable .COM namespace, the winning registrant should be permitted to use the name(s) as they see fit. Following a review of the public comments, Verisign voluntarily removed the proposed registrant to registrant transfer restriction from the proposed Amendment.

      Additional concerns were raised regarding the absence of certain Rights Protection Mechanisms (RPMs) to accompany the release of O.COM and possible security and stability issues once O.COM is added to the .COM namespace. However, there is no requirement to offer a sunrise period prior to the release of any reserved names according to the .COM Registry Agreement. Additionally, RSEP requests submitted and subsequently approved by the Board for .BIZ (2008), .INFO (2010), and .ORG (2011) to release single-character and two-character reserved names, did not include a sunrise period. The Uniform Domain Name Dispute Resolution Policy is available for any trademark-related disputes arising from the allocation of any name in the .COM namespace, including O.COM.

      What significant materials did the Board review?

      As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      What factors has the Board found to be significant?

      The Board carefully considered the public comments received for the amendment to implement the Registry Service request from Verisign to release the single-character name O.COM for registration, along with the summary and analysis of those comments. The Board also considered the terms agreed upon by the Registry Operator as part of the bilateral negotiations with ICANN org.

      The Board appreciates the time invested by the community to review the proposed Amendment to implement the release of O.COM. Further, the Board based its considerations on the community's engagement and feedback providing insightful suggestions to support Verisign's proposed approach to use the proceeds from the auction of O.COM for the public good of the Internet community.

      The Board also acknowledges the concerns expressed by some community members regarding the potential "whole script confusability" with the release of the single-character "O.COM" and how the release of the single-character domain name may be considered a security and stability concern. However, the Board acknowledges that other single-character domain names in both legacy and new gTLDs are available today, and work continues across the community to mitigate possible security and stability concerns for all whole-script confusables as domain names. This includes the Final Proposed Draft version 4.0 of Guidelines for the Implementation of Internationalized Domain Names (IDN Guidelines v4) published by the IDN Guidelines Working Group (IDNGWG), which recommends practices designed to minimize the risk of cybersquatting and consumer confusion. The Board notes that the draft IDN Guidelines v4, "encourage TLD registries to apply additional constraints on registrations that minimize Whole-Script Confusables…" but do not require specific mitigation, and that these IDN Guidelines v4 have not yet been adopted by the Board. It is ICANN org's practice to adhere to existing policies and procedures and to apply requirements from pending community recommendations only once they are adopted and implemented. The Board recently discussed how ICANN org should navigate incoming requests from contracted parties, when ongoing community work could result in a process change that might impact the request at the Genval workshop in September 2018.

      The Board also recognizes the concerns raised by the community noting that aspects of the proposed release of O.COM through the trial auction process have different requirements than the other domain names in the .COM namespace and may impact other domain names in the .COM namespace now and in the future. The Board acknowledges the concerns raised by the community and further recognizes Verisign's approach to release O.COM via a trial process offering Verisign and potential registrants the opportunity to gain valuable insights into the process. As stated, the proposed service would not impact the existing functionality, methods, pricing, procedures or specifications for the registration of any other domain names in the .COM namespace. Further, Verisign is bound by the terms in the .COM Registry Agreement and the release of O.COM will not change those commitments. The Board further acknowledges Verisign's update to the proposed amendment to remove the transfer restrictions in response to the concerns raised by the community.

      The Board also acknowledges the concerns raised regarding the overall auction and auction process in the proposed amendment and notes that the proposed auction process is similar to how most registry operators manage and have managed domain name auctions. Further, the registry operators for legacy TLDs such as .BIZ, .INFO, and .ORG used similar processes to auction their single and two-character TLDs. All registry operators, legacy or gTLD, can define and conduct auctions without oversight or restriction for their TLDs and rarely disclose the details of the auction in advance or the fees to be paid to the auction provider.

      The Board further acknowledges the concerns raised regarding Verisign's proposed plan to release O.COM without the RPMs new gTLD registry operators are required to support for their TLDs. Commenters suggested that with the release of O.COM, Verisign should be under the same obligations as new gTLD operators to conduct a 90- day Sunrise period. While the Board acknowledges the concerns expressed by some community members regarding Verisign's proposed plan to release O.COM without RPMs, there is no requirement to offer a sunrise period prior to the release of any reserved names according to the .COM registry agreement. Additionally, RSEP requests submitted and that called for registry agreement amendments that subsequently were approved by the Board for .BIZ (2008), .INFO (2010), and .ORG (2011) to release single-character and two-character reserved names, did not include a sunrise period. The Uniform Domain Name Dispute Resolution Policy is available for any trademark-related disputes arising from the allocation of any name in the .COM namespace, including O.COM.

      Are there positive or negative community impacts?

      The Board's approval of the proposed amendment to release the single-character, O.COM, domain name for registration is anticipated to be positive. As several community members noted during the public comment period, this is a positive step forward to releasing more single-character domain names, specifically in the .COM namespace. Further, commenters support Verisign's proposed approach to use the proceeds from the auction of O.COM for the public good of the Internet community and encourage Verisign to be transparent in how the proceeds are distributed.

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

      There is no significant fiscal impact to ICANN org expected from the release of the single-character O.COM for registration.

      Are there any security, stability or resiliency issues relating to the DNS?

      As noted above, the question as to whether the release of O.COM may cause a security or stability issue was raised during the public comment period. The concern raised involved the possible "whole-script" confusability of the Latin script "O.COM" with the Greek and Cyrillic characters already in the .COM namespace and contends that the release of O.COM may conflict with the draft IDN Guidelines v4. ICANN org has confirmed to the Board that the draft IDN Guidelines v4, "encourage TLD registries to apply additional constraints on registrations that minimize Whole-Script Confusables…" but do not require specific mitigation and this release of O.COM would not conflict with the IDN Guidelines v4. Furthermore, the IDN Guidelines v4 are not yet adopted by the Board as ICANN org continues to define the implementation plan to ensure a smooth transition to the new guidelines. The IDN Guidelines v4 anticipate the need for treating existing domains as exceptions, "When a pre-existing domain name requires a registry to make transitional exception to any of these Guidelines, the terms of that action must also be made readily available online, including the timeline for the resolution of such transitional matters." and would expect Verisign to comply with this requirement in due course.

    3. Deferral of Enforcement of Thick WHOIS Policy Implementation

      Whereas, the Thick WHOIS Transition Policy requires that Verisign begin accepting "Thick" registration data from registrars for .COM and .NET names starting 30 November 2019, that all new domain name registrations be submitted to the registry as "Thick" by 31 May 2020, and that all relevant registration data for existing domain names be migrated from "Thin" to "Thick" by 30 November 2020.

      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 expressed concerns about Verisign's proposed amendments based on issues relating to the European Union's General Data Protection Regulation, the processing of data, and new requirements and obligations imposed on the registrars.

      Whereas, ICANN org has continued to facilitate 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 Transition 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 Transition Policy.

      Whereas, the deferred enforcement period will allow the ICANN community and the Board time to consider the Final Report from the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data.

      Whereas the additional time will allow the affected contracted parties and ICANN org additional time to assess any potential impact on the Thick WHOIS Transition Policy from the recommendations from the EPDP.

      Resolved (2019.3.14.03), the President and CEO, or his designee(s), is authorized to defer compliance enforcement of the Thick WHOIS Transition Policy to 30 November 2019, 31 May 2020, and 30 November 2020, respectively.

      Rationale for Resolution 2019.03.14.03

      The Thick WHOIS Transition Policy specifies a phased approach to transition the .COM and .NET registries from "Thin" to "Thick" WHOIS. The three phases are:

      1. Registry operator (RO) to begin accepting Thick WHOIS data from registrars,
      2. New .COM and .NET domain name registrations to be created as thick registrations, and
      3. The complete migration of all existing domain registration data from "Thin" to "Thick" one year following the date the RO begins accepting Thick WHOIS data from registrars.

      The Thick WHOIS Transition Policy requires Verisign to begin accepting "Thick" registration data from registrars starting 31 May 2019, registrars to submit Thick registration data to Verisign for all new domain name registrations starting on 30 November 2019, and the migration of all existing domain registration data from Thin to Thick by 31 May 2020. In preparation for accepting Thick WHOIS data, Verisign, the registry operator for .COM and .NET, proposed amendments to the registry-registrar agreements for .COM and .NET to have the legal framework necessary for acceptance of the data. 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 for .JOBS as per the Policy.

      Following the Registry-Registrar Agreement Amendment procedure, ICANN org 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 community through the GNSO's EPDP is working to develop a permanent Consensus Policy to replace, or confirm, the Temporary Specification for gTLD Registration Data.

      The Board is taking action at this time to authorize the ICANN President and CEO to defer compliance enforcement of the Thick WHOIS Transition Policy by 180 days. This will provide additional time for the community and Board to consider the recommendations in the Final Report from the EPDP. The deferral will also provide the affected contracted parties and ICANN org time to assess any potential impact on the Thick WHOIS Transition Policy from the recommendations from the EPDP.

      There is a risk that additional deferrals will be necessary if the EPDP team appears to be recommending significant changes to the Temporary Specification for gTLD Registration Data.

      The Board's deliberations on this matter referenced several significant materials including:

      The Board's action is not anticipated to have a fiscal impact on ICANN that is not already anticipated in the current budget. This action is in the public interest and is consistent with ICANN's mission as it helps to ensure a consistent and coordinated implementation of policies in gTLDs.

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

    4. Appointment of the Independent Auditors for FY19

      Whereas, Section 22.2 of the ICANN Bylaws (http://www.icann.org/general/bylaws.htm) requires that after the end of the fiscal year, the books of ICANN must be audited by certified public accountants, which shall be appointed by the Board.

      Whereas, the Board Audit Committee has discussed the engagement of the independent auditor for the fiscal year ending 30 June 2019 and has recommended that the Board authorize the President and CEO, or his designee(s), to take all steps necessary to engage BDO LLP and BDO member firms.

      Resolved (2019.03.14.04), the Board authorizes the President and CEO, or his designee(s), to take all steps necessary to engage BDO LLP and BDO member firms as the auditors for the financial statements for the fiscal year ending 30 June 2019.

      Rationale for Resolution 2019.03.14.04

      The audit firm BDO LLP and BDO member firms have been ICANN's independent auditors since the audit of fiscal year 2014. Based on the report from the organization and the Audit Committee's evaluation of the work performed, the committee has recommended that the Board authorize the President and CEO, or his designee(s), to take all steps necessary to engage BDO LLP and BDO member firms as ICANN's annual independent auditor for fiscal year 2019 for any annual independent audit requirements in any jurisdiction.

      This furthers ICANN's accountability to its Bylaws and processes, and the results of the independent auditors' work will be publicly available. Taking this decision is both consistent with ICANN's Mission and in the public interest as the engagement of an independent auditor is in fulfilment of ICANN's obligations to undertake an audit of ICANN's financial statements and helps serve ICANN's stakeholders in a more accountable manner.

      This decision will have a fiscal impact on ICANN as is intended. This should not have any direct impact on the security, stability and resiliency of the domain name system.

      This is an Organizational Administrative Function not requiring public comment.

    5. Acceptance of Organizational Effectiveness Committee Charter Revisions

      Whereas, the Organizational Effectiveness Committee of the ICANN Board currently has responsibility for oversight of the Organizational and Specific Reviews mandated under the ICANN Bylaws. Under the post-IANA Stewardship Transition Bylaws, Article 18, ICANN is also responsible for causing periodic and special IANA naming function reviews, which are aimed at reviewing PTI's performance under the IANA Naming Function Contract and the IANA Naming Function Statement of Work. To date, no committee of the Board has been designated with oversight responsibility as it relates to the IANA naming function reviews (IFRs).

      Whereas, the Organizational Effectiveness Committee has proposed revisions to its current charter to reflect the oversight responsibility for IFRs.

      Whereas, the Board Governance Committee, charged with consideration of Committee charters agrees with the OEC's proposal and recommends the Board adopt this revised OEC Charter.

      Resolved (2019.03.14.05), that the Board adopts the proposed revisions to the Organizational Effectiveness Committee Charter.

      Rationale for Resolution 2019.03.14.05

      Why the Board is addressing the issue?

      The Board is addressing this issue because of the requirement that the Board approve revisions to charters of Board Committees.

      What is the proposal being considered?

      The Organizational Effectiveness Committee (OEC) is proposing a change to the Committee's oversight responsibility to include the IANA naming function reviews (IFRs). The OEC proposes to assume oversight responsibility over IFRs given the OEC's existing oversight role in connection with Specific and Organizational Reviews.

      What significant materials did the Board review?

      The Board reviewed the proposed revisions to the 2017 OEC charter. See Reference Materials, Exhibit A (redlined) and Exhibit B (clean).

      Are there positive or negative community impacts?

      The proposed revisions are intended to provide clarity and align Bylaws-mandated reviews in order to consistently apply Board oversight. These developments are expected to have a positive impact on the community. The IFRs are a key way for ICANN to confirm that its affiliate and contractor, Public Technical Identifiers, is performing appropriately against its contracts, and it is appropriate to have defined Board-level oversight for such review.

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

      There will be no fiscal impact or adverse ramifications on ICANN's strategic and operating plans from the proposed changes.

      Are there any security, stability or resiliency issues relating to the DNS?

      There are no security, stability or resiliency issues relating to the DNS as the result of this action.

      How is this action within ICANN's mission and what is the public interest served in this action?

      The Board's action is consistent with ICANN's commitment pursuant to Article 18 of the Bylaws to ensure that PTI performs the IANA naming function in accordance with the contractual requirements set forth in the IANA Naming Function Contract and the IANA Naming Function SOW. This action will serve the public interest in that it assures ICANN Board oversight over how ICANN and PTI are meeting ICANN's commitment to deliver IANA naming function services to the expectations of the customers and the broader ICANN community.

      Is public comment required prior to Board action?

      No public comment is required.

    6. Appointment of Root Server Operator Organization Representative to the RSSAC

      Whereas, the ICANN Bylaws call for the establishment of the Root Server System Advisory Committee (RSSAC) with the role to advise the ICANN community and ICANN Board of Directors on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System.

      Whereas, the ICANN Bylaws call for the ICANN Board of Directors to appoint one RSSAC member from each root server operator organization, based on recommendations from the RSSAC Co-Chairs.

      Whereas, in February 2019, Réseaux IP Européens Network Coordination Centre (RIPE NCC) requested to change its representative for the remainder of the current term, which expires on 31 December 2020.

      Whereas, the RSSAC Co-Chairs have recommended to the ICANN Board of Directors the appointment of a representative from RIPE NCC to the RSSAC.

      Resolved (2019.03.14.06), the ICANN Board of Directors appoints Kaveh Ranjbar to the RSSAC through 31 December 2020.

      Rationale for Resolution 2019.03.14.06

      In May 2013, the root server operator organizations agreed to an initial membership of representatives for the RSSAC, each nominating an individual. The ICANN Board of Directors approved the initial membership of the RSSAC in July 2013 with staggered terms.

      In February 2019, RIPE NCC requested to change its representative for the remainder of the current term, which expires on 31 December 2020.

      The appointment of RSSAC members is not anticipated to have any fiscal impact on the ICANN organization that has not already been accounted for in the budgeted resources necessary for ongoing support of the RSSAC.

      This resolution is an Organizational Administrative Function for which no public comment is required. The appointment of RSSAC members contributes to the commitment of the ICANN organization to strengthen the security, stability, and resiliency of the DNS.

    7. Approval of the Amendment to the IANA Naming Function Contract

      Whereas, the ICANN Bylaws, at Section 16.3, require ICANN and PTI to maintain an IANA Naming Function Contract for PTI's performance of the IANA naming function. The initial IANA Naming Function Contract was approved by both the ICANN and PTI Boards in 2016 as part of the IANA Stewardship Transition.

      Whereas, the IANA Naming Function Contract currently includes a table specifying detailed, operational Service Level Agreements (SLA Table) as agreed with the multi-stakeholder community during the IANA Stewardship Transition process.

      Whereas, ICANN org, PTI and the Customer Standing Committee (CSC) have all identified that requiring a modification to the IANA Naming Function Contract every time that an individual SLA needs to be modified, deleted or added is not sustainable and does not serve the needs of ICANN, PTI or the customers of the IANA Naming Function. Therefore, a proposal was reached to amend the IANA Naming Function Contract one time in order to move the SLA Table to outside of the Contract, and to require any changes to said SLAs to follow a community approved and published "Process for Amending the IANA Naming Service Level Agreements".

      Whereas, ICANN org, PTI and the CSC participated in the development of the Process for Amending the IANA Naming Service Level Agreements, and the CSC socialized that process with the customers of the IANA Naming Function.

      Whereas, ICANN solicited public comment on the proposed Naming Function Contract amendment to the IANA Naming Function Contract from 7 January 2019 to 18 February 2019.

      Whereas, the public comment forum for the proposed amendment to the IANA Naming Function Contract closed on 18 February 2018, with ICANN receiving one comment from the Registries Stakeholder Group supporting the proposed amendment. A summary and analysis of the comments was published on 25 February 2019 and provided to the Board.

      Resolved (2019.03.14.07), the proposed Amendment No. 1 to the IANA Naming Function Contract is approved, and the President and CEO, or his designee(s) is authorized to take such actions as appropriate to finalize and execute the Agreement.

      Rationale for Resolution 2019.03.14.07

      The Customer Standing Committee (CSC), working with ICANN org and PTI, has recommended changes based on evidence from accrued operational data. In proposing that the SLAs be moved from the contract to a SLA table on a PTI webpage, it was recognized that a comprehensive SLA change process was required to ensure that appropriate consultations with the IANA Function naming customers and broader ICANN community occur.

      In the CSC's meeting held on 17 December 2018, it approved the two SLA change processes: a 'Process for amending the IANA Naming Function Service Level agreements' and a 'Procedure for Modifying the process for amending the IANA Naming Function Service Level agreements'. ICANN org and PTI management were involved in the conversations and agree to the processes as well. The processes are not in force until such time as the naming function contract is amended.

      The Board is approving the amendment to the IANA Naming Function Contract at this time because moving IANA Naming Function SLAs from the contract to a SLA table on a webpage allows SLA changes to more efficiently meet the needs of naming customers, while adherence to the new "Process for Amending the IANA Naming Service Level Agreements" ensures all such changes follow a strict process to ensures appropriate levels of community consultation and agreement between the CSC and ICANN/PTI.

      The Board's action takes into consideration input from the community, which supported the amendment through the CSC's approval, as well the RySG's public comment which stated that "This amendment to the IANA Naming Functions Contract adopts an SLA Change Process that was cooperatively developed and agreed to by the CSC, PTI, and ICANN org. The SLA Change Process will allow the CSC and PTI to a) modify SLAs where appropriate b) add new SLAs as new services come on-line and, c) remove SLAs not warranted anymore. _The RySG supports the Amendment and requests the ICANN Board to approve the Amendment so that SLAs that currently need to be modified or added or removed may be accomplished as soon as possible."

      The action directed in this resolution will not have any further impact on ICANN resources or the security and stability of the DNS. This action is within ICANN's mission as it supports ICANN carrying out the IANA naming functions.

    8. Thank You to Local Host of ICANN 64 Meeting

      The Board wishes to extend its thanks to Ms.Yukari Sato, The State Minister for Internal Affairs and Communications, Mr. Kizō Hisamoto, Mayor of Kobe City, Prof. Jun Murai, Chairman of the ICANN64 Local Host Committee and the ICANN64 local host committee members, GMO Internet Inc., Japan Registry Services Co. Ltd., Internet Initiative Japan Inc., Internet Association Japan, Internet Multifeed Co., Interlink Co. Ltd., NTT Docomo Inc., Telecom Services Association, Japan Network Information Center, BusinessRalliart Inc., The Kyoto College of Graduate Studies for Informatics, Com Laude (Japan) Corporation, Taka Enterprise Ltd., Japan Internet Providers Association, WIDE Project, NTT Communications Corporation, KDDI Corporation, Nippon Telegraph and Telephone West Corporation. Also, thanks to Ministry of Internal Affairs and Communications, Kobe Convention Bureau and Tsutomu Nakauchi Foundation for their great support.

    9. Thank You to Sponsors of ICANN 64 Meeting

      The Board wishes to thank the following sponsors: Verisign, Public Interest Registry, Afilias plc, and CentralNic.

    10. Thank You to Interpreters, Staff, Event and Hotel Teams of ICANN 64 Meeting

      The Board expresses its deepest appreciation to the scribes, interpreters, audiovisual team, technical teams, and the entire ICANN staff for their efforts in facilitating the smooth operation of the meeting. The Board would also like to thank the management and staff of Kobe Portopia Hotel and Kobe International Conference Center for providing a wonderful facility to hold this event. Special thanks are extended to Kobe International Conference Center team, Omura Masatoshi, Rikako Nakanishi, Aya Fukuda, Eiji Makatsuj i, Yuko Zikumaru, Tetsuya Shori and Lance Ferguson and Kobe Portopia Hotel Event and IT staff, Hitoshi Nakauchi, Tsuyoshi Ito, Takahiko Kishimoto, Kenji Kino, Shingo Murakami, Takumi Nishihara, Tomoko Nishio, Tomoya Takeda, Makoto Sakai, Shohei Inoue, Yosuke Taniguchi, Rose Tanasugarn and Gilbert Yeo, Manager of Pryde Productions.

  2. Main Agenda:

    1. Recommendations for Managing the IDN variant TLDs

      Whereas, Internationalized Domain Names (IDNs) enable Internet users to access domain names in their own languages and remain a key component of ICANN's work.

      Whereas, the Board recognizes that IDN variants are an important component for some IDN top-level domain (TLD) strings and that implementation of variant labels in the root zone must take place in a way that maintains the security and stability of the DNS.

      Whereas, the Board resolved in 2010 that IDN variant TLDs will not be delegated until relevant work is completed and directed ICANN org to develop a report identifying what needs to be done with the evaluation, possible delegation, allocation and operation of generic top-level domains (gTLDs) containing variant characters IDNs, in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs.

      Whereas, based on six case studies, integrated into A Study of Issues Related to the Management of IDN Variant TLDs in 2012, ICANN org and the community identified two gaps to address: first that there is no definition of IDN variant TLDs, and second that there is no IDN variant TLD management mechanism.

      Whereas, the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels (RZ-LGR Procedure) has been developed by the community to define the IDN variant TLDs and, following the Board resolution in 2013 which approved the RZ-LGR Procedure, has been implemented to incrementally develop the Root Zone Label Generation Rules to address the first gap.

      Whereas, ICANN org has developed the Recommendations for Managing IDN Variant TLDs (the Variant TLD Recommendations), a collection of six documents finalized after incorporating the public comment feedback and published them as mechanisms for addressing the second gap identified by the community in the implementation of IDN variant TLDs.

      Resolved (2019.03.14.08), the Board approves the Variant TLD Recommendations and requests that the ccNSO and GNSO take into account the Variant TLD Recommendations while developing their respective policies to define and manage the IDN variant TLDs for the current TLDs as well as for future TLD applications.

      Resolved (2019.03.14.09), the Board requests that the ccNSO and GNSO keep each other informed of the progress in developing the relevant details of their policies and procedures to ensure a consistent solution, based on the Variant TLD Recommendations, is developed for IDN variant ccTLDs and IDN variant gTLDs.

      Resolved (2019.03.14.10), the Board also recognizes the significant community effort and contribution, since the start of the IDN Variant Issues Project in 2011, which has led to the development of the Variant TLD Recommendations.

      Rationale for Resolutions 2019.03.14.08 – 2019.03.14.10

      Internationalized Domain Names (IDNs) enable people around the world to use domain names in local languages and scripts. Some script communities have identified that technically distinct domain labels may be considered indistinguishable with other domain labels and therefore the "same" labels, referred to as variant labels. The IDNs in Applications (IDNA) 2008 standard, while stipulating how to use domain names in multiple scripts, also asks in RFC 58941 that "registries should develop and apply additional restrictions as needed to reduce confusion and other problems … For many scripts, the use of variant techniques … may be helpful in reducing problems that might be perceived by users. … In general, users will benefit if registries only permit characters from scripts that are well-understood by the registry or its advisers."

      Based on the IDNA2008 standard, variant labels must minimally be identified and managed to ensure that end-users are prevented from any security threats. A few of the variant labels identified could even be activated to promote usability of the IDNs, as different language communities using a script may use a different variant label. In some cases, applications for IDN ccTLDs and new gTLDs have identified additional labels considered as variant labels, indicating that the community may consider these different labels as variants of each other. However, due to lack of a clear definition and a solution to implement them, ICANN Board resolved on 25 September 2010 that "no variants of gTLDs will be delegated through the New gTLD Program until appropriate variant management solutions are developed." The resolution further directed ICANN staff to develop "an issues report identifying what needs to be done with the evaluation, possible delegation, allocation and operation of gTLDs containing variant characters IDNs as part of the new gTLD process in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs."

      Achieving these security and usability goals in a stable manner is the key challenge to be addressed. To address these complex linguistic and technical issues, ICANN organization undertook the IDN Variant Issues Project under the guidance of the ICANN Board. As a first step, it engaged with experts from six script communities, who analyzed issues in identifying variant labels for each of these scripts. This analysis of issues for Arabic, Chinese, Cyrillic, Devanagari, Greek, and Latin scripts in 2011, integrated in the Integrated Issues Report (IIR) (2012) identified two challenges:

      1. "in the DNS environment today, there is no accepted definition for what may constitute a variant relationship between top-level labels
      2. "nor is there a 'variant management' mechanism for the top level, although such has often been proposed as a way to facilitate solutions to a particular problem."

      1. Defining Variant TLDs

      IIR outlined the follow-on work that might be undertaken. To address the first problem noted in IIR, the community developed Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels (RZ-LGR Procedure). Based on the direction of the ICANN Board on 11 April 2013, ICANN undertook RZ-LGR Procedure which follows a two-step process, requiring each community to develop individual script-based Label Generation Rules (LGR) proposal and an expert panel to review and integrate each proposal into the Root Zone LGR (RZ-LGR). Multiple script communities have finalized their proposals, from which Arabic, Ethiopic, Georgian, Khmer, Lao and Thai script proposals have been integrated into its second version, RZ-LGR-2. Many other script communities are also active in defining their rules. Further, a specification to encode these linguistic details into a formal machine-readable format has also been developed and released through IETF as standards track RFC 7940: Representing Label Generation Rulesets Using XML. A LGR tool has also been developed to create, use and manage the LGRs, and is available for the community online as well as for download with an open source license.

      2. Analyzing Variant TLD Management Mechanisms

      The label generation rules for the root zone derived from the process described above produce variant TLD labels that are candidates for allocation. To address the second part of the need stated in Integrated Issues Report for a variant management mechanism for the top level, it is necessary for the ICANN community to develop the policies and procedures that govern such allocation of variant names. The set of documents, finalized after public comment and published, offer recommendations for consideration by the ccNSO and GNSO during the development of relevant policies and procedures in accordance with their respective Policy Development Processes (PDPs). These documents also analyze the recommendations and their impact on the gTLD application process, as described in the New gTLD Applicant Guidebook, and on the IDN ccTLD application process, based on the Final Implementation Plan for the IDN ccTLD Fast Track Process. The fundamental premises for the recommendations and analysis presented arise mostly from observations by the community in Integrated Issues Report and advice presented by the Security and Stability Advisory Committee (SSAC) in its SAC 60 report.

      While developing the analysis, ICANN organization team has had multiple interactions with the ICANN Board IDN Working Group (BIWG) since 2014, and the BIWG has guided the development of this work. The recommendations have been designed to be conservative, with the view that the IDN variant TLDs are being implemented for the first time, and that the solution could accommodate implementation experience over time.

      The ICANN Board notes that the RZ-LGR work is well underway. The ICANN Board also notes that the initial set of recommendations for implementing IDN variant TLDs in a conservative and consistent way are available for further consideration by the ccNSO and GNSO in their work on developing relevant policy and procedures. With the prerequisites identified by the community in Integrated Issues Report in place, the next steps can now be taken by the supporting organizations (SOs).

      This will have a positive impact for the community, though there are some associated risks. Minimally, the IDN variant TLDs identified are withheld from application, which will contribute towards the security of the end users, until possibly a feasible management mechanism has been developed by the supporting organizations. Further, if consistent management mechanisms can be agreed by the ccNSO and GNSO on delegating a few of these variant labels, it can help promote the usability of the domain names across the communities which require these IDN variant TLDs. There is risk associated with taking this work forward, especially if a consistent approach to TLDs is not agreed upon by the community, as that can potentially confuse the end-users, or in other cases may cause security issues for them. The IDN variant TLDs can also cause management burden on registrants, as identified by SSAC in its SAC060 report. Following the resolution, ccNSO and GNSO will have to develop their own policies and procedures to implement IDN variant TLDs, taking into account recommendations provided. This resolution, however, is not directing either the ccNSO or the GNSO to undertake policy work on this topic. If and when the respective Final Reports containing policy recommendations, developed through the appropriate PDPs, are submitted to the ICANN Board for approval, the Board will consider how effectively these policies and procedures address the Variant TLD recommendations, their impact and the associated risks. At that time the Board will decide whether to adopt the policy recommendations and move forward with implementing the IDN variant TLDs.

      There will eventually be a fiscal impact. The extent of the fiscal impact will depend on the eventual IDN variant TLD application evaluation process and the timing of this application process suggested by the community. Therefore, the impact will need to be gauged when the ccNSO and GNSO finalize their policies and procedures for implementing IDN variant TLDs and present them for consideration by the ICANN Board.

      The recommendations contribute towards a secure and stable operation of the unique identifier system, while addressing the need for IDN variant TLDs identified by the community and respecting the community policy development role. The work on IDN variant TLDs also contributes to the public interest by enhancing access to the Internet's Domain Name System (DNS) in different scripts and languages.

    2. Preparation for implementation of subsequent procedures for new gTLDs

      No Resolutions taken.

    3. Transfer of the .VU (Vanuatu) top-level domain to Telecommunications Radiocommunications and Broadcasting Regulator (TRBR).

      Resolved (2019.03.14.11), as part of the exercise of its responsibilities under the IANA Naming Function Contract with ICANN, PTI has reviewed and evaluated the request to transfer the .VU country-code top-level domain to Telecommunications Radiocommunications and Broadcasting Regulator (TRBR). The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Rationale for Resolution 2019.03.14.11

      Why the Board is addressing the issue now?

      In accordance with the IANA Naming Function Contract, PTI has evaluated a request for ccTLD transfer and is presenting its report to the Board for review. This review by the Board is intended to ensure that the proper procedures were followed.

      What is the proposal being considered?

      The proposal is to approve a request to transfer the country-code top-level domain .VU and assign the role of manager to Telecommunications Radiocommunications and Broadcasting Regulator (TRBR).

      Which stakeholders or others were consulted?

      In the course of evaluating this transfer application, PTI consulted with the applicant and other significantly interested parties. As part of the application process, the applicant needs to describe consultations that were performed within the country concerning the ccTLD, and their applicability to their local Internet community.

      What concerns or issues were raised by the community?

      PTI is not aware of any significant issues or concerns raised by the community in relation to this request.

      What significant materials did the Board review?

      [REDACTED – SENSITIVE DELEGATION INFORMATION]

      What factors the Board found to be significant?

      The Board did not identify any specific factors of concern with this request.

      Are there positive or negative community impacts?

      The timely approval of country-code domain name managers that meet the various public interest criteria is positive toward ICANN's overall mission, the local communities to which country-code top-level domains are designated to serve, and responsive to obligations under the IANA Naming Function Contract.

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

      The administration of country-code delegations in the DNS root zone is part of the IANA functions, and the delegation action should not cause any significant variance on pre-planned expenditure. It is not the role of ICANN to assess the financial impact of the internal operations of country-code top-level domains within a country.

      Are there any security, stability or resiliency issues relating to the DNS?

      ICANN does not believe this request poses any notable risks to security, stability or resiliency. This is an Organizational Administrative Function not requiring public comment.

    4. Consideration of Reconsideration Request 16-5: DotMusic Limited

      Whereas, DotMusic Limited (DotMusic) submitted a community-based application for .MUSIC (the Application), which was placed in a contention set with other .MUSIC applications.

      Whereas, DotMusic participated in Community Priority Evaluation (CPE) and but did not prevail.

      Whereas, DotMusic, the International Federation of Musicians, the International Federation of Arts Councils and Culture Agencies, the Worldwide Independent Network, the Merlin Network, the Independent Music Companies Association, the American Association of Independent Music, the Association of Independent Music, the Content Creators Coalition, the Nashville Songwriters Association International, and ReverbNation (collectively, Requestors) submitted Reconsideration Request 16-5, seeking reconsideration of the CPE report of the Application, and ICANN organization's acceptance of that CPE report.

      Whereas, while Request 16-5 was pending, the Board directed ICANN org to undertake a review of the CPE process (the CPE Process Review). The Board Governance Committee (BGC) determined that the pending Reconsideration Requests regarding the CPE process, including Request 16-5, would be placed on hold until the CPE Process Review was completed.2

      Whereas, on 13 December 2017, ICANN org published three reports on the CPE Process Review (CPE Process Review Reports).

      Whereas, on 15 March 2018, the Board passed Resolutions 2018.03.15.08 through 2018.03.15.11, which 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 Mechanism 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, in accordance with Resolutions 2018.03.15.08 through 2018.03.15.11, the BAMC invited the Requestors to submit additional materials and to make a presentation to the BAMC in support of Request 16-5; the Requestors rejected both invitations from the BAMC.

      Whereas, the BAMC has carefully considered the merits of Request 16-5 and all relevant materials and has recommended that Request 16-5 be denied because the CPE Provider did not violate any established policies or procedure in conducting the CPE and ICANN org complied with established policies, Bylaws, and Articles of Incorporation when it accepted the CPE Report. The BAMC also recommended that the Board deny Request 16-5 because the Requestors did not identify any misapplication of policy or procedure by the CPE Provider that materially or adversely affected the Requestors.

      Whereas, the Board has carefully considered the BAMC's Recommendation on Request 16-5 and all relevant materials related to Request 16-5, including the Requestors' rebuttal, and the Board agrees with the BAMC's Recommendation and concludes that the rebuttal provides no additional argument or evidence to support reconsideration.

      Resolved (2019.03.14.12), the Board adopts the BAMC Recommendation on Request 16-5.

      Rationale for Resolution 2019.03.14.12

      1. Brief Summary and Recommendation

        The full factual background is set forth in the BAMC Recommendation on Request 16-5 (BAMC Recommendation), which the Board has reviewed and considered, and which is incorporated here.

        On 25 January 2018, the BAMC evaluated Request 16-5 and all relevant materials and recommended that the Board deny Request 16-5 because the CPE Provider did not violate any established policies or procedure in conducting the CPE and ICANN org complied with established policies, Bylaws, and Articles of Incorporation when it accepted the CPE Report.  The BAMC also recommended that the Board deny Request 16-5 because the Requestors did not identify any misapplication of policy or procedure by the CPE Provider that materially or adversely affected the Requestors.

        The Board has carefully considered the BAMC's Recommendation and all relevant materials related to Request 16-5, and the Board agrees with the BAMC's Recommendation.

        On 12 February 2019, the Requestors submitted a rebuttal to the BAMC's Recommendation (Rebuttal). The Board notes that the Rebuttal is not called for under the Bylaws applicable to Request 16-5.3 Nonetheless, the Board has considered the arguments set out in the Requestors' rebuttal and finds that they do not support reconsideration for the reasons set forth below.

      2. Issue

        The issues are as follows:

        • Whether the Declaration of the Independent Review Process (IRP) Panel in Little Birch LLC et al. v. ICANN and Despegar Online SRL et al. v. ICANN (Despegar IRP) requires the Board to reconsider the CPE Report;
        • Whether the Board's acceptance of ICANN's Governmental Advisory Committee (GAC) Category 1 and 2 Advice required the CPE Provider to grant the Application community priority;
        • Whether the CPE Provider had a conflict of interest with respect to the Application;
        • Whether ICANN org made any revisions to the CPE Report, and if so, whether those revisions adhered to established policies or procedures;
        • Whether the CPE Provider adhered to applicable policies and procedures in its application of CPE criterion 1: Community Establishment;
        • Whether the CPE Provider adhered to applicable policies and procedures in its application of CPE sub-criterion 2-A-Nexus; and
        • Whether the CPE Provider adhered to applicable policies and procedures in its application of CPE sub-criterion 4-A-Support.

        These issues are considered under the relevant standards for reconsideration requests in effect at the time that Request 16-5 was submitted. These standards are discussed in detail in the BAMC Recommendation and are incorporated here.

      3. Analysis and Rationale

        1. The CPE Criteria and Procedures

          CPE is a contention resolution mechanism available to applicants that self-designated their applications as community applications.4 The CPE standards and CPE process are defined in Module 4, Section 4.2 of the Applicant Guidebook (Guidebook). Community-based applications that undergo CPE are evaluated by the following criteria: Criterion 1: Community Establishment; Criterion 2: Nexus Between the Proposed String and Community; Criterion 3: Registration Policies; and Criterion 3: Community Endorsement.5 Pursuant to the Guidebook, the sequence of the criteria reflects the order in which those criteria will be assessed by the CPE Provider. To prevail in CPE, an application must receive at least 14 out of 16 points on the scoring of the four criteria, each of which is worth a maximum of four points. An application that prevails in CPE "eliminates all directly contending standard applications, regardless of how well qualified the latter may be."6 CPE is performed by an independent panel composed of two evaluators who are appointed by the CPE Provider.7 A CPE Provider's role is to determine whether the community-based application fulfills the four community priority criteria set forth in Module 4.2.3 of the Guidebook.8

          The CPE process does not determine the existence, adequacy, or validity of a community. It merely evaluates whether a community-based application satisfies the CPE criteria for community priority. As the Guidebook notes, "a finding by the [CPE Provider] that an application does not meet the scoring threshold to prevail in a community priority evaluation is not necessarily an indication the community itself is in some way inadequate or invalid."9

        2. The Despegar IRP Declaration Does Not Support Reconsideration.

          The Requestors claim that reconsideration is appropriate because the CPE process is purportedly fundamentally flawed. In support, the Requestors reference the Despegar IRP Declaration, which the Requestors argue points out issues and concerns that the IRP Panel had with the CPE process.10 The Requestors contend that the concerns expressed by the DespegarIRP Panel demonstrate that the CPE Provider and ICANN org violated established policies and procedures relating to the evaluation of the Application.11 The DespegarIRP Panel recommended, among other things, that a system be put in place for future new gTLD rounds to ensure that CPE evaluations are conducted "on a consistent and predictable basis by different individual evaluators" and that ICANN org's core values "flow through . . . to entities such as the [CPE Provider]."12 The Requestors seem to assert that the Despegar IRP Declaration requires the Board to either conduct a review of the CPE Process as a whole—which the Board did in the CPE Process Review—or to reject the CPE Report here based on the purported flaws.13

          However, as BAMC concluded, and the Board agrees, nothing in the Despegar IRP Declaration or ICANN org's acceptance of it mandates that result. In accepting the Despegar IRP Declaration (2016 Resolution),14 the Board "note[d] the [IRP] Panel's suggestions" and directed ICANN org to "ensure that the New gTLD Program Reviews take into consideration the issues raised by the Panel as they relate to the consistency and predictability of the CPE process and third-party provider evaluations."15 Separately, the CPE Process Review provided additional careful review of the CPE process, with special consideration of ICANN org's relationship with the CPE Provider.16

          Nothing about the Despegar IRP Declaration or the Board's acceptance of it mandates that the CPE process be modified for the Application,17 or that the BAMC change its standard of review for reconsideration requests challenging CPE reports. Accordingly, nothing about the Despegar IRP Declaration or the 2016 Resolution requires the Board to take any action with respect to the CPE Report beyond determining whether ICANN org and the CPE Provider followed established policy and procedure with respect to that report. As discussed further below, the Requestors identify no violations of established policy or procedure with respect to the CPE Report.

          Moreover, to the extent the Requestors are arguing that the Despegar IRP Declaration mandates that the Board undertake a review of the CPE Process as a whole, as described above, the Board did undertake such a review: the CPE Process Review. DotMusic challenged the outcome of the CPE Process Review in Request 18-5,18 which the Board denied.19 The Requestors have not identified any material information that the Board failed to consider, or any false or misleading information on which the Board relied, in declining to overturn the CPE Report in light of the Despegar IRP Declaration or otherwise responding to it.

        3. The Board's Acceptance of the GAC's Category 1 and Category 2 Advice Has No Bearing on DotMusic's Claim for Community Priority.

          The Requestors assert that ICANN org should have given "preferential treatment" to the Application in response to the GAC's Category 1 and 2 Advice.20 The GAC's Category 1 Advice suggested that certain types of strings should be subject to additional safeguards. These types of strings included: (a) strings that involve regulated sectors; (b) strings that raise consumer protection concerns; and (c) other sensitive strings. .MUSIC was one of the new gTLDs subject to the GAC's Category 1 Advice as a string that raises consumer protection concerns – namely, intellectual property concerns.21 The GAC's Category 2 Advice suggested, among other things, that strings representing generic terms (Generic Term Strings) should not be operated as exclusive access registries unless doing so would "serve a public interest goal."22 .MUSIC also was one of the Generic Term Strings subject to the GAC's Category 2 Advice.

          The BAMC determined, and the Board agrees, that nothing in the Board's acceptance of and response to the GAC's Category 1 and 2 Advice required ICANN org to give "preferential treatment" to community applications for .MUSIC.23 The GAC's Category 1 and 2 Advice did not even discuss community versus standard applications. Moreover, contrary to what the Requestors assert, the .MUSIC string was subject to Category 1 Advice because it raised intellectual property concerns, not because it involved a regulated sector.24 As such, nothing about the GAC's Category 1 Advice implied that .MUSIC involved a community with "cohesion" as the Requestors suggest.25 Regarding the Category 2 Advice, the GAC stated that the Generic Term Strings, such as .MUSIC, represented generic terms for which exclusive registry access was not appropriate. The GAC's advice and ICANN org's acceptance of the Category 2 Advice has no bearing or relationship to community priority. Thus, the Board agrees with the BAMC's conclusion that the Requestors' argument does not support reconsideration.

        4. Nothing in the Generic Names Supporting Organization's (GNSO) Recommendations Required that Claims of Community Priority be "Taken on Trust."

          The Requestors claim that CPE should not have been required at all because ICANN org's GNSO recommended that an application's assertions of community representation should be "taken on trust."26 The Requestors misread the language of the GNSO's implementation guidelines, which are not the GNSO's policy recommendations, and which call for some type of CPE. Specifically, the GNSO noted that:

          Where an applicant lays any claim that the TLD is intended to support a particular community such as a sponsored TLD, or any other TLD intended for a specified community, that claim will be taken on trust with the following exceptions:

          (i) the claim relates to a string that is also subject to another application and the claim to support a community is being used to gain priority for the application; and

          (ii) a formal objection process is initiated.27

          Accordingly, the Guidebook provides that "[e]valuation of an applicant's designation as community-based will occur only in the event of a contention situation that results in a community priority evaluation."28 An applicant for a community-based application must choose to undergo CPE, although it is not required. Such applicants choose to do so because only via CPE can they gain priority over other competing applications for the same string.29 Therefore, no established policy or procedure exists that requires ICANN org to take DotMusic's claim of community priority "on trust." As such, ICANN did not violate any policies or procedures in declining to take DotMusic's claim of community priority "on trust."

        5. The Requestors Have Not Demonstrated Any Conflict of Interest on the Part of the CPE Provider.

          The Requestors contend that the CPE Provider had a conflict of interest with respect to the Application because Eric Schmidt, the executive Chairman of Google from 2001 to 2017, was a member of the Board of Directors of the Economist Group, the CPE Provider's parent company, from November 2013 through December 2015,30 and Vint Cerf, Vice President of Google since 2003, "chaired an ICANN strategy Panel in 2013 (when applications were being evaluated)," and Google also submitted an application for .MUSIC.31 The Board agrees with the BAMC that this argument does not support reconsideration for the following reasons.

          First, the Requestors present no evidence that the CPE Provider failed to confirm that none of the evaluation panelists or core team members had any conflicts with respect to the community-based applications as required by the Guidebook, the CPE Panel Process Document and the CPE Guidelines.32 The Requestors do not allege that Eric Schmidt—a high level executive—was an evaluation panelist or a core team member (he was not), or that he had any influence over, or knowledge of, the CPE Report (or even had any involvement whatsoever with the CPE Provider, which is a single division within the Economist Group). In fact, the CPE Report was issued two months after Mr. Schmidt ceased to be a board member of the Economist Group.33 Likewise, DotMusic has not explained how Vint Cerf's position on an ICANN Strategy Panel concerning the Internet Governance Ecosystem 34 in 2013, three years before the CPE Report was issued, had any effect on the Application.

          Second, the sole basis for the Requestors' bias argument is their contention (based on a sample set of 22 CPE reports) that community applications that were in contention with Google were more likely to fail CPE.35 The fact that many applications did not prevail in CPE fails to show any procedural violation whatsoever. Any application that prevails in CPE is awarded priority over all other applications therefore, the CPE process intentionally sets a high bar for an application to prevail.36 As such, that numerous applications did not prevail in CPE does not in any way demonstrate that the CPE Provider failed to follow established procedure and policy in ensuring that the members of the CPE Provider had no conflicts with respect to the Application.37 Moreover, the CoE Report on which DotMusic relies for these arguments concluded that "there is no evidence that Google in any way influenced the decisions taken on CPEs."38

        6. ICANN Org Is Not Involved in Scoring CPE Criteria.

          The Requestors argue that certain communications between ICANN org and the CPE Provider that were identified in the Dot Registry v. ICANN IRP (CPE Communications) demonstrate that ICANN org "materially" revised the CPE Report in violation of established policy and procedure.39  The BAMC concluded, and the Board agrees, that nothing in the CPE Communications supports the Requestors' view that ICANN org revised the CPE Provider's scoring on DotMusic's Application. The CPE Process Review's Scope 1 Report confirms that "there is no evidence that ICANN org had any undue influence on the CPE Provider with respect to the CPE reports issued by the CPE Provider or engaged in any impropriety in the CPE process," including with respect to the Application.40 When ICANN org provided input to the CPE Provider, that input did not involve challenging the CPE Provider's conclusions (including scoring determinations), but rather ensuring that the CPE Reports were clear and "that the CPE Provider had engaged in a robust discussion on each CPE criterion in the CPE report.41 FTI observed that "ICANN organization did not suggest that the CPE Provider make changes in the final scoring or adjust the rational set forth in the CPE report[s]."42

          The Requestors identify no established policy or procedure (because there is none) preventing ICANN org from communicating with the CPE Provider regarding the language in CPE reports. Nor does anything in the CPE Communications demonstrate, as the Requestors argue, that the CPE Provider lacked the necessary expertise to conduct CPEs. As such, the Requestors have not stated a basis for reconsideration in this regard.

        7. The CPE Report did not Implicate Due Process Rights.

          The Board agrees with the BAMC's determination that the Requestors' assertion that the CPE Provider and ICANN org failed to "follow due process" does not warrant reconsideration.43 The Requestors have not demonstrated any failure by the CPE Provider to follow the established policy and procedures for CPE as set forth in the Guidebook.

          The BAMC noted that the relevant Bylaws do not reference due process.44 At bottom, the Requestors are suggesting that there should have been a formal appeal process for decisions by ICANN org's third-party service providers, including the CPE Provider, Legal Rights Objection Panel, and String Confusion Panels. The methods for challenging determinations in the course of the gTLD contention resolution process are set forth in the Guidebook, which was developed after years of extensive discussions with a wide variety of stakeholder groups, including governments, individuals, civil society, business and intellectual property constituencies, and the technology community.45 Numerous drafts of the Guidebook itself were released for public comment, and revised in light of meaningful community input.46 The time for challenging the Guidebook has long passed.47

          Moreover, the Guidebook provides a path for challenging the results of the CPE process: Module 6 of the Guidebook states that applicants, including DotMusic, "may utilize any accountability mechanism set forth in ICANN's Bylaws for purposes of challenging any final decision made by ICANN with respect to the application."48 The Requestors have exercised this right by invoking the Reconsideration process repeatedly,49 including with Request 16-5.

          Because the CPE Provider's application of the CPE criteria to the Application was consistent with the Guidebook, ICANN org's acceptance of the CPE Report was also consistent with applicable policies and procedures, and did not implicate any "due process" violation. Nor does the fact that there was no option to appeal the substance of evaluation results implicate any due process violation.

        8. The Requestors' Claim Concerning Revenues from Auctions Does Not Support Reconsideration.

          The Board agrees with the BAMC's conclusion that the Requestors have not provided any evidence (because none exists) to support the Requestors' claim that ICANN org's acceptance of the CPE Report was motivated by some sort of financial incentive to earn revenues through the auction process. Further, the Requestors have not shown that any applicable ICANN policy or procedure was violated. Thus, this argument does not support reconsideration.

        9. The CPE Provider Adhered to Applicable Policies and Procedures in its Application of the CPE Criteria.

          The Requestors object to the CPE Provider's decision to award only 10 of the possible 16 points to the Application. For the reasons set forth in Section VI.I of Attachment 1 to the BAMC Recommendation, which are incorporated herein by reference, the Board agrees with the BAMC's findings that reconsideration is not warranted because the Requestors failed to demonstrate that the CPE Provider violated any established policy or procedure in scoring the Application. Moreover, the Board agrees with the BAMC that the Requestors' argument represents a substantive disagreement with the CPE Provider's conclusions, and that this is not a sufficient basis for reconsideration.

        10. The Requestors' Claims Regarding the CPE Process Review Do Not Support Reconsideration.

          The BAMC determined, and the Board agrees, that the Requestors' claims regarding the CPE Process Review do not support reconsideration for all the reasons detailed in Section VI.K of Attachment 1 to the BAMC Recommendation, which is incorporated herein by reference. Specifically, the Board finds that the Requestors' criticisms concerning the conclusion of the CPE Process Review do not support reconsideration. The Board further notes that it addressed many of the Requestors' concerns in its Action on Reconsideration Request 18-5, which are incorporated herein by reference.

          The Board also agrees with the BAMC's conclusion that Requestor DotMusic's 50 demand that ICANN org disclose all documents related to the CPE Process Review is not required by any established policy or procedure. Further, the Board previously addressed DotMusic's demand for the same documents it its Action on Reconsideration Request 18-1, which is incorporated herein by reference. The Board also agrees with the BAMC's conclusion that there is no established policy or procedure requiring ICANN org to bear DotMusic's costs and expenses for reviewing any documents produced by ICANN org and for preparing supplemental submissions to the BAMC concerning those documents. The Board further agrees with BAMC that there is no established policy or procedure requiring ICANN org to provide DotMusic with a list of specific concerns about Request 16-5 following DotMusic's supplemental submission and to schedule an in person presentation to address them (once the above-described conditions are met).51

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

          As an initial matter, Request 16-5 was submitted pursuant to the 11 February 2016 Bylaws, see Discussion supra, which do not call for a rebuttal to the BAMC's recommendation.52 Nonetheless, the Board has considered the Requestors' Rebuttal and finds that the Requestors have not provided any additional arguments or facts supporting reconsideration.

          1. The Requestors' Arguments Concerning the Community Definition Do Not Support Reconsideration.

            The Requestors assert that the CPE Provider misapplied the evaluation criteria on community establishment (Criterion 1) because it relied upon the community defined in response to Question 20D of DotMusic's Application. The Requestors contend that the Guidebook required the CPE Provider to rely solely on the community definition set forth in DotMusic's response to Question 20A.53 As support, the Requestors cite to a chart in the Attachment 2 to Module 2 of the Guidebook, which explains the evaluation questions, criteria, scoring and evaluation methodology of new gTLD applications.54 The explanation for the "Question" column of the chart for Question 20A states:

            Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.55

            The Requestors argue that this explanation required the CPE Provider to apply the definition of the community set forth in DotMusic's response to Question 20A. The Board finds that this argument ignores the explanation set forth in the "Criteria" column for Question 20A which provides:

            Responses to Question 20 will be regarded as firm commitments to the specified community and reflected in the Registry Agreement, provided the application is successful. Responses are not scored in the Initial Evaluation. Responses may be scored in a community priority evaluation, if applicable. Criteria and scoring methodology for the community priority evaluation are described in Module 4 of the Applicant Guidebook.56

            Nothing in Module 4 of the Guidebook requires the CPE Provider to consider only DotMusic's response to Question 20A, without looking at the rest of the Application in evaluating Criterion 1.57 As such, the Board finds that this argument does not support reconsideration because the Requestors have not shown that the CPE Provider's evaluation of Criterion 1 was inconsistent with the Guidebook or any other established policies and procedures.

            Second, DotMusic argues that the CPE Provider used the wrong community definition because the CPE Provider did "not explicitly mention Requestor's community definition in its CPE" and instead "create[d] its own 'general definition' of the community that was derived from Question 20D."58 In response to Question 20A (the "name and full description of the community that the applicant is committing to serve"), DotMusic wrote that the name of the community was the "Music Community," then described the community. In the course of describing the community, DotMusic stated that, "[t]he Music Community is strictly delineated using established NAICS codes . . . organized with the following delineation," then listed the NAICS codes that the CPE Provider included in the CPE Report.59 Accordingly, even if the CPE Provider had been required to consider only DotMusic's response to Question 20A—which it was not—the CPE Provider's consideration of the NAICS codes would have been appropriate.

            Third, the Requestors assert that the language included in DotMusic's response to Question 20D, concerned "the Eligibility criterion[]," not the community definition, and therefore the CPE Provider should not have considered it when it evaluated Criterion 1.60 As explained above, the Guidebook does not require this level of separation. Additionally, the Board notes that Question 20D does not reference eligibility; Question 20D asked DotMusic to "[e]xplain the relationship between the applied-for gTLD string and the community identified in [Question 20A]".61

            In response to Question 20D, DotMusic wrote, among other things, ".MUSIC relates to the Community by representing all constituents involved in music creation, production and distribution, including government culture agencies and arts councils and other complementor [sic] organizations involved in support activities that are aligned with the .MUSIC mission."62 DotMusic does not identify any Guidebook criterion or applicable policy or procedure that prohibited the CPE Provider from considering the "constituents" "represent[ed]" by the community defined in the Application when it assessed Community Establishment. For this additional reason, this argument does not support reconsideration.

            Fourth, DotMusic argues that because it defined the Music Community as an "organized community of individuals, organizations and business[es], a 'logical alliance of communities of a similar nature ("COMMUNITY")', that relate to music," the CPE Provider was required to "acknowledge[] that [DotMusic] met the precise definition of a 'logical alliance' that possesses 'awareness and recognition' among its members."63 The BAMC addressed this argument in its Recommendation 64 and the Board incorporates the BAMC's reasoning as if fully stated herein. The BAMC determined the Guidebook notes that "a logical alliance of communities" is "viable" as a community, "provided the requisite awareness and recognition of the community is at hand among the members."65 Because the CPE Provider did not find the requisite awareness and recognition among the members of the overarching community, the CPE Provider followed the directive of the Guidebook and awarded the Application zero points on Criterion 1.66

          2. The Requestors' Remaining Arguments Have Been Previously Addressed and Do Not Support Reconsideration.

            The Requestors repeat criticisms of the CPE Process Review Reports that it has already raised several times, including in Request 18-5.67 The Board addressed these arguments on 18 July 2018, which are incorporated herein by reference.68 The Requestors' remaining arguments in their Rebuttal reiterate arguments made in Request 16-5 and the materials submitted in support, all of which the BAMC considered in issuing its Recommendation.

          3. The Requestors' Response to the Invitation For Additional Briefing.

            Finally, the Board must address the Requestors' claim that they never "rejected" the BAMC's invitation to make additional submissions in support of Request 16-5. In the Rebuttal, the Requestors state that it is "inaccurate" to characterize its response to the BAMC's invitation as a rejection.69 That, however, was precisely the Requestors' characterization of its response to the invitation. On 5 April 2018, in response to the BAMC's invitation to make additional submissions, the Requestors wrote that "DotMusic rejects ICANN's attempt to impose artificial constraints on any additional submissions regarding Reconsideration Request 16-5" and thereafter submitted no additional briefing.70 It is incorrect to now suggest that DotMusic's response to the BAMC was instead a request "to make unconstrained written submissions and an in-person presentation."71

            For the foregoing reasons, the Board concludes that reconsideration is not warranted.

            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.

    5. Consideration of .AMAZON

      No Resolutions taken.

    6. Acceptance of the Second Organizational Review of the NomCom – Final Report and Recommendations

      Whereas, the second Organizational Review of the Nominating Committee (NomCom) commenced in June 2017, in accordance with the ICANN Bylaws, Article 4, Section 4.4.

      Whereas, the independent examiner that conducted the second NomCom Review produced an assessment report that was published for public consultation on 10 January 2018, a draft final report that was published for public comment on 27 March 2018, and a final report, containing twenty-seven (27) recommendations, that was published on 5 June 2018.

      Whereas, the NomCom Review Implementation Planning Team analyzed the independent examiner's recommendations for feasibility and usefulness, considered provisional budget implications, and anticipated resources to propose a prioritized implementation timeline.

      Whereas, the NomCom Review Implementation Planning Team prepared a draft Feasibility Assessment and Initial Implementation Plan (FAIIP), and presented it to interested community groups during ICANN63, receiving broad support from recipients.

      Whereas, having consulted regularly with the community as well as the 2018 and 2019 NomComs, the Implementation Planning Team, approved the final FAIIP with full consensus on 14 December 2018.

      Whereas, the Board notes that the FAIIP approval process did not fully reflect the procedure detailed in the organizational flow chart, where it is stated that the Supporting Organization/Advisory Committee (SO/AC) under review approves the FAIIP. This deviation is due to the NomCom's role and membership structure that differs significantly from that of the councils and leaderships of those SOs and ACs that are subject to organizational reviews.72 The Implementation Planning Team's unanimous support for the FAIIP, the representativeness of its membership, the transparency of its work, and the accountability of its outreach efforts throughout its work, including during ICANN63, all compensate for the lack of the formal approval by an advisory committee or council that occurs during the organizational review of a SO or an AC.

      Whereas, the NomCom Review Implementation Planning Team supported all 27 recommendations of the independent examiner, while providing minor modifications to four of the 27 recommendations, as detailed in the FAIIP.

      Whereas, the Organizational Effectiveness Committee (OEC) of the ICANN Board received briefings from the independent examiner on its final report and the NomCom Review Implementation Planning Team on its FAIIP during the OEC meeting on 8 January 2019.

      Whereas, the OEC considered the final report, the FAIIP, and the public comment input in order to reach a recommendation to the Board for how to proceed with the second NomCom Review. The OEC recommended that the Board accepts both the NomCom Review independent examiner's final report and the Implementation Planning Team's FAIIP. The OEC also recommended that the Board instruct the NomCom Review Implementation Planning Team to convene an implementation working group to develop a detailed implementation plan for the recommendations, as detailed in the FAIIP, within six months from the adoption of this resolution, and for that implementation working group to oversee the implementation of these recommendations, once the Board has approved said detailed implementation plan.73

      Resolved (2019.03.14.13), the Board acknowledges the independent examiner's diligent work and thanks it for producing a comprehensive final report aimed at improving the NomCom's effectiveness, transparency, and accountability.

      Resolved (2019.03.14.14), the Board acknowledges the work and support of the NomCom Review Working Party and the NomCom Review Implementation Planning Team during the review process. The Board thanks the NomCom Review Implementation Planning Team for their diligent and insightful work in producing the Feasibility Assessment and Initial Implementation Plan that was approved with full consensus by the NomCom Review Implementation Planning Team on 14 December 2018.

      Resolved (2019.03.14.15), the Board accepts the final report from the independent examiner.

      Resolved (2019.03.14.16), the Board accepts the Feasibility Assessment and Initial Implementation Plan from the NomCom Review Implementation Planning Team, subject to appropriate implementation costing.  The Board directs the ICANN President and CEO, or his designee(s), to support the NomCom Review Implementation Planning Team in the development and submission to the Board, through the OEC, of a plan for the implementation of the accepted recommendations. The ICANN President and CEO, or his designee(s), is directed to report back to the Board on the plan and any community input.

      Resolved (2019.03.14.17), to support this action the Board requests that the NomCom Review Implementation Planning Team convene a working group that drafts a detailed implementation plan of the recommendations, as detailed in the FAIIP. The detailed implementation plan shall be submitted to the Board as soon as possible, but no later than six months after the adoption of this resolution. The implementation plan should contain a realistic timeline for the implementation, a definition of desired outcomes, an explanation of how the implementation addresses underlying issues identified in the final report, and a way to measure current state as well as progress toward the desired outcome. The working group shall also work with ICANN organization to include expected budgetary implications for each of the implementation steps into its detailed implementation plan. The implementation plan shall incorporate a phased approach that allows for easy-to-implement and least costly improvements to be implemented first, with those items with more significant budget implications to be addressed later in the implementation process.

      Resolved (2019.03.14.18), the Board directs the NomCom Review implementation working group to oversee the implementation process, once the Board has accepted the detailed implementation plan. Any budgetary requests resulting from the implementation shall be made in line with ICANN org's annual budgeting processes.

      Resolved (2019.03.14.19) The Board directs the NomCom Review implementation working group to provide to the OEC with six-monthly written implementation reports on progress against the implementation plan, including, but not limited to, progress toward metrics detailed in the implementation plan and use of allocated budget.

      Rationale for Resolutions 2019.03.14.13 - 2019.03.14.19

      Why is the Board addressing the issue?

      To ensure ICANN's multistakeholder model remains transparent and accountable, and to improve its performance, ICANN conducts Organizational Reviews of its Supporting Organizations (SOs), Advisory Committees (ACs) (other than the Governmental Advisory Committee) and the Nominating Committee (NomCom), as prescribed in Article 4, Section 4.4 of its Bylaws. The second NomCom Review commenced in June 2017. The independent examiner conducting the review produced a final report that was published in June 2018. Based on its detailed review of the independent examiner's final report, the NomCom Implementation Planning Team prepared a Feasibility Assessment and Initial Implementation Plan (FAIIP), adopted by full consent on 14 December 2018.

      This action is also in recognition that the approach ICANN has historically taken in evaluating and implementing recommendations from review processes is not sustainable, and that prior to acting on the Final Report recommendations ICANN needs to engage with the community about processes by which ICANN and the community can collectively identify priorities and develop a sustainable cadence for implementing recommendations out of reviews.

      What is the proposal being considered?

      The proposal being considered is for the Board to accept the final report, to accept the Feasibility Assessment and Initial Implementation Plan (FAIIP), and to direct the NomCom Review Implementation Planning Team to convene a NomCom Review implementation working group that oversees the implementation the recommendations, as detailed in the FAIIP.

      Which stakeholders or others were consulted?

      During its work on the NomCom Review, the independent examiner conducted more than 60 interviews with current and former members of the NomCom, the wider ICANN community, the ICANN Board and the ICANN organization, and gathered 85 individual responses to its online survey. The independent examiner held regular meetings with the NomCom Review Working Partythroughout the review, including public meetings at ICANN61 and ICANN62 and meetings with community groups at ICANN63, public consultation on the assessment report, and webinar on the draft final report.

      The independent examiner published its assessment report for public consultation and its draft final report for Public Comment. Ten comments were submitted to the public comment forum – one from an individual and nine on behalf of organizations. (see Summary Report of Public Comment Proceeding). The NomCom Review Working Party, also provided direct feedback to the independent examiner on initial drafts of the assessment report, draft final report and final report.

      The OEC received briefings from the independent examiner on its final report and the NomCom Review Implementation Planning Team on its FAIIP during the OEC meeting on 8 January 2019. The OEC also considered community feedback on the independent examiner's assessment report and draft final report.

      What concerns or issues were raised by the community?

      While the NomCom Review Implementation Planning Team agreed with the spirit of all of the independent examiner's recommendations, it noted concerns with the wording of four recommendations. The NomCom Implementation Planning Team resolved the concerns by making semantic modifications to these four recommendations.

      In general, contributors to the public comment proceedings on the independent examiner's draft final report, expressed overall support for the findings and recommendations included in the report.

      In addition, the community also supported the draft Feasibility Assessment and Initial Implementation Plan that the Implementation Planning Team presented to interested community groups during ICANN 63.

      What significant materials did the Board review?

      The Board has considered the relevant Bylaws provisions, the independent examiner's final report, the NomCom Review Implementation Planning Team's FAIIP, and community feedback on the independent examiner's assessment report and draft final report, and took onboard the OEC's considerations in making this recommendation.

      What factors did the Board find to be significant?

      The Board notes the NomCom Review Implementation Planning Team's and community's overall support for the independent examiner's draft final report and final report and has considered them together with all other community input received throughout the NomCom Review process.

      In the four instances where the NomCom Review Implementation Planning Team agreed with the spirit of recommendation but made wording modifications, the Board believes that the modifications proposed, and the rationale provided in the FAIIP are appropriate to address the issues identified by the independent examiner in the final report. Therefore, the Board accepts the final report and the FAIIP.

      Implementing the proposed improvements is a significant step in assuring that the post-review NomCom is able and capable to fulfill its Bylaws-mandated role and responsibilities.

      Are there positive or negative community impacts?

      This Board action is expected to have a positive impact on the community as it supports the continuing process of facilitating periodic review of ICANN's SOs and ACs, as mandated in the Bylaws. Moreover, implementation of the recommendations will lead to improvements in the transparency, accountability, and effectiveness of the NomCom.

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

      This Board action will have fiscal implications, which will be catalogued in the forthcoming detailed implementation plan, which in itself will be subject to a future Board consideration. The detailed implementation plan shall outline how any budgetary requirements are going to be incorporated into future ICANN budgeting cycles.

      Are there any security, stability or resiliency issues relating to the DNS?

      This Board action is not expected to have a direct effect on security, stability or resiliency issues relating to the DNS.

      How is this action within ICANN's mission and what is the public interest served in this action?

      The Board's action is consistent with ICANN's Mission and its commitment pursuant to Section 4 of the Bylaws to ensure ICANN's multistakeholder model remains transparent and accountable, and to improve the performance of its supporting organizations and advisory committees.

      This action will serve the public interest by contributing to the fulfillment of ICANN's commitment to maintaining and improving its accountability and transparency.

      Is public comment required prior to Board action?

      The independent examiner's draft final report was published for public comment. The draft final Feasibility Assessment and Initial Implementation Plan was presented to interested community groups during ICANN63. No additional public comment prior to Board action is required.

    7. Next Steps Regarding the Composition of the IANA Naming Function Review Team

      No Resolutions taken.

    8. AOB

      1. Name Collision Analysis Project – First Study

        Whereas, on 2 November 2017, the Board requested ICANN's Security and Stability Advisory Committee (SSAC) to develop a plan for Board approval setting out studies of the issue of name collision, with many elements detailed. See https://www.icann.org/resources/board-material/resolutions-2017-11-02-en#2.a.

        Whereas, the SSAC delivered, in September 2018, a proposed Name Collision Analysis Project (NCAP) proposal, which detailed three studies anticipated to meet the call of the Board's 2017 resolution.

        Whereas, in October 2018, the Board Technical Committee (BTC) asked ICANN organization, through the Office of the Chief Technical Officer (OCTO), for an assessment of the NCAP proposal. Subsequently, OCTO and SSAC had discussions that provided additional information and further clarification to OCTO on the details of the proposal.

        Whereas, OCTO's assessment noted that a survey and summary of previous research on name collisions would be valuable, however a data repository and associated policies for use of that repository may not be necessary if a future decision is made to not continue with Study 2 and Study 3. As a result, OCTO refined the scope of the SSAC's proposed Study 1 on Understanding the Current State of Name Collisions to defer the implementation of a data repository and related policy development.

        Whereas, OCTO outlined for the BTC a proposed study on Understanding the Current State of Name Collisions with three goals: 1) examine all prior work on the issue of name collisions and produce a summary report that brings forward important knowledge from prior work into this study, and which can act as a primer for those new to the subject; 2) create a list of results of the data used in past studies, identify gaps, if any, and list additional data that would be required to successfully conduct the two additional identified studies; and 3) provide information that will facilitate a decision on whether the NCAP should proceed with studies 2 and 3 based on the results of the survey of prior work and the availability of data.

        Whereas, the BTC considered the OCTO proposal for a study on Understanding the Current State of Name Collisions, including the financial impact of this and all 3 studies and, on 4 March 2019, recommended that the Board direct ICANN org to move forward with Study 1.

        Resolved (2019.03.14.20), the ICANN Board thanks the SSAC for its work in responding to the November 2017 resolution and developing an initial proposal for the Name Collision Analysis Project (NCAP) and subsequent revisions to that proposal.

        Resolved, (2019.03.14.21), the Board directs ICANN's President and CEO, or his designee(s), to proceed with the Study 1 on the Understanding the Current State of Name Collisions as refined by ICANN org.

        Resolved (2019.03.14.22), the Board directs ICANN's President and CEO, or his designee(s), to identify and make available funding within proper budgetary and procurement limits, and that the expenses incurred for the proposed study shall not exceed [REDACTED FOR NEGOTIATION PURPOSES].

        Resolved (2019.03.14.23), 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 2019.03.14.20 – 2019.03.14.23

        A name collision occurs when an attempt to resolve a name used in a private name space (e.g., under a non-delegated Top-Level Domain, or a short, unqualified name) results in a query to the public Domain Name System (DNS). When the administrative boundaries of private and public namespaces overlap, name resolution may yield unintended or harmful results. This class of as-yet undelegated strings is referred to as "Collision Strings." In some cases, the unintended or harmful results of delegating Collision Strings may be considered "high-risk". Example parameters for classifying a Collision String as high risk include: high frequency of appearance in queries to the root servers, the severity of the impact from Collision Strings, the type of DNS requests, the type of user causing the collision (e.g. emergency services, air traffic controllers, etc.), diversity of query source, and appearance in internal name certificates.

        The Board has previously taken action on name collision issues, and in particular, requested the Security and Stability Advisory Committee (SSAC) to identify studies to address a series of questions that the Board identified to help further inform how ICANN will address the issue of name collision in the further expansion of the domain name space. In response to the Board's 2 November 2017 resolution, the SSAC delivered, in September 2018, a proposed Name Collision Analysis Project (NCAP) proposal. That proposal detailed three sequential studies anticipated to meet the call of that resolution.

        The Board Technical Committee (BTC) then asked ICANN's Office of the Chief Technical Officer (OCTO) for an assessment of the NCAP proposal. As a result of that request there were discussions between OCTO and SSAC to provide additional information and further clarification to OCTO on the details of the proposal.

        Ultimately, OCTO presented the BTC with an assessment that a survey and summary of previous research on name collisions would be valuable, however a data repository and associated policies for use of that repository may not be necessary if a future decision is made to not continue with Study 2 and Study 3. As a result, OCTO refined the scope of the SSAC's proposed Study 1 on Understanding the Current State of Name Collisions to defer the implementation of a data repository and related policy development to subsequent studies. The revised Study 1 has three goals: 1) examine all prior work on the issue of name collisions and produce a summary report that brings forward important knowledge from prior work into this study, and which can act as a primer for those new to the subject; 2) create a list of results of the data used in past studies, identify gaps, if any, and list additional data that would be required to successfully two additional identified studies; and 3) provide information necessary to decide if the NCAP should proceed to further studies based on the results of the survey of prior work and the availability of data.

        The Board is taking this action today for two reasons. First, OCTO's work on the NCAP has proceeded to a point where a study has been sufficiently scoped to be carried out. Second, there is potential interdependency between the outcomes of the name collision studies on the next round of New gTLDs, particularly in gaining more information on the ability to delegate strings that overlap in the public and private namespaces.

        This resolution is expected to have a positive impact on the security, stability and resiliency of the Internet's DNS, as it is designed to gather further information on this important technical challenge. This also serves ICANN's mission in the ensuring a secure and stable operation of the Internet's unique identifier systems. This resolution is in the public interest in meeting ICANN's core value of preserving and enhancing the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet.

        This resolution will have a financial impact, as there are expected costs associated with performing the studies. It instructs ICANN Org only to conduct Study 1 on the Understanding the Current State of Name Collisions as refined by ICANN org and further studies are to be independently considered and instructed further based on the result of Study 1. The ICANN President and CEO is expected to perform this work within the appropriate budgetary practices.

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

Published on 14 March 2019


1 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale

2 https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf.

3 See ICANN Bylaws, 11 February 2016, Art. 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

4 See Guidebook, Module 4, § 4.2 at Pg. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf). See also https://newgtlds.icann.org/en/applicants/cpe.

5 Id. at Module 4, § 4.2 at Pg. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

6 Id. at Module 4, § 4.2.3, Pg. 4-9.

7 Id. Module 4, § 4.2.2.

8 Id. at Module 4, §§ 4.2.2 and 4.2.3. at Pgs. 4-8 and 4-9 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

9 Guidebook, Module 4, § 4.2.3, at Pg. 4-9.

10 Request 16-5, § 6, Pg. 19; DespegarIRP Declaration ¶¶ 66-67 (https://www.icann.org/en/system/files/files/irp-despegar-online-et-al-final-declaration-12feb16-en.pdf).

11 Request 16-5, § 6, Pg. 19.

12 Id. ¶¶ 147, 150 (emphasis added).

13 Request 16-5, § 6, Pg. 19.

14 Board Resolutions 2016.03.10.10-11 (https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a).

15 Id.

16 See https://newgtlds.icann.org/en/applicants/cpe#process-review.

17 Request 16-5, § 8, Pg. 17, 18.

18 Request 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

19 Board Action on Request 18-5, https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

20 Request 16-5, § 8, Pg. 5.

21 See Beijing Communiqué, Annex I, Pg. 9 https://www.icann.org/en/system/files/correspondence/gac-to-board-18apr13-en.pdf; see also https://newgtlds.icann.org/en/applicants/gac-advice/cat2-safeguards.

22 See id., Pg. 11.

23 See https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf. See also http://www.icann.org/en/groups/board/documents/resolutions-new-gtld- 25jun13-en.htm; see also ICANN NGPC Paper No. 2013-06-25-2b: GAC Advice in Beijing Communiqué regarding Safeguard Advice Applicable to Category 2 Strings, Briefing Materials 1, Pgs. 25-31 (http://www.icann.org/en/groups/board/documents/briefing-materials-1- 25jun13-en.pdf); http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm#1.d; see also http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-item-1d- 02jul13-en.pdf, Annex I, New gTLD Agreement.).

24 Request 16-5, § 8, Pg. 5.

25 Id.; see also Blomqvist Opinion, ¶ 52, at pg. 41.

26 Id., § 6, Pg. 3, 6.

27 GNSO Final Report on the Introduction on New Generic Top Level Domains, Implementation Guideline IG H (emphasis added) (http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm).

28 Guidebook Module § 1.2.3.2, at Pg. 1-27.

29 Id.

30 Request 16-5, § 6, Pg. 20. See also DotMusic CPE Process Review Letter, at ¶¶ 26(c), 67b, at Pg. 28, 47 (also arguing that Sir Robin Jacob, a Panelist selected by the ICC in the Community Objection proceedings for .MUSIC and .BAND, represented Samsung, "one of Google's multi-billion dollar partners," in a legal case (for additional detail, see Reconsideration Request 16-7, § 8, at Pg. 18 (marked 17) n.68, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf).

31 DotMusic CPE Process Review Letter, at ¶ 26(c), at Pg. 28.

32 Guidebook § 2.4.3.1, at Pg. 2-33; CPE Panel Process Document at Pg. 2, https://newgtlds.icann.org/en/applicants/cpe; CPE Guidelines at Pg. 22, https://newgtlds.icann.org/en/applicants/cpe.

33 Mr. Schmidt stepped down in about December 2015 (https://www.theguardian.com/media/2015/dec/10/economist-appoints-tessa-jowell-to-board-as-googles-eric-schmidt-departs). The CPE Report was issued on 10 February 2016. (https://newgtlds.icann.org/sites/default/files/tlds/music/music-cpe-1-1115-14110-en.pdf.)

34 See Strategy Panel: ICANN's Role in the Internet Governance Ecosystem (https://www.icann.org/en/system/files/files/report-23feb14-en.pdf).

35 Request 16-5, § 6, Pg. 20.

36 See Guidebook Module 4, § 4.2.3, at Pg. 4-9 ("a qualified community application eliminates all directly contending standard applications, regardless of how well qualified the latter may be. This is a fundamental reason for very stringent requirements for qualification of a community-based application.").

37 The Requestors refer to an exchange with Fadi Chehadé at the public forum. See https://singapore52.icann.org/en/schedule/thu-public-forum/transcript-public-forum-12feb15-en.pdf, Pgs. 61-62. During that exchange, Mr. Chehadé thanked DotMusic for its comments and asked DotMusic to send ICANN a letter explaining DotMusic's concerns. DotMusic never did. Nothing about this exchange comprises an "acknowledgement" of any conflict of interest, as the Requestors imply. See Request 16-5, § 6, Pg. 20.

38 CoE Report, at Pg. 47, cited in DotMusic CPE Process Review Letter, ¶ 26(c), at Pg. 28.

39 Request 16-5, § 6, Pg. 18.

40 FTI Scope 1 Report at Pg. 3 https://www.icann.org/en/system/files/files/cpe-process-review-scope-1-communications-between-icann-cpe-provider-13dec17-en.pdf.

41 Id. at Pg. 12.

42 Id.

43 Request 16-5, § 8, at Pg. 16 (marked as Pg. 15).

44 See ICANN Bylaws, 11 February 2016.

45 Guidebook, Preamble.

46 Id.

47 See https://newgtlds.icann.org/en/applicants/agb, indicating current version of guidebook is dated 4 June 2012. Under the Bylaws in effect in June 2012, Reconsideration Requests were due within thirty days after publication of Board actions or within thirty days after a Requestor became aware of or should reasonably have become aware of challenged staff action. ICANN Bylaws, 16 March 2012, Art. IV, § 2.5 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV).

48 Guidebook, Module 6, § 6, at Pg. 6-4.

49 See Request 14-28, https://www.icann.org/en/system/files/files/request-dotmusic-07jun14-en.pdf; Request 16-7, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf; Request 17-2, https://www.icann.org/en/system/files/files/reconsideration-17-2-dotmusic-request-redacted-18jun17-en.pdf; Request 17-4, https://www.icann.org/en/system/files/files/reconsideration-17-4-dotmusic-dotgay-request-redacted-25jul17-en.pdf; Request 18-1, https://www.icann.org/en/system/files/files/reconsideration-18-1-dotmusic-request-redacted-10mar18-en.pdf; Request 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

50 The Board notes that this claim was raised only by Requestor DotMusic, not the other Requestors, in a supplemental submission in support of Request 16-5. See https://www.icann.org/en/system/files/files/reconsideration-16-3-et-al-dotgay-dechert-to-icann-board-bamc-redacted-23mar18-en.pdf.

51 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf.

52 See ICANN Bylaws, 11 February 2016, Art. 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

53 Rebuttal, Pgs. 3-5 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-requestors-rebuttal-to-bamc-recommendation-request-12feb19-en.pdf).

54 Id.; see also Guidebook, Module 2, Attachment 2 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf).

55 Guidebook, Module 2, Attachment 2, Pg. A-14 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf) (emphasis added).

56 Id. (emphasis added)

57 See Guidebook, Module 4, § 4.2.3, at Pgs. 4-10 – 4-12.

58 Rebuttal, at Pg. 6.

59 Application, Question 20A (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

60 Rebuttal, at Pg. 4 (internal quotation marks omitted).

61 Guidebook, Attachment 2 to Module 2, at Pg. A-14.

62 Application, Question 20D, (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

63 Rebuttal, at Pg. 4-5.

64 See Attachment 1 to BAMC Recommendation, at Pg. 29 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-bamc-recommendation-attachment-1-25jan19-en.pdf).

65 Guidebook, Module 4, § 4.2.3, at Pg. 4-12 (emphasis added).

66 Id.

67 See https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

68 See https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

69 Rebuttal, at Pg. 1.

70 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf (emphasis added).

71 Rebuttal, at Pg. 1.

72 An update to the flow chart to clarify this point will be made in the standard of reviewing and updating the ICANN process documentation.

73 The Board's acceptance of the detailed implementation plan is a deviation from the organizational review process flowchart but this step is in accordance with standard practice for organizational reviews because the Board is exercising its fiduciary responsibility by reviewing and accepting said detailed implementation plan. An update to the flow chart will be made in the standard process of reviewing and updating the ICANN process documentation